Internet DRAFT - draft-hoffman-pki4ipsec-profile

draft-hoffman-pki4ipsec-profile



Internet Draft                                          Paul Hoffman
draft-hoffman-pki4ipsec-profile-00.txt                VPN Consortium
December 18, 2003
Expires in six months
Intended status: Informational

              Profile for Certificate Use in IKE version 1

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 use of certificates for authenticating the creation of IPsec
security associations has long been fraught with difficulty. The
specifications in IKE version 1 are sometimes ambiguous about important
issues, and developers of IPsec systems are often unprepared to deal
with the complexities of PKIX certificates and certificate handling.
This document is a profile of certificate use in IPsec whose primary
goal is to greatly increase interoperability while maintaining high
security.


1. Introduction

The most common method for setting up IPsec security associations is to
use the Internet Key Exchange versions 1 [IKEv1]. IKE specifies many
ways to authenticate the two parties in a security association, some of
which use digital certificates. This document profiles one such use of
digital certificates.

The primary purpose of this profile is to greatly increase
interoperability among developers of IPsec systems. This profile greatly
narrows the number of choices that a developer has for certificate
format and how public key information is exchanged in IKE. At the same
time, this profile uses options that are considered to be strong enough
for typical IPsec usage.

In order for two parties to use this profile, both parties MUST have at
least one certificate authority whom they both fully trust to issue
certificates that associate one or more identities with public keys.

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


2. Certificate contents

All certificates used in this profile MUST be PKIX [PKIX] certificates.
All certificates send and received by either party in the IKE
negotiation MUST follow the content rules described in this section.

2.1 Identities in the Name and SubjectAltName fields for end entities

The first thing to acknowledge when dealing with PKIX certificates is
that the PKIX rules for naming the parties is a mess. The PKIX rules
evolved from the naming rules for X.500 and LDAP directories, and were
not originally designed for Internet identities.

The Subject field in all end entity certificates SHOULD be null. The
identity in the Subject field of end entity certificates MUST NOT be use
by either party for identification. The SubjectAltName field MUST have
at least one identity in it. At least one identity in the SubjectAltName
field of a certificate MUST be either an iPAddress (an IPv4 IP address),
an rfc822Name (an email address), or a dNSName (a fully-qualified domain
name).

An end entity certificate MAY have multiple identities and types of
identities within the subjectAltName field. For example, it is valid to
have a certificate that has DNS names, it is valid to have a certificate
that has a DNS name and an email address, and it is valid to have a
certificate that as two IP addresses and a DNS name. IKE implementations
MUST be able to find all the identities in end entity certificate that
have multiple identities and types of identities within the
subjectAltName field.

2.2 KeyUsage and ExtendedKeyUsage fields for end entities

There is no threat model in IKE that requires a system to demand
particular values in the KeyUsage and ExtendedKeyUsage fields of an end
entity certificate. Certificates SHOULD have the digitalSignature bit in
the KeyUsage field turned on, but authenticating parties SHOULD NOT
reject a certificate if that bit is not asserted. Both parties SHOULD
ignore the values in the KeyUsage and ExtendedKeyUsage fields.

2.3 Cryptographic algorithms

All certificates (trust anchors, intermediate CAs, and end entities)
MUST use sha-1WithRSAEncryption signature algorithm with RSA keys. All
RSA keys SHOULD be 1024 bits or longer.

2.4 Critical extensions

Certificates used in this profile SHOULD NOT have any critical
extensions except those that are listed in [PKIX] as being mandatory to
be marked as critical.

2.5 Matching identities with systems

Identities in certificates are often misunderstood. In most cases, the
issuer of a certificate believed that, at the time the certificate was
issued, that the identity in the certificate is associated with the
entity that controlled the private key that is paired with the public
key in the certificate. For example, a certificate that has an identity
of an IP address often indicates that, at the time the certificate was
issued, the certificate authority believes that the IP address is that
of the system that managed the private key that is paired with the
public key in the certificate.

Of course, things change over time. The IP address of a device might
change due to any number of reasons. Domain name hierarchies change and
email addresses change. A system that controls a private key is still
able to use it to authenticate itself even if the identifier associated
with the public key has changed.

When matching the identity in an end entity certificate with that in a
policy database, there is no inherent need to match the identity with
the topological location of the peer. That is, an IP address in a
certificate does not have to match the IP address of the system that is
authenticating using that certificate. Similarly, a DNS address in a
certificate does not have to resolve to the IP address of the system
that is authenticating using that certificate. (Of course, it is
impossible for the email address in a certificate to match the email
address of the system authentication using that certificate because IKE
systems don't have any particular email addresses.)


3. IKE processing

This section describes how to process certificates in IKEv1. Many of the
restrictions in this profile go counter to what some IKEv1
implementations do today. This is not to say that what those current
implementations do today is wrong or insecure; however, the restrictions
listed here are believed to achieve higher interoperability without
sacrificing security.

This profile only covers Main Mode of IKEv1. Both parties MUST use
authentication with RSA signatures (authentication method 3 in [IKEv1]).

Both parties MUST already have the full chain of certificates to all
mutually-trusted trust anchors. Neither party can assume that the other
party will send anything other than its end entity certificate.

3.1 Use of the CERTREQ and CERT payloads

Either party MAY send a CERTREQ payload. Note that this is strictly
optional; neither party has to send a CERTREQ payload. Systems MUST NOT
fail if the other party did not send a CERTREQ payload. If sent, the
CERTREQ payload MAY appear in messages 1 through 5.

If a CERTREQ payload appears, it MUST have encoding type 5 (X.509
Certificate - Signature). The CERTREQ payload MUST NOT be used for
requesting certificate revocation lists (CRLs).

The certificate authority field in the CERTREQ payload MAY be empty If a
party receives a CERTREQ payload with an empty name, the receiving party
SHOULD send all of its end entity certificates. That is, an empty
certificate authority name in a CERTREQ payload indicates that the party
wants any end entity certificates that the other party can use.

CERT payloads MUST only contain end entity certificates. They MUST not
contain trust anchors or intermediate certificates.

Each party MUST send at least one CERT payload during IKE. Parties
SHOULD send their end entity certificates in message 5 or 6, but each
party MAY send one or more CERT payloads in any message. If a CERT
payload appears, it MUST have encoding type 5 (X.509 Certificate -
Signature). Receiving parties MUST be able to handle multiple incoming
certificates, even if they are different payloads.

3.2 Use of the ID payload

IKEv1 requires that messages 5 and 6 contain ID payloads; these payloads
MUST be present. However, the interpretation of their contents is up to
the receiving party. The receiver MAY ignore the contents ID payload.
The sender MUST NOT assume that the receiver will take any particular
action based on the contents of the ID payload that was sent.

The receiver MUST NOT fail just because the ID payload does not match
one of the identities in the sender's certificate. The receiver SHOULD
NOT fail if the ID payload does not match an entry in the receiver's
policy database; instead, the receiver SHOULD try to match any identity
in the sender's certificate(s) to the policy database.

If any certificate sent has more than one identity, the ID payload
SHOULD match one of the identities. That is the "preferred identity"

3.3 Certificate expiration and revocation

Some IPsec environments purposely use short-lived certificates. Systems
adhering to this profile MUST check certificate expiration times when
authenticating using IKEv1. If a certificate has expired, the system
MUST NOT create an SA. If the certificate would expire during the SA
being created, the SA MUST expire when the certificate expires. In order
to meet these requirements, conformant IPsec systems MUST have a
reasonably accurate clock.

Systems following this profile MUST have access to revocation
information (usually CRLs) for all certificates they use. In the real
world, very few systems today have such access, and this profile does
not propose how to improve that situation.

3.4 Path validation

Most IPsec environments do fine without certificate paths. In typical
corporate use, a single certificate authority signs end entity
certificates, so there is no certificate chain.

If the mutually-trusted anchor has intermediate certificates between it
and the end entity certificates used by the IPsec systems, the systems
MUST be able to do full PKIX path validation. If they cannot validate
the path between the end entity and the trust anchor following the
(admittedly intricate) rules in PKIX, then they MUST NOT authenticate
with those end entity certificates.

3.5 Critical extensions

IPsec systems following this specification MUST process critical
extensions as described in PKIX. Systems MUST NOT ignore the criticality
of any extension in any certificate that they use for authentication.


4. Security considerations

This profile deals extensively with security. Using certificates for
authentication in IPsec is generally considered to be more secure than
using preshared secrets because typical preshared secret use often
devolves to passwords instead of preshared secrets.

The security of any system that uses certificates for authentication
relies on both the strength of the certificate's key and on how well the
private key associated with the public key is protected.


5. References

5.1 Normative references

[IKEv1] Harkins, D., et. al., "The Internet Key Exchange (IKE)", RFC
2409, November 1997.

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

[PKIX] Housley, R., et. al., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.

6. Author's address

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