Subject: RE: Section 7 Kerberos Revisions for comment

From: "Moore, Patrick" <[email-masked]>
Date: Tue, 26 Sep 2000 08:54:57 -0600

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 11:19:39 -0400

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

--