Subject: [Ietf-krb-wg] referrals: selection of client credentials

From: Ken Raeburn <[email-masked]>
Date: Sun, 23 Dec 2007 17:42:36 -0500

If we get a cross-realm TGT in a server referral case, must we use  
that TGT in authenticating to the next realm, if we have another for  
the same destination realm with a shorter authentication path?

General case:

* Client principal is in realm A.

* User types a name that's (apparently) in realm B, and, either  
through a referral from realm A or local configuration, authenticates  
to realm B, asking for service credentials.

* Realm B refers the client to realm C, and maybe offers a new  
service principal name.  (Perhaps domain B just has a DNS CNAME  
record pointing into domain C, and the KDC is set up to issue  
parallel referrals for selected services.  Maybe company B has been  
bought by company C, and the services merged into C's, but the old  
names left active to support existing customers.)

* Realms A and C have done the key-exchange dance, and so realm C's  
KDCs and application servers won't be expecting realm B to be in the  
transit path from A.

A weird special case: Instead of realm C, we're referred back to  
realm A, so credentials identifying a local user but coming from a  
remote realm will almost certainly be rejected.  Perhaps the name in  
realm (and domain) B was typed just because it was a lot shorter, or  
maybe it was put in a config file before the service was moved from B  
to A.  (And assume realm A's admins don't coordinate with realm B's  
admins to the degree that the realm-B alias info could be  
incorporated into realm A's KDC database.)

Should the authentication path necessarily match the referral path,  
or should the preferred authentication path to the indicated  
destination realm be used?  (Can we allow the client to pick, or must  
we dictate one?)  How about if there's a loop like in the special- 
case example?

I talked with Sam briefly about this, and he's concerned that  
separating the name processing from the authentication path makes the  
referrals proposal too much like a general name service.  Meanwhile,  
I've been suggesting for years that if we don't go in the direction  
of a general name service, there'll be arbitrary lines between  
reasonable cases that work and reasonable cases that don't work...

Sam also suggested that maybe in the referral process realm B should  
be able to impose its policies (new authorization-data restrictions,  
maybe enforced anonymity if we add that capability some day), but I'm  
not convinced that they should be required to be enforced if I'm not  
authenticating to a service in realm B.

Opinions?

Ken
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg