7 Network Working Group Ken'ichi Kamada
8 INTERNET-DRAFT Shoichi Sakane
9 Expires: August 25, 2007 Yokogawa Electric Corporation
13 Client-Friendly Cross-Realm Model for Kerberos 5
14 draft-kamada-krb-client-friendly-cross-00.txt
21 By submitting this Internet-Draft, each author represents that any
22 applicable patent or other IPR claims of which he or she is aware
23 have been or will be disclosed, and any of which he or she becomes
24 aware will be disclosed, in accordance with Section 6 of BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that
28 other groups may also distribute working documents as Internet-
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 The list of current Internet-Drafts can be accessed at
37 http://www.ietf.org/1id-abstracts.html
39 The list of Internet-Draft Shadow Directories can be accessed at
40 http://www.ietf.org/shadow.html
42 This Internet-Draft expires on August 25, 2007.
47 Copyright (C) The IETF Trust (2007).
58 Kamada and Sakane [Page 1]
60 Internet-Draft Client-Friendly Cross-Realm February 2007
65 This document proposes a cross-realm transition model, which is
66 friendly to resource-limited clients. This model provides a way to
67 move the cost of consecutive Ticket-Granting Service (TGS) exchanges
68 from the clients to the KDC and a way to reduce the transition cost
69 by generating a direct inter-realm relationship between two realms.
70 The document itself does not specify any protocols, which need to be
76 1. Introduction ................................................. 3
77 2. Problems on Client Performance ............................... 3
78 2.1. Long Authentication Path ................................ 4
79 2.2. Client-Centric Ticketing ................................ 4
80 3. Proposal of Client-Friendly Cross-Realm Model ................ 4
81 3.1. Temporary Inter-Realm Relationship Generation Mode ...... 5
82 3.2. Attorney Ticketing Mode ................................. 6
83 3.3. Combination of the Two Modes ............................ 7
84 4. Generality and Orthogonality of These Modes .................. 8
85 5. Related Protocols Currently Proposed ......................... 9
86 5.1. PKCROSS ................................................. 9
87 5.2. XTGS .................................................... 9
88 6. Interoperability Considerations .............................. 9
89 7. Security Considerations ...................................... 10
90 7.1. Denial of Service (DoS) ................................. 10
91 7.2. Ticketing Policy Enforcement ............................ 10
92 8. IANA Considerations .......................................... 10
93 9. Acknowledgments .............................................. 10
94 10. References ................................................... 10
95 Authors' Addresses ............................................... 11
96 Full Copyright Statement ......................................... 11
97 Intellectual Property Statement .................................. 11
114 Kamada and Sakane [Page 2]
116 Internet-Draft Client-Friendly Cross-Realm February 2007
121 Kerberos Version 5 [RFC4120] has a concept of cross-realm
122 authentication so that principals in different realms can
123 authenticate each other. However in the current cross-realm model,
124 each client has to traverse the authentication path, and the load of
125 the traversal is not negligible for clients with limited resources,
126 e.g., computational speed or power supply [CRPS].
128 In the current cross-realm operation, a client obtains a service
129 ticket for a remote principal in the following steps:
131 1) (Number of transit) TGSes to get cross-realm TGTs in order to
132 traverse the intermediate realms, and
134 2) One TGS to get the final service ticket.
136 That is, a client need to perform (number of transits) + 1
137 transactions to obtain a ticket for a remote service.
139 This document proposes a new cross-realm model, which consists of
140 "temporary inter-realm relationship generation mode" and "attorney
141 ticketing mode". The former is intended to reduce the transition
142 cost itself, on the other hand, the latter is to move the cost from
143 clients to KDCs. The document does not specify any protocols, which
144 need to be specified separately.
146 Terms defined in section 1.7 of RFC 4120 are used throughout this
150 2. Problems on Client Performance
152 In the current model of cross-realm operation, a client has to
153 transit all realms on the path to the destination realm. If the
154 source realm and the destination realm have a direct inter-realm
155 relationship, a client is able to obtain a service ticket with two
156 TGS transactions (one for a cross-realm TGT and one for the service
157 ticket), but if there is an only multi-hop relationship between the
158 realms, client's job increases in proportion to the distance of the
161 Two issues can be observed here behind the client load, which are
162 described in the following subsections.
170 Kamada and Sakane [Page 3]
172 Internet-Draft Client-Friendly Cross-Realm February 2007
175 2.1. Long Authentication Path
177 When a client wants to get a service ticket for a remote realm, it
178 must transit to the remote realm by traversing the intermediate
179 realms on the authentication path to the remote realm. The result of
180 a transition is cached as a cross-realm TGT, nonetheless, it is a
181 per-client optimization. Thus all clients accessing a remote realm
182 must pay the cost separately, even if their resource are limited.
183 For a long authentication path, the cost of the whole system becomes
187 2.2. Client-Centric Ticketing
189 In Kerberos, any service tickets or cross-realm TGTs are issued via
190 TGS, where a client present a ticket for the TGS and obtains a next
191 ticket. Currently, all TGS transactions are initiated by the client
192 and it need to get all necessary cross-realm TGTs iteratively before
193 the final service ticket. This process is a burden to a resource-
197 3. Proposal of Client-Friendly Cross-Realm Model
199 In this section, two modes of operation are introduced, "Temporary
200 Inter-Realm Relationship Generation Mode" and "Attorney Ticketing
201 Mode", to solve the issues described in the previous section.
203 Temporary Inter-Realm Relationship Generation Mode
204 This is introduced to solve the issue of the long authentication
205 path. In this mode, if the source realm and the destination realm
206 do not have a direct inter-realm relationship, the source KDC
207 traverses the authentication path by itself, contacts with the
208 remote KDC, and generates a direct inter-realm relationship
209 between them. After that, the source KDC can issue direct inter-
210 realm TGTs for the destination realm. The purpose of this mode is
211 to reduce the transition cost itself.
213 Attorney Ticketing Mode
214 This is introduced to solve the issue of the client-centric
215 ticketing. Consecutive TGS transactions to get cross-realm TGTs
216 and/or a final service ticket are initiated by a client in the
217 traditional Kerberos, but in this mode, a KDC undertake it. The
218 purpose of this mode is to shift the cost of TGSes from a client
219 to a KDC. This does not reduce the cost itself.
221 These two modes are designed to be independent, that is, can be used
222 separately or in combination.
226 Kamada and Sakane [Page 4]
228 Internet-Draft Client-Friendly Cross-Realm February 2007
231 3.1. Temporary Inter-Realm Relationship Generation Mode
233 Temporary inter-realm relationship generation mode enables a KDC to
234 issue an inter-realm TGT directly to a remote KDC with which the KDC
235 doesn't preshare an inter-realm key. To issue an inter-realm TGT
236 directly, a temporary inter-realm key needs to be provided somehow.
237 To achieve that, the local KDC obtains a special ticket for the
238 remote KDC and use its session key as an inter-realm key. This
239 methodology was introduced by PKCROSS [PKCROSS]. In this document,
240 that special ticket is called as an "inter-KDC ticket", and an inter-
241 realm TGT generated using an inter-KDC ticket as a "direct inter-
244 How does the local KDC reach the remote KDC is out of scope of this
245 model, but we can easily come up with 1) traversing a long
246 authentication path if available or 2) using PKINIT. That is,
247 PKCROSS is interpreted as a combination of this model and PKINIT.
249 This document does not standardize a specific protocol, but a inter-
250 KDC ticket will have the following form:
252 - its sname has a special form (PKCROSS proposes
253 "pkcross/realm@REALM", but it would be better to use a more
254 general name than "pkcross"),
256 and a direct inter-realm TGT will have the following form:
258 - its TicketExtensions field [KRBEXT] contains the inter-KDC ticket,
261 - it is protected by the session key (or the sub-session key) of the
282 Kamada and Sakane [Page 5]
284 Internet-Draft Client-Friendly Cross-Realm February 2007
287 client C KDC-L KDC-I KDC-R
288 -------- ----- ----- -----
290 1. --------TGS-REQ-------->
291 2. [Reach to KDC-R in any way.]
292 [Below is an example of PKCROSS.]
293 ------------PKINIT------------>
294 <----------XTKT(L,R)-----------
295 3. <--TKT(C,R)w/XTKT(L,R)--
296 4. ----------------------TGS-REQ------------------------>
297 5. <---------------------TKT(C,S)------------------------
299 [Note: TKT(x,y) means a ticket whose cname is x and sname is y. ]
300 [ XTKT is an inter-KDC ticket. See PKCROSS. ]
301 [ The client C and KDC-L belong to the local realm L. ]
302 [ The KDC-I is a KDC of an intermediate realm I. ]
303 [ The KDC-R is a KDC of the remote realm R. ]
305 1. The client C sends a normal TGS-REQ to KDC-L, requesting
306 a cross-realm TGT to KDC-R.
307 2. KDC-L reaches KDC-R in any way and obtains a XTKT.
308 There is no standardized way to achieve this step yet.
309 PKCROSS is one candidate. We could also standardize a way
310 in which KDC-L normally transits to KDC-R and obtains an XTKT.
311 3. KDC-L generates a cross-realm TGT that is from C to KDC-R
312 and returns to it to C. [PKCROSS] [KRBEXT]
313 4. The same with the traditional cross-realm TGS.
314 5. The same with the traditional cross-realm TGS.
316 Figure 1: Message Flow of Temporary Inter-Realm Relationship
320 3.2. Attorney Ticketing Mode
322 Traditionally, a Kerberos client repeats TGS transactions until it
323 gets the final ticket. For example, it has a TGT for its own realm
324 and wants to get a ticket for a service in 3-hop neighbor realm, then
327 1) Present the TGT and get a cross-realm TGT for the next realm,
329 2) Present the 1st cross-realm TGT and get a cross-realm TGT for the
332 3) Present the 2nd cross-realm TGT and get a cross-realm TGT for the
338 Kamada and Sakane [Page 6]
340 Internet-Draft Client-Friendly Cross-Realm February 2007
343 4) Present the final cross-realm TGT and get a service ticket.
345 Attorney ticketing mode enables the client to delegate the KDC to
346 perform all transactions listed above on behalf of the client. The
347 client entrust the KDC with its TGT. The KDC "impersonates" the
348 client and perform necessary TGS transactions, and returns the final
349 ticket to the client.
351 client C KDC-L KDC-I KDC-R
352 -------- ----- ----- -----
354 1. --------TGS-REQ-------->
358 4. ------------TGS-REQ----------->
359 <-----------TKT(C,S)-----------
360 5. <-------TKT(C,S)--------
362 1. The client C sends a special TGS-REQ, which indicates attorney
363 ticketing mode requesting a service ticket for S instead of a
364 cross-realm TGT, to KDC-L.
365 2. KDC-L internally generates a cross-realm TGT that is from C
366 to KDC-I, but does not return it to C.
367 3. KDC-L uses generated cross-realm TGT by itself, and sends
368 a TGS-REQ to KDC-I, which requests a cross-realm TGT from C
370 4. KDC-L use the obtained cross-realm TGT by itself, and sends
371 a TGS-REQ to KDC-R, which requests a service ticket from C
373 5. KDC-L returns the final service ticket to C.
375 Figure 2: Message Flow of Attorney Ticketing Mode
378 3.3. Combination of the Two Modes
394 Kamada and Sakane [Page 7]
396 Internet-Draft Client-Friendly Cross-Realm February 2007
399 client C KDC-L KDC-I KDC-R
400 -------- ----- ----- -----
402 1. --------TGS-REQ-------->
403 2. [Below is PKCROSS for example.]
404 ------------PKINIT------------>
405 <----------XTKT(L,R)-----------
406 3. TKT(C,R)w/XTKT(L,R)
407 4. ------------TGS-REQ----------->
408 <-----------TKT(C,S)-----------
409 5. <-------TKT(C,S)--------
411 Figure 3: Message Flow When Temporary Inter-Realm
412 Relationship Generation Mode and Attorney Ticketing
416 4. Generality and Orthogonality of These Modes
418 - Compatibility with Traditional Kerberos Deployment
420 Temporary inter-realm relationship generation involves only KDCs.
421 From the viewpoint of a client (and a server), it seems that there
422 is a direct inter-realm relationship between two realms.
424 In short, temporary inter-realm relationship generation mode needs
425 to be deployed only in KDCs. The merit of this property is large,
426 because it does not affect large installed base of clients.
428 Attorney ticketing mode involves only a client and the local KDC.
429 From the viewpoint of the remote KDC, TGS-REQs from a KDC as an
430 attorney cannot be distinguished from those from a "genuine"
433 Resulting service ticket is identical to the traditional one, so
434 the remote server has nothing to do this mode.
436 In short, attorney ticketing mode can be deployed in local realm,
437 independently of the remote deployment. The merit of this
438 property is large, because remote realms are often in different
441 - Orthogonality of Temporary Inter-Realm Relationship Generation
442 Mode and Attorney Ticketing Mode
444 Temporary inter-realm relationship generation mode and attorney
445 ticketing mode are independent concepts. Both can be implemented
446 separately or can be used in combination. When they are combined,
450 Kamada and Sakane [Page 8]
452 Internet-Draft Client-Friendly Cross-Realm February 2007
455 load of clients are shifted to KDCs and additional load of KDCs
456 are minimized, thus efficient cross-realm environment is achieved.
459 5. Related Protocols Currently Proposed
464 PKCROSS will be usable as a protocol for temporary inter-realm
465 relationship generation mode.
470 The purpose of XTGS protocol is similar to that of this model, but
471 the behavior is somewhat different [XTGS]. If we dare to look at
472 XTGS from the viewpoint of this model, it blended the two mode
473 indivisibly and abandoned the abstraction of cross-realm TGTs and
474 inter-KDC tickets in compensation for reducing the number of messages
475 between KDCs as far as possible.
477 Once a front-end (i.e., between a client and a KDC) protocol to
478 request attorney ticketing mode is standardized, XTGS can be used as
482 6. Interoperability Considerations
484 [To be more considered...]
486 [anything to do with u2u?]
488 [negotiation of various parameters]
490 [when there are multiple transit paths...]
491 [if authz data is involved halfway...?]
493 [something to do with referral?]
497 [when a KDC in attorney mode receives a KRB-ERROR?]
506 Kamada and Sakane [Page 9]
508 Internet-Draft Client-Friendly Cross-Realm February 2007
511 7. Security Considerations
514 7.1. Denial of Service (DoS)
516 A KDC that implements attorney ticketing mode need to initiate
517 multiple TGS-REQ upon a request from a client. This means that the
518 KDC will have some states in it and may suffer from DoS attacks.
520 Fortunately, attorney ticketing mode can be requested in TGS-REQ,
521 which is only available to authenticated clients, thus, any untrusted
522 party cannot exploit this statefulness.
525 7.2. Ticketing Policy Enforcement
527 [attorney: no problem?]
529 [tmp inter-realm rel gen: ?]
534 8. IANA Considerations
536 This document has no actions for IANA.
541 The authors would like to acknowledge Saber Zrelli, Masahiro
542 Ishiyama, Atsushi Inoue, Kazunori Miyazawa, and Nobuo Okabe for
543 contributions to this document.
548 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
549 Kerberos Network Authentication Service (V5)", RFC
552 [CRPS] Sakane, S., Zrelli, S., M. Ishiyama, "Problem statement
553 on the cross-realm operation of Kerberos in a specific
554 system", draft-sakane-krb-cross-problem-statement-01,
555 Work in Progress, October 2006.
557 [KRBEXT] Yu, T., "The Kerberos Network Authentication Service
558 (Version 5)", draft-ietf-krb-wg-rfc1510ter-03, Work in
562 Kamada and Sakane [Page 10]
564 Internet-Draft Client-Friendly Cross-Realm February 2007
567 Progress, October 2006.
569 [PKCROSS] Hur, M. et al., "Public Key Cryptography for Cross-
570 Realm Authentication in Kerberos", draft-ietf-cat-
571 kerberos-pk-cross-08 (expired), Work in Progress,
574 [XTGS] Zrelli, S. et al., "XTGSP, the Inter-TGS protocol for
575 cross-realm operations in Kerberos", draft-zrelli-krb-
576 xtgsp-00, Work in Progress, November 2006.
582 Yokogawa Electric Corporation
583 2-9-32 Nakacho, Musashino-shi,
585 E-mail: Ken-ichi.Kamada@jp.yokogawa.com,
586 Shouichi.Sakane@jp.yokogawa.com
589 Full Copyright Statement
591 Copyright (C) The IETF Trust (2007).
593 This document is subject to the rights, licenses and restrictions
594 contained in BCP 78, and except as set forth therein, the authors
595 retain all their rights.
597 This document and the information contained herein are provided on an
598 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
599 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
600 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
601 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
602 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
603 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
605 Intellectual Property Statement
607 The IETF takes no position regarding the validity or scope of any
608 Intellectual Property Rights or other rights that might be claimed to
609 pertain to the implementation or use of the technology described in
610 this document or the extent to which any license under such rights
611 might or might not be available; nor does it represent that it has
612 made any independent effort to identify any such rights. Information
613 on the procedures with respect to rights in RFC documents can be
614 found in BCP 78 and BCP 79.
618 Kamada and Sakane [Page 11]
620 Internet-Draft Client-Friendly Cross-Realm February 2007
623 Copies of IPR disclosures made to the IETF Secretariat and any
624 assurances of licenses to be made available, or the result of an
625 attempt made to obtain a general license or permission for the use of
626 such proprietary rights by implementers or users of this
627 specification can be obtained from the IETF on-line IPR repository at
628 http://www.ietf.org/ipr.
630 The IETF invites any interested party to bring to its attention any
631 copyrights, patents or patent applications, or other proprietary
632 rights that may cover technology that may be required to implement
633 this standard. Please address the information to the IETF at ietf-
674 Kamada and Sakane [Page 12]