Internet Draft Pascal Urien Document: draft-urien-16ng-security-api-00.txt Expires: December 2007 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 December, 2007. 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 December 2007 1 Security API for the IEEE 802.16 Security Sublayer June 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 6 PKMv2 protocol...................................................9 6.1 Single PKMv2-RSA operation..................................9 6.2 Single PKMv2-EAP operation..................................9 6.3 Single PKMv2-RSA and single PKMv2-EAP operation.............9 6.4 Double PKMv2-EAP session....................................9 6.5 The SA-TEK 3-way Handshake.................................10 6.6 Broadband Services.........................................10 7 PKMV2 services..................................................11 7.1 Basic Services.............................................11 7.2 Extended Services..........................................12 7.2.1 Data Management.......................................12 7.2.2 PKMv2-RSA facilities..................................12 7.2.3 PKMv2-EAP facilities..................................12 7.2.4 SA-TEK 3-way Handshake facilities.....................12 7.2.5 Broadband facilities..................................13 7.2.6 Keys facilities.......................................13 8 References......................................................15 9 Authors's and contributors' addresses...........................15 Intellectual Property Statement...................................16 Disclaimer of Validity............................................16 Copyright Statement...............................................16 Acknowledgment....................................................16 Urien Informational Expires December 2007 2 Security API for the IEEE 802.16 Security Sublayer June 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 securing 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 December 2007 3 Security API for the IEEE 802.16 Security Sublayer June 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 December 2007 4 Security API for the IEEE 802.16 Security Sublayer June 2007 2.2 Security APIs for the security sublayer Security APIs aims 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 December 2007 5 Security API for the IEEE 802.16 Security Sublayer June 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 December 2007 6 Security API for the IEEE 802.16 Security Sublayer June 2007 5 PKMv1 Services 5.1 Basic Services Two services are defined * Get-SS-Certificate () collects the SS certificate * Compute-SS-RSA-Priv (Message) decrypts a message with the SS RSA private key. Get-SS-Certificate() | | | Compute-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 December 2007 7 Security API for the IEEE 802.16 Security Sublayer June 2007 5.2 Extended 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 Urien Informational Expires December 2007 8 Security API for the IEEE 802.16 Security Sublayer June 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 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.2 Single PKMv2-EAP operation 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.3 Single PKMv2-RSA and single PKMv2-EAP operation. The SS forwards its X509 certificate to the BS. 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.4 Double PKMv2-EAP session Two EAP sessions are performed from which are computed two MSK keys (MSK1 and MSK2). Urien Informational Expires December 2007 9 Security API for the IEEE 802.16 Security Sublayer June 2007 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.5 The SA-TEK 3-way Handshake 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. 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.6 Broadband Services The MTK key is computed from a secret value MAK and a group traffic encryption key called the MGTEK Urien Informational Expires December 2007 10 Security API for the IEEE 802.16 Security Sublayer June 2007 7 PKMV2 services 7.1 Basic Services Four services are defined * Get-SS-Certificate () collects the SS certificate * Compute-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) | | | Compute-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 December 2007 11 Security API for the IEEE 802.16 Security Sublayer June 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 four services are provided * Get-SS-Certificate () collects the SS certificate * Compute-SS-RSA-Priv (Message) decrypts 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 * 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. Urien Informational Expires December 2007 12 Security API for the IEEE 802.16 Security Sublayer June 2007 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 December 2007 13 Security API for the IEEE 802.16 Security Sublayer June 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() | | | | Compute-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-+ | |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 December 2007 14 Security API for the IEEE 802.16 Security Sublayer June 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 December 2007 15 Security API for the IEEE 802.16 Security Sublayer June 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 December 2007 16