[469] in Kerberos
daemon@TELECOM.MIT.EDU ((Stephen Tihor))
Thu Jul 28 20:09:52 1988
From: (Stephen Tihor) <TIHOR@CMCL1.NYU.EDU>
To: <KERBEROS@ATHENA.MIT.EDU>
In-Reply-To: <MWvreay00VseAGl3Mu@andrew.cmu.edu>
Any field which contains the names of (a) existing programs, or (b) users
must be in general unbounded and unrestricted. There are operating systems
which permit pretty arbitrary usernames contain all the alphanumeric, national
replacement characters, and selected separators (INCLUDING BLANKS).
Considering the possibilities of Kanji usernames in any of the possible
encodings it would be best to not restrict this field.
Historically people hacking together code for Unix tend to ignore such issues
(e.g. sendmail) but if Kerberos is a serious first draft of a protocol we
hope to see adopted generally then it is a bad idea to add restrictions
that rule out its use by other vendors.
Realms and instances if named with the internet domain rules should follow
those rules as to the maximum size. I suspect in practice most names will be
shorter than 35 characters but everyday I use a couple of boxes that can not
express an internet name over 12 characters because their designers expected
the world to be xyz.asb.hjk. Setting a defacto limit means some other, honest
person will try and follow the rules and lose when using your version of the
code. Granted that we can define what a realm is so that it follows our own
naming rules but if the use of the real domain name rules is not acceptable why
were these fields defined as domain names rather than say unix path names,
another well defined heirarchical namespace?
You write, "Internet domain names are case insensitive, whereas, names,
instances, and realms are case sensitive. A standard needs to be established
for selecting the name of a realm from the various case representations of the
corresponding domain name. Alternatively, realms (and perhaps instances) could
be made case insensitive." I agree. By the same arguement I made before
I believe we should try and follow those rules exactly or else make up our
own ab initio.
If you feel you need to put an upper bound on the size of the ticket you can
ask around for reasoable values but I expect you will end up with something
like 1000 bytes worst cases. If preallocation of buffers is necessary perhaps
specifying an options dialog whereby Kerberos can discuss the legal size of
fields at the moment when a piece of Kerberos using code needs to get a buffer
allocated would be appropriate. [I am unsure why you are that concered about
this issue.] I am much more concerned about the realtively short passwords
being used.
-------
