Subject: RE: name canonicalization

From: "Paul Leach" <[email-masked]>
Date: Wed, 16 Aug 2000 10:49:10 -0700

> -----Original Message-----
> From: Douglas E. Engert [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2000 9:11 AM
> To: [email-masked]
> Cc: John Brezak; [email-masked]; Paul Leach
> Subject: Re: name canonicalization
> 
> 
> There has been quite a lot of discussion on name 
> canonicalization and referrals
> which has died down without consciences. This was a feature 
> being added to 
> kerberos-revisions at the request of Microsoft, yet no one at 
> Microsoft has 
> made any comments. 
> 
> The changes to kerberos revisions where based somewhat on:
> <draft-swift-win2k-krb-referals-01.txt> 
> "Generating KDC Referrals to locate Kerberos Realms", January 2000
> M.Swift, J. Brezek
> But not all of it are included in the revisions. 
> 
> I would like to get this resolved, as this appears to be the main 
> unresolved issue with the Kerberos Revision, which we want to get
> to last call this month!
> 
> Some issues:
> 
> Can this be used to look up a service, like service/foo and have
> foo expanded to a full host name. i.e. to service/foo.domain@realm
> (My option: yes)

It seems like a complex way just to look up a service name, but yes it
could be used for that. The main purpose is to get back the realm when
the client doesn't know it, so the TGS request can be sent to the
correct KDC.

> 
> Can foo be replaced with bar, i.e. service/bar.domain.realm
> (My option: maybe, only if foo was not a FQDN)

IIRC, yes, even if it is a FQDN. The canonical name of the account that
has SPN "service/bar.domain" in "realm" may not be "bar.domain". In
fact, in Win2k it is likely to be "bar$" (again, IIRC).

> 
> Could the service be replaced, like ftp/foo to host/bar.domain@realm
> (My option: no)

I think it can. In order to economize on the number of SPNs registered,
each KDC has a mapping of a (configurable) set of service names to
"host".
> 
> Could user return with user@realm2?
> (My option: yes only if realm was not specified.)

I suppose, but given that this is for a TGS_REQ, the client would have
to already have know the user's realm from having done the AS_REQ
successfully.

> 
> Can this be used inplace of DNS for host names? If so, this implies
> that the ticket should be obtained before the connection from 
> to server is made, since the server may change. 
> (My option: no)

I don't understand the question. It can and should be done in place of
reverse DNS lookup of the host IP to get the "canonical" host name. But
if you mean in place of the forward lookup to get the host IP address,
then I don't see how it could serve that function.

> 
> What about caching?
> (My option: good question, what does W2K do today?)
> 
> 
> -- 
> 
>  Douglas E. Engert  <[email-masked]>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439 
>  (630) 252-5444
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Aug 2000 00:01:15 -0400

> fact, in Win2k it is likely to be "bar$" (again, IIRC).

It seems to me that it's important for the KDC to be able to arbitrarily 
replace the service "instance" (hostname) and realm, because it is likely 
to have information that the client may not.  This should happen even if 
the hostname is a FQDN, and perhaps especially so:

- A client may use DNS to decide what IP address to talk to, and then send 
the original hostname to the KDC, which has its own (presumably secure) 
source of alias information.  This means that the client is not obligated 
to depend on potentially-insecure DNS to be sure it is getting a ticket for 
the right service.

- The hostnames used for a service in the KDC may not be the FQDN at all. 
They may be based on names in some other namespace, or even on some kind of 
UUID.

- The KDC may map several services on a host onto the same principal 
(telnet, ftp, etc).  It may also map the same service on several hosts onto 
the same principal, in cases where some form of load-balancing is used.

- The KDC may know that a particular host is in another realm.

One thing I think this should _not_ be used for is to expand partial 
hostnames into fully-qualified ones.  Clients should not use the KDC to 
expand abbreviations -- they should present the KDC with something 
approaching an actual service name.  Expanding abbreviations, hostname or 
otherwise, requires that the KDC know in what context the abbreviation was 
intended.  That may vary from one client to the next, or even from one user 
to the next.

> to already have know the user's realm from having done the AS_REQ

I'm not sure, but I think the question here is whether the KDC can 
canonicalize the user's identity in addition to that of the service.  This 
might be interesting if the KDC wants to map certain foreign users to local 
users, for example.  I think this kind of operation is getting dangerously 
close to meddling in authorization, which would be out-of-scope for 
Kerberos.

>> to server is made, since the server may change.

No.  The KDC should not be used as a general-purpose name service.  It 
seems that at lot of the point of name canonicalization is that a service's 
principal name might not be a straightforward function of the hostname of 
the host that provides it.  Overloading service name canonicalization to 
also provide hostname canonicalization seems like a bad idea to me.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Aug 2000 11:49:48 +0200 (METDST)

> the hostname is a FQDN, and perhaps especially so:

But does the KDC know how the Client resolves target hostname to establish
the (network communication).  I'm worried that when the client and the
KDC independently resolve and replace the hostname part of the target
that the resulting notion of the "target" may differ between client and
KDC, resulting in an authentication failure.  And it is probably hard
to figure out what is wrong why this happens without looking at the
details (TCP endpoint and service name in request and service name
in ticket).  This level of debugging exceeds the feature level for
the diagnostic output of most applications and the skill level of
most users.

> to depend on potentially-insecure DNS to be sure it is getting a ticket for 

That is perfectly fine with me.  As long as both apply the exact same
rule(s) and information source (DNS) to resolve the target, there won't
be any confusion except when someone is trying to spoof the insecure
DNS resolution of the client -- in which case we want the failure.

> - The KDC may know that a particular host is in another realm.

As I mentioned in a previous Email, such features make it hard for
distributed, gssapi-based applications to populate ACLs with names
of services.

> the same principal, in cases where some form of load-balancing is used.

The same service on several hosts onto the same principal?
How do you want to protect against replay of the authentication across hosts
-- usually the replay cache is only shared among processes on a single machine.

> intended.  That may vary from one client to the next, or even from one user 

Hmmmm.  Now what should a client do when the user only supplies a
partial hostname.  As you mentionend earlier, the client may only have
insecure DNS available.  If the clients expands a partial hostname,
it will probably (have to) use DNS and if the client applies the
expansion of the target name before creating the ticket request,
then having secure DNS available on the KDC will no longer protect
you from getting DNS-spoofed on the client.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Aug 2000 12:13:46 +0200 (METDST)

> fact, in Win2k it is likely to be "bar$" (again, IIRC).

Didn't computer accounts in a NT4-Domain looke like computername$.
So this is still valid with W2K?!
When I tried to map a hostbased service name to a local account
on a W2K pro standalone machine with ksetup, it wouldn't accept
service tickets issued to this hostbased service name.  This
translation did work in a W2K-Domain (i.e. Active Directory & NT-KDC))

Now if the localsystem computer account is still named "computername$",
I'm quite worried that the standalone W2K pro will not accept tickets
for host/f.q.d.n, but only for computername$ (which the non-NT KDC
will not know).  Awwww.  I going to try that in the next days ...

> > that the ticket should be obtained before the connection from=20
> > to server is made, since the server may change.=20
> > (My option: no)
> 

Canonicalization of a hostname via DNS is pure-forward resolving.
You *MUST* not go through the IP-Addr reverse resolving.

There were some hacks in the Solaris resolver that did this in order
to make the INSECURE Berkeley rlogin/rsh/rcp procotols work more
consistently, because these "authenticate" based on the peer IP-Address
of the socket from the incoming connection.

-Martin

PS: Paul, would you please disable HTML when posting to
    the ietf-krb-wg mailing list.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Aug 2000 13:53:28 -0400 (EDT)

> DNS resolution of the client -- in which case we want the failure.

Actually, the theory is that the KDC has the same data that's in DNS,
but may not get it via DNS.  For example, the DNS zone files and KDC alias
configuration may be generated from the same database and distributed out
of band.

> -- usually the replay cache is only shared among processes on a single machine.

Interesting question.  That's probably something for the implementation to
deal with.  I just don't want to have the possibility precluded by a
limitation in the protocol, or by language in the standard.

> you from getting DNS-spoofed on the client.

When a client gets an abbreviated hostname from a user, it must expand it
before doing DNS resolution.  Often this step is handled by having the
resolver library search a predefinied list of domains, but it is
nonetheless separate from actual name resolution.  The DNS handles _only_
fully-qualified names.