IPsec IPsec IP security Security for transmission over

IPsec • IPsec (IP security) • Security for transmission over IP networks – The Internet – Internal corporate IP networks – IP packets sent over public switched data networks (PSDN) Local Network Internet Local Network

IPsec • Why do we need IPsec? – IP has no security – Add security to create a virtual private network (VPN) (Chapter 9) to give secure communication over the Internet or another IP network Local Network Internet Local Network

IPsec • Genesis – Being created by the Internet Engineering Task Force – For both IP version 4 and IP version 6

IPsec • Two Modes of operation • Tunnel Mode – IPsec server at each site – Secures messages going through the Internet Local Network Secure Communication Internet Local Network IPsec Server

IPsec • Tunnel Mode – Hosts operate in their usual way • Tunnel mode IPsec is transparent to the hosts – No security within the site networks Local Network Secure Communication Internet Local Network IPsec Server

IPsec • Two Modes of operation • Transport Mode – End-to-end security between the hosts – Security within site networks as well – Requires hosts to implement IPsec. Local Network Secure Communication Internet Network

IPsec • Transport Mode – Adds a security header to IP packet – After the main IP header – Source and destination addresses of hosts can be learned by interceptor – Only the original data field is protected Original IP Header Transport Security Header Protected Original Data Field

IPsec • Tunnel Mode – Adds a security header before the original IP header – Has IP addresses of the source and destination IPsec servers only, not those of the source and destination hosts – Protects the main IP header Tunnel Security Header Protected Original IP Header Protected Original Data Field

IPsec • Can combine the two modes – Transport mode for end-to-end security – Plus tunnel mode to hide the IP addresses of the source and destination hosts during passage through the Internet Local Network Tunnel Mode Internet Local Network Transport Mode

IPsec • Two forms of protection • Encapsulating Security Protocol (ESP) security provides confidentiality as well as authentication • Authentication Header (AH) security provides authentication but not confidentiality – Useful where encryption is forbidden by law – Provides slightly better authentication by providing authentication over a slightly larger part of the message, but this is rarely decisive

IPsec • Modes and protection methods can be applied in any combination Tunnel Mode Transport Mode ESP Supported AH Supported

IPsec • Security Associations (SAs) are agreements between two hosts or two IPsec servers, depending on the mode • “Contracts” for how security will be performed • Negotiated • Governs subsequent transmissions Host A Negotiate Security Association Host B

IPsec • Security Associations (SAs) can be asymmetrical – Different strengths in the two directions – For instance, clients and servers may have different security needs SA for messages From A to B Host A Host B SA for messages From B to A

IPsec Policies may limit what SAs can be negotiated – To ensure that adequately strong SAs for the organization’s threats – Gives uniformity to negotiation decisions Host A Security Association Negotiations Limited By Policies Host B

IPsec • First, two parties negotiate IKE (Internet Key Exchange) Security Associations – IKE is not IPsec-specific – Can be used in other security protocols Host A Communication Governed by IKE SA Host B

IPsec • Under the protection of communication governed by this IKE SA, negotiate IPsecspecific security associations Host A Communication Governed by IKE SA IPsec SA Negotiation Host B

IPsec • Process of Creating IKE SAs (and other SAs) – Negotiate security parameters within policy limitations – Authenticate the parties using SA-agreed methods – Exchange a symmetric session key using SA-agreed method – Communicate securely with confidentiality, messageby-message authentication, and message integrity using SA-agreed method

IPsec • IPsec has mandatory security algorithms – Uses them as defaults if no other algorithm is negotiated – Other algorithms may be negotiated – But these mandatory algorithms MUST be supported

IPsec • Diffie-Hellman Key Agreement – To agree upon a symmetric session key to be used for confidentiality during this session – Also does authentication (not discussed) Party A Party B

IPsec • Diffie-Hellman Key Agreement – Each party sends the other a nonce (random number) – The nonces will almost certainly be different – Nonces are not sent confidentially Party A Nonce B Nonce A Party B

IPsec • Diffie-Hellman Key Agreement – From the different nonces, each party will be able to compute the same symmetric session key for subsequent use – No exchange of the key; instead, agreement on the key Symmetric Key Party A Symmetric Key From nonces, independently compute same symmetric session key Party B

IPsec • Mandatory algorithm for confidentiality is DES-CBC – DES with Cipher Block Chaining – An extension of DES (Data Encryption Standard) – Straight DES always gives the same ciphertext for the same plaintext and key – This allows certain types of attacks to guess passwords

IPsec • DES-CBC (DES Cipher Block Chaining) – DES works in blocks of 64 bits – DES-CBC begins with 64 -bit plaintext to be encrypted – Combines with the ciphertext output from the previous block (cipher block chaining) Plaintext Block + Previous Ciphertext Block Cipher Block Chaining Block To be Encrypted

IPsec • DES-CBC – Encrypts the plaintext block plus previous ciphertext block to give ciphertext for the current block – This gives different ciphertexts for the same plaintext and key on different occasions Block To be Encrypted DES Encryption Ciphertext For Block

IPsec • Adding Plaintext and Ciphertext together in DES-CBC – The bits are XORed – The result is 1 if one bit (but not both) is 1 • 1 XOR 0 = 1 • 0 XOR 1 = 1 – The result is 0 if both bits are 1 or 0 • 1 XOR 1 = 0 • 0 XOR 0 = 0

IPsec • Adding Plaintext and Ciphertext together in DES-CBC – The bits are XORed – If the ciphertext is – And the plaintext is – The result is 111000 … 101010 … 010010 …

IPsec • HMAC – key-Hashed Message Authentication Code – Mandatory IKE message-by-message authentication and message integrity algorithm – Not a digital signature – HMAC does not use public key encryption – So it is faster than digital signature authentication, which uses public key encryption

IPsec • HMAC – Begins with original plaintext – Adds a secret HMAC key that only the communicating partners know • It is a shared secret • Usually different from the symmetric key used to send the entire message confidentiality Original Plaintext HMAC Key

IPsec • HMAC – Hashes the combination with MD 5 or SHA 1 – This gives the HMAC – Get different HMACs with different HMAC keys Original Plaintext HMAC Key Hashing HMAC

IPsec • HMAC – The HMAC is added to the original plaintext – Gives authentication and message integrity – HMAC is similar to digital signature – However, hashes instead of using public key encryption, so processing is faster HMAC Original Plaintext

• HMAC IPsec – Receiver again hashes plaintext message plus shared secret HMAC key – If the same as transmitted HMAC, sender is authenticated because the sender knows the shared secret HMAC key Transmitted Original HMAC Plaintext Key Hashing Computed HMAC

IPsec • IPsec only uses symmetric key encryption and hashing, which are very fast • Avoids public key encryption, which is very slow – Diffie-Hellman key exchange instead of sending session key encrypted with receiver’s public key – HMAC instead of digital signatures • This allows IPsec to be fairly fast, reducing host or IPsec security server costs