1
2
3
4NETWORK WORKING GROUP                                         K. Raeburn
5Internet-Draft                                                       MIT
6Updates: 4120 (if approved)                                       L. Zhu
7Expires: December 27, 2006                                 K. Jaganathan
8                                                   Microsoft Corporation
9                                                           June 25, 2006
10
11
12           Generating KDC Referrals to Locate Kerberos Realms
13                draft-ietf-krb-wg-kerberos-referrals-08
14
15Status of this Memo
16
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.
21
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.
26
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."
31
32   The list of current Internet-Drafts can be accessed at
33   http://www.ietf.org/ietf/1id-abstracts.txt.
34
35   The list of Internet-Draft Shadow Directories can be accessed at
36   http://www.ietf.org/shadow.html.
37
38   This Internet-Draft will expire on December 27, 2006.
39
40Copyright Notice
41
42   Copyright (C) The Internet Society (2006).
43
44Abstract
45
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
52
53
54
55Raeburn, et al.         Expires December 27, 2006               [Page 1]
56
57Internet-Draft                KDC Referrals                    June 2006
58
59
60   referral information to reach the realm of the target principal and
61   then receive the ticket.
62
63
64Table of Contents
65
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.  Client Name Canonicalization . . . . . . . . . . . . . . . . .  5
71   6.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  7
72   7.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  8
73   8.  Server Name Canonicalization (Informative) . . . . . . . . . . 10
74   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 10
75   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 11
76   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 11
77   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
78   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
79   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
80     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 12
81     14.2.  Informative References  . . . . . . . . . . . . . . . . . 12
82   Appendix A.  Compatibility with Earlier Implementations of
83                Name Canonicalization . . . . . . . . . . . . . . . . 13
84   Appendix B.  Document history  . . . . . . . . . . . . . . . . . . 14
85   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
86   Intellectual Property and Copyright Statements . . . . . . . . . . 16
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Raeburn, et al.         Expires December 27, 2006               [Page 2]
112
113Internet-Draft                KDC Referrals                    June 2006
114
115
1161.  Introduction
117
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.
129
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.
143
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.  In order for this to work on the client, each
150   application canonicalizes the host name of the service, for example
151   by doing a DNS lookup followed by a reverse lookup using the returned
152   IP address.  The returned primary host name is then used in the
153   construction of the principal name for the target service.  In order
154   for the correct realm to be added for the target host, the mapping
155   table [domain_to_realm] is consulted for the realm corresponding to
156   the DNS host name.  The corresponding realm is then used to complete
157   the target service principal name.
158
159   This traditional mechanism requires that each client have very
160   detailed configuration information about the hosts that are providing
161   services and their corresponding realms.  Having client side
162   configuration information can be very costly from an administration
163   point of view - especially if there are many realms and computers in
164
165
166
167Raeburn, et al.         Expires December 27, 2006               [Page 3]
168
169Internet-Draft                KDC Referrals                    June 2006
170
171
172   the environment.
173
174   There are also cases where specific DNS aliases (local names) have
175   been setup in an organization to refer to a server in another
176   organization (remote server).  The server has different DNS names in
177   each organization and each organization has a Kerberos realm that is
178   configured to service DNS names within that organization.  Ideally
179   users are able to authenticate to the server in the other
180   organization using the local server name.  This would mean that the
181   local realm be able to produce a ticket to the remote server under
182   its name.  You could give that remote server an identity in the local
183   realm and then have that remote server maintain a separate secret for
184   each alias it is known as.  Alternatively you could arrange to have
185   the local realm issue a referral to the remote realm and notify the
186   requesting client of the server's remote name that should be used in
187   order to request a ticket.
188
189   This memo proposes a solution for these problems and simplifies
190   administration by minimizing the configuration information needed on
191   each computer using Kerberos.  Specifically it describes a mechanism
192   to allow the KDC to handle canonicalization of names, provide for
193   principal aliases for users and services and provide a mechanism for
194   the KDC to determine the trusted realm authentication path by being
195   able to generate referrals to other realms in order to locate
196   principals.
197
198   Two kinds of KDC referrals are introduced in this memo:
199
200   1. Client referrals, in which the client doesn't know which realm
201      contains a user account.
202   2. Server referrals, in which the client doesn't know which realm
203      contains a server account.
204
205
2062.  Conventions Used in This Document
207
208   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
209   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
210   document are to be interpreted as described in [RFC2119].
211
212
2133.  Requesting a Referral
214
215   In order to request referrals defined in section 5, 6, and 7, the
216   Kerberos client MUST explicitly request the canonicalize KDC option
217   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
218   the KDC that the client is prepared to receive a reply that contains
219   a principal name other than the one requested.
220
221
222
223Raeburn, et al.         Expires December 27, 2006               [Page 4]
224
225Internet-Draft                KDC Referrals                    June 2006
226
227
228          KDCOptions ::= KerberosFlags
229                   -- canonicalize (15)
230                   -- other KDCOptions values omitted
231
232   The client should expect, when sending names with the "canonicalize"
233   KDC option, that names in the KDC's reply MAY be different than the
234   name in the request.  A referral TGT is a cross realm TGT that is
235   returned with the server name of the ticket being different from the
236   server name in the request [RFC4120].
237
238
2394.  Realm Organization Model
240
241   This memo assumes that the world of principals is arranged on
242   multiple levels: the realm, the enterprise, and the world.  A KDC may
243   issue tickets for any principal in its realm or cross-realm tickets
244   for realms with which it has a direct trust relationship.  The KDC
245   also has access to a trusted name service that can resolve any name
246   from within its enterprise into a realm.  This trusted name service
247   removes the need to use an un-trusted DNS lookup for name resolution.
248
249   For example, consider the following configuration, where lines
250   indicate trust relationships:
251
252                        MS.COM
253                      /        \
254                     /          \
255              OFFICE.MS.COM  NTDEV.MS.COM
256
257   In this configuration, all users in the MS.COM enterprise could have
258   a principal name such as alice@MS.COM, with the same realm portion.
259   In addition, servers at MS.COM should be able to have DNS host names
260   from any DNS domain independent of what Kerberos realm their
261   principals reside in.
262
263
2645.  Client Name Canonicalization
265
266   A client account may have multiple principal names.  More useful,
267   though, is a globally unique name that allows unification of email
268   and security principal names.  For example, all users at MS may have
269   a client principal name of the form "joe@MS.COM" even though the
270   principals are contained in multiple realms.  This global name is
271   again an alias for the true client principal name, which indicates
272   what realm contains the principal.  Thus, accounts "alice" in the
273   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may log on as "alice@
274   MS.COM" and "bob@MS.COM".
275
276
277
278
279Raeburn, et al.         Expires December 27, 2006               [Page 5]
280
281Internet-Draft                KDC Referrals                    June 2006
282
283
284   This utilizes a new client principal name type, as the AS-REQ message
285   only contains a single realm field, and the realm portion of this
286   name doesn't correspond to any Kerberos realm.  Thus, the entire name
287   "alice@MS.COM" is transmitted as a single component in the client
288   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
289   [RFC4120] (and the local realm name).  The KDC will recognize this
290   name type and then transform the requested name into the true
291   principal name.  The true principal name can be using a name type
292   different from the requested name type.  Typically the true principal
293   name will be a NT-PRINCIPAL [RFC4120].
294
295   If the "canonicalize" KDC option is set, then the KDC MAY change the
296   client principal name and type in the AS response and ticket returned
297   from the name type of the client name in the request, and include a
298   mandatory PA-DATA object authenticating the client name mapping:
299
300   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
301     names          [0] SEQUENCE {
302       requested-name [0] PrincipalName,
303       real-name      [1] PrincipalName
304     },
305     canon-checksum [1] Checksum
306   }
307
308   The canon-checksum field is computed over the DER encoding of the
309   names sequences, using the returned session key and a key usage value
310   of (TBD).
311
312   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
313   not included.  If the client name is changed, and the PA-CLIENT-
314   CANONICALIZED field does not exist, or the checksum cannot be
315   verified, or the requested-name field doesn't match the originally-
316   transmitted request, the client should discard the response.
317
318   For example the AS request may specify a client name of "bob@MS.COM"
319   as an NT-ENTERPRISE name with the "canonicalize" KDC option set and
320   the KDC will return with a client name of "104567" as a NT-UID, and a
321   PA-CLIENT-CANONICALIZED field listing the NT-ENTERPRISE "bob@MS.COM"
322   principal as the requested-name and the NT-UID "104567" principal as
323   the real-name.
324
325   It is assumed that the client discovers whether the KDC supports the
326   NT-ENTERPRISE name type via out of band mechanisms.
327
328   In order to enable one party in a user-to-user exchange to confirm
329   the identity of another when only the alias is known, the KDC MAY
330   include the following authorization data element, wrapped in AD-IF-
331   RELEVANT, in the initial credentials and copy it from a ticket-
332
333
334
335Raeburn, et al.         Expires December 27, 2006               [Page 6]
336
337Internet-Draft                KDC Referrals                    June 2006
338
339
340   granting ticket into additional credentials:
341
342   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
343     login-alias  [0] PrincipalName,
344     checksum     [1] Checksum
345   }
346
347   (Q: Wrapped inside KDCIssued too?  Use SEQUENCE OF PrincipalName?)
348
349   The checksum is computed over the DER encoding of the login-alias
350   field using (WHICH KEY?  If recipient can forge it, the KDC can't
351   trust it when returned, and would have to verify that the alias is
352   valid before copying it to additional credentials) and a key usage
353   number of (TBD).
354
355   The recipient of this authenticator must check the AD-LOGIN-ALIAS
356   name, if present, in addition to the normal client name field,
357   against the identity of the party with which it wishes to
358   authenticate; either should be allowed to match.  (Note that this is
359   not backwards compatible with [RFC4120]; if the server side of the
360   user-to-user exchange does not support this extension, and does not
361   know the true principal name, authentication may fail if the alias is
362   sought in the client name field.)
363
364
3656.  Client Referrals
366
367   The simplest form of ticket referral is for a user requesting a
368   ticket using an AS-REQ.  In this case, the client machine will send
369   the AS-REQ to a convenient trusted realm, for example the realm of
370   the client machine.  In the case of the name alice@MS.COM, the client
371   MAY optimistically choose to send the request to MS.COM.  The realm
372   in the AS-REQ is always the name of the realm that the request is for
373   as specified in [RFC4120].
374
375   The KDC will try to lookup the name in its local account database.
376   If the account is present in the realm of the request, it SHOULD
377   return a KDC reply structure with the appropriate ticket.
378
379   If the account is not present in the realm specified in the request
380   and the "canonicalize" KDC option is set, the KDC will try to lookup
381   the entire name, alice@MS.COM, using a name service.  If this lookup
382   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
383   [RFC4120].  If the lookup is successful, it MUST return an error
384   KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm
385   field will contain either the true realm of the client or another
386   realm that MAY have better information about the client's true realm.
387   The client SHALL NOT use a cname returned from a referral until that
388
389
390
391Raeburn, et al.         Expires December 27, 2006               [Page 7]
392
393Internet-Draft                KDC Referrals                    June 2006
394
395
396   name is validated.
397
398   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
399   new AS request with the same client principal name used to generate
400   the first referral to the realm specified by the realm field of the
401   Kerberos error message from the first request.  (The client realm
402   name will be updated in the new request to refer to this new realm.)
403   The client SHOULD repeat these steps until it finds the true realm of
404   the client.  To avoid infinite referral loops, an implementation
405   should limit the number of referrals.  A suggested limit is 5
406   referrals before giving up.
407
408   Since the same client name is sent to the referring and referred-to
409   realms, both realms must recognize the same client names.  In
410   particular, the referring realm cannot (usefully) define principal
411   name aliases that the referred-to realm will not know.
412
413   The true principal name of the client, returned in AS-REQ, can be
414   validated in a subsequent TGS message exchange where its value is
415   communicated back to the KDC via the authenticator in the PA-TGS-REQ
416   padata [RFC4120].
417
418
4197.  Server Referrals
420
421   The primary difference in server referrals is that the KDC MUST
422   return a referral TGT rather than an error message as is done in the
423   client referrals.  There needs to be a place to include in the reply
424   information about what realm contains the server.  This is done by
425   returning information about the server name in the pre-authentication
426   data field of the KDC reply [RFC4120], as specified later in this
427   section.
428
429   If the KDC resolves the server principal name into a principal in the
430   realm specified by the service realm name, it will return a normal
431   ticket.
432
433   If the "canonicalize" flag in the KDC options is not set, the KDC
434   MUST only look up the name as a normal principal name in the
435   specified server realm.  If the "canonicalize" flag in the KDC
436   options is set and the KDC doesn't find the principal locally, the
437   KDC MAY return a cross-realm ticket granting ticket to the next hop
438   on the trust path towards a realm that may be able to resolve the
439   principal name.  The true principal name of the server SHALL be
440   returned in the padata of the reply if it is different from what is
441   specified the request.
442
443   When a referral TGT is returned, the KDC MUST return the target realm
444
445
446
447Raeburn, et al.         Expires December 27, 2006               [Page 8]
448
449Internet-Draft                KDC Referrals                    June 2006
450
451
452   for the referral TGT as an KDC supplied pre-authentication data
453   element in the response.  This referral information in pre-
454   authentication data MUST be encrypted using the session key from the
455   reply ticket.  The key usage value for the encryption operation used
456   by PA-SERVER-REFERRAL is 26.
457
458   The pre-authentication data returned by the KDC, which contains the
459   referred realm and the true principal name of server, is encoded in
460   DER as follows.
461
462          PA-SERVER-REFERRAL      25
463
464          PA-SERVER-REFERRAL-DATA ::= EncryptedData
465                                -- ServerReferralData --
466
467          ServerReferralData ::= SEQUENCE {
468                 referred-realm           [0] Realm OPTIONAL,
469                                -- target realm of the referral TGT
470                 true-principal-name      [1] PrincipalName OPTIONAL,
471                                -- true server principal name
472                 requested-principal-name [2] PrincipalName OPTIONAL,
473                                -- requested server name
474                 ...
475          }
476
477   Clients SHALL NOT accept a reply ticket, whose the server principal
478   name is different from that of the request, if the KDC response does
479   not contain a PA-SERVER-REFERRAL padata entry.
480
481   The requested-principal-name MUST be included by the KDC, and MUST be
482   verified by the client, if the client sent an AS-REQ, as protection
483   against a man-in-the-middle modification to the AS-REQ message.
484
485   (Note that with the forthcoming rfc1510ter, the AS-REP may include an
486   option checksum of the AS-REQ, in which case this check would no
487   longer be necessary.)
488
489   The referred-realm field is present if and only if the returned
490   ticket is a referral TGT, not a service ticket for the requested
491   server principal.
492
493   When a referral TGT is returned and the true-principal-name field is
494   present, the client MUST use that name in the subsequent requests to
495   the server realm when following the referral.
496
497   Client SHALL NOT accept a true server principal name for a service
498   ticket if the true-principal-name field is not present in the PA-
499   SERVER-REFERRAL data.
500
501
502
503Raeburn, et al.         Expires December 27, 2006               [Page 9]
504
505Internet-Draft                KDC Referrals                    June 2006
506
507
508   The client will use this referral information to request a chain of
509   cross-realm ticket granting tickets until it reaches the realm of the
510   server, and can then expect to receive a valid service ticket.
511
512   However an implementation should limit the number of referrals that
513   it processes to avoid infinite referral loops.  A suggested limit is
514   5 referrals before giving up.
515
516   Here is an example of a client requesting a service ticket for a
517   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
518
519          +NC = Canonicalize KDCOption set
520          +PA-REFERRAL = returned PA-SERVER-REFERRAL
521          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
522          S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
523             containing MS.COM as the referred realm with no
524             true-principal-name
525          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
526          S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
527             containing NTDEV.MS.COM as the referred realm with no
528             true-principal-name
529          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
530          S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
531
532   Note that any referral or alias processing of the server name in
533   user-to-user authentication should use the same data as client name
534   canonicalization or referral.  Otherwise, the name used by one user
535   to log in may not be useable by another for user-to-user
536   authentication to the first.
537
538
5398.  Server Name Canonicalization (Informative)
540
541   No attempt is being made in this document to provide a means for
542   dealing with local-realm server principal name canonicalization or
543   aliasing.  The most obvious use case for this would be a hostname-
544   based service principal name ("host/foobar.example.com"), with a DNS
545   alias ("foo") for the server host which is used by the client.  There
546   are other ways this can be handled, currently, though they may
547   require additional configuration on the application server or KDC or
548   both.
549
550
5519.  Cross Realm Routing
552
553   The current Kerberos protocol requires the client to explicitly
554   request a cross-realm TGT for each pair of realms on a referral
555   chain.  As a result, the client need to be aware of the trust
556
557
558
559Raeburn, et al.         Expires December 27, 2006              [Page 10]
560
561Internet-Draft                KDC Referrals                    June 2006
562
563
564   hierarchy and of any short-cut trusts (those that aren't parent-
565   child trusts).
566
567   Instead, using the server referral routing mechanism as defined in
568   Section 7, The KDC will determine the best path for the client and
569   return a cross-realm TGT as the referral TGT, and the target realm
570   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
571
572   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
573   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
574   response does not contain the PA-SERVER-REFERRAL padata.
575
576
57710.  Caching Information
578
579   It is possible that the client may wish to get additional credentials
580   for the same service principal, perhaps with different authorization-
581   data restrictions or other changed attributes.  The return of a
582   server referral from a KDC can be taken as an indication that the
583   requested principal does not currently exist in the local realm.
584   Clearly, it would reduce network traffic if the clientn could cache
585   that information and use it when acquiring the second set of
586   credentials for a service, rather than always having to re-check with
587   the local KDC to see if the name has been created locally.
588
589   Rather than introduce a new timeout field for this cached
590   information, we can use the lifetime of the returned TGT in this
591   case.  When the TGT expires, the previously returned referral from
592   the local KDC should be considered invalid, and the local KDC must be
593   asked again for information for the desired service principal name.
594   If the client is still in contact with the service and needs to
595   reauthenticate to the same service regardless of local service
596   principal name assignments, it should use the referred-realm and
597   true-principal-name values when requesting new credentials.
598
599   Accordingly, KDC authors and maintainers should consider what factors
600   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
601   into credential expiration times in cases of referrals.
602
603
60411.  Open Issues
605
606   When should client name aliases be included in credentials?
607
608   Should all known client name aliases be included, or only the one
609   used at initial ticket acquisition?
610
611
612
613
614
615Raeburn, et al.         Expires December 27, 2006              [Page 11]
616
617Internet-Draft                KDC Referrals                    June 2006
618
619
62012.  Security Considerations
621
622   For the AS exchange case, it is important that the logon mechanism
623   not trust a name that has not been used to authenticate the user.
624   For example, the name that the user enters as part of a logon
625   exchange may not be the name that the user authenticates as, given
626   that the KDC_ERR_WRONG_REALM error may have been returned.  The
627   relevant Kerberos naming information for logon (if any), is the
628   client name and client realm in the service ticket targeted at the
629   workstation that was obtained using the user's initial TGT.
630
631   How the client name and client realm is mapped into a local account
632   for logon is a local matter, but the client logon mechanism MUST use
633   additional information such as the client realm and/or authorization
634   attributes from the service ticket presented to the workstation by
635   the user, when mapping the logon credentials to a local account on
636   the workstation.
637
638
63913.  Acknowledgments
640
641   Sam Hartman and authors came up with the idea of using the ticket key
642   to encrypt the referral data, which prevents cut and paste attack
643   using the referral data and referral TGTs.
644
645   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
646   version of this document.
647
648
64914.  References
650
65114.1.  Normative References
652
653   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
654              Requirement Levels", BCP 14, RFC 2119, March 1997.
655
656   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
657              Kerberos Network Authentication Service (V5)", RFC 4120,
658              July 2005.
659
66014.2.  Informative References
661
662   [I-D.ietf-cat-kerberos-pk-init]
663              Tung, B. and L. Zhu, "Public Key Cryptography for Initial
664              Authentication in Kerberos",
665              draft-ietf-cat-kerberos-pk-init-34 (work in progress),
666              February 2006.
667
668
669
670
671Raeburn, et al.         Expires December 27, 2006              [Page 12]
672
673Internet-Draft                KDC Referrals                    June 2006
674
675
676   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
677              X.509 Public Key Infrastructure Certificate and
678              Certificate Revocation List (CRL) Profile", RFC 3280,
679              April 2002.
680
681   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
682              of Crossrealm Referral Handling in the MIT Kerberos
683              Client",  Network and Distributed System Security
684              Symposium, February 2001.
685
686
687Appendix A.  Compatibility with Earlier Implementations of Name
688             Canonicalization
689
690   The Microsoft Windows 2000 and Windows 2003 releases included an
691   earlier form of name-canonicalization [XPR].  Here are the
692   differences:
693
694   1) The TGS referral data is returned inside of the KDC message as
695      "encrypted pre-authentication data".
696
697
698
699          EncKDCRepPart   ::= SEQUENCE {
700                 key                [0] EncryptionKey,
701                 last-req           [1] LastReq,
702                 nonce              [2] UInt32,
703                 key-expiration     [3] KerberosTime OPTIONAL,
704                 flags              [4] TicketFlags,
705                 authtime           [5] KerberosTime,
706                 starttime          [6] KerberosTime OPTIONAL,
707                 endtime            [7] KerberosTime,
708                 renew-till         [8] KerberosTime OPTIONAL,
709                 srealm             [9] Realm,
710                 sname             [10] PrincipalName,
711                 caddr             [11] HostAddresses OPTIONAL,
712                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
713         }
714
715   2) The preauth data type definition in the encrypted preauth data is
716      as follows:
717
718
719
720
721
722
723
724
725
726
727Raeburn, et al.         Expires December 27, 2006              [Page 13]
728
729Internet-Draft                KDC Referrals                    June 2006
730
731
732          PA-SVR-REFERRAL-INFO       20
733
734          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
735                 referred-name   [1] PrincipalName OPTIONAL,
736                 referred-realm  [0] Realm
737          }}
738
739   3) When [I-D.ietf-cat-kerberos-pk-init] is used, the NT-ENTERPRISE
740      client name is encoded as a Subject Alternative Name (SAN)
741      extension [RFC3280] in the client's X.509 certificate.  The type
742      of the otherName field for this SAN extension is AnotherName
743      [RFC3280].  The type-id field of the type AnotherName is id-ms-sc-
744      logon-upn (1.3.6.1.4.1.311.20.2.3) and the value field of the type
745      AnotherName is a KerberosString [RFC4120].  The value of this
746      KerberosString type is the single component in the name-string
747      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
748
749   In Microsoft's current implementation through the use of global
750   catalogs any domain in one forest is reachable from any other domain
751   in the same forest or another trusted forest with 3 or less
752   referrals.  A forest is a collection of realms with hierarchical
753   trust relationships: there can be multiple trust trees in a forest;
754   each child and parent realm pair and each root realm pair have
755   bidirectional transitive direct rusts between them.
756
757   While we might want to permit multiple aliases to exist and even be
758   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
759   one alias to exist, so this question had not previously arisen.
760
761
762Appendix B.  Document history
763
764   08 Moved Microsoft implementation info to appendix.  Clarify lack of
765      local server name canonicalization.  Added optional authz-data for
766      login alias, to support user-to-user case.  Added requested-
767      principal-name to ServerReferralData.  Added discussion of caching
768      information, and referral TGT lifetime.
769   07 Re-issued with new editor.  Fixed up some references.  Started
770      history.
771
772
773
774
775
776
777
778
779
780
781
782
783Raeburn, et al.         Expires December 27, 2006              [Page 14]
784
785Internet-Draft                KDC Referrals                    June 2006
786
787
788Authors' Addresses
789
790   Kenneth Raeburn
791   Massachusetts Institute of Technology
792   77 Massachusetts Avenue
793   Cambridge, MA  02139
794   US
795
796   Email: raeburn@mit.edu
797
798
799   Larry Zhu
800   Microsoft Corporation
801   One Microsoft Way
802   Redmond, WA  98052
803   US
804
805   Email: lzhu@microsoft.com
806
807
808   Karthik Jaganathan
809   Microsoft Corporation
810   One Microsoft Way
811   Redmond, WA  98052
812   US
813
814   Email: karthikj@microsoft.com
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839Raeburn, et al.         Expires December 27, 2006              [Page 15]
840
841Internet-Draft                KDC Referrals                    June 2006
842
843
844Intellectual Property Statement
845
846   The IETF takes no position regarding the validity or scope of any
847   Intellectual Property Rights or other rights that might be claimed to
848   pertain to the implementation or use of the technology described in
849   this document or the extent to which any license under such rights
850   might or might not be available; nor does it represent that it has
851   made any independent effort to identify any such rights.  Information
852   on the procedures with respect to rights in RFC documents can be
853   found in BCP 78 and BCP 79.
854
855   Copies of IPR disclosures made to the IETF Secretariat and any
856   assurances of licenses to be made available, or the result of an
857   attempt made to obtain a general license or permission for the use of
858   such proprietary rights by implementers or users of this
859   specification can be obtained from the IETF on-line IPR repository at
860   http://www.ietf.org/ipr.
861
862   The IETF invites any interested party to bring to its attention any
863   copyrights, patents or patent applications, or other proprietary
864   rights that may cover technology that may be required to implement
865   this standard.  Please address the information to the IETF at
866   ietf-ipr@ietf.org.
867
868
869Disclaimer of Validity
870
871   This document and the information contained herein are provided on an
872   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
873   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
874   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
875   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
876   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
877   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
878
879
880Copyright Statement
881
882   Copyright (C) The Internet Society (2006).  This document is subject
883   to the rights, licenses and restrictions contained in BCP 78, and
884   except as set forth therein, the authors retain all their rights.
885
886
887Acknowledgment
888
889   Funding for the RFC Editor function is currently provided by the
890   Internet Society.
891
892
893
894
895Raeburn, et al.         Expires December 27, 2006              [Page 16]
896
897