[18868] in Kerberos_V5_Development
Re: [kitten] Token Preauth for Kerberos
daemon@ATHENA.MIT.EDU (Simo Sorce)
Tue Jun 17 08:43:44 2014
Message-ID: <1403009009.22737.129.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: "Zheng, Kai" <kai.zheng@intel.com>
Date: Tue, 17 Jun 2014 08:43:29 -0400
In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com>
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
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
