Network Working Group S. Zrelli Internet-Draft Y. Shinoda Expires: January 25, 2008 JAIST July 24, 2007 EAP Fast Re-Authentication Protocol (EAP-FRAP) draft-zrelli-eap-frap-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 January 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Zrelli & Shinoda Expires January 25, 2008 [Page 1] Internet-Draft XTGSP July 2007 Abstract This document specifies an extension to the EAP protocol that allows an EAP peer to perform fast re-authentication with an EAP server with which it has previously performed a full EAP authentication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. EAP-FRAP message format . . . . . . . . . . . . . . . . . . . 8 5. Bootstrapping of EAP-FRAP . . . . . . . . . . . . . . . . . . 10 6. Creation of an EAP-FRAP encapsulating an AS-REQ message . . . 11 7. Receipt of an EAP-FRAP message encapsulating an AS-REQ message . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Creation of an EAP-FRAP encapsulating a TGS-REQ message . . . 14 9. Receipt of an EAP-FRAP message encapsulating a TGS-REQ message . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Creation of an EAP-FRAP encapsulating an AP-REQ message . . . 16 11. Receipt of an EAP-FRAP message encapsulating a AP-REQ message . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Derivation of Kerberos principal . . . . . . . . . . . . . . . 18 13. Derivation of MSK after termination of EAP-FRAP . . . . . . . 19 14. Inter AAA domain hand-overs . . . . . . . . . . . . . . . . . 20 15. Inter Kerberos realm hand-overs . . . . . . . . . . . . . . . 21 16. Security considerations . . . . . . . . . . . . . . . . . . . 22 17. Normative References . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Zrelli & Shinoda Expires January 25, 2008 [Page 2] Internet-Draft XTGSP July 2007 1. Introduction Network access control with EAP [RFC3748] generally involves an EAP peer, which is the entity requesting the network access service. An EAP authenticator located at the edge of the access network (at the access point) and a back-end EAP server. The EAP authenticator acts as a pass-through. It relays EAP exchange between the EAP peer and the EAP server. Upon successful authentication the EAP server issues a key called Master Session Key (MSK) and deliver it to the EAP authenticator. On the other side, the EAP peer generates the MSK. The MSK is then used to establish a security association between the EAP peer and the EAP authenticator. When the EAP peer performs a hand-over, a full EAP authentication with the back-end EAP server must be performed. In cases where the EAP method requires several round-trips, or when the EAP peer belongs to a remote AAA domain. The EAP authentication may introduce delays that can directly impact the performance of real time applications. More details on this issue are developed in [draft-ietf-hokey-reauth-ps-01] This document, specifies an extension to the EAP protocol that enables EAP peers to authenticate only once to the local access network, using any legacy EAP authentication method, then re-use the established security association with the local EAP server to re- authenticate to the local access network in a reduced number of messages. In EAP-FRAP, a Kerberos realm is associated to each access network. The network access service corresponds to a Kerberos service in the Kerberos realm. Clients that support the EAP-FRAP extension, first perform an initial full EAP authentication when they use the first access point of the local access network. When the client performs a hand-over within the same access network, the EAP-FRAP extension can be used to create a temporary Kerberos principal and obtain sufficient Kerberos credentials from the Key Distribution Center (KDC) serving the local access network to authenticate to the local EAP server and gain network access. When the EAP peer roams to a new access network, using the EAP-FRAP extension in the new access network, the EAP peer can obtain a Ticket Granting Ticket (TGT) for the new access network through Kerberos cross-realm authentication proxied by the new EAP server. The current design of the EAP-FRAP requires a minor change on issuance and the processing of the initial EAP-Identity Request message. This change consists of including the AAA realm name of the local access network in the initial EAP-Identity Request message. On Zrelli & Shinoda Expires January 25, 2008 [Page 3] Internet-Draft XTGSP July 2007 the EAP peer side, the AAA realm name is used to determine whether a pre-existing security association (EMSK) between the peer and the access network exists, in which case, EAP-FRAP can be used to perform fast re-authentication. Apart from the bootstrapping that requires these minor changes, the EAP-FRAP extension is intact no more than an EAP method that re-uses the existing security association established through a prior EAP authentication for authenticating the EAP peer to the EAP server. The use of Kerberos guarantees simplicity and. The cross-realm features of Kerberos allows EAP-FRAP to support enhanced cross-realm roaming within the EAP framework. Zrelli & Shinoda Expires January 25, 2008 [Page 4] Internet-Draft XTGSP July 2007 2. Overview The extensions specified in this document can be summarized as follows : o A Kerberos realm name and a AAA realm name is associated to each access network. A Kerberos KDC serving the realm is deployed and ready to process standard Kerberos requests. Each Kerberos realm includes a special Kerberos service referred to as "knas" with the Kerberos principal name "knas/AAA-realm@KRB5-realm", where the "AAA-realm" is the AAA realm name of the local access network and "KRB5-realm" is the Kerberos realm name of the access network. The keytab of this service is made available to the EAP server of the network access. o The EAP peer obtains the initial EAP Identity Request message from the EAP authenticator. The EAP-Identity message must include the AAA realm name of the local access network. o Using the AAA realm name information, the EAP peer can check whether it shares an EMSK with the local EAP server. If it doesn't then EAP-FRAP can not be used and a full EAP authentication is carried out. o If the EAP peer shares an EMSK with the local EAP server then the EAP peer negotiates the use of EAP-FRAP. EAP-FRAP is negotiated as any other EAP method using EAP NAK messages when necessary. The bootstrapping of EAP-FRAP is detailed in Section 5 o The EAP peer obtains the Kerberos realm name of the local access network from the first EAP-FRAP Request from the local EAP server. o If the EAP peer does not have a TGT for the local Kerberos realm in its ticket cache, then an EAP-FRAP Response encapsulating a Kerberos AS-REQ message is sent to the local EAP server. The AS- REQ is built using a key derived from the EMSK, the Kerberos principal name used in the AS-REQ message corresponds to the EAP identity used in the initial EAP authentication. The EAP-FRAP Response message also contains an Authenticator that proves the identity of the EAP peer to the EAP server. The Authenticator is built using a key derived from the EMSK. The identity proven by the Authenticator corresponds to the identity used during the initial full EAP authentication (Note that this authenticator is not the same as the authenticator that may be included in the AS- REQ message). The creation of an EAP-FRAP message encapsulating a Kerberos AS-REQ message is detailed in Section 6 Zrelli & Shinoda Expires January 25, 2008 [Page 5] Internet-Draft XTGSP July 2007 o The local EAP server verifies the Authenticator and extracts the AS-REQ message. The EAP server then checks if the a Kerberos principal that corresponds to the EAP peer exists in the EAP Kerberos database. If the Kerberos principal does not exist it is created. The EAP server then forwards the AS-REQ to the KDC. The AS-REP message from the KDC is forwarded to the EAP peer. The processing of the the AS-REQ message is detailed in Section 7 o If the EAP peer has a TGT for the local Kerberos realm, it checks whether it has a service ticket for the service "knas". If such ticket does not exist, then an EAP-FRAP Response message encapsulating a TGS-REQ message is sent to the EAP server. The EAP server forwards the TGS-REQ message to the KDC and sends the TGS-REP reply message from the KDC back to the EAP peer. The acquisition of the service ticket trough the Kerberos TGS exchange with the KDC of the local access network is described in Section 8 and Section 9 o If the EAP peer has a ticket for the service "knas", then it issues a EAP-FRAP Response message that contains an AP-REQ message using this ticket. The AP-REQ message will be processed by the EAP Server. For that the EAP server uses the keytab of the "knas" service to decrypt the ticket and authenticate the EAP peer. If authentication succeeds, the EAP peer issues an EAP Success message. Along with the EAP Success message, the EAP peer delivers the MSK to the EAP authenticator. The authentication of the EAP peer using the service ticket and the termination of EAP- FRAP is described in Section 10 and Section 11 o When the EAP peer moves to a new access network to which corresponds a different Kerberos realm or a different AAA realm, the client may perform Kerberos cross-realm authentication in order to obtain a TGT for the new access network. The EAP server in this case acts as a Kerberos proxy and forwards the recursive TGS exchanges between the EAP peer and the KDCs in the cross-realm authentication path between the current and the previous access networks. The roaming operations in EAP-FRAP are detailed in Section 14 and Section 15 Zrelli & Shinoda Expires January 25, 2008 [Page 6] Internet-Draft XTGSP July 2007 3. Assumptions o The EAP-FRAP extension does not require client to belong to any Kerberos realm. However the client must have some other kind of credentials that allows it to authenticate to the visited realm using a certain EAP method. o The EAP method used the first time the EAP peer connects to the local access network must derive an EMSK on the EAP server and the EAP peer. o Since Kerberos uses times-tamps for protection against replay attacks, there must be a reasonably small time skew between the clocks of the EAP server, the EAP peer and the KDC. Zrelli & Shinoda Expires January 25, 2008 [Page 7] Internet-Draft XTGSP July 2007 4. EAP-FRAP message format EAP-FRAP encapsulates Kerberos5 [RFC4120] messages in EAP-Request and Response messages. The payload of the EAP message is formatted as follows : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg-type | Reserved | Msg-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KRB5-Realm-Length | KRB5-Realm ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 or more TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the EAP-FRAP message The EAP peer and the EAP server use additional TLVs for carrying other components such as Kerberos messages and Authenticators. The fixed elements of the EAP-FRAP message are defined as follows : o Msg-Type : Indicates the type of the EAP-FRAP message. This field may take one of the following values KRB5-INIT, KRB5-AS-REQ, KRB5- AS-REP, KRB5-TGS-REQ, KRB5-TGS-REP, KRB5-AP-REQ, KRB-AP-REP, KRB5- FINISH. o Reserved : This field contains flags. The current version does not define any flags yet. The field is just reserved for future use. o Msg-Length : The length of the payload EAP-FRAP message. This length includes all parts of the message except the fields Msg- type, Reserved and Msg-Length. o KRB5-Realm-Length : Contains the length in bytes of the Kerberos5 realm name field. o KRB5-Realm : Contains a Kerberos5 realm name. Additional Type-Length-Value pairs are used in EAP-FRAP messages. Zrelli & Shinoda Expires January 25, 2008 [Page 8] Internet-Draft XTGSP July 2007 These TLVs will be defined throughout the document. All the TLVs start by a 8 bit Type which is an integer indicating the type of TLV, followed by 16 bit Length field, finally a value field of variable length. Zrelli & Shinoda Expires January 25, 2008 [Page 9] Internet-Draft XTGSP July 2007 5. Bootstrapping of EAP-FRAP The EAP peer is responsible of bootstrapping EAP-FRAP, it must decide whether it can use EAP-FRAP or not. This section describes how this decision is made by the EAP peer. When the EAP peer changes of access point, it is queried for its identity by the EAP authenticator with an initial EAP-Identity Request message. EAP-FRAP mandates that the AAA realm name to be included in the payload of the EAP-Identity Request message. The current version of this document does not specify details on how the AAA realm name is carried in the payload of the EAP-Identity Request. o According to the EAP peer's context, the EAP peer has already authenticated to the AAA realm and a valid EMSK exists. o The EAP peer does not share an EMSK with the AAA realm, but the EAP peer has a valid TGT for another access network (the EAP peer in this case also have a valid Kerberos5 principal in that access network). In this case, the EAP peer will use Kerberos cross- realm authentication to obtain credentials in the new AAA realm. If the EAP peer does not share an EMSK with the AAA realm and it does not have valid TGT for another network access, then the EAP-FRAP can not be used. The EAP peer must perform a full EAP authentication using any legacy EAP authentication method. Clients that decide to use EAP-FRAP must negotiate the use of EAP- FRAP with the EAP server of the local access network as it would do with any other EAP authentication method with the EAP server, using the EAP-NAK message when necessary. When if the EAP server accepts the use of EAP-FRAP, then it issues an initial EAP-FRAP Request message of type KRB5-INIT. The initial EAP- FRAP Request message does not contain additional TLVs. The KRB5- Realm field contains the Kerberos realm name of the access network. Zrelli & Shinoda Expires January 25, 2008 [Page 10] Internet-Draft XTGSP July 2007 6. Creation of an EAP-FRAP encapsulating an AS-REQ message After negotiating the use of EAP-FRAP and reception of the initial KRB5-INIT message, the client checks if it has a TGT for the realm indicated in the KRB5-Realm field. If such TGT does not exist or exists but is expired, then the EAP peer must issue a EAP-FRAP Response encapsulating an AS-REQ message. The Msg-Type field of the EAP-FRAP message is set to KRB5-AS-REQ. An additional TLV or type "KRB5-MSG" (Type=0) is added. The value field of this TLV contains the DER encoding of a Kerberos AS-REQ message as defined in [RFC4120]. In order to build the AS-REQ message, the EAP peer MUST have a Kerberos principal. If the EAP peer does not have a Kerberos principal. One must be derived, The private key of the Kerberos principal is derived from the EMSK and the principal name is corresponds to the EAP peer's identity (the same identity used in the initial EAP authentication). Details of the derivation of a Kerberos principal from the EAP peer identity and the EMSK are in Section 12 . The EAP peer fills the AS-REQ message using the Kerberos realm name of the access network in the "realm" field of the AS-REQ. The "addresses" field of the AS-REQ message is left empty. The EAP-KRB5 Response message MUST contain an additional TLV of type "Authenticator" (Type=1). The Authenticator allows the EAP server to authenticate the client. The payload of the Authenticator TLV is divided into three fields. First "Auth-Type", is an 8 bit integer that indicates which type of authenticator is being used. This document specifies the default authenticator (Auth-Type 0) which consists of a time-stamp and the Kerberos principal name encrypted using the private key of the Kerberos principal (More details on how to build the default Authenticator (Auth-Type 0) are describe in [TBD]). After the Auth-Type field, an 8 bit field called "Crypto- Suite" contains an intefer code that indicates the cryptographic suite for processing the authenticator. The default and mandatory to implement cryptographic suite (Crypto-Suite 0) is [TBD]. Figure Figure 2 shows the layout of an EAP-FRAP message of type KRB5- AS-REQ (Msg-type 1) that encapsulates an AS-REQ and an Authenticator. Zrelli & Shinoda Expires January 25, 2008 [Page 11] Internet-Draft XTGSP July 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg-type = 1 | Reserved | Msg-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KRB5-Realm-Length | KRB5-Realm ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Length | AS-REQ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | Auth-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Crypto-Suite | Authenticator ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of the EAP-FRAP AS-REQ message Zrelli & Shinoda Expires January 25, 2008 [Page 12] Internet-Draft XTGSP July 2007 7. Receipt of an EAP-FRAP message encapsulating an AS-REQ message Upon reception of an AS-FRAP message of type KRB5-AS-REQ, the EAP server verifies the authenticator. If the authenticator is valid, then the EAP server will derive a Kerberos principal from the EAP peer's identity and EMSK. The EAP server may add or update the Kerberos principal in the database of the KDC serving the local access network. The maximum ticket lifetime and maximum total lifetime for renewable tickets must be equal or smaller than the remaining lifetime of the EMSK. The procedure of adding and updating the Kerberos principal is out of the scope of this document. The EAP server keeps track of the kerberos principals that were added in the database of the local Kerberos realm. Principals are removed from the Kerberos database when their corresponding EMSK expire (i.e. when their AAA session expire). After the EAP server has ensured the existence of the Kerberos principal, the AS-REQ message is extracted from the EAP-FRAP message and forwarded to the KDC of the local access network. The AS-REP message from the KDC is sent to the EAP peer in an EAP-FRAP message of type KRB5-AS-REP. The EAP-FRAP message contains a TLV of type "KRB5-MSG" that contains the DER encoding of the AS-REP message. Zrelli & Shinoda Expires January 25, 2008 [Page 13] Internet-Draft XTGSP July 2007 8. Creation of an EAP-FRAP encapsulating a TGS-REQ message If the EAP peer does not have a service ticket for the network access service. It must obtain one. The EAP peer prepares a TGS-REQ message as specified in [RFC4120]. The TGT for the local access network is used to build the TGS-REQ message. The "sname" field must be set to "knas/AAA-Realm", where AAA-Realm if the AAA realm name of the local access network. The "realm" field of the TGS-REQ message is set to the Kerberos realm name of the local access network. The TGS-REQ message is sent to the EAP server in an EAP-FRAP message. The Msg-Type field of the EAP-FRAP message is set to "KRB5-TGS-REQ". The EAP-FRAP message contains a TLV of type "KRB5-MSG". The payload of this TLV contains the DER encoding of the TGS-REQ message. Zrelli & Shinoda Expires January 25, 2008 [Page 14] Internet-Draft XTGSP July 2007 9. Receipt of an EAP-FRAP message encapsulating a TGS-REQ message When the EAP server receives an EAP-FRAP message of type KRB5-TGS- REQ, it extracts the TGS-REQ message then proxies it to the KDC serving the local access network. The TGS-REP message from the KDC is encapsulated in an EAP-FRAP message with Msg-Type field equal to "KRB5-TGS-REP". The TGS-REP message is carried in a "KRB5-MSG" TLV. Zrelli & Shinoda Expires January 25, 2008 [Page 15] Internet-Draft XTGSP July 2007 10. Creation of an EAP-FRAP encapsulating an AP-REQ message The EAP peer creates an AP-REQ message as specified in [RFC4120]. The ticket for the service "knas/AAA-realm@KRB5-Realm" is used to build the AP-REQ message which will be shipped to the EAP server in an EAP-FRAP message where Msg-Type is set to "KRB5-AP-REQ". A TLV of type "KRB5-MSG" is used to carry the DER encoding of the AP-REQ message. Zrelli & Shinoda Expires January 25, 2008 [Page 16] Internet-Draft XTGSP July 2007 11. Receipt of an EAP-FRAP message encapsulating a AP-REQ message When the EAP server receives an EAP-FRAP message of type "KRB5-AP- REQ", it starts by validating the ticket and the Authenticator included in the AP-REQ message. If the authentication of the EAP peer is successful, the EAP server may issue an AP-REP message if the flag "mutual-required" of the AP-REQ message is set. In this case, the EAP server sends the AP-REP message to the EAP peer. The AP-REP message is encapsulated in an EAP-FRAP message of type "KRB5-AP-REP". A TLV of type "KRB5-MSG" is used in the EAP-FRAP message to carry the DER encoded AP-REP message. If the flag "mutual-required" is not set, then the EAP server issues an EAP Success message. Along with the EAP Success message, the EAP server delivers an MSK to the EAP authenticator. If an AP-REP message was sent, the EAP peer will process the AP-REP as specified in [RFC4120]. If the AP-REP message is successfully verified, then the EAP peer issues an EAP-FRAP message with Msg-Type equal to "KRB5-FINISH". This EAP-FRAP message does not have any extra TLVs. The EAP peer can then derive the MSK. When the EAP server receives this EAP-FRAP message, it issues an EAP Success message. Along with the EAP Success message, the EAP server delivers an MSK to the EAP authenticator. The derivation of the MSK is detailed in Section 13 Zrelli & Shinoda Expires January 25, 2008 [Page 17] Internet-Draft XTGSP July 2007 12. Derivation of Kerberos principal [TBD] Zrelli & Shinoda Expires January 25, 2008 [Page 18] Internet-Draft XTGSP July 2007 13. Derivation of MSK after termination of EAP-FRAP [TBD] Zrelli & Shinoda Expires January 25, 2008 [Page 19] Internet-Draft XTGSP July 2007 14. Inter AAA domain hand-overs [TBD] Zrelli & Shinoda Expires January 25, 2008 [Page 20] Internet-Draft XTGSP July 2007 15. Inter Kerberos realm hand-overs [TBD] Zrelli & Shinoda Expires January 25, 2008 [Page 21] Internet-Draft XTGSP July 2007 16. Security considerations [RFC4120] highlights several security considerations. Most of these considerations apply to the framework using EAP-FRAP. The current version of the document does not analyze possible security threats and considerations introduced by the EAP-FRAP. Zrelli & Shinoda Expires January 25, 2008 [Page 22] Internet-Draft XTGSP July 2007 17. Normative References [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Zrelli & Shinoda Expires January 25, 2008 [Page 23] Internet-Draft XTGSP July 2007 Authors' Addresses Saber Zrelli Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 JAPAN Email: zrelli@jaist.ac.jp Yoichi Shinoda Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 JAPAN Email: shinoda@jaist.ac.jp Zrelli & Shinoda Expires January 25, 2008 [Page 24] Internet-Draft XTGSP July 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). Zrelli & Shinoda Expires January 25, 2008 [Page 25]