1 / 71

COEN 350

COEN 350. IPSec, SSL, SSH,. 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. Communication Security. Session Key Establishment

vernon
Download Presentation

COEN 350

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related