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

[Shawn M Emery <[e-mail]>]

On 3/5/14 7:59 AM, Jeffrey Hutzelman wrote:
> On Wed, 2014-03-05 at 09:23 -0500, Sam Hartman wrote:
>>>>>>> "Benjamin" == Benjamin Kaduk <[e-mail]> writes:
>>
>>      Benjamin> To me, this seems like a(nother) bug in RFC 7055, but of
>>      Benjamin> course it is not one that can be reasonably fixed.  I
>>      Benjamin> guess that the easiest way forward is to publish a quick
>>      Benjamin> document that reserves 0405 and 0501 noting that they were
>>      Benjamin> in use before the registry was established.
>>
>> 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.

Speaking as an individual; I agree, but having some guidance would be 
helpful, as there may be a pattern in the registry that might not be 
intuitive to IANA.

>> my preference is that the CFX context deletion token not be registered.
>> I don't see any protocol issues that are likely to result if that code
>> point were re-used.
>> If the community disagrees, writing a document is the right way forward.
> I think that depends on how mechanisms might get stacked and whether
> there is deployed code that emits or reacts to that code point.  In
> general, tokens used only during context establishment almost don't need
> to be in a common namespace at all, except that it makes it less
> complicated to update things when one mech builds on the context
> establishment of another.  However, tokens which can appear after
> context establishment require a little more care (but are also less
> likely to appear or change outside of 4121 or its successors).
>
> 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.

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.


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