[kitten] Token Preauth for Kerberos

[Zheng, Kai]

>> You need to modify something anyway, constrained delegation sound like a better way than trying to devise a whole new pre-auth plugin.
As far as I know s4u2self & s4u2proxy plus contrained delegation are from MS and I'm not sure we could modify it as we need. A new token-preauth based on existing Kerberos and framework is more preferred for us since the plugin is easy to deploy, also we believe the mechanism using JWT token will open the door to integrate Kerberos with OAuth.

>>However you should only transmit the authorization data, not the whole token, otherwise you destroy every single security property of Kerberos.
>>I can't see any krb admin as accepting something like that.
Yes I agree. As discussed with Greg and also said here in my previous email, we will not pass the token itself to service, instead token attributes or the derivation that can't be used to authenticate with KDC. 

Thanks for your feedback.

Regards,
Kai

-----Original Message-----
From: Simo Sorce [mailto:simo at redhat.com] 
Sent: Friday, June 13, 2014 8:41 PM
To: Zheng, Kai
Cc: kitten at ietf.org; krbdev at mit.edu
Subject: Re: [kitten] Token Preauth for Kerberos

On Fri, 2014-06-13 at 07:16 +0000, Zheng, Kai wrote:
> Hi Simo,
> 
> >> have you considered protocol transition (s4u2self) + constrained
> delegation (s4u2proxy) to get tickets at an authentication gateway 
> instead of a new pre auth mechanism ?
> 
> Yes we proposed for the Hadoop community a centralized Authn & Authz 
> Server (HAS) that might be like the gateway as you mentioned. It's 
> widely discussed and confirmed that it would be great the server 
> allows plugin of authentication module/provider but all mechanisms 
> output token. Sure I guess it's possible to use token to go thru 
> s4u2self and s4u2proxy in the Kerberos facility across the ecosystem 
> but as far as I know JRE just starts to support it from JDK8. Anyhow I 
> would check this and make sure it's a doable option not in so long 
> future.

You need to modify something anyway, constrained delegation sound like a better way than trying to devise a whole new pre-auth plugin.

> A question regarding this:
> Is it possible to contain the token in service ticket resulted from 
> s4u2self and s4u2proxy as authorization data so that services can get 
> it as proposed in token-preauth? Note in our wanted solution, token 
> not just serves for authentication, but also is meant to be passed (or 
> the token attributes) to service side for fine-grained authorization.

Well, theorethically it should be possible to ad AD data in the ticket before the s4u2proxy call and the KDC should just preserve it.
However you should only transmit the authorization data, not the whole token, otherwise you destroy every single security property of Kerberos.
I can't see any krb admin as accepting something like that.

Simo.

--
Simo Sorce * Red Hat, Inc * New York