Internet Security CSCE 813 IPsec CSCE 813 Farkas

Internet Security CSCE 813 IPsec CSCE 813 - Farkas

IPSec Protocols l Encapsulating Security Payload (ESP) – Confidentiality – Authentication l Authentication Header (AH) – Authentication CSCE 813 - Farkas 2

Encapsulating Security Payload (ESP) CSCE 813 - Farkas

ESP l Provides: – Confidentiality – Data origin authentication – Data integrity – Limited traffic flow confidentiality – Anti-replay l Protocol number: 50 CSCE 813 - Farkas 4

ESP Confidentiality: Encryptor l Integrity: Authenticator l Algorithm is determined by the Security Association (SA) l Each ESP has at most: l – – 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 5

ESP Protected IP packet encrypted IP header Protected ESP header data ESP Trailer authenticated ESP goals: • Authenticate as much information as possible • Allow efficient processing CSCE 813 - Farkas 6

ESP Format Security Parameter Index (SPI) IV Confidentiality protected Payload data padding Pad length Authenticity protected Sequence number Next header Authentication data (n*32 bit) CSCE 813 - Farkas 7

ESP Header l SPI: – Combined with the destination address and protocol in the preceding IP header identifies the SA – Authenticated but not encrypted l Sequence number: – Used for anti-replay – Monotonically increasing number – Authenticated but not encrypted CSCE 813 - Farkas 8

Payload Data Field Data to be protected l Length depends on the length of data to be protected l Contains: l – – – Initialization Vector (IV) Protected Data Pad Length Next Header CSCE 813 - Farkas 9

Initialization Vector l Specific algorithm must define location of IV l DES-CBC location first 8 octets of protected data field l Authenticated but not encrypted CSCE 813 - Farkas 10

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

Padding Needed for encryption (input data multiple of block size) l Hide actual data length l Padding values: l – Algorithm may specify – ESP default values: start with 1 and monotonically increases – Used for checking proper decryption by recipient CSCE 813 - Farkas 12

Padding l Padding Length – Needed for restoring actual length of payload data – Mandatory (even if there is no padding) l Next header – Defines that type of protected data Transport mode: type of upper-level protocol (e. g. , TCP 6) l Tunnel mode: 4 (IP-in-IP) l CSCE 813 - Farkas 13

Authentication Data Field l Used for data integrity check l Usually keyed hash function l Length: depends on the authentication algorithm defined in SA l If no authenticator is specified: there is no authentication data CSCE 813 - Farkas 14

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

Outbound Processing 1. ESP header inserted into the outgoing IP packet a. b. c. 2. 3. Protocol field of IP header copied into Next header field of ESP Remaining fields of ESP filled (SPI, sequence number, 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 CSCE 813 - Farkas 16

Inbound Processing 1. 2. 3. 4. 5. Check for SA of the packet a. If no SA drop packet b. Otherwise: use valid SA to process the packet Check sequence number a. Invalid number drop packet Authenticate cipher text a. Entire packet (without the authentication data) is processed by the authenticator b. Match generated data with authentication data c. No match drop packet Decrypt ESP packet (from beginning on payload to the next header field) a. Check pad integrity Validate ESP mode using Next header field and decrypted payload CSCE 813 - Farkas 17

Authentication Header CSCE 813 - Farkas

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

AH Protected IP packet IP header AH header Protected data authenticated CSCE 813 - Farkas 20

AH Header Next header Payload length Reserved Security Parameter Index (SPI) Sequence number Authentication data (n*32 bit) 32 bit CSCE 813 - Farkas 21

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

Internet Key Exchange (IKE) CSCE 813 - Farkas

IKE l Security Association (SA) defines processing done on IP packets – What algorithms to use – Parameters – Constraints l SA need to be created l IKE: establish shared security parameters and authenticated keys between IPsec peers CSCE 813 - Farkas 24

IKE General purpose security exchange protocol l Supports: l – Policy negotiation – Establishment of authenticated keying material l Based on three protocols – Internet Security Association and Key Management Protocol - ISAKMP ( NSA) – Oakley (Hilarie Orman) – SKEME (Hugo Krawczyk) CSCE 813 - Farkas 25

ISAKMP l Defines: – How two peers communicate – How messages are constructed – How to provide security l Provides means to – Authenticate peers – Exchange information for key exchange – Negotiate security services l Does not define } – How a particular key exchange should be done – Parameters necessary for SA establishment CSCE 813 - Farkas Specific Key exchange Protocols 26

Domain of Interpretation (DOI) l Defines what the protocol is being used for l Example: RFC 2407 (DOI of ISAKMP) – ISAKMP can be used to negotiate IKE and IPsec SAs CSCE 813 - Farkas 27

IKE l Request-response type of protocol l Initiator: need to establish SA because of the SDA requirement on an outbound packet l Responder: destination of the outgoing packet CSCE 813 - Farkas 28

Protection suite l Defines: – Encryption algorithm – Hash algorithm – Diffie-Hellman group – Method of authentication l IKE policy database: – List of protection suites weighted in order of preference CSCE 813 - Farkas 29

SA Establishement l Phase 1: IKE SA is established l Phase 2: IKE SA is used to establish IPsec Sas between communicating peers CSCE 813 - Farkas 30

Phase 1 1. Cookie exchange l l l 2. Value exchange l l 3. Protects responder by requesting that initiator submits valid cookie before value exchange and Diffie-Hellman key exchange Valid cookie: computed and verified by the responder Need cookie exchange Establishes a shared secret key Uses Diffie-Hellman key exchange Negotiate parameters Result: shared, un-authenticated secret key Authentication exchange l l Keys and SA are authenticated Methods: preshared keys, DSS, RSA digital signature, encrypted nonce with RSA CSCE 813 - Farkas 31

Phase 2 l Quick mode exchange l Negotiate IPsec SA under the protection of IKE SA l Keys derived from IKE secret state CSCE 813 - Farkas 32