Re: sacred again

Stephen et al:

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

RFC 2222 (SASL) specifies a framework for mechanisms to negotiate the use
of a security layer that provides mechanism-defined protections.  This is
used in production with, eg GSSAPI/Kerberos5 to provide integrity and
confidentiality protection for application protocols such as LDAP and
SMTP.

draft-burdis-cat-srp-sasl-04, in section 5, specifies the security layer
for SRP (the SRP family) as a SASL mechanism.  This layer provides
confidentiality, replay protection, and integrity protection.  The keys
and mechanisms used are those established by the SRP exchange.  I won't
vouch for the correctness of this spec, and I don't know about
implementations of it, but it seems to me to cover the territory you're
asking about.  Doesn't it to you?

This draft is unfortunately expired, I can provide it to this list if
necessary.  I believe the finalizing of this work is intended to be a work
item of the almost-but-not-quite-approved SASL WG (where the WG-creation
delay is, as far as I know, entirely IESG overload, not any WG-related
issue).

> 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?)

BEEP can use any SASL mechanism, and can use the mechanism-provided
security layer with any protections provided by that layer.  So BEEP does
everything needed here.

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

This would be entirely unnecessary, confusing, and counter-productive,
IMHO.

 - RL "Bob"