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. • Works 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 • 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 • AH Header • Next header: protocol of encapsulated package • Payload length: Size of AH header in words. • SPI • Sequence number: Used by AH to recognize replayed packages • Authentication data: Cryptographic integrity check on the payload data.

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

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

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

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

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

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

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

22. SKIP • Simple Key Management for Internet Protocols • Principals have • Certified Diffie-Hellman public keys gamod p • 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.

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

24. SKIP • SKIP packet

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45. Secure Shell: SSH • Client contacts server. • Client and server disclose the SSH versions they support. • Client and server switch to a packet based protocol. • Packet consists of • 4B length, • 1-8B of random padding, • one-byte packet type code, • packet payload data, • four-byte integrity check field.

46. Secure Shell: SSH • Server identifies itself by sending • Host key • Server key • 8 random bytes (use as cookie) • List of encryption, compression, authentication methods. • Both sides compute a 128b session identifier.

47. Secure Shell: SSH • When the client receives the host key, the client looks into the known host database. • If the host key matches the one in the database then the client proceeds. • If the host is in the database but with a different key, then the client queries the user. • Otherwise, the client warns the user and proposes to add host and key to the known host database.

48. Secure Shell: SSH • Client randomly generates a session key. • Clients sends the session key encrypted with the server key and then with the host’s public key. • Together with the choice of crypto-suites. • Both sides now use the session key for encryption. • Server sends confirmation message encrypted with the session key. • This proves the server’s authenticity to the client.

49. Secure Shell: SSH • Authentication phase starts: • SSH1 tries out • Kerberos • Rhosts • RhostsRSA • Public key • TIS • Password

50. Secure Shell: SSH