[506] in Kerberos_Protocol

home help back first fref pref prev next nref lref last post

On Kerberos principal name canonicalization

daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon Sep 11 12:03:25 2000

Date: Mon, 11 Sep 2000 12:00:23 -0400
From: Nicolas Williams <Nicolas.Williams@ubsw.com>
To: Clifford Neuman <bcn@ISI.EDU>, ietf-krb-wg@anl.gov, krb-protocol@MIT.EDU
Message-Id: <20000911120021.H1030@sm2p1386swk.wdr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii


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 username@NWTRADERS.MSFT 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 foobar@NAMERICA1.NWTRADERS.MSFT anywhere in
      NWTRADERS.MSFT domain tree (works)

1c.   Attempt to login as foobar@NWTRADERS.MSFT anywhere in
      NWTRADERS.MSFT domain tree (does NOT work)

2a.   Export foobar@NAMERICA1.NWTRADERS.MSFT to NWTRADERS.MSFT

2b.   Attempt to login as foobar@NWTRADERS.MSFT anywhere in
      NWTRADERS.MSFT domain tree (works)

3a.   Create a user, 'foobar' in EUROPE1.NWTRADERS.MSFT with a different
      password from foobar@NAMERICA1.NWTRADERS.MSFT

3b.   Attempt to login as foobar@NWTRADERS.MSFT anywhere in
      NWTRADERS.MSFT domain tree with foobar@EUROPE1.NWTRADERS.MSFT's
      password (does NOT work)

3c.   Attempt to login as foobar@NWTRADERS.MSFT anywhere in
      NWTRADERS.MSFT domain tree with foobar@NAMERICA1.NWTRADERS.MSFT'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 foobar@NWTRADERS.MSFT anywhere in
      NWTRADERS.MSFT domain tree with foobar@NAMERICA1.NWTRADERS.MSFT's
      password (does NOT work)

4c.   Attempt to login as foobar@NWTRADERS.MSFT anywhere in
      NWTRADERS.MSFT domain tree with foobar@EUROPE1.NWTRADERS.MSFT's
      password (does NOT work)

4d.   Attempt to login as foobar@NWTRADERS.MSFT anywhere in
      NWTRADERS.MSFT domain tree with foobar@NWTRADERS.MSFT'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
--


home help back first fref pref prev next nref lref last post