[kitten] Token Preauth for Kerberos

[Zheng, Kai]

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:kaduk at MIT.EDU] 
Sent: Wednesday, July 09, 2014 10:18 PM
To: Zheng, Kai
Cc: kitten at ietf.org; krbdev at mit.edu
Subject: Re: [kitten] Token Preauth for Kerberos

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

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