doc: Add RFC documents

1 files changed, 2411 insertions, 0 deletions

diff --git a/doc/rfc/rfc4945.txt b/doc/rfc/rfc4945.txt
new file mode 100644
index 0000000..4a95ab4
--- /dev/null
+++ b/doc/rfc/rfc4945.txt
@@ -0,0 +1,2411 @@
+
+
+
+
+
+
+Network Working Group                                          B. Korver
+Request for Comments: 4945                       Network Resonance, Inc.
+Category: Standards Track                                    August 2007
+
+
+ The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   The Internet Key Exchange (IKE) and Public Key Infrastructure for
+   X.509 (PKIX) certificate profile both provide frameworks that must be
+   profiled for use in a given application.  This document provides a
+   profile of IKE and PKIX that defines the requirements for using PKI
+   technology in the context of IKE/IPsec.  The document complements
+   protocol specifications such as IKEv1 and IKEv2, which assume the
+   existence of public key certificates and related keying materials,
+   but which do not address PKI issues explicitly.  This document
+   addresses those issues.  The intended audience is implementers of PKI
+   for IPsec.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                     [Page 1]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+Table of Contents
+
+   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
+
+
+
+Korver                      Standards Track                     [Page 2]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+           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 ................................40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                     [Page 3]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+1.  Introduction
+
+   IKE [1], ISAKMP [2], and IKEv2 [3] provide a secure key exchange
+   mechanism for use with IPsec [4] [14].  In many cases, the peers
+   authenticate using digital certificates as specified in PKIX [5].
+   Unfortunately, the combination of these standards leads to an
+   underspecified set of requirements for the use of certificates in the
+   context of IPsec.
+
+   ISAKMP references the PKIX certificate profile but, in many cases,
+   merely specifies the contents of various messages without specifying
+   their syntax or semantics.  Meanwhile, the PKIX certificate profile
+   provides a large set of certificate mechanisms that are generally
+   applicable for Internet protocols, but little specific guidance for
+   IPsec.  Given the numerous underspecified choices, interoperability
+   is hampered if all implementers do not make similar choices, or at
+   least fail to account for implementations that have chosen
+   differently.
+
+   This profile of the IKE and PKIX frameworks is intended to provide an
+   agreed-upon standard for using PKI technology in the context of IPsec
+   by profiling the PKIX framework for use with IKE and IPsec, and by
+   documenting the contents of the relevant IKE payloads and further
+   specifying their semantics.
+
+   In addition to providing a profile of IKE and PKIX, this document
+   attempts to incorporate lessons learned from recent experience with
+   both implementation and deployment, as well as the current state of
+   related protocols and technologies.
+
+   Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and
+   readers of this document are assumed to have read and understood
+   those documents.  The requirements and security aspects of those
+   documents are fully relevant to this document as well.
+
+   This document is organized as follows.  Section 2 defines special
+   terminology used in the rest of this document, Section 3 provides the
+   profile of IKEv1/ISAKMP, Section 4 provides a profile of IKEv2, and
+   Section 5 provides the profile of PKIX.  Section 6 covers conventions
+   for the out-of-band exchange of keying materials for configuration
+   purposes.
+
+2.  Terms and Definitions
+
+   Except for those terms that are defined immediately below, all terms
+   used in this document are defined in either the PKIX [5], ISAKMP [2],
+   IKEv1 [1], IKEv2 [3], or Domain of Interpretation (DOI) [6]
+   documents.
+
+
+
+Korver                      Standards Track                     [Page 4]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   o  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.
+
+   o  FQDN: Fully qualified domain name.
+
+   o  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].
+
+3.  Use of Certificates in RFC 2401 and IKEv1/ISAKMP
+
+3.1.  Identification Payload
+
+   The Identification (ID) Payload indicates the identity claimed by the
+   sender.  The recipient can then use the ID as a lookup key for policy
+   and for certificate lookup in whatever certificate store or directory
+   that it has available.  Our primary concern in this section is to
+   profile the ID payload so that it can be safely used to generate or
+   lookup policy.  IKE mandates the use of the ID payload in Phase 1.
+
+   The DOI [6] defines the 11 types of Identification Data that can be
+   used and specifies the syntax for these types.  These are discussed
+   below in detail.
+
+   The ID payload requirements in this document cover only the portion
+   of the explicit policy checks that deal with the Identification
+   Payload specifically.  For instance, in the case where ID does not
+   contain an IP address, checks such as verifying that the peer source
+   address is permitted by the relevant policy are not addressed here,
+   as they are out of the scope of this document.
+
+   Implementations SHOULD populate ID with identity information that is
+   contained within the end-entity certificate.  Populating ID with
+   identity information from the end-entity certificate enables
+   recipients to use ID as a lookup key to find the peer end-entity
+   certificate.  The only case where implementations may populate ID
+   with information that is not contained in the end-entity certificate
+   is when ID contains the peer source address (a single address, not a
+   subnet or range).
+
+   Because implementations may use ID as a lookup key to determine which
+   policy to use, all implementations MUST be especially careful to
+   verify the truthfulness of the contents by verifying that they
+   correspond to some keying material demonstrably held by the peer.
+
+
+
+Korver                      Standards Track                     [Page 5]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   Failure to do so may result in the use of an inappropriate or
+   insecure policy.  The following sections describe the methods for
+   performing this binding.
+
+   The following table summarizes the binding of the Identification
+   Payload to the contents of end-entity certificates and of identity
+   information to policy.  Each ID type is covered more thoroughly in
+   the following sections.
+
+   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
+            |          |             |          |
+
+   [a] = Implementation MUST have the configuration option to send this
+         ID type in the ID payload.  Whether or not the ID type is used
+         is a matter of local configuration.
+
+   [b] = 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 is not required to be used
+         for this.
+
+   [c] = At a minimum, Implementation MUST be capable of being
+         configured to perform exact matching of the ID payload contents
+         to an entry in the local SPD.
+
+
+
+
+Korver                      Standards Track                     [Page 6]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   [d] = In addition, the implementation MAY also be configurable to
+         perform 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 these ID types are treated the same: as strings that can be
+   compared easily and quickly to a corresponding string in an explicit
+   value in the certificate.  Of these types, FQDN and USER_FQDN are
+   RECOMMENDED over IP addresses (see 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.  In addition,
+   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 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 due
+   to interoperability issues such as 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:
+
+   o  the peer's IP address is static, not dynamically changing
+
+   o  the peer is NOT behind a NAT'ing device
+
+
+
+Korver                      Standards Track                     [Page 7]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   o  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 the "option-to-skip-
+   validation" in order to permit better interoperability as current
+   implementations vary greatly in how they behave on this topic.
+
+   In addition, 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 MAY provide a
+   configuration option for specifying which is to be checked.  If there
+   is 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 the "option-to-skip-validation" in order to permit better
+   interoperability, as current implementations vary greatly in how they
+   behave on the topic of verification of source IP.
+
+   If the default for both the verifications above are enabled, then, by
+   transitive property, the implementation will also be verifying that
+   the peer source IP address matches via a bitwise comparison the
+   contents of the iPAddress field in the SubjectAltName extension in
+   the certificate.  In addition, implementations MAY allow
+   administrators to configure a local policy that explicitly requires
+   that the peer source IP address match via a bitwise comparison the
+   contents of the iPAddress field in the SubjectAltName extension in
+
+
+
+Korver                      Standards Track                     [Page 8]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   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 such 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.
+   Although packet IP addresses are inherently untrustworthy and must
+   therefore be independently verified, it is often useful to use the
+   apparent IP address of the peer to locate 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
+   specifies a particular Certification Authority (CA) that is trusted
+   to issue certificates that contain a valid rfc822Name, which can be
+   used by that implementation to perform authorization based on access
+   control lists (ACLs) after the peer's certificate has been validated.
+   The rfc822Name can then be used to determine the policy that provides
+   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 to be
+   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
+
+   Implementations MUST support the ID_FQDN ID type, generally to
+   support host-based access control lists for hosts without fixed IP
+   addresses.  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.
+
+   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
+
+
+
+Korver                      Standards Track                     [Page 9]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   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
+
+   Implementations MUST support the ID_USER_FQDN ID type, generally to
+   support user-based access control lists for users without fixed IP
+   addresses.  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.
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 10]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   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
+
+   Note that RFC 3779 [13] defines blocks of addresses using the
+   certificate extension identified by:
+
+            id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
+
+   although use of this extension in IKE is considered experimental at
+   this time.
+
+3.1.5.  ID_DER_ASN1_DN
+
+   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
+
+
+
+Korver                      Standards Track                    [Page 11]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   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 used to specify pre-shared keys and thus is out of
+   scope.
+
+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.
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 12]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+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.
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 13]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+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:
+
+      o  X.509 Certificate - Signature
+      o  Revocation Lists (CRL and ARL)
+      o  PKCS #7 wrapped X.509 certificate
+
+   The use of the other types are out of the scope of this document:
+
+      o  X.509 Certificate - Key Exchange
+      o  PGP (Pretty Good Privacy) Certificate
+      o  DNS Signed Key
+      o  Kerberos Tokens
+      o  SPKI (Simple Public Key Infrastructure) Certificate
+      o  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)
+
+   ISAKMP does not support Certificate Payload sizes over approximately
+   64K, which is too small for many CRLs, and UDP fragmentation is
+   likely to occur at sizes much smaller than that.  Therefore, the
+   acquisition of revocation material is to be dealt with out-of-band of
+   IKE.  For this and other reasons, 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.  Upon receipt
+   of such a CERTREQ, implementations MAY ignore the request.
+
+   In lieu of exchanging 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 obtaining revocation information are available,
+   implementations SHOULD be able to process these attributes, and from
+   them be able to identify cached revocation material, or retrieve the
+   relevant revocation material from a URL, for validation processing.
+   In addition, implementations MUST have the ability to configure
+
+
+
+Korver                      Standards Track                    [Page 14]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   validation checking information for each certification authority.
+   Regardless of the method (CDP, AIA, or static configuration), the
+   acquisition of revocation material SHOULD occur out-of-band of IKE.
+   Note, however, that an inability to access revocation status data
+   through out-of-band means provides a potential security vulnerability
+   that could potentially be exploited by an attacker.
+
+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 are unaware
+   of any implementations that generate such CERTREQ messages.
+   Therefore, the use of this type is deprecated.  Implementations
+   SHOULD NOT require CERTREQs that contain this Certificate Type.
+   Implementations that receive CERTREQs that contain 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 does not 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 such that
+   binary comparison of the Subject and the Certification Authority will
+   succeed.
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 15]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   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 unless 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, in the case where multiple end-entity certificates may be
+   available that chain to different trust anchors, implementations
+   SHOULD resort to local heuristics to determine which trust anchor is
+   most appropriate 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.  Although PKIX prohibits certificates with an empty
+   Issuer field, there does exist 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, and so its use is specified, explained here for the sake
+   of interoperability.
+
+   USE CASE: Consider 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
+   simultaneously serving many customers (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 that in total, the
+   gateway has one hundred (100) trust anchors that could possibly used
+   to authenticate an incoming connection.  Assume that many of those
+   connections originate from hosts/gateways with dynamically assigned
+   IP addresses, so that the source IP of the IKE initiator is not known
+   to the gateway, nor is the identity of the initiator (until it is
+   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 will have no idea which of the
+   hundred possible Certification Authorities to send in the CERTREQ.
+   Sending all possible Certification Authorities will cause significant
+   processing delays, bandwidth consumption, and UDP fragmentation, so
+   this tactic is ruled out.
+
+
+
+
+
+Korver                      Standards Track                    [Page 16]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   In such a deployment, the responder gateway implementation should be
+   able to do all it can to indicate a Certification Authority in the
+   CERTREQ.  This means the responder SHOULD first check 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 not
+   familiar, as in the case above), then the responder SHOULD have a
+   configuration option specifying which CAs are the default CAs to
+   indicate in 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 is not configured or impractical in a certain deployment
+   scenario, then the responder implementation SHOULD have both of the
+   following configuration options:
+
+   o  send a CERTREQ payload with an empty Certification Authority
+      field, or
+
+   o  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/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, as it
+   initiated the connection on a matched policy to begin with, and can
+   thus 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 was now able to be matched due
+   to having the initiator's certificate 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.
+
+   The decision of which to configure is a matter of local security
+   policy; 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).
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 17]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+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 which 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 is still necessary to send the normal set of trust anchor CERTREQs
+   because the hints do not sufficiently convey all of the information
+   required by the peer.  Specifically, either the peer may not support
+   this optimization or there may be additional chains that could be
+   used in this context but will not 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.
+
+
+
+Korver                      Standards Track                    [Page 18]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   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 allows implementations to determine unambiguously when a
+   new certificate is being used by a peer (perhaps because the previous
+   certificate has just expired), which may result in a failure because
+   a new intermediate CA certificate might not be 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 retry.
+
+3.2.9.3.  Example
+
+   Imagine that an IKEv1 implementation has previously received and
+   cached the peer certificate chain TA->CA1->CA2->EE.  If, during a
+   subsequent exchange, this implementation sends a CERTREQ containing
+   the Subject field in certificate TA, this implementation is
+   requesting that the peer send at least three certificates: CA1, CA2,
+   and EE.  On the other hand, if this implementation also sends a
+   CERTREQ containing the Subject field of CA2, the implementation is
+   providing a hint that only one certificate needs to be sent: EE.
+   Note that in this example, 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 allows the peer to transmit a single
+   certificate or CRL.  Multiple certificates should be transmitted in
+   multiple payloads.  For backwards-compatibility reasons,
+   implementations MAY send intermediate CA certificates in addition to
+   the appropriate end-entity certificate(s), but SHOULD NOT send any
+   CRLs, ARLs, or trust anchors.  Exchanging trust anchors and
+   especially CRLs and ARLs in IKE would increase the likelihood of UDP
+   fragmentation, make the IKE exchange more complex, and consume
+   additional network bandwidth.
+
+   Note, however, that while the sender of the CERT payloads SHOULD NOT
+   send any certificates it considers trust anchors, it's possible that
+   the recipient may consider any 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 merely
+   including an intermediate CA certificate, while the recipient
+   receives a trust anchor.
+
+
+
+
+
+Korver                      Standards Track                    [Page 19]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   However, not all certificate forms that are legal in the PKIX
+   certificate profile make sense in the context of IPsec.  The issue of
+   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 identifies to the peer the type of
+   certificate keying materials that are included.  ISAKMP defines 10
+   types of Certificate Data that can be sent and specifies the syntax
+   for these types.  For the purposes of this document, only the
+   following types are relevant:
+
+      o  X.509 Certificate - Signature
+      o  Revocation Lists (CRL and ARL)
+      o  PKCS #7 wrapped X.509 certificate
+
+   The use of the other types are out of the scope of this document:
+
+      o  X.509 Certificate - Key Exchange
+      o  PGP Certificate
+      o  DNS Signed Key
+      o  Kerberos Tokens
+      o  SPKI Certificate
+      o  X.509 Certificate Attribute
+
+3.3.2.  X.509 Certificate - Signature
+
+   This type specifies that Certificate Data contains a certificate used
+   for signing.
+
+3.3.3.  Revocation Lists (CRL and ARL)
+
+   These types specify that 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 because several implementations are known to
+   generate them.  Note that those implementations sometimes include
+
+
+
+
+
+Korver                      Standards Track                    [Page 20]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   entire certificate hierarchies inside a single CERT PKCS #7 payload,
+   which violates the requirement specified in ISAKMP that this payload
+   contain a single certificate.
+
+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 does not receive any CERTREQs during an
+   exchange SHOULD NOT send any CERT payloads, except when explicitly
+   configured to proactively send CERT payloads in order to interoperate
+   with non-compliant implementations that fail to send CERTREQs even
+   when certificates are desired.  In this 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 are received.  Such a
+   condition has been known to occur due to non-compliant or buggy
+   implementations.
+
+   Implementations that receive CERTREQs from a peer that contain only
+   unrecognized Certification Authorities MAY elect to terminate the
+   exchange, in order to avoid unnecessary and potentially expensive
+   cryptographic processing, denial-of-service (resource starvation)
+   attacks.
+
+3.3.7.  Response to Multiple Certification Authority Proposals
+
+   In response to multiple CERTREQs that contain different Certification
+   Authority identities, implementations MAY respond using an end-entity
+   certificate which chains to a CA that matches any of the identities
+   provided by the peer.
+
+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 via
+   some preferable means, such as the case where certificates from a
+   previous exchange have been cached.
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 21]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+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 does not 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.
+
+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 are not 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 for including certificates that are irrelevant
+   to an exchange is to minimize the threat of leaking identifying
+   information in exchanges where CERT is not encrypted in IKEv1.  It
+   should be noted, however, that this probably provides rather poor
+   protection against leaking the identity.
+
+
+
+Korver                      Standards Track                    [Page 22]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   Another reason for including certificates that seem irrelevant to an
+   exchange is that there may be two chains from the Certification
+   Authority to the end entity, each of which 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 employ local means to recognize CERTs that have
+   already been received and 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 that 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.
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 23]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+4.  Use of Certificates in RFC 4301 and IKEv2
+
+4.1.  Identification Payload
+
+   The Peer Authorization Database (PAD) as described in RFC 4301 [14]
+   describes the use of the ID payload in IKEv2 and provides a formal
+   model for the binding of identity to policy in addition to providing
+   services that deal more specifically with the details of policy
+   enforcement, which are generally out of scope of this document.  The
+   PAD is intended to provide a link between the SPD and the 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
+   that the initiator may send to the responder in order 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.
+   This is a particularly useful mechanism when the peer is a device
+   with little memory and lower bandwidth, e.g., 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.
+
+
+
+
+
+Korver                      Standards Track                    [Page 24]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+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 is possible to have one side authenticating 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
+
+   This type specifies that Certificate Data contains a hash and the URL
+   to a repository where an X.509 certificate can be retrieved.
+
+   An implementation that sends an HTTP_CERT_LOOKUP_SUPPORTED
+   notification MUST support the http scheme and MAY support the ftp
+   scheme, and MUST NOT require any specific form of the url-path, and
+   it SHOULD support having user-name, password, and port parts in the
+   URL.  The following are examples of mandatory forms:
+
+   o  http://certs.example.com/certificate.cer
+   o  http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400
+   o  http://certs.example.com/%0a/../foo/bar/zappa
+
+   while the following is an example of a form that SHOULD be supported:
+
+   o  http://user:password@certs.example.com:8888/certificate.cer
+
+   FTP MAY be supported, and if it is, the following is an example of
+   the ftp scheme that MUST be supported:
+
+   o  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.  Note that in
+   IKEv2, it is possible to have one side authenticating with
+   certificates while the other side authenticates with pre-shared keys.
+
+4.3.3.  Ordering of Certificate Payloads
+
+   For IKEv2, implementations MUST NOT assume that any but the first
+   CERT is ordered in any way.  IKEv2 specifies that the first CERT
+   contain an end-entity certificate that can be used to authenticate
+   the peer.
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 25]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+5.  Certificate Profile for IKEv1/ISAKMP and IKEv2
+
+   Except where specifically stated in this document, implementations
+   MUST conform to the requirements of the PKIX [5] certificate profile.
+
+5.1.  X.509 Certificates
+
+   Users deploying IKE and IPsec with certificates have often had little
+   control over the capabilities of CAs available to them.
+   Implementations of this specification may include configuration knobs
+   to disable checks required by this specification in order to permit
+   use with inflexible and/or noncompliant CAs.  However, all checks on
+   certificates exist for a specific reason involving the security of
+   the entire system.  Therefore, all checks MUST be enabled by default.
+   Administrators and users ought to understand the security purpose for
+   the various checks, and be clear on what security will be lost by
+   disabling the check.
+
+5.1.1.  Versions
+
+   Although PKIX states that "implementations SHOULD be prepared to
+   accept any version certificate", in practice, this profile requires
+   certain extensions that necessitate the use of Version 3 certificates
+   for all but self-signed certificates used as trust anchors.
+   Implementations that conform to this document MAY therefore reject
+   Version 1 and Version 2 certificates in all other cases.
+
+5.1.2.  Subject
+
+   Certification Authority implementations MUST be able to create
+   certificates with Subject fields with at least the following four
+   attributes: CN, C, O, and OU.  Implementations MAY support other
+   Subject attributes as well.  The contents of these attributes SHOULD
+   be configurable on a certificate-by-certificate basis, as these
+   fields will likely be used by IKE implementations to match SPD
+   policy.
+
+   See Section 3.1.5 for details on 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 that contain an empty
+   Subject field, as specified in the PKIX certificate profile.
+   Identity information in such certificates will be contained entirely
+   in the SubjectAltName extension.
+
+
+
+
+
+Korver                      Standards Track                    [Page 26]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+5.1.2.2.  Specifying Hosts and not FQDN in the Subject Name
+
+   Implementations that desire to place host names that are not intended
+   to be processed by recipients as FQDNs (for instance "Gateway
+   Router") in the Subject MUST use the commonName attribute.
+
+5.1.2.3.  EmailAddress
+
+   As specified in the PKIX certificate profile, implementations MUST
+   NOT populate X.500 distinguished names with the emailAddress
+   attribute.
+
+5.1.3.  X.509 Certificate Extensions
+
+   Conforming IKE implementations MUST recognize extensions that must or
+   may be marked critical according to this specification.  These
+   extensions are: KeyUsage, SubjectAltName, and BasicConstraints.
+
+   Certification Authority implementations SHOULD generate certificates
+   such that the extension criticality bits are set in accordance with
+   the PKIX certificate profile and this document.  With respect to
+   compliance with the PKIX certificate profile, IKE implementations
+   processing certificates MAY ignore the value of the criticality bit
+   for extensions that are supported by that implementation, but MUST
+   support the criticality bit for extensions that are not supported by
+   that implementation.  That is, a relying party SHOULD processes all
+   the extensions it is aware of whether the bit is true or false -- the
+   bit says what happens when a relying party cannot process an
+   extension.
+
+          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           ok
+
+5.1.3.1.  AuthorityKeyIdentifier and SubjectKeyIdentifier
+
+   Implementations SHOULD NOT assume support for the
+   AuthorityKeyIdentifier or SubjectKeyIdentifier extensions.  Thus,
+   Certification Authority implementations should not generate
+   certificate hierarchies that are overly complex to process in the
+   absence of these extensions, such as those that require possibly
+
+
+
+Korver                      Standards Track                    [Page 27]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   verifying a signature against a large number of similarly named CA
+   certificates in order to find the CA certificate that contains the
+   key that was used to generate the signature.
+
+5.1.3.2.  KeyUsage
+
+   IKE uses an end-entity certificate in the authentication process.
+   The end-entity certificate may be used for multiple applications.  As
+   such, the CA can impose some constraints on the manner that a public
+   key ought to be used.  The KeyUsage (KU) and ExtendedKeyUsage (EKU)
+   extensions apply in this situation.
+
+   Since we are talking about using the public key to validate a
+   signature, if the KeyUsage extension is present, then at least one of
+   the digitalSignature or the nonRepudiation bits in the KeyUsage
+   extension MUST be set (both can be set as well).  It is also fine if
+   other KeyUsage bits are set.
+
+   A summary of the logic flow for peer cert validation follows:
+
+   o  If no KU extension, continue.
+
+   o  If KU present and doesn't mention digitalSignature or
+      nonRepudiation (both, in addition to other KUs, is also fine),
+      reject cert.
+
+   o  If none of the above, continue.
+
+5.1.3.3.  PrivateKeyUsagePeriod
+
+   The PKIX certificate profile recommends against the use of this
+   extension.  The PrivateKeyUsageExtension is intended to be used when
+   signatures will need to be verified long past the time when
+   signatures using the private keypair may be generated.  Since IKE
+   security associations (SAs) are short-lived relative to the intended
+   use of this extension in addition to the fact that each signature is
+   validated only a single time, the usefulness of this extension in the
+   context of IKE is unclear.  Therefore, Certification Authority
+   implementations MUST NOT generate certificates that contain the
+   PrivateKeyUsagePeriod extension.  If an IKE implementation receives a
+   certificate with this set, it SHOULD ignore it.
+
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 28]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+5.1.3.4.  CertificatePolicies
+
+   Many IKE implementations do not currently provide support for the
+   CertificatePolicies extension.  Therefore, Certification Authority
+   implementations that generate certificates that contain this
+   extension SHOULD NOT mark the extension as critical.  As is the case
+   with all certificate extensions, a relying party receiving this
+   extension but who can process the extension SHOULD NOT reject the
+   certificate because it contains the extension.
+
+5.1.3.5.  PolicyMappings
+
+   Many IKE implementations do not support the PolicyMappings extension.
+   Therefore, implementations that generate certificates that contain
+   this extension SHOULD NOT mark the extension as critical.
+
+5.1.3.6.  SubjectAltName
+
+   Deployments that intend to use an ID of FQDN, USER_FQDN, IPV4_ADDR,
+   or IPV6_ADDR MUST issue certificates with the corresponding
+   SubjectAltName fields populated with the same data.  Implementations
+   SHOULD generate only the following GeneralName choices in the
+   SubjectAltName extension, as these choices map to legal IKEv1/ISAKMP/
+   IKEv2 Identification Payload types: rfc822Name, dNSName, or
+   iPAddress.  Although it is possible to specify any GeneralName choice
+   in the Identification Payload by using the ID_DER_ASN1_GN ID type,
+   implementations SHOULD NOT assume support for such functionality, and
+   SHOULD NOT generate certificates that do so.
+
+5.1.3.6.1.  dNSName
+
+   If the IKE ID type is FQDN, then this field MUST contain a fully
+   qualified domain name.  If the IKE ID type is FQDN, then the dNSName
+   field MUST match its contents.  Implementations MUST NOT generate
+   names that contain wildcards.  Implementations MAY treat certificates
+   that contain wildcards in this field as syntactically invalid.
+
+   Although this field is in the form of an FQDN, IKE implementations
+   SHOULD NOT assume that this field contains an FQDN that will resolve
+   via the DNS, unless this is known by way of some out-of-band
+   mechanism.  Such a mechanism is out of the scope of this document.
+   Implementations SHOULD NOT treat the failure to resolve as an error.
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 29]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+5.1.3.6.2.  iPAddress
+
+   If the IKE ID type is IPV4_ADDR or IPV6_ADDR, then the iPAddress
+   field MUST match its contents.  Note that although PKIX permits CIDR
+   [15] notation in the "Name Constraints" extension, the PKIX
+   certificate profile explicitly prohibits using CIDR notation for
+   conveying identity information.  In other words, the CIDR notation
+   MUST NOT be used in the SubjectAltName extension.
+
+5.1.3.6.3.  rfc822Name
+
+   If the IKE ID type is USER_FQDN, then the rfc822Name field MUST match
+   its contents.  Although this field is in the form of an Internet mail
+   address, IKE implementations SHOULD NOT assume that this field
+   contains a valid email address, unless this is known by way of some
+   out-of-band mechanism.  Such a mechanism is out of the scope of this
+   document.
+
+5.1.3.7.  IssuerAltName
+
+   Certification Authority implementations SHOULD NOT assume that other
+   implementations support the IssuerAltName extension, and especially
+   should not assume that information contained in this extension will
+   be displayed to end users.
+
+5.1.3.8.  SubjectDirectoryAttributes
+
+   The SubjectDirectoryAttributes extension is intended to convey
+   identification attributes of the subject.  IKE implementations MAY
+   ignore this extension when it is marked non-critical, as the PKIX
+   certificate profile mandates.
+
+5.1.3.9.  BasicConstraints
+
+   The PKIX certificate profile mandates that CA certificates contain
+   this extension and that it be marked critical.  IKE implementations
+   SHOULD reject CA certificates that do not contain this extension.
+   For backwards compatibility, implementations may accept such
+   certificates if explicitly configured to do so, but the default for
+   this setting MUST be to reject such certificates.
+
+5.1.3.10.  NameConstraints
+
+   Many IKE implementations do not support the NameConstraints
+   extension.  Since the PKIX certificate profile mandates that this
+   extension be marked critical when present, Certification Authority
+   implementations that are interested in maximal interoperability for
+   IKE SHOULD NOT generate certificates that contain this extension.
+
+
+
+Korver                      Standards Track                    [Page 30]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+5.1.3.11.  PolicyConstraints
+
+   Many IKE implementations do not support the PolicyConstraints
+   extension.  Since the PKIX certificate profile mandates that this
+   extension be marked critical when present, Certification Authority
+   implementations that are interested in maximal interoperability for
+   IKE SHOULD NOT generate certificates that contain this extension.
+
+5.1.3.12.  ExtendedKeyUsage
+
+   The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in
+   certificates for use with IKE.  Note that there were three IPsec-
+   related object identifiers in EKU that were assigned in 1999.  The
+   semantics of these values were never clearly defined.  The use of
+   these three EKU values in IKE/IPsec is obsolete and explicitly
+   deprecated by this specification.  CAs SHOULD NOT issue certificates
+   for use in IKE with them.  (For historical reference only, those
+   values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-
+   ipsecUser.)
+
+   The CA SHOULD NOT mark the EKU extension in certificates for use with
+   IKE and one or more other applications.  Nevertheless, this document
+   defines an ExtendedKeyUsage keyPurposeID that MAY be used to limit a
+   certificate's use:
+
+   id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
+
+   where id-kp is defined in RFC 3280 [5].  If a certificate is intended
+   to be used with both IKE and other applications, and one of the other
+   applications requires use of an EKU value, then such certificates
+   MUST contain either the keyPurposeID id-kp-ipsecIKE or
+   anyExtendedKeyUsage [5], as well as the keyPurposeID values
+   associated with the other applications.  Similarly, if a CA issues
+   multiple otherwise-similar certificates for multiple applications
+   including IKE, and it is intended that the IKE certificate NOT be
+   used with another application, the IKE certificate MAY contain an EKU
+   extension listing a keyPurposeID of id-kp-ipsecIKE to discourage its
+   use with the other application.  Recall, however, that EKU extensions
+   in certificates meant for use in IKE are NOT RECOMMENDED.
+
+   Conforming IKE implementations are not required to support EKU.  If a
+   critical EKU extension appears in a certificate and EKU is not
+   supported by the implementation, then RFC 3280 requires that the
+   certificate be rejected.  Implementations that do support EKU MUST
+   support the following logic for certificate validation:
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 31]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   o  If no EKU extension, continue.
+
+   o  If EKU present AND contains either id-kp-ipsecIKE or
+      anyExtendedKeyUsage, continue.
+
+   o  Otherwise, reject cert.
+
+5.1.3.13.  CRLDistributionPoints
+
+   Because this document deprecates the sending of CRLs in-band, the use
+   of CRLDistributionPoints (CDP) becomes very important if CRLs are
+   used for revocation checking (as opposed to, say, Online Certificate
+   Status Protocol - OCSP [16]).  The IPsec peer either needs to have a
+   URL for a CRL written into its local configuration, or it needs to
+   learn it from CDP.  Therefore, Certification Authority
+   implementations SHOULD issue certificates with a populated CDP.
+
+   Failure to validate the CRLDistributionPoints/
+   IssuingDistributionPoint pair can result in CRL substitution where an
+   entity knowingly substitutes a known good CRL from a different
+   distribution point for the CRL that is supposed to be used, which
+   would show the entity as revoked.  IKE implementations MUST support
+   validating that the contents of CRLDistributionPoints match those of
+   the IssuingDistributionPoint to prevent CRL substitution when the
+   issuing CA is using them.  At least one CA is known to default to
+   this type of CRL use.  See Section 5.2.2.5 for more information.
+
+   CDPs SHOULD be "resolvable".  Several non-compliant Certification
+   Authority implementations are well known for including unresolvable
+   CDPs like http://localhost/path_to_CRL and http:///path_to_CRL that
+   are equivalent to failing to include the CDP extension in the
+   certificate.
+
+   See the IETF IPR Web page for CRLDistributionPoints intellectual
+   property rights (IPR) information.  Note that both the
+   CRLDistributionPoints and IssuingDistributionPoint extensions are
+   RECOMMENDED but not REQUIRED by the PKIX certificate profile, so
+   there is no requirement to license any IPR.
+
+5.1.3.14.  InhibitAnyPolicy
+
+   Many IKE implementations do not support the InhibitAnyPolicy
+   extension.  Since the PKIX certificate profile mandates that this
+   extension be marked critical when present, Certification Authority
+   implementations that are interested in maximal interoperability for
+   IKE SHOULD NOT generate certificates that contain this extension.
+
+
+
+
+
+Korver                      Standards Track                    [Page 32]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+5.1.3.15.  FreshestCRL
+
+   IKE implementations MUST NOT assume that the FreshestCRL extension
+   will exist in peer certificates.  Note that most IKE implementations
+   do not support delta CRLs.
+
+5.1.3.16.  AuthorityInfoAccess
+
+   The PKIX certificate profile defines the AuthorityInfoAccess
+   extension, 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 the sending of CRLs in-
+   band, the use of AuthorityInfoAccess (AIA) becomes very important if
+   OCSP [16] is to be used for revocation checking (as opposed to CRLs).
+   The IPsec peer either needs to have a URI for the OCSP query written
+   into its local configuration, or it needs to learn it from AIA.
+   Therefore, implementations SHOULD support this extension, especially
+   if OCSP will be used.
+
+5.1.3.17.  SubjectInfoAccess
+
+   The PKIX certificate profile defines the SubjectInfoAccess
+   certificate extension, which is used to indicate "how to access
+   information and services for the subject of the certificate in which
+   the extension appears".  This extension has no known use in the
+   context of IPsec.  Conformant IKE implementations SHOULD ignore this
+   extension when present.
+
+5.2.  X.509 Certificate Revocation Lists
+
+   When validating certificates, IKE implementations MUST make use of
+   certificate revocation information, and SHOULD support such
+   revocation information in the form of CRLs, unless non-CRL revocation
+   information is known to be the only method for transmitting this
+   information.  Deployments that intend to use CRLs for revocation
+   SHOULD populate the CRLDistributionPoints extension.  Therefore,
+   Certification Authority implementations MUST support issuing
+   certificates with this field populated.  IKE implementations MAY
+   provide a configuration option to disable use of certain types of
+   revocation information, but that option MUST be off by default.  Such
+   an option is often valuable in lab testing environments.
+
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 33]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+5.2.1.  Multiple Sources of Certificate Revocation Information
+
+   IKE implementations that support multiple sources of obtaining
+   certificate revocation information MUST act conservatively when the
+   information provided by these sources is inconsistent: when a
+   certificate is reported as revoked by one trusted source, the
+   certificate MUST be considered revoked.
+
+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, and
+   thus should not generate certificate hierarchies which are overly
+   complex to process in the absence of this extension, such as those
+   that require possibly verifying a signature against a large number of
+   similarly named CA certificates in order to find the CA certificate
+   which contains the key that was used to generate the signature.
+
+5.2.2.2.  IssuerAltName
+
+   Certification Authority implementations SHOULD NOT assume that IKE
+   implementations support the IssuerAltName extension, and especially
+   should not assume that information contained in this extension will
+   be displayed to end users.
+
+5.2.2.3.  CRLNumber
+
+   As stated in the PKIX certificate profile, 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 do not support delta CRLs MUST reject CRLs
+   that contain the DeltaCRLIndicator (which MUST be marked critical
+   according to the PKIX certificate profile) and MUST make use of a
+   base CRL if it is available.  Such implementations MUST ensure that a
+   delta CRL does not "overwrite" a base CRL, for instance, in the
+   keying material database.
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 34]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+5.2.2.4.2.  Delta CRL Recommendations
+
+   Since some IKE implementations that do not support delta CRLs may
+   behave incorrectly or insecurely when presented with delta CRLs,
+   administrators and deployers should consider whether issuing delta
+   CRLs increases security before issuing such CRLs.  And, if all the
+   elements in the VPN and PKI systems do not adequately support Delta
+   CRLs, then their use should be questioned.
+
+   The editors are aware of several implementations that behave in an
+   incorrect or insecure manner when presented with delta CRLs.  See
+   Appendix A for a description of the issue.  Therefore, this
+   specification RECOMMENDS NOT issuing delta CRLs at this time.  On the
+   other hand, failure to issue delta CRLs may expose a larger window of
+   vulnerability if a full CRL is not issued as often as delta CRLs
+   would be.  See the Security Considerations section of the PKIX [5]
+   certificate profile for additional discussion.  Implementers as well
+   as administrators are encouraged to consider these issues.
+
+5.2.2.5.  IssuingDistributionPoint
+
+   A CA that is using CRLDistributionPoints may do so to provide many
+   "small" CRLs, each only valid for a particular set of certificates
+   issued by that CA.  To associate a CRL with a certificate, the CA
+   places the CRLDistributionPoints extension in the certificate, and
+   places 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
+
+   At the time that this document is being written, popular
+   certification authorities and CA software issue certificates using
+   the RSA-with-SHA1 and RSA-with-MD5 signature algorithms.
+   Implementations MUST be able to validate certificates with either of
+   those algorithms.
+
+
+
+
+
+Korver                      Standards Track                    [Page 35]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   As described in [17], both the MD5 and SHA-1 hash algorithms are
+   weaker than originally expected with respect to hash collisions.
+   Certificates that use these hash algorithms as part of their
+   signature algorithms could conceivably be subject to an attack where
+   a CA issues a certificate with a particular identity, and the
+   recipient of that certificate can create a different valid
+   certificate with a different identity.  So far, such an attack is
+   only theoretical, even with the weaknesses found in the hash
+   algorithms.
+
+   Because of the recent attacks, there has been a heightened interest
+   in having widespread deployment of additional signature algorithms.
+   The algorithm that has been mentioned most often is RSA-with-SHA256,
+   two types of which are described in detail in [18].  It is widely
+   expected that this signature algorithm will be much more resilient to
+   collision-based attacks than the current RSA-with-SHA1 and RSA-with-
+   MD5, although no proof of that has been shown.  There is active
+   discussion in the cryptographic community of better hash functions
+   that could be used in signature algorithms.
+
+   In order to interoperate, all implementations need to be able to
+   validate signatures for all algorithms that the implementations will
+   encounter.  Therefore, implementations SHOULD be able to use
+   signatures that use the sha256WithRSAEncryption signature algorithm
+   (PKCS#1 version 1.5) as soon as possible.  At the time that this
+   document is being written, there is at least one CA that supports
+   generating certificates with sha256WithRSAEncryption signature
+   algorithm, and it is expected that there will 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.
+
+6.1.  Certificates
+
+   Certificates MUST be Base64 [19] encoded and appear between the
+   following delimiters:
+
+            -----BEGIN CERTIFICATE-----
+            -----END CERTIFICATE-----
+
+
+
+
+Korver                      Standards Track                    [Page 36]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+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 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
+
+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 prevent such information from leaking, at the cost of
+   performance.
+
+7.2.  IKEv1 Main Mode
+
+   Certificates may be included in any message, and therefore
+   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, thereby violating the identity protection feature of Main
+   Mode in IKEv1.
+
+
+
+
+
+Korver                      Standards Track                    [Page 37]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+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.
+
+
+
+
+Korver                      Standards Track                    [Page 38]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   [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.
+
+
+
+
+
+Korver                      Standards Track                    [Page 39]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+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:
+
+   o  fetch newest CRL
+
+   o  check validity of CRL signature
+
+   o  if CRL signature is valid, then
+
+   o  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
+
+   Sending empty certificate requests is commonly used in
+   implementations, and in the IPsec interop meetings, vendors have
+   generally agreed that it means that send all/any end-entity
+   certificates you have (if multiple end-entity certificates are sent,
+   they must have same public key, as otherwise, the other end does not
+   know which key was used).  For 99% of cases, the client has exactly
+   one certificate and public key, so it really doesn't matter, but the
+   server might have multiple; thus, it simply needs to say to the
+   client, use any certificate you have.  If we are talking about
+   corporate VPNs, etc., even if the client has multiple certificates or
+   keys, all of them would be usable when authenticating to the server,
+   so the client can simply pick one.
+
+   If there is some real difference on which certificate to use (like
+   ones giving different permissions), then the client must be
+   configured anyway, or it might even ask the user which one to use
+
+
+
+Korver                      Standards Track                    [Page 40]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   (the user is the only one who knows whether he needs admin
+   privileges, thus needs to use admin cert, or if the normal email
+   privileges are ok, thus uses email only cert).
+
+   In 99% of the cases, the client has exactly one certificate, so it
+   will send it.  In 90% of the rest of the cases, any of the
+   certificates is ok, as they are simply different certificates from
+   the same CA, or from different CAs for the same corporate VPN, thus
+   any of them is ok.
+
+   Sending empty certificate requests has been agreed there to mean
+   "give me your cert, any cert".
+
+   Justification:
+
+   o  Responder first does all it can to send a CERTREQ with a CA, check
+      for IP match in SPD, have a default set of CAs to use in ambiguous
+      cases, etc.
+
+   o  Sending empty CERTREQs is fairly common in implementations today,
+      and is generally accepted to mean "send me a certificate, any
+      certificate that works for you".
+
+   o  Saves responder sending potentially hundreds of certs, the
+      fragmentation problems that follow, etc.
+
+   o  In +90% of use cases, Initiators have exactly one certificate.
+
+   o  In +90% of the remaining use cases, the multiple certificates it
+      has are issued by the same CA.
+
+   o  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 following example shows why initiators need to have sufficient
+   policy definition to know which certificate to use for a given
+   connection it initiates.
+
+   EXAMPLE: Your client (initiator) is configured with VPN policies for
+   gateways A and B (representing perhaps corporate partners).
+
+
+
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 41]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+   The policies for the two gateways look something like:
+
+         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=BizcoPartners
+
+   You are an employee of Acme and you are issued the following
+   certificates:
+
+   o  From CA-A: CN=JoeUser,OU=Engineering
+   o  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 is not configured to
+   know the local credential to use for the remote gateway, this
+   scenario will not work either.  If you attempt to connect to Bizco,
+   everything will work... as you are presented with responding with a
+   certificate signed by CA-B or CA-C... as you only have a certificate
+   from CA-B you are OK.  If you attempt to connect to Acme, you have an
+   issue because you are presented with an ambiguous policy selection.
+   As the initiator, you will be presented with certificate requests
+   from both CA-A and CA-B.  You have certificates issued by both CAs,
+   but only one of the certificates will be usable.  How does the client
+   know which certificate it should present?  It must have sufficiently
+   clear local policy specifying which one credential to present for the
+   connection it initiates.
+
+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.com
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 42]
+
+RFC 4945            PKI Profile for IKE/ISAKMP/PKIX          August 2007
+
+
+Full Copyright Statement
+
+   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 takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Korver                      Standards Track                    [Page 43]
+