COEN 350

1. COEN 350 IPSec, SSL, SSH,

2. Communication Security • Decision: What Layer? • Implemented at application level • Application change • OS does not change • Implemented at TCP/IP level • OS changes • Applications do not change

3. Communication Security • Session Key Establishment • Threat: Session Hijacking • Counter-measure: Encryption • Use Session key for each session • Session key needs to be unpredictable • Implementation of SSL used time, process id, parent process id to concoct session key • Attacker could narrow search space to about 30b of key. • Both partners should contribute to session key • Threat: Packet replay • Counter-measure: Sequence number

4. Communication Security • Perfect Forward Security • Threat: • Eavesdropper captures traffic. • Eavesdropper later acquires master key for both communicants. • PFS: Eavesdropper can still not encrypt data. • Diffie Hellman key exchange provides PFS • Counter-example: • Encrypting all messages with a public key of partner • Kerberos • Session key is inside ticket, encrypted with long-term secret key • Sending session key encrypted with public key

5. Communication Security • Escrow-foilage • Alice and Bob have to give their private keys to an escrow agency. • Passive listener with those keys can still not decrypt traffic between Alice and Bob

6. Communication Security • Denial of Service Protections • Cookies: • Server can generate random looking cookies. • Server can quickly verify that something is a cookie. • Server hands out cookies to requestors. • Requestors need to pass cookie along with all traffic.

7. Communication Security • Denial of Service Attack Protection • Puzzles • Server creates puzzles • Client needs to solve puzzle in order to get work done. • Client does more work than server  DOS attack is harder

8. Communication Security • Replay prevention • Use session keys • Session Resumption • Goal is avoiding costly initial encryption exchange • Lotus Notes: • Server has secret that changes once a month. • Server sends hash(client-name, server-secret) to client after authentication. • Session key is calculated from this hash plus nonces.

9. Communication Security • Negotiation of crypto-parameters • Systems evolve: • Crypto-systems become breakable • Newer crypto-systems demand larger resources. • Potential Security Flaw • Negotiating in bad faith, insisting on breakable crypto-suites.

10. Communication Security • Endpoint identifier hiding • Establish secure tunnel (via Diffie Hellman) first. • Then authenticate. • Man-in-the-middle gets caught in the second step. • Can only find out one identity.

11. IPSec • RFC 1636 identified key areas where the internet needs to be made more secure. • Spoofing: Creating packets with false addresses. • Eavesdropping / packet sniffing. • True for both IPv4 and IPv6.

12. IPSec • Implemented below the transport layer. • No application needs to be rewritten. • Is part of the OS.

13. IPSec • Provides confidentiality for IP connections • Allows implementation of access policies • Authenticates source IP addresses • But not users.

14. IPSec • Transport Mode • Adds IPSec information between IP Header and remainder of packet. • Tunnel Mode • Encapsulates the original IP header and packet. • Adds new IP header and IPSec header IP Header IPSec Header IP-payload: Old rest of packet

15. IPSec • An IPSec packet in tunnel mode completely encapsulates the payload. • IP Header is either an • AH: Authentication Header • ESP: Encapsulating Security Payload that tells the user which Security Association to use.

16. IPSec • Developed by the Internet Engineering Task Force IETF • Architecture • ESP (Encapsulating Security Payload) • AH (Authentication Header) • Encryption Algorithm • Authentication Algorithm • Key Management • DOI (Domain of Interpretation) (How to fit the work together.)

17. IPSec • Security Association • Cryptographically protected connection. • Paradigm to manage authentication and confidentiality between sender and receiver. • Unidirectional. • IPSec header contains SPI (Security Parameter Index) that identifies the security association. • Allows partner to look up the necessary data such as the key in SA database.

18. IPSec • Security Association Database • When X transmits to Y in IPSec, X looks up Y in the SA database. • Provides key • Provides SPI • Security Parameter Index • Provides algorithms to be used • Provides sequence number • When Y receives a transmission, Y uses the SPI and the destination address to find the SA.

19. IPSec • Security Policy Database • Specifies what to do with packets: • Dropping • Forwarded and accepted without IPSec protection • Forwarded and protected by IPSec • Decision based on fields in the IPsec packet.

20. IPSec • Two types of IPsec headers. • AH • Authentication header. • Provides integrity protection only. • Allows firewalls to peek at TCP ports. • ESP • Encapsulating Security Payload • Optional integrity protection • Optional encryption

21. IPSec • Two modes • Transport mode • Adding IPsec information between IP header and remainder of package. • Tunnel mode • Keeps the original IP packet intact, but put it into a new packet with new IP header and IPsec data.

22. IPSec • Transport mode versus Tunnel mode

23. IPSec IPsec in tunnel mode for a VPN: IP: src=R1, dst=R2 | ESP | IP: src=A, dst=B | packet

24. IPSec • NAT • Network address translation • NAT boxes takes IP traffic from the outside. • Based on port number, repackages packet to be send to an internal address and vice versa. • Allows organization to make to do with few IP addresses.

25. IPSec • NAT • Have difficulties with incoming calls to dynamic hosts. • Need to maintain routing table dynamically. • Usually, need to be application-aware. • Function as a limited, package-based firewall.

26. IPSec • NAT • Have difficulties with programs like FTP. • FTP uses normally two channels: command channel and data channel. • Client opens command channel. • Packet to port 21, informs server of port on which it is listening. • Server responds by opening a data channel from port 20 to the client’s listening port. • PASV mode: • Client sends PASV command to server. • Server starts to listen on random port, gives port to client in respond to PASV. • Client opens data channel to the new port.

27. IPSec • AH Header • Next header: position of protocol field of encapsulated package • Payload length: Size of AH header in words. • SPI (Security Parameter Index) • Sequence number: Used by AH to recognize replayed packages. Not identical with TCP package number. • Authentication data: Cryptographic integrity check on the payload data.

28. IPSec • AH • Some IP header fields get reset by NATs and routers. • Mutable fields are not covered by the integrity check and can be changed by routers: • Type of service • Flags • Fragment offset • Time to live • Header checksum • Immutable fields cannot be changed: • Payload length • Needed to reassemble fragmented AH packets.

29. IPSec • AH • Immutable fields • Destination address is protected by AH. • NAT will change the destination address. • Hence, IPSec /AH and NAT do not work well together. • There is no way to predict the change at the source. • In source routing, routers change the destination address to the next field specified by source routing. • AH can predict the destination address. • An example of a mutable, but predictable field.

30. IPSec • ESP (Encapsulating Security Payload) • SPI • Sequence Number (same as for AH) • IV Initialization Vector (used by some cryptographic algorithms • Data: protected data, possibly encrypted • Padding: needed to make data multiple of block size. • Padding length • Next header: Protocol field in IPv4 or next header in IPv6 • Authentication data: Cryptographic integrity check.

31. IPSec • AH protects the IP header itself. • ESP protects everything beyond the ESP header. • Hence: AH provides additional (but useless?) protection. • AH is less likely to fall under export restrictions.

32. IPSec • TF-ESP (Transport-friendly ESP) • Proposal to copy fields of interest of the original header in clear. • Firewalls and routers can look at these information. • Potential for information leak. • Firewalls should not look at any data above layer 3. • But of course, they now do. • IPSec protection is end-to-end, and intermediate routers / firewalls cannot trust the cleartext copies of these fields.

33. IPSec: IKE • Internet Key Exchange • Needed for • mutual authentication • to set up an SA • … • Compromise based on Photuris and Skip

34. Photuris • Uses Cookies • Different from web browser cookies. • When Alice connects to Bob, Bob chooses a cookie and sends it to Alice. • Bob only honors further requests from Alice with the cookie. • Foils very simple DoS attacks. • To keep cookie stateless, the cookie is a function of Alice’s address and a secret known by Bob only.

35. Photuris CA CA, CB, crypto CA, CB, gb mod p, crypto selected CA, CB, gb mod p CA, CB, {Alice, sig of prev. message} gab mod p Alice Bob CA, CB, {Bob, sig of prev. message} gab mod p

36. Photuris • Alice chooses cookie CAin order to keep different login attempts separated. • Bob uses a stateless cookie CB in order to keep DoD attacks at bay. • Messages 3 and 4 consists of a Diffie-Hellman encryption. • Messages 5 and 6 serve for authentication. Encrypted with Diffie-Hellman key.

37. Photuris CA CA, CB, crypto CA, CB, gb mod p, crypto selected CA, CB, gb mod p CA, CB, {Alice, sig of prev. message}[gab mod p] Alice Bob CA, CB, {Bob, sig of prev. message}[gab mod p]

38. SKIP • Simple Key Management for Internet Protocols • Principals have • Certified Diffie-Hellman public keys gamod p • Long-time use • Private key a. • Alice wants to talk to Bob: • Alice takes Bob’s public key gband raises it to the ath power. • Bob takes Alice’s public key ga and raises it to the bth power. • Both share the secret gabmod p.

39. SKIP • SKIP derives a key KAlice,Bob from the mutually shared secret between Alice and Bob. • Such as the lower bits of gabmod p. • Each packet is encrypted / authenticated with a randomly generated key Kpacket. • The key Kpacket is encrypted with KAlice, Bob and added to the packet. • The header of the packet is in clear text.

40. SKIP • SKIP packet

41. SKIP • Changing a principal’s key is a difficult, but needed operation. • Minimizes exposure of the key and makes crypt-analysis more difficult. • Updating the master key prevents reusing compromised traffic keys. • Each new key needs to be certified.

42. SKIP • Make the master key KAlice,Bob dependent on a version that automatically updates: KAlice,Bob = hash(gab,counter-value) • Allows still principals to get a brand-new certified key. • Prevents some replay attacks.

43. IPSec: IKE • Phases • Phase 1: • Does mutual authentication and establishes session keys. • Known as KSAKMP SA / IKE SA • Phase 2: • Establishes an ESP or AH SA • Phase 1 is necessarily expensive. • The two phases try to have phase 2 profit from a phase 1 interchange used for another protocol, connection, …

44. IPSec: IKE • Phase 1 IKE: • Aggressive mode • Use a single crypto-proposal • Main mode • Negotiate the strongest crypto-proposal that both parties can agree to.

45. IPSec: IKE • Phase 1 Aggressive Mode: ga, Alice, crypto-proposal gb, crypto-choice, Proof that I’m Bob. Bob Alice Proof that I’m Alice

46. IPSec: IKE • Phase 1 Main Mode: crypto-suites I support Crypto suites I choose. ga Alice Bob gb gab{Alice, Proof that I’m Alice} gab{Bob, Proof that I’m Bob}

47. IPSec: IKE • Key Types • Pre-shared secret • Public key for encryption / decryption • Public key for signing • 8 variants of Phase 1!!!

48. IPSec: IKE • Phase 1 establishes two session keys: • Integrity key • Encryption key for the last exchange in phase 1 and all exchanges in phase 2. • Establishes a pair of cookies to keep different sessions different.

49. IPSec: IKE • Phase 1 protocols • Read them!

50. IPSec: IKE • Phase 2: A.k.a. quick mode. • Uses a pair X of cookies generated in phase 1. • Session nonce for phase 2 session. • All messages are encrypted with Phase 1 encryption key SKEYID_e • All messages are integrity protected with Phase 1 intergrity key SKEYID_a. • Can be initiated by either participant of Phase 1.