Subject: Proposed draft on name referrals in Kerberos

From: "Mike Swift (NT)" <[email-masked]>
Date: Mon, 26 Jan 1998 13:48:35 -0800

Here is the initial draft of a proposal on handling name referrals in
Kerberos. I haven't decided yet whether this should be put through the CAT
group or simply published as an information draft about the Microsoft
implementation of Kerberos. However, I'm interested in people's feedback on
the mechanism in general.

------------------------------------------------------------------------

CAT Working Group                           Michael M. Swift
INTERNET-DRAFT                                     Microsoft
<draft-ietf-cat-init-kerb-referrals-00.txt >
Expires July 15, 1998                       January 15, 1998

                  Generating KDC Referrals

STATUS OF THIS MEMO

This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress".

To learn the current status of any Internet-Draft, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West
Coast).

Distribution of this document is unlimited.  Please send
comments to the CAT working group at [email-masked] or the
authors.

ABSTRACT

The draft proposes a new method for a Kerberos Key
Distribution Center (KDC) to respond to client requests for
tickets. The KDC will handle requests for principals in
other realms by returning either a referral error or a cross-
realm TGT to another realm on the referral path.

Table of Contents

1.      Introduction                    2

2.      Security Considerations         2

3.      References                      2

1.   Introduction

The Kerberos TGS and AS protocols, as defined in RFC 1510
[1], require that client software be able to parse principal
names into a realm and an account portion. However, if a
site want to deploy a Kerberos realm infrastructure
separately from its DNS infrastructure, Kerberos must be
able to handle the case where the client software does not
know what realm contains a given service or user principal
name. In addition, the current protocol requires the client
to know the hierarchy of realms by explicitly asking for a
referral to a specific realm rather than letting the KDC
pick the next realm on the referral path.

To rectify these problems, this draft introduces three new
kinds of KDC referrals:

1.   AS ticket referrals, in which the client doesnt know
     which realm contains a user account.
2.   TGS ticket referrals, in which the client doesnt know
     which realm contains a server account.
3.   Cross realm shortcut referrals, in which the KDC
     chooses the next path on a referral chain

2.   Realm Organization Model

This draft assumes that the world of principals is arranged
on multiple levels: the realm, the enterprise, and the
world. A KDC may issue tickets for any principal in its
realm or cross-realm tickets for realms with which it has a
direct trust relationship. A realm has access to a directory
or name service that can resolve any name from within its
enterprise into a realm. In addition, at the top of an
enterprise hierarchy there is a list of trusted enterprises
in the world and information on what names are owned by
those enterprises.

For example, consider the following configuration, where
lines indicate trust relationships:

              MS.COM ---------------------- MIT.EDU
            /       \                     /         \
          /           \                 /            \
     OFFICE.MS.COM  NT.MS.COM      LCS.MIT.EDU ATHENA.MIT.EDU

In this configuration, all users in the MS.COM enterprise
could have a principal name such as [email-masked], with the
same realm portion, and all users in the MIT.EDU enterprise
could have principal names as [email-masked]. In addition,
servers at MS.COM should be able to have DNS host names from
any DNS domain independent of what Kerberos realm their
principal resides in. Finally, users from the MIT.EDU and
MS.COM enterprises should be able to authenticate to
services in the other enterprise.

In this model, all realms in the MS.COM enterprise must end
in MS.COM and all realms in the MIT.EDU enterprise must
end in MIT.EDU. While it is not necessary that all names
in both enterprise end in these postfixes, names that dont
will not be usable from the other enterprise.

3.   Name Types

In order to indicate to the KDC that a name may not be
present in its realm, this protocol introduces a new name
type: KRB_NT_ENTERPRISE_PRINCIPAL = 10, indicating that the
name is an enterprise principal and may not exist in the
target domain. In addition and unlike other principal names,
the entire name is transmitted rather than separating it
into name parts. This allows the whole name to be looked up
as it was entered without any processing on the client.

4.   AS Ticket Referrals

The simplest form of ticket referral is for a user
requesting an AS ticket. In this case, the client machine
will send the AS request to a convenient realm, probably
either the realm of the client machine or the realm portion
of the name. In the case of the name [email-masked], the
client may optimistically choose to send the request to
MS.COM. The client will send both Alice and ms.com in
the principal name field. The KDC will try to lookup the
name in its local account database. If the account is
present, it will return a KDC reply structure with the
appropriate ticket. If the account is not present, it will
try to lookup the entire name ([email-masked]) in the
enterprise directory. If this lookup is unsuccessful, it
will return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. The
client realm field will contain the realm of the root of the
enterprise. If the lookup is successful, it will return an
error KRB_ERR_WRONG_REALM (0x44) and in the error message,
the cname and crealm field will contain the client name and
the true realm of the client.

If the client receives a KDC_ERR_WRONG_REALM error, it will
issue a new AS request to the realm specified by the crealm
field of the error message. In this case, the client should
fail if it receives another referral. This error indicates
an authoritative referral  the account really is in the
domain specified.

If the client received a KDC_ERR_C_PRINCIPAL_UNKNOWN error
and a crealm other than the realm of the original KDC, it
should issue an AS request against that realm. The error
indicates that the client can expect another referral from
this request. Typically, the original realm will refer the
client to the root of the enterprise, which will then refer
the client to the root of another enterprise, which will
then refer the client to the correct realm in the other
enterprise. This may require that enterprise by pre-
configured for trust or that the KDC is able to locate a KDC
in another realm from the DNS portion of a name in order to
do public-key cross-realm trust.

5.   TGS Referrals

The TGS referral mechanism is a bit more complex than the AS
referral mechanism. The primary problem is that the KDC must
return a referral ticket rather than an error message, so it
must include in the TGS response information about what
realm contains the service. This is done by returning
information about the server name in the pre-auth data field
of the KDC reply.
There are two types of referrals: authoritative referrals,
in which the original KDC knows what realm contains a
service,and non-authoritative referrals, in which the KDC
doesnt know issues a referral to a realm that may know
where the service is located.

5.1  Authoritative TGS Referrals

In this case, the KDC has successfully resolved the server
principal name into a Kerberos realm. In this case, the KDC
will return the a server realm as a PA data type. The data
itself is an asn.1 encoded Realm and the following type:

#define KRB5_PADATA_SERVER_REALM   19

The client can use this information to request follow a
chain of cross-realm TGTs until it reaches this realm, and
can then expect to receive a valid service ticket.

5.2  Non-Authoritative TGS referrals

In the case that the KDC cant resolve the name but can
determine that it probably comes from another enterprise
(the realm portion of the name has a different postfix). In
this case, the KDC will return a referral ticket to a realm
closer on the route to the other enterprise, which will
generally be either the parent of the domain or a domain in
the other enterprise. The KDC will also return the name of a
realm in which the client should try to resolve the name in
a pre-auth data field:
#define KRB5_PADATA_SERVER_REFERRAL_REALM    20

5.3  Client Operations

In both the authoritative and non-authoritative referral
case, the client should follow the referral chain until it
hits the KDC for the realm specified by the original TGS
response. At that point it should attempt to get a TGS
ticket to the server principal name. If the original
referral was authoritative, the client can expect this to
return the correct ticket. If the original referral was not
authoritative, the client should expect this request to
return another referral realm and another cross-realm TGT.

Non-authoritative referrals have the possibility of becoming
a goose chase in which each realm refers the client to
another realm without ever terminating. In this case, the
client code will have to decide when to terminate the search
by bounding the number of non-authoritative referrals it
follow. If enterprises directly trust each other, it is
suggested that a client follow no more than two non-
authoritative referrals.

6.   Cross Realm Routing

The current Kerberos protocol requires the client libraries
to explicitly request a cross-realm TGT for each pair of
realms on a referral chain. As a result, the client machines
need to be aware of the trust hierarchy and of any short-cut
trusts (those that arent parent-child trusts). This
requires a lot of configuration on the client. Instead, the
client should be able to request a TGT to the target realm
from each realm on the route. The KDC will determine the
best path for the client and return a cross-realm TGT. The
client software has to be aware that a request for a cross-
realm TGT may return a TGT for a realm different from the
one requested.

7.   Security Considerations

The original Kerberos specification stated that the server
principal name in the KDC reply was the same as the server
name in the request. These protocol changes break that
assumption, so the client may be vulnerable to a denial of
service attack by an attacker that replays replies from
previous requests. It can verify that the request was one
its own by checking the client-address field or authtime
field, though, so the damage is limited.

8.    References

  [1]  J. Kohl, C. Neuman.  The Kerberos Network
     Authentication Service(V5).  Request for Comments 1510.
  [2]  J. Linn.  The Kerberos Version 5 GSS-API Mechanism.
     Request for Comments 1964
  [3] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J.
     Trostle, Public Key Cryptography for Initial
     Authentication in Kerberos, draft-ietf-cat-kerberos-pk-
     init-04.txt.
  [4] M. Swift, User to User Kerberos Authentication using
     GSS-API, draft-ietf-cat-user2user-01.txt.

Authors Address:
Michael Swift
Microsoft
1 Microsoft Way
Redmond, Washington, 98052, U.S.A.
Email: [email-masked]

---

From: [email-masked] (Johan Danielsson)
Date: 27 Jan 1998 17:58:19 +0100

Couldn't this more easily be solved with some `mail address' to
principal conversion database? For hosts such a database is already in
widespread use.

/Johan

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Fri, 6 Feb 1998 22:03:43 -0500

I've finally gotten a chance to read through your proposed draft about
name referrals, and I have some comments...

In section 3, you specify that you use a special name type,
KRB_NT_ENTERPRISE_PRINCIPAL.  I don't see the end for a separate name
type.  If the KDC is one that's playing the "enterprise" game (which is
not defined in the specification, BTW), it knows this.  It doesn't need
a special name type to tell the KDC that.  

The comment in section 3 about "the entire name is transmitted rather
than separated it into name parts" is not clear.  What does this mean?

In general, the Microsoft architecture about names and realms is not
clear, and needs to be defined in the specification.  It sounds like the
realm in a particular principal name is not necessarily specify the
true realm in which that principal resides.  

For example, the text gives the example of a user "[email-masked]", but
the KDC may refer the client to another realm which is truely the realm
to which "[email-masked]", notwithstanding the realm name of "ms.com" in
the principal name.

As another example, the TGS referal mechanism needs a preauthentication
data type to specify the serveral realm which must be used.  Why is this
necessary, given that normally the server name can be inferred from the
form of the ticket-granting-ticket?  (i.e., if you get a TGT with the
service name krbtgt/[email-masked], you know the next realm
you need to go to is LCS.MIT.EDU).

So unless I'm missing something, this document is presuming some very
different assumptions about how principals and realms are named than
what is documented in RFC-1510.  Or, I could be wrong; if that's the
case, could you clarify what's going on the document?  Thanks!!

The other comment I have with the document is the comment in section six
about cross realm routing.  There's a comment made that the client
should trust the Kerberos KDC's to be able to find the trusted path for
doing cross-realm authentication.  However, there's something else going
on here which also deserves mention, as it's much more serious.  

In the classical Krb5/RFC-1510 cross-realm model, the application server
was responsible for determining whether the trust path used was
acceptable.  This was admittedly problematical, since it meant the realm
trust relationships needed to be configured at each application server.
So another change which must be going on is that the KDC's much also be
checking and enforcing acceptable trust paths before honoring
cross-realm TGT's.  This should be explicitly mentioned in the document,
since it is a change from the RFC-1510 model.

						- Ted

---

From: Doug Engert <[email-masked]>
Date: Tue, 17 Feb 1998 08:59:35 -0600 (CST)

> name referrals, and I have some comments...
[...]
 > since it is a change from the RFC-1510 model.

The draft-ietf-cat-kerberos-revisions-0x.txt now has the TRANSITED
POLICY-CHECKED flag which says that the KDC has checked the trust
paths, and the application may rely on the KDC, thus relieving the
application server of having to know the trust paths. It also goes on
to state that intermediate KDCs can check the trust path, and that 
the client can set the DISABLE-TRANSITED-CHECK to encourage them to
not check the transited field. 

I have not read the Microsoft document in question, but I would hope
that it is in line with the Kerberos draft. 

-- 
 
 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444