Subject: TOK_ID in the K5 mechanism?

From: "Josh Howlett" <[email-masked]>
Date: Thu, 19 Mar 2009 22:29:07 -0000

Could someone kindly explain the purpose of the TOK_ID required by the K5 mechanism (RFC4121)? To the naïve reader, it seems that innerField is self-describing, in that it contains an unambigous Kerberos message.

I found a reference to this in the Acknowledgments section; unfortunately, the meaning of the accompanying explanation eludes me (I don't understand how the pseudo ASN.1 header would get encoded in a PDU, given that section 3.1 of RFC2743 explicitly states that it is descriptive only).

Many thanks, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Mar 2009 17:37:18 -0500

On Thu, Mar 19, 2009 at 10:29:07PM +0000, Josh Howlett wrote:
> Could someone kindly explain the purpose of the TOK_ID required by the
> K5 mechanism (RFC4121)? To the naïve reader, it seems that innerField
> is self-describing, in that it contains an unambigous Kerberos
> message.

It's there because it was there in RFC1964.

It's there in RFC1964 because... well, I don't know (and I had nothing
to do with that :)

RFC1964 went way overboard with token headers.  It required the RFC2743
section 3.1 initial context token header on every token, not just the
initial one, and it added a TOK_ID to all the security context tokens.
None of that was needed -- it is and would have been sufficient to use
the RFC2743 section 3.1 initial context token header only on the initial
context token and TOK_IDs only on the per-message (and context deletion)
tokens.

RFC4121 removed the need for the RFC2743 section 3.1 initial context
token header on the per-message tokens, but kept it for the non-initial
context tokens, and it kept the TOK_ID for all context tokens.  This
change was done for two reasons: a) to reduce the size of per-message
tokens and alleviate alignment issues, b) to minimize the amount of
change and special-casing that existing implementors of RFC1964 would
have to do in order to implement RFC4121.

> I found a reference to this in the Acknowledgments section;
> unfortunately, the meaning of the accompanying explanation eludes me
> (I don't understand how the pseudo ASN.1 header would get encoded in a
> PDU, given that section 3.1 of RFC2743 explicitly states that it is
> descriptive only).

Can you quote the specific text?

Nico
--

---

From: "Josh Howlett" <[email-masked]>
Date: Fri, 20 Mar 2009 11:24:19 -0000

> RFC4121 removed the need for the RFC2743 section 3.1 initial 
> context token header on the per-message tokens, but kept it 
> for the non-initial context tokens, and it kept the TOK_ID 
> for all context tokens.  This change was done for two 
> reasons: a) to reduce the size of per-message tokens and 
> alleviate alignment issues

Ok. So for a new mechanism this type of tagging should, in general, be
unnecessary?

Or, more generally, the GSS acceptor doesn't care about the contents of
innerField; it just passes it off to the appropriate mechanism on the
basis of the value of MechType given in the InitialContextToken?

> Can you quote the specific text?

Never mind, I was getting confused again :-|

Many thanks, josh.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Mar 2009 10:46:16 -0500

> Ok. So for a new mechanism this type of tagging should, in general, be

Correct.

The only token headers defined by the GSS-API are:

1) The RFC2743 section 3.1 initial context token header.

   This is needed so that a multi-mechanism acceptor can figure out
   which mechanism should consume this token.

   Once an initial security context token is successfully consumed the
   acceptor has state in the form of a partially established security
   context token (or fully established, in the case of a half round-trip
   exchange) that it can use to figure out how to consume the next
   context token from the initiator.

2) The RFC2743 section 3.2 exported name token.

It is the application's job to properly frame per-message tokens so that
the peer can know: a) how long a token is (and where, on the wire), b)
what kind of token it is (MIC or wrap, or not-a-gss-token).  (b) is
usually implied, and (a) is usually an explicit length field on the
wire.

> basis of the value of MechType given in the InitialContextToken?

That's exactly right for a GSS-API _library_ (or what we call a
"mechglue").  The mechanism itself, of course, does care.

[The reason I draw a distinction between mechglue and mechanism here is
that if you have a mechglue implementation where the plug-in interface
is the GSS-API itself, then your application could link directly with
the mechanism, in which case what you called the "GSS acceptor" most
definitely does care about the innerToken contents :)  -- a subtle
distinction, I know.]

Nico
--

---

From: "Josh Howlett" <[email-masked]>
Date: Fri, 20 Mar 2009 16:04:19 -0000

> [The reason I draw a distinction between mechglue and 
> mechanism here is that if you have a mechglue implementation 
> where the plug-in interface is the GSS-API itself, then your 
> application could link directly with the mechanism, in which 
> case what you called the "GSS acceptor" most definitely does 
> care about the innerToken contents :)  -- a subtle 
> distinction, I know.]

Almost too subtle for a Friday afternoon, but I have managed to grok it
:)

Many thanks, josh.