Subject: [kitten] An idea to go beyond 32 flags in draft-ietf-kitten-kerberos-iana-registries-03

From: Rick van Rein <[email-masked]>
Date: Wed, 13 Apr 2016 10:32:21 +0200

Hello Tom / Kitten,

Last week the Kerberos IANA registries draft popped up again.  I find
the general useful, but I feel strong objections against constraining
"Named Bit Assignments" to the 0..31 range.  I mentioned this before,
but now also see a way out.  My proposal is the replacement text at the
end of this email.

My reasons for my objection + alternative are

 (1) specifications should not follow implementations, and certainly not
confirm bad ones;
 (2) limiting to 32 named bits will confirm this lowest common
denominator and increase the number of flawed implementations;
 (3) after confirming a 32-bit limit, we have cut off any chance of
growing beyond this;
 (4) software that is incapable of being updated is a security problem,
not something that a spec should seek to confirm;
 (5) we currently cannot supply bits for experimental/private use, for
instance for development purposes; developers end up stealing bits and
the registry becomes an administration of such sins.

The suggestion below puts some suggestive pressure towards proper
implementation, by hinting at a future with bits beyond 32, also for
experimental/private use.  This is a hint in the direction that we would
like to have.  Also, it will help us grow an insight into which
implementations are flawed, which won't happen if we stuck to 32 bits.

Note that allowing more bits than anticipated is purely a parsing
matter; any implementation has a limited number of flags that it can
understand, and so the only requirement is to be able to parse DER
structures with more bits than understood; the default behaviour for
unknown flags can easily be triggered in any implementation by looking
at the extra bytes and responding to anything non-zero (which is easy
with DER, as the length will only be > (1+32/8) when a bit over 32 is
set).  After that potential trigger, only the understood (for instance,
32) bits need to be taken out for processing.  (For TicketFlags and
KDC-Options the unrecognised handling is even simpler, namely ignoring;
I could not find unrecognised handling for AP-Options but ignoring seems
to make sense there too.)

This leaves implementations of RFC 1510 which may be more restrictive. 
Assuming this problem is real, could we resolve it with policy settings
on supplied flags in client and/or KDC?

Cheers,
 -Rick

6.  Named bit assignments

   Names for named bit assignments must be unique within a given named
   bit registry, and typically do not have name prefixes that identify
   which registry they belong to.

   Assignments for named bits 0 through 31 require standards action,
   due to their scarcity; RFC 4120 predicts higher bit numbers, but use
   of these bits may involve fixing applications that falsely assume
   that no more than 32 named bits will ever be assigned.  These bits
   are available under a less restrictive policy because they are not
   scarce.

6.1.  AP-REQ options

   Registry name:      AP-REQ options

   Assignment policy:  Standards action
   Valid values:       ASN.1 bit numbers 0 through 31

   Assignment policy:  Experimental and Private Use
   Valid values:       ASN.1 bit numbers 32 through 35

   Assignment policy:  Specification Required
   Valid values:       ASN.1 bit numbers 36 and up

6.2.  KDC-REQ options

   Registry name:      KDC-REQ options

   Assignment policy:  Standards action
   Valid values:       ASN.1 bit numbers 0 through 31

   Assignment policy:  Experimental and Private Use
   Valid values:       ASN.1 bit numbers 32 through 35

   Assignment policy:  Specification Required
   Valid values:       ASN.1 bit numbers 36 and up

6.3.  Ticket flags

   Registry name:      Ticket flags

   Assignment policy:  Standards action
   Valid values:       ASN.1 bit numbers 0 through 31

   Assignment policy:  Experimental and Private Use
   Valid values:       ASN.1 bit numbers 32 through 35

   Assignment policy:  Specification Required
   Valid values:       ASN.1 bit numbers 36 and up

---

From: Greg Hudson <[email-masked]>
Date: Thu, 14 Apr 2016 11:18:55 -0400

> the registry becomes an administration of such sins.

(There is a brief earlier conversation here:
http://www.ietf.org/mail-archive/web/kitten/current/msg04761.html )

(1) IETF specifications often follow implementations and take into
account their limitations.  The desirable outcome of IETF work is
practical interoperability, not strict adherence to a waterfall model.
As examples, we recently re-issued RFC 4402 as RFC 7802 because
implementations screwed up the PRF count, and we are in the process of
re-issuing RFC 6112 because an implementation screwed up the case of a
key-derivation pepper input.

(2) Heimdal and MIT krb5 both use 32-bit values for the flags fields in
RFC 4120, and use those fields in public library API structures.
(Shishi uses 32-bit flag values but I don't know anything about its
library APIs; I don't think Microsoft has a Kerberos library API.)
There isn't much danger of increasing the number of implementations with
this limitation; the damage is already done.

(3) Applying this rule to the registry now does not preclude changing it
later.  The same high implementation costs would apply regardless of how
the current registry rules are set.

(4) I find this argument really hyperbolic in several respects.  Most
importantly, there are lots of ways to extend RFC 4120 beyond adding
flag values.  "Flags" are just a compressed representation of boolean
values; there are typically other, less efficient ways to add boolean
values to the surrounding ASN.1 sequence, such as authorization-data in
Ticket or padata in KDC-REQ.

(5) This is a real cost, though I can't think of a historical case where
an implementation has squatted on an RFC 4120 flag value.  It needs to
be weighed against the implementation cost of extending flag values.

> experimental/private use.

I don't think this suggestion has any practical benefit.  Anyone who
registers a flag value above 35 with a non-standards-track specification
would find themselves quite disappointed in their ability to use this
flag in any of the widely used krb5 implementations.

> structures with more bits than understood [...]

In some cases, implementations also need to be able to re-encode flag
values (particularly TicketFlags) without losing information.  For
instance, RFC 7751 section 4 requires KDCs to encode an EncTicketPart,
which contains a TicketFlags, for the ticket surrounding a CAMMAC.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Apr 2016 18:29:48 -0400 (EDT)

[sorry for the extra copy, Rick; I had to enter kitten manually since
reply-all tried to send the wrong place, and then I typo'd it]

Hi Rick,

Greg has already covered some of this, but I also wanted to say a few
things.

>  (1) specifications should not follow implementations, and certainly not

A motto of the IETF says (in part), "we believe in rough consensus and
running code".  In practice, this means that weight is given to actual
existing code, and this point is not really true -- IETF specifications
frequently do follow implementations, even bad ones, since that's the
route to getting things deployed.  A perfect spec that is not implemented
is not particularly useful...

>  (3) after confirming a 32-bit limit, we have cut off any chance of

This is also not exactly true; a future standards-track document is
permitted to change the registry specification and allow a larger number
of bits to be used.  And implementations still have to be prepared to
decode larger bitstrings with a conformant ASN.1 decoder -- just reading
bits off the wire into a uint32 would lead to software vulnerabilities.
Perhaps it might confirm it in those libraries' API layer, but that does
not seem to be a materially worse situation than what we have at present.

> not something that a spec should seek to confirm;

I'm not sure what is suggesting that software is fully *incapable* of
being updated; rather that making updates in this case would be a lot of
effort and require churn in the user interface.  Seeking to avoid having
to go through all that effort until it is fully necessary is reasonable to
many people, though reasonable people could certainly disagree.

> the registry becomes an administration of such sins.

This is true, and is somewhat unfortunate.  On the other hand (as Greg
notes), there are usually other places in the protocol where similar
information could be placed for experimental purposes.  That is not a
particularly compelling argument, of course, but in the balance, to me,
the 32-bit limitation still makes sense for now.

-Ben

---

From: Rick van Rein <[email-masked]>
Date: Mon, 18 Apr 2016 08:33:00 +0200

Hello Greg and Ben,

Thanks for your responses.  On a scale between idealism and pragmatism,
perhaps I'm leaning over too much towards idealism.

I am not deeply concerned if KDC implementations choose to setup 32 bit
flags; a KDC is run centrally and can be upgraded.  I'm already more
concerned about clients but mostly about services that make same this
choice in firmware; firmware is at some point not updated anymore.  I
can't remember the instance, but have seen in this group how such
backlog drove choices away from what would otherwise be possible.  It is
this backlog that concerns me.

I understand that the registry can be updated, but I think a registry
that states a 32 bit limit gives rise to the creation of aforementioned
backlog, especially because there is no reason to state the limitation
there.  Given that the values are registered under a formal
specification process, and so that values 32+ are not going to be
released easily, I see no positive side but a potentially strongly
negative side, to making a statement in the registry about an upper
limit to the number of flags.

The rest of my change proposal introduced uses for 32+ values, as a
suggestion to implementations to care for those flags.  As Greg stated,
there is a little more to this than silently ignoring them, so we could
discuss whether that is such a good idea.  To me, that's a gray area; it
is desirable to have Experimental / Private flags but requiring
implementations to support such flags may be too much asked.  The
Specification Required suggestion is more something that arose as a
side-effect possibility, it is not that important on its own.

Cheers,
 -Rick