Internet Security CSCE 813 IPsec Can be added to either current version of IP IPv4 or IPv6 Provides security across protocol layers Security for many security ignorant applications

Reading Oppliger: Chapter 14 CSCE 813 - Farkas

Benefits of IPSec When implemented in a firewall or router, IPSec provides strong security to ALL TRAFFIC crossing the perimeter. Traffic within the perimeter does not incur security overhead. Cannot be bypassed (if all traffic must go through the firewall implementing IPSec) Transparent to applications Transparent to end users CSCE 813 - Farkas

IP Security Architecture IPsec module 1 IPsec module 2 SPD SAD IKE IPsec SA Key functional areas: authentication, confidentiality and key management Very complex Support for these features is mandatory for IPv6 (optional for IPv4) Security features are implemented as extension headers that follow main IP header RFC 2401: Overview of Security Architecture RFC 2402: Desc. Of packet authentication extension to IPv4 and IPv6 RFC 2406: Desc. Of packet encryption extension to IPv4 and IPv6 RFC 2408: Specification of key management capabilities CSCE 813 - Farkas

IPSec Document Overview RFC 2401 Architecture Key Management DOI Authentication algs. Enryption algs. AH ESP Domain of Interpretation: contains values needed for the other documents to relate to each other. Includes indentifiers of approved enryption and authentication algs. Opeational paramenters CSCE 813 - Farkas

IPSec Services  AH ESP (encrypt.) ESP (Encrypt. & Auth.) Access Control  Connectionless integrity Data origin auth. Replay protection Confidentiality Traffic flow confidentiality CSCE 813 - Farkas

Security Association One-way relationship Identified by: Security parameters index (SPI) IP destination address Security protocol identifier Security Association Database: SA parameters: sequence number counter, sequence number overflow, anti-replay window, AH information, ESP information, lifetime of SA, IPSec protocol mode, path MTU Security Policy Database: SA selectors: destination IP address, source IP address, UserID, Data Sensitivity Level, transport layer protocol, source and destination port SPI: a bit string assigned to SA and having local significance only. Carried in AH and ESP headers. Enables receiving system to select which SA to use with incoming traffic. IP destL currently only unicast addresses . Address of destination endpoint of SA (may be enuser, may be proxy, firewall, etc.) Sec. prot. identifierL whether AH or ESP SA. Path MTUL maximum transmissio unitL max. size of packet that can be transmitted without fragmentation SPD: compare values in IP packet to find appropriate entry in SPD, Find SA, Do required IPSEc processing. CSCE 813 - Farkas

Modes Transport Mode Tunnel Mode AH Authenticates IP payload and selected portions of IP header and IPv6 extension headers Authenticates entire inner IP packet (inner header plus IP payload) plus selected portions of outer IP header and outer IPv6 extension headers ESP (encrypt. only) Encrypts IP payload and any IPv6 extension headers following the ESP header Encrypts entire inner IP packet ESP with Authentication (see above) plus authenticates IP payload but not IP header (see above) plus authenticates inner IP packet. Transport mode: protection for upper layer protocols Used for end-to-end connection between two hosts Payload: data following IP header or (IPv6: following Ip and extension headers) ESP: payload authentication but NOT IP Header AH ;both Tunnel mode: Protection to the entire IP packet. After AH or ESP fields are added, the entire packets plus security fields are treated as palyload. New outer IP header – needed for processing. One or both ends of SA are security gateways. (firewall or router implements IPSec. May serve number of hosts behind the firewal. Show msg. from host A to Host B CSCE 813 - Farkas

Encapsulating Security Payload (ESP)

ESP Confidentiality: Encryptor Integrity: Authenticator Algorithm is determined by the Security Association (SA) Each ESP has at most: One cipher and one authenticator or One cipher and zero authenticator or Zero cipher and one authenticator or Disallowed: zero cipher and zero authenticator or CSCE 813 - Farkas

ESP Processing Depends on mode in which ESP is employed Both modes: Cipher is authenticated Authenticated plain text is not encrypted Outbound: encryption happens first Inbound: authentication happens first CSCE 813 - Farkas

Protected Data Depends on the mode of ESP Transport mode: Upper-layer protocol packet Tunnel mode: entire IP packet is protected CSCE 813 - Farkas

Scope of ESP Encryption and Authentication Transport mode Authenticate Encrypt Orig. IP hdr ESP hdr. TCP Data ESP ESP auth. IPv4 Tunnel mode Authenticate Encrypt New IP hdr ESP hdr Orig. IP hdr TCP Data ESP trlr ESP auth CSCE 813 - Farkas

Outbound Processing ESP header inserted into the outgoing IP packet Protocol field of IP header copied into Next header field of ESP Remaining fields of ESP filled (SPI, sequence number, pad, pad length) Protocol number of IP header is given the value ESP (50) Encrypt packet from the beginning of payload data to the next header field Authenticate packet form the ESP header, through the encrypted ciphertext to the ESP trailer and insert authentication data into ESP trailer Packet is routed to the destination CSCE 813 - Farkas

Inbound Processing Check for SA of the packet If no SA  drop packet Otherwise: use valid SA to process the packet Check sequence number Invalid number  drop packet Authenticate cipher text Entire packet (without the authentication data) is processed by the authenticator Match generated data with authentication data No match  drop packet CSCE 813 - Farkas

Inbound Processing Decrypt ESP packet (from beginning on payload to the next header field) Check pad integrity Validate ESP mode using Next header field and decrypted payload CSCE 813 - Farkas

Authentication Header

Authentication Header (AH) Does NOT provide confidentiality Provides: Data origin authentication Connectionless data integrity Prevents spoofing attack May provide: Non-repudiation (depends on cryptographic alg.) Anti-replay protection Precision of authentication: granularity of SA Protocol number: 51 CSCE 813 - Farkas

Authentication Data AH protects outer IP header (unlike ESP) Computed by using Authentication algorithm (MD5, SHA-1) Cryptographic key (secret key) Sender: computes authentication data Recipient: verifies data CSCE 813 - Farkas

Scope of Authentication Transport Mode Authenticates except for mutable fields IPv4 Orig. IP hdr AH TCP Data Tunnel Mode Authenticates except for mutable fields in NEW IP hdr New IP hdr AH Orig. IP hdr TCP data IPv4 CSCE 813 - Farkas

Integrity Check Values Message Authentication Code is Calculated from: IP header fields that either do not change in transit or are predictable upon arrival – Fields that change and cannot be predicted are set to zero for the MAC calculation AH header -- other than the authentication data field Entire upper level protocol data Note: both source and destination address fields are protected CSCE 813 - Farkas

Combining Security Associations CSCE 813 - Farkas

SA Bundle Individual SA: either AH or ESP but NOT BOTH Some traffic flow needs both – HOW? Some traffic between host and security gateway requires different services than flow between security gateways Security Association Bundle: sequence of SAs through which traffic must be processed to provide a desired set of IPSec services SAs within a bundle may terminate at different end points CSCE 813 - Farkas

SA Combinations Transport adjacency: Iterated tunneling: Applying more than one security protocol to the same IP packet without invoking tunneling. Allows 1 level of combination (all IPSec processing are performed at one IPSec instance) Iterated tunneling: Multiple layers of security protocols efected through IP tunneling Multiple levels of nesting (each tunnel may originate and terminate at different IPSec site) Combination of the two approaches above. CSCE 813 - Farkas

Transport Adjacency Two bundled transport Sas Inner SA: ESP transport SA without authentication (encrypted IP payload) Outer SA: AH transport SA (covers ESP and the original IP header) CSCE 813 - Farkas

Transport-Tunnel Bundle Authenticate before encrypting Inner SA: AH transport SA (authenticates the entire IP payload + IP header) Outer SA: ESP tunnel SA (entire authenticated packet is encrypted + new IP header) Advantages: Authentication data is protected by encryption Can store authentication information with the message (convenience) CSCE 813 - Farkas

Combining Security Associations Possible combinations: AH in transport ESP in transport ESP followed by AH in transport Any 1,2,3 inside an AH or ESP tunnel Combining Security Associations Case 1: between end-systems Internet local intranet one or more SAs Figure from L. Buttyan CSCE 813 - Farkas

Combining Security Associations Security provided: Only between gateways No host security Only single tunnel SA AH, ESP or ESP with authentication Combining Security Associations Case 2: between gateways only Internet local intranet single tunnel SA Figure from L. Buttyan CSCE 813 - Farkas

Combining Security Associations End-to-end protection: Combinations for case 1 &2 allowed Gateway tunnel: authentication and confidentiality 3. Hosts: application specific IPSec Case 3: host-to-gateway (Case 2 + end-to-end security) Internet local intranet single tunnel SA One or two SAs Figure from L. Buttyan CSCE 813 - Farkas

Combining Security Associations Remote host: Host: tunnel mode to firewall Combining Security Associations Case 4: remote host Internet local intranet Tunnel SA One or two SAs Figure from L. Buttyan CSCE 813 - Farkas

Next Class: Key Management ISAKMP Exchanges CSCE 813 - Farkas