Group Key-based AKA Scheme

In this section, we present a group key-based AKA (GK-AKA) scheme addressing the scenario where roaming users with subscribership in a common HN visit a net-work. In our GK-AKA scheme, every MN provides its identity when visiting an SN. Upon reception, the SN examines whether the MN belongs to an active group of which any member has completed full authentication. If not, the SN acquires authentication data for the MN and its associated group from the concerned HN.

This leads MNs of the same group to share the same authentication data including group temporary authentication key (GTK) and other necessary information. To realize, our scheme comprises three procedures: group information setup, authenti-cation data distribution, and mutual authentiauthenti-cation and key agreement, as shall be described in following three subsections.

Table 3.1: The index Table in GK-AKA

Group Group ID Member ID Initial Value Other Information

G1 ID_G1 ID_M1-1 IV_M1-1 ...

ID_M1-2 IV_M1-2 ...

. . . .

ID_M1-n IV_M1-n ...

G2 ID_G2 ID_M2-1 IV_M2-1 ...

... ... ...

3.1.1 Group Information Setup

In our architecture the HN sends to an SN authentication data for a group of MNs, as opposed to sending authentication data for respective MNs. Initially, the HN configures group information of MNs, including an index table and GAK. As shown in Table 3.1, the index table contains fields of group identity, member identity, initial value (IV_i) for each member i, and other information. For the convenience of illustration, we denote the group in the first entry as G1, group in the second entry as G2, and so forth. We let the initial value IV_i be large and unique. Besides, IV_i behaves as a sequence number for synchronization between the MN and the SN.

The HN also assigns each MN an individual key for communication confiden-tiality, and each group a common group key, namely GAK, for authentication pur-pose. The generation and distribution of GAKs along with MNs joining or leaving a group can be managed by the Authentication Center (AuC) within the home net-work [47, 46, 43]. Furthermore, the HN, SNs and MNs contain MAC algorithms for authenticating messages. The inputs for MAC algorithms consist of a secret key and some related information, and outputs generated by MAC algorithms are irreversible. Without loss of generality, we denote MAC algorithms as f⁰, f¹, f², and f³, respectively, for the HN to authenticate an MN, for an MN to authenticate an SN, for an SN to authenticate an MN, and for key generation.

1. ID Req.

Figure 3.1: Authentication data distribution

AUTHSM1-1

Figure 3.2: An MN generating AUTH_G1, verifying MAC_S and generating MAC_G1.

3.1.2 Authentication Data Distribution

We now consider how the HN distributes authentication data for some MNs of the same group migrating to an SN. Let MN_M1-1 be the first MN initiating authentica-tion in the roaming group G1. Furthermore, in what follows a parenthetical term in any message represents some specific information to be conveyed in the payload.

The distribution procedure is shown in Fig. 3.1, where challenge-response messages can be embodied by CHAP [40], in following lines.

1. ID Request: The SN attempts to identify MN_M1-1.

2. ID Response (AUTH_G1): Upon receiving the ID Request message, MN_M1-1 generates AUTH_G1 = (ID_G1 IDM1-1RNM1-1MACM1-1), where ID_G1 denotes the group identity, ID_M1-1 is the station’s identity, RN_M1-1 represents a

ran-5. Auth.Req(AUTHSM1-1)

6.Auth.Res(MACG1)

7.Auth.Ack(Success/Fail) Verify AUTHSM1-1

Compute MK, MACG1

Compute MK

Verify MACG1

M1-1 KM1-1, GAKG1

Generate AUTHSM1-1

KM1-1, GAKG1

1.2 ID Req./Res.

Figure 3.3: Mutual authentication and key agreement

dom number, and MAC_M1-1 = f⁰(K_M1-1, RN_M1-1) for the HN to authenticate MN_M1-1 (see also Fig. 3.2.) Here K_M1-1 is the pre-shared secret key with the HN.

3. Authentication Data Request (AUTH_G1): Since MN_M1-1 is new, the SN with-out knowledge of the MN relays the foregoing message from MN_M1-1 to the HN. The HN shall authenticate the roaming group (G1) which MN_M1-1belongs to.

4. Authentication Data Response (AUTH_H): As shown in Fig. 3.4, the HN ver-ifies the received MAC_M1-1 in AUTH_G1 using K_M1-1 (the pre-shared key with MN_M1-1.) If MN_M1-1 is found authentic, the HN retrieves the corresponding group authentication key GAK_G1 to generate a Group Transient Key GTK_G1

= f³(RN_M1-1 RNH AMF || GAKG1).

Group authentication data sent to the SN contains AUTH_H= (RN_HAMFRNM1-1GTKG1), where RN_H is a newly selected random number by the HN, AMF denotes contents

of the Authentication Management Field, and RN_M1-1is the random number chosen a priori by MN_M1-1. The group information for G1 is piggy-backed in this message.

The SN will keep the received AUTH_H in local storage for future use.

AUTHG1

MAC_M1-1 K_M1-1 RN_M1-1

f⁰

= Yes/No

Generate RNH

RNH AMF

f³

GAKG1

GTK_G1 AUTHH= RNH|| AMF || RNM1-1|| GTKG1

AUTH Generation MN Authentication

Figure 3.4: The HN verifying AUTH_G1 and generating AUTH_H.

3.1.3 Mutual Authentication and Key Agreement

Upon receiving group authentication data, the SN starts on straightway a procedure of mutual authentication and key agreement with MN_M1-1. This procedure is to achieve mutual authentication and to establish the pairwise session key for message encryption between an MN and an SN. As a result of computing different responses of challenge messages with different arguments, both the MN and the SN can identity each other by verifying the correctness of responses. If both sides are successfully authenticated, the session key is generated to protect the traffic between the MN and the SN. This procedure is depicted as Fig. 3.3, starting with Message 5.

5. Authentication Request (AUTH_SM1-1): After acquiring AUTH_H for group G1, the SN initiates the i-th run of mutual authentication with MN_M1-1by generat-ing AUTH_SM1-1= (AMFRNHRNM1-1MACSRNSM1-1), where first three pa-rameters are meant for MN_M1-1to generate GTK_G1, MAC_S= f¹(GTK_G1RN_M1-1 IV_M1-1+i), and RN_SM1-1is a nonce chosen by the SN to challenge MN_M1-1later.

While waiting for the response from MN_M1-1, the SN computes the Master Key MK = f³(GTK _G1IVM1-1+ iRNM1-1RNSM1-1) for subsequent sessions with MN_M1-1 in advance. (See Fig. 3.5.)

6. Authentication Response (MAC_G1): In response to Authentication Request (AUTH_SM1-1), MN_M1-1computes GTK_G1using first three arguments in AUTH_SM1-1

AUTHSM1-1= RNH|| AMF || RNM1-1|| MACS|| RNSM1-1

AUTHH Generate RNSM1-1

RNM1-1 MACG1

IVM1-1 i

+

×

f¹ f² f³

×

= GTKG1

RNSM1-1

MACS MK

Yes/No AUTHG1

AUTH Generation MN Authentication

Figure 3.5: An SN generating AUTH_SM1-1 and MK and verifying MAC_G1. and GAK_G1 stored in each MN of the same group. MN_M1-1 then authenticates the SN by computing and comparing the corresponding result with MAC_S. After successfully authenticating the SN, MN_M1-1 calculates the Master Key MK with respect to the SN and generates a message back to the SN containing MAC_G1 = f²(GTK_G1RN_SM1-1IV_M1-1+ i). Such operations are diagrammed in Fig. 3.2.

7. Authentication Result (Success/Failure): Upon receiving an Authentication Response message carrying MAC_G1, the SN checks whether MN_M1-1 has pro-duced the correct response using operations as in Fig. 3.5. Then a message with a status code indicating either success or failure for mutual authentication is sent to MN_M1-1, whence our key agreement procedure is completed.

After full authentication, both MN_M1-1 and its SN share a common MK that can be employed as the material for subsequent key derivations.

When a second group member, say MN_M1-2, arrives and requests for authentica-tion, the SN simply initiates mutual authentication and key agreement with MN_M1-2 using the existing GTK_G1. In other words, messages 3 and 4 in the prescribed authentication data distribution procedure can be bypassed, leaving out signaling

traffic between SN and HN. In this regard, however, the SN needs to generate a new random number RN_SM1-2 to create a new challenge message for MN_M1-2 (message 5 in Fig. 3.3.) Using distinct arguments from those for MN_M1-1, such as RN_SM1-2, RN_M1-2 and IV_M1-2, our scheme not only assures the freshness of challenge-response messages but also guarantees the uniqueness of MKs for different MNs.

As a remark, the proposed G-AKA scheme reduces messages sent from the HN to the same destination SN repeatedly by providing group authentication data and GTK. The latter is used in place of GAK to prevent the original GAK from being divulged to eavesdroppers. Observe that a GTK allows of periodic updates whenever new random numbers are provided.