Network Working Group L. Dondeti Internet-Draft V. Narayanan Intended status: Standards Track QUALCOMM, Inc. Expires: April 19, 2007 October 16, 2006 EAP Keying and Re-authentication in Visited Domains draft-dondeti-eap-vkh-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 April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies a visited domain key hierarchy derived from the extended master session key (EMSK) from EAP to facilitate visited domain key management for various purposes including fast handovers and visited domain services. The visited domain key hierarchy avoids the latency associated with communicating with the home domain as in case of a full EAP method run or even in a single round trip as with the EAP efficient reauthentication scheme, and that is especially desirable when the protocol is in the critical path of a handover. Dondeti & Narayanan Expires April 19, 2007 [Page 1] Internet-Draft EAP VKH October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Visited Domain Keying . . . . . . . . . . . . . . 4 4. EMSK Hierarchy for Visited Domains . . . . . . . . . . . . . . 4 4.1. VRK Derivation and Properties . . . . . . . . . . . . . . 5 4.2. VMSK Derivation and Properties . . . . . . . . . . . . . . 6 4.2.1. VMSK Establishment and Delivery . . . . . . . . . . . 8 5. Intra-Visited Domain Re-authentication Keying Hierarchy . . . 11 5.1. V-rRK Derivation and Properties . . . . . . . . . . . . . 11 5.2. V-rRK Usage and Derived Keys . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Dondeti & Narayanan Expires April 19, 2007 [Page 2] Internet-Draft EAP VKH October 2006 1. Introduction The extensible authentication protocol (EAP) specified in [1] requires the peer to authenticate to an EAP server located typically in the peer's home domain. The authentication process may involve several roundtrips in case of a full EAP authentication, or a single roundtrip in case of the EAP efficient reauthentication (EAP-ER) [2] protocol. When the EAP peer is roaming in a visited domain, even a single roundtrip to the home domain is often unacceptable, especially when the EAP authentication needs to take place in the critical path of a handover. To avoid the need to revisit the home network each time an EAP peer moves to a new EAP authenticator within a visited domain, a visited domain keying hierarchy (V-KH) for re-authentication is specified in this document. Corresponding to this hierarchy, the EAP-ER protocol operation to support fast handovers with the availability of the V-KH is also specified. 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 RFC 2119 [3]. This document uses terminology defined in [1]. In addition, this document uses the following terms: Visited Domain A domain that an EAP peer may attach to while roaming. This domain is different from the domain that hosts the EAP server with which the peer shares credentials. Visited Root Key (VRK) This is the Usage Specific Root Key derived from the EMSK for visited domain keying purposes. Specific visited domain session keys for various visited domains are derived from the VRK. Visited Domain Master Session Key (VMSK) The VMSK is derived from the VRK for a given visited domain to serve as the master key for services within that visited domain. This document only defines EAP efficient re-authentication service within the visited domain. Dondeti & Narayanan Expires April 19, 2007 [Page 3] Internet-Draft EAP VKH October 2006 3. Overview of Visited Domain Keying The idea behind visited domain keying is that an EAP peer, after completion of at least one full EAP exchange with its home domain EAP server, can re-authenticate within the visited network by running an EAP-ER exchange with a visited domain EAP-ER server. This process does require the visited domain to host an EAP-ER server that supports the V-KH and EAP-ER - however, it does not require that the visited domain server support any EAP methods. Given that EAP-ER is method agnostic, it works well with the visited domain support concept. The EAP peer still only has to support methods that its home domain EAP server supports. As long as the peer supports the V-KH and EAP-ER, it will be able to perform EAP-ER within a visited domain that supports EAP-ER. Either during a full EAP exchange or during an EAP-ER bootstrap exchange as specified in [2], a visited domain EAP-ER server may request keying material for the peer from the home domain EAP server performing the EAP authentication with the peer. The visited domain key request message is sent in a AAA attribute to the AAA server, which is then relayed to the EAP layer. The home EAP server will derive a VMSK (Visited domain Master Session Key) specific to the requesting domain and provide it in a AAA attribute back to the requesting visited domain EAP-ER server. In order to preserve the stateless nature of the visited domain servers, it would be feasible to provide this key, along with other parameters such as lifetimes and authorization information to the peer in the form of a ticket that can later be presented to the visited domain EAP-ER server. This mechanism will be specified in a later version of this document. Along with the VMSK, the server MUST send a lifetime and may send authorization and other policy information pertinent to the peer. The standardization of any AAA attributes needed to accomplish this exchange is outside the scope of this document itself and will be done separately. 4. EMSK Hierarchy for Visited Domains Dondeti & Narayanan Expires April 19, 2007 [Page 4] Internet-Draft EAP VKH October 2006 EMSK | +------------+-------------+ | | | rRK VRK ... USRKn | +---------+---------+ | | VMSK1 ... VMSKn * VMSKx is the root key for the key hierarchy of a given visited domain X Figure 1: VMSK derivation from the EMSK The above figure shows the EMSK keying hierarchy as defined in [4]. The re-authentication Root Key (rRK) shown is defined in [2] for the purpose of EAP re-authentication with the home domain. In many cases, this may be the same server with which the peer executed a full EAP exchange. This document defines another USRK called Visited domain Root Key (VRK). The VRK is then used to derive a specific VMSK, which is given to an EAP-ER server in a particular visited domain. 4.1. VRK Derivation and Properties The VRK is derived from the EMSK using the prf+ operation defined in RFC4306 [5] as follows. VRK = prf+ (K, S), where, K = EMSK and S = VRK Label The VRK Label is an IANA-assigned ASCII string "EAP Visited domain Root Key" assigned from the USRK Key Label name space in accordance with [4]. This document specifies IANA registration for the VRK label above. The PRF used may be specified in the EAP Re-authentication message, as described in [2]. When that is not available, the default PRF to be used is HMAC-SHA-256. Along with the VRK, a unique VRK name is derived to identify the VRK. The VRK name is derived as follows. Dondeti & Narayanan Expires April 19, 2007 [Page 5] Internet-Draft EAP VKH October 2006 VRK_name = NDF-64( EAP Session-ID, VRK Label ) where NDF-64 is the first 64 bits from the output of the name derivation function (NDF). The NDF is a hash function, currently specified as SHA-256. The EAP Session-ID MUST be of the EAP session corresponding to the EMSK used in the derivation of the VRK. The VRK has the following properties. o The length of the VRK MUST at least be 64 bytes. o The VRK is to be used only as a root key for the derivation of specific VMSKs corresponding to different visited domains and MUST NOT be used to directly protect any data. o The VRK is only used for derivation of VMSKs as specified in this document. o The VRK must remain on the peer and the server and MUST NOT be transported to any other entity. o The VRK is cryptographically separate from any other USRK derived from the EMSK. o The lifetime of the VRK is the same as that of the EMSK. The VRK is expired when the EMSK expires and removed from use at that time. o If a new EMSK is derived due to a full EAP exchange, a new VRK from that EMSK must be derived for the purpose of subsequent VMSK derivations. The new VRK MUST replace an existing VRK derived from a previous EMSK. 4.2. VMSK Derivation and Properties The VMSK is derived from the VRK using the prf+ operation defined in RFC4306 [5] as follows. VMSK = prf+ (K, S), where, K = VRK and S = Server ID || Domain Name The server ID is the identity of the server requesting the VMSK. This should be included as a AAA attribute along with the AAA message carrying the EAP message requesting the VMSK. The server ID may typically be the FQDN of the server. In the event that state would Dondeti & Narayanan Expires April 19, 2007 [Page 6] Internet-Draft EAP VKH October 2006 be replicated on more than one visited domain server, the server ID could be a wildcard. The domain name is the realm of the visited domain requesting the VMSK. When the server ID is an FQDN, the realm would already be part of that and having a separate domain name is redundant. However, when other types of server IDs are allowed, it is important to have the domain name specified separately. For sake of consistency, the domain name is always specified as above, irrespective of the nature of the server ID. The PRF used may be specified in the EAP Re-authentication message, as described in [2]. When that is not available, the default PRF to be used is HMAC-SHA-256. Along with the VMSK, a unique VMSK name is derived to identify the VMSK. The VMSK name is derived as follows. VMSK_name = NDF-64( EAP Session-ID, Server ID || Domain Name ) where NDF-64 is the first 64 bits from the output of the name derivation function (NDF). The NDF is a hash function, currently specified as SHA-256. The EAP Session-ID is the session-id of the full EAP exchange used to derive the corresponding EMSK used as the parent key. The VMSK has the following properties. o The length of the VMSK MUST at least be 64 bytes. o The VMSK is to be used only as a root key for the derivation of specific keys for visited domain services such as re- authentication within the visited domain and MUST NOT be used to directly protect any data. o The VMSK is used for derivation of the V-rRKs as specified in this document. The VMSK may be used for derivation of other visited domain keys - it is outside the scope of this document to specify such keys. o The VMSK MUST NOT be transported to any entity other than the one requesting it. The VMSK scope must be clearly defined. The VMSK MUST NOT be used for any purpose other than what is authorized by the server deriving and distributing the key. o A given VMSK is cryptographically separate from any other VMSK derived from the VRK. Dondeti & Narayanan Expires April 19, 2007 [Page 7] Internet-Draft EAP VKH October 2006 o The lifetime of the VMSK MUST NOT be greater than the lifetime of the VRK. The associated lifetime of the VMSK must be transported along with the VMSK to the entity requesting it. By default, the lifetime of the VMSK is the same as that of the VRK and the EMSK. The VMSK MUST be removed from use when the lifetime expires. o The VMSK and the keys derived from it have limited applicability and have a specific lifetime. These keys are used to derive other keys to provide proof of having participated in an EAP conversation or having received the keys from an entity that participated in the EAP conversation. No other uses are allowed as per this specification. Such key scoping is important to disallow misuse of the keys which might result in compromise of security sessions established using those keys. o If a new VRK is derived due to a full EAP exchange, a new VMSK from that EMSK SHOULD be derived to replace a VMSK that is in use from the previous EAP exchange. 4.2.1. VMSK Establishment and Delivery A given VMSK is derived by the home EAP server upon request from a visited domain. This section specifies the establishment and transport of the VMSK and associated parameters. A visited domain AAA server may request a VMSK in the EAP Response Identity sent by the peer. Alternately, it may request for a VMSK in the EAP Re-auth Initiate message sent by the peer, in accordance with [2]. If there is an EAP Re-auth Initiate message from the peer, a visited domain server that supports VMSKs MUST include a request for VMSK in the EAP Re-auth Initiate message, even if it had already included the request in the EAP Response Identity message corresponding to that peer earlier. This is so that the home server can send the corresponding parameters to the peer in the EAP Re-auth Finish message. Further, note that the visited domain entities will typically be unaware if a VMSK has already been obtained for that particular peer earlier, as the peer ID may not be available to the visited domain entities during the EAP exchange. The home EAP server, upon receiving a request for VMSK, based on authorization information for the peer, SHOULD provide a VMSK to the requesting server. The VMSK may be provided along with the EAP Success message or with the EAP Re-auth Finish message. Along with the VMSK, the server MAY also provide relevant authorization policy. When provided with the EAP Re-authentication Finish, the server MUST also provide the relevant server IDs and visited domain information for the peer. Specifically, the server MUST provide the visited domain name to the peer. It MAY provide one or more server IDs to Dondeti & Narayanan Expires April 19, 2007 [Page 8] Internet-Draft EAP VKH October 2006 the peer - for e.g., its own server ID and the requesting visited domain server ID. When the VMSK is provided to the requesting entity along with the EAP Success message, it is assumed that the peer obtains the information relevant for computing the VMSK via the lower layer. Such mechanisms are out of scope of this document. Based on the information in the EAP Re-auth Finish message, the peer would be able to derive the VMSK and associated keys for re- authentication in the visited domain. Upon handoff to an EAP authenticator within the same domain, the peer SHOULD use the V-rIK to send an EAP Re-authentication Initiate message to the visited domain EAP-ER server in accordance with [2]. 4.2.1.1. Peer Considerations The EAP peer, while attached to an authenticator in the visited domain, may or may not be aware of the domain it is attached to. If the peer is aware, for instance, via lower layer advertisements, of the domain it is attached to, it may be aware that the visited domain supports VMSKs or not. Further, it may also receive the visited domain EAP-ER server ID via the lower layer or it may be aware via configuration that the server ID can be a wildcard. In such cases, the peer may never need to send an EAP Re-auth Initiate message with the Bootstrap flag set for the purpose of receiving VMSK related parameters. It may still send an EAP Re-auth Initiate message with the Bootstrap flag to retrieve some parameters for the home domain, in accordance with [2]. A peer that supports EAP-ER, in accordance with [2], MAY send an EAP Re-auth Initiate message with the Bootstrap flag set, immediately following a full EAP exchange. In response to this, if it receives an EAP Re-auth Finish message from the server, it MUST process it in accordance with [2]. In addition, it MUST check if the message contained a visited domain server ID and a visited domain name. If it does, the peer MUST compute the VMSK using that information. If the message contained a visited domain name, but no visited server ID, the peer MUST use a wildcard entry as the server ID. If the message contained a temporary peer ID to use within the visited domain, the peer MUST use that in a subsequent EAP re-auth initiate message sent within that visited domain. If not, the peer SHOULD use the V-rIKName as its ID in the visited domain. The V-rIKName appended with the visited domain name will provide the NAI to use as the peer ID in the EAP Re-auth Initiate message. Once a VMSK and subsequent keys for visited domain EAP re- authentication are available, the peer MUST process EAP Re- authentication messages in accordance with [2], even though it may be executed with the visited domain. Dondeti & Narayanan Expires April 19, 2007 [Page 9] Internet-Draft EAP VKH October 2006 4.2.1.2. Authenticator Considerations An authenticator that is compliant with [2] may advertise the presence of a visited domain EAP-ER server in the lower layer to the peer. The authenticator has no special considerations for VMSK support and is transparent to whether the EAP-ER exchange occurs with the visited domain or the home domain for a given peer. 4.2.1.3. Visited Domain EAP-ER Server Considerations The visited domain server MAY request a VMSK in an EAP Response Identity message sent by a peer through an authenticator in the visited domain. Alternately, it MAY request a VMSK in the EAP Re- auth Initiate message from the peer. If the request for VMSK was sent in the EAP Response Identity message, the server MUST retrieve the VMSK from the AAA message carrying the EAP Success message. If the result is an EAP failure, no state for that peer must be established in the visited domain. If the request for VMSK was sent in the EAP Re-auth Initiate message, the visited domain server MUST retrieve the VMSK in the AAA message carrying the EAP Re-auth Finish message. If the visited EAP-ER server obtains a VMSK, it MUST derive a V-rRK and a V-rIK from it. It may then serve as the EAP-ER server for subsequent EAP Re-authentication messages from the peer. The AAA attributes needed for the VMSK request and delivery are not defined in this document. These will be specified in a separate document. 4.2.1.4. Home EAP Server Considerations Upon receiving a request for a VMSK from the visited EAP-ER server, the home EAP server SHOULD check if the message contains the server ID and the domain name of the visited server. If so, the home EAP server SHOULD derive a VMSK and provide it to the requesting visited EAP-ER server. If the request was sent along with an EAP Response Identity message, the key MUST be provided in the EAP Success message. If the request was sent along with an EAP Re-auth Initiate message, the key MUST be provided in the EAP Re-auth Finish message. After transporting the VMSK, the home EAP server MUST delete the VMSK immediately. The VMSK MUST be securely transported from the home EAP server to the requesting visited EAP-ER server. If the visited server ID is unavailable or if the visited EAP-ER server is not specifically indicated, the server ID in the VMSK Label could be considered a wildcard. In this case, the message with the VMSK will be routed via normal AAA routing and it is assumed that there is Dondeti & Narayanan Expires April 19, 2007 [Page 10] Internet-Draft EAP VKH October 2006 backend duplication of keying material in the visited domain. The visited domain name and the appropriate server ID MUST be provided to the peer in an EAP Re-auth Finish message, if the server received an EAP Re-auth Initiate message that triggered the derivation of a VMSK. 5. Intra-Visited Domain Re-authentication Keying Hierarchy VMSK | V-rRK | +----------+---------------+ | | | V-rIK V-rMSK1 ... V-rMSKn Figure 2: Visited Domain Key Hierarchy The above figure shows a V-KH for re-authentication purposes. A Visited domain Master Session Key (VMSK) is at the top of the hierarchy. A visited domain re-authentication root key (V-rRK) is derived from the VMSK. The V-rRK hierarchy is identical to the rRK hierarchy for EAP-ER with the home domain; the exception here is that the scope of these keys is the visited domain that owns the VMSK. Other keys may be derived from the VMSK - however, such keys are out of scope of this document. 5.1. V-rRK Derivation and Properties This document defines the derivation of a Visited domain re- authentication Root Key (V-rRK) from the VMSK. This key is identical in purpose to the rRK defined in [2]. The V-rRK is derived from the VMSK using the prf+ operation defined in RFC4306 [5] as follows. rRK = prf+ (K, S), where, K = VMSK and S = rRK Label The rRK Label is an IANA-assigned ASCII string "EAP Re-authentication Root Key" as specified in [2]. The PRF used is specified in the EAP Re-authentication Response. The Dondeti & Narayanan Expires April 19, 2007 [Page 11] Internet-Draft EAP VKH October 2006 default PRF used is HMAC-SHA-256. The V-rRK has the following properties. o The V-rRK MUST be 64 octets in length. o The V-rRK is to be used only as a root key for re-authentication within the visited domain and never used to directly protect any data. o The V-rRK is only used for derivation of V-rIK and V-rMSK as specified in this document. o The rRK must remain on the peer and the server deriving it and MUST NOT be transported to any other entity. o The V-rRK is cryptographically separate from any other key derived from the VMSK. o The lifetime of the V-rRK is the same as that of the VMSK. The V-rRK is expired when the VMSK expires and removed from use at that time. o If a new VMSK is available for the visited domain, a new V-rRK from that VMSK must be derived for the purpose of subsequent EAP-ER exchanges in the visited domain. The new V-rRK MUST replace an existing V-rRK derived from a previous VMSK. 5.2. V-rRK Usage and Derived Keys The V-rRK is used within the visited domain in exactly the same manner as the rRK defined in [2]. The scope of all the derived keys, however, is limited to the visited domain to which the server belongs. 6. Security Considerations All the security considerations stated in [2] are also applicable for this document. In addition, scope of the VMSK MUST be restricted to the visited domain to which the VMSK is provided. Further, when a non-wildcard visited domain server ID is used to compute the VMSK the scope of the VMSK MUST be limited to the particular visited EAP-ER server to which the key is provided. The VMSK MUST remain on the peer and the visited domain EAP-ER server and MUST NOT be transported to any other entity, including other visited domain EAP-ER servers. The keys defined by this document must adhere to the properties and Dondeti & Narayanan Expires April 19, 2007 [Page 12] Internet-Draft EAP VKH October 2006 requirements stated here: A VMSK MUST NOT be used after expiry of its lifetime. When a new VMSK is available, the old VMSK MUST be replaced by the new one and the old key MUST NOT be used to compute any subsequent child keys. The VMSK MUST be securely transported from the EAP server to the visited domain entity requesting it. The visited domain entity MUST be authorized to receive such a key and perform re-authentication for the EAP peer. Authorization may be based on policies and such a process itself is outside the scope of this document. 7. IANA Considerations TBD 8. Acknowledgments We would like to thank, in alphabetical order, Bernard Aboba, Parag Agashe, Paul Bender, Sam Hartman, Russ Housley, Joe Salowey, George Tsirtsis, Fatih Ulupinar, Michaela Vanderveen, and Jun Wang for several useful discussions and reviews of the contents of this document. 9. References 9.1. Normative References [1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [2] Narayanan, V. and L. Dondeti, "EAP Extensions for Efficient Re- authentication", draft-vidya-eap-er-00 (work in progress), June 2006. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in progress), June 2006. [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. Dondeti & Narayanan Expires April 19, 2007 [Page 13] Internet-Draft EAP VKH October 2006 [6] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-14 (work in progress), June 2006. 9.2. Informative References [7] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-04 (work in progress), October 2006. [8] Narayanan, V. and L. Dondeti, "Gap analysis on the EAP keying hierarchy", draft-vidya-eap-keying-gap-analysis-00 (work in progress), April 2006. [9] Dondeti, L. and V. Narayanan, "EAP Extensions Problem Statement", draft-dondeti-eapext-ps-00 (work in progress), June 2006. Authors' Addresses Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Dondeti & Narayanan Expires April 19, 2007 [Page 14] Internet-Draft EAP VKH October 2006 Full 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. 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. 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). Dondeti & Narayanan Expires April 19, 2007 [Page 15]