Re: SACRED Protocol (long!)

Hi again Marshall,

What I am trying to say is that our proposal already re-uses the
SASL framework and integrates SASL into SACRED for a very small cost,
namely two extra messages. Not too complicated.

Sure, a mapping is needed. But the way the mapping is done in the
current draft is making it really hard to define SACRED for other
protocols that do not support SASL. One would even have to define
new SACRED PDUs for some mappings, thereby changing the protocol
itself. And, since there are other constituencies that are aiming to
make use of SACRED, e.g. the W3C XKMS WG, whose charter explicitly
states that one of the objectives is harmonization with SACRED, and
who are using other transports (in the case of XKMS SOAP), a tight
binding to BEEP could be counterproductive. My suggestion is therefore
to map to SOAP (and SOAP in turn has mappings to BEEP (soon, at least)
and http).

Speaking of charters, SACRED's own charter states: "Credentials must
be available to many different types of clients with different
characteristics in terms of processing power, storage and network
connectivity." Binding SACRED tightly to BEEP, and therfore requiring
constrained devices to implement BEEP when they already have to
implement SOAP and/or HTTP, does not, IMHO, really match well with
this statement.

Finally, my understanding of BEEP is that it is a protocol framework,
and as such suitable as a basis for a wide range of application
protocols having certain characteristics. As far as I understood from
your "On the design of application protocols" RFC, one of those
characteristics was asynchronous messaging, and BEEP therefore handles
asynchronous message exchanges. Since SACRED, has a clean
request-response, synchronous situation that does not appear to need
BEEP's support of these exchanges, and we, as our current proposal
aims to demonstrate, also are able to handle the security context
establishment ourselves in a simple manner, I feel that this tight
binding to BEEP is not optimal.

-- Magnus


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

> > 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.
>
> we just aren't communicating here...
>
> the basic problem is this: if you write a protocol that both:
>
> - maps onto multiple underlying protocols, and
> - protects its own exchanges
>
> then you are reinventing the wheel, spending more
> design/implementation/review time on administrative overhead and less on the
> application domain that you're trying to deal with.
>
> in other words, you've managed to maximize the pain and focus all the
> engineering energy on the non-essential parts of the system. probably not a
> good trade-off.
>
>
> > 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.
>
> it's true that beep isn't universally implemented.
>
> it's also true that do the other bindings, you'll have to complicate sacred
> in order to make up for the fact that all these other mappings are on top of
> transports that don't adequately deal with security, asynchrony, etc., etc.
>
> and all for the benefit of fragmenting the marketplace, reducing the amount
> of interoperability between implementations, promoting vendor lock-in, etc,
> etc.
>
> just because you can do it this way, doesn't mean you should.