1 / 36

Internet Key Exchange

Internet Key Exchange. IPSec – Reminder. SAD. IPSec – Reminder SA. Security Association Database (SAD) holds SA’s Security Associations (SA) is a one way , cryptographically protected connection between a sender and a receiver that affords security services to traffic. Alice. Bob.

Samuel
Télécharger la présentation

Internet Key Exchange

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. Internet Key Exchange

  2. IPSec – Reminder SAD

  3. IPSec – ReminderSA • Security Association Database (SAD) holds SA’s • Security Associations (SA) is a one way, cryptographically protected connection between a sender and a receiver that affords security services to traffic

  4. Alice Bob

  5. IPSec – ReminderSA SA contains the fields: • protocol identifier (ESP or AH) • mode (tunnel or transport) • algorithms for encryption/ decryption/ authentication and their respective keys • lifetime • SPI’s • sequence number

  6. IPSec – ReminderWhere does IKE fit in? SA’s building and managing is either: • Static (manual) – keys and other attributes of SA are manually configured by system administrator. Practical for small, relatively static environments. • Dynamic (automated) – On-demand creation of keys. Handled by IKE protocol

  7. IKE • IKE is a protocol that builds and manages IPSec SA’s between two computers that implement IPSec. • IKE is the only standard protocol for building IPSec SA’s (Standard IPSec implementation must also implement IKE) • IKE (like IPSec) is carried out either between a pair of hosts, a pair of security gateways or a host and a security gateway

  8. IKE • IKE is a protocol that builds and manages IPSec SA’s between two computers that implement IPSec. • IKE is the only standard protocol for building IPSec SA’s (Standard IPSec implementation must also implement IKE) • IKE (like IPSec) is carried out either between a pair of hosts, a pair of security gateways or a host and a security gateway

  9. Endpoint to Endpoint Transport • Both endpoints of the IP connection implement IPsec • Used with no inner IP header • One of the protected points can be behind a NAT node Protected Endpoint Protected Endpoint IPsec Tunnel

  10. Gateway to Gateway Tunnel • Neither point of the IP connection implements IPsec, but network nodes between them protect traffic for part of the way • Protection is transparent to the endpoints • The inner IP header contains the IP addresses of the actual endpoints IPsec Tunnel Protected Subnet Protected Subnet gateway gateway

  11. Endpoint to Gateway Transport • A protected endpoint (typically a portable roaming computer) connects back to its corporate network through an IPsec protected tunnel • The protected endpoint will want an IP address associated with the gateway so that packets returned to it will go to the gateway and be tunneled back • The protected endpoint may be behind a NAT Protected Subnet and/or Internet Protected Endpoint IPsec Tunnel gateway

  12. expectations from IKE • Secrecy and authenticity • Protection against replay attacks • Scalability (being suitable for big networks) • Privacy and anonymity (protecting identity of players in the protocol) • Protection against DOS • Efficiency (both computational and minimal in the number of messages) • Independence of cryptographic algorithms • Minimize protocol complexity • Reliability

  13. Key Exchange Protocols • Key exchange protocols goal is to agree on a shared key for the two participant • Should implement - authenticity - secrecy

  14. Long and Short Term Keys • To support authenticity parties should know a mutual secret key. This key is called long term key. • The keys negotiated in the protocol are called short term keys. • There are two types of long term keys: • Pre-shared secret • Public/private keys

  15. Long and Short Term Keys Why the need for short term keys? • It is not advisable to encrypt a lot of data with the same key • It is advisable to separate between encryption keys and authentication keys Why not sending the new key encrypted using the long term key? • PFS

  16. PFSPerfect Forward Secrecy • Exposure of long term keys will not entail exposure of short term keys that are created in the current execution of the protocol • PFS is optionally provided in IKE (detailed later)

  17. IKE version 1 • IKE version 1 is a hybrid of three protocols (actually a framework and two protocols) • Version 1 grew out of ISAKMP framework and OAKLEY and SKEME protocols that work within that framework.

  18. ISAKMP (IKE version 1) Stands for “Internet Security Association and Key Management” Protocol Created by NSA (National Security Agency) Framework (not really a protocol) for authentication and key exchange. This framework decides on the SA’s attributes the parties will use.

  19. ISAKMP (IKE version 1) • Designed to be key exchange independent (supports many different key exchanges) • In IKE version 1 ISAKMP uses part of OAKLEY and part of SKEME.

  20. SKEME (IKE version 1) • Describes a versatile key exchange technique Provides: • anonymity • repudiability • quick key refreshment

  21. OAKLEY (IKE version 1) • Describes a series of key exchanges and details the services provided by each • Based on Diffie-Hellman algorithm but providing added security • Generic in that it does not dictate specific formats

  22. OAKLEY (IKE version 1) Characterized by five important features: • Cookies to prevent clogging attacks • Negotiation of a group (specifying global parameters of DH) • Use of nonces to ensure against replay attacks • Exchange of public key values • Authentication of DH to prevent man-in-the-middle attacks

  23. Diffie-Hellman Groups • A group for the DH key exchange specifies the global parameters of DH. • Each group includes the definition of 2 global parameters and the identity of the algorithm • Three of these groups are classic DH algorithm using modular exponentiation

  24. Diffie-Hellman – groups id=1,2,5 All these three groups (id=1,2,5) have: • Generator = 2 For group id=1: • Prime = 2^768 - 2^704 – 1 + 2^64 * { [2^638 pi] + 149686} For group id=2: • Prime = 2^1024 - 2^960 – 1 + 2^64 * { [2^894 pi] + 129093} For group id=5: • Prime = 2^1536 - 2^1472 – 1 + 2^64 * { [2^1406 pi] + 741804}

  25. Diffie-Hellman – groups id=3,4 • Over galois fields using elliptic curves.

  26. IKE Version 2 From this point on we focus on IKE version 2 • IKE version 2 is a single protocol rather than three that cross reference one another and is described in a single self-contained document

  27. Main benefits of IKE Version 2over Version 1 IKEv2 preserves most of the features of IKEv1. The idea behind IKEv2 was to make it as easy as possible for IKEv1 implementations to be modified for IKEv2. • Later we will see that IKE is a two-phase protocol. Version 2 greatly simplified IKE by replacing the 8 possible phase 1 exchanges with a single exchange. • This single exchange provides identity hiding in 2 round trips rather than 3 in version 1

  28. Main benefits of IKE Version 2over Version 1 • Version 2 decreased latency by allowing setup of SA to be piggybacked on the initial exchange • Version 2 increased security by allowing responder to be stateless until initiator can receive at claimed IP address

  29. Side benefits of IKE Version 2over Version 1 • cryptographic syntax replaced with one simplified syntax • a few fields were removed (ex: DOI, SIT) • possible error states reduced

  30. Details and variations • IKE normally listens on UDP port 500, though may also be received on port 4500 with a slightly different format

  31. Reliability IKE is a reliable protocol. • Initiator responsible for retransmission in the event of timeout, therefore must remember each request until it receives the corresponding response • Responder retransmits a response only when it receives retransmission , therefore must remember each response until it receives a request with a larger sequence number plus window size • On failure all states associated with SA are discarded

  32. Reliability • IKE definition includes recovery from transmission error: packet loss, packet replay, packet forgery

  33. Functionality • IKE is designed to function so long as: • at least one of a series of retransmitted packets reaches its destination before timing out • channel not full of forged or replayed packets (exhausting network or CPU) • Even if these two minimum requirements are absent, IKE fails cleanly as though the network was broken

  34. NAT Traversal • IPsec through a NAT introduces problems. • protocols which include IP addresses of endpoint within the payload (like IPSec) necessitate that NAT understands the protocol and modify the internal references and those in the headers • In transport mode changing IP address will cause checksums to fail. In tunnel mode there are routing problems.

  35. NAT Traversal • For that reason, IKE supports UDP encoding that is easier for NATs to process • It is less efficient but is easier for NAT to process • This is where port 4500 comes in. When working through a NAT it is better to pass IKE packets over port 4500 which runs the NAT-friendly protocol.

  36. To Sum Up Overview We talked about: IPSec SAs what roles IKE play Design issues Key exchange protocols: long/short terms keys, pfs version 1: structure and features version 2 Reliability Terms of functionality NAT friendly protocol

More Related