[471] in Kerberos
Re: valid names
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Fri Jul 29 12:58:45 1988
To: kerberos@ATHENA.MIT.EDU
Cc: Ted Anderson <ota+@andrew.cmu.edu>
In-Reply-To: Ted Anderson <ota+@andrew.cmu.edu>'s message of Thu, 28 Jul 88 16:01:00 -0400 (EDT)
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> I don't think there's any intrinsic reason to prevent '.' in a
> username. Some ambiguity arises in trying to decide where the user
> name ends and the instance begins. Maybe comma should be an
> alternate separator between the name and instance. This is a far
> less likely character to find in either a user or instance name.
>
> However, allowing atsign in usernames is right out. Any system
> that allows '@' in usernames and also supports network mail is going
> to be sorry.
> Ted Anderson
I think that this discussion may be losing sight of some
fundamentals. There are non-UNIX systems out there that use
different mail conventions, and that may have at-signs, dots,
dollar-signs, and even blank spaces in their user names. Kerberos
ought to be applicable to those systems, too.
Kerberos itself should enforce restrictions on the range of
principal, instance, and realm identifiers only to the extent that
restrictions are required for proper, secure operation of an
authentication service. So far the only such requirement I have
heard articulated is of name length, in order to keep the cost of
encryption from getting out of hand. I would propose in addition
that a human-factors/security argument would suggest we constrain
identifiers to the 94 ASCII characters that have usual graphic
representations. Apart from those two sources of argument, no one
has mentioned anything about the authentication process, the Kerberos
protocol, or the Kerberos subroutine call interfaces that requires
that anything else (even space characters) should not be allowed in
Kerberos identifiers.
When Kerberos is applied to particular situations, such as the
authentication of UNIX logins, a mapping of Kerberos names to UNIX
login identifiers needs to be implemented, and to the extent that
people find it convenient to use one-to-one mapping, they may wish to
enforce some restriction from outside Kerberos that leads to not
registering certain names. In the case of UNIX one might impose
restrictions such as no more than 8 characters, that they must all be
lower case alphabetic or numeric, and they must begin with an
alphabetic.
Similarly, if one decides to use Kerberos to authenticate names used
for mail receipt, one might decide not to register names with
at-signs. But each of these examples are application restrictions,
not things that should be enforced by the Kerberos server itself.
Jerry Saltzer
