WDIFF

draft-ietf-pki4ipsec-ikecert-profile-00.txt --> draft-ietf-pki4ipsec-ikecert-profile-01.txt

Profiling the use of PKI in IPsec Brian Korver
(pkiPKI4Ipsec) Xythos Software
INTERNET-DRAFT May
Internet-Draft July 2004 (Expires Oct 2004)
<draft-ietf-pki4ipsec-ikecert-profile-00.txt>
Expires Jan 2005

The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
draft-ietf-pki4ipsec-ikecert-profile-01.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Draft. 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. By submitting this Internet-
Draft, I certify that any applicable patent or other IPR claims of
which I am aware have been disclosed, and any of which I become
aware will be disclosed, in accordance with RFC 3668

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

IKE/IPsec and PKIX both provide frameworks that must be profiled for
use in a given application. This document provides a profile of ISAKMP
IKE/IPsec and PKIX that defines the requirements for using PKI
technology in the context of IPsec. IKE/IPsec. The document complements
protocol specifications such as IKEv1 and IKEv2, which assume the
existence of public key certificates and related keying materials, but
which do not address PKI issues explicitly. This document addresses
those issues.

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 7/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) Lists (CRL and ARL) 11
3.2.4 Authority Revocation List (ARL) 12
3.2.5 PKCS #7 wrapped X.509 certificate 12
3.2.5 IKEv2's Hash and URL of 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) Lists (CRL & ARL) 16
3.3.5 Authority Revocation List (ARL)
3.3.4 IKEv2's Hash and URL of X.509 certificate 16
3.3.6
3.3.5 PKCS #7 wrapped X.509 certificate 16
3.3.7
3.3.6 Certificate Payloads Not Mandatory 16
3.3.8
3.3.7 Response to Multiple Certificate Authority Proposals 16
3.3.9
3.3.8 Using Local Keying Materials 17
3.3.10
3.3.9 Robustness 17
3.3.10.1
3.3.9.1 Unrecognized or Unsupported Certificate Types 17
3.3.10.2
3.3.9.2 Undecodable Certificate Data Fields 17
3.3.10.3
3.3.9.3 Ordering of Certificate Payloads 17
3.3.10.4
3.3.9.4 Duplicate Certificate Payloads 17
3.3.10.5
3.3.9.5 Irrelevant Certificates 17
3.3.11
3.3.10 Optimizations 18
3.3.11.1
3.3.10.1 Duplicate Certificate Payloads 18
3.3.11.2
3.3.10.2 Send Lowest 'Common' Only End Entity Certificates 18
3.3.11.3
3.3.10.3 Ignore Duplicate Certificate Payloads 18
3.3.12
3.3.11 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 7/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 and FQDN Host Names in Subject Name 19
4.1.2.4
4.1.2.3 EmailAddress 20
4.1.3 X.509 Certificate Extensions 20
4.1.3.1 AuthorityKeyIdentifier & SubjectKey ID 20
4.1.3.2 SubjectKeyIdentifier 21
4.1.3.3 KeyUsage 21
4.1.3.4
4.1.3.3 PrivateKeyUsagePeriod 21
4.1.3.5
4.1.3.4 Certificate Policies 21
4.1.3.6
4.1.3.5 PolicyMappings 21
4.1.3.7
4.1.3.6 SubjectAltName 21
4.1.3.7.1
4.1.3.6.1 dNSName 22
4.1.3.7.2
4.1.3.6.2 iPAddress 22
4.1.3.7.3
4.1.3.6.3 rfc822Name 22
4.1.3.8
4.1.3.7 IssuerAltName 22
4.1.3.9
4.1.3.8 SubjectDirectoryAttributes 22
4.1.3.10
4.1.3.9 BasicConstraints 23
4.1.3.11
4.1.3.10 NameConstraints 23
4.1.3.12
4.1.3.11 PolicyConstraints 23
4.1.3.13
4.1.3.12 ExtendedKeyUsage 23
4.1.3.14
4.1.3.13 CRLDistributionPoints 23
4.1.3.15
4.1.3.14 InhibitAnyPolicy 24
4.1.3.16
4.1.3.15 FreshestCRL 24
4.1.3.17
4.1.3.16 AuthorityInfoAccess 24
4.1.3.18
4.1.3.17 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 7/2004

8 IANA Considerations 28
9 Normative References 28
10 Informational References 29
11 Acknowledgements 29
12 Author's Addresses 29
Intellectual Property Statement
Full Copyright Statement
Appendix A - Change History
Appendix B - Possible Dangers of Delta CRLs
Appendix C - More on Empty CERTREQs

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 implementers do not make
similar choices, or at least fail to account for implementations
which have chosen differently.

This profile of the ISAKMP IKE and PKIX frameworks is intended to provide
an agreed-upon standard for using PKI technology in the context of
IPsec by profiling the PKIX framework for use with ISAKMP IKE and IPsec,
and by documenting the contents of the relevant ISAKMP IKE payloads and
further specifying their semantics.

In addition to providing a profile of ISAKMP IKE and PKIX, this document
attempts to incorporate lessons learned from recent experience with
both implementation and deployment, as well as the current state of
related protocols and technologies.

Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and
readers of this document are assumed to have read and understood 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 7/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, IKEv1,
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. 7/2004

Because implementations may use ID as a lookup key to determine which
policy to use, all implementations MUST be especially careful to
verify the truthfulness of the contents by verifying that they
correspond to some keying material demonstrably held by the peer.
Failure to do so may result in the use of an inappropriate or
insecure policy. The following sections describe the methods for
performing this binding.

The following table summarizes the binding of the Identification
Payload to the contents of end-entity certificates and of identity
information to policy. Each ID type | Support | is covered more thoroughly in the
following sections.

[1] = Implementation MUST be able have the configuration option to send based on
this ID type in the ID payload. Whether or not the ID type is
used is a matter of 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 7/2004

[3] = At a minimum, Implementation MUST be able to support be configured to
perform exact matching of the ID payload contents to an entry in
the SPD, but local SPD.

[4] = In addition, the implementation MAY also support be configurable to
perform substring or wildcard matches. matches of ID payload contents to
entries in the local SPD. (More on this in sect 3.1.5).

When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN,
implementations MUST be configurable able to be configured to send the same
string as appears in the corresponding SubjectAltName attribute. Recipients MAY
This document RECOMMENDS that deployers use wildcards this configuration
option. All these ID types are treated the same: as strings that can
be compared easily and quickly to do a corresponding string in an
explicit attribute in the SPD matching. certificate. Of these types, FQDN and
USER_FQDN are RECOMMENDED over IP addresses (see discussion in
3.1.1).

When sending a DN as ID, implementations MUST send the entire DN in
ID. Recipients MAY perform SPD lookup based on some combination of Also, implementations MUST support at least the C, CN, O, OU. Implementations and OU
attributes for SPD matching. See 3.1.5 for more details about DN,
including SPD matching.

Recipients MUST at a minimum be configurable able to match perform SPD matching on any combination the exact
contents of those 4 attributes. Implementations the ID, and this SHOULD be the default setting. In
addition, implementations MAY support
matching using other DN attributes use substrings or wildcards in any combination, including local
policy configuration to do the
entire DN. SPD matching against the ID contents.
In other words, implementations MUST be able to do exact matches of
ID to SPD, but MAY also be configurable to do substring or wildcard
matches of ID to SPD.

IKEv2 ads adds an optional IDr payload in the second exchange that the
initiator may send to the responder in order to specify which of the
responder's multiple identities should be used. The responder MAY
choose to send an IDr in the 3rd exchange that differs in type or
content from the initiator-
generator initiator-generated 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
Whether or ID_IPV6_ADDR not to accept such a response and continue with IKE
processing is a matter of local policy.

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 does NOT RECOMMEND populating the ID payload
with IP addresses due to interoperability issues such as problem problems with
NAT traversal.

Implementations traversal, and problems with IP verification behavior.

Deployments may only want to consider using the IP address as IKE_ID
if the following are true:
- the peer's IP address are fixed, not dynamically changing
- the peer's are NOT behind a NAT'ing device
- the administrator intends the implementation to verify that the
IP address in the peer's source matches the IP address in the IKE_ID
received, and that of the certificate's iPAddress field in the
subjectAltName extension.

Implementation MUST be capable of verifying that the IP address
contained
presented in ID is IKE_ID matches via bitwise comparison the same as IP address
present in the peer source address. certificate's iPAddress field in the subjectAltName
extension. Implementations MAY provide a configuration option to skip that
verification step, but that option MUST be off perform this verification by default. If the end
entity certificate contains address identities, then
When comparing the peer source
address must match at least one contents of those identities. ID with the iPAddress field in the
subjectAltName extension for equality, binary comparison MUST be
performed. If either of the
above do not match, this default is enabled, then a mismatch between the
two 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 Implementations MAY
provide a configuration option to (i.e. local policy configuration
can enable) skip that requires verification step, but that option MUST be off
by default. We include the peer source address exist "option-to-skip" in the
certificate. Implementations SHOULD order to permit
better interoperability, as today implementations vary greatly in
how they behave on this topic of verification between IKE_ID and
cert contents.

Implemenations MUST be capable of verifying that the address
contained in the ID is the same as the peer source address. If
IKE_ID is one of the IP address types, then implementations MUST
perform this verification by default. If this default is enabled,
then a mismatch MUST be treated as an error and security association
setup MUST be aborted. This event SHOULD be auditable.
Implementations MAY provide a configuration option to (i.e. local
policy configuration can enable) skip that verification step, but
that option MUST be off by default. We include the "option-to-skip-
validatation" in order to permit better interoperability, as today
implementations vary greatly in how they behave on this topic of
verification to source IP.

If the default for both the verifications above are enabled, then,
by transitive property, the implementation will also be verifying
that the peer source IP address matches via a bitwise comparison the
contents of the iPAddress field in the subjectAltName extension in
the certificate. In addition, implementations MAY allow
administrators to configure a local policy that does not enforce explicitly requires
that the peer source IP address match via a bitwise comparison the
contents of the iPAddress field in the subjectAltName extension in
the certificate. Implementations SHOULD allow administrators to
configure a local policy that skips this requirement. validation check.

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

Implementations MAY support substring, wildcard, or regular
expression matching of the IKE_ID to contents in the SPD, and such
would be a matter of local security policy configuration.

Implementations MAY use the IP address found in the header of packets
received from the peer to 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

Implemenations MUST be capable of verifying that the identity
contained in the ID payload matches identity information contained
in the peer end entity certificate, in the dNSName field in the
subjectAltName extension. Implementations MUST perform this
verification by default. When comparing the contents of ID with the
dNSName field in the subjectAltName extension 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. performed for this comparison. If there
this default is not enabled, then a
match, this mismatch MUST be treated as an error
and security association setup MUST be aborted. This event SHOULD be
auditable. Implementations MAY provide a configuration option to
(i.e. local policy configuration can enable) skip that verification
step, but that option MUST be off by default. We include the
"option-to-skip-validatation" in order to permit better
interoperability, as today implementations vary greatly in how they
behave on this topic.

Implementations MAY support substring, wildcard, or regular
expression matching of the IKE_ID to contents in the SPD, and such
would be a matter of local security policy configuration.

Korver [Page 8]
Internet-Draft PKI Profile for IKE/ISAKMP/PKIX
5/2004 7/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.

Implemenations MUST be capable of verifying that the identity
contained in the ID payload matches identity information contained
in the peer end entity certificate, in the rfc822Name field in the
subjectAltName extension. Implementations MUST perform this
verification by default. When comparing the contents of ID with the
rfc822Name field in the subjectAltName extension for equality,
caseless string comparison MUST be performed. Substring, wildcard,
or regular expression matching MUST NOT be performed.

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 MAY provide a
configuration option to (i.e. local policy configuration can enable)
skip that verification step, but that option MUST be off by default.
We include the "option-to-skip-validatation" in order to permit
better interoperability, as today implementations vary greatly in
how they behave on this topic.

Implementations MAY support substring, wildcard, or regular
expression matching of the IKE_ID to contents in the SPD, and such
would be a matter of local security policy configuration.

3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE,
ID_IPV6_ADDR_RANGE

Note that 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 MUST be capable of generating this type. Implementations which
generate type, and the
decision to do so will be a matter of local security policy
configuration. When generating this type type, implementations 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. 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. 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 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 7/2004

Regarding SPD matching, implementations MUST verify that be able to perform
matching based on a bitwise comparison of the identity contained entire DN in the ID
payload matches identity information contained to its
entry in the peer end entity
certificate, in SPD. However, operational experience has shown that
using the Subject Name field. If there entire DN in local configuration is not a match, this
MUST be treated as an error and security association setup difficult, especially
in large scale deployments. Therefore, implementations also 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
able to specify pre-shared perform SPD matches of any combination of one or more of the
C, CN, O, OU attributes within Subject DN in the ID to the same in
the SPD. Implementations MAY support matching using additional DN
attributes in any combination, although interoperability is far from
certain and dubious. Implementations MAY also support performing
substring, wildcard, or regular expression matches for any of its
supported DN attributes from ID, in any combination, to the SPD.
Such flexibility allows deployers to create one SPD entry on the
gateway for an entire department of a company (e.g. O=Foobar Inc.,
OU=Engineering) while still allowing them to draw out other details
from the DN (e.g. CN=John Doe) for auditing purposes. All the above
is a matter of local implementation and local policy definition and
enforcement capability, not bits on the wire, but will have a great
impact on interoperability.

3.1.6. ID_DER_ASN1_GN

Implementations MUST NOT generate this type.

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

The identity with which an implementation chooses to populate ID with the
IKE_ID payload is a local matter. For compatibility with non-conformant 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 MUST select the most appropriate identity with which to from the
certificate and populate ID. Therefore, when
determining the appropriate policy, implementations SHOULD select ID with that. The responder MUST use
the
most appropriate identity to sent as a first key when selecting the policy.
Responder MUST also use most specific policy from that database if
there are overlapping policies caused by wildcards (or the identities contained in
implementation can de-correlate the
certificate. policy database so there will
not be overlapping entries, or it can also forbid creation of
overlapping policies and leave the de-correlation process to the
administrator, but this moves the problem to administrator it is NOT
RECOMMENDED).

For example, imagine that a peer is configured with a certificate
that contains both a non-empty Subject Name and an a dNSName.
Independent of The
initiator MUST know by policy which identity is used of those to populate ID, use, and it
indicates the host
implementation MUST locate policy in the proper policy. For instance, if ID
contains other end by selecting the peer Subject correct ID.
If the responder has both a specific policy for the dNSName for this
host, and generic wildcard rule for some attributes present in the
subject Name, then it will match a different policy depending which ID is
sent. As the peer end entity certificate
may initiator knows why it wanted to connect the responder,
it also knows what identity it should use to match the policy it
needs to the operation it tries to perform; it is the only party who
can select the ID adequately.

In the event the policy cannot be found in the responder's SPD using
the Subject Name as a key. Once ID sent by the certificate
has been located and initiator, then validated, the dNSName responder MAY use the other
identities in the certificate
can be used when attempting to locate the appropriate match a suitable
policy. In other words, the
Subject Name is used to find the certificate, For example, say the certificate contains the dNSName, and the both non-
empty'subject Name, dNSName is used to lookup policy.

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

3.2. Certificate Request Payload and iPAddress. The Certificate Request (CERTREQ) Payload allows an implementation to
request that a peer provide some set initiator sends ID of certificates or certificate
revocation lists. It is
iPAddress, but the responder does not clear from ISAKMP exactly how have that set
should be specified or how in the peer should respond. We describe policy
database. If the
semantics on both sides.

3.2.1. Certificate Type

The Certificate Type field identifies to responder has a rule for the peer dNSName it MAY use
policy based on that.

If overlapping policies are found in this step, the type responder cannot
know which one of
certificate keying materials that are desired. ISAKMP defines those should be selected, i.e. if the responder
does have rules for both Subject Name and for dNSName, and it would
need to select one of those policies, but it cannot know which one
to select. One or both of those rules could also be wildcard rules.

The responder cannot use de-correctlation or forbidding the
overlapping policies, as there is no way to detect those overlaps
exist before the arrival of the certificate that makes the
overlapping a reality. In the case where overlapping policies exist,
the responder SHOULD terminate the negotiation with error, which
informs the other end that adminstrative modification to its policy
must be performed (i.e. it needs to use some other identity).

Korver [Page 10]
Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 7/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) Lists (CRL and ARL)
* PKCS #7 wrapped X.509 certificate
* IKEv2's Hash and URL of 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:
* IKEv2's Raw RSA Key
* Hash and URL of X.509 certificate
* IKEv2's Hash and URL of X.509 bundle

are out of the scope of this document.

3.2.2. X.509 Certificate - Signature

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

3.2.3. Certificate Revocation List (CRL) Lists (CRL and ARL)

ISAKMP and IKEv2 do not support Certificate Payload sizes over
approximately 64K, which is too small for many CRLs. In addition,
the acquisition of revocation material is to be dealt with out of
band of IKE. For this and other reasons, implementations SHOULD NOT
generate CERTREQs where the

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

Certificate Type is "Certificate Revocation List (CRL)". Upon receipt
of such a CERTREQ, implementations (CRL)" or
"Authority Revocation List (ARL)". Implementations that do generate
such CERTREQs MUST NOT expect the responder to send a CRL or ARL,
and MUST NOT fail for not receiving it. Upon receipt of such a
CERTREQ, implementations MAY ignore the request.

3.2.4.

In lieu of exchanging entire revocation lists in band, a pointer to
revocation checking SHOULD be listed in either the Certificate
Distribution Point (CDP) or the Authority Revocation List (ARL) Information Access (AIA)
attributes of the certificate extensions (see section 4 for
details.) Implementations SHOULD NOT generate CERTREQ payloads with this type.
Recipients MUST be able to process these attributes,
and from them be able to identify cached revocation material, or
retrieve the relevant revocation material from a URL, for validation
processing. In addition, implementations MUST have the ability to
configure validation checking information for each certificate
authority. Regardless of this type SHOULD treat it as synonymous with the CRL
type.

3.2.5. method (CDP, AIA, or static
configuration), the acquisition of revocation material occurs out of
band of IKE.

3.2.4. 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.5 IKEv2's Hash and URL of X.509 certificate

This ID type defines a request for the peer to send a hash and URL
of it X.509 certificate, instead of the actual certificate itself.
This is a particularly useful mechanism when the peer is a device
with little memory and lower bandwidth, e.g. a mobile handset or
consumer electronics device.

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 corresponding to and including the
certificate whose Issuer Name matches the name specified in the Certificate Authority field.
listed in the CERTREQ. Implementations MAY SHOULD NOT NOT send any
certificates other
certificates. than the appropriate end entity certificate (see
sect 3.3 for discussion).

Note, in the case where multiple end entity certificates may be
available, implementations SHOULD resort to local heuristics to

Korver [Page 12 ] 12]
Internet-Draft PKI Profile for IKE/ISAKMP/PKIX
5/2004 7/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.

3.2.6.2. Empty Certificate Authority Field

Implementations MUST NOT SHOULD generate CERTREQs where the Certificate Type is
"X.509 Certificate - Signature" and where an entry exits in the
Certificate Authority field. However, implementations MAY generate
CERTREQs 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 field under special
conditions. Though 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
fields, there does exist a use case where doing so is appropriate, and supported
CERTREQs, implementations MAY treat them as if they are
carries special meaning in the IKE context. This has become a
convention within the IKE interoperability tests and usage space, and
so its use is specified, explained and RECOMMENDED here for the sake
of interoperability.

USE CASE: Consider the case where you have a
supported type gateway with multiple
policies for a large number of IKE peers.'some of these peers are
business partners, some are remote access employees, some are
teleworkers, some are branch offices, and/or the 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 gateway may be taken.

3.2.8.3. Ordering
simultaneously serving many many customers (e.g. Virtual Routers). The
total number of Certificate Request Payloads

Implementations MUST NOT assume certificates, and corresponding trust anchors, is very
high, say hundreds. Each of these policies is configured with one or
more acceptable trust anchors, so that 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 total, the gateway has one
hundred (100) trust anchors that could possibly used to authenticate
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 incoming connection. Assume that many of those connections
originate from hosts/gateways with dynamically assigned IP addresses,
so that the
certificates source IP of the peer would normally respond with. In addition IKE initiator is not known to the
normal set of CERTREQs that are sent specifying the trust anchors, an
implementation MAY send CERTREQs containing gateway,
nor is the Issuer Name identity of the
relevant cached end entity certificates. When sending these hints, intiator (until it is still necessary revealed in Main Mode
message 5). In IKE main mode message 4, the responder gateway will
need to send a CERTREQ to the normal set of CERTREQs because initiator. Given this example, the
hints do not sufficiently convey all
gateway will have no idea which 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 hundred possible Certificate
Authorities to send in
this context but will not be specified if only supplying the issuer
of the end entity certificate.

No special CERTREQ. Sending all possible Certificate
Authorities will cause significant processing delays, bandwidth
consumption, and UDP fragmentation, so this tactic is required on the part of the recipient of ruled out.

In such a CERTREQ, and deployment, the end entity certificates will still responder gateway implementation should be sent.
On the other hand, the recipient MAY elect
able to elide certificates
based on receipt of such hints.

CERTREQs must contain information that identifies all it can to indicate a Certification Certificate Authority certificate, which results in the peer always sending at
least the end entity certificate. CERTREQ.
This mechanism allows
implementations to determine unambiguously when a new certificate is
being used by the peer, perhaps because means 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 responder SHOULD first check SPD to see if it by not performing this optimization when can match
the exchange source IP, and find some indication of which CA is
retried.

3.2.9.3. Example

Imagine associated with
that an implementation has previously received and cached the
peer certificate chain TA->CA1->CA2->EE. IP. If during a subsequent
exchange this implementation sends a CERTREQ containing fails (because the Subject
Name in certificate TA, this implementation source IP is requesting that not familiar, as in
the
peer send at least 3 certificates: CA1, CA2, and EE. On case above), then the other
hand, if this implementation also sends responder SHOULD have a CERTREQ containing the
Subject Name of CA2, configuration option
specifying which CA's are the implementation is providing a hint that only
1 certificate needs default CAs to be sent: EE. Note that indicate in this example, the
fact that TA CERTREQ
during such ambiguous connections (e.g. send CERTREQ with these N CAs
if there is an unknown source IP). If such a trust anchor should not be construed to imply that
TA fall-back is not
configured or impractical in a self-signed certificate.

3.3. certain deployment scenario, then the
responder implementation SHOULD have both of the following
configuration options:

- send a CERTREQ payload with an empty Certificate Payload

The Authority field,
or

- terminate the negotiation with an appropriate error message and
audit log entry.

Receiving a CERTREQ payload with an empty Certificate (CERT) Payload allows Authority field
indicates that the initiator peer to transmit a single
certificate or CRL. Multiple should send all/any certificates it
has, regardless of the trust anchor. The initiator should be transmitted in

Korver [Page 14]
Internet-Draft PKI Profile for IKE/ISAKMP/PKIX
5/2004 aware of
what policy and which identity it will use, as it initiated the
connection on a matched policy to begin with, and can thus respond
with the appropriate certificate. If multiple payloads. However, not all certificate forms that certificates are legal
in PKIX make sense sent,
they MUST have the same public key, otherwise the responder does not
know which key was used in the context of IPsec. The issue of how to
represent IKE-meaningful name-forms Main Mode message 5.

If, after sending an empty CERTREQ in Main Mode message 4, a certificate is especially
problematic. This memo provides responder
receives a profile for certificate in message 5 from a subset of PKIX trust anchor that
makes sense the
responder either (a) does NOT support, or (b) was not configured for IKEv1/ISAKMP
the policy (that policy was now able to be matched due to having the
initiators certificate present), then the responder SHOULD terminate
the exchange with proper error message and IKEv2.

3.3.1. Certificate Type

The Certificate Type field identifies audit log entry.

Instead of sending a empty CERTREQ, the responder implementation may
be configured to terminate the peer negotiation on the type grounds of
certificate keying materials that are included. ISAKMP defines 10
types a
conflict with locally configured security policy.

The decision of Certificate Data which to configure is a matter of local security
policy, this document RECOMMENDS that can both options be sent presented to
administrators.

More examples, and specifies the syntax
for these types. For the purposes of explanation on this document, only the
following types issue are relevant:

* X.509 Certificate included in Appendix
C - Signature
* More on Empty CERTREQs.

3.2.7. Robustness

3.2.7.1. Unrecognized or Unsupported 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 Types

Implementations MUST be able to deal with receiving CERTREQs with
unsupported Certificate - Attribute Types. Absent any recognized and supported
CERTREQs, implementations MAY treat them as if they are out of the scope of this document.

In addition to a
supported type with the above, IKEv2 adds 3 Certificate Authority field left empty,
depending on local policy. ISAKMP Section 5.10 "Certificate Request
Payload Processing" specifies 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 processing.

3.2.7.2. Undecodable Certificate - Signature

This type requests that the end entity certificate Authority Fields

Implementations MUST be a signing
certificate.

3.3.3. X.509 able to deal with receiving CERTREQs with
undecodable Certificate - Signature

This type Authority fields. Implementations MAY ignore
such payloads, depending on local policy. ISAKMP specifies other
actions which may be taken.

3.2.7.3. Ordering of Certificate Request Payloads

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

3.2.8. Optimizations

3.2.8.1. Duplicate Certificate Data contains a certificate used
for signing, whether Request Payloads

Implementations SHOULD NOT send duplicate CERTREQs during an end entity signature certificate or a CA
signature certificate.
exchange.

Korver [Page 15] 13]
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 7/2004

3.2.8.2. Name Lowest 'Common' Certification Authorities

When a peer's certificate keying materials have been cached, an X.509 CRL that
applies only to CA certificates. Recipients
implementation can send a hint to the peer to elide some 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
certificates the peer would normally respond with. In addition 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
normal set of CERTREQs during that are sent specifying the trust anchors, an
exchange SHOULD NOT
implementation MAY send any CERT payloads, except when explicitly
configured CERTREQs containing the Issuer Name of the
relevant cached end entity certificates. When sending these hints, it
is still necessary to proactively send CERT payloads 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 order to interoperate
with non-compliant implementations. In
this case, an implementation
MAY send the certificate chain (not including context but will not be specified if only supplying the trust anchor)
associated with issuer
of the end entity certificate. This MUST NOT be

No special processing is required on the
default behavior part of implementations.

Implementations which are configured to expect that the recipient of
such a peer must
receive CERTREQ, and the end entity 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 will still be sent.
On the
exchange, in order to avoid unnecessary and potentially expensive
cryptographic processing.

3.3.8. Response to Multiple Certificate Authority Proposals

In response other hand, the recipient MAY elect to multiple elide certificates
based on receipt of such hints.

CERTREQs which must contain different Certificate information that identifies a Certification
Authority identities, implementations MAY respond using an certificate, which results in the peer always sending at
least the end entity
certificate which chains certificate. This mechanism allows
implementations to determine unambiguously when a CA that matches any of the identities
provided new certificate is
being used 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 peer, perhaps because the processing of previous certificate has
just expired, which will result in a given set of CERTs
if preferable failure because the needed
keying materials are available. For instance, the
contents of a CERT may be available from a previous exchange or may
be not 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 validate the new end entity
certificate. Implementations which implement this optimization 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
recognize when the end entity certificate which is to be used has changed and respond to
authenticate
it by not performing this optimization when the peer.

3.3.10.4. Duplicate Certificate Payloads

Implementations MUST support receiving multiple identical CERTs
during exchange is retried.

3.2.8.3. Example

Imagine that an exchange.

3.3.10.5. Irrelevant Certificates

Implementations MUST be prepared to receive certificates implementation has previously received and CRLs
which are not relevant to cached 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
peer certificate chain TA->CA1->CA2->EE. If during a subsequent
exchange is to minimize this implementation sends a CERTREQ containing the threat of leaking identifying
information Subject
Name in exchanges where CERT is not encrypted. It should be
noted, however, that certificate TA, 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 implementation is requesting that there may be two chains from the Certificate
Authority to
peer send at least 3 certificates: CA1, CA2, and EE. On the end entity, each other
hand, if this implementation also sends a CERTREQ containing the
Subject Name of which CA2, the implementation is providing a hint that only valid with certain
validation parameters (such as acceptable policies). Since the end
entity doesn't know which parameters
1 certificate needs to be sent: EE. Note that in this example, the relying party
fact that TA is using, it a trust anchor should send not be construed to imply that
TA is a self-signed certificate.

3.3. Certificate Payload

The Certificate (CERT) Payload allows the certs needed for both chains (even if there's only
one CERTREQ).

Although peer to transmit a single
certificate or CRL. The following practice is explicitly deprecated:
Some implementations SHOULD NOT send multiple end entity
certificates if the receipient cannot determine the correct also transmit each certificate to use for authentication by using either in the contents of chain above
the ID payload end entity certificate up to match and including the certificate or, whose
Issuer Name matches the name specified in IKEv2, the correct
certificate Certificate Authority
field. This practice is contained in deprecated because the first CERT. In other words,
receipients chaining certificates
and validation material has now become a responsibility of the
lifecycle protocols between the IPsec peer and the PKI system, and not
the transmission within IKE. Therefore implementations SHOULD NOT be expected to iterate over multiple end- send
any certificates other than the appropriate end entity certs.

3.3.11. Optimizations

3.3.11.1. Duplicate Certificate Payloads

Implementations certificate,
and SHOULD NOT send duplicate CERTs during an exchange.
Such payloads any CRLs/ARLs.

Multiple certificates should be suppressed.

3.3.11.2. Send Lowest 'Common' Certificates

When transmitted in

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

multiple CERTREQs are received which specify certificate
authorities within the end entity payloads. However, not all certificate chain, implementations
MAY send forms that are legal
in PKIX make sense in the shortest chain possible. However, implementations SHOULD
always send the end entity certificate. See section 3.2.9.2 context of IPsec. The issue of how to
represent IKE-meaningful name-forms in a certificate is especially
problematic. This document provides a profile for more
discussion a subset of this optimization.

3.3.11.3. Ignore Duplicate PKIX
that
makes sense for IKEv1/ISAKMP and IKEv2.

3.3.1. Certificate Payloads

Implementations MAY employ local means Type

The Certificate Type field identifies to recognize CERTs that have
been received in the past, whether part of peer the current exchange or
not, for which type of
certificate keying material is available materials that are included. ISAKMP defines 10
types of Certificate Data that can be sent and may discard these
duplicate CERTs.

3.3.12. Hash Payload

IKEv1 specifies the optional use syntax
for these types. For the purposes of this document, only the
following types are relevant:

* X.509 Certificate - Signature
* Revocation Lists (CRL and ARL)
* PKCS #7 wrapped X.509 certificate
* IKEv2's Hash Payload to carry a
pointer to a and URL of X.509 certificate in either

The use of the Phase 1 public key
encryption modes. other types:

* X.509 Certificate - Key Exchange
* PGP Certificate
* DNS Signed Key
* Kerberos Tokens
* SPKI Certificate
* X.509 Certificate Attribute
* IKEv2's Raw RSA Key
* IKEv2's Hash and URL of X.509 bundle

are out of the scope of this document.

3.3.2. X.509 Certificate - Signature

This pointer is type specifies that Certificate Data contains a certificate used by
for signing. Implementations SHOULD only send an implementation to locate
the end entity certificate that contains the public key that a peer signature
certificate.

Korver [Page 18] 15]
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 7/2004

3.3.3. Revocation Lists (CRL and ARL)

These types specify that Certificate Data contains an X.509 CRL or ARL.
These types SHOULD NOT be sent in IKE. See section 3.2.3 for discussion.

3.3.4. IKEv2's Hash and URL of X.509 certificate

This type specifies that Certificate Data contains a hash and the keypair has been placed in URL
to a certificate.

4. Profile of PKIX

Except repository where specifically stated in an X.509 certificate can be retrieved.

3.3.5. PKCS #7 wrapped X.509 certificate

This type defines a particular encoding, not a particular certificate
type. Implementations SHOULD NOT generate CERTs that contain this document,
Certificate Type. Implementations SHOULD accept CERTs that contain
this Certificate Type because several implementations
MUST conform are known to
generate them. Note that those implementations may include entire
certificate hierarchies inside a single CERT PKCS #7 payload, which
violates the requirements of [PKIX].

4.1. X.509 Certificates

4.1.1. Versions

Although PKIX states requirement specified in ISAKMP that "implementations this payload
contain a single certificate.

3.3.6. Certificate Payloads Not Mandatory

An implementation which does not receive any CERTREQs during an
exchange SHOULD be prepared to
accept NOT send any version certificate", CERT payloads, except when explicitly
configured to proactively send CERT payloads in practice this profile requires
certain extensions that necessitate order to interoperate
with non-compliant implementations. This MUST NOT be the use
default behavior of Version 3 certificates
for all but self-signed certificates used as trust anchors. implementations.

Implementations whose local security policy configuration expects 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
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 an empty
Subject Name field, as specified in PKIX. Identity information in
such certificates will be contained entirely in only
unrecognized Certification Authorities SHOULD NOT continue the SubjectAltName
extension.

4.1.2.2. Specifying Non-FQDN Hosts
exchange, in Subject Name

Implementations which desire order to place host names that are not
intended avoid unnecessary and potentially expensive
cryptographic processing, denial of service (resource starvation)
attacks.

3.3.7. Response to be processed by recipients as FQDNs (for instance
"Gateway Router") in the Subject Name MUST use the commonName
attribute.

While nothing prevents Multiple Certificate Authority Proposals

In response to multiple CERTREQs which contain different Certificate
Authority identities, implementations MAY respond using 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 end entity
certificate which chains to a CA that matches any of
populating the dNSName field of identities
provided by the SubjectAltName extension. peer.

Korver [Page 19] 16]
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 7/2004

3.3.8. Using Local Keying Materials

Implementations MAY elect to skip the EmailAddress attribute.

4.1.3. X.509 Certificate Extensions

Conforming applications MUST recognize extensions which must 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 marked critical according to this specification. These extensions
are: KeyUsage, SubjectAltName, and BasicConstraints. available through some out-of-band means.

3.3.9. Robustness

3.3.9.1. Unrecognized or Unsupported Certificate Types

Implementations SHOULD generate certificates such that the extension
criticality bits are set in accordance MUST be able to deal with PKIX and this document.
With respect receiving CERTs with
unrecognized or unsupported Certificate Types. Implementations MAY

discard such payloads, depending on local policy. ISAKMP Section 5.10
"Certificate Request Payload Processing" specifies additional
processing.

3.3.9.2. Undecodable Certificate Data Fields

Implementations MUST be able to PKIX compliance, implementations processing
certificates deal with receiving CERTs with
undecodable Certificate Data fields. Implementations MAY ignore the value discard such
payloads, depending on local policy. ISAKMP specifies other actions
which may be taken.

3.3.9.3. Ordering of the criticality bit for
extensions Certificate Payloads

For IKEv1, implementations MUST NOT assume that CERTs are supported by that implementation, but ordered in
any way. For IKEv2, implementations MUST
support the criticality bit for extensions NOT assume that are not supported by any except
the first CERT is ordered in any way. IKEv2 specifies that implementation. That is, if an implementation supports (and thus the first
CERT contain the end entity certificate which is going to process) a given extension, then it isn't necessary be used to
reject the certificate if
authenticate the criticality bit is different from what
PKIX states it must be. However, if an implementation does not peer.

3.3.9.4. Duplicate Certificate Payloads

Implementations MUST support receiving multiple identical CERTs
during an extension that PKIX mandates exchange.

3.3.9.5. Irrelevant Certificates

Implementations MUST be critical, then the
implementation must reject prepared to receive certificates and CRLs
which are not relevant to 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 current exchange. Implementations SHOULD NOT assume that other implementations support
the AuthorityKeyIdentifier extension, MAY
discard such extraneous certificates and thus SHOULD NOT generate
certificate hierarchies CRLs.

Implementations MAY send certificates which are overly complex irrelevant 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 an
exchange. One reason for including certificates in order to find the CA certificate which contains the
key that was used are irrelevant
to generate an exchange is to minimize the signature. 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 20] 17]
Internet-Draft PKI Profile for IKE/ISAKMP/PKIX
5/2004

4.1.3.2. SubjectKeyIdentifier

Implementations SHOULD NOT assume 7/2004

against leaking the identity.

Another reason for including certificates that other implementations support seem irrelevant to an
exchange is that there may be two chains from the SubjectKeyIdentifier extension, and thus SHOULD NOT generate
certificate hierarchies which are overly complex Certificate
Authority to process in the
absence end entity, each of this extension, such which is only valid with certain
validation parameters (such as those that require possibly
verifying a signature against a large number of similarly named CA
certificates in order to find acceptable policies). Since the CA certificate end
entity doesn't know which contains the
key that was used to generate the signature.

4.1.3.3. KeyUsage

The meaning of parameters the nonRepudiation bit relying party is not defined in using, it
should send the context
of IPsec, although certs needed for both chains (even if there's only
one CERTREQ).

Although implementations SHOULD interpret the
nonRepudiation bit as synonymous with the digitalSignature bit.
Implementations SHOULD NOT generate send multiple end entity
certificates which only assert
the nonRepudiation bit.

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

4.1.3.4. PrivateKeyUsagePeriod

PKIX recommends against receipient cannot determine the use of this extension. The
PrivateKeyUsageExtension is intended to be used when signatures will
need correct
certificate to be verified long past the time when signatures use for authentication by using either the
private keypair may be generated. Since IKE SAs are short-lived
relative contents of
the ID payload to match the intended use of this extension certificate or, in addition to IKEv2, the
fact that each signature correct
certificate is validated only a single time, the
usefulness of this extension contained in the context of IKE is unclear.
Therefore, implementations MUST first CERT. In other words,
receipients SHOULD NOT generate certificates that
contain the PrivateKeyUsagePeriod extension.

4.1.3.5. Certificate Policies

Many IPsec implementations do not currently provide support for the be expected to iterate over multiple end-
entity certs.

3.3.10. Optimizations

3.3.10.1. Duplicate Certificate Policies extension. Therefore, implementations that
generate certificates which contain this extension Payloads

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

3.3.10.2. Send Only End Entity Certificates

When multiple CERTREQs are received which specify certificate
authorities within the
extension as non-critical.

4.1.3.6. PolicyMappings

Many end entity certificate chain, implementations do not support the PolicyMappings extension.

4.1.3.7. SubjectAltName

Implementations
SHOULD generate send always and only the following GeneralName
choices in the subjectAltName extension, relevant end entity certificate, 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
chaining will take place out-of-band of IKE, between the ID_DER_ASN1_GN ID type,
implementations SHOULD NOT assume that a IPsec peer supports such
functionality.

4.1.3.7.1. dNSName

This field MUST contain a fully qualified domain name.
and the PKI system. Implementations MUST SHOULD NOT generate names that contain wildcards. send the chain.

3.3.11.0. Ignore Duplicate Certificate Payloads

Implementations MAY treat certificates employ local means to recognize CERTs that contain wildcards have
been received in this
field as syntactically invalid.

Although this field the past, whether part of the current exchange or
not, for which keying material is in available and may discard these
duplicate CERTs.

3.3.11. Hash Payload

IKEv1 specifies the form 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 FQDN, implementations SHOULD
NOT assume implementation to locate
the end entity certificate that this field contains an FQDN the public key that will resolve via a peer

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

should use for encrypting payloads during the
DNS, unless exchange.

Implementations SHOULD include this is known by way payload whenever the public
portion of some out-of-band mechanism. Such the keypair has been placed in a mechanism is out certificate.

4. Profile of PKIX

Except where specifically stated in this document, implementations
MUST conform to the scope requirements of this document. Implementations [PKIX].

4.1. X.509 Certificates

4.1.1. Versions

Although PKIX states that "implementations SHOULD NOT treat the failure be prepared to resolve as an error.

4.1.3.7.2. iPAddress

Note that although PKIX permits CIDR [CIDR] notation
accept any version certificate", in practice this profile requires
certain extensions that necessitate the "Name
Constraints" extension, PKIX explicitly prohibits using CIDR notation use of Version 3 certificates
for conveying identity information. In other words, the CIDR notation
MUST NOT be all but self-signed certificates used in the subjectAltName extension.

4.1.3.7.3. rfc822Name

Although as trust anchors.
Implementations that conform to this field is document MAY therefore reject
Version 1 and Version 2 certificates in all other cases.

4.1.2. Subject Name

Certificate Authority implementations MUST be able to create
certificates with Subject Name fields with at least the form following four
attributes: CN, C, O, OU. Implementations MAY support other Subject
Name attributes as well. The contents of an Internet mail address,
implementations these attributes SHOULD NOT assume that this field contains be
configurable on a valid
email address, unless this is known certificate 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 certificate basis, as these fields
will likely be displayed used by IKE implementations to end
users.

4.1.3.9. SubjectDirectoryAttributes

The SubjectDirectoryAttributes extension is intended match SPD policy.

See sect 3.1.5 for details on how IKE implementations need to be able
to process Subject Name field attributes for SPD policy lookup.

4.1.2.1. Empty Subject Name

Implementations MUST accept certificates which contain
privilege information, an empty
Subject Name field, as specified in a manner analogous to privileges carried PKIX. Identity information in
Attribute Certificates.
such certificates will be contained entirely in the SubjectAltName
extension.

4.1.2.2. Specifying Hosts and FQDN in Subject Name

Implementations MAY ignore this extension
when it 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 IKE_ID or for policy lookup.

If the FQDN is marked non-critical, intended to be processed as PKIX mandates. identity for the purposes
IKE_ID matching, it MUST be placed in the dNSName field of the
SubjectAltName extension. Implementations MUST NOT populate the
Subject Name in place of populating the dNSName field of the
SubjectAltName extension.

Korver [Page 22] 19]
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 7/2004

4.1.2.3. 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. critical according to this specification. These extensions
are: KeyUsage, SubjectAltName, and BasicConstraints.

Implementations SHOULD reject CA generate certificates such that do not contain the extension
criticality bits are set in accordance with PKIX and this extension. For backwards compatibility, document.
With respect to PKIX compliance, implementations may accept such processing
certificates if explicitly configured
to do so, but MAY ignore the default value of the criticality bit for this setting
extensions that are supported by that implementation, but MUST be to reject such
certificates.

4.1.3.11. NameConstraints

Many implementations do not
support the NameConstraints extension.
Since PKIX mandates criticality bit for extensions that this extension be marked critical when
present, implementations which intend are not supported by
that implementation. That is, if an implementation supports (and thus
is going to be maximally interoperable
SHOULD NOT generate certificates which contain this extension.

4.1.3.12. PolicyConstraints

Many implementations do 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 the PolicyConstraints extension.
Since an extension that PKIX mandates that this extension be marked critical when
present, critical, then the
implementation must reject the certificate.

4.1.3.1. AuthorityKeyIdentifier & SubjectKey ID

Implementations SHOULD NOT assume that other implementations which intend to be maximally interoperable support
the AuthorityKeyIdentifier and SubjectKey ID extensions, and thus
SHOULD NOT generate certificates certificate hierarchies 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 overly complex
to process in the absence of this
certificate for IPsec MUST be treated extension, such as an error unless those that
require possibly verifying a signature against a large number of
similarly named CA certificates in order to find the
extension CA certificate
which contains the anyExtendedKeyUsage keyPurposeID, which
asserts key that the certificate can be was used for any purpose.
Implementations MAY ignore this extension if it is marked non-
critical. Implementations MUST NOT to generate this extension the signature.

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

4.1.3.2. KeyUsage

KeyUsage is not defined in the context of IPsec. Implementations
SHOULD accept certificates which are being with any set of KeyUsage bits asserted, as
certificates may be used for IPsec.

Note that a previous proposal for multiple applications.

4.1.3.3. PrivateKeyUsagePeriod

PKIX recommends against 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 extension. The
PrivateKeyUsageExtension is intended to be used when signatures will
need to be verified long past the requirement time when signatures using the
private keypair may be generated. Since IKE SAs are short-lived
relative to
process the CRLDistributionPoints if intended use of this extension in addition to the certificate being
fact that each signature is validated
contains only a single time, the
usefulness of this extension and the CRL being used to validate in the
certificate contains context of IKE is unclear.
Therefore, implementations MUST NOT generate certificates that
contain the IssuingDistributionPoint PrivateKeyUsagePeriod extension. Failure
to validate the CRLDistributionPoints/IssuingDistributionPoint pair
can result in CRL substitution where If an entity knowingly substitutes
a known good CRL from implementation
receives a different distribution point certificate with this set, it SHOULD ignore it.

4.1.3.4. Certificate Policies

Many IPsec implementations do not currently provide support for the CRL

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

which is supposed to be used
Certificate Policies extension. Therefore, implementations that
generate certificates which would show contain this extension SHOULD NOT mark the entity
extension 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 critical.

4.1.3.5. PolicyMappings

Many implementations do not support the InhibitAnyPolicy PolicyMappings extension.
Since PKIX mandates

4.1.3.6. SubjectAltName

Deployments that this extension be marked critical when
present, implementations which intend to be maximally interoperable
SHOULD NOT generate use an IKE_ID of either FQDN, USER_FQDN or
IP*_ADDR MUST issue certificates which contain this extension.

4.1.3.16. FreshestCRL with the corresponding SujectAltName
fields populated with the same data. Implementations MUST NOT assume that SHOULD generate
only the FreshestCRL extension will
exist following GeneralName choices in peer extensions. Note that most implementations do not
support delta CRLs.

4.1.3.17. AuthorityInfoAccess

PKIX defines the AuthorityInfoAccess subjectAltName extension, which is used to
indicate "how
as these choices map to access CA information and services

Korver [Page 21]
Internet-Draft PKI Profile 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 IKE/ISAKMP/PKIX 7/2004

legal IKEv1/ISAKMP/IKEv2 Identification Payload types: rfc822Name,
dNSName, or iPAddress. Although it is used to indicate "how possible to access information and services for
the subject of the certificate specify any
GeneralName choice in which the extension appears." This
extension has no known use in Identification Payload by using the context of IPsec. Conformant
ID_DER_ASN1_GN ID type, 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, NOT assume that a peer
supports such functionality, 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 NOT generate certificates 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
do so.

4.1.3.6.1. dNSName

This field MUST act conservatively when the
information provided by these sources is inconsistent: when contain a
certificate is reported as revoked by one trusted source, fully qualified domain name. If IKE ID type
equals FQDN then the
certificate dNSName field MUST be considered revoked.

4.2.2. X.509 Certificate Revocation List Extensions

4.2.2.1. AuthorityKeyIdentifier match its contents.
Implementations SHOULD MUST NOT assume generate names that other implementations support contain wildcards.
Implementations MAY treat certificates that contain wildcards in this
field as syntactically invalid.

Although this field is in the AuthorityKeyIdentifier extension, and thus form of an FQDN, implementations SHOULD
NOT generate
certificate hierarchies which are overly complex to process in assume that this field contains an FQDN that will resolve via the
absence
DNS, unless this is known by way of some out-of-band mechanism. Such
a mechanism is out of the scope of this extension.

4.2.2.2. IssuerAltName document. Implementations
SHOULD NOT assume that other implementations support treat the IssuerAltName extension, and especially should not assume that
information contained in this extension will be displayed failure to end
users.

4.2.2.3. CRLNumber

As stated resolve as an error.

4.1.3.6.2. iPAddress

If IKE ID type equals IP*_ADDR then the iPAddress field MUST match its
contents. Note that although PKIX permits CIDR [CIDR] notation in PKIX, all issuers conforming to the
"Name Constraints" extension, PKIX explicitly prohibits using CIDR
notation for conveying identity information. In other words, the CIDR
notation MUST include this
extension NOT be used in all CRLs.

4.2.2.4. DeltaCRLIndicator

4.2.2.4.1. the subjectAltName extension.

4.1.3.6.3. rfc822Name

If Delta CRLs Are Unsupported

Implementations that do not support delta CRLs MUST reject CRLs
which
contain IKE ID type equals USER_FQDN then the DeltaCRLIndicator (which MUST be marked critical
according to PKIX) and rfc822Name field MUST make use of a base CRL if it match
its contents. Although this field is
available. Such in the form of an Internet mail
address, implementations MUST ensure SHOULD NOT assume that this field contains a delta CRL does not
"overwrite"
valid email address, unless this is known by way of some out-of-band
mechanism. Such a base CRL, for instance in mechanism is out of the keying material database.

4.2.2.4.2. Delta CRL Recommendations

Since some implementations scope of this document.

4.1.3.7. IssuerAltName

Implementations SHOULD NOT assume that do not other implementations support delta CRLs may behave
incorrectly or insecurely
the IssuerAltName extension, and especially should not assume that
information contained in this extension will be displayed to end
users.

4.1.3.8. 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 presented with delta CRLs,
implementations SHOULD consider whether issuing delta CRLs
increases it is marked non-critical, as PKIX mandates.

Korver [Page 25] 22]
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 7/2004

4.1.3.9. BasicConstraints

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 mandates that CA. To associate a CRL with a certificate, the CA
places the CRLDistributionPoints certificates contain this extension in the certificate, and
places the IssuingDistributionPoint in the CRL. The
distributionPointName field in 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 CRLDistributionPoints extension default for this setting MUST be identical to reject such
certificates.

4.1.3.10. NameConstraints

Many implementations do not support the distributionPoint field in the
IssuingDistributionPoint NameConstraints extension. At least one CA is known to
default to
Since PKIX mandates that this type of CRL use. See section 4.1.3.14 for more
information.

4.2.2.6. FreshestCRL

Given the recommendations against extension be marked critical when
present, implementations generating delta
CRLs, which intend to be maximally interoperable
SHOULD NOT generate certificates which contain this specification RECOMMENDS that extension.

4.1.3.11. PolicyConstraints

Many implementations do not
populate CRLs with support the FreshestCRL extension, which is used PolicyConstraints extension.
Since PKIX mandates that this extension be marked critical when
present, implementations which intend 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 be maximally interoperable
SHOULD NOT generate certificates which contain this extension.

4.1.3.12. ExtendedKeyUsage

ExtendedKeyUsage is not defined in the beginning and end context of IKE/IPsec.
Implementations SHOULD accept certificates with any line, set of
ExtendedKeyUsage usages asserted. Implementations MUST support
arbitrary line lengths although they SHOULD NOT generate lines less than
76 characters, and MUST support
this extension in certificates which are being used for IPsec.

Note that a previous proposal for the following use of three line-termination
disciplines: LF (US-ASCII 10), CR (US-ASCII 13), ExtendedKeyUsage
values is obsolete and CRLF.

5.1. Certificates

Certificates MUST be Base64 encoded explicitly deprecated by this specification.
For historical reference, those values were id-kp-ipsecEndSystem,
id-kp-ipsecTunnel, and appear between id-kp-ipsecUser.

4.1.3.13. CRLDistributionPoints

Because this document deprecates the following
delimiters:

-----BEGIN CERTIFICATE----- sending of CRLs in band, the use
of CRLDistributionPoints (CDP) becomes very important if CRLs are used
for revocation checking (as opposed to say OCSP). The ipsec peer
either needs to have a URL for a CRL written into its local
configuration, or it needs to learn it from CDP. Therefore,
implementations SHOULD issue certificates with a populated CDP.

Failure to validate the CRLDistributionPoints/IssuingDistributionPoint
pair can result in CRL substitution where an entity knowingly
substitutes a known good CRL from a different distribution point for
the CRL

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

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

5.2. Public Keys 7/2004

which is supposed to be used which would show the entity as revoked.

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 validating that the SubjectPublicKeyInfo
portion contents of
CRLDistributionPoints match those of the certificate, and MUST be Base64 encoded and appear
between IssuingDistributionPoint to
prevent CRL substitution when 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 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.

CDPs SHOULD be Base64
encoded "resolvable". For example some very prominent
implementations are well known for including CDPs like
http://localhost/path_to_CRL and appear between http:///path_to_CRL which are as bad
as not including the following delimeters:

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

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

6. Security Considerations

6.1. Identification Payload

Depending on CDP.

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

4.1.3.14. InhibitAnyPolicy

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

4.1.3.15. FreshestCRL

Implementations MUST NOT assume that the clear.
Administrators FreshestCRL extension will
exist in some environments may wish to use peer extensions. Note that most implementations do not
support delta CRLs.

4.1.3.16. AuthorityInfoAccess

PKIX defines the empty
Certification Authority option AuthorityInfoAccess extension, which is used to prevent such
indicate "how to access CA information from
leaking, at and services for the possible cost issuer of some performance, although such
the certificate in which the extension appears." Because this document
deprecates the sending of CRLs in band, the use of AuthorityInfoAccess
(AIA) becomes very important if OCSP is discouraged.

6.2. Certificate Request Payload to be used for revocation
checking (as opposed to CRLs). The Contents of CERTREQ are not encrypted in IKE. In some
environments ipsec peer either needs to have a
URI for the OCSP query written into its local configuration, or it
needs to learn it from AIA. Therefore, implementations SHOULD support
this may leak extension, especially if OCSP will be used.

4.1.3.17. SubjectInfoAccess

PKIX defines the SubjectInfoAccess private information. Administrators in
some environments may wish certificate extension,
which is used to use the empty Certification Authority
option indicate "how to prevent such access information from leaking, at and services for
the cost subject of
performance.

6.3. Certificate Payload

Depending on the exchange type, CERTs may be passed certificate in which the clear 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
therefore may leak identity information. 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 27] 24]
Internet-Draft PKI Profile for IKE/ISAKMP/PKIX
5/2004

6.4. IKEv1 Main Mode

Implementations may not wish 7/2004

information. Deployment that intend to respond with CERTs in the second
message, thereby violating use CRLs for revocation MUST
populate the identity protection feature of Main
Mode in IKEv1. CERTs may be included in any message, and therefore
implementations may wish to respond CRLDistributionPoint field. Therefore Implementation MUST
support issuing certificates 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 field populated according to manage.

9. Normative References

[DOI] Piper, D., "The Internet IP Security Domain
administrator's needs. Implementations MAY provide a configuration
option to disable use 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 certain types of revocation information, but
that option MUST be off by default. Such an option is often valuable
in progress.

[IPSEC] Kent, S. and Atkinson, R., "Security Architecture for lab testing environments.

4.2.1. Multiple Sources of Certificate Revocation Information

Implementations which support multiple sources of obtaining
certificate revocation information MUST act conservatively when 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
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 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

4.2.2.1. AuthorityKeyIdentifier

Implementations SHOULD NOT assume that other implementations support
the AuthorityKeyIdentifier extension, and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-00.txt.

11. Acknowledgements

The authors would like thus SHOULD NOT generate
certificate hierarchies which are overly complex to acknowledge process in the expired draft-ietf-ipsec-
pki-req-05.txt for providing valuable materials for
absence of this document.
The authors would like to extension.

4.2.2.2. IssuerAltName

Implementations SHOULD NOT assume that other implementations support
the IssuerAltName extension, and especially thank Greg Carter, Russ Housley,
Steve Hanna, 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 Gregory Lebovitz 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 their valuable comments, instance in the keying material database.

4.2.2.4.2. Delta CRL Recommendations

Since some
of which have been incorporated unchanged into this document.

12. Author's Addresses

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

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

This document [Page 25]
Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 7/2004

And, if all the elements in the VPN and translations PKI systems do not adequately
support Delta CRLs, then their use should be questioned.

The authors are aware of it 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 NOT 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 be copied 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 furnished
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 7/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 7/2004

6.4. IKEv1 Main Mode

Certificates may be included in any message, and therefore
implementations may wish to respond with CERTs in a message that
offers privacy protection, in Main Mode messages 5 and 6.
Implementations may not wish to respond with CERTs in the second
message, thereby violating the identity protection feature of Main
Mode in IKEv1.

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 7/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,
especially Eric Rescorla, one of its original authors.
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

Full Copyright Statement

Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.

Acknowledgement

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

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

Appendix A. Change History

* July 2004 (-01) (Edited by Gregory Lebovitz)

Changed ISAKMP references in Abstract and Intro to IKE.

Editorial changes to make the text conform with the summary table in
3.1, especially in the text following the table in 3.1. Particular
note should be paid to changes in section 3.5.1.

Sect 3.1.1 - editorial changes to aid in clarification. Added text on
when deployers might consider using IP addr, but strongly encouraged
not to.

Sect 3.1.8 - removed IP address from list of practically used ID types.

3.1.9 overhauled (per Kivinen, July 18)

3.2 - added IKEv2's Hash and URL of x.509 to list of those profiled
and gave it its own section, now 3.2.5
- added note in CRL/ARL section about revocation occurring OOB of
IKE
- deleted ARL as its own section and collapsed it into Revocation
Lists (CRL and ARL) for consciseness. Renumbered accordingly.

Sect 3.2.7.2 - Changed from MUST not send empty certreqs to SHOULD
send CERTREQs which contain CA fields with direction on how, but MAY
send empty CERTREQs in certain case. Use case added, and specifics of
both initiator and responder behavior listed.

APPENDIX C added to fill out the explanation (mostly discussion from
list).

3.3 - clarified that sending CRLs and chaining certs is deprecated.
-
added IKEv2's Hash and URL of x.509 to list of those profiled and gave
it its own section. Condensed ARL into CRL and renumbered accordingly.
- duplicate section was removed, renumbered accordingly

3.3.10.2 - title changed. sending chaining becomes SHOULD NOT.

4.1.2 added text to explicity call out support for CN, C, O, OU

collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly.

Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly

Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to
Hoffman, July18

4.1.3.3 if receive cert w/ PKUP, ignore it.

4.1.3.13 - CDP changed text to represent SHOULD issue, and how
important CDP becomes when we do not send CRLs in-band. Added SHOULD
for CDPs actually being resolvable (reilly email).

Reordered 6.4 for better clarity.

Added Rescorla to Acknowledgements section, as he is no longer listed
as an editor, since -00.

* 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 7/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
others, ID_RFC822_ADDR, and derivative works that comment on or otherwise explain it
or assist in its implementation may
ID_USER_FQDN would be prepared, copied, published
and distributed, in whole or used exclusively in part, without restriction of any
kind, provided this document.

IKEv2: Declared that the above copyright notice 3 new CERTREQ and this paragraph CERT types are
included on all such copies and derivative works. However, not profiled
in this document itself may (well, at least not be modified yet, pending WG discussion of
what to do -- note that they are only SHOULDs in any way, such as by removing
the copyright notice or references IKEv2).

IKEv2: Noted that CERTREQ payload changed from DN to the Internet Society or other
Internet organizations, except as needed for the purpose SHA-1 of
developing Internet standards in which case
SubjectPublicKeyInfo.

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

Korver [Page 29] 31]
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 7/2004

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

Made it clearer that (-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 format CRL, Intermediat Certs, Trust Anchors,
etc OOB of the ID_IPV4_ADDR payload comes
from RFC791 IKE; MUST be able to send and receive EE cert payload;
only real exception is nothing new. (Tero Kivinen Feb 29)

Permit implementations Intermediate Cets which MAY be sent and
SHOULD be able to skip verifying that be receivable (but in reality there are very few
hierarchies in operation, so really it's a corner case); SHOULD
NOT send the peer source
address matches other stuff (CRL, Trust Anchors, etc) in cert
payloads in IKE; SHOULD be able to accept the contents 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 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) ISAKMP" Background section to each
payload section (removing duplication of these sections)

Removed some text implying RSA encryption mode "Certificate-Related Playloads in ISAKMP" section since it
was not specific to IKE.

Incorporated Gregory Lebovitz's table in scope. (Tero
Kivinen Feb 29)

Relaxed deprecation 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 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 populating the dNSName
from SHOULD NOT to use when generating CERTREQ, MUST NOT and removed the text regarding
domainComponent

Revocation information checking MAY now be disabled, although not when
receiving CERTREQ. (Tero Kivinen Feb 29)
by default

Korver [Page 30] 32]
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 7/2004

Aggressive Mode removed from this document,
implementations MUST conform profile

* June 2003 (-03)

Minor editorial changes to the requirements 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 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 "root" to be
regularized "trust anchor", in
accordance with Gregory Lebovitz's CERT proposal from -04. (Tylor
Allison, May 15)

Added PKIX

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

Clarification of text specifying how receipients SHOULD NOT be expected regarding placing names of hosts into the
Name commonName attribute of SubjectName

Added table to
iterate over multiple end-entity certs. (Tylor Allison, May 15)

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

IKEv2: Explained 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 IDr sent by responder doesn't have 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 match check the [IDr] sent initiator in second exchange.

IKEv2: Noted certificate against all
possible CRLs: if the first CRL that "The identity ... does not necessarily have is obtained from the keying
material database fails to
match anything in decode, no further revocation checks are
performed for the CERT payload" (S3.5) relevant certificate. This problem is not contradicted compounded by
SHOULD in this document.

IKEv2: Noted

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

the fact that ID_USER_FQDN renamed implementations which do not understand delta CRLs may
fail to ID_RFC822_ADDR, and
ID_USER_FQDN would be used exclusively in this document.

IKEv2: Declared decode such CRLs due to the critical DeltaCRLIndicator
extension. The algorithm that 3 new CERTREQ and CERT types are not profiled is implemented in this document (well, at least not yet, pending WG discussion case is
approximately:

fetch newest CRL
check validity of
what 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 do -- revoked

The authors note that they are only SHOULDs in IKEv2).

IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 a number 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 toolkits do not even provide a
method for CERT payloads:
"should deal with all obtaining anything but the newest 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 the
presence of delta CRLs may in operation, so really it's fact be a corner case); SHOULD
NOT send delta CRL, not a base CRL.

Note that the other stuff (CRL, Trust Anchors, etc) in cert
payloads above algorithm is dangerous in IKE; SHOULD be able to accept many ways. See PKIX
for the other stuff if by
chance it gets sent, though we hope they don't get sent"

Incorporated comments contained correct algorithm.

Appendix C - More on Empty CERTREQs

Sending empty certificate requests is commonly used 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
implementations, and in ISAKMP" section since the IPsec interop meetings, vendors have
generally agreed that it
was means that send all/any certificates you
have (if multiple certificates are sent, they must have same public
key, as otherwise the other end does not specific to IKE.

Incorporated Gregory Lebovitz's table in know which key was used).
For 99% of cases 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 client have exactly one certificate and ID_FQDN promoted to MUST from MAY

Promoted sending ID_DER_ASN1_DN public
key, so it really doesn't matter, but the server might have multiple,
thus it simply needs to MAY from SHOULD NOT, and
receiving from MUST from MAY

Demoted ID_DER_ASN1_GN say to MUST NOT

Demoted populating Subject Name in place the client, use any certificate you
have. If we are talking about corporate vpns etc, even if the client
have multiple certificates or keys, all of populating them would be usable when
authenticating to the dNSName
from SHOULD NOT server, so client can simply pick one.

If there is some real difference on which cert to MUST NOT and removed use (like ones
giving different permissions), then the text regarding
domainComponent

Revocation information checking MAY now client MUST 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 configured
anyways, or it might even ask the user which one 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" (the user is
the only one who knows whether he needs admin privileges, thus needs
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 use admin cert, or is the normal email privileges ok, thus using
email only cert).

99% of hosts into the
Name commonName attribute cases the client have exactly one certificate, so it will
send it. In 90% of SubjectName

Added table to clarify text regarding processing the rest 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 cases, any of Delta CRLs

The problem is that the CRL processing algorithm certificates is sometimes written
incorrectly with
ok, as they are simply different certificates from same CA, or
different CAs for the assumption that same corporate VPN, thus any of them is ok.

Sending empty certificate requests has been agreed
there to mean "give me a cert; any cert".

Justification:
- Responder first does all CRLs are base CRLs and it can to send a certreq with a CA,
check for IP match in SPD, have a default set of CAs to use in
ambiguous cases, etc.
- sending empty certreq's is
assumed that CRLs will pass content validity tests. Specifically,
such fairly common in implementations fail today,
and is generally accepted to check mean "send me a cert, any cert that works
for you"
- saves responder sending potentially 100's of certs, the certificate against all
possible CRLs:
fragmentation problems that follow, etc.
- in +90% of use cases, Initiators have exactly 1 cert
- in +90% of the remaining use cases, the multiple certs it has are
issued by the same CA
- in the remaining use case(s) -- if not all the first CRL that is obtained from others above --
the keying
material database fails Initiator will be configured explicitly with which cert to decode, no further revocation checks are
performed send,
so responding to an empty certreq is easy.

The following example shows why initiators need to have sufficient
policy definition to know which certificate to use for a given
connecting it initiates.

EXAMPLE: Your client (initiator) is configured with VPN policies for
gateways A and B (representing perhaps corporate partners). The
policies for the relevant certificate. This problem is compounded by

Korver [Page 33]
Internet-Draft PKI Profile for IKE/ISAKMP/PKIX
5/2004 two gateways look something like:

Acme Company policy (gateway A)
Engineering can access 10.1.1.0
Trusted CA: CA-A, Trusted Users: OU=Engineering
Partners can access 20.1.1.0
Trusted CA: CA-B, Trusted Users: OU=AcmePartners

Bizco Company policy (gateway B)
sales can access 30.1.1.0
Trusted CA: CA-C, Trusted Users: OU=Sales
Partners can access 40.1.1.0
Trusted CA: CA-B, Trusted Users: OU=BizcoPartners

You are an employee of Acme and you are issued the fact that implementations following
certificates:
From CA-A: CN=JoeUser,OU=Engineering
From CA-B: CN=JoePartner,OU=BizcoPartners

The client MUST be configured locally to know which do CA to use when
connecting to either gateway. If your client is not understand delta CRLs may
fail configured to decode such CRLs due know
the local credential to use for the critical DeltaCRLIndicator
extension. The algorithm that is implemented in remote gateway, this case is
approximately:

fetch newest CRL
check validity of CRL signature
if CRL signature is valid then
if CRL does scenario will
not contain unrecognized critical extensions
and certificate is on CRL then
set certificate status work either. If you attempt to revoked

The authors note that connect to Bizco, everything will
work... as you are presented with responding with a number of PKI toolkits do not even provide certificate signed
by CA-B or CA-C... as you only have a
method for obtaining anything but the newest CRL, which in certificated from CA-B you are
OK. If you attempt to connect to Acme, you have an issue because you
are presented with an ambiguous policy selection. As the
presence initiator,
you will be presented with certificate requests from both CA A and CA
B. You have certificates issued by both CAs, but only one of delta CRLs may in fact the
certificates will be a delta CRL, not a base CRL.

Note that usable. How does the above algorithm client know which
certificate it should present It must have sufficiently clear local
policy specifying which one credential to present for the connection
it initiates.

Copyright (C) The Internet Society (2004). This document is dangerous subject
to the rights, licenses and restrictions contained in many ways. See PKIX
for BCP 78 and
except as set forth therein, the correct algorithm. authors retain all their rights.

Korver [Page 34]

----