RFC 2407

The Internet IP Security Domain of Interpretation for ISAKMP

📅 published November 1998, from ietf

RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP 💖

Okay bestie, this one is the IPSEC DOI spec, and it's giving "how ISAKMP actually gets used for IP security" 🔐✨ Here's the title block so you know who's behind it:

RFC number: 2407 🎀
Group: Network Working Group
Authors: D. Piper, Network Alchemy 🧚
Category: Standards Track
Date: November 1998
Obsoletes / updates: the title block doesn't list anything this one obsoletes or updates 🦋

Status of this Memo

This is an Internet standards track protocol for the Internet community, and they're literally asking for discussion and suggestions for improvements 🫶 For where it stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright Notice

IESG Note

Okay, this note is important, so read it twice 🚨 Section 4.4.4.2 says, "All implememtations within the IPSEC DOI MUST support ESP_DES...". But recent cryptanalysis work suggests DES may not be strong enough for a lot of applications 💀 So it's very likely the IETF will deprecate ESP_DES as a mandatory cipher suite soon. It'll stick around as an optional use protocol 🥀

The IPsec working group and the IETF haven't picked a replacement algorithm yet (they're weighing security and performance) 🤔 Until they do, implementers may want to heed the recommendations in section 4.4.4.3 about ESP_3DES 🍓

1. Abstract ✨

The Internet Security Association and Key Management Protocol (ISAKMP) is the framework for security association management and cryptographic key establishment on the Internet 🔑 That framework is made of exchanges, payloads, and processing guidelines that all happen inside a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which plugs ISAKMP into IP whenever IP uses ISAKMP to negotiate security associations 💜

For a list of changes since the previous version of the IPSEC DOI, see Section 7 📝

2. Introduction 🦋

Okay so in ISAKMP, a Domain of Interpretation is how you group together protocols that use ISAKMP to negotiate security associations 👯‍♀️ Security protocols in the same DOI pick their security protocol and cryptographic transforms from one shared namespace, and they share key exchange protocol identifiers. They also agree on what DOI-specific payload data means, including the Security Association and Identification payloads 🫶

Overall, ISAKMP gives a DOI definition these requirements:

define the naming scheme for DOI-specific protocol identifiers
define the interpretation for the Situation field
define the set of applicable security policies
define the syntax for DOI-specific SA Attributes (Phase II)
define the syntax for DOI-specific payload contents
define additional Key Exchange types, if needed
define additional Notification Message types, if needed

The rest of this document goes through how the IPSEC DOI meets each of those, using the IP Security (IPSEC) protocols to provide authentication, integrity, and/or confidentiality for IP packets sent between cooperating host systems and/or firewalls 🔥

For the big-picture IPSEC architecture, check out [ARCH], [AH], and [ESP] 📚

3. Terms and Definitions 🎀

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] 📖

4.1 IPSEC Naming Scheme 🌸

Within ISAKMP, every DOI MUST be registered with IANA in the "Assigned Numbers" RFC [STD-2] 🗂️ The IANA Assigned Number for the Internet IP Security DOI (IPSEC DOI) is one (1). Inside the IPSEC DOI, all well-known identifiers MUST be registered with IANA under the IPSEC DOI. Unless noted otherwise, every table in this document refers to IANA Assigned Numbers for the IPSEC DOI. For more on the IANA registry for the IPSEC DOI, see Section 6 💅

All multi-octet binary values are stored in network byte order 🧠

4.2 IPSEC Situation Definition 💅

In ISAKMP, the Situation gives the responder info it can use to make a policy call about how to handle an incoming Security Association request 🧚 For the IPSEC DOI, the Situation field is a four (4) octet bitmask with the values below:

Situation                   Value
---------                   -----
SIT_IDENTITY_ONLY           0x01
SIT_SECRECY                 0x02
SIT_INTEGRITY               0x04

4.2.1 SIT_IDENTITY_ONLY ✨

SIT_IDENTITY_ONLY means the security association gets identified by source identity info sitting in an associated Identification Payload. For a full rundown of the Identification types, see Section 4.6.2 🪪 All IPSEC DOI implementations MUST support SIT_IDENTITY_ONLY by including an Identification Payload in at least one of the Phase I Oakley exchanges ([IKE], Section 5), and they MUST abort any association setup that doesn't include an Identification Payload 🚫

If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the situation is just the 4 octet situation bitmap. It doesn't include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) or any label info after it 🙈 But if the initiator supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain Identifier MUST be included in the situation payload 💜

4.2.2 SIT_SECRECY 🔒

SIT_SECRECY means the security association is being negotiated in an environment that needs labeled secrecy. If SIT_SECRECY is in the Situation bitmap, the Situation field gets followed by variable-length data with a sensitivity level and a compartment bitmask. For the full Security Association Payload format, see Section 4.6.1 🎀

If an initiator doesn't support SIT_SECRECY, SIT_SECRECY MUST NOT be set in the Situation bitmap, and no secrecy level or category bitmaps shall be included 🙅‍♀️

If a responder doesn't support SIT_SECRECY, a SITUATION-NOT-SUPPORTED Notification Payload SHOULD be returned, and the security association setup MUST be aborted 💀

4.2.3 SIT_INTEGRITY 🛡️

SIT_INTEGRITY means the security association is being negotiated in an environment that needs labeled integrity. If SIT_INTEGRITY is in the Situation bitmap, the Situation field gets followed by variable-length data with an integrity level and a compartment bitmask. If SIT_SECRECY is also in use for the association, the integrity info comes right after the variable-length secrecy level and categories 🧁 For the full Security Association Payload format, see section 4.6.1 🦋

If an initiator doesn't support SIT_INTEGRITY, SIT_INTEGRITY MUST NOT be set in the Situation bitmap, and no integrity level or category bitmaps shall be included 🚫

If a responder doesn't support SIT_INTEGRITY, a SITUATION-NOT-SUPPORTED Notification Payload SHOULD be returned, and the security association setup MUST be aborted 😭

4.3 IPSEC Security Policy Requirements 🌈

The IPSEC DOI doesn't put specific security policy requirements on any implementation. Host system policy issues are outside the scope of this document 🙌

That said, the sections below touch on some issues you'll need to think about when designing an IPSEC DOI host implementation. This section should be considered only informational in nature 🧠

4.3.1 Key Management Issues 🔑

A lot of systems that implement ISAKMP are going to try to give a combined IKE key management daemon a protected domain of execution. On protected-mode multiuser operating systems, that key management daemon will probably run as a separate privileged process 🛡️

In that kind of environment, a formalized API for getting keying material into the TCP/IP kernel may be desirable. The IP Security architecture doesn't place any requirements on the structure or flow between a host TCP/IP kernel and its key management provider 🫧

4.3.2 Static Keying Issues 🗝️

Host systems that implement static keys (either for direct use by IPSEC or for authentication purposes, see [IKE] Section 5.4) should take steps to protect that static keying material whenever it isn't in a protected memory domain or actively in use by the TCP/IP kernel 🔐

For example, on a laptop, you might store the static keys in a configuration store that's encrypted under a private password 💻

Depending on the operating system and utility software installed, it may not be possible to protect the static keys once they're loaded into the TCP/IP kernel. Even so, they should not be trivially recoverable on initial system startup without satisfying some additional form of authentication 👀

4.3.3 Host Policy Issues 📋

It's not realistic to assume the transition to IPSEC will happen overnight 🌙 Host systems must be prepared to run flexible policy lists that describe which systems they want to talk to securely and which systems they require to talk to them securely 💌 Some notion of proxy firewall addresses may also be required 🧱

A minimal approach is probably a static list of IP addresses, network masks, and a security required flag or flags 📃

A more flexible implementation might use a list of wildcard DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional firewall address. The wildcard DNS name is used to match incoming or outgoing IP addresses. The in/out bitmask decides whether security gets applied and in which direction. The optional firewall address indicates whether tunnel mode is needed to reach the target system through an intermediate firewall 🚇

4.3.4 Certificate Management 📜

Host systems that use a certificate-based authentication scheme will need a way to get and manage a database of certificates 🗃️

Secure DNS is supposed to be one certificate distribution mechanism, but honestly, widespread secure DNS zones in the short term are doubtful for a bunch of reasons 😬 What's way more likely is that hosts need to be able to import certificates they get through secure, out-of-band mechanisms, and export their own certificates for other systems to use 📨

Still, manual certificate management shouldn't be done in a way that blocks the ability to bring in dynamic certificate discovery mechanisms and/or protocols once they're available 🌟

4.4 IPSEC Assigned Numbers 🔢

The following sections list the Assigned Numbers for the IPSEC DOI: Situation Identifiers, Protocol Identifiers, Transform Identifiers, AH, ESP, and IPCOMP Transform Identifiers, Security Association Attribute Type Values, Labeled Domain Identifiers, ID Payload Type Values, and Notify Message Type Values 🎀

4.4.1 IPSEC Security Protocol Identifier

okay so ISAKMP's proposal syntax was literally built so you can negotiate several Phase II security protocol suites in ONE go ✨ that's main character energy 🦋 The protocol suites below are the ones that can get negotiated at the same time, and which ones get bundled is a host policy decision 💅

The table below lists the Security Protocol Identifier values used in an ISAKMP Proposal Payload for the IPSEC DOI 🎀

Protocol ID                         Value
-----------                         -----
RESERVED                            0
PROTO_ISAKMP                        1
PROTO_IPSEC_AH                      2
PROTO_IPSEC_ESP                     3
PROTO_IPCOMP                        4

4.4.1.1 PROTO_ISAKMP

PROTO_ISAKMP is all about protecting messages during Phase I of ISAKMP 🔒 The specific protection mechanism for the IPSEC DOI is described in [IKE]. Every implementation within the IPSEC DOI MUST support PROTO_ISAKMP 🫶

NB: ISAKMP reserves the value one (1) across all DOI definitions.

4.4.1.2 PROTO_IPSEC_AH

PROTO_IPSEC_AH is the one for IP packet authentication 🛡️ The default AH transform gives you data origin authentication, integrity protection, and replay detection. For export control considerations, confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform 💀 so don't even try it bestie.

4.4.1.3 PROTO_IPSEC_ESP

PROTO_IPSEC_ESP is the one for IP packet confidentiality 🔐 Authentication, if required, must be provided as part of the ESP transform. The default ESP transform includes data origin authentication, integrity protection, replay detection, and confidentiality, so it's the whole package ✨

4.4.1.4 PROTO_IPCOMP

PROTO_IPCOMP is for IP payload compression, as defined in [IPCOMP] 🗜️

4.4.2 IPSEC ISAKMP Transform Identifiers

okay so during ISAKMP Phase I negotiation, the initiator picks its Key Exchange offerings based on some host system policy description 🧠 The actual choice of Key Exchange mechanism happens through the standard ISAKMP Proposal Payload. Here are the defined ISAKMP Phase I Transform Identifiers for that Proposal Payload in the IPSEC DOI 💖

Transform                           Value
---------                           -----
RESERVED                            0
KEY_IKE                             1

Within the ISAKMP and IPSEC DOI framework, it's totally possible to define key establishment protocols other than IKE (Oakley) 🦋 Earlier versions of this document had types for manual keying and for schemes based on a generic Key Distribution Center (KDC), but those identifiers have been removed from the current document 🙈

The IPSEC DOI can still be extended later to include values for additional non-Oakley key establishment protocols for ISAKMP and IPSEC, like Kerberos [RFC-1510] or the Group Key Management Protocol (GKMP) [RFC-2093] 🌈

4.4.2.1 KEY_IKE

KEY_IKE is the hybrid ISAKMP/Oakley Diffie-Hellman key exchange (IKE) as defined in the [IKE] document 🔑 All implementations within the IPSEC DOI MUST support KEY_IKE, no exceptions 🫶

4.4.3 IPSEC AH Transform Identifiers

the Authentication Header Protocol (AH) has one mandatory transform and several optional ones, all for authentication, integrity, and replay detection 🛡️ Here's the table of defined AH Transform Identifiers for the ISAKMP Proposal Payload in the IPSEC DOI 🎀

Note: the Authentication Algorithm attribute MUST be specified to identify the appropriate AH protection suite. For example, AH_MD5 can best be thought of as a generic AH transform using MD5. To request the HMAC construction with AH, you specify the AH_MD5 transform ID along with the Authentication Algorithm attribute set to HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the following sections.

Transform ID                        Value
------------                        -----
RESERVED                            0-1
AH_MD5                              2
AH_SHA                              3
AH_DES                              4

Note: all mandatory-to-implement algorithms are listed as "MUST" implement (e.g. AH_MD5) in the following sections. All other algorithms are optional and MAY be implemented in any particular implementation.

4.4.3.1 AH_MD5

AH_MD5 is a generic AH transform using MD5 🧁 The actual protection suite gets figured out together with an associated SA attribute list. A generic MD5 transform is currently undefined, so don't go looking for it 🙃

All implementations within the IPSEC DOI MUST support AH_MD5 along with the Auth(HMAC-MD5) attribute. This suite is defined as the HMAC-MD5-96 transform described in [HMACMD5] 💜 AH_MD5 along with the Auth(KPDK) attribute specifies the AH transform (Key/Pad/Data/Key) described in RFC-1826.

Use of AH_MD5 with any other Authentication Algorithm attribute value is currently undefined 🚫

4.4.3.2 AH_SHA

AH_SHA is a generic AH transform using SHA-1 🌸 Again, the actual protection suite is determined together with an associated SA attribute list, and a generic SHA transform is currently undefined.

All implementations within the IPSEC DOI MUST support AH_SHA along with the Auth(HMAC-SHA) attribute. This suite is defined as the HMAC-SHA-1-96 transform described in [HMACSHA] ✨

Use of AH_SHA with any other Authentication Algorithm attribute value is currently undefined.

4.4.3.3 AH_DES

AH_DES is a generic AH transform using DES 🍓 The actual protection suite is determined together with an associated SA attribute list, and a generic DES transform is currently undefined.

The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute to be a DES-MAC transform. Implementations are not required to support this mode 🤷‍♀️

Use of AH_DES with any other Authentication Algorithm attribute value is currently undefined.

4.4.4 IPSEC ESP Transform Identifiers

the Encapsulating Security Payload (ESP) has one mandatory transform and a bunch of optional ones, all for data confidentiality 🔐 Here's the table of defined ESP Transform Identifiers for the ISAKMP Proposal Payload in the IPSEC DOI 🧚

Note: when authentication, integrity protection, and replay detection are required, the Authentication Algorithm attribute MUST be specified to identify the appropriate ESP protection suite. For example, to request HMAC-MD5 authentication with 3DES, you specify the ESP_3DES transform ID with the Authentication Algorithm attribute set to HMAC-MD5. For additional processing requirements, see Section 4.5 (Authentication Algorithm).

Transform ID                        Value
------------                        -----
RESERVED                            0
ESP_DES_IV64                        1
ESP_DES                             2
ESP_3DES                            3
ESP_RC5                             4
ESP_IDEA                            5
ESP_CAST                            6
ESP_BLOWFISH                        7
ESP_3IDEA                           8
ESP_DES_IV32                        9
ESP_RC4                             10
ESP_NULL                            11

Note: all mandatory-to-implement algorithms are listed as "MUST" implement (e.g. ESP_DES) in the following sections. All other algorithms are optional and MAY be implemented in any particular implementation.

4.4.4.1 ESP_DES_IV64

ESP_DES_IV64 specifies the DES-CBC transform defined in RFC-1827 and RFC-1829, using a 64-bit IV 🎀

4.4.4.2 ESP_DES

ESP_DES is a generic DES transform using DES-CBC 💅 The actual protection suite is determined together with an associated SA attribute list, and a generic transform is currently undefined.

All implementations within the IPSEC DOI MUST support ESP_DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [DES] transform, with authentication and integrity provided by HMAC MD5 [HMACMD5] 🫶

4.4.4.3 ESP_3DES

ESP_3DES is a generic triple-DES transform 🍓 The actual protection suite is determined together with an associated SA attribute list, and the generic transform is currently undefined.

All implementations within the IPSEC DOI are strongly encouraged to support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [ESPCBC] transform, with authentication and integrity provided by HMAC MD5 [HMACMD5] ✨

4.4.4.4 ESP_RC5

ESP_RC5 specifies the RC5 transform defined in [ESPCBC] 🌈

4.4.4.5 ESP_IDEA

ESP_IDEA specifies the IDEA transform defined in [ESPCBC] 🦋

4.4.4.6 ESP_CAST

ESP_CAST specifies the CAST transform defined in [ESPCBC] 💜

4.4.4.7 ESP_BLOWFISH

ESP_BLOWFISH specifies the BLOWFISH transform defined in [ESPCBC] 🐡

4.4.4.8 ESP_3IDEA

ESP_3IDEA is reserved for triple-IDEA 🔒

4.4.4.9 ESP_DES_IV32

ESP_DES_IV32 specifies the DES-CBC transform defined in RFC-1827 and RFC-1829, using a 32-bit IV 🎀

4.4.4.10 ESP_RC4

ESP_RC4 is reserved for RC4 🙈

4.4.4.11 ESP_NULL

ESP_NULL means no confidentiality is to be provided by ESP 🙃 It gets used when ESP is tunneling packets that only need authentication, integrity protection, and replay detection.

All implementations within the IPSEC DOI MUST support ESP_NULL. The ESP NULL transform is defined in [ESPNULL]. See the Authentication Algorithm attribute description in Section 4.5 for additional requirements relating to the use of ESP_NULL 🫶

4.4.5 IPSEC IPCOMP Transform Identifiers

the IP Compression (IPCOMP) transforms are optional compression algorithms that can be negotiated for IP payload compression ([IPCOMP]) 🗜️ Here's the table of defined IPCOMP Transform Identifiers for the ISAKMP Proposal Payload in the IPSEC DOI 🌸

Transform ID                        Value
------------                        -----
RESERVED                            0
IPCOMP_OUI                          1
IPCOMP_DEFLATE                      2
IPCOMP_LZS                          3

4.4.5.1 IPCOMP_OUI

IPCOMP_OUI is a proprietary compression transform 🔥 It must be accompanied by an attribute that further identifies the specific vendor algorithm.

4.4.5.2 IPCOMP_DEFLATE

IPCOMP_DEFLATE means using the "zlib" deflate algorithm as specified in [DEFLATE] 🧊

4.4.5.3 IPCOMP_LZS

IPCOMP_LZS means using the Stac Electronics LZS algorithm as specified in [LZS] 💫

4.5 IPSEC Security Association Attributes ✨

okay so these SA attribute definitions are used in Phase II of an IKE negotiation 💖 Each attribute type is either Basic (B) or Variable-Length (V), and the encoding of these is defined in the base ISAKMP spec 🎀

Basic attributes MUST NOT be encoded as variable 🙅 but variable length attributes MAY be encoded as basic attributes if their value can fit into two octets 🦋 For more on attribute encoding in the IPSEC DOI, check [IKE]. Every restriction listed in [IKE] applies to the IPSEC DOI too, no cap 💅

    Attribute Types

          class               value           type
    -------------------------------------------------
    SA Life Type                1               B
    SA Life Duration            2               V
    Group Description           3               B
    Encapsulation Mode          4               B
    Authentication Algorithm    5               B
    Key Length                  6               B
    Key Rounds                  7               B
    Compress Dictionary Size    8               B
    Compress Private Algorithm  9               V

Class Values

SA Life Type / SA Duration

This is the time-to-live for the whole security association ⏰ When the SA expires, every key negotiated under it (AH or ESP) must be renegotiated 😭 The life type values are:

RESERVED                0
seconds                 1
kilobytes               2

Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use 🔒 For a given Life Type, the Life Duration attribute gives the actual length of the component lifetime, either a number of seconds or a number of Kbytes that can be protected.

If unspecified, the default value shall be assumed to be 28800 seconds (8 hours) ⌛

An SA Life Duration attribute MUST always follow an SA Life Type which describes the units of duration 📏

See Section 4.5.4 for additional information relating to lifetime notification 🔔

Group Description

This specifies the Oakley Group to be used in a PFS QM negotiation 🔐 For a list of supported values, see Appendix A of [IKE] 📚

Encapsulation Mode

RESERVED                0
Tunnel                  1
Transport               2

Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use 🔒

If unspecified, the default value shall be assumed to be unspecified (host-dependent) 🤷‍♀️

Authentication Algorithm

RESERVED                0
HMAC-MD5                1
HMAC-SHA                2
DES-MAC                 3
KPDK                    4

Values 5-61439 are reserved to IANA. Values 61440-65535 are for private use 🔒

There is no default value for Auth Algorithm, because it must be specified to correctly identify the applicable AH or ESP transform 🧩 The one exception is below.

When negotiating ESP without authentication, the Auth Algorithm attribute MUST NOT be included in the proposal 🚫

When negotiating ESP without confidentiality, the Auth Algorithm attribute MUST be included in the proposal, and the ESP transform ID must be ESP_NULL 💜

Key Length

RESERVED                0

There is no default value for Key Length, because it must be specified for transforms using ciphers with variable key lengths 🗝️ For fixed length ciphers, the Key Length attribute MUST NOT be sent 🙈

Key Rounds

RESERVED                0

There is no default value for Key Rounds, because it must be specified for transforms using ciphers with varying numbers of rounds 🌀

Compression Dictionary Size

RESERVED                0

This specifies the log2 maximum size of the dictionary 📖

There is no default value for dictionary size.

Compression Private Algorithm

This specifies a private vendor compression algorithm 🧃 The first three (3) octets must be an IEEE assigned company_id (OUI). The next octet may be a vendor specific compression subtype, followed by zero or more octets of vendor data 🌈

4.5.1 Required Attribute Support

To ensure basic interoperability, all implementations MUST be prepared to negotiate all of the following attributes 🫶

SA Life Type
SA Duration
Auth Algorithm

4.5.2 Attribute Parsing Requirement (Lifetime)

To allow for flexible semantics, the IPSEC DOI requires that a conforming ISAKMP implementation MUST correctly parse an attribute list that contains multiple instances of the same attribute class, so long as the different attribute entries do not conflict with one another ✨ Right now, the only attributes that need this treatment are Life Type and Duration 🕰️

To see why this matters, here's the binary encoding of a four entry attribute list that specifies an SA Lifetime of either 100MB or 24 hours 🤯 (See Section 3.3 of [ISAKMP] for a complete description of the attribute encoding format 📚)

  Attribute #1:
    0x80010001  (AF = 1, type = SA Life Type, value = seconds)

  Attribute #2:
    0x00020004  (AF = 0, type = SA Duration, length = 4 bytes)
    0x00015180  (value = 0x15180 = 86400 seconds = 24 hours)

  Attribute #3:
    0x80010002  (AF = 1, type = SA Life Type, value = KB)

  Attribute #4:
    0x00020004  (AF = 0, type = SA Duration, length = 4 bytes)
    0x000186A0  (value = 0x186A0 = 100000KB = 100MB)

If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED Notification Payload SHOULD be returned, and the security association setup MUST be aborted 🚨

4.5.3 Attribute Negotiation

If an implementation receives a defined IPSEC DOI attribute (or attribute value) that it doesn't support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent, and the security association setup MUST be aborted 🙅‍♀️ The exception is when the attribute value is in the reserved range 🧐

If an implementation receives an attribute value in the reserved range, it MAY choose to continue based on local policy 🎲

4.5.4 Lifetime Notification

When an initiator offers an SA lifetime greater than what the responder wants based on their local policy, the responder has three choices 🤔

Fail the negotiation entirely.
Complete the negotiation but use a shorter lifetime than what was offered.
Complete the negotiation and send an advisory notification to the initiator, indicating the responder's true lifetime.

What the responder actually does is implementation specific and/or based on local policy 🎀

To ensure interoperability in the latter case, the IPSEC DOI requires the following, but only when the responder wants to notify the initiator 📣 If the initiator offers an SA lifetime longer than the responder is willing to accept, the responder SHOULD include an ISAKMP Notification Payload in the exchange that includes the responder's IPSEC SA payload 💌 Section 4.6.3.1 defines the payload layout for the RESPONDER-LIFETIME Notification Message type, which MUST be used for this purpose 🦋

4.6 IPSEC Payload Content 🌸

The following sections describe those ISAKMP payloads whose data representations are dependent on the applicable DOI 💜

4.6.1 Security Association Payload ✨

okay bestie, the Security Association Payload is where the whole "here's the security I want" menu lives 💅 this diagram shows it for the IPSEC DOI, and you'll want Section 4.2 for the Situation bitmap 🦋

 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 (IPSEC)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       Situation (bitmap)                      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                    Labeled Domain Identifier                  !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Secrecy Length (in octets)   !           RESERVED            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        Secrecy Level                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Cat. Length (in bits) !           RESERVED            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Secrecy Category Bitmap                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integrity Length (in octets)  !           RESERVED            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                       Integrity Level                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integ. Cat. Length (in bits)  !           RESERVED            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                  Integrity Category Bitmap                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Security Association Payload Format

Here's the breakdown of the Security Association Payload 🎀

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 zero (0).
RESERVED (1 octet) - unused, must be zero (0).
Payload Length (2 octets) - length, in octets, of the current payload, including the generic header.
Domain of Interpretation (4 octets) - specifies the IPSEC DOI, which has been assigned the value one (1).
Situation (4 octets) - bitmask used to interpret the remainder of the Security Association Payload. See Section 4.2 for a complete list of values.
Labeled Domain Identifier (4 octets) - IANA Assigned Number used to interpret the Secrecy and Integrity information.
Secrecy Length (2 octets) - specifies the length, in octets, of the secrecy level identifier, excluding pad bits.
RESERVED (2 octets) - unused, must be zero (0).
Secrecy Level (variable length) - specifies the mandatory secrecy level required. The secrecy level MUST be padded with zero (0) to align on the next 32-bit boundary.
Secrecy Category Length (2 octets) - specifies the length, in bits, of the secrecy category (compartment) bitmap, excluding pad bits.
RESERVED (2 octets) - unused, must be zero (0).
Secrecy Category Bitmap (variable length) - a bitmap used to designate secrecy categories (compartments) that are required. The bitmap MUST be padded with zero (0) to align on the next 32-bit boundary.
Integrity Length (2 octets) - specifies the length, in octets, of the integrity level identifier, excluding pad bits.
RESERVED (2 octets) - unused, must be zero (0).
Integrity Level (variable length) - specifies the mandatory integrity level required. The integrity level MUST be padded with zero (0) to align on the next 32-bit boundary.
Integrity Category Length (2 octets) - specifies the length, in bits, of the integrity category (compartment) bitmap, excluding pad bits.
RESERVED (2 octets) - unused, must be zero (0).
Integrity Category Bitmap (variable length) - a bitmap used to designate integrity categories (compartments) that are required. The bitmap MUST be padded with zero (0) to align on the next 32-bit boundary.

4.6.1.1 IPSEC Labeled Domain Identifiers 🌸

okay so this table lists the assigned values for the Labeled Domain Identifier field in the Situation field of the SA Payload 🧚

Domain                              Value
-------                             -----
RESERVED                            0

4.6.2 Identification Payload Content 🦋

the Identification Payload is how the initiator says "hi, it's me" 🫶 it's used to identify the initiator of the Security Association. the identity of the initiator SHOULD be used by the responder to pick the right host system security policy for the association. like, a host might decide to require authentication and integrity without confidentiality (AH) from one set of IP addresses, and full authentication with confidentiality (ESP) from a different range. the Identification Payload gives the responder the info it needs to make that call 👑

during Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500. if an implementation receives any other values, this MUST be treated as an error and the security association setup MUST be aborted. this event SHOULD be auditable 😭 bestie, that's a hard no on anything else 💀

here's the diagram for the Identification Payload 🌈

 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     !  Protocol ID  !             Port              !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                     Identification Data                       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Identification Payload Format

the Identification Payload fields are defined 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 zero (0).
RESERVED (1 octet) - unused, must be zero (0).
Payload Length (2 octets) - length, in octets, of the identification data, including the generic header.
Identification Type (1 octet) - value describing the identity information found in the Identification Data field.
Protocol ID (1 octet) - value specifying an associated IP protocol ID (e.g. UDP/TCP). A value of zero means that the Protocol ID field should be ignored.
Port (2 octets) - value specifying an associated port. A value of zero means that the Port field should be ignored.
Identification Data (variable length) - value, as indicated by the Identification Type.

4.6.2.1 Identification Type Values 💜

this table lists the assigned values for the Identification Type field in the Identification Payload 💅

ID Type                   Value
-------                   -----
RESERVED                            0
ID_IPV4_ADDR                        1
ID_FQDN                             2
ID_USER_FQDN                        3
ID_IPV4_ADDR_SUBNET                 4
ID_IPV6_ADDR                        5
ID_IPV6_ADDR_SUBNET                 6
ID_IPV4_ADDR_RANGE                  7
ID_IPV6_ADDR_RANGE                  8
ID_DER_ASN1_DN                      9
ID_DER_ASN1_GN                      10
ID_KEY_ID                           11

for types where the ID entity is variable length, the size of the ID entity is computed from size in the ID payload header ✨

when an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange. main character energy, the cert is the source of truth 👑

4.6.2.2 ID_IPV4_ADDR 🌸

the ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address 🦋

4.6.2.3 ID_FQDN 🧚

the ID_FQDN type specifies a fully-qualified domain name string. an example of an ID_FQDN is, "foo.bar.com". the string should not contain any terminators 🫶

4.6.2.4 ID_USER_FQDN 🎀

the ID_USER_FQDN type specifies a fully-qualified username string, An example of a ID_USER_FQDN is, "piper@foo.bar.com". the string should not contain any terminators 💖

4.6.2.5 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 and the second is an IPv4 network mask. ngl this one's a little tricky: ones (1s) in the network mask mean that the corresponding bit in the address is fixed, while zeros (0s) are a "wildcard" bit 🙈

4.6.2.6 ID_IPV6_ADDR 🍓

the ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address 💜

4.6.2.7 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 and the second is an IPv6 network mask. same rule as the IPv4 one: ones (1s) in the network mask mean the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit ✨

4.6.2.8 ID_IPV4_ADDR_RANGE 🦋

the ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, represented by two four (4) octet values. the first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). all addresses falling between the two specified addresses are considered to be within the list 🌸

4.6.2.9 ID_IPV6_ADDR_RANGE 🧚

the ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. the first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). all addresses falling between the two specified addresses are considered to be within the list 💅

4.6.2.10 ID_DER_ASN1_DN 🫶

the ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501] of the principal whose certificates are being exchanged to establish the SA 🎀

4.6.2.11 ID_DER_ASN1_GN 💖

the ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 X.500 GeneralName [X.509] of the principal whose certificates are being exchanged to establish the SA 🌈

4.6.2.12 ID_KEY_ID 🍓

the ID_KEY_ID type specifies an opaque byte stream which may be used to pass vendor-specific information necessary to identify which pre-shared key should be used to authenticate Aggressive mode negotiations. the vibe here is "tell me which key to use, no details needed" 🔐💜

4.6.3 IPSEC Notify Message Types ✨

okay so ISAKMP has two big buckets of Notify codes, one for errors and one for status stuff 💅. It also saves a chunk of each bucket for private use inside a DOI, and the IPSEC DOI grabs a few of those private slots for its own message types 🎀. Here they are:

Notify Messages - Error Types       Value
-----------------------------       -----
RESERVED                            8192

Notify Messages - Status Types      Value
------------------------------      -----
RESPONDER-LIFETIME                  24576
REPLAY-STATUS                       24577
INITIAL-CONTACT                     24578

bestie, Notification Status Messages MUST be sent under the protection of an ISAKMP SA 🔒. You can do that as a payload in the last Main Mode exchange, in a separate Informational Exchange after Main Mode or Aggressive Mode is done, or as a payload in any Quick Mode exchange. But they MUST NOT go out in an Aggressive Mode exchange 🙅‍♀️, because Aggressive Mode doesn't give the protection needed to bind the Notify Status Message to the exchange.

Nota Bene (heads up!!) 🚨: a Notify payload is only fully protected in Quick Mode, where the entire payload gets included in the HASH(n) digest. In Main Mode the notify payload is encrypted, but it isn't currently included in the HASH(n) digests. That means an active substitution attack on the Main Mode ciphertext could corrupt the notify status message type. (This is true, in general, for the last message of any Main Mode exchange.) The risk is small, but a corrupt notify message might make the receiver abort the whole negotiation, thinking the sender hit a fatal error 😭.

Implementation Note 🛠️: the ISAKMP protocol does not guarantee delivery of Notification Status messages when they're sent in an ISAKMP Informational Exchange. So to make sure a particular message actually arrives, the sender SHOULD include a Notification Payload in a defined Main Mode or Quick Mode exchange that's protected by a retransmission timer.

4.6.3.1 RESPONDER-LIFETIME 🧚

The RESPONDER-LIFETIME status message may be used to communicate the IPSEC SA lifetime chosen by the responder.

When it's present, the Notification Payload MUST have the following format:

Payload Length - set to length of payload + size of data (var)
DOI - set to IPSEC DOI (1)
Protocol ID - set to selected Protocol ID from chosen SA
SPI Size - set to either sixteen (16) (two eight-octet ISAKMP cookies) or four (4) (one IPSEC SPI)
Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3)
SPI - set to the two ISAKMP cookies or to the sender's inbound IPSEC SPI
Notification Data - contains an ISAKMP attribute list with the responder's actual SA lifetime(s)

Implementation Note 🛠️: saying that the Notification Data field contains an attribute list is the same as saying that the Notification Data field has zero length and the Notification Payload has an associated attribute list.

4.6.3.2 REPLAY-STATUS 🦋

The REPLAY-STATUS status message may be used for positive confirmation of the responder's election on whether or not he is to perform anti-replay detection.

When it's present, the Notification Payload MUST have the following format:

Payload Length - set to length of payload + size of data (4)
DOI - set to IPSEC DOI (1)
Protocol ID - set to selected Protocol ID from chosen SA
SPI Size - set to either sixteen (16) (two eight-octet ISAKMP cookies) or four (4) (one IPSEC SPI)
Notify Message Type - set to REPLAY-STATUS
SPI - set to the two ISAKMP cookies or to the sender's inbound IPSEC SPI
Notification Data - a 4 octet value:

0 = replay detection disabled
1 = replay detection enabled

4.6.3.3 INITIAL-CONTACT 🌸

The INITIAL-CONTACT status message may be used when one side wants to tell the other that this is the first SA being established with the remote system. The receiver of this Notification Message might then choose to delete any existing SA's it has for the sending system, on the assumption that the sending system has rebooted and no longer has access to the original SA's and their associated keying material. When it's used, the content of the Notification Data field SHOULD be null (i.e. the Payload Length should be set to the fixed length of Notification Payload).

When it's present, the Notification Payload MUST have the following format:

Payload Length - set to length of payload + size of data (0)
DOI - set to IPSEC DOI (1)
Protocol ID - set to selected Protocol ID from chosen SA
SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies)
Notify Message Type - set to INITIAL-CONTACT
SPI - set to the two ISAKMP cookies
Notification Data - <not included>

4.7 IPSEC Key Exchange Requirements 🔑

The IPSEC DOI introduces no additional Key Exchange types.

5. Security Considerations 🔐

This entire memo pertains to the Internet Key Exchange protocol ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to provide for the derivation of cryptographic keying material in a secure and authenticated manner. Specific discussion of the various security protocols and transforms identified in this document can be found in the associated base documents and in the cipher references.

6. IANA Considerations 🦋

This document contains many "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. All values not explicitly defined in previous sections are reserved to IANA.

6.1 IPSEC Situation Definition

The Situation Definition is a 32-bit bitmask which represents the environment under which the IPSEC SA proposal and negotiation is carried out. Requests for assignments of new situations must be accompanied by an RFC which describes the interpretation for the associated bit.

If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.

The upper two bits are reserved for private use amongst cooperating systems.

6.2 IPSEC Security Protocol Identifiers

The Security Protocol Identifier is an 8-bit value which identifies a security protocol suite being negotiated. Requests for assignments of new security protocol identifiers must be accompanied by an RFC which describes the requested security protocol. [AH] and [ESP] are examples of security protocol documents.

The values 249-255 are reserved for private use amongst cooperating systems.

6.3 IPSEC ISAKMP Transform Identifiers

The IPSEC ISAKMP Transform Identifier is an 8-bit value which identifies a key exchange protocol to be used for the negotiation. Requests for assignments of new ISAKMP transform identifiers must be accompanied by an RFC which describes the requested key exchange protocol. [IKE] is an example of one such document.

The values 249-255 are reserved for private use amongst cooperating systems.

6.4 IPSEC AH Transform Identifiers

The IPSEC AH Transform Identifier is an 8-bit value which identifies a particular algorithm to be used to provide integrity protection for AH. Requests for assignments of new AH transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the AH framework ([AH]).

The values 249-255 are reserved for private use amongst cooperating systems.

6.5 IPSEC ESP Transform Identifiers

The IPSEC ESP Transform Identifier is an 8-bit value which identifies a particular algorithm to be used to provide secrecy protection for ESP. Requests for assignments of new ESP transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the ESP framework ([ESP]).

The values 249-255 are reserved for private use amongst cooperating systems.

6.6 IPSEC IPCOMP Transform Identifiers

The IPSEC IPCOMP Transform Identifier is an 8-bit value which identifier a particular algorithm to be used to provide IP-level compression before ESP. Requests for assignments of new IPCOMP transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the IPCOMP framework ([IPCOMP]). In addition, the requested algorithm must be published and in the public domain.

The values 1-47 are reserved for algorithms for which an RFC has been approved for publication. The values 48-63 are reserved for private use amongst cooperating systems. The values 64-255 are reserved for future expansion.

6.7 IPSEC Security Association Attributes

The IPSEC Security Association Attribute consists of a 16-bit type and its associated value. IPSEC SA attributes are used to pass miscellaneous values between ISAKMP peers. Requests for assignments of new IPSEC SA attributes must be accompanied by an Internet Draft which describes the attribute encoding (Basic/Variable-Length) and its legal values. Section 4.5 of this document provides an example of such a description.

The values 32001-32767 are reserved for private use amongst cooperating systems.

6.8 IPSEC Labeled Domain Identifiers

The IPSEC Labeled Domain Identifier is a 32-bit value which identifies a namespace in which the Secrecy and Integrity levels and categories values are said to exist. Requests for assignments of new IPSEC Labeled Domain Identifiers should be granted on demand. No accompanying documentation is required, though Internet Drafts are encouraged when appropriate.

The values 0x80000000-0xffffffff are reserved for private use amongst cooperating systems.

6.9 IPSEC Identification Type

The IPSEC Identification Type is an 8-bit value which is used as a discriminant for interpretation of the variable-length Identification Payload. Requests for assignments of new IPSEC Identification Types must be accompanied by an RFC which describes how to use the identification type within IPSEC.

The values 249-255 are reserved for private use amongst cooperating systems.

6.10. IPSEC Notify Message Types 🔔

okay so the IPSEC Notify Message Type is a 16-bit value grabbed from the range ISAKMP reserves for each DOI 💅 there's one range for error messages (8192-16383) and a different range for status messages (24576-32767). if you wanna request a brand new Notify Message Type, it must be accompanied by an Internet Draft that describes how to use the identification type within IPSEC 📝

the values 16001-16383 and the values 32001-32767 are reserved for private use amongst cooperating systems 🔒 like, your own little friend group of machines, no outsiders allowed 🫶

7. Change Log 📜

7.1. Changes from V9

add explicit reference to [IPCOMP], [DEFLATE], and [LZS] 🎀
allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed at an IPSEC SPI in addition to the ISAKMP "SPI" ✨
added padding exclusion to Secrecy and Integrity Length text
added forward reference to Section 4.5 in Section 4.4.4
update document references

7.2. Changes from V8

update IPCOMP identifier range to better reflect IPCOMP draft 🦋
update IANA considerations per Jeff/Ted's suggested text
eliminate references to DES-MAC ID ([DESMAC])
correct bug in Notify section; ISAKMP Notify values are 16-bits 💀

7.3. Changes from V7

corrected name of IPCOMP (IP Payload Compression) 💅
corrected references to [ESPCBC]
added missing Secrecy Level and Integrity Level to Figure 1
removed ID references to PF_KEY and ARCFOUR
updated Basic/Variable text to align with [IKE]
updated document references and add intro pointer to [ARCH]
updated Notification requirements; remove aggressive reference
added clarification about protection for Notify payloads 🔐
restored RESERVED to ESP transform ID namespace; moved ESP_NULL
added requirement for ESP_NULL support and [ESPNULL] reference
added clarification on Auth Alg use with AH/ESP
added restriction against using conflicting AH/Auth combinations

7.4. Changes from V6

The following changes were made compared to the IPSEC DOI V6 🌸

added IANA Considerations section
moved most IANA numbers to IANA Considerations section
added prohibition on sending (V) encoding for (B) attributes
added prohibition on sending Key Length attribute for fixed length ciphers (e.g. DES)
replaced references to ISAKMP/Oakley with IKE
renamed ESP_ARCFOUR to ESP_RC4
updated Security Considerations section
updated document references

7.5. Changes from V5

The following changes were made compared to the IPSEC DOI V5 🌈

changed SPI size in Lifetime Notification text
changed REPLAY-ENABLED to REPLAY-STATUS
moved RESPONDER-LIFETIME payload definition from Section 4.5.4 to Section 4.6.3.1
added explicit payload layout for 4.6.3.3
added Implementation Note to Section 4.6.3 introduction
changed AH_SHA text to require SHA-1 in addition to MD5
updated document references

7.6. Changes from V4

The following changes were made compared to the IPSEC DOI V4 🧚

moved compatibility AH KPDK authentication method from AH transform ID to Authentication Algorithm identifier
added REPLAY-ENABLED notification message type per Architecture
added INITIAL-CONTACT notification message type per list
added text to ensure protection for Notify Status messages
added Lifetime qualification to attribute parsing section
added clarification that Lifetime notification is optional
removed private Group Description list (now points at [IKE])
replaced Terminology with pointer to RFC-2119
updated HMAC MD5 and SHA-1 ID references
updated Section 1 (Abstract)
updated Section 4.4 (IPSEC Assigned Numbers)
added restriction for ID port/protocol values for Phase I

7.7. Changes from V3 to V4

The following changes were made compared to the IPSEC DOI V3, which was posted to the IPSEC mailing list prior to the Munich IETF 🍓

added ESP transform identifiers for NULL and ARCFOUR
renamed HMAC Algorithm to Auth Algorithm to accommodate DES-MAC and optional authentication/integrity for ESP
added AH and ESP DES-MAC algorithm identifiers
removed KEY_MANUAL and KEY_KDC identifier definitions
added lifetime duration MUST follow lifetype attribute to SA Life Type and SA Life Duration attribute definition
added lifetime notification and IPSEC DOI message type table
added optional authentication and confidentiality restrictions to MAC Algorithm attribute definition
corrected attribute parsing example (used obsolete attribute)
corrected several Internet Draft document references
added ID_KEY_ID per ipsec list discussion (18-Mar-97)
removed Group Description default for PFS QM ([IKE] MUST)

Acknowledgments 🫶

This document is derived, in part, from previous works by Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran Atkinson also contributed suggestions and, in many cases, text 💜 the main character cast, honestly.

References 📚

[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[ARCH] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, August 1998.
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESPCBC] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[DES] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP and AH", RFC 2403, November 1998.
[HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IPCOMP] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[LZS] Friend, R., and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, August 1998.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[X.501] ISO/IEC 9594-2, "Information Technology - Open Systems Interconnection - The Directory: Models", CCITT/ITU Recommendation X.501, 1993.
[X.509] ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993.

Author's Address 🎀

Derrell Piper Network Alchemy 1521.5 Pacific Ave Santa Cruz, California, 95060 United States of America

Phone: +1 408 460-3822 EMail: ddp@network-alchemy.com

Full Copyright Statement ⚖️

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: rfc2407 1998-11
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms