Re: sacred again

Many SASL mechanisms support security layers.

This is covered in RFC 2222.

If the SRP mechanism doesn't define a security layer, it should be
fixed.  SACRED has no business defining its own security layer.

SASL security layers work today; they're supported by IMAP, SMTP, and
LDAP servers.  (Some of the SASL mechanisms with security layers are
GSSAPI and DIGEST-MD5.)

Larry

   Date: Fri, 19 Oct 2001 16:45:03 +0100
   From: Stephen Farrell <[email protected]>

   Radia, All,

   I've started drafting the SRP protocol stuff & am including SRP in 
   the sacred payload, (as opposed to using the SASL SRP mechanism),
   similar to how PDM was handled in the previous draft. Radia raises a 
   point where I'd like some feedback from the list (actually, I'd like 
   feedback from the list about *anything* at all:-)

   Radia Perlman - Boston Center for Networking wrote:
   > 
   [...]
   > I thought that it could be done without
   > any work on Sacred's part by just saying "use any SASL mechanism",
   > and the most work I thought sacred would have to do is to say that
   > the one mandatory SASL mechanism was RFC mumble (which would be SRP).
   > Though maybe SASL-SRP is still just an internet draft, but that
   > wouldn't make any difference.
   > 
   > Radia

   You mean that SASL-SRP does mutual auth and key derivation and that 
   (SRP derived) key is then used to encrypt & integrity-protect all 
   subsequent BEEP traffic. That'd be nice all right, problem is how
   is the SRP-derived key used to do that?

   Be great if BEEP itself took care of this, but AFAIK it doesn't
   (Marshall - would that be a general BEEP thing, using a SASL derived
   key to protect traffic where the SASL mech derives a suitable key?)

   So, if I'm right, that'd mean that we'd have to define our own payload 
   encryption and MACing, where needed. It seemed to me that at this 
   stage we're not getting much from the use of SASL and so I included
   the SRP stage in the payload from the start (arguably better from a 
   layering approach I guess).

   Hence the drift of the current (proto-)draft.

   Stephen.



   -- 
   ____________________________________________________________
   Stephen Farrell         				   
   Baltimore Technologies,   tel: (direct line) +353 1 881 6716
   39 Parkgate Street,                     fax: +353 1 881 7000
   Dublin 8.                mailto:[email protected]
   Ireland                             http://www.baltimore.com