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.