[krbwg-51] [grand.central.org #274] Re: Consider keeping name referal

[John Brezak via RT]

<URL: http://new-grand.central.org//rt//Ticket/Display.html?id=274 >

[hartmans - Wed Mar 21 17:42:50 2001]:

> 
> 
> Unless the list significantly objects, we want to keep name referal
> for cross realms.  We are still pulling out server name
> canonicalization.

These are the notes from the side meeting that we had in Minneapolis 
discussing referrals.

Here are my terse notes from the referrals meeting held on Wednesday 
morning.

We had a side meeting to discuss the Kerberos-referrals I-D and 
arrive at a shared understanding of the proposal. We divided the 
discussion into 3 parts - a) Client name canonicalization, b) server 
name canonicalization and c) TGS referrals.

a) Client name canonicalization - the discussion was around the 
scenario of a user having a fixed name that is independent of the 
user's principal name. If the user's principal name changes (say 
they move to another domain), the user's name doesn't change. There 
was no general agreement except that everyone appears to understand 
the scneario and agreed that it is a valuable bit of functionality. 
We intend to discuss this further on the list and in London. However 
the kerberos-revisions will reserve the enterprise name type value 
and the name-canonicalization kdcoption. There are 2 problems that 
are of concern 1) gssapi name canonicalization and 2) the 
unauthorized logon attack (Jeff's attack scenario).

1) For the GSSAPI name canonicalization of the client name for use 
in ACLs, there is an existing problem with GSSAPI v2 where servers 
that have multiple principal names today can have the exact same 
problem if a server is to be used as an authorization subject name 
that is a GSSAPI canonical name. This problem is not new to the 
Kerberos referrals and needs to be addressed in GSSAPI regardless of 
how this proceeds.

2) The unauthorized user attack is documented in the current I-D.

b) Server name canonicalization - the scenario was to allow a 
service principal to have multiple aliases. In current 
implementations this is achieved by having multiple principal names 
all with the same key. This is very similar to what we have today, 
except that the name is never changed in the ticket (referrals I-D 
and Win2000). We need to figure out what is the value of having 
a "foo$" name in the ticket - the service doesn't change it anyway 
in our implementation. There is one expanded scenario that is very 
interesting though (brought up by Ken Reaburn). A user wants to 
setup a DNS alias for a computer in a foreign realm. The name that 
the local user knows the remote server as is not recorded in the 
realm of the server, but you would like to allow kerberos to 
canonicalize the server name for mutual authentication. We agree to 
investigate this scenario. We also discussed the inclusion of the 
ticket extension to convey the non-canonical principal name and all 
aliases for the name. This was deemed to be very useful for 
optimizing the ticket cache, but this will require more thinking to 
apply it properly.

c) TGS referrals - the scenario is that you want to remove extensive 
realm binding information from the client configuration. This means 
that a TGS request to a realm that does not have that service can 
return a referral to a "closer" realm. The change is that instead of 
a server returning a service principal unknown error, it will return 
an
(unsolicited) cross-realm ticket to a "closer" realm. This saves the 
client from having to know the realm of the server beforehand. It 
was agreed that this is very useful and should be part of kerberos-
revisions.


--