Re: sacred again

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