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

[Luke Howard <[e-mail]>]

Hi Nico,

> Even better: base64(dh_pubkey).
> 
> And even better too if that can be used as a target name.
> 
> Then we'd have the building blocks of a modern mech_dh.

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.

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

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?

> - Section 6
> 
>   There should be a requirement that new DH keys be generated every
>   time, no?  Especially on the initiator side, and especially if you
>   don't add the use of a MIC in the response token (see previous
>   comment).

I will clarify the text to say that it must be a fresh key pair.

> - 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.
> 
>   I->A: {PK_i, PK_a}
>   A->I: MIC(SK, {PK_i, PK_a}) || <error>
> 
>         (ahh, you'd have to define an error message, but it could just
>          be a 1-byte code)
> 
>   Note that to reuse keys really does require nonces.  So those would
>   have to be added:
> 
>   I->A: {PK_i, PK_a, nonce}
>   A->I: MIC(SK, {PK_i, PK_a}) || <error>
> 
>   You could even have a half round-trip variant where the initiator
>   sends {PK_i, PK_a, nonce, MIC} and the acceptor sends nothing.

How does the initiator learn of the acceptor’s public key? It seems to me this is useful for mech_ecdh but not SAnon?

> - Section 7
> 
> |  context       the concatenation of the initiator and acceptor public
> |                keys, along with the channel binding application data
> |                (if present)
> 
>   Add "in that order”?

Fixed.

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

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

Cheers,
Luke