IPsec Protocols: SP & SA (cont.)

Inbound and Outbound Security Associations

Note: there are 2 security associations – one for communicationin each direction (Alice -> Bob, and Bob -> Alice) !

• Security Association Database (SAD)

→ each SA is normally defined by the following parameters in an SAD entry

SAD defines the parameters associated with each SA

IPsec Protocols: SP & SA (cont.)

Security Parameter Index = unique 32-bit (4-byte) value selectedby the receiving end of an SA to uniquely identify the SA→ in an SAD entry for an outbound SA, the SPI is used to construct the

packet’s AH or ESP header; in an SAD entry for an inbound SA, theSPI is used to map traffic to the appropriate SA

Sequence Number Counter = a 32-bit (4-byte) value used togenerate the Sequence Number field in AH or ESP header

Sequence Counter Overflow Flag = a flag indicating whether overflow of the SNC should generate an auditable event andprevent further transmission of packets on this SA

Anti-Replay Window = used to determine whether an inboundAH or ESP packet is a replay (default size 64)

• Security Association Database (SAD)

IPsec Protocols: SP & SA (cont.)

AH Information = specifies authentication algorithms, keys, keylifetimes, and other AH parameters

ESP Information = specifies encryption & authentication algorithm,keys, initialization values, key lifetimes, and other ESP parameters

Lifetime of this Security Association = defines a time interval or bytecount after which an SA must be replaced with a new SA or terminated

IPsec Protocol Mode = defines the mode in which this SA shouldoperate: tunnel or transport

Path MTU = specifies any observed path maximum transmission unit(i.e., max size of a packet that can be transmitted without fragmentation)and aging variables

Normally, in each IPsec module (device) there are two SADs –one for inbound and one for outbound traffic.

info from respective

SP

transport or tunnel

Gateway SPD/SAD ExampleType of traffic

corresponding to this particular

policy

_SA for incoming traf.

SA for outgoing traf.

Host SPD Example – End-to-End IPsec!!!

• The DMZ is protected from both the outside world and the rest of the corporate LAN by firewalls.

• The host is authorized to connect to the server 1.2.4.10 in the DMZ• UDP port 500 is the designated port for IKE. Any traffic from the local host to a remote

host for purposes of an IKE exchange bypasses the IPsec processing.• The other endpoints (other intranet hosts and 1.2.4.10) must have an IPsec policy that

specifies the same protection for the same packets.

In computer security, a DMZ or demilitarized zone (sometimes referred to as a perimeter network or screened subnet) is a physical or logical subnetwork that contains and exposes an organization's external-facing services to an untrusted network, usually a larger network such as the Internet. The purpose of a DMZ is to add an additional layer of security to an organization's local area network (LAN): an external network node can access only what is exposed in the DMZ, while the rest of the organization's network is firewalled. The DMZ functions as a small, isolated network positioned between the Internet and the private network and, if its design is effective, allows the organization extra time to detect and address breaches before they would further penetrate into the internal networks.

1.2.3.101

1.2.4.10

LAN

DMZ1.2.4.0/24

1.2.3.0/24

IPsec Protocols: IKE

• Internet Key Exchange (IKE) widespread deployment of IPsec requires automated means

of establishing and maintaining SAs

IKE is a comprehensive framework (protocol) for automated SA & key management in IPsec

→ it creates new SAs and new keys dynamically as they expire

→ it generates notifications for deleting SAs, rekeying andoperational errors

The IKE messages are sent as UDP payload between two end points.The source and destination UDP ports for IKE protocol are 500 (or 4500).

→ manual establishment of SA is appropriate only when there isa small number of IPsec endpoints

IPsec Protocols: IKE (cont.)

• Internet Key Exchange (IKE) framework designed to manage both inbound & outbound

Security Associations (SAs) & respective key management

IKE is a combination of 3 protocols:→ Internet Security Association & Key Management Protocol (ISAKMP)

→ Oakley key creation protocol

→ Secure Key Exchange Mechanism for Internet (SKEME)

when a peer needs to send an IP packet, it consults SPD to see if there isan SA for that type of traffic, if there is none, IKE is called to establish one

defines the framework for exchange and formatting of IKE messages

based on Diffie-Hellman algorithm with some enhancements

based on public-key authentication during key exchange

theseprotocolsare NOTexplicitly

mentionedin IKEv2

IPsec Protocols: IKE (cont.)

• IKE PhasesThe basic purpose of IKE phase 1 is to authenticate the IPsec peers and to set up a secure channel – IKE SA – which will be used for exchange of IPsec parameters (and ultimately the setup of IPsec SAs).

The purpose of IKE phase 2 is to negotiateIPSec SAs to set up the IPsec tunnel.

The purpose of IPsec tunnel is to allowsecure exchange of data between theIPsec peers. Data is protected using eitherAH or ESP protocol.IPsec virtual channel

IPsec Protocols: IKE (cont.)

IKE is divided into 2 phases→ Phase I: SAs for Phase II are created in a gradual manner – initial messages

are exchanged in plaintext, later messages are authenticated and encrypted withthe keys created from the earlier messages two modes are possible: Main Mode and Aggressive Mode

→ Phase II: SAs for a data exchange protocol, such as IPSec are created one mode is possible: Quick Mode

• IKE Phases (cont.)

Main Mode

creates IKEmanagement

channel

Quick Mode

creates IPsecdata-transfer

channel

https://www.eetimes.com/document.asp?doc_id=1275828#

Why are things so complicated?!?!

http://sparkfirewall.com/ipsec/ipsec.aspx

IPsec Protocols: IKE (cont.)

• IKE & Diffie-Hellman (how to generate symmetric crypto key)IKE determination is a refinement of the DH key exchange algorithm!

• IKE & Diffie-Hellman: Problem 1

IPsec Protocols: IKE (cont.)

DH protocol has some weakness that need to be eliminatedbefore it is suitable as an Internet key exchange!

Clogging / DoS Attack a malicious intruder can send many half-key (gx mod q) messages to Bob,

pretending they are from different sources Bob then needs to: 1) generate his own half-keys, 2) calculate different

responses (gy mod q), and 3) calculate the full-key (gxy mod q) this keeps Bob so busy that he may stop responding to any other message,

i.e., other clients would be denied service

to prevent the clogging/DoS attack, 2 extra messages can be added to theprotocol to force the two parties to send cookies (for more see next slide!)

the initiator sends its own cookie, the responder its own – both cookies arerepeated unchanged, in every following message

if the initiator is a hacker using a bogus IP address, the initiator will notreceive the second message and cannot send the third message!!!

Diffie Hellman with Cookies

IPsec Protocols: IKE (cont.)Through the initial exchange of cookie messages/values,

the responder (later) can quickly verify that the

initiator is trustworthy (e.g., does not use a spoofed IP),

and it is justifiable to ‘invest’ time into calculation of keys …

IPsec Protocols: IKE (cont.)

Cookie generation must satisfy 3 basic requirements

the cookie must depend on the specific parties (i.e., inherent chara-cteristics of their systems, such as IP address and port number)

it must NOT be possible for anyone other then the issuing entity to generate cookies that will subsequently be returned/accepted by that entity→ this implies that the issuing entity will use local secret information in the

generation and subsequent verification of a cookie→ moreover, it must not be possible to deduce this secret information from any

particular cookie

the cookie generation and verification methods must be fast to thwart attacks intended to sabotage processor resources

Recommended method for creating the cookies is to perform a fast hash (e.g., MD5) over the IP source & destination addresses, the UDP source & destination ports, a locally generated secret value and a timestamp.

Replay Attack

the information from one session can be replayed in a future session by amalicious intruder – attacker can listen and replay traffic in ‘one way’

IPsec Protocols: IKE (cont.)

to prevent a replay attack, nonces are added to 3rd and 4th messages topreserve the freshness of the message

without nonces an adversary capable of ‘eavesdropping’ (e.g., an insider) could simply replay the other IKE messages – no proof of freshness

• IKE & Diffie-Hellman: Problem 2

IPsec Protocols: IKE (cont.)

• IKE & Diffie-Hellman: Problem 2

NOTE: cookies could theoretically be repeated,

hence they cannot be used for the purpose of verifying whether this is a replay

(or a fresh) message.

Should I respond to

this or not?!?!

IPsec Protocols: IKE (cont.)

Use of Nonces to Thwart Replay Attacks

https://slideplayer.com/slide/9541747/

Man-in-the-Middle Attack attacker in this case can not only send replayed message to R only,

but to both I and R (‘two way’), and can block their direct communication

IPsec Protocols: IKE (cont.)

thwarting man-in-the-middle is not as simple as the other two attacks …

• IKE & Diffie-Hellman: Problem 3

Man-in-the-Middle Attack (cont.) to defend against MITM attack, the two communicating parties need to be

authenticated to each other and need to ensure that the integrity of themessages is preserved – this can be done by each party showing that itpossesses a secret

IPsec Protocols: IKE (cont.)

in IKE, the secret can be one of the following:→ a pre-shared secret key→ a pre-known encryption/decryption public-key pair - a message encrypted

with the announced public key can be decrypted with the corresponding private key(two possibilities – original and revised)

→ a pre-verified digital signature - a message signed with an entity’s private keycan be verified with this entity’s announced public key

IKE Phase I – Main Mode in Phase I, Main Mode, the initiator and the responder exchange 6 messages

→ in messages 1 & 2, I & R exchange SA parameters and are confident that theother party is genuine by means of cookies, to prevent clogging attack

→ in messages 3 & 4, I & R exchange their D-H half-keys and their nonces toprevent replay attack and prove freshness

→ in messages 5 & 6, I & R exchange their hashes to to authenticate themselves

IPsec Protocols: IKE (cont.)

Phase I, Main Mode: Pre-shared Secret Key Method

SKEYID_e = Secret Key ID _ encryptioncreated using DH

Initiator’s Identity

MAC that contains pre-shared secret between I and RNOTE: to pick the right shared-secret, I provides/confirms its ID

DH half-key

nonce

Cookie (SPI)

Typically the machine’s IP

address

I & R have apre-shared secret key

Phase I, Main Mode: Original Public Key Method

Initiator’s Identity

encrypted MAC

DH half-key

nonce

cookie (SPI)

By using responders public key,

nobody else will be able to ‘make

sense’ of this message and

move forward in communication

/negotiation.

I & R have and trusteach other’s public keys

more or less serves as an acknowledgment that DH key is working

Phase I, Main Mode: Revised Public Key Method I & R have but may nottrust other’s public keys

cookie (SPI)

Initiator’s Identity

DH half-key

nonce

Initiator’s certificate

Certificate carries the

true/verified sender’s public

key – so if it matches the one

that R already has, the I is

authenticated.

Phase I, Main Mode: Digital Signature Method I & R do not have each-other’s public keys

DH key is used to encrypt I’s ID, I’s

certificate (contains verified I’s public

key) and a message encrypted using I’s

private key.