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

[[e-mail] (Martin Rex)]

Nico Williams <[e-mail]> wrote:
> 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.

Again, there is *NO* concept of keys in GSS-API, and adding this
is a bad idea.  You can do that within a particular gssapi mechanism,
if you want to, but that is an implementation detail of a mechanism.


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

plus the trusted third party (the Kerberos KDC)

I'm just wondering about the MitM-unsafe GSS-API mechanism like
Microsoft NTLM, because there is no "target name" parameter,
and no binding to any target.  Every MitM attacker with access
to a domain member PC should be able to unwrap the tokens.
So the "Seal" security level for RPC when negotiate drops to NTLM
is potentially not quite what one expects.



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

Frankly, I don't know and I don't care what you mean by key confirmation.
At the GSS-API level the term "key confirmation" has *NO* meaning.
What is done within a gss-api mechanism, is irrelevant here.


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

"by the init sec context token alone" -- sorry that is non-sensical.

There can be any number of context-level tokens, and which context level
token is bound to which particular name, is entirely mechanism specific.

In particular, if the initiator happens to connect with a different
entity that what it wanted to talk to, the token will be bound to
some other name.

Technically, GSS-API mechanisms may use a completely different approach,
and start trying to perform mutual authentication of unspecified names,
and when authentication succeeds, perform discovery of the names
involved in the authentication, and match the result up with expectations.

Even Kerberos knows such a scheme. It is called user2user authentication.
It's not described in rfc1964/rfc4121, but Microsoft implemented it.


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


I'm pretty sure it has been implemented.  I've seen a (proprietary) GSS-API
mechanism wrapping TLS records in to GSS-API tokens about 18 years ago.  

We also have one (but its cheating on the flags at the API because
that was easier for drop-in into installed base).  The application
on top recognizes when this happens, and drops back to traditional
user&password authentication for initiator towards acceptor authentication.


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

This statement has at least two typos/confusions.


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

Nope.  It says "mutual authentication minus initiator towards acceptor
authentication".

That like asking for a "virgin Cuba libre"  (a Coke).
 

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


No, GSS-API does *NOT* have this implication _at_all_.
Making this implication at the GSS-API level, rather than at the
level of a specific mechanism, is a terribly bad idea. You're using
a whole dimension of what GSS-API can be.

conceptually, there do not need to be any crypto inside the context
level tokens at all (could all be out-of-band, potentially limiting
the environment where such a gssapi mechanism can be used).

However, I currently don't see how to provide the message protection
services (integrity protection and confidentiality protection) without 
crypto in the per-message tokens.


-Martin