RFC 4945
The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
RFC 4945 🎀 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
okay bestie, this one is from August 2007 and it's written by B. Korver of Network Resonance, Inc. It's filed under the Network Working Group as a Standards Track document, which means it's an actual standard, not just an idea floating around 🫶 It doesn't obsolete or update any other RFCs, since its header has no Obsoletes or Updates lines. Main character energy for sure ✨
Contents are below, copied exactly as the original lays them out:
1. Introduction ....................................................4
2. Terms and Definitions ...........................................4
3. Use of Certificates in RFC 2401 and IKEv1/ISAKMP ................5
3.1. Identification Payload .....................................5
3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR .......................7
3.1.2. ID_FQDN .............................................9
3.1.3. ID_USER_FQDN .......................................10
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET,
ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE .............11
3.1.5. ID_DER_ASN1_DN .....................................11
3.1.6. ID_DER_ASN1_GN .....................................12
3.1.7. ID_KEY_ID ..........................................12
3.1.8. Selecting an Identity from a Certificate ...........12
3.1.9. Subject for DN Only ................................12
3.1.10. Binding Identity to Policy ........................13
3.2. Certificate Request Payload ...............................13
3.2.1. Certificate Type ...................................14
3.2.2. X.509 Certificate - Signature ......................14
3.2.3. Revocation Lists (CRL and ARL) .....................14
3.2.4. PKCS #7 wrapped X.509 certificate ..................15
3.2.5. Location of Certificate Request Payloads ...........15
3.2.6. Presence or Absence of Certificate Request
Payloads ...........................................15
3.2.7. Certificate Requests ...............................15
3.2.8. Robustness .........................................18
3.2.9. Optimizations ......................................18
3.3. Certificate Payload .......................................19
3.3.1. Certificate Type ...................................20
3.3.2. X.509 Certificate - Signature ......................20
3.3.3. Revocation Lists (CRL and ARL) .....................20
3.3.4. PKCS #7 Wrapped X.509 Certificate ..................20
3.3.5. Location of Certificate Payloads ...................21
3.3.6. Certificate Payloads Not Mandatory .................21
3.3.7. Response to Multiple Certification
Authority Proposals ................................21
3.3.8. Using Local Keying Materials .......................21
3.3.9. Multiple End-Entity Certificates ...................22
3.3.10. Robustness ........................................22
3.3.11. Optimizations .....................................23
4. Use of Certificates in RFC 4301 and IKEv2 ......................24
4.1. Identification Payload ....................................24
4.2. Certificate Request Payload ...............................24
4.2.1. Revocation Lists (CRL and ARL) .....................24
4.3. Certificate Payload .......................................25
4.3.1. IKEv2's Hash and URL of X.509 Certificate ..........25
4.3.2. Location of Certificate Payloads ...................25
4.3.3. Ordering of Certificate Payloads ...................25
5. Certificate Profile for IKEv1/ISAKMP and IKEv2 .................26
5.1. X.509 Certificates ........................................26
5.1.1. Versions ...........................................26
5.1.2. Subject ............................................26
5.1.3. X.509 Certificate Extensions .......................27
5.2. X.509 Certificate Revocation Lists ........................33
5.2.1. Multiple Sources of Certificate Revocation
Information ........................................34
5.2.2. X.509 Certificate Revocation List Extensions .......34
5.3. Strength of Signature Hashing Algorithms ..................35
6. Configuration Data Exchange Conventions ........................36
6.1. Certificates ..............................................36
6.2. CRLs and ARLs .............................................37
6.3. Public Keys ...............................................37
6.4. PKCS#10 Certificate Signing Requests ......................37
7. Security Considerations ........................................37
7.1. Certificate Request Payload ...............................37
7.2. IKEv1 Main Mode ...........................................37
7.3. Disabling Certificate Checks ..............................38
8. Acknowledgements ...............................................38
9. References .....................................................38
9.1. Normative References ......................................38
9.2. Informative References ....................................39
Appendix A. The Possible Dangers of Delta CRLs ....................40
Appendix B. More on Empty CERTREQs ................................40Status of This Memo 📜
This is an Internet standards track protocol for the Internet community, and the authors are asking for discussion and suggestions for improvements 💖 If you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 🦋
Copyright Notice 💜
Copyright (C) The IETF Trust (2007).
Abstract 🌸
okay so the Internet Key Exchange (IKE) and the PKIX certificate profile for X.509 both give you frameworks, but each one needs a profile before you can actually use it for a specific job 🧚 This document is that profile for IKE and PKIX, and it spells out the requirements for using PKI tech in the IKE/IPsec world. IKEv1 and IKEv2 assume you already have public key certificates and related keying materials, but they never really talk about the PKI stuff head-on. This document does, and it's written for people implementing PKI for IPsec. Literally the missing piece 😭
1. Introduction ✨
IKE [1], ISAKMP [2], and IKEv2 [3] give you a secure key exchange mechanism for use with IPsec [4] [14]. A lot of the time the peers authenticate with digital certificates as specified in PKIX [5]. The catch is that when you smoosh all these standards together, the rules for using certificates in an IPsec context end up underspecified, which is not it 💀
ISAKMP points at the PKIX certificate profile, but in lots of cases it just lists what goes in various messages without saying how they're encoded or what they mean. Meanwhile PKIX has a huge pile of certificate mechanisms that work for Internet protocols in general, with very little guidance for IPsec specifically. With all those open choices, interoperability gets rough if implementers don't pick similar options, or at least don't handle implementations that picked differently 🙈
So this profile of the IKE and PKIX frameworks exists to give everyone one agreed-upon standard for using PKI tech with IPsec. It profiles PKIX for use with IKE and IPsec, documents the contents of the relevant IKE payloads, and pins down what they mean 💅
On top of that, this document tries to fold in lessons learned from recent implementation and deployment experience, plus the current state of related protocols and technologies. Big brain moves 🧠
Material from ISAKMP, IKEv1, IKEv2, or PKIX isn't repeated here, so readers are assumed to have already read and understood those documents. The requirements and security aspects from those documents are fully relevant here too, so don't skip them 🫶
Here's how the document is laid out. Section 2 defines the special terminology used throughout. Section 3 gives the profile of IKEv1/ISAKMP, Section 4 gives a profile of IKEv2, and Section 5 gives the profile of PKIX. Section 6 covers conventions for the out-of-band exchange of keying materials for configuration purposes 🎀
2. Terms and Definitions 💅
okay, so every term used in this document is defined in either the PKIX [5], ISAKMP [2], IKEv1 [1], IKEv2 [3], or Domain of Interpretation (DOI) [6] documents, except for the few terms defined right here:
- Peer source address: The source address in packets from a peer. This address may be different from any addresses asserted as the "identity" of the peer. 🦋
- FQDN: Fully qualified domain name. 🌈
- ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both are referred to as ID_USER_FQDN in this document. 👑
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. Those are the words with the real weight in this spec, so keep an eye out for them 🔥
3. Use of Certificates in RFC 2401 and IKEv1/ISAKMP 🎀
3.1. Identification Payload ✨
okay so the Identification (ID) Payload is how the sender says "hey, this is who I claim to be" 💖 the recipient then uses that ID as a lookup key for policy and for finding the certificate in whatever certificate store or directory it has 📂 our main goal here is to profile the ID payload so it can be safely used to generate or look up policy 🔐 and IKE mandates the use of the ID payload in Phase 1 🫶
the DOI [6] defines the 11 types of Identification Data you can use, plus the syntax for each one 🎀 we'll go through them in detail below 👀
ngl, the ID payload requirements in this document only cover the part of the explicit policy checks that's specifically about the Identification Payload 💅 for example, if ID doesn't contain an IP address, checks like making sure the peer source address is allowed by the relevant policy aren't covered here, because that's out of scope for this doc 🙈
Implementations SHOULD populate ID with identity information that's contained in the end-entity certificate 🌸 that way, recipients can use ID as a lookup key to find the peer end-entity certificate ✨ the only time implementations may put in information that isn't in the end-entity certificate is when ID holds the peer source address (one single address, not a subnet or range) 🦋
Because implementations may use ID as a lookup key to decide which policy to use, all implementations MUST be especially careful to verify that the contents are truthful 🔥 they do this by checking that the contents correspond to some keying material the peer can demonstrably prove it holds 💜
Skipping this step could land you with an inappropriate or insecure policy 💀 the following sections describe the methods for making that binding happen 🧚
The table below sums up how the Identification Payload gets bound to the contents of end-entity certificates, and how identity information gets bound to policy 🍓 each ID type gets a more thorough look in the sections that follow.
ID type | Support | Correspond | Cert | SPD lookup
| for send | PKIX Attrib | matching | rules
-------------------------------------------------------------------
| | | |
IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | iPAddress | |
| | | |
FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | dNSName | |
| | | |
USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | rfc822Name | |
| | | |
IP range | MUST NOT | n/a | n/a | n/a
| | | |
DN | MUST [a] | Entire | MUST [b] | MUST support lookup
| | Subject, | | on any combination
| | bitwise | | of C, CN, O, or OU
| | compare | |
| | | |
GN | MUST NOT | n/a | n/a | n/a
| | | |
KEY_ID | MUST NOT | n/a | n/a | n/a
| | | |Footnote [a] is about configuration: the implementation MUST have a configuration option to send this ID type in the ID payload 🎀 whether or not that ID type actually gets used is up to local configuration, so it's totally up to you 💖
Footnote [b] is the strict one: the ID in the ID payload MUST match the contents of the corresponding field (listed) in the certificate exactly, with no other lookup 💅 the matched ID MAY be used for Security Policy Database (SPD) lookup, but it isn't required to be used for this ✨
Footnote [c] sets the minimum: the implementation MUST be capable of being configured to do exact matching of the ID payload contents to an entry in the local SPD 🌈
Footnote [d] is the optional extra: the implementation MAY also be configurable to do substring or wildcard matches of ID payload contents to entries in the local SPD (more on this in Section 3.1.5) 🦋
When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, implementations MUST be able to be configured to send the same string as it appears in the corresponding SubjectAltName extension 🫶 this document RECOMMENDS that deployers use this configuration option 🙌 all of these ID types get treated the same way: as strings that can be compared easily and quickly to a corresponding string in an explicit value in the certificate 🍓 and of these types, FQDN and USER_FQDN are RECOMMENDED over IP addresses (see the discussion in Section 3.1.1) 👑
When sending a Distinguished Name (DN) as ID, implementations MUST send the entire DN in ID 💜 also, implementations MUST support at least the C, CN, O, and OU attributes for SPD matching 🧚 see Section 3.1.5 for more details about DN, including SPD matching ✨
Recipients MUST be able to perform SPD matching on the exact contents of the ID, and this SHOULD be the default setting 💖 on top of that, implementations MAY use substrings or wildcards in local policy configuration to do the SPD matching against the ID contents 🌸 in other words, implementations MUST be able to do exact matches of ID to SPD, but they MAY also be configurable to do substring or wildcard matches of ID to SPD 🦋
3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR
Implementations MUST support at least the ID_IPV4_ADDR or ID_IPV6_ADDR ID type, depending on whether the implementation supports IPv4, IPv6, or both 🌐 these addresses MUST be encoded in "network byte order", as specified in IP [8]: the least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address 🧠 for the ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8] 💅 for the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen octets [10] ✨
Implementations SHOULD NOT populate ID payload with IP addresses 🙅♀️ that's because of interoperability issues, like problems with Network Address Translator (NAT) traversal and problems with IP verification behavior 💀
Deployments may only want to consider using the IP address as ID if all of the following are true:
- the peer's IP address is static, not dynamically changing
- the peer is NOT behind a NAT'ing device
- the administrator intends the implementation to verify that the peer source address matches the IP address in the ID received, and that in the iPAddress field in the peer certificate's SubjectAltName extension
Implementations MUST be capable of verifying that the IP address presented in ID matches, via bitwise comparison, the IP address present in the certificate's iPAddress field of the SubjectAltName extension 🔐 implementations MUST perform this verification by default 💖 when comparing the contents of ID with the iPAddress field in the SubjectAltName extension for equality, binary comparison MUST be performed 🎀 note that certificates may contain multiple address identity types, in which case at least one must match the source IP 🌈 if the default is enabled, then a mismatch between the two addresses MUST be treated as an error, and security association setup MUST be aborted 🚨 this event SHOULD be auditable 📝 implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default 🙈 we include this "option-to-skip-validation" so we can permit better interoperability, since current implementations vary greatly in how they behave on this topic 🫶
Next up, implementations MUST be capable of verifying that the address contained in the ID is the same as the address contained in the IP header 🧚 implementations SHOULD be able to check the address in either the outermost or innermost IP header, and they MAY provide a configuration option for specifying which one gets checked 🦋 if there's no configuration option provided, an implementation SHOULD check the peer source address contained in the outermost header (as is the practice of most of today's implementations) 🍓 if ID is one of the IP address types, then implementations MUST perform this verification by default 💜 if this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted 🚨 this event SHOULD be auditable 📝 implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default 🙈 we include this "option-to-skip-validation" to permit better interoperability, since current implementations vary greatly in how they behave on the topic of verifying the source IP 💅
If the default for both of the verifications above is enabled, then, by transitive property, the implementation will also be verifying that the peer source IP address matches, via bitwise comparison, the contents of the iPAddress field in the SubjectAltName extension in the certificate ✨ on top of that, implementations MAY allow administrators to configure a local policy that explicitly requires the peer source IP address to match, via bitwise comparison, the contents of the iPAddress field in the SubjectAltName extension in the certificate 🌸 implementations SHOULD allow administrators to configure a local policy that skips this validation check 🫶
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up the policy in the SPD, and that would be a matter of local security policy configuration 🎀
Implementations MAY use the IP address found in the header of packets received from the peer to look up the policy, but such implementations MUST still perform verification of the ID payload 🔥 packet IP addresses are inherently untrustworthy and must therefore be independently verified, but it's often useful to use the apparent IP address of the peer to find a general class of policies that will be used until the mandatory identity-based policy lookup can be performed 🧠
For instance, if the IP address of the peer is unrecognized, a VPN gateway device might load a general "road warrior" policy 🚗 that policy specifies a particular Certification Authority (CA) that is trusted to issue certificates containing a valid rfc822Name 💌 the implementation can then use that rfc822Name to do authorization based on access control lists (ACLs) after the peer's certificate has been validated ✅ and the rfc822Name can then be used to determine the policy that gives specific authorization to access resources (such as IP addresses, ports, and so forth) 👑
As another example, if the IP address of the peer is recognized as a known peer VPN endpoint, policy may be determined using that address 🦋 but until the identity (address) is validated by validating the peer certificate, the policy MUST NOT be used to authorize any IPsec traffic 🛑
3.1.2. ID_FQDN 🌸
Okay bestie, ID_FQDN is the identity type for hosts that don't have a fixed IP address, so it's basically the go-to for host-based access control lists. Implementations MUST support the ID_FQDN ID type. 💖 However, implementations SHOULD NOT use the DNS to map the FQDN to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example, if DNSSEC [11] were employed for that FQDN. That's a big no-cap safety check. 🔥
If ID contains an ID_FQDN, implementations MUST be capable of verifying that the identity contained in the ID payload matches identity information contained in the peer end-entity certificate, in the dNSName field in the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the dNSName field in the SubjectAltName extension for equality, case-insensitive string comparison MUST be performed. Note that case-insensitive string comparison works on internationalized domain names (IDNs) as well (See IDN [12]). Substring, wildcard, or regular expression matching MUST NOT be performed for this comparison. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic. 🦋
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up the policy in the SPD, and such would be a matter of local security policy configuration. ✨
3.1.3. ID_USER_FQDN 🎀
ID_USER_FQDN is the same energy but for users instead of machines, so it's great for user-based access control lists when users don't have fixed IP addresses. Implementations MUST support the ID_USER_FQDN ID type. 🧚 However, implementations SHOULD NOT use the DNS to map the FQDN portion to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example, if DNSSEC [11] were employed for that FQDN.
Implementations MUST be capable of verifying that the identity contained in the ID payload matches identity information contained in the peer end-entity certificate, in the rfc822Name field in the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the rfc822Name field in the SubjectAltName extension for equality, case-insensitive string comparison MUST be performed. Note that case-insensitive string comparison works on internationalized domain names (IDNs) as well (See IDN [12]). Substring, wildcard, or regular expression matching MUST NOT be performed for this comparison. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic. 💅
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up policy in the SPD, and such would be a matter of local security policy configuration. 🌈
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE 🦋
Okay so the address-block types are a bit of a plot twist. Note that RFC 3779 [13] defines blocks of addresses using the certificate extension identified by:
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }Just a heads-up though, using this extension in IKE is considered experimental at this time. 🧪
3.1.5. ID_DER_ASN1_DN 💜
This one is giving "be thorough or be cancelled." Implementations MUST support receiving the ID_DER_ASN1_DN ID type. Implementations MUST be capable of generating this type, and the decision to do so will be a matter of local security policy configuration. When generating this type, implementations MUST populate the contents of ID with the Subject field from the end-entity certificate, and MUST do so such that a binary comparison of the two will succeed. If there is not a match, this MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable.
Implementations MUST NOT populate ID with the Subject from the end-entity certificate if it is empty, even though an empty certificate Subject is explicitly allowed in the "Subject" section of the PKIX certificate profile. 🙈
Regarding SPD matching, implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. However, operational experience has shown that using the entire DN in local configuration is difficult, especially in large-scale deployments. Therefore, implementations also MUST be able to perform SPD matches of any combination of one or more of the C, CN, O, OU attributes within Subject DN in the ID to the same in the SPD. Implementations MAY support matching using additional DN attributes in any combination, although interoperability is far from certain and is dubious. Implementations MAY also support performing substring, wildcard, or regular expression matches for any of its supported DN attributes from ID, in any combination, to the SPD. Such flexibility allows deployers to create one SPD entry on the gateway for an entire department of a company (e.g., O=Foobar Inc., OU=Engineering) while still allowing them to draw out other details from the DN (e.g., CN=John Doe) for auditing purposes. All the above is a matter of local implementation and local policy definition and enforcement capability, not bits on the wire, but will have a great impact on interoperability. 👑
3.1.6. ID_DER_ASN1_GN 🍓
Implementations MUST NOT generate this type, because the recipient will be unlikely to know how to use it. 🙅♀️
3.1.7. ID_KEY_ID 🌸
The ID_KEY_ID type is used to specify pre-shared keys and thus is out of scope. That's a wrap for this one! ✨
3.1.8. Selecting an Identity from a Certificate 🧚
Implementations MUST support certificates that contain more than a single identity, such as when the Subject field and the SubjectAltName extension are both populated, or the SubjectAltName extension contains multiple identities irrespective of whether or not the Subject is empty. In many cases, a certificate will contain an identity, such as an IP address, in the SubjectAltName extension in addition to a non-empty Subject. 🫶
implementations should populate ID with whichever identity is likely to be named in the peer's policy. In practice, this generally means FQDN, or USER_FQDN, but this information may also be available to the administrator through some out-of-band means. In the absence of such out-of-band configuration information, the identity with which an implementation chooses to populate the ID payload is a local matter. 🎀
3.1.9. Subject for DN Only 💖
If an FQDN is intended to be processed as an identity for the purposes of ID matching, it MUST be placed in the dNSName field of the SubjectAltName extension. Implementations MUST NOT populate the Subject with an FQDN in place of populating the dNSName field of the SubjectAltName extension. 💀
While nothing prevents an FQDN, USER_FQDN, or IP address information from appearing somewhere in the Subject contents, such entries MUST NOT be interpreted as identity information for the purposes of matching with ID or for policy lookup. 🙈
3.1.10. Binding Identity to Policy 👑
In the presence of certificates that contain multiple identities, implementations should select the most appropriate identity from the certificate and populate the ID with that. The recipient MUST use the identity sent as a first key when selecting the policy. The recipient MUST also use the most specific policy from that database if there are overlapping policies caused by wildcards (or the implementation can de-correlate the policy database so there will not be overlapping entries, or it can also forbid creation of overlapping policies and leave the de-correlation process to the administrator, but, as this moves the problem to the administrator, it is NOT RECOMMENDED).
For example, imagine that an implementation is configured with a certificate that contains both a non-empty Subject and a dNSName. The sender's policy may specify which of those to use, and it indicates the policy to the other end by sending that ID. If the recipient has both a specific policy for the dNSName for this host and generic wildcard rule for some attributes present in the Subject field, it will match a different policy depending on which ID is sent. As the sender knows why it wanted to connect the peer, it also knows what identity it should use to match the policy it needs to the operation it tries to perform; it is the only party who can select the ID adequately. 🦋
In the event that the policy cannot be found in the recipient's SPD using the ID sent, then the recipient MAY use the other identities in the certificate when attempting to match a suitable policy. For example, say the certificate contains a non-empty Subject field, a dNSName and an iPAddress. If an iPAddress is sent in ID but no specific entry exists for the address in the policy database, the recipient MAY search in the policy database based on the Subject or the dNSName contained in the certificate. 🌈
3.2. Certificate Request Payload 📜
The Certificate Request (CERTREQ) Payload allows an implementation to request that a peer provide some set of certificates or certificate revocation lists (CRLs). It is not clear from ISAKMP exactly how that set should be specified or how the peer should respond. We describe the semantics on both sides. ✨
3.2.1. Certificate Type 🎀
The Certificate Type field identifies to the peer the type of certificate keying materials that are desired. ISAKMP defines 10 types of Certificate Data that can be requested and specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
- X.509 Certificate - Signature
- Revocation Lists (CRL and ARL)
- PKCS #7 wrapped X.509 certificate
The use of the other types are out of the scope of this document:
- X.509 Certificate - Key Exchange
- PGP (Pretty Good Privacy) Certificate
- DNS Signed Key
- Kerberos Tokens
- SPKI (Simple Public Key Infrastructure) Certificate
- X.509 Certificate Attribute
3.2.2. X.509 Certificate - Signature 🦋
This type requests that the end-entity certificate be a certificate used for signing. 🫶
3.2.3. Revocation Lists (CRL and ARL) 📜✨
Okay so, ISAKMP can't handle Certificate Payload sizes over approximately 64K 😭, which is way too small for a lot of CRLs. UDP fragmentation is also likely to kick in at sizes much smaller than that 💀. So the acquisition of revocation material is handled out-of-band of IKE. For this reason and others, implementations SHOULD NOT generate CERTREQs where the Certificate Type is "Certificate Revocation List (CRL)" or "Authority Revocation List (ARL)" 🙈. Implementations that do generate such CERTREQs MUST NOT require the recipient to respond with a CRL or ARL, and MUST NOT fail when not receiving any 🫶. When one of these CERTREQs shows up, implementations MAY ignore the request 🦋.
Instead of swapping revocation lists in-band, a pointer to revocation checking SHOULD be listed in either the CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) certificate extensions (see Section 5 for details) 🌸. Unless other methods for getting revocation information are available, implementations SHOULD be able to process these attributes. From them, they should be able to identify cached revocation material, or retrieve the relevant revocation material from a URL for validation processing 🔥. Also, implementations MUST have the ability to configure validation checking information for each certification authority 👑. No matter the method (CDP, AIA, or static configuration), the acquisition of revocation material SHOULD occur out-of-band of IKE 💅. Note, however, that being unable to access revocation status data through out-of-band means is a potential security vulnerability, and an attacker could potentially exploit it 😱🚨.
3.2.4. PKCS #7 wrapped X.509 certificate 🎀
This ID type defines a particular encoding, not a particular certificate type 🧚. Some current implementations may ignore CERTREQs they receive that contain this ID type, and the editors aren't aware of any implementations that generate such CERTREQ messages 🙃. So the use of this type is deprecated 🥀. Implementations SHOULD NOT require CERTREQs that contain this Certificate Type. Implementations that receive CERTREQs containing this ID type MAY treat such payloads as synonymous with "X.509 Certificate - Signature" ✨.
3.2.5. Location of Certificate Request Payloads 📍
In IKEv1 Main Mode, the CERTREQ payload MUST be in messages 4 and 5 💖.
3.2.6. Presence or Absence of Certificate Request Payloads 🌈
When in-band exchange of certificate keying materials is desired, implementations MUST inform the peer of this by sending at least one CERTREQ 📣. In other words, an implementation that doesn't send any CERTREQs during an exchange SHOULD NOT expect to receive any CERT payloads 🙅♀️.
3.2.7. Certificate Requests 💌
3.2.7.1. Specifying Certification Authorities 🗂️
When requesting in-band exchange of keying materials, implementations SHOULD generate CERTREQs for every peer trust anchor that local policy explicitly deems trusted during a given exchange 💯. Implementations SHOULD populate the Certification Authority field with the Subject field of the trust anchor, populated in such a way that a binary comparison of the Subject and the Certification Authority will succeed 🔍.
Upon receipt of a CERTREQ, implementations MUST respond by sending at least the end-entity certificate corresponding to the Certification Authority listed in the CERTREQ 🎁. The exception is when local security policy configuration specifies that keying materials must be exchanged out-of-band. Implementations MAY send certificates other than the end-entity certificate (see Section 3.3 for discussion) 🧠.
Note that, when multiple end-entity certificates may be available that chain to different trust anchors, implementations SHOULD resort to local heuristics to figure out which trust anchor is the most appropriate one to use for generating the CERTREQ 🤔. Such heuristics are out of the scope of this document 🙌.
3.2.7.2. Empty Certification Authority Field 🕳️
Implementations SHOULD generate CERTREQs where the Certificate Type is "X.509 Certificate - Signature" and where the Certification Authority field is not empty 💅. However, implementations MAY generate CERTREQs with an empty Certification Authority field under special conditions. Even though PKIX prohibits certificates with an empty Issuer field, there's a use case where doing so is appropriate and carries special meaning in the IKE context 👀. This has become a convention within the IKE interoperability tests and usage space, so its use is specified and explained here for the sake of interoperability 🤝.
USE CASE: Picture the rare case where you have a gateway with multiple policies for a large number of IKE peers 🏰. Some of these peers are business partners, some are remote-access employees, some are teleworkers, some are branch offices, and/or the gateway may be serving many customers at once (e.g., Virtual Routers) 🧑💻. The total number of certificates, and corresponding trust anchors, is very high, say, hundreds 😵💫. Each of these policies is configured with one or more acceptable trust anchors, so in total the gateway has one hundred (100) trust anchors that could possibly be used to authenticate an incoming connection 💥. Now assume that many of those connections come from hosts or gateways with dynamically assigned IP addresses. That means the source IP of the IKE initiator isn't known to the gateway, and neither is the identity of the initiator (until it gets revealed in Main Mode message 5) 🫠. In IKE Main Mode message 4, the responder gateway will need to send a CERTREQ to the initiator. Given this example, the gateway has no idea which of the hundred possible Certification Authorities to put in the CERTREQ 😩. Sending all possible Certification Authorities would cause significant processing delays, bandwidth consumption, and UDP fragmentation, so this tactic is ruled out 🚫.
In a deployment like this, the responder gateway implementation should be able to do everything it can to indicate a Certification Authority in the CERTREQ 🛠️. This means the responder SHOULD first check the SPD to see if it can match the source IP and find some indication of which CA is associated with that IP 🔎. If this fails (because the source IP is unfamiliar, as in the case above), then the responder SHOULD have a configuration option specifying which CAs are the default CAs to indicate in the CERTREQ during such ambiguous connections (e.g., send CERTREQ with these N CAs if there is an unknown source IP) 🎯. If such a fall-back isn't configured, or it's impractical in a certain deployment scenario, then the responder implementation SHOULD have both of the following configuration options:
- send a CERTREQ payload with an empty Certification Authority field, or
- terminate the negotiation with an appropriate error message and audit log entry.
Receiving a CERTREQ payload with an empty Certification Authority field indicates that the recipient should send all or any end-entity certificates it has, regardless of the trust anchor 🎈. The initiator should be aware of what policy and which identity it will use, since it started the connection on a matched policy to begin with, so it can respond with the appropriate certificate 🧸.
If, after sending an empty CERTREQ in Main Mode message 4, a responder receives a certificate in message 5 that chains to a trust anchor that the responder either (a) does NOT support, or (b) was not configured for the policy (that policy is now able to be matched because the initiator's certificate is present), this MUST be treated as an error, and security association setup MUST be aborted 🛑. This event SHOULD be auditable 📝.
Instead of sending an empty CERTREQ, the responder implementation MAY be configured to terminate the negotiation on the grounds of a conflict with locally configured security policy 🙅.
Which one to configure is a matter of local security policy, but this document RECOMMENDS that both options be presented to administrators 🥰.
More examples and explanation of this issue are included in "More on Empty CERTREQs" (Appendix B) 📚✨.
3.2.8. Robustness 🛡️
3.2.8.1. Unrecognized or Unsupported Certificate Types 🙋
Implementations MUST be able to deal with receiving CERTREQs with unsupported Certificate Types 💪. Absent any recognized and supported CERTREQ types, implementations MAY treat them as if they are of a supported type with the Certification Authority field left empty, depending on local policy 🤷♀️. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing 📖.
3.2.8.2. Undecodable Certification Authority Fields 🧩
Implementations MUST be able to deal with receiving CERTREQs with undecodable Certification Authority fields 🫡. Implementations MAY ignore such payloads, depending on local policy. ISAKMP specifies other actions that may be taken 🌷.
3.2.8.3. Ordering of Certificate Request Payloads 🔀
Implementations MUST NOT assume that CERTREQs are ordered in any way 🚫✨.
3.2.9. Optimizations ⚡
3.2.9.1. Duplicate Certificate Request Payloads 👯
Implementations SHOULD NOT send duplicate CERTREQs during an exchange 🙅♀️.
3.2.9.2. Name Lowest 'Common' Certification Authorities 🏆
When a peer's certificate keying material has been cached, an implementation can send a hint to the peer to elide some of the certificates the peer would normally include in the response 🧠. In addition to the normal set of CERTREQs that are sent specifying the trust anchors, an implementation MAY send CERTREQs specifying the relevant cached end-entity certificates 💭. When sending these hints, it's still necessary to send the normal set of trust anchor CERTREQs, because the hints don't sufficiently convey all of the information the peer requires 📦. Specifically, either the peer may not support this optimization, or there may be additional chains that could be used in this context but won't be if only the end-entity certificate is specified 🙃.
No special processing is required on the part of the recipient of such a CERTREQ, and the end-entity certificates will still be sent 🎀. On the other hand, the recipient MAY elect to elide certificates based on receipt of such hints 🌸.
CERTREQs must contain information that identifies a Certification Authority certificate, which results in the peer always sending at least the end-entity certificate 🫶. Always sending the end-entity certificate lets implementations determine unambiguously when a new certificate is being used by a peer (perhaps because the previous certificate has just expired). That matters because, without it, a failure could happen if a new intermediate CA certificate isn't available to validate the new end-entity certificate 😬. Implementations that implement this optimization MUST recognize when the end-entity certificate has changed, and respond to it by not performing this optimization if the exchange must be retried, so that any missing keying materials will be sent during the retry 🔁💜.
3.2.9.3. Example 🧚
Okay bestie, picture this 🎀 An IKEv1 implementation already received and cached the peer certificate chain TA->CA1->CA2->EE ✨. Later, during a new exchange, it sends a CERTREQ containing the Subject field from certificate TA. That basically means "pls send at least three certs: CA1, CA2, and EE" 💌. But if it also sends a CERTREQ with the Subject field of CA2, that's a hint that only one cert needs to be sent: EE 💅. Lowkey genius. Also, no cap, the fact that TA is a trust anchor should not be construed to imply that TA is a self-signed certificate 🙈
3.3. Certificate Payload 💖
The Certificate (CERT) Payload lets the peer send over a single certificate or CRL 🦋. If there are multiple certificates, they should each go in their own payloads. For backwards-compatibility reasons, implementations MAY send intermediate CA certificates alongside the appropriate end-entity certificate(s), but they SHOULD NOT send any CRLs, ARLs, or trust anchors 🙅♀️. Sending trust anchors, and especially CRLs and ARLs, over IKE would increase the chance of UDP fragmentation, make the IKE exchange more complicated, and eat up extra network bandwidth 📉.
Note, however, that while the sender of CERT payloads SHOULD NOT send any certificates it considers trust anchors, the recipient might consider a given intermediate CA certificate to be a trust anchor 👀. For instance, imagine the sender has the certificate chain TA1->CA1->EE1, while the recipient has the certificate chain TA2->EE2, where TA2=CA1. The sender is just including an intermediate CA certificate, but the recipient receives a trust anchor. Plot twist 😭
However, not every certificate form that is legal in the PKIX certificate profile makes sense in the context of IPsec 🤔. How to represent IKE-meaningful name-forms in a certificate is especially problematic. This document provides a profile for a subset of the PKIX certificate profile that makes sense for IKEv1/ISAKMP 🎀.
3.3.1. Certificate Type 🌸
The Certificate Type field tells the peer what type of certificate keying material is included ✨. ISAKMP defines 10 types of Certificate Data that can be sent, and it specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
- X.509 Certificate - Signature
- Revocation Lists (CRL and ARL)
- PKCS #7 wrapped X.509 certificate
The use of the other types is out of scope for this document:
- X.509 Certificate - Key Exchange
- PGP Certificate
- DNS Signed Key
- Kerberos Tokens
- SPKI Certificate
- X.509 Certificate Attribute
3.3.2. X.509 Certificate - Signature 🔐
This type says that the Certificate Data contains a certificate used for signing. Simple and iconic 💅.
3.3.3. Revocation Lists (CRL and ARL) 🙈
These types say that the Certificate Data contains an X.509 CRL or ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for discussion 📖.
3.3.4. PKCS #7 Wrapped X.509 Certificate 🍓
This type defines a particular encoding, not a particular certificate type 🧁. Implementations SHOULD NOT generate CERTs that contain this Certificate Type. Implementations SHOULD accept CERTs that contain this Certificate Type, though, because several implementations are known to generate them 😅. Those implementations sometimes put entire certificate hierarchies inside a single CERT PKCS #7 payload, which goes against the ISAKMP requirement that this payload contain a single certificate. Messy, but we deal 🫶.
3.3.5. Location of Certificate Payloads 📍
In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6 ✨.
3.3.6. Certificate Payloads Not Mandatory 🌈
An implementation that doesn't receive any CERTREQs during an exchange SHOULD NOT send any CERT payloads. The exception is when it's explicitly configured to proactively send CERT payloads, so it can interoperate with non-compliant implementations that fail to send CERTREQs even when certificates are wanted 🫠. In that case, an implementation MAY send the certificate chain (not including the trust anchor) associated with the end-entity certificate. This MUST NOT be the default behavior of implementations 🚫.
Implementations whose local security policy configuration expects that a peer must receive certificates through out-of-band means SHOULD ignore any CERTREQ messages that they receive. This condition has been known to happen because of non-compliant or buggy implementations 🐛.
Implementations that receive CERTREQs from a peer containing only unrecognized Certification Authorities MAY elect to terminate the exchange. That helps avoid unnecessary and potentially expensive cryptographic processing and denial-of-service (resource starvation) attacks 🚨.
3.3.7. Response to Multiple Certification Authority Proposals 🦋
When multiple CERTREQs arrive with different Certification Authority identities, implementations MAY respond using an end-entity certificate that chains to a CA matching any of the identities the peer provided 💖.
3.3.8. Using Local Keying Materials 🧚
Implementations MAY elect to skip parsing or otherwise decoding a given set of CERTs if those same keying materials are available through some preferable means. An example is when certificates from a previous exchange have been cached 🗂️.
3.3.9. Multiple End-Entity Certificates 👑
Implementations SHOULD NOT send multiple end-entity certificates, and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates 🙃.
If multiple end-entity certificates are sent, they MUST have the same public key. Otherwise, the responder doesn't know which key was used in the Main Mode message 5 😭.
3.3.10. Robustness 🛡️
3.3.10.1. Unrecognized or Unsupported Certificate Types 🤷♀️
Implementations MUST be able to deal with receiving CERTs with unrecognized or unsupported Certificate Types. Implementations MAY discard such payloads, depending on local policy. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing 📚.
3.3.10.2. Undecodable Certificate Data Fields 🧩
Implementations MUST be able to deal with receiving CERTs with undecodable Certificate Data fields. Implementations MAY discard such payloads, depending on local policy. ISAKMP specifies other actions that may be taken 🙌.
3.3.10.3. Ordering of Certificate Payloads 🔀
Implementations MUST NOT assume that CERTs are ordered in any way. Trust no one, not even the order 🙅♀️.
3.3.10.4. Duplicate Certificate Payloads 👯
Implementations MUST support receiving multiple identical CERTs during an exchange 💜.
3.3.10.5. Irrelevant Certificates 🗑️
Implementations MUST be prepared to receive certificates and CRLs that aren't relevant to the current exchange. Implementations MAY discard such extraneous certificates and CRLs 🧹.
Implementations MAY send certificates that are irrelevant to an exchange. One reason to include them is to minimize the threat of leaking identifying information in exchanges where CERT isn't encrypted in IKEv1. It should be noted, however, that this probably provides rather poor protection against leaking the identity 🙈.
Another reason to include certificates that seem irrelevant is that there may be two chains from the Certification Authority to the end entity, and each one is only valid with certain validation parameters (such as acceptable policies). Since the end-entity doesn't know which parameters the relying party is using, it should send the certificates needed for both chains, even if there's only one CERTREQ 🧠.
Implementations SHOULD NOT send multiple end-entity certificates, and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates 🫶.
3.3.11. Optimizations ⚡
3.3.11.1. Duplicate Certificate Payloads 🔁
Implementations SHOULD NOT send duplicate CERTs during an exchange. Such payloads should be suppressed 🚫.
3.3.11.2. Send Lowest 'Common' Certificates 🏆
When multiple CERTREQs are received that specify certification authorities within the end-entity certificate chain, implementations MAY send the shortest chain possible. However, implementations SHOULD always send the end-entity certificate. See Section 3.2.9.2 for more discussion of this optimization 💅.
3.3.11.3. Ignore Duplicate Certificate Payloads 🫥
Implementations MAY use local means to recognize CERTs that have already been received, and they SHOULD discard these duplicate CERTs 🗑️.
3.3.11.4. Hash Payload 🪪
IKEv1 specifies the optional use of the Hash Payload to carry a pointer to a certificate in either of the Phase 1 public key encryption modes 🔑. This pointer is used by an implementation to locate the end-entity certificate that contains the public key a peer should use for encrypting payloads during the exchange.
Implementations SHOULD include this payload whenever the public portion of the keypair has been placed in a certificate ✨.
4. Use of Certificates in RFC 4301 and IKEv2 🌸
4.1. Identification Payload 🆔
The Peer Authorization Database (PAD) described in RFC 4301 [14] explains how the ID payload is used in IKEv2. It gives a formal model for binding identity to policy, and it provides services that deal more specifically with the details of policy enforcement, which are generally out of scope for this document 📋. The PAD is meant to be the link between the SPD and security association management in protocols such as IKE. See RFC 4301 [14], Section 4.4.3 for more details 🔗.
Note that IKEv2 adds an optional IDr payload in the second exchange, which the initiator may send to the responder to specify which of the responder's multiple identities should be used 🎯. The responder MAY choose to send an IDr in the third exchange that differs in type or content from the initiator-generated IDr. The initiator MUST be able to receive a responder-generated IDr that is a different type from the one the initiator generated 🫶.
4.2. Certificate Request Payload 📜
4.2.1. Revocation Lists (CRL and ARL) 🦋
IKEv2 does not support Certificate Payload sizes over approximately 64K. See Section 3.2.3 for the problems this can cause 😬.
4.2.1.1. IKEv2's Hash and URL of X.509 certificate 🌐
This ID type defines a request for the peer to send a hash and URL of its X.509 certificate, instead of the actual certificate itself. It's especially useful when the peer is a device with little memory and lower bandwidth, like a mobile handset or consumer electronics device 📱.
If the IKEv2 implementation supports URL lookups and prefers such a URL to receiving actual certificates, then the implementation will want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 [3], Section 3.10.1, "This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format)". If an HTTP_CERT_LOOKUP_SUPPORTED notification is sent, the sender MUST support the http scheme. See Section 4.3.1 for more discussion of HTTP_CERT_LOOKUP_SUPPORTED 🔎.
4.2.1.2. Location of Certificate Request Payloads 📍
In IKEv2, the CERTREQ payload must be in messages 2 and 3. Note that in IKEv2, it's possible for one side to authenticate with certificates while the other side authenticates with pre-shared keys 🗝️.
4.3. Certificate Payload 🎀
4.3.1. IKEv2's Hash and URL of X.509 Certificate 🔗
okay so this type says the Certificate Data holds a hash plus a URL pointing at a repository where an X.509 certificate can be fetched 🦋
If an implementation sends an HTTP_CERT_LOOKUP_SUPPORTED notification, it MUST support the http scheme and MAY support the ftp scheme. It MUST NOT require any specific form of the url-path, and it SHOULD support user-name, password, and port parts in the URL. These are the examples of the mandatory forms 💅
http://certs.example.com/certificate.cerhttp://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400http://certs.example.com/%0a/../foo/bar/zappa
And this one is an example of a form that SHOULD be supported 🌸
FTP MAY be supported. If you do support it, this ftp example is one that MUST be supported 🧚
ftp://ftp.example.com/pub/certificate.cer
4.3.2. Location of Certificate Payloads 📍
In IKEv2, the CERT payload MUST be in messages 3 and 4. ngl this is the kind of detail you need to have locked in 🔥 Also, it's totally possible in IKEv2 for one side to authenticate with certificates while the other side uses pre-shared keys. Mixing is giving flexibility 💜
4.3.3. Ordering of Certificate Payloads 🗂️
For IKEv2, implementations MUST NOT assume that any but the first CERT is ordered in any way. The first CERT is the special one: it has to contain an end-entity certificate that can be used to authenticate the peer 👑
5. Certificate Profile for IKEv1/ISAKMP and IKEv2 🌈
Unless this document specifically says otherwise, implementations MUST conform to the requirements of the PKIX [5] certificate profile. Main character rule, bestie 💖
5.1. X.509 Certificates 🔐
Okay real talk: a lot of people deploying IKE and IPsec with certificates have had very little say over what CAs they get to use 😭 This spec says implementations may include configuration knobs that turn off checks it requires, so you can work with inflexible or noncompliant CAs. BUT every check on a certificate is there for a real security reason that covers the whole system, so all checks MUST be enabled by default. Admins and users should understand why each check exists and be clear about what security they give up by turning one off 🙈
5.1.1. Versions 🎀
PKIX says "implementations SHOULD be prepared to accept any version certificate", but in practice this profile needs certain extensions, which means Version 3 certificates are required for everything except self-signed certificates used as trust anchors. So an implementation that conforms to this document MAY reject Version 1 and Version 2 certificates in all other cases ✨
5.1.2. Subject 🪪
Certification Authority implementations MUST be able to create certificates whose Subject fields have at least these four attributes: CN, C, O, and OU. They MAY support other Subject attributes too. The contents of these attributes SHOULD be configurable on a certificate-by-certificate basis, because IKE implementations will probably use these fields to match SPD policy 🦋
See Section 3.1.5 for how IKE implementations need to be able to process Subject field attributes for SPD policy lookup 🔍
5.1.2.1. Empty Subject Name 🫥
IKE implementations MUST accept certificates with an empty Subject field, as the PKIX certificate profile specifies. In those certs, all the identity info lives in the SubjectAltName extension 🧚
5.1.2.2. Specifying Hosts and not FQDN in the Subject Name 🖥️
If you want to put host names in the Subject that are NOT meant to be read as FQDNs (like "Gateway Router"), implementations MUST use the commonName attribute. Lowkey a very specific rule, but it matters 💅
5.1.2.3. EmailAddress 📧
As the PKIX certificate profile says, implementations MUST NOT populate X.500 distinguished names with the emailAddress attribute. Not me putting emails in the DN 💀
5.1.3. X.509 Certificate Extensions 🧩
Conforming IKE implementations MUST recognize the extensions that must or may be marked critical under this spec. Those are KeyUsage, SubjectAltName, and BasicConstraints 🔥
Certification Authority implementations SHOULD generate certificates where the extension criticality bits are set according to the PKIX certificate profile and this document. For compliance with the PKIX certificate profile, IKE implementations that process certificates MAY ignore the criticality bit for extensions they support, but MUST support the criticality bit for extensions they don't support. So a relying party SHOULD process every extension it knows about, whether the bit is true or false. The bit only says what happens when a relying party can't process an extension 💖
Here's the table, keep it in view, it's the whole vibe 👇
implements bit in cert PKIX mandate behavior
------------------------------------------------------
yes true true ok
yes true false ok or reject
yes false true ok or reject
yes false false ok
no true true reject
no true false reject
no false true reject
no false false ok5.1.3.1. AuthorityKeyIdentifier and SubjectKeyIdentifier 🗝️
Implementations SHOULD NOT assume they have support for the AuthorityKeyIdentifier or SubjectKeyIdentifier extensions. So Certification Authority implementations should avoid building overly complex certificate hierarchies that would be hard to process without those extensions. An example is one that might force you to check a signature against a big pile of similarly named CA certificates just to find the right one 🌀
5.1.3.2. KeyUsage 🔑
IKE uses an end-entity certificate in authentication. That same end-entity cert might be used for several applications, so the CA can put some limits on how the public key should be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU) extensions cover that 🎀
Since we're using the public key to validate a signature, if the KeyUsage extension is present, then at least one of the digitalSignature or nonRepudiation bits MUST be set (both can be set too). Other KeyUsage bits being set is also fine ✨
Here's a quick summary of the peer cert validation logic:
- If there's no KU extension, continue.
- If KU is present and doesn't mention digitalSignature or nonRepudiation (having both alongside other KUs is also fine), reject the cert.
- If none of the above, continue.
5.1.3.3. PrivateKeyUsagePeriod ⏳
The PKIX certificate profile recommends against this extension. PrivateKeyUsageExtension is meant for when signatures need to be verified long after the private keypair could have generated them. IKE SAs are short-lived compared to that, and each signature only gets validated once, so the usefulness of this extension for IKE is unclear 🌸 That's why Certification Authority implementations MUST NOT generate certificates containing the PrivateKeyUsagePeriod extension. If an IKE implementation receives a certificate with this extension set, it SHOULD ignore it 🙈
5.1.3.4. CertificatePolicies 📜
Lots of IKE implementations don't support the CertificatePolicies extension yet. So Certification Authority implementations that generate certificates with this extension SHOULD NOT mark it as critical. Like with every certificate extension, a relying party that receives this extension and CAN process it SHOULD NOT reject the certificate just because it's there 💅
5.1.3.5. PolicyMappings 🗺️
Many IKE implementations don't support the PolicyMappings extension. So implementations that generate certificates containing it SHOULD NOT mark it as critical 💜
5.1.3.6. SubjectAltName 🪄
Deployments that plan to use an ID of FQDN, USER_FQDN, IPV4_ADDR, or IPV6_ADDR MUST issue certificates with the matching SubjectAltName fields filled in with the same data. Implementations SHOULD generate only these GeneralName choices in SubjectAltName: rfc822Name, dNSName, or iPAddress. Those map to the legal IKEv1/ISAKMP/IKEv2 Identification Payload types. You can put any GeneralName choice in the Identification Payload using the ID_DER_ASN1_GN ID type, but implementations SHOULD NOT assume support for that, and SHOULD NOT generate certificates that do it 🫶
5.1.3.6.1. dNSName 🌐
If the IKE ID type is FQDN, this field MUST contain a fully qualified domain name, and the dNSName field MUST match its contents. Implementations MUST NOT generate names with wildcards. Implementations MAY treat certificates with wildcards in this field as syntactically invalid ✨
Even though this field is in FQDN form, IKE implementations SHOULD NOT assume the name will resolve via DNS, unless some out-of-band mechanism says so. That mechanism is out of scope for this document. And implementations SHOULD NOT treat a failure to resolve as an error 🦋
5.1.3.6.2. iPAddress 🔢
If the IKE ID type is IPV4_ADDR or IPV6_ADDR, the iPAddress field MUST match its contents. PKIX allows CIDR [15] notation in the "Name Constraints" extension, but the PKIX certificate profile explicitly prohibits CIDR notation for conveying identity information. In other words, CIDR notation MUST NOT be used in the SubjectAltName extension 🚫
5.1.3.6.3. rfc822Name 📬
If the IKE ID type is USER_FQDN, the rfc822Name field MUST match its contents. This field looks like an Internet mail address, but IKE implementations SHOULD NOT assume it's a valid email address unless an out-of-band mechanism says so. That mechanism is out of scope for this document 💌
5.1.3.7. IssuerAltName 🫧
Certification Authority implementations SHOULD NOT assume other implementations support the IssuerAltName extension. They especially should not assume that info in this extension gets shown to end users 🙈
5.1.3.8. SubjectDirectoryAttributes 🪞
This extension is meant to convey identification attributes of the subject. IKE implementations MAY ignore it when it's marked non-critical, which is what the PKIX certificate profile mandates 🌷
5.1.3.9. BasicConstraints 🛡️
The PKIX certificate profile requires that CA certificates contain this extension and that it be marked critical. IKE implementations SHOULD reject CA certificates that don't contain it. For backwards compatibility, implementations may accept such certificates if they're explicitly configured to, but the default for that setting MUST be to reject them 👑
Real talk: the default is the security-friendly choice, so only flip this if you truly know why you're doing it 🫶
5.1.3.10. NameConstraints 🌸
Okay so, a lot of IKE implementations just don't support the NameConstraints extension yet 😭. And because the PKIX certificate profile says this extension has to be marked critical whenever it shows up, any Certification Authority that wants to play nice with the most IKE setups SHOULD NOT generate certificates that include it. Bestie, skip it if interoperability matters to you 🫶.
5.1.3.11. PolicyConstraints 💜
Same drama here! Plenty of IKE implementations don't support PolicyConstraints either. The PKIX profile makes it critical when it's present, so a Certification Authority that cares about maximal interoperability for IKE SHOULD NOT generate certificates containing it. Honestly it's giving "leave it out and everyone's happy" ✨.
5.1.3.12. ExtendedKeyUsage 🎀
The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in certificates meant for IKE, no cap 💅. There were three IPsec-related object identifiers in EKU that got assigned back in 1999, but their meaning was never clearly defined, so they're messy. This document says that using those three EKU values in IKE/IPsec is obsolete and explicitly deprecated, and CAs SHOULD NOT issue IKE certificates with them. (For historical reference only, those values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-ipsecUser. Old news, bestie 🥀.)
The CA SHOULD NOT mark the EKU extension as critical in certificates used for IKE plus one or more other applications 🙈. That said, this document does define an ExtendedKeyUsage keyPurposeID that MAY be used to limit what a certificate can be used for. It looks like this:
id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }Here id-kp is defined in RFC 3280 [5]. Now the lore: if a certificate is meant for both IKE and other applications, and one of those other applications needs an EKU value, then the certificate MUST contain either the keyPurposeID id-kp-ipsecIKE or anyExtendedKeyUsage [5], plus the keyPurposeID values for the other applications. Also, if a CA issues several otherwise-similar certificates for multiple applications including IKE, and the IKE certificate is supposed to NOT be used with another application, the IKE certificate MAY contain an EKU extension listing id-kp-ipsecIKE to discourage that misuse 🔥. Just remember that EKU extensions in certificates meant for IKE are NOT RECOMMENDED, so don't go overboard!
Conforming IKE implementations aren't required to support EKU 🍓. But if a critical EKU extension shows up and the implementation doesn't support EKU, RFC 3280 says the certificate has to be rejected. Implementations that DO support EKU MUST support this validation logic:
- If no EKU extension, continue.
- If EKU present AND contains either id-kp-ipsecIKE or anyExtendedKeyUsage, continue.
- Otherwise, reject cert.
5.1.3.13. CRLDistributionPoints 🦋
Okay this one is so important, bestie 😭. This document deprecates sending CRLs in-band, so if CRLs are used for revocation checking (instead of something like Online Certificate Status Protocol - OCSP [16]), then CRLDistributionPoints (CDP) becomes super crucial. The IPsec peer either needs a CRL URL written into its local configuration, or it has to learn it from the CDP. That's why Certification Authority implementations SHOULD issue certificates with a populated CDP ✨.
Failing to validate the CRLDistributionPoints/IssuingDistributionPoint pair can lead to CRL substitution. That's when an entity knowingly swaps in a known good CRL from a different distribution point, so the entity looks revoked when it isn't 💀. To stop that, IKE implementations MUST support validating that the contents of CRLDistributionPoints match those of the IssuingDistributionPoint when the issuing CA is using them. At least one CA is known to default to this kind of CRL use. See Section 5.2.2.5 for more information.
CDPs SHOULD be "resolvable" 🌈. Some non-compliant Certification Authority implementations are notorious for including unresolvable CDPs like http://localhost/path_to_CRL and http:///path_to_CRL. Those are basically the same as leaving the CDP extension out entirely, which is so not it 🙄.
Check out the IETF IPR Web page for information on intellectual property rights (IPR) for CRLDistributionPoints. Both the CRLDistributionPoints and IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED by the PKIX certificate profile, so there's no requirement to license any IPR 🧚.
5.1.3.14. InhibitAnyPolicy 🫧
Many IKE implementations don't support the InhibitAnyPolicy extension, sadly. Since the PKIX certificate profile mandates that it be marked critical when present, Certification Authority implementations that want maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension 💅.
5.1.3.15. FreshestCRL 🌷
IKE implementations MUST NOT assume that the FreshestCRL extension will exist in peer certificates. Also, most IKE implementations don't support delta CRLs, so keep that in mind 🙈.
5.1.3.16. AuthorityInfoAccess 🍒
The PKIX certificate profile defines AuthorityInfoAccess, which is used to indicate "how to access CA information and services for the issuer of the certificate in which the extension appears". Because this document deprecates sending CRLs in-band, AuthorityInfoAccess (AIA) becomes super important if OCSP [16] is going to be used for revocation checking (instead of CRLs). The IPsec peer either needs a URI for the OCSP query written into its local configuration, or it has to learn it from AIA. So implementations SHOULD support this extension, especially if OCSP will be used 🔥.
5.1.3.17. SubjectInfoAccess 🎀
The PKIX certificate profile also defines the SubjectInfoAccess certificate extension, which indicates "how to access information and services for the subject of the certificate in which the extension appears". Honest tea: this extension has no known use in the context of IPsec 🥱. So conformant IKE implementations SHOULD ignore it when it's present 🫶.
5.2. X.509 Certificate Revocation Lists 👑
When validating certificates, IKE implementations MUST make use of certificate revocation information, and SHOULD support that information in the form of CRLs, unless non-CRL revocation information is known to be the only method for transmitting it 🌸. Deployments that plan to use CRLs for revocation SHOULD populate the CRLDistributionPoints extension. That's why Certification Authority implementations MUST support issuing certificates with this field populated 💖. IKE implementations MAY provide a configuration option to disable certain types of revocation information, but that option MUST be off by default. Such an option is often valuable in lab testing environments 🧪.
5.2.1. Multiple Sources of Certificate Revocation Information ✨
IKE implementations that support multiple sources of certificate revocation information MUST act conservatively when those sources are inconsistent. If one trusted source reports a certificate as revoked, the certificate MUST be considered revoked. No debate, bestie 💅.
5.2.2. X.509 Certificate Revocation List Extensions 🦋
5.2.2.1. AuthorityKeyIdentifier 🌈
Certification Authority implementations SHOULD NOT assume that IKE implementations support the AuthorityKeyIdentifier extension. So they shouldn't build certificate hierarchies that get overly complex to process without it, like ones that need to verify a signature against a huge pile of similarly named CA certificates just to find the one holding the key that made the signature 😵💫.
5.2.2.2. IssuerAltName 💜
Certification Authority implementations SHOULD NOT assume that IKE implementations support the IssuerAltName extension. They should especially not assume that information in this extension will be shown to end users 🙈.
5.2.2.3. CRLNumber 🍓
As the PKIX certificate profile says, all issuers MUST include this extension in all CRLs 📜.
5.2.2.4. DeltaCRLIndicator 🧚
5.2.2.4.1. If Delta CRLs Are Unsupported 🔥
IKE implementations that don't support delta CRLs MUST reject CRLs that contain the DeltaCRLIndicator, which MUST be marked critical according to the PKIX certificate profile. They MUST also make use of a base CRL if one is available. And these implementations MUST ensure that a delta CRL does not "overwrite" a base CRL, for example in the keying material database 😤.
5.2.2.4.2. Delta CRL Recommendations 🫧
Some IKE implementations that don't support delta CRLs may behave incorrectly or insecurely when they get delta CRLs, so administrators and deployers should think hard about whether issuing delta CRLs actually increases security before doing it. And if all the elements in the VPN and PKI systems don't adequately support delta CRLs, their use should be questioned 🤔.
The editors know of several implementations that act in an incorrect or insecure manner when presented with delta CRLs. See Appendix A for a description of the issue. So this specification RECOMMENDS NOT issuing delta CRLs at this time 🙅♀️. On the other hand, not issuing delta CRLs may leave a bigger window of vulnerability if a full CRL isn't issued as often as delta CRLs would be. See the Security Considerations section of the PKIX [5] certificate profile for more discussion 🥺. Implementers and administrators are both encouraged to think about these issues 🌷.
5.2.2.5. IssuingDistributionPoint 🎀
A CA that uses CRLDistributionPoints might do so to provide lots of "small" CRLs, each only valid for a particular set of certificates that CA issued 🍰. To link a CRL to a certificate, the CA puts the CRLDistributionPoints extension in the certificate and the IssuingDistributionPoint in the CRL. The distributionPointName field in the CRLDistributionPoints extension MUST be identical to the distributionPoint field in the IssuingDistributionPoint extension. At least one CA is known to default to this type of CRL use. See Section 5.1.3.13 for more information 🔗.
5.2.2.6. FreshestCRL 🌟
Given the recommendations against Certification Authority implementations generating delta CRLs, this specification RECOMMENDS that implementations do not populate CRLs with the FreshestCRL extension, which is used to obtain delta CRLs 💖.
5.3. Strength of Signature Hashing Algorithms 🔐
okay so, when this was being written, popular certification authorities and CA software were literally issuing certificates with RSA-with-SHA1 and RSA-with-MD5 signature algorithms 💀. Implementations MUST be able to validate certificates with either of those algorithms, no exceptions bestie 🫶.
As described in [17], both MD5 and SHA-1 are weaker than people originally expected when it comes to hash collisions 😭. So certificates that use these hash algorithms as part of their signature algorithms could conceivably be hit by an attack where a CA issues a certificate for a particular identity, and the recipient of that cert can make a different valid certificate with a different identity. Scary! 🙈 Right now though, that attack is only theoretical, even with the weaknesses found in these hashes.
Because of those recent attacks, everyone is suddenly super interested in widespread deployment of additional signature algorithms 👀. The one people mention the most is RSA-with-SHA256, and two types of it are described in detail in [18]. It's widely expected to be much more resilient to collision-based attacks than RSA-with-SHA1 and RSA-with-MD5, although no proof of that has been shown yet. There's also active discussion in the cryptographic community about better hash functions that could go into signature algorithms ✨.
To interoperate, all implementations need to be able to validate signatures for all the algorithms they'll encounter 🤝. So implementations SHOULD be able to use signatures that use the sha256WithRSAEncryption signature algorithm (PKCS#1 version 1.5) as soon as possible 🏃♀️. When this was being written, there was at least one CA that supported generating certificates with the sha256WithRSAEncryption signature algorithm, and it was expected that there would be significant deployment of this algorithm by the end of 2007 🌸.
6. Configuration Data Exchange Conventions 🎀
Below, we present a common format for exchanging configuration data 📦. Implementations MUST support these formats, MUST support receiving arbitrary whitespace at the beginning and end of any line, MUST support receiving arbitrary line lengths (although they SHOULD generate lines less than 76 characters), and MUST support receiving the following three line-termination disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF. Main character energy, literally 💅.
6.1. Certificates 📜
Certificates MUST be Base64 [19] encoded and appear between the following delimiters:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----6.2. CRLs and ARLs 🚫
CRLs and ARLs MUST be Base64 encoded and appear between the following delimiters:
-----BEGIN CRL-----
-----END CRL-----6.3. Public Keys 🔑
IKE implementations MUST support two forms of public keys: certificates and so-called "raw" keys 💖. Certificates should be transferred in the same form as Section 6.1. A raw key is only the SubjectPublicKeyInfo portion of the certificate, and it MUST be Base64 encoded and appear between the following delimiters:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----6.4. PKCS#10 Certificate Signing Requests 📝
A PKCS#10 [9] Certificate Signing Request MUST be Base64 encoded and appear between the following delimiters:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----7. Security Considerations 🚨
Okay this section is the serious one, so let's get into it 🫢.
7.1. Certificate Request Payload 🙊
The contents of CERTREQ are not encrypted in IKE. In some environments, this may leak private information 😬. Administrators in some environments may wish to use the empty Certification Authority option to stop that information from leaking, at the cost of performance 💀.
7.2. IKEv1 Main Mode 🕵️♀️
Certificates may be included in any message, so implementations may wish to respond with CERTs in a message that offers privacy protection in Main Mode messages 5 and 6 🔒.
Implementations may not wish to respond with CERTs in the second message, because that would violate the identity protection feature of Main Mode in IKEv1 🙅♀️. Don't do it, bestie.
7.3. Disabling Certificate Checks ⚠️
It is important to note that anywhere this document suggests implementers provide users with the configuration option to simplify, modify, or disable a feature or verification step, there may be security consequences for doing so. Deployment experience has shown that such flexibility may be required in some environments, but making use of such flexibility can be inappropriate in others. Such configuration options MUST default to "enabled", and it is appropriate to provide warnings to users when disabling such features. 🚩
8. Acknowledgements 🫶
The authors would like to acknowledge the expired document "A PKIX Profile for IKE" (July 2000) for providing valuable materials for this document 🌷.
The authors would like to especially thank Eric Rescorla, one of its original authors, in addition to Greg Carter, Steve Hanna, Russ Housley, Charlie Kaufman, Tero Kivinen, Pekka Savola, Paul Hoffman, and Gregory Lebovitz for their valuable comments, some of which have been incorporated verbatim into this document 🙌. Paul Knight performed the arduous task of converting the text to XML format 🧚.
9. References 📚
9.1. Normative References 💜
- [1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [2] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
- [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [6] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
- [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [9] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
9.2. Informative References 🌈
- [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
- [12] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
- [13] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
- [14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [15] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
- [16] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
- [17] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
- [18] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
- [19] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
Appendix A. The Possible Dangers of Delta CRLs ☠️
The problem is that the CRL processing algorithm is sometimes written incorrectly with the assumption that all CRLs are base CRLs, and it is assumed that CRLs will pass content validity tests 🙃. Specifically, such implementations fail to check the certificate against all possible CRLs: if the first CRL that is obtained from the keying material database fails to decode, no further revocation checks are performed for the relevant certificate 😱. This problem is compounded by the fact that implementations that do not understand delta CRLs may fail to decode such CRLs due to the critical DeltaCRLIndicator extension. The algorithm that is implemented in this case is approximately:
- fetch newest CRL
- check validity of CRL signature
- if CRL signature is valid, then
- if CRL does not contain unrecognized critical extensions and certificate is on CRL, then set certificate status to revoked
The authors note that a number of PKI toolkits do not even provide a method for obtaining anything but the newest CRL, which in the presence of delta CRLs may in fact be a delta CRL, not a base CRL 🫠.
Note that the above algorithm is dangerous in many ways. See the PKIX [5] certificate profile for the correct algorithm. 🚨💅
Appendix B. More on Empty CERTREQs 💅✨
Okay bestie, sending an empty CERTREQ is super common in real implementations 🫶. At the IPsec interop meetings, vendors basically agreed that an empty one means "send all/any end-entity certs you have." 🎀 If you send more than one, they all need the same public key, or the other end has no idea which key got used 🙈.
For 99% of cases the client only has one cert and one key, so it literally doesn't matter 💖. The server might have several though, so it just tells the client "use any cert you have" 🦋. For corporate VPN stuff, even if the client has a bunch of certs, they're all usable when it authenticates to the server, so it can just pick one 🧚.
Where it gets messy is when the certs actually do different things, like giving different permissions 😭. Then the client has to be configured anyway, or it might even ask the user which one to use. Only the user knows whether they need the admin cert or whether the normal email-only cert is good enough 💀.
Real talk, the numbers are on the side of "any cert works" 📊. In 99% of cases the client has exactly one cert, so it sends that. In 90% of the rest, any of the certs is ok, because they're different certs from the same CA, or from different CAs for the same corporate VPN 👑.
So the agreed meaning is: "give me your cert, any cert" 🌈.
Here's the justification, lowkey iconic 🔥:
- The responder first does everything it can to send a CERTREQ with a CA: checking for an IP match in the SPD, having a default set of CAs for ambiguous cases, and so on 🍓.
- Sending empty CERTREQs is pretty common in implementations today, and it's generally accepted to mean "send me a certificate, any certificate that works for you" 💜.
- It saves the responder from sending potentially hundreds of certs, plus all the fragmentation problems that come with that 🙈✨.
- In +90% of use cases, initiators have exactly one certificate 🎀.
- In +90% of the remaining use cases, the multiple certificates they have were issued by the same CA 🦋.
- In the remaining use case(s), if not all the others above, the initiator will be configured explicitly with which certificate to send, so responding to an empty CERTREQ is easy 🫶.
The next example shows why initiators need enough policy definition to know which cert to use for a given connection they start 🧚♀️.
EXAMPLE: Your client (initiator) is configured with VPN policies for gateways A and B (representing perhaps corporate partners) 🌸.
The policies for the two gateways look something like this:
Acme Company policy (gateway A)
Engineering can access 10.1.1.0
Trusted CA: CA-A, Trusted Users: OU=Engineering
Partners can access 20.1.1.0
Trusted CA: CA-B, Trusted Users: OU=AcmePartners
Bizco Company policy (gateway B)
Sales can access 30.1.1.0
Trusted CA: CA-C, Trusted Users: OU=Sales
Partners can access 40.1.1.0
Trusted CA: CA-B, Trusted Users: OU=BizcoPartnersYou're an Acme employee and you've been issued these certs:
- From CA-A: CN=JoeUser,OU=Engineering
- From CA-B: CN=JoePartner,OU=BizcoPartners
The client MUST be configured locally to know which CA to use when connecting to either gateway. 🚨 If your client doesn't know which local credential to use for the remote gateway, this scenario just won't work 😭. If you try to connect to Bizco, everything works... because you're presented with a request for a cert signed by CA-B or CA-C, and you only have one from CA-B, so you're good 🎉.
If you try to connect to Acme, it gets messy 🙈. You're presented with an ambiguous policy selection. As the initiator, you get certificate requests from both CA-A and CA-B. You have certs issued by both CAs, but only one of them will be usable. So how does the client know which cert to present? 🤔 It needs sufficiently clear local policy that says which one credential to present for the connection it's starting 💅.
Author's Address 🖊️
Brian Korver
Network Resonance, Inc.
2483 E. Bayshore Rd.
Palo Alto, CA 94303
US
Phone: +1 650 812 7705
EMail: briank@networkresonance.comFull Copyright Statement ⚖️
Okay, legal stuff, but it matters 🫶. Here's the copyright statement exactly as it's written:
Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🔐
The IETF doesn't take a position on whether any IPR claims about this technology are valid or how wide they are, and it doesn't say whether licenses are available. It also hasn't independently tried to find any such rights 🙈. Info on how rights work for RFC documents is in BCP 78 and BCP 79 💜.
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be available, or the results of attempts to get a general license for implementers or users of this spec can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🌐.
The IETF also invites anyone to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that to ietf-ipr@ietf.org 📬.
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society 💖✨.
📦 where this page comes from
- ietf: rfc4945 2007-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms