Re: protocol progress

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

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