1. Introduction
This document describes and identifies the requirements for
transactions to handle PKC lifecycle transactions between [IPsec] VPN
Systems using IKE ([IKEv1] and [IKEv2]) and PKI Systems. This
document contains requirements for a transaction-based approach.
Other models are conceivable, for example, a directory-centric
approach, but their requirements are beyond the scope of this
document.
This document enumerates requirements for Public Key Certificate
(PKC) lifecycle transactions between different VPN System and PKI
System products in order to better enable large scale, PKI-enabled
IPsec deployments with a common set of transactions. Requirements
for both the IPsec and the PKI products are discussed. The
requirements are carefully designed to achieve security without
compromising ease of management and deployment, even where the
deployment involves tens of thousands of IPsec users and devices.
The requirements address transactions for the entire PKC lifecycle
for PKI-enabled VPN System: authorization (of PKC issuance),
generation (public-private key pair and PKC request), enrollment (PKC
request, PKC response, and confirmation), maintenance (rekey, renew,
update, revoke, and confirm), and repository lookups. These
transactions enable a VPN Operator to:
- Use a VPN Administration function (Admin), which is introduced in
this document, to manage PKC authorization and possibly act as
the sole interface for the VPN System and the PKI System.
- Authorize individual or batches of PKC issuances based on a pre-
agreed template (i.e., both types of authorization requests refer
to the pre-agreed template). These authorizations can occur
either prior to the enrollment or in the same transaction as the
enrollment.
- Provision PKI-based user or machine identity to IPsec Peers, on a
large scale.
- Set the corresponding gateway or client authorization policy for
remote access and site-to-site connections.
- Establish policies for automatic PKC rekeys, renewals, and
updates.
- Ensure timely revocation information is available for PKCs used
in IKE exchanges.
These requirements are intended to be used to profile a certificate
management protocol that the VPN System will use to communicate with
the PKI System. Note that this profile will be in another document.
The certificate management profile will also clarify and constrain
existing PKIX (PKI for X.509 Certificates) and IPsec standards to
limit the complexity of deployment. Some requirements may require
either a new protocol, or changes or extensions to an existing
protocol.
The desired outcome of the requirements and profile documents is that
both IPsec and PKI vendors create interoperable products to enable
large-scale IPsec System deployments, and do so as quickly as
possible. For example, a VPN Operator should be able to use any
conforming IPsec implementation (VPN Administration or IPsec Peer) of
the certificate management profile with any conforming PKI vendor's
implementation to perform the VPN rollout and management.
1.1. Scope
The document addresses requirements on transactions between the VPN
Systems and the PKI Systems and between the VPN Administration and
IPsec Peers. The requirements strive to meet eighty percent of the
market needs for large-scale deployments (i.e., VPNs including
hundreds or thousands of managed VPN gateways or VPN remote access
clients). Environments will understandably exist in which large-
scale deployment tools are desired, but local security policy
stringency will not allow for the use of such commercial tools. The
solution will possibly miss the needs of the highest ten percent of
stringency and the lowest ten percent of convenience requirements.
Use cases will be considered or rejected based upon this eighty
percent rule. The needs of small deployments are a stated non-goal;
however, service providers employing the scoped solution and applying
it to many smaller deployments in aggregate may address them.
Gateway-to-gateway access and end-user remote access (to a gateway)
are both covered. End-to-end communications are not necessarily
excluded, but are intentionally not a focus.
Only VPN-PKI transactions that ease and enable scalable PKI-enabled
IPsec deployments are addressed.
The scenario for PKC cross-certification will not be addressed.
The protocol specification for the VPN-PKI interactions will not be
addressed.
The protocol specification for the VPN Administrator to Peer
transactions will not be addressed. These interactions are
considered vendor proprietary. These interactions may be
standardized later to enable interoperability between VPN
Administration function stations and IPsec Peers from different
vendors, but are far beyond the scope of this current effort, and
will be described as opaque transactions in this document.
The protocol specification for Registration Authority - Certificate
Authority (RA-CA), CA-Repository, and RA-Repository interactions will
not be addressed.
1.3. Definitions
VPN System
The VPN System is comprised of the VPN Administration function
(defined below), the IPsec Peers, and the communication mechanism
between the VPN Administration and the IPsec Peers. VPN System is
defined in more detail in Section 2.1.
PKI System
The PKI System, or simply PKI, is the set of functions needed to
authorize, issue, and manage PKCs. PKI System is defined in more
detail in Section 2.2.
(VPN) Operator
The Operator is the person or group of people that define security
policy and configure the VPN System to enforce that policy, with the
VPN Administration function.
IPsec Peer (Gateway or Client)
For the purposes of this document, an IPsec Peer, or simply "Peer",
is any VPN System component that communicates IKE and IPsec to
another Peer in order to create an IPsec Security Association for
communications. It can be either a traditional security gateway
(with two network interfaces, one for the protected network and one
for the unprotected network) or an IPsec client (with a single
network interface). In both cases, the Peer can pass traffic with no
IPsec protection, and can add IPsec protection to chosen traffic
streams. See Section 2.1.1 for more details.
(VPN) Admin
The Admin is the VPN System function that interacts with the PKI
System to establish PKC provisioning for the VPN connections. See
Section 2.1.2 for more details.
End Entity
An end entity is the entity or subject that is identified in a PKC.
The end entity is the one entity that will finally use a private key
associated with a PKC to digitally sign data. In this document, an
IPsec Peer is certainly an end entity, but the VPN Admin can also
constitute an end entity. Note that end entities can have different
PKCs for different purposes (e.g., signature vs. key exchange,
Admin-functions vs. Peer-functions).
PKC Rekey
The routine procedure for replacement of a PKC with a new PKC with a
new public key for the same subject name. A rekey process can rely
on the existing key pair to bootstrap authentication for the new
enrollment.
PKC Renewal
The acquisition of a new PKC with the same public key due to the
expiration of an existing PKC. Renewal occurs prior to the
expiration of the existing PKC to avoid any connection outages. A
renewal process can rely on the existing key pair to bootstrap
authentication for the new enrollment.
PKC Update
A special case of a renewal-like occurrence where a PKC needs to be
changed prior to expiration due to some change in its subject's
information. Examples might include change in the address, telephone
number, or name change due to marriage of the end entity. An update
process can rely on the existing key pair to bootstrap authentication
for the new enrollment.
Registration Authority (RA)
An optional entity in a PKI System given responsibility for
performing some of the administrative tasks necessary in the
registration of end entities, such as confirming the subject's
identity and verifying that the subject has possession of the private
key associated with the public key requested for a PKC.
Certificate Authority (CA)
An authority in a PKI System that is trusted by one or more users to
create and sign PKCs. It is important to note that the CA is
responsible for the PKCs during their whole lifetime, not just for
issuing them.
Repository
An Internet-accessible server in a PKI System that stores and makes
available for retrieval PKCs and Certificate Revocation Lists (CRLs).
Root CA/Trust Anchor
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 term is not meant to imply that a Root CA is
necessarily at the top of any hierarchy, simply that the CA in
question is trusted directly.
Certificate Revocation List (CRL)
A CRL is a CA-signed, timestamped list identifying revoked PKCs and
made freely available in a repository. Peers retrieve the CRL to
verify that a PKC being presented to them as the identity in an IKE
transaction has not been revoked.
CRL Distribution Point (CDP)
The CDP is a PKC extension that identifies the location from which
end entities should retrieve CRLs to check status information.
Authority Info Access (AIA)
The AIA is a PKC extension that indicates how to access CA
information and services for the issuer of the PKC in which the
extension appears. Information and services may include on-line
validation services and Certificate Policy (CP) data.
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 [MUSTSHOULD].
