Hash Algorithms Encryption Algorithms - York University€¦ · IPsec Protocols: ISAKMP (cont.) Next Payload = 8-bit field – indicates the type of the first payload in the message

IPsec Protocols: IKE (cont.)

SA Algorithms Used During IKE Phase I & Phase IIDiffie Helman Groups (many more exist)

Hash Algorithms Encryption Algorithms

See: https://community.cisco.com/t5/security-documents/diffie-hellman-groups/ta-p/3147010


Example: RFC 4308 VPN recommendations

https://www.cse.wustl.edu/~jain/cse571-14/ftp/l_20ips.pdf

PseudoRandom Function


Example: Windows Azure VPN IPsec configuration

https://blog.kloud.com.au/2012/07/25/windows-azure-virtual-network-vpn-with-tmg-2010/

• ISAKMP & IKE ISAKMP (Internet Security Association & Key Management Protocol)

is a protocol designed to carry messages for IKE exchange ISAKMP packet encapsulation comprises:

→ IP Header: source & destination IP are IP addresses of initiator’ & responder’sphysical/logical interface

→ UDP Header: IKE uses UDP port 500 to initiate & respond to negotiation→ ISAKMP Header: more on next slides …→ ISAKMP Payload: there may be 1 or more payloads in one ISAKMP packet –

more on next slides …

IPsec Protocols: ISAKMP

IPsec Protocols: ISAKMP (cont.)

→ 28 bytes long, and contains information that is required by theprotocol to maintain the sate, process payloads, and possiblyprevent DoS and replay attacks - its subfields include:

ISAKMP General Header

Initiator SPI (Security Parameter Index) - previously called ‘cookie’ = 64-bit value randomly-generated by the initiator to identify a unique IKE security association

Responder SPI = 64-bit value randomly generated by the responderto identify a unique IKE SA


Next Payload = 8-bit field – indicates the type of the first payload inthe message

Major Version = 4-bit field – defines the major version of IKE protocol in use by the sender in this packet (NOT the highest protocol version it supports) – currently only v. 1 and v. 2 supported!→ gives the other end the opportunity to obtain the version supported by the sender→ if the version is greater than what the receiver can support, the datagram MUST

be discarded (the old version cannot parse anything else in the datagram becausethe generic packet structure has changed)

→ in that case, the receiver also SHOULD send the INVALID-MAJOR-VERSION notification back, with its own version number inside the notification datagram

→ in order to prevent two nodes from being tricked into corresponding with a lowermajor version number than the maximum they both support, IKE has a flag thatindicates that the node is capable of speaking a higher major version #

Minor Version = 4-bit field – defines the minor version of the protocol in use by the sender; should be set to 0→ if an endpoint supports minor version N and major version M, then that implies

that it supports all versions between N and M


Exchange Type = 8-bit field – defines the type of exchange that is beingcarried by the ISAKMP packets (Main Mode, Aggressive Mode, Quick Mode)

Flags = 8-bit field in which each bit defines an option for the exchange –so far only the three last significant bits are defined

Message ID = 32-bit filed used to control retransmission of lost packetsand matching of requests and responses→ value is set to zero during the main mode negotiations and is incremented

for each subsequent exchange→ Message ID is reset to zero in the new IKE SA after the IKE SA is rekeyed

Length = 32-bit field that contains the length of total message (header plusall payload) in octets/bytes

→ each IKE payload begins with a generic payload header (shownbelow) followed by some specific fields

ISAKMP Payloads

Next Payload – 8-bit field that identifies the type of next payload→ when there is no next payload, the value of this field is 0→ the type of current payload is determined by the previous payload or the

general header (if the payload is the first one)→ for different possible types of payload – see next slide!


Reserved – (7+1)-bit field, must be sent as zero, must be ignored on receipt

Payload Length – 16-bit field that specifies the length of the currentpayload, including its generic payload header, in octets/bytes

IKE Payload Types

Figure 18.31 SA payload

Figure 18.32 Proposal payload


Domain Of Interpretation –indirectly says that this

ISKAMP message exchange is for IPsec.

Security Parameter Index


Figure 18.33 Transform payload

IPsec Protocols: ISAKMP (cont.)Figure 18.34 Key-exchange payload

Figure 18.35 Identification payload

Figure 18.36 Certification payload

IPsec Protocols: ISAKMP (cont.)Figure 18.37 Certification request payload

Figure 18.38 Hash payload

Figure 18.39 Signature payload


Figure 18.40 Nonce payload

Figure 18.41 Notification payload

IPsec: Implementation Scenarios

• Bundling Security Associations (SAs) an individual SA can implement either the AH or ESP protocol

but not both!

refers to a sequence of SAs through which traffic must be processed toprovide a desired set of IPsec services

Security Association (SA) Bundle …

Transport Adjacency: both security protocols are applied in transportmode to the same IP datagram => only one combination possible (bothAH and ESP done at the original-sending machine)

SAs can be combined into bundles in two ways:

Iterated Tunneling: the security protocols are applied in tunnel mode(or transport where appropriate), in sequence – allows multiple levels ofnesting → at each level, a new IP datagram is created and the next protocol is applied to it

=> no limit on the # of nesting levels, though more than 3 levels are impractical

• Different SA Bundling Possibilities … there are different way how authentication end encryption can be

bundled – each with its own pros and cons

can be done in transport or tunnel mode – see below! Encryption & Authentication using ESP (no pure AH used!)

→ in both cases, authentication applies to ciphertext rather than plaintext

ESP intransport

mode

ESP intunnelmode

→ disadvantage: authentication does NOT cover IP header fields, such asIP source and destination address

not really

bundling as only one ESP is used

IPsec: Implementation Scenarios (cont.)

both encryption & authentication are achieved by using 2 bundled transport SAs - with the inner being a transport-mode ESP SA, andthe outer being a transport-mode AH SA

Transport Adjacency (ESP and AH are combined!)

→ in this case, ESP is used without its authentication option!→ advantage: authentication covers more fields, including the source & destination

IP address→ disadvantage: overhead of deploying 2 SA versus 1 SA

inner SA:ESP in

transportmode

outer SA:AH in

transportmode


use of authentication prior to encryption may be preferred forthe following reasons:

Transport-Tunnel Bundle (AH in transport followed by ESP in tunnel)

→ authentication data is protected by encryption => it is impossible for someone tointercept the message and alter the authentication data without detection

→ it may be desirable to store the authentication information with the message atthe destination for later reference (e.g., for purposes of auditing or forensics)

→ NOTE: in this case, authentication covers the plaintext (only)

→ disadvantage: authentication does not cover the fields (source & destination)of the outer IP header – AH (only) authenticates the fields of the original IPheader/packet


Packet is entirely protected through the

Internet. Within the last-hop (only) the

integrity and authenticity of the

original packet (except mutable

fields) are protected.

Protect the payload only, and

ensure the authenticity and

integrity of the entire packet

(except the mutable fields).

In case of Transport Adj.AH after ESP -recommended

order!!!

Want to protect/encrypt the

content from everybody!

Want to protect the identity of internal

computers (IPs) from outside attackers.

How are scenario 2 and 3

different?Where and

which kind of adversaries are

assumed in each case??

• Real-world Use-Cases of SAs theoretically, AH & ESP protoc. can be used alone or together,

each being deployed in transport or tunnel mode and havingthe same or different endpoints (many combinations possible) in reality, however, only 4 main scenarios are likely/possible

CASE 1: End-to-End Security - no intermediate gateways involved various combinations can be used to support authentication, encryption,

authentication before encryption, and authentication after encryption, for example: → transport mode:

- AH alone- ESP alone- AH after ESP (transp. adjacency)

→ tunnel mode:- AH alone- ESP alone- iterated AH/ESP tunnel


Possible but likely

redundant!

CASE 2: Basic VPN Security / Site-to-Site – security provided only between gateways/routers/firewalls, no hosts implement IPsec only a single tunnel SA is needed – either AH, ESP, or ESP with

authentication option → nested tunnels are not required since IPsec applies to entire inner packet


Would transport mode work

here?!

CASE 3: End-to-End Combined With Site-to-Site Security– combination of CASE 1 & CASE 2

→ the whole packet traveling the Internet is authenticated, and the data carriedis encrypted/protected

common scenario: hosts use ESP in transport mode, and gatewaysuse AH in tunnel mode (see packets figure)

→ advantage – entire original packet, including destination addresses, encrypted alternative: combined AH-ESP tunnel between the gateways

→ disadvantage – processing load of encryption passed to gateways


CASE 4: Remote Access – remote host uses the Internet to reacha server in the home organization protected by a firewall

common scenario 2: AH in tunnel mode between H1 and G2, and ESPin transport mode between H1 and H2 - drawback: 2 AS needed!- advantage: gateway not slowed down with encryption

common scenario 1: combined ESP-AH tunnel between H1 and G2- advantage : only 1 AS needed

to reach entire Intranet!- disadvantage: gateway needs

to perform encryption


H2H1

G2

Documents

Hash Algorithms Encryption Algorithms - York University€¦ · IPsec Protocols: ISAKMP (cont.) Next Payload = 8-bit field – indicates the type of the first payload in the message