[kitten] GSS & krb5 mutual auth flags aren't -- they are about key confirmation

[Nico Williams <[e-mail]>]

See subject.

I assert that:

 - GSS_C_MUTUAL_FLAG is badly misnamed

 - GSS_C_MUTUAL_FLAGis not, never was, and never could have been about
   mutual authentication in the sense of authenticating two peers to
   each other,

 - and GSS_C_MUTUAL_FLAGis, always was, and only could have been about
   key confirmation.

It is understandable that "mutual authentication" had a somewhat
confusing definition back when RFCs 1508, 1509, and 1510 were written
(huh, notice the sequential RFC numbers...).  But it's time to nail it
down.

First off, a high-level observation: GSS (and Kerberos) always deals in
*two* principal names, so GSS and Kerberos are *always* about mutual
authentication.

Even if the initiator's name is some sort of anonymous name
authentication can still be said to be mutual.  Consider that an
anonymous name's credential might still convey some authorization
information.  E.g., some of a user's group memberships, just not the
user's name.  I.e., not all anonymous identities need be the same.
Indeed, for PK-based mechanisms we could use an initiator's bare public
key as its name even if they are "anonymous", which makes it more
"pseudonymous" than "anonymous" authentication, and still mutual.  (More
on this below.)

Even if both names are anonymous... the same argument about pseudonymity
holds.

The API by its very own nature implies mutual authentication even when
one or the other (or both) name can be anonymous or pseudonymous.


Second, we can look at all the mechanisms we know well enough, and all
the mechanisms we can posit, and see that the above assertions hold:

 - Mechanisms that can have just one, or just two context tokens:

    - Kerberos

      Mutual really only means key confirmation.

      Mutual authentication is obtained naturally in that the acceptor
      cannot GSS_Unwrap() (or GSS_VerifyMIC()) without having the
      requested target acceptor's credentials.

    - Solaris' mech_dh (the GSS form of the old AUTH_DH)

      Same as Kerberos (even though it's based on DH).

      Any variant that works the same way (specifically: having a
      directory of all initiator and acceptor names and public keys) but
      uses other crypto could have the same semantics.  E.g., a
      mechanism where the initiator uses RSA key transport using an
      acceptor's long-term public key, and signs the encrypted session
      key with the initiator's long-term private key.

    - a GSS version of SASL PLAIN

      There cannot be any real mutual authentication in either sense of
      the term.

 - Mechanisms that need more than 2 context tokens:

   For these mechanisms there's not much value in omitting key
   confirmation, and it isn't wise anyways, so I would argue that they
   must all always have key confirmation.

    - SCRAM
    
      Always mutual in that one password authenticates a pair of peers.
    
      Always mutual in that key confirmation cannot be elided (per the
      RFC).
    
      One could construct a SCRAM-like mechanism where the last message
      from the acceptor can be omitted if GSS_C_MUTUAL_FLAG is not
      requested, but one probably shouldn't.
    
    - Some GSS-PAKE
    
      Pretty much the same analysis as SCRAM.
    
    - NTLM
    
      Pretty much the same analysis as SCRAM.
    
    - Some PKIX-based mechanism (SPKM, GSS-TLS, PKU2U) w/o directories
      (i.e., not like mech_dh)
    
      Some such mechanisms truly could support non-mutual authentication
      in that one peer needs no credentials, not even anonymous
      credentials.  E.g., an RSA key transport mechanism needs nothing
      like an initiator credential.  Even if EDH is used, unless one
      thinks of the initiator's private EDH key as a credential, there's
      no need to authenticate an anonymous initiator name to the
      acceptor.
    
      Again, key confirmation is not wise to omit.

Did I miss any mechanisms?  Yes: OAuth/SAML mechanisms.  Any OAuth/SAML
mechanism constructions that end up needing no more than 2 context
tokens will look a lot like Kerberos, and could have optional key
confirmation.  Any OAuth/SAML mechanism constructions that end up
needing more than 2 context tokens because they do DH or similar key
agreement should not omit key confirmation.


Thirdly and lastly, I propose the following:

 - That we rename the GSS and Kerberos "mutual auth" flags to denote key
   confirmation rather than mutual authentication.

   We should explain the motivation for making key confirmation
   optional.  This is ex-post, but still, the motivation is clearly
   protocol optimization.

   Note that GSS has a second mechanism for protocol optimization:
   PROT_READY.  This one is akin to various TLS early application data
   schemes.

 - Recommend that any mechanism that needs more than one full round trip
   for security context establishment SHOULD NOT ever omit key
   confirmation.

 - That we clarify that authentication is always mutual except in the
   case that one or the other of the initiator or acceptor names is an
   anonymous name with no link to any authenticate user, and that no
   flag can alter this.

We might also want to clarify / re-think PROT_READY.


We should start a separate thread to cover a case that came up recently:
the desire for a way to name a target principal but not authenticate it
in the sense of not require having trust anchors for authenticating it.


Applications that want to use an anonymous name, should use... a
GSS_C_NT_ANONYMOUS name, or use GSS_C_ANON_FLAG to request that the
initiator be anonymous (more about this flag in some other thread).

If a mechanism always cannot authenticate the initiator, then it is a
mechanism that doesn't provide mutual authentication (and notice that
key confirmation has nothing to do with it, and that no flag could make
the mechanism provide mutual authentication).

A mechanisms that always cannot authenticate an acceptor is probably not
a very useful mechanis, so I won't think of such a thing.


Comments?

Nico
--