[476] in Kerberos
Limits in Standards
daemon@TELECOM.MIT.EDU (Ted Anderson)
Mon Aug 1 12:39:45 1988
From: Ted Anderson <ota+@ANDREW.CMU.EDU>
To: jb%cs.brown.edu@RELAY.CS.NET, bcn@june.cs.washington.edu (Clifford Neuman)
Cc: kerberos@ATHENA.MIT.EDU
While I am sympathetic to the desire to allow as much flexibility and
generality in the protocol as possible I think limits should be imposed by a
standard that has aspirations of usefulness. A standard is used by an
implementor to provide information about how other implementations will behave.
When an program is expected to communicate with other systems these guidelines
to those other system's behavior is critically important. A standard that is
too opened ended really just refuses to provide this information, it defers
decisions to another person or another time. The implementor is then forced to
guess, decide on his own, experimentally determine the operational parameters
of other implementations or take other measures to answer these questions for
himself. This is the process I am going through now since there is no standard
yet, but it would be nice to save future implementors the trouble.
Although there may be techniques for allowing truly unlimited name lengths,
these will span a spectrum of difficulty. I think it is safe to assume that
all implementations will impose some length limits, either explicitly or
implicitly. We owe it to the users of the system to specify, in advance, when
a name is too long. Otherwise, longish names will fail in unpredictable ways
when the limits are reached, perhaps in extremely subtle and intermittent ways.
A fixed upper bound can also be a well tested upper bound.
In our case, RPC needs a preallocated area in which to return tickets from
Kerberos. Above some limit, less than 1000 bytes, the underlying IP protocol
will be forced to fragment the packets which will be a source of delay,
complication and error. At still larger sizes an FTP like protocol will have
to be used, which will further complicate things. The limit I suggested of 63
characters has the property that tickets are smaller that 256 bytes, which
should be reasonably convenient for everyone.
A similar, but weaker, argument can be made for restricting the character set
of names. My main purpose in suggesting the restrictions was to allow
reasonability checks on the result of decrypting a ticket. A totally garbaged
ticket could still produce a legal user name, although there will be other ways
of detecting this. Allowing international character sets even precludes
checking for the eighth bit being on. Even if we allow this can we at least
require both user and instance name to have either all or none of their eighth
bits set? If the consensus is to allow any 8 bit byte except null then we
should explicitly say that we expect any sequence of bytes in names and remind
people not to do things like clear the eighth bit, canonicalize white space or
whatever. We should also suggests a standard escape convention for user level
applications to allow entry of unusual characters, such as backslash followed
by three octal digits.
Ted Anderson
