1 CAT Working Group M. Swift
2 Internet Draft Microsoft
3 Document: draft-swift-win2k-krb-referrals-00.txt October 1999
4 Category: Informational
7 Generating KDC Referrals to locate Kerberos realms
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026 [1].
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts. Internet-Drafts are draft documents valid for a maximum of
19 six months and may be updated, replaced, or obsoleted by other
20 documents at any time. It is inappropriate to use Internet- Drafts
21 as reference material or to cite them other than as "work in
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
32 The draft documents a new method for a Kerberos Key Distribution
33 Center (KDC) to respond to client requests for tickets as is used in
34 Microsoft's Windows 2000 implementation of Kerberos. The KDC will
35 handle requests for principals in other realms by returning either a
36 referral error or a cross-realm TGT to another realm on the referral
39 2. Conventions used in this document
41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
43 this document are to be interpreted as described in RFC-2119 [2].
47 The Kerberos TGS and AS protocols, as defined in RFC 1510 [3],
48 require that client software be able to parse principal names into a
49 realm and an account portion. However, if a site want to deploy a
50 Kerberos realm infrastructure separately from its DNS
51 infrastructure, Kerberos must be able to handle the case where the
52 client software does not know what realm contains a given service or
53 user principal name. In addition, the current protocol requires the
54 client to know the hierarchy of realms by explicitly asking for a
57 Swift Category - Informational 1
59 KDC Referrals October 1999
62 referral to a specific realm rather than letting the KDC pick the
63 next realm on the referral path.
65 To rectify these problems, this draft introduces three new kinds of
68 1. AS ticket referrals, in which the client doesnÆt know which realm
69 contains a user account.
70 2. TGS ticket referrals, in which the client doesnÆt know which realm
71 contains a server account.
72 3. Cross realm shortcut referrals, in which the KDC chooses the next
73 path on a referral chain
75 4. Realm Organization Model
77 This draft assumes that the world of principals is arranged on
78 multiple levels: the realm, the enterprise, and the world. A KDC may
79 issue tickets for any principal in its realm or cross-realm tickets
80 for realms with which it has a direct trust relationship. The KDC
81 also has access to a trusted directory or name service that can
82 resolve any name from within its enterprise into a realm. This
83 trusted name service removes the need to use an untrusted DNS lookup
86 For example, consider the following configuration, where lines
87 indicate trust relationships:
92 OFFICE.MS.COM NT.MS.COM
94 In this configuration, all users in the MS.COM enterprise could have
95 a principal name such as alice@ms.com, with the same realm portion.
96 In addition, servers at MS.COM should be able to have DNS host names
97 from any DNS domain independent of what Kerberos realm their
102 5.1 Service Principal Names
104 The standard Kerberos model in RFC 1510 [3] gives each Kerberos
105 principal a single name. However, if a service is reachable by
106 several addresses, it may be useful for a principal to have multiple
107 names. Consider a service running on a multi-homed machine. Rather
108 than requiring a separate principal and password for each name it
109 exports, a single account with multiple names could be used.
111 Multiple names are also useful for services in that clients need not
112 perform DNS lookups to resolve a host name into a full DNS address.
113 Instead, the service may have a name for each of its supported host
114 names, including its IP address. Nonetheless, it is still convenient
116 Swift Category - Informational 2
118 KDC Referrals October 1999
121 for the service to not have to be aware of all these names. Thus a
122 new name may be added to DNS for a service by updating DNS and the
123 KDC database without having to notify the service. In addition, it
124 implies that these aliases are globally unique: they do not include
125 a specifier dictating what domain contains the principal. Thus, an
126 alias for a server is of the form "name/name/name" and may be
127 transmitted as any name type.
129 5.2 Client Principal Names
131 Similarly, a client account may also have multiple principal names.
132 More useful, though, is a globally unique name that allows
133 unification of email and security principal names. For example, all
134 users at Microsoft may have a client principal name of the form
135 "joe@MS.COM" even though the principals are contained in multiple
136 realms. This global name is again an alias for the true client
137 principal name, which is indicates what realm contains the
138 principal. Thus, accounts "alice" in the realm ntdev.MS.COM and
139 "bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM".
140 This change requires a new client principal name type, as the AS-REQ
141 message only contains a single realm field, and the realm portion of
142 this name doesn't correspond to any realm security realm. Thus, the
143 entire name "alice@MS.COM" is transmitted in the client name field
144 of the AS-REQ message, with a name type of KRB-NT-ENTERPRISE-
147 #define KRB-NT-ENTERPRISE-PRINCIPAL 10
149 5.3 Name Canonicalization
151 In order to support name aliases, the Kerberos client must
152 explicitly request the name-canonicalization KDC option (bit 12) in
153 the ticket flags for the TGS-REQ. This option is an indicator to the
154 KDC that if it fails to find the name in the local database as a
155 normal principal name, it should try to look the name up as an alias
156 both locally and in a global directory. This flag indicates to the
157 KDC that the client is prepared to receive a reply with a different
158 client or server principal name than the request. Thus, the
159 KDCOptions types is redefined as:
161 KDCOptions ::= BIT STRING {
175 Swift Category - Informational 3
177 KDC Referrals October 1999
180 name-canonicalize(12),
189 The simplest form of ticket referral is for a user requesting a
190 ticket using an AS-REQ. In this case, the client machine will send
191 the AS request to a convenient realm, probably either the realm of
192 the client machine or the realm portion of the client name. In the
193 case of the name Alice@MS.COM, the client may optimistically choose
194 to send the request to MS.COM. The client will send the string
195 "alice@MS.COM" in the client principal name field using the KRB-NT-
196 ENTERPRISE-PRINCIPAL name type. The KDC will try to lookup the name
197 in its local account database. If the account is present, it will
198 return a KDC reply structure with the appropriate ticket. If the
199 account is not present and the name-canonicalize option is
200 requested, it will try to lookup the entire name (Alice@MS.COM) in
201 the global directory. If this lookup is unsuccessful, it will return
202 the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful,
203 it will return an error KDC_ERR_WRONG_REALM (0x44) and in the error
204 message, the cname and crealm field will contain the client name and
205 the true realm of the client. If the KDC contains the account
206 locally, it will return a normal ticket. The client name and realm
207 portions of the ticket and KDC reply message will be the client's
208 true name in the realm, not the globally unique name.
210 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
211 new AS request to the realm specified by the crealm field of the
216 The server referral mechanism is a bit more complex than the client
217 referral mechanism. The primary problem is that the KDC must return
218 a referral ticket rather than an error message, so it must include
219 in the TGS response information about what realm contains the
220 service. This is done by returning information about the server name
221 in the pre-auth data field of the KDC reply.
223 If the KDC resolves the server principal name into a principal in
224 its realm, it may return a normal ticket. If the name-canonicalize
225 bit is not set, then the KDC should only look up the name as a
226 normal principal name. Otherwise, it should search all aliases as
227 well. The server principal name in both the ticket and the KDC reply
228 should be the true server principal name instead of one of the
229 aliases. This prevents the application server from needing to know
230 about all its aliases.
234 Swift Category - Informational 4
236 KDC Referrals October 1999
239 If the KDC doesnÆt find the principal locally but is able to
240 resolved it into a realm from the global directory, then it should
241 return a cross-realm ticket granting ticket to the next hop on the
242 trust path towards that realm. In this case, the KDC will return the
243 server realm as a PA data type. The data itself is an ASN.1 encoded
244 structure containing the server's realm, and if known, true
245 principal name. The preauthentication data type is KRB5-PADATA-
246 SERVER-REFERRAL-INFO.
248 #define KRB5-PADATA-SERVER-REFERRAL-INFO 20
250 KERB-PA-SERV-REFERRAL ::= SEQUENCE {
251 referred-server-name[1] KERB-PRINCIPAL-NAME OPTIONAL,
252 referred-server-realm[0] KERB-REALM
255 The client may use the referred-server-name field to tell if it
256 already has a ticket to the server in its ticket cache.
258 The client can use this information to request a chain of cross-
259 realm ticket granting tickets until it reaches this realm, and can
260 then expect to receive a valid service ticket.
262 8. Cross Realm Routing
264 The current Kerberos protocol requires the client libraries to
265 explicitly request a cross-realm TGT for each pair of realms on a
266 referral chain. As a result, the client machines need to be aware of
267 the trust hierarchy and of any short-cut trusts (those that arenÆt
268 parent-child trusts). This requires a lot of configuration on the
269 client. Instead, the client should be able to request a TGT to the
270 target realm from each realm on the route. The KDC will determine
271 the best path for the client and return a cross-realm TGT. The
272 client software has to be aware that a request for a cross-realm TGT
273 may return a TGT for a realm different from the one requested.
275 9. Security Considerations
277 The original Kerberos specification stated that the server principal
278 name in the KDC reply was the same as the server name in the
279 request. These protocol changes break that assumption, so the client
280 may be vulnerable to a denial of service attack by an attacker that
281 replays replies from previous requests. It can verify that the
282 request was one of its own by checking the client-address field or
283 authtime field, though, so the damage is limited.
288 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
289 9, RFC 2026, October 1996.
293 Swift Category - Informational 5
295 KDC Referrals October 1999
299 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
300 Levels", BCP 14, RFC 2119, March 1997
302 3 Kohl, J., Neuman, C., "The Kerberos Network Authentication
303 Service (V5)", RFC 1510, September 1993
306 10. Author's Addresses
312 Email: mikesw@microsoft.com
352 Swift Category - Informational 6
354 KDC Referrals October 1999
358 Full Copyright Statement
360 Copyright (C) The Internet Society (1999). All Rights Reserved.
362 This document and translations of it may be copied and furnished to
363 others, and derivative works that comment on or otherwise explain it
364 or assist in its implementation may be prepared, copied, published
365 and distributed, in whole or in part, without restriction of any
366 kind, provided that the above copyright notice and this paragraph
367 are included on all such copies and derivative works. However, this
368 document itself may not be modified in any way, such as by removing
369 the copyright notice or references to the Internet Society or other
370 Internet organizations, except as needed for the purpose of
371 developing Internet standards in which case the procedures for
372 copyrights defined in the Internet Standards process must be
373 followed, or as required to translate it into languages other than
376 The limited permissions granted above are perpetual and will not be
377 revoked by the Internet Society or its successors or assigns.
379 This document and the information contained herein is provided on an
380 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
381 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
382 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
383 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
384 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
411 Swift Category - Informational 7