Network Working Group J. Arkko Internet-Draft V. Lehtovirta Updates: 4187 (if approved) Ericsson Intended status: Informational P. Eronen Expires: January 8, 2009 Nokia July 7, 2008 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') draft-arkko-eap-aka-kdf-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 8, 2009. Arkko, et al. Expires January 8, 2009 [Page 1] Internet-Draft EAP-AKA' July 2008 Abstract This specification defines a new EAP method, EAP-AKA', a small revision of the EAP-AKA method. The change is a new key derivation function that binds the name of the access network to the keys derived within the method. As a result, it becomes possible to authenticate the network name. The new key derivation mechanism has been defined in 3GPP. This specification allows its use in EAP in an interoperable manner. This specification also updates RFC 4187 EAP-AKA to add support for preventing bidding down attacks between itself and EAP-AKA'. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The AT_KDF_INPUT Attribute . . . . . . . . . . . . . . . . 5 2.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Key Generation . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Hash Function Update . . . . . . . . . . . . . . . . . . . 9 3. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Changes from RFC 4187 . . . . . . . . . . . . . . . . 17 Appendix B. Importance of Explicit Negotiation . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Arkko, et al. Expires January 8, 2009 [Page 2] Internet-Draft EAP-AKA' July 2008 1. Introduction This specification defines a new Extensible Authentication Protocol (EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA method originally defined in [RFC4187]. What is new in EAP-AKA' is that it has a new key derivation function specified in [3GPP.33.402]. This function binds the name of the access network to the keys derived within the method. As a result, it becomes possible to authenticate the network name, limiting the effects of compromised nodes and keys. This specification defines the EAP encapsulation for AKA when the new key derivation mechanism is in use. 3GPP has defined a number of applications for the revised AKA mechanism, some based on native encapsulation of AKA over 3GPP radio access networks and others based on the use of EAP. For making the new key derivation mechanisms usable in EAP-AKA additional protocol mechanisms are necessary. Given that RFC 4187 calls for the use of CK (the encryption key) and IK (the integrity key) from AKA directly, existing implementations continue to use these. Any change of the key derivation must be unambiguous to both sides in the protocol. That is, it must not be possible to accidentally connect old equipment to new equipment and get the key derivation wrong or attempt to use wrong keys without getting a proper error message. This specification therefore introduces a variant of the EAP-AKA method, called EAP-AKA'. This method can employ the derived keys CK' and IK' from the 3GPP specification but it is otherwise equivalent to RFC 4187. Given that a different EAP method Type value is used for EAP-AKA and EAP-AKA', a mutually supported method may be negotiated using the standard mechanisms in EAP [RFC3748]. Editor's Note: A number of other possible ways to use the new key derivation functions have been proposed. These include configuration and reliance on a particular domain employing only the new functions. Appendix B explains why these approaches lead to severe interoperability problems and why it is important to be explicit about the change of semantics in protocol design. The rest of this specification is structured as follows. Section 2 defines the EAP-AKA' method. Section 3 adds support to EAP-AKA to prevent bidding down attacks from EAP-AKA'. Section 4 explains the security differences between EAP-AKA and EAP-AKA'. Section 5 describes the IANA considerations and Appendix A explains what updates to RFC 4187 EAP-AKA have been made in this specification. Arkko, et al. Expires January 8, 2009 [Page 3] Internet-Draft EAP-AKA' July 2008 2. EAP-AKA' EAP-AKA' is a new EAP method that follows EAP-AKA specification [RFC4187] in all other respects except the following: o It uses the Type code TBD1 BY IANA, not 23 which is used by EAP- AKA. o It carries the AT_KDF_INPUT attribute, as defined in Section 2.1 to ensure that both parties know the name of the access network. o It calculates the Master Key (MK) as defined in Section 2.3, not as defined in EAP-AKA. o It uses the optional AT_KDF attribute as defined in Section 2.2 to control possible future key derivation function changes. Figure 1 shows an example of the authentication process. Each message AKA'-Challenge and so on represents the corresponding message from EAP-AKA, but with EAP-AKA' Type code. The definition of these messages, along with the definition of attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found from [RFC4187]. Arkko, et al. Expires January 8, 2009 [Page 4] Internet-Draft EAP-AKA' July 2008 Peer Server | EAP-Request/Identity | |<------------------------------------------------------| | | | EAP-Response/Identity | | (Includes user's NAI) | |------------------------------------------------------>| | +-------------------------------+ | | Server runs AKA' algorithms, | | | generates AT_RAND and AT_AUTN.| | | For creating AT_MAC, the | | | server employs CK' and IK'. | | +-------------------------------+ | EAP-Request/AKA'-Challenge | | (AT_RAND, AT_AUTN, AT_KDF_INPUT, AT_MAC)| |<------------------------------------------------------| +-------------------------------------+ | | Peer runs AKA' algorithms, | | | verifies AT_AUTN and AT_MAC, derives| | | AT_RES and session keys. Again, for | | | verifying AT_MAC and creating | | | AT_RES, the peer uses CK' and IK' | | +-------------------------------------+ | | EAP-Response/AKA'-Challenge | | (AT_RES, AT_MAC) | |------------------------------------------------------>| | +--------------------------------+ | | Server checks the given AT_RES,| | | and MAC and finds them correct.| | +--------------------------------+ | EAP-Success | |<------------------------------------------------------| Figure 1: EAP-AKA' Authentication Process 2.1. The AT_KDF_INPUT Attribute The format of the AT_KDF_INPUT attribute is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_KDF_INPUT | Length | Actual Network Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Network Name . . . | | Arkko, et al. Expires January 8, 2009 [Page 5] Internet-Draft EAP-AKA' July 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are as follows: AT_KDF_INPUT This is set to TBD2 BY IANA. Length The length of the attribute, calculated as defined in [RFC4187] Section 8.1. Actual Network Name Length This a 2-byte actual length field, needed due to the requirement that previous field is expressed in multiples of 4 bytes per the usual EAP-SIM and EAP rules. The Actual Network Name Length field provides the length of the Network Name in bytes. Network Name This field contains the network name of the access network for which the authentication is being performed. The name does not include any terminating null characters. Because the length of the entire attribute must be a multiple of 4 bytes, the sender pads the name with zero bytes when necessary. Only the server sends the AT_KDF_INPUT attribute. The peer SHOULD check the received value against its own understanding of the network name. Upon detecting a discrepancy, the peer MAY either log an error and continue, or fail the authentication process. The Network Name field contains an octet string. This string MUST be constructed as specified in [3GPP.23.003]. For network types where this reference does not provide an instruction on how to construct the name, the empty octet string SHOULD be used. Editor's Note: This 3GPP specification is still being worked on. It is assumed that the specification ensures that conflicts potentially arising from using the same name in different types of networks are avoided. It is also assumed that the 3GPP specification will have detailed rules about how a client can determine these based on information available to the client, such as the type of protocol used to attach to the network, beacons sent out by the network, and so on. Information that the client cannot directly observe (such as the type or version of the home Arkko, et al. Expires January 8, 2009 [Page 6] Internet-Draft EAP-AKA' July 2008 network) should not be used by this algorithm. 2.2. AT_KDF AT_KDF is an optional attribute that the server MAY use when it wishes to employ a specific key derivation function. This is useful for future evolution of the key derivation functions. The format of the AT_KDF attribute is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_KDF | Length | Key Derivation Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are as follows: AT_KDF This is set to TBD3 BY IANA. Length The length of the attribute, MUST be set to 1. Key Derivation Function An enumerated value representing the key derivation function that the server (or peer) wishes to use. Value 1 represents RFC 4187 key derivation, i.e., fallback to EAP-AKA functionality. Value 2 represents the default key derivation function for EAP-AKA', i.e., employing CK' and IK' as defined in Section 2.3. Servers MAY choose to send one or more AT_KDF attributes in the EAP- Request/AKA'-Challenge message. The first of these attributes represents the desired function and the other ones are acceptable alternatives, the most desired alternative being the second attribute. Upon receiving this attribute, if the peer supports and is willing to use the key derivation function indicated by the first attribute, the function is taken into use and no further action is necessary. However, if the peer does not support this function or is unwilling to use it, it responds with the EAP-Response/AKA'-Challenge message that contains only one attribute, AT_KDF with the value set to the selected alternative. If there is no suitable alternative, the peer Arkko, et al. Expires January 8, 2009 [Page 7] Internet-Draft EAP-AKA' July 2008 behaves as if AT_MAC had been incorrect and authentication fails. Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the peer, the server checks that the alternative was in its offer. If not, it behaves as if AT_MAC of the response had been incorrect and fails the authentication. Otherwise, the server re-sends the EAP- Response/AKA'-Challenge message, but moves the selected alternative to the beginning of the list of AT_KDF attributes. When the peer receives the new EAP-Request/AKA'-Challenge message, it MUST check that requested change, and only the requested change occurred in the list of AT_KDF attributes. If yes, it continues. If not, it behaves as if AT_MAC had been incorrect and fails the authentication. 2.3. Key Generation Both the peer and server MUST derive the Master Key (MK) from underlying AKA values and the identity, as follows. AT_KDF set to 1 MK is as defined in [RFC4187]. AT_KDF not present or set to 2 MK is as follows: MK = SHA1(Identity|IK'|CK') Here SHA1 and Identity are as specified in [RFC4187] and IK' and CK' are derived as specified in [3GPP.33.402]. The functions that derive IK' and CK' take the following parameters: CK and IK produced by the AKA algorithm and value of the Network Name field (without length or padding) from AT_KDF_INPUT as the access network identity. AT_KDF is present and has any other value Future variations of key derivation functions may be defined, and they will be represented by new values of AT_KDF. If the peer does not recognize the value it cannot calculate the keys and behaves as explained in Section 2.2. If the peer supports a given key derivation function but is unwilling to perform it for policy reasons, it refuses to calculate the keys and behaves as explained in Section 2.2. Arkko, et al. Expires January 8, 2009 [Page 8] Internet-Draft EAP-AKA' July 2008 2.4. Hash Function Update Given that we are defining a new method, it would potentially be a convenient time to introduce a change of the hash functions from those used in EAP-AKA (SHA1) to SHA256 which is used in new 3GPP systems. Would this be desirable? Arkko, et al. Expires January 8, 2009 [Page 9] Internet-Draft EAP-AKA' July 2008 3. Bidding Down Prevention for EAP-AKA As discussed in [RFC3748], negotiation of methods within EAP is insecure. That is, a man-in-the-middle attacker may force the endpoints to use a method that is not the strongest one they both support. This is a problem, as we expect EAP-AKA and EAP-AKA' to be negotiated via EAP. In order to prevent such attacks, this specification specifies a new mechanism for EAP-AKA that allows the endpoints to securely discover the capabilities of each other. This mechanism comes in the form of the AT_BIDDING attribute. This allows both endpoints to communicate their desire and support for EAP-AKA' when exchanging EAP-AKA messages. This attribute is not included in EAP-AKA' messages as defined in this RFC. If during the authentication process it is discovered that both endpoints would have been able to use EAP-AKA', the authentication process SHOULD be aborted, as a bidding down attack may have happened. The format of the AT_BIDDING attribute is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_BIDDING | Length |D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are as follows: AT_BIDDING This is set to TBD4 BY IANA. Length The length of the attribute, MUST be set to 1. D This bit is set to 1 if the sender does support EAP-AKA', is willing to use it, and prefers it over EAP-AKA. Otherwise it should be set to 0. Reserved This field MUST be set to zero when sent and ignored on receipt. Arkko, et al. Expires January 8, 2009 [Page 10] Internet-Draft EAP-AKA' July 2008 The server sends this attribute in the EAP-Request/AKA-Challenge message. The peer compares the received value to its own capabilities. If it turns out that both the server and peer would have been able to use EAP-AKA' and preferred it over EAP-AKA, the peer behaves as if AT_MAC had been incorrect, and fails the authentication. Arkko, et al. Expires January 8, 2009 [Page 11] Internet-Draft EAP-AKA' July 2008 4. Security Considerations A summary of the security properties of EAP-AKA' follows. As there has been only a minor change in the method, most of the security properties are unchanged from EAP-AKA. Protected ciphersuite negotiation The ciphersuite negotiation mechanisms of EAP-AKA are also present in EAP-AKA'. Refer to [RFC4187] Section 12 for further details. However, EAP-AKA' adds a new negotiation mechanism for selecting the key derivation function that feeds CK' and IK' into MK. This mechanism is secure against bidding down attacks. Mutual authentication The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to [RFC4187] Section 12 for further details. Integrity protection The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to [RFC4187] Section 12 for further details. Replay protection The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to [RFC4187] Section 12 for further details. Confidentiality The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to [RFC4187] Section 12 for further details. Key derivation The key derivation mechanisms of EAP-AKA are also present in EAP- AKA'. Refer to [RFC4187] Section 12 for further details. However, EAP-AKA' adds an additional layer of key derivation functions within itself. This does not affect the type of keys the method exports. However, the additional functions make it harder to use compromised keys in a different context. Key strength The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect, on the assumption that key derivation functions do not change the strength of the keys. This is currently the case with Arkko, et al. Expires January 8, 2009 [Page 12] Internet-Draft EAP-AKA' July 2008 the functions defined in [3GPP.33.402]. Refer to [RFC4187] Section 12 for further details. Dictionary attack resistance The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to [RFC4187] Section 12 for further details. Fast reconnect The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to [RFC4187] Section 12 for further details. Note that implementations MUST prevent performing a fast reconnect across method types. Cryptographic binding Note that this term refers to a very specific form of binding, something that is performed between two layers of authentication. It is not the same as the binding to a particular network name. The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect, i.e., as it is not a tunnel method this property is not applicable to it. Refer to [RFC4187] Section 12 for further details. Session independence The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to [RFC4187] Section 12 for further details. Fragmentation The properties of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to [RFC4187] Section 12 for further details. Channel binding EAP-AKA' provides a simple form of channel binding. Arkko, et al. Expires January 8, 2009 [Page 13] Internet-Draft EAP-AKA' July 2008 5. IANA Considerations EAP-AKA' has the EAP Type value TBD1 BY IANA. Per [RFC3748] Section 6.2, this allocation can be made with Designated Expert and Specification Required. EAP-AKA' shares its attribute space and message Subtypes, with EAP- SIM [RFC4186] and EAP-AKA [RFC4186]. However, a new Attribute Type value (TBD2) in the non-skippable range needs to be assigned for AT_KDF_INPUT (Section 2.1). Also, a new Attribute Type value (TBD3) in the non-skippable range needs to be assigned for AT_KDF (Section 2.2). IANA also needs to create a registry for EAP-AKA' KDF Type values. The initial contents of this registry are given below; new values can be created through Specification Required policy [RFC5226]. Value Description Reference --------- ---------------------- --------------- 0 Reserved 1 EAP-AKA with CK/IK [this document] 2 EAP-AKA' with CK'/IK' [this document] 3-65535 Unassigned Finally, a new Attribute Type value (TBD4) in the skippable range needs to be assigned for AT_BIDDING (Section 3). Arkko, et al. Expires January 8, 2009 [Page 14] Internet-Draft EAP-AKA' July 2008 6. Acknowledgments The authors would like to thank Guenther Horn, Joe Salowey, Mats Naslund, and Stefan Rommer for interesting discussions in this problem space. Arkko, et al. Expires January 8, 2009 [Page 15] Internet-Draft EAP-AKA' July 2008 7. References 7.1. Normative References [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [3GPP.23.003] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 8)", 3GPP Draft Technical Specification 23.003 v 8.0.0, June 2008. [3GPP.33.402] 3GPP, "3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses; Release 8", 3GPP Draft Technical Specification 33.402 v 8.0.0, June 2008. 7.2. Informative References [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP- SIM)", RFC 4186, January 2006. [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006. [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network Discovery and Selection Problem", RFC 5113, January 2008. Arkko, et al. Expires January 8, 2009 [Page 16] Internet-Draft EAP-AKA' July 2008 Appendix A. Changes from RFC 4187 The changes to RFC 4187 relate only to the bidding down prevention support defined Section 3. Arkko, et al. Expires January 8, 2009 [Page 17] Internet-Draft EAP-AKA' July 2008 Appendix B. Importance of Explicit Negotiation Choosing between the traditional and revised AKA key derivation functions is easy when their use is unambiguously tied to a particular radio access network, e.g LTE as defined by 3GPP or eHRPD as defined by 3GPP2. There is no possibility for interoperability problems if this radio access network is always used in conjunction with new protocols that cannot be mixed with the old ones; clients will always know whether they are connecting to the old or new system. However, using the new key derivation functions over EAP introduces several degrees of separation, making the choice of the correct key derivation functions much harder. Many different types of networks employ EAP. Most of these networks have no means to carry any information about what is expected from the authentication process. EAP itself is severely limited in carrying any additional information, as noted in [RFC4284] [RFC5113]. Even if these networks or EAP were extended to carry additional information, it would not affect millions of deployed access networks and clients attaching to them. Simply changing the key derivation functions that EAP-AKA [RFC4187] uses would cause interoperability problems with all of the existing implementations. Perhaps it would be possible to employ strict separation into domain names that should be used by the new clients and networks. Only these new devices would then employ the new key derivation mechanism. While this can be made to work for specific cases, it would be an extremely brittle mechanism, ripe to result in problems whenever client configuration, routing of authentication requests, or server configuration does not match expectations. It also does not help to assume that the EAP client and server are running a particular release of 3GPP network specifications. Network vendors often provide features from the future releases early or do not provide all features of the current release. And obviously, there are many EAP and even some EAP-AKA implementations that are not bundled with the 3GPP network offerings. In general, these approaches are expected to lead to hard-to-diagnose problems and increased support calls. Arkko, et al. Expires January 8, 2009 [Page 18] Internet-Draft EAP-AKA' July 2008 Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Vesa Lehtovirta Ericsson Jorvas 02420 Finland Email: vesa.lehtovirta@ericsson.com Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com Arkko, et al. Expires January 8, 2009 [Page 19] Internet-Draft EAP-AKA' July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Arkko, et al. Expires January 8, 2009 [Page 20]