[507] in Kerberos_Protocol
RE: On Kerberos principal name canonicalization
daemon@ATHENA.MIT.EDU (Matt Hur)
Tue Sep 12 14:35:35 2000
Message-Id: <E015A077DF20D411A7610050DA289BD41F7618@corporate.cybersafe.com>
From: Matt Hur <matt.hur@cybersafe.com>
To: "'Nicolas Williams'" <Nicolas.Williams@ubsw.com>,
Cliff Neuman-ISI
<bcn@isi.edu>, ietf-krb-wg@anl.gov,
krb-protocol@MIT.EDU
Date: Tue, 12 Sep 2000 11:34:48 -0700
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C01CE8.216F0C10"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C01CE8.216F0C10
Content-Type: text/plain;
charset="iso-8859-1"
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:Nicolas.Williams@ubsw.com]
> Sent: Monday, September 11, 2000 9:00 AM
> To: Cliff Neuman-ISI; ietf-krb-wg@anl.gov; krb-protocol@mit.edu
> 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 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
> --
>
------_=_NextPart_001_01C01CE8.216F0C10
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.75">
<TITLE>RE: On Kerberos principal name canonicalization</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>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).</FONT></P>
<P><FONT SIZE=3D2>What you are describing seems to be out of scope of =
the Kerberos revisions.</FONT>
</P>
<P><FONT SIZE=3D2>--Matt</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Nicolas Williams [<A =
HREF=3D"mailto:Nicolas.Williams@ubsw.com">mailto:Nicolas.Williams@ubsw.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Monday, September 11, 2000 9:00 AM</FONT>
<BR><FONT SIZE=3D2>> To: Cliff Neuman-ISI; ietf-krb-wg@anl.gov; =
krb-protocol@mit.edu</FONT>
<BR><FONT SIZE=3D2>> Subject: On Kerberos principal name =
canonicalization</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I attended a Windows 2000 class a few months =
ago; when the subject of</FONT>
<BR><FONT SIZE=3D2>> principal name canonicalization came up I payed =
close attention and</FONT>
<BR><FONT SIZE=3D2>> engaged the instructor in some tests to see =
just how it worked.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Note that we were using Windows 2000 release =
software, not betas,</FONT>
<BR><FONT SIZE=3D2>> release candidates, or SP1 for that =
matter.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Note also that the subject was not called =
"Kerberos principal name</FONT>
<BR><FONT SIZE=3D2>> canonicalization" either. Instead we were =
shown how, in a multi-domain</FONT>
<BR><FONT SIZE=3D2>> Active Directory tree one could =
"export" principal names from </FONT>
<BR><FONT SIZE=3D2>> one domain</FONT>
<BR><FONT SIZE=3D2>> to domains higher up.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I've been meaning to write this up for some =
time now. Here's what we</FONT>
<BR><FONT SIZE=3D2>> did (I'll use domain names from the =
class):</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Setup:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - top-level domain is =
NWTRADERS.MSFT</FONT>
<BR><FONT SIZE=3D2>> - there are several sub-domains, such =
as:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - =
NAMERICA1.NWTRADERS.MSFT</FONT>
<BR><FONT SIZE=3D2>> - =
NAMERICA2.NWTRADERS.MSFT</FONT>
<BR><FONT SIZE=3D2>> - =
EUROPE1.NWTRADERS.MSFT</FONT>
<BR><FONT SIZE=3D2>> - ... (I don't =
remembers them all :)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Now, if you create a user in, say, NAMERICA1 =
you can can export it so</FONT>
<BR><FONT SIZE=3D2>> that the user can log in as =
username@NWTRADERS.MSFT an thus save some</FONT>
<BR><FONT SIZE=3D2>> typing on the realm/domain name. Pretty cool =
eh?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The question that came (comes) to mind was =
(is): what is done about</FONT>
<BR><FONT SIZE=3D2>> keeping promoted principal names unique to the =
domain tree? and, if</FONT>
<BR><FONT SIZE=3D2>> nothing, what happens when there are multiple =
users in a domain tree</FONT>
<BR><FONT SIZE=3D2>> with the same usernames and at least one of =
which is promoted?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Well, we tried several things:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 1a. Create a user, 'foobar', in =
NAMERICA1.NWTRADERS.MSFT domain</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 1b. Attempt to login as =
foobar@NAMERICA1.NWTRADERS.MSFT anywhere in</FONT>
<BR><FONT SIZE=3D2>> =
NWTRADERS.MSFT domain tree (works)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 1c. Attempt to login as =
foobar@NWTRADERS.MSFT anywhere in</FONT>
<BR><FONT SIZE=3D2>> =
NWTRADERS.MSFT domain tree (does NOT work)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 2a. Export =
foobar@NAMERICA1.NWTRADERS.MSFT to NWTRADERS.MSFT</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 2b. Attempt to login as =
foobar@NWTRADERS.MSFT anywhere in</FONT>
<BR><FONT SIZE=3D2>> =
NWTRADERS.MSFT domain tree (works)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 3a. Create a user, 'foobar' in =
EUROPE1.NWTRADERS.MSFT with </FONT>
<BR><FONT SIZE=3D2>> a different</FONT>
<BR><FONT SIZE=3D2>> password =
from foobar@NAMERICA1.NWTRADERS.MSFT</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 3b. Attempt to login as =
foobar@NWTRADERS.MSFT anywhere in</FONT>
<BR><FONT SIZE=3D2>> =
NWTRADERS.MSFT domain tree with foobar@EUROPE1.NWTRADERS.MSFT's</FONT>
<BR><FONT SIZE=3D2>> password =
(does NOT work)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 3c. Attempt to login as =
foobar@NWTRADERS.MSFT anywhere in</FONT>
<BR><FONT SIZE=3D2>> =
NWTRADERS.MSFT domain tree with </FONT>
<BR><FONT SIZE=3D2>> foobar@NAMERICA1.NWTRADERS.MSFT's</FONT>
<BR><FONT SIZE=3D2>> password =
(works)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 4a. Create a user, 'foobar' in =
NWTRADERS.MSFT with a password</FONT>
<BR><FONT SIZE=3D2>> different =
from the other two 'foobar' users in NAMERICA1 and</FONT>
<BR><FONT SIZE=3D2>> =
EUROPE1</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 4b. Attempt to login as =
foobar@NWTRADERS.MSFT anywhere in</FONT>
<BR><FONT SIZE=3D2>> =
NWTRADERS.MSFT domain tree with </FONT>
<BR><FONT SIZE=3D2>> foobar@NAMERICA1.NWTRADERS.MSFT's</FONT>
<BR><FONT SIZE=3D2>> password =
(does NOT work)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 4c. Attempt to login as =
foobar@NWTRADERS.MSFT anywhere in</FONT>
<BR><FONT SIZE=3D2>> =
NWTRADERS.MSFT domain tree with foobar@EUROPE1.NWTRADERS.MSFT's</FONT>
<BR><FONT SIZE=3D2>> password =
(does NOT work)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 4d. Attempt to login as =
foobar@NWTRADERS.MSFT anywhere in</FONT>
<BR><FONT SIZE=3D2>> =
NWTRADERS.MSFT domain tree with foobar@NWTRADERS.MSFT's password</FONT>
<BR><FONT SIZE=3D2>> =
(works)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> [I may be forgetful of some lesser details, but =
my memory is clear on</FONT>
<BR><FONT SIZE=3D2>> the major points about how uniqueness issues =
are poorly handled.]</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> You can see how confusing this can be.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Different Kerberos products might handle this =
differently.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> There is no protocol for informing a realm's =
KDCs of trusted </FONT>
<BR><FONT SIZE=3D2>> sub-realms'</FONT>
<BR><FONT SIZE=3D2>> promoted principals. Presumably this is handled =
in Windows 2000 by the</FONT>
<BR><FONT SIZE=3D2>> presence of some object or object attributes in =
the LDAP databases for</FONT>
<BR><FONT SIZE=3D2>> the realms involved.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> There is no provision for dealing with =
principal uniqueness issues.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This is a practical demonstration of the theory =
issue that Sam Hartman</FONT>
<BR><FONT SIZE=3D2>> described in <A =
HREF=3D"http://www.mit.edu:8008/menelaus.mit.edu/kprot/490" =
TARGET=3D"_blank">http://www.mit.edu:8008/menelaus.mit.edu/kprot/490</A>=
which</FONT>
<BR><FONT SIZE=3D2>> can be summarized to "Kerberos is an =
authentication system, not a</FONT>
<BR><FONT SIZE=3D2>> directory service."</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I wonder if Microsoft or any of its customers =
really care for this</FONT>
<BR><FONT SIZE=3D2>> feature.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> At the very least some strong words should be =
included in the draft</FONT>
<BR><FONT SIZE=3D2>> about this problem. In my opinion this feature =
should be reconsidered</FONT>
<BR><FONT SIZE=3D2>> and maybe even redesigned, if not =
dropped.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I am willing to consider the possibility that =
I'm overreacting.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> NOTE: I myself am not entirely against adding =
functionality to</FONT>
<BR><FONT SIZE=3D2>> Kerberos which goes beyond authentication. For =
example I believe that</FONT>
<BR><FONT SIZE=3D2>> TGT forwarding begs for an authorization system =
whereby users </FONT>
<BR><FONT SIZE=3D2>> can limit</FONT>
<BR><FONT SIZE=3D2>> the usefulness of forwarded TGTs; I believe =
this can provide a better</FONT>
<BR><FONT SIZE=3D2>> alternative to Microsoft's =
PAC-in-Kerberos-tickets private extension.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Nico</FONT>
<BR><FONT SIZE=3D2>> --</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C01CE8.216F0C10--
