Subject: RE: On Kerberos principal name canonicalization

From: Matt Hur <[email-masked]>
Date: Tue, 12 Sep 2000 11:34:48 -0700

This is not the canonicalization that is specified in the revisions.  The
Kerberos name canonicalization allows a client to indicate to the KDC that
it is ok to return a ticket (or referral) for a server name that does not
match the server name in the request (i.e. an alias).

What you are describing seems to be out of scope of the Kerberos revisions.

--Matt

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Monday, September 11, 2000 9:00 AM
> To: Cliff Neuman-ISI; [email-masked]; [email-masked]
> Subject: On Kerberos principal name canonicalization
> 
> 
> 
> I attended a Windows 2000 class a few months ago; when the subject of
> principal name canonicalization came up I payed close attention and
> engaged the instructor in some tests to see just how it worked.
> 
> Note that we were using Windows 2000 release software, not betas,
> release candidates, or SP1 for that matter.
> 
> Note also that the subject was not called "Kerberos principal name
> canonicalization" either. Instead we were shown how, in a multi-domain
> Active Directory tree one could "export" principal names from 
> one domain
> to domains higher up.
> 
> I've been meaning to write this up for some time now. Here's what we
> did (I'll use domain names from the class):
> 
> Setup:
> 
>  - top-level domain is NWTRADERS.MSFT
>  - there are several sub-domains, such as:
> 
>     - NAMERICA1.NWTRADERS.MSFT
>     - NAMERICA2.NWTRADERS.MSFT
>     - EUROPE1.NWTRADERS.MSFT
>     - ... (I don't remembers them all :)
> 
> Now, if you create a user in, say, NAMERICA1 you can can export it so
> that the user can log in as [email-masked] an thus save some
> typing on the realm/domain name. Pretty cool eh?
> 
> The question that came (comes) to mind was (is): what is done about
> keeping promoted principal names unique to the domain tree? and, if
> nothing, what happens when there are multiple users in a domain tree
> with the same usernames and at least one of which is promoted?
> 
> Well, we tried several things:
> 
> 1a.   Create a user, 'foobar', in NAMERICA1.NWTRADERS.MSFT domain
> 
> 1b.   Attempt to login as [email-masked] anywhere in
>       NWTRADERS.MSFT domain tree (works)
> 
> 1c.   Attempt to login as [email-masked] anywhere in
>       NWTRADERS.MSFT domain tree (does NOT work)
> 
> 2a.   Export [email-masked] to NWTRADERS.MSFT
> 
> 2b.   Attempt to login as [email-masked] anywhere in
>       NWTRADERS.MSFT domain tree (works)
> 
> 3a.   Create a user, 'foobar' in EUROPE1.NWTRADERS.MSFT with 
> a different
>       password from [email-masked]
> 
> 3b.   Attempt to login as [email-masked] anywhere in
>       NWTRADERS.MSFT domain tree with [email-masked]'s
>       password (does NOT work)
> 
> 3c.   Attempt to login as [email-masked] anywhere in
>       NWTRADERS.MSFT domain tree with 
> [email-masked]'s
>       password (works)
> 
> 4a.   Create a user, 'foobar' in NWTRADERS.MSFT with a password
>       different from the other two 'foobar' users in NAMERICA1 and
>       EUROPE1
> 
> 4b.   Attempt to login as [email-masked] anywhere in
>       NWTRADERS.MSFT domain tree with 
> [email-masked]'s
>       password (does NOT work)
> 
> 4c.   Attempt to login as [email-masked] anywhere in
>       NWTRADERS.MSFT domain tree with [email-masked]'s
>       password (does NOT work)
> 
> 4d.   Attempt to login as [email-masked] anywhere in
>       NWTRADERS.MSFT domain tree with [email-masked]'s password
>       (works)
> 
> [I may be forgetful of some lesser details, but my memory is clear on
> the major points about how uniqueness issues are poorly handled.]
> 
> You can see how confusing this can be.
> 
> Different Kerberos products might handle this differently.
> 
> There is no protocol for informing a realm's KDCs of trusted 
> sub-realms'
> promoted principals. Presumably this is handled in Windows 2000 by the
> presence of some object or object attributes in the LDAP databases for
> the realms involved.
> 
> There is no provision for dealing with principal uniqueness issues.
> 
> This is a practical demonstration of the theory issue that Sam Hartman
> described in http://www.mit.edu:8008/menelaus.mit.edu/kprot/490 which
> can be summarized to "Kerberos is an authentication system, not a
> directory service."
> 
> I wonder if Microsoft or any of its customers really care for this
> feature.
> 
> 
> At the very least some strong words should be included in the draft
> about this problem. In my opinion this feature should be reconsidered
> and maybe even redesigned, if not dropped.
> 
> 
> I am willing to consider the possibility that I'm overreacting.
> 
> NOTE: I myself am not entirely against adding functionality to
> Kerberos which goes beyond authentication. For example I believe that
> TGT forwarding begs for an authorization system whereby users 
> can limit
> the usefulness of forwarded TGTs; I believe this can provide a better
> alternative to Microsoft's PAC-in-Kerberos-tickets private extension.
> 
> Nico
> --
>

---

From: Ken Raeburn <[email-masked]>
Date: 13 Sep 2000 19:22:34 -0400

> What you are describing seems to be out of scope of the Kerberos revisions.

Look at the first paragraph of section 3.1.3 as mailed out.  It talks
about looking up the principal name in an alternate database (which I
think is too implementation-oriented a description).

I also note in passing that the AS_REP generation description doesn't
seem to allow for canonicalization of the specified server principal,
in case it's not a krbtgt principal.  And there's no discussion about
whether krbtgt principal names can be the canonical forms of other
service principal names (say if some site makes Kerberos admin service
use the krbtgt principal), and the possibility of ambiguity that might
result in interpreting the response.

---

From: Ken Raeburn <[email-masked]>
Date: 13 Sep 2000 19:22:34 -0400