COEN 350

1. COEN 350 IPSec, SSL, SSH,

2. 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.

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

4. 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.

5. 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.)

6. 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.

7. IPSec • Security Association Database • When X transmits to Y in IPSec, X looks up Y in the SA database. • Provides key • Provides SPI • 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.

8. 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.

9. 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

10. 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.

11. IPSec • Transport mode versus Tunnel mode

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

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. IPSec • ESP • 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.

20. 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.

21. 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.

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

23. 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.

24. 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

25. 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.

26. 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]

27. 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.

28. 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.

29. SKIP • SKIP packet

30. 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.

31. 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.

32. 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, …

33. 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.

34. 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

35. 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}

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

37. 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.

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

39. 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.

40. IPSec: IKE X,Y, Crypto-protocol, SPIA, nonceA, Alice Bob X,Y, Crypto-protocol accepted, SPIB, nonceB X, Y Ack SPI: Security Parameter Index

41. Secure Socket Layer • 1995: deployed in Netscape Navigator as SSLv2. • 1995: Microsoft fixes SSLv2 and introduces a similar protocol • Private Communication Technology (PCT) • 1996: Netscape introduces SSLv3 • 1999: IETF introduces Transport Layer Security. • SSLv3 remains the most implemented protocol.

42. Secure Socket Layer • SSL is built on top of TCP. • TCP provides reliable packet delivery. • Rogue packet problem: • Maliciously introduced TCP packet. • Easy to do, since it only needs to satisfy the non-cryptographic TCP checksum. • SSL disregards the package. • TCP however will not accept the true packet, because it looks like a double to it. • SSL will have to start over.

43. Secure Socket Layer • Various keys are formed from various random numbers exchanged during the protocol. • Negotiate crypto-protocols.

44. Secure Socket Layer • SSL sessions are long-lived. • Many SSL connections can be derived from an SSL session.

45. Secure Socket Layer:Session Connection Hello. Ciphers I support. RAlice Alice Bob Certificate. Ciphers I choose. RBob {S}Public Key of Bob. {Keyed Hash of Messages} {Keyed Hash of Messages} S is a random number, the pre-master secret. K is the master secret, calculated from RAlice, RBob, S

46. Secure Socket Layer:Session Resumption • If Bob wants to have multiple connections per session, he sends in Message 2 a session id. • If Alice presents in Message 1 a session id, they skip the handshake. • Alice can still negotiate ciphers with Bob who might have changed policies. Session ID. Ciphers I support. RAlice Alice Bob Session ID. Certificate. Ciphers I choose. RBob {Keyed Hash of Messages}

47. Secure Socket Layer • SSL comes deployed with public keys of various trusted organizations. • User can modify this list. • User verifies public keys by sending certificate requests to the organizations in the list.

48. Secure Socket Layer • SSLv3 upgrades: • Protects against the “downgrade attack” • Active attacker replaces the initial messages with ones containing weak crypto. • Protects against the “truncation attack” • Active attacker sends a TCP close (FIN) message. • TCP is not protected, so the connection is abnormally terminated without SSL being aware of it.

49. Secure Shell: SSH • SSH client and server are applications (running on top of OS). • SSH consists of a bunch of applications. • But SSH is not a UNIX shell.

50. Secure Shell: SSH • Provides • Authentication • Encryption • Integrity