[kitten] Token Preauth for Kerberos
kai.zheng at intel.com
Tue Jul 8 08:10:00 EDT 2014
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.
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
> >>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
Do you have a standardized AD element in mind, or are you going to define a new one ?
Simo Sorce * Red Hat, Inc * New York
More information about the krbdev