Subject: [kitten] draft-ietf-kitten-kerberos-iana-registries -- KerberosFlags limited to 0..31?

From: Rick van Rein <[email-masked]>
Date: Mon, 21 Jul 2014 11:03:55 +0200

Hello Tom Yu / Kitten,

I was surprised to learn that draft-ietf-kitten-kerberos-iana-registries-03 defines

> 6.1.  AP-REQ options
> 
>    Registry name:      AP-REQ options
>    Assignment policy:  Standards action
>    Valid values:       ASN.1 bit numbers 0 through 31
> 
> 6.2.  KDC-REQ options
> 
>    Registry name:      KDC-REQ options
>    Assignment policy:  Standards action
>    Valid values:       ASN.1 bit numbers 0 through 31
> 
> 6.3.  Ticket flags
> 
>    Registry name:      Ticket flags
>    Assignment policy:  Standards action
>    Valid values:       ASN.1 bit numbers 0 through 31

These are all instances of the KerberosFlags type.

I’m not sure that a maximum of 32 bits is required, or desirable, for that type.

RFC 4120 specifies in section 5.2.8 “KerberosFlags” that

>    KerberosFlags   ::= BIT STRING (SIZE (32..MAX))
>                        -- minimum number of bits shall be sent,
>                        -- but no fewer than 32

and

>    Most existing implementations of Kerberos unconditionally send 32
>    bits on the wire when encoding bit strings used as boolean vectors.
>    This behavior violates the ASN.1 syntax used for flag values in RFC
>    1510, but it occurs on such a widely installed base that the protocol
>    description is being modified to accommodate it.
> 
>    Consequently, this document removes the "NamedBit" notations for
>    individual bits, relegating them to comments.  The size constraint on
>    the KerberosFlags type requires that at least 32 bits be encoded at
>    all times, though a lenient implementation MAY choose to accept fewer
>    than 32 bits and to treat the missing bits as set to zero.
> 
>    Currently, no uses of KerberosFlags specify more than 32 bits' worth
>    of flags, although future revisions of this document may do so.  When
>    more than 32 bits are to be transmitted in a KerberosFlags value,
>    future revisions to this document will likely specify that the
>    smallest number of bits needed to encode the highest-numbered one-
>    valued bit should be sent.  This is somewhat similar to the DER
>    encoding of a bit string that is declared with the "NamedBit"
>    notation.

I see nothing here that constrains the number of bits, and I cannot think of any real problems as a result of encoding more bits; not even when a lot of zero bits are included at the high end; for instance, to send 64 bits to be able to include 35 bits worth of flags.  (And if problems arose with existing implementations, then these would constitute an error in the ASN.1 encoding used, and these implementations would need a bug fix.)

I would therefore like to argue that it is not necessary to constrain the "Ticket flags” registry to 32 bits, and that it may be helpful in the future to prepare for longer BITSTRINGs.

I hope this is a useful addition.

Cheers,
 -Rick

---

From: Greg Hudson <[email-masked]>
Date: Mon, 21 Jul 2014 10:43:22 -0400

>>    Valid values:       ASN.1 bit numbers 0 through 31
[...]

I believe this is in deference to implementations which store flag
values in fixed 32-bit flags.  For example, in MIT krb5:

* krb5_flags is a 32-bit integer type.
* A krb5_flags field representing ticket flags is included in krb5_creds.
* krb5_creds is used in several core public APIs such as
krb5_get_credentials.

Although RFC 4120 has a well-specified means of encoding larger flag
values over the wire, there would still be a significant implementation
cost to using larger bit values over the wire.

If the IETF decides that this implementation cost is warranted, the
standards action which assigns the flag value could amend the registry
to accomodate it.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 23 Jul 2014 12:46:04 +0200

Hi,

> values in fixed 32-bit flags.

I’m fairly new to this list, so I may have missed that discussion.

> standards action which assigns the flag value could amend the registry

So you are saying that the Kitten list has agreed to do it this way?

IMHO, standards should not be dictated by software; it ought to be the
other way around, thus celebrating the soft in software.  It will take long
before we run over the 32 bits, and by then software could be adapted.
Meanwhile, we’re not introducing a “64 kB ought to be enough for everyone”.

But, if all this has been discussed in the past and the group has decided
in favour of the current proposal than I feel it is warranted to ignore this opinion.

-Rick