[18890] in Kerberos_V5_Development
RE: [kitten] Token Preauth for Kerberos
daemon@ATHENA.MIT.EDU (Zheng, Kai)
Tue Jul 8 08:14:44 2014
From: "Zheng, Kai" <kai.zheng@intel.com>
To: Simo Sorce <simo@redhat.com>
Date: Tue, 8 Jul 2014 12:10:00 +0000
Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118FB475@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <1403009009.22737.129.camel@willson.usersys.redhat.com>
Content-Language: en-US
MIME-Version: 1.0
Cc: "kitten@ietf.org" <kitten@ietf.org>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@redhat.com]
Sent: Tuesday, June 17, 2014 8:43 PM
To: Zheng, Kai
Cc: kitten@ietf.org; krbdev@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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
