3
Kerberos Working Group M. Swift
4
Internet Draft University of WA
5
Document: draft-ietf-krb-wg-kerberos-referrals-00.txt J. Brezak
6
Category: Standards Track Microsoft
14
Generating KDC Referrals to locate Kerberos realms
19
This document is an Internet-Draft and is in full conformance with
20
all provisions of Section 10 of RFC2026 [1].
22
Internet-Drafts are working documents of the Internet Engineering
23
Task Force (IETF), its areas, and its working groups. Note that
24
other groups may also distribute working documents as Internet-
25
Drafts. Internet-Drafts are draft documents valid for a maximum of
26
six months and may be updated, replaced, or obsoleted by other
27
documents at any time. It is inappropriate to use Internet- Drafts
28
as reference material or to cite them other than as "work in
31
The list of current Internet-Drafts can be accessed at
32
http://www.ietf.org/ietf/1id-abstracts.txt
33
The list of Internet-Draft Shadow Directories can be accessed at
34
http://www.ietf.org/shadow.html.
38
The draft documents a new method for a Kerberos Key Distribution
39
Center (KDC) to respond to client requests for kerberos tickets when
40
the client does not have detailed configuration information on the
41
realms of users or services. The KDC will handle requests for
42
principals in other realms by returning either a referral error or a
43
cross-realm TGT to another realm on the referral path. The clients
44
will use this referral information to reach the realm of the target
45
principal and then receive the ticket.
47
2. Conventions used in this document
49
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
50
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
51
this document are to be interpreted as described in RFC-2119 [2].
58
Swift Category - Standards Track 1
67
KDC Referrals February 2001
70
Current implementations of the Kerberos AS and TGS protocols, as
71
defined in RFC 1510 [3], use principal names constructed from a
72
known user or service name and realm. A service name is typically
73
constructed from a name of the service and the DNS host name of the
74
computer that is providing the service. Many existing deployments of
75
Kerberos use a single Kerberos realm where all users and services
76
would be using the same realm. However in an environment where there
77
are multiple trusted Kerberos realms, the client needs to be able to
78
determine what realm a particular user or service is in before
79
making an AS or TGS request. Traditionally this requires client
80
configuration to make this possible.
82
When having to deal with multiple trusted realms, users are forced
83
to know what realm they are in before they can obtain a ticket
84
granting ticket (TGT) with an AS request. However, in many cases the
85
user would like to use a more familiar name that is not directly
86
related to the realm of their Kerberos principal name. A good
87
example of this is an RFC-822 style email name. This document
88
describes a mechanism that would allow a user to specify a user
89
principal name that is an alias for the user's Kerberos principal
90
name. In practice this would be the name that the user specifies to
91
obtain a TGT from a Kerberos KDC. The user principal name no longer
92
has a direct relationship with the Kerberos principal or realm. Thus
93
the administrator is able to move the user's principal to other
94
realms without the user having to know that it happened.
96
Once a user has a TGT, they would like to be able to access services
97
in any trusted Kerberos realm. To do this requires that the client
98
be able to determine what realm the target service's host is in
99
before making the TGS request. Current implementations of Kerberos
100
typically have a table that maps DNS host names to corresponding
101
Kerberos realms. In order for this to work on the client, each
102
application canonicalizes the host name of the service by doing a
103
DNS lookup followed by a reverse lookup using the returned IP
104
address. The returned primary host name is then used in the
105
construction of the principal name for the target service. In order
106
for the correct realm to be added for the target host, the mapping
107
table [domain_to_realm] is consulted for the realm corresponding to
108
the DNS host name. The corresponding realm is then used to complete
109
the target service principal name.
111
This traditional mechanism requires that each client have very
112
detailed configuration information about the hosts that are
113
providing services and their corresponding realms. Having client
114
side configuration information can be very costly from an
115
administration point of view - especially if there are many realms
116
and computers in the environment.
118
Current implementations of Kerberos also have difficulty with
119
services on hosts that can have multiple host names (multi-homed
120
hosts). Traditionally, each host name would need to have a distinct
121
principal and a corresponding key. An extreme example of this would
122
be a Web server with multiple host names for each domain that it is
124
Swift Category - Standards Track 2
133
KDC Referrals February 2001
136
supporting. Principal aliases allow multi-homed hosts to have a
137
single Kerberos principal (with a single key) that can have
138
identities for each distinct host name. This mechanism allows the
139
Kerberos client to request a service ticket for the distinct
140
hostname and allows the KDC to return a ticket for the single
141
principal that the host is using. This canonical principal name
142
allows the host to only have to manage a single key for all of the
143
identities that it supports. In addition, the client only needs to
144
know the realm of the canonical service name, not all of the
147
This draft proposes a solution for these problems and simplifies
148
administration by minimizing the configuration information needed on
149
each computer using Kerberos. Specifically it describes a mechanism
150
to allow the KDC to handle Canonicalization of names, provide for
151
principal aliases for users and services and provide a mechanism for
152
the KDC to determine the trusted realm authentication path by being
153
able to generate referrals to other realms in order to locate
156
To rectify these problems, this draft introduces three new kinds of
159
1. AS ticket referrals, in which the client doesn't know which realm
160
contains a user account.
161
2. TGS ticket referrals, in which the client doesn't know which
162
realm contains a server account.
163
3. Cross realm shortcut referrals, in which the KDC chooses the next
164
path on a referral chain
166
4. Realm Organization Model
168
This draft assumes that the world of principals is arranged on
169
multiple levels: the realm, the enterprise, and the world. A KDC may
170
issue tickets for any principal in its realm or cross-realm tickets
171
for realms with which it has a direct trust relationship. The KDC
172
also has access to a trusted name service that can resolve any name
173
from within its enterprise into a realm. This trusted name service
174
removes the need to use an untrusted DNS lookup for name resolution.
176
For example, consider the following configuration, where lines
177
indicate trust relationships:
182
OFFICE.MS.COM NT.MS.COM
184
In this configuration, all users in the MS.COM enterprise could have
185
a principal name such as alice@MS.COM, with the same realm portion.
186
In addition, servers at MS.COM should be able to have DNS host names
187
from any DNS domain independent of what Kerberos realm their
188
principal resides in.
190
Swift Category - Standards Track 3
199
KDC Referrals February 2001
205
5.1 Service Principal Names
207
The standard Kerberos model in RFC 1510 [3] gives each Kerberos
208
principal a single name. However, if a service is reachable by
209
several addresses, it is useful for a principal to have multiple
210
names. Consider a service running on a multi-homed machine. Rather
211
than requiring a separate principal and password for each name it
212
exports, a single account with multiple names could be used.
214
Multiple names are also useful for services in that clients need not
215
perform DNS lookups to resolve a host name into a full DNS address.
216
Instead, the service may have a name for each of its supported host
217
names, including its IP address. Nonetheless, it is still convenient
218
for the service to not have to be aware of all these names. Thus a
219
new name may be added to DNS for a service by updating DNS and the
220
KDC database without having to notify the service. In addition, it
221
implies that these aliases are globally unique: they do not include
222
a specifier dictating what realm contains the principal. Thus, an
223
alias for a server is of the form "class/instance/name" and may be
224
transmitted as any name type.
226
5.2 Client Principal Names
228
Similarly, a client account may also have multiple principal names.
229
More useful, though, is a globally unique name that allows
230
unification of email and security principal names. For example, all
231
users at MS may have a client principal name of the form
232
"joe@MS.COM" even though the principals are contained in multiple
233
realms. This global name is again an alias for the true client
234
principal name, which is indicates what realm contains the
235
principal. Thus, accounts "alice" in the realm ntdev.MS.COM and
236
"bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM".
237
This requires a new client principal name type, as the AS-REQ
238
message only contains a single realm field, and the realm portion of
239
this name doesn't correspond to any Kerberos realm. Thus, the entire
240
name "alice@MS.COM" is transmitted in the client name field of the
241
AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL.
243
KRB-NT-ENTERPRISE-PRINCIPAL 10
245
5.3 Name Canonicalization
247
In order to support name aliases, the Kerberos client must
248
explicitly request the name-canonicalization KDC option (bit 15) in
249
the ticket flags for the TGS-REQ. This flag indicates to the KDC
250
that the client is prepared to receive a reply with a different
251
client or server principal name than the request. Thus, the
252
KDCOptions types is redefined as:
254
KDCOptions ::= BIT STRING {
256
Swift Category - Standards Track 4
265
KDC Referrals February 2001
280
name-canonicalize(15),
289
The simplest form of ticket referral is for a user requesting a
290
ticket using an AS-REQ. In this case, the client machine will send
291
the AS request to a convenient trusted realm, either the realm of
292
the client machine or the realm of the client name. In the case of
293
the name Alice@MS.COM, the client may optimistically choose to send
294
the request to MS.COM.
296
The client will send the string "alice@MS.COM" in the client
297
principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type
298
with the crealm set to MS.COM. The KDC will try to lookup the name
299
in its local account database. If the account is present in the
300
crealm of the request, it MUST return a KDC reply structure with the
301
appropriate ticket. If the account is not present in the crealm
302
specified in the request and the name-canonicalize flag in the
303
KDCoptions is set, the KDC will try to lookup the entire name,
304
Alice@MS.COM, using a name service. If this lookup is unsuccessful,
305
it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup
306
is successful, it MUST return an error KDC_ERR_WRONG_REALM (0x44)
307
and in the error message the cname and crealm field MUST contain the
308
client name and the true realm of the client. If the KDC contains
309
the account locally, it MUST return a normal ticket. The client name
310
and realm portions of the ticket and KDC reply message MUST be the
311
client's true name in the realm, not the globally unique name.
313
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
314
new AS request with the same client principal name used to generate
315
the first referral to the realm specified by the crealm field of the
316
kerberos error message from the first request. This request MUST
317
produce a valid AS response with a ticket for the canonical user
318
name. The ticket MUST also include the ticket extension containing
319
the TE-REFERRAL-DATA with the referred-names set to the name from
322
Swift Category - Standards Track 5
331
KDC Referrals February 2001
334
the AS request. Any other error or referral will terminate the
335
request and result in a failed AS request.
339
The server referral mechanism is a bit more complex than the client
340
referral mechanism. The primary problem is that the KDC must return
341
a referral ticket rather than an error message, so it will include
342
in the TGS response information about what realm contains the
343
service. This is done by returning information about the server name
344
in the pre-auth data field of the KDC reply.
346
If the KDC resolves the server principal name into a principal in
347
its realm, it may return a normal ticket. If the name-canonicalize
348
flag in the KDCoptions is not set, then the KDC MUST only look up
349
the name as a normal principal name. Otherwise, it MUST search all
350
aliases as well. The server principal name in both the ticket and
351
the KDC reply MUST be the true server principal name instead of one
352
of the aliases. This frees the application server from needing to
353
know about all its aliases.
355
If the name-canonicalize flag in the KDCoptions is set and the KDC
356
doesn't find the principal locally, the KDC can return a cross-realm
357
ticket granting ticket to the next hop on the trust path towards a
358
realm that may be able to resolve the principal name.
360
If the KDC can determine the service principal's realm, it can
361
return the server realm as ticket extension data. The ticket
362
extension MUST be encrypted using the session key from the ticket,
363
and the same etype as is used to protect the TGS reply body.
365
The data itself is an ASN.1 encoded structure containing the
366
server's realm, and if known, canonical principal name and alias
367
names. The first name in the sequence is the canonical principal
372
TE-REFERRAL-DATA ::= SEQUENCE {
373
referred-server-realm[0] KERB-REALM
374
referred-names[1] SEQUENCE OF
375
PrincipalNames OPTIONAL
379
The client can use this information to request a chain of cross-
380
realm ticket granting tickets until it reaches the realm of the
381
server, and can then expect to receive a valid service ticket.
383
In order to facilitate cross-realm interoperability, a client SHOULD
384
NOT send short names in TGS requests to the KDC. A short name is
385
defined as a Kerberos name that includes a DNS name that is not
386
fully qualified. The client MAY use forward DNS lookups to obtain
388
Swift Category - Standards Track 6
397
KDC Referrals February 2001
400
the long name that corresponds to the user entered short name (the
401
short name will be a prefix of the corresponding long name).
403
The client may use the referred-names field to tell if it already
404
has a ticket to the server in its ticket cache.
406
The client can use this information to request a chain of cross-
407
realm ticket granting tickets until it reaches the realm of the
408
server, and can then expect to receive a valid service ticket.
409
However an implementation should limit the number of referrals that
410
it processes to avoid infinite referral loops. A suggested limit is
411
5 referrals before giving up.
413
8. Cross Realm Routing
415
The current Kerberos protocol requires the client to explicitly
416
request a cross-realm TGT for each pair of realms on a referral
417
chain. As a result, the client machines need to be aware of the
418
trust hierarchy and of any short-cut trusts (those that aren't
419
parent-child trusts). This requires more configurations on the
420
client. Instead, the client should be able to request a TGT to the
421
target realm from each realm on the route. The KDC will determine
422
the best path for the client and return a cross-realm TGT. The
423
client has to be aware that a request for a cross-realm TGT may
424
return a TGT for a realm different from the one requested.
426
9. Security Considerations
428
The original Kerberos specification stated that the server principal
429
name in the KDC reply was the same as the server name in the
430
request. These protocol changes break that assumption, so the client
431
may be vulnerable to a denial of service attack by an attacker that
432
replays replies from previous requests. It can verify that the
433
request was one of its own by checking the client-address field or
434
authtime field, though, so the damage is limited and detectable.
436
For the AS exchange case, it is important that the logon mechanism
437
not trust a name that has not been used to authenticate the user.
438
For example, the name that the user enters as part of a logon
439
exchange may not be the name that the user authenticates as, given
440
that the KDC_ERR_WRONG_REALM error may have been returned. The
441
relevant Kerberos naming information for logon (if any), is the
442
client name and client realm in the service ticket targeted at the
443
workstation that was obtained using the user's initial TGT.
445
How the client name and client realm is mapped into a local account
446
for logon is a local matter, but the client logon mechanism MUST use
447
additional information such as the client realm and/or authorization
448
attributes from the service ticket presented to the workstation by
449
the user, when mapping the logon credentials to a local account on
454
Swift Category - Standards Track 7
463
KDC Referrals February 2001
467
This section contains issues and suggestions that need to be
468
incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]:
470
1) No means to do name canonicalization if you're not
471
authenticating. Is it okay to require credentials in order to do
472
canonicalization? If so, how about this: Send a TGS_REQ for the
473
service name you have. If you get back a TGS_REP for a service,
474
great; pull out the name and throw out the credentials. If you
475
get back a TGS_REP for a TGT service, ask again in the specified
476
realm. If you get back a KRB_ERROR because policy prohibits you
477
from authenticating to that service, we can add to the
478
specification that the {realm,sname} in the KRB_ERROR must be the
479
canonical name, and the checksum must be used. As long as the
480
checksum is present, it's still a secure exchange with the KDC.
482
If we have to be able to do name canonicalization without any
483
sort of credentials, either client-side (tickets) or server-side
484
(tickets automatically acquired via service key), I think we just
485
lose. But maybe GSSAPI should be changed if that's the case.
487
2) Can't refer to another realm and specify a different service name
488
to give to that realm's KDC. The local KDC can tell you a
489
different service name or a different realm name, but not both.
490
This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type
491
of case I've mentioned.
493
Except ... the KDC-REP structure includes padata and ticket
494
extensions fields that are extensible. We could add a required
495
value to one of them -- perhaps only in the case where you return
496
a TGT when not asked -- that contains signed information about
497
the principal name to ask for in the other realm. (It would have
498
to be required, otherwise a man-in-the-middle could make it go
499
away.) Signing would be done using the session key for the TGS.
501
3) Secure canonicalization of service name in AS_REQ. If the
502
response is an AS_REP, we need a way to tell that the altered
503
server name wasn't a result of a MITM attack on the AS_REQ
504
message. Again, the KDC-REP extensible fields could have a new
505
required value added when name canonicalization happens,
506
indicating what the original principal name (in the AS_REQ
507
message) was, and signed using the same key as protects the
508
AS_REP. If it doesn't match what the client requested, the
509
messages were altered in transit.
511
4) Client name needs referral to another realm, and server name
512
needs canonicalization of some sort. The above fixes wouldn't
513
work for this case, and I'm not even sure which KDC should be
514
doing the canonicalization anyways.
517
The other-principal-name datum would probably look something like:
520
Swift Category - Standards Track 8
529
KDC Referrals February 2001
532
PrincipalAndNonce ::= SEQUENCE {
533
name[0] PrincipalName,
534
nonce[1] INTEGER -- copied from KDC_REQ
536
SignedPrincipal ::= SEQUENCE {
537
name-and-nonce[0] PrincipalAndNonce,
540
{PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal
541
{PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal
543
with the checksum computed over the encoding of the 'name-and-nonce'
544
field, and appropriate PA- or TE- numbers assigned. I don't have a
545
strong opinion on whether it'd be a pa-data or ticket extension;
546
conceptually it seems like an abuse of either, but, well, I think
547
I'd rather abuse them than leave the facility both in and
550
The nonce is needed because multiple exchanges may be made with the
551
same key, and these extension fields aren't packed in with the other
552
encrypted data in the same response, so a MITM could pick apart
553
multiple messages and mix-and-match components. (In a TGS_REQ
554
exchange, a subsession key would help, but it's not required.)
556
The extension field would be required to prevent a MITM from
557
discarding the field from a response; a flag bit in a protected part
558
of the message (probably in 'flags' in EncKDCRepPart) could also let
559
us know of a cases where the information can be omitted, namely,
560
when no name change is done. Perhaps the bit should be set to
561
indicate that a name change *was* done, and clear if it wasn't,
562
making the no-change case more directly compatible with RFC1510.
567
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
568
9, RFC 2026, October 1996.
570
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
571
Levels", BCP 14, RFC 2119, March 1997
573
3 Kohl, J., Neuman, C., "The Kerberos Network Authentication
574
Service (V5)", RFC 1510, September 1993
577
12. Author's Addresses
580
University of Washington
582
Email: mikesw@cs.washington.edu
586
Swift Category - Standards Track 9
595
KDC Referrals February 2001
601
Email: jbrezak@Microsoft.com
607
Email: jtrostle@cisco.com
610
Massachusetts Institute of Technology 77
612
Cambridge, Massachusetts 02139
613
Email: raeburn@mit.edu
652
Swift Category - Standards Track 10
661
KDC Referrals February 2001
664
Full Copyright Statement
666
Copyright (C) The Internet Society (1999). All Rights Reserved.
668
This document and translations of it may be copied and furnished to
669
others, and derivative works that comment on or otherwise explain it
670
or assist in its implementation may be prepared, copied, published
671
and distributed, in whole or in part, without restriction of any
672
kind, provided that the above copyright notice and this paragraph
673
are included on all such copies and derivative works. However, this
674
document itself may not be modified in any way, such as by removing
675
the copyright notice or references to the Internet Society or other
676
Internet organizations, except as needed for the purpose of
677
developing Internet standards in which case the procedures for
678
copyrights defined in the Internet Standards process must be
679
followed, or as required to translate it into languages other than
682
The limited permissions granted above are perpetual and will not be
683
revoked by the Internet Society or its successors or assigns.
685
This document and the information contained herein is provided on an
686
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
687
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
688
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
689
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
690
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
718
Swift Category - Standards Track 11
added
removed
doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt
