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: "Moore, Patrick" <[email-masked]>
Date: Thu, 14 Sep 2000 18:57:19 -0600

I believe Kerberos should support the service@hostname functionality
provided by SRV_HST name types, but where the service name consists of slash
separated components, and the hostname is the single (final) component.  

Especially at DCE sites, it is common to use DCE container ACLs so as to
allow distributed management of service identities and keytabs. We have
service identities with names like drm-daemon/broker/<hostname> and
drm-daemon/info-service/<hostname>. Most of these are GSSAPI or SASL/GSSAPI
services expecting gss_nt_service_name name types.

We have kludges in our Krb5 builds today to support this, but I think we
need this functionality supported by the spec, then we can make mods that
could be merged. 

Preferred solution for us would be to change the text:

> components will identify the host. 

To something like:

 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 multi-component name of type NT-SRV-HST if the
 final component is a fully qualified Internet domain hostname for 
 the service's host, or a multi-component name of type NT-SRV-XHST 
 if the first component identifies a service and the name of the host 
 is of a form such as X.500 that allows slash (/) separators.  
 
A less desirable alternative would be to add another name type, such as: 

  NT-CPLXSRV-HST		8 Slash-separated complex service with host
name as final component

I prefer the first alternative because the Krb5 GSSAPI implementation
could simply map gss_nt_service_name into NT-SRV-HST. 

Pat Moore
Sandia National Labs
[email-masked]

> -----> From: Clifford Neuman [mailto:[email-masked]]
> Sent: Thursday, September 14, 2000 10:31 AM
> To: [email-masked]; [email-masked]
> Subject: Section 7 Kerberos Revisions for comment
> 
> 
. . .  [ snip ] Section 7.2 follows . . . 
> used when constructing the name of the server principal.
[ snip ]

---

From: "Moore, Patrick" <[email-masked]>
Date: Tue, 26 Sep 2000 12:28:31 -0600

That's an interesting point. I played around with allowing an embedded '/'
in the service name.  To make that work i need to muck with lots of
low-level krb5 code (like replay cache code) that assumes that a principal
name component never has a slash.  Also my reading of the spec implies that
the only alowance for '/' in a principal name is for names of type
NT_SRV_XHST where the slash is in an x.500 style hostname.

But I think I could probably make that work if folks think that embedded
slashes in a principal component is a more palatable solution than
supporting more than two components in NT_SRV_HST.

- pat

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Monday, September 25, 2000 9:54 PM
> To: [email-masked]
> Subject: Re: Section 7 Kerberos Revisions for comment
> 
> 
> "Moore, Patrick" <[email-masked]> writes:
> > My suggestion is that the NT_SRV_XHST wording stay 
> unchanged, so that the
> > first component is the service and evrything else is the 
> host. NT_SRV_HST
> > would be just the opposite - the last component is the host 
> and everything
> > else is the service. In both cases you know where the boundry is.
> 
> So would the first component be "foo/bar" (with "foo\/bar/host/name"
> in the printed form)?  If so, that'd work for NT_SRV_HST as well.  Or
> do you just not get the ability to provide multipart service
> identification with X.500 names?
> 
> > I'm also unfamiliar with X.500 hostname formats, and don't 
> know whether
> > anybody might want to somehow use that format in a GSSAPI/SASL
> > service@hostname connection. But I know that if the 
> NT_SRV_XHST were to be
> 
> I would guess so, if anyone's using Kerberos and X.500 names in the
> same environment.  Having to pass different service names depending on
> the hostname type would be unfortunate.
> 
> 
> Nicolas Williams <[email-masked]> writes:
> > Pardon me, but, if the hostname is not X.500 then it must 
> be an FQDN, as
> > in a DNS FQDN. Right? Then, if you never use '.' in service 
> names, you
> > can distinguish the hostname components in NT-SRV-XHST from 
> the other
> > instance components. Granted, it's hackish.
> 
> What about using '.' for service name components in both name types?
> Then the service name supplied and the work done to pick it apart are
> identical regardless of the hostname type.
> 
> > Does anyone use '.' in service name components other than hostnames?
> 
> Realm, AFS cell, or other domain-like entity names ... but not as
> anything other than the domain-like-entity name in anything I've seen.
> 
> Ken
>