Re: [kitten] Updating IANA krb5 GSSAPI token type registry

[[e-mail] (Martin Rex)]

Benjamin Kaduk wrote:
> Martin, Luke, thanks for looking these up, it saved a bunch of time.
> 
> I see that draft-ietf-krb-wg-gssapi-cfx-02 (which became RFC4121) had 0405 
> for the context deletion token, but this was removed in the -03 in favor 
> of not emitting such tokens.

I just found another one:

  http://tools.ietf.org/html/rfc2743#page-84

  04 01   exported name (token) created by gss_export_name()


In case that anyone is wondering what "per-message token without
generic framing" means:

GSS-API defines a mechanism-independent Token Format in
rfc-2743, section 3.1
   http://tools.ietf.org/html/rfc2743#page-81

(originally in GSS-API v1, rfc-1508, Appendix B)
   http://tools.ietf.org/html/rfc1508#page-48

which must be used for the _initial_context_token_,
This "generic framing" is originally defined as ASN.1, but
the description in rfc2743, section 3.1 also describes that
framing as bits-on-the-wire, so that it can be implemented
without ASN.1 tools.

There is _no_ requirement in the base gssapi specification
for mechanisms what framing or format to use for others but the
initia context token (i.e. the 1st token from Initiator to Acceptor)
or for per-message tokens.

The Kerberos gssapi mechanism (rfc1964) decided to use the generic
framing for _all_ context tokens, and in addition, for _all_ per message
tokens as well.

The update of the Kerberos gssapi mechanism (rfc4121) dropped the
generic framing on the per-message tokens, making the TOKEN_ID the
fist two octets to appear in rfc4121 per-message tokens.

-Martin