WiMAX: Technology for Broadband Wireless Access

2017-07-07 02:10:07

15.2 Authentication and the PKM Protocol

The security sublayer of IEEE 802.16 employs an authenticated client/server key management protocol in which the BS, the server, controls the distribution of keying material to the client SS. Security is then based on the PKM (Privacy Key Management) protocol ^[50]. The BS authenticates a client SS during the initial authorisation exchange (see Chapter 11) using digital-certificate-based SS authentication. The PKM protocol uses public key cryptography to establish a shared secret between the SS and the BS. The SS also uses the PKM protocol to support periodic reauthorisation and key refresh.

If during capabilities negotiation (see Section 11.6 for SBC, SS Basic Capability messages exchange) the SS specifies that it does not support IEEE 802.16 security, the authorisation and key exchange procedures in Network Entry process are skipped, i.e. neither key exchange nor data encryption is performed. The standard states that the BS, if provIsioned in this way, considers the SS authenticated; otherwise, the SS is not serviced.

The 802.16e amendment defined PKMv2 with enhanced features. Table 15.3 summarises the main differences between the two PKM versions.

Table 15.3: The main differences between PKMv1 and PKMv2. (Table by L. Nuaymi, M. Boutin and M. Jubin.)
Open table as spreadsheet
Feature	PKMv1	PKMv2
Authentication	RSA-based one-way authentication: the BS authenticates the SS	Mutual authentication. Supports two authentication methods: EAP or RSA
Security Association	One SA family: Unicast. Composed of three types of security associations: primary, dynamic and static	Three SA families: Unicast, Group Security Association and MBS Security Association. Composed of the same three types of security associations as PKMv1
Key encryption	Use of three encryption algorithms: 3-DES, RSA and AES	New encyption method implemented: AES with Key Wrap
Data encryption	Two different algorithms are defined in the standard: DES in the CBC mode, AES in the CCM mode	Use of the same algorithms plus AES in the CTR more and AES in the CBC mode implementation
Other additions	-	Management of security for: broadcast traffic, MBS traffic. Definition of a preauthentication procedure in the case of handover

First 802.16 PKM protocol MAC management messages are described, followed by the use of these messages and X.509 digital certificates for authentication and key material exchange.

15.2.1 PKM Protocol MAC Management Messages

The PKM protocol has two generic MAC management messages in the 802.16 standard:

PKM Request (PKM-REQ). The PKM-REQ message encapsulates one PKM message in its message payload. It is always sent from the SS to the BS.

PKM Response (PKM-RSP). The PKM-RSP message encapsulates one PKM message inits message payload. It is always sent from the BS to the SS.

Both PKM-REQ and PKM-RSP use the primary management connection with the exception that when the BS sends the PKM-RSP message to the SSs for a multicast service or a broaddcast service, it may be carried on the broadcast connection. The general formats of PKMMREQ and PKM-RSP messages are shown in Figures 15.2 and 15.3. Table 15.3

Management Message Type (=9, for PKM-REQ)

Code (8 bits)

PKM identifier (8 bits)

TLV Encoded information

Figure 15.2: PKM-REQ MAC management message format

Management Message Type (=10, for PKM-RSP)

Code (8 bits)

PKM identifier (8 bits)

TLV Encoded information

Figure 15.3: PKM-RSP MAC management message format

Table 15.4 is a synthesis of 802.16 standard PKMv1 MAC management messages parammeters and descriptions. The PKM-REQ and PKM-RSP messages codes added for PKMv2 can be found in Table 26 of Reference ^[2].

Table 15.4: PKM MAC mangement message parameters and descriptions. The Core Code Field in a KM-XXX message indicates its type. (Table by L. Rouill and X. Lagrange at ENST Bretagne.)
Open table as spreadsheet
PKM protocol message type	MAC message (code)	Message Parameter(s)	Description
Authorisation Info	PKM-REQ (12)	X.509 certificate of a manufacturer CA that issued the SS X.509 certificate	The external CA issues these CA certificates to SS manufacturers
Authorisation Request	PKM-REQ (4)	SS X.509 user certificate, requesting SS security capabilities, SS primary SAID	Request of an AK and a list of SA(s)
Authorisation Reply	PKM-RSP(5)	AK, AK lifetime and sequence number, SA Descriptor(s)
Authorisation Reject	PKM-RSP(6)	Error Code	The BS rejects the SS Authorisation Request
Authorisation Invalid	PKM-RSP (10)	Error Code identifying reason for Authorisation Invalid (a possibility as no valid AK associated with the requesting SS)	Instructs the receiving SS to reauthorise its BS
Key Request	PKM-REQ (7)	AK sequence number, SAID, HMAC-Digest (Keyed SHA message digest) for message authentication	Request of a TEK for an established SA
Key Reply	PKM-RSP (8)	All of the keying material corresponding to a particular generation of an SAID TEK.	Carries the two TEKs for the concerned SAID. Encrypted (using 3-DES algorithm) with a KEK
Key Reject	PKM-RSP(9)	AK sequence number, SAID, Error Code, HMAC-Digest for message authentication	Indicates the receiving client SS is no longer authorised for a particular SAID
TEK Invalid	PKM-RSP (11)	AK sequence number, SAID, Error Code, HMAC- Digest for message authentication	Indicates to a client SS that the BS determined that the SS encrypted an uplink PDU with an invalid TEK
SA Add	PKM-RSP (3)	AK, sequence number, SA Descriptor(s), HMAC-Digest for message authentication	Establishes one or more additional SAs

15.2.2 PKMv1: the BS Authenticates the SS and then Provides it with Keying Material

After capability negotiation, the BS authenticates the SS and provides it with key material to enable the ciphering of data. All SSs have factory-installed RSA private/public key pairs or provide an internal algorithm to generate such key pairs dynamically. The SSs with factory-installed RSA key pairs also have factory-installed X.509 certificates. The SSs that rely on internal algorithms to generate an RSA key pair support a mechanism for installing a manufacturer-issued X.509 certificate following key generation.

Thus, each SS has a unique X.509 digital certificate issued by the SS manufacturer ^[1]. The SS X.509 digital certificate contains the SS public key and the SS MAC address. The SS X.509 certificate is a public key certificate that binds the 55 identifying information to its RSA public key in a verifiable manner. The AK is a secret key obtained from the operator. When requesting an AK, an 55 presents its digital certificate to the B5. The SS X.509 certificate is digitally signed by the SS manufacturer and that signature can be verified by a BS that knows the manufacturer's public key.

When requesting an AK (Authorisation Key), an SS presents its X.509 digital certificate and a description of the supported cryptographic algorithms to the BS. The AK is a shared secret used to secure further transactions. The BS verifies the digital certificate, determines the encryption algorithm that should be used and then sends an authentication response to the SS. The verified public key is used to encrypt the AK using the R5A algorithm. The BS then sends this RSA public key encrypted AK to the requesting SS. The procedure of authentication and first key exchange is illustrated in Figure 15.4 and is detailed in the following. The above-described PKM MAC management messages are used for authentication and first key exchange (see the illustration in Figure 15.5).

Figure 15.4: Authentication and Authorisation Key allocation by the BS. The BS is the server and the SS is the client

Figure 15.5: MAC management messages as used for PKM protocol-based authentication and key exchange in the 802.16 standard. Some of the parameters are shown. (Figure by L. Rouillé. X. Lagrange and L. Nuaymi.)

The SS sends a PKM Authorisation Information message. This message contains its mannufacturer's X.509 certificate. The Authorisation Information message is strictly an informative message the SS sends to the BS; with it, a BS may dynamically learn the manufacturer's certificate of the client SS.

Then, the SS sends a PKM Authorisation Request message containing the SS X.509 certificate, the SS primary SAID and a description of its security capability (including the ciphering algorithms it supports). The manufacturer's public key is placed in an X.509 Certification Authority (CA) certificate, which in turn is signed by a higher-level CA. The BS verifies the digital certificate and then uses the verified public key to encrypt an AK. The BS then sends this AK to the requesting SS with a PKM Authorisation Response message. The use of the X.509 certificates prevents cloned SSs from passing fake credentials to a BS. The use of a sequence number prevents the so-called replay attack.

As part of their authorisation exchange, the SS provides the BS with a list of all the cryptographic suites (pairing of data encryption and data authentication algorithms) the SS suppports. The BS selects from this list a single cryptographic suite to employ with the requesting SS's primary SA and sends this information in the Authorisation Reply message. After this procedure, the SS is required to perform the authentication and key exchange procedures periodically in order to refresh its key material.

It was then pointed out that this one-way authentication (the SS does not authenticate the BS) is a security vulnerability as there can be rogue BSs. This problem is solved with PKMv2.

15.2.3 Mutual Authentication as Defined in 802.16e

The PKMv2 protocol uses the same basis as PKMv1. One of the main differences is the authentication: PKMv2 uses mutual authentication; i.e. the MS also authenticates the BS in order to prevent the connection to a ‘false’ BS. The BS and MS mutual authentication is the process of:

the BS authenticating a client's MS identity;

the MS authenticating the BS identity;

the BS providing the authenticated MS with an AK;

the BS providing the authenticated MS with the identities and properties of primary and static SAs.

The key management protocol uses either X.509 digital certificates or EAP for authentication. Therefore, two distinct authentication protocol mechanisms are supported by PKMv2:

RSA authentication. This protocol is based on X.509 certificates.

Extensible Authentication Protocol (EAP) authentication (RFC 3748 ^[39] and RFC 2716 ^[51]). The EAP uses particular kinds of credential (subscriber identity module, password, token-based, X.509 certificate or other) depending on the EAP method implemented. The EAP methods that are to be used are outside the scope of the standard. Yet. the standard ^[2] indicates that the EAP method selected should fulfil the ‘mandatory criteria’ listed in Section 2.2 of RFC 4017 ^[52]. It seems that, for the moment, EAP-TLS ^[51] is the only EAP algorithm that fulfils these criterias.

15.2.4 Authorisation Key (AK) Management

The BS is responsible for maintaining the keying information of all its SAs. The standard indicates that the PKMvl protocol uses public key cryptography to establish a shared secret (i.e. an AK) between the SS and the BS. For the PKMv2 AK generation, see below. The PKM protocol includes a mechanism for synchronising this keying information between a (server) BS and its client SS. This procedure is illustrated in Figure 15.6 and detailed in the following.

Figure 15.6: Authorisation keys management between the BS and an SS

As mentioned above, the BS's first receipt of an Authorisation Request message from an unauthorised SS initiates the activation of a new AK, which the BS sends back to the requesting SS in an Authorisation Reply message. This AK remains active until it expires according to its predefined AK lifetime. This parameter is included in the Authorisation Reply message. If an SS fails to reauthorise before the expiration of its current AK, the BS considers this SS unauthorised and then no longer holds an active AK for it.

The SS is responsible for requesting authorisation with its BS and maintaining an active AK. An SS refreshes its AK by reissuing an Authorisation Request to the BS. An AK transition period begins when the BS receives an Authorisation Request message from an SS and the BS has a single active AK for that SS. In response to this Authorisation Request, the BS activates a second AK and sends it back to the requesting SS in an Authorisaticn Reply message. The BS sets the active lifetime of this second AK to be the remaining lifetime of the first AK, plus the predefined AK lifetime. Thus, the second (newer) key remains active for one AK lifetime beyond the expiration of the first key. Upon achieving authorisation, an SS starts a new encrypted link for each of the SAIDs identified in the Authorisation Reply message. The SS sends a Key Request MAC management message encrypted with the new AK (see Figure 15.6).

Two active keys have overlapping lifetimes. The BS is able to support two simultaneously active AKs for each client SS during an AK transition period. The key transition period ends with the expiration of the older key.

An SS schedules the beginning of reauthorisation based on a configurable duration of time, defined in the standard as the Authorisation Grace Time, before the SS's latest AK is scheduled to expire. The Authorisation Grace Time is configured to provide an SS with an authorisation retry period that is sufficiently long to allow for system delays and provide adequate time for the SS to successfully complete an authorisation exchange before the expiration of its most current AK. The BS does not need to know the Authorisation Grace Time. The BS has only to track the lifetimes of its AKs and deactivate each of them when it expires. An AK is used for the generation of encryption keys used for further exchanges, as described in the following section.

15.2.5 Management of the Authorisation Key in PKMv2

Due to PKMv2 there are two different authentication protocols (RSA-based or EAP-based) and two sources of keying materials: RSA and EAP.

15.2.5.1 RSA-based Authorisation

The RSA-based authorisation process yields the Pre-PAK (Pre-Primary AK) as described above. The Pre-PAK is sent by the BS to the MS encrypted with the public key of the MS certificate. Pre-PAK is used to generate the PAK.

15.2.5.2 EAP-based Authentication

An RSA mutual authorisation may take place before the EAP exchange. In that case, the EAP messages may be protected by an ElK (EAP Integrity Key) derived from the Pre-PAK. The product of the EAP exchange is the MSK (Master Key). The MS and the authenticator derive a PMK by truncating the MSK and an optional ElK.

In order to prevent a man-in-the-middle attack, the MS and the BS must negotiate a double EAP mode (also known as authenticated EAP after EAP) and use the ElK generated during the first round of EAP.

15.2.5.3 AK Derivation

The AK is derived by the BS and the MS using either the PMK (from an EAP-based authoriisation procedure) or the PAK (from an RSA-based authorisation procedure).

^[50]SCTE DSS 00–09, Data over cable service interface specification baseline privacy interface, DOCSIS SP-BPI+-I06–001215, Baseline privacy plus interface specification, December 2000.

^[1]IEEE 802.16-2004, IEEE Standard for Local and Metropolitan Area Networks, Air Interface for Fixed Broadband Wireless Access Systems, October 2004.

^[39]IETF RFC 3748, Extensible Authentication Protocol (EAP), B. Aboba et al., June 2004.

^[51]IETF RFC 2716, PPP EAP TLS Authentication Protocol, B. Aboba and D. Simon, October 1999.

^[52]IETF RFC 4017, Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs, D. Stanley et al., March 2005.