Subject: RE: Section 7 Kerberos Revisions for comment

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:

> 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. 

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
> 
> 
> Here is section 7.  Section 6 will follow, today or tomorrow.
> 
> Clifford Neuman
> 
. . .  [ snip ] Section 7.2 follows . . . 
> <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.
> 
[ snip ]

---

From: Ken Raeburn <[email-masked]>
Date: 25 Sep 2000 17:05:40 -0400

> separated components, and the hostname is the single (final) component.  

Would you suggest also extending NT-SRV-XHST in the same manner, so as
to allow the slash-separated components in the service name regardless
of the hostname format?  I'm not very familiar with X.500 hostname
formats.  Can ambiguities arise this way?  Do we care about being able
to easily identify the boundary between service name and hostname?

Ken