RFC 2408
Internet Security Association and Key Management Protocol (ISAKMP)
Internet Security Association and Key Management Protocol (ISAKMP) ✨
🎀 Title block tea: this one is from the Network Working Group and is RFC 2408. It's a Standards Track doc dated November 1998. The authors are D. Maughan (National Security Agency), M. Schertler (Securify, Inc.), M. Schneider (National Security Agency), and J. Turner (RABA Technologies, Inc.). The header doesn't list anything it obsoletes or updates, so there's no drama there 💅
Status of this Memo
Okay so this memo is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🦋 If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💜
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. 🔒
Abstract
Okay bestie, this memo is about the security stuff you need to set up Security Associations (SA) and cryptographic keys on the Internet 🌈 An SA protocol that negotiates, sets up, modifies, and deletes SAs and their attributes is totally essential for an evolving Internet, where there are loads of security mechanisms and several options for each one 😭 The key management protocol also has to be super robust, handling public key generation for the whole Internet community and private key needs for the private networks that want that 👑
ISAKMP (the Internet Security Association and Key Management Protocol) is the one that defines how to authenticate a communicating peer, how to create and manage SAs, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks) 🛡️ Honestly, all of this is needed to set up and keep secure communications going (via IP Security Service or any other security protocol) in an Internet environment. It's giving main character energy ✨
Table of Contents
1 Introduction 4
1.1 Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . 5
1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . 6
1.4 Security Associations and Management . . . . . . . . . . . 7
1.4.1 Security Associations and Registration . . . . . . . . 7
1.4.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 8
1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Certificate Authorities . . . . . . . . . . . . . . . 9
1.5.2 Entity Naming . . . . . . . . . . . . . . . . . . . . 9
1.5.3 ISAKMP Requirements . . . . . . . . . . . . . . . . . 10
1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . 10
1.6.1 Key Exchange Properties . . . . . . . . . . . . . . . 11
1.6.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 12
1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . 12
1.7.1 Anti-Clogging (Denial of Service) . . . . . . . . . . 12
1.7.2 Connection Hijacking . . . . . . . . . . . . . . . . . 13
1.7.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 13
1.8 Multicast Communications . . . . . . . . . . . . . . . . . 13
2 Terminology and Concepts 14
2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . 14
2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . 16
2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . 16
2.4 Identifying Security Associations . . . . . . . . . . . . . 17
2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Transport Protocol . . . . . . . . . . . . . . . . . . 20
2.5.2 RESERVED Fields . . . . . . . . . . . . . . . . . . . 20
2.5.3 Anti-Clogging Token ("Cookie") Creation . . . . . . . 20
3 ISAKMP Payloads 21
3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 21
3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Security Association Payload . . . . . . . . . . . . . . . 27
3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . 28
3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . 29
3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . 31
3.8 Identification Payload . . . . . . . . . . . . . . . . . . 32
3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . 33
3.10 Certificate Request Payload . . . . . . . . . . . . . . . 34
3.11 Hash Payload . . . . . . . . . . . . . . . . . . . . . . 36
3.12 Signature Payload . . . . . . . . . . . . . . . . . . . . 37
3.13 Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 37
3.14 Notification Payload . . . . . . . . . . . . . . . . . . 38
3.14.1 Notify Message Types . . . . . . . . . . . . . . . . 40
3.15 Delete Payload . . . . . . . . . . . . . . . . . . . . . 41
3.16 Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 43
4 ISAKMP Exchanges 44
4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . 45
4.1.1 Notation . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Security Association Establishment . . . . . . . . . . . . 46
4.2.1 Security Association Establishment Examples . . . . . 48
4.3 Security Association Modification . . . . . . . . . . . . . 50
4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Identity Protection Exchange . . . . . . . . . . . . . . . 52
4.6 Authentication Only Exchange . . . . . . . . . . . . . . . 54
4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . 55
4.8 Informational Exchange . . . . . . . . . . . . . . . . . . 57
5 ISAKMP Payload Processing 58
5.1 General Message Processing . . . . . . . . . . . . . . . . 58
5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . 59
5.3 Generic Payload Header Processing . . . . . . . . . . . . . 61
5.4 Security Association Payload Processing . . . . . . . . . . 62
5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . 63
5.6 Transform Payload Processing . . . . . . . . . . . . . . . 64
5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . 65
5.8 Identification Payload Processing . . . . . . . . . . . . . 66
5.9 Certificate Payload Processing . . . . . . . . . . . . . . 66
5.10 Certificate Request Payload Processing . . . . . . . . . 67
5.11 Hash Payload Processing . . . . . . . . . . . . . . . . . 69
5.12 Signature Payload Processing . . . . . . . . . . . . . . 69
5.13 Nonce Payload Processing . . . . . . . . . . . . . . . . 70
5.14 Notification Payload Processing . . . . . . . . . . . . . 71
5.15 Delete Payload Processing . . . . . . . . . . . . . . . . 73
6 Conclusions 75
A ISAKMP Security Association Attributes 77
A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . 77
A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . 77
A.3 Supported Security Protocols . . . . . . . . . . . . . . . 77
A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . 78
A.4.1 ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.2 ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . 78
A.4.3 ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.4 ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . 78
B Defining a new Domain of Interpretation 79
B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . 80
B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . 80
B.4 Syntax for Specifying Security Services . . . . . . . . . . 80
B.5 Payload Specification . . . . . . . . . . . . . . . . . . . 80
B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . 80
Security Considerations 81
IANA Considerations 81
Domain of Interpretation 81
Supported Security Protocols 82
Acknowledgements 82
References 82
Authors' Addresses 85
Full Copyright Statement 86List of Figures
1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . 16
2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 22
3 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 26
5 Security Association Payload . . . . . . . . . . . . . . . 27
6 Proposal Payload Format . . . . . . . . . . . . . . . . . . 28
7 Transform Payload Format . . . . . . . . . . . . . . . . . 30
8 Key Exchange Payload Format . . . . . . . . . . . . . . . . 31
9 Identification Payload Format . . . . . . . . . . . . . . . 32
10 Certificate Payload Format . . . . . . . . . . . . . . . . 33
11 Certificate Request Payload Format . . . . . . . . . . . . 34
12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . 36
13 Signature Payload Format . . . . . . . . . . . . . . . . . 37
14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . 38
15 Notification Payload Format . . . . . . . . . . . . . . . . 39
16 Delete Payload Format . . . . . . . . . . . . . . . . . . . 42
17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . 441. Introduction ✨
okay so this doc is all about the Internet Security Association and Key Management Protocol, aka ISAKMP 💖. It mixes together three big security ideas: authentication, key management, and security associations. The goal is that everyone gets the security they need for government, business, and private stuff on the Internet 🔐.
The Internet Security Association and Key Management Protocol (ISAKMP) sets the rules for how to establish, negotiate, change, and delete Security Associations (SAs) 🦋. An SA holds all the info needed to run different network security services, like IP layer services (header authentication and payload encapsulation), transport or application layer services, or protecting the negotiation traffic itself 🛡️. ISAKMP also has payloads for swapping key generation and authentication data. These formats give everyone one consistent framework for moving key and auth data around, no matter which key generation technique, encryption algorithm, or authentication mechanism you pick 🎀.
ISAKMP is separate from key exchange protocols on purpose 🙈. This keeps the nitty-gritty of SA management (and key management) apart from the details of key exchange. There may be lots of key exchange protocols, each with its own security properties. But we still need a shared framework for agreeing on the format of SA attributes and for negotiating, modifying, and deleting SAs. ISAKMP is that framework 👑.
Splitting things into three parts does add complexity to the security analysis of a full ISAKMP implementation, ngl 😭. But the separation is critical for interoperability between systems with different security requirements, and it should also make it easier to analyze future changes to an ISAKMP server.
ISAKMP is meant to support negotiating SAs for security protocols at every layer of the network stack (e.g., IPSEC, TLS, TLSP, OSPF, etc.) 🌈. By centralizing SA management, ISAKMP cuts down on duplicated functionality inside each security protocol. It can also reduce connection setup time by negotiating a whole stack of services at once ⚡.
The rest of section 1 explains why security negotiation matters and walks through the main pieces of ISAKMP: Security Associations and Management, Authentication, Public Key Cryptography, and Miscellaneous items 🧚. Section 2 covers the terminology and concepts. Section 3 describes the ISAKMP payload formats. Section 4 explains how those payloads get composed into exchange types to establish SAs and do key exchanges in an authenticated way, and it also covers SA modification, deletion, and error notification 📦. Section 5 goes through how each payload is processed inside ISAKMP exchanges, including error handling and the actions that go with it 🔍. The appendices give the attribute values ISAKMP needs and the requirements for defining a new Domain of Interpretation (DOI) within ISAKMP 💅.
1.1. Requirements Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC-2119] 📖.
1.2. The Need for Negotiation
ISAKMP takes the idea from [DOW92] that authentication and key exchanges must be combined for better security, and extends it to include security association exchanges 🫶. Which security services you need depends on your network setup and environment. Organizations set up Virtual Private Networks (VPN), also known as Intranets, that need one set of security functions for communicating inside the VPN and possibly lots of different ones for communicating outside it. That covers geographically separate organizational components, customers, suppliers, sub-contractors (with their own VPNs), government, and others 🌍.
Departments inside large organizations may need several SAs to separate and protect data (like personnel data, company proprietary data, and medical data) on internal networks, plus other SAs to communicate within the same department 🗂️. Nomadic users who want to "phone home" are their own whole set of security requirements 📱. These requirements have to be balanced against bandwidth challenges 🐢. Smaller groups may meet their security requirements by setting up "Webs of Trust" 🕸️.
ISAKMP exchanges let all these networking communities show peers the security functionality the user supports, in an authenticated and protected way, and agree on a common set of security attributes, i.e. an interoperable security association 🤝.
1.3. What can be Negotiated?
Security associations must support different encryption algorithms, authentication mechanisms, and key establishment algorithms for other security protocols, as well as IP Security 💫. SAs must also support host-oriented certificates for lower layer protocols and user-oriented certificates for higher level protocols 📜. Algorithm and mechanism independence is required in applications like e-mail, remote login, and file transfer, as well as in session oriented protocols, routing protocols, and link layer protocols 💌. ISAKMP gives one common security association and key establishment protocol for this whole wide range of security protocols, applications, security requirements, and network environments 🎀.
ISAKMP isn't bound to any specific cryptographic algorithm, key generation technique, or security mechanism 🙌. This flexibility is super beneficial for a few reasons. First, it supports the dynamic communications environment described above. Second, being independent of specific security mechanisms and algorithms gives a forward migration path to better ones. When improved security mechanisms come out, or new attacks against current encryption algorithms, authentication mechanisms, and key exchanges are discovered, ISAKMP lets you update the algorithms and mechanisms without developing a completely new KMP or patching the current one 🔄.
ISAKMP has basic requirements for its authentication and key exchange components 🔐. These requirements guard against denial of service, replay / reflection, man-in-the-middle, and connection hijacking attacks. That matters because these are the exact types of attacks that get targeted at protocols 🚨. Complete Security Association (SA) support, which gives mechanism and algorithm independence, plus protection from protocol threats, are the big strengths of ISAKMP 💪.
1.4. Security Associations and Management
A Security Association (SA) is a relationship between two or more entities that describes how the entities will use security services to communicate securely 🤍. This relationship is represented by a set of information that you can think of as a contract between the entities. The information must be agreed upon and shared between all the entities. Sometimes the information alone is called an SA, but that's just a physical instantiation of the existing relationship 📝. The existence of this relationship, represented by the information, is what provides the agreed upon security information entities need to securely interoperate. All entities must adhere to the SA for secure communications to be possible 🫡.
When accessing SA attributes, entities use a pointer or identifier called the Security Parameter Index (SPI). [SEC-ARCH] provides details on IP Security Associations (SA) and Security Parameter Index (SPI) definitions 📚.
1.4.1. Security Associations and Registration
The SA attributes required and recommended for IP Security (AH, ESP) are defined in [SEC-ARCH] 🛠️. The attributes specified for an IP Security SA include, but are not limited to, authentication mechanism, cryptographic algorithm, algorithm mode, key length, and Initialization Vector (IV). Other protocols that provide algorithm and mechanism independent security MUST define their requirements for SA attributes 🚩. Keeping ISAKMP separate from any specific SA definition is important so ISAKMP can establish SAs for all possible security protocols and applications 🌟.
NOTE: See [IPDOI] for a discussion of SA attributes that should be considered when defining a security protocol or application.
In order to make specific attributes (e.g. a specific encryption algorithm) easy to identify across different network entities, the attributes must be assigned identifiers, and those identifiers must be registered by a central authority 📋. The Internet Assigned Numbers Authority (IANA) provides this function for the Internet 🏛️.
1.4.2. ISAKMP Requirements
Security Association (SA) establishment MUST be part of the key management protocol defined for IP based networks 🏗️. The SA concept is required to support security protocols in a diverse and dynamic networking environment. Just as authentication and key exchange must be linked to provide assurance that the key is established with the authenticated party [DOW92], SA establishment must be linked with the authentication and the key exchange protocol 🔗.
ISAKMP provides the protocol exchanges to establish a security association between negotiating entities, followed by those entities establishing a security association on behalf of some protocol (e.g. ESP/AH) 🎁. First, an initial protocol exchange allows a basic set of security attributes to be agreed upon. This basic set protects subsequent ISAKMP exchanges, and it indicates the authentication method and key exchange that will be performed as part of the ISAKMP protocol 🧁. If a basic set of security attributes is already in place between the negotiating server entities, the initial ISAKMP exchange may be skipped and the establishment of a security association can be done directly ⏭️.
After the basic set of security attributes has been agreed upon, the initial identity authenticated, and required keys generated, the established SA can be used for subsequent communications by the entity that invoked ISAKMP ✅. The basic set of SA attributes that MUST be implemented to provide ISAKMP interoperability are defined in Appendix A 💖.
1.5 Authentication 🔐
Okay bestie, this part is SO important. Before you trust a network connection, you need to know who is actually on the other end 👀 There are lots of ways to authenticate, and they come in two strengths: weak and strong. Sending cleartext keys or other unprotected auth info over a network is weak, because anyone with a network sniffer can just read them 💀 Sending one-way hashed keys that are badly chosen (low entropy) is weak too, since attackers can brute-force guess them from the sniffed messages 🙈
Passwords can technically establish identity, but this doc doesn't count them here because of recent statements from the Internet Architecture Board [IAB] 🤷♀️
Digital signatures are the strong, main-character mechanisms 🔥 The Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) signature are both public key based. Each entity needs a public key and a private key 🗝️ Certificates are an essential part of digital signature authentication 📜 They bind an entity's identity (be it a host, network, user, or application) to its public keys, and maybe other security stuff too, like privileges, clearances, and compartments 🎀 Signature-based auth needs a trusted third party or certificate authority to create, sign, and properly distribute the certificates 👑 For the deep dive on DSS, RSA, and certificates, check out [Schneier] 📚
1.5.1 Certificate Authorities 🏛️
Certificates need a whole infrastructure for generation, verification, revocation, management, and distribution 🧱 The Internet Policy Registration Authority (IPRA) [RFC-1422] was set up to run this infrastructure for the IETF 👑 The IPRA certifies Policy Certification Authorities (PCA), and PCAs control Certificate Authorities (CA) that certify users and subordinate entities 🌸
There's a lot of certificate work happening! The Domain Name System (DNS) Security Extensions [DNSSEC] will provide signed entity keys in the DNS 🔐 The Public Key Infrastructure (PKIX) working group is specifying an Internet profile for X.509 certificates 📋 Industry is also working on X.500 Directory Services that would give users X.509 certificates 🏢 The U.S. Post Office is developing a (CA) hierarchy 📮 The NIST Public Key Infrastructure Working Group has been busy in this area too 🧑🔬 And the DOD Multi Level Information System Security Initiative (MISSI) program has started deploying a certificate infrastructure for the U.S. Government 🇺🇸
If there's no infrastructure at all, PGP Web of Trust certificates can provide user authentication and privacy in a community of users who know and trust each other 🫶
1.5.2 Entity Naming 🪪
An entity's name is its identity, and it's bound to its public keys in certificates 💖 The CA MUST define the naming semantics for the certificates it issues. Check out the UNINETT PCA Policy Statements [Berge] to see how a CA defines its naming policy 📖 When a certificate is verified, the name gets verified too, and that name only means something within the realm of that CA 🌍
DNS security extensions are an example: they make DNS servers CAs for the zones and nodes they serve 🧚 Resource records hold public keys and signatures on those keys, and the names attached to the keys are IP addresses and domain names that mean something to the entities querying the DNS 💅 A Web of Trust is another example. When webs of trust are set up, names are bound to public keys. In PGP the name is usually an e-mail address, which has meaning to those, and only those, who understand e-mail 📧 Another web of trust could use a totally different naming scheme 🦋
1.5.3 ISAKMP Requirements 📋
Strong authentication MUST be provided on ISAKMP exchanges. This one's non-negotiable 🚫 Without being able to authenticate the entity on the other end, the Security Association (SA) and session key that get established are suspect 🙈 And without authentication you can't trust anyone's identification, which makes access control questionable 😬 Encryption (e.g. ESP) and integrity (e.g. AH) will protect later communications from passive eavesdroppers, sure, but without authentication the SA and key might have been set up with an adversary doing an active man-in-the-middle attack, and now they're stealing all your personal data 💀
A digital signature algorithm MUST be used within ISAKMP's authentication component. This is the big one. ✨
ISAKMP doesn't mandate a specific signature algorithm or certificate authority (CA) though 🤷♀️ It lets an entity starting communications say which CAs it supports 📣 Once a CA is selected, the protocol provides the messages needed for the actual authentication exchange 💬 It also has a way to identify different certificate authorities and certificate types (e.g. X.509, PKCS #7, PGP, DNS SIG and KEY records), plus a way to exchange the certificates that were identified 🎀
ISAKMP uses digital signatures, based on public key cryptography, for authentication 🔑 Other strong authentication systems exist too, and they could be specified as additional optional authentication mechanisms for ISAKMP 🌈 Some of them rely on a trusted third party called a key distribution center (KDC) to hand out secret session keys 🎟️ Kerberos is an example: its trusted third party is the Kerberos server, which holds secret keys for all clients and servers in its network domain 🏰 A client proving it holds its secret key is what provides authentication to a server 🫡
The ISAKMP spec doesn't define the protocol for talking to trusted third parties (TTP) or certificate directory services 🙅♀️ Those protocols are defined by the TTP and directory service themselves, and they're outside the scope of this spec 📦 How these extra services and protocols get used will be described in a Key Exchange specific document 📝
1.6 Public Key Cryptography 🗝️💜
Public key cryptography is the most flexible, scalable, and efficient way for users to get the shared secrets and session keys needed to support all the ways Internet users will interoperate 🌐 There are lots of key generation algorithms with different properties (see [DOW92], [ANSI], and [Oakley]) 📚 The properties of key exchange protocols include key establishment method, authentication, symmetry, perfect forward secrecy, and back traffic protection 🧠
NOTE: Cryptographic keys can protect information for a considerable length of time 😮 But that only holds if the keys used to protect communications are destroyed after use and not kept for any reason 🔥
1.6.1 Key Exchange Properties 🧩
Key Establishment (Key Generation / Key Transport): The two common ways to use public key cryptography for key establishment are key transport and key generation 🌷 Key transport looks like this: use RSA to encrypt a randomly generated session key (for encrypting later communications) with the recipient's public key 🔐 The encrypted random key gets sent over, and the recipient decrypts it with their private key 🗝️ Now both sides have the same session key, even though it was made from input from only one side 🤔 The perk of key transport is that it has less computational overhead than the next method 💨
Key generation is shown by the Diffie-Hellman (D-H) algorithm 🌀 It starts with two users exchanging public info. Then each user mathematically combines the other's public info with their own secret info to compute a shared secret value 🧮 That secret value can be used as a session key, or as a key encryption key for encrypting a randomly generated session key 🔑 This way the session key is based on public and secret info held by both users 👯 The D-H perk is that the key used for encrypting messages is based on info both users hold, and keys that are independent from one key exchange to the next give you perfect forward secrecy 🌟 Detailed descriptions of these algorithms are in [Schneier] 📖 There are a bunch of variations on these two key generation schemes, and they don't necessarily interoperate 🙃
Key Exchange Authentication: Key exchanges can be authenticated during the protocol or after it's done 🛡️ Authentication during the protocol happens when each party proves it has the secret session key before the protocol ends 🤝 That proof can be given by encrypting known data with the secret session key during the exchange 🔏 Authentication after the protocol has to happen in later communications 📬 Authentication during the protocol is preferred, so later communications don't get started if the secret session key isn't established with the party you wanted 🙅♀️
Key Exchange Symmetry: A key exchange has symmetry if either party can start the exchange, and the exchanged messages can cross in transit without changing the key that gets generated 🔄 This is desirable, because computing the keys then doesn't require either party to know who started the exchange 🥰 Key exchange symmetry is nice, but symmetry across the whole key management protocol might open up a vulnerability to reflection attacks 😱
Perfect Forward Secrecy: As described in [DOW92], an authenticated key exchange protocol has perfect forward secrecy if disclosing long-term secret keying material doesn't compromise the secrecy of keys exchanged in previous communications 🕰️✨ Perfect forward secrecy doesn't apply to key exchange without authentication 🚫
1.6.2 ISAKMP Requirements 📋🌸
An authenticated key exchange MUST be supported by ISAKMP. Users SHOULD choose additional key establishment algorithms based on their requirements 🎯 ISAKMP doesn't specify one particular key exchange, but [IKE] describes a proposal for using the Oakley key exchange [Oakley] together with ISAKMP 💫 When picking a key establishment algorithm, evaluate things like establishment method (generation vs. transport), perfect forward secrecy, computational overhead, key escrow, and key strength 🧐 Based on user requirements, ISAKMP lets an entity starting communications say which key exchanges it supports 📣 Once a key exchange is selected, the protocol provides the messages needed for the actual key establishment 🔑✅
1.7 ISAKMP Protection 🛡️
1.7.1 Anti-Clogging (Denial of Service) 🛡️
okay so denial of service is honestly one of the hardest security problems to crack 😭. A "cookie" (aka an anti-clogging token, or ACT) is there to protect computing resources from attacks without burning a ton of CPU just to check whether it's legit 💅. Doing a little exchange before the CPU-heavy public key operations can stop some DoS attempts, like plain flooding with bogus IP source addresses 🙈. But ngl, absolute protection against DoS is impossible. This token is just a technique that makes it way easier to handle. The anti-clogging token was introduced by Karn and Simpson in [Karn] ✨.
It's important to know that in the exchanges shown in section 4, the anti-clogging mechanism should be used together with a garbage-state collection mechanism 🧹. Otherwise an attacker can still flood a server with packets using bogus IP addresses and make it create state. Such aggressive memory management techniques SHOULD be employed by protocols using ISAKMP that don't go through an initial, anti-clogging-only phase, the way [Karn] did 💜.
1.7.2 Connection Hijacking 👑
ISAKMP stops connection hijacking by linking the authentication, key exchange, and security association exchanges together 🔗. Because they're linked, an attacker can't let the authentication finish and then jump in to impersonate one entity to the other during the key and security association exchanges. Nope, not today 💅.
1.7.3 Man-in-the-Middle Attacks 🕵️♀️
Man-in-the-Middle attacks cover a lot of ground: interception, insertion, deletion, and modification of messages, reflecting messages back at the sender, replaying old messages, and redirecting messages 😱. ISAKMP features are designed to stop these from working. Linking the ISAKMP exchanges prevents messages from being inserted into the protocol exchange. The ISAKMP protocol state machine is defined so that deleted messages won't cause a partial SA to be created. Instead, the state machine clears all state and goes back to idle 🧼. The state machine also stops a reflected message from causing harm 🪞.
Requiring a new cookie with time variant material for every new SA establishment stops attacks that involve replaying old messages ⏰. The ISAKMP strong authentication requirement means an SA can't be established with anyone other than the intended party 🎯. Messages might get redirected somewhere else or modified, but that will be detected and no SA will be established. The ISAKMP specification also defines where abnormal processing has occurred, and it recommends notifying the appropriate party about the abnormality 🚨.
1.8 Multicast Communications 🌸
Multicast communications are expected to need the same security services as unicast communications, and they might introduce the need for extra security services too 📡. The issues around distributing SPIs for multicast traffic are covered in [SEC-ARCH]. Multicast security issues are also discussed in [RFC-1949] and [BC]. A future extension to ISAKMP will support multicast key distribution 🔮. If you want an intro to multicast security, check out the Internet Drafts [RFC-2094] and [RFC-2093], which describe Sparta's research in this area 📚.
2 Terminology and Concepts 🎀
2.1 ISAKMP Terminology 📖
Security Protocol: A Security Protocol is an entity at a single point in the network stack that performs a security service for network communication. For example, IPSEC ESP and IPSEC AH are two different security protocols. TLS is another example. Security Protocols may perform more than one service, for example providing integrity and confidentiality in one module 🧩.
Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a protection suite may consist of DES encryption in IP ESP and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This matters because security services in different security protocols can have subtle interactions, so the effects of a suite must be analyzed and verified as a whole 🧐.
Security Association (SA): A Security Association is a security-protocol-specific set of parameters that completely defines the services and mechanisms needed to protect traffic at that security protocol location. These parameters can include algorithm identifiers, modes, cryptographic keys, and so on 🔐. The SA is referred to by its associated security protocol (for example, "ISAKMP SA", "ESP SA", "TLS SA") 🏷️.
ISAKMP SA: An SA used by the ISAKMP servers to protect their own traffic. Sections 2.3 and 2.4 give more details about ISAKMP SAs 🫶.
Security Parameter Index (SPI): An identifier for a Security Association, relative to some security protocol. Each security protocol has its own "SPI-space". A (security protocol, SPI) pair may uniquely identify an SA. How unique the SPI is depends on the implementation, and it could be based per system, per protocol, or on other options. Depending on the DOI, extra information (e.g. host address) may be needed to identify an SA. The DOI also determines which SPIs (i.e. initiator's or responder's) are sent during communication 🔢.
Domain of Interpretation: A Domain of Interpretation (DOI) defines payload formats, exchange types, and conventions for naming security-relevant information, such as security policies or cryptographic algorithms and modes 🌍. A DOI identifier is used to interpret the payloads of ISAKMP payloads. A system SHOULD support multiple Domains of Interpretation simultaneously 🙌. The concept of a DOI is based on earlier work by the TSIG CIPSO Working Group, but it goes beyond security label interpretation to include naming and interpretation of security services. A DOI defines:
- A "situation": the set of information that will be used to determine the required security services.
- The set of security policies that must, and may, be supported.
- A syntax for the specification of proposed security services.
- A scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, security policy attributes, and certificate authorities.
- The specific formats of the various payload contents.
- Additional exchange types, if required.
The rules for the IETF IP Security DOI are presented in [IPDOI]. Specifications of the rules for customized DOIs will be presented in separate documents 📄.
Situation: A situation contains all of the security-relevant information that a system considers necessary to decide which security services are required to protect the session being negotiated. The situation may include addresses, security classifications, modes of operation (normal vs. emergency), and so on 🚦.
Proposal: A proposal is a list, in decreasing order of preference, of the protection suites that a system considers acceptable for protecting traffic under a given situation 📋.
Payload: ISAKMP defines several types of payloads, which are used to transfer information such as security association data or key exchange data, in DOI-defined formats 📦. A payload consists of a generic payload header and a string of octets that is opaque to ISAKMP. ISAKMP uses DOI-specific functionality to synthesize and interpret these payloads. Multiple payloads can be sent in a single ISAKMP message. See section 3 for more details on the payload types, and [IPDOI] for the formats of the IETF IP Security DOI payloads 🎁.
Exchange Type: An exchange type specifies the number of messages in an ISAKMP exchange and the payload types contained in each of those messages 💬. Each exchange type is designed to provide a particular set of security services, such as anonymity of the participants, perfect forward secrecy of the keying material, authentication of the participants, and so on. Section 4.1 defines the default set of ISAKMP exchange types. Other exchange types can be added to support additional key exchanges, if required ✨.
2.2 ISAKMP Placement 🗺️
Figure 1 is a high-level view of where ISAKMP sits within a system context in a network architecture 🏗️. An important part of negotiating security services is considering the entire "stack" of individual SAs as a unit. This is referred to as a "protection suite" 💖.
+------------+ +--------+ +--------------+
! DOI ! ! ! ! Application !
! Definition ! <----> ! ISAKMP ! ! Process !
+------------+ --> ! ! !--------------!
+--------------+ ! +--------+ ! Appl Protocol!
! Key Exchange ! ! ^ ^ +--------------+
! Definition !<-- ! ! ^
+--------------+ ! ! !
! ! !
!----------------! ! !
v ! !
+-------+ v v
! API ! +---------------------------------------------+
+-------+ ! Socket Layer !
! !---------------------------------------------!
v ! Transport Protocol (TCP / UDP) !
+----------+ !---------------------------------------------!
! Security ! <----> ! IP !
! Protocol ! !---------------------------------------------!
+----------+ ! Link Layer Protocol !
+---------------------------------------------+
Figure 1: ISAKMP Relationships2.3 Negotiation Phases ✨
okay bestie, ISAKMP has two "phases" of negotiation 💅 In phase one, two entities (e.g. ISAKMP servers) agree on how to protect the further negotiation traffic between themselves, and that's how they set up an ISAKMP SA 🔐. That ISAKMP SA then protects the negotiations for the Protocol SA being requested. Two entities (e.g. ISAKMP servers) can negotiate and have multiple ISAKMP SAs active at once 🙌
Phase two is for setting up security associations for other security protocols. It can set up a whole bunch of them, and each one can protect many message/data exchanges 🧚
Yes, the two-phase approach has a higher start-up cost for simple scenarios, but it's worth it in most cases, and here's why 🎀
First, entities (e.g. ISAKMP servers) can spread the cost of phase one across several phase two negotiations 💜 This means multiple SAs can be set up between peers over time without having to start over for every communication.
Second, the security services negotiated in phase one give security properties to phase two ✨ For example, after phase one, the encryption from the ISAKMP SA can provide identity protection, which could mean simpler phase two exchanges. But if the channel from phase one isn't adequate to protect identities, then the second phase must negotiate adequate security mechanisms 😭
Third, having an ISAKMP SA in place makes ISAKMP management way cheaper 💸 Without the "trusted path" an ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would have to go through a complete re-authentication for every error notification or deletion of an SA. no thank you 🙅♀️
Negotiation during each phase happens using ISAKMP-defined exchanges (see section 4) or exchanges defined for a key exchange within a DOI.
Also, security services can be applied differently in each phase 🦋 Different parties get authenticated in each one. In phase one, the parties being authenticated may be the ISAKMP servers/hosts, while in phase two, users or application-level programs are the ones being authenticated 👑
2.4 Identifying Security Associations 🦋
While bootstrapping secure channels between systems, ISAKMP can't assume security services already exist, so it has to protect itself 🛡️ That's why ISAKMP treats an ISAKMP Security Association as different from other types. It manages ISAKMP SAs itself, in their own name space. ISAKMP uses the two cookie fields in the ISAKMP header to identify ISAKMP SAs. The Message ID in the ISAKMP Header and the SPI field in the Proposal payload are used during SA establishment to identify the SA for other security protocols. What these four fields mean depends on the operation happening 🌈
The table below shows which fields are present or absent during SA establishment. The fields that matter here are the cookies in the ISAKMP header, the ISAKMP Header Message ID field, and the SPI field in the Proposal payload. An 'X' in the column means the value MUST be present. An 'NA' means the value is Not Applicable to that operation 📋
# Operation I-Cookie R-Cookie Message ID SPI
(1) Start ISAKMP SA negotiation X 0 0 0
(2) Respond ISAKMP SA negotiation X X 0 0
(3) Init other SA negotiation X X X X
(4) Respond other SA negotiation X X X X
(5) Other (KE, ID, etc.) X X X/0 NA
(6) Security Protocol (ESP, AH) NA NA NA XOkay, line (1) of the table: the initiator includes the Initiator Cookie field in the ISAKMP Header, following the procedures in sections 2.5.3 and 3.1 🌸
Line (2): the responder includes the Initiator and Responder Cookie fields in the ISAKMP Header, using the procedures in sections 2.5.3 and 3.1. Extra messages may get swapped between ISAKMP peers, depending on which ISAKMP exchange type gets used in the phase 1 negotiation. Once the phase 1 exchange is done, both cookies go in the ISAKMP Header of every later message between the peers 💕
During phase 1, the initiator and responder cookies determine the ISAKMP SA. So the SPI field in the Proposal payload is redundant. It MAY be set to 0, or it MAY contain the transmitting entity's cookie 🎀
Line (3): the initiator associates a Message ID with the Protocols in the SA Proposal. That Message ID, plus the initiator's SPI(s) for each protocol in the Proposal, gets sent to the responder. The SPI(s) will be used by the security protocols once phase 2 is complete 🚀
Line (4): the responder sends back the same Message ID, along with the responder's SPI(s) for each protocol in the accepted Proposal. That info goes back to the initiator 🔁
Line (5): the initiator and responder use the Message ID field in the ISAKMP Header to keep track of the in-progress protocol negotiation. This only applies to a phase 2 exchange, and the value MUST be 0 for a phase 1 exchange, because the combined cookies identify the ISAKMP SA. The SPI field in the Proposal payload doesn't apply here either, because the Proposal payload is only used during the SA negotiation message exchange (steps 3 and 4) 🙃
Line (6): phase 2 negotiation is complete 🎉 The security protocols use the SPI(s) to figure out which security services and mechanisms to apply to the communication between them. The SPI value in line (6) isn't the SPI field in the Proposal payload. It's the SPI field inside the security protocol header.
During SA establishment, a SPI MUST be generated. ISAKMP is designed to handle variable sized SPIs, and that's done with the SPI Size field in the Proposal payload during SA establishment. The DOI specification (e.g. [IPDOI]) will outline how SPIs are handled 📖
When an SA is first established, one side takes the role of initiator and the other takes the role of responder. Once the SA is up, both the original initiator and responder can start a phase 2 negotiation with the peer. So ISAKMP SAs are bidirectional in nature 🔄
ISAKMP also lets both the initiator and responder have some control over the negotiation 👑 ISAKMP is designed to allow an SA negotiation with multiple proposals, but the initiator can keep control by only making one proposal, matching its local security policy. If the initiator sends a proposal containing more than one proposal (sent in decreasing preference order), it gives up control to the responder. Once the responder is in control, the responder can make its own policy take precedence over the initiator, within the multiple options offered. It does this by picking the proposal that fits its local security policy best and sending that selection back to the initiator 💅
2.5 Miscellaneous 🌈
2.5.1 Transport Protocol
ISAKMP can run over any transport protocol, or over IP itself 🚄 Implementations MUST include send and receive capability for ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP port 500 was assigned to ISAKMP by the Internet Assigned Numbers Authority (IANA). Implementations MAY additionally support ISAKMP over other transport protocols or over IP itself 🌸
2.5.2 RESERVED Fields
RESERVED fields inside ISAKMP payloads exist strictly to preserve byte alignment 📏 All RESERVED fields in the ISAKMP protocol MUST be set to zero (0) when a packet is issued. The receiver SHOULD check the RESERVED fields for a zero (0) value, and discard the packet if other values are found 🗑️
2.5.3 Anti-Clogging Token ("Cookie") Creation
The details of cookie generation are up to the implementation, but cookies MUST satisfy these basic requirements (originally stated by Phil Karn in [Karn]) 🍪
- The cookie must depend on the specific parties. This stops an attacker from grabbing a cookie using a real IP address and UDP port, then using it to swamp the victim with Diffie-Hellman requests from randomly chosen IP addresses or ports 🙅♀️
- It must not be possible for anyone other than the issuing entity to generate cookies that entity will accept. This means the issuing entity has to use local secret information when generating and later verifying a cookie. It must not be possible to deduce this secret information from any particular cookie 🔐
- The cookie generation function must be fast, to thwart attacks meant to sabotage CPU resources 🏃♀️
Karn's suggested method for creating the cookie is to run a fast hash (e.g. MD5) over the IP Source and Destination Address, the UDP Source and Destination Ports, and a locally generated secret random value 🧁 ISAKMP requires that the cookie be unique for each SA establishment to help prevent replay attacks, so the date and time MUST be added to the information hashed ⏰ The generated cookies go in the ISAKMP Header (described in section 3.1) Initiator and Responder cookie fields. These fields are 8 octets long, so a generated cookie has to be 8 octets too 💜
Notify and Delete messages (see sections 3.14, 3.15, and 4.8) are one-way transmissions done under the protection of an existing ISAKMP SA, so they don't need a new cookie generated. There's one exception: sending a Notify message during a Phase 1 exchange, before the SA is fully established 🙈 Sections 3.14 and 4.8 have the extra details.
3 ISAKMP Payloads 🎀
ISAKMP payloads are modular building blocks for constructing ISAKMP messages 🧩 The presence and ordering of payloads are defined by, and depend on, the Exchange Type Field in the ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 through 3.15. The descriptions of the ISAKMP payloads, messages, and exchanges (see Section 4) are shown using network octet ordering 💖
3.1. ISAKMP Header Format
Okay so every ISAKMP message starts with a fixed header 💅 (shown in Figure 2), and then comes a variable number of payloads ✨. Why fixed? Because it makes parsing SO much easier, which means the protocol parsing software is less complex and easier to implement 🎀. The fixed header holds everything the protocol needs to maintain state, process payloads, and possibly prevent denial of service or replay attacks 🛡️.
Here are the header fields, bestie 🫶:
Initiator Cookie(8 octets): the Cookie of the entity that initiated SA establishment, SA notification, or SA deletion.Responder Cookie(8 octets): the Cookie of the entity that is responding to an SA establishment request, SA notification, or SA deletion.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Responder !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: ISAKMP Header Format
Next Payload(1 octet): indicates the type of the first payload in the message. The format for each payload is defined in sections 3.4 through 3.16, and the processing for the payloads is defined in section 5. 🧚
Next Payload Type Value
NONE 0
Security Association (SA) 1
Proposal (P) 2
Transform (T) 3
Key Exchange (KE) 4
Identification (ID) 5
Certificate (CERT) 6
Certificate Request (CR) 7
Hash (HASH) 8
Signature (SIG) 9
Nonce (NONCE) 10
Notification (N) 11
Delete (D) 12
Vendor ID (VID) 13
RESERVED 14 - 127
Private USE 128 - 255Major Version(4 bits): tells you the major version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Major Version to 1. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Major Version to 0. Implementations SHOULD never accept packets with a major version number larger than their own. 👑Minor Version(4 bits): tells you the minor version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Minor Version to 0. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Minor Version to 1. Implementations SHOULD never accept packets with a minor version number larger than their own, given the major version numbers are identical. 🌸Exchange Type(1 octet): indicates the type of exchange being used. This dictates the message and payload orderings in the ISAKMP exchanges. 🦋
Exchange Type Value
NONE 0
Base 1
Identity Protection 2
Authentication Only 3
Aggressive 4
Informational 5
ISAKMP Future Use 6 - 31
DOI Specific Use 32 - 239
Private Use 240 - 255Flags(1 octet): the specific options set for the ISAKMP exchange. The flags are specified in the Flags field beginning with the least significant bit. So the Encryption bit is bit 0 of the Flags field, the Commit bit is bit 1, and the Authentication Only bit is bit 2. The remaining bits of the Flags field MUST be set to 0 prior to transmission. 🔥- E(ncryption Bit) (1 bit): If set (1), all payloads following the header are encrypted using the encryption algorithm identified in the ISAKMP SA. The ISAKMP SA Identifier is the combination of the initiator and responder cookie. It is RECOMMENDED that encryption of communications be done as soon as possible between the peers. For all ISAKMP exchanges described in section 4.1, the encryption SHOULD begin after both parties have exchanged Key Exchange payloads. If the E(ncryption Bit) is not set (0), the payloads are not encrypted. 🔐
- C(ommit Bit) (1 bit): This bit is used to signal key exchange synchronization. It is used to ensure that encrypted material is not received prior to completion of the SA establishment. The Commit Bit can be set (at anytime) by either party participating in the SA establishment, and can be used during both phases of an ISAKMP SA establishment. However, the value MUST be reset after the Phase 1 negotiation. If set (1), the entity which did not set the Commit Bit MUST wait for an Informational Exchange containing a Notify payload (with the CONNECTED Notify Message) from the entity which set the Commit Bit. In this instance, the Message ID field of the Informational Exchange MUST contain the Message ID of the original ISAKMP Phase 2 SA negotiation. This is done to ensure that the Informational Exchange with the CONNECTED Notify Message can be associated with the correct Phase 2 SA. The receipt and processing of the Informational Exchange indicates that the SA establishment was successful, and either entity can now proceed with encrypted traffic communication. In addition to synchronizing key exchange, the Commit Bit can be used to protect against loss of transmissions over unreliable networks and guard against the need for multiple re-transmissions. ✅
NOTE: It is always possible that the final message of an exchange can be lost. In this case, the entity expecting to receive the final message of an exchange would receive the Phase 2 SA negotiation message following a Phase 1 exchange, or encrypted traffic following a Phase 2 exchange. Handling of this situation is not standardized, but we propose the following possibilities. If the entity awaiting the Informational Exchange can verify the received message (i.e. Phase 2 SA negotiation message or encrypted traffic), then they MAY consider the SA was established and continue processing. The other option is to retransmit the last ISAKMP message to force the other entity to retransmit the final message. This suggests that implementations may consider retaining the last message (locally) until they are sure the SA is established.
- A(uthentication Only Bit) (1 bit): This bit is intended for use with the Informational Exchange with a Notify payload, and will allow the transmission of information with integrity checking but no encryption (e.g. "emergency mode"). Section 4.8 states that a Phase 2 Informational Exchange MUST be sent under the protection of an ISAKMP SA. This is the only exception to that policy. If the Authentication Only bit is set (1), only authentication security services will be applied to the entire Notify payload of the Informational Exchange, and the payload will not be encrypted. 🙈
Message ID(4 octets): a unique Message Identifier used to identify protocol state during Phase 2 negotiations. This value is randomly generated by the initiator of the Phase 2 negotiation. In the event of simultaneous SA establishments (i.e. collisions), the value of this field will likely be different, because they are independently generated and, thus, two security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. During Phase 1 negotiations, the value MUST be set to 0. 🍓Length(4 octets): the length of the total message (header + payloads) in octets. Encryption can expand the size of an ISAKMP message. 📏
3.2. Generic Payload Header
Each ISAKMP payload defined in sections 3.4 through 3.16 begins with a generic header, shown in Figure 3 🧩. It provides a payload "chaining" capability and clearly defines the boundaries of a payload, which is honestly iconic. 💖
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Generic Payload Header
The Generic Payload Header fields are defined as follows:
Next Payload(1 octet): identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. 🔗RESERVED(1 octet): unused, set to 0. 🌙Payload Length(2 octets): the length in octets of the current payload, including the generic payload header. ✨
3.3 Data Attributes 💖
okay so there are a bunch of spots in ISAKMP where you need to represent Data Attributes 🎀 an example is the Security Association (SA) Attributes living inside the Transform payload (we cover that in section 3.6). these aren't a payload of their own, they just sit inside ISAKMP payloads. the format is super flexible so it can represent all kinds of info, and one payload can hold multiple Data Attributes ✨ the length is either 4 octets or whatever the Attribute Length field says, and the Attribute Format bit (more on that below) decides which one. the specifics for each domain get spelled out in a DOI document, like the IPSEC DOI [IPDOI] 🧚
Figure 4: Data Attributes
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A! Attribute Type ! AF=0 Attribute Length !
!F! ! AF=1 Attribute Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AF=0 Attribute Value .
. AF=1 Not Transmitted .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Data Attributes fields, breakdown time 🔥
- Attribute Type (2 octets) - a unique ID for each type of attribute 👑 these get defined as part of the DOI-specific info. the most significant bit is the Attribute Format (AF), and it tells you whether the attribute is in the Type/Length/Value (TLV) format or the shortened Type/Value (TV) format. AF = 0 means TLV, AF = 1 means TV. ✨
- Attribute Length (2 octets) - the length in octets of the Attribute Value. when AF is 1, the Attribute Value is only 2 octets and this Attribute Length field isn't even there 🙈
- Attribute Value (variable length) - the value for the DOI-specific Attribute Type 💅 if AF is 0, its length is whatever the Attribute Length field says. if AF is 1, it's exactly 2 octets.
3.4 Security Association Payload 🦋
the Security Association Payload is how you negotiate security attributes, and it's also how you say which Domain of Interpretation (DOI) and Situation the negotiation is happening in 🌸 here's what it looks like, Figure 5:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Situation ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Security Association Payload
and here's the field tea 🍓
- Next Payload (1 octet) - the payload type ID for the next payload in the message. if the current payload is the last one, this field is 0. this field MUST NOT contain the values for the Proposal or Transform payloads, because those count as part of the security association negotiation 🚫 for example, this field would hold the value "10" (Nonce payload) in the first message of a Base Exchange (see Section 4.4), and the value "0" in the first message of an Identity Protect Exchange (see Section 4.5). 💜
- RESERVED (1 octet) - unused, set to 0 🫶
- Payload Length (2 octets) - the length in octets of the entire Security Association payload, which includes the SA payload itself plus all Proposal payloads and all Transform payloads tied to the proposed Security Association 📏
- Domain of Interpretation (4 octets) - identifies the DOI (see Section 2.1) that this negotiation is happening under 🌈 the DOI is a 32-bit unsigned integer. a DOI value of 0 during a Phase 1 exchange gives you a Generic ISAKMP SA, which can be used for any protocol during the Phase 2 exchange. the necessary SA Attributes are defined in A.4. a DOI value of 1 is assigned to the IPsec DOI [IPDOI]. every other DOI value is reserved to IANA for future use, and IANA won't normally assign a DOI value without pointing to some public spec, like an Internet RFC. other DOIs can be defined using the description in appendix B. this field MUST be present within the Security Association payload. ✨
- Situation (variable length) - a DOI-specific field that identifies the situation this negotiation is happening in ⭐ the Situation is used to make policy decisions about the security attributes being negotiated. the details for the IETF IP Security DOI Situation are in [IPDOI]. this field MUST be present within the Security Association payload. 👑
3.5 Proposal Payload 🎀
the Proposal Payload holds info used during Security Association negotiation 💅 a proposal is made up of security mechanisms, aka transforms, that get used to secure the communications channel. Figure 6 shows the format, and you can find out how it gets used in section 4.2 🦋
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal # ! Protocol-Id ! SPI Size !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI (variable) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Proposal Payload Format
the Proposal Payload fields, lowkey the most detailed bit 🧚
- Next Payload (1 octet) - the payload type ID for the next payload in the message. this field MUST only contain the value "2" or "0" 🔥 if there are more Proposal payloads in the message, this field is 2. if the current Proposal payload is the last one in the security association proposal, this field is 0.
- RESERVED (1 octet) - unused, set to 0 🌸
- Payload Length (2 octets) - the length in octets of the entire Proposal payload, including the generic payload header, the Proposal payload itself, and all Transform payloads tied to this proposal ✨ if there are multiple proposals with the same proposal number (see section 4.2), the Payload Length field only applies to the current Proposal payload, not to all of the Proposal payloads. 🙈
- Proposal # (1 octet) - the Proposal number for the current payload. you can read about how this field gets used in section 4.2. 💖
- Protocol-Id (1 octet) - specifies the protocol identifier for the current negotiation. examples might be IPSEC ESP, IPSEC AH, OSPF, TLS, etc. 🌈
- SPI Size (1 octet) - the length in octets of the SPI, as defined by the Protocol-Id. for ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, so the SPI Size is irrelevant and MAY be anywhere from zero (0) to sixteen (16) 🫶 if the SPI Size is non-zero, the content of the SPI field MUST be ignored. if the SPI Size isn't a multiple of 4 octets, it'll affect the SPI field and the alignment of all payloads in the message. the Domain of Interpretation (DOI) dictates the SPI Size for other protocols. 🦋
- # of Transforms (1 octet) - the number of transforms for the Proposal. each one lives in its own Transform payload. 💜
- SPI (variable) - the sending entity's SPI. if the SPI Size isn't a multiple of 4 octets, no padding gets applied to the payload, but it can be applied at the end of the message. 🍓
the payload type for the Proposal Payload is two (2) 👑 ✨
3.6 Transform Payload ✨
Okay bestie, the Transform Payload is where the actual security mechanism gets picked 💅 It carries information used during Security Association negotiation. It holds a specific security mechanism, or transforms, to be used to secure the communications channel, plus the security association attributes that go with that transform. Those SA attributes are DOI-specific 🧚 Figure 7 shows the format, and section 4.2 explains how it gets used 🦋
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform # ! Transform-Id ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ SA Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Transform Payload Format
The Transform Payload fields are the following, and they're all very important 💖
Next Payload(1 octet) - Identifier for the payload type of the next payload in the message. This field MUST only contain the value "3" or "0". If there are additional Transform payloads in the proposal, then this field will be 3. If the current Transform payload is the last within the proposal, then this field will be 0. 🎀RESERVED(1 octet) - Unused, set to 0. 🌸Payload Length(2 octets) - Length in octets of the current payload, including the generic payload header, Transform values, and all SA Attributes. 📏Transform #(1 octet) - Identifies the Transform number for the current payload. If there is more than one transform proposed for a specific protocol within the Proposal payload, then each Transform payload has a unique Transform number. A description of the use of this field is found in section 4.2. 🔢Transform-Id(1 octet) - Specifies the Transform identifier for the protocol within the current proposal. These transforms are defined by the DOI and are dependent on the protocol being negotiated. 🆔RESERVED2(2 octets) - Unused, set to 0. 🌸SA Attributes(variable length) - This field contains the security association attributes as defined for the transform given in theTransform-Idfield. The SA Attributes SHOULD be represented using the Data Attributes format described in section 3.3. If the SA Attributes are not aligned on 4-byte boundaries, then subsequent payloads will not be aligned and any padding will be added at the end of the message to make the message 4-octet aligned. 🧩
The payload type for the Transform Payload is three (3). 💜
3.7 Key Exchange Payload 🔑
The Key Exchange Payload supports a whole variety of key exchange techniques, which is so iconic 🌈 Example key exchanges are Oakley [Oakley], Diffie-Hellman, the enhanced Diffie-Hellman key exchange described in X9.42 [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows the format of the Key Exchange payload.
The Key Exchange Payload fields are defined as follows:
Next Payload(1 octet) - Identifier for the payload type of the nextpayload in the message. If the current payload is the last in the message, then this field will be 0.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Exchange Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: Key Exchange Payload Format
RESERVED(1 octet) - Unused, set to 0. 🌸Payload Length(2 octets) - Length in octets of the current payload, including the generic payload header. 📏Key Exchange Data(variable length) - Data required to generate a session key. The interpretation of this data is specified by the DOI and the associated Key Exchange algorithm. This field may also contain pre-placed key indicators. 🗝️
The payload type for the Key Exchange Payload is four (4). 💜
3.8 Identification Payload 🪪
The Identification Payload contains DOI-specific data used to exchange identification information. This information is used for determining the identities of communicating peers and may be used for determining authenticity of information. Figure 9 shows the format of the Identification Payload. 🕵️♀️
The Identification Payload fields are defined as follows:
Next Payload(1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.RESERVED(1 octet) - Unused, set to 0. 🌸Payload Length(2 octets) - Length in octets of the current payload, including the generic payload header. 📏ID Type(1 octet) - Specifies the type of Identification being used.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! DOI Specific ID Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Identification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: Identification Payload Format
This field is DOI-dependent.
DOI Specific ID Data(3 octets) - Contains DOI specific Identification data. If unused, then this field MUST be set to 0. 🧊Identification Data(variable length) - Contains identity information. The values for this field are DOI-specific and the format is specified by theID Typefield. Specific details for the IETF IP Security DOI Identification Data are detailed in [IPDOI]. 🪞
The payload type for the Identification Payload is five (5). 💜
3.9 Certificate Payload 📜
The Certificate Payload is how you transport certificates or other certificate-related information via ISAKMP, and it can show up in any ISAKMP message 💫 Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate payload MUST be accepted at any point during an exchange. Figure 10 shows the format of the Certificate Payload.
NOTE: Certificate types and formats are not generally bound to a DOI - it is expected that there will only be a few certificate types, and that most DOIs will accept all of these types. 👀
The Certificate Payload fields are defined as follows:
Next Payload(1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding ! !
+-+-+-+-+-+-+-+-+ !
~ Certificate Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: Certificate Payload Format
RESERVED(1 octet) - Unused, set to 0. 🌸Payload Length(2 octets) - Length in octets of the current payload, including the generic payload header. 📏Certificate Encoding(1 octet) - This field indicates the type of certificate or certificate-related information contained in theCertificate Datafield. 🏷️
Certificate Type Value
NONE 0
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
X.509 Certificate - Signature 4
X.509 Certificate - Key Exchange 5
Kerberos Tokens 6
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8
SPKI Certificate 9
X.509 Certificate - Attribute 10
RESERVED 11 - 255Certificate Data(variable length) - Actual encoding of certificate data. The type of certificate is indicated by theCertificate Encodingfield. 📦
The payload type for the Certificate Payload is six (6). 💖
3.10 Certificate Request Payload 🎀
okay so the Certificate Request Payload is how you ask for certificates over ISAKMP, and it can show up in any message 📮 Bestie, you should include these SHOULD whenever there's no decent directory service around to hand out certificates (think Secure DNS [DNSSEC]) 🧚 The Certificate Request payload MUST be accepted at any point in the exchange, no exceptions 🙅♀️ And the responder MUST send its certificate, if it supports certificates, based on what the payload asks for 💖 If you need several certificates, you SHOULD send several Certificate Request payloads 🌸 Here's the layout, Figure 11 🦋
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert. Type ! !
+-+-+-+-+-+-+-+-+ !
~ Certificate Authority ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: Certificate Request Payload Format
the Certificate Payload fields are defined like this 💅
- Next Payload (1 octet) - the payload type ID of the next payload in the message 🧚 If this is the last payload in the message, this field will be 0.
- RESERVED (1 octet) - unused, set to 0 🫶
- Payload Length (2 octets) - the length in octets of this payload, generic payload header included 📏
- Certificate Type (1 octet) - encodes the type of certificate being requested 🎟️ The acceptable values are listed in section 3.9 ✨
- Certificate Authority (variable length) - encodes a certificate authority that's acceptable for the requested certificate type 🏛️ For example, with an X.509 certificate this field would hold the Distinguished Name encoding of the Issuer Name of an X.509 certificate authority the sender accepts 🪪 This helps the responder figure out how much of the certificate chain it needs to send back in response 🔗 If no specific certificate authority is requested, this field SHOULD not be included 🙈
The payload type for the Certificate Request Payload is seven (7) 🔢
3.11 Hash Payload 🍓
The Hash Payload carries data made by the hash function (picked during the SA establishment exchange) over some part of the message and/or ISAKMP state 💜 It can be used to check that the data in an ISAKMP message hasn't been messed with, or to authenticate the entities negotiating 🔐 Here's Figure 12 🌈
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Hash Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: Hash Payload Format
The Hash Payload fields are defined as follows:
- Next Payload (1 octet) - the payload type ID of the next payload in the message 🧚 If this is the last payload in the message, this field will be 0.
- RESERVED (1 octet) - unused, set to 0 🫶
- Payload Length (2 octets) - the length in octets of this payload, generic payload header included 📏
- Hash Data (variable length) - the data you get by running the hash routine over the ISAKMP message and/or state 🌸
3.12 Signature Payload 🦋
The Signature Payload carries data made by the digital signature function (chosen during the SA establishment exchange) over some part of the message and/or ISAKMP state ✍️ It's used to check the integrity of the data in the ISAKMP message, and it may be useful for non-repudiation services 👑 Figure 13 is right here 💅
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Signature Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: Signature Payload Format
The Signature Payload fields are defined as follows:
- Next Payload (1 octet) - the payload type ID of the next payload in the message 🧚 If this is the last payload in the message, this field will be 0.
- RESERVED (1 octet) - unused, set to 0 🫶
- Payload Length (2 octets) - the length in octets of this payload, generic payload header included 📏
- Signature Data (variable length) - the data you get by applying the digital signature function to the ISAKMP message and/or state 🔏
The payload type for the Signature Payload is nine (9) 🔢
3.13 Nonce Payload 🧚
The Nonce Payload holds random data used to guarantee liveness during an exchange and to protect against replay attacks 🎲 Figure 14 shows its format 💜 If a particular key exchange uses nonces, the key exchange decides how the Nonce payload gets used 🫶 Nonces can ride along as part of the key exchange data, or as a separate payload 🌈 But that's defined by the key exchange, not by ISAKMP, so don't look for it here 🙈
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Nonce Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: Nonce Payload Format
The Nonce Payload fields are defined as follows:
- Next Payload (1 octet) - the payload type ID of the next payload in the message 🧚 If this is the last payload in the message, this field will be 0.
- RESERVED (1 octet) - unused, set to 0 🫶
- Payload Length (2 octets) - the length in octets of this payload, generic payload header included 📏
- Nonce Data (variable length) - the random data generated by the transmitting entity 🎲
The payload type for the Nonce Payload is ten (10) 🔢✨
3.14 Notification Payload 🔔✨
Okay bestie, the Notification Payload is the drama queen of the message 💅. It can carry both ISAKMP and DOI-specific data, and it's how you send informational stuff like error conditions to an ISAKMP peer. You can send multiple Notification payloads in a single ISAKMP message, which is so iconic 🙌. Here's the layout, Figure 15:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: Notification Payload Format
Phase 1 notifications 🧠 are the ones that happen during, or are about, a Phase 1 negotiation. You can spot them by the Initiator and Responder cookie pair in the ISAKMP Header. The Protocol Identifier is ISAKMP and the SPI value is 0, because that cookie pair already identifies the ISAKMP SA. If the notification happens before the keying info has been fully exchanged, it's going out unprotected. Yikes 😬.
Phase 2 notifications 🌈 are the ones tied to a Phase 2 negotiation. These are identified by the Initiator and Responder cookie pair in the ISAKMP Header, plus the Message ID and SPI for the negotiation in progress. A classic example is saying why a proposal got rejected, which is literally the tea ☕.
Here's what each field does:
Next Payload(1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be 0.RESERVED(1 octet) - Unused, set to 0.Payload Length(2 octets) - Length in octets of the current payload, including the generic payload header.Domain of Interpretation(4 octets) - Identifies the DOI (as described in Section 2.1) under which this notification is taking place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is one (1). Other DOI's can be defined using the description in appendix B. 🙌Protocol-Id(1 octet) - Specifies the protocol identifier for the current notification. Examples might include ISAKMP, IPSEC ESP, IPSEC AH, OSPF, TLS, etc.SPI Size(1 octet) - Length in octets of the SPI as defined by the Protocol-Id. For ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, so the SPI Size is basically irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. The Domain of Interpretation (DOI) decides the SPI Size for other protocols.Notify Message Type(2 octets) - Specifies the type of notification message (see section 3.14.1). Extra text, if the DOI specifies it, goes in the Notification Data field.SPI(variable length) - Security Parameter Index. This is the receiving entity's SPI. How the SPI field gets used is described in section 2.4. Its length is set by the SPI Size field, and it isn't necessarily aligned to a 4 octet boundary.Notification Data(variable length) - Informational or error data sent along with the Notify Message Type. The values for this field are DOI-specific. 💖
The payload type for the Notification Payload is eleven (11). 🔢
3.14.1 Notify Message Types
Notification info can be error messages that explain why an SA couldn't be established 🙅♀️. It can also be status data that a process managing an SA database wants to share with a peer process. For example, a secure front end or security gateway might use the Notify message to sync up its SA communication 🔄. The tables below list the Notify messages and their values. Values in the Private Use range are expected to be DOI-specific values 🎀.
NOTIFY MESSAGES - ERROR TYPES
Errors Value
INVALID-PAYLOAD-TYPE 1
DOI-NOT-SUPPORTED 2
SITUATION-NOT-SUPPORTED 3
INVALID-COOKIE 4
INVALID-MAJOR-VERSION 5
INVALID-MINOR-VERSION 6
INVALID-EXCHANGE-TYPE 7
INVALID-FLAGS 8
INVALID-MESSAGE-ID 9
INVALID-PROTOCOL-ID 10
INVALID-SPI 11
INVALID-TRANSFORM-ID 12
ATTRIBUTES-NOT-SUPPORTED 13
NO-PROPOSAL-CHOSEN 14
BAD-PROPOSAL-SYNTAX 15
PAYLOAD-MALFORMED 16
INVALID-KEY-INFORMATION 17
INVALID-ID-INFORMATION 18
INVALID-CERT-ENCODING 19
INVALID-CERTIFICATE 20
CERT-TYPE-UNSUPPORTED 21
INVALID-CERT-AUTHORITY 22
INVALID-HASH-INFORMATION 23
AUTHENTICATION-FAILED 24
INVALID-SIGNATURE 25
ADDRESS-NOTIFICATION 26
NOTIFY-SA-LIFETIME 27
CERTIFICATE-UNAVAILABLE 28
UNSUPPORTED-EXCHANGE-TYPE 29
UNEQUAL-PAYLOAD-LENGTHS 30
RESERVED (Future Use) 31 - 8191
Private Use 8192 - 16383
NOTIFY MESSAGES - STATUS TYPES
Status Value
CONNECTED 16384
RESERVED (Future Use) 16385 - 24575
DOI-specific codes 24576 - 32767
Private Use 32768 - 40959
RESERVED (Future Use) 40960 - 655353.15 Delete Payload 🗑️💜
The Delete Payload carries a protocol-specific security association identifier that the sender has already removed from its security association database, so it's no longer valid 👋. Here's the layout, Figure 16. You can send multiple SPIs in one Delete payload, but each SPI MUST be for the same protocol. Mixing Protocol Identifiers MUST NOT be done with the Delete payload. No mixing, babe 🙅♀️.
A deletion about an ISAKMP SA will have a Protocol-Id of ISAKMP, and the SPIs are the initiator and responder cookies from the ISAKMP Header. A deletion about a Protocol SA, like ESP or AH, will have the Protocol-Id of that protocol (e.g. ESP, AH), and the SPI is the sending entity's SPI(s) ✨.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-Id ! SPI Size ! # of SPIs !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index(es) (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 16: Delete Payload Format
The Delete Payload fields work like this:
Next Payload(1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be 0.RESERVED(1 octet) - Unused, set to 0.Payload Length(2 octets) - Length in octets of the current payload, including the generic payload header.Domain of Interpretation(4 octets) - Identifies the DOI (as described in Section 2.1) under which this deletion is taking place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is one (1). Other DOI's can be defined using the description in appendix B. 💅Protocol-Id(1 octet) - ISAKMP can establish security associations for various protocols, including ISAKMP and IPSEC. This field says which security association database the delete request should apply to.SPI Size(1 octet) - Length in octets of the SPI as defined by the Protocol-Id. For ISAKMP, the Initiator and Responder cookie pair is the ISAKMP SPI. In that case, the SPI Size would be 16 octets for each SPI being deleted.# of SPIs(2 octets) - The number of SPIs in the Delete payload. The size of each SPI is set by the SPI Size field.Security Parameter Index(es)(variable length) - Identifies the specific security association(s) to delete. The values for this field are DOI and protocol specific. Its length is determined by the SPI Size and # of SPIs fields.
The payload type for the Delete Payload is twelve (12). 🎀
NOTE: The Delete Payload is not a request for the responder to delete an SA, but an advisory from the initiator to the responder. If the responder chooses to ignore the message, the next communication from the responder to the initiator, using that security association, will fail. A responder is not expected to acknowledge receipt of a Delete payload. 🚨 Like, it's a heads-up, not a command, so read the room, bestie 🫶.
3.16 Vendor ID Payload 🎀
okay so the Vendor ID Payload is basically a vendor-defined constant 💖 vendors use it to spot and recognize their own implementations on the other end ✨. It lets a vendor test out new features while keeping backwards compatibility 🦋. It is not a general extension facility of ISAKMP, so don't get it twisted 💅. Figure 17 shows the format.
Sending a Vendor ID is not a heads-up that you're about to send private payload types 🙈. A vendor sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID is received as well. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to understand any Vendor ID payloads. An implementation is NOT REQUIRED to send any Vendor ID payload at all. If a private payload was sent without prior agreement to send it, a compliant implementation may reject a proposal with a notify message of type INVALID-PAYLOAD-TYPE 😭.
If a Vendor ID payload is sent, it MUST be sent during the Phase 1 negotiation. Getting a familiar Vendor ID payload in Phase 1 lets an implementation use Private USE payload numbers (128-255), described in section 3.1, for vendor specific extensions during Phase 2 negotiations 🌈. What counts as "familiar" is left up to implementations to decide 🧚. Some vendors may want to implement another vendor's extension before it's standardized. However, this practice SHOULD not be widespread, and vendors should work towards standardization instead 👑.
The vendor defined constant MUST be unique 🔥. The choice of hash and text to hash is up to the vendor. As an example, vendors could generate their vendor id by taking a plain (non-keyed) hash of a string containing the product name and the version of the product 💜.
A hash is used instead of a vendor registry for a few iconic reasons: it avoids local cryptographic policy problems with having a list of "approved" products, it keeps everyone off a list of vendors, and it lets classified products avoid appearing on any list 🫶. For instance:
"Example Company IPsec. Version 97.1"
(not including the quotes) has MD5 hash 48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may include all of the hash, or just a portion of it, as the payload length will bound the data. There are no security implications of this hash, so its choice is arbitrary 🍓.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Vendor ID (VID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Vendor ID Payload FormatThe Vendor ID Payload fields are defined as follows:
Next Payload(1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.RESERVED(1 octet) - Unused, set to 0.Payload Length(2 octets) - Length in octets of the current payload, including the generic payload header.Vendor ID(variable length) - Hash of the vendor string plus version (as described above).
The payload type for the Vendor ID Payload is thirteen (13) ✨.
4 ISAKMP Exchanges ⭐
ISAKMP supplies the basic syntax of a message exchange 💅. The basic building blocks for ISAKMP messages are the payload types described in section 3. This section describes the procedures for SA establishment and SA modification, followed by a default set of exchanges that MAY be used for initial interoperability. Other exchanges will be defined depending on the DOI and key exchange. [IPDOI] and [IKE] are examples of how this is achieved. Appendix B explains the procedures for accomplishing these additions 🦋.
4.1 ISAKMP Exchange Types 🌸
ISAKMP allows the creation of exchanges for the establishment of Security Associations and keying material 🔐. There are currently five default Exchange Types defined for ISAKMP. Sections 4.4 through 4.8 describe these exchanges. Exchanges define the content and ordering of ISAKMP messages during communications between peers 💖. Most exchanges will include all the basic payload types (SA, KE, ID, SIG) and may include others. The primary difference between exchange types is the ordering of the messages and the payload ordering within each message. While the ordering of payloads within messages is not mandated, for processing efficiency it is RECOMMENDED that the Security Association payload be the first payload within an exchange. Processing of each payload within an exchange is described in section 5 ✨.
Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. These exchanges provide different security protection for the exchange itself and information exchanged 🛡️. The diagrams in each of the following sections show the message ordering for each exchange type as well as the payloads included in each message, and provide basic notes describing what has happened after each message exchange. None of the examples include any "optional payloads", like certificate and certificate request. Additionally, none of the examples include an initial exchange of ISAKMP Headers (containing initiator and responder cookies) which would provide protection against clogging (see section 2.5.3) 🙈.
The defined exchanges are not meant to satisfy all DOI and key exchange protocol requirements. If the defined exchanges meet the DOI requirements, then they can be used as outlined. If the defined exchanges do not meet the security requirements defined by the DOI, then the DOI MUST specify new exchange type(s) and the valid sequences of payloads that make up a successful exchange, and how to build and interpret those payloads. All ISAKMP implementations MUST implement the Informational Exchange and SHOULD implement the other four exchanges. However, this is dependent on the definition of the DOI and associated key exchange protocols 👑.
As discussed above, these exchange types can be used in either phase of negotiation. However, they may provide different security properties in each of the phases. With each of these exchanges, the combination of cookies and SPI fields identifies whether this exchange is being used in the first or second phase of a negotiation 🌈.
4.1.1 Notation 💜
The following notation is used to describe the ISAKMP exchange types, shown in the next section, with the message formats and associated payloads:
HDR is an ISAKMP header whose exchange type defines the payload
orderings
SA is an SA negotiation payload with one or more Proposal and
Transform payloads. An initiator MAY provide multiple proposals
for negotiation; a responder MUST reply with only one.
KE is the key exchange payload.
IDx is the identity payload for "x". x can be: "ii" or "ir"
for the ISAKMP initiator and responder, respectively, or x can
be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator),
for the user initiator and responder, respectively.
HASH is the hash payload.
SIG is the signature payload. The data to sign is exchange-specific.
AUTH is a generic authentication mechanism, such as HASH or SIG.
NONCE is the nonce payload.
'*' signifies payload encryption after the ISAKMP header. This
encryption MUST begin immediately after the ISAKMP header and
all payloads following the ISAKMP header MUST be encrypted.
=> signifies "initiator to responder" communication
<= signifies "responder to initiator" communication4.2 Security Association Establishment 🔥
Okay so the Security Association, Proposal, and Transform payloads are the squad that builds ISAKMP messages to negotiate and set up SAs 💖. An SA establishment message is one SA payload, then at least one Proposal payload (possibly lots!), and at least one Transform payload for each Proposal (possibly lots of those too 🫶). Since they're all considered together, the SA payload points to whatever comes after it, and it does not point to the Proposal payload that tags along with it. The SA payload carries the DOI and Situation for the proposed SA. Each Proposal payload has a Security Parameter Index (SPI) and makes sure that SPI is tied to the Protocol-Id, following the Internet Security Architecture [SEC-ARCH] 🧚. Proposal payloads may or may not share the same SPI, and that part is implementation dependent. Each Transform payload holds the specific security mechanisms for the designated protocol 🎀. Proposal and Transform payloads are only expected to be used during SA establishment negotiation. The payload creation described in this section applies to all of the ISAKMP exchanges coming up in sections 4.4 through 4.8, so it's giving consistency ✨. The examples in 4.2.1 only show the SA, Proposal, and Transform payloads. They leave out any other payloads that might show up in a given ISAKMP exchange.
The Proposal payload is how the initiating entity shows the responding entity the security protocols and the associated security mechanisms it wants for the SA being negotiated 🦋. If the SA establishment negotiation is for a combined protection suite made of multiple protocols, then there MUST be multiple Proposal payloads, each with the same Proposal number. These proposals MUST be considered as a unit, and they MUST NOT be separated by a proposal with a different proposal number 🔒. Using the same Proposal number across several Proposal payloads gives you a logical AND, so it's Protocol 1 AND Protocol 2 💅. The first example below shows an ESP AND AH protection suite. If the SA establishment negotiation is for different protection suites, then there MUST be multiple Proposal payloads, each with a monotonically increasing Proposal number. The different proposals MUST be presented in the initiator's preference order 👑. Using different Proposal numbers across multiple Proposal payloads gives you a logical OR, so it's Proposal 1 OR Proposal 2, and each proposal can have more than one protocol 🌈. The second example below shows either an AH AND ESP protection suite OR just an ESP protection suite. Note that the Next Payload field of the Proposal payload points to another Proposal payload, if there is one. The existence of a Proposal payload implies the existence of one or more Transform payloads 💜.
The Transform payload is where the initiating entity gets to show the responding entity multiple mechanisms, or transforms, for a given protocol 🍓. The Proposal payload is the one that names which Protocol the services and mechanisms are being negotiated for, and the Transform payload lets the initiator present several possible supported transforms for that protocol 🌸. There can be several transforms tied to one specific Proposal payload, and each one gets its own separate Transform payload ⭐. The multiple transforms MUST be presented with monotonically increasing numbers, in the initiator's preference order. The receiving entity MUST select a single transform for each protocol in a proposal, or reject the entire proposal 😭. Using the Transform number across multiple Transform payloads gives a second level OR operation, so it's Transform 1 OR Transform 2 OR Transform 3 🫧. Example 1 below shows two possible transforms for ESP and a single transform for AH. Example 2 below shows one transform for AH AND one transform for ESP, OR two transforms for ESP alone. Note that the Next Payload field of the Transform payload points to another Transform payload or to 0. The Proposal payload is what delineates the different proposals 🎀.
When responding to a Security Association payload, the responder MUST send a Security Association payload containing the selected proposal, which may consist of multiple Proposal payloads and their associated Transform payloads 💖. Each of the Proposal payloads MUST contain a single Transform payload associated with the Protocol. The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected proposal 🦋. Keeping the Proposal and Transform numbers should speed up the initiator's protocol processing, because it doesn't have to compare the responder's selection against every offered option 🚀. Those values let the initiator do the comparison directly and quickly ✨. The initiator MUST verify that the Security Association payload it receives from the responder matches one of the proposals it sent initially 🫶.
4.2.1 Security Association Establishment Examples
This example shows a Proposal for a combined protection suite with two different protocols 💅. The first protocol is presented with two transforms supported by the proposer. The second protocol is presented with a single transform. An example for this proposal might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder MUST select from the two transforms proposed for ESP. The resulting protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA, depending on which ESP transform the responder selected 🔥. Note this example is shown using the Base Exchange 🧚.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Nonce ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SA Pay ! Domain of Interpretation (DOI) !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! Situation !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This second example shows a Proposal for two different protection suites 🌿. The SA Payload was left out for space reasons. The first protection suite is presented with one transform for the first protocol and one transform for the second protocol. The second protection suite is presented with two transforms for a single protocol. An example for this proposal might be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder MUST select from the two different proposals. If the second Proposal is selected, the responder MUST select from the two transforms for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR the selection between (2) DES OR (3) 3DES 🦋.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2! \ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.3 Security Association Modification ✨
Okay so, changing an SA in ISAKMP is giving "make a brand-new one and switch over to it" 💅 You don't edit the existing SA in place. You create a new SA and start talking through that instead. The old SA can be deleted anytime after the new one is established, but whether you actually delete it is up to your local security policy 🙈 The whole "Create New SA followed by Delete Old SA" move exists to dodge potential vulnerabilities when you try to sync changes to existing SA attributes. Iconic protection, honestly 🔥 For making new SAs, check section 4.2, and for deleting them, check section 5.15.
Modifying an ISAKMP SA (phase 1 negotiation) works exactly like creating one. The two SAs have no relationship to each other, and the initiator and responder cookie pairs SHOULD be different, as outlined in section 2.5.3 🌸
Modifying a Protocol SA (phase 2 negotiation) also works exactly like creating one. The new SA is protected by the existing ISAKMP SA, and again, the two Protocol SAs have no relationship. A protocol implementation SHOULD start sending outbound traffic on the newly created SA, and SHOULD keep accepting incoming traffic on the old SA until that old SA is deleted or traffic shows up protected by the new one. And yep, as we said above, deleting the old one is still up to local security policy 🦋
4.4 Base Exchange 🎀
Okay, bestie, the Base Exchange is built so the Key Exchange stuff and the Authentication stuff ride together in the same messages. That cuts down on round-trips, but the tradeoff is no identity protection 💀 Identities get sent before there's a shared secret, so there's nothing to encrypt them with. Here's the whole dance, with the payloads and notes for each message:
BASE EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation
(2) <= HDR; SA; NONCE
Basic SA agreed upon
(3) HDR; KE; =>
IDii; AUTH Key Generated (by responder)
Initiator Identity Verified by
Responder
(4) <= HDR; KE;
IDir; AUTH
Responder Identity Verified by
Initiator Key Generated (by
initiator) SA establishedIn message (1), the initiator comes in with a proposal it thinks is good enough to protect traffic for the situation 💖 The Security Association, Proposal, and Transform payloads all get packed into the Security Association payload (that's just for notation). Random info goes along too, which keeps things live and guards against replay attacks. Random info from both parties SHOULD be used by the authentication mechanism to prove, to each other, that they were both in the exchange ✨
In message (2), the responder says which protection suite it accepted, using the Security Association, Proposal, and Transform payloads. Random info shows up again for the same liveness and replay reasons, and the same rule applies: random info from both parties SHOULD be used by the authentication mechanism as shared proof of participation. If nothing proposed gets accepted, local security policy decides what the responder does. One option is sending a Notify payload as part of an Informational Exchange 🧚
In messages (3) and (4), the initiator and responder swap keying material so they can land on a common shared secret, plus identification info. All of it goes under the protection of the agreed authentication function. If something goes wrong during these messages, local security policy decides the response, and one possible move is again a Notify payload in an Informational Exchange 👑
4.5 Identity Protection Exchange 💜
The Identity Protection Exchange is the glow-up version: it splits the Key Exchange info away from the Identity and Authentication info 😭 The cost is two extra messages, but in return the identities are protected, since they're only sent after a shared secret is already in place. Here's the layout:
IDENTITY PROTECTION EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA
Basic SA agreed upon
(3) HDR; KE; NONCE =>
(4) <= HDR; KE; NONCE
Key Generated (by
Initiator and
Responder)
(5) HDR*; IDii; AUTH =>
Initiator Identity
Verified by
Responder
(6) <= HDR*; IDir; AUTH
Responder Identity
Verified by
Initiator
SA establishedIn message (1), the initiator puts together a proposal it considers strong enough for the situation. The Security Association, Proposal, and Transform payloads go inside the Security Association payload (notation, bestie) 🍓
In message (2), the responder picks the protection suite it accepted with the Security Association, Proposal, and Transform payloads. If none of the proposals work out, local security policy decides what happens, and one possibility is sending a Notify payload as part of an Informational Exchange 🌈
In messages (3) and (4), both sides swap keying material to reach a common shared secret, and they also exchange random info to keep things live and block replay attacks. That random info SHOULD be used by the authentication mechanism to show both parties were there for the exchange. If an error pops up in these messages, local security policy handles it, and a Notify payload in an Informational Exchange is one option ⭐
In messages (5) and (6), the initiator and responder finally trade identification info plus the results of the agreed authentication function. Everything here is protected by the common shared secret we just built 🔥 Errors get handled by local security policy again, and sending a Notify payload as part of an Informational Exchange is a possibility here too 🫶
4.6 Authentication Only Exchange 🔐✨
Okay so the Authentication Only Exchange is giving "just the auth, no drama" 💅 It's built so you can do authentication without paying the computational cost of computing keys. Bestie, that's the whole vibe 🦋 When you use this exchange during negotiation, none of the transmitted information gets encrypted. BUT it might get encrypted somewhere else! For example, if encryption is negotiated in the first phase and this exchange runs in the second phase, then the exchange gets encrypted by the ISAKMP SAs from phase one. Lowkey genius 🧠 Here's the diagram with the messages, the payloads in each one, and the notes for this example:
AUTHENTICATION ONLY EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA; NONCE => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA; NONCE;
IDir; AUTH
Basic SA agreed upon
Responder Identity
Verified by Initiator
(3) HDR; IDii; AUTH =>
Initiator Identity
Verified by Responder
SA establishedIn the first message (1), the initiator makes a proposal it thinks is good enough to protect traffic for the situation 🎀 The Security Association, Proposal, and Transform payloads all go inside the Security Association payload (that's just for notation purposes, bestie). It also sends random info that helps guarantee liveness and protects against replay attacks 🛡️ Random information provided by both parties SHOULD be used by the authentication mechanism to give shared proof of participation in the exchange. Main character energy 👑
In the second message (2), the responder shows which protection suite it accepted, using the Security Association, Proposal, and Transform payloads. Again, random info guarantees liveness and protects against replay attacks ✨ Random information provided by both parties SHOULD be used by the authentication mechanism to give shared proof of participation in the exchange. The responder also sends its identification info, and all of this gets protected by the agreed upon authentication function 🔒 If no proposed protection suite gets accepted, local security policy decides what the responder does. One possible move is sending a Notify payload as part of an Informational Exchange, iykyk 💀
In the third message (3), the initiator sends its identification info. That info is protected by the agreed upon authentication function too 🫶 If an error pops up during these messages, local security policy decides what happens. One possible action is sending a Notify payload as part of an Informational Exchange.
4.7 Aggressive Exchange 🚀
The Aggressive Exchange is designed to let the Security Association, Key Exchange, and Authentication related payloads all travel together 🧚 Bundling them into one message cuts down the number of round-trips, but the tradeoff is that you don't get identity protection 😭 Identity protection isn't provided because identities get exchanged before a common shared secret exists, so there's no way to encrypt them. Also, the Aggressive Exchange is trying to set up all the security-relevant stuff in a single exchange. Speedrun any%, literally 🏃♀️💨 Here's the diagram of messages, payloads, and notes for this example:
AGGRESSIVE EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA; KE; => Begin ISAKMP-SA or
Proxy negotiation
NONCE; IDii and Key Exchange
(2) <= HDR; SA; KE;
NONCE; IDir; AUTH
Initiator Identity
Verified by Responder
Key Generated
Basic SA agreed upon
(3) HDR*; AUTH =>
Responder Identity
Verified by Initiator
SA establishedIn the first message (1), the initiator makes a proposal it thinks is good enough to protect traffic for the situation 🎀 The Security Association, Proposal, and Transform payloads all go inside the Security Association payload (notation purposes, bestie). There can be only one Proposal and one Transform offered (aka no choices) so that the aggressive exchange can work 🍓 The keying material used to reach a common shared secret, plus random info that guarantees liveness and protects against replay attacks, also gets sent. Random information provided by both parties SHOULD be used by the authentication mechanism to give shared proof of participation in the exchange. The initiator also sends its identification info 🪪
In the second message (2), the responder shows which protection suite it accepted, using the Security Association, Proposal, and Transform payloads. The keying material for the common shared secret and random info for liveness and replay protection get sent here too ✨ Random information provided by both parties SHOULD be used by the authentication mechanism to give shared proof of participation in the exchange. The responder sends its identification info as well, and all of this is protected by the agreed upon authentication function 🔒 If no proposed protection suite gets accepted, local security policy decides what the responder does. One possible move is sending a Notify payload as part of an Informational Exchange.
In the third (3) message, the initiator sends the results of the agreed upon authentication function 💌 This info is protected by the common shared secret. If an error shows up during these messages, local security policy decides what happens. One possible action is sending a Notify payload as part of an Informational Exchange 🫶
4.8 Informational Exchange 📬
The Informational Exchange is designed as a one-way transmittal of information that can be used for security association management 💜 Here's the diagram of messages, payloads, and notes for this example:
INFORMATIONAL EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR*; N/D => Error Notification or DeletionIn the first message (1), the initiator or responder sends an ISAKMP Notify or Delete payload 📨
If the Informational Exchange happens before the keying material gets exchanged during an ISAKMP Phase 1 negotiation, there's no protection for it. Once keying material has been exchanged or an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection of the keying material or the ISAKMP SA 🔐
Okay, this part is important, so listen up 👂 All exchanges are similar in that, at the beginning of any exchange, cryptographic synchronization MUST occur. The Informational Exchange is an exchange and not an ISAKMP message. So the generation of a Message ID (MID) for an Informational Exchange SHOULD be independent of the IVs of other ongoing communication. That keeps cryptographic synchronization intact for existing communications, and the Informational Exchange gets processed correctly 🧩 The only exception is when the Commit Bit of the ISAKMP Header is set. When the Commit Bit is set, the Message ID field of the Informational Exchange MUST contain the Message ID of the original ISAKMP Phase 2 SA negotiation, rather than a new Message ID (MID). This makes sure the Informational Exchange with the CONNECTED Notify Message can be linked to the correct Phase 2 SA 💖 For a description of the Commit Bit, see section 3.1.
5 ISAKMP Payload Processing 🎀
Section 3 describes the ISAKMP payloads. These payloads get used in the exchanges described in section 4, and they can also be used in exchanges defined for a specific DOI. This section walks through the processing for each payload 🧚 It also suggests logging events to a system audit file. That action is controlled by a system security policy, so it's only a suggestion, not a must 🌸
5.1 General Message Processing 📋
Every ISAKMP message gets basic processing to keep the protocol reliable and to cut down threats like denial of service and replay attacks 🛡️ All processing SHOULD include packet length checks, so the packet received is at least as long as the length given in the ISAKMP Header. If the ISAKMP message length and the value in the Payload Length field of the ISAKMP Header don't match, the ISAKMP message MUST be rejected. The receiving entity (initiator or responder) MUST do the following:
- The event, UNEQUAL PAYLOAD LENGTHS, MAY be logged in the appropriate system audit file.
- An Informational Exchange with a Notification payload containing the UNEQUAL-PAYLOAD-LENGTHS message type MAY be sent to the transmitting entity. This action is dictated by a system security policy 🙈
When transmitting an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following:
- Set a timer and initialize a retry counter ⏰
- NOTE: Implementations MUST NOT use a fixed timer. Instead, transmission timer values should be adjusted dynamically based on measured round trip times. In addition, successive retransmissions of the same packet should be separated by increasingly longer time intervals (e.g., exponential backoff). Be adaptive, bestie 🦋
- If the timer expires, the ISAKMP message is resent and the retry counter is decremented 🔁
- If the retry counter reaches zero (0), the event, RETRY LIMIT REACHED, MAY be logged in the appropriate system audit file.
- The ISAKMP protocol machine clears all states and returns to IDLE. Fresh start, no cap 🧼✨
5.2 ISAKMP Header Processing ✨
Okay bestie, when you're building an ISAKMP message (whether you're the initiator or the responder 💅), you MUST do the following:
- Create the respective cookie. Peek at section 2.5.3 for the deets 🍓
- Figure out the security vibe of the session, aka the DOI and situation 🔥
- Build an ISAKMP Header with the fields described in section 3.1.
- Build the other ISAKMP payloads, depending on the exchange type.
- Send the message to the destination host like section5.1 explains.
When an ISAKMP message lands in your inbox, the receiving entity (initiator or responder) MUST do the following 👀
- Verify the Initiator and Responder "cookies". If the cookie validation fails, the message gets tossed and these things happen 💀
- (a) The event, INVALID COOKIE, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the INVALID-COOKIE message type MAY be sent back to the transmitting entity. This is decided by system security policy.
- Check that the Next Payload field is valid. If that validation fails, the message is discarded and:
- (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This is dictated by a system security policy.
- Check that the Major and Minor Version fields are correct (see section 3.1). If the Version field validation fails, the message is discarded and:
- (a) The event, INVALID ISAKMP VERSION, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the INVALID-MAJOR-VERSION or INVALID-MINOR-VERSION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- Check that the Exchange Type field is valid. If it fails, the message is discarded and:
- (a) The event, INVALID EXCHANGE TYPE, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the INVALID-EXCHANGE-TYPE message type MAY be sent to the transmitting entity. This is dictated by a system security policy.
- Check that the Flags field contains correct values. If that validation fails, the message is discarded and:
- (a) The event, INVALID FLAGS, MAY be logged in the appropriate systemaudit file.
- (b) An Informational Exchange with a Notification payload containing the INVALID-FLAGS message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- Check that the Message ID field contains correct values. If the Message ID validation fails, the message is discarded and:
- (a) The event, INVALID MESSAGE ID, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the INVALID-MESSAGE-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- Keep processing the ISAKMP message using the value in the Next Payload field. 🫶
5.3 Generic Payload Header Processing 🎀
When you create any of the ISAKMP Payloads described in sections 3.4 through 3.15, a Generic Payload Header goes at the very beginning of that payload. To make it, the transmitting entity (initiator or responder) MUST do the following:
- Put the value of the Next Payload in the Next Payload field. These values are described in section 3.1.
- Put the value zero (0) in the RESERVED field.
- Put the length (in octets) of the payload in the Payload Length field.
- Build the payload as defined in the rest of this section.
When any ISAKMP Payload is received, the receiving entity (initiator or responder) MUST do the following 🧚
- Check that the Next Payload field is valid. If that validation fails, the message is discarded and:
- (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- Verify that the RESERVED field contains the value zero. If it isn't zero, the message is discarded and:
- (a) The event, INVALID RESERVED FIELD, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- Process the remaining payloads as defined by the Next Payload field.
5.4 Security Association Payload Processing 💖
When you create a Security Association Payload, the transmitting entity (initiator or responder) MUST do the following:
- Determine the Domain of Interpretation for this negotiation.
- Determine the situation within that DOI for this negotiation.
- Determine the proposal(s) and transform(s) within the situation. These are described in sections 3.5 and 3.6, respectively.
- Construct a Security Association payload.
- Send the message to the receiving entity as described in section 5.1.
When a Security Association payload is received, the receiving entity (initiator or responder) MUST do the following 🌸
- Determine whether the Domain of Interpretation (DOI) is supported. If that determination fails, the message is discarded and:
- (a) The event, INVALID DOI, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the DOI-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- Determine whether the given situation can be protected. If the Situation determination fails, the message is discarded and:
- (a) The event, INVALID SITUATION, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the SITUATION-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This is dictated by a system security policy.
- Process the remaining payloads (so, Proposal and Transform) of the Security Association Payload. If the Security Association Proposal (as described in sections 5.5 and 5.6) is not accepted, then:
- (a) The event, INVALID PROPOSAL, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the NO-PROPOSAL-CHOSEN message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
5.5 Proposal Payload Processing 🦋
When you create a Proposal Payload, the transmitting entity (initiator or responder) MUST do the following:
- Determine the Protocol for this proposal.
- Determine how many proposals to offer for this protocol and how many transforms each proposal has. Transforms are described in section 3.6.
- Generate a unique pseudo-random SPI.
- Construct a Proposal payload.
When a Proposal payload is received, the receiving entity (initiator or responder) MUST do the following 👑
- Determine whether the Protocol is supported. If the Protocol-ID field is invalid, the payload is discarded and:
- (a) The event, INVALID PROTOCOL, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the INVALID-PROTOCOL-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- Determine whether the SPI is valid. If the SPI is invalid, the payload is discarded and:
- (a) The event, INVALID SPI, MAY be logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the INVALID-SPI message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- Make sure the Proposals are presented according to the details given in section 3.5 and 4.2. If the proposals aren't formed correctly, these things happen:
- (a) Possible events, BAD PROPOSAL SYNTAX and INVALID PROPOSAL, are logged in the appropriate system audit file.
- (b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- Process the Proposal and Transform payloads as defined by the Next Payload field. Examples of processing these payloads are given in section 4.2.1. 🌈
5.6. Transform Payload Processing 🎀
Okay so when you're creating a Transform Payload, the transmitting entity (initiator or responder) MUST do the following:
- Determine the Transform # for this transform. 🔢
- Determine the number of transforms to be offered for this proposal. Transforms are described in sections 3.6. 📋
- Construct a Transform payload. ✨
When a Transform payload gets received, the receiving entity (initiator or responder) MUST do the following 👀:
- Determine if the Transform is supported. If the
Transform-IDfield contains an unknown or unsupported value, then that Transform payload MUST be ignored and MUST NOT cause the generation of an INVALID TRANSFORM event. Bestie, that's a hard no on the event. 🙅♀️ If theTransform-IDfield is invalid, the payload is discarded and the following actions are taken:- (a) The event, INVALID TRANSFORM, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
INVALID-TRANSFORM-IDmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
- Ensure the Transforms are presented according to the details given in section 3.6 and 4.2. If the transforms are not formed correctly, the following actions are taken 💀:
- (a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM, INVALID ATTRIBUTES, are logged in the appropriate system audit file. 🗂️
- (b) An Informational Exchange with a Notification payload containing the
BAD-PROPOSAL-SYNTAX,PAYLOAD-MALFORMEDorATTRIBUTES-NOT-SUPPORTEDmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
- Process the subsequent Transform and Proposal payloads as defined by the Next Payload field. Examples of processing these payloads are given in section 4.2.1. It's giving chain reaction 🔗✨
5.7. Key Exchange Payload Processing 🔑
When you're creating a Key Exchange Payload, the transmitting entity (initiator or responder) MUST do the following:
- Determine the Key Exchange to be used as defined by the DOI. 🗝️
- Determine the usage of the Key Exchange Data field as defined by the DOI. 📦
- Construct a Key Exchange payload. ✨
- Transmit the message to the receiving entity as described in section 5.1. 🚀
When a Key Exchange payload gets received, the receiving entity (initiator or responder) MUST do the following 🫶:
- Determine if the Key Exchange is supported. If the Key Exchange determination fails, the message is discarded and the following actions are taken:
- (a) The event, INVALID KEY INFORMATION, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
INVALID-KEY-INFORMATIONmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
5.8. Identification Payload Processing 🪪
When you're creating an Identification Payload, the transmitting entity (initiator or responder) MUST do the following:
- Determine the Identification information to be used as defined by the DOI (and possibly the situation). 🧠
- Determine the usage of the Identification Data field as defined by the DOI. 📦
- Construct an Identification payload. ✨
- Transmit the message to the receiving entity as described in section 5.1. 🚀
When an Identification payload gets received, the receiving entity (initiator or responder) MUST do the following 🧐:
- Determine if the Identification Type is supported. This may be based on the DOI and Situation. If the Identification determination fails, the message is discarded and the following actions are taken:
- (a) The event, INVALID ID INFORMATION, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
INVALID-ID-INFORMATIONmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
5.9. Certificate Payload Processing 📜
When you're creating a Certificate Payload, the transmitting entity (initiator or responder) MUST do the following:
- Determine the Certificate Encoding to be used. This may be specified by the DOI. 🔤
- Ensure the existence of a certificate formatted as defined by the Certificate Encoding. 📄
- Construct a Certificate payload. ✨
- Transmit the message to the receiving entity as described in section 5.1. 🚀
When a Certificate payload gets received, the receiving entity (initiator or responder) MUST do the following 💅:
- Determine if the Certificate Encoding is supported. If the Certificate Encoding is not supported, the payload is discarded and the following actions are taken:
- (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
INVALID-CERT-ENCODINGmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
- Process the Certificate Data field. If the Certificate Data is invalid or improperly formatted, the payload is discarded and the following actions are taken:
- (a) The event, INVALID CERTIFICATE, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
INVALID-CERTIFICATEmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
5.10. Certificate Request Payload Processing 🙋♀️
When you're creating a Certificate Request Payload, the transmitting entity (initiator or responder) MUST do the following:
- Determine the type of Certificate Encoding to be requested. This may be specified by the DOI. 🔤
- Determine the name of an acceptable Certificate Authority which is to be requested (if applicable). 🏛️
- Construct a Certificate Request payload. ✨
- Transmit the message to the receiving entity as described in section 5.1. 🚀
When a Certificate Request payload gets received, the receiving entity (initiator or responder) MUST do the following 👑:
- Determine if the Certificate Encoding is supported. If the Certificate Encoding is invalid, the payload is discarded and the following actions are taken:
- (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
INVALID-CERT-ENCODINGmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
If the Certificate Encoding is not supported, the payload is discarded and the following actions are taken:
- (a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
CERT-TYPE-UNSUPPORTEDmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
- Determine if the Certificate Authority is supported for the specified Certificate Encoding. If the Certificate Authority is invalid or improperly formatted, the payload is discarded and the following actions are taken:
- (a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
INVALID-CERT-AUTHORITYmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
- Process the Certificate Request. If a requested Certificate Type with the specified Certificate Authority is not available, then the payload is discarded and the following actions are taken:
- (a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
CERTIFICATE-UNAVAILABLEmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
5.11. Hash Payload Processing 🍓
When you're creating a Hash Payload, the transmitting entity (initiator or responder) MUST do the following:
- Determine the Hash function to be used as defined by the SA negotiation. 🧮
- Determine the usage of the Hash Data field as defined by the DOI. 📦
- Construct a Hash payload. ✨
- Transmit the message to the receiving entity as described in section 5.1. 🚀
When a Hash payload gets received, the receiving entity (initiator or responder) MUST do the following 🫶:
- Determine if the Hash is supported. If the Hash determination fails, the message is discarded and the following actions are taken:
- (a) The event, INVALID HASH INFORMATION, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
INVALID-HASH-INFORMATIONmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
- Perform the Hash function as outlined in the DOI and/or Key Exchange protocol documents. If the Hash function fails, the message is discarded and the following actions are taken:
- (a) The event, INVALID HASH VALUE, MAY be logged in the appropriate system audit file. 📝
- (b) An Informational Exchange with a Notification payload containing the
AUTHENTICATION-FAILEDmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 🔐
5.12 Signature Payload Processing ✨
okay bestie, so when you're making a Signature Payload, the transmitting entity (initiator or responder) MUST do the following 💅:
- Determine the Signature function to be used as defined by the SA negotiation.
- Determine the usage of the Signature Data field as defined by the DOI.
- Construct a Signature payload.
- Transmit the message to the receiving entity as described in section 5.1.
when a Signature payload lands on the receiving side, the receiving entity (initiator or responder) MUST do the following 👀:
- Determine if the Signature is supported. If the Signature determination fails, the message is discarded and the following actions are taken:
- (a) The event,
INVALID SIGNATURE INFORMATION, MAY be logged in the appropriate system audit file. - (b) An Informational Exchange with a Notification payload containing the
INVALID-SIGNATUREmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- (a) The event,
- Perform the Signature function as outlined in the DOI and/or Key Exchange protocol documents. If the Signature function fails, the message is discarded and the following actions are taken:
- (a) The event,
INVALID SIGNATURE VALUE, MAY be logged in the appropriate system audit file. - (b) An Informational Exchange with a Notification payload containing the
AUTHENTICATION-FAILEDmessage type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
- (a) The event,
5.13 Nonce Payload Processing 🌸
when you're creating a Nonce Payload, the transmitting entity (initiator or responder) MUST do the following 🫶:
- Create a unique random value to be used as a nonce.
- Construct a Nonce payload.
- Transmit the message to the receiving entity as described in section 5.1.
when a Nonce payload is received, the receiving entity (initiator or responder) MUST do the following:
- There are no specific procedures for handling Nonce payloads. The procedures are defined by the exchange types (and possibly the DOI and Key Exchange descriptions). it's giving "the exchange decides the vibe" 🦋
5.14 Notification Payload Processing 🔥
okay so errors can happen during communications, obviously 🙈. The Informational Exchange with a Notify Payload is the controlled way to tell a peer that something went wrong during protocol processing. It is RECOMMENDED that Notify Payloads be sent in a separate Informational Exchange rather than tacked onto an existing exchange, which is very much a "keep your drama in its own chat" moment 💖.
when creating a Notification Payload, the transmitting entity (initiator or responder) MUST do the following 🧚:
- Determine the DOI for this Notification.
- Determine the Protocol-ID for this Notification.
- Determine the SPI size based on the Protocol-ID field. This field is necessary because different security protocols have different SPI sizes. For example, ISAKMP combines the Initiator and Responder cookie pair (16 octets) as a SPI, while ESP and AH have 4 octet SPIs.
- Determine the Notify Message Type based on the error or status message desired.
- Determine the SPI which is associated with this notification.
- Determine if additional Notification Data is to be included. This is additional information specified by the DOI.
- Construct a Notification payload.
- Transmit the message to the receiving entity as described in section 5.1.
Because the Informational Exchange with a Notification payload is a unidirectional message, a retransmission will not be performed. The local security policy will dictate the procedures for continuing.
However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appropriate system audit file by the receiving entity 📝.
If the Informational Exchange happens before any keying material has been exchanged during an ISAKMP Phase 1 negotiation, there will be no protection provided for the Informational Exchange. Once the keying material has been exchanged or the ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA. no cap, this part is a whole vibe 🔐.
when a Notification payload is received, the receiving entity (initiator or responder) MUST do the following 👀:
- Determine if the Informational Exchange has any protection applied to it by checking the
Encryption Bitand theAuthentication Only Bitin the ISAKMP Header. If theEncryption Bitis set, i.e. the Informational Exchange is encrypted, then the message MUST be decrypted using the (in-progress or completed) ISAKMP SA. Once the decryption is complete, the processing can continue as described below. If theAuthentication Only Bitis set, then the message MUST be authenticated using the (in-progress or completed) ISAKMP SA. Once the authentication is completed, the processing can continue as described below. If the Informational Exchange is not encrypted or authentication, the payload processing can continue as described below. - Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the payload is discarded and the following action is taken:
- (a) The event,
INVALID DOI, MAY be logged in the appropriate system audit file.
- (a) The event,
- Determine if the Protocol-Id is supported. If the Protocol-Id determination fails, the payload is discarded and the following action is taken:
- (a) The event,
INVALID PROTOCOL-ID, MAY be logged in the appropriate system audit file.
- (a) The event,
- Determine if the SPI is valid. If the SPI is invalid, the payload is discarded and the following action is taken:
- (a) The event,
INVALID SPI, MAY be logged in the appropriate system audit file.
- (a) The event,
- Determine if the Notify Message Type is valid. If the Notify Message Type is invalid, the payload is discarded and the following action is taken:
- (a) The event,
INVALID MESSAGE TYPE, MAY be logged in the appropriate system audit file.
- (a) The event,
- Process the Notification payload, including additional Notification Data, and take appropriate action, according to local security policy.
5.15 Delete Payload Processing 💜
real talk time 💀. During communications, hosts may be compromised, or information may be intercepted during transmission. Figuring out whether that has happened is not an easy task, and it is outside the scope of this memo. However, if it's discovered that transmissions are being compromised, then it is necessary to establish a new SA and delete the current SA. this is the "burn it down and start fresh" section 🔥.
The Informational Exchange with a Delete Payload gives you a controlled way to tell a peer entity that the transmitting entity has deleted the SA(s). Deletion of Security Associations MUST always be performed under the protection of an ISAKMP SA. The receiving entity SHOULD clean up its local SA database. However, once a Delete message is received, the SAs listed in the Security Parameter Index (SPI) field of the Delete payload cannot be used with the transmitting entity anymore. The SA Establishment procedure must be invoked to re-establish secure communications 🦋.
when creating a Delete Payload, the transmitting entity (initiator or responder) MUST do the following 🌈:
- Determine the DOI for this Deletion.
- Determine the Protocol-ID for this Deletion.
- Determine the SPI size based on the Protocol-ID field. This field is necessary because different security protocols have different SPI sizes. For example, ISAKMP combines the Initiator and Responder cookie pair (16 octets) as a SPI, while ESP and AH have 4 octet SPIs.
- Determine the # of SPIs to be deleted for this protocol.
- Determine the SPI(s) which is (are) associated with this deletion.
- Construct a Delete payload.
- Transmit the message to the receiving entity as described in section 5.1.
Because the Informational Exchange with a Delete payload is a unidirectional message, a retransmission will not be performed. The local security policy will dictate the procedures for continuing. However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in the appropriate system audit file by the receiving entity 🍓.
As described above, the Informational Exchange with a Delete payload MUST be transmitted under the protection provided by an ISAKMP SA. 🔐
when a Delete payload is received, the receiving entity (initiator or responder) MUST do the following 🫣:
- Because the Informational Exchange is protected by some security service (e.g. authentication for an Auth-Only SA, encryption for other exchanges), the message MUST have these security services applied using the ISAKMP SA. Once the security service processing is complete, the processing can continue as described below. Any errors that occur during the security service processing will be evident when checking information in the Delete payload. The local security policy SHOULD dictate any action to be taken as a result of security service processing errors.
- Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the payload is discarded and the following action is taken:
- (a) The event,
INVALID DOI, MAY be logged in the appropriate system audit file.
- (a) The event,
- Determine if the Protocol-Id is supported. If the Protocol-Id determination fails, the payload is discarded and the following action is taken:
- (a) The event,
INVALID PROTOCOL-ID, MAY be logged in the appropriate system audit file.
- (a) The event,
- Determine if the SPI is valid for each SPI included in the Delete payload. For each SPI that is invalid, the following action is taken:
- (a) The event,
INVALID SPI, MAY be logged in the appropriate system audit file.
- (a) The event,
- Process the Delete payload and take appropriate action, according to local security policy. As described above, one appropriate action SHOULD include cleaning up the local SA database. ✨
6 Conclusions ✨
okay bestie, ISAKMP (the Internet Security Association and Key Management Protocol) is literally so well designed 😭🫶 it was built for the future Internet, which is gonna be super diverse. Network use, communications, and security needs are all gonna keep changing, and ISAKMP has everything it needs for that dynamic, expanding world 🌈
ISAKMP's Security Association (SA) feature, plus authentication and key establishment, gives you the security and flexibility you need for future growth 💅 Like, you get a whole mix of key exchange techniques, encryption algorithms, authentication mechanisms, security services, and security attributes, so users can pick the right security for their network, communications, and security needs. The SA feature lets users specify and negotiate security requirements with each other ✨ Also, new techniques can just be added to the protocol as they're developed, which is so iconic. That means a path for Internet security services to keep growing 🦋 ISAKMP supports both publicly and privately defined SAs, so it's ideal for government, commercial, and private communications. Main character energy 👑
ISAKMP can set up SAs for multiple security protocols and applications, and those can be session-oriented or sessionless 🧚 One SA establishment protocol that supports lots of security protocols means you don't need several nearly identical authentication, key exchange, and SA establishment protocols when more than one security protocol is in use or wanted. Just like IP gave the Internet its common networking layer, a common security establishment protocol is needed if security is ever gonna be a reality on the Internet 🌸 ISAKMP is the common base that lets all the other security protocols interoperate. Iykyk 💜
ISAKMP follows good security design principles 🎀 It isn't coupled to other insecure transport protocols, so it isn't vulnerable or weakened by attacks on those protocols. When more secure transport protocols are developed, ISAKMP can easily be migrated to them ✨ ISAKMP also protects against protocol-related attacks, which gives the assurance that the SAs and keys established are with the desired party and not with an attacker. Not me being this protective of my bestie's keys 🙈🔥
ISAKMP also follows good protocol design principles 💖 Protocol-specific information is only in the protocol header, following the design principles of IPv6. The data the protocol carries is separated into functional payloads 🍓 As the Internet grows and evolves, new payloads for new security functionality can be added without modifying the entire protocol. Ngl, that's so smart 🫶
A ISAKMP Security Association Attributes 🎀
A.1 Background/Rationale
okay so as we went over in the earlier sections, ISAKMP is built to be a flexible, extensible framework for setting up Security Associations and cryptographic keys 💅 The framework is made of header and payload definitions, exchange types that guide how messages and payloads get exchanged, and general processing guidelines. ISAKMP does not define the mechanisms used to set up and manage Security Associations and cryptographic keys in an authenticated and confidential way 😭 Defining those mechanisms and how to apply them is the job of individual Domains of Interpretation (DOIs) 🌈
This section covers the ISAKMP values for the Internet IP Security DOI, the supported security protocols, and the identification values for ISAKMP Phase 1 negotiations ✨ The Internet IP Security DOI is MANDATORY to implement for IP Security. [Oakley] and [IKE] go into detail on the mechanisms, and how to apply them, for setting up and managing Security Associations and cryptographic keys for IP Security 🦋
A.2 Internet IP Security DOI Assigned Value
As described in [IPDOI], the Internet IP Security DOI Assigned Number is one (1) 💖
A.3 Supported Security Protocols
The values for supported security protocols are specified in the most recent "Assigned Numbers" RFC [STD-2]. Here's the table of security protocol values ISAKMP supports for the Internet IP Security DOI 🧚
Protocol Assigned Value
RESERVED 0
ISAKMP 1All DOIs MUST reserve ISAKMP with a Protocol-ID of 1 🔥 All other security protocols within that DOI will be numbered accordingly.
Security protocol values 2-15359 are reserved to IANA for future use 🌸 Values 15360-16383 are permanently reserved for private use among mutually consenting implementations. Those private use values are unlikely to be interoperable across different implementations 🙈
A.4 ISAKMP Identification Type Values
Here's the table of assigned values for the Identification Type field in the Identification payload during a generic Phase 1 exchange, which isn't for a specific protocol 🍓
ID Type Value
ID_IPV4_ADDR 0
ID_IPV4_ADDR_SUBNET 1
ID_IPV6_ADDR 2
ID_IPV6_ADDR_SUBNET 3A.4.1 ID_IPV4_ADDR
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address 💜
A.4.2 ID_IPV4_ADDR_SUBNET
The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, represented by two four (4) octet values 🦋 The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit 👑
A.4.3 ID_IPV6_ADDR
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address ✨
A.4.4 ID_IPV6_ADDR_SUBNET
The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values 🧚 The first value is an IPv6 address. The second is an IPv6 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit 💅
B Defining a new Domain of Interpretation 🌈
okay so the Internet DOI might be enough to meet the security requirements of a big chunk of the internet community 🫶 But some groups might want to customize some part of a DOI, maybe to add a different set of cryptographic algorithms, or because they want their security-relevant decisions based on something other than a host ID or user ID 🔥 A particular group might also need a new exchange type, for example to support key management for multicast groups 💖
This section talks about guidelines for defining a new DOI. The full specification for the Internet DOI can be found in [IPDOI] 🎀
Defining a new DOI is likely to be a time-consuming process 😭 If at all possible, it is recommended that the designer begin with an existing DOI and customize only the parts that are unacceptable ✨
If a designer chooses to start from scratch, the following MUST be defined 💅
- A "situation": the set of information that will be used to determine the required security services.
- The set of security policies that must be supported.
- A scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, etc.
- A syntax for the specification of proposed security services, attributes, and certificate authorities.
- The specific formats of the various payload contents.
- Additional exchange types, if required.
B.1 Situation
The situation is the basis for deciding how to protect a communications channel 🦋 It must contain all of the data that will be used to determine the types and strengths of protections applied in an SA. For example, a US Department of Defense DOI would probably use unpublished algorithms and have additional special attributes to negotiate 🧚 Those additional security attributes would be included in the situation.
B.2 Security Policies
Security policies define how various types of information must be categorized and protected 🌸 The DOI must define the set of security policies supported, because both parties in a negotiation must trust that the other party understands a situation and will protect information appropriately, both in transit and in storage 💜 In a corporate setting, for example, both parties in a negotiation must agree on the meaning of the term "proprietary information" before they can negotiate how to protect it 🙈
Note that including the required security policies in the DOI only specifies that the participating hosts understand and implement those policies in a full system context 🍓
B.3 Naming Schemes
Any DOI must define a consistent way to name cryptographic algorithms, certificate authorities, etc. 🫶 This can usually be done by using IANA naming conventions, perhaps with some private extensions ✨
B.4 Syntax for Specifying Security Services
In addition to simply specifying how to name entities, the DOI must also specify the format for complete proposals of how to protect traffic under a given situation 💅
B.5 Payload Specification
The DOI must specify the format of each payload type 🌈 For several of the payload types, ISAKMP has included fields that would have to be present across all DOIs (such as a certificate authority in the certificate payload, or a key exchange identifier in the key exchange payload) 🔥
B.6 Defining new Exchange Types
If the basic exchange types aren't good enough for a DOI's requirements, a designer can define up to thirteen extra exchange types per DOI 🦋 The designer creates a new exchange type by choosing an unused exchange type value and defining a sequence of messages made of strings of the ISAKMP payload types 👑
Any new exchange types must be rigorously analyzed for vulnerabilities 😭 Since this is an expensive and imprecise undertaking, a new exchange type should only be created when absolutely necessary 🙈
Security Considerations ✨
okay bestie, this section is SERIOUS but also kind of iconic 💅 so let's go. 🫶
Cryptographic analysis techniques keep getting better and better, no cap 🔥 and more processing power means attacks that used to be computationally prohibitive are starting to look way more realistic 💀. New cryptographic algorithms and public key generation techniques are also popping up at a steady pace 🌸. New security services and mechanisms are developing at an accelerated pace 🚀. So a consistent way to choose from all these services and mechanisms, and to exchange the attributes they need, is super important for security in the complex structure of the Internet 🧚. But like, a system that locks itself into one single cryptographic algorithm, key exchange technique, or security mechanism is going to get more and more vulnerable as time goes on 😭. Not me locking in one algorithm forever 🙈.
UDP is an unreliable datagram protocol, so using it in ISAKMP brings along a bunch of security considerations 🦋. Since UDP is unreliable but a key management protocol must be reliable, the reliability gets built into ISAKMP itself 💖. Even though ISAKMP uses UDP as its transport, it doesn't rely on any UDP information (like the checksum or length) for its processing ✨. Iykyk 💅.
Firewalls are another thing to think about when developing ISAKMP 🎀. Lots of firewalls filter out all UDP packets, so relying on UDP is kinda questionable in certain environments 🫠.
[SEC-ARCH] has a bunch of very important security considerations too 📚, and one of them is worth repeating 💜: once a private session key is created, it must be stored safely 🔐. If the private key isn't properly protected from access, both inside and outside the system, then any protection the IP Security services provide is completely nullified 😱💀. Literally the whole point, gone 💔.
IANA Considerations ✨
This document has a lot of "magic" numbers that IANA needs to maintain 🪄. This section explains the criteria IANA uses to assign additional numbers to each of these lists 🌈.
Domain of Interpretation 🦋
The Domain of Interpretation (DOI) is a 32-bit field that identifies the domain where the security association negotiation is happening 💫. If you want to request a brand new DOI, it must come with a standards-track RFC describing that specific domain 📜.
Supported Security Protocols 🎀
ISAKMP is designed to handle security association negotiation and key management for many security protocols 🌸. If you want identifiers for additional security protocols, they must be accompanied by a standards-track RFC that describes the security protocol and how it relates to ISAKMP 💅.
Acknowledgements 🫶
Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems gave design help with the protocol and coordinated the [IKE] and [IPDOI] documents 👑.
Hilarie Orman, through the Oakley key exchange protocol, has significantly influenced the design of ISAKMP 🧚.
Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor gave significant input and review to this document 💖.
Scott Carlson ported the TIS DNSSEC prototype to FreeBSD so it could be used with the ISAKMP prototype 🍓.
Jeff Turner and Steve Smalley helped with prototype development and integration with ESP and AH ✨.
Mike Oehler and Pete Sell ran interoperability testing with other ISAKMP implementors 🔥.
Thanks to Carl Muckenhirn of SPARTA, Inc. for his help with LaTeX 🌈.
References 📚
[ANSI] ANSI, X9.42: Public Key Cryptography for the Financial
Services Industry -- Establishment of Symmetric Algorithm
Keys Using Diffie-Hellman, Working Draft, April 19, 1996.
[BC] Ballardie, A., and J. Crowcroft, Multicast-specific
Security Threats and Countermeasures, Proceedings of 1995
ISOC Symposium on Networks & Distributed Systems Security,
pp. 17-30, Internet Society, San Diego, CA, February 1995.
[Berge] Berge, N., "UNINETT PCA Policy Statements", RFC 1875,
December 1995.
[CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial
and Military Computer Security Policies, Proceedings of
the IEEE Symposium on Security & Privacy, Oakland, CA,
1987, pp. 184-193.
[DNSSEC] D. Eastlake III, Domain Name System Protocol Security
Extensions, Work in Progress.
[DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and
Authenticated Key Exchanges, Designs, Codes, and
Cryptography, 2, 107-125, Kluwer Academic Publishers,
1992.
[IAB] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IPDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[Karn] Karn, P., and B. Simpson, Photuris: Session Key
Management Protocol, Work in Progress.
[Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August
10, 1994.
[Oakley] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998.
[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC
1422, February 1993.
[RFC-1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC
1949, May 1996.
[RFC-2093] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC-2094] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Schneier] Bruce Schneier, Applied Cryptography - Protocols,
Algorithms, and Source Code in C (Second Edition), John
Wiley & Sons, Inc., 1996.
[SEC-ARCH] Atkinson, R., and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.htmlAuthors' Addresses 🌸
Douglas Maughan
National Security Agency
ATTN: R23
9800 Savage Road
Ft. Meade, MD. 20755-6000
Phone: 301-688-0847
EMail:wdm@tycho.ncsc.mil
Mark Schneider
National Security Agency
ATTN: R23
9800 Savage Road
Ft. Meade, MD. 20755-6000
Phone: 301-688-0851
EMail:mss@tycho.ncsc.mil
Mark Schertler
Securify, Inc.
2415-B Charleston Road
Mountain View, CA 94043
Phone: 650-934-9303
EMail:mjs@securify.com
Jeff Turner
RABA Technologies, Inc.
10500 Little Patuxent Parkway
Columbia, MD. 21044
Phone: 410-715-9399
EMail:jeff.turner@raba.comFull Copyright Statement 🦋
Copyright (C) The Internet Society (1998). All Rights Reserved. 💜
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 📜
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ♾️
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀✨
📦 where this page comes from
- ietf: rfc2408 1998-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms