Ipsec and IKE Ipsec and IKE

IPSec and IKE IPSec and IKE

VPN: IPSec and IKE 1. Standard for realtime communication security • confidentiality • message integrity 2. Negotiate Security Associations (crypto protected conn) • cryptographic protocol • key size 3. Other features • data compression, if any • type of error checking • how sender indicates it is finished sending • how the receiving device indicates it has received msg 4. Establish and exchange session keys based on above 5. Used to support virtual private networks IPSec and IKE Layer 3.5 implementation: applications do not have to be changed to use it all applications automatically use it whether they like it or not.

Applications User

TCP OS IPSec

... IPSec and IKE Layer 3.5 implementation: applications do not have to be changed to use it all applications automatically use it whether they like it or not.

But the OS needs to be modified Applications User

TCP OS IPSec

... IPSec and IKE Layer 3.5 implementation: applications do not have to be changed to use it all applications automatically use it whether they like it or not.

But the OS needs to be modified Applications User IPSec capable of authenticating

TCP but can only tell app the address OS of source IPSec IP

... IPSec and IKE Layer 3.5 implementation: applications do not have to be changed to use it all applications automatically use it whether they like it or not.

But the OS needs to be modified Applications User IPSec capable of authenticating

TCP but can only tell app the address OS of source IPSec Operates like a firewall IP encrypts has policies ... authenticates address to app IPSec and IKE Perfect Forward Secrecy: attacker cannot decrypt even if the entire session is recorded and attacker breaks into both parties and finds their secrets (uses session keys).

IPSec and IKE Perfect Forward Secrecy: attacker cannot decrypt even if the entire session is recorded and attacker breaks into both parties and finds their secrets (uses session keys). Denial of Service Protection: lock out with repeated authentication attempts. Uses cookies: unpredictable numbers sent to IP address with expectation of return if no return then connection is stopped. Uses stateless cookies so that no one has to remember where the cookies came from ( hash(IP address, some secret)). IPSec and IKE Perfect Forward Secrecy: attacker cannot decrypt even if the entire session is recorded and attacker breaks into both parties and finds their secrets (uses session keys). Denial of Service Protection: lock out with repeated authentication attempts. Uses cookies: unpredictable numbers sent to IP address with expectation of return if no return then connection is stopped. Uses stateless cookies so that no one has to remember where the cookies came from ( hash(IP address, some secret)). Endpoint Identifier Hiding: prevent target node from knowing the source of a packet. Uses DiffieHellman to get a key then authentication information is sent encrypted. IPSec and IKE Live Partner Reassurance: prevent replay attacks. Can change secret DiffieHellman a,b but that is expensive, alternative: use a nonce as part of the session key. IPSec and IKE Live Partner Reassurance: prevent replay attacks. Can change secret DiffieHellman a,b but that is expensive, alternative: use a nonce as part of the session key. Data Stream Protection: individual packets are self contained so they can be encrypted and integrity protected independently. Decryption can easily be offloaded to other software or hardware. IPSec and IKE Security Association: • A cryptographically protected connection • Each end has ≥ one key, sequence number, identity of other end • Each end has crypto services used: integrity only, encryption+integrity, crypto algorithms • Unidirectional two connections needed for 2way operation • Details of an SA are kept in a database • IPSec header has a Security Parameter Index (SPI) field that identifies the SA allowing the sender to look up necessary info in the sender's SA database. • SPI value is chosen by the receiver. • An SA is defined by an SPI and destination address (if receiver is involved in a multicast, it may not have chosen the SA – the destination address is a group address in the case of multicast) IPSec and IKE Security Association Database: • Transmitter checks receiver's address to see how to transmit (database entry provides the SPI, key, crypto algorithms, etc.) • When receiving a packet, SPI of the packet is used to find the SA entry giving the receiver the key, sequence # etc. IPSec and IKE Security Association Database: • Transmitter checks receiver's address to see how to transmit (database entry provides the SPI, key, crypto algorithms, etc.) • When receiving a packet, SPI of the packet is used to find the SA entry giving the receiver the key, sequence # etc. Security Policy Database: • Which packets are to be dropped completely • Which should be forwarded or accepted without IPSec protection • Which should be forwarded or accepted with IPSec protection & which type of protection (encrypt, integrity) • Decisions based on ports, source addr, dest addr, protocol type or any other fields in the packet header. IPSec and IKE Authentication Header (AH): • Message integrity protection only (Message Authentication) • IPSec computes a HMAC checksum over nearly all the fields of the IP packet, and stores it in a new AH header ... IP header ... (8 bits) next header (8 bits) payload length (size of AH header) (16 bits) unused (32 bits) SPI (Security Parameter Index) (32 bits) sequence number (detect replayed packet) (N32 bits) authentication data (MD5 or SHA1 hash) ... rest of packet ...

• Can protect some IP header fields and all AH fields IPSec and IKE Authentication Header (AH):

(8 bits) next header (8 bits) payload length (16 bits) unused (32 bits) Security Parameter Index (32 bits) sequence number (N32 bits) authentication data

next header: same as protocol field in IPv4 – says IP layer is protected payload length: size of AH header in 32 bit chunks, not counting first 64 sequence number: assigned by AH and used so that AH can recognize replayed packets and discard them. AH protects immutable and mutable but pedictable fields. For example, source computes AH knowing destination address even though next address is address of next hop. All AH fields are protected. IPSec and IKE IPv4 Header:

(4 bits) version header length (4 bits) (8 bits) type of service (priority/quality) (16 bits) length of header plus data in this fragment (16 bits) packet id flags (3 bits) (13 bits) frag offset time to live (hops) (8 bits) (8 bits) protocol checksum (hdr only) (16 bits) (32 bits) source addr dest addr (32 bits) options protocol: 0x32 = ESP 0x33 = AH

mutable fields: type of service, flags, frag offset, hops, checksum mutable but predictable: dest addr fields in yellow are integrity protected (included in hash) others are not IPSec and IKE Encapsulating Security Payload (ESP): • Provides integrity and/or encryption • Only protects information after the IP header (HMAC for ESP header and payload) • Typical encryption algorithms used: DES, 3DES, Blowfish, AES IPSec and IKE Encapsulating Security Payload (ESP): • Provides integrity and/or encryption • Only protects information after the IP header (HMAC for ESP header and payload) • Typical encryption algorithms used: DES, 3DES, Blowfish, AES There is nothing in the packet that says it's encrypted so firewalls may get stuck if they need to check ports, for example, because they cannot reliably get that info only the sender and receiver know whether the ESP packets are encrypted IPSec and IKE Encapsulating Security Payload header (ESP):

(32 bits) Security Parameter Index (32 bits) sequence number header initialization vector TCP header + payload (data) padding (8 bits) padding length trailer (8 bits) next header/protocol type authentication data encryption

sequence number: for detecting replay attacks integrity initialization vector: depends on the encryption scheme (CBC) padding: depends on the crypto algorithm used, allows block encryption algorithms room for multiples of their blocksize padding length: size of the padding field IPSec and IKE Transport Mode: 1. IPSec info between IP header and rest of packet 2. Applied endtoend, authentication, encryption, or both

IP Header Rest of Packet

IP Header IPSec Rest of Packet IPSec and IKE Transport Mode (AH): IPSec and IKE Transport Mode (AH): the IP header is modified only slightly after validation, the IPSec header is stripped away the original protocol field is restored in the IP header thus, the packet is restored to its original state and can be delivered IPSec and IKE Transport Mode (AH): AH is incompatible with Network Address Translation (map range of private addresses to/from small set of public addresses) and Port Address Translation (map multiple private addresses to single external address, ports are assigned) IPSec and IKE Transport Mode (ESP):

IPSec and IKE Transport Mode: 1. IPSec info between IP header and rest of packet 2. Applied endtoend, authentication, encryption, or both

IP Header Rest of Packet

IP Header IPSec Rest of Packet Tunnel Mode: 1. Keep original IP packet intact, add new IP header and IPSec information (AH or ESP) 2. Firewalltofirewall, endtofirewall, encrypt header & payload

IP Header Rest of Packet

New IP Header IPSec IP Header Rest of Packet IPSec and IKE Tunnel Mode (AH): IPSec and IKE Tunnel Mode (ESP): IPSec and IKE AH vs. ESP AH does not support NAT or PAT AH does not encrypt hence port information at level 4 is available to firewalls for screening, filtering, etc. ESP may be used in integrityonly mode but only the endpoints know whether encryption was used so intermediate firewalls cannot know the port information reliably (SAs are unknown to them) However, people object to firewalls needing to use port information AH integrity protects IP header fields but this could be accomplished by ESP in tunnel mode AHonly might be approved for export more readily but vendors have been able to export ESPbased IPSec systems Ipv6 proponents see AH as a way to force/encourage people to adopt Ipv6 IPSec is a mandatory feature of Ipv6 IPSec and IKE AH vs. ESP The authentication data in AH appears before the data it authenticates The authentication data in ESP appears after the data it authenticates

Hence, in AH, the data must be buffered to allow the HMAC to be computed and added to the AH header.

But, AH packets tend to be smaller (vs. ESP in integrityonly mode) because there is no need to pad. IPSec and IKE AH vs. ESP International Engineering Task Force meeting held just before AH and ESP were finalized: Microsoft rep: “AH is useless given the existence of ESP, cluttered up the spec, and couldn't be implemented efficiently because the HMAC is in front of the data it authenticates.”

Network Security: Private Communication is a Public World, 2nd Ed., Kaufman, Perlman, Speciner Page 438 IPSec and IKE AH vs. ESP International Engineering Task Force meeting held just before AH and ESP were finalized: Microsoft rep: “AH is useless given the existence of ESP, cluttered up the spec, and couldn't be implemented efficiently because the HMAC is in front of the data it authenticates.”

Then everyone in the room looked around at each other and thought:

Hmmm...he's right, and we hate AH, but if it annoys Microsoft let's leave it in since we hate Microsoft more than we hate AH

Network Security: Private Communication is a Public World, 2nd Ed., Kaufman, Perlman, Speciner Page 438 IPSec and IKE Firewalls IETF people do not like firewalls because they can make it difficult to deploy new applications and they may break some existing applications. Argue against firewalls: security is strongest if it is endtoend IPSec encrypts information that SysAdmins would like to use to filter packets, determine whether data is email or telnet, etc. But IPSec has not encouraged the disappearance of firewalls and reliance on firewalls has not encouraged the disuse of IPSec Maybe there should be more cooperation between protocol designers and SysAdmins? Aside: attackers can spoof protocols anyway, so are firewalls really that secure? IPSec and IKE Internet Key Exchange: Protocol for doing mutual authentication and establishing a shared secret key to create an IPSec SA. Uses: long term keys (public signatureonly keys, preshared secret keys, public encryption keys) Pieces: ISAKMP (Internet Security Association and Key Management Protocol) framework (OAKLEY implementation) IKE (Internet Key Exchange) defines fields, chooses options of ISAKMP DOI (Domain of Interpretation) specifies particular use of ISAKMP IPSec and IKE Internet Key Exchange Phases:

Phase 1: Does mutual authentication and establishes session keys based on identities such as names, and secrets Phase 2: SAs are established between two entities

Reason for two phases: Different SAs may be established for different traffic flows. There might be security weaknesses if two different flows used the same key. Phase 1 need be done once, phase 2 uses the same phase 1 session key to generate multiple SAs. Phase 1 relies on (slower) publickey cryptography, phase 2 relies on (faster) secret keys – hence sessionkeys are made quickly IPSec and IKE Possible Security Problem: (encryption w/o integrity)

C can decrypt packet sent by A to B • Record packet from A to B and packet from C to D • Splice encrypted part with srcdst from C to D onto A to B packet • Forward packet to Firewall 2, Firewall decrypts, sends result to D

Firewall 1 Firewall 2 (encrypts) (decrypts)

A C B D IPSec and IKE Internet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server share a secret K

Client Server (K) (K) IPSec and IKE Internet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server share a secret K

Client Server (K) (K) g mod a p, ID , crypto prop. C nonce C

DiffieHellman Exchange IPSec and IKE Internet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server share a secret K

Client Server (K) (K) g mod b p, ID , cypto choice S proof(Server), nonce S

DiffieHellman Exchange proof (Server) might be hash of K and nonce C IPSec and IKE Internet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server share a secret K

Client Server (K) (K) proof(Client)

DiffieHellman Exchange proof (Client) might be hash of K and nonce S IPSec and IKE Internet Key Exchange Phase 1: Aggressive Mode Problems:

1. Someone other than Server can send a refusal back to Client and Client cannot tell if it is fake (such a message should be sent encrypted). 2. Identities of the client and server are revealed 3. Reflection attack avoided by making sure Server does not accept its nonce from Client in second exchange 4. Replay avoided due to the use of a nonce both ways Allows using the same a and b exponents for many exchanges as nonces are included in the key computation 5. Man in the middle avoided due to mutual authentication IPSec and IKE Internet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server do not share a secret

Client Server IPSec and IKE Internet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server do not share a secret

Client Server g mod a p, ID , crypto prop. C nonce C

DiffieHellman Exchange IPSec and IKE Internet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server do not share a secret

Client Server g mod b p, ID , cypto choice S Certificate , nonce S S

DiffieHellman Exchange Certificate proves identity of Server to Client (sign nonce ?) S C IPSec and IKE Internet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server do not share a secret

Client Server Certificate C

DiffieHellman Exchange Certificate proves identity of Client to Server (sign nonce ?) C S IPSec and IKE Internet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms

Client Server crypto proposal

Parameter negotiation IPSec and IKE Internet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms

Client Server crypto choose

Client Server a g mod p, nonce C

DiffieHellman exchange IPSec and IKE Internet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms

Client Server b g mod p, nonce S

ab K = f(g mod p, nonce , nonce ) C S Client Server K{ID, proof of ID,[cert]}

authenticate, encrypted nonces allow same DiffieHellman private value for many transactions proof of ID: signature on a hash of ID, DH values, nonces, crypto choices IPSec and IKE Internet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms

Client Server K{ID, proof of ID,[cert]}

authenticate, encrypted IPSec and IKE Internet Key Exchange Phase 1: Proof of Identity: Some hash of the key associated with the identity, the DiffieHellman values, nonces, cryptographic choices, and cookies. Problem: choice of cryptographic suite by server is not encrypted. A maninthemiddle might actually replace a good choice with a poor (crackable) choice then decrypt and impersonate server from then on. Stateless cookies? No, must remember crypto proposals they are included in the hash used in the proof of identity sender could repeat this info later in the handshake, but IPSec does not allow this Duplicate connection identifiers? Possible to have two connections with the same crypto parameters IPSec and IKE Internet Key Exchange Phase 1: Regarding key types: Phase 1 might be based on a publickey pair for encryption, publickey pair for signing, or preshared secret. A more recent possibility is encrypting a randomly chosen secret key with the other side's public key and using that to encrypt all remaining fields. Hence there are 8 choices for Phase 1 handshakes: 4 authentication methods  (main + aggressive modes) IPSec and IKE Internet Key Exchange Phase 1: Crypto Parameters: 1. Encryption algorithm (DES, 3DES, IDEA) 2. Hash algorithm (MD5, SHA) 3. Authentication method (RSA signature, DSS...) 4. DiffieHellman group ((g,p), elliptic curves) Any combination is allowed – could result in more than 100 crypto suite choices in the proposal. Optionally, an expiration time/date can be specified in the proposal IPSec and IKE Internet Key Exchange Phase 1: Certificates: Client or Server can ask the other side for a certificate. If they do not know the other side's public key they cannot use the protocol. If certificates are sent in first two messages then identities are revealed. IPSec and IKE Internet Key Exchange Phase 1: Main Mode Revised: requires a single private key operation on either side.

Client Server crypto proposal

Parameter negotiation Starts out as before IPSec and IKE Internet Key Exchange Phase 1: Main Mode Revised:

Client Server crypto choose

Parameter negotiation No change yet IPSec and IKE Internet Key Exchange Phase 1: Main Mode Revised: Cookie: a fast hash over the IP source and destination addresses, the UDP source and destination ports, random number Stateless: if a secret is used in place of the random number

K1 = hash(nonce , cookie ) C C Client Server K1{g mod a p}, K1{ID}, K1{[certificate]}, ServerPublicKey{nonce } C

DiffieHellman exchange Server uses private key to decrypt nonce then determines K1 C then decrypts ID, and everything else IPSec and IKE Internet Key Exchange Phase 1: Main Mode Revised:

K2 = hash(nonce , cookie ) S S Client Server K2{g mod b p}, K2{ID}, ClientPublicKey{nonce } S

DiffieHellman exchange IPSec and IKE Internet Key Exchange Phase 1: Main Mode Revised:

K = f(gab mod p, nonces, cookies) Client Server K{proof of ID}

authenticate, encrypted IPSec and IKE Internet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?

Shared Secret J

Client Server crypto proposal

Parameter negotiation IPSec and IKE Internet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?

Shared Secret J

Client Server crypto choose

Shared Secret J

Client Server g mod a p, nonce C

DiffieHellman IPSec and IKE Internet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?

Shared Secret J

Client Server g mod b p, nonce S

Shared Secret J ab K =f(J ,g mod p, nons, coks) Client Server K{ID, proof(ID)}

authentication IPSec and IKE Internet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?

Shared Secret J ab K =f(J ,g mod p, nons, coks) Client Server K{ID, proof(ID)}

authentication IPSec and IKE Internet Key Exchange Phase 1: Problems: 1. Identities must be IP addresses so cannot seriously be used in road warrior application 2. Client sends identity in message 5 encrypted with key K which is a function of shared secret J. Server cannot decrypt that message to find out who the Client is unless it knows J. But that means Server must know who the Client is in the first place! This is why identities are IP addresses.

IPSec and IKE Internet Key Exchange Phase 1: Problems: 1. Identities must be IP addresses so cannot seriously be used in road warrior application 2. Client sends identity in message 5 encrypted with key K which is a function of shared secret J. Server cannot decrypt that message to find out who the Client is unless it knows J. But that means Server must know who the Client is in the first place! This is why identities are IP addresses. Fix: Do not make K a function of J. OK since J is included in the hash which is proof of identity. IPSec and IKE Internet Key Exchange Phase 1: Negotiating Cryptographic Parameters: encryption algorithm: DES, 3DES, IDEA hash: MD5, SHA authentication method: presharedkeys, RSA signing, RSA encryption, DSS DiffieHellman type: p,g

Session Keys: Two established: integrity, encryption for protecting the last phase 1 transaction (both directions) and all the phase 2 transactions

Keys are: hashes of DiffieHellman values, nonces, cookies,.. IPSec and IKE Internet Key Exchange Phase 2: Setting up IPSec SAs: All messages are encrypted with Phase 1 SA's encryption key K1 and integrity protected with phase 1 SA's integrity key K2.

Phase 1 SA

Client Server X, Y, CP, traffic, SPI1, nonce , [ga mod p] C

X is a pair of cookies from phase 1 Y is a 32 bit number chosen to distinguish this setup from others that may be setup simultaneously in phase 1. X and Y are unencrypted. (vulnerable to replay) IPSec and IKE Internet Key Exchange Phase 2: Setting up IPSec SAs: All messages are encrypted with Phase 1 SA's encryption key K1 and integrity protected with phase 1 SA's integrity key K2.

Phase 1 SA

Client Server X, Y, CP, traffic, SPI1, nonce , [ga mod p] C

Rest of message: authenticator using K2, crypto parameters, optional DiffieHellman values, optionally a description of traffic. IPSec and IKE Internet Key Exchange Phase 2: Setting up IPSec SAs: All messages are encrypted with Phase 1 SA's encryption key K1 and integrity protected with phase 1 SA's integrity key K2.

Phase 1 SA

Client Server X, Y, CP, traffic, SPI1, nonce , [ga mod p] C

Encryption: Initialization vector is the final ciphertext block of last message of phase 1 hashed with Y. IPSec and IKE Internet Key Exchange Phase 2: Setting up IPSec SAs:

Phase 1 SA

Client Server X, Y, CPA, traffic, SPI2, nonce , [gb mod p] S

Encryption: Initialization vector is the final ciphertext block of last message of previous phase 2 message hashed with Y. IPSec and IKE Internet Key Exchange Phase 2: Setting up IPSec SAs:

Phase 1 SA

Client Server X, Y, ack

Encryption: Initialization vector is the final ciphertext block of last message of previous phase 2 message hashed with Y. IPSec and IKE Internet Key Exchange Phase 2: Problems: 1. It is vulnerable to replay: a. Since Y is "random" instead of based on a sequence #, to detect a replay attack one must remember all Y's generated. b. Headers and session keys are the same in both directions so attacker can replay easily. 2. Vulnerable to reflection attack. IPSec and IKE Internet Key Exchange Phase 2: Problems: 1. It is vulnerable to replay: a. Since Y is "random" instead of based on a sequence #, to detect a replay attack one must remember all Y's generated. b. Headers and session keys are the same in both directions so attacker can replay easily. 2. Vulnerable to reflection attack. Fix: Use different keys in different directions or by reversing the order of the cookies so the recipient's cookie appears first. Use sequence numbers instead of message IDs. IPSec and IKE ISAKMP/IKE Encoding: Messages have a fixed header followed by a sequence of payloads. Each payload starts with "type of next payload" and "length of this payload".

Payload types: end, SA, proposed SPI, crypto choices, DiffieHellman values, certificate, certificate request, hash (checksum), signature, nonce, notification, delete, vendor ID. IPSec and IKE Fixed Header:

(64 bits) initiator's cookie (64 bits) responder's cookie (8 bits) next payload type (32 bits) version exchange type (80 bits) flags message ID (64 bits) message length exchange type: base adds extra message to aggresive mode, allows DH negot. identity protection (main mode) authentication only (not used by IKE) aggressive informational flags: encrypted, commit, authentication only (set only during phase 2), messageID: differentiates messages with same phase 1 SA

IPSec and IKE Payload, starting fields:

(8 bits) next type of payload (8 bits) unused (16 bits) length of this payload