Token Preauth for Kerberos

[Dr. Greg Wettstein]

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