Re: SACRED Protocol (long!)

Hi again Marshall.

You are not being difficult at all (perhaps I am the one being
difficult...;). On the contrary, thanks for continuing the discussion.
Please find my responses below.

On Sat, 8 Dec 2001, Marshall T. Rose wrote:

> 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.

SACRED is not a sasl mechanism. It currently makes use of SASL to
establish a security context, but could also make use of other
security context establishing frameworks.

> 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.

This is the core of the discussion yes, and I will try to summarize
in a subsequent posting.

> 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 ...

Honestly, I don't think that work will be too onerous. C.f. with other
security-related protocols that runs over http.

> 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...

As I mentioned in an earlier posting, the concern we had about the
current draft stemmed from two facts:

-it binds SACRED tightly to BEEP; and
-there are widely implemented protocols that do not support SASL (or
 other security frameworks), and platforms that SACRED is expected to
 serve support these protocols and not BEEP.

We therefore felt that making SACRED payloads security-aware would
alleviate these concerns. And yes, at least one mapping to some
existing transport is needed, and given the latter factor above I
suggest that the initial mapping shall be to SOAP.

BR,
-- Magnus

> 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.
> >
> >
> >
>
>

-- Magnus
Magnus Nystrom
RSA Security