Network Working Group S. Zrelli Internet-Draft Y. Shinoda Expires: December 19, 2006 JAIST S. Sakane K. Kamada Yokogawa Electric Corp. M. Ishiyama Toshiba Corp. June 17, 2006 XKDCP, the Inter-KDC protocol for cross-realm operations in Kerberos. draft-zrelli-krb-xkdcp-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 December 19, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo proposes protocol extensions to the Kerberos protocol specification. The extension (hereafter called XKDCP) offers a new cross-realm protocol for Kerberos. The XKDCP extension defines a Zrelli, et al. Expires December 19, 2006 [Page 1] Internet-Draft XKDCP June 2006 protocol between Kerberos Key Distribution Centers (KDCs) that allows a KDC to build credentials even when the client or the requested service is not registered in the KDC's database (but registered in another KDC's database). The XKDCP extension defines two protocols: XTGSP (Inter Ticket Granting Service Protocol) and XASP (Inter Authentication Service Protocol). The XTGSP protocol can be used in remote access scenarios to allow the local KDC to deliver credentials for services located in remote realms. On the other hand, the XASP protocol can be used in case of cross-realm roaming scenarios to allow the visited KDC to deliver credentials for roaming users. Zrelli, et al. Expires December 19, 2006 [Page 2] Internet-Draft XKDCP June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Kerberos basic operations . . . . . . . . . . . . . . . . 4 1.2 Kerberos cross-realm operations . . . . . . . . . . . . . 6 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.4 Overview of the extension . . . . . . . . . . . . . . . . 9 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Inter realm trust model . . . . . . . . . . . . . . . . . 11 2.2 Exposure of the KDC . . . . . . . . . . . . . . . . . . . 12 2.3 Client centralized exchanges . . . . . . . . . . . . . . . 12 2.4 Pre-authentication problem in roaming scenarios . . . . . 12 3. XKDCP: the cross-realm authentication protocol . . . . . . . . 13 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Overview of the XTGSP extension . . . . . . . . . . . . . 13 3.3 Overview of the XASP extension . . . . . . . . . . . . . . 17 3.4 The XKDCP padata . . . . . . . . . . . . . . . . . . . . . 20 3.5 XTGSP protocol details . . . . . . . . . . . . . . . . . . 23 3.5.1 The KRB_TGS_REQ message . . . . . . . . . . . . . . . 23 3.5.2 The XTGSP-REQ message . . . . . . . . . . . . . . . . 24 3.5.3 The XTGSP-REP message . . . . . . . . . . . . . . . . 25 3.5.4 The KRB_TGS_REP message . . . . . . . . . . . . . . . 27 3.6 The XASP protocol details . . . . . . . . . . . . . . . . 29 3.6.1 The KRB_AS_REQ message . . . . . . . . . . . . . . . . 29 3.6.2 The XASP-REQ message . . . . . . . . . . . . . . . . . 29 3.6.3 The XASP-REP message . . . . . . . . . . . . . . . . . 31 3.6.4 The KRB_AS_REP message . . . . . . . . . . . . . . . . 33 3.7 Realm policy . . . . . . . . . . . . . . . . . . . . . . . 35 4. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1 XKDCP error codes . . . . . . . . . . . . . . . . . . . . 37 4.2 XKDCP message types . . . . . . . . . . . . . . . . . . . 37 5. Security considerations . . . . . . . . . . . . . . . . . . . 38 5.1 Integrity protection . . . . . . . . . . . . . . . . . . . 38 5.2 Confidentiality . . . . . . . . . . . . . . . . . . . . . 38 5.3 DoS and replay protection . . . . . . . . . . . . . . . . 38 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 7. Normative References . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 A. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . 44 Zrelli, et al. Expires December 19, 2006 [Page 3] Internet-Draft XKDCP June 2006 1. Introduction 1.1 Kerberos basic operations Kerberos [RFC4120] is a widely deployed authentication system. The authentication process in Kerberos involves principals and a Key Distribution Center (KDC). The principals can be users or services. Each KDC maintains a principals database and shares a secret key with each registered principal. The authentication process allows a user to acquire the needed credentials from the KDC. These credentials allow services to authenticate the users before granting them access to the resources. An important part of the credentials are called Tickets. There are two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket (ST). The TGT is obtained periodically from the KDC and has a limited limit after which it expires and the user must renew it. The TGT is used to obtain the other kind of tickets (Service Tickets). The user obtains the TGT from the Authentication Service (AS), a logical component of the KDC. The process of obtaining a TGT is referred to as 'AS exchange'. When a TGT request is issued by some user, the AS responds by sending a reply packet containing the credentials which consists of the TGT along with a random key called 'TGS Session Key'. The TGT contains a set of information encrypted using a secret key associated with a special service referred to as TGS (Ticket Granting Service). The TGS session key is encrypted using the user's key so that the user can obtain the TGS session key only if she knows the secret key shared with the KDC. The TGT then is used to obtain Service Tickets from the Ticket Granting Service (TGS)- the second component of the KDC. The process of obtaining service tickets is referred to as 'TGS exchange'. The request for a service ticket consists on a packet containing a TGT and an 'Authenticator'. The Authenticator is encrypted using the TGS session key and contains the identity of the user as well as time- stamps (for protection against replay attacks). After decrypting the TGT (which was encrypted by the AS using the TGS's secret key), the TGS extracts the TGS session key. Using that session key, it decrypts the Authenticator and authenticates the user. Finally, the TGS issues the credentials requested by the user, these credentials consists on a service ticket and a session key that will be used to authenticate the user with the desired application service. Figure 1 shows the different exchanges between the client, the KDC and the service. Zrelli, et al. Expires December 19, 2006 [Page 4] Internet-Draft XKDCP June 2006 KDC +-------------------------------+ +---------+ Client | AS TGS | | SVC | | +----+--------------------+-----+ +----+----+ | | | | | KRB_AS_REQ [1] | | | | -----------------------> | | | | | | | | KRB_AS_REP [2] | | | | <----------------------- | | | | | | | | KRB_TGS_REQ [3] | | | --------------------------------------------> | | | | | | | KRB_TGS_REP [4] | | | <-------------------------------------------- | | | | | | | | | | | | | | | KRB_AP_REQ [5] | | -----------------------------------------------------------> | | | | | | KRB_AP_REP [6] | | <----------------------------------------------------------- | | | | | | | | | Zrelli, et al. Expires December 19, 2006 [Page 5] Internet-Draft XKDCP June 2006 [1] Client -> AS : Client_ID, Nonce1 [2] AS -> Client : [Client_ID, TimeStamp1, TGS_SK]_TGS_K, [Nonce1, TGS_SK]_Client_K [3] Client -> TGS : [Client_ID, TimeStamp1, TGS_SK]_TGS_K, [Client_ID, TimeStamp2]_TGS_SK, SVC_ID, Nonce2 [4] TGS -> Client : [Client_ID, TimeStamp3, SK]_SVC_K, [Nonce2, SK]_TGS_SK [5] Client -> SVC : [Client_ID, TimeStamp3, SK]_SVC_K, [Client_ID, TimeStamp4]_SK, [6] SVC -> Client : [Client_ID, TimeStamp4]_SK Notation : ---------- Client_ID : Principal name of the client [A]_x : Content A is encrypted using secret key x A_K : Secret key of principal A TGS_SK : TGS session key SK : Session key SVC : An application service SVC_ID : Principal name of the application service Figure 1: The Kerberos Protocol exchanges For more details about the different exchanges and the exact message specifications, refer to [RFC4120]. 1.2 Kerberos cross-realm operations The Kerberos protocol offers cross-realm authentication capabilities. This allows users to obtain service tickets to access resources in foreign realms. In order to access such services, the users first contact their home KDC asking for a TGT that will be used with the TGS of the foreign realm (message 1 of Figure 2). If the home realm and the foreign realm share keys and have an established trust relationship, the home KDC delivers the requested TGT. However, if the home realm does not share cross-realm keys with the foreign realm, the home KDC will provide a TGT that can be used with an intermediary foreign realm that is likely to be sharing cross- Zrelli, et al. Expires December 19, 2006 [Page 6] Internet-Draft XKDCP June 2006 realm keys with the target realm (message 2 of Figure 2). The client can use this 'intermediary TGT' to communicate with the intermediary KDC (message 3 of Figure 2) which will iterate the actions taken by the home KDC: If the intermediary KDC does not share cross-realm keys with the target foreign realm it will point the user to another intermediary KDC (just as in the first exchange between the user and its home KDC). However, in the other case (when it shares cross- realm keys with the target realm), the intermediary KDC will issue a TGT that can be used with the KDC of the target realm (message 4 of Figure 2). After obtaining a TGT for the desired foreign realm, the client uses it to obtain service tickets from the TGS of the foreign realm (messages 5 and 6 of Figure 2). Finally the user authenticates to the service using the service ticket. Figure 2 shows the exchanges between the different entities involved in a cross-realm authentication aiming at delivering a service ticket to a client when the service is deployed in a foreign realm. Zrelli, et al. Expires December 19, 2006 [Page 7] Internet-Draft XKDCP June 2006 +-------+ | | ST-SRV? 5 | KDC-T | 6 ST-SRV +-------------------->| |---------------------+ | +-------+ | | | | +-------+ | | TGT-T? 3 | | 4 TGT-T | | +------------->| KDC-I |--------------+ | | | | | | | | | +-------+ | | | | | | | | +-------+ | | | | TGT-T? 1 | | 2 TGT-I | | | | +------>| KDC-H |-------+ | | | | | | | | | | | | | +-------+ | | | | | | | | | | | | | | | | | +------ +--------+ <----+ | | | +------------- | Client | <-----------+ | +-------------------- +--------+ <------------------+ H : Home realm I : Intermediary realm T : Target realm KDC-X : KDC of realm X (where X in {H,I,T}) TGT-X ?: A KRB_TGS_REQ requesting a TGT for realm X ST-SRV?: A KRB_TGS_REQ requesting a service ticket for service SRV TGT-X : A KRB_TGS_REP that contains a a TGT for realm X ST-SRV : A KRB_TGS_REP that contains a service ticket for service SRV Figure 2: The Kerberos Protocol exchanges for cross-realm operations 1.3 Terminology 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 : Zrelli, et al. Expires December 19, 2006 [Page 8] Internet-Draft XKDCP June 2006 Local realm : The realm where the client is physically (or topologically) located. The client can be a registered user or principal in the local realm or she can be a visitor in the local realm. Remote realm : A realm that is different from the local realm. Home realm : The realm where the client is registered as a Kerberos principal. Foreign realm : A realm that is different from the home realm. Roaming client/user : A user that is being physically (or topologically) located in a realm that is not her home realm. Visited realm : When a client is in a roaming situation, the realm where she is located is referred to as the visited realm. The visited realm is considered as a local realm from the client's point of view. TGS session key : The session key that is shared between the TGS and the client. This session key corresponds to the field 'key' of the EncASRepPart in the TGS-REP message. Service session key : The session key that is shared between the service and the client. This session key corresponds to the field 'key' of the EncTGSRepPart in the AS-REP message. TGS : The KDC is logically divided into two main services, one of these services is the TGS (Ticket Granting Service), the TGS provides service tickets to clients with valid TGTs AS : The authentication service (AS), is the part of the KDC that authenticates clients and delivers TGTs. 1.4 Overview of the extension The extension described in this document augments the specification of the Kerberos protocol as follows : o Extension of the TGS exchange : * Clients can issue KRB_TGS_REQ [RFC4120] messages to any KDC for which they have a valid TGT. * When a KRB_TGS_REQ message can not be processed by the TGS because the requested service is registered in a different Zrelli, et al. Expires December 19, 2006 [Page 9] Internet-Draft XKDCP June 2006 realm, then the TGS issues a message to the TGS of the remote realm (where the service is registered) requesting a service ticket and the associated service session key, on behalf of the client. The communication between the two KDCs is protected using public key cryptography. o Extension of the AS exchange : * Clients can issue KRB_AS_REQ [RFC4120] messages to any KDC in order to a obtain TGT for that KDC. * when a client issues a KRB_AS_REQ message [RFC4120] to a KDC where she is not registered, the foreign KDC identifies the client's home realm and initiates an exchange with client's home KDC. The result of this exchange is that the foreign KDC has all the required information to build the KRB_AS_REP message [RFC4120] and send it to the client. This exchange between the two KDCs is protected and authenticated using the public-keys of both KDCs. Zrelli, et al. Expires December 19, 2006 [Page 10] Internet-Draft XKDCP June 2006 2. Motivations This document defines an alternative to Kerberos cross-realm operations as specified in [RFC4120]. The protocol, here after called XKDCP, defines exchanges between KDCs when cross-realm operations are involved. The motivations behind this extension are to fulfill new needs and enhance the cross-realm operations in general. There are several aspects in the Kerberos-cross realm operations that can benefit from enhancement. In certain cases, the semantic of the current cross-realm protocol introduces security risks, in other cases, the Kerberos protocol can not be used at all. The following sections list the aspects where the Kerberos cross-realm protocol can be enhanced. The actual extension defined in this document aims at resolving all these issues. 2.1 Inter realm trust model Kerberos offers cross-realm authentication that allows users to access services managed by foreign realms. The cross-realm operations assumes that realms have a direct or indirect trust relationships. A direct trust relationship means that the realms involved in the cross-realm authentication share keys and their respective TGS principals are registered in each other's KDC. When direct trust relationships are used, the KDC of each realm must maintain keys with all foreign realms. This can become a cumbersome task when the number of realms increase. Therefore, cross-realm authentication based on indirect trust relationships, offer better scalability. Indirect trust relationship means that there is a 'chain of trust' linking the two realms. This can be performed by having a common trusted realm or a chain of intermediary trusted realms. When the realms belong to the same institution, a chain of trust can be determined by the client or the KDC by following the DNS domain hierarchy and supposing that the parent domains share keys with all its child sub-domains. However, when the inter-realm trust model does not follow the hierarchic approach, the trust path must be specified manually. When intermediary realms are involved, the success of the cross-realm authentication completely depends on the realms that are part of the authentication path. If any of the realms in the authentication path is not available, then the principals of the end-realms can not perform cross-realm operations. Moreover, as described in [CJSW05] Zrelli, et al. Expires December 19, 2006 [Page 11] Internet-Draft XKDCP June 2006 any KDC in the authentication path can learn the session key that will be used between the client and the desired service, this means that any intermediary realm is able to spoof the identify of the service and the client as well as to eavesdrop on the communication between the client and the server. 2.2 Exposure of the KDC One of the assumption made when allowing cross-realm operations in Kerberos is that users can communicate with KDCs located in remote realms. This practice introduces security threats because KDCs are open to the public. Administrators may think of restricting the access to the KDC to the trusted realms only. However, this approach is not scalable and does not really protect the KDC. Indeed, when the remote realms have several IP prefixes (e.g. a company with offices located world wide), then the administrator of the local KDC must collect the list of prefixes that belong to this company. The Filtering rules must then explicitly allow the incoming traffic from any host that belongs to one of these prefixes. This makes the administrator's tasks more complicated and prone to human errors. On the other hand, when ranges of external IP addresses are allowed to communicate with the KDC, the risk of becoming target to attacks from remote malicious users increases. 2.3 Client centralized exchanges In the cross-realm operations, Kerberos clients have to perform TGS exchanges with all the KDCs in the trust path, including the home KDC and the target KDC. In some cases where the client has limited computational capabilities, the overhead of these cross-realm exchanges may grow into unacceptable delays. Furthermore, if the number or intermediary realms increases, the delay introduced by the cross-realm messages can result in unacceptable delays. 2.4 Pre-authentication problem in roaming scenarios In roaming scenarios, the client needs to contact her home KDC to obtain a cross-realm TGT for the local (or visited) realm. However, the policy of the network access providers usually does not allow clients to communicate with hosts in the Internet unless they provide valid authentication credentials. In this manner, the client falls in a deadlock situation where two resources are inter-dependent; the Internet connection is needed to contact the home KDC and for obtaining credentials, and on the other hand, the Internet connection is only granted for clients who have valid credentials. As a result, the Kerberos protocol can not be used as it is for authenticating roaming clients requesting network access. Zrelli, et al. Expires December 19, 2006 [Page 12] Internet-Draft XKDCP June 2006 3. XKDCP: the cross-realm authentication protocol 3.1 Introduction In the standard Kerberos specification, when a client wishes to obtain credentials for a certain service, she must issue a request for a service ticket to the KDC where the service is registered. The XKDCP extension allows the client to obtain the service ticket from any KDC for which she already has a TGT. On the other hand, the XKDCP extension allows a client to obtain a TGT for any KDC after only one AS exchange with the target KDC. XKDCP extends the Kerberos protocol [RFC4120] by adding two exchanges called XASP and XTGSP. o XTGSP (Inter-TGS Protocol) : When a TGS can not process a request for a service ticket because the service's realm is different from the TGS's realm, then the XTGSP protocol can be used between the TGS of both realms to build the desired service ticket. When XTGSP is used, the client does not need to communicate with the KDC in which the service is registered. The TGSs for which the client has already obtained a TGT is capable of delivering the service ticket after using the XTGSP protocol with the remote TGS. o XASP (Inter-AS Protocol) : When an AS can not process a client request (a KRB_AS_REQ message) because the client does not belong to the local realm, the XASP extension can be used between the visited AS and the home AS to build the required credentials (a TGT) for the roaming client. XASP and XTGSP extend the Kerberos messages by exploiting the pre- authentication data field 'padata' in the KRB_KDC_REQ and KRB_KDC_REP messages [RFC4120]. The 'padata' field is used as a typed hole and employed to convey information related to the XKDCP protocol. The specification of the new padata type is detailed in Section 3.4. The details of the XASP and the XTGSP protocols can be found in Section 3.6 and Section 3.5 respectively. 3.2 Overview of the XTGSP extension XTGSP allows users to obtain service tickets from a KDC even if the service is not registered in that KDC. The typical use of XTGSP is in remote access scenarios where a user has a TGT for a local KDC and wishes to access a service deployed in a remote realm. The advantage of using the XTGSP protocol is that the client does not need to have a cross-realm TGT for the target Zrelli, et al. Expires December 19, 2006 [Page 13] Internet-Draft XKDCP June 2006 realm deploying the service. Moreover, the client does not need to contact the remote KDC at all since the local KDC will deliver the service ticket that can be used directly to authenticate with the remote service. In fact, 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 local KDC uses the XTGSP protocol with the KDC of the realm where the service is registered. As a result of the XTGSP exchange, the local KDC acquires enough materials to be able to deliver the requested service ticket to the client. Figure 3 represents the different exchanges in a cross-realm operation, based on the XTGSP protocol, for delivering service ticket to a client. | | | +-------+ (2) XTGSP-REQ +-------+ | |<-----------------------------------| | | TGS-R | XTGSP-REP (3) | TGS-L | | |----------------------------------->| | +-------+ | +-------+ | ^ | | | | +-------+ | (1)| |(4) | SRV-R | | KRB_TGS_REQ | | KRB_TGS_REP +-------+ | | | | | v | +------+ | |Client| | +------+ | Remote Realm (R) | Local Realm (L) Zrelli, et al. Expires December 19, 2006 [Page 14] Internet-Draft XKDCP June 2006 client : A client that has a TGT for the local realm L TGS-L : The TGS of the local realm L TGS-R : The TGS of the remote realm R SRV-R : A service registered in the remote realm R KRB_TGS_REQ : A message requesting service ticket for the remote service SRV-R KRB_TGS_REP : A message containing a service ticket for the servie SRV-R Figure 3: The Inter-TGS protocol In the following, we assume that the client has already obtained a TGT that can be used with the TGS of the local realm (TGS-L). 1. Client -> TGS-L : KRB_TGS_REQ The client sends a KRB_TGS_REQ [RFC4120] to the local TGS asking for credentials required to access a certain remote service (SRV-R). The KRB_TGS_REQ message is built as specified in [RFC4120]. Note that the 'realm' field MUST be set to the realm name of the desired service. In the scenario of Figure 3 the client MUST put the realm name 'R' in the 'realm' field of the KRB_TGS_REQ message. 2. TGS-L -> TGS-R : XTGSP-REQ TGS-L extracts the service's realm name from the field 'realm' of the client's request. If the extracted realm name does not match with the local realm name, then TGS-L MUST use the XTGSP extension with the TGS of the remote realm (TGS-R). The goal of the XTGSP protocol is to enable the local KDC (TGS-L) to build a valid KRB_TGS_REP [RFC4120] in response to a KRB_TGS_REQ for a service that is not registered in the local realm. TGS-L basically needs to build or have an EncTicketPart [RFC4120] as well as the session key associated with it. The EncTicketPart is a component of the ticket included in the KRB_TGS_REP message, it must be encrypted using the secret key of the remote service (shared with the remote TGS only). Since the only entity capable of building the EncTicketPart is the remote TGS (TGS-R), there is need for a protocol to request TGS-R to build the EncTicketPart component and to communicated it along with the associated service session key to TGS-L in a secure manner. XTGSP was designed to fulfill this task. Zrelli, et al. Expires December 19, 2006 [Page 15] Internet-Draft XKDCP June 2006 The XTGSP-REQ message contains all the necessary information to enable TGS-R to build an EncTicketPart and to transmit it along with the associated session key ,in a secure manner, to TGS-L. The XTGSP-REQ message is built from the client's original KRB_TGS_REQ message (which contains all information about the requested credentials). The XTGSP-REQ message is in fact a copy of the client's request extended using the 'padata' field. The 'padata' field defined by the XKDCP extension includes information for cross-realm operations as well as materials that will allow the KDCs to authenticate each others and to protect the XTGSP exchange. For this purpose, public key cryptography (based on a pre-existent PKI) is used between the two KDCs. The padata field of the XTGSP-REQ includes a signature [RFC3852] and the certificate of TGS-L. The process of building the XTGSP-REQ message and the associated 'padata' field is detailed in Section 3.5.2. 3. TGS-R -> TGS-L : XTGSP-REP When TGS-R receives a TGS-REQ message, it authenticates TGS-L and validates the request by verifying the certificate and the signature embedded in the padata field. Then, TGS-R creates a service session key and builds an EncTicketPart. The EncTicketPart is created as specified in [RFC4120]. TGS-R gets all the information needed to build the EncTicketPart from the XTGSP-REQ message. The EncTicketPart is encrypted using the secret key of the service (SRV-R). A copy of the generated session key (included in the EncTicketPart) is encrypted using the public key of TGS-L. The encrypted EncTicketPart and the encrypted service session key are conveyed to TGS-L using the padata field of the XTGSP-REP message. The XTGSP-REP message is a KRB_TGS_REP message extended using the padata field. The padata field includes materials for authenticating TGS-R to TGS-L and for verifying the integrity of the message. The XTGSP-REP message will be used by TGS-L to build a valid KRB_TGS_REP. More details on how to build the XTGSP-REP message are in Section 3.5.3. 4. TGS-L -> Client : KRB_TGS_REP When TGS-L recieves a XTGSP-REP message, it authenticates TGS-R and validates the message by verifying the certificate and the signature embedded in the padata field. After receiving the XTGSP-REP message, TGS-L is able to build the credentials requested by the client. For that, TGS-L will Zrelli, et al. Expires December 19, 2006 [Page 16] Internet-Draft XKDCP June 2006 decrypt the service session key using its private key. The EncTicketPart will be used to build a service ticket. The session key will be sent to the client along with the service ticket in a KRB_TGS_REP message. The KRB_TGS_REP message has the same format as specified in [RFC4120]. More details about this phase of the protocol are in Section 3.5.4. The client processes the KRB_TGS_REP message exactly as specified in [RFC4120]. She can use the service session key and the service ticket to issue a KRB_AP_REQ to the remote service. The mutual authentication between the client and the remote service occurs as specified in [RFC4120]. 3.3 Overview of the XASP extension In situations where the home KDC (or the KDC for which the client has a TGT) is not reachable or when the client has a limited network connectivity in a visited network, neither the standard Kerberos protocol nor the XTGSP protocol can be used to obtain tickets. In such circumstances, the client has no other alternatives but using previously acquired credentials (as long as they are still valid) or contact an entity in the visited network in order to acquire new credentials. XASP is an extension to the Kerberos protocol that complements the XTGSP protocol. It allows two Kerberos authentication services (that may be belong to two distinct realms) to collaborate in order to authenticate a roaming user and to deliver a TGT usable in the visited realm. When assuming that the KDC of the visited realm and the home KDC both support the XKDCP extension, the client behaves as if the visited KDC is capable of delivering a TGT even if she knows that she is not registered as principal in the visited realm. When the visited KDC supports the XASP extension it processes KRB_AS_REQ requests from users belonging to different realms. The processing of these requests is specified by the XASP extension. Figure 4 depicts the different exchanges between the different entities involved in a cross-realm operation based on XASP for delivering a TGT to a roaming user. Zrelli, et al. Expires December 19, 2006 [Page 17] Internet-Draft XKDCP June 2006 | | | +-------+ (2) XASP-REQ +-------+ | |----------------------------------->| | | AS-V | XASP-REP (3) | AS-H | | |<-----------------------------------| | +-------+ | +-------+ ^ | | | | | (1)| |(4) | KRB_AS_REQ | | KRB_AS_REP | | | | | v | +------+ | |Client| | +------+ | | Visited Realm (V) | Home Realm (H) client : A roaming client registered in realm H AS-V : The AS of the visited realm V AS-H : The AS of the home realm H KRB_AS_REQ : A message requesting a TGT for the visited realm V KRB_AS_REP : A message containing a TGT for the visited realm V Figure 4: The Inter-AS protocol The following is a description of the different exchanges shown in Figure 4. 1. Client -> AS-V : KRB_AS_REQ The roaming client requests a TGT from the visited KDC. This request is a KRB_AS_REQ as specified in [RFC4120]. The XASP protocol mandates that the client MUST put her home realm name in the 'realm' field of the request. Furthermore, the 'sname' field of the KRB_AS_REQ MUST contain the principal name of the TGS of the visited realm. The name of the TGS indicates the visited realm name as the realm issuing the TGT and the realm that will Zrelli, et al. Expires December 19, 2006 [Page 18] Internet-Draft XKDCP June 2006 accept the TGT. 2. AS-V -> AS-H : XASP-REQ When AS-V receives a KRB_AS_REQ message, it extracts the client's home realm name from the 'realm' field. If the extracted realm name matches the local realm name, then the request is processed as specified in [RFC4120]. In the opposite case (when the client's realm name is different from the local realm name), AS-V determines the IP address of the KDC that serves the client's home realm (AS-H). AS-V then initiates an XASP exchange with AS-H by sending an XASP-REQ message. The goal of the XASP exchange is to enable the visited KDC to build a valid KRB_AS_REP message in response to a KRB_AS_REQ request issued by a roaming client. AS-V basically needs to build or have an EncASRepPart [RFC4120] and the associated session key. The EncASRepPart is a part of the KRB_AS_REP that must be encrypted using the client's secret key (shared with the home AS only). The XASP protocol allows AS-V to obtain the EncASRepPart from the home AS. The EncASRepPart includes a session key that will be shared between the client and the TGS of the visited realm. This session key is also obtained from AS-H using the XASP protocol. The XASP-REQ message contains all the necessary information to enable AS-H to build an EncASRepPart and to transmit it along with the associated session key, in a secure manner, to AS-V. The XASP-REQ message is built from the client's KRB_AS_REQ request, extended using the 'padata' field. The 'padata' field includes information for cross-realm operations as well as material that will allow the KDCs to authenticate each others and to protect the XASP exchange. For this purpose, public key cryptography (based on a pre-existent PKI) is used between the two KDCs. The padata field of the XASP-REQ includes a signature [RFC3852] and the certificate of AS-V. The process of building the XASP-REQ message and the associated 'padata' field is detailed in Section 3.6.2. Note that the padata fields used in the XASP and XTGSP exchanges all have the same format which is described in Section 3.4. 3. AS-H -> AS-V : XASP-REP Upon reception of an XASP-REQ message, AS-H uses the signature and the certificate from the padata field to authenticate and verify the request. Then, AS-H generates a session key (a TGS Zrelli, et al. Expires December 19, 2006 [Page 19] Internet-Draft XKDCP June 2006 session key) and builds an EncASRepPart then encrypts it using the client's secret key. The TGS session key is included in the EncASRepPart as specified by [RFC4120] and a copy of the same key is encrypted using the public key of AS-V. The encrypted EncASRepPart and the encrypted session key are conveyed to AS-V using the padata field of the XASP-REP message. The XASP-REP message is a KRB_AS_REP message extended using the padata field. The padata field includes material for authenticating the home KDC and for verifying the integrity of the message. The XASP-REP message will be used by AS-V to build a KRB_AS_REP. 4. AS-V -> Client : KRB_AS_REP When AS-V receives the XASP-REP message, it starts by authenticating and verifyng the message using the signature and the certificate from the padata field. Then, it extracts the TGS session key from the padata field. AS-V uses its own private key to decrypt the TGS session key. The EncASRepPart is extracted from the XASP-REP message. At this stage AS-V is able to build a KRB_AS_REP composed of a TGT (using the TGS session key extracted from the XASP-REP) and the EncASRepPart. The KRB_AS_REP message is then delivered to the roaming client. The client processes the KRB_AS_REP message exactly as specified in [RFC4120]. The client uses her secret key to decrypt the EncASRepPart (created by AS-H). The TGT and the TGS session key can then be used to create a KRB_TGS_REQ messages to request service tickets from the visited KDC. 3.4 The XKDCP padata The XKDCP protocol defines a new pre-authentication type (padata- type) PA-XKDCP 18 The XKDCP extension specifies the ASN.1 PA-XKDCP-DATA type which represents a mandatory padata that MUST be included in all XKDCP messages. Each time a KDC issues an XKDCP message, it MUST build a PA-DATA object whose padata-type is PA-XKDCP and with the DER encoding of an PA-XKDCP-DATA object as padata-value. The PA-XKDCP-DATA object specification is as follows : Zrelli, et al. Expires December 19, 2006 [Page 20] Internet-Draft XKDCP June 2006 PA-XKDCP-DATA ::= [APPLICATION 18] IMPLICIT OCTET STRING XKDCP-BODY ::= SEQUENCE { kippu [0] IMPLICIT OCTET STRING OPTIONAL, cname [1] PrincipalName, caddr [2] HostAddresses, crealm [3] Realm, lrealm [4] Realm, cksum [5] Checksum OPTIONAL, ... } KIPPU ::= SEQUENCE { encSK [1] EncryptionKey, xkdcpEncData [2] EncryptedData, tktOptions [3] TicketFlags, last-req [4] LastReq, authtime [5] KerberosTime, starttime [6] KerberosTime OPTIONAL, endtime [7] KerberosTime, renew-till [8] KerberosTime OPTIONAL, proxyaddr [9] HostAddress OPTIONAL, ... } The PA-XKDCP-DATA object contains a CMS type ContentInfo encoded according to [RFC3852]. The contentType field of the type ContentInfo is id-signedData (1.2.840.113549.1.7.2), and the content field is a SignedData. The eContentType field for the type Zrelli, et al. Expires December 19, 2006 [Page 21] Internet-Draft XKDCP June 2006 SignedData is id-xkdcp-authData (1.3.6.1.5.2.4.1), and the eContent field contains the DER encoding of the type XKDCP-BODY. The XKDCP-BODY object is filled as follows: kippu : The kippu field is built by the responding KDC. It contains a KIPPU object signed by the responding KDC and encrypted using the public key of the initiating KDC. It consists of a CMS type ContentInfo encoded according to [RFC3852]. The contentType field of the type ContentInfo is id-envelopedData (1.2.840.113549.1.7.3), and the content field is an EnvelopedData. The contentType field of the EncryptedContentInfo id-signedData (1.2.840.113549.1.7.2). The eContentType field for the inner type SignedData (when unencrypted) is id-xkdcp-kippu (1.3.6.1.5.2.4.2) and the eContent field contains the DER encoding of a KIPPU object (described below). Note that the Kippu field is used in XTGSP-REP and XASP-REP messages only. cname : The principal name of the client who issued the initial request (KRB_AS_REQ or KRB_TGS_REQ). The client name is obtained from the 'cname' field of the client's request. caddr : The IP address of the client who issued the request. This field is a "HostAddress" object [RFC4120]. crealm : The realm name where the client is registered as a Kerberos principal. This information is filled by the initiating KDC. In case of an XTGSP exchange, the realm name of the client is extracted from the TGT. In case of an XASP exchange, the client's realm name is obtained from the 'realm' field of the KRB_AS_REQ message. lrealm : The realm name of the KDC that initiated an XKDCP exchange. cksum : This field contains an unkeyed checksum computed over the DER encoding of the "req-body" of a XTGSP-REQ or an XASP-REQ message (Note that the req-body in the XKDCP messages is a copy of the req-body component of the KRB_KDC_REQ issued by the client). This checksum is used to protect the integrity of "req-body" part of the XTGSP-REQ and XASP-REQ messages. The "cksum" field is a "Checksum" data object as defined in [RFC4120]. The SHA-1 hash function ("cksumtype" value 10 [RFC3961]) MUST be supported to compute the checksum. The KDC SHOULD support additional collision-proof, unkeyed hash functions. Zrelli, et al. Expires December 19, 2006 [Page 22] Internet-Draft XKDCP June 2006 encSK : This field contains an EncryptionKey object [RFC4120]. xkdcpEncData : The xkdcpEncData is an EncryptedData object [RFC4120]. In case of a XTGSP-REP message, this field contains an EncTicketPart [RFC4120] encrypted using the secret key of the service. In case of an XASP-REP message, the xkdcpEncData contains an EncASRepPart [RFC4120] encrypted using the secret key of the client. tktOptions: Contains a "TicketFlags" object that indicates the options associated with a certain credential. The responding KDC fills these fields by applying the realm's policy while taking into account the client's request. last-req, authtime, starttime, endtime, renew-till: These fields have the same definition as in section 5.4.2. of [RFC4120]. The responding KDC fills these fields by applying the realm's policy while taking into account the client's request. These options will be used by the initiating KDC to build the KRB_KDC_REP message. proxyaddr: Same as the 'caddr' field of the Ticket object (section 5.3. of [RFC4120]). The XKDCP extension defines the following object identifiers: id-xkdcp OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) xkdcp (4) } id-xkdcp-authData OBJECT IDENTIFIER ::= { id-xkdcp 1 } id-xkdcp-kippu OBJECT IDENTIFIER ::= { id-xkdcp 2 } "id-xkdcp" identifies the XKDCP extension and the PA-XKDCP-DATA object. The "id-xkdcp-authData" identifies the XKDCP-DATA object. "id-xkdcp-kippu" identifies the object KIPPU. 3.5 XTGSP protocol details 3.5.1 The KRB_TGS_REQ message When a client wishes to access any service located at any realm. She must first determine the principal name and the realm name of the service. In the current specification of the Kerberos protocol, if the realm name of the service is different from the client's home realm, then the client must first obtain a TGT for the remote realm (where the service is registered). Zrelli, et al. Expires December 19, 2006 [Page 23] Internet-Draft XKDCP June 2006 When assuming that the KDCs support the XTGSP extension, the client does not try to obtain a TGT for the remote realm. Instead, she issues a KRB_TGS_REQ to the KDC for which she has already a TGT (this KDC might be the client's home KDC or it might be any another KDC for which the client has a TGT). The KRB_TGS_REQ message in the same as defined in section 5.4.1 of [RFC4120]. The only difference is in the field 'realm'. The XKDCP specification mandates that the 'realm' field MUST contain the realm name where the service is believed to be registered. 3.5.2 The XTGSP-REQ message On reception of a KRB_TGS_REQ message, the KDC checks the field 'realm' in the KDC-REQ-BODY. If this field indicates the same realm name as the KDC's realm name, then the KDC follows the same behavior as described in section 3.3.2 of [RFC4120]. If the realm name indicated in the 'realm' field is different from the local realm name (which means that the service is located in a remote realm), then the XTGSP extension MUST be used. The following specifies the behavior of the KDC when the XTGSP extension is in use: 1. The KDC starts by validating the request by validating the TGT and verifying the integrity of the KRB_TGS_REQ message as specified in section 3.3.2 of [RFC4120]. If the KRB_TGS_REQ is valid then the KDC can proceed to the next step. 2. The KDC determines the KDC of the remote realm, the process of discovering the remote KDC is out of the scope of this document but the same guidelines specified in section 7.2.3. of [RFC4120] are applicable. If the KDC fails to discover the KDC of the remote realm, then a KRB_ERROR message is sent to the client with an error code KDC_ERR_XKDCP_CANT_DISCOVER_KDC and the processing of the KRB_TGS_REQ stops here, otherwise the KDC proceeds to the next step. 3. The KDC creates a XTGSP-REQ message as specified below : XTGSP-REQ ::= SEQUENCE { pvno [1] INTEGER , msg-type [2] INTEGER , padata [3] SEQUENCE OF PA-DATA OPTIONAL, req-body [4] KDC-REQ-BODY } Zrelli, et al. Expires December 19, 2006 [Page 24] Internet-Draft XKDCP June 2006 The XTGSP-REQ message has the same format and semantics as the KDC-REQ [RFC4120] message. The fields are filled as follows : pvno : Indicates the Kerberos protocol version, this integer MUST be set to 5. msg-type : The XTGSP-REQ message type MUST be set to the integer XKDCP-XTGSP-REQ. padata : The padata field MUST contain any padata field extracted from the client's initial KRB_TGS_REQ message as well as an additional padata field of type PA-XKDCP-DATA as specified in Section 3.4. req-body : This field contains a copy of the 'req-body' component from the KRB_TGS_REQ issued by the client. Note that the initiating KDC can modify the fields of the req-body to reflect the realm policy (more details in Section 3.7). 4. The XTGSP-REQ is then sent to the remote KDC. 3.5.3 The XTGSP-REP message On reception of a XTGSP-REQ message the remote KDC proceeds as follows: 1. The KDC MUST verify the signature in the PA-XKDCP-DATA object according to [RFC3852]. If the remote KDC can not build a certification path to validate the X.509 certificate [RFC3280], it sends back a KRB-ERROR message with the code KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE. When receiving this error message, the initiating KDC SHOULD issue a new XTGSP-REQ using a different certificate. If the signature is verified successfully, the KDC proceeds to the next step. 2. The KDC verifies the checksum in the field 'cksum'. If the checksum test fails, the remote KDC sends a KRB_ERROR message with an error code KRB_ERR_XKDCP_BAD_INTEGRITY . If the checksum test succeeds, then the integrity of the information embedded in the 'req-body' of the XTGSP-REQ message is verified. The KDC can then proceed to the next step. 3. The remote KDC verifies that the realm indicated by the field 'realm' of the XTGSP-REQ matches with its own realm name. If the realm name does not match, the KDC issues a KRB_ERROR message to the initiating KDC, the error code of this message is KRB_ERR_XKDCP_WRONG_REALM. If the realm name matches, the KDC Zrelli, et al. Expires December 19, 2006 [Page 25] Internet-Draft XKDCP June 2006 verifies that the requested service is registered in its database. If the principal is not found, then a KRB_ERROR message is sent to the initiating KDC with an error code KDC_ERR_XKDCP_S_PRINCIPAL_UNKNOWN . If the principal is found in the database, then the KDC proceeds to the next step. 4. The remote KDC builds an EncTicketPart [RFC4120] which is defined as follows : EncTicketPart ::= [APPLICATION 3] SEQUENCE { flags [0] TicketFlags, key [1] EncryptionKey, crealm [2] Realm, cname [3] PrincipalName, transited [4] TransitedEncoding, authtime [5] KerberosTime, starttime [6] KerberosTime OPTIONAL, endtime [7] KerberosTime, renew-till [8] KerberosTime OPTIONAL, caddr [9] HostAddresses OPTIONAL, authorization-data [10] AuthorizationData OPTIONAL } The EncTicketPart is filled as follows : flags : The remote KDC relies on the local policy and the options requested by the client (in the kdc-options field of the req- body of the XTGSP-REQ message) to decide which ticket options will be granted. Key : The remote KDC generates a random session key and places it in an EncryptionKey [RFC4120] object. crealm : The same as the 'crealm' field of the 'req-body' of the XTGSP-REQ message cname : Contains the client's principal name. transited : Not used, left empty. authtime, starttime, endtime, renew-till, caddr, authorization- data : These fields are filled according to [RFC4120]. The KDC takes into consideration the realm's policy and the client's request to determine the lifetime and other parameters related to the ticket. Zrelli, et al. Expires December 19, 2006 [Page 26] Internet-Draft XKDCP June 2006 5. The remote KDC builds a XTGSP-REP message defined as follows : XTGSP-REP ::= SEQUENCE { pvno [0] INTEGER , msg-type [1] INTEGER , padata [2] SEQUENCE OF PA-DATA OPTIONAL, crealm [3] Realm, cname [4] PrincipalName, ticket [5] Ticket, enc-part [6] EncryptedData } The XTGSP-REP message is filled as follows : pvno : Indicates the Kerberos protocol version, this integer MUST be set to 5. msg-type : The XTGSP-REP message type MUST be set to the integer XKDCP-XTGSP-REP padata : The padata field MUST contain a padata field of type PA- XKDCP-DATA ( specified in Section 3.4). The session key which was generated by the remote KDC and inserted in the 'key' field of EncTicketPart, is used to build an EncryptionKey object. This object is used as the field 'encSK' of the kippu object of the padata. The EncTicketPart, built by the remote KDC in step 4, is encrypted using the secret key of the requested service. The result is used to build an EncryptedData object. The EncryptedData object is then placed in the xkdcpEncData of the KIPPU object. The padata is then signed by the KDC as specified in Section 3.4 These fields contain the client's principal name and the client's realm name. ticket, enc-part: These fields are not used, they are left empty. 6. The remote KDC sends the XTGSP-REP to the initiating KDC. 3.5.4 The KRB_TGS_REP message The local realm uses the XTGSP-REP message to build a KRB_TGS_REP message for the client. For that, the local KDC proceeds as follows : 1. The local KDC MUST verify the signature in the PA-XKDCP-DATA object according to [RFC3852]. If the local KDC can not build a Zrelli, et al. Expires December 19, 2006 [Page 27] Internet-Draft XKDCP June 2006 certification path to validate the X.509 certificate [RFC3280], it sends back a KRB-ERROR message with the code KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE. Upon reception of this error message, the remote KDC SHOULD try to retransmit the XTGSP- REP message using a different certificate. If the signature is verified successfully, the local KDC proceeds to the next step. 2. The EncTicketPart is extracted from the xkdcpEncData component of the kippu object. The session key is extracted from the encSK field of the kippu object. For that, the KDC uses its own private key to decrypt the kippu object. 3. The local KDC builds an EncTGSRepPart [RFC4120] which is defined as follows : EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 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 } The EncTGSRepPart is filled as follows : Key: This field is filled with the session key extracted from the kippu object. flags: This field is obtained from the tktOptions field of the kippu object extracted from the XTGSP-REP message. These ticket options reflect the policy of the remote realm where the service is actually deployed. authtime, starttime, endtime, renew-till These fields are filled using the fields with the same name in the kippu object. Zrelli, et al. Expires December 19, 2006 [Page 28] Internet-Draft XKDCP June 2006 srealm, sname Contains the realm name of the service (which is different from the realm name that issues the KRB_TGS_REP message) and the principal name of the service. Same usage as in [RFC4120]. This field is filled using the field proxyaddr from the kippu object. 4. The local KDC builds a ticket using the EncTicketPart and other information extracted from the kippu object. The EncTGSRepPart built in the previous step is used with the Ticket to build a KRB_TGS_REP message that will be sent to the client. The EncTGSRepPart is encrypted using the TGS session key shared between the client and the local TGS, then placed in the enc-part field of the KRB_TGS_REP message 3.6 The XASP protocol details The XASP protocol allows a KDC (generally a visited KDC) to deliver a TGT (destined to be used with the TGS of the same KDC) to users who are not registered in the KDC's database. The XASP protocol defines an exchange between the visited KDC and the client's home KDC. The result of the XASP exchange is that the visited KDC is able to deliver the desired TGT. An overview of the the XASP protocol was presented in section Section 3.3. The following paragraphs give deeper details of the XASP message specification and exchanges. 3.6.1 The KRB_AS_REQ message When a client wishes to get a TGT for a visited realm, she issues a KRB_AS_REQ message to the KDC of the target realm. The KRB_AS_REQ is defined in [RFC4120]. The client fills this request exactly as if she was initiating an AS exchange with her home KDC. Note that, the XKDCP protocol mandates that the client MUST indicate her home realm name in the field 'realm' of the KRB_AS_REQ request. The client MUST use the principal name of the TGS of the visited realm in the 'sname' field of the request. According to [RFC4120], section 7.3, the name of the TGS contains the realm name of the KDC that will issue the TGT and the realm name of the KDC that will accept the TGT. In case of roaming scenario using XASP for cross-realm operations, the client MUST use the visited realm name for building the TGS name of the KRB_AS_REQ. 3.6.2 The XASP-REQ message Upon reception of a KRB_AS_REQ, the AS checks the 'realm' field of the KDC-REQ-BODY. If this field matches the local realm name, then the request MUST be processed as defined in [RFC4120]. If the Zrelli, et al. Expires December 19, 2006 [Page 29] Internet-Draft XKDCP June 2006 client's realm name does not match with the target KDC's realm name, then the client is considered as roaming client, and the request MUST be processed using the XASP extension. The following specifies the behavior of the KDC when the XASP extension is being used : 1. The KDC determines the KDC of the client's home realm, this host discovery process is out of the scope of this document but the same guidelines specified in section 7.2.3. of [RFC4120] are applicable. If the foreign KDC fails to discover the KDC of client's home realm, then a KRB_ERROR message is sent to the client with an error code KDC_ERR_XKDCP_CANT_DISCOVER_KDC and the processing of the KRB_AS_REQ stops here, otherwise the KDC proceeds to the next step. 2. The KDC creates an XASP-REQ message as specified below : XASP-REQ ::= SEQUENCE { pvno [1] INTEGER , msg-type [2] INTEGER , padata [3] SEQUENCE OF PA-DATA OPTIONAL, req-body [4] KDC-REQ-BODY } The XASP-REQ message has the same format and semantics as the KDC-REQ [RFC4120] message. The fields are filled as follows : pvno : Indicates the Kerberos protocol version, this integer MUST be set to 5. msg-type : The XASP-REQ message type MUST be set to the integer XKDCP-XASP-REQ padata : The padata field MUST contain any padata field issued by the client as well as a padata field of type PA-XKDCP-MSG as specified in Section 3.4. req-body : This field contains a copy of the 'req-body' component from the KRB_AS_REQ issued by the client. Note that the initiating KDC can modify the fields of the req-body to reflect the realm policy (more details in Section 3.7). 3. The XASP-REQ is sent to the client's home KDC. Zrelli, et al. Expires December 19, 2006 [Page 30] Internet-Draft XKDCP June 2006 3.6.3 The XASP-REP message On reception of an XASP-REQ message the home KDC proceeds as follows : 1. The KDC MUST verify the signature in the PA-XKDCP-DATA object according to [RFC3852]. If the home KDC can not build a certification path to validate the X.509 certificate [RFC3280], it sends back a KRB-ERROR message [RFC4120] with error code KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE. Upon reception of this error message, the visited KDC SHOULD try another XASP-REQ using a different certificate. If the signature is verified successfully, then the home KDC proceeds to the next step. 2. The home KDC verifies the checksum in the 'cksum' field of the padata field of the XASP-REQ message. If the checksum test fails, the home KDC sends a KRB_ERROR message with an error code KRB_ERR_XKDCP_BAD_INTEGRITY. If the checksum test succeeds, the integrity of the information embedded in the 'req-body' of the XASP-REQ message is verified. The KDC can then proceed to the next step. 3. The KDC verifies that the client's home realm indicated by the field 'realm' of the XASP-REQ matches with the KDC's realm name. If the realm name does not match, the KDC issues a KRB_ERROR message to the initiating KDC, the error code of this message is KRB_ERR_XKDCP_WRONG_REALM . The KDC then verifies that the client's principal is registered in its database. If the principal is not found, a KRB_ERROR message is sent to the visited KDC with an error code KDC_ERR_XKDCP_C_PRINCIPAL_UNKNOWN . If the principal is found then the KDC proceeds to the next step. 4. The home KDC builds an EncASRepPart which is defined in [RFC4120] as follows. Zrelli, et al. Expires December 19, 2006 [Page 31] Internet-Draft XKDCP June 2006 EncASRepPart ::= [APPLICATION 26] EncKDCRepPart 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 } The EncKDCRepPart is filled as follows : Key : The home KDC generates a random session key and places it in an EncryptionKey object. This session key will be used later on as a TGS session key shared between the client and the visited KDC. nonce : The value of the nonce field from the XASP-REQ message is copied into this field. flags : The home KDC relies on the local policy and the options requested by the client (in the kdc-options field of the req- body of the XASP-REQ message) to decide which ticket options will be granted. crealm, cname : The client's home realm name and principal name. transited : Not used, left empty. authtime, starttime, endtime, renew-till, caddr,authorization- data : These fields are filled according to [RFC4120]. The home KDC takes into consideration the realm's policy and the client's request to determine the lifetime and other parameters related to the ticket. srealm: This field MUST indicate the realm name of the visited KDC (or the visited realm name). The visited realm name is extracted from the 'lrealm' field of the XASP-REQ message. Zrelli, et al. Expires December 19, 2006 [Page 32] Internet-Draft XKDCP June 2006 sname: This field contains the principal name that corresponds to the TGS of the visited realm. 5. The remote KDC builds an XASP-REP message defined as follows : XASP-REP ::= SEQUENCE { pvno [0] INTEGER , msg-type [1] INTEGER , padata [2] SEQUENCE OF PA-DATA OPTIONAL, crealm [3] Realm, cname [4] PrincipalName, ticket [5] Ticket, enc-part [6] EncryptedData } The XASP-REP message is filled as follows : pvno : Indicates the Kerberos protocol version, this integer MUST be set to 5. msg-type : For the XASP-REP message this field MUST be set to the integer XKDCP-XASP-REP padata : The padata field MUST contain a padata of type PA-XKDCP- MSG (specified in Section 3.4). The session key (generated by the home KDC and inserted in the 'key' field of EncTicketPart) is used to build an EncryptionKey object. The EncryptionKey object is placed in the encSK field of the kippu object. The EncASRepPart built by the home KDC in step 4 is encrypted using the client's secret key. The result is used to build an EncryptedData object which will be placed in the xkdcpEncData of the kippu object. These fields contain the client's realm name and the client's principal name ticket, enc-part: These fields are not used, they are left empty. 6. The home KDC sends the XASP-REP to the visited KDC. 3.6.4 The KRB_AS_REP message The visited realm uses the XASP-REP message to build a KRB_AS_REP message for the client. For that, the visited KDC proceeds as follows : Zrelli, et al. Expires December 19, 2006 [Page 33] Internet-Draft XKDCP June 2006 1. The visited KDC MUST verify the signature in the PA-XKDCP-DATA object according to [RFC3852]. If the visited KDC can not build a certification path to validate the X.509 certificate [RFC3280], it sends back a KRB-ERROR message with the code KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE. Upon reception of this error message, the home KDC SHOULD try to retransmit the XASP-REP message using a different certificate. If the signature is verified successfully, the local KDC proceeds to the next step. 2. The EncASRepPart is obtained from the xkdcpEncData component of the kippu object. The TGS session key is extracted from the encSK field of the kippu object. For that, the visited KDC uses its own private key to decrypt the kippu object. 3. The visited KDC builds an EncTicketPart object [RFC4120] which is defined as follows : EncTicketPart ::= [APPLICATION 3] SEQUENCE { flags [0] TicketFlags, key [1] EncryptionKey, crealm [2] Realm, cname [3] PrincipalName, transited [4] TransitedEncoding, authtime [5] KerberosTime, starttime [6] KerberosTime OPTIONAL, endtime [7] KerberosTime, renew-till [8] KerberosTime OPTIONAL, caddr [9] HostAddresses OPTIONAL, authorization-data [10] AuthorizationData OPTIONAL } The EncTicketPart is filled as follows : flags: The visited KDC SHOULD use the tktOptions field of the kippu object extracted from the XASP-REP message. The visited KDC MAY check the ticket options indicated in the tktOptions field against its local policy to decide which are the final ticket options that will be granted to the client. (Note that if the visited KDC does not use the same flags as in tktOptions, the client will have wrong information about the ticket flags). Key : The TGS session key extracted from the encSK field of the kippu object is placed in this field. Zrelli, et al. Expires December 19, 2006 [Page 34] Internet-Draft XKDCP June 2006 crealm, cname : The client's home realm name and principal name. transited : Not used, left empty. authtime, starttime, endtime, renew-till, caddr, authorization- data : To fill these fields, the visited KDC SHOULD use the the correspondent fields of the kippu object extracted from the XASP-REP message. The visited KDC MAY check these fields against its local policy to decide what will be the final values assigned to these fields. (Note that if the visited KDC does not use the same values as in the kippu object, the client will have wrong information about the TGT that she obtained). 4. The visited KDC builds a Ticket object (ticket granting ticket) using the EncTicketPart built in the previous step. The 'realm' field of the ticket indicates the realm name of visited KDC. The EncASRepPart extracted from the kippu object is used with the ticket to build a KRB_AS_REP message that will be sent to the client. The client uses her secret key to decrypt the EncASRepPart of the KRB_AS_REP message. She can then use the TGS session key to build an authenticator and issue KRB_TGS_REP messages to request service tickets for services deployed in the visited realm. 3.7 Realm policy Each realm has enough control that enables it to apply its own policies concerning cross-realm authentication. The initiating KDC can accept or refuse a client's request according to its policy. If the initiating KDC can not process the client's request because the requested options (ticket flags and lifetime) are not compatible with its policy, it MUST issue a KRB-ERROR with error code KDC_ERR_XKDCP_WRONG_TKT_OPTS. The client then SHOULD issue another request with different options. When the client's request is accepted, the initiating KDC MAY fix the final options according to its local policy while taking in consideration the client's request. Then, the initiating KDC issues an XKDCP request to the remote KDC. The responding KDC can decide whether to honor the request or not according to its local policy. If the responding KDC can not process the XKDCP request because the requested options are not compatible with its policy, it issues a KRB-ERROR with error code KDC_ERR_XKDCP_WRONG_TKT_OPTS. The initiating KDC notifies the client about the error and finalizes the exchange by sending a KRB-ERROR with code KDC_ERR_XKDCP_INCOMPATIBLE_CROSS_REALM_POLICY. Otherwise the responding KDC processes the XKDCP request and issues the corresponding reply message. Zrelli, et al. Expires December 19, 2006 [Page 35] Internet-Draft XKDCP June 2006 After receiving the remote KDC's reply which contains parts of the credentials requested by the client, the initiating KDC can decide whether to accept the remote KDC's policy that were applied on the credentials or not. If the XKDCP reply message indicates that the responding KDC did not use the same options as requested in the XKDCP request message, and if these options are not acceptable according to the initiating KDC's policy, then the initiating KDC MAY issue a KRB- ERROR message to the client with error code KDC_ERR_XKDCP_INCOMPATIBLE_CROSS_REALM_POLICY. If the XKDCP reply message shows that the remote KDC used options that are compatible with the initiating KDC's policy, the initiating KDC use these options to build the credentials. For example, a roaming client can issue a request asking for a TGT from a visited KDC. The client may ask for a ticket life time of 5 hours. The visited KDC decides whether to accept the client's request or not depending for example on whether the client's realm is known or not, whether the client's ip address is acceptable, and most importantly, if the requested ticket options are acceptable (lifetime of 5 hours). The visited KDC may choose to reduce the lifetime to 2 hours or to reject the client's request. If the visited KDC decides to process the client's request, it will issue an XASP-REQ message to the client's home KDC. The XASP-REQ message includes information to notify the home KDC that the credentials to be issued must have a lifetime of 2 hours. The client's home KDC can decide whether the requested lifetime is acceptable or not. If not, the KDC_ERR_XKDCP_WRONG_TKT_OPTS error will be sent to the initiating KDC. Otherwise, the home KDC may accept the requested lifetime of 2 hours. It MAY also consider a shorter lifetime of 1 hour for example. The XASP-REP message includes information that indicates to the visited KDC that the home KDC issued credentials with lifetime of 1 hour. The visited KDC MAY accept this value or reject it by issuing an KDC_ERR_XKDCP_INCOMPATIBLE_CROSS_REALM_POLICY error to the client. Zrelli, et al. Expires December 19, 2006 [Page 36] Internet-Draft XKDCP June 2006 4. Constants The XKDCP extension defines a new PreAuthentication Data Types as follows : Padata and Data Type Padata-type value PA-XKDCP 18 Additionally, the XKDCP extension uses the following constants. 4.1 XKDCP error codes Error code | Value ------------------------------------------------+------- KDC_ERR_XKDCP_CANT_DISCOVER_KDC | 80 KDC_ERR_XKDCP_CANT_DISCOVER_KDC | 81 KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE | 82 KRB_ERR_XKDCP_BAD_INTEGRITY | 83 KRB_ERR_XKDCP_WRONG_REALM | 84 KDC_ERR_XKDCP_S_PRINCIPAL_UNKNOWN | 85 KDC_ERR_XKDCP_C_PRINCIPAL_UNKNOWN | 86 KDC_ERR_XKDCP_WRONG_TKT_OPTS | 87 KDC_ERR_XKDCP_INCOMPATIBLE_CROSS_REALM_POLICY | 89 4.2 XKDCP message types Message type | Value ------------------------------------------------+------- XKDCP-XTGSP-REQ | 40 XKDCP-XTGSP-REP | 41 XKDCP-XASP-REQ | 42 XKDCP-XASP-REP | 43 Zrelli, et al. Expires December 19, 2006 [Page 37] Internet-Draft XKDCP June 2006 5. Security considerations [RFC4120] highlights several security considerations. All these considerations apply to a Kerberos KDC implementing the XKDCP extension. This section discusses the security properties as well as additional vulnerabilities and security recommendations introduced by the XKDCP extension. 5.1 Integrity protection All XKDCP messages are integrity protected. The 'req-body' part of XKDCP requests is protected using an unkeyed checksum. On the other hand, the 'padata' part is always protected using public key signature. The uneyed checksum used to protect the 'req-body' field is included in the padata field and is thus protected. 5.2 Confidentiality In XKDCP, sensible information is encrypted in order to preserve its confidentiality. The session keys created by the responding KDC are encrypted using the public key of the initiating KDC before sending the XKDCP reply message. On the other hand no secret key (shared between a principal and its home KDC) is revealed to any third party. The secret keys are used by the responding KDC to create EncryptedData objects, but are never transmitted. 5.3 DoS and replay protection An attacker can flood a KDC with forged or replayed XKDCP requests or replies. Since the processing of any XKDCP message involves public key cryptography, such attack can result in a denial of service at the target KDC. In order to mitigate the threat of DoS attacks, filtering mechanisms should be deployed to ensure that the KDC will only receive client requests from the internal network and XKDCP messages from a trusted set of remote KDCs. Additionally, the XKDCP extension SHOULD use a replay protection mechanism to detect replayed messages. Zrelli, et al. Expires December 19, 2006 [Page 38] Internet-Draft XKDCP June 2006 6. Acknowledgments The authors would like to thank the following individuals for their comments and suggestions : Okabe Nobuo and Atsushi Inoue. 7. 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. [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. [CJSW05] Cervesato, I., Jaggard, A., Scedrov, A., and C. Walstad, "Specifying Kerberos 5 Cross-Realm Authentication", Fifth Workshop on Issues in the Theory of Security 12--26, January 2005. 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 Zrelli, et al. Expires December 19, 2006 [Page 39] Internet-Draft XKDCP June 2006 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 December 19, 2006 [Page 40] Internet-Draft XKDCP June 2006 Appendix A. ASN.1 module KerberosV5-XKDCP-SPEC { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) xkdcp(6) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS KerberosTime, PrincipalName, Realm, EncryptionKey, HostAddress, HostAddresses, EncryptedData, EncTicketPart, Checksum, Ticket, TicketFlags, LastReq, KDC-REQ, PA-DATA FROM KerberosV5Spec2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) krb5spec2(2) }; -- As defined in RFC 4120. id-xkdcp OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) xkdcp (4) } id-xkdcp-authData OBJECT IDENTIFIER ::= { id-xkdcp 1 } id-xkdcp-kippu OBJECT IDENTIFIER ::= { id-xkdcp 2 } -- XTGSP-REP and XASP-REP are identical to KDC-REP [RFC4120] -- XTGSP-REQ and XASP-REQ are identical to KDC-REQ [RFC4120] XTGSP-REQ ::= [APPLICATION 40] KDC-REQ XTGSP-REP ::= [APPLICATION 41] KDC-REQ XASP-REQ ::= [APPLICATION 42] KDC-REQ XASP-REP ::= [APPLICATION 43] KDC-REQ -- The PA-XKDCP-DATA object is used in the padata-value -- of a PA-DATA and inserted in the padata field of all -- XKDCP messages. Zrelli, et al. Expires December 19, 2006 [Page 41] Internet-Draft XKDCP June 2006 PA-XKDCP-DATA ::= [APPLICATION 18] IMPLICIT OCTET STRING -- Contains a CMS type ContentInfo encoded -- according to [RFC3852]. -- The contentType field of the type ContentInfo -- is id-signedData (1.2.840.113549.1.7.2), -- and the content field is a SignedData. -- The eContentType field for the type SignedData -- is id-xkdcp-authData (1.3.6.1.5.2.4.1), and the -- eContent field contains the DER encoding of the -- type XKDCP-BODY -- XKDCP-BODY is defined below. XKDCP-BODY ::= SEQUENCE { kippu [0] IMPLICIT OCTET STRING OPTIONAL, -- Contains a CMS type ContentInfo encoded -- according to [RFC3852]. -- The contentType field of the type ContentInfo -- is id-envelopedData (1.2.840.113549.1.7.3), -- and the content field is an EnvelopedData. -- The contentType field of the EncryptedContentInfo -- id-signedData (1.2.840.113549.1.7.2). -- The eContentType field for the inner type -- SignedData (when unencrypted) is -- id-xkdcp-kippu (1.3.6.1.5.2.4.2) and the -- eContent field contains the DER encoding of the -- type KIPPU defined below -- This field is used only in XASP-REP and XTGSP-REP -- messages. cname [1] PrincipalName, -- The client's principal name caddr [2] HostAddress, -- IP address of the client crealm [3] Realm, -- The realm name of the client. lrealm [4] Realm, -- The realm name of the KDC that -- initiated an XKDCP exchange. cksum [5] Checksum OPTIONAL, -- This field is a checksum computed -- over the DER encoding of the "req-body" of Zrelli, et al. Expires December 19, 2006 [Page 42] Internet-Draft XKDCP June 2006 -- an XKDCP request message (XTGSP-REQ or XASP-REQ) -- The "cksum" field is a "Checksum" data object -- as defined in [RFC4120]. The checksum used -- here is an unkeyed checksum. ... } KIPPU ::= SEQUENCE { encSK [1] EncryptionKey, -- contains a TGS session key in XASP-REP -- contains a service session key in XTGSP-REP xkdcpEncData [2] EncryptedData, -- contains an EncTicketPart in XTGSP-REP -- contains an EncASRepPart in XASP-REP tktOptions [3] TicketFlags, -- conains the ticket flags last-req [4] LastReq, authtime [5] KerberosTime, starttime [6] KerberosTime OPTIONAL, endtime [7] KerberosTime, renew-till [8] KerberosTime OPTIONAL, -- The fields labelled 4,5,6,7,8 have the same -- definitions and use as specified in [RFC4120] proxyaddr [9] HostAddress OPTIONAL, -- used with proxy or forwarded tickets ... } END Zrelli, et al. Expires December 19, 2006 [Page 43] Internet-Draft XKDCP 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. Zrelli, et al. Expires December 19, 2006 [Page 44]