Network Working Group Ken'ichi Kamada INTERNET-DRAFT Shoichi Sakane Expires: August 25, 2007 Yokogawa Electric Corporation February 21, 2007 Client-Friendly Cross-Realm Model for Kerberos 5 draft-kamada-krb-client-friendly-cross-00.txt 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft expires on August 25, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Kamada and Sakane [Page 1] Internet-Draft Client-Friendly Cross-Realm February 2007 Abstract This document proposes a cross-realm transition model, which is friendly to resource-limited clients. This model provides a way to move the cost of consecutive Ticket-Granting Service (TGS) exchanges from the clients to the KDC and a way to reduce the transition cost by generating a direct inter-realm relationship between two realms. The document itself does not specify any protocols, which need to be specified separately. Table of Contents 1. Introduction ................................................. 3 2. Problems on Client Performance ............................... 3 2.1. Long Authentication Path ................................ 4 2.2. Client-Centric Ticketing ................................ 4 3. Proposal of Client-Friendly Cross-Realm Model ................ 4 3.1. Temporary Inter-Realm Relationship Generation Mode ...... 5 3.2. Attorney Ticketing Mode ................................. 6 3.3. Combination of the Two Modes ............................ 7 4. Generality and Orthogonality of These Modes .................. 8 5. Related Protocols Currently Proposed ......................... 9 5.1. PKCROSS ................................................. 9 5.2. XTGS .................................................... 9 6. Interoperability Considerations .............................. 9 7. Security Considerations ...................................... 10 7.1. Denial of Service (DoS) ................................. 10 7.2. Ticketing Policy Enforcement ............................ 10 8. IANA Considerations .......................................... 10 9. Acknowledgments .............................................. 10 10. References ................................................... 10 Authors' Addresses ............................................... 11 Full Copyright Statement ......................................... 11 Intellectual Property Statement .................................. 11 Kamada and Sakane [Page 2] Internet-Draft Client-Friendly Cross-Realm February 2007 1. Introduction Kerberos Version 5 [RFC4120] has a concept of cross-realm authentication so that principals in different realms can authenticate each other. However in the current cross-realm model, each client has to traverse the authentication path, and the load of the traversal is not negligible for clients with limited resources, e.g., computational speed or power supply [CRPS]. In the current cross-realm operation, a client obtains a service ticket for a remote principal in the following steps: 1) (Number of transit) TGSes to get cross-realm TGTs in order to traverse the intermediate realms, and 2) One TGS to get the final service ticket. That is, a client need to perform (number of transits) + 1 transactions to obtain a ticket for a remote service. This document proposes a new cross-realm model, which consists of "temporary inter-realm relationship generation mode" and "attorney ticketing mode". The former is intended to reduce the transition cost itself, on the other hand, the latter is to move the cost from clients to KDCs. The document does not specify any protocols, which need to be specified separately. Terms defined in section 1.7 of RFC 4120 are used throughout this document. 2. Problems on Client Performance In the current model of cross-realm operation, a client has to transit all realms on the path to the destination realm. If the source realm and the destination realm have a direct inter-realm relationship, a client is able to obtain a service ticket with two TGS transactions (one for a cross-realm TGT and one for the service ticket), but if there is an only multi-hop relationship between the realms, client's job increases in proportion to the distance of the relationship. Two issues can be observed here behind the client load, which are described in the following subsections. Kamada and Sakane [Page 3] Internet-Draft Client-Friendly Cross-Realm February 2007 2.1. Long Authentication Path When a client wants to get a service ticket for a remote realm, it must transit to the remote realm by traversing the intermediate realms on the authentication path to the remote realm. The result of a transition is cached as a cross-realm TGT, nonetheless, it is a per-client optimization. Thus all clients accessing a remote realm must pay the cost separately, even if their resource are limited. For a long authentication path, the cost of the whole system becomes large. 2.2. Client-Centric Ticketing In Kerberos, any service tickets or cross-realm TGTs are issued via TGS, where a client present a ticket for the TGS and obtains a next ticket. Currently, all TGS transactions are initiated by the client and it need to get all necessary cross-realm TGTs iteratively before the final service ticket. This process is a burden to a resource- limited client. 3. Proposal of Client-Friendly Cross-Realm Model In this section, two modes of operation are introduced, "Temporary Inter-Realm Relationship Generation Mode" and "Attorney Ticketing Mode", to solve the issues described in the previous section. Temporary Inter-Realm Relationship Generation Mode This is introduced to solve the issue of the long authentication path. In this mode, if the source realm and the destination realm do not have a direct inter-realm relationship, the source KDC traverses the authentication path by itself, contacts with the remote KDC, and generates a direct inter-realm relationship between them. After that, the source KDC can issue direct inter- realm TGTs for the destination realm. The purpose of this mode is to reduce the transition cost itself. Attorney Ticketing Mode This is introduced to solve the issue of the client-centric ticketing. Consecutive TGS transactions to get cross-realm TGTs and/or a final service ticket are initiated by a client in the traditional Kerberos, but in this mode, a KDC undertake it. The purpose of this mode is to shift the cost of TGSes from a client to a KDC. This does not reduce the cost itself. These two modes are designed to be independent, that is, can be used separately or in combination. Kamada and Sakane [Page 4] Internet-Draft Client-Friendly Cross-Realm February 2007 3.1. Temporary Inter-Realm Relationship Generation Mode Temporary inter-realm relationship generation mode enables a KDC to issue an inter-realm TGT directly to a remote KDC with which the KDC doesn't preshare an inter-realm key. To issue an inter-realm TGT directly, a temporary inter-realm key needs to be provided somehow. To achieve that, the local KDC obtains a special ticket for the remote KDC and use its session key as an inter-realm key. This methodology was introduced by PKCROSS [PKCROSS]. In this document, that special ticket is called as an "inter-KDC ticket", and an inter- realm TGT generated using an inter-KDC ticket as a "direct inter- realm TGT". How does the local KDC reach the remote KDC is out of scope of this model, but we can easily come up with 1) traversing a long authentication path if available or 2) using PKINIT. That is, PKCROSS is interpreted as a combination of this model and PKINIT. This document does not standardize a specific protocol, but a inter- KDC ticket will have the following form: - its sname has a special form (PKCROSS proposes "pkcross/realm@REALM", but it would be better to use a more general name than "pkcross"), and a direct inter-realm TGT will have the following form: - its TicketExtensions field [KRBEXT] contains the inter-KDC ticket, and - it is protected by the session key (or the sub-session key) of the inter-KDC ticket. Kamada and Sakane [Page 5] Internet-Draft Client-Friendly Cross-Realm February 2007 client C KDC-L KDC-I KDC-R -------- ----- ----- ----- 1. --------TGS-REQ--------> 2. [Reach to KDC-R in any way.] [Below is an example of PKCROSS.] ------------PKINIT------------> <----------XTKT(L,R)----------- 3. <--TKT(C,R)w/XTKT(L,R)-- 4. ----------------------TGS-REQ------------------------> 5. <---------------------TKT(C,S)------------------------ [Note: TKT(x,y) means a ticket whose cname is x and sname is y. ] [ XTKT is an inter-KDC ticket. See PKCROSS. ] [ The client C and KDC-L belong to the local realm L. ] [ The KDC-I is a KDC of an intermediate realm I. ] [ The KDC-R is a KDC of the remote realm R. ] 1. The client C sends a normal TGS-REQ to KDC-L, requesting a cross-realm TGT to KDC-R. 2. KDC-L reaches KDC-R in any way and obtains a XTKT. There is no standardized way to achieve this step yet. PKCROSS is one candidate. We could also standardize a way in which KDC-L normally transits to KDC-R and obtains an XTKT. 3. KDC-L generates a cross-realm TGT that is from C to KDC-R and returns to it to C. [PKCROSS] [KRBEXT] 4. The same with the traditional cross-realm TGS. 5. The same with the traditional cross-realm TGS. Figure 1: Message Flow of Temporary Inter-Realm Relationship Generation 3.2. Attorney Ticketing Mode Traditionally, a Kerberos client repeats TGS transactions until it gets the final ticket. For example, it has a TGT for its own realm and wants to get a ticket for a service in 3-hop neighbor realm, then it will: 1) Present the TGT and get a cross-realm TGT for the next realm, 2) Present the 1st cross-realm TGT and get a cross-realm TGT for the 2nd next realm, 3) Present the 2nd cross-realm TGT and get a cross-realm TGT for the final realm, and Kamada and Sakane [Page 6] Internet-Draft Client-Friendly Cross-Realm February 2007 4) Present the final cross-realm TGT and get a service ticket. Attorney ticketing mode enables the client to delegate the KDC to perform all transactions listed above on behalf of the client. The client entrust the KDC with its TGT. The KDC "impersonates" the client and perform necessary TGS transactions, and returns the final ticket to the client. client C KDC-L KDC-I KDC-R -------- ----- ----- ----- 1. --------TGS-REQ--------> 2. TKT(C,I) 3. ----TGS-REQ----> <---TKT(C,R)---- 4. ------------TGS-REQ-----------> <-----------TKT(C,S)----------- 5. <-------TKT(C,S)-------- 1. The client C sends a special TGS-REQ, which indicates attorney ticketing mode requesting a service ticket for S instead of a cross-realm TGT, to KDC-L. 2. KDC-L internally generates a cross-realm TGT that is from C to KDC-I, but does not return it to C. 3. KDC-L uses generated cross-realm TGT by itself, and sends a TGS-REQ to KDC-I, which requests a cross-realm TGT from C to KDC-R. 4. KDC-L use the obtained cross-realm TGT by itself, and sends a TGS-REQ to KDC-R, which requests a service ticket from C to S. 5. KDC-L returns the final service ticket to C. Figure 2: Message Flow of Attorney Ticketing Mode 3.3. Combination of the Two Modes Kamada and Sakane [Page 7] Internet-Draft Client-Friendly Cross-Realm February 2007 client C KDC-L KDC-I KDC-R -------- ----- ----- ----- 1. --------TGS-REQ--------> 2. [Below is PKCROSS for example.] ------------PKINIT------------> <----------XTKT(L,R)----------- 3. TKT(C,R)w/XTKT(L,R) 4. ------------TGS-REQ-----------> <-----------TKT(C,S)----------- 5. <-------TKT(C,S)-------- Figure 3: Message Flow When Temporary Inter-Realm Relationship Generation Mode and Attorney Ticketing Mode Are Combined 4. Generality and Orthogonality of These Modes - Compatibility with Traditional Kerberos Deployment Temporary inter-realm relationship generation involves only KDCs. From the viewpoint of a client (and a server), it seems that there is a direct inter-realm relationship between two realms. In short, temporary inter-realm relationship generation mode needs to be deployed only in KDCs. The merit of this property is large, because it does not affect large installed base of clients. Attorney ticketing mode involves only a client and the local KDC. From the viewpoint of the remote KDC, TGS-REQs from a KDC as an attorney cannot be distinguished from those from a "genuine" client. [except caddr] Resulting service ticket is identical to the traditional one, so the remote server has nothing to do this mode. In short, attorney ticketing mode can be deployed in local realm, independently of the remote deployment. The merit of this property is large, because remote realms are often in different administration. - Orthogonality of Temporary Inter-Realm Relationship Generation Mode and Attorney Ticketing Mode Temporary inter-realm relationship generation mode and attorney ticketing mode are independent concepts. Both can be implemented separately or can be used in combination. When they are combined, Kamada and Sakane [Page 8] Internet-Draft Client-Friendly Cross-Realm February 2007 load of clients are shifted to KDCs and additional load of KDCs are minimized, thus efficient cross-realm environment is achieved. 5. Related Protocols Currently Proposed 5.1. PKCROSS PKCROSS will be usable as a protocol for temporary inter-realm relationship generation mode. 5.2. XTGS The purpose of XTGS protocol is similar to that of this model, but the behavior is somewhat different [XTGS]. If we dare to look at XTGS from the viewpoint of this model, it blended the two mode indivisibly and abandoned the abstraction of cross-realm TGTs and inter-KDC tickets in compensation for reducing the number of messages between KDCs as far as possible. Once a front-end (i.e., between a client and a KDC) protocol to request attorney ticketing mode is standardized, XTGS can be used as an opaque back-end. 6. Interoperability Considerations [To be more considered...] [anything to do with u2u?] [negotiation of various parameters] [when there are multiple transit paths...] [if authz data is involved halfway...?] [something to do with referral?] [transited field?] [when a KDC in attorney mode receives a KRB-ERROR?] Kamada and Sakane [Page 9] Internet-Draft Client-Friendly Cross-Realm February 2007 7. Security Considerations 7.1. Denial of Service (DoS) A KDC that implements attorney ticketing mode need to initiate multiple TGS-REQ upon a request from a client. This means that the KDC will have some states in it and may suffer from DoS attacks. Fortunately, attorney ticketing mode can be requested in TGS-REQ, which is only available to authenticated clients, thus, any untrusted party cannot exploit this statefulness. 7.2. Ticketing Policy Enforcement [attorney: no problem?] [tmp inter-realm rel gen: ?] [learn from PKCROSS] 8. IANA Considerations This document has no actions for IANA. 9. Acknowledgments The authors would like to acknowledge Saber Zrelli, Masahiro Ishiyama, Atsushi Inoue, Kazunori Miyazawa, and Nobuo Okabe for contributions to this document. 10. References [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [CRPS] Sakane, S., Zrelli, S., M. Ishiyama, "Problem statement on the cross-realm operation of Kerberos in a specific system", draft-sakane-krb-cross-problem-statement-01, Work in Progress, October 2006. [KRBEXT] Yu, T., "The Kerberos Network Authentication Service (Version 5)", draft-ietf-krb-wg-rfc1510ter-03, Work in Kamada and Sakane [Page 10] Internet-Draft Client-Friendly Cross-Realm February 2007 Progress, October 2006. [PKCROSS] Hur, M. et al., "Public Key Cryptography for Cross- Realm Authentication in Kerberos", draft-ietf-cat- kerberos-pk-cross-08 (expired), Work in Progress, November 2001. [XTGS] Zrelli, S. et al., "XTGSP, the Inter-TGS protocol for cross-realm operations in Kerberos", draft-zrelli-krb- xtgsp-00, Work in Progress, November 2006. Authors' Addresses Ken'ichi Kamada Shoichi Sakane Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo 180-8750 Japan E-mail: Ken-ichi.Kamada@jp.yokogawa.com, Shouichi.Sakane@jp.yokogawa.com Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. 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. Kamada and Sakane [Page 11] Internet-Draft Client-Friendly Cross-Realm February 2007 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. Kamada and Sakane [Page 12]