Re: [kitten] Token Preauth for Kerberos

[Greg Hudson <[e-mail]>]

On 06/10/2014 08:19 AM, Zheng, Kai wrote:
> This proposes to add another preauthentication mechanism similar to OTP
> and PKINIT for Kerberos, based on Kerberos preauthentication framework
> and FAST tunnel. It allows 3^rd party token in JWT format like OAuth
> bearer token can be used as credential to authenticate to KDC for a
> normal principal instead of user password.

Without knowing more details, here are three areas where there might be
concerns:

1. How is the reply key computed during an AS request?

I am guessing that you took the OTP approach of using the FAST armor key
as the reply key.  This is not ideal, but may be the path of least
resistance if you have to work with bearer tokens.  The limitations of
this approach are:

* It precludes the preauth mechanism from working securely inside FAST
channels which do not authenticate the KDC (such as anonymous PKINIT
channels without KDC certificate verification).

* It means any holder of the FAST armor key (e.g. someone who has the
host keytab) can passively observe the exchange and decrypt the ticket,
not just the holder of some user-specific authentication secret.

If you use holder-of-key tokens instead of bearer tokens, the key can be
used in one of several ways to more securely establish a reply key.

The last time I talked about this with Sam Hartman in person, he
suggested that perhaps mechanisms which can't securely establish a reply
key should be doing an unauthenticated DH exchange within the FAST
channel, which would prevent a passive observer with the armor key from
decrypting the ticket.  That would add a lot of complexity and have a
performance impact, however.

2. Can a service impersonate the client to other services?

If you're handing out client bearer tokens to each service the client
authenticates to, and the bearer token can be used to obtain a TGT, then
a service can use that bearer token to get its own TGT and authenticate
as the user to other services.

This problem goes away if the bearer tokens are restricted to particular
services and the KDC doesn't issue TGTs.  The client would make an AS
request for a specific server (identified in the bearer token) and get a
service ticket for that server directly, without making a TGS request.
The service can then only impersonate a user to itself, which is harmless.

3. Is the authdata correctly packaged?

In the Kerberos 5 authdata model, the KDC is assumed to blindly pass
through authdata requested by the client.  If the authdata is to be
trusted by the target service as something vetted by the KDC, it needs
to be packaged accordingly.

The traditional method for doing this is a container called
AD-KDC-ISSUED which contains a checksum for the authdata in a key which
cannot be known (in advance) by the client.  This container has not seen
much practical use, and it turns out that RFC 4120 says conflicting
things about which key to use for the checksum.  To the extent that
there are implementations, they use the ticket session key.

A more recent container for this purpose is AD-CAMMAC, as specified in:

    http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-01

In addition to not having key ambiguity issues, AD-CAMMAC also contains
a KDC verifier which allows the authdata to be propagated through an
S4U2Proxy request.