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

[Nadja von Reitzenstein Cerpnjak <[e-mail]>]

As apparently my last reply got lost to the mail deities before reaching 
the list I hope it'll work better on the second try.

Original Message:

EHLO Simon!

> - I'm very happy you modeled this as a GS2 profile, and would like to
>    explore/help establish it into a GSS-API mechanism.  Some additional
>    wording on GSS-API credentials and naming would be useful.

Thank you, I would in fact love help there. My experience with the 
GSS-API is
limited to really only Kerberos V5, and even there I have spent more time
understanding and implementing the Kerberos Network Protocol than I have 
with
its GSS-API implementation.

> - Don't define a SASL family!  SASL families is a mess in SASL which
>    leads to sub-negotiation that have no well-established solution in
>    SASL.  The naming can be the same, only that new separate documents
>    needs to be defined orthogonal to this if new parameters are
>    developed.  Sub-negotiating between SCRAM-SHA1 and SCRAM-SHA256 has
>    proved challenging.

Yeah, I have been on the receiving end of the troubles that come from 
trying to
move an existing user base to SCRAM-SHA-256 in the XMPP world.

However, with OPAQUE specifically a valid point can be made for another 
set of
parameters, even outside of government regulations requiring certain
cryptographic primitives:
OPAQUE has the advantage that the server private key can be used via a HSM,
making a leak of stored user credentials a significantly less drastic 
security
incident. But the ristretto255 and decaf448 groups are quite new 
developments
and somewhat niche. Compared to NIST P-256 the HSM support for both of the
former is exceedingly rare.
I personally feel more comfortable with ristretto255 and Argon2, but 
with the
above point an OPAQUE variant using NIST P-256 and e.g. PBKDF#2 may very 
well be
more secure in some circumstances.

So if we were to take this into account this would lead us to define two
OPAQUE-based mechanisms, called e.g. OPAQUE-A255BLK and OPAQUE-P256SHA, the
former using Argon2, ristretto255 and BLAKE3, the latter PBKDF#2, NIST 
P-256 and
{HKDF-,HMAC-,}SHA-256. And given that the only remaining difference between
defining a mechanism family versus two discrete specifications would be the
point in your blog post regarding the more complicated specification.

I guess this question somewhat boils down to if we should let this kind of
implementation support inform the standardization work this drastically.
Potentially the correct approach would be to do the exact opposite; 
requiring
ristretto255 and/or decaf448 may well push the next generation of HSM to add
support for those groups, and adding ristretto255 support is very much 
not an
undue burden if Curve25519 is already supported.

> - Require TLS channel bindings.  I don't think there is sufficient
>    use-cases ofr non-TLS settings for IETF application protocols any more
>    (and those that may exist aren't likely to be using state-of-the-art
>    authentication protocols -- and can always profile a mechanism if
>    necessary).  The recent RFC9622 tls-exporter has sufficient properties
>    to always be included in authentication.  Having an optional TLS
>    channel binding also leads to sub-negotiation between PLUS and
>    non-PLUS variants.

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. And given that OPAQUE *is* a key
exchange protocol, it does suggest itself. My personal stance on that 
point is
however that SASL security layer today are strictly worse than just 
using TLS.
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 about requiring tls-exporter specifically. Many TLS 
implementation
such as Windows' schannel and Apple's security-framework AFAIK don't offer
exporter functionality at all. Also channel bindings become most useful 
when the
channel isn't authenticated using PKIX or similar, i.e. in the context 
of RFC
7250 and the related RawPublicKey certificate type of TLS 1.3. Both of which
notably are *also* not supported by the two aforementioned implementations.

That all being said this too is somewhat the same question as above; how 
much
existing implementation support should inform our standardization work.

> I'm happy to help your effort, and will look into developing a prototype
> as well within GNU SASL.

That would be wonderful, yes! I'll work on an implementation of this for the
rsasl library, although it may take me several more days to get that done.

Thanks for your kind words,
Nadja

[¹]: https://github.com/stef/libopaque/issues/31