Re: [kitten] Token Preauth for Kerberos

[Thomas Hardjono <[e-mail]>]

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