Subject: Re: [kitten] Token Preauth for Kerberos

From: "Zheng, Kai" <[email-masked]>
Date: Tue, 8 Jul 2014 12:10:00 +0000

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:[email-masked]] 
Sent: Tuesday, June 17, 2014 8:43 PM
To: Zheng, Kai
Cc: [email-masked]; [email-masked]
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

---

From: Greg Hudson <[email-masked]>
Date: Tue, 08 Jul 2014 12:33:23 -0400

On 07/08/2014 08:10 AM, Zheng, Kai wrote:
> How about having a new one like AD-TOKEN that contains the token derivation.

To me, this sounds like creating a container-of-anything within an
existing container-of-anything.  That is, if you see something within an
AD-TOKEN subcontainer, you don't know anything about what it is, only
something about where it came from and how it is encoded.

An advantage of the subcontainer approach is that the KDC can be fairly
dumb.  But the server application has to be correspondingly smart; if a
semantically equivalent piece of authorization data could exist in one
of several subcontainers, each with its own encoding, then it must
understand all of the different subcontainers and search within each.

---

From: "Zheng, Kai" <[email-masked]>
Date: Wed, 9 Jul 2014 01:49:55 +0000

Hi Creg,

> this sounds like creating a container-of-anything within an existing container-of-anything.  That is, if you see something within an AD-TOKEN subcontainer, you don't know anything about what it is, only something about where it came from and how it is encoded.

Hmmm, not exactly as what I mean. It's container-of-exactly-token within the existing container-of-anything (AD-KDC-ISSUED). Looking at AD-TOKEN subcontainer, applications are meant to get a token from it, as AD-TOKEN could be defined as:
   AD-TOKEN            ::= SEQUENCE {
           token     [0] OCTET STRING,
   }
The token is defined as JWT token, and can be converted as OCTET STRING according to how JWT tokens are serialized into binary bytes.

Looks like AD-CAMMAC is a better alternative to AD-KDC-ISSUED, so as you suggested we can use it instead, though it's a little bit complex regarding implementation.

Regards,
Kai

-----Original Message-----
From: Greg Hudson [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2014 12:33 AM
To: Zheng, Kai
Cc: [email-masked]; [email-masked]
Subject: Re: [kitten] Token Preauth for Kerberos

> How about having a new one like AD-TOKEN that contains the token derivation.

To me, this sounds like creating a container-of-anything within an existing container-of-anything.  That is, if you see something within an AD-TOKEN subcontainer, you don't know anything about what it is, only something about where it came from and how it is encoded.

An advantage of the subcontainer approach is that the KDC can be fairly dumb.  But the server application has to be correspondingly smart; if a semantically equivalent piece of authorization data could exist in one of several subcontainers, each with its own encoding, then it must understand all of the different subcontainers and search within each.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Jul 2014 10:17:52 -0400 (EDT)

On Tue, 8 Jul 2014, Zheng, Kai wrote:

> Hmmm, not exactly as what I mean. It's container-of-exactly-token within 
> the existing container-of-anything (AD-KDC-ISSUED). Looking at AD-TOKEN 
> subcontainer, applications are meant to get a token from it, as AD-TOKEN 
> could be defined as:

AD-TOKEN is a "container of anything" not in the sense of the ASN.1 data 
type, but rather that the JWT token therein could contain any sort of 
information about the user making the request, restrictions placed on the 
token, and so on.  (Almost) any sort of information could be in the 
AD-TOKEN, even if only a single data type is permitted.

-Ben

---

From: "Zheng, Kai" <[email-masked]>
Date: Wed, 9 Jul 2014 21:01:30 +0000

Hi Ben,

> AD-TOKEN is a "container of anything" not in the sense of the ASN.1 data type, but rather that the JWT token therein could contain any sort of information about the user making the request ...

Yes I agree. Thanks for clarifying. I'm thinking of AD-TOKEN as AD-WIN2K-PAC. The difference is AD-TOKEN contained token is from 3rd party token authority and can contain anything like you 
mentioned, and the layout of AD-WIN2K-PAC is well defined by MS-PAC. Also IMO, having a subcontainer like AD-TOKEN for token-preauth mechanism could allow some flexibility for 
future extensions. 

What would you suggest regarding this or any other aspects for the proposed mechanism? Thanks.

Regards,
Kai

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2014 10:18 PM
To: Zheng, Kai
Cc: [email-masked]; [email-masked]
Subject: Re: [kitten] Token Preauth for Kerberos

On Tue, 8 Jul 2014, Zheng, Kai wrote:

> Hmmm, not exactly as what I mean. It's container-of-exactly-token 
> within the existing container-of-anything (AD-KDC-ISSUED). Looking at 
> AD-TOKEN subcontainer, applications are meant to get a token from it, 
> as AD-TOKEN could be defined as:

AD-TOKEN is a "container of anything" not in the sense of the ASN.1 data type, but rather that the JWT token therein could contain any sort of information about the user making the request, restrictions placed on the token, and so on.  (Almost) any sort of information could be in the AD-TOKEN, even if only a single data type is permitted.

-Ben