1
Kerberos Working Group Karthik Jaganathan
2
Internet Draft Larry Zhu
3
Document: draft-ietf-krb-wg-kerberos-referrals-04.txt John Brezak
4
Category: Standards Track Microsoft
6
University of Washington
12
Generating KDC Referrals to locate Kerberos realms
18
This document is an Internet-Draft and is in full conformance with
19
all provisions of Section 10 of RFC-2026 [1].
22
Internet-Drafts are working documents of the Internet Engineering
23
Task Force (IETF), its areas, and its working groups. Note that other
24
groups may also distribute working documents as Internet-Drafts.
25
Internet-Drafts are draft documents valid for a maximum of six months
26
and may be updated, replaced, or obsoleted by other documents at any
27
time. It is inappropriate to use Internet-Drafts as reference
28
material or to cite them other than as "work in progress."
31
The list of current Internet-Drafts can be accessed at
32
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
33
Draft Shadow Directories can be accessed at
34
http://www.ietf.org/shadow.html.
40
The draft documents a method for a Kerberos Key Distribution Center
41
(KDC) to respond to client requests for Kerberos tickets when the
42
client does not have detailed configuration information on the realms
43
of users or services. The KDC will handle requests for principals in
44
other realms by returning either a referral error or a cross-realm
45
TGT to another realm on the referral path. The clients will use this
46
referral information to reach the realm of the target principal and
47
then receive the ticket.
50
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 this
55
document are to be interpreted as described in RFC-2119 [2].
70
KDC Referrals January 2005
74
Current implementations of the Kerberos AS and TGS protocols, as
75
defined in [3], use principal names constructed from a known user or
76
service name and realm. A service name is typically constructed from
77
a name of the service and the DNS host name of the computer that is
78
providing the service. Many existing deployments of Kerberos use a
79
single Kerberos realm where all users and services would be using the
80
same realm. However in an environment where there are multiple
81
trusted Kerberos realms, the client needs to be able to determine
82
what realm a particular user or service is in before making an AS or
83
TGS request. Traditionally this requires client configuration to make
87
When having to deal with multiple trusted realms, users are forced to
88
know what realm they are in before they can obtain a ticket granting
89
ticket (TGT) with an AS request. However, in many cases the user
90
would like to use a more familiar name that is not directly related
91
to the realm of their Kerberos principal name. A good example of this
92
is an RFC-821 style email name [4]. This document describes a
93
mechanism that would allow a user to specify a user principal name
94
that is an alias for the user's Kerberos principal name. In practice
95
this would be the name that the user specifies to obtain a TGT from a
96
Kerberos KDC. The user principal name no longer has a direct
97
relationship with the Kerberos principal or realm. Thus the
98
administrator is able to move the user's principal to other realms
99
without the user having to know that it happened.
102
Once a user has a TGT, they would like to be able to access services
103
in any trusted Kerberos realm. To do this requires that the client be
104
able to determine what realm the target service principal is in
105
before making the TGS request. Current implementations of Kerberos
106
typically have a table that maps DNS host names to corresponding
107
Kerberos realms. In order for this to work on the client, each
108
application canonicalizes the host name of the service, for example
109
by doing a DNS lookup followed by a reverse lookup using the returned
110
IP address. The returned primary host name is then used in the
111
construction of the principal name for the target service. In order
112
for the correct realm to be added for the target host, the mapping
113
table [domain_to_realm] is consulted for the realm corresponding to
114
the DNS host name. The corresponding realm is then used to complete
115
the target service principal name.
118
This traditional mechanism requires that each client have very
119
detailed configuration information about the hosts that are providing
120
services and their corresponding realms. Having client side
121
configuration information can be very costly from an administration
122
point of view - especially if there are many realms and computers in
136
KDC Referrals January 2005
140
There are also cases where specific DNS aliases (local names) have
141
been setup in an organization to refer to a server in another
142
organization (remote server). The server has different DNS names in
143
each organization and each organization has a Kerberos realm that is
144
configured to service DNS names within that organization. Ideally
145
users are able to authenticate to the server in the other
146
organization using the local server name. This would mean that the
147
local realm be able to produce a ticket to the remote server under
148
its name. You could give that remote server an identity in the local
149
realm and then have that remote server maintain a separate secret for
150
each alias it is known as. Alternatively you could arrange to have
151
the local realm issue a referral to the remote realm and notify the
152
requesting client of the server's remote name that should be used in
153
order to request a ticket.
156
This draft proposes a solution for these problems and simplifies
157
administration by minimizing the configuration information needed on
158
each computer using Kerberos. Specifically it describes a mechanism
159
to allow the KDC to handle canonicalization of names, provide for
160
principal aliases for users and services and provide a mechanism for
161
the KDC to determine the trusted realm authentication path by being
162
able to generate referrals to other realms in order to locate
166
To rectify these problems, this draft introduces three new kinds of
170
1. AS ticket referrals, in which the client doesn't know which realm
171
contains a user account.
172
2. TGS ticket referrals, in which the client doesn't know which realm
173
contains a server account.
174
3. Cross realm shortcut referrals, in which the KDC chooses the next
175
path on a referral chain
178
2. Requesting a referral
181
In order to request referrals defined in section 5, 6, and 7, the
182
Kerberos client MUST explicitly request the canonicalize KDC option
183
(bit 15) [3] for the AS-REQ or TGS-REQ. This flag indicates to the
184
KDC that the client is prepared to receive a reply that contains a
185
principal name other than the one requested.
188
KDCOptions ::= KerberosFlags
190
-- other KDCOptions values omitted
193
The client should expect, when sending names with the "canonicalize"
194
KDC option, that names in the KDC's reply MAY be different than the
206
KDC Referrals January 2005
210
name in the request. A referral ticket is a cross realm TGT that is
211
returned when the sname of the ticket is not the sname in the request
215
3. Realm Organization Model
218
This draft assumes that the world of principals is arranged on
219
multiple levels: the realm, the enterprise, and the world. A KDC may
220
issue tickets for any principal in its realm or cross-realm tickets
221
for realms with which it has a direct trust relationship. The KDC
222
also has access to a trusted name service that can resolve any name
223
from within its enterprise into a realm. This trusted name service
224
removes the need to use an un-trusted DNS lookup for name resolution.
227
For example, consider the following configuration, where lines
228
indicate trust relationships:
235
OFFICE.MS.COM NTDEV.MS.COM
239
In this configuration, all users in the MS.COM enterprise could have
240
a principal name such as alice@MS.COM, with the same realm portion.
241
In addition, servers at MS.COM should be able to have DNS host names
242
from any DNS domain independent of what Kerberos realm their
243
principals reside in.
246
4. Client Name Canonicalization
249
A client account may have multiple principal names. More useful,
250
though, is a globally unique name that allows unification of email
251
and security principal names. For example, all users at MS may have a
252
client principal name of the form "joe@MS.COM" even though the
253
principals are contained in multiple realms. This global name is
254
again an alias for the true client principal name, which indicates
255
what realm contains the principal. Thus, accounts "alice" in the
256
realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as
257
"alice@MS.COM" and "bob@MS.COM".
260
This utilizes a new client principal name type, as the AS-REQ message
261
only contains a single realm field, and the realm portion of this
262
name doesn't correspond to any Kerberos realm. Thus, the entire name
263
"alice@MS.COM" is transmitted as a single component in the client
264
name field of the AS-REQ message, with a name type of NT-ENTERPRISE
265
[3]. The KDC will recognize this name type and then transform the
277
KDC Referrals January 2005
281
requested name into the true principal name. The true principal name
282
can be using a name type different from the requested name type.
283
Typically the true principal name will be a NT-PRINCIPAL [3].
286
If the "canonicalize" KDC option is set, then the KDC MAY change the
287
client principal name and type in the AS response and ticket returned
288
from the name type of the client name in the request. For example the
289
AS request may specify a client name of "bob@MS.COM" as an NT-
290
PRINCIPAL with the "canonicalize" KDC option set and the KDC will
291
return with a client name of "104567" as a NT-UID.
297
The simplest form of ticket referral is for a user requesting a
298
ticket using an AS-REQ. In this case, the client machine will send
299
the AS-REQ to a convenient trusted realm, for example the realm of
300
the client machine. In the case of the name alice@MS.COM, the client
301
MAY optimistically choose to send the request to MS.COM. The realm in
302
the AS-REQ is always the name of the realm that the request is for as
306
The KDC will try to lookup the name in its local account database. If
307
the account is present in the realm of the request, it SHOULD return
308
a KDC reply structure with the appropriate ticket.
311
If the account is not present in the realm specified in the request
312
and the "canonicalize" KDC option is set, the KDC will try to lookup
313
the entire name, alice@MS.COM, using a name service. If this lookup
314
is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
315
[3]. If the lookup is successful, it MUST return an error
316
KDC_ERR_WRONG_REALM [3] and in the error message the crealm field
317
will contain either the true realm of the client or another realm
318
that MAY have better information about the client's true realm. The
319
client MUST NOT use a cname returned from a referral.
322
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
323
new AS request with the same client principal name used to generate
324
the first referral to the realm specified by the realm field of the
325
Kerberos error message from the first request. The client SHOULD
326
repeat these steps until it finds the true realm of the client. To
327
avoid infinite referral loops, an implementation should limit the
328
number of referrals. A suggested limit is 5 referrals before giving
329
up. In Microsoft's current implementation through the use of global
330
catalogs any domain in one forest is reachable from any other domain
331
in the same forest or another trusted forest with 3 or less
347
KDC Referrals January 2005
351
The primary problem in service referrals is that the KDC must return
352
a referral ticket rather than an error message as is done in AS
353
ticket referrals. There needs to be a place to include in the TGS-REP
354
information about what realm contains the service. This is done by
355
returning information about the service name in the pre-
356
authentication data field of the KDC reply [3].
359
If the KDC resolves the service principal name into a principal in
360
the realm specified by the service realm name, it will return a
364
If the "canonicalize" flag in the KDC options is not set, the KDC
365
MUST only look up the name as a normal principal name in the
366
specified service realm. If the "canonicalize" flag in the KDC
367
options is set and the KDC doesn't find the principal locally, the
368
KDC MAY return a cross-realm ticket granting ticket to the next hop
369
on the trust path towards a realm that may be able to resolve the
373
When a referral TGT is returned, the KDC MUST return the target realm
374
for the referral TGT as an KDC supplied pre-authentication data
375
element in the response. The pre-authentication data MUST be
376
encrypted using the sub-session key from the authenticator if present
377
or the session key from the ticket. The pre-authentication data
378
contains the referred realm, and if known, the real principal name.
381
PA-SERVER-REFERRAL 25
384
PA-SERVER-REFERRAL-DATA ::= EncryptedData
385
-- ServerReferalData --
388
ServerReferralData ::= SEQUENCE {
389
referred-realm [0] Realm,
390
-- target realm of the referral TGT
391
referred-name [1] PrincipalName OPTIONAL,
392
-- service principal name, MAY differ
393
-- from the server name in the request
398
Clients MUST NOT process referral tickets if the KDC response does
399
not contain the PA-SERVER-REFERRAL.
402
If applicable to the encryption type, the key usage value for the
403
encryption key used by PA-SERVER-REFERRAL is 26 if the session key
404
from the ticket is used or 27 if a sub-session key is used.
407
If the referred-name field is present, the client MUST use that name
419
KDC Referrals January 2005
423
in a subsequent TGS request to the service realm when following the
427
The client will use this information to request a chain of cross-
428
realm ticket granting tickets until it reaches the realm of the
429
service, and can then expect to receive a valid service ticket.
430
However an implementation should limit the number of referrals that
431
it processes to avoid infinite referral loops. A suggested limit is 5
432
referrals before giving up.
435
Here is an example of a client requesting a service ticket for a
436
service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
439
+NC = Canonicalize KDCOption set
440
+PA-REFERRAL = returned PA-SERVER-REFERRAL
441
C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to OFFICE.MS.COM
442
S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
443
containing MS.COM as the referred realm with no referred name
444
C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to MS.COM
445
S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
446
containing NTDEV.MS.COM as the referred realm with no referred
448
C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to NTDEV.MS.COM
449
S: TGS-REP sname=server/foo.ntdev.ms.com@NTDEV.MS.COM
452
7. Cross Realm Routing
455
The current Kerberos protocol requires the client to explicitly
456
request a cross-realm TGT for each pair of realms on a referral
457
chain. As a result, the client need to be aware of the trust
458
hierarchy and of any short-cut trusts (those that aren't parent-
462
Instead, using this referral routing mechanism, The KDC will
463
determine the best path for the client and return a cross-realm TGT
464
as the referral TGT, and the target realm for this TGT in the PA-
465
SERVER-REFERRAL of the KDC reply.
468
If the "canonicalize" KDC option is not set, the KDC MUST NOT return
469
a referral ticket. Clients MUST NOT process referral tickets if the
470
KDC response does not contain the PA-SERVER-REFERRAL.
473
8. Compatibility with earlier implementations of name canonicalization
476
The Microsoft Windows 2000 and Windows 2003 releases included an
477
earlier form of name-canonicalization [5]. Here are the differences:
480
1) The TGS referral data is returned inside of the KDC message as
492
KDC Referrals January 2005
496
"encrypted pre-authentication data".
499
EncKDCRepPart ::= SEQUENCE {
500
key [0] EncryptionKey,
501
last-req [1] LastReq,
503
key-expiration [3] KerberosTime OPTIONAL,
504
flags [4] TicketFlags,
505
authtime [5] KerberosTime,
506
starttime [6] KerberosTime OPTIONAL,
507
endtime [7] KerberosTime,
508
renew-till [8] KerberosTime OPTIONAL,
510
sname [10] PrincipalName,
511
caddr [11] HostAddresses OPTIONAL,
512
encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
516
2) The preauth data type definition in the encrypted preauth data is
520
PA-SVR-REFERRAL-INFO 20
523
PA-SVR-REFERRAL-DATA ::= SEQUENCE {
524
referred-name [1] PrincipalName OPTIONAL,
525
referred-realm [0] Realm
529
9. Security Considerations
532
In the case of TGS requests the client may be vulnerable to a denial
533
of service attack by an attacker that replays replies from previous
534
requests. The client can verify that the request was one of its own
535
by checking the client-address field or authtime field, though, so
536
the damage is limited and detectable.
539
For the AS exchange case, it is important that the logon mechanism
540
not trust a name that has not been used to authenticate the user.
541
For example, the name that the user enters as part of a logon
542
exchange may not be the name that the user authenticates as, given
543
that the KDC_ERR_WRONG_REALM error may have been returned. The
544
relevant Kerberos naming information for logon (if any), is the
545
client name and client realm in the service ticket targeted at the
546
workstation that was obtained using the user's initial TGT.
549
How the client name and client realm is mapped into a local account
550
for logon is a local matter, but the client logon mechanism MUST use
551
additional information such as the client realm and/or authorization
563
KDC Referrals January 2005
567
attributes from the service ticket presented to the workstation by
568
the user, when mapping the logon credentials to a local account on
575
The authors wish to thank Ken Raeburn for his comments and
582
11.1 Normative References
585
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
586
9, RFC 2026, October 1996.
589
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
590
Levels", BCP 14, RFC 2119, March 1997.
593
[3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
594
Network Authentication Service (V5)", draft-ietf-krb-wg-kerberos-
595
clarifications. Work in progress.
598
[4] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
602
11.2 Informative References
605
[5] Trostle, J., Kosinovsky, I., and Swift, M., "Implementation of
606
Crossrealm Referral Handling in the MIT Kerberos Client", In Network
607
and Distributed System Security Symposium, February 2001.
610
12. Author's Addresses
617
Email: karthikj@Microsoft.com
624
Email: lzhu@Microsoft.com
628
University of Washington
640
KDC Referrals January 2005
645
Email: mikesw@cs.washington.edu
652
Email: jbrezak@Microsoft.com
659
Email: jtrostle@cisco.com
705
KDC Referrals January 2005
712
Copyright (C) The Internet Society (2004). This document is subject
713
to the rights, licenses and restrictions contained in BCP 78, and
714
except as set forth therein, the authors retain all their rights.
717
This document and the information contained herein are provided on an
718
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
719
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
720
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
721
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
722
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
723
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
726
Intellectual Property
729
The IETF takes no position regarding the validity or scope of any
730
Intellectual Property Rights or other rights that might be claimed to
731
pertain to the implementation or use of the technology described in
732
this document or the extent to which any license under such rights
733
might or might not be available; nor does it represent that it has
734
made any independent effort to identify any such rights. Information
735
on the procedures with respect to rights in RFC documents can be
736
found in BCP 78 and BCP 79.
739
Copies of IPR disclosures made to the IETF Secretariat and any
740
assurances of licenses to be made available, or the result of an
741
attempt made to obtain a general license or permission for the use of
742
such proprietary rights by implementers or users of this
743
specification can be obtained from the IETF on-line IPR repository at
744
http://www.ietf.org/ipr.
747
The IETF invites any interested party to bring to its attention any
748
copyrights, patents or patent applications, or other proprietary
749
rights that may cover technology that may be required to implement
750
this standard. Please address the information to the IETF at ietf-
b'\\ No newline at end of file'
added
removed
doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt
