[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Internet Draft                                          Rodney Thayer
draft-ietf-ipsec-pki-req-05.txt                Charles Kunzinger, IBM
July 10, 2000                                      Paul Hoffman, VPNC
Expires in six months

                     A PKIX Profile for IKE

Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."

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.

Abstract

The IKE protocol allows the use of the PKIX profile of X.509v3
certificates for encryption and authentication. Common practice in the
IPsec community differs in some ways from these specifications made in
the PKIX format specification and other specifications that have come
from the PKIX WG. In order to promote interoperability in the IPsec
market, this document lays out a profile for using PKIX in IKE.

1. Introduction

Implementors of IKE [RFC-2409] who use public key certificates have
almost universally used PKIX certificates and certificate processing,
as described in the PKIX certificate profile [RFC-2459], often called
"PKIX Part 1". However, many implementors have not adhered completely
to the PKIX certificate profile specification for a variety of reasons.
Note that many IPsec implementors are not completely happy with the
PKIX documents and procedures, but have agreed to use the PKIX
protocols because they are supported in other contexts and have a
significant market share.

This document is a profile for the PKIX certificate profile and other
PKI-related documents. IKE Implementors should follow all requirements
and suggestions in those documents except where this document
specifies differently.

This document is a profile of the PKIX certificate profile and the PKIX
roadmap [ROADMAP]. Material from those two documents is not repeated
here, and readers of this document are assumed to have read and fully
understood both documents. All security aspects of those documents are
fully relevant to this one.

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

All PKI terms used in this document are defined either in the PKIX
certificate profile or the PKIX roadmap [ROADMAP]. For terms where the
two documents differ, the definition in the PKIX roadmap is used. In
particular, this document follows the PKIX roadmap's use of the term
"root CA", meaning "a CA that is directly trusted by an end entity;
that is, securely acquiring the value of a root CA public key requires
some out-of-band step(s)".

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

2. Certificate Validation and Revocation Checking

As described in the PKIX certificate profile, in certificate path
validation for a path whose length is longer than 2, the relying party
needs to check the validity of the certificates of subordinate CAs. An
IKE system that conforms to this profile MAY get the certificates of
subordinate CAs during the IKE exchanges, or MAY get those certificates
through other methods, such as through a local certificate cache or
from a directory.

IKE systems conforming to this profile MUST support a signing hierarchy
containing at least seven subordinate CAs between an end entity and a
root CA. This means that a certificate chain might have nine
certificates in it (the end-entity certificate, seven intermediate CAs,
and the trusted root certificate).

IKE systems conforming to this profile MUST check the revocation status
of any certificate on which they rely, as described in
the PKIX certificate profile. Thus, every conforming IKE system MUST
have a method for receiving up-to-date revocation information for the
certificates it is validating.

An IKE system that conforms to this profile that learns that a
certificate that was used in association with the creation of an
existing security association becomes invalid for any reason MUST
delete the corresponding IKE and IPsec security associations. A
conforming IKE system SHOULD periodically check for revocation
information such as CRLs and OCSP responses.

3. Certificate Format

This profile modifies the use of two fields specified in the
PKIX certificate profile.

3.1 The extendedKeyUsage field

In a certificate for an IPsec end entity, the extendedKeyUsage field
(commonly called "EKU") MAY be present. If it is present, the field
SHOULD contain the object identifier iKEIntermediate
(iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or
1.3.6.1.5.5.8.2.2).

Note that this field is not given in the PKIX certificate profile. In
fact, the PKIX certificate profile lists three object identifiers for
IPsec devices: id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-
ipsecUser. These object identifiers never achieved any significant use
in the IPsec community; they SHOULD NOT be used.

3.2 The subjectAltName field

The subjectAltName field MAY be checked for identification of the
device. It is explicitly valid for an IKE system that conforms to this
profile to reject an end entity certificate whose identification fails
any of the following tests.

- If a name is the subjectAltName is an IP address, the IKE system MAY
  confirm that the IP address is valid for the IKE negotiation process.

- If a name is a domain name, the IKE system MAY find the A record in
  the DNS that matches that domain name and MAY confirm that the IP
  address is valid for the IKE negotiation process.

[[[ Should there be some discussion here about comparing the identification
in the cert with the ID payload? If so, what should it say? ]]]

4. Extending the Validity Field to SAs

The notAfter field of the validity field specifies the date after which
the certificate is always considered invalid. An IKE implementation MUST
examine the notAfter date in conjunction with all relevant SA lifetimes
(both IKE SA and IPsec SA's) at the date the certificate is used to
authenticate creation of an SA. If the SA would definitely expire after
the end of the certificate lifetime, then either:

- the SA SHOULD NOT be created at all

- the SA SHOULD be created but the lifetime of the SA SHOULD match the
  certificate lifetime

5. Algorithm Requirements

IKE systems that conform to this profile SHOULD support DSA-with-SHA1
signatures and RSA-with-SHA1 signatures on certificates (as expressed
by the signatureAlgorithm in the certificate). The OIDs associated with
these algorithms are id-dsa-with-sha1 and sha-1WithRSAEncryption,
respectively.

1024-bit keys MUST be supported for each signature algorithm supported,
and longer keys SHOULD be supported.

6. ISAKMP Certificate and Certificate Request Payloads

The steps in this section use sequential numbering of IKE messages as
shown in Sections 5.1-5.5 of [RFC 2409].  The first message sent by the
IKE initiator is numbered 1, the response sent by the IKE responder is
numbered 2, the next message from the Initiator is numbered 3, and so
on.

6.1 Signature-based authentication

End entity certificates contain identity information about the
certificate's owner. Thus, some systems will want to only transmit
their certificates in the protected messages of the IKE exchange. Other
systems will not find such protection needed, such as if the identity
is the IP address or domain name of the device owning the certificate.

Certificate requests may reveal information about the system making the
request. For instance, a certificate request that names a particular
root CA could help identify that the system requesting the certificate
is part of a particular security realm. However, most IKE systems have
not to date shown much care about revealing the names of the roots they
trust.

In order to protect the identity in a Certificate payload, the IKE
device that wishes to deliver its own certificates to its peer MUST use
Main Mode MUST only include Certificate payloads in message 5 or 6.
Devices not concerned with protecting the identity in a Certificate
payload MAY put that payload in any IKE message in either Main Mode or
Aggressive Mode. Devices receiving certificate payloads MUST store them
for use during further messages in the same IKE exchange, and MAY store
them for longer-term use, such as for future IKE exchanges.

In order to protect the information in a Certificate Request payload,
the IKE initiator that wishes to request a certificate MUST use Main
Mode and MUST send the Certificate Request payload in message 5. IKE
responders cannot protect Certificate Request payloads. Devices not
concerned with protecting the information in a Certificate Request
payload can include those payloads in messages 1 through 5 in Main
Mode, or in messages 1 and 2 in Aggressive Mode.

6.2 Encryption-based authentication

In Main Mode with encryption-based authentication, Certificate Request
payloads, if they are to be included anywhere, SHOULD appear only in
messages 1 and 2 because that is the only place where they are useful
for the exchange. Certificate Request payloads SHOULD NOT appear in
Aggressive Mode encryption-based authentication because they are never
useful.

In Main Mode with encryption-based authentication, Certificate payloads
SHOULD only appear in messages 1, 2, and 3 because that is the only
place where they are useful for the exchange; note that the
certificates in these messages are not encrypted and will thus reveal
identity information. In Aggressive Mode with encryption-based
authentication, Certificate payloads SHOULD only appear in message 1.

6.3 Certificate requests that yield no results

If a Certificate Request payload is received for a certificate or CRL
that the responder does not have, the responder SHOULD silently ignore
the request. The responder SHOULD NOT send a notify payload in response
to a Certificate Request that could not be fulfilled.

[[[Note: the previous version said "If a responding device is not
offering a certificate that will chain to the certificate authority
named in the Certificate Request payload, the Certificate payload
offered in response to a Certificate Request payload MUST specify a
certificate encoding of type NONE." However, there was general
agreement to delete this and replace it with the text above.]]]

6.4 Responding with multiple certificates

Some requests might cause the responder to send multiple certificates
as a response. Note that such responses may exceed the size of a single
UDP packet. However, if the requestor needs (or the responder believes
that the requestor needs) multiple certificates, such a response is
probably worthwhile.

Under this profile, a request for certificate type 1 (PKCS #7)
indicates that the requestor wants the responder to send a chain of
certificates, while a request for certificate type 4 or 5 (X.509
certificates) indicates that the requestor only wants an end entity
cert.

If a Certificate Request payload specifies a certificate type of 1
(PKCS #7), and the responder has a certificate that is not directly
signed by the root named in the certificate request but is singed by CA
in a chain that ends in the named root, the responder SHOULD send back
a single Certificate payload of type 1 that contains multiple
certificates: one for the end entity certificate, and one for each
intermediate certificate in the chain (not including the certificate
for the root).

If a Certificate Request payload specifies a certificate type of 4 or
5, and the responder has a certificate that is not directly signed by
the root named in the certificate request but is singed by CA in a
chain that ends in the named root, the responder SHOULD send back the
single end entity certificate and SHOULD NOT send back intermediate
certificate in the chain.

If a Certificate Request payload specifies a certificate type of 7
(CRL), and in the same message there is a Certificate Request payload
that specifies a certificate type of 1 (PKCS #7), the responder MAY
include the CRL in the PKCS #7 it returns.

6.5 Requests without certificate authority fields

The meaning of Certificate Request payloads that do not include
certificate authority fields is not well specified in [RFC-2408]. For
this profile, the following interpretations are given:

- For certificate type 2, 4, and 5, this means "return a single
  certificate that might chain to a root that you somehow believe I
  trust"

- For certificate type 1, this means "return one or more certificates
  that might chain to a root that you somehow believe I trust in a
  single payload"

- For certificate type 7, if the same message included a Certificate
  Request payload of type 1, 2, 4, or 5, this means "please also return
  any CRLs you have for the certificates you are returning for the
  other request".

- For certificate type 7, if the same message did not include a
  Certificate Request payload of type 1, 2, 4, or 5, this has no
  meaning. Such requests SHOULD NOT be made.

6.6 Indicating validation failure

If certificate validation fails for any reason, the responder SHOULD
return an unprotected notify payload. The notify message SHOULD include
a notify message type of 17, 18, 19, 20, 21, 22, 23, 24, or 25, as
described in section 3.14.1 of [RFC-2408].

6.7     Matching ID payloads with certificate subjects

An IKE implementation that conforms to this profile MUST NOT use an end
entity certificate received from an IKE peer for purposes of completing
the IKE authentication process unless there is a match in both content
and format between the ID payload (IDii or IDir) offered by the peer in
the IKE negotiation and at least one of the name forms carried in
either the subject or subjectAltName fields in the certificate
received.

7. Obtaining a Certificate for a Device

This specification explicitly does not mandate the use of any
particular certificate enrollment mechanism for IKE systems.

The process of a device presenting a CA with a public key and
identification, and then receiving a certificate from that CA for the
combination of the public key and identification, is often called
"enrollment" and "fulfillment". Unfortunately, the PKI world has had
little agreement on enrollment protocols.

The PKIX Working Group has standardized one mechanism, CMP [RFC-2510],
and has recently asked that a second, incompatible mechanism, CMC
[CMC], be standardized as well. In addition to CMP and CMC, there are
at least two other non-IETF protocols that have been used by a number
of IPsec vendors and CAs.

The IPsec market has coalesced around one method of enrollment that is
not fully defined anywhere other than this document. That method can be
called "PKCS10 plus out of band" or "P10POUB", described below. All
IKE systems that need to obtain a certificate for the public key MAY
do P10POUB, and MAY do CMP and/or CMC in the near future.

After receiving the PKCS #10 request, the CA creates a certificate and
makes it available to the requestor either as a PKCS #7 response or
as a bare certificate.

7.1 Enrollment requests with PKCS10 plus out of band information

The steps an end-entity uses in P10POUB are:

1. Obtain a key pair.

2. Create a PKCS #10 [RFC-2314] object that includes the public key
   portion of the key pair. This object MUST NOT use any PKCS #10
   extensions.

3. Determine the subjectAltName information desired for the
   certificate.

4. Transmit the PKCS #10 object, the desired subjectAltName, and
   any desired extensions to the CA.

The last step may be performed in many ways. One common method is a web
form where the Base64 [RFC-2045] transformation of the PKCS #10 object
is pasted into a text-entry field and the subjectAltName and the fact
that the desired certificate is for IPsec is specified with a variety
of form controls. A second common method is email message that is
manually processed by the CA.

Note that the CA may ask the person enrolling for the SHA-1 hash
of the PKCS10. This check helps prevent a man-in-the-middle from
replacing the person's PKCS #10 request with a fake one and
tricking the CA into issuing a certificate.

Devices enrolling with P10POUB over email MUST include the
subjectAltName in the message. The public key SHOULD be included in the
message as the Base64 transformation of the PKCS #10 object. That
Base64 object SHOULD be preceded with either the line:

-----BEGIN CERTIFICATE-----

or the line:

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

and should be followed by the line:

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

or the line:

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

This latter mechanism is somewhat similar to the certificate request
mechanism from PEM [RFC-1421].

The CA's response to a successful creation of a certificate using
P10POUB MAY be any of the following:

- A PKCS #7 object holding the certificate
- The Base64 encoding of a PKCS #7 object holding the certificate
- The bare certificate
- The Base64 encoding of the bare certificate

[[[ OK, folks, that really doesn't help on interoperability. Should
we pick one of those four as a SHOULD? ]]]

8. Acknowledgements

This document was based on discussions with various IPsec implementers
and PKI service providers, as well as other members of the IETF
community.  It also benefits from the spirit of interoperability
exhibited by participants in the various IPsec bakeoff events.

9. Security Considerations

All security considerations from the PKIX certificate profile and
the PKIX roadmap are relevant here.

Identifiers in certificates such as IP addresses or FQDN's should be
checked for consistency with other information about the security
associations being formed.

IKE Main Mode attempts to preserve identity protection by only sending
ID payloads in messages 5 and 6, which are encrypted. Sending
certificates in unencrypted IKE Main Mode messages (1 through 4) will
reveal the identity of the sender. Note that sending certificates in
Main Mode for encryption-based authentication by its very nature will
expose the identity of the sender.

10. References

[CMC] Myers, M., et. al., "Certificate Management Messages over CMS",
draft-ietf-pkix-cmc-xx.txt. (Awaiting the RFC Editor)

[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures", February
1993.

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

[RFC-2045] Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
November 1996.

[RFC-2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version
1.5", March 1998.

[RFC-2408]  Maughan, D., et. al., "Internet Security Association and
Key Management Protocol (ISAKMP)", November, 1998.

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

[RFC-2459] Housley, R., et. al., "Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", January 1999.

[RFC-2510] Adams, C. and Farrell, S., "Internet X.509 Public Key
Infrastructure Certificate Management Protocols", March 1999.

[ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap",
draft-ietf-pkix-roadmap-xx.txt.

A. Change History

Some of the requirements from this draft come from other related drafts
in the IPsec WG. Many people have contributed to those drafts
and this one.

The differences between the -04 and -05 drafts were:

1. Added second paragraph to make it clear that implementors need
to follow other documents as well.

2. Rearranged a bit to put validation before revocation,
and changed the title of the section.

3.1 Changed this significantly because no one was requiring
its use for interoperability. Relaxed all requirements
(and even eliminated some).

3.2 Added open question at the end.

4. Changed "time" to "date" to match the PKIX usage.

5. Clarified what the signatures were for, added the SHA1 part, and
added OIDs. Removed "or equivalent" for the key sizes, and added note
about longer lengths.

6. Changed this whole section based on comments from the list. Split
the information out into separate sub-parts.

7. Moved Appendix A to section 7.

7. (A.) Added "Note that P10POUB using PKCS7 responses is one mode of
CMC." Described the reply from the CA being either a PKCS7 or a bare
cert based on the results from the San Diego bakeoff. Removed the last
paragraph about CAs MUST NOT issue certs with different subject or
altNames.

7.1 (A.1) Changed step 4. Added the response stuff and the open
question at the end of the section.

B. Authors' Addresses

Rodney Thayer
rodney@tillerman.to

Charles A. Kunzinger
IBM
kunzinge@us.ibm.com

Paul Hoffman
VPN Consortium
paul.hoffman@vpnc.org


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/