Subject: constrained integer types

From: Tom Yu <[email-masked]>
Date: 04 Dec 2000 20:41:30 -0500

There are a number of places in the Kerberos protocol where
unconstrained integers are used.  The integer values that may be
encoded in ASN.1 are effectively unbounded.  Most implementations will
only use 32-bit integers.  The following types may be useful:

    Int32 ::= INTEGER (-2147483648..2147483647)
        -- signed values representable in 32 bits
    UInt32 ::= INTEGER (0..4294967295)
        -- unsigned 32 bit values
    Microseconds ::= INTEGER (0..99999)

Int32 would be used in every case where a protocol constant
(e.g. enctypes, checksumtypes) is needed, since these may take on
negative values.

UInt32 would be used for other things, such as sequence numbers.  The
behavior of wrapping at 32 bits is made more explicit in the most
recent -revisions draft, but in my opinion, making a constrained type
for it is best.  (Strangely enough, the MIT implementation uses signed
sequence numbers, which is likely a bug...)

Microseconds would be used in the obvious places.  This constraint
already exists in the text of RFC-1510 but not in the ASN.1 syntax.

Are there any objections to the above proposals?

Do people think it's reasonable to constrain a nonce to 32 bits?
Should it be signed or unsigned?  (The MIT implementation sends it as
signed, which is probably a bug, but also uses the current unix
time...)

Also, do people think it's reasonable to apply explicit single-value
constraints to integer fields of messages that may only take on one
value, such as the pvno or msg-type fields of many messages?

The MIT implementation using signed 32 bit integers in various places
where one might expect unsigned integers is somewhat of a problem,
though.  I'm not sure quite how we should accomodate this.  If we make
into unsigned integers the types that one would expect to be unsigned,
then things may fail half the time, due to negative numbers being sent
by MIT code.  The current code also probably depends on non-portable
wraparound behavior of signed integers, but that's a separate issue.

---Tom