[kitten] Token Preauth for Kerberos

[Zheng, Kai]

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

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.