1 / 23

Internet Security CSCE 813 IPsec

Internet Security CSCE 813 IPsec. Reading. Today: Oppliger: IPSec: Chapter 14 Stalllings: Network Security Essentials, 3 rd edition, Chapter 6 Related readings (not required) IPSec Architecture RFC 2401 ISAKMP RFC 2408 IKE RFC 2409 HMAC RFC 2104. IPSec Overview.

makani
Télécharger la présentation

Internet Security CSCE 813 IPsec

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 Security CSCE 813IPsec

  2. Reading • Today: • Oppliger: IPSec: Chapter 14 • Stalllings: Network Security Essentials, 3rd edition, Chapter 6 Related readings (not required) • IPSec Architecture RFC 2401 • ISAKMP RFC 2408 • IKE RFC 2409 • HMAC RFC 2104 CSCE 813 - Farkas

  3. IPSec Overview IPSec can be added to either IPv4 or IPv6 Supported functionalities: authentication, confidentiality, and key management Scope of authentication: entire packet (tunnel mode) or entire packet minus the IP header (transport mode) Confidentiality: can be supported in either mode. Flexible Key Management CSCE 813 - Farkas

  4. Internet Key Exchange

  5. IKE • Goal: create security association between 2 hosts • Two phases: • 1st phase establishes security association (IKE-SA) for the 2nd phase • Always by authenticated Diffie-Hellman (expensive) • 2nd phase uses IKE-SA to create actual SAs to be used by AH and ESP • Use keys derived in the 1st phase to avoid DH exchange • Operates only in “quick” mode • To create a fresh key, hash old DH value and new nonces CSCE 813 - Farkas

  6. Properties What properties are needed? • Authentication • Secrecy • Forward Secrecy (Perfect FS) • Prevent replay of old key material • Prevent denial of service • Protect identities from eavesdroppers CSCE 813 - Farkas

  7. Key Management in IPSec • Manual key management • System administrator manually configures each system with its own keys – not scalable • Automated key management • On-demand creation of keys for the SAs – scalable for large, distributed systems CSCE 813 - Farkas

  8. Internet Key Exchange • ISAKMP/Oakley • Oakley key determination protocol • Based on Diffie-Hellman • Added security (e.g., authentication) • Does not dictated specific format • ISAKMP – Internet Security Association and Key Management Protocol • Framework for key management • Specific protocol support (format, negotiation, etc.) CSCE 813 - Farkas

  9. A B Diffie-Hellman Key Exchange • Prior agreement of two parameters: g and p • A selects random integer a, B selects random integer b • Protocol ga mod p gb mod p Alice, Bob compute gab mod p not known to anyone else CSCE 813 - Farkas

  10. Problems with DH • No information about identities • Subject to a man-in-the-middle type attack • Computationally extensive: vulnerable to a clogging attack • Attacker sends fake DH messages to a victim from a forged IP address • Victim starts performing modular exponentiations to compute a secret key • Victim can be blocked with useless work CSCE 813 - Farkas

  11. Added Security Features of Oakley • Cookie exchange: thwart clogging attacks • Properties: depends on specific parties, impossible to anyone else to generate cookies, fast • hash(src IP addr, dst IP addr, src UDP port, dst UDP port, local secret) • Ensure that the responder is stateless until initiator produced at least 2 messages • Responder’s state (IP addresses and ports) is stored in an un-forgeable cookie and sent to initiator • After initiator responds, cookie is regenerated and compared with the cookie returned by the initiator • The cost is 2 extra messages in each execution CSCE 813 - Farkas

  12. Added Security Features of Oakley • Nonces: detect replay attacks • Authenticates the DH exchange • Digital signatures, public key encryption, or symmetric key encryption • Support negotiation of the global parameters for the DH exchange • DH groups: global parameters and identity of algorithms CSCE 813 - Farkas

  13. Key Exchange • Identities: not secret • Derived key: PFS • Two modes: • Main mode: 5 messages, protects IDs • Aggressive mode: 3 messages, does not protect IDs • Multiple variations, see The OAKLEY Key Determination Protocol, http://tools.ietf.org/html/rfc2412 CSCE 813 - Farkas

  14. Aggressive Oakley Example I  R: CKYI ,OK_KEYX , GRP , gx , EHAO , NIDP, IDI , IDR , NI , SKI[ IDI || IDR || NI || GRP || gx || EHAO] R  I: CKYR , CKYI , OK_KEYX , GRP , gy , EHAS , NIDP, IDR , IDI , NR , NI , SKR[ IDR || IDI || NR || NI || GRP || gx || gy || EHAS] I  R: CKYI , CKYR, OK_KEYX , GRP , gx , EHAS, NIDP , IDI , IDR , SKI[ IDI || IDR || NI || NR || GRP || gx || gy || EHAS] • CKYI: I’s cookie • OK_KEYX: key exchange message type • GRP: DH group, gx, gy: public key of init. and resp., gxy: session key • EHAO/EHAS: encryption, hash, authentication alg. offered/selected • NIDP: indicates encryption is not used for remainder of this message • N: nonce, ID: identifier, • SKI[X] CSCE 813 - Farkas

  15. ISAKMP • Defines procedures and packet formats to • Establish • Negotiate • Modify • Delete security associations CSCE 813 - Farkas

  16. Initiator cookie Responder cookie Next payload Mj ver Mn Ver Exchange type Flags Message ID Length Next payload Reserved Payload length payload ISAKMP Header Format ISAKMP header Generic payload header CSCE 813 - Farkas

  17. Payload Types • Security Association (SA) • Proposal (P) – info used during SA negotiation, e.g., protocol type, sender’s SPI, # of transforms • Transform (T) – defines the security transform to be used, transform # (ids the payload), transform id (specific transforms) • Key exchange (KE) – key exchange techniques • Identification (ID) – identity of the communicating peers • Certificate (CR) – public-key certificate (X.509. Kerberos, etc.) • Hash (HASH) • Signature (SIG) • Nonce (NONCE) • Notification (N) • Delete (D) CSCE 813 - Farkas

  18. Base Exchange • Allows key exchange and authentication material to be transmitted together • Minimizes number of exchanges • Does not provide ID protection • Protocol: • I  R : SA; NONCE • R  I : SA; NONCE • I  R : KE; IDI; AUTH • R  I : KE; IDR; AUTH 1-2: cookies + SA establish; nonce: replay protection 3-4: key materials and IDs CSCE 813 - Farkas

  19. Identity Protection Exchange • Expands the Base exchange to protect user IDs. • Protocol: • I  R : SA • R  I : SA • I  R : KE; NONCE • R  I : KE; NONCE • I  R : IDI; AUTH • R  I : IDR; AUTH 1-2: establish SA 3-4: key exchange + replay protection 5-6: authentication + optional certificate CSCE 813 - Farkas

  20. Authentication Only Exchange • Perform mutual authentication without key exchange • Protocol: • I  R : SA; NONCE • R  I : SA; NONCE; IDR; AUTH • I  R : IDI; AUTH 1-2: establish SA + responder send his/her ID + authenticate the msg. 3: I’s authenticated ID CSCE 813 - Farkas

  21. Aggressive Exchange • Minimize number of exchanges • Does not provide ID protection • Protocol: • I  R : SA; KE; NONCE; IDI • R  I : SA; KE; NONCE; IDR; AUTH • I  R : AUTH 1:I proposes an SA + begins key exchange + I’s ID. 2: R indicates acceptance of SA + completes key exchange + authentication 3: Authentication CSCE 813 - Farkas

  22. Informational Exchange • One-way transmittal of information for SA management • Error or status notification • Invalid payload type, invalid protocol ID, payload malformed, authentication failed, invalid signature, etc. • Connected, responder-lifetime, replay status, initial contact • Protocol • I  R : N/D CSCE 813 - Farkas

  23. Next Class: Transport layer security CSCE 813 - Farkas

More Related