Internet Draft                                        Rodney Thayer, SSH
draft-ietf-ipsec-pki-req-04.txt                   Charles Kunzinger, IBM
December 14, 1999                                      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.

. 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 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)". (It is noted that the fact that the two
documents differ does not give great confidence to the IPsec community
or other users of the PKIX protocols.)

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

. Certificate Revocation

IKE systems conforming to this profile MUST check the revocation status
of any certificate on which they rely, using the algorithm 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.

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

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.

. 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") MUST be present and MUST contain only the
object identifier iKEIntermediate
(iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or
1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD
NOT accept end-entity certificates that do not follow this rule.

Note that this requirement 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 MUST NOT be used and are
deprecated in this profile.

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.

. 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 time in conjunction with all relevant SA lifetimes
(both IKE SA and IPsec SA's) at the time 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

. Algorithm Requirements

IKE systems that conform to this profile SHOULD support DSA signatures
and RSA signatures. 1024-bit keys or the equivalent MUST be supported
for each signature algorithm supported.

. 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

When the IKE messages are authenticated using either RSA Signatures or
DSS Signatures, the following rules apply. These rules specify exactly
where Certificate and Certificate Request payloads may and may not
appear in messages. Note that [RFC-2408] requires that Certificate and
Certificate Request payloads MUST be accepted in any ISAKMP message;
that doesn't mean that they must be processed if they appear. This
section describes the messages in which these payloads MUST appear in
order to be processed by the receiving IKE system.

- In Main Mode, an IKE initiator MUST include Certificate Request
payloads only in Message 5 if they are to be included anywhere in the
IKE negotiation. An IKE responder MUST include them only in Message 4
if they are to be included anywhere in the IKE negotiation. Certificate
Request payloads appearing in other messages MAY be ignored by the
party receiving them.

- In Aggressive Mode, an IKE Initiator MUST include Certificate Request
payloads only in Message 1 if they are to be included anywhere in the
IKE negotiation. An IKE Responder MUST include them in Message 2 if
they are to be included anywhere in the IKE negotiation.

- In Main Mode, an IKE device that wishes to deliver its own
certificates to its peer without having been previously received a
Certificate Request payload from the peer MUST deliver the Certificate
payloads only in Message 5 if it is the IKE initiator, or only in
Message 6 if it is the IKE responder. Certificate payloads in other
messages MAY be ignored by the party receiving them.

- In Aggressive Mode, an IKE device that wishes to deliver its own
certificates to its peer without having been previously received a
Certificate Request payload from the peer MUST deliver the Certificate
payloads only in Message 3 if it is the IKE initiator, or only in
Message 2 if it is the IKE responder.

6.2 Encryption-based authentication

In Main Mode with encryption-based authentication, Certificate Request
payloads, if they are to be included anywhere, MUST appear only in
messages 1 and 2. Certificate Request payloads MUST NOT appear in
Aggressive Mode encryption-based authentication.

In Main Mode with encryption-based authentication, Certificate payloads
MUST only appear in messages 1, 2, and 3; 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 MUST only appear in message 1.

6.3 Content of Certificate payloads

If a responding device is offering a certificate that will chain to the
certificate authority named in the Certificate Request payload, and
there are intermediate certificates in the chain, the responding device
SHOULD include the intermediate certificates in Certificate payloads in
the response.

[[[Editorial note: we might want to downgrade this to a MAY. Including
a bunch of certs in a UDP transmission greatly increases the chances of
a blown exchange due to dropped packets, particularly because a typical
cert is 5-10 packets long. Of course, not including intermediate certs
means that the sender assumes the recipient has them all, which can't
be determined easily.]]]

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.

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

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

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

. References

[CMC] Myers, M., et. al., "Certificate Management Messages over CMS",
draft-ietf-pkix-cmc-xx.txt. (Has finished WG Last Call and is
currently awaiting IETF Last Call.)

[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures", RFC-1421,
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. 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.

Regardless of the protocol used, a CA who gets an IKE system's
enrollment request that includes the subject and subjectAltName desired
for the device MUST include exactly the same subject and subjectAltName
in the certificate. If the CA does not want to issue a certificate with
the same subject and subjectAltName that was requested, the CA MUST NOT
issue a certificate with a different name and subjectAltName.

A.1 Enrollment requests with PKCS10 plus out of band information

The steps an end-entity uses in P10POUB are:

. Obtain a key pair.

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

. Determine the subjectAltName information desired for the
   certificate.

. Transmit the PKCS #10 object, the desired subjectAltName, and the
   fact that this is an IPsec certificate 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.

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

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

B.1 Differences between the -03 and -04 drafts

. Spelled out the definition of a root CA from the PKIX roadmap.

. Clarified the wording on number of intermediate CAs. Clarified that
it's both IKE and IPsec SAs that need to be taken down if certs are
revoked.

3.2. Removed the first paragraph, which disagreed with PKIX.
Also removed the prohibition on Ipv6 and subnetwork address,
which also disagreed with PKIX. Also removed the last paragraph,
which disagreed with PKIX.

. Added this entire section, and therefore renumbered the current
6-9 to 7-10.

. Added new third paragraph to the security considerations.

C. Authors' Addresses

Rodney Thayer
Rodney@tillerman.to

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

Paul Hoffman
VPN Consortium
 Segre Place
Santa Cruz, CA  95060
paul.hoffman@vpnc.org