*4.3.1. Security consideration*

RFC-3748 [17] indicates mandatory properties and security constraints of an EAP method such as freshness of session key and resistance against replay, dictionary and man in middle attacks. These features can be used as a reference to analyze the protocol in compliance with the EAP frame work. In this section we present our analysis of our protocol against this criterion.

**Replay attacks**: Generally replay attacks are initiated by re-using captured PDUs. The captured PDUs have authentic ingredients and can be replayed influencing legitimate nodes to respond. The CRA responds to this threat by the use of sequence numbers that enables both the sender and the receiver to have a record of the received datagram. If a packet is out of order it can be dropped. In case of re-authentication the sequence number is generated by the peer. For the rest of the session the peer and the foreign server will increment the value of this sequence number. In the process of full authentication the peer and HAS can benefit from the same procedure to protect against reply attacks.

**Man In The Middle (MitM) attacks**: In this category of attacks a rogue node introduces itself as a legitimate member in the communication. If there is no security mechanism in place the malicious node can continue to remain in between two legitimate nodes and subsequently masquerade as a legitimate node. During the EAP-CRA re-authentication process, MitM attacks are shunned with a Message Authentication Code (MAC). The MAC is simply a hash of the entire message that is attached to the original message. In this situation an attacker needs to have the knowledge of the hash key to revise the message and to re-calculate the hash. In case of full authentication, the use PKI certificate provides immunization against modification of messages.

**Hiding User identification**: The proposed method uses KeyName value as user's id during the full CRA process. This prevents from the real identity being revealed to an outsider. During the full authentication process, just before the EAP-Success message the FAS pass a reauthentication ID to the Peer in a secured message. Therefore when the peer requests for reauthentication there is a new random identifier for the peer.

**Mutual Authentication**:One of the essential features of every EAP method is mutual authen‐ tication. However, at the time of publishing EAP framework, the scope of EAP authentication was limited to peer-to-server authentication and the roaming attribute had not been consid‐ ered. EAP-ERP may satisfy the condition of mutual authentication between Home server and the supplicant, but it is lacking of bilateral proof of identity between the supplicant and a foreign server. More importantly it relies on the security of RADIUS for server-to-server authentication. In contrast, EAP-CRA reaps the advantages of PKI to satisfy this need during the full authentication process.

As both EAP-CRA and EAP-ERP extend the scope of authentication process, the mutual authentication issue can be explored in three areas; between peer and home server, peer and foreign server, and the foreign and home servers. During full EAP-CRA authentication, the proof of possession of MSK (or a key generated from MSK) from the prior EAP authentication process validates the mutual identity between the peer and the home server. The mutual identity between the peer and the foreign server is realized by the foreign server generating a MAC from a key derived from the EMSK which both the foreign server and the peer are in possession. In return the peer also calculates a MAC value to place it inside the final message. This same model is valid for re-authentication phase as well.

Mutual authentication between servers is realized by each server using its private key to encrypt their hostnames. In this view, both servers sign the MSKname to authenticate each other.
