Internet Draft Pascal Urien Document: draft-urien-16ng-security-api-01.txt Expires: June 2008 Security API for the IEEE 802.16 Security Sublayer 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 June, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). All rights reserved. 1 Abstract This document describes a security Application Programming Interface (API), which aims at supporting tamper resistant devices that perform collaborative tasks with the IEEE 802.16 security sublayer. The security sublayer provides operators with strong protection from theft of service. This security API enables to transfer critical calculations or protocol processing to trusted computers, such as smart cards or trusted platform modules (TPMs). Urien Informational - Expires June 2008 1 Security API for the IEEE 802.16 Security Sublayer December 2007 Table of Contents Copyright Notice...................................................1 1 Abstract.........................................................1 2 Overview.........................................................3 2.1 The IEEE 802.16 Security Sublayer...........................3 2.2 Security APIs for the security sublayer.....................5 3 Terms............................................................6 4 The PKMv1 protocol...............................................6 5 PKMv1 Services...................................................7 5.1 Basic Services..............................................7 5.2 Extended Services...........................................8 5.2.1 Services..............................................8 5.2.2 Some calculation details..............................8 6 PKMv2 protocol...................................................9 6.1 Single PKMv2-RSA operation..................................9 6.1.1 Overview..............................................9 6.1.2 Some calculation details..............................9 6.2 Single PKMv2-EAP operation..................................9 6.2.1 Overview..............................................9 6.2.2 Some calculation details..............................9 6.3 Single PKMv2-RSA and single PKMv2-EAP operation.............9 6.3.1 Overview..............................................9 6.3.2 Some calculations details............................10 6.4 Double PKMv2-EAP session...................................10 6.4.1 Overview.............................................10 6.4.2 Some calculation details.............................10 6.5 The SA-TEK 3-way Handshake.................................10 6.5.1 Overview.............................................10 6.5.2 Some calculation details.............................11 6.6 Broadband Services.........................................11 6.6.1 Overview.............................................11 6.6.3 Some calculation details.............................11 6.7 HMAC and CMAC keys.........................................11 7 PKMV2 services..................................................12 7.1 Basic Services.............................................12 7.2 Extended Services..........................................13 7.2.1 Data Management......................................13 7.2.2 PKMv2-RSA facilities.................................13 7.2.3 PKMv2-EAP facilities.................................13 7.2.4 SA-TEK 3-way Handshake facilities....................13 7.2.5 Broadband facilities.................................14 7.2.6 Keys facilities......................................14 8 References......................................................16 9 Authors's and contributors' addresses...........................16 Intellectual Property Statement...................................17 Disclaimer of Validity............................................17 Copyright Statement...............................................17 Acknowledgment....................................................17 Urien Informational Expires June 2008 2 Security API for the IEEE 802.16 Security Sublayer December 2007 2 Overview 2.1 The IEEE 802.16 Security Sublayer +----------------------+ | EAP Method | +-----------+----------+ | +-----------+----------+ | EAP Layer | +-----------+----------+ | +--------------------+--------------------+-----------+-----------+ | RSA based Authen- | Authorization / SA | EAP encapsulation | | -tication (RSA-OP) | Control (SA-CNTL) | decapsulation (EAP-OP)| +--------------------+--------------------+-----------------------+ | PKM Control Management (PKM-CM) | +---------------------------------+-------------------------------+ | Traffic Data | Control Message Processing | | Encryption/Authentication | (PKM-CMP) | | Processing | +------------------------+ | | + Message Authentication | | (TDEAP) +------+------+ Processing (PKM-MAP)| +--------------------------+ PHY SAP +------------------------+ +------+------+ | The IEEE 802.16e security sublayer According to the [IEEE 802.16e] specification, the security sublayer provides subscribers with privacy, authentication, or confidentiality. It does this by applying cryptographic transforms to MAC PDUs carried across between connections between SS and BS. The Traffic Data Encryption Authentication sublayer (TDEAP) performs these operations thanks to negotiated cryptographic algorithms working with Traffic Encryption Keys (TEKs). In addition, the security sublayer provides operators with strong protection from theft of service. The BS protects against unauthorized access to these data transport services by enforcing encryption of the associated service flows across the network. The security sublayer employs an authenticated client/server key management protocol, named PKM (Privacy Key Management) in which the BS, the server, controls distribution of keying material to client SS. Urien Informational Expires June 2008 3 Security API for the IEEE 802.16 Security Sublayer December 2007 PKM Control Management (PKM-CM) entities exchange messages that usually include an authentication field, computed either with HMAC [RFC 2104] or CMAC [RFC 4493] algorithms. These packets are parsed by the Control Message Processing bloc (PKM-CMP) and authenticated by the Message Authentication Processing sublayer (PKM-MAP) The PKM-CM entity is the heart of the security sublayer. It performs the following functions: - Management of security associations (SA). A Security Association (SA) is the set of security information share between BS and SS in order to support secure communications across the IEEE 802.16 network. One may distinguish two classes of security associations, first is used for control messages, second for traffic data. - Management of RSA based authentication operations (RSA-OP) - Management of EAP [RFC 3748] packets (EAP-OP). The privacy sublayer accesses to an EAP stack, as defined by [RFC 3748] that supports one or several authentication methods. Urien Informational Expires June 2008 4 Security API for the IEEE 802.16 Security Sublayer December 2007 2.2 Security APIs for the security sublayer Security APIs aim at increasing operators trust in security sublayer operations, and facilitating users’ mobility. These goals are typically achieved by delegating operations, dealing with RSA calculations or EAP packets processing, to tamper resistant devices such as Trusted Platform Module (TPM) or Smart Cards. Basic services only deal with RSA calculations and/or EAP packets processing. Extended services cache the Authorization Key (AK) in a trusted computing platform. In that case the AK value is never exposed to the security sublayer. All calculations dealing with AK are performed by a tamper resistant device, which computes and exports all keys needed by security associations. +-------------------------------------------------------+ | | | +------------+ | | TAMPER RESISTANT DEVICE | EAP Method | | | +------+-----+ | | | | | RSA Operations +-------------------------+-------+ | | | | Secure Data Storage | +------+-----+ | | | EAP Layer | | | +------+-----+ +-|---------|---------+ | ..|.........|..............SECURITY API.........| | | | | +------ V----------+------------------+-----V-----------------+ | |RSA based Authen- |Authorization / SA| EAP encapsulation | | |-tication (RSA-OP)|Control (SA-CNTL) | decapsulation (EAP-OP)| +-V-+------------------+------------------+-----------------------+ | PKM Control Management (PKM-CM) | +---------------------------------+-------------------------------+ | Traffic Data | Control Message Processing | | Encryption/Authentication | (PKM-CMP) | | Processing | +------------------------+ | | + Message Authentication | | (TDEAP) +------+------+ Processing (PKM-MAP)| +--------------------------+ PHY SAP +------------------------+ +------+------+ Security APIs for the privacy sublayer Urien Informational Expires June 2008 5 Security API for the IEEE 802.16 Security Sublayer December 2007 3 Terms 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. AK Authorization Key AK-SN AK Sequence Number AKID AK IDentifier ASA Authentication and Service Authorization BS Base Station BSID Base Station Identification CMAC Cipher-based Message Authentication Code EAP Extensible authentication protocol EIK EAP Integrity Key GKEK Group Key Encryption Key GTEK Group Traffic Encryption Key HMAC Hashed Message Authentication Code KEK Key Encryption Key MAC Medium Access Control MAK MBS AK MBS Multicast and Broadcast Services MS Mobile Station MSK Master Session Key MTK MBS Transport Key PAK Primary Authorization Key PKM Privacy Key Management PMK Pairwise Master Key PS Privacy Sublayer Pre-PAK Pre Primary AK SAID Security Association Identifier SN Sequence Number SS Subscriber Station TEK Traffic Encryption Key 4 The PKMv1 protocol The PKMv1 protocol realizes the SS authentication thanks to a single way authentication. The SS forwards its X509 certificate to the BS. The BS sends an AK key, encrypted with the SS public key. Three parameters are deduced from the AK value, a key encryption key (KEK(AK)), a HMAC key used for the downlink (HMAC-D(AK)) and a HMAC key used for the uplink (HMAC-U(AK)). Urien Informational Expires June 2008 6 Security API for the IEEE 802.16 Security Sublayer December 2007 5 PKMv1 Services 5.1 Basic Services Two services are defined * Get-SS-Certificate () collects the SS certificate * Decrypt-SS-RSA-Priv (Message) decrypts a message with the SS RSA private key. Get-SS-Certificate() | | Decrypt-SS-RSA-Priv(Message) | | +----V----------V----+--------------------+ | RSA based Authen- | Authorization / SA | | -tication (RSA-OP) | Control (SA-CNTL) | +--------------------+--------------------+-----------------------+ | PKM Control Management (PKM-CM) | +---------------------------------+-------------------------------+ | Traffic Data | Control Message Processing | | Encryption/Authentication | (PKM-CMP) | | Processing | +------------------------+ | | + Message Authentication | | (TDEAP) +------+------+ Processing (PKM-MAP)| +--------------------------+ PHY SAP +------------------------+ +------+------+ PKMv1 Basic Services Urien Informational Expires June 2008 7 Security API for the IEEE 802.16 Security Sublayer December 2007 5.2 Extended Services 5.2.1 Services Five services are defined * Get-Certificate () collects the SS certificate * Set-AK(AK-SN, Message), pushes a message that contains an encrypted value of AK, identified by its index AK-SN, towards the tamper resistant device. * Get-KEK(AK-SN), collects a KEK key whose index is AK-SN. * Get-HMAC-U(AK-SN), collects an HMAC-U key, whose index is AK-SN * Get-HMAC-D(AK-SN), collects an HMAC-D key, whose index is AK-SN Get-SS-Certificate() | | Set-AK(AK-SN, Message) | | | | +- Get-KEK(AK-SN) | | | | | +-- Get-HMAC-U(AK-SN) | | | | | +--- Get-HMAC-U(AK-SN | | | +----V----V-----V----+--------------------+ | RSA based Authen- | Authorization / SA | | -tication (RSA-OP) | Control (SA-CNTL) | +--------------------+--------------------+-----------------------+ | PKM Control Management (PKM-CM) | +---------------------------------+-------------------------------+ | Traffic Data | Control Message Processing | | Encryption/Authentication | (PKM-CMP) | | Processing | +------------------------+ | | + Message Authentication | | (TDEAP) +------+------+ Processing (PKM-MAP)| +--------------------------+ PHY SAP +------------------------+ +------+------+ PKMv1 Extended Services 5.2.2 Some calculation details KEK=Truncate(SHA1(K-PAD-KEK | AK),128) K-PAD-KEK=0x53 repeated 64 times, i.e., a 512 bits string. HMAC-KEY-D=SHA1(H-PAD-D|AK), H-PAD-D=0x3A repeated 64 times HMAC-KEY-U=SHA1(H-PAD-U|AK), H-PAD-U=0x5C repeated 64 times Urien Informational Expires June 2008 8 Security API for the IEEE 802.16 Security Sublayer December 2007 6 PKMv2 protocol The PKMv2 protocol supports four classes of authentication procedures, single PKMv2-RSA, single PKMv2-EAP, single PKMv2-RSA and single PKMV2-EAP, and double PKMv2-EAP session. 6.1 Single PKMv2-RSA operation 6.1.1 Overview In the PKMv2-RSA protocol a mutual authentication is performed between SS and BS. The SS is identified by its X509 certificate and holds a RSA private key. The BS is identified by its X509 certificate and holds a RSA private key. The BS sends a Pre-PAK key encrypted with the SS public key and associated to an AK-SN index (the Key Sequence Number). A value PAK is then deduced from Pre-PAK, and finally the AK value is computed from PAK. 6.1.2 Some calculation details EIK-RSA | PAK = Dot16KDF(pre-PAK, SSID | "EIK+PAK", 288) AK = Dot16KDF (PAK, SS-MAC-Address | BSID | PAK | "AK", 160) 6.2 Single PKMv2-EAP operation 6.2.1 Overview A single EAP session is performed between SS and BS. At the end of a successful authentication an MSK key is calculated, from which is deduced the AK value. The last PKM packet, which transports the EAP-Success notification, includes an AK-SN index associated to the calculated AK. 6.2.2 Some calculation details AK = Dot16KDF(PMK, SS-MAC-Address | BSID | "AK", 160) 6.3 Single PKMv2-RSA and single PKMv2-EAP operation. 6.3.1 Overview The SS forwards its X509 certificate to the BS. Urien Informational Expires June 2008 9 Security API for the IEEE 802.16 Security Sublayer December 2007 The BS sends a pre-AK key encrypted with the SS public key, and associated to an AK-SN index. The SS decrypts the Pre-PAK value with its private key, and computes two keys EIK-RSA(Pre-PAK) and PAK(Pre-AK). Thereafter, the EAP session is performed, from which the MSK key is computed. The final AK value is deduced from PAK and MSK. 6.3.2 Some calculations details EIK-RSA | PAK = Dot16KDF(pre-PAK, SSID | "EIK+PAK", 288) EIK-EAP | PMK = truncate (MSK,320) AK = Dot16KDF (PAK|PMK, SS-MAC-Address| BSID | PAK | "AK", 160) 6.4 Double PKMv2-EAP session 6.4.1 Overview Two EAP sessions are performed from which are computed two MSK keys (MSK1 and MSK2). The AK value is calculated from these two values and associated to an AK-SN index, found in the PKM message transporting the EAP- Success notification. 6.4.2 Some calculation details EIK-EAP | PMK = truncate (MSK,320) PMK2 = Truncate(MSK2,160) AK= Dot16KDF(PMK|PMK2,SS-MAC-Address|BSID|PAK|"AK",160) 6.5 The SA-TEK 3-way Handshake 6.5.1 Overview This procedure is used for fast handover purposes, and pushes a set of cryptographic keys from base station to subscriber station in only three ways. An AK key is computed both by the BS and the SS, details of this calculation are not specified by the IEEE-802.16e-2005 standard. This AK value is identified by an AKID identifier and an AK-SN index. Urien Informational Expires June 2008 10 Security API for the IEEE 802.16 Security Sublayer December 2007 Messages exchanged during this handshake are authenticated by HMAC [RFC 2104] or CMAC [RFC 4493] keyed digest, whose keys are deduced from the secret AK value. 6.5.2 Some calculation details AKID = Dot16KDF(AK, AK-SN | SS-MAC-Address | BSID | "AK", 64) 6.6 Broadband Services 6.6.1 Overview The MTK key is computed from a secret value MAK and a group traffic encryption key called the MGTEK 6.6.3 Some calculation details MTK = Dot16KDF(MAK, MGTEK| "MTK" , 128) 6.7 HMAC and CMAC keys CMAC-KEY-U | CMAC-KEY-D | KEK = Dot16KDF(AK, SS-MAC-Address | BSID | "CMAC-KEYS+KEK", 384) CMAC-KEY-GD = Dot16KDF(GKEK, "GROUP-CMAC-KEY",128) CMAC-KEY-U | CMAC-KEY-D = Dot16KDF(EIK,BS-MAC-Address|BSID|"CMAC-KEYS",256) HMAC-KEY-U | HMAC-KEY-D | KEK = Dot16KDF(AK, SS-MAC-Address | BSID | "HMAC-KEYS+KEK", 448) HMAC-KEY-GD = Dot16KDF(GKEK, "GROUP-HMAC-KEY", 160) HMAC-KEY-U | HMAC-KEY-D = Dot16KDF(EIK,BS_MAC-Address|BSID|"HMAC-KEYS",320) Urien Informational Expires June 2008 11 Security API for the IEEE 802.16 Security Sublayer December 2007 7 PKMV2 services 7.1 Basic Services Four services are defined * Get-SS-Certificate () collects the SS certificate * Decrypt-SS-RSA-Priv (Message) decrypts a message with the SS RSA private key. * Process-EAP(packet) processes an EAP request and returns an EAP response * Get-MSK(), returns the MSK 512 bits value, available after the completion of a successful EAP session. Get-SS-Certificate() Process-EAP(packet) | | | Decrypt-SS-RSA-Priv(Message) | Get-MSK() | | | | +-V--V---------------+--------------------+-V---V-----------------+ | RSA based Authen- | Authorization / SA | EAP encapsulation | | –tication (RSA-OP) | Control (SA-CNTL) | decapsulation (EAP-OP)| +--------------------+--------------------+-----------------------+ | PKM Control Management (PKM-CM) | +---------------------------------+-------------------------------+ | Traffic Data | Control Message Processing | | Encryption/Authentication | (PKM-CMP) | | Processing | +------------------------+ | | + Message Authentication | | (TDEAP) +------+------+ Processing (PKM-MAP)| +--------------------------+ PHY SAP +------------------------+ +------+------+ PKMv2 Basic Services Urien Informational Expires June 2008 12 Security API for the IEEE 802.16 Security Sublayer December 2007 7.2 Extended Services 7.2.1 Data Management In order to compute various keys, the tamper resistant device needs to collect some information. Four parameters are required, * Set-Mode(mode), resets the tamper resistant device and gives the current mode of operation , a choice among four alternatives (single PKMv2-RSA, single PKMv2-EAP, single PKMv2-RSA and single PKMv2-EAP, double PKMv2-EAP session. * Set-SS-MAC-Address(), gives the SS MAC address * Set-Current-BSID(), gives the current BS identifier. * Set-Current-AK-SN(), gives the current AK key sequence number 7.2.2 PKMv2-RSA facilities When PKMv2-RSA operations are used five services are provided * Get-SS-Certificate () collects the SS certificate * Decrypt-SS-RSA-Priv (Message) decrypts a message with the SS RSA private key. * Sign-SS-RSA-Priv(Message) encrypts a message with the SS RSA private key * Compute-Pre-PAK(value) decrypts the Pre-PAK value with the SS private key, the PAK value is calculated and securely stored in the tamper resistant device. * Set-Pre-PAK(value), the security sublayer exclusively manages the PKMv2-RSA protocol and provides this value to the tamper resistant device. Thereafter the PAK value is calculated and stored in the tamper resistant device. 7.2.3 PKMv2-EAP facilities * Process-EAP-first-session (packet), processes an EAP request belonging to a first EAP session and returns an EAP response * Process-EAP-second-session (packet), processes an EAP request belonging to a second EAP session and returns an EAP response 7.2.4 SA-TEK 3-way Handshake facilities Urien Informational Expires June 2008 13 Security API for the IEEE 802.16 Security Sublayer December 2007 * Get-AKID(AK-SN, list of parameters), computes an AK value (associated to the AK-SN index) from a list of parameters (that may be empty) and returns the AKID value. 7.2.5 Broadband facilities * Compute-MTK(MGTEK), computes the MTK value from the MGTEK parameter 7.2.6 Keys facilities All keys are identified by an AK-SN index * Get-KEK(AK-SN), returns value of the KEK key * Get-HMAC-U(AK-SN), returns the value of the HMAC-U key * Get-HMAC-D(AK-SN), returns the value of the HMAC-D key * Get-CMAC-U(AK-SN), returns the value of the CMAC-U key * Get-CMAC-D(AK-SN), returns the value of the CMAC-D key * Get-EIK-RSA(AK-SN), returns the value of the EIK key deduced from a previous PKMv2-RSA operation. * Get-EIK-EAP(AK-SN), returns the value of the EIK key deduced from a previous EAP session. Urien Informational Expires June 2008 14 Security API for the IEEE 802.16 Security Sublayer December 2007 +-> Set-Mode(mode) | +--> Set-SS-MAC-Address() | +---> Set-Current-BSID() | +----> Set-Current-AK-SN() | +-----> Compute-MTK(MGTEK) | +------> Get-AKID(AK-SN, list of parameters) | +-------> Get-KEK(AK-SN) | +--------> Get-HMAC-U(AK-SN) | +---------> Get-HMAC-D(AK-SN) | +----------> Get-CMAC-U(AK-SN) | +-----------> Get-CMAC-D(AK-SN) | +------------> Get-EIK-RSA(AK-SN) | +-------------> Get-EIK-EAP(AK-SN) | | Get-SS-Certificate() | | | | Decrypt-SS-RSA-Priv(Message) | | | | | | Sign-SS-RSA-Priv(Message) | | | | | | | | Compute-Pre-PAK(value) Process-EAP-second-session() | | | | | | | | | | | Set-Pre-PAK(value) Process-EAP-first-session() | | | | | | | | | | +-V-V-V-V-V--------+------------------+-V-------------------V-+ | |RSA based Authen- |Authorization / SA| EAP encapsulation | | |-tication (RSA-OP)|Control (SA-CNTL) | decapsulation (EAP-OP)| +-V-+------------------+------------------+-----------------------+ | PKM Control Management (PKM-CM) | +---------------------------------+-------------------------------+ | Traffic Data | Control Message Processing | | Encryption/Authentication | (PKM-CMP) | | Processing | +------------------------+ | | + Message Authentication | | (TDEAP) +------+------+ Processing (PKM-MAP)| +--------------------------+ PHY SAP +------------------------+ +------+------+ Urien Informational Expires June 2008 15 Security API for the IEEE 802.16 Security Sublayer December 2007 8 References [PKCS1] "PKCS #1: RSA Encryption Standard", RSA Laboratories. [RFC 2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC 4017] D. Stanley, J. Walker, B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", March 2005. [RFC 4137] J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP)Peer and Authenticator", August 2005 [RFC 3748] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson Sun, H. Levkowetz, "Extensible Authentication Protocol (EAP)" RFC 3748, June 2004 {RFC 4493] JH. Song, R. Poovendran, J. Lee, T. Iwata, "The AES-CMAC Algorithm", RFC 3748, June 2006 [EAP-KEY] Bernard Aboba, Dan Simon, P. Eronen, H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-14.txt, June 2006 [EAP-EXT] Bernard Aboba, "Extensible Authentication Protocol (EAP) Key Management Extensions", draft-aboba-eap-keying-extens-00.txt, April 2005 [IEEE 802.16-2004] IEEE Standard for Local and metropolitan area networks. Part 16: Air Interface for Fixed Broadband Wireless Access Systems - 2004 [IEEE 802.16e] IEEE Standard for Local and metropolitan area networks. - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems - Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1, February 2006 9 Authors's and contributors' addresses Pascal Urien ENST 37/39 rue Dareau 75014 Paris Phone: NA France Email: Pascal.Urien@enst.fr Urien Informational Expires June 2008 16 Security API for the IEEE 802.16 Security Sublayer December 2007 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urien Informational Expires June 2008 17