Network Working Group
Internet Draft B. Korver
Document: draft-ietf-ipsec-pki-profile-00.txt Xythos, Inc.
Expires: October 2002 E. Rescorla
RTFM, Inc.
June 2002
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 RFC-2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
ISAKMP and PKIX both provide frameworks that must be profiled for
use in a given application. This document provides a profile of
ISAKMP and PKIX that defines the requirements for using PKI
technology in the context of IPsec. The document compliments
protocol specifications such as IKE, which assume the existence of
public key certificates and related keying materials, but which do
not address PKI issues explicitly. This document addresses these
issues.
Korver Expires - December 2002 [Page 1]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
Table of Contents
1. Introduction ..................................................3
2. Terms and Definitions .........................................4
3. Profile of ISAKMP .............................................5
3.1 Background .................................................5
3.1.1 Certificate-Related Payloads in ISAKMP ...............5
3.1.1.1 Identification Payload ...........................5
3.1.1.2 Certificate Payload ..............................5
3.1.1.3 Certificate Request Payload ......................5
3.1.1.4 Hash Payload .....................................5
3.1.2 Endpoint Identification ..............................5
3.1.2.1 Identification Payload Only ......................6
3.1.2.2 Certificate Payload Only .........................6
3.2 Identification Payload .....................................6
3.2.1 Securely Binding Identity to Policy ..................6
3.2.1.1 Using Peer IP Address to Bind Identity to Policy .7
3.2.2 Using a PKI ..........................................7
3.2.2.1 Securely Binding Identity to Policy ..............8
3.2.2.2 ID Type ..........................................8
3.2.2.3 Local Policy Regarding ID Types .................10
3.3 Certificate Request Payload ...............................11
3.3.1 Using a PKI .........................................11
3.3.1.1 Certificate Type ................................11
3.3.1.2 Certificate Request Payload Semantics ...........12
3.4 Certificate Payload .......................................15
3.4.1 Using a PKI .........................................16
3.4.1.1 Certificate Payloads Not Mandatory ..............16
3.4.1.2 Response to Multiple Certificate Authority Proposals
................................................16
3.4.1.3 Local Keying Materials ..........................16
3.4.1.4 Certificate Type ................................16
3.4.1.5 Optimizations ...................................18
3.4.1.6 Robustness ......................................18
3.4.2 Leaking Identity Information ........................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 Hosts in Subject Name ................19
4.1.2.3 EmailAddress ....................................20
4.1.3 X.509 Certificate Extensions ........................20
4.2 X.509 Certificate Revocation Lists ........................24
4.2.1 Certificate Revocation Requirement ..................24
4.2.2 Multiple Sources of Certificate Revocation Information24
4.2.3 X.509 Certificate Revocation List Extensions ........25
5. Configuration Data Exchange Conventions ......................26
Korver Expires - December 2002 [Page 2]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
5.1 Certificates ..............................................26
5.2 Public Keys ...............................................26
6. IKE ..........................................................26
6.1 IKE Phase 1 Authenticated With Signatures .................26
6.1.1 Identification Payload ..............................27
6.1.1.1 When the Identification Payload is Mandatory ....27
6.1.1.2 Leaking Identity Information ....................27
6.1.2 Certificate Request Payload .........................27
6.1.3 Certificate Payload .................................27
6.1.3.1 Leaking Identity Information ....................27
6.1.4 X.509 Certificate Extensions ........................28
6.1.4.1 KeyUsage ........................................28
6.2 IKE Phase 1 Authenticated With Public Key Encryption ......28
6.2.1 Identification Payload ..............................28
6.2.1.1 Without Certificates ............................28
6.2.1.2 With Certificates ...............................28
6.2.1.3 When the Identification Payload is Mandatory ....28
6.2.2 Hash Payload ........................................28
6.2.3 X.509 Certificate Extensions ........................29
6.2.3.1 KeyUsage ........................................29
6.3 IKE Phase 1 Authenticated With a Revised Mode of Public Key
Encryption ...............................................29
Intellectual Property Rights ....................................29
Security Considerations .........................................29
References ......................................................29
Acknowledgments .................................................31
Author's Addresses ..............................................31
Full Copyright Statement ........................................32
A. Change History ..............................................32
B. The Possible Dangers of Delta CRLs ..........................32
C. Mapping A Peer Address to a Peer Certificate ................33
1. Introduction
IKE [IKE] and ISAKMP [ISAKMP] provide a secure key exchange
mechanism for use with IPsec [IPSEC]. In many cases the peers
authenticate using digital certificates as specified in PKIX [PKIX].
Unfortunately, the combination of these standards leads to an
underspecified set of requirements for the use of certificates in
the context of IPsec. PKIX provides a large set of certificate
mechanisms which are generally applicable for Internet protocols,
but no specific guidance for IPsec. This document profiles the PKIX
framework for use with ISAKMP and IPsec.
ISAKMP references PKIX but in many cases merely specifies the
contents of various messages without specifying their semantics. In
other cases, contents may be specified no more precisely than to
require some form of X.509 certificate. This document profiles the
Korver Expires - December 2002 [Page 3]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
contents of the relevant ISAKMP payloads and further specifies their
semantics.
Since the ISAKMP and PKIX frameworks present the implementor with
numerous underspecified choices, interoperability is hampered if all
implementors do not make similar choices, or at least fail to
account for implementations which choose different options. This
profile of ISAKMP and PKIX is intended to provide an agreed upon
standard for using PKI technology in the context of IPsec.
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.
Version "00" of this document is intended as a "straw man" to
encourage comments from implementors of IPsec and to encourage
discussion of the issues which the authors hope to address this
document.
This document is being discussed on the ipsec@lists.tislabs.com
mailing list, which is the mailing list for the IPsec Working Group.
2. Terms and Definitions
Except for those terms which are defined immediately below, all PKI
terms used in this document are defined in either the PKIX, ISAKMP,
or DOI [DOI] documents.
. Peer 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.
. Root CA: A CA that is directly trusted by an end entity.
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].
Korver Expires - December 2002 [Page 4]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
3. Profile of ISAKMP
3.1 Background
3.1.1 Certificate-Related Payloads in ISAKMP
ISAKMP has three primary certificate-related payloads:
Identification, Certificate, and Certificate Request. Additionally,
IKE specifies the optional use of the Hash Payload to carry a
pointer to a certificate in either of the Phase 1 public key
encryption modes. In this section we provide a short introduction
to these payload types.
3.1.1.1 Identification Payload
The Identification (ID) Payload is used to indicate the identity
that the agent claims to be speaking for. The receiving agent can
then use the ID as a lookup key for policy and whatever certificate
store or directory that it has available. Our primary concern in
this document is to profile the ID payload so that it can be safely
used to generate or lookup policy.
3.1.1.2 Certificate Payload
The Certificate (CERT) Payload allows the peer to transmit a single
certificate or CRL. Multiple certificates are transmitted in
multiple payloads. However, not all certificate forms that are
legal in PKIX make sense in the context of ISAKMP or IPsec. The
issue of how to represent ISAKMP-meaningful name-forms in a
certificate is especially problematic. This memo provides a profile
for a subset of PKIX that makes sense for ISAKMP.
3.1.1.3 Certificate Request Payload
The Certificate Request (CERTREQ) Payload allows an ISAKMP
implementation to request that a peer provide some set of
certificates. It is not clear from ISAKMP exactly how that set
should be specified or how the peer should respond. We describe the
semantics on both sides.
3.1.1.4 Hash Payload
The Hash (HASH) Payload is a generic mechanism for ISAKMP
implementations to communicate hash values to a peer. The meaning
of the contents of such payloads is left undefined by ISAKMP.
3.1.2 Endpoint Identification
Korver Expires - December 2002 [Page 5]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
ISAKMP contains two different payloads that allow the specification
of endpoint identity, the ID payload and the CERT payload.
According to ISAKMP, these payloads can be used separately or
together, although specific profiles of ISAKMP may place additional
requirements on implementations.
3.1.2.1 Identification Payload Only
If one peer presents only the ID payload, it is expected that the
peer will be able to recover whatever keying material is required to
verify the peer's identity. How to do so is out of the scope of
this document but might include a local cache, an LDAP directory, or
DNS.
3.1.2.2 Certificate Payload Only
If a peer presents only a CERT payload, this creates an ambiguity,
since ISAKMP does not specify which of potentially many certificates
corresponds to the end-entity and which are chaining certificates.
Implementations SHOULD compare whatever local hints they have about
peer identity to each certificate until they find one that appears
acceptable.
3.2 Identification Payload
According to ISAKMP:
"The Identification Payload contains DOI-specific data used to
exchange identification information. This information is used for
determining the identities of communicating peers and may be used
for determining authenticity of information."
Note, the Identity Payload requirements in this document only cover
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 address is permitted by the relevant policy are not addressed
here as they are out of the scope of this document.
3.2.1 Securely Binding Identity to Policy
Because implementations sometimes use Identification Data as a
lookup key to determine which policy to use, all implementations
MUST be especially careful to verify the truthfulness of the
Identification Data by verifying that the Identification Data
corresponds to some keying material demonstrably held by the peer.
Failure to do so may result in the use of an inappropriate or
insecure policy.
Korver Expires - December 2002 [Page 6]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
3.2.1.1 Using Peer IP Address to Bind Identity to Policy
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 Identification
Data.
3.2.1.1.1 Peer IP Address Considerations
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 specific CA that is trusted to issue certificates which
contain a valid rfc822Name which will be used by that implementation
to 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) that the peer has been granted access to.
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 traffic.
Implementations may want to consider their deployment environments
when considering local Identity Payload policy, although such
considerations are environment-specific and thus out of scope of
this document.
In general, however, it is easier to spoof the contents of an ID
payload than it is to spoof a peer address. Implementations MUST
validate the Identity Data provided by a peer, but implementations
SHOULD favor unauthenticated peer addresses over unauthenticated
Identity Data for policy lookup, unless an implementation has been
configured to do otherwise.
3.2.2 Using a PKI
For the purposes of this section, it is assumed that there exists a
peer certificate chain that has been validated and which is trusted
in the context of the policy being discussed.
Korver Expires - December 2002 [Page 7]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
3.2.2.1 Securely Binding Identity to Policy
3.2.2.1.1 Single Address Identification Data
In the case where Identification Data contains an address (not an
address range or subnet), implementations MUST verify that this
address is the same as the peer address. If the end entity
certificate contains addresses identity, then the peer address must
match one of those identities. If either of the above do not match,
this MUST be treated as an error and security association setup MUST
be aborted. This event SHOULD be auditable. The definition of
"match" is specific to each ID type and is discussed below.
In addition, implementations MUST allow administrators to configure
a local policy that requires that the peer address exist in the
certificate. Implementations SHOULD allow administrators to
configure a local policy that not enforce this requirement.
3.2.2.1.2 Identification Data Not Containing a Single Address
In the case where Identification Data does not contain a single
address, Implementations MUST verify that the Identification Data
contained in the Identification Payload matches identity information
contained in the peer end entity certificate, either in the Subject
Name field or subjectAltName extension. If there is not a match,
this MUST be treated as an error and security association setup MUST
be aborted. This event SHOULD be auditable. The definition of
"match" is specific to each ID type and is discussed below.
3.2.2.2 ID Type
The DOI defines the 11 types of Identification Data that can be used
and specifies the syntax for these types. All of these except for
the ID_KEY_ID type, which is not relevant to this document, are
discussed below.
3.2.2.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 RFC-791 [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, Identity Data MUST contain
exactly four octets. For the ID_IPV6_ADDR type, Identity Data MUST
contain exactly sixteen octets [RFC1883]. When comparing the
Korver Expires - December 2002 [Page 8]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
contents of Identification Data with the iPAddress field in the
subjectAltName extension for equality, binary comparison is
performed.
3.2.2.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 [DNSSEC] is
employed. When comparing the contents of Identification Data with
the dNSName field in the subjectAltName extension for equality,
caseless string comparison is performed. Substring, wildcard, or
regular expression matching MUST NOT be performed.
3.2.2.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 Identification
Data with the rfc822Name field in the subjectAltName extension for
equality, caseless string comparison is performed. Substring,
wildcard, or regular expression matching MUST NOT be performed.
3.2.2.2.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET,
ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE
Implementations MUST NOT use these ID types unless they appear
identically in the end entity certificate. As there is currently no
standard method for putting address subnet or range identity
information into certificates, implementations SHOULD NOT use these
ID types. Use of these ID types is currently undefined.
3.2.2.2.5 ID_DER_ASN1_DN
Implementations MAY support the ID_DER_ASN1_DN ID type, although
implementations SHOULD NOT generate this type. Implementations
which generate this ID type SHOULD populate the contents of Identity
Data 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 is the one that MUST be used to populate
ID Data. In other words, implementations MUST NOT re-encode the DN
Korver Expires - December 2002 [Page 9]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
for the purposes of making it DER if it does not appear in the
certificate as DER. Implementations MUST NOT populate Identity Data
with the Subject Name from the end entity certificate if it is
empty, as described in the "Subject" section of PKIX.
3.2.2.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 making use of
this ID type. Implementations which generate this ID type MUST
populate the contents of Identity Data with the a GeneralName from
the SubjectAltName extension in the end entity certificate, and MUST
do so such that a binary comparison of the two will succeed. For
instance, if the certificate was erroneously created such that the
encoding of the GeneralName varies from the constraints set by DER,
that non-conformant GeneralName is the one that MUST be used to
populate ID Data. In other words, implementations MUST NOT re-
encode the GeneralName for the purposes of making it DER if it does
not appear in the certificate as DER.
3.2.2.2.7 ID_KEY_ID
Type ID_KEY_ID type is not relevant to this document.
3.2.2.3 Local Policy Regarding ID Types
3.2.2.3.1 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,
implementations SHOULD iterate over the identities contained in the
certificate to locate the appropriate policy.
For example, imagine that a host is configured with a certificate
that contains both an IP address (for when the host is on the
corporate LAN) and a "username" (either ID_FQDN or ID_USER_FQDN)
(for when the host is connecting via dialup). Assume also that the
peer will enforce different policies depending on whether the host
is local or remote. Independent of which identity is used to
populate ID, the peer implementation MUST locate the proper policy.
For instance, if the lookup key for the policy in the remote case is
an FQDN but ID contained the IP address identity in the certificate,
the peer will likely use the IP address in ID to find the
certificate, and once the certificate has been validated the FQDN in
the certificate will be used to locate the appropriate policy.
Korver Expires - December 2002 [Page 10]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
Determining which policy is most appropriate in a given context is a
local policy matter and is therefore out of the scope of this
document.
3.2.2.3.2 Opportunistic IPsec
TODO
3.3 Certificate Request Payload
According to ISAKMP:
"The Certificate Request (CERTREQ) Payload provides a means to
request certificates via ISAKMP and can appear in any message.
Certificate Request payloads SHOULD be included in an exchange
whenever an appropriate directory service (e.g. Secure DNS [DNSSEC])
is not available to distribute certificates."
3.3.1 Using a PKI
For the purposes of this section, it is assumed that there exists a
peer certificate chain that has been validated and which is trusted
in the context of the policy being discussed.
3.3.1.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 4
types are relevant:
. X.509 Certificate - Signature
. X.509 Certificate - Key Exchange
. Certificate Revocation List (CRL)
. 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
. Authority Revocation List (ARL)
. SPKI Certificate
Korver Expires - December 2002 [Page 11]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
. X.509 Certificate - Attribute
are out of the scope of this document.
3.3.1.1.1 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.1.1.2 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.1.1.3 Certificate Revocation List (CRL)
This ID type requests that X.509 CRLs be provided, along with any
certificates that may be needed to validate those CRLs.
3.3.1.1.4 PKCS #7 wrapped X.509 certificate
This ID type defines a particular encoding (not a particular
certificate or CRL type), some current implementations may ignore
CERTREQs they receive which contain this ID type, and the authors
are unaware of any implementations that generate such CERTREQ
messages. Therefore, the use of this type is deprecated.
Implementations SHOULD NOT generate CERTREQs that contain this
Certificate Type.
Implementations which receive CERTREQs which contain this ID type
MAY ignore such payloads.
3.3.1.2 Certificate Request Payload Semantics
3.3.1.2.1 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.1.2.2 Empty Certificate Authority Field
If no certificate authority is specified in the Certificate
Korver Expires - December 2002 [Page 12]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
Authority field, ISAKMP states that "no specific certificate
authority [is] requested". The following two sections describe how
to behave when the Certificate Authority field is empty.
3.3.1.2.2.1 Certificate Requests
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, 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, in the case where multiple end entity certificates may be
available, implementations SHOULD resort to local heuristics to
determine which end entity is most appropriate to use. Such
heuristics are out of the scope of this document.
3.3.1.2.2.2 CRL Requests
Implementations MAY generate CERTREQs where the Certificate Type is
"Certificate Revocation List (CRL)" with an empty Certificate
Authority field to signify that the peer should send all CRLs that
are possessed by that peer, whether relevant to the current exchange
or not. Upon receipt of such a CERTREQ, implementations SHOULD send
all CRLs that are possessed but MUST send all CRLs that are relevant
to the current exchange, including the certificates that are needed
to validate those CRLs.
3.3.1.2.3 Specifying Certificate Authorities
Implementations MUST generate CERTREQs for every peer root that
local policy explicitly deems trusted during a given exchange.
Implementations MUST populate the Certificate Authority field with
the Subject Name of the trusted root.
3.3.1.2.3.1 Certificate Requests
Upon receipt of a CERTREQ where the Certificate Type is either
"X.509 Certificate - Signature" or "X.509 Certificate - Key
Exchange", implementations MUST respond by sending each certificate
in the chain from the end entity certificate to the certificate
whose Issuer Name matches the name specified in the Certificate
Authority field. Implementations MAY send other certificates from
the chain.
Korver Expires - December 2002 [Page 13]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
3.3.1.2.3.2 CRL Requests
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 are
needed to validate those CRLs,
3.3.1.2.4 Optimizations
3.3.1.2.4.1 Duplicate Certificate Request Payloads
Implementations SHOULD NOT send duplicate CERTREQs during an
exchange in order to reduce bandwidth usage.
3.3.1.2.4.2 Name Lowest "Common" Certificate Authorities
When a peer's certificate keying materials have been cached, an
implementation can send a hint to the peer to elide some (or all) of
the certificates 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 sufficiently convey all of the information required by
the peer. Specifically, an implementation may not know about all of
the peer chains and therefore will fail to send CERTREQ for all
possible peer chains.
No special processing is required on the part of the recipient of
such a CERTREQ, and the end entity certificates will still be sent.
On the other hand, the recipient MAY elect to elide certificates
based on receipt of such hints.
ISAKMP mandates that CERTREQs contain the Subject Name of a
Certification Authority, which results in the peer always sending at
least the end entity certificate. This mechanism allows
implementations to determine unambiguously when a new certificate is
being used by the peer, perhaps because the previous certificate was
about to expire, which will result in a failure because the needed
keying materials are not available to validate the new end entity
certificate. Implementations which implement this optimization MUST
recognize when the end entity certificate has changed and respond to
it by not performing this optimization when the exchange is retried.
Korver Expires - December 2002 [Page 14]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
3.3.1.2.4.2.1 Example
Imagine that an implementation has previously received and cached
the peer certificate chain R->CA1->CA2->EE. If during a subsequent
exchange this implementation sends a CERTREQ containing the Subject
Name in certificate R, this implementation is requesting that the
peer send at least 3 certificates: CA1, CA2, and EE. On the other
hand, if this implementation also sends a CERTREQ containing the
Subject Name of CA2, the implementation is providing a hint that
only 1 certificate need be sent: EE.
3.3.1.2.5 Robustness
3.3.1.2.5.1 Unrecognized or Unsupported Certificate Types
Implementations MUST be able to deal with receiving CERTREQs with
unrecognized or unsupported Certificate Types. Absent any
recognized and supported CERTREQs, implementations MAY treat them as
if they are of a supported type with the Certificate Authority field
left empty, depending on local policy. ISAKMP section 5.10 Certificate
Request Payload Processing" specifies additional processing.
3.3.1.2.5.2 Undecodable Certificate Authority Fields
Implementations MUST be able to deal with receiving CERTREQs with
undecodable Certificate Authority fields. Implementations MAY treat
such fields as if there were empty, depending on local policy.
ISAKMP specifies other actions which may be taken.
3.3.1.2.5.3 Ordering of Certificate Request Payloads
Implementations MUST NOT assume that CERTREQs are ordered in any
way.
3.3.1.2.6 Leaking Identity Information
Depending on the exchange type, CERTREQs 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 cost of performance).
3.4 Certificate Payload
According to ISAKMP:
"The Certificate (CERT) Payload provides a means to transport
certificates or other certificate-related information via ISAKMP and
can appear in any ISAKMP message. Certificate payloads SHOULD be
Korver Expires - December 2002 [Page 15]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
included in an exchange whenever an appropriate directory service
(e.g. Secure DNS [DNSSEC]) is not available to distribute
certificates. The Certificate payload MUST be accepted at any point
during an exchange."
3.4.1 Using a PKI
For the purposes of this section, it is assumed that there exists a
peer certificate chain that has been validated and which is trusted
in the context of the policy being discussed.
3.4.1.1 Certificate Payloads Not Mandatory
An implementation which does not receive any CERTREQs during an
exchange SHOULD NOT send any CERT payloads, except when explicitly
configured to proactively send CERT payloads in order to
interoperate with non-compliant implementations. In this case, an
implementation MUST send the all certificate chains and CRLs
associated with the end entity certificate. This MUST NOT be the
default behavior of implementations.
Implementations which are configured to expect that a peer must
receive certificates through out-of-band means SHOULD ignore any
CERTREQ messages that are received.
Implementations that receive CERTREQs from a peer which contain only
unrecognized Certification Authorities SHOULD NOT continue the
exchange, in order to avoid unnecessary and potentially expensive
cryptographic processing.
3.4.1.2 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 any of the identities provided by
the peer.
3.4.1.3 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.1.4 Certificate Type
The Certificate Type field identifies to the peer the type of
Korver Expires - December 2002 [Page 16]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
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 5 types
are relevant:
. X.509 Certificate - Signature
. X.509 Certificate - Key Exchange
. Certificate Revocation List (CRL)
. PKCS #7 wrapped X.509 certificate
. Authority Revocation List (ARL) [TBD]
For example, if CRLs are desired, an implementation will populate
the Certificate Type field with the value associated with
"Certificate Revocation List (CRL)", or possibly ARL [TBD].
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.1.4.1 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 signing certificate.
3.4.1.4.2 X.509 Certificate - Key Exchange
This type specifies that Certificate Data contains an end entity
certificate used for either key exchange (or key encipherment).
3.4.1.4.3 Certificate Revocation List (CRL)
This type specifies that Certificate Data contains an X.509 CRL.
3.4.1.4.4 PKCS #7 wrapped X.509 certificate
This type defines a particular encoding, not a particular
certificate or CRL type. Implementations MUST NOT generate CERTs
that contain this Certificate Type. Implementations which violate
this requirement SHOULD note that this is a single certificate
ISAKMP. Implementations MAY accept CERTs that contain this
Certificate type.
Korver Expires - December 2002 [Page 17]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
3.4.1.5 Optimizations
3.4.1.5.1 Duplicate Certificate Payloads
Implementations SHOULD NOT send duplicate CERTs during an exchange
in order to reduce bandwidth usage. Such payloads should be
suppressed.
3.4.1.5.2 Send Lowest "Common" Certificates
When multiple CERTREQs are received which specify certificate
authorities within the end entity certificate chain, implementations
MAY send the shortest chain possible. However, implementations
SHOULD always send the end entity certificate. See section
3.3.1.2.4.2 for more discussion of this optimization.
3.4.1.5.3 Drop Duplicate Certificate Payloads
Implementations MAY employ means to recognize CERTs that have been
received in the past, whether part of the current exchange or not,
for which keying material is available and may discard these
duplicate CERTs.
3.4.1.6 Robustness
3.4.1.6.1 Unrecognized or Unsupported Certificate Types
Implementations MUST be able to deal with receiving CERTs with
unrecognized or unsupported Certificate Types. Implementations MAY
discard such payloads, depending on local policy. ISAKMP section
5.10 "Certificate Request Payload Processing" specifies additional
processing.
3.4.1.6.2 Undecodable Certificate Data Fields
Implementations MUST be able to deal with receiving CERTs with
undecodable Certificate Data fields. Implementations MAY discard
such payloads, depending on local policy. ISAKMP specifies other
actions which may be taken.
3.4.1.6.3 Ordering of Certificate Payloads
Implementations MUST NOT assume that CERTs are ordered in any
way.
3.4.1.6.4 Duplicate Certificate Payloads
Korver Expires - December 2002 [Page 18]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
Implementations MUST support receiving multiple identical CERTs
during an exchange.
3.4.1.6.5 Irrelevant Certificates
Implementations MUST be prepared to receive certificates and CRLs
which are not relevant to the current exchange. Implementations MAY
discard such keying materials.
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.
3.4.2 Leaking Identity Information
Depending on the exchange type, CERTs may be passed in the clear and
therefore may leak identity information.
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. Implementations that conform to this document MAY
therefore reject Version 1 and Version 2 certificates.
4.1.2 Subject Name
4.1.2.1 Empty Subject Name
Implementations MUST accept certificates which contain an empty
Subject Name field, as specified in PKIX. Identity information
in such certificates will be contained entirely in the
SubjectAltName extension.
4.1.2.2 Specifying Hosts in Subject Name
4.1.2.2.1 Non-FQDN Host Names
Korver Expires - December 2002 [Page 19]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
Implementations which desire to place host names that are not FQDNs
(for instance "Gateway Router") in the Subject Name MUST use the
commonName attribute.
4.1.2.2.2 FQDN Host Names
Implementations which desire to place host names that are FQDNs (for
instance "gateway.xythos.com") in the Subject Name field SHOULD use
the commonName attribute type.
Implementations SHOULD NOT populate the Subject Name in place of
populating the dNSName field of the SubjectAltName extension. Host
names that appear in the Subject Name cannot be unambiguously
determined to be a host name.
Note, PKIX defines a domainComponent attribute for representing
FQDNs in DistinguishedNames such as Subject Name. As an alternative
to using commonName, implementations MAY use the domainComponent
attribute type. However, note that support for the domainComponent
attribute is far from universal and many implementations will reject
certificates that contain this attribute.
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 according to this specification. These
extensions are: KeyUsage, SubjectAltName, and BasicConstraints.
Implementations SHOULD generate certificates such that the extension
criticality bits are set in accordance with PKIX and this document.
With respect to PKIX compliance, implementations processing
certificates MAY ignore the criticality bit for extensions that are
supported by that implementation, but MUST support the criticality
bit for extensions that are not supported by that implementation.
4.1.3.1 AuthorityKeyIdentifier
Implementations SHOULD NOT assume that other implementations support
the AuthorityKeyIdentifier extension, and thus should not generate
certificate hierarchies which are overly complex to process in the
absence of this extension (such as those that require possibly
verifying a signature against a large number of similarly named CA
certificates in order to find the CA certificate which contains the
Korver Expires - December 2002 [Page 20]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
key that was used to generate the signature).
4.1.3.2 SubjectKeyIdentifier
Implementations SHOULD NOT assume that other implementations support
the SubjectKeyIdentifier extension, and thus should not generate
certificate hierarchies which are overly complex to process in the
absence of this extension (such as those that require possibly
verifying a signature against a large number of similarly named CA
certificates in order to find the CA certificate which contains the
key that was used to generate the signature).
4.1.3.3 KeyUsage
The meaning of the nonRepudiation bit is undefined in the context of
IPsec. Implementations SHOULD ignore this bit if present.
See PKIX for general guidance on which of the other KeyUsage bits
should be set in any given certificate.
4.1.3.4 PrivateKeyUsagePeriod
PKIX recommends against the use of this extension. The
PrivateKeyUsageExtension is intended to be used when signatures will
need to be verified long past the time when signatures using the
private keypair may be generated. Since ISAKMP SAs are short-lived
relative to the intended use of this extension in addition to the
fact that each signature is validated only a single time, the
meaning of this extension in the context of ISAKMP is unclear.
Therefore, the PrivateKeyUsagePeriod is inappropriate in the context
of ISAKMP and therefore implementations MUST NOT generate
certificates that contain the PrivateKeyUsagePeriod extension.
4.1.3.5 Certificate Policies
Many IPsec implementations do not currently provide support for the
Certificate Policies extension. Therefore, implementations that
generate certificates which contain this extension SHOULD mark the
extension as non-critical.
4.1.3.6 PolicyMappings
Many implementations do not support the PolicyMappings extension.
4.1.3.7 SubjectAltName
4.1.3.7.1 Permitted Choices
Korver Expires - December 2002 [Page 21]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
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
functionality.
4.1.3.7.1.1 dNSName
This field MUST contain a fully qualified domain name.
Implementations MUST NOT generate names that contain wildcards.
Implementations MAY treat certificates that contain wildcards in
this field as syntactically invalid.
Although this field is in the form of an FQDN, implementations
SHOULD NOT assume that the this field contains an FQDN that will
resolve via the DNS, unless this is known by way of some out-of-band
mechanism. Such a mechanism is out of the scope of this document.
Implementations SHOULD NOT treat the failure to resolve as an error.
4.1.3.7.1.2 iPAddress
Note that the CIDR [CIDR] notation permitted in the "Name
Constraints" section of PKIX is explicitly not permitted by that
specification for conveying identity information. In other words,
the CIDR notation MUST NOT be used in the subjectAltName extension.
4.1.3.7.1.3 rfc822Name
Although this field is in the form of an Internet mail address,
implementations SHOULD NOT assume that the this field contains a
valid email address, unless this is known by way of some out-of-band
mechanism. Such a mechanism is out of the scope of this document.
4.1.3.8 IssuerAltName
Implementations SHOULD NOT assume that other implementations support
the IssuerAltName extension, and especially should not assume that
information contained in this extension will be displayed to end
users.
4.1.3.9 SubjectDirectoryAttributes
The SubjectDirectoryAttributes extension is intended to contain
privilege information, in a manner analogous to privileges carried
in Attribute Certificates. Implementations MAY ignore this
extension as PKIX mandates it be marked non-critical.
Korver Expires - December 2002 [Page 22]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
4.1.3.10 BasicConstraints
PKIX mandates that CA certificates contain this extension and that
it be marked critical. For backwards compatibility, implementations
SHOULD accept CA certificates that do not contain this extension or
that contain this extension marked non-critical.
4.1.3.11 NameConstraints
Many implementations do not support the NameConstraints extension.
Since PKIX mandates that this extension be marked critical when
present, implementations which intend to be maximally interoperable
SHOULD NOT generate certificates which contain this extension.
4.1.3.12 PolicyConstraints
Many implementations do not support the PolicyConstraints extension.
Since PKIX mandates that this extension be marked critical when
present, implementations which intend to be maximally interoperable
SHOULD NOT generate certificates which contain this extension.
4.1.3.13 ExtendedKeyUsage
No ExtendedKeyUsage usages are defined for IPsec, so if this
extension is present and marked critical, use of this certificate
for IPsec MUST be treated as an error. Implementations MUST NOT
generate this extension in certificates which are being used for
IPsec.
4.1.3.14 CRLDistributionPoint
Most implementations expect to exchange CRLs in band via the ISAKMP
Certificate Payload. Implementations MUST NOT assume that the
CRLDistributionPoint extension will exist in peer extensions and
therefore implementations SHOULD request that peers send CRLs in the
absence of knowledge that this extension exists in the peer
certificates.
4.1.3.15 InhibitAnyPolicy
Many implementations do not support the InhibitAnyPolicy extension.
Since PKIX mandates that this extension be marked critical when
present, implementations which intend to be maximally interoperable
SHOULD NOT generate certificates which contain this extension.
4.1.3.16 FreshestCRL
Korver Expires - December 2002 [Page 23]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
Most implementations expect to exchange CRLs in band via the ISAKMP
Certificate Payload. Implementations MUST NOT assume that the
FreshestCRL extension will exist in peer extensions and therefore
implementations SHOULD request that peers send CRLs in the absence
knowledge that this extension exists in the peer certificates.
4.1.3.17 AuthorityInfoAccess
PKIX defines the AuthorityInfoAccess extension, which is used to
"how to access CA information and services for the issuer of the
certificate in which the extension appears." This extension has no
known use in the context of IPsec. Conformant implementations
SHOULD ignore this extension when present.
4.1.3.18 SubjectInfoAccess
PKIX defines the SubjectInfoAccess private certificate extension,
which is used to indicate "how to access information and services
for the subject of the certificate in which the extension appears."
This extension has no known use in the context of IPsec. Conformant
implementations SHOULD ignore this extension when present.
4.2 X.509 Certificate Revocation Lists
Implementations SHOULD send CRLs, unless non-CRL certificate
revocation information is known to be preferred by all interested
parties in the application environment that the implementation is
used. Implementations MUST send CRLs if non-CRL certificate
revocation information may not be available to all interested
parties.
4.2.1 Certificate Revocation Requirement
Implementations which validate certificates MUST make use of
certificate revocation information, and SHOULD support such
revocation information in the form of CRLs, unless non-CRL
revocation information is known to be the only method for
transmitting this information.
4.2.2 Multiple Sources of Certificate Revocation Information
Implementations which support multiple sources of obtaining
certificate revocation information MUST act conservatively when the
information provided by these sources is inconsistent: when a
certificate is reported as revoked by one source, the certificate
MUST be considered revoked.
Korver Expires - December 2002 [Page 24]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
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 are overly complex to process in the
absence of this extension (such as those that require possibly
verifying a signature against a large number of similarly named CA
certificates in order to find the CA certificate which contains the
key that was used to generate the signature).
4.2.3.2 IssuerAltName
Implementations SHOULD NOT assume that other implementations support
the IssuerAltName extension, and especially should not assume that
information contained in this extension will be displayed to end
users.
4.2.3.3 CRLNumber
As stated in PKIX, all issuers conforming to PKIX MUST include this
extension in all CRLs.
4.2.3.4 DeltaCRLIndicator
4.2.3.4.1 If Delta CRLs Are Unsupported
Implementations that do not support delta CRLs MUST reject CRLs
which contain the DeltaCRLIndicator (which MUST be marked critical
according to PKIX) and MUST make use of a base CRL if it is
available. Such implementations MUST ensure that a delta CRL does
not "overwrite" a base CRL, for instance in the keying material
database.
4.2.3.4.2 Delta CRL Recommendations
Since some implementations that do not support delta CRLs may behave
incorrectly or insecurely when presented with delta CRLs,
implementations SHOULD consider whether issuing delta CRLs increases
security before issuing such CRLs.
The authors are aware of several implementations which behave in an
incorrect or insecure manner when presented with delta CRLs. See
Appendix B for a description of the issue. Therefore, this
specification RECOMMENDS against issuing delta CRLs at this time.
On the other hand, failure to issue delta CRLs exposes a larger
window of vulnerability. See the Security Considerations section of
PKIX for additional discussion. Implementors as well as
administrators are encouraged to consider these issues.
Korver Expires - December 2002 [Page 25]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
4.2.3.5 IssuingDistributionPoint
TODO
4.2.3.6 FreshestCRL
Given the recommendations against implementations generating delta
CRLs, this specification RECOMMENDS that implementations do not
populate CRLs with the FreshestCRL extension, which is used to
obtain delta CRLs.
5. Configuration Data Exchange Conventions
Below we present a common format for exchanging configuration data.
Implementations MUST support these formats, MUST support arbitrary
whitespace at the start and end of any line, and MUST support all
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
exact same form as above. A raw key is only the
SubjectPublicKeyInfo portion of the certificate, and should be
Base64 encoded and appear between the following delimiters:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
6. IKE
6.1 IKE Phase 1 Authenticated With Signatures
6.1.1 Identification Payload
Implementations SHOULD populate Identification Data with identity
Korver Expires - December 2002 [Page 26]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
information that is contained within the end entity certificate.
This enables recipients to use the Identification Data as a lookup
key to find the peer end entity certificate. The only case where
implementations MAY populate the Identification Data with
information that is not contained in the end entity certificate is
when the Identification Data contains the peer address (a single
address, not a subnet or range). This means that implementations
MUST be able to map a peer address to a peer end entity certificate.
The exact method for performing this mapping is out of the scope of
this document. See Appendix C for an example of how this mapping
might be implemented.
6.1.1.1 When the Identification Payload is Mandatory
IKE mandates the use of the ID payload in Phase 1.
6.1.1.2 Leaking Identity Information
6.1.1.2.1 IKE Aggressive Mode
The contents of ID are not encrypted in Aggressive Mode when
authentication is performed with signatures. In some environments
this may leak private information. The solutions to this problem if
such a leak is unacceptable are:
(1) Use Main Mode instead of Aggressive Mode.
(2) Populate ID Data with the address of the host.
6.1.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.1.3 Certificate Payload
6.1.3.1 Leaking Identity Information
6.1.3.1.1 IKE Main Mode
Implementations may not wish to respond with CERTs in the second
message, thereby violating the identity protection feature of Main
Mode IKE. ISAKMP allows CERTs to be included in any message, and
Korver Expires - December 2002 [Page 27]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
therefore implementations may wish to respond with CERTs in a
message that offers privacy protection in this case.
6.1.3.1.2 IKE Aggressive Mode
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 solution to this problem if
such a leak is unacceptable is to use Main Mode instead of
Aggressive Mode.
6.1.4 X.509 Certificate Extensions
6.1.4.1 KeyUsage
If the KeyUsage extension is present in an end entity certificate,
the digitalSignature bit must be asserted.
6.2 IKE Phase 1 Authenticated With Public Key Encryption
6.2.1 Identification Payload
6.2.1.1 Without Certificates
If certificates are not being used, the contents of Identification
Data in this case are out of scope for this document.
6.2.1.2 With Certificates
No additional requirements exist.
6.2.1.3 When the Identification Payload is Mandatory
IKE mandates the use of the ID payload in Phase 1.
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 will use for
encrypting payloads during the exchange.
Implementations SHOULD include this payload whenever the public
portion of the keypair has been placed in a certificate.
Korver Expires - December 2002 [Page 28]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
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.
6.3 IKE Phase 1 Authenticated With a Revised Mode of Public Key
Encryption
IKE Phase 1 Authenticated With a Revised Mode of Public Key
Encryption has the same requirements as IKE Phase 1 Authenticated
With Public Key Encryption. See section 6.2 for these requirements.
Intellectual Property Rights
No new intellectual property rights are introduced by this document.
Security Considerations
Using Peer IP Address to Bind Identity to Policy
In some environments, the peer address is more resistant to spoofing
than will be the identity contents of certificates, and thus may be
more trustworthy than the contents of certificates. In other
environments, the opposite may be true. Implementations may want to
consider their deployment environments when considering local
Identity Payload policy, although such considerations are
environment-specific and thus out of scope of this document. See
section 3.2.1.1.1 for more background.
Cleartext ID, CERT, or CERTREQ Payloads
Depending on the exchange, the contents of ID, CERT, or CERTREQ may
be passed in the clear. This document provides suggestions for
avoiding such leaks.
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 Protocol Security
Extensions", RFC 2535, March 1999.
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
Korver Expires - December 2002 [Page 29]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
[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.
[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.
[RFC1883] Deering, S. and Hinden, R. "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap",
draft-ietf-pkix-roadmap-08.txt
Korver Expires - December 2002 [Page 30]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
Acknowledgments
The authors would like to acknowledge the expired draft-ietf-ipsec-
pki-req-05.txt for providing valuable materials for this document.
Author's Addresses
Brian Korver
Xythos Software, Inc.
25 Maiden Lane, 6th Floor
San Francisco, CA 94108
USA
Phone: +1 415 248-3800
EMail: briank@xythos.com
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
USA
Phone: +1 650 320-8549
EMail: ekr@rtfm.com
Korver Expires - December 2002 [Page 31]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
A. Change History
June 2002, Initial Draft
B. The Possible Dangers of Delta CRLs
The problem is that the CRL processing algorithm is often written
with the assumption that all CRLs are base CRLs and it is assumed
that CRLs will pass content validity tests. Specifically, such
implementations fail to check the certificate against all possible
CRLs: if the first CRL that is obtained from the keying material
database fails to decode, no further revocation checks are performed
for the relevant certificate. This problem is compounded by the
fact that implementations which do not understand delta CRLs will
fail to decode such CRLs due to the critical DeltaCRLIndicator
extension. The insecure algorithm that is implemented in this case
is approximately:
Korver Expires - December 2002 [Page 32]
The IP Security PKI Profile of ISAKMP and PKIX June 2002
fetch newest CRL
check validity of CRL signature
if CRL signature is invalid then
if CRL is contains unrecognized critical extensions then
if certificate is on CRL then
set certificate status to revoked
when the algorithm should be approximately:
fetch all up-to-date CRLs
set CRLchecked status to false
for each CRL
check validity of CRL
if CRL is valid then
set CRLchecked status to true
if certificate is on CRL then
set certificate status to revoked
goto done
done:
if CRLchecked status is false
not valid CRL failure
The authors note that a number of PKI toolkits do not even provide a
method for obtaining anything but the newest CRL, which in the
presence of delta CRLs may in fact be a delta CRL, not a base CRL.
C. Mapping A Peer Address to a Peer Certificate
TODO
Korver Expires - December 2002 [Page 33]
