RFC 6071
IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
Internet Engineering Task Force (IETF) RFC 6071 ✨ IPsec and IKE Document Roadmap 🎀
Okay bestie, let's get into it! 💖 This RFC is the big family tree of everything IPsec and IKE, written by S. Frankel (NIST) and S. Krishnan (Ericsson) in February 2011. It's Informational (so not a Standards Track spec, just vibes and context 🦋), and it's the ISSN 2070-1721 one. It obsoletes RFC 2411, the old "IP Security Document Roadmap," so this is the new glow-up 🌸. It doesn't update anything else.
Abstract
Okay so the number of RFCs about IPsec and Internet Key Exchange (IKE) has literally exploded 💥. It's messy because they come from tons of IETF working groups: the original IPsec WG, its spin-offs, and other WGs that use IPsec and/or IKE to protect their own traffic 🫶.
This doc is a snapshot of all those IPsec and IKE RFCs. Each one gets a short description, plus background on why IPsec's outgrowths and extensions exist 🌈. It obsoletes RFC 2411, the previous "IP Security Document Roadmap" 🙈.
RFC 2411 gave a quick overview of how the different classes of base IPsec documents relate to each other. Its main focus was spelling out what documents defining extra encryption and authentication algorithms should contain 💅.
Status of This Memo
This doc is not an Internet Standards Track specification. It's published for informational purposes only 📚.
It's a product of the Internet Engineering Task Force (IETF) and represents IETF community consensus 💜. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🧚.
For the current status, errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6071 🔥.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved ©️.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions 🍓. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸.
Table of Contents
1. Introduction ....................................................4
2. IPsec/IKE Background Information ................................5
2.1. Interrelationship of IPsec/IKE Documents ...................5
2.2. Versions of IPsec ..........................................6
2.2.1. Differences between "Old" IPsec (IPsec-v2) and
"New" IPsec (IPsec-v3) ..............................6
2.3. Versions of IKE ............................................7
2.3.1. Differences between IKEv1 and IKEv2 .................8
2.4. IPsec and IKE IANA Registries ..............................9
3. IPsec Documents .................................................9
3.1. Base Documents .............................................9
3.1.1. "Old" IPsec (IPsec-v2) ..............................9
3.1.2. "New" IPsec (IPsec-v3) .............................11
3.2. Additions to IPsec ........................................11
3.3. General Considerations ....................................14
4. IKE Documents ..................................................15
4.1. Base Documents ............................................15
4.1.1. IKEv1 ..............................................15
4.1.2. IKEv2 ..............................................16
4.2. Additions and Extensions ..................................17
4.2.1. Peer Authentication Methods ........................17
4.2.2. Certificate Contents and Management (PKI4IPsec) ....18
4.2.3. Dead Peer Detection ................................19
4.2.4. Remote Access ......................................19
5. Cryptographic Algorithms and Suites ............................21
5.1. Algorithm Requirements ....................................22
5.2. Encryption Algorithms .....................................23
5.3. Integrity-Protection (Authentication) Algorithms ..........27
5.4. Combined Mode Algorithms ..................................30
5.5. Pseudo-Random Functions (PRFs) ............................33
5.6. Cryptographic Suites ......................................34
5.7. Diffie-Hellman Algorithms .................................35
6. IPsec/IKE for Multicast ........................................36
7. Outgrowths of IPsec/IKE ........................................38
7.1. IPsec Policy ..............................................38
7.2. IPsec MIBs ................................................39
7.3. IPComp (Compression) ......................................39
7.4. Better-Than-Nothing Security (BTNS) .......................39
7.5. Kerberized Internet Negotiation of Keys (KINK) ............40
7.6. IPsec Secure Remote Access (IPSRA) ........................41
7.7. IPsec Keying Information Resource Record (IPSECKEY) .......42
8. Other Protocols That Use IPsec/IKE .............................42
8.1. Mobile IP (MIPv4 and MIPv6) ...............................42
8.2. Open Shortest Path First (OSPF) ...........................44
8.3. Host Identity Protocol (HIP) ..............................45
8.4. Stream Control Transmission Protocol (SCTP) ...............46
8.5. Robust Header Compression (ROHC) ..........................46
8.6. Border Gateway Protocol (BGP) .............................47
8.7. IPsec Benchmarking ........................................47
8.8. Network Address Translators (NAT) .........................48
8.9. Session Initiation Protocol (SIP) .........................48
8.10. Explicit Packet Sensitivity Labels .......................49
9. Other Protocols That Adapt IKE for Non-IPsec Functionality .....49
9.1. Extensible Authentication Protocol (EAP) ..................49
9.2. Fibre Channel .............................................49
9.3. Wireless Security .........................................50
10. Acknowledgements ..............................................50
11. Security Considerations .......................................50
12. References ....................................................50
12.1. Informative References ...................................50
Appendix A. Summary of Algorithm Requirement Levels ..............611. Introduction 🦋
Okay so IPsec (Internet Protocol Security) is a suite of protocols that adds security to Internet communications at the IP layer 🔐. Its most common use right now is a Virtual Private Network (VPN), either between two locations (gateway-to-gateway) or between a remote user and an enterprise network (host-to-gateway). It can also do end-to-end, or host-to-host, security 💜. Other protocols use IPsec too, like Mobile IP version 6 (MIPv6), to protect some or all of their traffic ✨.
IKE (Internet Key Exchange) is the key negotiation and management protocol most commonly used to dynamically negotiate and update keying material for IPsec 🔑. And IPsec and IKE work with both IPv4 and IPv6 🌍.
Besides the base documents for IPsec and IKE, there are loads of RFCs that reference, extend, and sometimes change the core specs 🤯. This document obsoletes [RFC2411]. It tries to list and briefly describe those RFCs, with context and rationale where it helps 🧠. Each RFC title is followed by a letter showing its category in the RFC series [RFC2026]:
- S: Standards Track (Proposed Standard, Draft Standard, or Standard)
- E: Experimental
- B: Best Current Practice
- I: Informational
Each RFC also gets its publication date 📅.
This document also sorts each cryptographic algorithm by requirement level for use with IKEv1, IKEv2, IPsec-v2, and IPsec-v3 💅. You'll find those requirements summarized in Appendix A. These levels are current as of February 2011, so later RFCs may change them 🌸.
This document does not define requirement levels. It just restates the ones found in the IKE and IPsec RFCs 🎀. If this document conflicts with any other RFC, the other RFC wins 👑.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶.
2. IPsec/IKE Background Information 🌈
(Part 1 of 13 — more coming, bestie! Stay tuned 💖)
2.1. Interrelationship of IPsec/IKE Documents
okay so the main IPsec docs are split into seven groups, and this little diagram shows how they all connect 🦋 There's one main Architecture doc that covers the big-picture stuff: the general concepts, security requirements, definitions, and mechanisms that make IPsec, IPsec 🎀
Then there's the Encapsulating Security Payload (ESP) Protocol doc and the Authentication Header (AH) Protocol doc. These cover the packet format and the general issues for each protocol 📦 The "Encryption Algorithm" docs (on the left) explain how different encryption algorithms get used for ESP. The "Combined Algorithm" docs (in the middle) explain how combined mode algorithms give you both encryption and integrity protection for ESP ✨ And the "Integ-Protection Algorithm" docs (on the right) explain how integrity-protection algorithms get used for both ESP and AH 🔐
The IKE docs sit at the bottom, and they're the IETF Standards-Track key management schemes 🗝️ Bestie, the diagram is kinda chaotic but it's giving full web of connections 🕸️💖
+--------------+
| Architecture |
+--------------+
v v
+<-<-<-<-<-<-<-<-+ +->->->->->->->->+
v v
+----------+ +----------+
| ESP | | AH |
| Protocol | | Protocol |
+----------+ +----------+
v v v v
v +->->->->->->->->+->->->->->->->->+ v v
v v v v v v
v v v v v v
v +------------+ +-----------+ +----------------+ v
v | +------------+ | +------------+ | +----------------+ v
v | | Encryption | | | Combined | | |Integ-Protection| v
v +-| Algorithm | +-| Algorithm | +-| Algorithm | v
v +------------+ +------------+ +----------------+ v
v v v v v
v v v v v
+>->->->-+->->->->->->->->->--<-<-<-<-<-<-<-<-<-+-<-<-<-<-+
^
^
+------------+
| IKE |
| Protocol |
+------------+
Figure 1. IPsec/IKE Document Interrelationships2.2. Versions of IPsec
Two versions of IPsec are currently floating around in implementations 🌸 The "new" IPsec (called IPsec-v3 in this doc; see Section 3.1.1 for the RFC descriptions) obsoleted the "old" IPsec (called IPsec-v2 in this doc; see Section 3.1.2 for the RFC descriptions). BUT IPsec-v2 is still super common in operational use 💀 In this document, when someone just says the unqualified term IPsec, it covers both versions 🫶 And an even earlier version (defined in RFCs 1825-1829) got obsoleted by IPsec-v2, and this doc doesn't cover it.
2.2.1. Differences between "Old" IPsec (IPsec-v2) and "New" IPsec (IPsec-v3)
IPsec-v3 is literally built on "lessons learned" from implementation and operational experience with IPsec-v2 and its predecessor, IPsec-v1 🧠✨
People learned a lot about the barriers to IPsec deployment, the scenarios where IPsec works best, and the requirements that had to be added so IPsec could play nicely with other protocols 💅 Plus, the IPsec-v3 docs clarify and expand details that were underspecified or ambiguous in IPsec-v2. Iconic glow-up behavior 👑
Here's what changed in the architecture document [RFC4301]:
- More detailed descriptions of IPsec processing, both unicast and multicast, and the interactions among the various IPsec databases 🗂️
- In IPsec-v2, an SA (Security Association) is uniquely identified by a combination of the SPI (Security Parameters Index), protocol (ESP or AH) and the destination address. In IPsec-v3, a unicast SA is uniquely identified by the SPI and, optionally, by the protocol; a multicast SA is identified by a combination of the SPI and the destination address and, optionally, the source address. 🔑
- More flexible SPD (Security Policy Database) selectors, including ranges of values and ICMP message types as selectors 🎯
- Decorrelated (order-independent) SAD (Security Association Database) replaced the former ordered SAD 🔀
- Extended sequence numbers (ESNs) were added 🔢
- Mandatory algorithms defined in standalone document 📄
- AH [RFC4302] is mandatory to implement (MUST) in IPsec-v2, optional (MAY) in IPsec-v3 🌈
Here's what changed in ESP [RFC4303]:
- Combined mode algorithms were added, which necessitated changes to packet format and processing 🎀
- NULL authentication, mandatory (MUST) in ESP-v2, is optional (MAY) in ESP-v3 🙈
2.3. Versions of IKE
Same vibe for IKE: two versions are out in the wild 🦋 The "new" IKE (usually called IKEv2) obsoleted the "old" IKE (usually called IKEv1), but IKEv1 is still commonly found in operational use. In this document, when the unqualified term IKE shows up, it refers to both versions 💜
2.3.1. Differences between IKEv1 and IKEv2
Just like IPsec-v3, IKEv2 is built on "lessons learned" from implementation and operational experience with IKEv1 🌸 Folks learned about the barriers to IKE deployment, the scenarios where IKE is most effective, and the requirements that had to be added so IKE could work with other protocols and in general-purpose use. The IKEv2 docs replace multiple, sometimes contradictory, documents with a single document, and they clarify and expand details that were underspecified or ambiguous in IKEv1. Main character energy, fr 🎬
Once an IKE negotiation is successfully completed, the peers have established two pairs of one-way (inbound and outbound) SAs 🤝 IKE always negotiates pairs of SAs, so the term "SA" is usually used to mean a pair (like an "IKE SA" or an "IPsec SA," which is really a pair of one-way SAs). The first one, the IKE SA, protects IKE traffic 🛡️ The second one gives IPsec protection to data traffic between the peers and/or other devices the peers are authorized to negotiate for. In IKEv1 it's called the IPsec SA, and in the IKEv2 RFCs it's called a CHILD_SA, a child SA, and an IPsec SA depending on where you look 😭 This document uses the term "IPsec SA." And to make it even messier, since IKEv1 has two sequential negotiations called phases, the IKE SA is also called a Phase 1 SA and the IPsec SA is called a Phase 2 SA 🙃
Here's what changed in IKE:
- Replaced multiple alternate exchange types with a single, shorter exchange ✂️
- Streamlined negotiation format to avoid combinatorial bloat for multiple proposals 🧹
- Protect responder from committing significant resources to the exchange until the initiator's existence and identity are confirmed 🔒
- Reliable exchanges: every request expects a response 📬
- Protection of IKE messages based on ESP, rather than a method unique to IKE 💫
- Add traffic selectors: distinct from peer IDs and more flexible 🎯
- Support of EAP-based authentication methods and asymmetric authentication (i.e., initiator and responder can use different authentication methods) 🫧
2.4. IPsec and IKE IANA Registries
There are tons of IANA registries with values used in IPsec, IKE, and related protocols 📚 They include:
- IKE Attributes (
http://www.iana.org/assignments/ipsec-registry): values used during IKEv1 Phase 1 exchanges, defined in [RFC2409]. - "Magic Numbers" for Internet Security Association and Key Management Protocol (ISAKMP) (
http://www.iana.org/assignments/isakmp-registry): values used during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408], and numerous other cryptographic algorithm RFCs. 🪄 - IKEv2 Parameters (
http://www.iana.org/assignments/ikev2-parameters): values used in IKEv2 exchanges, defined in [RFC5996] and numerous other cryptographic algorithm RFCs. 🧁 - Cryptographic Suites for IKEv1, IKEv2, and IPsec (
http://www.iana.org/assignments/crypto-suites): names of cryptographic suites in [RFC4308] and [RFC4869]. 🌷
3. IPsec Documents
3.1. Base Documents
IPsec protections come from two special headers: the Encapsulating Security Payload (ESP) Header and the Authentication Header (AH) 🛡️✨ In IPv4, these headers take the form of protocol headers; in IPv6, they're classified as extension headers. There are three base IPsec documents: one that describes the IP security architecture, and one for each of the IPsec headers 💜
3.1.1. "Old" IPsec (IPsec-v2)
3.1.1.1. RFC 2401, Security Architecture for the Internet Protocol (S, November 1998)
[RFC2401] specifies the mechanisms, procedures, and components required to provide security services at the IP layer 🔐 It also describes how they all relate to each other and the general processing needed to inject IPsec protections into the network architecture 🕸️
The components include:
- SA (Security Association): a one-way (inbound or outbound) agreement between two communicating peers that specifies the IPsec protections to be provided to their communications. This includes the specific security protections, cryptographic algorithms, and secret keys to be applied, as well as the specific types of traffic to be protected. 🤝
- SPI (Security Parameters Index): a value that, together with the destination address and security protocol (AH or ESP), uniquely identifies a single SA. 🔑
- SAD (Security Association Database): each peer's SA repository. The RFC describes how this database functions (SA lookup, etc.) and the types of information it must contain to facilitate SA processing; it does not dictate the format or layout of the database. SAs can be established in either transport mode or tunnel mode (see below). 🗃️
- SPD (Security Policy Database): an ordered database that expresses the security protections to be afforded to different types and classes of traffic. The three general classes of traffic are traffic to be discarded, traffic that is allowed without IPsec protection, and traffic that requires IPsec protection. 🚦
[RFC2401] describes general inbound and outbound IPsec processing; it also includes details on several special cases: packet fragments, ICMP messages, and multicast traffic 🧩
3.1.1.2. RFC 2402, IP Authentication Header (S, November 1998) 🦋
Okay bestie, so [RFC2402] is the one that defines the Authentication Header (AH) 💅 It gives you integrity protection, and it also does data-origin authentication, access control, and, optionally, replay protection ✨ A transport mode AH SA is for peer-to-peer comms, and it protects the upper-layer data plus the parts of the IP header that don't change unpredictably during delivery 🌸 A tunnel mode AH SA can cover gateway-to-gateway or host-to-gateway traffic, and it can optionally be used for host-to-host traffic too 🧚 This kind of AH SA protects the inner (original) header and the upper-layer data, along with the parts of the outer (tunnel) header that don't change unpredictably during delivery 🎀
Here's the tea 🫢 AH processing is more complex than ESP processing, because portions of the IP header are left out of the AH calculations. AH also doesn't work when Network Address Translation (NAT) is involved 😭 And unlike IPsec-v3, IPsec-v2 classifies AH as mandatory to implement 👑
3.1.1.3. RFC 2406, IP Encapsulating Security Payload (ESP) (S, November 1998) 🌈
[RFC2406] defines the IP Encapsulating Security Payload (ESP) 💜 ESP gives you confidentiality (encryption) and/or integrity protection, and it also does data-origin authentication, access control, and, optionally, replay and/or traffic analysis protection 🔥 A transport mode ESP SA protects the upper-layer data, but not the IP header 🍓 A tunnel mode ESP SA protects the upper-layer data and the inner header, but not the outer header 🦋
3.1.2. "New" IPsec (IPsec-v3) ⭐
3.1.2.1. RFC 4301, Security Architecture for the Internet Protocol (S, December 2005) 👑
[RFC4301] obsoletes [RFC2401], and it has a more complete and detailed processing model 💖 The most notable changes are detailed above in Section 2.2.1. IPsec-v3 processing brings in an extra database:
- PAD (Peer Authorization Database): contains information necessary to conduct peer authentication, providing a link between IPsec and the key management protocol (e.g., IKE)
3.1.2.2. RFC 4302, IP Authentication Header (S, December 2005) 🌸
[RFC4302] obsoletes [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies AH as optional 🙈
3.1.2.3. RFC 4303, IP Encapsulating Security Payload (ESP) (S, December 2005) 🧚
[RFC4303] obsoletes [RFC2406]. The most notable changes are detailed above in Section 2.2.1 ✨
3.2. Additions to IPsec 🎀
Once the IKEv1 and IPsec-v2 RFCs were finalized, a bunch of additions got defined in separate documents: negotiation of NAT traversal, extended sequence numbers, UDP encapsulation of ESP packets, opportunistic encryption, and IPsec-related ICMP messages 🦋 There were also extra uses of IPsec transport mode described: protection of manually configured IPv6-in-IPv4 tunnels and protection of IP-in-IP tunnels. These documents describe atypical uses of IPsec transport mode, but they don't define any new IPsec features 💅
Once the original IPsec Working Group wrapped up, the IPsecME (IPsec Maintenance and Extensions) Working Group picked up the other IPsec-related issues 🫶 One of those is how middleboxes can tell unencrypted ESP packets (ESP-NULL) apart from encrypted ones in a fast and accurate way 👀 Two solutions are described: a new protocol that requires changes to IKEv2 and IPsec-v3, and a heuristic method that imposes no new requirements 🔥 Another issue that got addressed is using IKE and IPsec in a high-availability environment 🌈
3.2.1. RFC 3947, Negotiation of NAT-Traversal in the IKE (S, January 2005) 🌸
[RFC3947] defines an optional extension to IKEv1 🧚 It lets IKEv1 detect whether there are any NATs between the negotiating peers and whether both peers support NAT traversal. It also describes how IKEv1 can be used to negotiate the use of UDP encapsulation of ESP packets for the IPsec SA. For IKEv2, this capability is described in [RFC5996] 💜
3.2.2. RFC 3948, UDP Encapsulation of IPsec ESP Packets (S, January 2005) 🍓
[RFC3948] is an optional extension for IPsec-v2 and IPsec-v3 🦋 It defines how to wrap ESP packets in UDP packets so they can traverse NATs that discard packets with protocols other than UDP or TCP. This means ESP packets can pass through the NAT device without requiring any change to the NAT device itself 🙌 IKE negotiates the use of this solution, as described in [RFC3947] for IKEv1 and [RFC5996] for IKEv2 ✨
3.2.3. RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) (S, December 2005) 🔥
ESNs let IPsec use 64-bit sequence numbers for replay protection, but only 32 bits of the sequence number get sent in the packet 🤯 That means shorter packets and no need to redesign the packet format 💖 The larger sequence numbers also let an existing IPsec SA be used for larger volumes of data 📈 [RFC4304] describes an optional extension to IKEv1 that lets IKEv1 negotiate the use of ESNs for IPsec SAs. For IKEv2, this capability is described in [RFC5996] 🌈
3.2.4. RFC 4322, Opportunistic Encryption using the Internet Key Exchange (IKE) (I, December 2005) 🔐
Opportunistic encryption lets a pair of end systems use encryption without any specific pre-arrangements, and that's giving main character energy 🌟 [RFC4322] specifies a mechanism that uses DNS to distribute the public keys of each system involved, and it uses DNS Security (DNSSEC) to protect the mechanism against active attackers 🛡️ It also specifies the changes that are needed in existing IPsec and IKE implementations 💅 Most of those changes land in the IKE implementation, and they relate to handling key acquisition requests, looking up public keys and TXT records, and interacting with firewalls and other security facilities that may be co-resident on the same gateway 🫶
3.2.5. RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May 2007) 🧚
[RFC4891] describes how to use IKE and transport-mode IPsec to provide security protection to manually configured IPv6-in-IPv4 tunnels 🎀 This document uses standard IKE and IPsec, without any new extensions, so it's pretty chill 😌 It does not apply to tunnels that are initiated in an automated manner (e.g., 6to4 tunnels [RFC3056]) 🙅♀️
3.2.6. RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I, September 2004) 🦋
[RFC3884] describes the use of transport-mode IPsec to secure IP-in-IP tunnels, which make up the links of a multi-hop, distributed virtual network (VN) 🌐 This lets traffic get dynamically routed via the VN's trusted routers, rather than sending all traffic through a statically routed IPsec tunnel 🗺️ This RFC has not been widely adopted 🥲
3.2.7. RFC 5840, Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility (S, April 2010) 👀
ESP, as defined in [RFC4303], doesn't let a network device easily tell whether protected traffic passing through it is encrypted or only integrity protected (referred to as ESP-NULL packets) 😵 [RFC5840] extends ESPv3 to provide explicit notification of integrity-protected packets, and it extends IKEv2 to negotiate this capability between the IPsec peers 🤝
3.2.8. RFC 5879, Heuristics for Detecting ESP-NULL packets (I, May 2010) 🔍
[RFC5879] offers an alternative approach to telling ESP-encrypted and ESP-NULL packets apart through packet inspection 🕵️♀️ This method doesn't require any change to IKE or ESP, and it can be used with ESP-v2 or ESP-v3 💖
3.3. General Considerations 🌷
3.3.1. RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements (I, March 2004) 🚧
[RFC3715] "describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them". This is a critical issue 🚨 IPsec is frequently used to provide VPN access to the corporate network for telecommuters, and NATs are widely deployed in home gateways, hotels, and other access networks that are typically used for remote access 🏨
3.3.2. RFC 5406, Guidelines for Specifying the Use of IPsec Version 2 (B, February 2009) 📋
[RFC5406] offers guidance to protocol designers on how to figure out whether IPsec is the right security mechanism for providing an interoperable security solution for their protocol 🧠 If it isn't, it advises against trying to define a new security protocol, and instead suggests using another standards-based security protocol 🙅♀️ The details in this document apply only to IPsec-v2 🌸
3.3.3. RFC 2521, ICMP Security Failures Messages (E, March 1999) 🚨
[RFC2521] specifies an ICMP message for indicating failures related to the use of IPsec protocols (AH and ESP) 📣 The specified ICMP message defines several codes for handling common IPsec failure modes. The failures it signals include invalid or expired SPIs, failure of authenticity or integrity checks on datagrams, decryption and decompression errors, etc. 😬 These messages can be used to trigger automated session-key management, or to signal to an operator the need to manually reconfigure the SAs 🔧 This RFC has not been widely adopted either 😅 Furthermore, [RFC4301] discusses the pros and cons of relying on unprotected ICMP messages ⚖️
3.3.4. RFC 6027, IPsec Cluster Problem Statement (I, October 2010) 🧩
[RFC6027] describes the problems of using IKE and IPsec in a high availability environment, where one or both of the peers are clusters of gateways 🏰 It details the many types of stateful information shared by IKE and IPsec peers that would have to be available to other members of the cluster in order to provide high availability, load sharing, and/or failover capabilities 🔁
4. IKE Documents 🌟
4.1. Base Documents 💜
4.1.1. IKEv1 🔑
Okay bestie, IKE is the preferred key management protocol for IPsec, so this is the one everybody reaches for 💅. It handles peer authentication, negotiates, modifies, and deletes SAs, and negotiates authenticated keying material for use inside those SAs. The standard peer authentication methods IKEv1 used (pre-shared secret keys and digital certificates) had a few shortcomings when it came to letting remote users log into a corporate VPN 😩. It could not leverage legacy authentication systems (e.g. RADIUS databases) to authenticate a remote user to a security gateway. It also could not be used to configure remote users with network addresses or other information needed to access the internal network. Automatic key distribution is required for IPsec-v2, but alternatives to IKE may be used to satisfy that requirement 🎀.
Several Internet Drafts were written to fix these problems 🧚. Two of the main ones were "Extended Authentication within IKE (XAUTH)" [IKE-XAUTH] (and its predecessor, "Extended Authentication within ISAKMP/Oakley (XAUTH)" [ISAKMP-XAUTH]) and "The ISAKMP Configuration Method" [IKE-MODE-CFG] (and its predecessor [ISAKMP-MODE-CFG]). These Internet Drafts never made it to RFC status because of security flaws and other problems with these solutions 💀. However, lots of current IKEv1 implementations borrow pieces of these solutions to help remote users get into corporate VPNs 🌸. These solutions were never standardized, and different implementations built different versions. So there's no guarantee that implementations stick fully to the suggested solutions, or that one implementation can interoperate with others that claim to have the same features 😭. On top of that, these solutions have known security issues. All of those problems and security issues were solved in IKEv2, so using these non-standardized IKEv1 solutions is not recommended 🙅♀️.
4.1.1.1. RFC 2409, The Internet Key Exchange (IKE) (S, November 1998) 🌈
This document defines a key exchange protocol that can be used to negotiate authenticated keying material for SAs ✨. It implements a subset of the Oakley protocol in conjunction with ISAKMP, to get authenticated keying material for use with ISAKMP and for other security associations such as AH and ESP for the IETF IPsec DOI. Historically, IKEv1 was created by combining two security protocols, ISAKMP and Oakley. In practice, though, the combination (along with the IPsec DOI) is commonly viewed as one protocol, IKEv1. You can see its origins in how the documents that define it are organized 🦋.
4.1.1.2. RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP) (S, November 1998) 🍓
This document defines the procedures and packet formats used to establish, negotiate, modify, and delete Security Associations (SAs) 💜. It's meant to support negotiating SAs for security protocols at all layers of the network stack. ISAKMP can work with many different key exchange protocols, and each one has different security properties 🫶.
4.1.1.3. RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP (S, November 1998) 👑
Within ISAKMP, a Domain of Interpretation (DOI) is used to group related protocols that use ISAKMP to negotiate security associations 🧁. Security protocols that share a DOI choose their security protocol and cryptographic transforms from a common namespace, and they share key exchange protocol identifiers. This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations 🔥.
4.1.1.4. RFC 2412, The OAKLEY Key Determination Protocol (I, November 1998) 🧠
[RFC2412] describes a key establishment protocol that two authenticated parties can use to agree on secure and secret keying material 🔐. The Oakley protocol describes a series of key exchanges, called "modes", and details the services each one provides (e.g., perfect forward secrecy for keys, identity protection, and authentication). This document gives extra theory and background to explain some of the design decisions and security features of IKE and ISAKMP. It does not include the details needed to implement IKEv1, though, so it's more of a "why" doc than a "how" doc 📚.
4.1.2. IKEv2 🎀
4.1.2.1. RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, December 2005) 💖
This document has the original description of version 2 of the Internet Key Exchange (IKE) protocol ✨. It covers what used to be spread across separate documents: ISAKMP, IKE, and DOI. It also addresses NAT traversal, legacy authentication, and remote address acquisition 🌸. IKEv2 is not interoperable with IKEv1. Automatic key distribution is required for IPsec-v3, but alternatives to IKE may be used to satisfy that requirement. This document has been superseded by [RFC5996] 🦋.
4.1.2.2. RFC 4718, IKEv2 Clarifications and Implementation Guidelines (I, October 2006) 🧚
[RFC4718] clears up a lot of the original IKEv2 specification [RFC4306] that developers who weren't deep in the spec and its history found hard to understand 🙈. It doesn't change the protocol at all. It just gives descriptions that are less open to ambiguous interpretation. The goal was to help people build interoperable implementations 🫶. The clarifications in this document have been folded into the new version of the IKEv2 specification [RFC5996] 💅.
4.1.2.3. RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2) (S, September 2010) 👑
[RFC5996] combines the original IKEv2 RFC [RFC4306] with the Clarifications RFC [RFC4718], and it fixes many implementation issues the community found after those two documents came out 🔥. This document was developed by the IPsecME (IPsec Maintenance and Extensions) Working Group, after the original IPsec Working Group wrapped up 🌈. Automatic key distribution is required for IPsec-v3, but alternatives to IKE may be used to satisfy that requirement 💜.
4.2. Additions and Extensions 🌟
4.2.1. Peer Authentication Methods 🔐
4.2.1.1. RFC 4478, Repeated Authentication in Internet Key Exchange (IKEv2) Protocol (E, April 2006) 🙋♀️
[RFC4478] tackles a problem that's unique to remote access setups 😤. How can the gateway (the IKE responder) make the remote user (the IKE initiator) reauthenticate every so often, so the damage is limited if an unauthorized person gets physical access to the remote host? This document defines a new status notification that a responder can send to an initiator. It tells the initiator that the IPsec SA will be revoked unless the initiator reauthenticates within a specified period of time ⏰. This optional extension applies only to IKEv2, not to IKEv1 🦋.
4.2.1.2. RFC 4739, Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol (E, November 2006) 🧩
IKEv2 supports several mechanisms for authenticating the parties, but each endpoint uses only one of them to authenticate itself 🙃. [RFC4739] specifies an extension to IKEv2 that lets you run multiple authentication exchanges, using either different mechanisms or the same mechanism. For example, it allows certificate-based authentication of the client host followed by an EAP authentication of the user 🎀. It also allows authentication by multiple administrative domains, if that's needed. This optional extension applies only to IKEv2, not to IKEv1 ✨.
4.2.1.3. RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) (S, January 2007) 🌊
[RFC4754] describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) can be used as the authentication method within the IKEv1 and IKEv2 protocols 💜. ECDSA has lots of perks: computational efficiency, small signature sizes, and minimal bandwidth compared to other digital signature methods like RSA and DSA 😍. This optional extension applies to both IKEv1 and IKEv2 🍓.
4.2.1.4. RFC 5998, An Extension for EAP-Only Authentication in IKEv2 (S, September 2010) 🎭
IKEv2 lets an initiator use EAP for peer authentication, but it requires the responder to authenticate using a digital signature 🙄. [RFC5998] extends IKEv2 so that EAP methods providing mutual authentication and key agreement can also be used to provide peer authentication for the responder 🤝. This optional extension applies only to IKEv2, not to IKEv1 🌸.
4.2.2. Certificate Contents and Management (PKI4IPsec) 📜
The format, contents, and interpretation of Public Key Certificates (PKCs) turned out to be a big source of interoperability problems within IKE and IPsec 😵. PKI4IPsec was an attempt to set up some common procedures and interpretations to help fix those problems 🧡.
4.2.2.1. RFC 4809, Requirements for an IPsec Certificate Management Profile (I, February 2007) 📋
[RFC4809] lists the requirements for Public Key Certificate (PKC) lifecycle transactions between different VPN System and PKI System products 💌. The goal is better large-scale, PKI-enabled IPsec deployments that use a common set of transactions. This document discusses requirements for both the IPsec and the PKI products. These optional requirements apply to both IKEv1 and IKEv2 🌈.
4.2.2.2. RFC 4945, The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX (S, August 2007) 🏅
[RFC4945] defines a profile of IKE and the Public Key Infrastructure using X.509 (PKIX) frameworks 🫧. The aim is an agreed-upon standard for using PKI technology in the context of IPsec. It also documents the contents of the relevant IKE payloads and further specifies their semantics 🔍. Plus, it summarizes the current state of implementations and deployment, and gives advice on avoiding common interoperability issues 💡. This optional extension applies to both IKEv1 and IKEv2 🌟.
4.2.2.3. RFC 4806, Online Certificate Status Protocol (OCSP) Extensions to IKEv2 (S, February 2007) 🕵️♀️
When certificates are used with IKEv2, the communicating peers need a way to figure out the revocation status of the peer's certificate 🔎. OCSP is one such way. [RFC4806] defines the "OCSP Content" extension to IKEv2 💫. This document applies when OCSP is wanted and security policy (e.g., firewall policy) stops one of the IKEv2 peers from reaching the relevant OCSP responder directly 🚧. This optional extension applies only to IKEv2, not to IKEv1 🦋.
4.2.3. Dead Peer Detection 💀
4.2.3.1. RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers (I, February 2004) 🕳️
When two peers talk using IKE and IPsec, the connectivity between them can drop without warning 😱. The SAs can still stick around until their lifetimes expire, and then packets end up getting tunneled into a "black hole" 🕳️. [RFC3706] describes a way to detect peer liveliness without sending messages at regular intervals 🫶. This RFC defines an optional extension to IKEv1. Dead peer detection (DPD) is an integral part of IKEv2, which calls this feature a "liveness check" or "liveness test" ✨.
4.2.4. Remote Access 🦋
okay so the IKEv2 Mobility and Multihoming (MOBIKE) protocol gives IPsec VPN users two extra powers 💅: 1) switching from one address to another without re-establishing existing SAs and 2) using multiple interfaces at the same time 🫶. bestie, these only work for IPsec VPNs. they are NOT trying to be general mobility or multihoming solutions, so don't expect magic everywhere 🙈
the IPsecME Working Group spotted some missing pieces needed for fuller IKEv2 and IPsec-v3 support for remote access clients ✨. those are efficient client resumption of a previously established session with a VPN gateway, efficient client redirection to an alternate VPN gateway, and support for IPv6 client configuration using IPsec configuration payloads 🌸.
4.2.4.1. RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S, June 2006)
ngl this one is the core of the whole thing 🔥. IKEv2 assumes that an IKE SA is created implicitly between the IP address pair used during the protocol execution when the IKEv2 SA is established. IPsec-related documents had no way to change that pair after an IKE SA was created 😭. [RFC4555] adds IKEv2 extensions that make managing IKE and IPsec Security Associations way more efficient when a host has multiple IP addresses and/or when the IP addresses of an IPsec host change over time 💖.
4.2.4.2. RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol (I, August 2006)
[RFC4621] is the design diary of MOBIKE 🧚. it looks at the network entities involved and how IKEv2 signaling relates to info from other protocols. it also records the design decisions, background info, and what the working group talked about along the way 📝.
4.2.4.3. RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) (B, June 2008)
[RFC5266] is giving "secure roaming for enterprise people" 💼. it describes a solution using Mobile IPv4 (MIPv4) and the mobility extensions to IKEv2 (MOBIKE) to give secure connectivity and mobility to enterprise users who roam into untrusted networks 🌈.
4.2.4.4. RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption (S, January 2010)
this one is so iconic 👑. [RFC5723] lets a remote client that got disconnected from a gateway re-establish SAs with that gateway in an expedited way, without repeating the whole IKEv2 negotiation ⚡. it does need changes to IKEv2 🔧. it's an optional extension, and it only applies to IKEv2, not IKEv1 🙅♀️.
4.2.4.5. RFC 5685, Re-direct Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) (S, November 2009)
[RFC5685] lets a gateway securely redirect VPN clients to another VPN gateway, either during or after the IKEv2 negotiation 🦋. the reasons could be an overloaded gateway or a gateway that needs to shut down, among others 🫠. this also needs changes to IKEv2 🔧. it's optional, and it's IKEv2-only, not IKEv1 💅.
4.2.4.6. RFC 5739, IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) (E, February 2010)
in IKEv2, a VPN gateway can give a remote VPN client an internal network address using configuration payloads 🎀. for an IPv6 client though, one address isn't enough for full-fledged IPv6 communications 😤. [RFC5739] proposes a few solutions that might fix that limitation 💜. it's an optional extension, IKEv2-only, not IKEv1 ✨.
5. Cryptographic Algorithms and Suites 👑
okay the vibe here is that two basic requirements have to be met before an algorithm can be used within IKE and/or IPsec 🧐: it needs one or more IANA values, and it needs an RFC that describes how to use it within the relevant protocol, packet formats, special considerations, and so on 📜. for every RFC that describes a cryptographic algorithm, this roadmap classifies its requirement level for each protocol as MUST, SHOULD, or MAY [RFC2119]; SHOULD+, SHOULD-, or MUST- [RFC4835]; optional; undefined; or N/A (not applicable) 💖.
quick decoder ring 💍: "optional" means the algorithm meets both basic requirements, but its use isn't specifically recommended for that protocol 🌸. "undefined" means one of the basic requirements isn't met, so either there's no relevant IANA number for it, or there's no RFC saying how to use it in that specific protocol 💀. "N/A" means using the algorithm is inappropriate in that context, like NULL encryption for IKE (which always requires encryption) or combined mode algorithms (a new IPsec-v3 feature) used with IPsec-v2 🙈.
this document sorts the requirement level of each algorithm for IKEv1, IKEv2, IPsec-v2, and IPsec-v3 🫶. if an algorithm is recommended for IKEv1 or IKEv2, it either protects the IKE SA's traffic (encryption and integrity-protection algorithms) or generates keying material (Diffie-Hellman or DH groups, Pseudorandom Functions or PRFs) 🔐. if it's recommended for IPsec, it protects the IPsec/child SA's traffic, and IKE can negotiate its use for that purpose 🦋. all of this is summarized in Table 1 (Appendix A) 📋. these levels are current as of February 2011, and subsequent RFCs may change them 🕰️. for algorithms, that could mean brand new algorithms, or upgrading or downgrading the requirement levels of existing ones 🌈.
the IANA registries for IKEv1 and IKEv2 include IANA values for various cryptographic algorithms 📚. IKE uses those values to negotiate IPsec SAs that provide protection with those algorithms ✨. if a specific algorithm lacks a value for IKEv1 and/or IKEv2, its use is classified as "undefined" (no IANA #) within IPsec-v2 and/or IPsec-v3 😭.
5.1. Algorithm Requirements 🧩
specifying a core set of mandatory algorithms for each protocol makes interoperability way easier 🫶. defining those algorithms in a separate RFC from the base protocol RFC boosts algorithm agility 🏃♀️. IPsec-v3 and IKEv2 each have an RFC that specifies their mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY), and deprecated (SHOULD NOT) algorithms 💅. for IPsec-v2, that's included in the base protocol RFC 📄. that was originally the case for IKEv1 too, but IKEv1's algorithm requirements got updated in [RFC4109] 🌸.
5.1.1. RFC 4835, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, April 2007)
[RFC4835] specifies the encryption and integrity-protection algorithms for IPsec (both versions) 🔐. the IPsec-v2 algorithms were originally defined in [RFC2402] and [RFC2406]. [RFC4305] obsoleted those requirements, and then [RFC4835] obsoleted [RFC4305] in turn 🔄. so [RFC4835] applies to IPsec-v2 as well as IPsec-v3, periodt 💅. combined mode algorithms are mentioned, but they don't get a requirement level 🙈.
5.1.2. RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) (S, December 2005)
[RFC4307] specifies the encryption and integrity-protection algorithms IKEv2 uses to protect its own traffic 🛡️, the Diffie-Hellman (DH) groups used within IKEv2 💎, and the pseudorandom functions IKEv2 uses to generate keys, nonces, and other random values 🎲. ngl, [RFC4307] has conflicting requirements for IKEv2 encryption and integrity-protection algorithms 😭. when things contradict, this document takes its requirement levels from Section 3.1.1, "Encrypted Payload Algorithms", instead of Section 3.1.3, "IKEv2 Transform Type 1 Algorithms", or Section 3.1.4, "IKEv2 Transform Type 2 Algorithms" 📌.
5.1.3. RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1) (S, May 2005)
[RFC4109] updates IKEv1's algorithm specifications, which were originally defined in [RFC2409] ✨. it specifies the encryption and integrity-protection algorithms IKEv1 uses to protect its own traffic 🔒; the Diffie-Hellman (DH) groups used within IKEv1 💎; the hash and pseudorandom functions IKEv1 uses to generate keys, nonces, and other random values 🎲; and the authentication methods and algorithms IKEv1 uses for peer authentication 🫂.
5.2. Encryption Algorithms 🔐
the encryption-algorithm RFCs describe how to use these algorithms to encrypt IKE and/or ESP traffic, which gives the traffic confidentiality protection 🫶. they also describe any special constraints, requirements, or packet format changes that suit the specific algorithm 🧾. in general they don't go into the detailed algorithmic computations 🤓; the reference section of each RFC has pointers to documents that define the algorithm's inner workings 📚. some of the RFCs include sample test data, so implementors can compare their results with standardized output 🧪.
when any encryption algorithm is used for confidentiality, using integrity protection is strongly recommended 🛡️. if the encryption algorithm is a stream cipher, leaving out integrity protection seriously compromises the security properties of the algorithm 😱.
DES, as described in [RFC2405], was originally a required algorithm for IKEv1 and ESP-v2 🕰️. since DES is now deprecated, this roadmap doesn't include [RFC2405] 🪦.
5.2.1. RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec (S, November 1998)
[RFC2410] is a tongue-in-cheek description of the no-op encryption algorithm (aka using ESP without encryption) 😜. for IKE to negotiate picking the NULL encryption algorithm for an ESP SA, it needs an identifying IANA number 🔢. that number (the value 11 for ESP_NULL) is on the IANA registries for both IKEv1 and IKEv2, but it isn't mentioned in [RFC2410] 🙃.
requirement levels for ESP-NULL:
IKEv1 - N/A
IKEv2 - N/A
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835]NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2; this has been corrected in an errata submission for RFC 4307 🚨.
5.2.2. RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, November 1998)
[RFC2451] describes how to use encryption algorithms in cipher-block-chaining (CBC) mode to encrypt IKE and ESP traffic 🧁. it specifically mentions Blowfish, CAST-128, Triple DES (3DES), International Data Encryption Algorithm (IDEA), and RC5, but it applies to any block-cipher algorithm used in CBC mode 🍓. the algorithms mentioned in the RFC all have a 64-bit blocksize and a 64-bit random Initialization Vector (IV) that gets sent in the packet along with the encrypted data 📦.
requirement levels for 3DES-CBC:
IKEv1 - MUST [RFC4109]
IKEv2 - MUST- [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST- [RFC4835]requirement levels for other CBC algorithms (Blowfish, CAST, IDEA, RC5):
IKEv1 - optional
IKEv2 - optional
ESP-v2 - optional
ESP-v3 - optional5.2.3. RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec (S, September. 2003) 🌸
[RFC3602] is the one to read if you want AES in cipher block chaining (CBC) mode to encrypt IKE and ESP traffic 🔐. AES is the successor to DES, and it's giving main character energy ✨. AES-CBC is a block-mode cipher with a 128-bit blocksize, a random IV that gets sent in the packet with the encrypted data, and keysizes of 128, 192 and 256 bits 🦋. If AES-CBC is implemented, 128-bit keys are MUST, and the other sizes are MAY 💅. [RFC3602] includes IANA values for IKEv1 and ESP-v2 🍓. There's only one IANA value for AES-CBC, though, so IKE negotiations need to say which keysize they want 🙈.
Requirement levels for AES-CBC with 128-bit keys:
Requirement levels for AES-CBC with 192- or 256-bit keys:
- IKEv1 - optional
- IKEv2 - optional
- ESP-v2 - optional
- ESP-v3 - optional
5.2.4. RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) (S, January 2004) 🧚
[RFC3686] shows you how to use AES in counter (CTR) mode to encrypt ESP traffic 💜. AES-CTR is a stream cipher with a 32-bit random nonce (1/SA) and a 64-bit IV 🌈. If AES-CTR is implemented, 128-bit keys are MUST, and 192- and 256-byte keys are MAY 🎀. Reusing the IV with the same key and nonce wrecks the data's security, so AES-CTR should not be used with manual keying 💀. AES-CTR can be pipelined and parallelized, and it only uses the AES encryption operations for both encryption and decryption 🔥.
Requirement levels for AES-CTR:
- IKEv1 - undefined (no IANA #)
- IKEv2 - optional [RFC5930]
- ESP-v2 - SHOULD [RFC4835]
- ESP-v3 - SHOULD [RFC4835]
5.2.5. RFC 5930, Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol (I, July 210). 🦋
[RFC5930] extends [RFC3686] so you can use AES-CTR to give encryption and integrity protection to IKEv2 messages 🫶.
5.2.6. RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec (S, December 2005) 🌷
[RFC4312] explains how to use Camellia in cipher block chaining (CBC) mode to encrypt IKE and ESP traffic 🌺. Camellia-CBC is a block-mode cipher with a 128-bit blocksize, a random IV that gets sent in the packet with the encrypted data, and keysizes of 128, 192, and 256 bits ✨. If Camellia-CBC is implemented, 128-bit keys are MUST, and the other sizes are MAY 👑. [RFC4312] has IANA values for IKEv1 and IPsec-v2 💅. There's only one IANA value for Camellia-CBC, so IKEv1 negotiations need to specify the keysize 🙈.
5.2.7. RFC 5529, Modes of Operation for Camellia for Use with IPsec (S, April 2009) 🌈
[RFC5529] covers using the Camellia block cipher with a few different modes of operation 💖. It explains Camellia in cipher block chaining (CBC) mode and counter (CTR) mode as an encryption algorithm within ESP. It also covers Camellia in Counter with CBC-MAC (CCM) mode as a combined mode algorithm in ESP 🔐. This document defines how to use IKEv2 to generate keying material for a Camellia ESP SA, but it doesn't define how to use Camellia inside IKEv2 to protect an IKEv2 SA's traffic 🙃. Still, this RFC, together with IKEv2's general description of block-mode encryption, has enough detail to let you use Camellia-CBC algorithms within IKEv2 🧠. All three modes can use keys of length 128 bits, 192 bits, or 256 bits. [RFC5529] includes IANA values for IKEv2 and IPsec-v3. Each Camellia mode has a single IANA value, so IKEv2 negotiations need to specify the keysize 🍓.
Requirement levels for Camellia-CBC:
- IKEv1 - optional
- IKEv2 - optional
- ESP-v2 - optional
- ESP-v3 - optional
Requirement levels for Camellia-CTR:
- IKEv1 - undefined (no IANA #)
- IKEv2 - undefined (no RFC)
- ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
- ESP-v3 - optional
Requirement levels for Camellia-CCM:
- IKEv1 - N/A
- IKEv2 - undefined (no RFC)
- ESP-v2 - N/A
- ESP-v3 - optional
5.2.8. RFC 4196, The SEED Cipher Algorithm and Its Use with IPsec (S, October 2005) 🌸
[RFC4196] explains how to use SEED in cipher block chaining (CBC) mode to encrypt ESP traffic 🌼. It shows how to use IKEv1 to negotiate a SEED-ESP SA, but it doesn't define using SEED to protect IKEv1 traffic 🙅♀️. SEED-CBC is a block-mode cipher with a 128-bit blocksize, a random IV that gets sent in the packet with the encrypted data, and a keysize of 128 bits 💜. [RFC4196] includes IANA values for IKEv1 and IPsec-v2, and it also includes test data ✨.
Requirement levels for SEED-CBC:
- IKEv1 - undefined (no IANA #)
- IKEv2 - undefined (no IANA #)
- ESP-v2 - optional
- ESP-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
5.3. Integrity-Protection (Authentication) Algorithms 🛡️
The integrity-protection algorithm RFCs explain how to use these algorithms to authenticate IKE and/or IPsec traffic, which gives the traffic integrity protection 🫶. This protection comes from computing an Integrity Check Value (ICV), which gets sent in the packet 📦. The RFCs describe any special constraints, requirements, or packet format changes that are specific to each algorithm 👀. In general, they don't go into the detailed algorithmic computations. The reference section of each RFC points you to documents that define how the algorithm works inside 📚. Some of the RFCs include sample test data so implementors can compare their results with standardized output 🧪.
Some of these algorithms generate a fixed-length ICV, which gets truncated when it's included in an IPsec-protected packet ✂️. For example, standard HMAC-SHA-1 (Hashed Message Authentication Code) generates a 160-bit ICV, which gets truncated to 96 bits when it's used to protect an ESP or AH packet 🍓. The individual RFC descriptions mention which algorithms get truncated. When these algorithms protect IKEv2 SAs, they're also truncated 💅. For IKEv1, HMAC-SHA-1 and HMAC-MD5 are negotiated by requesting the hash algorithms SHA-1 and MD5, respectively. These algorithms aren't truncated when they protect an IKEv1 SA 🙌. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry has values for both the truncated version and the standard non-truncated version, so IKEv2 can negotiate either version of the algorithm 🌈. However, only the truncated version is used for IKEv2 SAs and for IPsec SAs. The non-truncated version is reserved for use by the Fibre Channel protocol [RFC4595] 🚫. For the other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC-RIPEMD), only the truncated version can be used for both IKEv2 and IPsec-v3 SAs 🎀.
One other algorithm, AES-GMAC [RFC4543], can also provide integrity protection 🌟. It has two versions: an integrity-protection algorithm for use within AH-v3, and a combined mode algorithm with null encryption for use within ESP-v3 🧚♀️. [RFC4543] is described in Section 5.4, "Combined Mode Algorithms" 👑.
5.3.1. RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (S, November 1998) 🍓
[RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm with a 512-bit blocksize and a 160-bit key and Integrity Check Value (ICV). For use within IPsec, the ICV is truncated to 96 bits. This is currently the most commonly used integrity-protection algorithm 🏆.
Requirement levels for HMAC-SHA-1:
5.3.2. RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec (S, September 2003) 🌸
[RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC that's secure for messages of varying lengths (unlike classic CBC-MAC) 🧁. It's an integrity-protection algorithm with a 128-bit blocksize and a 128-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits. [RFC3566] includes test data 🧪.
Requirement levels for AES-XCBC-MAC:
- IKEv1 - undefined (no RFC)
- IKEv2 - optional
- IPsec-v2 - SHOULD+ [RFC4835]
- IPsec-v3 - SHOULD+ [RFC4835]
5.3.3. RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec (S, May 2007) 💫
[RFC4868] describes a family of algorithms that are the successors to HMAC-SHA-1 🌈. HMAC-SHA-256 has a 512-bit blocksize and a 256-bit key and ICV. HMAC-SHA-384 has a 1024-bit blocksize and a 384-bit key and ICV.
HMAC-SHA-512 has a 1024-bit blocksize and a 512-bit key and ICV. For use within IKE and IPsec, the ICV is truncated to half its original size (128 bits, 192 bits, or 256 bits). Each of the three algorithms has its own IANA value, so IKE doesn't have to negotiate the keysize 🙌.
Requirement levels for HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512:
- IKEv1 - optional
- IKEv2 - optional
- IPsec-v2 - optional
- IPsec-v3 - optional
5.3.4. RFC 2403, The Use of HMAC-MD5-96 within ESP and AH (S, November 1998) 🧸
[RFC2403] describes HMAC-MD5, an integrity-protection algorithm with a 512-bit blocksize and a 128-bit key and Integrity Check Value (ICV). For use within IPsec, the ICV is truncated to 96 bits. It was a required algorithm for IKEv1 and IPsec-v2. Plain MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC" 🕰️.
Requirement levels for HMAC-MD5:
5.3.5. RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec (S, June 2006) 🌷
[RFC4494] describes AES-CMAC, another variant of CBC-MAC that's secure for messages of varying lengths 🌼. It's an integrity-protection algorithm with a 128-bit blocksize and 128-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits. [RFC4494] includes test data 🧪.
Requirement levels for AES-CMAC:
- IKEv1 - undefined (no IANA #)
- IKEv2 - optional
- IPsec-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
- IPsec-v3 - optional
5.3.6. RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH (S, June 2000) 💜
[RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm with a 512-bit blocksize and a 160-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits.
Requirement levels for HMAC-RIPEMD:
- IKEv1 - undefined (no IANA #)
- IKEv2 - undefined (no IANA #)
- IPsec-v2 - optional
- IPsec-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
5.3.7. RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec (I, May 2007) 🔍
In light of recent attacks on MD5 and SHA-1, [RFC4894] looks at whether the hash functions that IKE and IPsec currently use for key generation, integrity protection, digital signatures, or PKIX certificates need to be replaced 🕵️♀️. It concludes that the algorithms recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] aren't currently susceptible to any known attacks 🙌. Even so, it suggests that implementors add support for AES-XCBC-MAC-96 [RFC3566], AES-XCBC-PRF-128 [RFC4434], and HMAC-SHA-256, -384, and -512 [RFC4868] for future use 🔮. It also suggests that IKEv2 implementors add support for PKIX certificates signed with SHA-256, -384, and -512 🎀.
5.4. Combined Mode Algorithms ✨
okay so IKEv1 and ESP-v2 use separate algorithms for encryption and integrity protection 🧁, and IKEv1 can mix and match different combos for different SAs. then ESP-v3 dropped a whole new class of algorithms where ONE algorithm does encryption AND integrity protection 🤯 it's giving efficiency. [RFC5996] explains how IKEv2 can negotiate combined mode algorithms for ESP-v3 SAs, and [RFC5282] gives IKEv2 that same power so it can use them for its OWN traffic 💅. when they're designed well, they can be more efficient to implement and to run ✨
ESP-v2 didn't originally have combined mode algorithms, but some IKEv1 implementations added the ability to negotiate them for IPsec SAs anyway 🙈. those implementations don't let you use combined mode to protect IKE SAs though. and IANA numbers for combined mode algorithms got added to the IKEv1 registry too 🎀
5.4.1. RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) (S, December 2005)
okay so [RFC4309] is all about using AES in counter with CBC-MAC (CCM) mode 🔐, which is a combined algorithm that encrypts AND integrity protects ESP traffic. the vibe: AES-CCM is a block-mode cipher with a 128-bit blocksize 🧱, a random IV that gets sent in the packet with the encrypted data 🎲, a 24-bit salt value (1/SA) 🧂, keysizes of 128, 192, and 256 bits, and ICV sizes of 64, 96 and 128 bits 📦.
if AES-CCM is implemented, 128-bit keys are MUST; the other sizes are MAY. ICV sizes of 64 and 128 bits are MUST; 96 bits is MAY. the salt value gets generated by IKE during the key-generation process 🧂✨
⚠️ bestie, reusing the IV with the same key totally compromises the data's security 💀 so AES-CCM should not be used with manual keying. don't be that person 🙅♀️
[RFC4309] includes IANA values that IKE can use to negotiate ESP-v3 SAs 🎟️. each of the three ICV lengths has its own IANA value, but IKE negotiations still need to specify the keysize. it also includes test data 🧪, and it describes how IKE can negotiate AES-CCM for an ESP SA. then [RFC5282] extends that to AES-CCM protecting an IKEv2 SA 🫶
Requirement levels for AES-CCM:
IKEv1 - N/A
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional [RFC4835]NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. 🙃
5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) (S, June 2005)
the GCM girlie of the group 💜 [RFC4106] describes how to use AES in Galois/Counter (GCM) mode, another combined algorithm that encrypts and integrity protects ESP traffic. AES-GCM is a block-mode cipher with a 128-bit blocksize 🧱, a random IV sent in the packet along with the encrypted data 🎲, a 32-bit salt value (1/SA) 🧂, keysizes of 128, 192, and 256 bits, and ICV sizes of 64, 96, and 128 bits 📦.
if AES-GCM is implemented, 128-bit keys are MUST; the other sizes are MAY. an ICV size of 128 bits is a MUST; 64 and 96 bits are MAY. the salt value is generated by IKE during the key-generation process ✨
⚠️ same energy as CCM: reusing the IV with the same key compromises the data's security 😭 so AES-GCM should not be used with manual keying.
[RFC4106] includes IANA values that IKE can use to negotiate ESP-v3 SAs. each of the three ICV lengths has its own IANA value, but IKE negotiations need to specify the keysize. it also includes test data 🧪 and describes how IKE can negotiate AES-GCM for an ESP SA. [RFC5282] extends this to AES-GCM protecting an IKEv2 SA 🌸
Requirement levels for AES-GCM:
IKEv1 - N/A
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional [RFC4835]NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. 🫠
5.4.3. RFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH (S, May 2006)
okay so [RFC4543] is the AES-GCM variant [RFC4106] that does integrity protection WITHOUT encryption 👀 it's giving "authenticate but don't hide" 🕵️♀️. there are two versions: one integrity-protection algorithm for use within AH, and one combined mode algorithm with null encryption for use within ESP. it can use a 128-, 192-, or 256-bit key 🔑. the ICV is always 128 bits and is never truncated 📏
AES-GMAC uses a nonce made of a 64-bit IV and a 32-bit salt (1/SA) 🧂. the salt value gets generated by IKE during the key generation process. reusing the salt value with the same key compromises the data's security, so AES-GMAC should not be used with manual keying 💅
for use within AH, each keysize has its own IANA value, so IKE does not have to negotiate the keysize. for use within ESP, there's only ONE IANA value, so IKE negotiations must specify the keysize 🎀. and AES-GMAC cannot be used by IKE to protect its own SAs, since IKE traffic requires encryption 🙅♀️
Requirement levels for AES-GMAC:
IKEv1 - N/A
IKEv2 - N/A
IPsec-v2 - N/A
IPsec-v3 - optionalNOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. 🙃
5.4.4. RFC 5282, Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol (S, August 2008)
[RFC5282] is the glow-up that extends [RFC4309] and [RFC4106] so AES-CCM and AES-GCM can provide encryption and integrity protection for IKEv2 messages 💖✨
5.5. Pseudo-Random Functions (PRFs)
okay PRFs are the things IKE uses to generate the secret keys for its IKE SAs and IPsec SAs 🗝️. these are generally the same algorithms used for integrity protection, but their output is NOT truncated, since basically all the generated bits are needed for the keys 💅. if a PRF's output isn't long enough for the keying material you need, the PRF gets applied iteratively until you have enough 🔁
for each IKEv2 SA, the peers negotiate BOTH a PRF algorithm and an integrity-protection algorithm 👯♀️. the PRF generates the keying material and other values, and the integrity-protection algorithm protects the IKE SA's traffic.
IKEv1's approach is more complicated 🥴. [RFC2409] doesn't specify any PRF algorithms. for each IKEv1 SA, the peers agree on an unkeyed hash function (e.g., SHA-1) 🍞. IKEv1 uses the HMAC version of that function to generate keying material and to provide integrity protection for the IKE SA. so PRFs that aren't HMACs can't currently be used in IKEv1 🙅♀️
Requirement levels for PRF-HMAC-SHA1:
IKEv1 - MUST [RFC4109]
IKEv2 - MUST [RFC4307]Requirement levels for PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512:
IKEv1 - optional [RFC4868]
IKEv2 - optional [RFC4868]5.5.1. RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) (S, February 2006)
so [RFC3566] defines AES-XCBC-MAC-96, which is used for integrity protection within IKE and IPsec 🔒. [RFC4434] then enables AES-XCBC-MAC as a PRF within IKE 🎉. the PRF differs from the integrity-protection algorithm in two ways 👀: its 128-bit output is NOT truncated to 96 bits, and it accepts a variable-length key, which gets modified (lengthened via padding or shortened through application of AES-XCBC) into a 128-bit key 🧩. [RFC4434] includes test data 🧪
Requirement levels for AES-XCBC-PRF:
IKEv1 - undefined (no RFC)
IKEv2 - SHOULD+ [RFC4307]NOTE: RFC 4109 erroneously classifies AES-XCBC-PRF as SHOULD for IKEv1; this has been corrected in an errata submission for RFC 4109. 🙈
5.5.2. RFC 4615, The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudorandom Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) (S, August 2006)
[RFC4615] extends [RFC4494] to enable AES-CMAC as a PRF within IKEv2 🌈, in a way that's analogous to what [RFC4434] does for AES-XCBC. it's the same pattern, just a different MAC, so it's giving sisterhood 💜
Requirement levels for AES-CMAC-PRF:
IKEv1 - undefined (no IANA #)
IKEv2 - optional5.6. Cryptographic Suites
5.6.1. RFC 4308, Cryptographic Suites for IPsec (S, December 2005)
okay so an IKE negotiation has MULTIPLE cryptographic attributes, for both the IKE SA and the IPsec SA 🧠. the number of possible combinations can make it hard for peers to find a common policy 😵💫. to make life easier, [RFC4308] defines two pre-defined suites that bundle up combinations of algorithms for typical security policies 🎁. IKE/ESP suite "VPN-A" includes 3DES, HMAC-SHA-1, and 1024-bit modular exponentiation group (MODP) Diffie-Hellman (DH) 🍼. IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit MODP DH ✨. these are meant to be "single-button" choices in the admin interface, but they don't stop you from using alternative combinations 🎛️
5.6.2. RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007)
[RFC4869] adds four more pre-defined suites 💎, based on the United States National Security Agency's "Suite B" specifications, on top of the ones in [RFC4308]. IKE/ESP suites "Suite-B-GCM-128" and "Suite-B-GCM-256" include AES-CBC, AES-GCM, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or 384-bit elliptic-curve (EC) DH groups 🌟. IKE/AH suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include AES-CBC, AES-GMAC, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or 384-bit EC DH groups 🫧
here's the tea ☕: while [RFC4308] doesn't specify a peer-authentication method, [RFC4869] mandates pre-shared key authentication for IKEv1. public key authentication using ECDSA is recommended for IKEv1 and required for IKEv2 🔑✨
5.7. Diffie-Hellman Algorithms
IKE negotiations include a Diffie-Hellman exchange 🤝, which establishes a shared secret that BOTH parties contributed to. this value is used to generate the keying material that protects both the IKE SA and the IPsec SA 🔐
[RFC2409] contains definitions of two DH MODP groups and two elliptic curve (EC) groups, while IKEv2 [RFC5996] only references the MODP groups 🫶. the requirement levels for these groups are:
Requirement levels for DH MODP group 1:
IKEv1 - MAY [RFC4109]
IKEv2 - optionalRequirement levels for DH MODP group 2:
IKEv1 - MUST [RFC4109]
IKEv2 - MUST- [RFC4307]Requirement levels for EC groups 3-4:
IKEv1 - MAY [RFC4109]
IKEv2 - undefined (no IANA #)5.7.1. RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) (S, May 2003)
[RFC2409] and [RFC5996] define two MODP DH groups (groups 1 and 2) for use within IKE 🧁. [RFC3526] adds six more groups (groups 5 and 14-18) 🌸. group 14 is a 2048-bit group that is strongly recommended for use in IKE 💅✨
Requirement levels for DH MODP group 14:
IKEv1 - SHOULD [RFC4109]
IKEv2 - SHOULD+ [RFC4307]Requirement levels for DH MODP groups 5, 15-18:
IKEv1 - optional [RFC4109]
IKEv2 - optional5.7.2. RFC 4753, ECP Groups For IKE and IKEv2 (I, January 2007) 🦋
Okay so [RFC4753] defines three EC DH groups (groups 19-21) for use within IKE. Iconic. 💅
The document includes test data. ✨
Requirement levels for DH EC groups 19-21:
- IKEv1 - optional [RFC4109]
- IKEv2 - optional
5.7.3. RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2 (I, June 2010) 🌸
Bestie, [RFC5903] obsoletes [RFC4753], and it's giving fixing an inconsistency in the DH shared secret value. 🙈 Very much a glow-up moment. 💖
5.7.4. RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards (I, January 2008) 🧚
So [RFC5114] defines five additional DH groups (MODP groups 22-24 and EC groups 25-26) for use in IKE. ✨ It also includes three EC DH groups (groups 19-21) that were originally defined in [RFC4753]. Lowkey confusing, but the current specification for those groups is [RFC5903], so that's the one to check. 🫶
Also, the IANA group numbers are specific to IKE, but the DH groups are intended for use in multiple IETF protocols, including Transport Layer Security/Secure Socket Layer (TLS/SSL), Secure/Multipurpose Internet Mail Extensions (S/MIME), and X.509 Certificates. Main character energy, honestly. 👑
Requirement levels for DH MODP groups 22-24 and EC groups 25-26:
- IKEv1 - optional
- IKEv2 - optional
6. IPsec/IKE for Multicast 🌈
Okay, so [RFC4301] describes IPsec processing for unicast and multicast traffic. 🎀 But here's the tea: classical IPsec SAs give you point-to-point protection. The security IPsec's crypto algorithms provide is not applicable when the SA is one-to-many or many-to-many, which is exactly the multicast situation. 💀
The Multicast Security (msec) Working Group came up with alternatives to IKE and extensions to IPsec for multicast traffic. ✨ Different multicast groups have totally different vibes and requirements: the number of senders (one-to-many or many-to-many), the number of members (few, moderate, very large), how volatile membership is, real-time delivery, and so on. Their security needs vary too. So each solution msec defined only fits a subset of the huge variety of multicast groups. 🍓
6.1. RFC 3740, The Multicast Group Security Architecture (I, March 2004) 🦋
[RFC3740] defines the multicast security architecture, which provides security for packets exchanged by large multicast groups. 🫶 It lays out the components of the architectural framework and discusses Group Security Associations (GSAs), key management, data handling, and security policies.
Several existing protocols satisfy the group key management requirements defined in this document: Group DOI (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], and Multimedia Internet KEYing (MIKEY) [RFC3830]. ✨ Both the architecture and the components for Multicast Group Security are different from IPsec, so don't mix them up, bestie. 🙈
6.2. RFC 5374, Multicast Extensions to the Security Architecture for the Internet Protocol (S, November 2008) 💜
[RFC5374] extends the security architecture defined in [RFC4301] so it applies to multicast traffic. ⭐ It defines a new class of SAs (GSAs - Group Security Associations) and additional databases used to apply IPsec protection to multicast traffic. It also describes revisions and additions to the processing algorithms in [RFC4301]. Iconic. 🔥
6.3. RFC 3547, The Group Domain of Interpretation (S, July 2003) 🌸
GDOI [RFC3547] extends IKEv1 so it can be used to establish SAs that protect multicast traffic. 💖 This document defines additional exchanges and payloads to be used for that purpose. ✨
6.4. RFC 4046, Multicast Security (MSEC) Group Key Management Architecture (I, April 2005) 🧚
[RFC4046] sets out the general requirements and design principles for protocols used for multicast key management. 🎀 It does not go into the specifics of any individual protocol that can be used for that purpose. Not its job, babe. 💅
6.5. RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, January 2006) 🦋
[RFC4359] describes using the RSA digital signature algorithm to provide integrity protection for multicast traffic within ESP and AH. 🌈 The algorithms used for unicast integrity protection (e.g., HMAC) are not suitable for this purpose when used with multicast traffic. ⚠️ Not the vibe for multicast, periodt. 🙅
7. Outgrowths of IPsec/IKE 🌟
Operational experience with IPsec revealed extra capabilities that could make IPsec more useful in real-world scenarios. ✨ These include support for IPsec policy mechanisms, IPsec MIBs, payload compression (IPComp), extensions that facilitate additional peer authentication methods (Better-Than-Nothing Security (BTNS), Kerberized Internet Negotiation of Keys (KINK), and IPSECKEY), and additional capabilities for VPN clients (IPSRA). 💖
7.1. IPsec Policy 🎀
The IPsec Policy (ipsp) Working Group originally planned an RFC that would allow entities with no common Trust Anchor and no prior knowledge of each other's security policies to establish an IPsec-protected connection. 🥺 The solutions proposed for gateway discovery and security policy negotiation turned out to be overly complex and fragile, especially without prior knowledge or compatible configuration policies. 💀
7.1.1. RFC 3586, IP Security Policy (IPSP) Requirements (S, August 2003) 🦋
[RFC3586] describes the functional requirements of a generalized IPsec policy framework, one that could be used to discover, negotiate, and manage IPsec policies. 🫶
7.1.2. RFC 3585, IPsec Configuration Policy Information Model (S, August 2003) 🧚
As stated in [RFC3585]:
This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints.
This RFC has not been widely adopted. 😭
7.2. IPsec MIBs 🌸
Over the years, several MIB-related Internet Drafts were proposed for IPsec and IKE, but only one progressed to RFC status. ✨
7.2.1. RFC 4807, IPsec Security Policy Database Configuration MIB (S, March 2007) 💜
[RFC4807] defines a MIB module that can be used to configure the SPD of an IPsec device. This RFC has not been widely adopted. 😭
7.3. IPComp (Compression) 🌈
The IP Payload Compression Protocol (IPComp) provides lossless compression for IP datagrams. ✨ Although IKE can be used to negotiate the use of IPComp in conjunction with IPsec, IPComp can also be used when IPsec is not applied. Flexible, bestie. 🫶
IPComp lets you compress IP datagrams by supporting different compression algorithms. Three of these are: DEFLATE [RFC2394], LZS [RFC2395], and the ITU-T V.44 Packet Method [RFC3051], which is based on the LZJH algorithm. 🎀
7.3.1. RFC 3173, IP Payload Compression Protocol (IPComp) (S, September 2001) 🦋
IP payload compression is especially useful when IPsec-based encryption is applied to IP datagrams. 🔥 Encrypting the datagram makes the data random in nature, which renders compression at lower protocol layers ineffective. 💀 If IKE is used to negotiate compression in conjunction with IPsec, compression can be performed prior to encryption. ✨ [RFC3173] defines the payload compression protocol, the IPComp packet structure, the IPComp Association (IPCA), and several methods to negotiate the IPCA. 🧚
7.4. Better-Than-Nothing Security (BTNS) 💖
One of the major obstacles to widespread IPsec implementation is the lack of pre-existing credentials that can be used for peer authentication. 🥺 Better-Than-Nothing Security (BTNS) is an attempt to sidestep this problem by allowing IKE to negotiate unauthenticated (anonymous) IPsec SAs. It uses credentials such as self-signed certificates or "bare" public keys (public keys that are not connected to a public key certificate) for peer authentication. ✨ This ensures that subsequent traffic protected by the SA is conducted with the same peer, and protects the communications from passive attack. Then these SAs can be cryptographically bound to a higher-level application protocol, which performs its own peer authentication. 🫶
7.4.1. RFC 5660, IPsec Channels: Connection Latching (S, October 2009) 🌸
[RFC5660] specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create channels by latching connections (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. 🎀 Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. 💅
7.4.2. RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec (S, November 2008) 🧚
[RFC5386] specifies how to use IKEv2 to set up unauthenticated security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). ✨ This document does not require any changes to the bits on the wire, but it specifies extensions to the Peer Authorization Database (PAD) and Security Policy Database (SPD). No bit changes, just vibes. 💜
7.4.3. RFC 5387, Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) (I, November 2008) 🦋
[RFC5387] considers that the need to deploy authentication information and its associated identities is a significant obstacle to using IPsec. 🥺 This document explains the rationale for extending the Internet network security protocol suite so IPsec security services can be used without authentication. 🌈
7.5. Kerberized Internet Negotiation of Keys (KINK) 🔑
Kerberized Internet Negotiation of Keys (KINK) is an attempt to provide an alternative to IKE for IPsec peer authentication. 🫶 It uses Kerberos, instead of IKE, to establish IPsec SAs. For enterprises that already deploy the Kerberos centralized key management system, IPsec can then be implemented without the need for additional peer credentials. ✨ Some vendors have implemented proprietary extensions for using Kerberos in IKEv1, as an alternative to KINK. Those extensions, as well as the KINK protocol, apply only to IKEv1, and not to IKEv2. 💀
7.5.1. RFC 3129, Requirements for Kerberized Internet Negotiation of Keys (I, June 2001) 🌸
[RFC3129] considers that peer-to-peer authentication and keying mechanisms have inherent drawbacks, like computational complexity and difficulty enforcing security policies. 🥺 This document specifies the requirements for using basic Kerberos features and uses them to its advantage to create a protocol that can establish and maintain IPsec security associations ([RFC2401]). 🎀
7.5.2. RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S, March 2006) 💜
[RFC4430] defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. ✨ This document reuses the Quick Mode payloads of IKEv1 in order to foster substantial reuse of IKEv1 implementations. 🧚 This RFC has not been widely adopted. 😭
7.6. IPsec Secure Remote Access (IPSRA) 🧳
okay so IPsec Secure Remote Access (IPSRA) was basically a glow-up attempt 💅 to extend IPsec protection to "road warriors" 🧳, the people working from wherever with their laptops. The goal was to let IKE authenticate not just the user's device but also the user 🫶, and it had to do that without changing IKEv1 🙅♀️. The working group wrote up generic requirements for the different IPsec remote access scenarios 📝. Then they tried an IKE-like protocol that would take legacy authentication mechanisms and turn them into a temporary, short-lived user credential, so peer authentication could happen inside IKE 🔐. Honestly it got way too cumbersome compared to standard Public Key protocols, so it got abandoned 💀. That's what led to IKEv2, which bakes in EAP for user authentication ✨. Iconic redemption arc, no cap 👑.
7.6.1. RFC 3457, Requirements for IPsec Remote Access Scenarios (I, January 2003)
[RFC3457] explores and lists out the requirements of various IPsec remote access scenarios 🗺️. It doesn't suggest any particular solutions for them, just vibes-checks the problem space 🌸.
7.6.2. RFC 3456, Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode (S, January 2003)
[RFC3456] digs into the requirements for host configuration in IPsec tunnel mode 🚇, and shows how the Dynamic Host Configuration Protocol (DHCPv4) can be used to hand out that configuration info 📦. Lowkey underrated, but this RFC has not been widely adopted 😭.
7.7. IPsec Keying Information Resource Record (IPSECKEY) 🗝️
The IPsec Keying Information Resource Record (IPSECKEY) is giving storage realness 💖. It lets you store public keys and other info that can help with opportunistic IPsec, and it does that through a brand-new type of DNS resource record 🧚.
7.7.1. RFC 4025, A method for storing IPsec keying material in DNS (S, February 2005)
[RFC4025] describes a way to store IPsec keying material in DNS using a new type of resource record 🍓. This document explains how to store the public key of the target node in that record 🔑. This RFC has not been widely adopted 🥲.
8. Other Protocols That Use IPsec/IKE 🌈
okay bestie, IPsec and IKE were built to give IP-layer security to other Internet protocols' traffic 🛡️, and to generic communications too 💜. IPsec is a general-purpose protocol, so sometimes its features don't give another protocol the granularity or special features it needs 🤷♀️. And sometimes its overhead or prerequisites just don't match what another protocol wants 🙈. Even so, a bunch of other protocols do use IKE and/or IPsec to protect some or all of their communications 🦋.
8.1. Mobile IP (MIPv4 and MIPv6) 🏃♀️
8.1.1. RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways (I, August 2005)
[RFC4093] breaks down the issues with deploying Mobile IPv4 across virtual private networks (VPNs) 🌐. IPsec is one of the VPN technologies it covers 🔒. It identifies and describes practical deployment scenarios for Mobile IPv4 running alongside IPsec in enterprise and operator environments 🏢. It also sets out framework guidelines for evaluating proposed solutions for multi-vendor seamless IPv4 mobility across IPsec-based VPN gateways ✨.
8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways (S, June 2008)
[RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec together to give session mobility between enterprise intranets and external networks 🎀. The solution keeps changes to existing firewall/VPN/DMZ deployments minimal, and it doesn't require any changes to IPsec or key exchange protocols 🙌. It also proposes a mechanism for minimizing IPsec renegotiation when the mobile node moves 🚶♀️.
8.1.3. RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents (S, June 2004)
This document specifies using IPsec to secure Mobile IPv6 traffic between mobile nodes and home agents 🔐. It spells out the required wire formats for the protected packets, and shows examples of Security Policy Database and Security Association Database entries that can protect Mobile IPv6 signaling messages 📋. It also describes how to configure either manually keyed IPsec security associations or IKEv1 to set up the SAs automatically 🤖. Mobile IPv6 means you have to consider the home address destination option and Routing Header in IPsec processing 🧭. And IPsec and IKE security association addresses can be updated by Mobile IPv6 signaling messages 🔄.
8.1.4. RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (S, April 2007)
This document updates [RFC3776] so it works with the revised IPsec architecture [RFC4301] 🪄. Since that revised architecture adds the Mobility Header message type to the list of selectors, it's way easier to tell apart the different mobility header messages 🕵️♀️. The ICMP message type and code are also newly added as selectors, so this document uses them to protect Mobile Prefix Discovery messages 💅. It also specifies using IKEv2 configuration payloads for dynamic home address configuration 🏠. And finally, it describes using IKEv2 to set up the SAs for Mobile IPv6 💜.
8.1.5. RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, October 2007)
[RFC5026] extends [RFC4877] to support dynamic discovery of home agents and the home network prefix 🧭. For the prefix part, it specifies a new IKEv2 configuration attribute and notification 📣. It describes how a Mobile IPv6 node can get the address of its home agent and its home address, and then create IPsec security associations with that home agent 🤝. It does this using DNS lookups and security credentials preconfigured on the Mobile Node 🗝️. It defines how a mobile node (MN) can request its home address and home prefixes through the Configuration Payload in the IKE_AUTH exchange 📮. It also spells out which attributes need to be present in the CFG_REQUEST messages to make that work 📝. And it specifies how the home agent can authorize the credentials used for the IKEv2 exchange 👑.
8.1.6. RFC 5213, Proxy Mobile IPv6 (S, August 2008)
[RFC5213] describes a network-based mobility management protocol 🛰️. It gives mobility services to hosts without needing them to take part in any mobility-related signaling 🙈. It uses IPsec to protect the mobility signaling messages between the two network entities, the mobile access gateway (MAG) and the local mobility anchor (LMA) 🔒. It also uses IKEv2 to set up the security associations between the MAG and the LMA 🤝.
8.1.7. RFC 5568, Mobile IPv6 Fast Handovers (S, July 2009)
When Mobile IPv6 is used for a handover, there's a stretch of time where the Mobile Node can't send or receive packets 😭, because of link switching delay and IP protocol operations. [RFC5568] specifies a protocol between the Previous Access Router (PAR) and the New Access Router (NAR) to cut down that handover latency 🏎️. It uses IPsec ESP in transport mode with integrity protection to protect the signaling messages between the PAR and the NAR 🛡️. It also describes the SPD entries and the PAD entries when IKEv2 is used to set up the required SAs 📋.
8.1.8. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management (S, October 2008)
[RFC5380] adds extensions to Mobile IPv6 and IPv6 Neighbor Discovery so you can handle mobility locally 🏡. That cuts down how much signaling goes between the mobile node, its correspondent nodes, and its home agent 📉. It also speeds up handovers for Mobile IPv6 ⚡. It uses IPsec to protect the signaling between the mobile node and a local mobility management entity called the Mobility Anchor Point (MAP) 🔐. The MAP also uses IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] to allocate a Regional Care-of Address (RCoA) for mobile nodes 🎯.
8.2. Open Shortest Path First (OSPF) 🛣️
8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 (S, June 2006)
OSPF is a link-state routing protocol designed to run inside a single Autonomous System 🗺️. OSPFv2 had its own authentication mechanisms using the AuType and Authentication protocol header fields, but OSPFv3 removed those fields and uses IPsec instead 🔄. [RFC4552] describes how to use IPsec ESP and AH to protect OSPFv3 signaling between two routers 🔐. It also lists the IPsec capabilities the routers need to support this specification 📜. Finally, it describes how OSPFv3 runs with IPsec over virtual links where the other endpoint isn't known at configuration time 🧩. Since OSPFv3 exchanges multicast packets as well as unicast ones, using IKE within OSPFv3 isn't appropriate 🙅♀️. So this document mandates the use of manual keys 🗝️.
8.3. Host Identity Protocol (HIP) 🆔
8.3.1. RFC 5201, Host Identity Protocol (E, April 2008)
IP addresses do two jobs at once: they're a host identifier and a locator 📍. This document specifies a protocol that lets consenting hosts securely set up and maintain shared IP-layer state 🤝. That allows the identifier and locator roles of IP addresses to be separated 🪄. This enables continuity of communications across IP address (locator) changes 🦋. It uses public key identifiers from a new Host Identity (HI) namespace for peer authentication 🔑. And it uses the HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH to protect its signaling messages 🛡️.
8.3.2. RFC 5202, Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (E, April 2008)
The HIP base exchange specification [RFC5201] doesn't describe any transport formats or methods for how ESP is used to protect user data during the actual communication 🙈. [RFC5202] specifies a set of HIP extensions for creating a pair of ESP Security Associations (SAs) between the hosts during the base exchange 🤝. Once the HIP association and the required ESP SAs are set up between the hosts, user data communication is protected using ESP 🔐. This document also specifies how the ESP Security Parameter Index (SPI) indicates the right host context (host identity), and it describes methods for updating an existing ESP Security Association 🔄.
8.3.3. RFC 5206, End-Host Mobility and Multihoming with the Host Identity (E, April 2008)
When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets) and Encapsulating Security Payload (ESP) Security Associations (SAs) are bound to representations of these host identities 🎀. The IP addresses are only used for packet forwarding 📦. [RFC5206] defines a generalized LOCATOR parameter for use in HIP messages, which lets a HIP host tell a peer about alternate addresses where it can be reached 📬. It also specifies how a host can change its IP address and keep sending packets to its peers without necessarily rekeying 🏃♀️💨.
8.3.4. RFC 5207, NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) (I, April 2008)
[RFC5207] talks about the problems with HIP communication across network paths that include network address translators and firewalls 🧱. It analyzes how NATs and firewalls affect the HIP base exchange and the ESP data exchange 🔍. It discusses possible changes to HIP that try to improve NAT and firewall traversal 🛠️, and it proposes a rendezvous point so HIP nodes behind a NAT can still be reachable 📡. It also suggests mechanisms for NATs to be more aware of the HIP messages 👀.
8.4. Stream Control Transmission Protocol (SCTP) ✨
8.4.1. RFC 3554, On the Use of Stream Control Transmission Protocol (SCTP) with IPsec (S, July 2003) 💖
okay so SCTP (Stream Control Transmission Protocol) is a reliable transport protocol that sits on top of a connection-less packet network like IP 🦋. [RFC3554] lays out the functional requirements for IPsec and IKE when it comes to securing SCTP traffic 🔐. It adds SCTP support by introducing a new ID type in IKE [RFC2409], and by having the IPsec processing account for the multiple source and destination addresses that go with a single SCTP association. ngl that multi-address thing is so iconic 😭. This document applies only to IKEv1 and IPsec-v2; it does not apply to IKEv2 AND IPsec-v3 💀.
8.5. Robust Header Compression (ROHC) 🌈
8.5.1. RFC 3095, RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed (S, July 2001) 🎀
ROHC is a framework for header compression, and it's meant for resource-constrained environments 🔋. [RFC3095] applies this framework to four protocols, and ESP is one of them ✨.
8.5.2. RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008) 🍓
[RFC5225] defines an updated ESP/IP profile for use with ROHC version 2 💅. It analyzes the ESP header and sorts the fields into classes like static, well-known, irregular, and so on, so the headers can be compressed efficiently 🧚.
8.5.3. RFC 5856, Integration of Robust Header Compression over IPsec Security Associations (I, May 2010) 🦋
[RFC5856] describes a mechanism that compresses inner IP headers at the ingress point of IPsec tunnels and decompresses them at the egress point 🚇. Here's the plot twist: the ROHC specifications only describe operations on a per-hop basis, so this document also specifies extensions that enable ROHC over multiple hops 🌸. This document applies only to tunnel mode SAs and does not support transport mode SAs 🙈.
8.5.4. RFC 5857, IKEv2 Extensions to Support Robust Header Compression over IPsec (S, May 2010) 🫶
ROHC needs initial configuration at both the compressor and decompressor ends ⚙️. Because ROHC usually operates per hop, that configuration information is carried over link-layer protocols such as PPP. But [RFC5856] operates over multiple hops, so a different signaling mechanism is required 👀. [RFC5857] describes how to use IKEv2 to dynamically communicate the configuration parameters between the compressor and decompressor 👑.
8.5.5. RFC 5858, IPsec Extensions to Support Robust Header Compression over IPsec (S, May 2010) 💜
[RFC5856] describes how to use ROHC with IPsec, and that isn't possible without extensions to IPsec 😤. [RFC5858] describes the extensions IPsec needs in order to support ROHC. Specifically, it covers extensions to the IPsec SPD, SAD, and IPsec processing, including ICV computation and integrity verification 🔥.
8.6. Border Gateway Protocol (BGP) 🌿
8.6.1. RFC 5566, BGP IPsec Tunnel Encapsulation Attribute (S, June 2009) 🍑
[RFC5566] adds an additional BGP Encapsulation Subsequent Address Family Identifier (SAFI), which allows IPsec and, optionally, IKE to protect BGP tunnels 🛡️. It defines the use of AH and ESP in tunnel mode, and the use of AH and ESP in transport mode, to protect IP in IP and MPLS-in-IP tunnels 🚀. It also defines how public key fingerprints (hashes) are distributed via BGP and used later to authenticate the IKEv2 exchange between the tunnel endpoints 🗝️.
8.7. IPsec Benchmarking 📊
The Benchmarking Methodology WG in the IETF is working on documents that relate to benchmarking IPsec [BMWG-1] [BMWG-2] ⏱️.
8.7.1. Methodology for Benchmarking IPsec Devices (Work in Progress) 🧪
[BMWG-1] defines a set of tests that can measure and report the performance characteristics of IPsec devices 📈. It extends the methodology defined for benchmarking network interconnecting devices so it includes IPsec gateways, and it adds further tests that can measure IPsec performance of end-hosts 💻. The document focuses on a performance testing methodology for IPsec devices that support manual keying and IKEv1, but it does not cover IKEv2 🙅♀️.
8.7.2. Terminology for Benchmarking IPsec Devices (Work in Progress) 📖
[BMWG-2] defines the standardized performance testing terminology for IPsec devices that support manual keying and IKEv1 🧠. It also describes the benchmark tests that would be used to test the performance of those IPsec devices 🏁.
8.8. Network Address Translators (NAT) 🏠
8.8.1. RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains (I, October 1999) 🌍
NAT devices give transparent routing to end-hosts that are trying to communicate from disparate address realms, and they do it by modifying IP and transport headers en route 🗺️. That makes it hard for applications to pursue end-to-end application-level security 😩. [RFC2709] describes a security model in which tunnel mode IPsec security can be architected on NAT devices 🏗️. It defines how NATs administer security policies and SA attributes based on private realm addressing. It also specifies how to operate IKE in such scenarios, by specifying an IKE-ALG (Application Level Gateway) that translates policies from private realm addressing into public addressing 🔁. Although the model here uses terminology from IKEv1, it can be deployed within IKEv1, IKEv2, IPsec-v2, and IPsec-v3 ✨. This security model has not been widely adopted 🥲.
8.9. Session Initiation Protocol (SIP) 📞
8.9.1. RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol (SIP) (S, January 2003) 🤙
[RFC3329] describes how a SIP client can select one of the various available SIP security mechanisms 🎯. In particular, the method allows secure negotiation to prevent bidding down attacks 🛑. It also describes a security mechanism called ipsec-3gpp and its associated parameters (algorithms, protocols, mode, SPIs, and ports) as they are used in the 3GPP IP Multimedia Subsystem 📲.
8.10. Explicit Packet Sensitivity Labels 🏷️
8.10.1. RFC 5570, Common Architecture Label IPv6 Security Option (CALIPSO) (I, July 2009) 🪪
[RFC5570] describes a mechanism for encoding explicit packet Sensitivity Labels on IPv6 packets in Multi-Level Secure (MLS) networks 🕵️♀️. The method is implemented using an IPv6 hop-by-hop option. This document uses the IPsec Authentication Header (AH) to detect any malicious modification of the Sensitivity Label in a packet 🔍.
9. Other Protocols That Adapt IKE for Non-IPsec Functionality 🧩
Some protocols protect their traffic through mechanisms other than IPsec, but they use IKEv2 as the basis for their key negotiation and key management functionality 🔑.
9.1. Extensible Authentication Protocol (EAP) 🪪
9.1.1. RFC 5106, The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method (E, February 2008) 🌟
[RFC5106] specifies an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange version 2 (IKEv2) protocol 🤝. EAP-IKEv2 provides mutual authentication and session-key establishment between an EAP peer and an EAP server 🫂. It describes the full EAP-IKEv2 message exchange and the composition of the protocol messages 📨.
9.2. Fibre Channel 🧵
9.2.1. RFC 4595, Use of IKEv2 in the Fibre Channel Security Association Management Protocol (I, July 2006) 💫
Fibre Channel (FC) is a gigabit-speed network technology used for Storage Area Networking 💾. The Fibre Channel Security Protocols (FC-SP) standard has adapted the IKEv2 protocol [RFC4306] to provide authentication of Fibre Channel entities and set up security associations 🔐. Since IP is transported over Fibre Channel and Fibre Channel is transported over IP, there's real potential for confusion when IKEv2 is used for both IP and FC traffic 😵💫. [RFC4595] specifies identifiers for IKEv2 over FC in a way that ensures any mistaken usage of IKEv2/FC over IP, or IKEv2/IP over FC, will result in a negotiation failure due to the absence of an acceptable proposal 🙅♀️.
9.3. Wireless Security 📡
9.3.1. RFC 4705, GigaBeam High-Speed Radio Link Encryption (I, October 2006) ⚡
[RFC4705] describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio-link products 📶. It is intended to serve as a guideline for similar wireless product development efforts that want comparable capabilities 🛠️. It specifies the algorithms used to provide confidentiality and integrity protection for both subscriber and management traffic 🔒. It also specifies a custom security protocol that runs between two Gigabeam Radio Control Modules (RCMs) 🤖.
10. Acknowledgements 🫶
The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel Montenegro, Sean Turner, Julien Laganier, Grey Daley, Scott Moonen, Richard Graveman, Tero Kivinen, Pasi Eronen, Ran Atkinson, David Black, and Tim Polk for reviewing this document and suggesting changes 💖. Everyone on that list is absolutely iconic 👑.
11. Security Considerations 🔐
This RFC serves as a review of other documents and introduces no new security considerations itself 🧐. However, please see each of the individual documents described herein for security considerations related to each protocol ⚠️. Do not skip those, bestie 😤.
12. References 📚
12.1. Informative References 📖
[BMWG-1]Kaeo, M. and T. Van Herck, "Methodology for Benchmarking IPsec Devices", Work in Progress, July 2009.[BMWG-2]Kaeo, M., Van Herck T., and M. Bustos, "Terminology for Benchmarking IPsec Devices", Work in Progress, July 2009.[IKE-MODE-CFG]Dukes, D. and R. Pereira, "The ISAKMP Configuration Method", Work in Progress, September 2001.[IKE-XAUTH]Beaulieu, S. and R. Pereira, "Extended Authentication within IKE (XAUTH)", Work in Progress, October 2001.[ISAKMP-MODE-CFG]Pereira, R., Anand, S., and B. Patel, "The ISAKKMP Configuration Method", Work in Progress, August 1999.[ISAKMP-XAUTH]Pereira, R. and S. Beaulieu, "Extended Authentication within ISAKMP/Oakley (XAUTH)", Work in Progress, December 1999.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2026]Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.[RFC2394]Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.[RFC2395]Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.[RFC2401]Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.[RFC2402]Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.[RFC2403]Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.[RFC2404]Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.[RFC2405]Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.[RFC2406]Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.[RFC2407]Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.- [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
- [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
- [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
- [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
- [RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999.
- [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
- [RFC2857] Keromytis, A. and N. Provos, "The Use of HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June 2000.
- [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using ITU-T V.44 Packet Method", RFC 3051, January 2001.
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
- [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
- [RFC3129] Thomas, M., "Requirements for Kerberized Internet Negotiation of Keys", RFC 3129, June 2001.
- [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
- [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
- [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
- [RFC3457] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec Remote Access Scenarios", RFC 3457, January 2003.
- [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
- [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
- [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
- [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
- [RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003.
- [RFC3586] Blaze, M., Keromytis, A., Richardson, M., and L. Sanchez, "IP Security Policy (IPSP) Requirements", RFC 3586, August 2003.
- [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
- [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
- [RFC3706] Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", RFC 3706, February 2004.
- [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
- [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
- [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
- [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
- [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
- [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
- [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
- [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
- [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
- [RFC4093] Adrangi, F., Ed., and H. Levkowetz, Ed., "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005.
- [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
- [RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 1 (IKEv1)", RFC 4109, May 2005.
- [RFC4196] Lee, H., Yoon, J., Lee, S., and J. Lee, "The SEED Cipher Algorithm and Its Use with IPsec", RFC 4196, October 2005.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, December 2005.
- [RFC4305] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
- [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
- [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, December 2005.
- [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
- [RFC4312] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher Algorithm and Its Use With IPsec", RFC 4312, December 2005.
- [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005.
- [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
- [RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
- [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006.
- [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
- [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 Algorithm and Its Use with IPsec", RFC 4494, June 2006.
- [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
- [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
- [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
- [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
- [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006.
- [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006.
- [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, August 2006.
- [RFC4705] Housley, R. and A. Corry, "GigaBeam High-Speed Radio Link Encryption", RFC 4705, October 2006.
- [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
- [RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol", RFC 4739, November 2006.
- [RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC 4753, January 2007.
- [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007.
- [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
- [RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec Security Policy Database Configuration MIB", RFC 4807, March 2007.
- [RFC4809] Bonatti, C., Ed., Turner, S., Ed., and G. Lebovitz, Ed., "Requirements for an IPsec Certificate Management Profile", RFC 4809, February 2007.
- [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
- [RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007.
- [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
- [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
Okay bestie, the reference list keeps going 💖 These are the informative ones, and yes, every single entry comes along for the ride 🎀
- [RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec", RFC 4894, May 2007.
- [RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
- [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
- [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.
- [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
- [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
- [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
- [RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
- [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
- [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
- [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
- [RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
- [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008.
- [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008.
- [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
- [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
- [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
- [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008.
- [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009.
- [RFC5529] Kato, A., Kanda, M., and S. Kanno, "Modes of Operation for Camellia for Use with IPsec", RFC 5529, April 2009.
- [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, June 2009.
- [RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
- [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
- [RFC5660] Williams, N., "IPsec Channels: Connection Latching", RFC 5660, October 2009.
- [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, November 2009.
- [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
- [RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, February 2010.
- [RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility", RFC 5840, April 2010.
- [RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, "Integration of Robust Header Compression over IPsec Security Associations", RFC 5856, May 2010.
- [RFC5857] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, "IKEv2 Extensions to Support Robust Header Compression over IPsec", RFC 5857, May 2010.
- [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec Extensions to Support Robust Header Compression over IPsec", RFC 5858, May 2010.
- [RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting ESP-NULL Packets", RFC 5879, May 2010.
- [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.
- [RFC5930] Shen, S., Mao, Y., and NSS. Murthy, "Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol", RFC 5930, July 2010.
- [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
- [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010.
- [RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010.
Appendix A. Summary of Algorithm Requirement Levels ✨
okay bestie, this is the big cheat sheet 📋💅 it lists every algorithm and how strict each protocol version is about it, across IKEv1, IKEv2, IPsec-v2 and IPsec-v3. here's the first table 🎀
Table 1: Algorithm Requirement Levels
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Encryption Algorithms: |
|--------------------- |
| ESP-NULL | N/A N/A MUST MUST |
| | |
| 3DES-CBC | MUST MUST- MUST MUST- |
| | |
| Blowfish/CAST/IDEA/RC5 | optional optional optional optional |
| | |
| AES-CBC 128-bit key | SHOULD SHOULD+ MUST MUST |
| | |
| AES-CBC 192/256-bit key | optional optional optional optional |
| | |
| AES-CTR | undefined optional SHOULD SHOULD |
| | |
| Camellia-CBC | optional optional optional optional |
| | |
| Camellia-CTR | undefined undefined undefined optional |
| | |
| SEED-CBC | undefined undefined optional undefined|
| | |
|Integrity-Protection Algorithms: |
|------------------------------ |
| HMAC-SHA-1 | MUST MUST MUST MUST |
| | |
| AES-XCBC-MAC | undefined optional SHOULD+ SHOULD+ |
| | |
| HMAC-SHA-256/384/512 | optional optional optional optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| HMAC-MD5 | MAY optional MAY MAY |
| | |
| AES-CMAC | undefined optional undefined optional |
| | |
| HMAC-RIPEMD | undefined undefined optional undefined|
+--------------------------+----------------------------------------+
Table 1: Algorithm Requirement Levels (continued)
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Combined Mode Algorithms: |
|------------------------ |
| AES-CCM | N/A optional N/A optional |
| | |
| AES-GCM | N/A optional N/A optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| Camellia-CCM | N/A undefined N/A optional |
| | |
|Pseudorandom Functions: |
|----------------------- |
| PRF-HMAC-SHA1 | MUST MUST |
| | |
| PRF-HMAC-SHA-256/384/512 | optional optional |
| | |
| AES-XCBC-PRF | undefined SHOULD+ |
| | |
| AES-CMAC-PRF | undefined optional |
| | |
|Diffie-Hellman Algorithms: |
|------------------------- |
| DH MODP grp 1 | MAY optional |
| | |
| DH MODP grp 2 | MUST MUST- |
| | |
| DH MODP grp 5 | optional optional |
| | |
| DH MODP grp 14 | SHOULD SHOULD+ |
| | |
| DH MODP grp 15-18 | optional optional |
| | |
| DH MODP grp 22-24 | optional optional |
| | |
| DH EC grp 3-4 | MAY undefined |
| | |
| DH EC grp 19-21 | optional optional |
| | |
| DH EC grp 25-26 | optional optional |
+--------------------------+----------------------------------------+Authors' Addresses 🦋
here are the lovely people who wrote this 🫶 you can reach them at the details below 💌
Sheila Frankel
NIST
Bldg. 223 Rm. B366
Gaithersburg, MD 20899
Phone: 1-301-975-3297
EMail: sheila.frankel@nist.gov
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: 1-514-345-7900 x42871
EMail: suresh.krishnan@ericsson.comthat's the whole thing, bestie, we made it through all 13 parts 🌈👑🥹
📦 where this page comes from
- ietf: rfc6071 2011-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms