Re: [kitten] Token Preauth for Kerberos

["Zheng, Kai" <[e-mail]>]

Hi Thomas,

Thanks for your confirm and encouraging. I think the feedback and input from the community for the idea are very important,
so please kindly allow me to understand them and prepare well for the initial draft for your review. Thanks.

Regards,
Kai

-----Original Message-----
From: Kitten [mailto:[e-mail]] On Behalf Of Thomas Hardjono
Sent: Tuesday, June 10, 2014 11:10 PM
To: [e-mail]; [e-mail]
Subject: Re: [kitten] Token Preauth for Kerberos

Kai,

I think a token-preauth mechanism would be a very useful addition to the set of mechanisms that we have today.  

When do you plan to submit the draft to the KITTEN WG?

Best.

/thomas/


____________________________________________


From: Kitten [mailto:[e-mail]] On Behalf Of Zheng, Kai
Sent: Tuesday, June 10, 2014 8:19 AM
To: [e-mail]; [e-mail]
Subject: [kitten] Token Preauth for Kerberos

Hi all,

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 with 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 application 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.
2.       For end users, we provide ktinit tool as
follows:
ktinit -h
This tool uses token to authenticate to KDC and obtains tgt for you.
ktinit [-t token | -T token-cache-file] [-c kerb-ccache-file]
      when no token specified, ~/.tokenauth.token will be used by default

In the behind, it requests the needed armor ticket using PKINIT anonymous and then executes kinit with the armor ticket and token with -X option, gets tgt and puts the tgt in specified credential cache 3.       For JAVA application servers (Apache Hadoop services), we figured out how to extract token from service tickets from both GSSAPI layer and SASL layer.

It's planned to have a draft for this work. Our team is making effort to enable Kerberos to be easily deployed in large Hadoop clusters and big data platform and can integrate with other authn & authz solutions well from enterprise and internet.
Thanks for your input, feedback and correction.

Regards,
Kai