IP/Network

  

 

 

 

Security - IKE

 

IKE stands for Internet Key Exchange. As you may guess from the terminology itself, it is a method that is used for Internet Security. Base framework of IKE is specified in RFC 2409 (IKE), RFC 4306 (IKEv2) and RFC 7296 (IKEv2).

 

This protocol is responsible for negotiating and exchanging the encryption keys that will be used to secure the communication between the two devices. IKE is used to establish the initial connection between two devices and to re-establish the connection if it is broken due to network disruptions or other issues.

 

IKE works by using a combination of several security protocols, including Authentication Header (AH), Encapsulating Security Payload (ESP), and Internet Security Association and Key Management Protocol (ISAKMP). These protocols work together to establish a secure channel between the two devices, authenticate the devices, negotiate the encryption algorithm and keys, and manage the keys during the communication.

 

 

 

 

Two Phases of IKE

 

IKE has two phases as follows : phase 1 of IKE establishes a secure channel for the exchange of IKE messages and negotiates the encryption algorithm and keys, while phase 2 establishes a secure channel for the exchange of data and negotiates the encryption algorithm and keys for protecting the data exchanged between the devices.

 

 

Phase 1: In this phase, the devices establish a secure channel for the exchange of IKE messages. The main goal of this phase is to authenticate the devices and to negotiate the encryption algorithm and keys that will be used to secure the communication. The following steps occur in phase 1:

    a. The devices exchange a series of messages to establish a secure channel, called the IKE Security Association (SA). This channel will be used to exchange further messages during the negotiation process.

    b. The devices authenticate each other using a pre-shared key, a digital certificate, or another authentication method agreed upon during the negotiation.

    c. The devices negotiate the encryption algorithm and keys that will be used to secure the communication. They also negotiate the Diffie-Hellman key exchange algorithm, which is used to establish a shared secret between the devices.

    d. Once the negotiation is complete, the devices have established a secure IKE SA and are ready to proceed to phase 2.

Phase 2: In this phase, the devices establish a secure channel for the exchange of data between the two devices. The main goal of this phase is to negotiate the encryption algorithm and keys that will be used to protect the data exchanged between the devices. The following steps occur in phase 2:

    a. The devices negotiate the encryption algorithm and keys that will be used to protect the data exchanged between them. They also negotiate the protocol for data encryption and integrity, such as ESP (Encapsulating Security Payload) or AH (Authentication Header).

    b. Once the negotiation is complete, the devices have established a secure data channel and are ready to exchange data.

    c. The devices can now communicate securely over the network, using the encryption algorithm and keys that were negotiated during this phase.

 

 

 

Overall Sequence Flow - RFC 2409

 

The primary purpose of RFC 2409 defines the protocol and algorithms for IKE Phase 1. The protocol defined in this specification is called IKEv1.

 

 

IKE : Phase 1 - Main Mode

 

Main Mode provides a secure method for exchanging the authentication and encryption keys used in Phase 1, as well as for negotiating the parameters of the subsequent Phase 2 negotiation.

Acronyms used in the above procedures are as follows.

  • SA stands for Security Association. It is a set of security parameters, such as encryption algorithms, integrity algorithms, and key lifetimes, that are negotiated between the two peers during IKE negotiation.
  • N stands for the nonce value sent by the initiator in the IKE_SA_INIT message. The nonce is a random value used to ensure that each exchange of IKE messages is unique.
  • KE stands for Key Exchange payload. It is used to transport the DH( Diffie-Hellman) public key between the two peers
  • ID stands for Identity. It is a field in IKE messages that is used to identify the initiator or responder of the IKE negotiation. The identity may take different forms, depending on the authentication method being used. For example, the identity may be a username and password, a digital certificate, or a pre-shared key.
  • "i" being used with each Acronym indicates "Initiator" and "r" being used with each Acronym indicates "Responder"

 

 

Followings are descriptions for each step.

    Step 1 : Initiator sends a proposal: The initiator sends a proposal message to the responder, which includes a set of encryption and authentication algorithms and parameters that the initiator is willing to use.

    Step 2 : Responder sends a proposal: The responder sends a proposal message to the initiator, which includes a set of encryption and authentication algorithms and parameters that the responder is willing to use.

    Step 3 : Initiator sends a Diffie-Hellman value: The initiator sends a Diffie-Hellman value to the responder, which is used to generate a shared secret key.

    Step 4 : Responder sends a Diffie-Hellman value and a certificate: The responder sends a Diffie-Hellman value to the initiator, along with a certificate that contains the responder's public key. The certificate is used to authenticate the responder to the initiator.

    Step 5 : Initiator verifies the certificate and generates a shared secret key: The initiator verifies the certificate sent by the responder and uses the Diffie-Hellman value to generate a shared secret key.

    Step 6 : Responder verifies the certificate and generates a shared secret key: The responder verifies the certificate sent by the initiator and uses the Diffie-Hellman value to generate a shared secret key.

 

 

 

IKE : Phase 1 - Aggressive Mode

 

Aggressive Mode provides a faster method for exchanging the authentication and encryption keys used in Phase 1, as well as for negotiating the parameters of the subsequent Phase 2 negotiation. Aggressive Mode is a three-message exchange that occurs between the two devices.

 

Acronyms used in the above procedures are as follows.

  • SA stands for Security Association. It is a set of security parameters, such as encryption algorithms, integrity algorithms, and key lifetimes, that are negotiated between the two peers during IKE negotiation.
  • N stands for the nonce value sent by the initiator in the IKE_SA_INIT message. The nonce is a random value used to ensure that each exchange of IKE messages is unique.
  • KE stands for Key Exchange payload. It is used to transport the DH( Diffie-Hellman) public key between the two peers
  • ID stands for Identity. It is a field in IKE messages that is used to identify the initiator or responder of the IKE negotiation. The identity may take different forms, depending on the authentication method being used. For example, the identity may be a username and password, a digital certificate, or a pre-shared key.
  • "i" being used with each Acronym indicates "Initiator" and "r" being used with each Acronym indicates "Responder"

 

Followings are descriptions for each step.

    Step 1 : Initiator sends a proposal: The initiator sends a proposal message to the responder, which includes a set of encryption and authentication algorithms and parameters that the initiator is willing to use, along with its identity.

    Step 2 : Responder sends a proposal and its identity: The responder sends a proposal message to the initiator, which includes a set of encryption and authentication algorithms and parameters that the responder is willing to use, along with its identity.

    Step 3 : Initiator generates a shared secret key: The initiator generates a shared secret key using its identity, the responder's identity, and the Diffie-Hellman key exchange. The shared secret key is used to protect the subsequent Phase 2 negotiations.

 

 

 

Differences between Main Mode and Aggressive Mode

 

Both modes involve the negotiation and exchange of authentication and encryption keys, as well as the establishment of a secure channel for further communication, but there a several differences between the two modes as highlighted below.

  • Protection against eavesdropping: Main Mode provides better protection against eavesdropping attacks, as it encrypts the identities of the devices during the first two messages. In contrast, Aggressive Mode exchanges the identities in plaintext in the first two messages, which makes it vulnerable to eavesdropping attacks.
  • Negotiation flexibility: Main Mode provides greater flexibility in negotiating Phase 1 parameters, as it allows for multiple proposals to be exchanged between the devices. Aggressive Mode, on the other hand, only allows for a single proposal to be exchanged between the devices.
  • Speed: Aggressive Mode is faster than Main Mode, as it involves fewer messages and requires less computation. However, this speed comes at the expense of security.

Which mode you would use depends on the specific security and performance requirements of the networked devices. Followings are some of the criteria of selecting which one to use. These are not mandatory criteria and are just general guide lines. You would see exceptions in real application that would not fit into these criteria.

  • Site-to-Site VPNs: Main Mode is typically used for site-to-site VPNs, where security is of utmost importance, and there is no need for speed. Site-to-site VPNs are used to connect two or more remote networks over the Internet securely. Main Mode provides greater flexibility in negotiating Phase 1 parameters, and it provides better protection against eavesdropping attacks.
  • Remote Access VPNs: Aggressive Mode is typically used for remote access VPNs, where speed is more important than security. Remote access VPNs are used to allow remote users to connect securely to a corporate network over the Internet. Aggressive Mode involves fewer messages and requires less computation, making it faster than Main Mode.
  • Mobile Networks: Aggressive Mode is useful in mobile networks, where a large number of mobile clients need to quickly establish a secure connection. Mobile clients may have limited resources and may not be able to support the more computationally intensive Main Mode. In addition, mobile clients may already have prior knowledge of the network they are connecting to, making the exchange of identities in plaintext in the first two messages of Aggressive Mode less of a security concern.
  • High-Security Networks: Main Mode is preferred for networks that require the highest levels of security, such as government or military networks. These networks require the highest levels of protection against eavesdropping attacks and require more flexible negotiation of Phase 1 parameters.

 

 

 

Overall Sequence Flow - RFC 4306

 

Following sequence is based on RFC 4306 2.16. Extensible Authentication Protocol Methods. RFC 4306 defines the protocol and algorithms for IKEv2, which improves upon the security and flexibility of IKEv1.

 

 

Acronyms used in the above procedures are as follows.

  • SA stands for Security Association. It is a set of security parameters, such as encryption algorithms, integrity algorithms, and key lifetimes, that are negotiated between the two peers during IKE negotiation.
  • N stands for the nonce value sent by the initiator in the IKE_SA_INIT message. The nonce is a random value used to ensure that each exchange of IKE messages is unique.
  • KE stands for Key Exchange payload. It is used to transport the DH( Diffie-Hellman) public key between the two peers
  • SK stands for the session key. This is the shared secret key generated by the two peers during the DH key exchange process, and is used to protect the subsequent traffic between the two peers.
  • EAP stands for Extensible Authentication Protocol. EAP is used as one of the authentication methods that can be used during the IKE negotiation process. When EAP is used, the peers exchange EAP messages to perform the authentication and key exchange.
  • TS stands for Traffic Selector. It is a set of parameters that define the type of traffic that is allowed to flow through the security association established by IKE. The traffic selector includes the IP address ranges, port numbers, and protocols that are allowed or disallowed.
  • ID stands for Identity. It is a field in IKE messages that is used to identify the initiator or responder of the IKE negotiation. The identity may take different forms, depending on the authentication method being used. For example, the identity may be a username and password, a digital certificate, or a pre-shared key.
  • AUTH stands for Authentication. In IKE, authentication refers to the process of verifying the identity of the IKE peers and establishing the trust between them.
  • "i" being used with each Acronym indicates "Initiator" and "r" being used with each Acronym indicates "Responder"

 

 

Followings are descriptions for each step.

    Step 1 : The initiator sends an IKE_SA_INIT message to the responder, indicating that it wishes to establish a secure connection.

    Step 2 : The responder sends an IKE_SA_INIT reply message back to the initiator, containing a list of supported EAP Methods.

    Step 3 : The initiator selects an EAP Method from the list provided by the responder, and includes this information in its next message.

    Step 4 : The responder sends an EAP Request message to the initiator, indicating that it is ready to begin the authentication process using the selected EAP Method.

    Step 5 : The initiator sends an EAP Response message back to the responder, containing the appropriate authentication information for the selected EAP Method.

    Step 6 : The responder continues to send EAP Request messages to the initiator, as needed, until the authentication process is complete.

    Step 7 : Once the authentication process is complete, the responder sends an IKE_AUTH message to the initiator, containing the result of the EAP authentication process.

    Step 8 : The initiator responds with an IKE_AUTH reply message, and the IKEv2 negotiation process continues as usual, with the exchange of additional messages to establish the secure connection.

 

 

 

Comparision between IKEv1 and IKEv2

 

There are some differences in terms of procedure and use cases as listed below.

  • IKEv2 provides better protection against security threats, such as denial-of-service (DoS) attacks and man-in-the-middle (MitM) attacks, by using stronger cryptographic algorithms and providing improved authentication mechanisms.
  • IKEv2 also provides better support for mobile and wireless networks, such as those used in smartphones and tablets. It allows for faster and more efficient reconnection to the network after a device has been disconnected, and it supports roaming between networks without the need for re-authentication.
  • IKEv2 provides improved flexibility and extensibility over IKEv1. It allows for more fine-grained control over the negotiation of cryptographic parameters, and it provides a framework for the negotiation and implementation of additional security features and protocols.

 

 

 

Overall  Sequence Flow - 3GPP 33.402

 

If you are interested in 3GPP based device (e.g, LTE UE) trying to get access to the core network through WiFi, you may need to focus on this document (3GPP 33.402). However this doesn't mean that you don't have to refer to RFC anymore. RFC is still base framework for this 3GPP document. 3GPP 33.402 is based on RFC 4306 (IKEv2) in terms of overall sequence and in terms of packet structure and negotiation sequence it is based on RFC 2408 (ISAKMP).

 

 

< Key Exchange Algorithm : IKE >

 

Overall key exchanging protocol sequence in 33.402 is as shown below. (This is from Figure 8.2.2-1)

 

 

 

Following is Wireshark log capturing the transaction between UE and ePDG. In this log, AAA and HSS side log is not captured. I put the step number of 3GPP procedure on the right end of Wireshark log.

 

 

If you managed to decode the whole ISAKMP packet including the Encrypted Payload part, you will see the wireshark log as shown below.

 

There are a couple of important point where both Initiator and Respondor aquire a complete information to encode/decode the traffic as shown below.

 

 

Now let's look into the detailed contents/procedure of each steps.

 

Step 1 :  SA Establish ----------------------------------------------------------------------------------------------

 

This step corresponds to Step 1~2 of RFC 4306.

 

In this step, UE and ePDG performs roughly following task. (These tasks are not performed by each separate steps, they are all performed in a signal back-and-forth. You will notice how these are performed if you see the detailed contents of ISAKMP packet that will be shown shortly)

  • Negotiate Cryptographic Algorithm  
  • Exchange Nonces
  • Perform a Diffie_Hellman exchange

 

Actually Step 1 is made up of two sub steps as follows :

    Step 1a : UE --> ePDG : IKE SA INIT

    Step 1b : UE <-- ePDG : IKE SA INIT

 

In this step,

  • Step 1a : UE notifies ePDG "Hey, I want to communicate with you and for the safe/secure communication, here goes the information /my capability for Security Association. (e.g, Key, Nonce, Hash Algorithm, Encryption Algorithm etc)
  • Step 1b : ePDG tells UE "OK, I allows you to communicate with me.. for Safe/Secure communication, I want you to use this and this information and algorithm(e.g, Key, Nonce, Hash Algorithm, Encryption Algorithm etc)

Since this step is mainly for information exchange before Security is established, information/data carried by this step is not encrypted.

 

In terms of contents of the message, I think this step carries the most complicated data structure (ISAKMP format). One example of ISAKMP carried at Step 1a is as follows.

 

 

If you have wireshark log, you can easily look into the details of the data structure.. but to let you more familiar with format structure described in RFC 2408, I represented the data as follows. It is very complicated structure and of course you don't have to memorize this structure and value. Just look through the overall structure from the top to bottom and see what are main information/data being carried at this step.

 

 

 

Step 2~6 :  Auth request/response for AAA----------------------------------------------------------------------------

 

This step corresponds to Step 3~4 of RFC 4306.

 

At step 2,

    UE sends following ID.

    • IDi = user ID (in the format of of NAI, 3GPP 23.003 19.3)
    • IDr = APN Information

    UE begins negotiation of child security association

    UE shall send configuration payload (CFG_REQUEST) to abtain IPv4 and/or IPv6 home IP address and/or Home Agent Address

      Following is one example of CFG_REQUEST from RFC 4306 2.19.  Requesting an Internal Address on a Remote Network

       

        CP(CFG_REQUEST)=

          INTERNAL_ADDRESS(0.0.0.0)

          INTERNAL_NETMASK(0.0.0.0)

          INTERNAL_DNS(0.0.0.0)

        TSi = (0, 0-65535,0.0.0.0-255.255.255.255)

        TSr = (0, 0-65535,0.0.0.0-255.255.255.255)

         

        Note : format of TSi, TSr is (protocol, port range, address range)

       

      Following is one example of Wireshark log for this step.

       

       

       

       

       

       

At step 3,

    ePDG take out the information from the information (e.g, User ID, APN Info) at step 2 and send it to AAA Server

    AAA Server identity the user

    combined authentication and authorization is performed for tunnel establishment with ePDG.

 

At step 4,

    AAA Server

    • fetch the user profile and authentication vector from HSS/HLR if these parameters are not avaialable in the AAA server
    • look up the IMSI of the authenticated user based on the recieved user ID (root NAI)

    HSS

    • generate authentication vectors with AMF sepration bit = 0 and send them back to AAA Server

    AAA Server

    • checks if the UE is authorized for non-3GPP access

 

At Step 5,

    AAA Server initiate the authentication challenge. In this case, user identity is not requested.

 

At Step 6,

    ePDG send the response to UE with ePDG identity, certificate and send AUTH parameter to protect the previous message in IKE_SA_INIT exchange.

    EAP message (EAP Request/Ack Challenge) received from AAA Server is also included in this response in order to start the EAP proecedure over IKEv2.

     

     

     

     

     

     

 

Step 7~11 :  Auth request/response for RES/XRES Verification --------------------------------------------------------

 

This step corresponds to Step 5~6 of RFC 4306.

 

At Step 7,

    UE checks the authentication parameters and responds to the authentication challenge. (The only payload in this IKEv2 message is the EAP message)

     

     

     

At Step 8,

    ePDG forward the EAP-Response/AKA-Challenge message to AAA Server

 

At Step 9,

    AAA Server sends the final Authentication and Authorization answer to ePDG with the MSK (key material)

 

At Step 10,

    ePDG generate AUTH parameter using the MSK from AAA Server in order to authenticate the IKE_SA_INIT phase messages (These two messages had not been authenticated up to this point since there was no key material available yet.

 

At Step 11,

    ePDG forwards EAP Success/Failure message to the UE

     

 

Step 12~15 :  Auth request/response for AUTH Verification -----------------------------------------------------------

 

This step corresponds to Step 7~8 of RFC 4306.

 

At Step 12,

    UE generate AUTH parameter using its own copy of MSK in order to authenticate the first IKE_SA_INIT message and this AUTH is sent to ePDG

     

 

At Step 13,

    ePDG checks if the AUTH from UE is correct or not.

 

At Step 14,

    ePDG calculate the AUTH parameter to authenticate the second IKE_SA_INIT message.

     

 

At Step 15,

    ePDG send

    • AUTH Parameter calculated at step 14
    • the assigned Remote IP address in the configuration payload (CFG_REPLY)
    • Security Associations
    • the rest of the IKEv2 parameters

      Following is one example of CFG_REPLY from RFC 4306 2.19.  Requesting an Internal Address on a Remote Network

       

        CP(CFG_REPLY)=

          INTERNAL_ADDRESS(192.0.2.202)

          INTERNAL_NETMASK(255.255.255.0)

          INTERNAL_SUBNET(192.0.2.0/255.255.255.0)

        TSi = (0, 0-65535,192.0.2.202-192.0.2.202)

        TSr = (0, 0-65535,192.0.2.0-192.0.2.255)

         

        Note : format of TSi, TSr is (protocol, port range, address range)

         

     

     

     

     

 

 

IKEv2 Parameter Details

 

If you are interested in the full details of the each of the parameters getting involved in IKEv2 process, refer to RFC7296. I will summarize on some of the important parameters later.

 

 

Deleting a SA

 

    RFC 5996

    1.4.  The INFORMATIONAL Exchange

    1.4.1.  Deleting an SA with INFORMATIONAL Exchanges

    Similar to ESP and AH SAs, IKE SAs are also deleted by sending an Informational exchange.

    Deleting an IKE SA implicitly closes any remaining Child SAs negotiated under it.

    The response to a request that deletes the IKE SA is an empty INFORMATIONAL

     

Example >

    i) A party send Informational Request (A) with a specific message ID (B) with Delete (C) payload.

    ii) The other party send Informational Response (D) with the same message ID (E) with emtpy (F) payload

     

    < sending an Informational request with 'Delete' Payload >

     

    < sending an Informational response with 'empty' Payload >

 

 

DPD (Dead Peer Detection)

 

DPD stands for Dead Peer Detection. You can interpret this in two ways as follows.

    i) A mechanism that can detect a Peer (the other party of communication) that is dead

    ii) A mechanism to check whether a Peer (the other party of communication) is dead or alive.

How can a device or a server can do DPD ?

The method is very simple. It just sends 'INFORMATION' message with empty next payload (Next Payload : NONE) and waits for the same type of INFORMATION message from the other party. If it recieves the response, it consider that the other party is alive. If not, it considers the other party is dead. If it does not get any response for a certain duration, it usually delete the existing SA.

 

 

Notation

 

  • HDR (Header) is an ISAKMP header whose exchange type is the mode. When writen as HDR* it indicates payload encryption.
  • SA (Security Association) is an SA negotiation payload with one or more proposals. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one
  • KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. There is no particular encoding (e.g. a TLV) used for the data of a KE payload.
  • Nx is the nonce payload;
    • x can be: i or r for the ISAKMP(Internet Security Association and Key Management Protocol) initiator and responder respectively.
  • IDx is the identification payload for "x".
    • x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation; or "ui" or "ur" for the user initiator and responder respectively during phase two.
  • SIG is the signature payload. The data to sign is exchange- specific.
  • CERT is the certificate payload
  • CERTREQ Certificate Request
  • CP Configuration
  • EAP Extensible Authentication
  • AUTH Authentication
  • TSi Traffic Selector - Initiator
  • TSr Traffic Selector - Responder

 

 

Appendix

 

< ISAKMP Header Format >

 

 

   (Refer to RFC 2408 for details)

 

 

< Security Association (SA) Payload >

 

(Refer to RFC 2408 for details)

 

 

< Key Exchange (KE) Payload >

 

(Refer to RFC 2408 for details)

 

Key Exchange Data (variable length) - Data required to generate a session key.  The interpretation of this data is specified by the DOI and the associated Key Exchange algorithm.  This field may also contain pre-placed key indicators

 

 

< Nonce (N) Payload >

 

(Refer to RFC 2408 for details)

 

Nonce Data (variable length) - Contains the random data generated by the transmitting entity

 

 

< Identification (ID) Payload >

 

(Refer to RFC 2408 for details)

 

DOI Specific ID Data (3 octets) - Contains DOI specific Identification data.  If unused, then this field MUST be set to 0.

 

Identification Data (variable length) - Contains identity information.  The values for this field are DOI-specific and the format is specified by the ID Type field.

 

 

< Proposal Payload >

 

(Refer to RFC 2408 for details)

 

< Transform Payload >

 

(Refer to RFC 2408 for details)

 

< Nonce Payload >

 

(Refer to RFC 2408 for details)

 

< Notify Payload >

 

(Refer to RFC 2408 for details)