Re: sacred again

Lawrence,

Now that I've found the expired SASL SRP draft (I found it at 
http://www.forge.com.au/products/Papers/Secure_Remote_Password.htm),
and re-read rfc2222, I tend to agree with you and Bob. The sasl-srp
draft does include a security layer.

So - in the (probably likely;-) absence of further inputs, I'll try
to draft up a protocol with beep+sasl+sasl-srp+sacred-messages-in-xml
and we can then see whether it meets the requirements in rfc3157.

Regards,
Stephen.

Lawrence Greenfield wrote:
> 
> 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