4
Kerberos Working Group Karthik
6
Internet Draft Larry Zhu
7
Document: draft-ietf-krb-wg-kerberos-referrals-03.txt John Brezak
8
Category: Standards Track Microsoft
18
Generating KDC Referrals to locate Kerberos realms
23
This document is an Internet-Draft and is in full conformance with
24
all provisions of Section 10 of RFC2026 [1].
26
Internet-Drafts are working documents of the Internet Engineering
27
Task Force (IETF), its areas, and its working groups. Note that
28
other groups may also distribute working documents as Internet-
29
Drafts. Internet-Drafts are draft documents valid for a maximum of
30
six months and may be updated, replaced, or obsoleted by other
31
documents at any time. It is inappropriate to use Internet- Drafts
32
as reference material or to cite them other than as "work in
35
The list of current Internet-Drafts can be accessed at
36
http://www.ietf.org/ietf/1id-abstracts.txt
37
The list of Internet-Draft Shadow Directories can be accessed at
38
http://www.ietf.org/shadow.html.
42
The draft documents a new method for a Kerberos Key Distribution
43
Center (KDC) to respond to client requests for kerberos tickets when
44
the client does not have detailed configuration information on the
45
realms of users or services. The KDC will handle requests for
46
principals in other realms by returning either a referral error or a
47
cross-realm TGT to another realm on the referral path. The clients
48
will use this referral information to reach the realm of the target
49
principal and then receive the ticket.
51
2. Conventions used in this document
53
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
54
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
55
this document are to be interpreted as described in RFC-2119 [2].
59
Jaganathan Category - Standards Track 1
60
KDC Referrals August 2004
65
Current implementations of the Kerberos AS and TGS protocols, as
66
defined in [3], use principal names constructed from a known user or
67
service name and realm. A service name is typically constructed from
68
a name of the service and the DNS host name of the computer that is
69
providing the service. Many existing deployments of Kerberos use a
70
single Kerberos realm where all users and services would be using
71
the same realm. However in an environment where there are multiple
72
trusted Kerberos realms, the client needs to be able to determine
73
what realm a particular user or service is in before making an AS or
74
TGS request. Traditionally this requires client configuration to
77
When having to deal with multiple trusted realms, users are forced
78
to know what realm they are in before they can obtain a ticket
79
granting ticket (TGT) with an AS request. However, in many cases the
80
user would like to use a more familiar name that is not directly
81
related to the realm of their Kerberos principal name. A good
82
example of this is an RFC-822 style email name. This document
83
describes a mechanism that would allow a user to specify a user
84
principal name that is an alias for the user's Kerberos principal
85
name. In practice this would be the name that the user specifies to
86
obtain a TGT from a Kerberos KDC. The user principal name no longer
87
has a direct relationship with the Kerberos principal or realm. Thus
88
the administrator is able to move the user's principal to other
89
realms without the user having to know that it happened.
91
Once a user has a TGT, they would like to be able to access services
92
in any trusted Kerberos realm. To do this requires that the client
93
be able to determine what realm the target service's host is in
94
before making the TGS request. Current implementations of Kerberos
95
typically have a table that maps DNS host names to corresponding
96
Kerberos realms. In order for this to work on the client, each
97
application canonicalizes the host name of the service by doing a
98
DNS lookup followed by a reverse lookup using the returned IP
99
address. The returned primary host name is then used in the
100
construction of the principal name for the target service. In order
101
for the correct realm to be added for the target host, the mapping
102
table [domain_to_realm] is consulted for the realm corresponding to
103
the DNS host name. The corresponding realm is then used to complete
104
the target service principal name.
106
This traditional mechanism requires that each client have very
107
detailed configuration information about the hosts that are
108
providing services and their corresponding realms. Having client
109
side configuration information can be very costly from an
110
administration point of view - especially if there are many realms
111
and computers in the environment.
113
There are also cases where specific DNS aliases (local names) have
114
been setup in an organization to refer to a server in another
115
organization (remote server). The server has different DNS names in
117
Jaganathan Category - Standards Track 2
118
KDC Referrals August 2004
121
each organization and each organization has a Kerberos realm that is
122
configured to service DNS names within that organization. Ideally
123
users are able to authenticate to the server in the other
124
organization using the local server name. This would mean that the
125
local realm be able to produce a ticket to the remote server under
126
its name. You could give that remote server an identity in the local
127
realm and then have that remote server maintain a separate secret
128
for each alias it is known as. Alternatively you could arrange to
129
have the local realm issue a referral to the remote realm and notify
130
the requesting client of the server's remote name that should be
131
used in order to request a ticket.
133
This draft proposes a solution for these problems and simplifies
134
administration by minimizing the configuration information needed on
135
each computer using Kerberos. Specifically it describes a mechanism
136
to allow the KDC to handle Canonicalization of names, provide for
137
principal aliases for users and services and provide a mechanism for
138
the KDC to determine the trusted realm authentication path by being
139
able to generate referrals to other realms in order to locate
142
To rectify these problems, this draft introduces three new kinds of
145
1. AS ticket referrals, in which the client doesn't know which realm
146
contains a user account.
147
2. TGS ticket referrals, in which the client doesn't know which
148
realm contains a server account.
149
3. Cross realm shortcut referrals, in which the KDC chooses the next
150
path on a referral chain
152
4. Realm Organization Model
154
This draft assumes that the world of principals is arranged on
155
multiple levels: the realm, the enterprise, and the world. A KDC may
156
issue tickets for any principal in its realm or cross-realm tickets
157
for realms with which it has a direct trust relationship. The KDC
158
also has access to a trusted name service that can resolve any name
159
from within its enterprise into a realm. This trusted name service
160
removes the need to use an untrusted DNS lookup for name resolution.
162
For example, consider the following configuration, where lines
163
indicate trust relationships:
168
OFFICE.MS.COM NT.MS.COM
170
In this configuration, all users in the MS.COM enterprise could have
171
a principal name such as alice@MS.COM, with the same realm portion.
172
In addition, servers at MS.COM should be able to have DNS host names
175
Jaganathan Category - Standards Track 3
176
KDC Referrals August 2004
179
from any DNS domain independent of what Kerberos realm their
180
principal resides in.
182
5. Client Name Canonicalization
184
A client account may have multiple principal names. More useful,
185
though, is a globally unique name that allows unification of email
186
and security principal names. For example, all users at MS may have
187
a client principal name of the form "joe@MS.COM" even though the
188
principals are contained in multiple realms. This global name is
189
again an alias for the true client principal name, which indicates
190
what realm contains the principal. Thus, accounts "alice" in the
191
realm NT.MS.COM and "bob" in OFFICE.MS.COM may logon as
192
"alice@MS.COM" and "bob@MS.COM".
194
This utilizes a new client principal name type, as the AS-REQ
195
message only contains a single realm field, and the realm portion of
196
this name doesn't correspond to any Kerberos realm. Thus, the entire
197
name "alice@MS.COM" is transmitted in the client name field of the
198
AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL.
200
KRB-NT-ENTERPRISE-PRINCIPAL 10
202
The KDC will recognize this name type and then transform the
203
requested name into the true principal name. The true principal name
204
can be using a name type different from the requested name type.
205
Typically the returned principal name will be a KRB-NT-PRINCIPAL.
206
The returned name will be the same in the AS response and in the
207
ticket. The KDC will always return a different name type than KRB-
208
NT-ENTERPRISE-PRINCIPAL. This is regardless of the presence of the
209
"canonicalize" KDC option.
211
If the "canonicalize" KDC option is set, then the KDC MAY change the
212
client principal name and type in the AS response and ticket
213
regardless of the name type of the client name in the request. For
214
example the AS request may specify a client name of "fred@MS.COM" as
215
an KRB-NT-PRINCIPAL with the "canonicalize" KDC option set and the
216
KDC will return with a client name of "104567" as a KRB-NT-UID.
218
6. Requesting a referral
220
In order to request referrals, the Kerberos client must explicitly
221
request the canonicalize KDC option (bit 15) in the KDC options for
222
the TGS-REQ. This flag indicates to the KDC that the client is
223
prepared to receive a reply that contains a principal name other
224
than the one requested. Thus, the KDCOptions types is redefined as:
226
KDCOptions ::= BIT STRING {
233
Jaganathan Category - Standards Track 4
234
KDC Referrals August 2004
251
The client should expect, when sending names with the "canonicalize"
252
KDC option, that names in the KDC's reply will be different than the
257
The simplest form of ticket referral is for a user requesting a
258
ticket using an AS-REQ. In this case, the client machine will send
259
the AS request to a convenient trusted realm, either the realm of
260
the client machine or the realm of the client name. In the case of
261
the name Alice@MS.COM, the client may optimistically choose to send
262
the request to MS.COM. The realm in the AS request is always the
263
name of the realm that the request is for as specified in [3].
265
The client will send the string "alice@MS.COM" in the client
266
principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type
267
with the crealm set to MS.COM. The KDC will try to lookup the name
268
in its local account database. If the account is present in the
269
realm of the request, it MUST return a KDC reply structure with the
272
If the account is not present in the realm specified in the request
273
and the "canonicalize" KDC option is set, the KDC will try to lookup
274
the entire name, Alice@MS.COM, using a name service. If this lookup
275
is unsuccessful, it MUST return the error
276
KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, it MUST
277
return an error KDC_ERR_WRONG_REALM (0x44) and in the error message
278
the crealm field will contain the the true realm of the client or
279
another realm that has better information about the client's true
280
realm. The client MUST NOT use a cname returned from a referral.
282
If the KDC contains the account locally and "canonicalize" KDC
283
option is not set, it MUST return a normal ticket. The client name
284
and realm portions of the ticket and KDC reply message MUST be the
285
client's true name in the realm, not the globally unique name.
287
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
288
new AS request with the same client principal name used to generate
289
the first referral to the realm specified by the realm field of the
291
Jaganathan Category - Standards Track 5
292
KDC Referrals August 2004
295
kerberos error message from the first request. This request MUST
296
produce a valid AS response with a ticket for the canonical user
299
An implementation should limit the number of referrals that it
300
processes to avoid infinite referral loops. A suggested limit is 5
301
referrals before giving up. In Microsoft�s implementation the
302
default limit is 3 since through the use of the global catalog any
303
domain in one forest is reachable from any other domain in another
304
trusting forest with 3 or less referrals.
306
6.2 Service Referrals
308
The primary problem is that the KDC must return a referral ticket
309
rather than an error message as is done in AS request referrals.
310
There needs to be a place to include in the TGS response information
311
about what realm contains the service. This is done by returning
312
information about the service name in the pre-auth data field of the
315
If the KDC resolves the service principal name into a principal in
316
the realm specified by the service realm name, it will return a
317
normal ticket. When using canonicalization, the client can omit the
318
service realm name. If it is supplied, it is used as a hint by the
319
KDC, but the service principal lookup is not constrained to locating
320
the service principal name in that specified realm. If the
321
"canonicalize" flag in the KDC options is not set, then the KDC MUST
322
only look up the name as a normal principal name in the specified
325
If the "canonicalize" flag in the KDC options is set and the KDC
326
doesn't find the principal locally, the KDC can return a cross-realm
327
ticket granting ticket to the next hop on the trust path towards a
328
realm that may be able to resolve the principal name.
330
If the KDC can determine the service principal's realm, it SHOULD
331
return the service realm as KDC supplied pre-authentication data
332
element. The preauth data MUST be encrypted using the sub-session
333
key from the authenticator if present or the session key from the
336
The data itself is an ASN.1 encoded structure containing the
337
server's realm, and if known, the real principal name.
339
PA-SERVER-REFERRAL-INFO 25
341
PA-SERVER-REFERRAL :: = KERB-ENCRYPTED-DATA
342
-- PA-SERVER-REFERRAL-DATA
344
PA-SERVER-REFERRAL-DATA ::= SEQUENCE {
345
referred-server-realm[0] KERB-REALM
346
referred-name[1] PrincipalName OPTIONAL
349
Jaganathan Category - Standards Track 6
350
KDC Referrals August 2004
356
If applicable to the encryption type, the key derivation value will
357
for the PA-SERVER-REFERRAL is 22.
359
If the referred-name field is present, the client MUST use that name
360
in a subsequent TGS request to the service realm when following the
363
The client will use this information to request a chain of cross-
364
realm ticket granting tickets until it reaches the realm of the
365
service, and can then expect to receive a valid service ticket.
367
However an implementation should limit the number of referrals that
368
it processes to avoid infinite referral loops. A suggested limit is
369
5 referrals before giving up.
371
This is an example of a client requesting a service ticket for a
372
service in realm NT.MS.COM where the client is in OFFICE.MS.COM.
374
+NC = Canonicalize KDCOption set
375
+PA-REFERRAL = returned PA-SERVER-REFERRAL-INFO
377
C: TGS-REQ sname=server/foo.nt.ms.com srealm=NULL +NC to
379
S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
381
C: TGS-REQ sname=krbtgt/NT.MS.COM@MS.COM +NC to MS.COM
382
S: TGS-REP sname=krbtgt/NT.MS.COM@MS.COM
383
C: TGS-REQ sname=server/foo.nt.ms.com srealm=NT.MS.COM +NC to
385
S: TGS-REP sname=server/foo.nt.ms.com@NT.MS.COM
387
Notice that the client only specifies the service name in the
388
initial and final TGS request.
390
7. Cross Realm Routing
392
The current Kerberos protocol requires the client to explicitly
393
request a cross-realm TGT for each pair of realms on a referral
394
chain. As a result, the client need to be aware of the trust
395
hierarchy and of any short-cut trusts (those that aren't parent-
396
child trusts). Instead, the client should be able to request a TGT
397
to the target realm from each realm on the route. The KDC will
398
determine the best path for the client and return a cross-realm TGT.
399
The client has to be aware that a request for a cross-realm TGT may
400
return a TGT for a realm different from the one requested.
402
For compatibility, the client MUST use the "canonicalize" KDC option
403
if it is able to use cross-realm routing from the KDC.
405
8. Compatibility with earlier implementations of name canonicalization
407
Jaganathan Category - Standards Track 7
408
KDC Referrals August 2004
412
The Microsoft Windows 2000 release included an earlier form of name-
413
canonicalization [4]. It has these differences:
415
1) The TGS referral data was returned inside of the KDC message as
416
"encrypted pre auth data".
418
KERB-ENCRYPTED-KDC-REPLY ::= SEQUENCE {
419
session-key[0] KERB-ENCRYPTION-KEY,
420
last-request[1] PKERB-LAST-REQUEST,
422
key-expiration[3] KERB-TIME OPTIONAL,
423
flags[4] KERB-TICKET-FLAGS,
424
authtime[5] KERB-TIME,
425
starttime[6] KERB-TIME OPTIONAL,
426
endtime[7] KERB-TIME,
427
renew-until[8] KERB-TIME OPTIONAL,
428
server-realm[9] KERB-REALM,
429
server-name[10] KERB-PRINCIPAL-NAME,
430
client-addresses[11] PKERB-HOST-ADDRESSES
432
encrypted-pa-data[12] SEQUENCE OF KERB-PA-DATA
436
2) The preauth data type definition in the encrypted preauth data is
439
PA-SVR-REFERRAL-INFO 20
441
PA-SVR-REFERRAL-DATA ::= SEQUENCE {
442
referred-server-name[1] PrincipalName OPTIONAL
443
referred-server-realm[0] KERB-REALM
447
9. Security Considerations
449
In the case of TGS requests the client may be vulnerable to a denial
450
of service attack by an attacker that replays replies from previous
451
requests. The client can verify that the request was one of its own
452
by checking the client-address field or authtime field, though, so
453
the damage is limited and detectable. Clients MUST NOT process cross
454
realm referral TGTs if the KDC reply does not include the encrypted
455
PA-SERVER-REFERRAL-INFO.
457
For the AS exchange case, it is important that the logon mechanism
458
not trust a name that has not been used to authenticate the user.
459
For example, the name that the user enters as part of a logon
460
exchange may not be the name that the user authenticates as, given
461
that the KDC_ERR_WRONG_REALM error may have been returned. The
462
relevant Kerberos naming information for logon (if any), is the
465
Jaganathan Category - Standards Track 8
466
KDC Referrals August 2004
469
client name and client realm in the service ticket targeted at the
470
workstation that was obtained using the user's initial TGT.
472
How the client name and client realm is mapped into a local account
473
for logon is a local matter, but the client logon mechanism MUST use
474
additional information such as the client realm and/or authorization
475
attributes from the service ticket presented to the workstation by
476
the user, when mapping the logon credentials to a local account on
480
The authors wish to thank Ken Raeburn for his comments and
483
11.1 Normative References
486
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
487
9, RFC 2026, October 1996.
489
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
490
Levels", BCP 14, RFC 2119, March 1997
492
3 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
493
Raeburn, "The Kerberos Network Authentication Service (V5)",
494
draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
495
2002. Work in progress.
497
11.2 Informative References
500
4 J. Trostle, I. Kosinovsky, and M. Swift,"Implementation of
501
Crossrealm Referral Handling in the MIT Kerberos Client", In
502
Network and Distributed System Security Symposium, February 2001.
505
12. Author's Addresses
511
Email: karthikj@Microsoft.com
517
Email: lzhu@Microsoft.com
520
University of Washington
522
Jaganathan Category - Standards Track 9
523
KDC Referrals August 2004
527
Email: mikesw@cs.washington.edu
533
Email: jbrezak@Microsoft.com
539
Email: jtrostle@cisco.com
580
Jaganathan Category - Standards Track 10
581
KDC Referrals August 2004
584
Full Copyright Statement
586
Copyright (C) The Internet Society (1999). All Rights Reserved.
588
This document and translations of it may be copied and furnished to
589
others, and derivative works that comment on or otherwise explain it
590
or assist in its implementation may be prepared, copied, published
591
and distributed, in whole or in part, without restriction of any
592
kind, provided that the above copyright notice and this paragraph
593
are included on all such copies and derivative works. However, this
594
document itself may not be modified in any way, such as by removing
595
the copyright notice or references to the Internet Society or other
596
Internet organizations, except as needed for the purpose of
597
developing Internet standards in which case the procedures for
598
copyrights defined in the Internet Standards process must be
599
followed, or as required to translate it into languages other than
602
The limited permissions granted above are perpetual and will not be
603
revoked by the Internet Society or its successors or assigns.
605
This document and the information contained herein is provided on an
606
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
607
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
608
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
609
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
610
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
638
Jaganathan Category - Standards Track 11
added
removed
doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-03.txt
