1 / 43

Implementing and Testing IPsec: NIST’s Contributions and Future Developments

Implementing and Testing IPsec: NIST’s Contributions and Future Developments. Sheila Frankel Systems and Network Security Group NIST sheila.frankel@nist.gov. An SAT-type Analogy: The Question. IPsec : Security a) foundation : house b) hammer : nail c) electron : chemistry

snow
Download Presentation

Implementing and Testing IPsec: NIST’s Contributions and Future Developments

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. Implementing and Testing IPsec:NIST’s Contributionsand Future Developments Sheila Frankel Systems and Network Security Group NIST sheila.frankel@nist.gov

  2. An SAT-type Analogy:The Question IPsec : Security a) foundation : house b) hammer : nail c) electron : chemistry d) government : progress

  3. Topics • Overview of IPsec • NIST’s IPsec Reference Implementations • NIST’s IPsec Web-Based Interoperability Tester (IPsec-WIT) • Current Status of IPsec • Future Directions of IPsec

  4. At Which Network Layer Should Security Be Provided? • Application Layer • Transport (Sockets) Layer • Internet Layer

  5. Why Internet Layer Security? • Implement once, in a consistent manner, for multiple applications • Centrally-controlled access policy • Enable multi-level, layered approach to security

  6. Internet Packet Format IP Header Upper Protocol Headers and Packet Data

  7. Types of Security Provided by IPsec • Data Origin Authentication • Connectionless Integrity • Replay Protection • Confidentiality (Encryption) • Traffic Flow Confidentiality

  8. Authentication Header (AH) • Data origin authentication • Connectionless integrity • Replay protection (optional) • Transport or tunnel mode • Mandatory algorithms: • HMAC-MD5 • HMAC-SHA1 • Other algorithms optional

  9. New IP Header AH Header Old IP Header Upper Protocol Headers and Packet Data Internet Packet Format with AH IP Header AH Header Upper Protocol Headers and Packet Data • Transport Mode • Tunnel Mode

  10. Encapsulating Security Payload (ESP) • Confidentiality • Limited traffic flow confidentiality (tunnel mode only) • Data origin authentication • Connectionless integrity • Replay protection (optional) • Transport or tunnel mode

  11. Encapsulating Security Payload (ESP) (continued) • Mandatory algorithms: • DES-CBC • HMAC-MD5 • HMAC-SHA1 • Null Authentication algorithm • Null Encryption algorithm • Other algorithms optional

  12. Internet Packet Format with ESP IP Header ESP Header Upper Protocol Headers and Packet Data • Transport Mode New IP Header ESP Header Old IP Header Upper Protocol Headers and Packet Data • Tunnel Mode

  13. Transport vs. Tunnel Mode

  14. Constructs Underlying IP Security • Security Association (SA) • Security Association Database (SAD) • Security Parameter Index (SPI) • Security Policy Database (SPD)

  15. Internet Key Exchange (IKE) • Negotiate: • Communication Parameters • Security Features • Authenticate Communicating Peer • Protect Identity • Generate, Exchange, and Establish Keys in a Secure Manner • Delete Security Associations

  16. Internet Key Exchange (IKE) (continued) • Threat Mitigation • Denial of Service • Replay • Man in Middle • Perfect Forward Secrecy • Usable by IPsec and other domains

  17. Internet Key Exchange (IKE) (continued) • Components: • Internet Security Association and Key Management Protocol (ISAKMP) • Internet Key Exchange (IKE, aka ISAKMP/Oakley) • IP Security Domain of Interpretation (IPsec DOI)

  18. IKE Negotiations - Phase 1 • Purpose: • Establish ISAKMP SA (“Secure Channel”) • Steps (4-6 messages exchanged): • Negotiate Security Parameters • Diffie-Hellman Exchange • Authenticate Identities • Main Mode vs. Aggressive Mode

  19. IKE Negotiations - Phase 2 • Purpose: • Establish IPsec SA • Steps (3-5 messages exchanged): • Negotiate Security Parameters • Optional Diffie-Hellman Exchange • Final Verification • Quick Mode

  20. NIST’s Contributions to IPsec • Cerberus - Linux-based reference implementation of Ipsec • PlutoPlus - Linux-based reference implementation of IKE • IPsec-WIT - Web-based IPsec interoperability test facility

  21. NIST’s Contributions to Ipsec (continued) • Goals: • Enable smaller industry vendors to jump-start their entry into IPsec • Facilitate ongoing interoperability testing of multiple IPsec implementations

  22. IPsec-WIT: Motivation • Inter-operability of multiple implementations essential for IPsec to succeed • Existing test modalities • Interoperability “Bake-offs” • Pre-planned Web-based interoperability testing • Needed: spontaneous Web-based testing

  23. User-Related Objectives • Accessible from remote locations • Available at any time • Require no modification to the tester’s IPsec implementation • Allow testers to resume testing at a later time • Configurable • Well-documented • Easy to use

  24. Implementation Objectives • Simultaneous access by multiple users • Rapid, modular implementation • Easily modified and expanded as IPsec/IKE specifications evolve • Built around NIST’s IPsec/IKE Reference Implementations, Cerberus and PlutoPlus

  25. Implementation Objectives(continued) • Require minimal changes to Cerberus and PlutoPlus • Operator intervention not required

  26. NIST PlutoPlus State Files Test Suites IPsec-WIT Architecture IPsec WIT Web Browser WWW-based Tester Control (HTML/CGI) HTML Docs., Forms, and HTTP Server IKE Negotiation Message logging and IKE Configuration Local IUT Configuration IUT PERL CGI Test Engine Negotiated SAs and SA mgmt. messages Manual SAs and IP/IPsec Packet Traces Linux Kernel IP + NIST Cerberus IPsec Encapsulated IP Packets INTERNET

  27. Implementation • Perl cgi-bin tester • HTML forms • Executable test cases • Output • PlutoPlus: tracing the IKE negotiation • Cerberus: dumping the ping packets • expect command: color-coded output

  28. Implementation(continued) • Individual tester files • Tester-specific parameters • Tester’s individual output • Storage and expiration

  29. Current Capabilities • Key establishment: manual or IKE negotiation • IKE negotiation: Initiator or Responder • Peer authentication: pre-shared secrets • ISAKMP hash: MD5 or SHA • ISAKMP encryption: DES or 3DES • Diffie-Hellman exchange: 1st Oakley group

  30. Current Capabilities(continued) • Configurable port for IKE negotiation • IPsec AH algorithms: HMAC-MD5 or HMAC-SHA1 • IPsec ESP algorithms: • Encryption: DES, 3DES, IDEA, RC5, Blowfish, or ESP-Null • Authentication (optional): HMAC-MD5 or HMAC-SHA1 • Variable key length for RC5 and Blowfish

  31. Current Capabilities(continued) • IPsec encapsulation mode: transport or tunnel • Perfect Forward Secrecy (PFS) • Verbosity of IKE/IPsec output configurable • IPsec SA tested using “ping” command • Transport-mode SA: host-to-host

  32. Current Capabilities(continued) • Tunnel-mode SA:host-to-host or host-to-gateway • Host-to-gateway SA tests communications with tester’s host behind gateway • Sample test cases for testers without a working IKE/IPsec implementation • Current/cumulative test results can be viewed via browser or emailed to tester

  33. Limitations • Re-keying • Crash/disaster recovery • Complex policy-related scenarios

  34. Lessons Learned • Voluntary interoperability testing is useful and used • Interoperability tests can also serve as conformance tests • Stateful protocols can be tested using a Web-based tester • “Standard” features are more useful than “cutting edge”

  35. Lessons Learned(continued) • Some human intervention is required • Productive and informative multi-protocol interaction is challenging • Users do the “darnedest” - and most unexpected - things

  36. Future Horizons - PlutoPlus • Additional Diffie-Hellman groups • More complex policy options • Multiple proposals • Adjacent SA’s • Nested SA’s • Peer authentication: public key • PKI interaction and certificate exchanges

  37. Future Horizons - IPsec-WIT • Test IPsec SA’s with UDP/TCP connections, rather than ICMP • Better diagnostics from underlying protocols

  38. Futuristic Horizons • Negative testing • Robustness testing

  39. Current Status of IPsec • Basic IPsec and IKE functionality defined in RFC’s • Add-ons and additional functionality defined in Internet Drafts • Numerous IPsec implementations in hardware and software • Periodic interoperability/conformance testing at IPsec “Bake-offs”

  40. Current Status of IPsec(continued) • Deployed in Auto Industry Networks (ANX and ENX) • Used for Virtual Private Networks (VPNs)

  41. Future Directions of IPsec • PKI profiles for IPsec • Policy configuration and control (IPSP) • Secure remote access (IPSRA) • Transport-friendly ESP (TF-ESP)

  42. An SAT-type Analogy:The Answer ?? To Be Announced ??

  43. Contact/Usage Information • IPsec-WIT: http://ipsec-wit.antd.nist.gov • Cerberus documentation: http://www.antd.nist.gov/cerberus • PlutoPlus documentation: http://ipsec-wit.antd.nist.gov/newipsecdoc/pluto.html • For further information, contact: • Sheila Frankel: sheila.frankel@nist.gov • Rob Glenn: rob.glenn@nist.gov

More Related