Subject: On Kerberos principal name canonicalization

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Sep 2000 12:00:23 -0400

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: Matt Hur <[email-masked]>
Date: Wed, 13 Sep 2000 18:13:49 -0700

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Wednesday, September 13, 2000 4:23 PM
> To: Matt Hur
> Cc: 'Nicolas Williams'; Cliff Neuman-ISI; [email-masked];
> [email-masked]
> Subject: Re: On Kerberos principal name canonicalization
> 
> 
> 
> Matt Hur <[email-masked]> writes:
> > 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.
> 
> 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.
> 

These are good comments wrt name canonicalization.  I don't see how this
relates to my comment about user promotion in Windows 2000 (not name
canonicalization) being out of scope.  Am I missing something?