Token Preauth for Kerberos

[Zheng, Kai]

Hi Greg,

Thanks for letting know this and I did read your proposal. Identity token is a good point. Per my understanding,  I noticed the following points, please feel free to clarify or correct.

1. Looks like you modified the Kerberos implementation along with backend principal store to make it work. Our approach is a pure plugin for MIT Kerberos and we tried to avoid 
changing into the main programs and make sure it's easy to deploy the mechanism.

2. You introduced the identity token in a private format with corresponding key generation algorithms. We propose to use JWT token since it's well defined in JWT/JWA/JWE/JWS etc., 
and also implemented well for OAuth2 related profiles. This allows the proposal to be easier defined based on the existing specs, and also enables to integrate Kerberos with OAuth.

3. Looks like your identity token was tightly coupled with specific KDC. We would prefer decouple the both and establish the trust relationship between token issuer and KDC via PKI.
Token can be issued without knowing any KDC (its IP). Token domains/subjects are mapped into Kerberos realms via defined token attributes or plugined mapping provider.

4. In low level:
you passed the token in authorization data in the AS-REQ exchange. Our work based on pre-authentication framework and FAST tunnel, tokens are passed as PADATA in the FAST tunnel.
This allows the mechanism can work together with other preauth mechanism like PKINIT and make use of them for their provide facilities.

Though, I'm wondering if it's possible to align the both efforts if the community would. Still in drafting, we would prefer something like following:
1. define token-preauth mechanism using JWT token format;
2. define OAuth token for Kerberos profile based on token-preauth, that allows OAuth token work flow can integrate with existing Kerberos authenticated systems as resource servers.

Considering to align with your work, one possible approach would be something like following:
1. define token-preauth mechanism using opaque token, only if the token can be verified, encrypted, and token attributes can be extracted. As to how to verify, encrypt, and extract attributes,
it leaves for specific token provider to define and implement;
 2. Based on token-preauth with opaque token, we define JWT token provider;
3. Based on JWT token provider, we define OAuth token support.

At first glance looks token-preauth with opaque token is more general and useful. However I'm not sure if it's easily defined and implemented. I guess the community can decide which way 
should we go.

Regards,
Kai

-----Original Message-----
From: Dr. Greg Wettstein [mailto:greg at wind.enjellic.com] 
Sent: Friday, June 13, 2014 5:11 PM
To: Zheng, Kai; kitten at ietf.org; krbdev at mit.edu
Subject: Re: Token Preauth for Kerberos

On Jun 10, 12:19pm, "Zheng, Kai" wrote:
} Subject: Token Preauth for Kerberos

> Hi all,

Good morning Kai, I hope the end of you week is going well.

> I would like to mention an effort regarding Kerberos and propose a new 
> Kerberos preauth mechanism, token-preauth. Before dive into that, 
> please kindly allow me to introduce, mainly for the background and 
> scenario for the proposal.
>
> I'm an engineer from Intel and develop identity and security related 
> products. The current focus is Apache Hadoop, and our goal is enabling 
> Hadoop to support more authentication mechanisms and providers. 
> Currently Hadoop only supports Kerberos authentication method as the 
> built-in secured one and it's not easy to add more since it involves 
> changing into many projects on top of it in the large ecosystem. The 
> community had proposed a token based authentication, planned to add 
> TokenAuth method for Hadoop and by TokenAuth then all kinds of 
> authentication providers can be supported since their authentication 
> results can be wrapped into token, and the token can be employed to 
> authenticate to Hadoop across the ecosystem. The effort is still 
> undergoing. Considering the complexity, risk and deployment overhead 
> of this approach, our team investigate and think of another possible 
> solution, i.e. support token in Kerberos. The basic idea is allow end 
> users to authenticate to Kerberos wit!  h their tokens and obtain 
> tickets, then access Hadoop services using the tickets as current flow 
> goes. The PoC was already done, and we make it work seamlessly from 
> MIT Kerberos to Java world and Hadoop. However we think it's very 
> important to get the key point token-preauth be reviewed by you 
> security and Kerberos experts, to make sure it's defined and 
> implemented in compliance with the existing standards and protocols, 
> without involving security critical leaks. So please kindly give your 
> feedback and we appreciate it.
> 
> The proposal - Kerberos token-preauth

> This proposes to add another preauthentication mechanism similar to 
> OTP and PKINIT for Kerberos, based on Kerberos preauthentication 
> framework and FAST tunnel. It allows 3rd 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. When using the 
> token to request a tgt, the user name or other attributes claimed in 
> the token must match the target Kerberos principal. PKI is used to 
> establish the trust relationship between 3rd party token issuer and 
> KDC. According to configured certificate and public/private keys KDC 
> decrypt and verify the token, and determines to issue ticket or not 
> according to configured policy. The token itself will be wrapped into 
> ticket as new authorization data and carried on to application server 
> side. The tgt and derived service ticket resulted from token are not 
> in much difference except the contained token and work exactly as 
> normally. Besides that in applicatio!  n servers, token can be 
> extracted from service ticket and employed further to do fine-grained 
> authorization since the token can contain rich identity attributes.
>
> POC implementation
>
> 1.  We implement a token-preauth plugin for MIT Kerberos like OTP one 
> and it does all the necessary work that should be done for Kerberos 
> itself in both client side and KDC side. We need update krb5.conf and 
> kdc.conf to use and enable the mechanism. The plugin is a so module 
> and can be separately installed/deployed. To protect token between 
> client and KDC in KDC-REQ/KDC-REP exchanges, FAST must be used, 
> therefore we suggest PKINIT be deployed also.

.. [ much material deleted ] ...

At a conceptual level we did a great deal of work on this back in 2007.  Look through the archives of the Kerberos development list for 'One-Time-Identification'.  Unfortunately at that time no one really thought authorization was all that important and there was a fair amount of contempt in the community for using the Kerberos supplied authorization data.

OTI was an outgrowth of work which we started doing in 2001 on the issue of intrinsic definition of identity.  In that work the notion of authorization for a service naturally falls out of the identity definition model. If you GOOGLE around a bit you will find a presentation we did at a Kerberos/AFS conference at Ann Arbor on how this was applied to Kerberos.

We implemented OTI as a pre-authentication method and it was a fairly natural fit.  The concept was roughly a bearer token model where the service authorization identity was used in concert with the user password to generate a one time encryption of the service authorization token.

We've since taken that work into the trusted system domain and it continues to prove itself in combination with software/hardware attestation.

> Regards,
> Kai

We've actually had ongoing conversations with your organization.  If you are interested we could take an additional conversation offline.

Have a good weekend.

Greg

}-- End of excerpt from "Zheng, Kai"

As always,
Dr. G.W. Wettstein, Ph.D.   IDfusion.org
4206 N. 19th Ave.           Unified health identity architecture.
Fargo, ND  58102
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at idfusion.org
------------------------------------------------------------------------------
"My thoughts on trusting Open-Source?  A quote I once saw said it
 best: 'Remember, Amateurs built the ark.  Professionals built the  Titanic.'  Perhaps most significantly the ark was one guy, there were  no doubt committees involved with the Titanic project."
                                -- Dr. G.W. Wettstein
                                   Resurrection