Subject: referrals and canonicalization

From: Ken Raeburn <[email-masked]>
Date: Tue, 6 Sep 2005 21:16:18 -0400

The "introduction" is one and a half pages, out of, what, about ten  
pages, excluding the boilerplate, references, ToC, etc.  Can it be  
reduced a bit?  Is it all "introductory" material?

Are client name canonicalization and server name canonicalization  
required to use the same database?  If not, what happens if I use an  
NT-ENTERPRISE name as a server for u2u?  Can a service use a non- 
canonical principal name (e.g., naively constructing servicename/ 
fqdn@realm) for itself to get credentials for contacting some second  
service?  For example:

At a company where NT-ENTERPRISE and multiple realms are used,  
suppose Alice and Bob meet in the lunch room and want to securely  
exchange some messages or data.  Is "[email-masked]" and  
"[email-masked]" enough to set up a user-to-user session?  If Alice  
tries authenticating to [email-masked], she should get something  
back that tells her (a) she needs to do user-to-user, and (b) the  
principal to use is [email-masked].  Her software  
asks his for a TGT, his sends it.  Then he gets a u2u authenticator  
from [email-masked]; how does he know if this is the  
person he met?  Does he need to go and try to get a ticket to the  
[email-masked] service in order to perform the canonicalization to  
verify it?  Unless the credentials or some other data from Alice  
include "[email-masked]" somewhere, there's no way for Bob to work  
backwards from the data he receives to get to "[email-masked]" in  
an automatic and secure fashion.

The KINK draft says kink/canonical-f.q.d.n is the normal principal  
name to use for KINK authentication.  Can I write a script which does:

   kinit -kt /etc/all-my-krb5-keys kink/`uname -n`

on a system where "uname -n" might return only the first component of  
the name, if the KDC does the obvious client name canonicalization?   
Or do I have to know the canonical name for my local KINK service  
(which may not even use "kink" in the first component)?

I think the u2u and service-as-client cases should be pointed out as  
reasons why the canonicalization process SHOULD be the same in both  
positions, though I admit the service-as-client case is probably a  
little weaker.

Can the client-side software cache the information that ftp/ 
[email-masked] maps to ftp/[email-masked]?  (Hint: If  
the answer is "no", then I may have to contact the KDC every time I  
want to talk to the server "ftp".)  For how long?  Suppose we have  
servers ftp1.example.com and ftp2.example.com, with long-lived DNS  
records, and a short-lived DNS CNAME RR ftp.example.com currently  
pointing to ftp1, but getting switched to ftp2 very soon.  If Alice  
connects to and authenticates to "ftp" now, and then again in a  
couple hours, the CNAME data may have changed.  What about the  
Kerberos tickets?

For server referrals, the alias data may have a lifetime shorter than  
the requested ticket lifetime.  The simplest "fix" I see here is to  
use the expiration time of the alias data as an additional limit on  
the lifetime of the returned tickets, and state that any cached data  
related to principal name aliasing (which may simply be the storing  
of the ftp/ftp1 service ticket under the name ftp/ftp in a local  
cache) may only be valid for the life of the returned tickets.

For client referrals, I think it's a slightly different story.  I'd  
think once we have a client identity we want to stick with it, and if  
the alias mapping changes, that's not going to magically give us  
additional keys for whatever our new name is.  But I might be missing  
something....

Section 6 refers to the validation of the new client name passed back  
from the KDC.  "The true principal name of the client, returned in AS- 
REQ, can be validated in a subsequent TGS message exchange where its  
value is communicated back to the KDC via the authenticator in the PA- 
TGS-REQ padata [RFC4120]."  Okay, this would seem to verify that the  
name in the ticket matches what the client was told.  But does any of  
this validate the mapping from the originally requested name to the  
returned name?  Clearly the password (or other initial authentication  
process) would have to work for the spoofed name as well as the  
requested name, assuming the user is not in collusion with the  
spoofer (in which case we'd just have a variation on the standard  
Zanarotti attack).  This -- users using the same passwords for  
multiple accounts -- certainly happens sometimes.  Without  
canonicalization or referrals, we'd record the original name we  
chose, and use it when trying to get additional tickets, at which  
point things would fail.  If we use the name sent back to us off the  
net, it would be good to have stronger validation of it.

I'm a little uncomfortable with the use of "database" in places; it  
implies a certain structure to the software implementation that may  
not be appropriate.  For example, a server could have a simple set of  
rules for transforming certain names (e.g., NT-ENTERPRISE name  
regular expression "[^/]*@MIT\.EDU" maps to \[email-masked], i.e.,  
anything that looks like a one-component name is treated as such  
after domain to realm name mapping), and if the resulting realm is  
not the local one, no actual database is consulted, and the local  
server doesn't even know if the account actually exists.  Likewise  
for "the mapping table [domain_to_realm]" in the introduction.  The  
text should refer to implementation-defined techniques or "local  
policy", maybe giving these as examples.

I apologize for not writing up text yet for the changes I suggest.   
I'm sort of rushing through this review as part of trying to get some  
comments in on the KINK draft.

Ken