[kitten] Token Preauth for Kerberos

[Zheng, Kai]

Hi Greg,

Thanks for your valuable feedback and suggestions!

1. Yes you're right I'm taking the OTP approach and use the FAST armor key as the reply key. As mentioned in the proposal we suggest PKINIT be deployed along with this mechanism,
And client uses PKINIT anonymous to obtain the armor ticket. It doesn't provide mutual authentication since only KDC is authenticated to client with the configured certificate of KDC and 
client doesn't due to lacking of certificate as to avoid the deployment overhead in our solution. So protecting the token here in AS-REQ exchange mainly depends on the FAST tunnel and
client should be careful about the armor ticket.

I agree using Holder-of-Key token is much secure. Does that mean KDC needs to authenticate client and user still needs to provide credential like password right. Perhaps we could support 
both since they're useful in different situations and requirements.

2. Can a service impersonate the client to other services? It depends. Sometimes we want to avoid the impersonation as you mentioned for security concern, sometimes it's desired like 
we might consider to support similar flows as S4U2Self and S4U2Proxy. What do you think about this? Could we do it in a restricted way like constrained delegation? At least if we have to 
avoid the impersonation, sure we can consider your suggestion and don't get tgt but get service ticket directly using token. A problem would be it's hard for now to make it work in JAVA 
because using tgt requesting service ticket is buried in JRE and we can't hack into it. Getting tgt using token works well because we can put the credential into cache then JRE picks it from the cache file
to request service ticket without extra effort. Another way to avoid the impersonation would be we don't pass token to service. Since only token attributes are really needed for authorization stuff 
so KDC could just emit the token attributes into service ticket and don't put the token into it. But I'm not very sure if token itself is desired or not in more general cases.

3. Yes we considered support packing the new authorization data type, though not in AD-KDC-ISSUED, AD-IF-RELEVANT instead. We would encrypt the data using the server key probably as MS-PAC
does. Sure we can use more secure way if it doesn't involve too much deployment overhead for services.

Please help clarify and correct, and again thanks for your great input.

Regards,
Kai

-----Original Message-----
From: Greg Hudson [mailto:ghudson at MIT.EDU] 
Sent: Wednesday, June 11, 2014 12:30 AM
To: Zheng, Kai; kitten at ietf.org; krbdev at mit.edu
Subject: Re: [kitten] Token Preauth for Kerberos

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.