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

Rick van Rein <rick@openfortress.nl> Mon, 21 July 2014 09:04 UTC

From: Rick van Rein <rick@openfortress.nl>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Jul 2014 11:03:55 +0200
To: tlyu@mit.edu, kitten@ietf.org
Message-Id: <93975EF5-D151-417E-8043-6B54D36FD9DC@openfortress.nl>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/yqV5stI91cl9P4ABaWlsAj-3IK4
Subject: [kitten] draft-ietf-kitten-kerberos-iana-registries -- KerberosFlags limited to 0..31?
Precedence: list

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

[kitten] draft-ietf-kitten-kerberos-iana-registri… Rick van Rein
Re: [kitten] draft-ietf-kitten-kerberos-iana-regi… Greg Hudson
Re: [kitten] draft-ietf-kitten-kerberos-iana-regi… Rick van Rein