One document matched: draft-urien-16ng-security-api-00.txt
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 | PAFTECH AB 2003-2026 | 2026-04-24 01:11:01 |