Brian Korver
Xythos Software
Eric Rescorla
INTERNET-DRAFT RTFM, Inc.
<draft-ietf-ipsec-pki-profile-02.txt> Feb 2003 (Expires Aug 2003)
The Internet IP Security PKI Profile of ISAKMP and PKIX
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
ISAKMP and PKIX both provide frameworks that must be profiled for use
in a given application. This document provides a profile of ISAKMP
and PKIX that defines the requirements for using PKI technology in
the context of IPsec. The document compliments protocol specifica-
tions such as IKE, which assume the existence of public key certifi-
cates and related keying materials, but which do not address PKI
issues explicitly. This document addresses those issues.
Table of Contents
1 Introduction 4
2 Terms and Definitions 5
3 Profile of ISAKMP 6
3.1 Background 6
3.1.1 Certificate-Related Payloads in ISAKMP 6
3.1.1.1 Identification Payload 6
3.1.1.2 Certificate Payload 6
Korver, Rescorla [Page 1]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.1.1.3 Certificate Request Payload 6
3.1.1.4 Hash Payload 6
3.1.2 Endpoint Identification 7
3.1.2.1 Identification Payload Only 7
3.1.2.2 Certificate Payload Only 7
3.2 Identification Payload 7
3.2.1 ID_IPV4_ADDR and ID_IPV6_ADDR 7
3.2.2 ID_FQDN 8
3.2.3 ID_USER_FQDN 8
3.2.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_R... 8
3.2.5 ID_DER_ASN1_DN 8
3.2.6 ID_DER_ASN1_GN 9
3.2.7 ID_KEY_ID 9
3.2.8 Using Peer Source IP Address to Bind Identity to Policy 9
3.2.9 Securely Binding Identity to Policy 10
3.2.9.1 Single Address Identification Data 10
3.2.9.2 Identification Data other than a Single Address 10
3.2.10 Selecting an Identity from a Certificate 11
3.2.11 Transitively Binding Identity to Policy 11
3.3 Certificate Request Payload 11
3.3.1 Certificate Type 11
3.3.2 X.509 Certificate - Signature 12
3.3.3 X.509 Certificate - Key Exchange 12
3.3.4 Certificate Revocation List (CRL) 12
3.3.5 Authority Revocation List (ARL) 12
3.3.6 PKCS #7 wrapped X.509 certificate 12
3.3.7 Presence or Absence of Certificate Request Payloads 13
3.3.8 Certificate Requests 13
3.3.8.1 Specifying Certificate Authorities 13
3.3.8.2 Empty Certificate Authority Field 13
3.3.9 CRL Requests 14
3.3.9.1 Specifying Certificate Authorities 14
3.3.9.2 Empty Certificate Authority Field 14
3.3.10 Robustness 14
3.3.10.1 Unrecognized or Unsupported Certificate Types 14
3.3.10.2 Undecodable Certificate Authority Fields 14
3.3.10.3 Ordering of Certificate Request Payloads 15
3.3.11 Optimizations 15
3.3.11.1 Duplicate Certificate Request Payloads 15
3.3.11.2 Name Lowest 'Common' Certification Authorities 15
3.3.11.3 Example 15
3.4 Certificate Payload 16
3.4.1 Certificate Type 16
3.4.2 X.509 Certificate - Signature 16
3.4.3 X.509 Certificate - Key Exchange 16
3.4.4 Certificate Revocation List (CRL) 17
3.4.5 Authority Revocation List (ARL) 17
3.4.6 PKCS #7 wrapped X.509 certificate 17
Korver, Rescorla [Page 2]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.4.7 Certificate Payloads Not Mandatory 17
3.4.8 Response to Multiple Certificate Authority Proposals 17
3.4.9 Using Local Keying Materials 18
3.4.10 Robustness 18
3.4.10.1 Unrecognized or Unsupported Certificate Types 18
3.4.10.2 Undecodable Certificate Data Fields 18
3.4.10.3 Ordering of Certificate Payloads 18
3.4.10.4 Duplicate Certificate Payloads 18
3.4.10.5 Irrelevant Certificates 18
3.4.11 Optimizations 19
3.4.11.1 Duplicate Certificate Payloads 19
3.4.11.2 Send Lowest 'Common' Certificates 19
3.4.11.3 Drop Duplicate Certificate Payloads 19
4 Profile of PKIX 19
4.1 X.509 Certificates 19
4.1.1 Versions 19
4.1.2 Subject Name 19
4.1.2.1 Empty Subject Name 19
4.1.2.2 Specifying Non-FQDN Hosts in Subject Name 20
4.1.2.3 Specifying FQDN Host Names in Subject Name 20
4.1.2.4 EmailAddress 20
4.1.3 X.509 Certificate Extensions 20
4.1.3.1 AuthorityKeyIdentifier 21
4.1.3.2 SubjectKeyIdentifier 21
4.1.3.3 KeyUsage 21
4.1.3.4 PrivateKeyUsagePeriod 22
4.1.3.5 Certificate Policies 22
4.1.3.6 PolicyMappings 22
4.1.3.7 SubjectAltName 22
4.1.3.7.1 dNSName 22
4.1.3.7.2 iPAddress 23
4.1.3.7.3 rfc822Name 23
4.1.3.8 IssuerAltName 23
4.1.3.9 SubjectDirectoryAttributes 23
4.1.3.10 BasicConstraints 23
4.1.3.11 NameConstraints 23
4.1.3.12 PolicyConstraints 23
4.1.3.13 ExtendedKeyUsage 24
4.1.3.14 CRLDistributionPoint 24
4.1.3.15 InhibitAnyPolicy 24
4.1.3.16 FreshestCRL 25
4.1.3.17 AuthorityInfoAccess 25
4.1.3.18 SubjectInfoAccess 25
4.2 X.509 Certificate Revocation Lists 25
4.2.1 Certificate Revocation Requirement 25
4.2.2 Multiple Sources of Certificate Revocation Information 25
4.2.3 X.509 Certificate Revocation List Extensions 26
4.2.3.1 AuthorityKeyIdentifier 26
Korver, Rescorla [Page 3]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
4.2.3.2 IssuerAltName 26
4.2.3.3 CRLNumber 26
4.2.3.4 DeltaCRLIndicator 26
4.2.3.4.1 If Delta CRLs Are Unsupported 26
4.2.3.4.2 Delta CRL Recommendations 26
4.2.3.5 IssuingDistributionPoint 27
4.2.3.6 FreshestCRL 27
5 Configuration Data Exchange Conventions 27
5.1 Certificates 27
5.2 Public Keys 27
5.3 PKCS#10 Certificate Signing Requests 28
6 IKE 28
6.1 IKE Phase 1 Authenticated With Signatures 28
6.1.1 Identification Payload 28
6.1.2 X.509 Certificate Extensions 28
6.1.2.1 KeyUsage 28
6.1.3 Obtaining Peer Certificates and CRLs 28
6.2 IKE Phase 1 Authenticated With Public Key Encryption 29
6.2.1 Identification Payload 29
6.2.2 Hash Payload 29
6.2.3 X.509 Certificate Extensions 29
6.2.3.1 KeyUsage 29
6.2.4 Obtaining Peer Certificates and CRLs 29
6.3 IKE Phase 1 Authenticated With a Revised Mode of Public K... 29
7 Security Considerations 29
7.1 Identity Payload 30
7.2 Certificate Request Payload 30
7.3 Certificate Payload 30
7.4 IKE Main Mode 30
7.5 IKE Aggressive Mode 30
8 Intellectual Property Rights 30
9 IANA Considerations 31
10 Normative References 31
11 Informational References 31
12 Acknowledgements 32
13 Author's Addresses 32
1. Introduction
IKE [IKE] and ISAKMP [ISAKMP] provide a secure key exchange mechanism
for use with IPsec [IPSEC]. In many cases the peers authenticate
using digital certificates as specified in PKIX [PKIX]. Unfortu-
nately, 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 con-
tents of various messages without specifying their syntax or
Korver, Rescorla [Page 4]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
semantics. Meanwhile, PKIX provides a large set of certificate mecha-
nisms which are generally applicable for Internet protocols, but lit-
tle specific guidance for IPsec. Given the numerous underspecified
choices, interoperability is hampered if all implementors do not make
similar choices, or at least fail to account for implementations
which have chosen differently.
This profile of the ISAKMP and PKIX frameworks is intended to provide
an agreed upon standard for using PKI technology in the context of
IPsec by profiling the PKIX framework for use with ISAKMP and IPsec,
and by documenting the contents of the relevant ISAKMP payloads and
further specifying their semantics.
In addition to providing a profile of ISAKMP and PKIX, this document
attempts to incorporate lessons learned from recent experience with
both implementation and deployment, as well as the current state of
related protocols and technologies.
Material from ISAKMP and PKIX is not repeated here, and readers of
this document are assumed to have read and understood both documents.
The requirements and security aspects of those documents are fully
relevant to this document as well.
This document is organized as follows. Section 2 defines special ter-
minology used in threst of this document, Section 3 provides the pro-
file of ISAKMP and Section 4 provides the profile of PKIX. Section 5
covers conventions for the out-of-band exchange of keying materials
for configuration purposes. Section 6 covers aspects of ISAKMP and
PKIX which are unique to IKE.
Versions "00" through "02" of this document are intended as a "straw
man" to encourage comments from implementors of IPsec and to encour-
age discussion of the issues which the authors hope to address this
document.
This document is being discussed on the ipsec@lists.tislabs.com mail-
ing list, which is the mailing list for the IPsec Working Group.
2. Terms and Definitions
Except for those terms which are defined immediately below, all PKI
terms used in this document are defined in either the PKIX, ISAKMP,
or DOI [DOI] documents.
* Peer source address: The source address in packets from a peer.
This address may be different from any addresses asserted as the
"identity" of the peer.
* FQDN: Fully qualified domain name.
Korver, Rescorla [Page 5]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
3. Profile of ISAKMP
3.1. Background
3.1.1. Certificate-Related Payloads in ISAKMP
ISAKMP has three primary certificate-related payloads: Identifica-
tion, Certificate, and Certificate Request. Additionally, IKE speci-
fies the optional use of the Hash Payload to carry a pointer to a
certificate in either of the Phase 1 public key encryption modes. In
this section we provide a short introduction to these payload types.
3.1.1.1. Identification Payload
The Identification (ID) Payload is used to indicate the identity that
the agent claims to be speaking for. The receiving agent can then use
the ID as a lookup key for policy and whatever certificate store or
directory that it has available. Our primary concern in this document
is to profile the ID payload so that it can be safely used to gener-
ate or lookup policy.
3.1.1.2. Certificate Payload
The Certificate (CERT) Payload allows the peer to transmit a single
certificate or CRL. Multiple certificates are transmitted in multiple
payloads. However, not all certificate forms that are legal in PKIX
make sense in the context of ISAKMP or IPsec. The issue of how to
represent ISAKMP-meaningful name-forms in a certificate is especially
problematic. This memo provides a profile for a subset of PKIX that
makes sense for ISAKMP.
3.1.1.3. Certificate Request Payload
The Certificate Request (CERTREQ) Payload allows an ISAKMP implemen-
tation to request that a peer provide some set of certificates or
certificate revocation lists. It is not clear from ISAKMP exactly how
that set should be specified or how the peer should respond. We
describe the semantics on both sides.
3.1.1.4. Hash Payload
The Hash (HASH) Payload is a generic mechanism for ISAKMP implementa-
tions to communicate hash values to a peer. The meaning of the con-
tents of such payloads is left undefined by ISAKMP.
Korver, Rescorla [Page 6]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.1.2. Endpoint Identification
ISAKMP contains two different payloads that allow the specification
of endpoint identity, the ID payload and the CERT payload. According
to ISAKMP, these payloads can be used separately or together,
although specific profiles of ISAKMP may place additional require-
ments on implementations.
3.1.2.1. Identification Payload Only
If one peer presents only the ID payload, it is expected that the
peer will be able to recover whatever keying material is required to
verify the peer's identity. How to do so is out of the scope of this
document but might include a local cache, an LDAP directory, or DNS.
3.1.2.2. Certificate Payload Only
If a peer presents only a CERT payload, this creates an ambiguity,
since ISAKMP does not specify which of potentially many certificates
corresponds to the end-entity and which are chaining certificates.
Implementations SHOULD compare whatever local hints they have about
peer identity to each certificate until they find one that appears
acceptable.
3.2. Identification Payload
The ID payload requirements in this document cover only the portion
of the explicit policy checks that deal with the Identity Payload
specifically. For instance, in the case where ID does not contain an
IP address, checks such as verifying that the peer source address is
permitted by the relevant policy are not addressed here as they are
out of the scope of this document.
The [DOI] defines the 11 types of Identification Data that can be
used and specifies the syntax for these types. All of these are dis-
cussed immediately below.
3.2.1. ID_IPV4_ADDR and ID_IPV6_ADDR
Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR
ID type. These addresses MUST be stored in "network byte order," as
specified in [RFC791]. The least significant bit (LSB) of each octet
is the LSB of the corresponding byte in the network address. For the
ID_IPV4_ADDR type, the payload MUST contain exactly four octets
[RFC791]. For the ID_IPV6_ADDR type, the payload MUST contain exactly
sixteen octets [RFC1883]. When comparing the contents of ID with the
iPAddress field in the subjectAltName extension for equality, binary
comparison MUST be performed.
Korver, Rescorla [Page 7]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.2.2. ID_FQDN
Implementations MAY support the ID_FQDN ID type, generally to support
host-based access control lists for hosts without fixed IP addresses.
However, implementations SHOULD NOT use the DNS to map the FQDN to IP
addresses for input into any policy decisions, unless that mapping is
known to be secure, such as when [DNSSEC] is employed. When comparing
the contents of ID with the dNSName field in the subjectAltName
extension for equality, caseless string comparison MUST be performed.
Substring, wildcard, or regular expression matching MUST NOT be per-
formed.
3.2.3. ID_USER_FQDN
Implementations MAY support the ID_USER_FQDN ID type, generally to
support user-based access control lists for users without fixed IP
addresses. However, implementations SHOULD NOT use the DNS to map the
FQDN portion to IP addresses for input into any policy decisions,
unless that mapping is known to be secure, such as when [DNSSEC] is
employed. When comparing the contents of ID with the rfc822Name field
in the subjectAltName extension for equality, caseless string compar-
ison MUST be performed. Substring, wildcard, or regular expression
matching MUST NOT be performed.
3.2.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE,
ID_IPV6_ADDR_RANGE
As there is currently no standard method for putting address subnet
or range identity information into certificates, the use of these ID
types is currently undefined.
Note that work in [SBGP] for defining blocks of addresses using
the certificate extension identified by
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
is experimental at this time.
3.2.5. ID_DER_ASN1_DN
Implementations MAY support receiving the ID_DER_ASN1_DN ID type,
although implementations SHOULD NOT generate this type. Implementa-
tions which generate this type SHOULD populate the contents of ID
with the Subject Name from the end entity certificate, and MUST do so
such that a binary comparison of the two will succeed. For instance,
if the certificate was erroneously created such that the encoding of
the Subject Name DN varies from the constraints set by DER, that non-
conformant DN that MUST be used to populate the ID payload:
Korver, Rescorla [Page 8]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
implementations MUST NOT re-encode the DN for the purposes of making
it DER if it does not appear in the certificate as DER. Implementa-
tions MUST NOT populate ID with the Subject Name from the end entity
certificate if it is empty, as described in the "Subject" section of
PKIX.
3.2.6. ID_DER_ASN1_GN
Implementations MAY support the ID_DER_ASN1_GN ID type, although
implementations SHOULD NOT generate this type unless it is known
through out-of-band means that the peer is capable of understanding
this type. Implementations which generate this type MUST populate the
contents of ID with the a GeneralName from the SubjectAltName exten-
sion in the end entity certificate, and MUST do so such that a binary
comparison of the two will succeed. For instance, if the certificate
was erroneously created such that the encoding of the GeneralName
varies from the constraints set by DER, that non-conformant General-
Name MUST be used to populate the ID payload: implementations MUST
NOT re-encode the GeneralName for the purposes of making it DER if it
does not appear in the certificate as DER.
3.2.7. ID_KEY_ID
Type ID_KEY_ID type used to specify pre-shared keys and thus is not
relevant to this document.
3.2.8. Using Peer Source IP Address to Bind Identity to Policy
Because implementations sometimes use ID as a lookup key to determine
which policy to use, all implementations MUST be especially careful
to verify the truthfulness of the contents by verifying that they
correspond to some keying material demonstrably held by the peer.
Failure to do so may result in the use of an inappropriate or inse-
cure policy. The following sections describe the methods for perform-
ing this binding.
Implementations MAY use the IP address found in the header of packets
received from the peer to lookup the policy, but such implementations
MUST still perform verification of the ID payload. Although packet IP
addresses are inherently untrustworthy and must therefore be indepen-
dently 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 speci-
fies a particular CA that is trusted to issue certificates which con-
tain a valid rfc822Name which can be used by that implementation to
Korver, Rescorla [Page 9]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
perform authorization based on access control lists (ACLs). 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, the general policy and the identity-based
policy may be identical, but until the identity is validated, the
policy MUST not be used to authorize any IPsec traffic.
As a general comment, however, it may be easier to spoof the contents
of an ID payload than it is to spoof a peer source address because
the peer source address must exist on the route to the peer, while ID
can contain essentially random identification information. Implemen-
tations MUST validate the Identity Data provided by a peer, but
implementations MAY favor unauthenticated peer source addresses over
an unauthenticated ID for initial policy lookup.
3.2.9. Securely Binding Identity to Policy
3.2.9.1. Single Address Identification Data
In the case where ID contains ID_IPV4_ADDR or ID_IPV6_ADDR (that is,
is not an address range or subnet), implementations MUST verify that
this address is the same as the peer source address. If the end
entity certificate contains addresses identities, then the peer
source address must match at least one of those identities. If either
of the above do not match, this MUST be treated as an error and secu-
rity association setup MUST be aborted. This event SHOULD be
auditable. The definition of "match" is specific to each ID type and
was discussed above. In addition, implementations MUST allow adminis-
trators to configure a local policy that requires that the peer
source address exist in the certificate. Implementations SHOULD allow
administrators to configure a local policy that does not enforce this
requirement.
3.2.9.2. Identification Data other than a Single Address
In the case where ID contains an identity type other than a single
address, implementations MUST verify that the identity contained in
the ID payload matches identity information contained in the peer end
entity certificate, either in the Subject Name field or subjectAlt-
Name extension. If there is not a match, this MUST be treated as an
error and security association setup MUST be aborted. This event
SHOULD be auditable. The definition of "match" is specific to each ID
type and was discussed above.
Korver, Rescorla [Page 10]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.2.10. Selecting an Identity from a Certificate
Implementations MUST support certificates that contain more than a
single identity. In many cases a certificate will contain an identity
such as an IP address in the subjectAltName extension in addition to
a non-empty Subject Name.
Which identity an implementations chooses to populate ID with is a
local matter. For compatibility with non-conformant implementations,
implementations SHOULD populate ID with whichever identity is likely
to be named in the peer's policy. In practice, this generally means
IP address, FQDN, or USER-FQDN.
3.2.11. Transitively Binding Identity to Policy
In the presence of certificates that contain multiple identities,
implementations SHOULD NOT assume that a peer will choose the most
appropriate identity with which to populate ID. Therefore, implemen-
tations SHOULD select the most appropriate identity to use from the
identities contained in the certificate when determining the appro-
priate policy.
For example, imagine that a peer is configured with a certificate
that contains both a non-empty Subject Name and an FQDN. Independent
of which identity is used to populate ID, the host implementation
MUST locate the proper policy. For instance, if ID contains the peer
Subject Name, then the peer end entity certificate may be found using
the Subject Name as a key. Once the certificate has been located and
then validated, the FQDN in the certificate can be used to locate the
appropriate policy.
3.3. Certificate Request Payload
3.3.1. Certificate Type
The Certificate Type field identifies to the peer the type of
certificate keying materials that are desired. ISAKMP defines 10
types of Certificate Data that can be requested and specifies the
syntax for these types. For the purposes of this document, only the
following types are relevant:
* X.509 Certificate - Signature
* X.509 Certificate - Key Exchange
* Certificate Revocation List (CRL)
* Authority Revocation List (ARL)
* PKCS #7 wrapped X.509 certificate
Korver, Rescorla [Page 11]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
For example, if CRLs are desired, an implementation will populate the
Certificate Type field with the value associated with "Certificate
Revocation List (CRL)".
The use of the other types:
* PGP Certificate
* DNS Signed Key
* Kerberos Tokens
* SPKI Certificate
* X.509 Certificate - Attribute
are out of the scope of this document.
3.3.2. X.509 Certificate - Signature
This type requests that the end entity certificate be a signing
certificate. Implementations that receive CERTREQs which contain this
ID type in a context in which end entity signature certificates are
not used SHOULD ignore such CERTREQs.
3.3.3. X.509 Certificate - Key Exchange
This type requests that the end entity certificate be a key exchange
certificate. Implementations that receive CERTREQs which contain this
ID type in a context in which end entity key exchange certificates
are not used SHOULD ignore such CERTREQs.
3.3.4. Certificate Revocation List (CRL)
This type requests that X.509 CRLs be provided, along with any cer-
tificates that may be needed to validate those CRLs.
3.3.5. Authority Revocation List (ARL)
Implementations SHOULD NOT generate CERTREQ payloads with this type,
but should instead generate CRL CERTREQs. That is, implementations
request CRLs generically, whether they be CRLs or ARLs, using the CRL
type. Recipients of this type SHOULD treat it as synonymous with the
CRL type.
3.3.6. PKCS #7 wrapped X.509 certificate
This ID type defines a particular encoding (not a particular
certificate or CRL type), some current implementations may ignore
CERTREQs they receive which contain this ID type, and the authors are
unaware of any implementations that generate such CERTREQ messages.
Therefore, the use of this type is deprecated. Implementations SHOULD
Korver, Rescorla [Page 12]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
NOT generate CERTREQs that contain this Certificate Type. Implementa-
tions which receive CERTREQs which contain this ID type MAY ignore
such payloads.
3.3.7. Presence or Absence of Certificate Request Payloads
When in-band exchange of certificate keying materials is desired,
implementations MUST inform the peer of this by sending at least one
CERTREQ. An implementation which does not send any CERTREQs during an
exchange SHOULD NOT expect to receive any CERT payloads.
3.3.8. Certificate Requests
3.3.8.1. Specifying Certificate Authorities
Implementations MUST generate CERTREQs for every peer trust anchor
that local policy explicitly deems trusted during a given exchange.
Implementations MUST populate the Certificate Authority field with
the Subject Name of the trust anchor, populated such that binary com-
parison of the Subject Name and the Certificate Authority will suc-
ceed.
Upon receipt of a CERTREQ where the Certificate Type is either "X.509
Certificate - Signature" or "X.509 Certificate - Key Exchange",
implementations MUST respond by sending each certificate in the chain
from the end entity certificate to the certificate whose Issuer Name
matches the name specified in the Certificate Authority field. Imple-
mentations MAY send other certificates from the chain.
Note, in the case where multiple end entity certificates may be
available, implementations SHOULD resort to local heuristics to
determine which end entity is most appropriate to use. Such heuris-
tics are out of the scope of this document.
3.3.8.2. Empty Certificate Authority Field
Implementations MUST NOT generate CERTREQs where the Certificate Type
is either "X.509 Certificate - Signature" or "X.509 Certificate - Key
Exchange" with an empty Certificate Authority field. Upon receipt of
such a CERTREQ from a non-conformant implementation, implementations
SHOULD send just the certificate chain associated with the end entity
certificate, not including any CRLs or the certificates that would be
needed to validate those CRLs.
Note that PKIX prohibits certificates with an empty issuer name
field.
Korver, Rescorla [Page 13]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.3.9. CRL Requests
3.3.9.1. Specifying Certificate Authorities
Upon receipt of a CERTREQ where the Certificate Type is "Certificate
Revocation List (CRL)", implementations MUST respond by sending the
CRL issued by the issuer of each certificate in the chain between the
end entity certificate and the certificate whose Issuer Name matches
the name specified in the Certificate Authority field. In additional,
implementations MUST send any certificates that the peer will need to
validate those CRLs, while optionally eliding those certificates and
CRLs identified in CERTREQs as already being in the possession of the
peer.
3.3.9.2. Empty Certificate Authority Field
Implementations MAY generate CERTREQs where the Certificate Type is
"Certificate Revocation List (CRL)" with an empty Certificate Author-
ity field to signify that the peer should send all CRLs that are pos-
sessed by that peer, whether relevant to the current exchange or not.
Upon receipt of such a CERTREQ, implementations SHOULD send all CRLs
that are possessed but MUST send all CRLs that are relevant to the
current exchange, including the certificates that are needed to vali-
date those CRLs.
Note that PKIX prohibits CRLs with an empty issuer name field.
3.3.10. Robustness
3.3.10.1. Unrecognized or Unsupported Certificate Types
Implementations MUST be able to deal with receiving CERTREQs with
unsupported Certificate Types. Absent any recognized and supported
CERTREQs, implementations MAY treat them as if they are of a sup-
ported type with the Certificate Authority field left empty, depend-
ing on local policy. ISAKMP Section 5.10 "Certificate Request Payload
Processing" specifies additional processing.
3.3.10.2. Undecodable Certificate Authority Fields
Implementations MUST be able to deal with receiving CERTREQs with
undecodable Certificate Authority fields. Implementations MAY treat
such fields as if there were empty, depending on local policy. ISAKMP
specifies other actions which may be taken.
Korver, Rescorla [Page 14]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.3.10.3. Ordering of Certificate Request Payloads
Implementations MUST NOT assume that CERTREQs are ordered in any way.
3.3.11. Optimizations
3.3.11.1. Duplicate Certificate Request Payloads
Implementations SHOULD NOT send duplicate CERTREQs during an
exchange.
3.3.11.2. Name Lowest 'Common' Certification Authorities
When a peer's certificate keying materials have been cached, an
implementation can send a hint to the peer to elide some of the cer-
tificates and CRLs the peer would normally respond with. In addition
to the normal set of CERTREQs that are sent, an implementation MAY
send CERTREQs containing the Issuer Name of the relevant cached end
entity certificates. When sending these hints, it is still necessary
to send the normal set of CERTREQs because the hints do not suffi-
ciently convey all of the information required by the peer. Specifi-
cally, either the peer may not support this optimization or there may
be additional chains that could be used in this context but will not
be specified if only supplying the issuer of the end entity
certificate.
No special processing is required on the part of the recipient of
such a CERTREQ, and the end entity certificates will still be sent.
On the other hand, the recipient MAY elect to elide certificates
based on receipt of such hints.
ISAKMP mandates that CERTREQs contain the Subject Name of a Certifi-
cation Authority, which results in the peer always sending at least
the end entity certificate. This mechanism allows implementations to
determine unambiguously when a new certificate is being used by the
peer, perhaps because the previous certificate has just expired,
which will result in a failure because the needed keying materials
are not available to validate the new end entity certificate. Imple-
mentations which implement this optimization MUST recognize when the
end entity certificate has changed and respond to it by not perform-
ing this optimization when the exchange is retried.
3.3.11.3. Example
Imagine that an implementation has previously received and cached the
peer certificate chain TA->CA1->CA2->EE. If during a subsequent
exchange this implementation sends a CERTREQ containing the Subject
Name in certificate TA, this implementation is requesting that the
Korver, Rescorla [Page 15]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
peer send at least 3 certificates: CA1, CA2, and EE. On the other
hand, if this implementation also sends a CERTREQ containing the Sub-
ject Name of CA2, the implementation is providing a hint that only 1
certificate needs to be sent: EE. Note that in this example, that TA
is a trust anchor should not be construed to imply that TA is a self-
signed certificate.
3.4. Certificate Payload
3.4.1. Certificate Type
The Certificate Type field identifies to the peer the type of
certificate keying materials that are included. ISAKMP defines 10
types of Certificate Data that can be sent and specifies the syntax
for these types. For the purposes of this document, only the follow-
ing types are relevant:
* X.509 Certificate - Signature
* X.509 Certificate - Key Exchange
* Certificate Revocation List (CRL)
* Authority Revocation List (ARL)
* PKCS #7 wrapped X.509 certificate
For example, if CRLs are desired, an implementation will populate the
Certificate Type field with the value associated with "Certificate
Revocation List (CRL)".
The use of the other types:
* PGP Certificate
* DNS Signed Key
* Kerberos Tokens
* SPKI Certificate
* X.509 Certificate - Attribute
are out of the scope of this document.
3.4.2. X.509 Certificate - Signature
This type specifies that Certificate Data contains a certificate used
for signing, whether an end entity signature certificate or a CA
certificate or CRL signing certificate.
3.4.3. X.509 Certificate - Key Exchange
This type specifies that Certificate Data contains an end entity
certificate used for either key exchange (or key encipherment).
Korver, Rescorla [Page 16]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.4.4. Certificate Revocation List (CRL)
This type specifies that Certificate Data contains an X.509 CRL.
3.4.5. Authority Revocation List (ARL)
This type specifies that Certificate Data contains an X.509 CRL that
revokes CAs. In response to CRL CERTREQs, an implementation may
include ARLs in an ARL payload to more precisely specify the contents
of the CERT payload. Recipients of this type MAY treat it as synony-
mous with the CRL type.
3.4.6. PKCS #7 wrapped X.509 certificate
This type defines a particular encoding, not a particular certificate
or CRL type. Implementations SHOULD NOT generate CERTs that contain
this Certificate Type. Implementations which violate this requirement
SHOULD note that this is a single certificate as specified in ISAKMP.
Implementations SHOULD accept CERTs that contain this Certificate
type.
3.4.7. Certificate Payloads Not Mandatory
An implementation which does not receive any CERTREQs during an
exchange SHOULD NOT send any CERT payloads, except when explicitly
configured to proactively send CERT payloads in order to interoperate
with non-compliant implementations. In this case, an implementation
MUST send the all certificate chains and CRLs associated with the end
entity certificate. This MUST NOT be the default behavior of imple-
mentations.
Implementations which are configured to expect that a peer must
receive certificates through out-of-band means SHOULD ignore any
CERTREQ messages that are received.
Implementations that receive CERTREQs from a peer which contain only
unrecognized Certification Authorities SHOULD NOT continue the
exchange, in order to avoid unnecessary and potentially expensive
cryptographic processing.
3.4.8. Response to Multiple Certificate Authority Proposals
In response to multiple CERTREQs which contain different Certificate
Authority identities, implementations MAY respond using an end entity
certificate which chains to a CA that matches any of the identities
provided by the peer.
Korver, Rescorla [Page 17]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.4.9. Using Local Keying Materials
Implementations MAY elect not to use keying materials contained in a
given set of CERTs if preferable keying materials are available. For
instance, the contents of a CERT may be available from a previous
exchange, or a newer CRL may be available through some out-of-band
means.
3.4.10. Robustness
3.4.10.1. Unrecognized or Unsupported Certificate Types
Implementations MUST be able to deal with receiving CERTs with unrec-
ognized or unsupported Certificate Types. Implementations MAY discard
such payloads, depending on local policy. ISAKMP Section 5.10
"Certificate Request Payload Processing" specifies additional pro-
cessing.
3.4.10.2. Undecodable Certificate Data Fields
Implementations MUST be able to deal with receiving CERTs with unde-
codable Certificate Data fields. Implementations MAY discard such
payloads, depending on local policy. ISAKMP specifies other actions
which may be taken.
3.4.10.3. Ordering of Certificate Payloads
Implementations MUST NOT assume that CERTs are ordered in any way.
3.4.10.4. Duplicate Certificate Payloads
Implementations MUST support receiving multiple identical CERTs dur-
ing an exchange.
3.4.10.5. Irrelevant Certificates
Implementations MUST be prepared to receive certificates and CRLs
which are not relevant to the current exchange. Implementations MAY
discard such extraneous certificates and CRLs.
Implementations MAY include certificates which are irrelevant to an
exchange. One reason for including certificates which are irrelevant
to an exchange is to minimize the threat of leaking identifying
information in exchanges where CERT is not encrypted. It should be
noted, however, that this probably provides rather poor protection
against leaking the identity.
Korver, Rescorla [Page 18]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
3.4.11. Optimizations
3.4.11.1. Duplicate Certificate Payloads
Implementations SHOULD NOT send duplicate CERTs during an exchange.
Such payloads should be suppressed.
3.4.11.2. Send Lowest 'Common' Certificates
When multiple CERTREQs are received which specify certificate author-
ities within the end entity certificate chain, implementations MAY
send the shortest chain possible. However, implementations SHOULD
always send the end entity certificate. See section 3.3.11.2 for more
discussion of this optimization.
3.4.11.3. Drop Duplicate Certificate Payloads
Implementations MAY employ local means to recognize CERTs that have
been received in the past, whether part of the current exchange or
not, for which keying material is available and may discard these
duplicate CERTs.
4. Profile of PKIX
4.1. X.509 Certificates
4.1.1. Versions
Although PKIX states that "implementations SHOULD be prepared to
accept any version certificate", in practice this profile requires
certain extensions that necessitate the use of Version 3 certificates
for all but certain self-signed certificates that are used as trust
anchors. Implementations that conform to this document MAY therefore
reject Version 1 and Version 2 certificates in all other cases.
4.1.2. Subject Name
4.1.2.1. Empty Subject Name
Implementations MUST accept certificates which contain an empty Sub-
ject Name field, as specified in PKIX. Identity information in such
certificates will be contained entirely in the SubjectAltName exten-
sion.
Korver, Rescorla [Page 19]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
4.1.2.2. Specifying Non-FQDN Hosts in Subject Name
Implementations which desire to place host names that are not
indended to be processed by recipients as FQDNs (for instance "Gate-
way Router") in the Subject Name MUST use the commonName attribute.
While nothing prevents an FQDN, USER-FQDN, or IP address information
from appearing somewhere in the Subject Name contents, with the
exception of domainComponent which is discussed below, such entries
MUST NOT be interpreted by compliant implementations as identity
information.
4.1.2.3. Specifying FQDN Host Names in Subject Name
Implementations SHOULD NOT populate the Subject Name in place of pop-
ulating the dNSName field of the SubjectAltName extension.
Implementations which desire to place resolvable FQDNs (for instance
"gateway.example.com") in the Subject Name field MUST use the domain-
Component attribute type, as specified in PKIX. PKIX further speci-
fies that implementations MUST be prepared to receive the domainCom-
ponent attribute. The contents of the domainComponent are semanti-
cally identical to the contents of the SubjectAltName dNSName field.
Note, however, that support for the domainComponent attribute is far
from universal and some implementations will reject or fail to dis-
play certificates that contain this attribute.
4.1.2.4. EmailAddress
As specified in PKIX, implementations MUST NOT populate Distin-
guishedNames with the EmailAddress attribute.
4.1.3. X.509 Certificate Extensions
Conforming applications MUST recognize extensions which must or may
be marked critical according to this specification. These extensions
are: KeyUsage, SubjectAltName, and BasicConstraints.
Implementations SHOULD generate certificates such that the extension
criticality bits are set in accordance with PKIX and this document.
With respect to PKIX compliance, implementations processing certifi-
cates MAY ignore the value of the criticality bit for extensions that
are supported by that implementation, but MUST support the critical-
ity bit for extensions that are not supported by that implementation.
That is, if an implementation supports (and thus is going to process)
a given extension, then it isn't necessary to reject the certificate
if the criticality bit is different from what PKIX states it must be.
Korver, Rescorla [Page 20]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
However, if an implementation does not support an extension that PKIX
mandates be critical, then the implementation must reject the
certificate.
implements bit in cert PKIX mandate behavior
------------------------------------------------------
yes true true ok
yes true false ok or reject
yes false true ok or reject
yes false false ok
no true true reject
no true false reject
no false true reject
no false false ok
4.1.3.1. AuthorityKeyIdentifier
Implementations SHOULD NOT assume that other implementations support
the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate
certificate hierarchies which overly complex to process in the
absence of this extension, such that those that require possibly ver-
ifying a signature against a large number of similarly named CA cer-
tificates in order to find the CA certificate which contains the key
that was used to generate the signature.
4.1.3.2. SubjectKeyIdentifier
Implementations SHOULD NOT assume that other implementations support
the SubjectKeyIdentifier extension, and thus SHOULD NOT generate
certificate hierarchies which overly complex to process in the
absence of this extension, such that those that require possibly ver-
ifying a signature against a large number of similarly named CA cer-
tificates in order to find the CA certificate which contains the key
that was used to generate the signature.
4.1.3.3. KeyUsage
The meaning of the nonRepudiation bit is not defined in the context
of IPsec, although implementations SHOULD interpret the nonRepudia-
tion bit as synonymous with the digitalSignature bit. Implementations
SHOULD NOT generate certificates which only assert the nonRepudiation
bit.
See PKIX for general guidance on which of the other KeyUsage bits
should be set in any given certificate.
Korver, Rescorla [Page 21]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
4.1.3.4. PrivateKeyUsagePeriod
PKIX recommends against the use of this extension. The Pri-
vateKeyUsageExtension is intended to be used when signatures will
need to be verified long past the time when signatures using the pri-
vate keypair may be generated. Since ISAKMP SAs are short-lived rela-
tive to the intended use of this extension in addition to the fact
that each signature is validated only a single time, the meaning of
this extension in the context of ISAKMP is unclear. Therefore, the
PrivateKeyUsagePeriod is inappropriate in the context of ISAKMP and
therefore implementations MUST NOT generate certificates that contain
the PrivateKeyUsagePeriod extension.
4.1.3.5. Certificate Policies
Many IPsec implementations do not currently provide support for the
Certificate Policies extension. Therefore, implementations that gen-
erate certificates which contain this extension SHOULD mark the
extension as non-critical.
4.1.3.6. PolicyMappings
Many implementations do not support the PolicyMappings extension.
4.1.3.7. SubjectAltName
Implementations SHOULD generate only the following GeneralName
choices in the subjectAltName extension, as these choices map to
legal ISAKMP Identity Payload types ISAKMP: rfc822Name, dNSName, or
iPAddress. Although it is possible to specify any GeneralName choice
in the ISAKMP Identity Payload by using the ID_DER_ASN1_GN ID type,
implementations SHOULD NOT assume that a peer supports such function-
ality.
4.1.3.7.1. dNSName
This field MUST contain a fully qualified domain name. Implementa-
tions MUST NOT generate names that contain wildcards.
Implementations MAY treat certificates that contain wildcards in this
field as syntactically invalid.
Although this field is in the form of an FQDN, implementations SHOULD
NOT assume that the this field contains an FQDN that will resolve via
the DNS, unless this is known by way of some out-of-band mechanism.
Such a mechanism is out of the scope of this document. Implementa-
tions SHOULD NOT treat the failure to resolve as an error.
Korver, Rescorla [Page 22]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
4.1.3.7.2. iPAddress
Note that although PKIX permits CIDR [CIDR] notation in the "Name
Constraints", PKIX also explicitly prohibits using CIDR notation for
conveying identity information. In other words, the CIDR notation
MUST NOT be used in the subjectAltName extension.
4.1.3.7.3. rfc822Name
Although this field is in the form of an Internet mail address,
implementations SHOULD NOT assume that the this field contains a
valid email address, unless this is known by way of some out-of-band
mechanism. Such a mechanism is out of the scope of this document.
4.1.3.8. IssuerAltName
Implementations SHOULD NOT assume that other implementations support
the IssuerAltName extension, and especially should not assume that
information contained in this extension will be displayed to end
users.
4.1.3.9. SubjectDirectoryAttributes
The SubjectDirectoryAttributes extension is intended to contain priv-
ilege information, in a manner analogous to privileges carried in
Attribute Certificates. Implementations MAY ignore this extension as
PKIX mandates it be marked non-critical.
4.1.3.10. BasicConstraints
PKIX mandates that CA certificates contain this extension and that it
be marked critical. Implementations SHOULD reject CA certificates
that do not contain this extension. For backwards compatibility,
implementations may accept such certificates if explicitly configured
to do so, but the default for this setting MUST be to reject such
certificates.
4.1.3.11. NameConstraints
Many implementations do not support the NameConstraints extension.
Since PKIX mandates that this extension be marked critical when pre-
sent, implementations which intend to be maximally interoperable
SHOULD NOT generate certificates which contain this extension.
4.1.3.12. PolicyConstraints
Many implementations do not support the PolicyConstraints extension.
Since PKIX mandates that this extension be marked critical when
Korver, Rescorla [Page 23]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
present, implementations which intend to be maximally interoperable
SHOULD NOT generate certificates which contain this extension.
4.1.3.13. ExtendedKeyUsage
No ExtendedKeyUsage usages are defined for IPsec, so if this exten-
sion is present and marked critical, use of this certificate for
IPsec MUST be treated as an error. Implementations MUST NOT generate
this extension in certificates which are being used for IPsec.
Note that a previous proposal for the use of three ExtendedKeyUsage
values is obsolete and explicitly deprecated by this specification.
For historical reference, those values were id-kp-ipsecEndSystem, id-
kp-ipsecTunnel, and id-kp-ipsecUser.
4.1.3.14. CRLDistributionPoint
Most implementations expect to exchange CRLs in band via the ISAKMP
Certificate Payload. Implementations MUST NOT assume that the CRLDis-
tributionPoint extension will exist in peer extensions and therefore
implementations SHOULD request that peers send CRLs in the absence of
knowledge that this extension exists in the peer's certificates.
However receiving CRLs in band via ISAKMP does not alleviate the
requirement to process the CRLDistributionPoint if the certificate
being validated contains the extension and the CRL being used to val-
idate the certificate contains the IssuingDistributionPoint. Failure
to validate the CRLDistributionPoint/IssusingDistributionPoint pair
can result in CRL substitution where an entity knowingly substitutes
a known good CRL for the CRL which is supposed to be used which would
show the entity as revoked.
Implementations MUST support validation that the contents of CRLDis-
tributionPoints match those of the IssuingDistributionPoint to pre-
vent CRL substitution when the issuing CA is using them. At least
one CA is known to default to this type of CRL use. See section
4.2.3.5 for more information.
See PKIX docs for CRLDistributionPoints intellectual rights informa-
tion.
4.1.3.15. InhibitAnyPolicy
Many implementations do not support the InhibitAnyPolicy extension.
Since PKIX mandates that this extension be marked critical when pre-
sent, implementations which intend to be maximally interoperable
SHOULD NOT generate certificates which contain this extension.
Korver, Rescorla [Page 24]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
4.1.3.16. FreshestCRL
Most implementations expect to exchange CRLs in band via the ISAKMP
Certificate Payload. Implementations MUST NOT assume that the Fresh-
estCRL extension will exist in peer extensions and therefore imple-
mentations SHOULD request that peers send CRLs in the absence knowl-
edge that this extension exists in the peer certificates. Note that
most implementations do not support delta CRLs.
4.1.3.17. AuthorityInfoAccess
PKIX defines the AuthorityInfoAccess extension, which is used to
indicate "how to access CA information and services for the issuer of
the certificate in which the extension appears." This extension has
no known use in the context of IPsec. Conformant implementations
SHOULD ignore this extension when present.
4.1.3.18. SubjectInfoAccess
PKIX defines the SubjectInfoAccess private certificate extension,
which is used to indicate "how to access information and services for
the subject of the certificate in which the extension appears." This
extension has no known use in the context of IPsec. Conformant imple-
mentations SHOULD ignore this extension when present.
4.2. X.509 Certificate Revocation Lists
Implementations SHOULD send CRLs, unless non-CRL certificate revoca-
tion information is known to be preferred by all interested parties
in the application environment that the implementation is used.
Implementations MUST send CRLs if non-CRL certificate revocation
information may not be available to all interested parties.
4.2.1. Certificate Revocation Requirement
Implementations which validate certificates MUST make use of
certificate revocation information, and SHOULD support such revoca-
tion information in the form of CRLs, unless non-CRL revocation
information is known to be the only method for transmitting this
information.
4.2.2. Multiple Sources of Certificate Revocation Information
Implementations which support multiple sources of obtaining
certificate revocation information MUST act conservatively when the
information provided by these sources is inconsistent: when a
certificate is reported as revoked by one source, the certificate
MUST be considered revoked.
Korver, Rescorla [Page 25]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
4.2.3. X.509 Certificate Revocation List Extensions
4.2.3.1. AuthorityKeyIdentifier
Implementations SHOULD NOT assume that other implementations support
the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate
certificate hierarchies which overly complex to process in the
absence of this extension.
4.2.3.2. IssuerAltName
Implementations SHOULD NOT assume that other implementations support
the IssuerAltName extension, and especially should not assume that
information contained in this extension will be displayed to end
users.
4.2.3.3. CRLNumber
As stated in PKIX, all issuers conforming to PKIX MUST include this
extension in all CRLs.
4.2.3.4. DeltaCRLIndicator
4.2.3.4.1. If Delta CRLs Are Unsupported
Implementations that do not support delta CRLs MUST reject CRLs which
contain the DeltaCRLIndicator (which MUST be marked critical accord-
ing to PKIX) and MUST make use of a base CRL if it is available. Such
implementations MUST ensure that a delta CRL does not "overwrite" a
base CRL, for instance in the keying material database.
4.2.3.4.2. Delta CRL Recommendations
Since some implementations that do not support delta CRLs may behave
incorrectly or insecurely when presented with delta CRLs, implementa-
tions SHOULD consider whether issuing delta CRLs increases security
before issuing such CRLs.
The authors are aware of several implementations which behave in an
incorrect or insecure manner when presented with delta CRLs. See
Appendix B for a description of the issue. Therefore, this specifica-
tion RECOMMENDS against issuing delta CRLs at this time. On the other
hand, failure to issue delta CRLs exposes a larger window of vulnera-
bility. See the Security Considerations section of PKIX for addi-
tional discussion. Implementors as well as administrators are encour-
aged to consider these issues.
Korver, Rescorla [Page 26]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
4.2.3.5. IssuingDistributionPoint
A CA that is using CRLDistributionPoints may do so to provide many
"small" CRLs, each only valid for a particular set of certificates
issued by that CA. To associate a CRL with a certificate, the CA
places the CRLDistributionPoint extension in the certificate, and
places the IssuingDistributionPoint in the CRL. The distribution-
PointName field in the CRLDistributionPoint extension and the MUST be
identical to the distributionPoint field in the IssuingDistribution-
Point extension. At least one CA is known to default to this type of
CRL use. See section 4.1.3.14 for more information.
4.2.3.6. FreshestCRL
Given the recommendations against implementations generating delta
CRLs, this specification RECOMMENDS that implementations do not popu-
late 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, and MUST support the
three line-termination disciplines: LF (US-ASCII 10), CR (US-ASCII
13), and CRLF.
5.1. Certificates
Certificates MUST be Base64 encoded and appear between the following
delimiters:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
5.2. Public Keys
Implementations MUST support two forms of public keys: certificates
and so-called "raw" keys. Certificates should be transferred in the
same form as above. A raw key is only the SubjectPublicKeyInfo por-
tion of the certificate, and MUST be Base64 encoded and appear
between the following delimiters:
-----BEGIN PUBLIC KEY-----
Korver, Rescorla [Page 27]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
-----END PUBLIC KEY-----
5.3. PKCS#10 Certificate Signing Requests
A PKCS#10 [PKCS-10] Certificiate Signing Request MUST be Base64
encoded and appear between the following delimeters:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
6. IKE
6.1. IKE Phase 1 Authenticated With Signatures
6.1.1. Identification Payload
IKE mandates the use of the ID payload in Phase 1.
Implementations SHOULD populate ID with identity information that is
contained within the end entity certificate. This enables recipients
to use ID as a lookup key to find the peer end entity certificate.
The only case where implementations MAY populate ID with information
that is not contained in the end entity certificate is when ID con-
tains the peer source address (a single address, not a subnet or
range). This means that implementations MUST be able to map a peer
source address to a peer end entity certificate, even when the
certificate does not contain that address. The exact method for per-
forming this mapping is out of the scope of this document.
6.1.2. X.509 Certificate Extensions
6.1.2.1. KeyUsage
If the KeyUsage extension is present in an end entity certificate,
the digitalSignature bit MUST be asserted, or if no other bits but
the nonRepudiation bit are asserted and the certificate is being used
to generate a signature, an implementation MAY interpret the nonRepu-
diation bit as synonymous with the digitalSignature.
6.1.3. Obtaining Peer Certificates and CRLs
IKE implementations MUST assume all necessary certificates and CRLs
will be exchanged in-band.
Korver, Rescorla [Page 28]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
6.2. IKE Phase 1 Authenticated With Public Key Encryption
6.2.1. Identification Payload
IKE mandates the use of the ID payload in Phase 1.
If certificates are not being used, the contents of ID are out of
scope for this document.
6.2.2. Hash Payload
IKE specifies the optional use of the Hash Payload to carry a pointer
to a certificate in either of the Phase 1 public key encryption
modes. This pointer is used by an implementation to locate the end
entity certificate that contains the public key that a peer should
use for encrypting payloads during the exchange.
Implementations SHOULD include this payload whenever the public por-
tion of the keypair has been placed in a certificate.
6.2.3. X.509 Certificate Extensions
6.2.3.1. KeyUsage
If the KeyUsage extension is present in an end entity certificate,
the keyEncipherment bit MUST be asserted, or if no other bits but the
nonRepudiation bit are asserted and the certificate is being used for
key encipherment, an implementation MAY interpret the nonRepudiation
bit as synonymous with the keyEncipherment.
6.2.4. Obtaining Peer Certificates and CRLs
Certificates are generally not exchanged in-band, but rather are
exchanged out-of-band, with direct trust of the peer certificate
being most prevalent. CRLs SHOULD be obtained out-of-band from a
directory or other repository.
6.3. IKE Phase 1 Authenticated With a Revised Mode of Public Key Encryp-
tion
IKE Phase 1 Authenticated With a Revised Mode of Public Key Encryp-
tion has the same requirements as IKE Phase 1 Authenticated With Pub-
lic Key Encryption. See section 6.2 for these requirements.
7. Security Considerations
Korver, Rescorla [Page 29]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
7.1. Identity Payload
Depending on the exchange type, ID may be passed in the clear. Admin-
istrators in some environments may wish to use the empty Certifica-
tion Authority option to prevent such information from leaking, at
the possible cost of some performance.
7.2. Certificate Request Payload
The Contents of CERTREQ are not encrypted in IKE. In some environ-
ments this may leak private information. Administrators in some envi-
ronments may wish to use the empty Certification Authority option to
prevent such information from leaking, at the cost of performance.
7.3. Certificate Payload
Depending on the exchange type, CERTs may be passed in the clear and
therefore may leak identity information.
7.4. IKE Main Mode
Implementations may not wish to respond with CERTs in the second mes-
sage, thereby violating the identity protection feature of Main Mode
IKE. ISAKMP allows CERTs to be included in any message, and therefore
implementations may wish to respond with CERTs in a message that
offers privacy protection in this case.
7.5. IKE Aggressive Mode
The contents of ID are not encrypted in Aggressive Mode when authen-
tication is performed with signatures. In some environments this may
leak private information. The solutions to this problem if such a
leak is unacceptable are:
* Use Main Mode instead of Aggressive Mode.
* Populate ID Data with the address of the host.
The contents of CERT are not encrypted in Aggressive Mode when
authentication is performed with signatures. In some environments
this may leak private information. The solutions to this problem if
such a leak is unacceptable are:
* Use Main Mode instead of Aggressive Mode.
8. Intellectual Property Rights
No new intellectual property rights are introduced by this document.
Korver, Rescorla [Page 30]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
9. IANA Considerations
There are no known numbers which IANA will need to manage.
10. Normative References
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IPSEC] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[ISAKMP] Maughan, D., et. al., "Internet Security Association and
Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax
Version 1.5", RFC 2314, March 1998.
[PKIX] Housley, R., et al., "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3280, April 2002.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11. Informational References
[CIDR] Fuller, V., et al., "Classless Inter-Domain Routing (CIDR):
An Address Assignment and Aggregation Strategy", RFC 1519,
September 1993.
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC1883] Deering, S. and Hinden, R. "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap",
draft-ietf-pkix-roadmap-08.txt.
[SBGP] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for
IP Addresses and AS Identifiers",
draft-ietf-pkix-x509-ipaddr-as-extn-00.txt.
Korver, Rescorla [Page 31]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
12. Acknowledgements
The authors would like to acknowledge the expired draft-ietf-ipsec-
pki-req-05.txt for providing valuable materials for this document.
The authors would like to especially thank Greg Carter and Russ Hous-
ley for their valuable comments, some of which have been incorporated
unchanged into this document.
13. Author's Addresses
Brian Korver
Xythos Software, Inc.
25 Maiden Lane, 6th Floor
San Francisco, CA 94108
USA
Phone: +1 415 248-3800
EMail: briank@xythos.com
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
USA
Phone: +1 650 320-8549
EMail: ekr@rtfm.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Korver, Rescorla [Page 32]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Appendix A. Change History
* February 2003
Word choice: move from use of "root" to "trust anchor", in accor-
dance with PKIX
SBGP note and reference for placing address subnet and range
information into certificates
Clarification of text regarding placing names of hosts into the
Name commonName attribute of SubjectName
Added table to clarify text regarding processing of the
certificate extension criticality bit
Added text underscoring processing requirements for CRLDistribu-
tionPoints and IssuingDistributionPoint
* October 2002, Reorganization
* June 2002, Initial Draft
Appendix B. The Possible Dangers of Delta CRLs
The problem is that the CRL processing algorithm is often written
with the assumption that all CRLs are base CRLs and it is assumed
that CRLs will pass content validity tests. Specifically, such imple-
mentations fail to check the certificate against all possible CRLs:
if the first CRL that is obtained from the keying material database
fails to decode, no further revocation checks are performed for the
relevant certificate. This problem is compounded by the fact that
implementations which do not understand delta CRLs may fail to decode
such CRLs due to the critical DeltaCRLIndicator extension. The algo-
rithm that is implemented in this case is approximately:
Korver, Rescorla [Page 33]Internet-Draft PKI Profile for ISAKMP/PKIX 2/2003
fetch newest CRL
check validity of CRL signature
if CRL signature is valid then
if CRL does not contain unrecognized critical extensions
and certificate is on CRL then
set certificate status to revoked
The authors note that a number of PKI toolkits do not even provide a
method for obtaining anything but the newest CRL, which in the pres-
ence of delta CRLs may in fact be a delta CRL, not a base CRL.
Korver, Rescorla [Page 34]
Datatracker
Report a datatracker bug
draft-ietf-ipsec-pki-profile-02
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |