Re: SACRED Protocol (long!)

Marshall,

I certainly agree with you that we need to be thoughtful on security
issues - and that's why we are specifying the use of a security
framework (SASL, so far) and strong mechanisms within that framework
(SRP, so far). There are no differencies between us there, AFAICT.

SACRED in the form proposed this week by me is quite self-sufficient
and puts very few requirements on the protocol it runs on top of.
Compare once again with OCSP. The authors of OCSP wanted it to be
possible to run OCSP over a variety of protocols, including http,
smtp, and ldap. By making sure that OCSP could protect its own
exchanges and minimizing the requirements on underlying protocols they
achieved this. There are other examples of this, as I mentioned in my
previous posting.

The fact is, BEEP is not universally implemented. We should allow for
other bindings too, and make the work to do those mappings as simple
as possible.

-- Magnus

On Fri, 7 Dec 2001, Marshall T. Rose wrote:

> > With the current draft, it was not clear how to do this, and hence if
> > someone would have liked to implement SACRED on top of http, they
> > would more or less had been forced to start all over again (since the
> > current proposal relied on BEEP's support of SASL, and http does not
> > have this support (yet)).
>
> i think the problem is the "if someone wanted to implement sacred on http"
> part...
>
> the reason that people use beep is because it allows them to focus on the
> 90% of the problem that's "interesting" rather than the 10% of the problem
> that's administrative. otherwise, 90% of the effort gets spent dealing with
> the administrative part.
>
> if you can get a tight match between http's service and your application's
> requirements, then you should use http. the problem comes up when the match
> isn't tight enough.
>
> in this particular case, the ietf/iesg is pretty clear that application
> protocols be thoughtful with respect to security issues, and that the use of
> sasl is a good first step.
>
>
> > My suggestion is to define a mapping to SOAP. Since SOAP already maps
> > to BEEP (as I understand it) and also has a http binding this would
> > seem to take care of our immediate requirements.
>
> the problem, of course, is what happens if you don't run soap over beep. in
> that case, you're back to square one, because the iesg will require that you
> flesh out all the security stuff you'll need to implement sacred in that
> environment.
>
> if it positively, absolutely is a requirement that sacred run directly over
> http, then time would be far better spent dealing with the security issues
> of that mapping. you won't need beep, because it's not saving you any time.
> instead, you get to spend 90% of your time working on the administrative
> overhead instead of focusing on the problem domain. enjoy!
>
> /mtr
>
>
>

-- Magnus
Magnus Nystrom
RSA Security