Subject: RE: Section 7 Kerberos Revisions for comment

From: "Moore, Patrick" <[email-masked]>
Date: Tue, 26 Sep 2000 13:34:16 -0600

Re:
nico> At any rate, if you have no dots in components other that the 
nico> host name you can at least distinguish the hostname from the 
nico> other components.

To distinguish you also need to assume that a hostname component always has
a dot. 

If the spec were modified to say that for NT_SRV_HST dots must not be used
in non-hostname principal components, and must be present in hostname
principal components, then I could kludge in what I need.  With that, we
would have even more flexibility - could allow names like
<container>/<hostname>/<instance>

But I worry that there are deployments out there where the canonical
hostname does not have a dot, and the above change would break things for
them.  My proposed change was designed to do no harm to existing
deployments. 

- pat

> 
> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Tuesday, September 26, 2000 9:20 AM
> To: Moore, Patrick
> Cc: [email-masked]
> Subject: Re: Section 7 Kerberos Revisions for comment
> 
> 
> 
> Allowing '/' in individual components gets a little confusing, IMNSHO.
> 
> The issue is, what should the order of components "types" in a service
> principal be:
> 
>  - service / host [ / other-component1 [ / other-component2 ...]]
> 
>  or
> 
>  - service [ / other-component1 [ / other-component2 ...]] / host
> 
> And what should the semantics of the other components be. I think
> Microsoft allows trailing components to specify UDP/TCP port 
> numbers and
> the like in ActiveDirectory SPNs.
> 
> At any rate, if you have no dots in components other that the 
> host name
> you can at least distinguish the hostname from the other components.
> 
> Yes, with TGTs there is no hostname component, instead there 
> is a realm
> name component, but this too is not a problem.
> 
> As for fully qualifying hostnames, it's pretty hard to make 
> good use of
> Kerberos unless you: a) have NO DNS or b) have DNS and fully qualify
> hostnames in SPNs (and gethostbyaddr(localhost's IP addresses) returns
> an FQDN).
> 
> A ticket extension type for specification of such things as server
> UDP/TCP ports, RPC program numbers and so on might be useful here.
> 
> Nico
> 
> 
> On Tue, Sep 26, 2000 at 08:54:57AM -0600, Moore, Patrick wrote:
> > If the hostname is not X.500 then we have no problem 
> distinguishing the
> > boundry between the service and the hostname. We are doing 
> that now with a
> > simple mod in libgssapi_krb5. I'm looking for a clean and 
> straightforward
> > adjustment of the NT_SRV_HST verbiage to support what we 
> are doing. ('We' in
> > this case refers to national labs with DCE infrastructures)
> > 
> > If you are suggesting that NT-SRV-XHST be redefined so as 
> to specify that
> > the service name or the host name or both may have slash seperated
> > components, and that DNS style names (non X.500 names) must 
> always be fully
> > qualified (containing a dot) then we'd still need a kludge 
> to find the
> > boundry in the X.500 case. 
> > 
> > Plus, in the current implementation the hostname in a 
> service@hostname
> > target need not be fully qualified, it just needs to be 
> resolved by both the
> > client and server as the canonical name. So it might not 
> have a 'dot'
> > 
> >   
> > - pat
> > 
> > 
> > > -----Original Message-----
> > > From: Nicolas Williams [mailto:[email-masked]]
> > > Sent: Monday, September 25, 2000 8:17 PM
> > > To: Moore, Patrick
> > > Cc: 'Ken Raeburn'; [email-masked]
> > > Subject: Re: Section 7 Kerberos Revisions for comment
> > > 
> > > 
> > > 
> > > 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.
> > > 
> > > Does anyone use '.' in service name components other than 
> hostnames?
> > > 
> > > Nico
> > > 
> > > 
> > > On Mon, Sep 25, 2000 at 04:21:39PM -0600, Moore, Patrick wrote:
> > > > Re:
> > > > Ken> Would you suggest also extending NT-SRV-XHST in the 
> > > same manner, so as
> > > > Ken> to allow the slash-separated components in the service 
> > > name regardless
> > > > Ken> of the hostname format? 
> > > > 
> > > > 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.
> > > > 
> > > > 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
> > > > extended to allow slash separated service names you would 
> > > have a problem --
> > > > you would have no way of knowing the boundry between the 
> > > service and the
> > > > host. And for this gssapi nametype you must be able to 
> parse out the
> > > > hostname part from the service name part. (When krb5 
> gss imports a
> > > > gss_nt_service_name it validates the hostname part of the 
> > > principal using
> > > > gethostbyname/gethostbyaddr calls.)
> > > > 
> > > > 
> > > > - Pat  
> > > --
> > > 
> --
>

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Sep 2000 15:56:07 -0400

> To distinguish you also need to assume that a hostname component always has

Yes. If no component has a dot you can default things so the second
component MUST be the hostname.

Hackish, hackish. I know.

> <container>/<hostname>/<instance>

Right.

> them.  My proposed change was designed to do no harm to existing

You proposed allowing '/' characters in the components, yes? Isn't that
a problem? I mean, won't you have to quote '/' characters and so on?

I think that conventions such as: "a hostname component must have a . or
else it must be the second component" are simpler to deal with.

The draft already contains such conventions in the section about realm
naming anyways.

Nico
--