**3.1. The EAP-CRA protocol**

With regard to mutual authentication EAP-CRA uses RADIUS servers as suggested in IEEE 802.1x [17]. RADIUS protocol exhibits better performance compared to other mutual authen‐ tication protocols [18]. EAP-CRA offers direct communication between radius servers by prearranged agreement or the servers could find each other dynamically. In case the RADIUS servers do not have a pre-arranged agreement then they can use their CA-signed PKI certifi‐ cates to ascertain trust between servers.

All AAA servers that participate in the EAP-CRA must have some pre-arranged agreement for secure communication. Assuming that all AAA Servers that participate in the EAP-CRA are in possession of their CA-signed PKI certificates, the CRA protocol uses the CA-signed PKI certificates to communicate between the FOREIGN and the HOME AAA servers. However, other options for secure communications such as a virtual private network (VPN) or SSL can also be used. In the protocol details shown in Figure 4, CRA uses the already available CAsigned PKI certificates of the FOREIGN and the HOME AAA servers for secure communica‐ tion. Message 3 is encrypted using the private key of the FOREIGN AAA server (*EKP <sup>F</sup> HostName*, *EKU <sup>H</sup> EMSKname*, *SeqNo*. ) and message 4 is encrypted using the public key of the FOREIGN AAA server (*EKU <sup>F</sup> DSRK* ). However, in Figure 4, we have left the issue of secure communication between the FOREIGN and the HOME AAA server open, to confirm that other options are possible.

According to the EAP-CRA protocol, in response to the EAP-CRA Request Identity message (message 1 in Figure 4), the supplicant sends an EAP Response message with its *Identity* (EMSKname and Sequence number) encrypted with the public key of the HOME AAA server (message 2 in Figure 4) along with the unencrypted host name of the HOME AAA server. EMSKname is used to identify the corresponding EMSK and Sequence Number for Replay protection by the Home AAA server. The authenticator, having received the encrypted *Identity* will pass it to the FOREIGN AAA server as it is. The FOREIGN AAA server uses the fully qualified *Host Name* provided in EAP-CRA Response message to determine the Home AAA server. The FOREIGN AAA server will append its *Domain name* to the received message (EAP-CRA Response) and pass it to the HOME AAA server using the secure method described above (message 3).

**Figure 4.** Coordinated Robust Authentication (CRA) Protocol.

802.1X SUPPLICANT

110 Selected Topics in WiMAX

1. 802.11 Probe Request 2. 802.11 Probe Response 3. Open System Authentication Request 4. Open System Authentication Response 5. 802.11 Association Request 6. 802.11 Association Response

7. EAP Request Identity

8. EAP Response Identity 9. RADIUS

DATA PRIVACY

**Figure 3.** Coordinated authentication message exchange

cates to ascertain trust between servers.

that other options are possible.

**3.1. The EAP-CRA protocol**

13. EAP Success

802.1X AUTHENTICATOR

FOREIGN AAA SERVER

Access Request 10. RADIUS

12. RADIUS Access Accept

Access Accept

With regard to mutual authentication EAP-CRA uses RADIUS servers as suggested in IEEE 802.1x [17]. RADIUS protocol exhibits better performance compared to other mutual authen‐ tication protocols [18]. EAP-CRA offers direct communication between radius servers by prearranged agreement or the servers could find each other dynamically. In case the RADIUS servers do not have a pre-arranged agreement then they can use their CA-signed PKI certifi‐

All AAA servers that participate in the EAP-CRA must have some pre-arranged agreement for secure communication. Assuming that all AAA Servers that participate in the EAP-CRA are in possession of their CA-signed PKI certificates, the CRA protocol uses the CA-signed PKI certificates to communicate between the FOREIGN and the HOME AAA servers. However, other options for secure communications such as a virtual private network (VPN) or SSL can also be used. In the protocol details shown in Figure 4, CRA uses the already available CAsigned PKI certificates of the FOREIGN and the HOME AAA servers for secure communica‐ tion. Message 3 is encrypted using the private key of the FOREIGN AAA server (*EKP <sup>F</sup> HostName*, *EKU <sup>H</sup> EMSKname*, *SeqNo*. ) and message 4 is encrypted using the public key of the FOREIGN AAA server (*EKU <sup>F</sup> DSRK* ). However, in Figure 4, we have left the issue of secure communication between the FOREIGN and the HOME AAA server open, to confirm

Access Request 11. RADIUS

HOME AAA SERVER

> The HOME AAA server will then have to do a double decryption to find the identity of the HOME wireless device. If the wireless device is positively identified, the HOME AAA server calculates *DSRK* (Domain Specific Re-authentication key). DRSK is calculated using *Domain Name* as an optional data in the key derivation specified in [15]. HOME AAA server will then send the *DSRK* to the FOREIGN AAA server after encrypting the message using the public key of the FOREIGN AAA server (message 4). This process is illustrated in Figure 5. The FOREIGN AAA server can use its private key to decrypt the received message to discover the *DSRK* and generate *rMSK* (Re-authentication Master Session Key). rMSK is calculated using a sequence number as an optional data specified in [14]. The *rMSK* can then be transferred to the authenticator with the RADIUS Access Accept message (message 5 in Figure 4). Finally the authenticator sends the EAP success message to the wireless device indicating the completion of the CRA authentication and the beginning of the key distribution phase.

> Two sequence numbers, one with HOME AAA server and one with FOREIGN AAA server is maintained for replay protection of EAP-CRA messages. The sequence number maintained by the supplicant and HOME AAA server is initialized to zero on the generation of EMSK. The server sets the expected sequence number to the received sequence number plus one on every

successful Re-authentication request i.e. on generation of DSRK. Similarly the supplicant and the FOREIGN AAA server maintain a sequence number with the generation of rMSK until the supplicant is in the FOREIGN AAA server's domain.

**3.2. Extentions to RADIUS**

previous section.

particular attributes.

**Table 1.** Attributes in a RADIUS packet

1 2 3 4 5 6 7 8 9 1

*3.2.1. EAP-CRA message and process details*

0 0

and received.

EAP-CRA uses RADIUS as the transportation protocol between the Home and Foreign servers. However the RADIUS protocol is a client-server protocol. The RADIUS server, when for‐ warding the authentication packet to another RADIUS server, designates the sender as client. Hence, the foreign server's only responsibility is to fulfill the role of a proxy server and to forward the RADIUS packets to the Home server. EAP-CRA takes advantage of RADIUS communication and encapsulates the EAP-CRA messages inside the RADIUS packets. There are two viable approaches to designing the security methods that were discussed in the

The first approach is to implement the security features inside the attribute field of the RADIUS packet (Table 1). The attribute field of each RADIUS Packet includes at least three fields that enable the RADIUS packet to carry EAP messages or other information for Dial in user. The attribute field can be used to encapsulate EAP-CRA messages inside the RADIUS packet. Extensions to RADIUS protocol so far proposed have been for the purpose of modifying or creating new attributes such as EAP or apple extensions for RADIUS, each of which has

1 2 3 4 5 6 7 8 9 2

EAP-CRA for WiMAX, WLAN and 4G LTE Interoperability

http://dx.doi.org/10.5772/54837

113

0

1 2 3

0

and then respond by a proper RADIUS message to the foreign server.

Type Length Value …

Type 79 is for EAP messages and 92-191 are Unused. If the value is string or text type then the length can be from 1 to 253 octets. Therefore the type value can be between 92 to 191 octets for the EAP method. The type of the value will be string and as with other EAP methods data is encapsulated inside the RADIUS packet. The foreign server can encapsulate the encrypted message inside the RADIUS packet, so that the home server must first decrypt the message

The second approach is to use a dependent VPN over a SSL connection between the two servers prior to RADIUS communication. The RADIUS packets can then be sent in a secure channel. However, EAP-CRA does not use this method because it entails extra network administration. It also creates a connection delay prior to the EAP-CRA message transmission. Also, the use of PKI actually provides a more secure channel by which the EAP-CRA message can be sent

The proposed EAP-CRA packet is depicted in Table 2. The reasons for designing each of the fields are illustrated based on the associated requirements. The fields are transmitted from left to right. The first influencing factor of EAP-CRA is that it is based on the EAP protocol.

**Figure 5.** EAP-CRA on Home Server

On receiving the EAP success message, the peer generates rMSK independently leading to the key distribution phase. The key distribution phase will be similar to that of the RSNA where the supplicant and the authenticator will use the MSK to derive TSK. Once the Temporary Session keys (TSK) are derived normal data communication can commence. In the next section we discuss the server side communication of the CRA authentication mechanism.
