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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 Mar 2014 11:49:50 -0500 (EST)

Digging up an old thread....

The wheels of progress have slowly spun, and the registry at 
http://www.iana.org/assignments/kerberos-v-gss-api/kerberos-v-gss-api.xhtml#token-types 
has been updated to include the rest of the token types from RFC 4121, and 
the values from RFCs 1964 and 6880.  As expected, values from in-progress 
I-Ds were not included.

In particular, the value 0405 from draft-ietf-krb-wg-gssapi-cfx-02 which 
was removed before that document became RFC 4121, and the value 0501 from 
draft-ietf-kitten-iakerb-00 (now -01), were not added.  Apparently they 
were declined on the grounds that they don't meet the criteria defined in 
section 7.2 of draft-ietf-abfab-gss-eap:

    In the top-level registry titled "Kerberos V GSS-API Mechanism
    Parameters", a subregistry called "Kerberos GSS-API Token Type
    Identifiers" was created; the references for this subregistry are RFC
    4121 and this document.  The allocation procedure is Expert Review
    [RFC5226].  The Expert's primary job is to make sure that token type
    identifiers are requested by an appropriate requester for the RFC
    4121 mechanism in which they will be used and that multiple values
    are not allocated for the same purpose.  For RFC 4121 and this
    mechanism, the Expert is currently expected to make allocations for
    token identifiers from documents in the IETF stream; effectively, for
    these mechanisms, the Expert currently confirms the allocation meets
    the requirements of the IETF Review process.

The RFC 4121 (krb5) and RFC 7055 (EAP) mechanisms appear to be 
specifically called out to have the expected behavior of the exper 
reviewer essentially be "standards action", to confirm that the assignment 
has had adequate IETF review.  Perhaps token types used by some other 
mechanism could get by with a weaker review standard.

To me, this seems like a(nother) bug in RFC 7055, but of course it is not 
one that can be reasonably fixed.  I guess that the easiest way forward is 
to publish a quick document that reserves 0405 and 0501 noting that they 
were in use before the registry was established.

-Ben

---

From: Simo Sorce <[email-masked]>
Date: Tue, 04 Mar 2014 16:36:04 -0500

On Tue, 2014-03-04 at 11:49 -0500, Benjamin Kaduk wrote:
> 
> To me, this seems like a(nother) bug in RFC 7055, but of course it is
> not one that can be reasonably fixed.  I guess that the easiest way
> forward is to publish a quick document that reserves 0405 and 0501
> noting that they were in use before the registry was established.

+1 if there is a registry we must avoid errors in allocations, and
allocating 0405 or 0501 to something else would definitely cause
standards issues.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 04 Mar 2014 16:44:26 -0500

> allocating 0405 or 0501 to something else would definitely cause

No, you have it backwards.  The registry doesn't create the requirement
to avoid conflicting allocations; it is a tool for helping to meet that
requirement.

We probably don't actually need to publish a document; it ought to be
sufficient to point out to IANA that there is a conflict and ask that
the relevant numbers be marked reserved.

-- Jeff

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 Mar 2014 16:46:07 -0500 (EST)

> the relevant numbers be marked reserved.

I ought to be, but in practice it appears to not actually be sufficient.
Unless you're saying that I should try again?

-Ben

---

From: [email-masked] (Martin Rex)
Date: Tue, 4 Mar 2014 22:47:54 +0100 (CET)

Benjamin Kaduk wrote:
> draft-ietf-kitten-iakerb-00 (now -01), were not added.
>
>  [...]
> 

This should be easily fixed with a small amount of common sense
applied by consenting AD & WG chairs, no documents necesssary.

As long as we're not facing depletion of the pool, simply marking
the code point as "Reserved to avoid conflicts" should be feasible.

See the TLS cipher suites registry for comparison:

   http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

   cipher suite code points 0x00, 0x040  through  0x00, 0x60
   that are in the "Standards Action" range

-Martin

---

From: Simo Sorce <[email-masked]>
Date: Tue, 04 Mar 2014 17:17:42 -0500

> the relevant numbers be marked reserved.

I think we are saying the same thing, I do not care what is the means of
getting those numbers marked as reserved as long as it is done and
quickly.

Simo.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Mar 2014 09:23:08 -0500

>>>>> "Benjamin" == Benjamin Kaduk <[email-masked]> 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.

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.

Yes, as expert, I could have done something else.
I just think it would have been the wrong choice.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 05 Mar 2014 09:59:16 -0500

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

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

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.

-- Jeff

---

From: Shawn M Emery <[email-masked]>
Date: Wed, 05 Mar 2014 17:12:30 -0700

> until a value is assigned by IANA, and to mention this in its IANA

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.

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

> rather heavyweight process to correct the oversight.
Shawn.
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Mar 2014 19:41:20 -0500 (EST)

>> until a value is assigned by IANA, and to mention this in its IANA

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.

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

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

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Mar 2014 05:20:19 -0500

So, my understanding of the situation is that we have an implementation
that has chosen to ship code prior to completion of a spec in two
instances.

1) CFX.  In that instance, the spec evolved differently than anticipated
and no longer standardizes the behavior MIT implements.

2) Iakerb.  There, we still expect that the spec will use the same value
as MIT.

In the CFX case, I don't actually see any significant harm that would
result if we were to  assign the codepoint MIT uses to something else.
It would be bad if we assigned that codepoint to some token other than a
context deletion token intended to be passed into
gss_process_context_token.
However, there are no such tokens and there are no extensions under
discussion that would create such tokens.

In general, when you ship a draft, you take on responsibility for
dealing if the IETF process doesn't go the way you anticipate.  Doing
that is part of doing business; it's definitely the case that there are
times when you end up shipping based on drafts.
I'm aware of the iakerb issue, and if iakerb moves forward at a
reasonable speed, I'll certainly keep its assignment preference in mind
when reviewing other allocations.

IANA expert decisions can be appealed; you'd first file an appeal with
me, and then I'm not sure whether it goes to the IESG as a whole or the
security AD.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Mar 2014 17:51:12 -0500 (EST)

> and no longer standardizes the behavior MIT implements.

Greg pointed out that we have removed the code that generates the CFX 
deletion token from our development branch, though of course older 
releases still generate such tokens.

> discussion that would create such tokens.

There actually is provision in RFC 2743 for tokens to be passed to 
gss_process_context_token which are not deletion tokens. (Last two 
paragraphs of 1.2.1.2.)  I do not remember any provisions in RFC 4121 to 
account for this case, though, so I guess it is under-specified.

> times when you end up shipping based on drafts.

I don't disagree with anything you say there.

However, I think we should consider what the purpose of the central 
registry is: to document what values are in use and avoid conflicts. 
Given that there were already values in broad use when the registry was 
created, I think it is appropriate to document those values in the 
registry, even if it is just as "reserved to avoid conflicts", as Martin 
notes in the prior art.  There certainly does not seem to be a shortage 
of values in the token type space.

> me, and then I'm not sure whether it goes to the IESG as a whole or the

Is there a magic phrase that invokes such an appeal?  (Or does it go 
through IANA?)  I am unfamiliar with the process, and not necessarily 
indicating intent to do so.

-Ben

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 06 Mar 2014 19:01:22 -0500

> indicating intent to do so.

Sort of.  You have to do it intentionally, stating the reason for the
appeal and what remedy you want.  A chair or AD or really anyone
familiar with the process should be happy to help you, if you decide to
go that route.

Personally, I think there is usually little value in the appeal process
while you are having a discussion with the original decision-maker that
has not yet converged and does not yet appear not to do so.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Mar 2014 10:12:20 -0500

>>>>> "Benjamin" == Benjamin Kaduk <[email-masked]> writes:

    Benjamin> There actually is provision in RFC 2743 for tokens to be
    Benjamin> passed to gss_process_context_token which are not deletion
    Benjamin> tokens. (Last two paragraphs of 1.2.1.2.)  I do not
    Benjamin> remember any provisions in RFC 4121 to account for this
    Benjamin> case, though, so I guess it is under-specified.

Right, but no provisions to create such tokens.
If we start thinking about that, making sure  that RFC 4121 doesn't use
the token type used by CFX would be potentially desirable..

    >> dealing if the IETF process doesn't go the way you anticipate.
    >> Doing that is part of doing business; it's definitely the case
    >> that there are times when you end up shipping based on drafts.

    Benjamin> I don't disagree with anything you say there.

    Benjamin> However, I think we should consider what the purpose of
    Benjamin> the central registry is: to document what values are in
    Benjamin> use and avoid conflicts. Given that there were already
    Benjamin> values in broad use when the registry was created, I think
    Benjamin> it is appropriate to document those values in the
    Benjamin> registry, even if it is just as "reserved to avoid
    Benjamin> conflicts", as Martin notes in the prior art.  There
    Benjamin> certainly does not seem to be a shortage of values in the
    Benjamin> token type space.

    >> IANA expert decisions can be appealed; you'd first file an appeal
    >> with me, and then I'm not sure whether it goes to the IESG as a
    >> whole or the security AD.

    Benjamin> Is there a magic phrase that invokes such an appeal?  (Or
    Benjamin> does it go through IANA?)  I am unfamiliar with the
    Benjamin> process, and not necessarily indicating intent to do so.

I'm not sure if there are more formal ways, but just drop me a note if
you decide it's important enough to appeal and say that.  INcluding
rationale would be good.