Security Gateway To Security Gateway In Tunnel

Published Date: 02 Nov 2017

Internet Key exchange is the security protocol which uses the IPSec protocol suit to set up a security association using X.509 certificate association. There are number of RFC's which are implemented based on Internet Key Exchange. Pre- shared key are exchanged between the peers and Diffie-Hellman key exchange is used to derive the cryptographic key. The objective of the seminar is to describe the advance feature of IKE that is IKEv2. The IKE consist of two phases and it lacked automatic negotiation and it was really difficult to debug the output. The problems with the IKEv1 was rectified in Version 2. IKEv2 also provide improvements with mobility support, NAT traversal , fewer cryptographic mechanism in increased reliability. The number of RFC's used are significantly reduces in IKEv2. This seminar also explains about the various improvements made by IKEv2, Internet Security Association and Key Management Protocol(ISAKMP) combine with IKE implemented by Microsoft and Cisco which are used in modern windows operating system.

INTRODUCTION

Internet Key Exchange which are originally defined by IETF known as RFC 2407 , RFC 2408 and 2409. Internet Key Exchange which uses the IP Security where the authentication , confidentiality , data integrity and access controls are maintained in all the IP datagram .This is followed from the source till it reaches the destination. Where the protocol follows some set of cryptographic algorithm and some particular key exchange mechanism which is followed before the cryptographic mechanism.

IKE which is known by the series of publication

RFC 2407 - Internet IP security Domain of Interpretation

RFC 2408 - Internet Security Association and Key Management Protocol (ISAKMP)

RFC 2409 - the Internet Key Exchange (IKE)

in which all the above mentioned publication involves the evolution of Internet Key Exchange Algorithm version 1. Internet Key Exchange version 2 which was developed by RFC 4306 and RFC 4718 where both the documents are combined together to form RFC 5996.

IKE performs the mutual authentication between the source and the destination. Where there is a IKE security association that include shared secret information which is established in encapsulation security payload. Generally a IKE communication consists of pair of messages which is a request and response , IKE SA is initialized and authenticated , finally the IKE child messages are created from which the information are exchanged. The request / response initialization consists of a timeout, when the response is not received after the timeout interval either the message is sent again or it is abandoned. IKE session which establishes the security parameter for IKE SA and sends Diffie-Hellman value. Second exchange IKE_AUTH which helps to prove the identities which are used in transmission, where it is used to setup the first AH and ESP child SA. Finally the CREATE_CHILD_SA and INFORMATIONAL are performed.

Seminar Report consists of _ different chapters. The chapter 2 deals with the scenarios in which IKE can be implemented, Chapter 3 deals with the IKE communication mechanism, Chapter 4 explains about the IKEv2 header formats, Chapter 5 Explains about the IKEv2 improvements based on the minimal IKEv2 and the implementation of IKEv2 by an extension for supporting ERP and Chapter 6 explains the conclusion of this seminar.

SCENARIOS

IKE can be implemented in different scenarios and each scenarios has its special requirement.

SCENARIO 1 : SECURITY GATEWAY TO SECURITY GATEWAY IN TUNNEL MODE

IPSec TUNNEL

PROTECTED SUBNET

PROTECTED SUBNET

TUNNEL END POINT

TUNNEL END POINT

Figure 2.1 Security Gateway to Security Gateway in Tunnel Mode

This is the scenario in which neither of the endpoint consists of the secure tunneling mechanism but the network between them is protected with the IPsec tunneling mechanism. The protection is transparent in the endpoint whereas it is well protected between the end points where ordinary routing is used for transmission of packets through the tunnel endpoints for processing. The End points which is it advertises the address behind it. Therefore the inner tunnel address consists of the IP address of the end points[1].

SCENARIO 2 : ENDPOINT-TO-ENDPOINT TRANSPORT MODE

IPSec TRANSPORT OR TUNNEL MODE SA

PROTECTED END POINT

PROTECTED END POINT

Figure 2.2 Endpoint -to-Endpoint Transport Mode

In this scenario both the endpoints are using the IPSec , Whereas the inner network uses either the transport mode or tunneling mode. Single pair of address will be helped to negotiate the packets protected by SA. Although it cannot be implement fully in the IPv4 internet, can be implemented within IKEv1. It can be more broadly implemented on IPv6 which can be implemented by means of IKEv2.

It is possible that the protected network contains a Network Address Translator behind the protected end point, which translates all the address which are in the secure mode. The packets which are in the secure mode has to be address translated by NAT before going out. Therefore the outside network should implement NAT[1].

SCENARIO 3 : ENDPOINT TO SECURITY GATEWAY IN TUNNEL MODE

Protected Subnet

TUNNEL END POINT

IPSec TUNNEL

PROTECTED END POINT

Figure 2.3 Endpoint to Security Gateway Tunnel mode

In this scenario there are both the protected and the non-protected endpoint. This kind of scenario always takes place when there is a corporate network on side of the secure tunnel and the other side consists of the branch network. Therefore if the branch network wants to access some protected data from the corporate network, they will have a access to the corporate network with the secure access.

In this scenario the packets always uses the tunnel mode, each packet consist of source IP address associated with its current location. The inner IP address contains the address of the security gateway which is assigned by the protected network. The outer destination address will also be assigned by the security gateway and the inner destination will be the ultimate destination of the packet. As discussed earlier the protected gateway has the NAT at the endpoint in order to be translated in the protected network and the outside network , therefore the packet will have the UDP encapsulation in ordered to be routed properly[1].

SCENARIO 4 : OTHER SCENARIOS

The other scenarios consists of the combination of all the above scenarios. The subnet may have all the access through the security gateway in protected end point where the IP address are routed to the security gateway by the help of Internet. The other scenario network consists of someone's home network is assigned by the static IP address even though it is produced by the ISP with the dynamic IP address to get connected to the internet by the user's security gateway[1].

IKE COMMUNICATION

IKE communication consists of three different exchanges in order to establish a communication. They are as follows

Initial Exchanges

Create Child Security Association Exchange

Informational Exchange

THE INITIAL EXCHANGE

The initial exchanges consists of exchange of IKE_SA_INIT and IKE_AUTH exchanges. There are four different exchanged which takes place in IKE where it starts with the Request/Reply elements and have a pair of messages known as IKE_SA_INIT takes place which consists of cryptographic algorithm and do a Diffie-Hellman exchange[1]. The second part of the message consists of IKE_AUTH which is used to authenticate the previous message , exchange identity and certificates and establish the first child SA. Therefore by the above two phases it provides the encryption key gets exchanged and the message should be authenticated[5].

THE CREATE_CHILD_SA EXCHANGE

The CREATE_CHILD_SA exchange is used to create new child SAs and IKE SAs. These type of exchange takes place with the request/response principle where these exchanges are also said to be phase 2 exchange in IKEv1. The concept of rekeying takes place in this exchange. Rekeying is the process of creating a new key to the newly created child where the old key is deleted after this process. This exchange consists of the keying payload which request for the key to enable a stronger encryption to forward secrecy[5]. Therefore if KE payload are included in the CREATE_CHILD_SA exchange it also includes the exchange of nonce value and the Diffie-Hellman value. When the sender sends a CREATE_CHILD_SA, the responder check with his Diffe-Hellman value, if he is correct it accepts it or if its incorrect it just rejects it. After the period of timeout the sender retry another CREATE_CHILD_SA with the different Diffie-Hellman value[1].

INFORMATION EXCHANGE

IKE also includes the exchange of control messages which includes about notification of events and error control. The informational exchange should only happen after the initial exchange and the creation of child security association. Therefore it can be exchanged only when they are cryptographically encrypted[1]. Messages in the information exchange contains zero or more payloads. The information message is sent and it requires a response from the responder, whereas if the response is not received the sender will think that the receiver or the message is lost. Therefore even if the information message has nothing in it, it should receive a response.

Totally there are 2 phases which takes place in IKE

PHASE 1

There are 6 messages which are transferred between the source and the destination. Security Association are the messages which are sent and negotiated with the message 1 and message 2. Diffie Hellman exchange are to be done in the message 3 and message 4. The master key SKEYID is established. Finally the digital signature and certificates are exchanged in the message 5 and message 6. They are encrypted with the SKEYID. The two nodes are authenticated to each other.

3)Authenticate

1) Negotiate SA

2) Diffie Hellman Master Key

B

A

Figure 3.1 Phase 1 IKE Exchange

PHASE 2

The phase 2 of the IKE consists of exchange of 3 messages . Using the encrypted packets and protected by the digital signatures, they do another Diffie-Hellman exchange. This generate the secret key, with the help of this secret key the messages are exchanged. The keys are dynamically changed often after some period of time.

2) Diffie Hellman Master Key

2) Session Key

2) Session Key

B

A

3)Message Exchange

1) Authenticate

Figure 3.2 Phase 2 IKE Exchange

IKEv2 HEADER

IKE messages uses two UDP ports 500 and 4500. Generally the UDP packet header are ignored except the IP address and the UDP port on the header which are often used to determine the return path. When the messages are sent on the UDP port 500 the IKE messages follows the UDP header. When the messages are sent on the UDP port 4500, IKE has prepended 4 octet of zero. These octet are not included in the messages. Header is followed by the payload in which each header has a next header field which shows the order of the next payload. Next header field always holds some value if there is a sequence of payload followed by it. If the next header value is zero it means that's the end of the payload[2].

IKE HEADER FORMAT

INITIATOR SPI

RESPONDER SPI

NEXT PAYLOAD

MAJOR VERSION

MINOR VERSION

EXCHANGE TYPE

FLAGS

MESSAGE ID

LENGTH

DATA

Figure 4.1 IKEv2 Header Format[2]

Initiator SPI

It is a 8 byte field in which a value chosen by the initiator to identify the unique IKE security association. This value cannot be equal to zero.

Responder SPI

It is a 8 byte field in which the value chosen is used to identify a unique IKE. This value must be corrected to zero if it is for the initial message and it must not be equal to zero if it is for the rest of the messages.

Next Payload

Next payload is the 8 bit field which indicates the type of payload that is followed by the header. The type number varies from type 0 to type 255.

Major Version

It is the 4 bit field which indicate the major version of IKE to use. Implementation based on the IKEv2 must set this version bit as 2. The implementation based on the previous IKE and ISAKMP must set to version 1.When there is number more than 2 in this field then IKE must describe it as an invalid IKE version number.

Minor version

Minor version is a 4 bit field that indicates the minor version of the IKE protocol. Implementation based on this version must be set to 0 and the version is invalid when it in obtained from the receiver side.

Exchange Type

Exchange type is a 8 bit field , indicates the type of messages which is being used. This constrains the payload in each message and ordering of messages in exchange. The exchange type varies from 0 to 255. The exchange type values of the IKEv2 are as follows

IKE_SA_INIT

34

IKE_AUTH

35

CREATE_CHILD_SA

36

INFORMATIONAL

37

Flags

Indicates the specific option that are set for the messages. The option is indicated by the appropriate bit in the flag field. There are three types of indication available

I, Initiator (1bit) - Indicates the message was sent by the initiator.

V, Version(1bit) - Indicates the sender to implement and show that it uses a higher major number. This bit should be ignored if it is received from the receiver.

R, Response(1bit) - Indicates that this message is the response message for the message containing the same message ID. Therefore this bit can be used only when they respond and they are not used by the sender.

Message ID

Message ID 4 octet in length , in which they are used to identify the message with unique number. Therefore it controls the retransmission of packets which matches the request and response of message. It is greatly used to avoid the replay attack caused by the hacker.

Length

Length is 4 octet unsigned integer which are used to represent the length of the message in octet. The length of the messages include both the header and the payload.

PAYLOAD HEADER

The common form of payload header is defined as generic payload header[1] . The payload header can generally be classified as :

Security Association payload

Key Exchange Payload

Identification Payload

Certification Payload

Certificate Request Payload

Authentication Payload

Nonce Payload

Delete Payload

Vendor ID Payload

Traffic Selector Payload

Encrypted Payload

Configuration Payload

The generic payload has the basic entities of all the above payload.

1 32

NEXT PAYLOAD

C

RESERVED

PAYLOAD LENGTHFigure 4.2 Payload Format

Next Payload

The next payload is a 1 octet field in the payload. This field helps us to provide the information about the next payload. If this current payload is the last payload, then the field is filled with the number 0. This payload helps in providing the chaining capabilities. When it is an encrypted payload , the next payload field is not set to 0 which is a n exception, therefore in the next header the next payload is set up to the payload type of the first contained payload.

Critical

Critical is 1 bit field must be set to 0 if the receiver gets this bit as zero , it means the receiver should skip this payload if it did not understand the next payload field in the previous payload. It is set to 1 if the sender wants to send the payload and receiver didn`t understand the payload type it rejects. It must ignore if the receiver understand the pay load. Skipped payload are to have a valid next payload and payload length fields.

Reserved

Reserved are the 7 bit element which are used to define for further use. It must be sent a zero and ignore by the recipient.

Payload Length

Payload length generally consists of 2 octets and unsigned integer. It includes the length of the payload including the header`s length.

IKEv2 IMPROVEMENTS

IKEv2 provides lot of improvements in the protocol definition, the protocol is being changed according the recent network needs. This document deal with two important improvements which are available in today's network.

MINIMAL IKEv2

The minimal version of IKEv2 which are implemented with the minimum characteristics where IKEv2 include which include several optional feature which are all neglected in this implementation. This minimal IKEv2 can be implemented with the lot of optimization.[3]

Exchanges

The IKEv2 minimal implementation consists of only using first two exchanges called IKE_SA_INIT and IKE_AUTH thus these two are used in creating security Association and Child SA. The minimal implementation of IKEv2 should understand that CREATE_CHILD_SA request so that it can reply to CREATE_CHILD_SA respond saying that NO_ADDITIONAL_SA and it should understand the information request and respond to the information with the empty messages. It shouldn`t respond to any other messages.

The minimal implementation need not have any other request to be sent because it support of being an initiator. Therefore it need not send any other request as IKE_SA_INIT and IKE_AUTH messages. These messages have fixed message ID that is 0 and 1 therefore it need not to keep track of message ID`s of outgoing request[3].

Minimal implementation can also optimize message ID of the incoming request , were they do not need to protect the incoming request with the replays. This procedure is accepted here in the minimal IKEv2 because it allows only the error or empty notification replies to the incoming request. Therefore any the incoming request do not have any implementation regarding the message ID , therefore it is to be performed a check again in which nothing harm takes place. The response can be sent with the same message ID the request came upon therefore the system does not want to remember or store the message ID anywhere because they are independent of the incoming request`s message ID[3].

The minimal implementation only support exactly one set of cryptographic algorithm that is payload will be static , it needs to check with the received matches the proposal it sent.

IKEv2 EXTENSION FOR SUPPORTING ERP

IKEv2 as discussed earlier it allows authentication of initiator using the EAP method. This significantly increases the number of rounds which is established for maintaining the IPSec SA, also it may increases the number of user interaction. Thus causes a inconvenience where a single user is connected to the same domain with the number of IPSec connection.

EAP Re-authentication Protocol (ERP) which helps in authenticating to multiple authenticator, while performing full EAP authentication. This process avoids the multiple establishment of IPSec and also avoids the number of user interaction[4].

Therefore when these two technologies combined together which allows a remote access IPSec client to create multiple tunnel with different gateway that belong to the single domain. Keys are from other context using EAP to have a network with the same domain to transparently connect to VPN gateway within this domain.

Usage Scenarios

1) Multiple tunnels can be really useful when the user is trying to connect to three different geographic location server. It is always efficient to use three different VPN for 3 different location. Normally when they do not implement a different VPN they do connect to the single gateway, the gateway route the request to other gateways and go on, therefore this method is not so efficient than that of client have three different VPN connection. Moreover while establishing 3 different VPN , user are not required to establish connection by enter three times their credential[4].

2) Roaming, it is an important factor to be considered. Nowadays almost all the organisation depends on 802.1x where network connection is established without any medium. Therefore during the wireless connectivity the user or client moves from one place to another , therefore the user is not required to enter the credential whenever they change their access point[4].

Payload Structure

Notify payload is of the following structure

NEXT PAYLOAD

RESERVED

PAYLOAD LENGTH

PROTOCOL ID

SPI SIZE

ERX NOTIFY MESSAGE TYPE

DOMAIN NAME

Figure 5.1 Payload Structure with ERX

Conditions:

1) Protocol ID - Since the message is related to IKE_SA , the protocol ID must be equal to 1 always.

2) SPI SIZE- is always recommend to be zero

3) ERX Notify Message Type- this field must be equal to xxxxx

4) Domain Name(variable) - contains the realm name or domain name.

CONCLUSION

The major changes which are implemented in IKEv2 is the implementation of supporting NAT traversal, Extensible authentication and Remote address acquisition. They replace the initial eight different exchanges with four different exchanges in IKEv2, whereas in the minimal IKEv2 it just has two initial exchanges. IKE's latency is much decreased by making initial exchange by 2 round trips and allowing ability to piggyback setup of child SA. IKEv2 greatly fixes the cryptographic weakness. The protocol is made reliable and sequential significantly reducing the number of possible error states.