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

[Benjamin Kaduk <[e-mail]>]

On Wed, 5 Mar 2014, Shawn M Emery wrote:

> On 3/5/14 7:59 AM, Jeffrey Hutzelman wrote:
>> On Wed, 2014-03-05 at 09:23 -0500, Sam Hartman wrote:
>>> 
>>> I do not support reserving the iakerb value in another document.
>>> The right solution there is to finish iakerb and get it published.
>> Agreed.  For better or worse, our process generally allocates values on
>> publication, not when a spec first appears that needs one.  The right
>> way to avoid conflicts here is for the iakerb document to say "TBA"
>> until a value is assigned by IANA, and to mention this in its IANA
>> considerations section.

For future allocation of values, leaving it TBA until a value is assigned 
by IANA is absolutely the right thing to do.  I am concerned only with 
values that were already in use prior to the establishment of the 
registry.

>> In this particular case, I don't feel like I'm in a position to develop
>> an opinion on whether the code points needs to be reserved, because I
>> don't know what the existing implementation does with it.

It has been many months since I looked at the MIT code in question, but I 
am absolutely confident that we do process tokens that we receive, which 
use these values.  I did end up looking a little bit, again; more below.

> Implementers could interpret text from 2743 as requiring a token that is 
> emitted for deleting security contexts:
>
>   Optionally, the server-side application may provide a token buffer to
>   GSS_Delete_sec_context(), to receive a context_token to be transferred to 
> the client in
>   order to request that client-side context-level information be deleted.

If a buffer is provided, I think (but would have to reread to be sure) 
that the GSS-API library is required to produce a token.  We recommend 
that applications neither provide a buffer nor send such tokens, of 
course, but not all applications heed the recommendation.

>> Here, we're talking about a code point used in a document which was in
>> progress and then abandoned or superseded before the registry was
>> created; thus, it never appeared in any published protocol
>> specification.  If we're concerned that use of such a code point might
>> cause interop problems, then having marked it as reserved in the initial
>> registry would have been a fine thing to do, and there is ample
>> precedent for that.  If it didn't, and we consider that an oversight,
>> then it seems to me that publication of a new IETF-reviewed RFC is a
>> rather heavyweight process to correct the oversight.

It never appeared in any published protocol specification, but both of 
these code points have appeared in shipping code, and we have no way of 
updating all the existing deployments.

Doing a little poking in the source, it looks like MIT krb5 probably does 
emit tokens of type 0x0405 when asked to produce context deletion tokens. 
(I will try to look at what bits are actually produced, just to be sure, 
at some point.)  Similarly, the MIT krb5 IAKERB implementation is using 
0x0501 for the tokens it produces.

Given that IAKERB has been in the MIT krb5 tree since 2010, and the 
context deletion tokens since 2009, I think it would be irresponsible to 
leave these code points open in the registry.  I don't really care what 
mechanism we use to modify the registry (but of course less effort is 
nice).

-Ben