Network Working Group M. Nakhjiri, Ed. Internet-Draft Huawei USA Expires: December 24, 2007 Y. Ohba, Ed. Toshiba June 22, 2007 Derivation, delivery and management of EAP based keys for handover and re-authentication draft-ietf-hokey-key-mgm-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 24, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes a delivery framework for usage and/ or domain specific keys, derived as part of an EAP EMSK hierarchy, and delivered from an EAP server to an intended third party key holder. The framework description includes different scenarios for key delivery, depending on the type of keys being delivered. It also includes, specification of derivation of keys required for security Nakhjiri & Ohba Expires December 24, 2007 [Page 1] Internet-Draft Hokey hierarchy June 2007 protection of key requests and delivery signaling. The key delivery framework also includes proper specification and conveyance of the context and scope of the keys being delivered. Derivation of the EMSK based handover root key (HRK) and domain specific handover root keys (DSHRK) for use in the problem of handover keying and re- authentication is also described. Table of Contents 1. Introduction and Problem statement . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. EMSK key delivery architecture . . . . . . . . . . . . . . . . 6 4. Distribution of EAP based keys to a third party . . . . . . . 10 4.1. Overview of the 3 party key distribution exchange (KDE) . 11 4.2. 3 party key exchange scenarios . . . . . . . . . . . . . . 13 4.3. Derivation of keys protecting the KDE . . . . . . . . . . 14 4.3.1. keys protecting the KDE within a domain . . . . . . . 16 4.4. Specification of context and scope for distributed keys . 17 5. key derivation and delivery scenarios . . . . . . . . . . . . 17 5.1. Derivation and delivery of Handover Root Key . . . . . . . 17 5.1.1. Delivery of HRK to HOKEY server . . . . . . . . . . . 18 5.2. Derivation and delivery of Domain Specific Root keys . . . 20 5.2.1. Delivery of DSRK to domain server . . . . . . . . . . 20 5.3. Domain Specific Handover Root key . . . . . . . . . . . . 22 5.4. key delivery within a domain . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 9.2. Informative references . . . . . . . . . . . . . . . . . . 25 Appendix A. Appendix A: Roaming hieararchy based on HRK . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Nakhjiri & Ohba Expires December 24, 2007 [Page 2] Internet-Draft Hokey hierarchy June 2007 1. Introduction and Problem statement The ability of Extensible Authentication Protocol (EAP) framework ([RFC3748] ) in incorporating desired authentication methods and generating master session keys [I-D.ietf-eap-keying]) has led to the idea of using EAP authentication and the resulting key material for bootstrap further keys for a variety of security mechanisms. Out of two master session keys, generated from EAP, the MSK is used heavily for bootstrapping the security associations for the wireless link between the peer and the network. However, the combination of the heavy deployment of these solution and their issues around mobility performance and agility ([I-D.nakhjiri-aaa-hokey-ps], [I-D.ohba-hokey-3party-keydist-ps] and [I-D.ietf-hokey-reauth-ps]) had led the IETF HOKEY to consider use of the extended master session key (EMSK) for providing future security bootstrapping problems, such as handover keying, re-authentications and IP mobility provisioning signaling. Currently, specifications on use of EAP EMSK for generating further keys in still work under progress. A general guideline document ([I-D.ietf-hokey-emsk-hierarchy]) describes how one can use EMSK to generate the following child keys: USRK: Usage Specific Root key. A root key generated from EMSK and is used for a specific usage that is authorized for a peer, following an EAP authentication. USRK is domain independent. DSRK: Domain Specific Root key. A root key generated from EMSK and is used within a specific domain that peer is authorized to receive services from or roam into, following an EAP authentication. DSRK is usage independent. DSUSRK: Domain Specific Usage Specific Root key. A root key generated from EMSK and is used for a specific usage within a specific domain that peer is authorized to receive services from, following an EAP authentication. DSUSRK is both usage and domain dependent. EMSK ________________|_____________________________ | | | | | | DSRK1 .. DSRKn USRK1..USRKm DSUSRK1 DSUSRKj Figure 1: Different categories of EMSK Child keys Nakhjiri & Ohba Expires December 24, 2007 [Page 3] Internet-Draft Hokey hierarchy June 2007 [I-D.ietf-hokey-emsk-hierarchy] also describes how the knowledge related to a specific usage or an administrative domain can be used as standardized format input data into a cryptographic function to generate USRKs, DSRK and DSUSRKs. The guidelines assure that different child keys generated from the EMSK are cryptographically separate from each other, so that compromise any EMSK child key does not lead to compromise of the parent EMSK or the sibling child keys. It should be noted that a USRK can be used to generate domain specific keys for that specific usage (DSUSRK), while on the other hand, a DSRK may have been authorized to a specific domain for a set of allowed services. So it is also possible to create DSUSRKs for those services at that domain. Thus coordination is necessary between the home and visited domain on which DSUSRKs are generated from USRK at home, which DSUSRKs can be generated from DSRK at visited domain and which DSUSRKs can be generated directly as EMSK child keys at the EAP server. Since EAP authentication is a 2 party protocol, additional measures should be taken to properly utilize the EAP generated keys in a 3 party key management arrangement. While USRK, DSRK and DSUSRK are typically stored and utilized at third party key holders (e.g. AAA servers/ entities) logically or physically separate from the EAP server or peer, the security restrictions ([I-D.ietf-eap-keying]) forbid against transport of EMSK outside the EAP server/ layer. On the other hand, EAP authentication and EMSK generation process is oblivious to the future service requests and authorizations. This will imply that the input data required for creation of the USRK, DSRK or DSUSRK needs to be delivered to the EAP server, performing the derivation function, followed by a secure delivery of the resulting keys to these third party key holders. It is the purpose of this document to show how such input data can be delivered to the EAP server, and how the generated key material is delivered to the third party key holder in a secure manner, while considering the security requirements and principles defined in [I-D.housley-aaa-key-mgmt] and [I-D.ohba-hokey-3party-keydist-ps] into account. Thus, the specification includes derivation of key material required for secure key delivery and channel binding procedures to ensure that not only the keys are not exposed to unintended parties during delivery, but also the scope and usage context for the key is properly understood and agreed upon by the initial parties. To provide a complete solution for the problem of handover keying and re-authentication, the key hierarchy specified in this document includes specification of use of EMSK in derivation of top level handover root keys (HRK), domain specific root keys (DSRK) and the DSUSRK specifically for handover, called domain specific handover root key (DSHRK), according to [I-D.ietf-hokey-emsk-hierarchy] and Nakhjiri & Ohba Expires December 24, 2007 [Page 4] Internet-Draft Hokey hierarchy June 2007 the delivery of these keys to the intended third parties. The purpose of this document is not to provide exact syntax for the signaling, only the general semantics for the parameters involved are defined. The exact syntax for these parameters when carried by specific protocols, such as AAA protocols or EAP protocols are out of scope of this document. 2. 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]. DSRK: Domain Specific Root key. A root key generated from EMSK and is used within a specific domain that peer is authorized to receive services from or roam into, following an EAP authentication. DSRK is usage independent. DSRK holder (DSR-KH): The DSR-KH is responsible for receiving, holding and protection of the DSRK derived directly from EMSK. The DSR-KH is possibly responsible for derivation and distribution of any child keys derived from DSRK for that specific domain. The most likely realization of DSR-KH is a AAA server in the corresponding domain, responsible for setting the policies for usage of DSRK within the domain. DSUSRK: Domain Specific Usage Specific Root key. A root key generated from EMSK and is used for a specific usage within a specific domain that peer is authorized to receive services from, following an EAP authentication. DSUSRK is both usage and domain dependent. DSUSRK holder (DSUSR-KH): The DSUSR-KH is responsible for receiving, holding and protection of the DSUSRK derived directly from EMSK. The DSUSR-KH is possibly responsible for derivation and distribution of any child keys derived from DSUSRK for that specific domain and usage. The most likely realization of DSUSR-KH is a AAA server in the corresponding domain, responsible for the service offered within the domain for the specific usage at hand. HOKEY server: This is essentially a usage specific server, that deals with handover and re-authentication as specific usage (USR-KH for HOKEY). For the purpose of this document, a HOKEY server is domain independent and interacts directly with EAP server to receive HRK from EAP server. This top level HOKEY Nakhjiri & Ohba Expires December 24, 2007 [Page 5] Internet-Draft Hokey hierarchy June 2007 server can generate and deliver domain specific HRKs (DSHRK) to domain HOKEY servers. domain HOKEY server: This is a server handling HOKEY service and holding the domain specific HRK (DSHRK) for a specific domain. For practical purposes, this can be a domain AAA server handling HOKEY service. When DSHRK is generated from HRK, domain HOKEY server deals with top level HOKEY server. When DSHRK is generated directly from EMSK, the domain HOKEY server deals directly with EAP server. HRK: Handover root key is a key that will be used as the root key to solve the handover keying and re-authentication problem. The HRK is considered a usage specific root key (USRK) (defined in [I-D.ietf-hokey-emsk-hierarchy]) and is derived directly from EMSK. HRK is a domain independent specific root key for re- authentication and handover, meaning that it can be used to create domain-specific HRK for various domains (DSHRK). HRK is generated using a Pseudo random function (PRF) that complies with requirements and guidance in [I-D.ietf-hokey-emsk-hierarchy]. For simplicity we refer to this PRF as USRK_PRF. DSHRK: Domain specific handover root key: A key that can only be used for HOKEY service within a specific domain. IK and CK: Integrity and cipher keys, used to protect the key delivery signaling between the peer and the EAP server. These two keys are some times referred to as key delivery keys. USRK: Usage Specific Root key. A root key generated from EMSK and is used for a specific usage that is authorized for a peer, following an EAP authentication. USRK is domain independent. USRK holder (USR-KH): The USR-KH is responsible for receiving, holding and protection of the USRK derived directly from EMSK. The USR-KH is possibly responsible for derivation and distribution of any child keys derived from USRK for that specific usage. 3. EMSK key delivery architecture As mentioned earlier, EMSK can be used to generate any of the USRKs, DSRK and DSUSRKs. It should however be noted that a USRK can be used to generate domain specific keys for that specific usage (DSUSRK), while on the other hand, a DSRK may have been authorized to a specific domain for a set of allowed services. So it is also possible to create DSUSRKs for those services at that domain. While the end result, a DSUSRK, is the same, the way to arrive at and Nakhjiri & Ohba Expires December 24, 2007 [Page 6] Internet-Draft Hokey hierarchy June 2007 deliver the DSUSRK to the proper destination is important: First, coordination is necessary between the home and visited domain on which DSUSRKs are generated from USRK at home, which DSUSRKs can be generated from DSRK at visited domain and which DSUSRKs can be generated directly as EMSK child keys. Second, the destination to which the key is delivered is dictated by the type of key being generated. This is important, since the EAP keying framework ([I-D.ietf-eap-keying]) forbids against transport of EMSK outside the EAP server/ layer to ensure the security of EMSK. On the other hand, the EAP server is not expected to be involved in any service authorization decisions. To keep the generality of the specification of the key delivery mechanism, we introduce the notion of key holders: USRK holder (USR-KH): For the purpose of the key delivery mechanism specified in this document, this is an entity acting as a recipient of the usage specific root key (USRK) derived from the EMSK and delivered from the EAP server. Also, for the purpose of the key delivery mechanism, the USR-KH has a interface with the EAP server and is responsible for delivering the usage specific input data required for derivation of USRK from EMSK to the EAP server. Thus USR-KH is responsible for receiving, holding and protection of the USRK derived directly from EMSK. The USR-KH is possibly responsible for derivation and distribution of any child keys derived from USRK for that specific usage. DSRK holder (DSR-KH): For the purpose of the key delivery mechanism specified in this document, this is an entity acting as a recipient of the domain specific root key (DSRK) derived from the EMSK and delivered from the EAP server. Also, for the purpose of the key delivery mechanism, the DSR-KH has a interface with the EAP server and is responsible for delivering the domain specific input data required for derivation of DSRK from EMSK to the EAP server. Thus DSR-KH is responsible for receiving, holding and protection of the DSRK derived directly from EMSK. The DSR-KH is possibly responsible for derivation and distribution of any child keys derived from DSRK for that specific domain. The most likely realization of DSR-KH is a AAA server in the corresponding domain, responsible for setting the policies for usage of DSRK within the domain. DSUSRK holder (DSUSR-KH): For the purpose of the key delivery mechanism specified in this document, this is an entity acting as a recipient of the domain specific and usage specific root key (DSUSRK) derived from the EMSK and delivered from the EAP server. Also, for the purpose of the key delivery mechanism, the DSUSR-KH has a interface with the EAP server and is responsible for delivering the domain and usage specific input data required for Nakhjiri & Ohba Expires December 24, 2007 [Page 7] Internet-Draft Hokey hierarchy June 2007 derivation of USRK from EMSK to the EAP server. Thus DSUSR-KH is responsible for receiving, holding and protection of the DSUSRK derived directly from EMSK. The DSUSR-KH is possibly responsible for derivation and distribution of any child keys derived from DSUSRK for that specific domain and usage. The most likely realization of DSUSR-KH is a AAA server in the corresponding domain, responsible for the service offered within the domain for the specific usage at hand. In a general case, we can assume that the EAP server at the time of authentication is unaware of any future service authorization requests from the peer. Thus, the EAP server caches EMSK and creates each of the EMSK child keys based on request, using its cache of EMSK. Thus, the key holder needs to provide the EAP server with proper input data before receiving the requested key. For instance a visited domain HOKEY server, needs to authorize the peer for handover keying and re-authentication service, and then request a handover root key for its domain (visited domain HRK, VHRK) from the EAP server. A home domain may also operate a home HOKEY server that uses a home handover root key (HHRK) to serve the peer's re-authentication and handover keying needs within home domain. The following figure shows the assumed logical architecture for each type of EMSK child key being created and delivered: Nakhjiri & Ohba Expires December 24, 2007 [Page 8] Internet-Draft Hokey hierarchy June 2007 +-+-+-+-+-+-+ | EAP server| +-+-+-+-+-+-+ USRK1 / \ USRK2 (HRK) / \ (XYZ) +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | USR-KH1 | | USR-KH2 | | HOKEY server | | XYZ server| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | peer | +-+-+-+-+-+-+ (A) +-+-+-+-+-+-+ | EAP server| +-+-+-+-+-+-+ DSUSRK1 / \ DSUSRK2 (HHRK) / \ (VHRK) +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | Domain 1 | | Domain 2 | | DSUSR-KH | | DSUSR-KH | |(home domain | |(visited domain| |HOKEY server)| |HOKEY server) | +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | peer | +-+-+-+-+-+-+ (B) +-+-+-+-+-+-+-+-+-+ | EAP server | +-+-+-+-+-+-+-+-+-+ / DSRK1 \ DSRK2 / \ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | DSR-KH1 | | DSR-KH2 | +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | peer | +-+-+-+-+-+-+ (C) Nakhjiri & Ohba Expires December 24, 2007 [Page 9] Internet-Draft Hokey hierarchy June 2007 Figure 2: Key delivery for various EMSK child key cateories As one can see, depending on the type of key being delivered, different third party key holders are involved. The general mechanism for delivering a key to 3rd party is described in the following section. 4. Distribution of EAP based keys to a third party EAP authentication method signaling and the following EMSK generation is performed between the peer and the EAP server in a manner that is almost transparent to all intermediaries. However, providing a keying service, such as the handover keying and re-authentication services, involves a set of key management services, including creation of a key hierarchy and installation of specific keys at one or more of such third party intermediaries (figure 2). Requirements for such AAA/ EAP based key management procedures are stated in several documents ([I-D.housley-aaa-key-mgmt], [I-D.ietf-hokey-reauth-ps], [I-D.ohba-hokey-3party-keydist-ps] ). Requirements such as well-defined key scope and authentication of all parties are addressed by the following 3 party key distribution mechanism, which allows distribution of a key, initially only known to two parties (typically directly and mutually authenticated), to a well-identified third party. As seen above handover keying and re-authentication service requires distribution of keys a variety of intermediaries. In the following we describe the mechanism for a 3 party key distribution exchange (KDE), where a key is distributed from a network server (with parent key holder) to a generic third party. The following shows a generic trust model for the 3 party key distribution mechanism. The peer (P) and a parent key holder, called "server" (S) in this model share a parent key from the key hierarchy. From this parent key, a key (Kpt) is to be generated and distributed to a third party intermediary (T). We keep the generation of Kpt out of the general description of the KDE (key distribution exchange) as the goal is show the process for distribution of Kpt from S to T. To support the key distribution mechanism, we assume that the peer and the server share a set of security associations, including keys for integrity and privacy protection of the signaling between the peer and the server (KIps and KCps for integrity and privacy protection). We also assume that the server (S) and the third party (T) share a similar set security association (KIts, KCts). Nakhjiri & Ohba Expires December 24, 2007 [Page 10] Internet-Draft Hokey hierarchy June 2007 +-+-+-+-+ +-+-+-+-+-+-+-+ | | shared SA1 | | | |------------------------------| server | | Peer | | KH | +-+-+-+-+ +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+ V | 3 rd party | | SA2 (Kpt) | KH | ----------| +-+-+-+-+-+-+ Figure 3: Distribution of a child key from a parent key key holder to a 3rd party child key key holder 4.1. Overview of the 3 party key distribution exchange (KDE) The key distribution mechanism described below is a modified version of the Otway-Rees protocol that meets the requirements for such 3-party lay-out. The description below can be carried over a generic transport and thus is independent of the exact type of protocol that is used. However for the purpose of this document the assumption is that the 3 party mechanism parameters are carried for EAP messages that are themselves encapsulated over a lower layer such as a AAA protocol or an access protocol. The exchange proposed below is to perform a channel binding and avoid the lying intermediary scenario, where the intermediary announces a down link ID to the peer (DTID) and a different uplink ID to the server (UTID). The peer uses DTID in its token towards the server, while the intermediary uses its UTID in its token to the server. Server must use the UTID from peer token to calculate the MIC in the third party token ([PID, UTID]KIts) and if there is a match, then the server can verify that DTID and UTID are the same as the TID and proceed with generating and provisioning of Kpt, otherwise the server MUST return a failure code instead of generating an Kpt. The 3 party key distribution basically consists of 1 exchange, i.e. 2 messages between the peer and the server. However, in most scenarios each message traverses through the intermediary, i.e. Over two logical hops (peer-third party) and (third party-server) even though the exchange seems to consist of 4 logical messages. It should be noted that the information in message 0 is typically conveyed as an advertisement through other means. 0 Third party to peer: (DTID, DID) Nakhjiri & Ohba Expires December 24, 2007 [Page 11] Internet-Draft Hokey hierarchy June 2007 1 Peer to Third party: Int[ KIps, (PID, DTID, DID, Np,KN_KIps)] 2 Third party to Server: Int[KIts, (PID, UTID)], Int[ KIps, (PID, DTID, DID, Np,KN_KIps)] 3 Server to third party: {PID,TID,KN_Kpt, KL_Kpt, Kpt}KCts, Int[ KIps, (PID, TID, DID, Np+1,KN_Kpt,KL_Kpt, KN_KIps)] 4 Third party to Peer: Int[KIps, (PID, TID, DID, Np+1, KN_Kpt,KL_Kpt, KNps)] the notation is as follows: PID: peer ID. The information is expected by carried by an existing attribute within EAP and/or AAA protocols. DID: Domain ID, used for generation of domain specific keys, such as HHRK (see key generation). TID: third party ID (obtained by the peer through beacon announcements or other means) DTID: third party ID as perceived by the peer (down link ID) UTID: third party ID as perceived by the server (uplink ID) {X}K: X encrypted with key K Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X with key K. KIps: A symmetric key shared between peer and Server for signing and identified by KN_KIps. KCps: A symmetric key shared between peer and Server for encryption and identified by KN_KCps KCts: A symmetric key shared between third party and Server for encryption (provisioned out of band). KIts: A symmetric key between third party and server for signing (provisioned out of band). Kpt: A symmetric key to be shared between peer and third party (key to be distributed to third party). The key is named as KN_Kpt. KL_Kx : Key lifetime for key x Nakhjiri & Ohba Expires December 24, 2007 [Page 12] Internet-Draft Hokey hierarchy June 2007 KN_Kx: Key name for Key x, e.g. KN_KIas: key name for KIas Nx : Nonce provided by the party X Int[ KIps, (PID, DTID, DID, Np,KN_KIps)] is called the peer request token (PRT), which carries the identities of both peer and the third party along with a signature. The signature is called the peer request authenticator (PRA). Int[KIts, (PID, UTID)] is called thirdparty_ID_token (TIT), which carries a signature, called third party ID authenticator. {PID,TID,KN_Kpt, KL_Kpt, Kpt}KCts is called key_token (KT), which carries the Kpt wrapped with KCts (encryption key shared between the third party and server). Int[ KIps, (PID, TID, DID, Np+1,KN_Kpt,KL_Kpt, KN_KIps)] is called Server_authorization_token (SAT). 4.2. 3 party key exchange scenarios The following scenarios can be envisioned for distribution of a key to a 3rd party. All scenarios assume the peer and the EAP server have mutually authenticated to each other using an EAP method and have generated an EMSK. EAP server to USR-KH: The service requested by the peer (e.g. Handover keying and re-authentication keying service) is provided by the a server that also authorizes that service. This server is a AAA-style server other than the EAP server (e.g. a HOKEY server), since EAP server is typically only in charge of EAP authentication and MSK/EMSK generation. For the purpose of this document, we assume that this server is the USR-KH for that service (usage). Following the authorization of the service (usage) a request is placed with the EAP server and the USRK is generated and delivered to USR-KH. The USR-KH is domain independent and the USR-KH can use USRK to generate DSUSRK for other domain. It is possible that this USR-KH server is not physically disjunct from the EAP server and thus is identified with the same identity as the EAP server. In such cases, the existence of USR-KH server is to off-load the EAP server from the need to handle usage specific services, such as HOKEY service, for multiple domains. Security Requirements for delivery of USRK from EAP server to a collocated USR-KH is currently TBD. However, to keep the specifications generic here, we assume that USR-KH and EAP server are physically separate and specify the delivery of USRK from EAP server to USR-KH according to the KDE. The specific use case considered in this document is HOKEY service: The USR-KH Nakhjiri & Ohba Expires December 24, 2007 [Page 13] Internet-Draft Hokey hierarchy June 2007 is a HOKEY service and USRK is HRK. The EAP server delivers the HRK to the USR-KH (HOKEY server). The details of this procedure is discussed later in this document. The trigger and mechanism for key delivery may involve a specific request from the peer and another intermediary (such as authenticator) for HOKEY service. EAP server to DSR-KH In this scenario, a domain server, typically a domain AAA server requires delivery of a DSRK for all allowed usage within the domain. DSR-KH are EAP server are physically disjunct. Thus deployment of 3 party key distribution exchange is required. USR-KH to DSUSR-KH: This stage assumes that both peer and USR-KH server possess USRK, and further operation between peer and the domain that the peer intends to attach to, depends on delivery of a domain specific USRK (DSUSRK) to the DSUSR-KH. It is best to assume that the USR-KH and DSUSR-KH HOKEY are physically separate and thus deployment of the 3 party KDE is required for the delivery of DSUSRK. domain specific key management operations: Domain specific scenarios can involve delivery of keys that are at lower levels of the key hierarchy, for instance keys that are children of USRK, DSRK or DSUSRK and not children of EMSK. Such key generation and management scenarios do not involve EAP server, but still can and need to use a 3 party key distribution exchange mechanism to ensure secure delivery of the key to a third party. An example is delivery of per-authenticator keys from domain HOKEY server to an authenticator. 4.3. Derivation of keys protecting the KDE As shown in the generic description of the key distribution exchange, to protect the exchange, at least one (or two) keys are required to protect the exchange. These keys are an integrity and a cipher key. These keys are generated from the EMSK hierarchy themselves. However, as discussed when enumerating the various KDE use case scenarios, the KDE can and need to be used in many different scenarios for delivering keys. Depending on the key that is being delivered, the integrity and cipher keys can be generated at different levels of the key hierarchy as well. For instance to protect the KDE performed to deliver an EMSK child key (USRK, DSRK, or DSUSRK), these two keys are generated directly from EMSK. Nakhjiri & Ohba Expires December 24, 2007 [Page 14] Internet-Draft Hokey hierarchy June 2007 EMSK ________________|________________ | | | | | DSRK USRK DSUSRK CK IK Figure 4: Key delivery keys as EMSK Child keys Cipher key (CK) and Integrity Key (IK) are generated from EMSK as domain independent USRKs. CK and IK are used to protect KDE for delivery of USRK, DSRK and those DSUSRKs that are generated from EMSK directly. We refer to PRF used to generate the USRKs, USRK-PRF, and assume that it can generate Z bits of output. In order to be able to perform the key delivery exchange, IK | IK_name_key=USRK-PRF (EMSK, "Integrity Key" | NULL | peer_ID | Key_length ) IK_name=First(128, HMAC_SHA256(IK_name_key "Integrity Key"| NULL| peer_ID) CK | CK_name_key=USRK-PRF (EMSK, "Cipher Key" | NULL | peer_ID | Key_length ) CK_name=First(128, HMAC_SHA256(CK_name_key, "Cipher Key" | NULL | peer_ID) Where, First (N, X) refers to the first N bits of X and it is assumed that USRK_PRF generates Z=X+Y bits, where the first X bits are used for key itself, while the remaining Y bits are used for key_name_key, which is used to create temporal uniqueness in the key name generation. Choice of Z and X are outside scope of this document. The "Usage_label" value is to be assigned by IANA to the strings "Integrity Key" and "Cipher Key". NULL as domain label, since the IK and CK are considered to be a usage specific, but domain independent keys. Thus domain label is wild carded. Peer_ID is the identifier for the peer. This identifier is exchanged in the key distribution exchange (KDE) as described shortly. It is assumed the parties involved in the key distribution exchange will need to be able to have access (or derive??) to the CK and IK to Nakhjiri & Ohba Expires December 24, 2007 [Page 15] Internet-Draft Hokey hierarchy June 2007 protect the key delivery signaling. 4.3.1. keys protecting the KDE within a domain The following provides an example of derivation of integrity and cipher keys for distributions of service related keys within a domain. We assume that the keys to be delivered (KX or KY) are derived from a DSUSRK for that domain and specific usage. We call the cipher key and integrity key for delivering a domain and usage specific child of DSUSRK, the DUCK and DUIK, respectively. DSUSRK ______|________________ | | | | KX KY DUCK DUIK Figure 5: Keys for delivery of service keys within a domain DUIK | DUIK_name_key=PRF (DSUSRK, "domain usage Integrity Key" | Domain Label | peer_ID | Key_length ) DUIK_name=First(128, HMAC_SHA256(DUIK_name_key "domain usage Integrity Key"| Domain Label | peer_ID) DUCK | DUCK_name_key=PRF (DSUSRK, "domain usage Cipher Key" | Domain Label | peer_ID | Key_length ) DUCK_name=First(128, HMAC_SHA256(DUCK_name_key, " domain usage Cipher Key" | Domain Label | peer_ID) KX and KY above are both keys related to a specific service as defined in generation of DSUSRK. It is also possible to use the same keys to protect delivery of keys for all services within a domain, as long as service independent root keys (DSRK) are available. In that case, the key delivery keys (integrity and cipher keys for KDE protection) are derived from a DSRK, so that the same keys can be used to protect KDE for delivery of keys for any type of key derived from DSRK. DSRK ______|________________ | | | | KX KY DCK DIK Figure 6: Keys for delivery of keys within a domain Nakhjiri & Ohba Expires December 24, 2007 [Page 16] Internet-Draft Hokey hierarchy June 2007 DIK | DIK_name_key=PRF (DSRK, "domain Integrity Key" | Domain Label | peer_ID | Key_length ) DIK_name=First(128, HMAC_SHA256(DIK_name_key "domain Integrity Key"| Domain Label | peer_ID) DCK | DCK_name_key=PRF (DSRK, "domain Cipher Key" | Domain Label | peer_ID | Key_length ) DCK_name=First(128, HMAC_SHA256(DCK_name_key, " domain Cipher Key" | Domain Label | peer_ID) 4.4. Specification of context and scope for distributed keys To be completed. 5. key derivation and delivery scenarios 5.1. Derivation and delivery of Handover Root Key Depending on the deployment and trust models, several key hierarchy models can be considered for solving the handover and re- authentication problem, based on the category of the EMSK child key categories used. In this section we will discuss derivation and delivery of handover root key (HRK) as a top level root key for handover keying and re-authentication usage. This will not only serve as an example for derivation and delivery of a USRK, but also provide enough specification to support other handover keying and re- authentication specifications. HRK is considered as USRK. The USR-KH to cache and maintain HRK is called HOKEY server. Since the top level HRK is domain independent, a domain independent HOKEY server can hold HRK and can act authorization server for service to multiple domains, delivering domain specific HRK (DSHRK) to each domain as needed. Domain dependent HOKEY servers are deployed in each domain to be only responsible for receiving DSHRK and authorization and delivery of handover keying and re-authentication services within that domain. In this section we only discuss delivery of HRK to top level HOKEY server, leaving delivery of DSHRKs for later. subscribing to the model of USRK for HRK derivation and delivery, the following portions of the EMSK hierarchy are considered in this section. As mentioned in [I-D.ietf-hokey-emsk-hierarchy] the USRK- PRF used below can be negotiated, pre-configured based on network policy. We assume that it can generate Z=X+Y bits of output, where the first X bits are used for HRK, while the remaining Y bits are Nakhjiri & Ohba Expires December 24, 2007 [Page 17] Internet-Draft Hokey hierarchy June 2007 used for HRK_name_key, which is used to create temporal uniqueness in the key name generation. EMSK ________|_____________ | | | HRK CK IK Figure 7: Using EMSK for HRK derivation and delivery HRK | HRK_name_Key=USRK-PRF (EMSK, Usage_label | NULL | Peer_ID | Key_length) HRK_name=First (128, HMAC_SHA256(HRK_name_Key, "Usage_label | NULL | peer_ID)) The "Usage_label" value is to be assigned by IANA to the string "Handover Root Key". NULL as domain label, since the HRK is considered to be a usage specific (for handover keying and re-authentication) but domain independent root key. Thus domain label is wild carded. This way the same HRK can be used to create root keys for all visited and home domains. Peer_ID is the identifier for the peer as known to the server generating HRK. This identifier is exchanged in the key distribution exchange (KDE) as described shortly. The HRK is stored at this HOKEY server database. We can call this database the HRK key holder (HRK-KH). HOKEY server can for instance generate a home HRK (HHRK) for the home HOKEY server or AAA server and a visited HRK (VHRK) for the visited HOKEY server or AAA server. 5.1.1. Delivery of HRK to HOKEY server The HOKEY server is a USR-KH, which is considered a third party to the initial EAP parties (peer and EAP server). The key distribution exchange (KDE) can be used to the deliver the HRK from EAP server to the domain independent HOKEY server, using the CK and IK derived from EMSK (described in earlier section). Since HRK is domain independent, domain information is omitted from exchanged tokens. Nakhjiri & Ohba Expires December 24, 2007 [Page 18] Internet-Draft Hokey hierarchy June 2007 0 HOKEY server to peer: (DHID) 1 Peer to HOKEY server: Int[ IK, (PID, DHID, Np,KN_IK)] 2 HOKEY server to EAP Server: Int[KIhs, (PID, UHID)], Int[ IK, (PID, DHID, Np,KN_IK)] 3 EAP Server to HOKEY server: {PID,HID,KN_HRK, KL_HRK, HRK}KChs, Int[ IK, (PID, HID, Np+1,KN_HRK,KL_HRK, KN_IK)] 4 HOKEY server to Peer: Int[IK, (PID, HID, Np+1, KN_HRK,KL_HRK, KN_IK)] the notation is as follows: PID: peer ID. The information is expected by carried by an existing attribute within EAP and/or AAA protocols. HID: HOKEY server ID (obtained by the peer through beacon announcements or other means) DHID: downlink HOKEY server ID as perceived by the peer (down link ID) UHID: Uplink HOKEY server ID as perceived by the EAP server (uplink ID) {X}K: X encrypted with key K Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X with key K. IK: Integrity key, A symmetric key shared between peer and EAP Server for signing and identified by KN_IK. CK: A symmetric key shared between peer and EAP Server for encryption and identified by KN_CK KChs: A symmetric key shared between HOKEY and EAP servers for encryption (provisioned out of band). KIhs: A symmetric key between HOKEY and EAP servers for signing (provisioned out of band). HRK: to be shared between peer and HOKEY server. The key is named as KN_HRK. KLx : Key lifetime for key x Nakhjiri & Ohba Expires December 24, 2007 [Page 19] Internet-Draft Hokey hierarchy June 2007 KN_Kx: Key name for Key x, e.g. KN_KIas: key name for KIas Nx : Nonce provided by the party X Roaming between two administrative domains, e.g. from home domain to visited domain, while mid-session, would require involvement of a top level HOKEY server, so that it can generate a domain-specific HRK (DSHRK) for that domain. 5.2. Derivation and delivery of Domain Specific Root keys A domain server acts as an authority for authorizing services, and DSRK holder (DSR-KH) and can authorize and generate keys for a set of services for which DSRK is generated (see [I-D.ietf-hokey-emsk-hierarchy]). In this model each domain server needs to refer to the EAP server to derive DSRK directly from the EMSK. DSRK | DSRK_name_Key=DSRK_PRF(EMSK, NULL | Domain_ID | Peer_ID | Key_length) DSRK_name=First (128, HMAC_SHA256(DSRK_name_Key, NULL | peer_ID)) Where Usage label is wild carded by inserting a NULL. the Domain_ID is the identifier of the domain for which the DSRK is being derived, e.g. Home_domain_ID for DSHRK. 5.2.1. Delivery of DSRK to domain server The DSR-KH is considered as a third party and thus the key distribution exchange is to be used for distributing DSRKs to the DSR-KH. CK and IK derived from EMSK (described in earlier section) are used for protecting the signaling. The delivery of DSRK to DSR-KH is very similar to delivery of USRK to USR-KH, except the domain ID needs to be communicated to both peer and EAP server. 0 Domain server to peer: (DDID, DID) 1 Peer to Domain server: Int[ IK, (PID, DDID, DID, Np,KN_IK)] 2 Domain server to EAP Server: Int[KIds, (PID, UDID)], Int[ IK, (PID, DDID, DID, Np,KN_IK)] 3 EAP Server to Domain server: {PID,DID,KN_DSRK, KL_DSRK, DSRK}KCds, Int[ IK, (PID, DID, Np+1,KN_DSRK,KL_DSRK, KN_IK)] Nakhjiri & Ohba Expires December 24, 2007 [Page 20] Internet-Draft Hokey hierarchy June 2007 4 Domain server to Peer: Int[IK, (PID, DID, Np+1, KN_DSRK,KL_DSRK, KN_IK)] the notation is as follows: PID: peer ID. The information is expected by carried by an existing attribute within EAP and/or AAA protocols. DID: Domain server ID (obtained by the peer through beacon announcements or other means) DDID: down link Domain server ID as perceived by the peer (down link ID) UDID: Uplink Domain server ID as perceived by the EAP server (uplink ID) {X}K: X encrypted with key K Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X with key K. IK: Integrity key, A symmetric key shared between peer and EAP Server for signing and identified by KN_IK. CK: A symmetric key shared between peer and EAP Server for encryption and identified by KN_CK KCds: A symmetric key shared between Domain and EAP servers for encryption (provisioned out of band). KIds: A symmetric key between Domain and EAP servers for signing (provisioned out of band). DSRK: to be shared between peer and domain server. The key is named as KN_DSRK. KLx : Key lifetime for key x KN_Kx: Key name for Key x, e.g. KN_KIas: key name for KIas Nx : Nonce provided by the party X Roaming between two administrative domains, e.g. from home domain to visited domain, while mid-session, would require involvement of EAP server, so that it can generate a domain-specific HRK (DSRK) for that domain based on the knowledge of peer and domain server identities. Nakhjiri & Ohba Expires December 24, 2007 [Page 21] Internet-Draft Hokey hierarchy June 2007 5.3. Domain Specific Handover Root key A domain server can act as domain HOKEY server, holding the DSUSRK for HOKEY usage (DSUSR-KH). In this model each domain HOKEY server needs to refer to the EAP server to derive DSHRK directly from the EMSK. DSHRK | DSHRK_name_Key=DSUSRK_PRF(EMSK, Usage_lable| Domain_ID | Peer_ID | Key_length) DSHRK_name=First (128, HMAC_SHA256(DSHRK_name_Key, Usage_label | peer_ID)) Where Usage label is "Domain Handover Root Key". the Domain_ID is the identifier of the domain for which the DSHRK is being derived, e.g. Home_domain_ID for HHRK. When roaming from one domain to the next, a domain specific handover root key (DSHRK) needs to be requested and generated from the EMSK and based on the knowledge of peer and domain server identities. 5.4. key delivery within a domain In this section we describe the use of KDE in delivery a key within a domain. We use delivery of a key to be shared between a peer and an authenticator (Kpa) from a domain HOKEY server to an authenticator as an example. The domain HOKEY server holds a domain specific handover root key (DSHRK) and thus is a DSUSR-KH. The peer and the domain HOKEY server share the DSHRK and can be both generate the Kpa. The authenticator is considered as a third party. The KDE is used to deliver the Kpa to the authenticator. However, since the KDE is performed within a domain, domain and usage specific IK and CK (DUIK and DUCK) are used for protecting the signaling. The derivation of DUIK and DUCK is described in section XXX. 0 Authenticator to peer: (DAID, DID) 1 Peer to Authenticator: Int[ DUIK, (PID, DAID, DID, Np,KN_DUIK)] 2 Authenticator to Domain HOKEY Server: Int[KIas, (PID, UAID)], Int[ DUIK, (PID, DAID, DID, Np,KN_DUIK)] 3 Domain HOKEY server to Authenticator: {PID,DID,KN_Kpa, KL_Kpa, Kpa}KCas, Int[ DUIK, (PID, DID, Np+1,KN_Kpa,KL_Kpa, KN_DUIK)] Nakhjiri & Ohba Expires December 24, 2007 [Page 22] Internet-Draft Hokey hierarchy June 2007 4 Authenticator to Peer: Int[DUIK, (PID, DID, Np+1, KN_Kpa,KL_Kpa, KN_DUIK)] the specific notation is as follows: PID: peer ID. The information is expected by carried by an existing attribute within EAP and/or AAA protocols. DID: Domain ID, used for generation of domain specific keys, such as HHRK (see key generation). AID: Authenticator ID (obtained by the peer through beacon announcements or as part of EAP Identity Request) DAID: Authenticator ID as perceived by the peer (down link ID) UAID: Authenticator ID as perceived by the server (uplink ID) {X}K: X encrypted with key K Int[K, X]: X | MIC (K, X) Message Integrity Code over X with key K. X(Y): Y carried with X protocol DUIK: Integrity key, A symmetric key shared between peer and domain HOKEY server for signing and identified by KN_DUIK. DUCK: A symmetric key shared between peer and domain HOKEY server for encryption and identified by KN_DUCK KCas: A symmetric key shared between authenticator and Server for encryption (provisioned out of band). KIas: A symmetric key between authentication and server for MDCs for signing (provisioned out of band). Kpa: A symmetric key to be shared between peer and authenticator. The key is named as KN_Kpa. KLx : Key lifetime for key x KN_Kx: Key name for Key x, e.g. KN_KIas: key name for KIas Nx : Nonce provided by the party X 6. Security Considerations Nakhjiri & Ohba Expires December 24, 2007 [Page 23] Internet-Draft Hokey hierarchy June 2007 7. IANA consideration This document defines new usage labels, such as those used in generation of CK, IK, HRK. The corresponding labels (e.g. "Integrity Key" and "Cipher key") need to be assigned numerical values by IANA. 8. Acknowledgements The author would like to thank XX feedback. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-18 (work in progress), February 2007. [I-D.nakhjiri-aaa-hokey-ps] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem Statement", draft-nakhjiri-aaa-hokey-ps-03 (work in progress), June 2006. [I-D.ietf-hokey-reauth-ps] Clancy, C., "Handover Key Management and Re-authentication Problem Statement", draft-ietf-hokey-reauth-ps-01 (work in progress), January 2007. [I-D.ietf-hokey-emsk-hierarchy] Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-00 (work in progress), January 2007. [I-D.ohba-hokey-3party-keydist-ps] Ohba, Y., "Problem Statement and Requirements on a 3-Party Key Distribution Protocol for Handover Keying", Nakhjiri & Ohba Expires December 24, 2007 [Page 24] Internet-Draft Hokey hierarchy June 2007 draft-ohba-hokey-3party-keydist-ps-01 (work in progress), March 2007. [I-D.nakhjiri-hokey-hierarchy] Nakhjiri, M., "Keying and signaling for wireless access and handover using EAP (EAP-HR)", draft-nakhjiri-hokey-hierarchy-04 (work in progress), April 2007. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. 9.2. Informative references [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-09 (work in progress), February 2007. Appendix A. Appendix A: Roaming hieararchy based on HRK The HOKEY server can use HRK to generate separate domain specific handover root keys (DSHRK) for each domain, e.g. a home HRK (HHRK) for home domain and a visited HRK (VHRK) for each visited domain. HHRK | HHRK_name_Key=HO_PRF(HRK, Peer_ID | home_domain_ID | Key_length) VHRK | VHRK_name_Key=HO_PRF(HRK, Peer_ID | visited_domain_ID | Key_length) Since HHRK and VHRK are no longer derived from the EMSK, the PRF used for generating these keys may or may need to comply with the requirements in [I-D.ietf-hokey-emsk-hierarchy] and thus we have used the notion of HO_PRF to indicate this flexibility. HHRK_name=First (128, HMAC_SHA256(HHRK_name_Key, "domain handover root key derivation"| peer_ID)) VHRK_name=First (128, HMAC_SHA256(VHRK_name_Key, "domain handover root key derivation"| peer_ID)) Nakhjiri & Ohba Expires December 24, 2007 [Page 25] Internet-Draft Hokey hierarchy June 2007 Home_domain_ID or the Visited_domain_ID are the identifier for the home or visited domain as known to both peer and the HOKEY server generating HHRK or VHRK. When roaming from one domain to the next, the peer needs to request for the domain specific handover root key (DSHRK) to be generated from the HRK and exchange its own identity as well as the domain identity with the server. It should be mentioned that HHRK and VHRKs can be generated directly from EMSK as usage and specific root keys (USDSRK). In that case it would be the EAP server that has to generate such domain specific handover root keys (DSHRK), which means each DSHRK request needs to be made directly to the EAP server, along with domain_label for the domain. The preferred method is to generate DSHRK from HRK instead. Domain specific HRKs (DSHRK) are delivered to the domain HOKEY servers through secure transport and cached at domain HOKEY servers, at a so called DSHRK key holder (DSHRK-KH). Proper care needs to be taken to assure that DSHRK is bound to the identity of the HOKEY server caching the DSHRK. This is described later on. In case the peer is at home domain, HHRK is delivered to the home HOKEY server. Providing re-authentication and handover keying service within each domain is upon the HOKEY server within that domain. This means integrity and cipher keys (IK and CK) for re-authentication and handover keying signaling can be domain specific (DSIK and CSIK). Also the mobility domain master session keys (MDMSK) passed to the authenticators within the administrative domain are also domain specific. This means DSHRK is used for calculation of these keys. It should be obvious that DSHRK, DSIK and DSCK are only accessible to the peer and domain HOKEY server, but not to the authenticator within the domain. The following describes derivation of IK and CK for home domain (HUIK and CUIK) from HHRK: HUIK | HUIK_name_key=HO-PRF (HHRK, "domain integrity Key" | peer_ID | Home_domain_ID | Key_length ) HUIK_name=First(128, HMAC_SHA256(HUIK_name_key "domain integrity Key"| peer_ID) HUCK | HUCK_name_key=HO-PRF (HHRK, "domain cipher Key" | peer_ID | Home_domain_ID | Key_length ) HUCK_name=First(128, HMAC_SHA256(HUCK_name_key, "domain cipher Key"| peer_ID) Nakhjiri & Ohba Expires December 24, 2007 [Page 26] Internet-Draft Hokey hierarchy June 2007 Authors' Addresses Madjid Nakhjiri (editor) Huawei USA Email: mnakhjiri@huawei.com Yoshihiro Ohba (editor) Toshiba Email: yohba@tari.toshiba.com Nakhjiri & Ohba Expires December 24, 2007 [Page 27] Internet-Draft Hokey hierarchy June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nakhjiri & Ohba Expires December 24, 2007 [Page 28]