Network Working Group Y. Ohba (Editor) Internet-Draft Toshiba Expires: September 4, 2007 A. Dutta Telcordia S. Sreemanthula Nokia A. Yegin Samsung M. Mani Avaya March 3, 2007 EAP Pre-authentication Problem Statement draft-ohba-preauth-ps-01 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 September 4, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract EAP pre-authentication is defined as the utilization of EAP to pre- Ohba (Editor), et al. Expires September 4, 2007 [Page 1] Internet-Draft EAP Pre-authentication Problem Statement March 2007 establish EAP keying material on an authenticator prior to arrival of the peer at the access network managed by that authenticator. This draft discusses EAP pre-authentication problems in details. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Direct Pre-authentication . . . . . . . . . . . . . . . . 7 3.2. Indirect Pre-authentication . . . . . . . . . . . . . . . 7 4. Architectural Considerations . . . . . . . . . . . . . . . . . 9 4.1. Authenticator Discovery . . . . . . . . . . . . . . . . . 9 4.2. Context Binding . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Performance Requirements . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Ohba (Editor), et al. Expires September 4, 2007 [Page 2] Internet-Draft EAP Pre-authentication Problem Statement March 2007 1. Introduction When a mobile during an active communication session moves from one access network to another access network and changes its point of attachment it is subjected to disruption in the continuity of service because of the associated handover operation. During the handover process, when the mobile changes its point-of-attachment in the network, it may change its subnet or administrative domain it is connected to. We provide in Appendix A some performance requirement that are needed to support an interactive real-time communication such as VoIP and thus can serve as the guidelines for handover optimization. Handover often requires authorization for acquisition or modification of resources assigned to a mobile and the authorization needs interaction with a central authority in a domain. In many cases an authorization procedure during a handover procedure follows an authentication procedure that also requires interaction with a central authority in a domain. The delay introduced due to such an authentication and authorization procedure adds to the handover latency and consequently affects the ongoing multimedia sessions. The authentication and authorization procedure may include EAP authentication [RFC3748] where an AAA server may be involved in EAP messaging during the handover. Depending upon the type of architecture, in some cases the AAA signals traverse all the way to the AAA server in the home domain of the mobile as well before the network service is granted to the mobile in the new network. Real-time communication and interactive traffic such as VoIP is very sensitive to the delay. Thus it is desirable that interactions between the mobile and AAA servers must be avoided or be reduced during the handover. This draft discusses EAP pre-authentication problems in details where EAP pre-authentication is defined as the utilization of EAP to pre- establish EAP keying material on an authenticator prior to arrival of the peer at the access network managed by that authenticator. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. Ohba (Editor), et al. Expires September 4, 2007 [Page 3] Internet-Draft EAP Pre-authentication Problem Statement March 2007 2. Problem Statement Basic mechanism of handover is a three-step procedure involving i) discovery of potential points of attachment and their authenticators, ii) network selection procedure to determine the appropriate candidate network point of attachment and iii) handover or setting up of L2 and L3 connectivity to the target network point of attachment. Currently, security mechanisms for authentication and authorization is performed as part of the third step directly with the target network. For example, in basic IEEE 802.11b based wireless networks, the security mechanism involves performing a new IEEE 802.1X message exchange with the authenticator in the target AP to initiate an EAP exchange to the authentication server [WPA]. Following a successful authentication, a four-way handshake with the wireless station derives a new set of the session keys for use in data communications. Unless PMK (Pairwise Master Key) is not cached in the target AP, this mechanism is same as the initial setup to the AP with no particular optimizations for the handover scenario. The handover latency introduced by this security mechanism has proven to be larger than what is acceptable for some handover scenarios. Hence, improvement in the handover latency performance due to security procedures is a necessary objective for such scenarios. For example, if a mobile only requires 250 ms for "fast reconnect" then if it is moving at 60 mph (87 feet/second), then the mobile will have moved roughly 22 feet during the EAP authentication process. This is larger than the average coverage overlap of a wireless LAN (WLAN). There is relevant work undertaken by various standards organizations. But these efforts are scoped to a specific access technology. IEEE 802.11f has defined context transfer between APs. IEEE 802.11i defines a pre-authentication mechanism for use in 802.11 variant wireless networks. This mechanism allows mobile devices to pre- authenticate using EAP to one or more target authenticators over the wired medium, by way of the current authenticator. Presently, IEEE 802.11r WG has been working to define Fast BSS transition mechanisms involving a definition of key management hierarchy and setup of session keys before the re-association to the target AP. These mechanisms, as indicated before, are defined for IEEE 802.11 technologies and are only applicable within a certain access domain and fall short when it comes to inter-access technology handovers. They also require L2 (e.g., Ethernet) connectivity for transfer of encapsulated signaling to the target AP. Especially, a solution is needed to enable EAP pre-authentication in IEEE 802.11 to work even if the STA and AP are not members of the same VLAN. As various flavors of wireless technologies are increasingly Ohba (Editor), et al. Expires September 4, 2007 [Page 4] Internet-Draft EAP Pre-authentication Problem Statement March 2007 available, there is a growing demand for seamless inter-access technology mobility and handovers. This is particularly beneficial in the presence of high bandwidth wireless technologies (e.g., IEEE 802.11a/b/g) with only hotspot like coverages while the overlay licensed wireless/cellular coverages are expensive and relatively lower bandwidth. There is a strong motivation to allow seamless inter-technology handovers for all kinds of data communications. Hence, the security optimization mechanisms for better handover performance must be looked at from the IP level so as to make it a common method over different access technologies. Solutions for inter-authenticator mobility security optimizations can be largely seen as security context transfer, handover keying or EAP pre-authentication. Security context transfer involves transfer of reusable key context in the new point of attachment. However, the recent AAA key management requirement [I-D.housley-aaa-key-mgmt] does not recommend horizontal context transfer of reusable key context because of domino effect in which a compromise of an authenticator will lead to a compromise of another authenticator. Nakhjiri et al [I-D.nakhjiri-aaa-hokey-ps] discusses handover keying. Handover keying uses an existing EAP-generated key for deriving a key to be used for a target authenticator in order to reduce the handover delay, which eliminates the need for running EAP for each inter- authenticator handover. On the other hand, there are certain cases where an EAP-generated key does not exist or is not usable for handover keying at the time of handover and an EAP run is not avoidable to generate a key for the target authenticator. One case is an inter-domain handover without any trust relationship between domains. Another case is a handover to an existing technology that does not support handover keying. EAP pre-authentication discussed in this document is mainly to deal with an environment where the mobile device and target authenticators are not in the same subnet or of the same link-layer technology. Such use of EAP pre-authentication would enable the mobile device to authenticate and setup keys prior to connecting to the target authenticator. This framework has general applicability to various deployment scenarios in which proactive signaling can take effect. In other words, applicability of EAP pre-authentication is limited to the scenarios where target authenticators can be easily discovered, an accurate prediction of movement can be easily made. Also the effectiveness of EAP pre-authentication may be less significant for particular inter-technology handover scenarios where simultaneous use of multiple technologies is not a major concern or where there is sufficient radio-coverage overlap among different technologies. Ohba (Editor), et al. Expires September 4, 2007 [Page 5] Internet-Draft EAP Pre-authentication Problem Statement March 2007 Note that EAP pre-authentication problem for intra-technology intra- subnet handover could be solved by each link-layer and is thus out of the scope of this document while a general solution developed at IETF can be used for intra-technology and intra-subnet scenarios as well. In EAP pre-authentication, AAA authentication and authorization for a target authenticator is performed while application sessions are in progress via the serving network. The goal of EAP pre-authentication is to avoid AAA signaling for EAP when or soon after the device moves. There are several AAA issues related to EAP pre- authentication. The pre-authentication AAA issues are described in another document [I-D.nakhjiri-preauth-aaa-req]. Figure 1 shows the functional elements that are related to EAP pre- authentication. +------+ +-------------+ +------+ |Mobile|---------| Serving | / \ | Node | |Authenticator|---/ \ +------+ +-------------+ / \ . / \ +----------+ . Move + Internet +---|AAA Server| . \ / +----------+ v +-------------+ \ / | Target |---\ / |Authenticator| \ / +-------------+ +------+ Figure 1: EAP Pre-authentication Functional Elements A mobile node is attached to the serving access network. Before the mobile node performs handover from the serving access network to a target access network, it performs EAP pre-authentication with a target authenticator, an authenticator in the target access network, via the serving access network. The mobile node may perform EAP pre- authentication with one or more target authenticators. It is assumed that each authenticator has an IP address when authenticators are on different IP links. It is assumed that there is at least one target authenticator in each target access network while the serving access network may or may not have a serving authenticator. The serving and target access networks may use different link-layer technologies. Each authenticator has the functionality of EAP authenticator which is either standalone EAP authenticator or pass-through EAP authenticator. When an authenticator acts as a standalone EAP authenticator, it also has the functionality of EAP server. On the other hand, when an authenticator acts as a pass-through EAP authenticator, it communicates with EAP server typically implemented Ohba (Editor), et al. Expires September 4, 2007 [Page 6] Internet-Draft EAP Pre-authentication Problem Statement March 2007 on a AAA server using a AAA protocol such as RADIUS and Diameter. If the target authenticator is of an existing link-layer technology that uses an MSK (Master Session Key) [I-D.ietf-eap-keying] for generating lower-layer ciphering keys, EAP pre-authentication is used for proactively generating the MSK for the target authenticator. 3. Usage Scenarios There are two scenarios on how EAP pre-authentication signaling can happen among a mobile node, a serving authenticator, a target authenticator and a AAA server, depending on how the serving authenticator is involved in the EAP pre-authentication signaling. 3.1. Direct Pre-authentication Direct pre-authentication signaling is shown in Figure 2. Mobile Serving Target AAA Node Authenticator Authenticator Server (MN) (SA) (TA) | | | | | | | | | MN-TA Signaling (L2 or L3) | AAA | |<------------------+------------------->|<----------------->| | | | | | | | | Figure 2: Direct Pre-authentication In this type of pre-authentication, the serving authenticator forwards the EAP pre-authentication traffic as it would any other data traffic or there may be no serving authenticator at all in the serving access network. [I-D.ietf-pana-preauth] is identified as a protocol to realize direct pre-authentication. 3.2. Indirect Pre-authentication Indirect pre-authentication signaling is shown in Figure 3. Ohba (Editor), et al. Expires September 4, 2007 [Page 7] Internet-Draft EAP Pre-authentication Problem Statement March 2007 Mobile Serving Target AAA Node Authenticator Authenticator Server (MN) (SA) (TA) | | | | | | | | | MN-SA Signaling | SA-TA Signaling | AAA | | (L2 or L3) | (L3) | | |<----------------->|<------------------>|<----------------->| | | | | | | | | Figure 3: Indirect Pre-authentication With indirect pre-authentication, the serving authenticator is involved in EAP pre-authentication signaling. Indirect pre- authentication is needed if the MN cannot discover the TA's IP address or if IP communication is not allowed between the target authenticator and unauthorized nodes for security reasons. Indirect pre-authentication signaling is spliced into mobile node to serving authenticator signaling (MN-SA signaling) and serving authenticator to target authenticator signaling (SA-TA signaling). SA-TA signaling is performed over L3. MN-SA signaling is performed over L2 or L3. The role of the serving authenticator in indirect pre-authentication is to forward EAP pre-authentication signaling between the mobile node and the target authenticator and not to act as an EAP authenticator, while it acts as an EAP authenticator for normal authentication signaling. This is illustrated in Figure 4. Mobile Serving Target Node Authenticator Authenticator (MN) (SA) (TA) +-----------+ +-----------+ | |<- - - - - - - - - - - - - - - - - - ->| | | EAP Peer | +-----------------------------+ | EAP Auth- | | | |Pre-authentication Forwarding| | enticator | +-----------+ +-----------+-----+-----------+ +-----------+ | MN-SA | | MN-SA | | SA-TA | | SA-TA | | Signaling |<-->| Signaling | | Signaling |<-->| Signaling | | Layer | | Layer | | Layer | | Layer | +-----------+ +-----------+ +-----------+ +-----------+ Figure 4: Indirect Pre-authentication Layering Model Ohba (Editor), et al. Expires September 4, 2007 [Page 8] Internet-Draft EAP Pre-authentication Problem Statement March 2007 4. Architectural Considerations There are two architectural issues relating to pre-authentication, i.e., authenticator discovery and context binding. 4.1. Authenticator Discovery In general, pre-authentication requires an address of a target authenticator to be discovered either by a mobile node or by a serving authenticator prior to handover. An authenticator discovery protocol is typically defined as a separated protocol from a pre- authentication protocol as described below. When a target authenticator uses link-layer EAP transport for both normal authentication and pre-authentication, a mechanism for target authenticator discovery is typically defined in each link-layer technology. For other cases, a mechanism for discovering an IP address of a target authenticator is needed. For example, IEEE 802.21 Information Service (IS) [802.21] provides a link-layer independent mechanism for obtaining neighboring network information by defining a set of Information Elements (IEs), where one of the IEs is defined to contain an IP address of a point of attachment. IEEE 802.21 IS queries for such an IE may be used as a method for discovering an IP address of a target authenticator. 4.2. Context Binding When a target authenticator uses different EAP transport protocols for normal authentication and pre-authentication, a mechanisms is needed to bind link-layer independent context carried over pre- authentication signaling to the link-layer specific context of the link to be established between the mobile node and the target authenticator. The link-layer independent context includes the identities of the peer and authenticator as well as the MSK. The link-layer specific context includes link-layer addresses of the mobile node and the target authenticator. There are two possible approaches to address the context binding issue. The first approach is based on communicating the lower-layer context as opaque data via pre-authentication signaling and perform the link-layer specific secure association procedure after handover. The second approach is based on use of normal EAP authentication after handover with using the same link-layer independent context for both pre-authentication and normal authentication and then perform the link-layer specific secure association procedure. Ohba (Editor), et al. Expires September 4, 2007 [Page 9] Internet-Draft EAP Pre-authentication Problem Statement March 2007 5. Security Considerations Since pre-authentication described in this document needs to work across multiple authenticators, any solution for this problem needs considerations on the following security threats. First, a possible resource consumption denial of service attack where an attacker that is not on the same IP link as the mobile node or the target authenticator may send unprotected pre-authentication messages to the mobile node or the target authenticator to let the legitimate mobile node and target authenticator spend their computational and bandwidth resources. Second, consideration for the Channel Binding problem described in [I-D.ietf-eap-keying] is needed as lack of Channel Binding may enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via a AAA or lower layer protocol) [RFC3748]. It should be noted that it would be easier to launch such an impersonation attack for pre- authentication than normal authentication because an attacker does not need to be physically on the same link as the legitimate peer to send a pre-authentication trigger to the peer. A simple solution would be to let the peer always initiate EAP pre-authentication and not allow EAP pre-authentication initiation from authenticator side. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgments The authors would like to thank Bernard Aboba, Jari Arkko and Madjid Nakhjiri for their valuable input. 8. References 8.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. Ohba (Editor), et al. Expires September 4, 2007 [Page 10] Internet-Draft EAP Pre-authentication Problem Statement March 2007 [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.ietf-pana-preauth] Ohba, Y., "Pre-authentication Support for PANA", draft-ietf-pana-preauth-01 (work in progress), March 2006. [I-D.nakhjiri-preauth-aaa-req] Nakhjiri, M. and Y. Ohba, "Pre-Authentication AAA requirements", draft-nakhjiri-preauth-aaa-req-00 (work in progress), September 2006. 8.2. Informative References [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.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. [802.21] IEEE, "Draft Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", LAN MAN Standards Committee of the IEEE Computer Society 2007. [ITU] ITU-T, "General Characteristics of International Telephone Connections and International Telephone Circuits: One-Way Transmission Time", ITU-T Recommendation G.114 1998. [ETSI] ETSI, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3: End-to-end Quality of Service in TIPHON systems; Part 1: General aspects of Quality of Service.", ETSI TR 101 329-6 V2.1.1. [WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi- Fi WPA v3.1, 2004. Appendix A. Performance Requirements In order to provide the desirable quality of service for interactive VoIP and streaming traffic during handoff, one needs to limit the value of end-to-end delay, jitter and packet loss to a certain Ohba (Editor), et al. Expires September 4, 2007 [Page 11] Internet-Draft EAP Pre-authentication Problem Statement March 2007 threshold level. ITU-T and ITU-R standards define the acceptable values for these parameters. For example for one-way delay, ITU-T G.114 [ITU] recommends 150 ms as the upper limit for most of the applications, and 400 ms as generally unacceptable delay. One way delay tolerance for video conferencing is in the range of 200 to 300 ms. Also if an out-of-order packet is received after a certain threshold, it is considered lost. The performance requirement will vary based on the type of application and its characteristics such as delay tolerance and loss tolerance limit. Interactive traffic such as VoIP and streaming traffic will have different tolerance for delay and packet loss. For example, according to ETSI TR 101 [ETSI] a normal voice conversation can tolerate up to 2% packet loss. Similarly there are other factors such as Transmission Rating Factor (R) standardized within ITU-T G.107, End to End delay (one way mouth- to-ear) and call blocking ratio that determine the QoS metrics. An R value of 50 is considered to be poor and a value of 90 can be considered as the best that provides most user satisfaction. As an example, a class B QoS which is equivalent to cellular telephony has a R factor that is greater than 70, E2E delay of less than 150 ms and call blocking ratio which is less than or equal to 0.15. Class A QoS that is the highest and is equivalent to fixed phone quality has an R value that is more than 80 and an end-to-end delay that is less than 100 ms. Similarly, 3GPP TS23.107 defines 4 application classes: conversational, streaming, interactive and background each with different set of end-to-end delay and QoS requirement. The streaming class has the tolerable packet (SDU) error rates ranging from 0.1 to 0.00001 and the transfer delay of less than 300ms. In short, the delay and packet loss tolerance value will depend upon the type of application and different standard bodies and vendors provide different specification for each type of application and thus any optimized handoff mechanism will need to take these values into consideration. It is desirable to support a heterogeneous handover that is agnostic to link-layer technologies in an optimized and secure fashion without incurring unreasonable complexity while providing seamless handover experience to the user. As a mobile goes through a handover process, it is subjected to handover delay because of the rebinding of properties at several layers of the protocol stack, such as layer 2, layer 3 and application layer. There are several common properties that contribute to the re-establishment or modification of these layers during handover. These properties can mostly be attributed to things such as access characteristics (e.g., bandwidth, channel characteristics, channel scan, access point association), access mechanism (e.g., CDMA, CSMA/CA, TDMA), configuration of layer 3 parameters such as IP address acquisition, re-authentication, re- authorization, rebinding of security association at all layers, binding update etc. Although each of the components during the Ohba (Editor), et al. Expires September 4, 2007 [Page 12] Internet-Draft EAP Pre-authentication Problem Statement March 2007 handover process that contributes to the handover delay needs to be optimized, we focus our discussion on optimizing the delay due to authentication and authorization. Authors' Addresses Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5365 Email: yohba@tari.toshiba.com Ashutosh Dutta Telcordia 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 3130 Email: adutta@research.telcordia.com Srivinas Sreemanthula Nokia Research Center 6000 Connection Dr. Irving, TX 75028 USA Email: srinivas.sreemanthula@nokia.com Alper E. Yegin Samsung Advanced Institute of Technology Istanbul, Turkey Phone: +90 538 719 0181 Email: alper01.yegin@partner.samsung.com Ohba (Editor), et al. Expires September 4, 2007 [Page 13] Internet-Draft EAP Pre-authentication Problem Statement March 2007 Mahalingam Mani Avaya Email: mmani@avaya.com Ohba (Editor), et al. Expires September 4, 2007 [Page 14] Internet-Draft EAP Pre-authentication Problem Statement March 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). Ohba (Editor), et al. Expires September 4, 2007 [Page 15]