Subject: RE: protocol progress

From: "Linn, John" <[email-masked]>
Date: Thu, 20 Sep 2001 13:40:47 -0400

I'm also trying to understand the layering here for the SASL case, so would
like to paraphrase what I believe is being proposed.  I'm taking it that
there would be four sublayers, descending as follows:

(1) the SACRED application, carrying the transferred credential data and
assuming
    a secured channel from a lower sublayer
(2) BEEP
(3) SASL
(4) the SACRED-specified SASL mechanism (with SRP as MTI, and PDM as a
possible
    additional choice)

Potentially, another arbitrary SASL mechanism could be used in place of (4),
but not all SASL mechanisms might have the operational properties desired
for SACRED purposes (e.g., ability to operate without pre-configuration at
the client).  

If this is the case, it seems to imply that there would actually be two
distinct "SACRED protocols", at (1) and (4).  Do I have this right?  

--jl

> -----Original Message-----
> From: Magnus Nystrom [mailto:[email-masked]]
> Sent: Thursday, September 20, 2001 8:58 AM
> To: Stephen Farrell
> Cc: ietf-sacred
> Subject: Re: protocol progress
> 
> 
> 
> Stephen,
> 
> On Thu, 20 Sep 2001, Stephen Farrell wrote:
> 
> > Magnus,
> >
> > Main open issue seems to be SASL or not.
> >
> > > > 1. should we specify both PDM and SRP schemes? [yes]
> > >
> > > I don't see a strong reason why. With a suitable framework, it is
> > > enough to specify one MUST. Actual other schemes can be described
> > > separately, e.g. as SASL mechanisms, should we choose to 
> follow that
> > > path.
> >
> > So you're for just working on SRP for now. Ok, I can buy that, but
> > would suggest we try to also maintain an I-D for PDM (as a 
> subsidiary
> > document) if we can - just to make sure we're really "pluggable"
> > for authentication schemes.
> 
> That's fine. But, depending on the chosen authentication framework,
> this may turn out to be very easy (e.g. if SASL is used, then any
> suitable SASL mechanism would plug in). I'd also love to see separate
> I-Ds for other transports, e.g. SOAP - to make sure there is a
> transport independence.
> 
> > > > 3. Should we rely on use of SASL for authentication or should
> > > > we define the authentication elements as part of our messages?
> > > > [Don't use SASL.]
> > >
> > > There are both pros and cons of this. As pointed out by 
> Lawrence, and
> > > this was also my original view, the main advantage of BEEP in this
> > > context is its built-in support for SASL. Otherwise http could be
> > > regarded as a better choice since it is more common and 
> more likely to
> > > be accepted by, e.g., firewalls. The disadvantage of 
> relying on the
> > > transport for security protection of the channel is that
> > > implementation in other transports, e.g. XML Protocol, 
> may need more
> > > work, and for certain transports the security may not be 
> possible to
> > > achieve. Anyway, wrt your response to Lawrence, the SASL 
> layer would
> > > protect the connection. Any extra keys needed, e.g. to decrypt the
> > > credential themselves, would seemingly have to be derived by the
> > > application using either the SASL interface or some separate
> > > mechanism.
> >
> > I still don't see how this really works - how is the SRP-established
> > session key used for BEEP - does it protect all traffic like TLS,
> > or is the key popped up the stack (somehow) to be available to
> > the payload handling code?
> 
> It could be similar to how other SASL mechanisms providing a security
> layer works - all traffic would be protected. See e.g. the description
> of how SASL works with LDAPv3. But as I said, I am not certain anymore
> that one should rely on an underlying transport's security features.
> 
> [...]
> > > I also attach some comments on the first I-D given by 
> Burt Kaliski of
> > > RSA Laboratories. The first ones may become moot when 
> moving to SRP.
> >
> > Let's revist when we're done with the next draft, but I 
> think they'll
> > probably all be addressed.
> 
> Fine, important though to keep them in mind when drafting, I think.
> 
> Cheers,
> -- Magnus
>