[Docs] [txt|pdf] [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-03.txt>       Jul 2003 (Expires Jan 2004)

        The Internet IP Security PKI Profile of 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 compliments 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 ISAKMP                                              6
  3.1         Background                                                   6
    3.1.1       Certificate-Related Payloads in ISAKMP                     6
      3.1.1.1     Identification Payload                                   6
      3.1.1.2     Certificate Payload                                      6



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


      3.1.1.3     Certificate Request Payload                              6
      3.1.1.4     Hash Payload                                             6
    3.1.2       Endpoint Identification                                    7
      3.1.2.1     Identification Payload Only                              7
      3.1.2.2     Certificate Payload Only                                 7
  3.2         Identification Payload                                       7
    3.2.1       ID_IPV4_ADDR and ID_IPV6_ADDR                              7
    3.2.2       ID_FQDN                                                    8
    3.2.3       ID_USER_FQDN                                               8
    3.2.4       ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_A... 8
    3.2.5       ID_DER_ASN1_DN                                             8
    3.2.6       ID_DER_ASN1_GN                                             9
    3.2.7       ID_KEY_ID                                                  9
    3.2.8       Using Peer Source IP Address to Bind Identity to Po... 9
    3.2.9       Securely Binding Identity to Policy                       10
      3.2.9.1     Single Address Identification Data                      10
      3.2.9.2     Identification Data other than a Single Address         10
    3.2.10      Selecting an Identity from a Certificate                  11
    3.2.11      Transitively Binding Identity to Policy                   11
  3.3         Certificate Request Payload                                 11
    3.3.1       Certificate Type                                          11
    3.3.2       X.509 Certificate - Signature                             12
    3.3.3       X.509 Certificate - Key Exchange                          12
    3.3.4       Certificate Revocation List (CRL)                         12
    3.3.5       Authority Revocation List (ARL)                           12
    3.3.6       PKCS #7 wrapped X.509 certificate                         13
    3.3.7       Presence or Absence of Certificate Request Payloads       13
    3.3.8       Certificate Requests                                      13
      3.3.8.1     Specifying Certificate Authorities                      13
      3.3.8.2     Empty Certificate Authority Field                       13
    3.3.9       CRL Requests                                              14
      3.3.9.1     Specifying Certificate Authorities                      14
      3.3.9.2     Empty Certificate Authority Field                       14
    3.3.10      Robustness                                                14
      3.3.10.1    Unrecognized or Unsupported Certificate Types           14
      3.3.10.2    Undecodable Certificate Authority Fields                15
      3.3.10.3    Ordering of Certificate Request Payloads                15
    3.3.11      Optimizations                                             15
      3.3.11.1    Duplicate Certificate Request Payloads                  15
      3.3.11.2    Name Lowest 'Common' Certification Authorities          15
      3.3.11.3    Example                                                 16
  3.4         Certificate Payload                                         16
    3.4.1       Certificate Type                                          16
    3.4.2       X.509 Certificate - Signature                             16
    3.4.3       X.509 Certificate - Key Exchange                          17
    3.4.4       Certificate Revocation List (CRL)                         17
    3.4.5       Authority Revocation List (ARL)                           17
    3.4.6       PKCS #7 wrapped X.509 certificate                         17



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


    3.4.7       Certificate Payloads Not Mandatory                        17
    3.4.8       Response to Multiple Certificate Authority Proposals      18
    3.4.9       Using Local Keying Materials                              18
    3.4.10      Robustness                                                18
      3.4.10.1    Unrecognized or Unsupported Certificate Types           18
      3.4.10.2    Undecodable Certificate Data Fields                     18
      3.4.10.3    Ordering of Certificate Payloads                        18
      3.4.10.4    Duplicate Certificate Payloads                          18
      3.4.10.5    Irrelevant Certificates                                 18
    3.4.11      Optimizations                                             19
      3.4.11.1    Duplicate Certificate Payloads                          19
      3.4.11.2    Send Lowest 'Common' Certificates                       19
      3.4.11.3    Ignore Duplicate Certificate Payloads                   19
4           Profile of PKIX                                               19
  4.1         X.509 Certificates                                          19
    4.1.1       Versions                                                  19
    4.1.2       Subject Name                                              19
      4.1.2.1     Empty Subject Name                                      20
      4.1.2.2     Specifying Non-FQDN Hosts in Subject Name               20
      4.1.2.3     Specifying FQDN Host Names in Subject Name              20
      4.1.2.4     EmailAddress                                            20
    4.1.3       X.509 Certificate Extensions                              20
      4.1.3.1     AuthorityKeyIdentifier                                  21
      4.1.3.2     SubjectKeyIdentifier                                    21
      4.1.3.3     KeyUsage                                                22
      4.1.3.4     PrivateKeyUsagePeriod                                   22
      4.1.3.5     Certificate Policies                                    22
      4.1.3.6     PolicyMappings                                          22
      4.1.3.7     SubjectAltName                                          22
        4.1.3.7.1   dNSName                                               23
        4.1.3.7.2   iPAddress                                             23
        4.1.3.7.3   rfc822Name                                            23
      4.1.3.8     IssuerAltName                                           23
      4.1.3.9     SubjectDirectoryAttributes                              23
      4.1.3.10    BasicConstraints                                        23
      4.1.3.11    NameConstraints                                         24
      4.1.3.12    PolicyConstraints                                       24
      4.1.3.13    ExtendedKeyUsage                                        24
      4.1.3.14    CRLDistributionPoint                                    24
      4.1.3.15    InhibitAnyPolicy                                        25
      4.1.3.16    FreshestCRL                                             25
      4.1.3.17    AuthorityInfoAccess                                     25
      4.1.3.18    SubjectInfoAccess                                       25
  4.2         X.509 Certificate Revocation Lists                          25
    4.2.1       Certificate Revocation Requirement                        26
    4.2.2       Multiple Sources of Certificate Revocation Informati... 26
    4.2.3       X.509 Certificate Revocation List Extensions              26
      4.2.3.1     AuthorityKeyIdentifier                                  26



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


      4.2.3.2     IssuerAltName                                           26
      4.2.3.3     CRLNumber                                               26
      4.2.3.4     DeltaCRLIndicator                                       26
        4.2.3.4.1   If Delta CRLs Are Unsupported                         26
        4.2.3.4.2   Delta CRL Recommendations                             27
      4.2.3.5     IssuingDistributionPoint                                27
      4.2.3.6     FreshestCRL                                             27
5           Configuration Data Exchange Conventions                       27
  5.1         Certificates                                                27
  5.2         Public Keys                                                 28
  5.3         PKCS#10 Certificate Signing Requests                        28
6           IKE                                                           28
  6.1         IKE Phase 1 Authenticated With Signatures                   28
    6.1.1       Identification Payload                                    28
    6.1.2       X.509 Certificate Extensions                              29
      6.1.2.1     KeyUsage                                                29
    6.1.3       Obtaining Peer Certificates and CRLs                      29
  6.2         IKE Phase 1 Authenticated With Public Key Encryption        29
    6.2.1       Identification Payload                                    29
    6.2.2       Hash Payload                                              29
    6.2.3       X.509 Certificate Extensions                              29
      6.2.3.1     KeyUsage                                                29
    6.2.4       Obtaining Peer Certificates and CRLs                      30
  6.3         IKE Phase 1 Authenticated With a Revised Mode of Pub... 30
7           Security Considerations                                       30
  7.1         Identity Payload                                            30
  7.2         Certificate Request Payload                                 30
  7.3         Certificate Payload                                         30
  7.4         IKE Main Mode                                               30
  7.5         IKE Aggressive Mode                                         31
8           Intellectual Property Rights                                  31
9           IANA Considerations                                           31
10          Normative References                                          31
11          Informational References                                      32
12          Acknowledgements                                              32
13          Author's Addresses                                            32

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



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


   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 threst of this document, Section 3 provides the
   profile of 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. Section 6 covers aspects of ISAKMP and
   PKIX which are unique to IKE.

   Versions "00" through "03" of this document are intended as "straw
   men" to encourage comments from implementors of IPsec and to
   encourage discussion of the issues which the authors hope to address
   this document.

   This document is being discussed on the ipsec@lists.tislabs.com
   mailing list, which is the mailing list for the IPsec Working Group.

2. Terms and Definitions

   Except for those terms which are defined immediately below, all PKI
   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.



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


   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 ISAKMP

3.1. Background

3.1.1. Certificate-Related Payloads in ISAKMP

   ISAKMP has three primary certificate-related payloads:
   Identification, Certificate, and Certificate Request. Additionally,
   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. In this section we provide a short introduction to these
   payload types.

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

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

3.1.1.3. Certificate Request Payload

   The Certificate Request (CERTREQ) Payload allows an ISAKMP
   implementation to request that a peer provide some set of
   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.1.1.4. Hash Payload

   The Hash (HASH) Payload is a generic mechanism for ISAKMP
   implementations to communicate hash values to a peer. The meaning of



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


   the contents of such payloads is left undefined by ISAKMP.

3.1.2. Endpoint Identification

   ISAKMP contains two different payloads that allow the specification
   of  endpoint identity, the ID payload and the CERT payload. According
   to  ISAKMP, these payloads can be used separately or together,
   although specific profiles of ISAKMP may place additional
   requirements on implementations.

3.1.2.1. Identification Payload Only

   If one peer presents only the ID payload, it is expected that the
   peer will be able to recover whatever keying material is required to
   verify the peer's identity. How to do so is out of the scope of this
   document but might include a local cache, an LDAP directory, or DNS.

3.1.2.2. Certificate Payload Only

   If a peer presents only a CERT payload, this creates an ambiguity,
   since ISAKMP does not specify which of potentially many certificates
   corresponds to the end-entity and which are chaining certificates.
   Implementations SHOULD compare whatever local hints they have about
   peer identity to each certificate until they find one that appears
   acceptable.

3.2. Identification Payload

   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.

   The [DOI] defines the 11 types of Identification Data that can be
   used and specifies the syntax for these types. All of these are
   discussed immediately below.

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



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


   iPAddress field in the subjectAltName extension for equality, binary
   comparison MUST be performed.

3.2.2. ID_FQDN

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

3.2.3. ID_USER_FQDN

   Implementations MAY 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
   comparison MUST be performed. Substring, wildcard, or regular
   expression matching MUST NOT be performed.

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

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

   Implementations MAY support receiving the ID_DER_ASN1_DN ID type,
   although implementations SHOULD NOT generate this type because many
   implementations do not support this type. Implementations which
   generate this type SHOULD populate the contents of ID with the
   Subject Name from the end entity certificate, and MUST do so such



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


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

3.2.6. ID_DER_ASN1_GN

   Implementations MAY support receiving the ID_DER_ASN1_GN ID type,
   although implementations SHOULD NOT generate this type unless it is
   known through out-of-band means that the peer is capable of
   understanding this type. Implementations which generate this type
   MUST populate the contents of ID with the a GeneralName from the
   SubjectAltName extension in 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 GeneralName varies from the constraints set by DER,
   that non-conformant GeneralName MUST be used to populate the ID
   payload: in other words, implementations MUST NOT re-encode the
   GeneralName for the purposes of making it DER if it does not appear
   in the certificate as DER.

3.2.7. ID_KEY_ID

   Type ID_KEY_ID type used to specify pre-shared keys and thus is not
   relevant to this document.

3.2.8. Using Peer Source IP Address to Bind Identity to Policy

   Because implementations sometimes 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.

   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



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


   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
   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 favor unauthenticated peer source addresses
   over an unauthenticated ID for initial policy lookup.

3.2.9. Securely Binding Identity to Policy

3.2.9.1. Single Address Identification Data

   In the case where ID contains ID_IPV4_ADDR or ID_IPV6_ADDR,
   implementations MUST verify that this address 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. The definition of "match" is specific
   to each ID type and was discussed above. 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.

3.2.9.2. Identification Data other than a Single Address

   In the case where ID contains an identity type other than a single
   address, implementations MUST verify that the identity contained in



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


   the ID payload matches identity information contained in the peer end
   entity certificate, either in the Subject Name field or
   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. The definition of "match" is specific
   to each ID type and was discussed above.

3.2.10. 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.2.11. 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 FQDN. 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 FQDN in the certificate can be used to locate the
   appropriate policy. In other wores, the Subject Name is used to find
   the certificate, the certificate contains the FQDN, and the FQDN is
   used to lookup policy.

3.3. Certificate Request Payload

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



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


   following types are relevant:

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

   For example, if CRLs are desired, an implementation will populate the
   Certificate Type field with the value associated with "Certificate
   Revocation List (CRL)".

   The use of the other types:

   * 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 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.3.3. X.509 Certificate - Key Exchange

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

3.3.4. Certificate Revocation List (CRL)

   This type requests that X.509 CRLs be provided, along with any
   certificates that may be needed to validate those CRLs.

3.3.5. Authority Revocation List (ARL)

   Implementations SHOULD NOT generate CERTREQ payloads with this type,
   but should instead generate CRL CERTREQs. That is, implementations
   request CRLs generically, whether they be CRLs or ARLs, using the CRL
   type. Recipients of this type SHOULD treat it as synonymous with the
   CRL type.



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


3.3.6. PKCS #7 wrapped X.509 certificate

   This ID type defines a particular encoding (not a particular
   certificate or CRL type), 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
   ignore such payloads.

3.3.7. 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.3.8. Certificate Requests

3.3.8.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 either "X.509
   Certificate - Signature" or "X.509 Certificate - Key Exchange",
   implementations MUST respond by sending each certificate in the chain
   from the end entity certificate to the certificate whose Issuer Name
   matches the name specified in the Certificate Authority field.
   Implementations MAY send other certificates from the chain.

   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.3.8.2. Empty Certificate Authority Field

   Implementations MUST NOT generate CERTREQs where the Certificate Type
   is either "X.509 Certificate - Signature" or "X.509 Certificate - Key
   Exchange" 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



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


   certificate chain associated 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.3.9. CRL Requests

3.3.9.1. Specifying Certificate Authorities

   Upon receipt of a CERTREQ where the Certificate Type is "Certificate
   Revocation List (CRL)", implementations MUST respond by sending the
   CRL issued by the issuer of each certificate in the chain between the
   end entity certificate and the certificate whose Issuer Name matches
   the name specified in the Certificate Authority field. In additional,
   implementations MUST send any certificates that the peer will need to
   validate those CRLs, while optionally eliding those certificates and
   CRLs identified in CERTREQs as already being in the possession of the
   peer.

3.3.9.2. Empty Certificate Authority Field

   Implementations MAY generate CERTREQs where the Certificate Type is
   "Certificate Revocation List (CRL)" with an empty Certificate
   Authority field to signify that the peer should send all CRLs that
   are possessed by that peer, whether relevant to the current exchange
   or not. Upon receipt of such a CERTREQ, implementations SHOULD send
   all CRLs that are possessed but MUST send all CRLs that are relevant
   to the current exchange, including the certificates that are needed
   to validate those CRLs, as a general mechanism for sharing revocation
   information.

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

3.3.10. Robustness

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






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


3.3.10.2. Undecodable Certificate Authority Fields

   Implementations MUST be able to deal with receiving CERTREQs with
   undecodable Certificate Authority fields. Implementations MAY treat
   such fields as if there were empty, depending on local policy. ISAKMP
   specifies other actions which may be taken.

3.3.10.3. Ordering of Certificate Request Payloads

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

3.3.11. Optimizations

3.3.11.1. Duplicate Certificate Request Payloads

   Implementations SHOULD NOT send duplicate CERTREQs during an
   exchange.

3.3.11.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 and CRLs 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 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.



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


3.3.11.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, that
   TA is a trust anchor should not be construed to imply that TA is a
   self-signed certificate.

3.4. Certificate Payload

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

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

   For example, if CRLs are desired, an implementation will populate the
   Certificate Type field with the value associated with "Certificate
   Revocation List (CRL)".

   The use of the other types:

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

   are out of the scope of this document.

3.4.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
   certificate or CRL signing certificate.



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


3.4.3. X.509 Certificate - Key Exchange

   This type specifies that Certificate Data contains an end entity
   certificate used for either key exchange (or key encipherment).

3.4.4. Certificate Revocation List (CRL)

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

3.4.5. Authority Revocation List (ARL)

   This type specifies that Certificate Data contains an X.509 CRL that
   revokes CAs. In response to CRL CERTREQs, an implementation MAY
   include ARLs in an ARL payload to more precisely specify the contents
   of the CERT payload. Recipients of this type MAY treat it as
   synonymous with the CRL type.

3.4.6. PKCS #7 wrapped X.509 certificate

   This type defines a particular encoding, not a particular certificate
   or CRL 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.4.7. 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
   MUST send the all certificate chains and CRLs 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.







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


3.4.8. 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.4.9. 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 a newer CRL may be available through some out-of-band
   means.

3.4.10. Robustness

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

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

3.4.10.3. Ordering of Certificate Payloads

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

3.4.10.4. Duplicate Certificate Payloads

   Implementations MUST support receiving multiple identical CERTs
   during an exchange.

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





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


   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.

3.4.11. Optimizations

3.4.11.1. Duplicate Certificate Payloads

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


3.4.11.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.3.11.2 for more
   discussion of this optimization.

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

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 certain self-signed certificates 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







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


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
   indended 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, with the
   exception of domainComponent which is discussed below, such entries
   MUST NOT be interpreted as identity information.

4.1.2.3. Specifying FQDN Host Names in Subject Name

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

   Implementations which desire to place resolvable FQDNs (for instance
   "gateway.example.com") in the Subject Name field instead of the
   SubjectAltName dNSName field MUST use the domainComponent attribute
   type, as specified in PKIX. PKIX further specifies that
   implementations MUST be prepared to receive the domainComponent
   attribute. The contents of the domainComponent are semantically
   identical to the contents of the SubjectAltName dNSName field.

   Note, however, that support for the domainComponent attribute is far
   from universal and some implementations will reject or fail to
   display certificates that contain this attribute.

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.





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


   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 overly complex to process in the
   absence of this extension, such that 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.2. SubjectKeyIdentifier

   Implementations SHOULD NOT assume that other implementations support
   the SubjectKeyIdentifier extension, and thus SHOULD NOT generate
   certificate hierarchies which overly complex to process in the
   absence of this extension, such that 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.







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


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 ISAKMP 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 meaning
   of this extension in the context of ISAKMP is unclear. Therefore, the
   PrivateKeyUsagePeriod is inappropriate in the context of ISAKMP and
   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.

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.







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


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 the 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", 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 the 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.

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 as
   PKIX mandates it be marked non-critical.

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



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


   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 for IPsec, so if this
   extension is present and marked critical, use of this certificate for
   IPsec MUST be treated as an error. 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.

4.1.3.14. CRLDistributionPoint

   Most implementations expect to exchange CRLs in band via the ISAKMP
   Certificate Payload. Implementations MUST NOT assume that the
   CRLDistributionPoint extension will exist in peer extensions and
   therefore implementations SHOULD request that peers send CRLs in the
   absence of knowledge that this extension exists in the peer's
   certificates.

   However receiving CRLs in band via ISAKMP does not alleviate the
   requirement to process the CRLDistributionPoint if the certificate
   being validated contains the extension and the CRL being used to
   validate the certificate contains the IssuingDistributionPoint.
   Failure to validate the
   CRLDistributionPoint/IssusingDistributionPoint pair can result in CRL
   substitution where an entity knowingly substitutes a known good CRL
   for the CRL which is supposed to be used which would show the entity
   as revoked.




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


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

   See PKIX docs for CRLDistributionPoints intellectual rights
   information.

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

   Most implementations expect to exchange CRLs in band via the ISAKMP
   Certificate Payload. Implementations MUST NOT assume that the
   FreshestCRL extension will exist in peer extensions and therefore
   implementations SHOULD request that peers send CRLs in the absence
   knowledge that this extension exists in the peer certificates. 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." This extension has
   no known use in the context of IPsec. Conformant implementations
   SHOULD ignore this extension when present.

4.1.3.18. SubjectInfoAccess

   PKIX defines the SubjectInfoAccess private 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
   implementations SHOULD ignore this extension when present.

4.2. X.509 Certificate Revocation Lists

   Implementations SHOULD send CRLs, unless non-CRL certificate
   revocation information is known to be preferred by all interested
   parties in the application environment that the implementation is
   used. Implementations MUST send CRLs if non-CRL certificate
   revocation information may not be available to all interested



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


   parties.

4.2.1. Certificate Revocation Requirement

   Implementations which validate certificates 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.

4.2.2. 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.3. X.509 Certificate Revocation List Extensions

4.2.3.1. AuthorityKeyIdentifier

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

4.2.3.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.3.3. CRLNumber

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

4.2.3.4. DeltaCRLIndicator

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



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


4.2.3.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.3.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 CRLDistributionPoint extension in the certificate, and
   places the IssuingDistributionPoint in the CRL. The
   distributionPointName field in the CRLDistributionPoint extension and
   the 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.3.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
   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






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


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

6.1. IKE Phase 1 Authenticated With Signatures

6.1.1. Identification Payload

   IKE mandates the use of the ID payload in Phase 1.

   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 28]Internet-Draft         PKI Profile for ISAKMP/PKIX                2/2003


6.1.2. X.509 Certificate Extensions

6.1.2.1. KeyUsage

   If the KeyUsage extension is present in an end entity certificate,
   the digitalSignature bit MUST be asserted, or if no other bits but
   the nonRepudiation bit are asserted and the certificate is being used
   to generate a signature, an implementation MAY interpret the
   nonRepudiation bit as synonymous with the digitalSignature.

6.1.3. Obtaining Peer Certificates and CRLs

   IKE implementations MUST assume all necessary certificates and CRLs
   will be exchanged in-band.

6.2. IKE Phase 1 Authenticated With Public Key Encryption

6.2.1. Identification Payload

   IKE mandates the use of the ID payload in Phase 1.

   If certificates are not being used, the contents of ID are out of
   scope for this document.

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

6.2.3. X.509 Certificate Extensions

6.2.3.1. KeyUsage

   If the KeyUsage extension is present in an end entity certificate,
   the keyEncipherment bit MUST be asserted, or if no other bits but the
   nonRepudiation bit are asserted and the certificate is being used for
   key encipherment, an implementation MAY interpret the nonRepudiation
   bit as synonymous with the keyEncipherment.







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


6.2.4. Obtaining Peer Certificates and CRLs

   Certificates are generally not exchanged in-band, but rather are
   exchanged out-of-band, with direct trust of the peer certificate
   being most prevalent. CRLs SHOULD be obtained out-of-band from a
   directory or other repository.

6.3. IKE Phase 1 Authenticated With a Revised Mode of Public Key
Encryption

   IKE Phase 1 Authenticated With a Revised Mode of Public Key
   Encryption has the same requirements as IKE Phase 1 Authenticated
   With Public Key Encryption. See section 6.2 for these requirements.

7. Security Considerations

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

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

7.3. Certificate Payload

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

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







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


7.5. IKE Aggressive Mode

   The contents of ID are not encrypted in Aggressive Mode when
   authentication is performed with signatures. In some environments
   this may leak private information. The solutions to this problem if
   such a leak is unacceptable are:

   * Use Main Mode instead of Aggressive Mode.
   * Populate ID Data with the address of the host.

   The contents of CERT are not encrypted in Aggressive Mode when
   authentication is performed with signatures. In some environments
   this may leak private information. The solutions to this problem if
   such a leak is unacceptable are:

   * Use Main Mode instead of Aggressive Mode.

8. Intellectual Property Rights

   No new intellectual property rights are introduced by this document.

9. IANA Considerations

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

10. 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
   Infrastructure Certificate and Certificate Revocation
   List (CRL) Profile", RFC 3280, April 2002.

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



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


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

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

12. 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 and Russ
   Housley for their valuable comments, some of which have been
   incorporated unchanged into this document.

13. Author's Addresses

   Brian Korver
   Xythos Software, Inc.
   25 Maiden Lane, 6th Floor
   San Francisco, CA  94108
   USA
   Phone: +1 415 248-3800
   EMail: briank@xythos.com

   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, CA  94303
   USA
   Phone: +1 650 320-8549
   EMail: ekr@rtfm.com





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


   Copyright (C) The Internet Society (2003). 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



   * June 2003 (-03)

      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




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


   * 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 often written
   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:

     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.





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





















































Korver, Rescorla                                                [Page 35]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/