Re: [kitten] Request for review of a SASL mechanism using the OPAQUE aPAKE

[Rick van Rein <[e-mail]>]

Hello Nadja,

> That is an interesting point I hadn't considered. In the original
> discussion[¹]
> that sparked me writing the draft several people did argue for such
> an OPAQUE
> mechanism to provide a security layer.

Yes, I was one of those.  I was thinking of the (undocumented) work
on RFB that can employ a secure layer, among others.  I made an
embedding of SASL into ASCII that could benefit; and I made

Also, I've rethought what I really find useful, and that was key
derivation as that might help to add entropy to overthrow analysis
with a quantum computer.  This may or may not be a group opinion,
I don't know.

I defined key derivation in Section 2.7 of draft-vanrein-diameter-sasl-07
and left it to applications to use it or not (as is the case with the
encrypting form of security layer).

> And given that OPAQUE *is* a key
> exchange protocol, it does suggest itself.

Yes, it would be a waste to squander such useful information.
The key derivation mechanism noted above is less forceful than a
security layer, and I think it adds value.  (I know this may be
a discussion all of its own.)

> My personal stance on
> that point is
> however that SASL security layer today are strictly worse than just
> using TLS.

TLS however, is designed for single-hop protection.  Protocols that
are commonly relayed, such as HTTP and SIP for which I defined SASL
embeddings, may be difficult to protect withouth end-to-end keying.

> In fact, the only way I'd approach a security layer is as "STARTTLS in
> a trench coat" — i.e. by using in essence TLS-PSK to bootstrap the
> TLS context to
> then use as security layer.

I'm not sure I understand.  Are you talking of TLS after SASL?
That is quite uncommon, it is unsafe for most SASL mechanisms
(I know OPAQUE can do this, but most application protocols will
probably not support STARTTLS after AUTH).

If you intend to use TLS-PSK you need to be aware that there is no
framework for standard key identities, so you could not rely on it
in a standard.  But I suppose a reasonable hack could be to send
a prefix UUID to your key identity (if any) and formalise what the
meaning of that UUID is.  The risk of a clash is minimal, and it
does fit within the TLS-PSK framework.


Cheers,
 -Rick