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

[Nico Williams <[e-mail]>]

On Sun, Apr 05, 2020 at 06:49:31PM -0500, Nico Williams wrote:
>  - Section 4.1.4
>    
>    The name string displayed should either be a constant OR, better yet,
>    a base64-encoded hash of the peer's DH key!  The latter especially
>    after context establishment.
> 
>     - GSS_Display_name(GSS_Canonicalize_name(
>                          mech=SAnon,
>                          name=GSS_Import_name(GSS_C_NT_ANONYMOUS, "whatever")))
>         -> "whatever"
> 
>     - GSS_Display_name(GSS_Inquire_context_peer_name(context))
>         -> base64_encode(hash(dh_pubkey))

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.

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

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

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

   The length of the initiator context token would say all that's
   needed -- no ASN.1/DER or whatever would be needed.

 - 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"?

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

 - Test vectors?

 - Section 10

   This section should repeat something about the importance of SAnon
   not being negotiated when it's not appropriate.

Done.

Nico
--