Re: SACRED Protocol (long!)

hi. i'm just getting more and more confused. perhaps a diagram or two would
help.

are you suggesting that sacred be a:

    - application protocol
    - a sasl mechanism
    - an exchange over soap
    - or ...

if the argument is that sacred has to integrate with multiple application
protocols, then it should be defined as a sasl mechanism.

if the argument is that sacred should be a seperate application protocol,
then we're back to the issue of pain amplification or minimization, and
everyone already knows which of those i favor.

if the argument is that sacred should be defined as a soap exchange, then
the question is what context does the exchange occur in, and who's going to
write down the one-hundred-and-one security issues that the iesg will want
answered with respect to things that layer over soap and http and ...

regardless, i don't understand about the requirement to accomodate protocols
that don't do sasl, since, afaik, any "modern" application protocol
developed in the ietf does sasl...

if it looks like i'm being difficult here, i guess i'm more confused than
anything else...

/mtr

----- Original Message -----
From: "Magnus Nystrom" <[email protected]>
To: "Marshall T. Rose" <[email protected]>
Cc: <[email protected]>; "Marshall Rose" <[email protected]>
Sent: Friday, December 07, 2001 15:08
Subject: 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.
>
>
>