**3.2. Extentions to RADIUS**

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

Drop the Packet Is the Foreign Server

Encrypt an Invalid Supplicant Message with Home Private Key

Authenticated ?

Decrypt the message with Foreign Public Key

Decrypt the message with Home Private Key

Check the Supplicant Authenticity

Is the Supplicant Authenticated ?

Generate DSRK and Encrypt with Home Private Key

Encrypt the Result with Foreign Public Key

Encapsulate the CRA packet in RADIUS Packet

Send the message to the Destination

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.

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

supplicant is in the FOREIGN AAA server's domain.

112 Selected Topics in WiMAX

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 previous section.

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 particular attributes.

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

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 and then respond by a proper RADIUS message to the foreign server.

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 and received.
