Brian Korver
                                                         Xythos Software
INTERNET-DRAFT                              May 2004 (Expires Oct 2004)
<draft-ietf-pki4ipsec-ikecert-profile-00.txt>

  The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, 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 IKEv1 and IKEv2, which assume the existence of
    public key certificates and related keying materials, but which do
    not address PKI issues explicitly. This document addresses those
    issues.


Table of Contents

1      Introduction                                                    4
2      Terms and Definitions                                           5
3      Profile of IKEv1/ISAKMP and IKEv2                               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                                            9



Korver                                                           [Page 1]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/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                                11
     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)                        12
     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                  13
     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     14
       3.2.9.3      Example                                            14
   3.3      Certificate Payload                                        14
     3.3.1      Certificate Type                                       15
     3.3.2      X.509 Certificate - Signature                          15
     3.3.3      X.509 Certificate - Signature                          15
     3.3.4      Certificate Revocation List (CRL)                      16
     3.3.5      Authority Revocation List (ARL)                        16
     3.3.6      PKCS #7 wrapped X.509 certificate                      16
     3.3.7      Certificate Payloads Not Mandatory                     16
     3.3.8      Response to Multiple Certificate Authority Proposals   16
     3.3.9      Using Local Keying Materials                           17
     3.3.10      Robustness                                            17
       3.3.10.1      Unrecognized or Unsupported Certificate Types     17
       3.3.10.2      Undecodable Certificate Data Fields               17
       3.3.10.3      Ordering of Certificate Payloads                  17
       3.3.10.4      Duplicate Certificate Payloads                    17
       3.3.10.5      Irrelevant Certificates                           17
     3.3.11      Optimizations                                         18
       3.3.11.1      Duplicate Certificate Payloads                    18
       3.3.11.2      Send Lowest 'Common' Certificates                 18
       3.3.11.3      Ignore Duplicate Certificate Payloads             18
     3.3.12      Hash Payload                                          18
4      Profile of PKIX                                                19
   4.1      X.509 Certificates                                         19
     4.1.1      Versions                                               19



Korver                                                           [Page 2]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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

Korver                                                           [Page 3]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


8      IANA Considerations                                            28
9      Normative References                                           28
10      Informational References                                      29
11      Acknowledgements                                              29
12      Author's Addresses                                            29

1. Introduction

    IKE [IKEv1] and ISAKMP [ISAKMP] and IKEv2 [IKEv2] 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, IKEv2, or 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 IKEv1/ISAKMP and IKEv2, 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                                                           [Page 4]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/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, IKEv2,
    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.
    * ID_USER_FQDN:  IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both
    are referred to as ID_USER_FQDN in this document.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC-2119 [RFC2119].

3. Profile of IKEv1/ISAKMP and IKEv2

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 Identification
    Payload specifically. For instance, in the case where ID does not
    contain an IP address, checks such as verifying that the peer source
    address is permitted by the relevant policy are not addressed here as
    they are out of the scope of this document.

    Implementations SHOULD populate ID with identity information that is
    contained within the end entity certificate (This SHOULD does not
    contradict text in IKEv2 Section 3.5 that implies a looser binding
    between these two). Populating ID with identity information from the
    end entity certificate enables recipients to use ID as a lookup key
    to find the peer end entity certificate. The only case where
    implementations MAY populate ID with information that is not
    contained in the end entity certificate is when ID contains the peer



Korver                                                           [Page 5]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


    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.

    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.



Korver                                                           [Page 6]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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

    IKEv2 ads an optional IDr payload in the second exchange that the
    initiator may send to the responder specify which of the responder's
    identities should be used. The responder MAY choose to send an IDr in
    the 3rd exchange that differs in type or content from the initiator-
    generator IDr. The initiator MUST be able to receive a responder-
    generated IDr that is different from the one the initiator generated.


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.

    Note that this document RECOMMENDS against populating the ID payload
    with IP addresses due to interoperability issues such as problem with
    NAT traversal.

    Implementations MUST be capable of verifying that the address
    contained in ID is the same as the peer source address.
    Implementations MAY provide a configuration option to skip that
    verification step, but that option MUST be off by default. 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



Korver                                                           [Page 7]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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

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.



Korver                                                           [Page 8]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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



Korver                                                           [Page 9]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


    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.

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.




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


3.2. Certificate Request Payload

    The Certificate Request (CERTREQ) Payload allows an implementation to
    request that a peer provide some set of certificates or certificate
    revocation lists. 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.

    In addition to the above, IKEv2 adds 3 additional types which are not
    profiled in this document:
    * Raw RSA Key
    * Hash and URL of X.509 certificate
    * Hash and URL of X.509 bundle

3.2.2. X.509 Certificate - Signature

    This type requests that the end entity certificate be a signing
    certificate.

3.2.3. Certificate Revocation List (CRL)

    ISAKMP and IKEv2 do 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



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


    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.

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.
    For IKEv1, 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. For IKEv2, implementations MUST populate the
    Certificate Authority field as specified in [IKEv2].

    Upon receipt of a CERTREQ, implementations MUST respond by sending
    the end entity certificate but MAY also send each certificate in the
    chain above 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



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


    determine which end entity is most appropriate to use for generating
    the CERTREQ. 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
    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.







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


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

    CERTREQs must contain information that identifies a Certification
    Authority certificate, 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 should be transmitted in



Korver                                                          [Page 14]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


    multiple payloads. However, not all certificate forms that are legal
    in PKIX make sense in the context of IPsec. The issue of how to
    represent IKE-meaningful name-forms in a certificate is especially
    problematic. This memo provides a profile for a subset of PKIX that
    makes sense for IKEv1/ISAKMP and IKEv2.

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:

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

    In addition to the above, IKEv2 adds 3 additional types which are not
    profiled in this document:
    * Raw RSA Key
    * Hash and URL of X.509 certificate
    * Hash and URL of X.509 bundle

3.3.2. X.509 Certificate - Signature

    This type requests that the end entity certificate be a signing
    certificate.

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





Korver                                                          [Page 15]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


3.3.4. Certificate Revocation List (CRL)

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

3.3.5. 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.6. PKCS #7 wrapped X.509 certificate

    This type defines a particular encoding, not a particular certificate
    type. Implementations SHOULD NOT generate CERTs that contain this
    Certificate Type. Implementations SHOULD accept CERTs that contain
    this Certificate Type because several implementations are known to
    generate them. Note that those implementations may include entire
    certificate hierarchies inside a single CERT PKCS #7 payload, which
    violates the requirement specified in ISAKMP that this payload
    contain a single certificate.

3.3.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
    MAY send the certificate chain (not including the trust anchor)
    associated with the end entity certificate. This MUST NOT be the
    default behavior of implementations.

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





Korver                                                          [Page 16]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


3.3.9. Using Local Keying Materials

    Implementations MAY elect skip the processing of 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.10. Robustness

3.3.10.1. Unrecognized or Unsupported Certificate Types

    Implementations MUST be able to deal with receiving CERTs with
    unrecognized or unsupported Certificate Types. Implementations MAY
    discard such payloads, depending on local policy. ISAKMP Section 5.10
    "Certificate Request Payload Processing" specifies additional
    processing.

3.3.10.2. Undecodable Certificate Data Fields

    Implementations MUST be able to deal with receiving CERTs with
    undecodable Certificate Data fields. Implementations MAY discard such
    payloads, depending on local policy. ISAKMP specifies other actions
    which may be taken.

3.3.10.3. Ordering of Certificate Payloads

    For IKEv1, implementations MUST NOT assume that CERTs are ordered in
    any way. For IKEv2, implementations MUST NOT assume that any except
    the first CERT is ordered in any way. IKEv2 specifies that the first
    CERT contain the end entity certificate which is to be used to
    authenticate the peer.

3.3.10.4. Duplicate Certificate Payloads

    Implementations MUST support receiving multiple identical CERTs
    during an exchange.

3.3.10.5. Irrelevant Certificates

    Implementations MUST be prepared to receive certificates and CRLs
    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



Korver                                                          [Page 17]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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

    Although implementations SHOULD NOT send multiple end entity
    certificates if the receipient cannot determine the correct
    certificate to use for authentication by using either the contents of
    the ID payload to match the certificate or, in IKEv2, the correct
    certificate is contained in the first CERT. In other words,
    receipients SHOULD NOT be expected to iterate over multiple end-
    entity certs.

3.3.11. Optimizations

3.3.11.1. Duplicate Certificate Payloads

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


3.3.11.2. Send Lowest 'Common' Certificates

    When multiple CERTREQs are received 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.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.


3.3.12. Hash Payload

    IKEv1 specifies the optional use of the Hash Payload to carry a
    pointer to a certificate in either of the Phase 1 public key
    encryption modes. This pointer is used by an implementation to  locate
    the end entity certificate that contains the public key that a peer



Korver                                                          [Page 18]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


    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

    Except where specifically stated in this document, implementations
    MUST conform to the requirements 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.

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.



Korver                                                          [Page 19]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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
    certificates in order to find the CA certificate which contains the
    key that was used to generate the signature.






Korver                                                          [Page 20]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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.

4.1.3.7. SubjectAltName

    Implementations SHOULD generate only the following GeneralName
    choices in the subjectAltName extension, as these choices map to



Korver                                                          [Page 21]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


    legal Identification Payload types: rfc822Name, dNSName, or
    iPAddress. Although it is possible to specify any GeneralName choice
    in the Identification Payload by using the ID_DER_ASN1_GN ID type,
    implementations SHOULD NOT assume 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.

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.




Korver                                                          [Page 22]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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.

4.1.3.14. CRLDistributionPoints

    Receiving CRLs in band via IKE 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



Korver                                                          [Page 23]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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



Korver                                                          [Page 24]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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

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



Korver                                                          [Page 25]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


    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
    whitespace at the beginning and end of any line, MUST support
    arbitrary line lengths although they SHOULD generate lines less than
    76 characters, and MUST support the following 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-----




Korver                                                          [Page 26]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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

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.





Korver                                                          [Page 27]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


6.4. IKEv1 Main Mode

    Implementations may not wish to respond with CERTs in the second
    message, thereby violating the identity protection feature of Main
    Mode in IKEv1. CERTs may 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.

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

    [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
    draft-ietf-ipsec-ikev2-13.txt, March 2004, work in progress.

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

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





Korver                                                          [Page 28]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


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

    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



Korver                                                          [Page 29]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


    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


    * May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt)


       Made it clearer that the format of the ID_IPV4_ADDR payload comes
       from RFC791 and is nothing new. (Tero Kivinen Feb 29)

       Permit implementations to skip verifying that the peer source
       address matches the contents of ID_IPV{4,6}_ADDR. (Tero Kivinen
       Feb 29, Gregory Lebovitz Feb 29)

       Removed paragraph suggesting that implementations favor
       unauthenticated peer source addresses over an unauthenticated ID
       for initial policy lookup. (Tero Kivinen Feb 29, Gregory Lebovitz
       Feb 29)

       Removed some text implying RSA encryption mode was in scope. (Tero
       Kivinen Feb 29)

       Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb 29)

       Made it clearer that out-of-scope local heuristics should be used
       for picking an EE cert to use when generating CERTREQ, not when
       receiving CERTREQ. (Tero Kivinen Feb 29)




Korver                                                          [Page 30]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


       Made it clearer that CERT processing can be skipped when the
       contents of a CERT are already known. (Tero Kivinen Feb 29)

       Implementations SHOULD generate BASE64 lines less than 76
       characters. (Tero Kivinen Feb 29)

       Added "Except where specifically stated in this document,
       implementations MUST conform to the requirements of PKIX" (Steve
       Hanna Oct 7, 2003)

       RECOMMENDS against populating the ID payload with IP addresses due
       to interoperability issues such as problem with NAT traversal.
       (Gregory Lebovitz May 14)

       Changed "as revoked by one source" to "as revoked by one trusted
       source". (Michael Myers, May 15)

       Specifying Certificate Authorities section needed to be
       regularized with Gregory Lebovitz's CERT proposal from -04. (Tylor
       Allison, May 15)

       Added text specifying how receipients SHOULD NOT be expected to
       iterate over multiple end-entity certs. (Tylor Allison, May 15)

       Modified text to refer to IKEv2 as well as IKEv1/ISAKMP where
       relevant.

       IKEv2: Explained that IDr sent by responder doesn't have to match
       the [IDr] sent initiator in second exchange.

       IKEv2: Noted that "The identity ... does not necessarily have to
       match anything in the CERT payload" (S3.5) is not contradicted by
       SHOULD in this document.

       IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and
       ID_USER_FQDN would be used exclusively in this document.

       IKEv2: Declared that 3 new CERTREQ and CERT types are not profiled
       in this document (well, at least not yet, pending WG discussion of
       what to do -- note that they are only SHOULDs in IKEv2).

       IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of
       SubjectPublicKeyInfo.

       IKEv2: Noted new requirement that specifies that the first
       certificate sent MUST be the EE cert (section 3.6).





Korver                                                          [Page 31]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


    * February 2004 (-04)

       Minor editorial changes to clean up language

       Deprecate in-band exchange of CRLs

       Incorporated Gregory Lebovitz's proposal for CERT payloads:
       "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




Korver                                                          [Page 32]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


       Aggressive Mode removed from this profile




    * 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


    * 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



Korver                                                          [Page 33]


Internet-Draft       PKI Profile for IKE/ISAKMP/PKIX
5/2004


    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.

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
































Korver                                                          [Page 34]