Subject: Re: Section 7 Kerberos Revisions for comment

From: Nicolas Williams <[email-masked]>
Date: Thu, 28 Sep 2000 14:34:42 -0400

On Thu, Sep 28, 2000 at 12:28:27PM -0600, Moore, Patrick wrote:
> Nico, you must have somehow misunderstood my proposed 
> revision if you think it's not backwards compatible.  
> The current draft and current MIT implementation of 
> gss_import_name both require that the hostname be the 
> final component. If anyone is using gss-nt-service 
> name in Krb5 where the hostname is NOT the final component, 
> they have diverged from the draft and have 
> seriously kludged their code. (Nico, if you have access 
> to MIT source, look at krb5_gss_import_name and 
> krb5_sname_to_principal and you will see what I mean) 

I was thinking of applications that use raw Kerberos, not GSS-API. Not
that I could think of any particular application. It's just that there
always seems to be some organization that does something weird with
Kerberos and they tend to come out of the woodwork at some point and say
"but that breaks our setup!".

:)

> In the interest of putting this thread to bed, I'll propose 
> some verbiage that I think would support hypothetical cases
> where the hostname may need to be in something other than the
> last component of the hostname.

[...]

I concur.

> - pat

Nico
--

---

From: "Moore, Patrick" <[email-masked]>
Date: Thu, 28 Sep 2000 12:28:27 -0600

Here is the original verbiage:
>> 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. 

Here is what I first proposed:
> 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.  

And here is something I think will work 
that allows lots of flexibility:
--------------------------------------------------------------
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 or NT-SRV-XHST.  In names of type NT_SRV_HST 
the final component is generally assumed to be the canonical 
Internet domain hostname for the service's host. If the 
hostname is not the final component, it is assumed that the 
implementation can reliably determine from the service 
identifier which component is the hostname. In names of 
type NT-SRV-XHST the first component identifies a service 
and the name of the host is of a form such as X.500 that 
allows slash (/)separators.
-------------------------------------------------------------- 

This will allow me share a simple patch to the
krb5_sname_to_principal function that would support 
everything we need: an implementation that allows
us to use DCE or W2K containers for organizing and controlling
access to GSSAPI/SASL service principals.  My implementation
would support a gss_import_name of a service in the form
<container>/<instance>@<hostname>.  But somebody could add a 
trick so that when they gss_import a name in the form 
"hosts/%h/self@hostname" they understand that the princ 
name should be built as "hosts/<hostname>/self". 

[Note: my code patch will not support an arbitrary number of 
components, and the draft should not say that it must. To do 
that I think I would need a  revision to the 
krb5_build_principal functionality.]

- pat

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Wednesday, September 27, 2000 9:47 AM
> To: Moore, Patrick
> Cc: [email-masked]'
> Subject: Re: Section 7 Kerberos Revisions for comment
> 
> 
> 
> Ok. The only issue is: is anyone using NT_SRV_HST SPNs with 
> more than 2
> components where the hostname is the second component. If so then what
> you propose is not backwards compatible.
> 
> One may wish to take my proposal further and state that the first
> component of SPNs with more that 2 components provides the context
> needed to distinguish if the hostname is the second or last component.
> But given what you say below, I doubt it would be safe to do so.
> 
> Nico
> 
> 
> On Tue, Sep 26, 2000 at 06:08:07PM -0600, Moore, Patrick wrote:
> > Nico,
> > 
> > I could live with what you've proposed here, but personally 
> still prefer my
> > simpler solution, which is adequate for anything I can 
> envision with DCE and
> > W2K. My solution gets us from the current situation where 
> we flat cannot use
> > DCE (or W2K) containers to manage SASL service principals 
> to a situation
> > where we can, which is really all we need. Your suggestion 
> goes further to
> > allow things that I don't anticipate needing, at a cost in 
> simplicity. 
> > 
> > Where your examples say "service" I would recommend 
> "component1".  Typically
> > the leading component would be a container name, and the 
> second component
> > might be something out of /etc/services. 
> > 
> > - pat
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Nicolas Williams [mailto:[email-masked]]
> > > Sent: Tuesday, September 26, 2000 3:35 PM
> > > To: Moore, Patrick
> > > Cc: [email-masked]'
> > > Subject: Re: Section 7 Kerberos Revisions for comment
> > > 
> > > 
> > > 
> > > Well, that may be the solution: that the SPN NT_SRV_HST form 
> > > depends on
> > > the context. After all, the clients and services 
> referencing or using
> > > these SPNs should know the context in which they're used.
> > > 
> > > So then the NT_SRV_HST rules might be:
> > > 
> > >  - SPNs with 2 components must be of the form <service> / <host>
> > > 
> > >  - The form of SPNs with more than 2 components may vary 
> according to
> > >    the application. Specifically there can be two forms:
> > > 
> > >     - <service> / <host> / <component3> [ / ... / <componentN>]
> > > 
> > >     - <service> / <component2> [ / ... / <componentN> ] / <host>
> > > 
> > > Can we ban '.' from non-hostname SPN components 
> (instances)? That, at
> > > least, would allow a heuristic for determining the SPN form 
> > > when context
> > > is missing and FQDNs are used.
> > > 
> > > Any other strange SPN forms?
> > > 
> > > Nico
> > > 
> > > 
> > > On Tue, Sep 26, 2000 at 03:15:14PM -0600, Moore, Patrick wrote:
> > > > DCE also uses components that trail the hostname for many 
> > > (maybe most) of
> > > > its RPC principals. We have lots and lots of them in the form
> > > > "hosts/<hostname>/self" (and <hostname> is not canonical, 
> > > contains no dot.)
> > > > W2K princ names are similar (Windows RPC is an adaptation 
> > > of DCE RPC).  It
> > > > never worried me that these can't be used for NT_SRV_HST 
> > > style services -
> > > > they were never intended for that. 
> > > > 
> > > > Again, I'm trying to solve a real-world problem for DCE 
> > > infrastructures in a
> > > > way that does not break things and can be cleanly 
> implemented and
> > > > documented. If a solution involving parsing of dots or 
> > > embedding slashes
> > > > better supports some W2K or X.500 installation, then I 
> > > could live with that.
> > > > 
> > > > 
> > > > 
> > > > - pat
> > > > 
> > > --
> > > 
> --
>