[kitten] Token Preauth for Kerberos

[Zheng, Kai]

Hi Simo,

I apologize for the very late response. 

>> I think AD data can be added with s4u2self/s4u2proxy as well, what other modifications do you have in mind ?
Yes I agree. Adding AD data like AD_TOKEN won't be an issue if we could enhance S4U to support token adding something like PA_S4U_TOKEN 
in lieu with PA_FOR_USER and PA_S4U_X509_USER. :)
I might be just repeating what I have said already, why I would prefer to do it in pre-authentication framework:
1. Token can be used in AS-REQ/AS-REP exchange via token-preauth mechanism to acquire a TGT, making kinit tool support that is easy.
S4U works in TGS-REQ/TGS-REP exchange to acquire service ticket, which involves corresponding GSSAPI support for applications to make use of it. 
2. In token-preauth approach, we can also achieve the effect of S4U in some degree. Web server accepting token submitted by browser page form,
doing Kerberos login stuff via token-preauth, then performing GSSAPI/SASL negotiation with backend service, works great.

>> Do you have a standardized AD element in mind, or are you going to define a new one ?
How about having a new one like AD-TOKEN that contains the token derivation. It can encapsulated into AD-KDC-ISSUED, with checksum. The thinking
would be, KDC validates incoming token and determines to issue ticket, by escaping any encryption/signature layers of the token, gets the token derivation,
and put it into the issued ticket. As such it's natural to wrap the new AD data into AD-KDC-ISSUED.

Thanks for thinking about this. 

Regards,
Kai


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

On Tue, 2014-06-17 at 05:35 +0000, Zheng, Kai wrote:
> >> 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.

I think AD data can be added with s4u2self/s4u2proxy as well, what other modifications do you have in mind ?

> >>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.

Do you have a standardized AD element in mind, or are you going to define a new one ?

Simo.

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