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).

 

 

IKE has two phases as follows :

 

\

 

Overall Sequence Flow - RFC 2409

 

 

< IKE : Phase 1 - Main Mode >

 

 

 

< IKE : Phase 1 - Aggressive Mode >

 

 

 

Overall Sequence Flow - RFC 4306

 

Following sequence is based on RFC 4306 2.16. Extensible Authentication Protocol Methods

 

 

 

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).

 

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)