The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
Extracted elements (32)
An empty Certification Authority field in CERTREQ was standardized to handle large-scale deployments where a gateway has hundreds of trust anchors but cannot identify the initiator before message 5. Sending all possible CAs would cause processing delays, bandwidth waste, and UDP fragmentation.
CRL acquisition is mandated to occur out-of-band of IKE because ISAKMP does not support Certificate Payload sizes over approximately 64K (too small for many CRLs) and UDP fragmentation occurs at much smaller sizes. CRLDistributionPoints or AuthorityInfoAccess extensions should provide pointers to revocation material instead.
Delta CRLs are explicitly NOT RECOMMENDED at this time because several IKE implementations behave incorrectly or insecurely when presented with them, despite the trade-off that infrequent full CRLs leave a larger revocation vulnerability window.
NameConstraints, PolicyConstraints, and InhibitAnyPolicy extensions SHOULD NOT be generated in certificates intended for IKE, because many IKE implementations do not support them and PKIX mandates they be marked critical when present, causing non-supporting implementations to reject the certificate.
PKCS#7 wrapped X.509 certificate type is deprecated for CERTREQ generation and implementations SHOULD NOT generate CERTs with this type, but implementations SHOULD accept them because several existing implementations generate them, sometimes including entire certificate hierarchies in a single payload in violation of ISAKMP requirements.
All implementations MUST be especially careful to verify the truthfulness of ID payload contents by verifying they correspond to keying material demonstrably held by the peer. Failure to do so may result in use of an inappropriate or insecure policy.
Deployments that intend to use an ID of FQDN, USER_FQDN, IPV4_ADDR, or IPV6_ADDR MUST issue certificates with corresponding SubjectAltName fields populated with the same data. The dNSName field MUST NOT contain wildcards, and CIDR notation MUST NOT be used in SubjectAltName iPAddress fields.
For ID_DER_ASN1_DN, implementations MUST send the entire Subject DN in the ID payload such that binary comparison with the certificate Subject will succeed. Implementations MUST NOT populate ID with an empty Subject, and MUST support SPD matching on C, CN, O, and OU attributes.
For ID_FQDN, implementations MUST verify the ID payload against the dNSName field in SubjectAltName using case-insensitive string comparison; substring, wildcard, or regex matching MUST NOT be performed for this comparison. A mismatch MUST cause SA setup to be aborted.
For ID_IPV4_ADDR and ID_IPV6_ADDR, implementations MUST verify by binary comparison that the ID payload address matches the iPAddress field in the certificate's SubjectAltName extension, with this verification enabled by default. A mismatch MUST be treated as an error and security association setup MUST be aborted.
For ID_USER_FQDN (renamed ID_RFC822_ADDR in IKEv2), implementations MUST verify the ID payload against the rfc822Name field in SubjectAltName using case-insensitive string comparison. Substring, wildcard, or regex matching MUST NOT be performed; a mismatch MUST abort SA setup.
For IKEv2, implementations MUST NOT assume that any CERT beyond the first is ordered in any way. IKEv2 specifies that the first CERT contain an end-entity certificate that can be used to authenticate the peer.
If multiple end-entity certificates are sent, they MUST have the same public key. Implementations SHOULD NOT send multiple end-entity certificates, and recipients SHOULD NOT be expected to iterate over them.
If the KeyUsage extension is present in an end-entity certificate, at least one of the digitalSignature or nonRepudiation bits MUST be set; otherwise the certificate MUST be rejected for IKE use.
IKE implementations MUST support validating that the distributionPointName in CRLDistributionPoints matches the distributionPoint in IssuingDistributionPoint to prevent CRL substitution attacks where a known-good CRL from a different distribution point is substituted.
IKE implementations that do not support delta CRLs MUST reject CRLs containing the DeltaCRLIndicator extension and MUST ensure a delta CRL does not overwrite a base CRL in the keying material database.
Implementations MUST be able to validate certificates using RSA-with-SHA1 and RSA-with-MD5 signature algorithms, and SHOULD be able to use sha256WithRSAEncryption (PKCS#1 v1.5) as soon as possible given known weaknesses in MD5 and SHA-1 against hash collisions.
Implementations MUST NOT generate the ID_DER_ASN1_GN ID type because recipients are unlikely to know how to use it.
Implementations SHOULD NOT generate CERTREQs with Certificate Type 'CRL' or 'ARL' because ISAKMP cannot support payloads over approximately 64K, which is too small for many CRLs. Acquisition of revocation material SHOULD occur out-of-band of IKE.
Implementations SHOULD NOT use IP addresses as the IKE ID due to NAT traversal problems and IP verification complexity. IP address identity should only be considered when the peer IP is static, not behind NAT, and the administrator intends to verify source address against the certificate.
Implementations SHOULD populate the IKE ID payload with identity information contained within the end-entity certificate, enabling recipients to use ID as a lookup key to find the peer certificate. The only exception is when ID contains the peer source address (a single address, not a subnet or range).
In IKEv1 Main Mode, the CERTREQ payload MUST be in messages 4 and 5; the CERT payload MUST be in messages 5 and 6. In IKEv2, CERTREQ must be in messages 2 and 3, and CERT MUST be in messages 3 and 4.
Upon receipt of a CERTREQ, implementations MUST respond by sending at least the end-entity certificate corresponding to the listed Certification Authority, unless local security policy mandates out-of-band keying material exchange.
When validating certificates, IKE implementations MUST use certificate revocation information. When multiple revocation sources disagree, a certificate reported as revoked by any one trusted source MUST be considered revoked.
IKEv2's 'Hash and URL of X.509 Certificate' CERT type allows the peer to send a certificate hash plus retrieval URL instead of the certificate itself, suited for low-memory/low-bandwidth devices. The sender MUST support http:// and MUST NOT require any specific url-path form; ftp:// MAY be supported.
The Certificate Request (CERTREQ) payload requests a peer to provide certificates. The Certification Authority field SHOULD contain the Subject field of the trust anchor for binary comparison. An empty Certification Authority field is a convention indicating the sender should provide any/all available end-entity certificates.
The id-kp-ipsecIKE ExtendedKeyUsage keyPurposeID (OID: { id-kp 17 }) is defined to limit certificate use to IKE. If a certificate is intended for both IKE and other EKU-requiring applications, it MUST contain id-kp-ipsecIKE or anyExtendedKeyUsage. The three legacy IPsec EKU OIDs (id-kp-ipsecEndSystem, id-kp-ipsecTunnel, id-kp-ipsecUser) are explicitly deprecated.
The IKE Identification Payload (ID) carries the sender's claimed identity and serves as a lookup key for policy and certificate store queries. The profile mandates support for IP*_ADDR, FQDN, USER_FQDN, and ID_DER_ASN1_DN types; IP ranges, GN, and KEY_ID are prohibited in the certificate context.
Any configuration option that simplifies, modifies, or disables a verification step carries security consequences. All such options MUST default to 'enabled', and it is appropriate to provide warnings to users when disabling features such as certificate chain validation or identity verification.
CERTREQ payload contents are not encrypted in IKE, potentially leaking private information such as trust anchor identities in some environments. Administrators may use empty Certification Authority fields to prevent such leakage at the cost of performance.
In IKEv1 Main Mode, certificates included in message 2 are sent before encryption, violating the identity protection feature. Implementations may wish to delay sending CERT payloads until messages 5 and 6, which offer privacy protection.
Configuration data exchange uses PEM (Base64) encoding with specific delimiters: certificates use '-----BEGIN/END CERTIFICATE-----', CRLs use '-----BEGIN/END CRL-----', raw public keys (SubjectPublicKeyInfo only) use '-----BEGIN/END PUBLIC KEY-----', and PKCS#10 CSRs use '-----BEGIN/END CERTIFICATE REQUEST-----'. Lines SHOULD be less than 76 characters; LF, CR, and CRLF line endings MUST all be accepted.