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

[[e-mail] (Martin Rex)]

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

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.


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


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.


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

Until GSS_C_ANON_FLAG was invented, MUTUAL was an implied requirement.

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


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

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

You may want to check what Microsoft does 23 years later when encountering
DNS CNAME records for rfc4559 SPNEGO authentication...

(spoiler: insecure server name canonicalization through DNS)

Essentially, Kerberos 5 never provided mutual authentication in the
past, and you probably should not hold your breath until it happens.


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

Definite *NO* for NTLM.  NTLM is unidirectional initiator to target,
and susceptible to man-in-the-middle.  This was obvious in 1995,
and causes some amount of headaches earlier this year.

  https://www.theregister.co.uk/2019/01/25/microsoft_exchange_domain_admin_eop/


>     
>     - Some PKIX-based mechanism (SPKM, GSS-TLS, PKU2U) w/o directories
>       (i.e., not like mech_dh)

I know PKIX-based mechanisms that perform mutual properly.
But for convenience, some of them contain various tweaks/cheats to
perform just uni-directional authentication.


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


Security guarantees of GSS-API apply only to application data that
has been protected by the GSS-API message protection primitives.

If someome abuses the GSS-API context token exchange for an OTP-scheme,
and then transfers application data without GSS-API message protection,
that's spoiling between most and all of the security
(again, rfc4559 HTTP Negotiate comes to mind).


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

which is almost what Kerberos has been doing for the past 30 years thanks
to canonicalizing service names through insecure DNS...


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

The "Applications that want to use an anonymous name," above
sort of implies that the entire information conveyed must be
public and free.

Or were you also considering "pseudonymous", which GSS-API currently
does not address, such as a "one from a certain group", such as an
"unnamed paying customer".



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

these things are called "Web Browsers".  I'm not sure the folks from
CABforum share your view.

Have you noticed how poorly some browsers work with TLS client certificates?
Almost indistinguishable from malice.  Like "Enrollment"?

Ever tried to make your Google Chrome automatically select a TLS client
cert for accessing a Web Server that wants TLS client certs?
Maybe not exactly "Beware of the leopard"-style, but sufficiently close.
(stuff from Apple Inc. and TLS client certs?  even worse).


-Martin