Network Working Group S. Zrelli Internet-Draft Y. Shinoda Expires: May 9, 2007 JAIST S. Sakane K. Kamada Yokogawa Electric Corp. M. Ishiyama Toshiba Corp. November 5, 2006 XTGSP, the Inter-TGS protocol for cross-realm operations in Kerberos. draft-zrelli-krb-xtgsp-00 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 May 9, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The XTGSP protocol defines an extension to the Kerberos protocol. This extension allows a KDC to build a TGS-REP message for services that are not registered in the local realm. Part of the components Zrelli, et al. Expires May 9, 2007 [Page 1] Internet-Draft XTGSP November 2006 of the TGS-REP message are obtained from the KDC where the service is registered. The communication between the local KDC and the remote KDC is encrypted using cross-realm keys maintained using the PKINIT extension. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and notations . . . . . . . . . . . . . . . . . . 4 3. Overview of the XTGSP extension . . . . . . . . . . . . . . . 5 4. Details of the XTGSP protocol . . . . . . . . . . . . . . . . 7 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Zrelli, et al. Expires May 9, 2007 [Page 2] Internet-Draft XTGSP November 2006 1. Introduction The cross-realm operations as specified in [RFC4120] have some shortcomings. These shortcomings include performance, reliability and safety issues. A separate problem statement document [I-D.sakane-krb-cross-problem-statement] analyzes these issues. The XTGSP proposal is an extension to the Kerberos protocol that defines a new cross-realm model for Kerberos. The aim of XTGSP is to solve some of the issues in the Kerberos cross-realm operations. The XTGSP protocol maintains does not add any data structure, it reuses the existing message components defined in the Kerberos V base specification [RFC4120] and in the PKINIT [RFC4556] specification. Finally, note that this document is derived from a previous Internet- Draft [I-D.zrelli-krb-xkdcp]. The specification of XTGSP in [I-D.zrelli-krb-xkdcp] was updated and improved according to the comments from the Kerberos-wg in IETF-66. Mainly these comments were about : o Re-use of PKINIT if possible, even if the usage is not semantically perfect. o Minimize the use of public-key operations to ensure best performance. For complete understanding of this specification, the reader is required to be familiar with [RFC4120] and [RFC4556]. Zrelli, et al. Expires May 9, 2007 [Page 3] Internet-Draft XTGSP November 2006 2. Terminology and notations 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]. The following terms are used in this document : KDC: The Kerberos Key Distribution center, it is composed of two logical components: Authentication Server (AS) and Ticket Granting Service (TGS). The KDC of the local realm is referred to as KDC-L, while the KDC of a remote realm is referred to as KDC-R. TGS: The TGS is the logical component of the KDC that delivers Service tickets and the associated session-key to clients. The TGS of the local realm is referred to as TGS-L and the TGS of the remote realm is referred to as TGS-R. Each TGS is registered in the database of its KDC as a service and shares a long key K(TGS,KDC) with it. K(X,Y): Represents a long-term key shared between the entities X and Y. For example, K(SVC,TGS-L) represents the long-term key shared between a certain service SVC and the local TGS. K(TGS- L,KDC-L) represents the long-term key shared between the TGS and the KDC of the local realm. Cross-realm key: A cross-realm key K(L,R) shared between the two realms L and R involves the registration of the TGS service of realm R (TGS-R) as a principal in realm L and the registration of the TGS service of realm L (TGS-L) as a principal in realm R. Both TGS-L/R and TGS-R/L share the same long term secret K(L,R) with KDC-R and KDC-L respectively. The cross-realm key has a life time, before using it the TGS MUST verify that the key is not expired. SK(X,Y): Represents a short-term session-key shared between the entities X and Y. For example, the session-key shared between a client C and a service SVC is represented as SK(C,SVC). TKT(X,Y,Z): Represents a Ticket delivered by Z to X, the service that with which this ticket will be used is Y. For example TKT(C,TGS-L,AS-L) represents a Ticket Granting Ticket (TGT) issued by AS-L (or KDC-L) for the client C to authenticate with the service TGS-L. Zrelli, et al. Expires May 9, 2007 [Page 4] Internet-Draft XTGSP November 2006 3. Overview of the XTGSP extension XTGSP is a protocol extension to the Kerberos protocol specification. It offers a new cross-realm protocol for Kerberos that addresses the issues stated in [I-D.sakane-krb-cross-problem-statement] In XTGSP, a client C MAY issue a TGS-REQ for a service SVC, registered in a remote realm R, to any TGS for which the client has a valid TGT. From the client's point of view, the local KDC delivers the service ticket as if the remote service was registered in the local realm. The cross-realm operations are managed by the local KDC and made transparent to the client. The XTGSP extension defines a protocol between two Kerberos key distribution centers (KDCs) that enables a KDC to build credentials even when the service is not registered in the KDC database. This allows clients to obtain credentials from their local KDC in a single round-trip without having to exchange messages with KDCs deployed in remote realms. The typical use of XTGSP is in remote access scenarios where a user has a TGT for a local TGS (TGS-L) and wishes to access a service deployed in a remote realm. When a client requests a service not registered in the local realm, then TGS-L uses the XTGSP protocol with the TGS of the remote realm (TGS-R) where the service is registered. The execution of the XTGSP exchange enables the local TGS to obtain the necessary materials needed to build the credentials requested by the client. More precisely, the local TGS needs to have a Ticket ``TKT(C,SVC-R,TGS-R)'' and build an ``EncTGSRepPart'' (As defined in [RFC4120]) that contains the key K(C,SVC-R). EncTGSRepPart is encrypted using the session-key ``K(C,TGS-L)'' and thus MUST be built by TGS-L. The key ``K(C,SVC-R)'' and the associated ticket ``TKT(C,SVC-R,TGS-R)'' MUST be built by the remote TGS and sent to the local TGS in a secure manner. Once these components are received, TGS-L can build a TGS-REP message containing the credentials requested by the client. The XTGSP protocol uses PKINIT [RFC4556] to maintain cross-realm keys that are used to secure the XTGSP exchanges. The PKINIT specification was designed for performing public-key authentication between a client and the KDC when the client and the KDC do not share long term secret key. The local TGS uses PKINIT when there is no cross-realm key, represented as K(L,R), between the local and the remote realm. Concerning the use of PKINIT, we distinguish two cases depending on Zrelli, et al. Expires May 9, 2007 [Page 5] Internet-Draft XTGSP November 2006 whether TGS-L and TGS-R share inter-realm key (represented as K(L,R)) or not. If the inter-realm key exists then it is used to secure the XTGSP exchange, and PKINIT is not used. If the key does not exist then the the PKINIT extension is used to secure the XTGSP exchange and to generate new inter-realm keys between TGS-L and TGS-R. Zrelli, et al. Expires May 9, 2007 [Page 6] Internet-Draft XTGSP November 2006 4. Details of the XTGSP protocol Assuming that a client C located in a realm L wishes to access a service SVC-R deployed in a remote realm R, and that the client C has a TGT for the TGS of the local realm L (TGS-L). We explain in this section how the XTGSP extension can be used to allow the client C to obtain a service ticket ``TKT(C,SVC-R,TGS-R)'' and the associated session from TGS-L. The operations of the XTGSP protocol differs depending on the existence of an inter-realm key between TGS-L and TGS-R. We distinguish two cases : Case 1 : When cross-realm key ``K(L,R)'' between the two realms exists o C -> TGS-L : TGS-REQ The client starts by sending a TGS-REQ (as defined in [RFC4120]) to the local TGS (TGS-L) asking for credentials required to access a certain remote service (SVC-R). The TGS-REQ message includes a TGT for TGS-L ``TKT(C,TGS-L,KDC-L)'' and an Authenticator. o TGS-L -> TGS-R : XTGSP-REQ When TGS-L receives a TGS-REQ for a service that is registered in a remote realm R, it initiates an XTGSP exchange by issuing an XTGSP-REQ message to the TGS of the remote realm (TGS-R). The XTGSP-REQ message consists of a copy of the client's TGS-REQ message to which an Authenticator is added. The Authenticator contains a check-sum over the TGS-REQ message and time-stamps. It is encrypted using the cross-realm key ``K(L,R)''. The Authenticator provides replay protection as well as message integrity and authentication. o TGS-R -> TGS-L : XTGSP-REP The remote TGS verifies the authenticator and builds an XTGSP-REP as follows: The XTGSP-REP is a TGS-REP message which consists of two main parts: a Ticket and an EncTGSRepPart. The Ticket (more precisely, the EncTicketPart of the Ticket) is encrypted using the secret key of the service SVC-R ``K(SVC-R,TGS-R)'', shared with TGS-R. The EncTGSRepPart is encrypted using the cross-realm key ``K(L,R)'' shared between TGS-L and TGS-R. Both the Ticket and the EncTGSRepPart contain a session-key field. The remote TGS puts the same key ``SK(C,SVC-R)'' in both fields. This session- key will be shared between the client and the service after the AP exchange. Zrelli, et al. Expires May 9, 2007 [Page 7] Internet-Draft XTGSP November 2006 o TGS-L -> C : TGS-REP The local TGS extracts and decrypts the EncTGSRepPart from the XTGSP-REP message, then encrypts it using the session-key shared with the client ``SK(C,TGS-L)''. The EncTGSRepPart and the Ticket are used to build a TGS-REP message for the client. The client processes the TGS-REP message as specified in [RFC4120]. Case 2 : When there is no cross-realm key shared between L and R o C -> TGS-L : TGS-REQ The client starts by sending a TGS-REQ (as defined in [RFC4120]) to the local TGS (TGS-L) asking for credentials required to access a certain remote service (SVC-R). The TGS-REQ message includes a TGT for TGS-L ``TKT(C,TGS-L,KDC-L)'' and an Authenticator. o TGS-L -> TGS-R : XTGSP-REQ When TGS-L receives a TGS-REQ for a service that is registered in a remote realm R, it initiates an XTGSP exchange by issuing an XTGSP-REQ message to the TGS of the remote realm (TGS-R). The XTGSP-REQ consists of the client's TGS-REQ message to which a PA- PK-AS-REQ (a PKINIT request) is added. The PA-PK-AS-REQ contains a check-sum over the TGS-REQ message and time-stamps. It is signed using the public-key of TGS-L. The PA-PK-AS-REQ provides replay protection as well as message integrity and authentication. o TGS-R -> TGS-L : XTGSP-REP The remote TGS verifies the PA-PK-AS-REQ and builds an XTGSP-REP as follows: The XTGSP-REP is an TGS-REP message which consists of two main parts: The Ticket and an EncTGSRepPart. The Ticket (more precisely, the EncTicketPart of the Ticket) is encrypted using the secret key of the service SVC (shared with TGS-R). The EncTGSRepPart is encrypted using a newly generated cross-realm key ``K(L,R)''. Both the Ticket and the EncTGSRepPart contain a session-key field. The remote TGS puts the key ``SK(C,SVC-R)'' in the key fields. The XTGSP-REP message also contains a PA-PK-AS- REP (a PKINIT reply). The PA-PK-AS-REP contains the cross-realm key ``K(L,R)''. It is encrypted using the public key of TGS-L, and signed using the private key of TGS-R. o TGS-L -> C : TGS-REP The local TGS decrypts the PA-PK-AS-REP using its public key and verifies the signature of TGS-R. The cross-realm key ``K(L,R)'' is then extracted from the PA-PK-AS-REP and used to decrypt the Zrelli, et al. Expires May 9, 2007 [Page 8] Internet-Draft XTGSP November 2006 EncTGSRepPart of the XTGSP-REP message. The EncTGSRepPart is then encrypted using the session-key ``SK(C,TS-L)'' shared with the client. The EncTGSRepPart and the Ticket (as provided by the remote TGS) are used to build a TGS-REP message for the client. Zrelli, et al. Expires May 9, 2007 [Page 9] Internet-Draft XTGSP November 2006 5. Security considerations [RFC4120] highlights several security considerations. Most of these considerations apply to a Kerberos KDC implementing the XTGSP extension. The current version of the document does not analyze possible security threats and considerations introduced by the XTGSP extension. 6. Normative References [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.zrelli-krb-xkdcp] Zrelli, S., "XKDCP, the Inter-KDC protocol for cross-realm operations in Kerberos.", draft-zrelli-krb-xkdcp-00 (work in progress), June 2006. [I-D.sakane-krb-cross-problem-statement] Sakane, S., "Problem statement on the cross-realm operation of Kerberos in a specific system", draft-sakane-krb-cross-problem-statement-00 (work in progress), October 2006. Zrelli, et al. Expires May 9, 2007 [Page 10] Internet-Draft XTGSP November 2006 Authors' Addresses Saber Zrelli Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 JAPAN Email: zrelli@jaist.ac.jp Yoichi Shinoda Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 JAPAN Email: shinoda@jaist.ac.jp Shoichi Sakane Yokogawa Electric Corporation 2-9-32 Nakacho Musashino-shi, Tokyo 180-8750 JAPAN Email: Shouichi.Sakane@jp.yokogawa.com Ken'ichi Kamada Yokogawa Electric Corporation 2-9-32 Nakacho Musashino-shi, Tokyo 180-8750 JAPAN Email: Ken-ichi.Kamada@jp.yokogawa.com Masahiro Ishiyama Toshiba Corporation 1, komukai-toshiba-cho Saiwai-ku, Kawasaki 212-8582 JAPAN Email: masahiro@isl.rdc.toshiba.co.jp Zrelli, et al. Expires May 9, 2007 [Page 11] Internet-Draft XTGSP November 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. Zrelli, et al. Expires May 9, 2007 [Page 12]