Subject: Section 7 Kerberos Revisions for comment

From: Clifford Neuman <[email-masked]>
Date: Thu, 14 Sep 2000 09:30:39 -0700 (PDT)

Here is section 7.  Section 6 will follow, today or tomorrow.

Clifford Neuman

---

<H3>7.  Naming Constraints</H3>

<H3>7.1.  Realm Names</H3>

Although realm names are encoded as GeneralStrings and although a
realm can technically select any name it chooses, interoperability
across realm boundaries requires agreement on how realm names are to
be assigned, and what information they imply.

<P>

To enforce these conventions, each realm must conform to the
conventions itself, and it must require that any realms with which
inter-realm keys are shared also conform to the conventions and
require the same from its neighbors.

<P>

Kerberos realm names are case sensitive.  Realm names that differ only
in the case of the characters are not equivalent.  There are presently
four styles of realm names: domain, X500, other, and reserved.
Examples of each style follow:

<PRE>
     domain:   ATHENA.MIT.EDU (example)
       X500:   C=US/O=OSF (example)
      other:   NAMETYPE:rest/of.name=without-restrictions (example)
   reserved:   reserved, but will not conflict with above
</PRE>

Domain names must look like domain names: they consist of components
separated by periods (.) and they contain neither colons (:) nor
slashes (/).  Though domain names themselves are case insensitive, in
order for realms to match, the case must match as well.  When
establishing a new realm name based on an internet domain name it is
recommended by convention that the characters be converted to upper
case.

<P>

X.500 names contain an equal (=) and cannot contain a colon (:) before
the equal.  The realm names for X.500 names will be string
representations of the names with components separated by slashes.
Leading and trailing slashes will not be included.  Note that the
slash separator is consistent with Kerberos implementations based on
RFC1510, but it is different from the separator recommended in
RFC2253.

<P>

Names that fall into the other category must begin with a prefix that
contains no equal (=) or period (.) and the prefix must be followed by
a colon (:) and the rest of the name.  All prefixes must be assigned
before they may be used.  Presently none are assigned.

<P>

The reserved category includes strings which do not fall into the
first three categories.  All names in this category are reserved.  It
is unlikely that names will be assigned to this category unless there
is a very strong argument for not using the 'other' category.

<P>

These rules guarantee that there will be no conflicts between the
various name styles.  The following additional constraints apply to
the assignment of realm names in the domain and X.500 categories: the
name of a realm for the domain or X.500 formats must either be used by
the organization owning (to whom it was assigned) an Internet domain
name or X.500 name, or in the case that no such names are registered,
authority to use a realm name may be derived from the authority of the
parent realm.  For example, if there is no domain name for
E40.MIT.EDU, then the administrator of the MIT.EDU realm can authorize
the creation of a realm with that name.

<P>

This is acceptable because the organization to which the parent is
assigned is presumably the organization authorized to assign names to
its children in the X.500 and domain name systems as well.  If the
parent assigns a realm name without also registering it in the domain
name or X.500 hierarchy, it is the parent's responsibility to make
sure that there will not in the future exist a name identical to the
realm name of the child unless it is assigned to the same entity as
the realm name.

<H3>7.2.  Principal Names</H3>

As was the case for realm names, conventions are needed to ensure that
all agree on what information is implied by a principal name.  The
name-type field that is part of the principal name indicates the kind
of information implied by the name.  The name-type should be treated
as a hint.  Ignoring the name type, no two names can be the same (i.e.
at least one of the components, or the realm, must be different).  The
following name types are defined:

<PRE>
  name-type      value   meaning

   NT-UNKNOWN        0   Name type not known
   NT-PRINCIPAL      1   General principal name (e.g. username, or DCE principal)
   NT-SRV-INST       2   Service and other unique instance (krbtgt)
   NT-SRV-HST        3   Service with host name as instance (telnet, rcommands)
   NT-SRV-XHST       4   Service with slash-separated host name components
   NT-UID            5   Unique ID
   NT-X500-PRINCIPAL 6   Encoded X.509 Distingished name [RFC 1779]
   NT-SMTP-NAME      7   Name in form of SMTP email name (e.g. [email-masked])
</PRE>

When a name implies no information other than its uniqueness at a
particular time the name type PRINCIPAL should be used.  The principal
name type should be used for users, and it might also be used for a
unique server.  If the name is a unique machine generated ID that is
guaranteed never to be reassigned then the name type of UID should be
used (note that it is generally a bad idea to reassign names of any
type since stale entries might remain in access control lists).

<P>

If the first component of a name identifies a service and the
remaining components identify an instance of the service in a server
specified manner, then the name type of SRV-INST should be used.  An
example of this name type is the Kerberos ticket-granting service
whose name has a first component of krbtgt and a second component
identifying the realm for which the ticket is valid.

<P>

If instance is a single component following the service name and the
instance identifies the host on which the server is running, then the
name type SRV-HST should be used.  This type is typically used for
Internet services such as telnet and the Berkeley R commands.  If the
separate components of the host name appear as successive components
following the name of the service, then the name type SRV-XHST should
be used.  This type might be used to identify servers on hosts with
X.500 names where the slash (/) might otherwise be ambiguous.

<P>

A name type of NT-X500-PRINCIPAL should be used when a name from an
X.509 certificate is translated into a Kerberos name.  The encoding
of the X.509 name as a Kerberos principal shall conform to the
encoding rules specified in RFC 2253.

<P>

A name type of SMTP allows a name to be of a form that resembles a
SMTP email name. This name type can be used in conjunction with
name-canonicalization to allow a free-form of username to be specified
as a client name and allow the KDC to determine the Kerberos principal
name for the requested name.  [JBrezak]

<P>

A name type of UNKNOWN should be used when the form of the name is not
known.  When comparing names, a name of type UNKNOWN will match
principals authenticated with names of any type.  A principal
authenticated with a name of type UNKNOWN, however, will only match
other names of type UNKNOWN.

<P>

Names of any type with an initial component of 'krbtgt' are reserved
for the Kerberos ticket granting service.  See section 8.2.3 for the
form of such names.

<H4>7.2.1.  Name of server principals</H4>

The principal identifier for a server on a host will generally be
composed of two parts: (1) the realm of the KDC with which the server
is registered, and (2) a two-component name of type NT-SRV-HST if the
host name is an Internet domain name or a multi-component name of type
NT-SRV-XHST if the name of the host is of a form such as X.500 that
allows slash (/) separators.  The first component of the two- or
multi-component name will identify the service and the latter
components will identify the host.  Where the name of the host is not
case sensitive (for example, with Internet domain names) the name of
the host must be lower case.  If specified by the application protocol
for services such as telnet and the Berkeley R commands which run with
system privileges, the first component may be the string 'host'
instead of a service specific identifier.  When a host has an official
name and one or more aliases, the official name of the host must be
used when constructing the name of the server principal.

---
Commentary: Words were added describing the convention that domain
based realm names for newly created realms should be specified as
upper case.  This recommendation does not make lower case realm names
illegal.  Words were added highlighting that the slash separated
components in the X500 style of realm names is consistent with
existing RFC1510 based implementations, but that it conflicts with the
general recommendation of X.500 name representation specified in
RFC2253.

---

From: Sam Hartman <[email-masked]>
Date: 18 Sep 2000 16:15:44 -0400

I've always been puzzd by the role of name types in the Kerberos
protocol.  They seem reasonable within a client library, and possibly
reasonable within a KDC doing name canonicalization.  However, it
never seemed that the document did a good job of explaining where name
types could and could not be used, especially in the presence of a
string representation for names and implementations that basically
ignore the field.

The only enlightenment I reached was
http://www.mit.edu:8008/menelaus.mit.edu/kprot/251.  This message
claims that name types might be useful in the future but even for
comparisons they could be ignored at the current time.

Since then there have been a number of debates about how name types
should be used.

The current text  seems to indicate that (at least for SMTP name type)
name types can be used for name canonicalization.

I think the text needs significant clarification to explain where name
types can and cannot be used.  I could send proposed text, but
basically I would say that they should not be used at all.  Perhaps
someone who wants to use name types could send text better explaining
when they MAY be used and when they MUST be ignored.

Also, I do not understand what the SMTP name type is used for.  The
text is not clear enough that I could implement it and expect to
interoperate.

---

From: Sam Hartman <[email-masked]>
Date: 18 Sep 2000 16:15:44 -0400