CNS - 33 - IPsec II

Lecture Info

  • Date: [2020-12-07 lun 14:00]

  • Lecturer: Marco Bonola

  • Slides: (30_ipsec_MB.pdf)

  • Introduction: In the last lecture we introduced the basic concept behind IPsec such as Security Associations (SAs) and Security Policies (SPs). Today we will take a lot at IPsec security protocols such as AH/ESP and at the IKE.

1 Ipsec Security Protocols

The basic security protocols are:

  • Authentication Header (AH): This protocol offers only integrity and data origin authentication. This authentication layer covers both the payload and parts of the IP header. It also protects against replay attacks, through an optional extended sequence numbers field.

  • Encapsulated Security Payload (ESP): This protocol provides the same services as AH, although the authentication is only limited to the IP payload. It also provides confidentiality through encryption, and it provides traffic flow confidentiality.

1.1 AH

The header structure of AH is the following

If we are working in transport mode, inside the IP header we have protocol number \(51\). The AH header is then described:

  • Next Header: describes what is the protocol of the payload of AH. The value of this fields depend on the particular mode of operation. If we are working with tunnel mode, the next header is another IP header, while if we working with transport mode, the next header is a transport level layer.

  • AH Payload Length: Length of the payload.

1.1.1 Tunnel/Transport mode

Remember that IPsec can work in two different modes of operation. When us ing AH the following things are worth remembering

  • Transport mode:

  • Tunnel mode:

1.1.2 Integrity check computation

In the Integrity Check Value (ICV) we put the message code authentication for the packet.

Notice that we cannot put in the auth code all the fields of the IP packet, because some of them are mutable, meaning that they can be modified during the path from the source to the destination. During the MAC computation the mutable fields are set to 0.

The authentication algorithms used are specified in RFC 4835. Some further detail:

  • HMAC-SHA-1-96, meaning the first 96 bits of standard HMAC-SHA-1 must be supported.

  • AES-XCBC-MAC-96, should+ support.

  • HMAC-MD5-96, may support.

  • HMAC-SHA-256/384/512, may support.

Whathever algorithm you choose, the ICV value must be a multiple of \(32\) bits. The sender can also add padding to line up with the required number of bits.

1.1.3 Sequence numbers

Since we don't have a sequence number inside the IP header, it is possible to replay an ipsec packet. We thus have to add an explicit sequence number inside the ipsec packet.

The sequence number field is a \(32\) bit value. The standard says that if you turn this feature on, you have to rekey the security association when you reach the maximum number for this field. Notice that even though \(2^23\) bytes seems a lot, given a packet size of \(1500\) bytes (\(1460\) bytes payload), then given a \(1\) gbps link we reach the maximum in about \(14\) hours of transmission.

There is thus an optional feature called extended sequence number that increases the size of sequence numbers from \(32\) bits to \(64\) bits. This does not create overhead problems becuse in the packet only the lower \(32\) bits of the generated \(64\) counter are inserted.

The anti-replay mechanism works as follows: every node keeps a sliding window \(w\) that is updated everytime you receive a packet. A given window defines a maximum sequence number and a minimum sequence number. Once a window is fixed, if you receive a sequence number that does not fid the window you discard it, else you accept it.

1.2 ESP

The header structure of ESP is the following

1.2.1 Tunnel/Transport mode

Once again, ESP works diffently depending on whether or not we are working in tunnel mode or transport mode.

  • Transport mode:

  • Tunnel mode:

Notice that ESP only authenticates the payload and the ESP header and trailer, while the encryption is only applied to the payload and the trailer. Thus with ESP the header is not encryped nor authenticated.

1.2.2 Header and Trailer

The ESP header contains a both the SPI and the SN in a \(8\) bytes value.

The ESP trailer instead contains:

  • Padding of variable size

  • Length of the padding

  • Next header

  • ICV

Notice that we require the addigion of the padding for two different reasons:

  1. Encryption algorithms may require plaintext to be a multiple of some number of bytes.

  2. The resulting ciphertext must terminate on a 4-byte boundary.

1.2.3 Algorithms supported

The authentication is the same as AH and it is specified in RFC

As far as specific algorithms go, we have the following situation:

  • AES-CBC_128 (MUST be supported)

  • 3DES-CBC (MUST be supported)

  • AES-CTR (SHOULD be supported)

  • DES-CBC (SHOULD NOT be supported)

There are also AEAD algorithms that provide both authentication and encyption is a single algorithm.

1.2.4 IP unrealiability

Notice that some good encryption algorithms need to maintain syncrhonization between the different packets. IP packets however may arrive out of order or may be entirely lost.

As a consequence, for some encryption algorithm packets must carry the data needed to resync the deciphering. The idea is to prepend the Initialization Vector (IV) data before the payload data as an "invisible" header.

1.2.5 Traffic flow confidentiality

It has been studied that even if we protect our traffic with encryption we still leave some patterns that may be analyzed through statistical means. One paper that discussed this is Privacy, Vulnerabilities in Encrypted HTTP Streams, by Bissias, Liberatore, Levine.

That is why ESP comes with two counter-measures against traffic analysis attacks:

  • Ability to alter packet size: You can add additional padding to the data. By using the IP/TCP header you can differentiate between the original padding and the added padding.

  • Ability to generate "dummy" packets: You can transform a VBR traffic into CBR.

1.3 IKEv2

We know that if you use IPsec for securing your traffic you must maintain a shared state between the source and the destination of said traffic. This state typically contains the following things:

  • Which security services to use (AH, ESP).

  • Which crypto algorithms to use.

  • Which crypto keys to use.

Manual maintenance is only partially ok for small scale VPNs, it doesn't scale well, and in general its a weak approach since you have an infinite lifetime SA (no rekeying).

To dynamically establish and mainain SAs a different protocol is used, named IKE (Internet Key Exchange protocol). IKE is not in version 2 (september 2010, RFC 5996).

1.3.1 IKE phases

The IKE protocol exchange looks like this:

  • We have a first phase which is in clear. This is used to negotiate the security associations to protect the exchange of the parameters for the SAs that we will install.

  • We then have the IKE_AUTH exchange, in which you authenticate the first packet you have sent in clear.

  • After that the parameters of the so-called CHILD CAs are exchanged. The child CAs are the CAs you want to set on both endpoints.

1.3.2 IKE SAs

In IKE thus we have two types of security associations:

  • IKE SAs: These are the security associations used to exchange IKE messages (control messages).

  • CHILD SAs: These are the security associations used to exchange the data messages. They make use of AH or EPS.

While you have two SAs of type IKE, you can have as many child SAs as you want.

1.3.3 Message format

The IKE messages are encapsulated using UDP and the ports used are 500 and or 4500. This means that to provide a reliable means of communication IKE must implement its own reliable delivery system. For more details see RFC 4306.

An IKE message contains an IKE header followed by one or more IKE payloads.

1.3.4 Header

The IKE header is structured as follows

1.3.5 Version flag

To actually protect against downgrade attacks a bit, called the version flag is used in the header as follows:

  • When the first handshake is made, the first node tells the other what kind of versions he can support. Whenever he wants to use the maximum version he can support, he sets the version flag to \(0\).

  • The receiver then replies by specifying the version he can support. Once again, if he sets the maximum value that he can support, then he sets the version flag to \(0\).

  • After that the original client sends a message with the version flag set to \(1\), since he has agreed on using version \(N-1\), which is not his maximum supported version.

Consider now an attacker that wants to do a downgrade attack. By using the version flag one of the endpoins understand that someone is attacking the communication.

Notice that IKEv1 does not include this flag. Therefore a rollback to IKEv1 is not protected, and this mechanism is useless unless IKEv1 is deprecated from everywhere.

1.3.6 IKE_SA_INIT

In the initial exchange a clear text request is followed by a clear text response. This exchange is based on a diffie-hellman key exchanged.

Both the initiator and the responder send the following things:

  • security parameters for the IKE_SA

  • nonces

  • Diffie-Hellman values

Graphically,

We thus have different payloads:

  • Sai1/Sarl (Security Association) payloads.

  • Kei/KEr (Key Exchange) payloads.

  • Ni/Nr (nonce) payloads.

The output of this phase is the generation of a seed key SKEYSEED, which will then be expanded in order to derive all the keys we need to implement the CHILD SAs. To generate the seed key we use a pseudo random function that is negotiated during the first messages.

\[\text{SKEYSEED} = \text{prf}(Ni, Nr, g^{ir})\]

From that \(7\) keys are generated:

  • \(SK_{ai}, SK_{ar}\) for autehntication at initiator and responder

  • \(SK_{ei}, SK_{er}\) for encryption at initiator and responder

  • \(SK_{pi}, SK_{pr}\) for generating AUTH payloads in SA_AUTH phase.

  • \(SK_{d}\) to derive new keys for the CHILD_SA.

1.3.7 DDoS Attacks

Notice that the DH computation and key generation is a computational expensive process. THe IKE protocol described so far is thus vulnerable to a denial of service attack.

The solution to this problem is done through a cookie-based 4-way INIT handshake. The basic idea is that the initiator sends the first packet, but the responder does not store anything, it only replies with a cookie. Then, the initiator who receives the cookie sends the cookie back, the responder verifies that the cookie is valid, and only then it stores the status.

As long as we use stateless cookies, that is cookies which do not require any state memorization and whose validity may be checked only by looking at the request and the cookie itself this approach works. For example, we might compute the following

\[\text{Cookie} = \langle \text{VersionIDofSecret} \rangle \,\, | \,\, \text{Hash}(\text{Ni} \,\, |\,\, \text{IPi} \,\, | \,\, \text{SPli} \,\, | \langle \text{secret} \rangle)\]

where,

  • Ni, IPi and SPli is the information that is available in the IKE_SA_INIT request (nonce, IP address, SPI)

  • The secret is an information available only at the responder that changes over time in order to avoid build up of cookie dictionaries.

1.3.8 IKE_AUTH

The last phase is the IKE_AUTH phase, in which we authenticate all the previous messages, and if the certificate is exchanged it is also verified that the authentication uses corresponding private key.

1.3.9 CHILD_SA generation

Once we have a protected channel we simply transmit the parameters of the CHILD_SAs.

1.3.10 INFORMATIONAL

Finally, we have another type of packets which are the informational packet, and which are used to report error conditions or configuration messages and things of the sort.

2 Lab #2: IPsec + IKE + PSK

In this laboratory we will set up the topology we had previously used.

This time however we will set up IPsec without explicitly adding the security associations by instead by using the IKE protocol with a pre-shared key. For this end we will use racoon.

2.1 Racoon config 

path pre_shared_key "/root/psk.txt";

# specify the IKE_SAs
remote 2.0.0.2 {
        exchange_mode main;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group modp1024;
	}
}

# specify the CHILD_SAs
sainfo address 10.0.0.0/24 any address 192.168.0.0/24 any {
        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}

3 Lab #3: IPsec + IKE + X.509 Certs

This time instead of a pre-shared key we will use a X.509 cert to authenticate with private/public key.

4 Lab #4: Road Warrior Scenario

In this case we will see how to connect a single VPN client to a VPN GW.