Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt

[Nico Williams <[e-mail]>]

On Mon, Apr 06, 2020 at 11:24:31AM +1000, Luke Howard wrote:
> Agreed. I would like to implement mech_ecdh. :) But I would also like
> to avoid scope creep for SAnon due to time and funding constraints.

Understood.  SAnon will be a trivial base for a new mech_dh.

> > - Section 6.1.2
> > 
> >   The acceptor should also send a MIC along with the key, thus proving
> >   it has possession of the shared secret.  This is important, otherwise
> >   reply tokens could be replayed, and though it wouldn't be much of an
> >   attack, it's worth doing.
> 
> Happy to add this, but is it much of an attack? Both parties are
> anonymous, so (as we discovered with GS2) this mechanism is completely
> superfluous unless you intend to use a message protection service (or
> PRF), which will fail in a replay attack.

For pure GSS/SAnon apps it probably makes no difference, but it might
for future stacks combining SAnon with other things.

> Having said that: is there value in the putative MIC being of the
> public keys (as opposed to a constant) given the public keys are
> already input to the KDF?

It can be a MIC over the empty string.

> > - If you allow a target name to be imported as an anonymous name whose
> >   value is the base64 encoding of a raw public key, then the initial
> >   context token should send two public keys, and the response token
> >   should be just a MIC.
> > 
> >   [...]
> 
> How does the initiator learn of the acceptor’s public key? It seems to
> me this is useful for mech_ecdh but not SAnon?

There's two options: the mech_dh method (add a directory) and
leap-of-faith (learn the keys once, keep reusing them.

You wanted to leave the mech_dh thing out of scope, so let's do that.

In Sun's mech_dh there were pluggable name service switch modules for
the "publickey" DB, with files, nisplus, and ldap shipping in Solaris.
That was... a long time ago.  Today we'd use DNS w/ DNSSEC (DANE).

The leap-of-faith thing would work like this: the initiator uses
well-known anon names to set up a security context with some acceptor,
then inquires the resulting initiator and acceptor names, and later sets
up new contexts using the same keys (which might not work if the private
keys are gone).  To make this work at all we'd need a bit on the wire
for indicating that you want the keys to be less-ephemeral.

Anyways, forget the leap-of-faith case for now too.

> > - Section 7
> > 
> > |  The session key K1 is used as the base key for the generation of per-
> > |  message tokens and the GSS-API PRF.  The encryption type of K1 is
> > |  aes128-cts-hmac-sha256-128 as defined in [RFC8009].
> > 
> >   There should be a reference here to RFC4121.  Also, RFC4121 doesn't
> >   mention a K1.  I suspect you need to state how to derive a key of the
> >   enctype (aes128-cts-hmac-sha256-128) that would be equivalent to the
> >   AcceptorSubkey.  You might want to mention that four keys are to be
> >   derived from that per RFC4121 section 2, plus the GSS_Pseudo_random()
> >   key (GSS_C_PRF_KEY_FULL) [RFC8009].
> 
> How about:
> 
>    This session key is equivalent to the acceptor-asserted subkey
>    defined in [RFC4121] Section 2 and is used as the base key for
>    generating keys for per-message tokens and the GSS-API PRF.
> 
>    The session key encryption type is aes128-cts-hmac-sha256-128 as
>    defined in [RFC8009].  The [RFC3961] algorithm protocol parameters
>    are as given in [RFC8009] Section 5.
> 
> I’ll also add a note in 6.2 that AcceptorSubkey MUST be set.

Works for me!

> > - Test vectors?
> 
> I will add.
> 
> > - Section 10
> > 
> >   This section should repeat something about the importance of SAnon
> >   not being negotiated when it's not appropriate.
> 
> “It MUST not be selected if either party requires identification of
> its peer.” – is that OK? I would prefer not to use the word
> negotiated, as SAnon can be explicitly selected outside of
> SPNEGO/NegoEx.

Works for me!

Nico
--