Subject: RE: name canonicalization

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

> -----Original Message-----
> From: Douglas E. Engert [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2000 9:11 AM
> 
> 
> What about caching?
> (My option: good question, what does W2K do today?)

I don't know for sure; I don't think it's much. Regardless of what it
currently does, I can't think of any reason why a client couldn't
remember that
	"ftp/bar"
got canonicalized to "ftp/[email-masked]" and use the
ticket for the latter the next time a ticket for the former is
requested, if the ticket hasn't yet expired.

In order to reduce KDC load, I would say that such caching should be
encouraged.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 16 Aug 2000 15:16:24 EDT

> 
> > We can only cache the relationship between "ftp/bar"  and
> > "ftp/[email-masked]" if we know that the lifetime of
> > the alias is either "static" or guaranteed not to change during the
> > lifetime of the ticket.
> 
> Is there an existing requirement that the name of a service not change
> during the lifetime of a ticket?  I think that all that can be said is
> that if you change the name of a service, you can expect info cached at
> clients to result in failures, and this warning applies to both canonical
> names and aliases.
> 
>  - RL "Bob"

I don't think there is an existing requirement but it is standard
practice.  Currently we look up the name of the service and then find
the appropriate ticket.  If the service name changes, we would be
requesting a new ticket since we wouldn't have one already.  

In the new scheme, the service name could change but we wouldn't know
about it.

                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * [email-masked]

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 16 Aug 2000 15:51:58 -0700

> From: Jeffrey Altman [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2000 11:45 AM
> To: Paul Leach
> Cc: [email-masked]; [email-masked]; John Brezak;
> [email-masked]
> Subject: RE: name canonicalization
> 
> 
> > > What about caching?
> the alias is either "static" or guarranteed not to change during the
> lifetime of the ticket.

Well, my password can change after I got a ticket to some service, but
as long as I use the old password for communications with that service,
it works until the ticket expires. Ditto with my user name.
I'm just saying we can and should apply the same methodology to this
case.

> 
> Is this the case?  If so, this should be documented in the revisions
> draft.

Saying that caching is allowed for the lifetime of the ticket would
imply that the out-of-synchness is OK.

Paul

---

From: [email-masked]
Date: Thu, 17 Aug 2000 08:44:36 -0700

I'll try to fill in what Win2K does today - my responses are marked with ***

-----Original Message-----
From: Douglas E. Engert [mailto:[email-masked]]
Sent: Wednesday, August 16, 2000 9:11 AM
To: [email-masked]
Cc: John Brezak; Mike Swift; 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)

*** Yes - any flat name can be resolved to a fully qualified name. This
requires, though, that the KDC be able to locate the name service/foo, which
in NT4 will only work if foo is the netbios host name for foo.domain.

Can foo be replaced with bar, i.e. service/bar.domain.realm
(My option: maybe, only if foo was not a FQDN)
*** Yes - if the name "service/foo" is an spn on the account service/bar,
then this will work. This can happen, for example, when you have a different
DNS name space and kerberos realm name space. For example, consider
"www/microsoft.com" on the account "www/corporate.microsoft.com".

Could the service be replaced, like ftp/foo to host/bar.domain@realm
(My option: no)
*** Yes. This can happen if there are multiple SPNs for a single account. In
windows2k, many services run as local system, and thus their fully qualified
name is "host/bar.domain@realm". If you ask for a ticket to
"rpc/bar.domain@realm", the KDC will replace it with
"host/bar.domain@realm".

Could user return with user@realm2?
(My option: yes only if realm was not specified.) 
*** Yes. Suppose you want a single logon domain for all users at your
company, so everybody can logon as "[email-masked]". In this case, the
logon would return with "[email-masked]" or
"[email-masked]" depending on what realm holds the user account.

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)
*** As paul said, the goal was to get rid of reverse DNS lookups. The KDC
doesn't provide addressing information, so it doesn't tell the client what
network address corresponds to the name.

What about caching?
(My option: good question, what does W2K do today?)
*** Win2k caches tickets for the configured lifetime of the ticket. If the
dns mapping for the service changes, then the service may reject the ticket,
which will cause the client to delete the ticket from its cache and attempt
to get a new one. There is no notion of tying ticket lifetime to the
lifetime of the hostname as resolved by DNS. The client code retries within
a single GSSAPI session, so applications aren't aware of the retry.
The client caches tickets both by SPN and by canonical name, so if it sees
the same SPN again, it will use the cached ticket. However, there is a bug
in Win2k (as far as I know), that it will only cache one SPN per canonical
name, so if the client repeatedly accesses services with different SPNs but
the same canonical names, it will have cache conflicts and need to keep
getting new tickets.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: "Paul Leach" <[email-masked]>
Date: Thu, 17 Aug 2000 10:25:57 -0700

> From: Martin Rex [mailto:[email-masked]]
> Sent: Thursday, August 17, 2000 2:50 AM
> To: [email-masked]
> Cc: [email-masked]
> > - 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.
> 
> 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.

I don't understand this comment. The KDC does not use DNS at all to
resolve the target -- in order to avoid dependence on the insecurity of
DNS (with objective which you appear to agree), it can't.

Perhaps you meant that as long as the client and KDC apply rules that
are _consistent_ with each other, there won't be a problem except when
there an attack.

I believe the Win2k KDC in fact does that. The rule is:
the client puts into the ticket request the host portion of the service
name as it was sent to DNS to resolve.
E.g., if the target is the FTP service on "foo.example.com", then the
SPN will be "ftp/foo.example.com". Or, if the target was "foo" and the
DNS suffix list was "example.org" then what would get sent to DNS to
resolve would be "foo.example.org", so the SPN would be
"ftp/foo.example.org".

The KDC looks up the SPN in a database that maps SPNs to realms. There
can be multiple SPNs for an account (i.e., they all share a service
key). One of those SPNs is the canonical one. This one is returned in
the service ticket, along with the realm. The service is configured to
know which SPN is the canonical one, so that's the one it will expect in
tickets for it. The client can not have any expectation about the
relation of the SPN sent in the TGS_REQ and the canonicalized one in the
ticket, so it can't get confused.

These seem pretty straightforward and "natural". I don't see where a
problem would arise, but maybe there is one.

Paul

(PS: AFAIK, HTML is off; MIME isn't, and can't be turned off.)