Subject: Kerberos referrals

From: Ken Raeburn <[email-masked]>
Date: Fri, 28 Apr 2006 20:44:38 -0400

We didn't get to talk about referrals at the last working group  
meeting, but Larry and I talked a bit about some concerns I had.   
Some of the ideas we came up with should probably be folded into the  
next draft, but I wanted to get the basic points out in email for  
further discussion.

1) The user-to-user case, where the users exchange NT-ENTERPRISE  
names that are not their canonical principal names.  E.g., Alice logs  
in as NT-ENTERPRISE [email-masked] but is really NT-UID  
[email-masked]; Bob logs in as NT-ENTERPRISE [email-masked] but is  
really NT-UID [email-masked].  They talk in the lunch room and  
exchange the login names they use, and go back to their offices to  
initiate a u2u session to exchange some data.  Alice receives a TGT  
for 67890@OFFICE; okay, we could say that she sends it to the KDC  
with a requested server name of bob@MS, and the KDC has to ("SHOULD")  
use the same mapping here as for client name canonicalization at  
login time.  But then Bob gets credentials from 12345@NTDEV and is  
expected to verify the identity as Alice.

--> Proposal: Include signed authz data with the login alias,  
propagated to at least some of the acquired service credentials.   
According to Larry, Windows only allows for one alias, so the issue  
of "Do we include all aliases or just the one used at login time?"  
doesn't come up for them, but the client name canonicalization  
proposal, as far as I recall, had no such restriction, so it's an  
open question.  There's an obvious possible privacy concern here, if  
we don't want authentication to reveal a string that's likely to be  
the same as an email address.  Which leads to the question of who  
gets to see the alias info and who doesn't.

The server-side software then has to be updated to look for this  
alternate name, so that both can be checked against the desired name,  
logged, presented to the user, whatever.

2) Validation of client name canonicalization.  How do we know the  
name wasn't modified by a MITM attack?  The threat scenario is an  
attacker knowing that someone with access to two accounts (perhaps  
with different privileges) is sloppy and uses the same password for  
both, although the attacker doesn't know the password.  A MITM  
attacker could cause the user to unknowingly get the wrong  
credentials, under the guise of client name canonicalization.

--> Proposal: Include mandatory PA-DATA with signed copies of the  
requested name and the real name, and have the client software check  
that the requested name is correct.

How does this help in the case of client referrals?  There is the  
little detail that the request sent to the referred-to KDC uses the  
same client name as the first request.  The client name cannot be  
changed by the referral, and the referred-to KDC must also recognize  
the requested name.  So, for example, a KDC doing referrals of NT- 
ENTERPRISE names to an organization's several internal realms is not  
useful if the KDCs for those realms cannot also handle NT-ENTERPRISE  
names and recognize the referring realm's name as local.

3) Caching of the returned TGT in a server referral, and the mapping  
of names indicated by a referral.  If the user wants additional  
credentials for the same service (perhaps under a new identity,  
perhaps with different flags or authz data or something), can the  
information be re-used?

My notes and recollection say that Larry and I discussed this, but  
that's all.

My proposal is that the client should be able to reuse that data, but  
there are cases (for example, host aliases) where the information may  
change and thus invalidate the cached data.  We do have one obvious  
place to impose a lifetime, and that's the lifetime of the acquired  
credentials, so I'd suggest that the information should be considered  
to expire when the returned credentials carrying the information  
expire, and that the KDC should ... well, Do The Right Thing.   
(Insert some weasel wording that says the implementor needs to think  
about it and decide what the right thing is, maybe including leaving  
it up to the administrator, but suggest, without requiring, that  
something akin to DNS TTL might apply when DNS data like hostnames  
are involved.)

4) AS-REQ server referral versus MITM attack.  Like #2 above, except  
with an unauthorized modification of the requested server principal  
name OR a cross-realm referral happening OR both.

--> Proposal: Include the requested principal name in  
ServerReferralData.  It's only needed in cases where there is no  
integrity check for the KDC-REQ message, namely the AS-REQ exchange  
currently, but if a checksum of the AS-REQ is included as in  
rfc1510ter, this field won't need to be set.

5) A clarification, implied by omission in the current draft: There  
is no in-realm server name canonicalization.  If a server has  
multiple names, the KDC must return credentials using the requested  
name, and the application server must either know all of its names or  
not use the name in finding its own service keys.  This is somewhat  
at odds with the MIT implementation's approach of using the supplied  
service principal name to look up the service key, and potentially  
allowing a server to have multiple different keys under different,  
unrelated names (e.g., a per-host key, plus a shared key used for a  
server pool the host participates in), though keys could probably be  
issued independently under each name the host has without changing  
the current implementation.

So, proposed updates to the draft:

For u2u case, NT-ENTERPRISE name canonicalization (or, probably, any  
client-name canonicalization) should apply to the requested "server"  
principal name.  Probably add an example exchange.

Add optional requested principal name to ServerReferralData, and text  
describing when it's needed.

New mandatory PA-DATA for client name canonicalization.

New optional authz data with (the?) login alias.

Descriptive text emphasizing or clarifying: (1) referring and  
referred-to realm must recognize the same client names; (2) server  
must know all its locally-assigned names, or not care; (3) caching  
information; (4) open question for now, whether to include all known  
client name aliases or just the one used; (5) open question for now,  
when to propagate the client name alias and when to omit it.

Also, Larry and JK are talking about submitting a separate,  
informational draft that discusses what Windows implementations are  
doing, which I think is a great idea, since with these proposed  
changes, this spec will differ from that a bit.  So some of the  
Windows-specific bits can be removed.

Ken