4 NETWORK WORKING GROUP K. Raeburn
6 Updates: 4120 (if approved) L. Zhu
7 Intended status: Standards Track Microsoft Corporation
8 Expires: January 15, 2009 July 14, 2008
11 Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm
13 draft-ietf-krb-wg-kerberos-referrals-11
17 By submitting this Internet-Draft, each author represents that any
18 applicable patent or other IPR claims of which he or she is aware
19 have been or will be disclosed, and any of which he or she becomes
20 aware will be disclosed, in accordance with Section 6 of BCP 79.
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-
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on January 15, 2009.
42 Copyright (C) The IETF Trust (2008).
46 The memo documents a method for a Kerberos Key Distribution Center
47 (KDC) to respond to client requests for Kerberos tickets when the
48 client does not have detailed configuration information on the realms
49 of users or services. The KDC will handle requests for principals in
50 other realms by returning either a referral error or a cross-realm
51 TGT to another realm on the referral path. The clients will use this
55 Raeburn & Zhu Expires January 15, 2009 [Page 1]
57 Internet-Draft KDC Referrals July 2008
60 referral information to reach the realm of the target principal and
61 then receive the ticket.
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
68 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4
69 4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5
70 5. Enterprise Principal Name Type . . . . . . . . . . . . . . . . 5
71 6. Name Canonicalization . . . . . . . . . . . . . . . . . . . . 6
72 7. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 8
73 8. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 9
74 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 12
75 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 12
76 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
77 12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 13
78 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
79 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13
80 14.1. Shared-password case . . . . . . . . . . . . . . . . . . 14
81 14.2. Preauthentication data . . . . . . . . . . . . . . . . . 14
82 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
83 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
84 16.1. Normative References . . . . . . . . . . . . . . . . . . 15
85 16.2. Informative References . . . . . . . . . . . . . . . . . 15
86 Appendix A. Compatibility with Earlier Implementations of
87 Name Canonicalization . . . . . . . . . . . . . . . . 15
88 Appendix B. Document history [REMOVE BEFORE PUBLICATION] . . . . 17
89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
90 Intellectual Property and Copyright Statements . . . . . . . . . . 19
111 Raeburn & Zhu Expires January 15, 2009 [Page 2]
113 Internet-Draft KDC Referrals July 2008
118 Current implementations of the Kerberos AS and TGS protocols, as
119 defined in [RFC4120], use principal names constructed from a known
120 user or service name and realm. A service name is typically
121 constructed from a name of the service and the DNS host name of the
122 computer that is providing the service. Many existing deployments of
123 Kerberos use a single Kerberos realm where all users and services
124 would be using the same realm. However in an environment where there
125 are multiple trusted Kerberos realms, the client needs to be able to
126 determine what realm a particular user or service is in before making
127 an AS or TGS request. Traditionally this requires client
128 configuration to make this possible.
130 When having to deal with multiple trusted realms, users are forced to
131 know what realm they are in before they can obtain a ticket granting
132 ticket (TGT) with an AS request. However, in many cases the user
133 would like to use a more familiar name that is not directly related
134 to the realm of their Kerberos principal name. A good example of
135 this is an RFC 822 style email name. This document describes a
136 mechanism that would allow a user to specify a user principal name
137 that is an alias for the user's Kerberos principal name. In practice
138 this would be the name that the user specifies to obtain a TGT from a
139 Kerberos KDC. The user principal name no longer has a direct
140 relationship with the Kerberos principal or realm. Thus the
141 administrator is able to move the user's principal to other realms
142 without the user having to know that it happened.
144 Once a user has a TGT, they would like to be able to access services
145 in any trusted Kerberos realm. To do this requires that the client
146 be able to determine what realm the target service principal is in
147 before making the TGS request. Current implementations of Kerberos
148 typically have a table that maps DNS host names to corresponding
149 Kerberos realms. The user-supplied host name or its domain component
150 is looked up in this table (often using the result of some form of
151 host name lookup performed with insecure DNS queries, in violation of
152 [RFC4120]). The corresponding realm is then used to complete the
153 target service principal name.
155 This traditional mechanism requires that each client have very
156 detailed configuration information about the hosts that are providing
157 services and their corresponding realms. Having client side
158 configuration information can be very costly from an administration
159 point of view - especially if there are many realms and computers in
162 There are also cases where specific DNS aliases (local names) have
163 been setup in an organization to refer to a server in another
167 Raeburn & Zhu Expires January 15, 2009 [Page 3]
169 Internet-Draft KDC Referrals July 2008
172 organization (remote server). The server has different DNS names in
173 each organization and each organization has a Kerberos realm that is
174 configured to service DNS names within that organization. Ideally
175 users are able to authenticate to the server in the other
176 organization using the local server name. This would mean that the
177 local realm be able to produce a ticket to the remote server under
178 its name. The administrator in the local realm could give that
179 remote server an identity in the local realm and then have that
180 remote server maintain a separate secret for each alias it is known
181 as. Alternatively the administrator could arrange to have the local
182 realm issue a referral to the remote realm and notify the requesting
183 client of the server's remote name that should be used in order to
186 This memo proposes a solution for these problems and simplifies
187 administration by minimizing the configuration information needed on
188 each computer using Kerberos. Specifically it describes a mechanism
189 to allow the KDC to handle canonicalization of names, provide for
190 principal aliases for users and services and allow the KDC to
191 determine the trusted realm authentication path by being able to
192 generate referrals to other realms in order to locate principals.
194 Two kinds of KDC referrals are introduced in this memo:
196 1. Client referrals, in which the client doesn't know which realm
197 contains a user account.
198 2. Server referrals, in which the client doesn't know which realm
199 contains a server account.
202 2. Conventions Used in This Document
204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
206 document are to be interpreted as described in [RFC2119].
209 3. Requesting a Referral
211 In order to request referrals as defined in later sections, the
212 Kerberos client MUST explicitly request the canonicalize KDC option
213 (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to
214 the KDC that the client is prepared to receive a reply that contains
215 a principal name other than the one requested.
218 KDCOptions ::= KerberosFlags
223 Raeburn & Zhu Expires January 15, 2009 [Page 4]
225 Internet-Draft KDC Referrals July 2008
228 -- other KDCOptions values omitted
230 The client should expect, when sending names with the "canonicalize"
231 KDC option, that names in the KDC's reply MAY be different than the
232 name in the request. A referral TGT is a cross realm TGT that is
233 returned with the server name of the ticket being different from the
234 server name in the request [RFC4120].
237 4. Realm Organization Model
239 This memo assumes that the world of principals is arranged on
240 multiple levels: the realm, the enterprise, and the world. A KDC may
241 issue tickets for any principal in its realm or cross-realm tickets
242 for realms with which it has a direct trust relationship. The KDC
243 also has access to a trusted name service that can resolve any name
244 from within its enterprise into a realm. This trusted name service
245 removes the need to use an un-trusted DNS lookup for name resolution.
247 For example, consider the following configuration, where lines
248 indicate trust relationships:
253 ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM
255 In this configuration, all users in the EXAMPLE.COM enterprise could
256 have principal names such as alice@EXAMPLE.COM, with the same realm
257 portion. In addition, servers at EXAMPLE.COM should be able to have
258 DNS host names from any DNS domain independent of what Kerberos realm
259 their principals reside in.
262 5. Enterprise Principal Name Type
264 The NT-ENTERPRISE type principal name contains one component, a
265 string of realm-defined content, which is intended to be used as an
266 alias for another principal name in some realm in the enterprise. It
267 is used for conveying the alias name, not for the real principal
268 names within the realms, and thus is only useful when name
269 canonicalization is requested.
271 The intent is to allow unification of email and security principal
272 names. For example, all users at EXAMPLE.COM may have a client
273 principal name of the form "joe@EXAMPLE.COM" even though the
274 principals are contained in multiple realms. This global name is
275 again an alias for the true client principal name, which indicates
279 Raeburn & Zhu Expires January 15, 2009 [Page 5]
281 Internet-Draft KDC Referrals July 2008
284 what realm contains the principal. Thus, accounts "alice" in the
285 realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as
286 "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
288 This utilizes a new principal name type, as the KDC-REQ message only
289 contains a single client realm field, and the realm portion of this
290 name corresponds to the Kerberos realm with which the request is
291 made. Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a
292 single component in the client name field of the AS-REQ message, with
293 a name type of NT-ENTERPRISE [RFC4120] (and the local realm name).
294 The KDC will recognize this name type and then transform the
295 requested name into the true principal name if the client account
296 resides in the local realm. The true principal name can have a name
297 type different from the requested name type. Typically the true
298 principal name will be a NT-PRINCIPAL [RFC4120].
301 6. Name Canonicalization
303 A service or account may have multiple principal names. For example,
304 if a host is known by multiple names, host-based services on it may
305 be known by multiple names in order to prevent the client from
306 needing a secure directory service to determine the correct hostname
307 to use. In order that the host should not need to be updated
308 whenever a new alias is created, the KDC may provide the mapping
309 information to the client in the credential acquisition process.
311 If the "canonicalize" KDC option is set, then the KDC MAY change the
312 client and server principal names and types in the AS response and
313 ticket returned from the name type of the client name in the request.
314 In a TGS exchange, the server principal name and type may be changed.
316 If the client principal name is changed in an AS exchange, the KDC
317 must include a mandatory PA-DATA object authenticating the client
320 ClientReferralInfo ::= SEQUENCE {
321 requested-name [0] PrincipalName,
322 mapped-name [1] PrincipalName,
325 PA-CLIENT-CANONICALIZED ::= SEQUENCE {
326 names [0] ClientReferralInfo,
327 canon-checksum [1] Checksum
330 The canon-checksum field is computed over the DER encoding of the
331 names sequences, using the AS reply key and a key usage value of
335 Raeburn & Zhu Expires January 15, 2009 [Page 6]
337 Internet-Draft KDC Referrals July 2008
342 If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
343 not included. If the client name is changed, and the PA-CLIENT-
344 CANONICALIZED field does not exist, or the checksum cannot be
345 verified, or the requested-name field doesn't match the client name
346 in the originally-transmitted request, the client should discard the
349 For example the AS request may specify a client name of "bob@
350 EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC
351 option set and the KDC will return with a client name of "104567" as
352 a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT-
353 ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the
354 NT-UID "104567" principal as the mapped-name.
356 (It is assumed that the client discovers whether the KDC supports the
357 NT-ENTERPRISE name type via out of band mechanisms.)
359 If the server name is changed, a PA-SERVER-REFERRAL preauth data
360 entry MUST be supplied by the KDC and validated by the client.
362 In order to enable one party in a user-to-user exchange to confirm
363 the identity of another when only the alias is known, the KDC MAY
364 include the following authorization data element, wrapped in AD-KDC-
365 ISSUED, in the initial credentials and copy it from a ticket-granting
366 ticket into additional credentials:
368 AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
369 login-aliases [0] SEQUENCE(1..MAX) OF PrincipalName,
372 The login-aliases field lists one or more of the aliases the
375 The recipient of this authenticator must check the AD-LOGIN-ALIAS
376 names, if present, in addition to the normal client name field,
377 against the identity of the party with which it wishes to
378 authenticate; either should be allowed to match. (Note that this is
379 not backwards compatible with [RFC4120]; if the server side of the
380 user-to-user exchange does not support this extension, and does not
381 know the true principal name, authentication may fail if the alias is
382 sought in the client name field.)
384 The use of AD-KDC-ISSUED authorization data elements in cross-realm
385 cases has not been well explored at this writing; hence we will only
386 specify the inclusion of this data in the one-realm case. The alias
387 information SHOULD be dropped in the general cross-realm case.
391 Raeburn & Zhu Expires January 15, 2009 [Page 7]
393 Internet-Draft KDC Referrals July 2008
396 However, a realm MAY implement a policy of accepting and re-signing
397 (wrapping in a new AD-KDC-ISSUED element) alias information provided
398 by certain trusted realms, in the cross-realm ticket-granting
401 The canonical principal name for an alias may not be in the form of a
402 ticket-granting service name, as (in a case of server name
403 canonicalization) that would be construed as a case of cross-realm
404 referral, described below.
409 The simplest form of ticket referral is for a user requesting a
410 ticket using an AS-REQ. In this case, the client machine will send
411 the AS-REQ to a convenient trusted realm, for example the realm of
412 the client machine. In the case of the name alice@EXAMPLE.COM, the
413 client MAY optimistically choose to send the request to EXAMPLE.COM.
414 The realm in the AS-REQ is always the name of the realm that the
415 request is for as specified in [RFC4120].
417 The KDC will try to lookup the name in its local account database.
418 If the account is present in the realm of the request, it SHOULD
419 return a KDC reply structure with the appropriate ticket.
421 If the account is not present in the realm specified in the request
422 and the "canonicalize" KDC option is set, the KDC may look up the
423 client principal name using some kind of name service or directory
424 service. If this lookup is unsuccessful, it MUST return the error
425 KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful,
426 it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the
427 error message the crealm field will contain either the true realm of
428 the client or another realm that MAY have better information about
429 the client's true realm. The client SHALL NOT use the cname returned
430 in this error message.
432 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
433 new AS request with the same client principal name used to generate
434 the first referral to the realm specified by the realm field of the
435 Kerberos error message corresponding to the first request. (The
436 client realm name will be updated in the new request to refer to this
437 new realm.) The client SHOULD repeat these steps until it finds the
438 true realm of the client. To avoid infinite referral loops, an
439 implementation should limit the number of referrals. A suggested
440 limit is 5 referrals before giving up.
442 Since the same client name is sent to the referring and referred-to
443 realms, both realms must recognize the same client names. In
447 Raeburn & Zhu Expires January 15, 2009 [Page 8]
449 Internet-Draft KDC Referrals July 2008
452 particular, the referring realm cannot (usefully) define principal
453 name aliases that the referred-to realm will not know.
455 The true principal name of the client, returned in AS-REQ, can be
456 validated in a subsequent TGS message exchange where its value is
457 communicated back to the KDC via the authenticator in the PA-TGS-REQ
458 padata [RFC4120]. However, this requires trusting the referred-to
459 realm's KDCs. Clients should limit the referral mappings they will
460 accept to realms trusted via some local policy. Some possible
461 factors that might be taken into consideration for such a policy
464 o Any realm indicated by the local KDC, if the returned KRB-ERROR
465 message is protected by some additional means, for example using a
466 preauthentication scheme using a public key known to be associated
467 with the KDC, or an IPsec tunnel known to have the desired KDC as
469 o A list of realms configured by an administrator
470 o Any realm accepted by the user when explicitly prompted
472 There is currently no provision for changing the client name in a
473 client referral response, because there is no method for verifying
474 that a man-in-the-middle attack did not change the requested name in
475 the request on the way to the KDC.
480 The primary difference in server referrals is that the KDC returns a
481 referral TGT rather than an error message as is done in the client
482 referrals. There needs to be a place to include in the reply
483 information about what realm contains the server; this is done by
484 returning information about the server name in the pre-authentication
485 data field of the KDC reply [RFC4120], as specified later in this
488 If the "canonicalize" flag in the KDC options is set and the KDC
489 doesn't find the principal locally, either as a regular principal or
490 as an alias for another local principal, the KDC MAY return a cross-
491 realm ticket granting ticket to the next hop on the trust path
492 towards a realm that may be able to resolve the principal name. The
493 true principal name of the server SHALL be returned in the padata of
494 the reply if it is different from what is specified the request.
496 When a referral TGT is returned, the KDC MUST return the target realm
497 for the referral TGT as an KDC supplied pre-authentication data
498 element in the response. This referral information in pre-
499 authentication data MUST be encrypted using the session key from the
503 Raeburn & Zhu Expires January 15, 2009 [Page 9]
505 Internet-Draft KDC Referrals July 2008
508 reply ticket. The key usage value for the encryption operation used
509 by PA-SERVER-REFERRAL is 26.
511 The pre-authentication data returned by the KDC, which contains the
512 referred realm and the true principal name of server, is encoded in
516 PA-SERVER-REFERRAL 25
518 SERVER-REFERRAL-DATA ::= EncryptedData
519 -- ServerReferralData
520 -- returned session key, ku=26
522 ServerReferralData ::= SEQUENCE {
523 referred-realm [0] Realm OPTIONAL,
524 -- target realm of the referral TGT
525 true-principal-name [1] PrincipalName OPTIONAL,
526 -- true server principal name
527 requested-principal-name [2] PrincipalName OPTIONAL,
528 -- requested server name
529 referral-valid-until [3] KerberosTime OPTIONAL,
530 rep-cksum [4] Checksum,
531 -- associated {AS,TGS}-REP with no padata
532 -- reply key, ku=[TBD]
536 The rep-cksum field is a checksum computed over the DER encoding of
537 the AS-REP or TGS-REP message with which the SERVER-REFERRAL-DATA is
538 included, but with the padata field omitted. It SHOULD be computed
539 using the mandatory-to-implement checksum type associated with the
540 encryption type of the reply key. (Encrypting the referral data in
541 with the reply key but without the checksum only proves that it was
542 generated by one of the parties with access to the reply key; it is
543 not proof against cut-and-paste attacks combining parts of different
544 KDC replies using the same reply key.)
546 Clients SHALL NOT accept a reply ticket in which the server principal
547 name is different from that of the request, if the KDC response does
548 not contain a PA-SERVER-REFERRAL padata entry.
550 The requested-principal-name MUST be included by the KDC, and MUST be
551 verified by the client, if the client sent an AS-REQ, as protection
552 against a man-in-the-middle modification to the AS-REQ message.
554 The referred-realm field is present if and only if the returned
555 ticket is a referral TGT, not a service ticket for the requested
559 Raeburn & Zhu Expires January 15, 2009 [Page 10]
561 Internet-Draft KDC Referrals July 2008
566 When a referral TGT is returned and the true-principal-name field is
567 present, the client MUST use that name in the subsequent requests to
568 the server realm when following the referral.
570 Client SHALL NOT accept a true server principal name for a service
571 ticket if the true-principal-name field is not present in the PA-
572 SERVER-REFERRAL data.
574 The client will use this referral information to request a chain of
575 cross-realm ticket granting tickets until it reaches the realm of the
576 server, and can then expect to receive a valid service ticket.
578 However an implementation should limit the number of referrals that
579 it processes to avoid infinite referral loops. A suggested limit is
580 5 referrals before giving up.
582 The client may cache the mapping of the requested name to the name of
583 the next realm to use and the principal name to ask for. (See
584 Section 10.) The referral-valid-until field, if present, conveys how
585 long this information is valid for.
587 Here is an example of a client requesting a service ticket for a
588 service in realm DEV.EXAMPLE.COM where the client is in
591 +NC = Canonicalize KDCOption set
592 +PA-REFERRAL = returned PA-SERVER-REFERRAL
593 C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
594 S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL
595 containing EXAMPLE.COM as the referred realm with no
597 C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
598 S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL
599 containing DEV.EXAMPLE.COM as the referred realm with no
601 C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
602 S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
604 Note that any referral or alias processing of the server name in
605 user-to-user authentication should use the same data as client name
606 canonicalization or referral. Otherwise, the name used by one user
607 to log in may not be useable by another for user-to-user
608 authentication to the first.
615 Raeburn & Zhu Expires January 15, 2009 [Page 11]
617 Internet-Draft KDC Referrals July 2008
620 9. Cross Realm Routing
622 The current Kerberos protocol requires the client to explicitly
623 request a cross-realm TGT for each pair of realms on a referral
624 chain. As a result, the client need to be aware of the trust
625 hierarchy and of any short-cut trusts (those that aren't parent-
628 Instead, using the server referral routing mechanism as defined in
629 Section 8, The KDC will determine the best path for the client and
630 return a cross-realm TGT as the referral TGT, and the target realm
631 for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
633 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
634 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC
635 response does not contain the PA-SERVER-REFERRAL padata.
638 10. Caching Information
640 It is possible that the client may wish to get additional credentials
641 for the same service principal, perhaps with different authorization-
642 data restrictions or other changed attributes. The return of a
643 server referral from a KDC can be taken as an indication that the
644 requested principal does not currently exist in the local realm.
645 Clearly, it would reduce network traffic if the clients could cache
646 that information and use it when acquiring the second set of
647 credentials for a service, rather than always having to re-check with
648 the local KDC to see if the name has been created locally.
650 If the referral-valid-until field is provided in the PA-SERVER-
651 REFERRAL-DATA message, it indicates the expiration time of this data;
652 if it is not included, the expiration time of the TGT is used. When
653 the TGT expires, the previously returned referral from the local KDC
654 should be considered invalid, and the local KDC must be asked again
655 for information for the desired service principal name. (Note that
656 the client may get back multiple referral TGTs from the local KDC to
657 the same remote realm, with different lifetimes. The lifetime
658 information must be properly associated with the requested service
659 principal names. Simply having another TGT for the same remote realm
660 does not extend the validity of previously acquired information about
661 one service principal name.) If the client is still in contact with
662 the service and needs to reauthenticate to the same service
663 regardless of local service principal name assignments, it should use
664 the referred-realm and true-principal-name values when requesting new
667 Accordingly, KDC authors and maintainers should consider what factors
671 Raeburn & Zhu Expires January 15, 2009 [Page 12]
673 Internet-Draft KDC Referrals July 2008
676 (e.g., DNS alias lifetimes) they may or may not wish to incorporate
677 into credential expiration times in cases of referrals.
682 Client referral info validation
684 When should client name aliases be included in credentials? Should
685 all known client name aliases be included, or only the one used at
686 initial ticket acquisition?
688 Should list the policies that need to be defined.
690 More examples: u2u, policy checks, maybe cross-realm.
692 Possibly generalize the integrity/privacy protection on
693 ServerReferralData into a general padata wrapper?
695 Is PA-SERVER-REFERRAL needed in a TGS exchange?
697 Do we need to send requested-name fields, or can we just include them
701 12. Number Assignments
703 Most number registries in the Kerberos protocol have not been turned
704 over to IANA for management at the time of this writing, hence this
705 is not an "IANA Considerations" section.
707 Various values do need assigning for this draft:
709 PA-CLIENT-CANONICALIZED
710 key usage value for PA-CLIENT-CANONICALIZED field canon-checksum
713 13. IANA Considerations
718 14. Security Considerations
720 For the AS exchange case, it is important that the logon mechanism
721 not trust a name that has not been used to authenticate the user.
722 For example, the name that the user enters as part of a logon
723 exchange may not be the name that the user authenticates as, given
727 Raeburn & Zhu Expires January 15, 2009 [Page 13]
729 Internet-Draft KDC Referrals July 2008
732 that the KDC_ERR_WRONG_REALM error may have been returned. The
733 relevant Kerberos naming information for logon (if any), is the
734 client name and client realm in the service ticket targeted at the
735 workstation that was obtained using the user's initial TGT.
737 How the client name and client realm is mapped into a local account
738 for logon is a local matter, but the client logon mechanism MUST use
739 additional information such as the client realm and/or authorization
740 attributes from the service ticket presented to the workstation by
741 the user, when mapping the logon credentials to a local account on
744 14.1. Shared-password case
746 A special case to examine is when the user is known (or correctly
747 suspected) to use the same password for multiple accounts. A man-in-
748 the-middle attacker can either alter the request on its way to the
749 KDC, changing the client principal name, or reply to the client with
750 a response previously send by the KDC in response to a request from
751 the attacker. The response received by the client can then be
752 decrypted by the user, though if the default "salt" generated from
753 the principal name is used to produce the user's key, a PA-ETYPE-INFO
754 or PA-ETYPE-INFO2 preauth record may need to be added or altered by
755 the attacker to cause the client software to generate the key needed
756 for the message it will receive. None of this requires the attacker
757 to know the user's password, and without further checking, could
758 cause the user to unknowingly use the wrong credentials.
760 In normal [RFC4120] operation, a generated AP-REQ message includes in
761 the Authenticator field a copy of the client's idea of its own
762 principal name. If this differs from the name in the KDC-generated
763 Ticket, the application server will reject the message.
765 With client name canonicalization as described in this document, the
766 client may get its principal name from the response from the KDC.
767 Requiring the PA-CLIENT-CANONICALIZED data lets the client securely
768 check that the requested name was not altered in transit. If the PA-
769 CLIENT-CANONICALIZED data is absent, the client can use the principal
772 14.2. Preauthentication data
774 In cases of credential renewal, forwarding, or validation, if
775 credentials are sent to the KDC that are not an initial ticket-
776 granting ticket for the client's home realm, the encryption key used
777 to protect the TGS exchange is one known to a third party (namely,
778 the service for which the credential was issued). Consequently, in
779 such an exchange, the protection described earlier for the
783 Raeburn & Zhu Expires January 15, 2009 [Page 14]
785 Internet-Draft KDC Referrals July 2008
788 preauthentication data cannot be assumed to provide a secure channel
789 between the KDC and the client, and such preauth data MUST NOT be
790 trusted for any information that needs to come from the KDC.
795 Sam Hartman and authors came up with the idea of using the ticket key
796 to encrypt the referral data, which prevents cut and paste attack
797 using the referral data and referral TGTs.
799 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
800 version of this document.
802 Karthik Jaganathan contributed to earlier versions.
807 16.1. Normative References
809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
810 Requirement Levels", BCP 14, RFC 2119, March 1997.
812 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
813 Kerberos Network Authentication Service (V5)", RFC 4120,
816 16.2. Informative References
818 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
819 X.509 Public Key Infrastructure Certificate and
820 Certificate Revocation List (CRL) Profile", RFC 3280,
823 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
824 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
826 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
827 of Crossrealm Referral Handling in the MIT Kerberos
828 Client", Network and Distributed System Security
829 Symposium, February 2001.
832 Appendix A. Compatibility with Earlier Implementations of Name
835 The Microsoft Windows 2000 and Windows 2003 releases included an
839 Raeburn & Zhu Expires January 15, 2009 [Page 15]
841 Internet-Draft KDC Referrals July 2008
844 earlier form of name-canonicalization [XPR]. Here are the
847 1) The TGS referral data is returned inside of the KDC message as
848 "encrypted pre-authentication data".
852 EncKDCRepPart ::= SEQUENCE {
853 key [0] EncryptionKey,
854 last-req [1] LastReq,
856 key-expiration [3] KerberosTime OPTIONAL,
857 flags [4] TicketFlags,
858 authtime [5] KerberosTime,
859 starttime [6] KerberosTime OPTIONAL,
860 endtime [7] KerberosTime,
861 renew-till [8] KerberosTime OPTIONAL,
863 sname [10] PrincipalName,
864 caddr [11] HostAddresses OPTIONAL,
865 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
868 2) The preauth data type definition in the encrypted preauth data is
873 PA-SVR-REFERRAL-INFO 20
875 PA-SVR-REFERRAL-DATA ::= SEQUENCE {
876 referred-name [1] PrincipalName OPTIONAL,
877 referred-realm [0] Realm
880 3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is
881 encoded as a Subject Alternative Name (SAN) extension [RFC3280] in
882 the client's X.509 certificate. The type of the otherName field
883 for this SAN extension is AnotherName [RFC3280]. The type-id
884 field of the type AnotherName is id-ms-sc-logon-upn
885 (1.3.6.1.4.1.311.20.2.3) and the value field of the type
886 AnotherName is a KerberosString [RFC4120]. The value of this
887 KerberosString type is the single component in the name-string
888 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
890 In Microsoft's current implementation through the use of global
891 catalogs any domain in one forest is reachable from any other domain
895 Raeburn & Zhu Expires January 15, 2009 [Page 16]
897 Internet-Draft KDC Referrals July 2008
900 in the same forest or another trusted forest with 3 or less
901 referrals. A forest is a collection of realms with hierarchical
902 trust relationships: there can be multiple trust trees in a forest;
903 each child and parent realm pair and each root realm pair have
904 bidirectional transitive direct rusts between them.
906 While we might want to permit multiple aliases to exist and even be
907 reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
908 one NT-ENTERPRISE alias to exist, so this question had not previously
912 Appendix B. Document history [REMOVE BEFORE PUBLICATION]
914 11 Changed title. Better protection on server referral preauth data.
915 Support server name canonicalization. Rename ReferralInfo to
916 ClientReferralInfo. Disallow alias mapping to a TGT principal.
917 Explain why no name change in client referrals. Add empty IANA
918 Considerations. Add some notes on preauth data protection during
920 10 Separate enterprise principal names into a separate section. Add
921 a little wording to suggest server principal name canonicalization
922 might be allowed; not fleshed out. Advise against AD-KDC-ISSUED
923 in cronn-realm cases. Advise policy checks on returned client
924 referral info, since there's no security. List number
925 assignments. Add security analysis of shared-password case. No
926 longer plan to remove Microsoft appendix. Add referral-valid-
928 09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain.
929 Rewrote description of existing practice. (Don't name the lookup
930 table consulted. Mention that DNS "canonicalization" is contrary
931 to [RFC4120].) Noted Microsoft behavior should be moved out into
932 a separate document. Changed some second-person references in the
933 introduction to identify the proper parties. Changed PA-CLIENT-
934 CANONICALIZED to use a separate type for the actual referral data,
935 add an extension marker to that type, and change the checksum key
936 from the "returned session key" to the "AS reply key". Changed
937 AD-LOGIN-ALIAS to contain a sequence of names, to be contained in
938 AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer
939 needed separate checksum. Attempt to clarify the cache lifetime
940 of referral information.
941 08 Moved Microsoft implementation info to appendix. Clarify lack of
942 local server name canonicalization. Added optional authz-data for
943 login alias, to support user-to-user case. Added requested-
944 principal-name to ServerReferralData. Added discussion of caching
945 information, and referral TGT lifetime.
951 Raeburn & Zhu Expires January 15, 2009 [Page 17]
953 Internet-Draft KDC Referrals July 2008
956 07 Re-issued with new editor. Fixed up some references. Started
963 Massachusetts Institute of Technology
964 77 Massachusetts Avenue
968 Email: raeburn@mit.edu
972 Microsoft Corporation
977 Email: lzhu@microsoft.com
1007 Raeburn & Zhu Expires January 15, 2009 [Page 18]
1009 Internet-Draft KDC Referrals July 2008
1012 Full Copyright Statement
1014 Copyright (C) The IETF Trust (2008).
1016 This document is subject to the rights, licenses and restrictions
1017 contained in BCP 78, and except as set forth therein, the authors
1018 retain all their rights.
1020 This document and the information contained herein are provided on an
1021 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1022 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1023 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1024 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1025 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1026 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1029 Intellectual Property
1031 The IETF takes no position regarding the validity or scope of any
1032 Intellectual Property Rights or other rights that might be claimed to
1033 pertain to the implementation or use of the technology described in
1034 this document or the extent to which any license under such rights
1035 might or might not be available; nor does it represent that it has
1036 made any independent effort to identify any such rights. Information
1037 on the procedures with respect to rights in RFC documents can be
1038 found in BCP 78 and BCP 79.
1040 Copies of IPR disclosures made to the IETF Secretariat and any
1041 assurances of licenses to be made available, or the result of an
1042 attempt made to obtain a general license or permission for the use of
1043 such proprietary rights by implementers or users of this
1044 specification can be obtained from the IETF on-line IPR repository at
1045 http://www.ietf.org/ipr.
1047 The IETF invites any interested party to bring to its attention any
1048 copyrights, patents or patent applications, or other proprietary
1049 rights that may cover technology that may be required to implement
1050 this standard. Please address the information to the IETF at
1056 Funding for the RFC Editor function is provided by the IETF
1057 Administrative Support Activity (IASA).
1063 Raeburn & Zhu Expires January 15, 2009 [Page 19]