[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
                                                           Brian Korver
                                                        Xythos Software
                                                          Eric Rescorla
INTERNET-DRAFT                                                RTFM, Inc.
<draft-ietf-ipsec-pki-profile-04.txt>       Feb 2004 (Expires Jul 2004)


      The Internet IP Security PKI Profile of IKE/ISAKMP and PKIX


Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''


   To learn the current status of any Internet-Draft, please check the


   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).



Abstract


   ISAKMP and PKIX both provide frameworks that must be profiled for use
   in a given application. This document provides a profile of ISAKMP
   and PKIX that defines the requirements for using PKI technology in
   the context of IPsec. The document complements protocol
   specifications such as IKE, 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.



Table of Contents


1           Introduction                                                   4
2           Terms and Definitions                                          5
3           Profile of IKE/ISAKMP                                          5
  3.1         Identification Payload                                       5
    3.1.1       ID_IPV4_ADDR and ID_IPV6_ADDR                              7
    3.1.2       ID_FQDN                                                    8
    3.1.3       ID_USER_FQDN                                               8




Korver, Rescorla                                                 [Page 1]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



    3.1.4       ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_A... 9
    3.1.5       ID_DER_ASN1_DN                                             9
    3.1.6       ID_DER_ASN1_GN                                            10
    3.1.7       ID_KEY_ID                                                 10
    3.1.8       Selecting an Identity from a Certificate                  10
    3.1.9       Transitively Binding Identity to Policy                   10
  3.2         Certificate Request Payload                                 10
    3.2.1       Certificate Type                                          11
    3.2.2       X.509 Certificate - Signature                             11
    3.2.3       Certificate Revocation List (CRL)                         11
    3.2.4       Authority Revocation List (ARL)                           11
    3.2.5       PKCS #7 wrapped X.509 certificate                         12
    3.2.6       Presence or Absence of Certificate Request Payloads       12
    3.2.7       Certificate Requests                                      12
      3.2.7.1     Specifying Certificate Authorities                      12
      3.2.7.2     Empty Certificate Authority Field                       12
    3.2.8       Robustness                                                13
      3.2.8.1     Unrecognized or Unsupported Certificate Types           13
      3.2.8.2     Undecodable Certificate Authority Fields                13
      3.2.8.3     Ordering of Certificate Request Payloads                13
    3.2.9       Optimizations                                             13
      3.2.9.1     Duplicate Certificate Request Payloads                  13
      3.2.9.2     Name Lowest 'Common' Certification Authorities          13
      3.2.9.3     Example                                                 14
  3.3         Certificate Payload                                         14
    3.3.1       Certificate Type                                          14
    3.3.2       X.509 Certificate - Signature                             15
    3.3.3       Certificate Revocation List (CRL)                         15
    3.3.4       Authority Revocation List (ARL)                           15
    3.3.5       PKCS #7 wrapped X.509 certificate                         15
    3.3.6       Certificate Payloads Not Mandatory                        15
    3.3.7       Response to Multiple Certificate Authority Proposals      16
    3.3.8       Using Local Keying Materials                              16
    3.3.9       Robustness                                                16
      3.3.9.1     Unrecognized or Unsupported Certificate Types           16
      3.3.9.2     Undecodable Certificate Data Fields                     16
      3.3.9.3     Ordering of Certificate Payloads                        16
      3.3.9.4     Duplicate Certificate Payloads                          17
      3.3.9.5     Irrelevant Certificates                                 17
    3.3.10      Optimizations                                             17
      3.3.10.1    Duplicate Certificate Payloads                          17
      3.3.10.2    Send Lowest 'Common' Certificates                       17
      3.3.10.3    Ignore Duplicate Certificate Payloads                   17
    3.3.11      Hash Payload                                              18
4           Profile of PKIX                                               18
  4.1         X.509 Certificates                                          18
    4.1.1       Versions                                                  18
    4.1.2       Subject Name                                              18




Korver, Rescorla                                                 [Page 2]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



      4.1.2.1     Empty Subject Name                                      18
      4.1.2.2     Specifying Non-FQDN Hosts in Subject Name               18
      4.1.2.3     Specifying FQDN Host Names in Subject Name              19
      4.1.2.4     EmailAddress                                            19
    4.1.3       X.509 Certificate Extensions                              19
      4.1.3.1     AuthorityKeyIdentifier                                  19
      4.1.3.2     SubjectKeyIdentifier                                    20
      4.1.3.3     KeyUsage                                                20
      4.1.3.4     PrivateKeyUsagePeriod                                   20
      4.1.3.5     Certificate Policies                                    20
      4.1.3.6     PolicyMappings                                          20
      4.1.3.7     SubjectAltName                                          21
        4.1.3.7.1   dNSName                                               21
        4.1.3.7.2   iPAddress                                             21
        4.1.3.7.3   rfc822Name                                            21
      4.1.3.8     IssuerAltName                                           21
      4.1.3.9     SubjectDirectoryAttributes                              22
      4.1.3.10    BasicConstraints                                        22
      4.1.3.11    NameConstraints                                         22
      4.1.3.12    PolicyConstraints                                       22
      4.1.3.13    ExtendedKeyUsage                                        22
      4.1.3.14    CRLDistributionPoints                                   23
      4.1.3.15    InhibitAnyPolicy                                        23
      4.1.3.16    FreshestCRL                                             23
      4.1.3.17    AuthorityInfoAccess                                     23
      4.1.3.18    SubjectInfoAccess                                       23
  4.2         X.509 Certificate Revocation Lists                          24
    4.2.1       Multiple Sources of Certificate Revocation Informati... 24
    4.2.2       X.509 Certificate Revocation List Extensions              24
      4.2.2.1     AuthorityKeyIdentifier                                  24
      4.2.2.2     IssuerAltName                                           24
      4.2.2.3     CRLNumber                                               24
      4.2.2.4     DeltaCRLIndicator                                       24
        4.2.2.4.1   If Delta CRLs Are Unsupported                         25
        4.2.2.4.2   Delta CRL Recommendations                             25
      4.2.2.5     IssuingDistributionPoint                                25
      4.2.2.6     FreshestCRL                                             25
5           Configuration Data Exchange Conventions                       25
  5.1         Certificates                                                26
  5.2         Public Keys                                                 26
  5.3         PKCS#10 Certificate Signing Requests                        26
6           Security Considerations                                       26
  6.1         Identity Payload                                            26
  6.2         Certificate Request Payload                                 27
  6.3         Certificate Payload                                         27
  6.4         IKE Main Mode                                               27
7           Intellectual Property Rights                                  27
8           IANA Considerations                                           27




Korver, Rescorla                                                 [Page 3]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



9           Normative References                                          27
10          Informational References                                      28
11          Acknowledgements                                              28
12          Author's Addresses                                            28


1. Introduction


   IKE [IKE] and ISAKMP [ISAKMP] provide a secure key exchange mechanism
   for use with IPsec [IPSEC]. In many cases the peers authenticate
   using digital certificates as specified in PKIX [PKIX].
   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 PKIX but in many cases merely specifies the
   contents of various messages without specifying their syntax or
   semantics. Meanwhile, PKIX provides a large set of certificate
   mechanisms which are generally applicable for Internet protocols, but
   little specific guidance for IPsec. Given the numerous underspecified
   choices, interoperability is hampered if all implementors do not make
   similar choices, or at least fail to account for implementations
   which have chosen differently.


   This profile of the ISAKMP 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 ISAKMP and IPsec,
   and by documenting the contents of the relevant ISAKMP payloads and
   further specifying their semantics.


   In addition to providing a profile of ISAKMP 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 and PKIX is not repeated here, and readers of
   this document are assumed to have read and understood both 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 IKE/ISAKMP and Section 4 provides the profile of PKIX.
   Section 5 covers conventions for the out-of-band exchange of keying
   materials for configuration purposes.


   This document is being discussed on the pki4ipsec@icsalabs.com
   mailing list.





Korver, Rescorla                                                 [Page 4]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



2. Terms and Definitions


   Except for those terms which are defined immediately below, all terms
   used in this document are defined in either the PKIX, ISAKMP, or DOI
   [DOI] documents.


   * Peer source address: The source address in packets from a peer.
   This address may be different from any addresses asserted as the
   "identity" of the peer.
   * FQDN:  Fully qualified domain name.


   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 [RFC2119].


3. Profile of IKE/ISAKMP


3.1. Identification Payload


   The Identification (ID) Payload is used to indicate the identity that
   the agent claims to be speaking for. The receiving agent can then use
   the ID as a lookup key for policy and whatever certificate store or
   directory that it has available. Our primary concern in this document
   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] 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 Identity 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. This 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). This means that implementations MUST be able to map a peer
   source address to a peer end entity certificate, even when the
   certificate does not contain that address. The exact method for
   performing this mapping is out of the scope of this document.




Korver, Rescorla                                                 [Page 5]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   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.
   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.


      ID type  | Support  | Correspond  | Cert     | SPD lookup
               | for send | PKIX Attrib | matching | rules
      -------------------------------------------------------------------
               |          |             |          |
      IP*_ADDR | MUST [1] | SubjAltName | MUST [2] | MUST [3]
               |          | iPAddress   |          |
               |          |             |          |
      FQDN     | MUST [1] | SubjAltName | MUST [2] | MUST [3]
               |          | dNSName     |          |
               |          |             |          |
      USER_FQDN| MUST [1] | SubjAltName | MUST [2] | MUST [3]
               |          | rfc822Name  |          |
               |          |             |          |
      DN       | MUST [1] | Entire      | MUST [2] | MUST support lookup
               |          | Subject,    |          | on any combination
               |          | bitwise     |          | of C, CN, O, or OU
               |          | compare     |          |
               |          |             |          |
      IP range | MUST NOT | n/a         | n/a      | n/a
               |          |             |          |
               |          |             |          |
      KEY_ID   | MUST NOT | n/a         | n/a      | n/a
               |          |             |          |


      [1] = MUST be able to send based on local configuration.


      [2] = 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 SPD lookup, but is
      not required to be used for this.


      [3] = MUST be able to support exact matching in the SPD, but MAY
      also support substring or wildcard matches.


   When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN,
   implementations MUST be configurable to send the same string as




Korver, Rescorla                                                 [Page 6]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   appears in the corresponding SubjectAltName attribute. Recipients MAY
   use wildcards to do the SPD matching.



   When sending a DN as ID, implementations MUST send the entire DN in
   ID. Recipients MAY perform SPD lookup based on some combination of C,
   CN, O, OU. Implementations MUST at a minimum be configurable to match
   on any combination of those 4 attributes. Implementations MAY support
   matching using other DN attributes in any combination, including the
   entire DN.



3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR


   Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR
   ID type. These addresses MUST be stored in "network byte order," as
   specified in [RFC791]. 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
   [RFC791]. For the ID_IPV6_ADDR type, the payload MUST contain exactly
   sixteen octets [RFC1883]. When comparing the contents of ID with the
   iPAddress field in the subjectAltName extension for equality, binary
   comparison MUST be performed.


   Implementations MUST verify that the address contained in ID is the
   same as the peer source address. If the end entity certificate
   contains address identities, then the peer source address must match
   at least one of those identities. If either of the above do not
   match, this MUST be treated as an error and security association
   setup MUST be aborted. This event SHOULD be auditable. In addition,
   implementations MUST allow administrators to configure a local policy
   that requires that the peer source address exist in the certificate.
   Implementations SHOULD allow administrators to configure a local
   policy that does not enforce this requirement.


   Implementations MAY use the IP address found in the header of packets
   received from the peer to lookup 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 CA that is trusted to issue certificates which
   contain a valid rfc822Name which can be used by that implementation




Korver, Rescorla                                                 [Page 7]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   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. Whether the address need appear as an identity in the
   certificate is a matter of local policy, and SHOULD be configurable
   by an administrator.


   As a general comment, however, it may be easier to spoof the contents
   of an ID payload than it is to spoof a peer source address because
   the peer source address must exist on the route to the peer, while ID
   can contain essentially random identification information.
   Implementations MUST validate the Identity Data provided by a peer,
   but implementations MAY wish to favor unauthenticated peer source
   addresses over an unauthenticated ID for initial policy lookup.


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, such as when [DNSSEC] is employed.
   When comparing the contents of ID with the dNSName field in the
   subjectAltName extension for equality, caseless string comparison
   MUST be performed. Substring, wildcard, or regular expression
   matching MUST NOT be performed.


   Implementations MUST verify that the identity contained in the ID
   payload matches identity information contained in the peer end entity
   certificate, in the subjectAltName extension. 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.


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, such as when [DNSSEC] is
   employed. When comparing the contents of ID with the rfc822Name field
   in the subjectAltName extension for equality, caseless string




Korver, Rescorla                                                 [Page 8]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   comparison MUST be performed. Substring, wildcard, or regular
   expression matching MUST NOT be performed.


   Implementations MUST verify that the identity contained in the ID
   payload matches identity information contained in the peer end entity
   certificate, in the subjectAltName extension. 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.


3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE,
ID_IPV6_ADDR_RANGE


   As there is currently no standard method for putting address subnet
   or range identity information into certificates, the use of these ID
   types is currently undefined. Implementations MUST NOT generate these
   ID types.


      Note that work in [SBGP] for defining blocks of addresses using
      the certificate extension identified by


         id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }


      is experimental at this time.


3.1.5. ID_DER_ASN1_DN


   Implementations MUST support receiving the ID_DER_ASN1_DN ID type.
   Implementations MAY generate this type. Implementations which
   generate this type MUST populate the contents of ID with the Subject
   Name from the end entity certificate, and MUST do so such that a
   binary comparison of the two will succeed. For instance, if the
   certificate was erroneously created such that the encoding of the
   Subject Name DN varies from the constraints set by DER, that non-
   conformant DN MUST be used to populate the ID payload: in other
   words, implementations MUST NOT re-encode the DN for the purposes of
   making it DER if it does not appear in the certificate as DER.
   Implementations MUST NOT populate ID with the Subject Name from the
   end entity certificate if it is empty, as described in the "Subject"
   section of PKIX.


   Implementations MUST verify that the identity contained in the ID
   payload matches identity information contained in the peer end entity
   certificate, in the Subject Name field. 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.







Korver, Rescorla                                                 [Page 9]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



3.1.6. ID_DER_ASN1_GN


   Implementations MUST NOT generate this type.


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. 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 Name.


   Which identity an implementation chooses to populate ID with is a
   local matter. For compatibility with non-conformant implementations,
   implementations SHOULD populate ID with whichever identity is likely
   to be named in the peer's policy. In practice, this generally means
   IP address, FQDN, or USER-FQDN.


3.1.9. Transitively Binding Identity to Policy


   In the presence of certificates that contain multiple identities,
   implementations SHOULD NOT assume that a peer will choose the most
   appropriate identity with which to populate ID. Therefore, when
   determining the appropriate policy, implementations SHOULD select the
   most appropriate identity to use from the identities contained in the
   certificate.


   For example, imagine that a peer is configured with a certificate
   that contains both a non-empty Subject Name and an dNSName.
   Independent of which identity is used to populate ID, the host
   implementation MUST locate the proper policy. For instance, if ID
   contains the peer Subject Name, then the peer end entity certificate
   may be found using the Subject Name as a key. Once the certificate
   has been located and then validated, the dNSName in the certificate
   can be used to locate the appropriate policy. In other words, the
   Subject Name is used to find the certificate, the certificate
   contains the dNSName, and the dNSName is used to lookup policy.




3.2. Certificate Request Payload


   The Certificate Request (CERTREQ) Payload allows an ISAKMP
   implementation to request that a peer provide some set of




Korver, Rescorla                                                [Page 10]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   certificates or certificate revocation lists. It is not clear from
   ISAKMP exactly how that set should be specified or how the peer
   should respond. We describe the semantics on both sides.


3.2.1. Certificate Type


   The Certificate Type field identifies to the peer the type of
   certificate keying materials that are desired. ISAKMP defines 10
   types of Certificate Data that can be requested and specifies the
   syntax for these types. For the purposes of this document, only the
   following types are relevant:


   * X.509 Certificate - Signature
   * Certificate Revocation List (CRL)
   * Authority Revocation List (ARL)
   * PKCS #7 wrapped X.509 certificate


   The use of the other types:


   * X.509 Certificate - Key Exchange
   * PGP Certificate
   * DNS Signed Key
   * Kerberos Tokens
   * SPKI Certificate
   * X.509 Certificate - Attribute


   are out of the scope of this document.


3.2.2. X.509 Certificate - Signature


   This type requests that the end entity certificate be a signing
   certificate. Implementations that receive CERTREQs which contain this
   ID type in a context in which end entity signature certificates are
   not used SHOULD ignore such CERTREQs.


3.2.3. Certificate Revocation List (CRL)


   ISAKMP does not support Certificate Payload sizes over approximately
   64K, which is too small for many CRLs. For this and other reasons,
   implementations SHOULD NOT generate CERTREQs where the Certificate
   Type is "Certificate Revocation List (CRL)". Upon receipt of such a
   CERTREQ, implementations MAY ignore the request.


3.2.4. Authority Revocation List (ARL)


   Implementations SHOULD NOT generate CERTREQ payloads with this type.
   Recipients of this type SHOULD treat it as synonymous with the CRL
   type.




Korver, Rescorla                                                [Page 11]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



3.2.5. PKCS #7 wrapped X.509 certificate


   This ID type defines a particular encoding (not a particular
   certificate), some current implementations may ignore CERTREQs they
   receive which contain this ID type, and the authors 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
   which receive CERTREQs which contain this ID type MAY treat such
   payloads as synonymous with "X.509 Certificate - Signature".


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. An implementation which 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 Certificate Authorities


   Implementations MUST generate CERTREQs for every peer trust anchor
   that local policy explicitly deems trusted during a given exchange.
   Implementations MUST populate the Certificate Authority field with
   the Subject Name of the trust anchor, populated such that binary
   comparison of the Subject Name and the Certificate Authority will
   succeed.


   Upon receipt of a CERTREQ where the Certificate Type is "X.509
   Certificate - Signature", implementations MUST respond by sending
   each certificate in the chain from the end entity certificate up to
   and including the certificate whose Issuer Name matches the name
   specified in the Certificate Authority field. Implementations MAY
   send other certificates.


   Note, in the case where multiple end entity certificates may be
   available, implementations SHOULD resort to local heuristics to
   determine which end entity is most appropriate to use. Such
   heuristics are out of the scope of this document.


3.2.7.2. Empty Certificate Authority Field


   Implementations MUST NOT generate CERTREQs where the Certificate Type
   is "X.509 Certificate - Signature" with an empty Certificate
   Authority field, as this form is explicitly deprecated. Upon receipt
   of such a CERTREQ from a non-conformant implementation,
   implementations SHOULD send just the certificate chain associated




Korver, Rescorla                                                [Page 12]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   with the end entity certificate, not including any CRLs or the
   certificates that would be needed to validate those CRLs.


   Note that PKIX prohibits certificates with an empty issuer name
   field.


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
   CERTREQs, implementations MAY treat them as if they are of a
   supported type with the Certificate Authority field left empty,
   depending on local policy. ISAKMP Section 5.10 "Certificate Request
   Payload Processing" specifies additional processing.


3.2.8.2. Undecodable Certificate Authority Fields


   Implementations MUST be able to deal with receiving CERTREQs with
   undecodable Certificate 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 materials have been cached, an
   implementation can send a hint to the peer to elide some of the
   certificates the peer would normally respond with. In addition to the
   normal set of CERTREQs that are sent specifying the trust anchors, an
   implementation MAY send CERTREQs containing the Issuer Name of the
   relevant cached end entity certificates. When sending these hints, it
   is still necessary to send the normal set of 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 specified if only supplying the issuer




Korver, Rescorla                                                [Page 13]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   of the end entity certificate.


   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.


   ISAKMP mandates that CERTREQs contain the Subject Name of a
   Certification Authority, which results in the peer always sending at
   least the end entity certificate. This mechanism allows
   implementations to determine unambiguously when a new certificate is
   being used by the peer, perhaps because the previous certificate has
   just expired, which will result in a failure because the needed
   keying materials are not available to validate the new end entity
   certificate. Implementations which implement this optimization MUST
   recognize when the end entity certificate has changed and respond to
   it by not performing this optimization when the exchange is retried.


3.2.9.3. Example


   Imagine that an 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
   Name in certificate TA, this implementation is requesting that the
   peer send at least 3 certificates: CA1, CA2, and EE. On the other
   hand, if this implementation also sends a CERTREQ containing the
   Subject Name of CA2, the implementation is providing a hint that only
   1 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 are transmitted in multiple
   payloads. However, not all certificate forms that are legal in PKIX
   make sense in the context of ISAKMP or IPsec. The issue of how to
   represent ISAKMP-meaningful name-forms in a certificate is especially
   problematic. This memo provides a profile for a subset of PKIX that
   makes sense for IKE/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:




Korver, Rescorla                                                [Page 14]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   * X.509 Certificate - Signature
   * Certificate Revocation List (CRL)
   * Authority Revocation List (ARL)
   * PKCS #7 wrapped X.509 certificate


   The use of the other types:


   * X.509 Certificate - Key Exchange
   * PGP Certificate
   * DNS Signed Key
   * Kerberos Tokens
   * SPKI Certificate
   * X.509 Certificate - Attribute


   are out of the scope of this document.


3.3.2. X.509 Certificate - Signature


   This type specifies that Certificate Data contains a certificate used
   for signing, whether an end entity signature certificate or a CA
   signature certificate.


3.3.3. Certificate Revocation List (CRL)


   This type specifies that Certificate Data contains an X.509 CRL.


3.3.4. Authority Revocation List (ARL)


   This type specifies that Certificate Data contains an X.509 CRL that
   applies only to CA certificates. Recipients of this type MAY treat it
   as synonymous with the CRL type.


3.3.5. 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 which violate this requirement
   SHOULD note that this is a single certificate as specified in ISAKMP.
   Implementations SHOULD accept CERTs that contain this Certificate
   Type.


3.3.6. Certificate Payloads Not Mandatory


   An implementation which 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. In this case, an implementation
   MAY send the certificate chain (not including the trust anchor)




Korver, Rescorla                                                [Page 15]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   associated with the end entity certificate. This MUST NOT be the
   default behavior of implementations.


   Implementations which are configured to expect that a peer must
   receive certificates through out-of-band means SHOULD ignore any
   CERTREQ messages that are received.


   Implementations that receive CERTREQs from a peer which contain only
   unrecognized Certification Authorities SHOULD NOT continue the
   exchange, in order to avoid unnecessary and potentially expensive
   cryptographic processing.


3.3.7. Response to Multiple Certificate Authority Proposals


   In response to multiple CERTREQs which contain different Certificate
   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 not to use keying materials contained in a
   given set of CERTs if preferable keying materials are available. For
   instance, the contents of a CERT may be available from a previous
   exchange or may be available through some out-of-band means.


3.3.9. Robustness


3.3.9.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 Section 5.10
   "Certificate Request Payload Processing" specifies additional
   processing.


3.3.9.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
   which may be taken.


3.3.9.3. Ordering of Certificate Payloads


   Implementations MUST NOT assume that CERTs are ordered in any way.






Korver, Rescorla                                                [Page 16]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



3.3.9.4. Duplicate Certificate Payloads


   Implementations MUST support receiving multiple identical CERTs
   during an exchange.


3.3.9.5. Irrelevant Certificates


   Implementations MUST be prepared to receive certificates and CRLs
   which are not relevant to the current exchange. Implementations MAY
   discard such extraneous certificates and CRLs.


   Implementations MAY send certificates which are irrelevant to an
   exchange. One reason for including certificates which are irrelevant
   to an exchange is to minimize the threat of leaking identifying
   information in exchanges where CERT is not encrypted. It should be
   noted, however, that this probably provides rather poor protection
   against leaking the identity.


   Another reason for including certificates that seem irrelevant to an
   exchange is that there may be two chains from the Certificate
   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 certs needed for both chains (even if there's only
   one CERTREQ).


3.3.10. Optimizations


3.3.10.1. Duplicate Certificate Payloads


   Implementations SHOULD NOT send duplicate CERTs during an exchange.
   Such payloads should be suppressed.



3.3.10.2. Send Lowest 'Common' Certificates


   When multiple CERTREQs are received which specify certificate
   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.10.3. Ignore Duplicate Certificate Payloads


   Implementations MAY employ local means to recognize CERTs that have
   been received in the past, whether part of the current exchange or
   not, for which keying material is available and may discard these
   duplicate CERTs.




Korver, Rescorla                                                [Page 17]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



3.3.11. Hash Payload


   IKE 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.



4. Profile of PKIX


4.1. X.509 Certificates


4.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.


4.1.2. Subject Name


4.1.2.1. Empty Subject Name


   Implementations MUST accept certificates which contain an empty
   Subject Name field, as specified in PKIX. Identity information in
   such certificates will be contained entirely in the SubjectAltName
   extension.


4.1.2.2. Specifying Non-FQDN Hosts in Subject Name


   Implementations which desire to place host names that are not
   intended to be processed by recipients as FQDNs (for instance
   "Gateway Router") in the Subject Name MUST use the commonName
   attribute.


   While nothing prevents an FQDN, USER-FQDN, or IP address information
   from appearing somewhere in the Subject Name contents, such entries
   MUST NOT be interpreted as identity information for the purposes of
   matching with ID or for policy lookup.







Korver, Rescorla                                                [Page 18]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



4.1.2.3. Specifying FQDN Host Names in Subject Name


   Implementations MUST NOT populate the Subject Name in place of
   populating the dNSName field of the SubjectAltName extension.


4.1.2.4. EmailAddress


   As specified in PKIX, implementations MUST NOT populate
   DistinguishedNames with the EmailAddress attribute.


4.1.3. X.509 Certificate Extensions


   Conforming applications MUST recognize extensions which must or may
   be marked critical according to this specification. These extensions
   are: KeyUsage, SubjectAltName, and BasicConstraints.


   Implementations SHOULD generate certificates such that the extension
   criticality bits are set in accordance with PKIX and this document.
   With respect to PKIX compliance, 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, if an implementation supports (and thus
   is going to process) a given extension, then it isn't necessary to
   reject the certificate if the criticality bit is different from what
   PKIX states it must be. However, if an implementation does not
   support an extension that PKIX mandates be critical, then the
   implementation must reject the certificate.


       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



4.1.3.1. AuthorityKeyIdentifier


   Implementations SHOULD NOT assume that other 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




Korver, Rescorla                                                [Page 19]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   certificates in order to find the CA certificate which contains the
   key that was used to generate the signature.


4.1.3.2. SubjectKeyIdentifier


   Implementations SHOULD NOT assume that other implementations support


   the SubjectKeyIdentifier 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.


4.1.3.3. KeyUsage


   The meaning of the nonRepudiation bit is not defined in the context
   of IPsec, although implementations SHOULD interpret the
   nonRepudiation bit as synonymous with the digitalSignature bit.
   Implementations SHOULD NOT generate certificates which only assert
   the nonRepudiation bit.


   See PKIX for general guidance on which of the other KeyUsage bits
   should be set in any given certificate.


4.1.3.4. PrivateKeyUsagePeriod


   PKIX 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 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, implementations MUST NOT generate certificates that
   contain the PrivateKeyUsagePeriod extension.


4.1.3.5. Certificate Policies


   Many IPsec implementations do not currently provide support for the
   Certificate Policies extension. Therefore, implementations that
   generate certificates which contain this extension SHOULD mark the
   extension as non-critical.


4.1.3.6. PolicyMappings


   Many implementations do not support the PolicyMappings extension.






Korver, Rescorla                                                [Page 20]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



4.1.3.7. SubjectAltName


   Implementations SHOULD generate only the following GeneralName
   choices in the subjectAltName extension, as these choices map to
   legal ISAKMP Identity Payload types: rfc822Name, dNSName, or
   iPAddress. Although it is possible to specify any GeneralName choice
   in the ISAKMP Identity Payload by using the ID_DER_ASN1_GN ID type,
   implementations SHOULD NOT assume that a peer supports such
   functionality.


4.1.3.7.1. dNSName


   This field MUST contain a fully qualified domain name.
   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, 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.


4.1.3.7.2. iPAddress


   Note that although PKIX permits CIDR [CIDR] notation in the "Name
   Constraints" extension, PKIX explicitly prohibits using CIDR notation
   for conveying identity information. In other words, the CIDR notation
   MUST NOT be used in the subjectAltName extension.


4.1.3.7.3. rfc822Name


   Although this field is in the form of an Internet mail address,
   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.


4.1.3.8. IssuerAltName


   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.








Korver, Rescorla                                                [Page 21]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



4.1.3.9. SubjectDirectoryAttributes


   The SubjectDirectoryAttributes extension is intended to contain
   privilege information, in a manner analogous to privileges carried in
   Attribute Certificates. Implementations MAY ignore this extension
   when it is marked non-critical, as PKIX mandates.


4.1.3.10. BasicConstraints


   PKIX mandates that CA certificates contain this extension and that it
   be marked critical. 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.


4.1.3.11. NameConstraints


   Many implementations do not support the NameConstraints extension.
   Since PKIX mandates that this extension be marked critical when
   present, implementations which intend to be maximally interoperable
   SHOULD NOT generate certificates which contain this extension.


4.1.3.12. PolicyConstraints


   Many implementations do not support the PolicyConstraints extension.
   Since PKIX mandates that this extension be marked critical when
   present, implementations which intend to be maximally interoperable
   SHOULD NOT generate certificates which contain this extension.


4.1.3.13. ExtendedKeyUsage


   No ExtendedKeyUsage usages are defined specifically for IPsec, so if
   this extension is present and marked critical, use of this
   certificate for IPsec MUST be treated as an error unless the
   extension contains the anyExtendedKeyUsage keyPurposeID, which
   asserts that the certificate can be used for any purpose.
   Implementations MAY ignore this extension if it is marked non-
   critical. Implementations MUST NOT generate this extension in
   certificates which are being used for IPsec.


   Note that a previous proposal for the use of three ExtendedKeyUsage
   values is obsolete and explicitly deprecated by this specification.
   For historical reference, those values were id-kp-ipsecEndSystem, id-
   kp-ipsecTunnel, and id-kp-ipsecUser.







Korver, Rescorla                                                [Page 22]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



4.1.3.14. CRLDistributionPoints


   Receiving CRLs in band via IKE/ISAKMP does not alleviate the
   requirement to process the CRLDistributionPoints if the certificate
   being validated contains the extension and the CRL being used to
   validate the certificate contains the IssuingDistributionPoint
   extension. 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 which is supposed to
   be used which would show the entity as revoked.


   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
   4.2.2.5 for more information.


   See PKIX docs for CRLDistributionPoints intellectual rights
   information. Note that both the CRLDistributionPoints and
   IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED
   by PKIX, so there is no requirement to license any IPR.


4.1.3.15. InhibitAnyPolicy


   Many implementations do not support the InhibitAnyPolicy extension.
   Since PKIX mandates that this extension be marked critical when
   present, implementations which intend to be maximally interoperable
   SHOULD NOT generate certificates which contain this extension.


4.1.3.16. FreshestCRL


   Implementations MUST NOT assume that the FreshestCRL extension will
   exist in peer extensions. Note that most implementations do not
   support delta CRLs.


4.1.3.17. AuthorityInfoAccess


   PKIX 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." Conformant
   implementations MAY support this extension.



4.1.3.18. SubjectInfoAccess


   PKIX defines the SubjectInfoAccess private certificate extension,
   which is used to indicate "how to access information and services for




Korver, Rescorla                                                [Page 23]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   the subject of the certificate in which the extension appears." This
   extension has no known use in the context of IPsec. Conformant
   implementations SHOULD ignore this extension when present.


4.2. X.509 Certificate Revocation Lists


   When validating certificates, 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. Implementations MAY provide a configuration option to
   disable use of certain types of revocation information, but that
   option MUST be off by default.


4.2.1. Multiple Sources of Certificate Revocation Information


   Implementations which 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 source, the certificate
   MUST be considered revoked.


4.2.2. X.509 Certificate Revocation List Extensions


4.2.2.1. AuthorityKeyIdentifier


   Implementations SHOULD NOT assume that other implementations support
   the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate
   certificate hierarchies which are overly complex to process in the
   absence of this extension.


4.2.2.2. IssuerAltName


   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.


4.2.2.3. CRLNumber


   As stated in PKIX, all issuers conforming to PKIX MUST include this
   extension in all CRLs.


4.2.2.4. DeltaCRLIndicator








Korver, Rescorla                                                [Page 24]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



4.2.2.4.1. If Delta CRLs Are Unsupported


   Implementations that do not support delta CRLs MUST reject CRLs which
   contain the DeltaCRLIndicator (which MUST be marked critical
   according to PKIX) 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.


4.2.2.4.2. Delta CRL Recommendations


   Since some implementations that do not support delta CRLs may behave
   incorrectly or insecurely when presented with delta CRLs,
   implementations SHOULD consider whether issuing delta CRLs increases
   security before issuing such CRLs.


   The authors are aware of several implementations which behave in an
   incorrect or insecure manner when presented with delta CRLs. See
   Appendix B for a description of the issue. Therefore, this
   specification RECOMMENDS against issuing delta CRLs at this time. On
   the other hand, failure to issue delta CRLs exposes a larger window
   of vulnerability. See the Security Considerations section of PKIX for
   additional discussion. Implementors as well as administrators are
   encouraged to consider these issues.


4.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 4.1.3.14 for more
   information.


4.2.2.6. FreshestCRL


   Given the recommendations against 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. Configuration Data Exchange Conventions


   Below we present a common format for exchanging configuration data.
   Implementations MUST support these formats, MUST support arbitrary




Korver, Rescorla                                                [Page 25]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   whitespace at the beginning and end of any line, MUST support
   arbitrary line lengths, and MUST support the three line-termination
   disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF.


5.1. Certificates



   Certificates MUST be Base64 encoded and appear between the following
   delimiters:


   -----BEGIN CERTIFICATE-----


   -----END CERTIFICATE-----


5.2. Public Keys


   Implementations MUST support two forms of public keys: certificates
   and so-called "raw" keys. Certificates should be transferred in the
   same form as above. 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-----


5.3. PKCS#10 Certificate Signing Requests


   A PKCS#10 [PKCS-10] Certificiate Signing Request MUST be Base64
   encoded and appear between the following delimeters:


   -----BEGIN CERTIFICATE REQUEST-----


   -----END CERTIFICATE REQUEST-----



6. Security Considerations


6.1. Identity Payload


   Depending on the exchange type, ID may be passed in the clear.
   Administrators in some environments may wish to use the empty
   Certification Authority option to prevent such information from
   leaking, at the possible cost of some performance, although such use
   is discouraged.







Korver, Rescorla                                                [Page 26]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



6.2. 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.


6.3. Certificate Payload


   Depending on the exchange type, CERTs may be passed in the clear and
   therefore may leak identity information.


6.4. IKE Main Mode


   Implementations may not wish to respond with CERTs in the second
   message, thereby violating the identity protection feature of Main
   Mode IKE. ISAKMP allows CERTs to be included in any message, and
   therefore implementations may wish to respond with CERTs in a message
   that offers privacy protection in this case.



7. Intellectual Property Rights


   No new intellectual property rights are introduced by this document.


8. IANA Considerations


   There are no known numbers which IANA will need to manage.


9. Normative References


   [DOI]      Piper, D., "The Internet IP Security Domain of
   Interpretation for ISAKMP", RFC 2407, November 1998.


   [IKE]      Harkins, D. and Carrel, D., "The Internet Key Exchange
   (IKE)", RFC 2409, November 1998.


   [IPSEC]    Kent, S. and Atkinson, R., "Security Architecture for the
   Internet Protocol", RFC 2401, November 1998.


   [ISAKMP]   Maughan, D., et. al., "Internet Security Association and
   Key Management Protocol (ISAKMP)", RFC 2408, November 1998.


   [PKCS-10]  Kaliski, B., "PKCS #10: Certification Request Syntax
   Version 1.5", RFC 2314, March 1998.


   [PKIX]     Housley, R., et al., "Internet X.509 Public Key




Korver, Rescorla                                                [Page 27]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   Infrastructure Certificate and Certificate Revocation
   List (CRL) Profile", RFC 3280, April 2002.


   [RFC791]   Postel, J.,  "Internet Protocol", STD 5, RFC 791,
   September 1981.


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.


10. Informational References


   [CIDR]     Fuller, V., et al., "Classless Inter-Domain Routing (CIDR):
   An Address Assignment and Aggregation Strategy", RFC 1519,
   September 1993.


   [DNSSEC]   Eastlake, D., "Domain Name System Security Extensions",
   RFC 2535, March 1999.


   [RFC1883]  Deering, S. and Hinden, R. "Internet Protocol, Version 6
   (IPv6) Specification", RFC 1883, December 1995.


   [ROADMAP]  Arsenault, A., and Turner, S., "PKIX Roadmap",
   draft-ietf-pkix-roadmap-08.txt.


   [SBGP]     Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for
   IP Addresses and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-00.txt.


11. Acknowledgements


   The authors would like to acknowledge the expired draft-ietf-ipsec-
   pki-req-05.txt for providing valuable materials for this document.
   The authors would like to especially thank Greg Carter, Russ Housley,
   Steve Hanna, and Gregory Lebovitz for their valuable comments, some
   of which have been incorporated unchanged into this document.


12. Author's Addresses


   Brian Korver
   Xythos Software, Inc.
   One Bush Street, Suite 600
   San Francisco, CA  94104
   USA
   Phone: +1 415 248-3800
   EMail: briank@xythos.com


   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive




Korver, Rescorla                                                [Page 28]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



   Palo Alto, CA  94303
   USA
   Phone: +1 650 320-8549
   EMail: ekr@rtfm.com


   Copyright (C) The Internet Society (2004). All Rights Reserved.


   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.


   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.


   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Acknowledgement


   Funding for the RFC Editor function is currently provided by the
   Internet Society.



Appendix A. Change History



   * February 2004 (-04)


      Minor editorial changes to clean up language


      Deprecate in-band exchange of CRLs


      Incorporated Gregory Lebovitz's proposal for CERT payloads:




Korver, Rescorla                                                [Page 29]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



      "should deal with all the CRL, Intermediat Certs, Trust Anchors,
      etc OOB of IKE; MUST be able to send and receive EE cert payload;
      only real exception is Intermediate Cets which MAY be sent and
      SHOULD be able to be receivable (but in reality there are very few
      hierarchies in operation, so really it's a corner case); SHOULD
      NOT send the other stuff (CRL, Trust Anchors, etc) in cert
      payloads in IKE; SHOULD be able to accept the other stuff if by
      chance it gets sent, though we hope they don't get sent"


      Incorporated comments contained in Oct 7, 2003 email from
      steve.hanna@sun.com to ipsec@lists.tislabs.com


      Moved text from "Profile of ISAKMP" Background section to each
      payload section (removing duplication of these sections)


      Removed "Certificate-Related Playloads in ISAKMP" section since it
      was not specific to IKE.


      Incorporated Gregory Lebovitz's table in the "Identification
      Payload" section


      Moved text from "binding identity to policy" sections to each
      payload section


      Moved text from "IKE" section into now-combined "IKE/ISAKMP"
      section


      ID_USER_FQDN and ID_FQDN promoted to MUST from MAY


      Promoted sending ID_DER_ASN1_DN to MAY from SHOULD NOT, and
      receiving from MUST from MAY


      Demoted ID_DER_ASN1_GN to MUST NOT


      Demoted populating Subject Name in place of populating the dNSName
      from SHOULD NOT to MUST NOT and removed the text regarding
      domainComponent


      Revocation information checking MAY now be disabled, although not
      by default


      Aggressive Mode removed from this profile





   * June 2003 (-03)





Korver, Rescorla                                                [Page 30]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



      Minor editorial changes to clean up language


      Minor additional clarifying text


      Removed hyphenation


      Added requirement that implementations support configuration data
      exchange having arbitrary line lengths



   * February 2003 (-02)


      Word choice: move from use of "root" to "trust anchor", in
      accordance with PKIX


      SBGP note and reference for placing address subnet and range
      information into certificates


      Clarification of text regarding placing names of hosts into the
      Name commonName attribute of SubjectName


      Added table to clarify text regarding processing of the
      certificate extension criticality bit


      Added text underscoring processing requirements for
      CRLDistributionPoints and IssuingDistributionPoint



   * October 2002, Reorganization (-01)
   * June 2002, Initial Draft (-00)



Appendix B. 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 which 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:







Korver, Rescorla                                                [Page 31]Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX              2/2004



     fetch newest CRL
     check validity of CRL signature
     if CRL signature is valid then
     if CRL does not contain unrecognized critical extensions
     and certificate is on CRL then
     set certificate status to revoked



   The authors note that a number of PKI toolkits do not even provide a
   method for obtaining anything but the newest CRL, which in the
   presence of delta CRLs may in fact be a delta CRL, not a base CRL.


      Note that the above algorithm is dangerous in many ways. See PKIX
      for the correct algorithm.






































Korver, Rescorla                                                [Page 32]