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

From: Larry Zhu <[email-masked]>
Date: Tue, 22 Jan 2008 15:55:54 -0800

You have raised good questions

Ken Raeburn wrote:
> 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?

The spirit of the referrals is to leave the configuration and policy on the KDC. The client should not make any smart decision other than ensure there is not an infinite loop. So we should avoid asking the client for anything, definitely we should not to allow the client to pick.

The referrals should not turn KDC into a generic name service. I do like the idea allowing the enterprise name as the server, but I am overwhelmed with extra processing it entails. Maybe we should need strike a balance between generality and efficiency.

<chair hat on>
What kind of information would be sufficient for you to make progress? I really like to see ways how do we encourage more participation.
</chair hat off>

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Sunday, December 23, 2007 2:43 PM
To: IETF Kerberos Working Group
Subject: [Ietf-krb-wg] referrals: selection of client credentials

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
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg