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

[Nico Williams <[e-mail]>]

On Wed, May 08, 2019 at 04:53:51AM +0200, Martin Rex wrote:
> Nico Williams <[e-mail]> wrote:
> > I assert that:
> > 
> >  - GSS_C_MUTUAL_FLAG is badly misnamed
> 
> Not really.
> 
> Original GSS-API implied initator towards acceptor authentication,
> and GSS_C_MUTUAL_FLAG was used to request acceptor towards initiator
> authentication.

I believe that conflates "mutual" with key confirmation.

Assuming the cryptosystems are secure, an exchange of this form:

I->A: init sec context token w/o "mutual" (AP-REQ)
I->A: wrap token w/ confidentiality

keeps the plaintext confidential even if the recipient is not the
intended acceptor.

Kerberos ensures that only the intended acceptor can unwrap that token.

Moreover, in an exchange like this

I->A: init sec context token w/o "mutual" (AP-REQ)
A->I: sec context token (AP-REP)
I->A: wrap token w/ confidentiality

there is no assurance that there is not a party on-path that can observe
the ciphertext of these tokens.

Thus the only thing GSS_C_MUTUAL_FLAG can do in the case of Kerberos is
provide key confirmation and, in RFC4121, a new sub-session key.

In both cases there are *two* principal names, and they are
cryptographically bound by the init sec context token alone.

Moreover, the GSS-API always has two principal names involved in every
security context.  I suppose you could argue it's "up to two names", but
I wouldn't agree.  First, the initiator's credential (default or not)
supplies one name (the initiator's) to GSS_Init_sec_context().  Second,
GSS_Init_sec_context() requires a target_name (the acceptor's).  Even if
the initiator wishes to be anonymous, it still has a NAME as indicated
by GSS_Inquire_context() -- that name will be of GSS_C_NT_ANONYMOUS
type, indeed, but it will be a NAME.

> The better terminology would have been to indicate the actually desired
> (additional) function, rather than describing the addition of what is
> requested, and what has been silently implied/assumed.

If I understand this, you might actually be agreeing with me.  But I
probably didn't understand it.  What alternative terminology would you
propose?

> The difference became obvious when the "Anoymous" authentication was
> added in GSS-APIv2, i.e. no authentication of initiator towards acceptor.

Has this been implemented by any mechanisms?

(Kerberos is the only Internet mechanism that has this specified, but
it's not yet been implemented, much less as specified.)

A better design would have been to have the initiator application supply
GSS_Inquire_context() with an input_cred_handle for a GSS_C_NT_ANONYMOUS
desired_name.  No flag should have been needed or specified.

> Web Browsers using TLS usually do what at the GSS-API would be the
> combination of (GSS_C_ANON_FLAG|GSS_C_MUTUAL_FLAG), i.e.
> unidirectional authentication, acceptor towards initiator.

This would seem like a contradiction in terms.  Unless you take
GSS_C_MUTUAL_FLAG to be about key confirmation, which is not optional in
TLS, and so we're down to just GSS_C_ANON_FLAG (about which see above).

> >  - and GSS_C_MUTUAL_FLAGis, always was, and only could have been about
> >    key confirmation.
> 
> GSS-API is about authentication of name-based entities.
> There is no concept of keys in GSS-API.

Key confirmation is a term of art referring to an aspect of the chosen
mechanism's context token protocol.  "Key confirmation" is certainly not
about exposing keys to applications.

But certainly, too, the existence of cryptographic keys is strongly
implied by the GSS-API, at least assuming classical cryptography (and we
can't assume quantum cryptography because while there are quantum key
exchange systems, there are no quantum authentication systems).

> > 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.
> 
> Nope.  Kerberos has always been about unidirectional authentication,
> and most of the time, MUTUAL is still unidirectional.

I strongly disagree as explained above.

> Performing server name canonicalization through insecure DNS
> has been insecure and a well-known bad idea in 1996.

I'd rather not distract this thread with that issue.

Nico
--