CERBERUS

1. CERBERUS An IPsec Reference Implementation Rob Glenn Rob.Glenn@nist.gov

2. IPsec & IKE • IPsec is defined by the following sets of specifications: • Security Architecture For IP • Authentication Header Protocol (AH) • Encapsulated Security Protocol (ESP) • Internet Key Exchange (IKE) • Algorithms NIST/ITL/ANTD

3. Security Architecture For IP • “…to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6”. • Offers access control, connectionless integrity, data origin authentication, protection against replays, confidentiality, and limited traffic flow confidentiality. • Provides host-to-host, router-to-router, and host-to-router security services. • Independent of any particular algorithms. • Secure communications between two systems is defined by Security Associations (SAs). NIST/ITL/ANTD

4. Security Architecture For IP(continued) • SAs are indexed by the triple, Security Parameter Index (SPI), Destination Address, Protocol. • Security is provided by two encapsulation protocols, ESP & AH • SAs can be setup manually or dynamically through the use of IKE. • SA bundles allow for multiple encapsulations between systems. • Some pre-defined IP functions are affected by ESP & AH, (e.g. PMTU, ICMP, Fragmentation). • Encapsulations can be within a IP-IP Tunnel. NIST/ITL/ANTD

5. AH • “…provides connectionless integrity, data origin authentication, and an optional anti-replay service.” • Provides access control through the distribution of secret cryptographic keying material. • Outbound packets compute and include cryptographic checksum over entire IP packet. • Inbound packets compute and compare cryptographic checksum. • Anti-replay is provided by including and verifying a 32-bit sequence number. NIST/ITL/ANTD

6. AH Packet Format IP Header Next Header Payload Len Reserved Security Parameters Index (SPI) Transport Data (TCP, UDP, IP-IP) Sequence Number Field Authentication Data (variable) NIST/ITL/ANTD

7. ESP • MAY provide confidentiality, limited traffic flow confidentiality, connectionless integrity, data origin authentication, and an anti-replay service. • “One or more of these services must be applied whenever ESP is invoked.” • Provides access control through the distribution of secret cryptographic keying material. • Confidentiality is provided by encrypting outbound packets and decrypting inbound packets. NIST/ITL/ANTD

8. ESP(continued) • Integrity and authentication is provided in a very similar manner to AH (excludes the IP header when computing the cryptographic checksum). • Traffic flow confidentiality is provided by concealing the IP addresses, and including extra padding to conceal the message length. • Anti-replay is provided by including and verifying a 32-bit sequence number. NIST/ITL/ANTD

9. ESP Packet Format IP Header Security Parameters Index (SPI) Auth. Coverage Sequence Number Field Confid. Coverage Payload Data (variable) (Initialization Vector, Transport Data) Padding (0-255 bytes) Pad Len Next Header Authentication Data (variable) NIST/ITL/ANTD

10. IKE • A scalable, automated, SA management protocol to facilitate the use of the anti-replay features of AH and ESP, and to accommodate the on-demand creation of SAs. • Combines the ISAKMP framework (which is independent of key exchanges) with a particular key exchange algorithm to provide authentication, key exchange, and SA management. • SAs established as part of a 2 Phase exchange of messages • In Phase I the two IKE peers use a Diffie-Helman exchange to establish a secure authenticated channel with which to communicate. NIST/ITL/ANTD

11. IKE(continued) • In Phase II the secure channel from Phase I is used to negotiate and exchange SA parameters. • Allows for perfect forward secrecy by performing Phase I with each Phase II. • Uses either digital signatures, public keys, or pre-shared secret keys for authentication. NIST/ITL/ANTD

12. Algorithms • IPsec is independent of the cryptographic algorithms used to secure traffic • IPsec algorithms specifications remove some of the variable aspects of particular algorithms to assist with interoperability. • Specifications re-iterate aspects of particular algorithms to emphasize issues that pertain to interoperability and the correctness of the implementation. NIST/ITL/ANTD

13. Cerberus • Cerberus has been developed to assist developers, researchers, and potential users in better understanding this new technology. • Interoperability testing tool. • Connecting home and corporate offices. NIST/ITL/ANTD

14. Cerberus Software Architecture Manual SADB Interface IPsec Input IPv4 IPsec Output SADB IKE Applications Linux Kernel Linux Netlink Sockets TCP UDP MSS/ PMTU SADB Management TCP/IP Data Flow IPv6 IPsec Calls Transforms and Algorithms NIST/ITL/ANTD

15. SADB • Made up of 3 databases. A system policy database, an inbound SA database, and an outbound SA database. • The policy database is a simple table that allows IPsec to determine how to use the information in the SADB (or lack thereof) to process IP packets. This is specified as levels such that: • 0 - All traffic must be IPsec traffic (ESP or AH) • 1 - Null SAs can be used • 2 - Traffic in the clear (i.e. No SA present) is allowed NIST/ITL/ANTD

16. SADB(continued) • SAs are stored in two sorted chained hash tables as a single piece of data with two sets of pointers. • SADB is organized for both unidirectional SAs and bi-directional SAs • The fields that make up an SA entry are as follows: • Destination Address, Prefix Length, Local SPI, Peer Address, Peer SPI, Linked SPI, Linked Protocol, Sequence Number, Replay Window Bitmap, Last Sequence Number Received, Flags: <M, C, T>, Protocol: (ESP, AH, NULL_SA) NIST/ITL/ANTD

17. SADB(continued) • For ESP protocol: • Crypto Algorithm Identifier, Ivec Length, Outbound Key, Inbound Key, Auth Algorithm Identifier, Outbound Key, Inbound Key, Auth Data Length • For AH protocol: • Auth Algorithm Identifier, Outbound Key, Inbound Key, Auth Data Length NIST/ITL/ANTD

18. SADB Management Routines • SADB management routines receive requests through a Linux Netlink socket in the form of an SADB message: • SADBM_ADD • SADBM_DELETE • SADBM_GET • SADBM_FLUSH NIST/ITL/ANTD

19. User Interface • A command line interface (sadb) originally based on the BSD route command. • Allows systems administrators to manually manage SAs. • Reads SA arguments from the command line, performs simple syntax checking, and sends a completed SADBM message via a Netlink socket to the Linux kernel. • For SADBM_GET messages, sadb waits for incoming SADBM messages and processes them until an end-of-message message is received. NIST/ITL/ANTD

20. Inbound IPsec Processing • Inbound IPsec processing is processed in the following steps. • If not encapsulated, check policy. • Verify the correctness of the protocol information. • Lookup the SA using source address in packet (matched to peer address), SPI, and protocol. • Check the sequence number. • For ESP, lookup the authentication transform, verify the authentication data, lookup the crypto transform, decrypt the packet. NIST/ITL/ANTD

21. Inbound IPsec Processing(continued) • For AH, lookup the authentication transform, verify the authentication data. • Build non-encapsulated packet. • Remove tunnel. • Return the IP packet to IP for forwarding or sinking. • All failures are logged. • Inbound processing is recursive. NIST/ITL/ANTD

22. Outbound IPsec Processing • Outbound IPsec processing is processed in the following steps. All IP packets go through IPsec processing. • Lookup SA based on the destination address. • If no SA is found, check policy and either return the packet to IP for further processing or drop the packet and log a failure. • Check the sequence number for wrapping. • Prepare for tunnel if specified in SA. • For ESP, lookup the crypto transform, encrypt the packet, lookup the authentication transform, compute the authentication data. NIST/ITL/ANTD

23. Outbound IPsec Processing(continued) • For AH, lookup the authentication transform, compute the authentication data. • Return the IP packet to IP for forwarding. • All failures are logged. • Outbound processing is recursive. NIST/ITL/ANTD

24. Transforms & Crypto Routines • Most of the specified algorithms have been included: • DES/CBC, 3DES/CBC, IDEA/CBC, RC5/CBC, Blowfish/CBC, HMAC-SHA1-96, HMAC-MD5-96, ESP-NULL, Auth-Test, Crypto-Test • The transform object is made up of a name, ID, input function, output function, add function, and delete function. • Transforms are stored in a small hash table indexed by algorithm identifiers. • Transforms can be compiled and run a complete and separate Linux run-time modules. NIST/ITL/ANTD

25. TCP & IP Interface • IP<->IPsec hooks • ip_build_xmit heavily modified. • TCP was modified to allow for the extra bytes added to the IP packet that has to be accounted for in the PMTU and MSS calculations. NIST/ITL/ANTD

26. Future Work • Better way to handle TCP MSS calculations. • Tune performance by tying SAs to routing table. • Better way to handle the ip_build_xmit problem. • Additional policy support. • IKE reference implementation • Session/port specific SAs. • Compression (IPPCP) • Port to IPv6 • PKIX client support for IKE authentication • Mobile IPsec NIST/ITL/ANTD

27. Additional Information • IETF IPsec WG Charter, RFCs, and Internet Drafts: • http://www.ietf.org/html.charters/ipsec-charter.html • Cerberus • http://www.antd.nist.gov/cerberus/ • NIST IP Security Project • http://www.antd.nist.gov/antd/html/security.html • NIST Internetworking Technologies Group • http://www.antd.nist.gov/html/itg.html NIST/ITL/ANTD