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