< draft-ietf-pki4ipsec-mgmt-profile-rqts-06.txt   draft-ietf-pki4ipsec-mgmt-profile-rqts-07.txt >
PKI4IPSEC Working Group PKI4IPSEC Working Group
Internet Draft Chris Bonatti, IECA Internet Draft Chris Bonatti, IECA
draft-ietf-pki4ipsec-mgmt-profile-rqts-06.txt Sean Turner, IECA draft-ietf-pki4ipsec-mgmt-profile-rqts-07.txt Sean Turner, IECA
October 2, 2006 Gregory Lebovitz, Juniper November 8, 2006 Gregory Lebovitz, Juniper
Expires April 2, 2007 Expires May 8, 2007
Requirements for an IPsec Certificate Management Profile Requirements for an IPsec Certificate Management Profile
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 2, 2007. This Internet-Draft will expire on November 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This informational document describes and identifies the requirements This informational document describes and identifies the requirements
for transactions to handle Public Key Certificate (PKC) lifecycle for transactions to handle Public Key Certificate (PKC) lifecycle
transactions between Internet Protocol Security (IPsec) Virtual transactions between Internet Protocol Security (IPsec) Virtual
skipping to change at page 2, line 9 skipping to change at page 2, line 9
(versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These
requirements are designed to meet the needs of enterprise scale IPsec requirements are designed to meet the needs of enterprise scale IPsec
VPN deployments. It is intended that a standards track profile of a VPN deployments. It is intended that a standards track profile of a
management protocol will be created to address many of these management protocol will be created to address many of these
requirements. requirements.
IPsec Certificate Management Profile IPsec Certificate Management Profile
Table of Contents Table of Contents
1 INTRODUCTION.....................................................4 1 Introduction....................................................3
1.1 SCOPE..........................................................5 1.1 Scope.........................................................5
1.2 NON-GOALS......................................................5 1.2 Non-Goals.....................................................5
1.3 DEFINITIONS....................................................6 1.3 Definitions...................................................6
1.4 REQUIREMENTS TERMINOLOGY.......................................8 1.4 Requirements Terminology.......................................8
2. ARCHITECTURE....................................................9 2 Architecture....................................................8
2.1 VPN SYSTEM.....................................................9 2.1 VPN System....................................................8
2.1.1 IPSEC PEER(S)................................................9 2.1.1 IPsec Peer(s)...............................................9
2.1.2 VPN ADMINISTRATION FUNCTION (ADMIN)..........................9 2.1.2 VPN Administration Function (Admin).........................9
2.2 PKI SYSTEM....................................................11 2.2 PKI System...................................................10
2.3 VPN-PKI INTERACTION...........................................11 2.3 VPN-PKI Interaction..........................................10
3 REQUIREMENTS....................................................13 3 Requirements...................................................12
3.1 GENERAL REQUIREMENTS..........................................13 3.1 General Requirements.........................................12
3.1.1 ONE PROTOCOL................................................13 3.1.1 One Protocol...............................................12
3.1.2 SECURE TRANSACTIONS.........................................13 3.1.2 Secure Transactions........................................12
3.1.3 ADMIN AVAILABILITY..........................................13 3.1.3 Admin Availability.........................................12
3.1.3 PKI AVAILABILITY............................................14 3.1.3 PKI Availability...........................................13
3.1.4 END-USER TRANSPARENCY.......................................14 3.1.4 End-User Transparency......................................13
3.1.5 PKC PROFILE FOR PKI INTERACTION.............................14 3.1.5 PKC Profile for PKI Interaction............................13
3.1.5.1 IDENTITY..................................................15 3.1.5.1 Identity.................................................14
3.1.5.2 KEY USAGE.................................................15 3.1.5.2 Key Usage................................................14
3.1.5.3 EXTENDED KEY USAGE........................................15 3.1.5.3 Extended Key Usage.......................................14
3.1.5.4 REVOCATION INFORMATION LOCATION...........................15 3.1.5.4 Revocation Information Location..........................14
3.1.6 ERROR HANDLING..............................................15 3.1.6 Error Handling.............................................14
3.2 AUTHORIZATION.................................................15 3.2 Authorization................................................14
3.2.1 ONE PROTOCOL................................................15 3.2.1 One Protocol...............................................14
3.2.2 BULK AUTHORIZATION..........................................16 3.2.2 Bulk Authorization.........................................15
3.2.3 AUTHORIZATION SCENARIO......................................17 3.2.3 Authorization Scenario.....................................16
3.2.4 AUTHORIZATION REQUEST.......................................17 3.2.4 Authorization Request......................................16
3.2.4.1 SPECIFYING FIELDS WITHIN THE PKC..........................17 3.2.4.1 Specifying Fields within the PKC.........................16
3.2.4.2 AUTHORIZATIONS FOR RENEWAL, UPDATE, AND REKEY.............18 3.2.4.2 Authorizations for Renewal, Update, and Rekey............17
3.2.4.3 OTHER AUTHORIZATION ELEMENTS..............................19 3.2.4.3 Other Authorization Elements.............................18
3.2.4.4 CANCEL CAPABILITY.........................................19 3.2.4.4 Cancel Capability........................................18
3.2.5 AUTHORIZATION RESPONSE......................................20 3.2.5 Authorization Response.....................................19
3.2.5.1 ERROR HANDLING FOR AUTHORIZATION..........................20 3.2.5.1 Error Handling for Authorization.........................19
3.3 GENERATION....................................................20 3.3 Generation...................................................19
3.3.1 GENERATION METHOD 1: IPSEC PEER GENERATES KEY PAIR, 3.3.1 Generation Method 1: IPsec Peer Generates Key Pair,
CONSTRUCTS PKC REQUEST, AND SIGNS PKC REQUEST..............21 Constructs PKC Request, and Signs PKC Request..............20
3.3.2 GENERATION METHOD 2: IPSEC PEER GENERATES KEY PAIR, ADMIN 3.3.2 Generation Method 2: IPsec Peer Generates Key Pair, Admin
CONSTRUCTS PKC REQUEST, ADMIN SIGNS PKC REQUEST............22 Constructs PKC Request, Admin Signs PKC Request............21
3.3.3 GENERATION METHOD 3: ADMIN GENERATES KEY PAIR, CONSTRUCTS 3.3.3 Generation Method 3: Admin Generates Key Pair, Constructs PKC
PKC REQUEST, AND SIGNS PKC REQUEST.........................23 Request, and Signs PKC Request.............................22
3.3.4 METHOD 4: PKI GENERATES KEY PAIR............................24 3.3.4 Method 4: PKI Generates Key Pair...........................23
3.3.5 ERROR HANDLING FOR GENERATION...............................24 3.3.5 Error Handling for Generation..............................23
3.4 Enrollment...................................................24
3.4.1 One protocol...............................................24
3.4.2 On-line protocol...........................................24
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.4 ENROLLMENT....................................................25 3.4.3 Single Connection with Immediate Response..................24
3.4.1 ONE PROTOCOL................................................25 3.4.4 Manual Approval Option.....................................24
3.4.2 ON-LINE PROTOCOL............................................25 3.4.5 Enrollment Method 1: Peer Enrolls to PKI Directly..........24
3.4.3 SINGLE CONNECTION WITH IMMEDIATE RESPONSE...................25 3.4.6 Enrollment Method 2a: Peer Enrolls through Admin...........26
3.4.4 MANUAL APPROVAL OPTION......................................25 3.4.7 Enrollment Method 2b: Peer Enrolls Through Admin...........28
3.4.5 ENROLLMENT METHOD 1: PEER ENROLLS TO PKI DIRECTLY...........25 3.4.8 Enrollment Method 3a: Admin Authorizes and Enrolls
3.4.6 ENROLLMENT METHOD 2A: PEER ENROLLS THROUGH ADMIN............27 Directly to PKI............................................30
3.4.7 ENROLLMENT METHOD 2B: PEER ENROLLS THROUGH ADMIN............29 3.4.9 Enrollment Method 3b: Admin Authorizes and Enrolls
3.4.8 ENROLLMENT METHOD 3A: ADMIN AUTHORIZES AND ENROLLS Directly to PKI............................................32
DIRECTLY TO PKI............................................31 3.4.10 Confirmation Handshake....................................34
3.4.9 ENROLLMENT METHOD 3B: ADMIN AUTHORIZES AND ENROLLS 3.4.11 Error Handling for Enrollment.............................35
DIRECTLY TO PKI............................................33 3.5 Lifecycle....................................................36
3.4.10 CONFIRMATION HANDSHAKE.....................................35 3.5.1 One Protocol...............................................36
3.4.11 ERROR HANDLING FOR ENROLLMENT..............................36 3.5.2 PKC Rekeys, Renewals, and Updates..........................36
3.5 LIFECYCLE.....................................................37 3.5.2.1 Rekey Request............................................38
3.5.1 ONE PROTOCOL................................................37 3.5.2.1 Renew Request............................................38
3.5.2 PKC REKEYS, RENEWALS, AND UPDATES...........................37 3.5.2.2 Update Request...........................................38
3.5.2.1 REKEY REQUEST.............................................39 3.5.2.3 Error Handling for Rekey, Renewal, and Update............39
3.5.2.1 RENEW REQUEST.............................................39 3.5.2.4 Confirmation Handshakes..................................40
3.5.2.2 UPDATE REQUEST............................................39 3.5.3 Revocation.................................................40
3.5.2.3 ERROR HANDLING FOR REKEY, RENEWAL, AND UPDATE.............40 3.6 Repositories.................................................41
3.5.2.4 CONFIRMATION HANDSHAKES...................................41 3.6.1 Lookups....................................................41
3.5.3 REVOCATION..................................................41 3.6.2 Error Handling for Repository Lookups......................42
3.6 REPOSITORIES..................................................42 3.7 Trust........................................................42
3.6.1 LOOKUPS.....................................................42 3.7.1 Trust Anchor PKC Acquisition...............................42
3.6.2 ERROR HANDLING FOR REPOSITORY LOOKUPS.......................43 3.7.2 Certification Path Validation..............................42
3.7 TRUST.........................................................43 3.7.3 Revocation Checking and Status Information.................43
3.7.1 TRUST ANCHOR PKC ACQUISITION................................43 3.7.4 Error Handling in Revocation Checking and Certificate
3.7.2 CERTIFICATION PATH VALIDATION...............................43 Path Validation...........................................43
3.7.3 REVOCATION CHECKING AND STATUS INFORMATION..................44 4 Security Considerations........................................44
3.7.4 ERROR HANDLING IN REVOCATION CHECKING AND CERTIFICATE 5 IANA Considerations............................................44
PATH VALIDATION............................................44 6 References.....................................................44
4. SECURITY CONSIDERATIONS........................................45 6.1 Normative References.........................................44
7. INTELLECTUAL PROPERTY RIGHTS..................................45 6.2 Informative References.......................................44
8. IANA CONSIDERATIONS...........................................45 7 Acknowledgements...............................................45
A REFERENCES......................................................46 Editor’s Address..................................................45
A.1 NORMATIVE REFERENCES..........................................46
A.2 NON-NORMATIVE REFERENCES......................................46
B. ACKNOWLEDGEMENTS...............................................46
C. EDITOR’S ADDRESS...............................................47
D. CHANGE HISTORY.................................................47
IPsec Certificate Management Profile
1 Introduction 1 Introduction
This document contains requirements for a transaction-based This document contains requirements for a transaction-based
approach. Other models are conceivable, for example a directory- approach. Other models are conceivable, for example a directory-
centric approach, but their requirements are beyond the scope of centric approach, but their requirements are beyond the scope of
this document. this document.
This document enumerates requirements for Public Key Certificate This document enumerates requirements for Public Key Certificate
(PKC) lifecycle transactions between different VPN System and PKI (PKC) lifecycle transactions between different VPN System and PKI
System products in order to better enable large scale, PKI-enabled System products in order to better enable large scale, PKI-enabled
IPsec deployments with a common set of transactions. Requirements for IPsec deployments with a common set of transactions. Requirements for
IPsec Certificate Management Profile
both the IPsec and the PKI products are discussed. The requirements both the IPsec and the PKI products are discussed. The requirements
are carefully designed to achieve security without compromising ease are carefully designed to achieve security without compromising ease
of management and deployment, even where the deployment involves tens of management and deployment, even where the deployment involves tens
of thousands of IPsec users and devices. of thousands of IPsec users and devices.
The requirements address transactions for the entire PKC lifecycle The requirements address transactions for the entire PKC lifecycle
for PKI-enabled VPN System: authorization (of PKC issuance), for PKI-enabled VPN System: authorization (of PKC issuance),
generation (public-private key pair and PKC request), enrollment (PKC generation (public-private key pair and PKC request), enrollment (PKC
request, PKC response, and confirmation), maintenance (rekey, renew, request, PKC response, and confirmation), maintenance (rekey, renew,
update, revoke, and confirm), and repository lookups. These update, revoke, and confirm), and repository lookups. These
skipping to change at page 5, line 4 skipping to change at page 4, line 43
- Establish policies for automatic PKC renewal, updates, or rekeys. - Establish policies for automatic PKC renewal, updates, or rekeys.
- Ensure timely revocation information is available for PKCs used - Ensure timely revocation information is available for PKCs used
in IKE exchanges. in IKE exchanges.
These requirements are intended to be used to profile a certificate These requirements are intended to be used to profile a certificate
management protocol that the VPN System will use to communicate with management protocol that the VPN System will use to communicate with
the PKI System. Note that this profile will be in another document. the PKI System. Note that this profile will be in another document.
The certificate management profile will also clarify and constrain The certificate management profile will also clarify and constrain
IPsec Certificate Management Profile
existing PKIX and IPsec standards to limit the complexity of existing PKIX and IPsec standards to limit the complexity of
deployment. Some requirements may require either a new protocol, or deployment. Some requirements may require either a new protocol, or
changes or extensions to an existing protocol. changes or extensions to an existing protocol.
The desired outcome of the requirements and profile documents is that The desired outcome of the requirements and profile documents is that
both IPsec and PKI vendors create interoperable products to enable both IPsec and PKI vendors create interoperable products to enable
large-scale IPsec System deployments, and do so as quickly as large-scale IPsec System deployments, and do so as quickly as
possible. For example, a VPN Operator should be able to use any possible. For example, a VPN Operator should be able to use any
conforming IPsec implementation (VPN Admin or IPsec Peer) of the conforming IPsec implementation (VPN Admin or IPsec Peer) of the
certificate management profile with any conforming PKI vendor’s certificate management profile with any conforming PKI vendor’s
implementation to perform the VPN rollout and management. implementation to perform the VPN rollout and management.
1.1 Scope IPsec Certificate Management Profile
1.1 Scope
The document addresses requirements on transactions between the VPN The document addresses requirements on transactions between the VPN
Systems and the PKI Systems and between the VPN Administration and Systems and the PKI Systems and between the VPN Administration and
IPsec Peers. The requirements strive to meet eighty percent of the IPsec Peers. The requirements strive to meet eighty percent of the
market needs for large-scale deployments (i.e., VPNs including market needs for large-scale deployments (i.e., VPNs including
hundreds or thousands of managed VPN gateways or VPN remote access hundreds or thousands of managed VPN gateways or VPN remote access
clients). Environments will understandably exist in which large-scale clients). Environments will understandably exist in which large-scale
deployment tools are desired, but local security policy stringency deployment tools are desired, but local security policy stringency
will not allow for the use of such commercial tools. The solution will not allow for the use of such commercial tools. The solution
will possibly miss the needs of the highest ten percent of stringency will possibly miss the needs of the highest ten percent of stringency
skipping to change at page 5, line 42 skipping to change at page 5, line 31
employing the scoped solution and applying it to many smaller employing the scoped solution and applying it to many smaller
deployments in aggregate may address them. deployments in aggregate may address them.
Gateway-to-gateway access and end-user remote access (to a gateway) Gateway-to-gateway access and end-user remote access (to a gateway)
are both covered. End-to-end communications are not necessarily are both covered. End-to-end communications are not necessarily
excluded but are intentionally not a focus. excluded but are intentionally not a focus.
Only VPN-PKI transactions that ease and enable scalable PKI-enabled Only VPN-PKI transactions that ease and enable scalable PKI-enabled
IPsec deployments are addressed. IPsec deployments are addressed.
1.2 Non-Goals 1.2 Non-Goals
The scenario for PKC cross-certification will not be addressed. The scenario for PKC cross-certification will not be addressed.
The protocol specification for the VPN-PKI interactions will not be The protocol specification for the VPN-PKI interactions will not be
addressed. addressed.
The protocol specification for the VPN Administrator to Peer The protocol specification for the VPN Administrator to Peer
transactions will not be addressed. These interactions are considered transactions will not be addressed. These interactions are considered
vendor proprietary. These interactions may be standardized later to vendor proprietary. These interactions may be standardized later to
enable interoperability between VPN Administration function stations enable interoperability between VPN Administration function stations
IPsec Certificate Management Profile
and IPsec Peers from different vendors, but are far beyond the scope and IPsec Peers from different vendors, but are far beyond the scope
of this current effort, and will be described as opaque transactions of this current effort, and will be described as opaque transactions
in this document. in this document.
The protocol specification for RA-CA, CA-Repository, and RA- The protocol specification for RA-CA, CA-Repository, and RA-
Repository interactions will not be addressed. Repository interactions will not be addressed.
1.3 Definitions IPsec Certificate Management Profile
1.3 Definitions
VPN System VPN System
The VPN System is comprised of the VPN Administration function The VPN System is comprised of the VPN Administration function
(defined below), the IPsec Peers, and the communication mechanism (defined below), the IPsec Peers, and the communication mechanism
between the VPN Administration and the IPsec Peers. VPN System is between the VPN Administration and the IPsec Peers. VPN System is
defined in more detail in section 2.1. defined in more detail in section 2.1.
PKI System PKI System
The PKI System, or simply PKI, is the set of functions needed to The PKI System, or simply PKI, is the set of functions needed to
authorize, issue, and manage PKCs. PKI System is defined in more authorize, issue, and manage PKCs. PKI System is defined in more
skipping to change at page 7, line 4 skipping to change at page 6, line 47
The Admin is the VPN System function that interacts with the PKI The Admin is the VPN System function that interacts with the PKI
System to establish PKC provisioning for the VPN connections. See System to establish PKC provisioning for the VPN connections. See
Section 2.1.2 for more details. Section 2.1.2 for more details.
End Entity End Entity
An end entity is the entity or subject that is identified in a PKC. 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 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 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 IPsec Peer is certainly an end entity, but the VPN Admin can also
constitute an end entity. Note that end entities can have different constitute an end entity. Note that end entities can have different
IPsec Certificate Management Profile
PKCs for different purposes (e.g., signature vs. key exchange, Admin- PKCs for different purposes (e.g., signature vs. key exchange, Admin-
functions vs. Peer-functions). functions vs. Peer-functions).
PKC Renewal PKC Renewal
The acquisition of a new PKC with the same public key due to the 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 expiration of an existing PKC. Renewal occurs prior to the expiration
of the existing PKC to avoid any connection outages. A renewal of the existing PKC to avoid any connection outages. A renewal
process can rely on the existing key pair to bootstrap authentication process can rely on the existing key pair to bootstrap authentication
for the new enrollment. for the new enrollment.
IPsec Certificate Management Profile
PKC Update PKC Update
A special case of a renewal-like occurrence where a PKC needs to be 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 changed prior to expiration due to some change in its subject’s
information. Examples might include change in the address, telephone information. Examples might include change in the address, telephone
number, or name change due to marriage of the end entity. An update number, or name change due to marriage of the end entity. An update
process can rely on the existing key pair to bootstrap authentication process can rely on the existing key pair to bootstrap authentication
for the new enrollment. for the new enrollment.
PKC Rekey PKC Rekey
The routine procedure for replacement of a PKC with a new PKC with a The routine procedure for replacement of a PKC with a new PKC with a
skipping to change at page 8, line 5 skipping to change at page 7, line 45
An Internet-accessible server in a PKI System that stores and makes An Internet-accessible server in a PKI System that stores and makes
available for retrieval PKCs and Certificate Revocation Lists (CRLs). available for retrieval PKCs and Certificate Revocation Lists (CRLs).
Root CA/Trust Anchor Root CA/Trust Anchor
A CA that is directly trusted by an end entity; that is, securely 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 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 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 necessarily at the top of any hierarchy, simply that the CA in
question is trusted directly. question is trusted directly.
IPsec Certificate Management Profile
Certificate Revocation List (CRL) Certificate Revocation List (CRL)
A CRL is a CA-signed, time stamped list identifying revoked PKCs and A CRL is a CA-signed, time stamped list identifying revoked PKCs and
made freely available in a repository. Peers retrieve the CRL to 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 verify that a PKC being presented to them as the identity in an IKE
transaction has not been revoked. transaction has not been revoked.
CRL Distribution Point (CDP) CRL Distribution Point (CDP)
The CDP is a PKC extension that identifies the location from which The CDP is a PKC extension that identifies the location from which
end entities should retrieve CRLs to check status information. end entities should retrieve CRLs to check status information.
IPsec Certificate Management Profile
Authority Info Access (AIA) Authority Info Access (AIA)
The AIA is a PKC extension that indicates how to access CA The AIA is a PKC extension that indicates how to access CA
information and services for the issuer of the PKC in which the information and services for the issuer of the PKC in which the
extension appears. Information and services may include on-line extension appears. Information and services may include on-line
validation services and Certificate Policy (CP) data. validation services and Certificate Policy (CP) data.
1.4 Requirements Terminology 1.4 Requirements Terminology
Though this document is not an Internet Draft, we use the convention The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
that the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in document are to be interpreted as described in [MUSTSHOULD].
this document are to be interpreted as described in [MUSTSHOULD].
IPsec Certificate Management Profile
2. Architecture 2 Architecture
This section describes the overall architecture for a PKI-supported This section describes the overall architecture for a PKI-supported
IPsec VPN deployment. First, an explanation of the VPN System is IPsec VPN deployment. First, an explanation of the VPN System is
presented. Second, key points about the PKI System are stated. Third, presented. Second, key points about the PKI System are stated. Third,
the VPN-PKI architecture is presented. the VPN-PKI architecture is presented.
2.1 VPN System 2.1 VPN System
The VPN System consists of the IPsec Peers and the VPN Administration The VPN System consists of the IPsec Peers and the VPN Administration
function, as depicted in Figure 1. function, as depicted in Figure 1.
+---------------------------------------------------+ +---------------------------------------------------+
| | | |
| +----------+ | | +----------+ |
| | VPN | | | | VPN | |
| +---------->| Admin |<-------+ | | +---------->| Admin |<-------+ |
| | | Function | | | | | | Function | | |
skipping to change at page 9, line 37 skipping to change at page 9, line 5
| +---------+ +---------+ | | +---------+ +---------+ |
| | IPsec | | IPsec | | | | IPsec | | IPsec | |
| | Peer 1 |<=======================>| Peer 2 | | | | Peer 1 |<=======================>| Peer 2 | |
| +---------+ +---------+ | | +---------+ +---------+ |
| | | |
| VPN System | | VPN System |
+---------------------------------------------------+ +---------------------------------------------------+
Figure 1: VPN System Figure 1: VPN System
2.1.1 IPsec Peer(s) IPsec Certificate Management Profile
2.1.1 IPsec Peer(s)
The Peers are two entities between which establishment of an IPsec The Peers are two entities between which establishment of an IPsec
Security Association is required. Two Peers are shown in Figure 1, Security Association is required. Two Peers are shown in Figure 1,
but implementations can support an actual number in the hundreds or but implementations can support an actual number in the hundreds or
thousands. The Peers can be gateway-to-gateway, remote-access-host- thousands. The Peers can be gateway-to-gateway, remote-access-host-
to-gateway, or a mix of both. The Peers authenticate themselves in to-gateway, or a mix of both. The Peers authenticate themselves in
the IKE negotiation using digital signatures generated with PKCs for the IKE negotiation using digital signatures generated with PKCs for
a PKI System. a PKI System.
2.1.2 VPN Administration Function (Admin) 2.1.2 VPN Administration Function (Admin)
This document defines the notion of a VPN Administration function, This document defines the notion of a VPN Administration function,
hereafter referred to as Admin, and gives the Admin great hereafter referred to as Admin, and gives the Admin great
responsibility within the VPN System. The Admin is a centralized responsibility within the VPN System. The Admin is a centralized
function used by the Operator to interact with the PKI system to function used by the Operator to interact with the PKI system to
IPsec Certificate Management Profile
establish PKI policy (e.g., algorithms, key lengths, lifecycle establish PKI policy (e.g., algorithms, key lengths, lifecycle
options, and PKC fields) for groups of IPsec Peers. The Admin also options, and PKC fields) for groups of IPsec Peers. The Admin also
authorizes PKC issuance and it can act as the Peer's PKI System authorizes PKC issuance and it can act as the Peer's PKI System
interface, which allows the Admin to perform many RA-like functions. interface, which allows the Admin to perform many RA-like functions.
It is important to note that, within this document, the Admin is It is important to note that, within this document, the Admin is
neither a device nor a person; rather it is a function. Every large- neither a device nor a person; rather it is a function. Every large-
scale VPN deployment will contain the Admin function. The function scale VPN deployment will contain the Admin function. The function
can be performed on a stand-alone workstation, on a gateway, or on an can be performed on a stand-alone workstation, on a gateway, or on an
administration software component. The Admin function can also be one administration software component. The Admin function can also be one
skipping to change at page 10, line 38 skipping to change at page 10, line 4
the VPN System. The Operator will configure local security the VPN System. The Operator will configure local security
policy in part through the Admin and its authorized PKI-enabled policy in part through the Admin and its authorized PKI-enabled
Peers. Peers.
- It will interact directly with the PKI System to initiate - It will interact directly with the PKI System to initiate
authorization for end entity PKCs by sending the parameters and authorization for end entity PKCs by sending the parameters and
contents for individual PKCs or batches of PKCs based on a pre- contents for individual PKCs or batches of PKCs based on a pre-
agreed template (i.e., both types of authorization requests agreed template (i.e., both types of authorization requests
refer to the pre-agreed template). Templates will be agreed in refer to the pre-agreed template). Templates will be agreed in
an out-of-band mechanism by the VPN Operator and the PKI an out-of-band mechanism by the VPN Operator and the PKI
IPsec Certificate Management Profile
Operator. It will receive back from the PKI a unique tuple of Operator. It will receive back from the PKI a unique tuple of
authorization identifiers and one-time authorization tokens that authorization identifiers and one-time authorization tokens that
will authorize Peers to request a PKC. will authorize Peers to request a PKC.
- It will deliver instructions to the IPsec Peers, and the Peers - It will deliver instructions to the IPsec Peers, and the Peers
will carry out those instructions (e.g., Admin passes Peer will carry out those instructions (e.g., Admin passes Peer
information necessary to generate keys and PKC request). information necessary to generate keys and PKC request).
IPsec Certificate Management Profile 2.2 PKI System
2.2 PKI System
The PKI System, as depicted in Figure 2, can be set up and operated The PKI System, as depicted in Figure 2, can be set up and operated
by the Operator (in-house), be provided by third party PKI providers by the Operator (in-house), be provided by third party PKI providers
to which connectivity is available at the time of provisioning to which connectivity is available at the time of provisioning
(managed PKI service), or be integrated with the VPN product. (managed PKI service), or be integrated with the VPN product.
+---------------------------------------------+ +---------------------------------------------+
| +-------------------------+ | | +-------------------------+ |
| v | | | v | |
| +--------------+ v | | +--------------+ v |
skipping to change at page 11, line 40 skipping to change at page 10, line 47
anchor PKC fall out of scope. anchor PKC fall out of scope.
The PKI System contains a mechanism for handling Admin’s The PKI System contains a mechanism for handling Admin’s
authorization requests and PKC enrollments. This mechanism is authorization requests and PKC enrollments. This mechanism is
referred to as the Registration Authority (RA). The PKI System referred to as the Registration Authority (RA). The PKI System
contains a Repository for Peers to retrieve each other’s PKCs and contains a Repository for Peers to retrieve each other’s PKCs and
revocation information. Last, the PKI System contains the core revocation information. Last, the PKI System contains the core
function of a CA that uses a public and private key pair and signs function of a CA that uses a public and private key pair and signs
PKCs. PKCs.
2.3 VPN-PKI Interaction 2.3 VPN-PKI Interaction
The interaction between the VPN System and the PKI System is the key The interaction between the VPN System and the PKI System is the key
focus of this requirements document, as shown in Figure 3. It is focus of this requirements document, as shown in Figure 3. It is
therefore sensible to consider the steps necessary to set up, use and therefore sensible to consider the steps necessary to set up, use and
IPsec Certificate Management Profile
manage PKCs for one Peer to establish an association with another manage PKCs for one Peer to establish an association with another
Peer. Peer.
IPsec Certificate Management Profile
+-----------------------------------------------+ +-----------------------------------------------+
| PKI System | | PKI System |
| | | |
| +--------------+ | | +--------------+ |
| | Repository | +----+ +----+ | | | Repository | +----+ +----+ |
| | Certs & CRLs | | CA | | RA | | | | Certs & CRLs | | CA | | RA | |
| +--------------+ +----+ +----+ | | +--------------+ +----+ +----+ |
| | | |
+-----------------------------------------------+ +-----------------------------------------------+
^ ^ ^ ^ ^ ^
skipping to change at page 12, line 53 skipping to change at page 12, line 4
[L] = Lifecycle: Rekey, renewal, update, revocation, and [L] = Lifecycle: Rekey, renewal, update, revocation, and
confirmation confirmation
[R] = Repository: Posting and lookups [R] = Repository: Posting and lookups
Figure 3. Architectural Framework for VPN-PKI Interaction Figure 3. Architectural Framework for VPN-PKI Interaction
Requirements for each of the interactions, [A], [G], [E], [L], and Requirements for each of the interactions, [A], [G], [E], [L], and
[R], are addressed in paragraphs 3.2-3.6. However, only requirements [R], are addressed in paragraphs 3.2-3.6. However, only requirements
for [A], [E], [L], and [R] will be addressed by the certificate for [A], [E], [L], and [R] will be addressed by the certificate
management profile. Requirements for [I] transactions are beyond the management profile. Requirements for [I] transactions are beyond the
IPsec Certificate Management Profile
scope of this document. Additionally, the act of certification (i.e., scope of this document. Additionally, the act of certification (i.e.,
binding the public key to the name) is performed at the CA and is not binding the public key to the name) is performed at the CA and is not
shown in the Figure. shown in the Figure.
IPsec Certificate Management Profile 3 Requirements
3 Requirements
3.1 General Requirements 3.1 General Requirements
3.1.1 One Protocol 3.1.1 One Protocol
The target profile, to be based on this requirements document, MUST The target profile, to be based on this requirements document, MUST
call for ONE PROTOCOL or ONE USE PROFILE for each main element of the call for ONE PROTOCOL or ONE USE PROFILE for each main element of the
[A], [E], [L], and [R] interactions. It is a specific goal to avoid [A], [E], [L], and [R] interactions. It is a specific goal to avoid
multiple competing protocols or profiles to solve the same multiple competing protocols or profiles to solve the same
requirement whenever possible to reduce complexity and improve requirement whenever possible to reduce complexity and improve
interoperability. interoperability.
Meeting some of the requirements may necessitate the creation of a Meeting some of the requirements may necessitate the creation of a
new protocol or new extension for an existing protocol; however, the new protocol or new extension for an existing protocol; however, the
latter is much preferred. latter is much preferred.
3.1.2 Secure Transactions 3.1.2 Secure Transactions
The target certificate management profile MUST specify the [A], [E], The target certificate management profile MUST specify the [A], [E],
[L], and [R] transactions between VPN and PKI Systems. To support [L], and [R] transactions between VPN and PKI Systems. To support
these transactions, the Admin and PKI MUST exchange policy details, these transactions, the Admin and PKI MUST exchange policy details,
identities, and keys. As such, the method of communication for [A], identities, and keys. As such, the method of communication for [A],
[E], and [L] transactions MUST be secured in a manner that ensures [E], and [L] transactions MUST be secured in a manner that ensures
privacy, authentication, and message data integrity. The privacy, authentication, and message data integrity. The
communication method MUST require that mutual trust be established communication method MUST require that mutual trust be established
between the PKI and the Admin. See paragraph 3.7.1. [R] transactions between the PKI and the Admin. See paragraph 3.7.1. [R] transactions
do not require authentication or message data integrity because the do not require authentication or message data integrity because the
responses (i.e., PKCs and CRLs) are already digital signed. Whether responses (i.e., PKCs and CRLs) are already digital signed. Whether
[R] transactions require privacy is determined by the local security [R] transactions require privacy is determined by the local security
policy. policy.
The target certificate management profile will not specify [G] The target certificate management profile will not specify [G]
transactions; however, these transactions MUST be secured in a manner transactions; however, these transactions MUST be secured in a manner
that ensures privacy, authentication, and message data integrity that ensures privacy, authentication, and message data integrity
because these transactions are the basis for the other transactions. because these transactions are the basis for the other transactions.
3.1.3 Admin Availability 3.1.3 Admin Availability
The Admin MUST be reachable by the Peers. Most implementations will The Admin MUST be reachable by the Peers. Most implementations will
meet this requirement by ensuring Peers can connect to the Admin from meet this requirement by ensuring Peers can connect to the Admin from
anywhere on the network or Internet. However, communication between anywhere on the network or Internet. However, communication between
IPsec Certificate Management Profile
the Admin and Peers can be "off-line". It can, in some environments, the Admin and Peers can be "off-line". It can, in some environments,
be "moving media" (i.e., the configuration or data is loaded on to a be "moving media" (i.e., the configuration or data is loaded on to a
floppy disk or other media and physically moved to the IPsec Peers). floppy disk or other media and physically moved to the IPsec Peers).
IPsec Certificate Management Profile
Likewise, it can be entered directly on the IPsec Peer via a User Likewise, it can be entered directly on the IPsec Peer via a User
Interface (UI). In this case, the Admin function is co-located on the Interface (UI). In this case, the Admin function is co-located on the
Peer device itself. Most requirements and scenarios in this document Peer device itself. Most requirements and scenarios in this document
assume on-line availability of the Admin for the life of the VPN assume on-line availability of the Admin for the life of the VPN
System. System.
3.1.3 PKI Availability 3.1.3 PKI Availability
Availability is REQUIRED initially for authorization transactions Availability is REQUIRED initially for authorization transactions
between the PKI and Admin. Further availability is required in most between the PKI and Admin. Further availability is required in most
cases, but the extent of this availability is a decision point for cases, but the extent of this availability is a decision point for
the Operator. Most requirements and scenarios in this document assume the Operator. Most requirements and scenarios in this document assume
on-line availability of the PKI for the life of the VPN System. on-line availability of the PKI for the life of the VPN System.
Off-line interaction between the VPN and PKI Systems (i.e., where Off-line interaction between the VPN and PKI Systems (i.e., where
physical media is used as the transport method) is beyond the scope physical media is used as the transport method) is beyond the scope
of this document. of this document.
3.1.4 End-User Transparency 3.1.4 End-User Transparency
PKI interactions are to be transparent to the user. Users SHOULD NOT PKI interactions are to be transparent to the user. Users SHOULD NOT
even be aware that PKI is in use. First time connections SHOULD even be aware that PKI is in use. First time connections SHOULD
consist of no more than a prompt for some identification and pass consist of no more than a prompt for some identification and pass
phrase, and a status bar notifying the user that setup is in phrase, and a status bar notifying the user that setup is in
progress. progress.
3.1.5 PKC Profile for PKI Interaction 3.1.5 PKC Profile for PKI Interaction
A PKC used for identity in VPN-PKI transactions MUST include all the A PKC used for identity in VPN-PKI transactions MUST include all the
[CERTPROFILE] mandatory fields. It MUST also contain contents [CERTPROFILE] mandatory fields. It MUST also contain contents
necessary to support path validation and certificate status checking. necessary to support path validation and certificate status checking.
It is preferable that the PKC profiles for IPsec transactions It is preferable that the PKC profiles for IPsec transactions
[IKECERTPROFILE] and VPN-PKI transactions (in the certificate [IKECERTPROFILE] and VPN-PKI transactions (in the certificate
management profile) are the same so that one PKC could be used for management profile) are the same so that one PKC could be used for
both transaction sets. If the profiles are inconsistent then both transaction sets. If the profiles are inconsistent then
different PKCs (and perhaps different processing requirements) might different PKCs (and perhaps different processing requirements) might
be required. However, the authors urge that process on other aspects be required. However, the authors urge that process on other aspects
of this standardization effort continue regardless of the status of of this standardization effort continue regardless of the status of
efforts to achieve PKC profile consensus. efforts to achieve PKC profile consensus.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.1.5.1 Identity 3.1.5.1 Identity
PKCs MUST support identifying (i.e., naming) Peers and Admins. The PKCs MUST support identifying (i.e., naming) Peers and Admins. The
following name forms MUST be supported: following name forms MUST be supported:
- Fully-Qualified Domain Name (FQDN) - Fully-Qualified Domain Name (FQDN)
- RFC 822 (also called USER FQDN) - RFC 822 (also called USER FQDN)
- IPv4 Address - IPv4 Address
- IPv6 Address - IPv6 Address
3.1.5.2 Key Usage 3.1.5.2 Key Usage
PKCs MUST support indicating the purposes for which the key (i.e., PKCs MUST support indicating the purposes for which the key (i.e.,
digital signature) can be used. Further, PKCs MUST always indicate digital signature) can be used. Further, PKCs MUST always indicate
that relying parties (i.e., Peers) need to understand the indication. that relying parties (i.e., Peers) need to understand the indication.
3.1.5.3 Extended Key Usage 3.1.5.3 Extended Key Usage
Extended Key Usage (EKU) indications are not required. The presence Extended Key Usage (EKU) indications are not required. The presence
or lack of an EKU MUST NOT cause an implementation to fail an IKE or lack of an EKU MUST NOT cause an implementation to fail an IKE
connection. connection.
3.1.5.4 Revocation Information Location 3.1.5.4 Revocation Information Location
PKCs MUST indicate the location of CRL such that any Peer who holds PKCs MUST indicate the location of CRL such that any Peer who holds
the PKC locally will know exactly where to go and how to request the the PKC locally will know exactly where to go and how to request the
CRL. CRL.
3.1.6 Error Handling 3.1.6 Error Handling
The protocol for the VPN-PKI transactions MUST specify error handling The protocol for the VPN-PKI transactions MUST specify error handling
for each transaction. Thorough error condition descriptions and for each transaction. Thorough error condition descriptions and
handling instructions will greatly aid interoperability efforts handling instructions will greatly aid interoperability efforts
between the PKI and VPN System products. between the PKI and VPN System products.
3.2 Authorization 3.2 Authorization
This section refers to the [A] elements labeled in Figure 3. This section refers to the [A] elements labeled in Figure 3.
3.2.1 One Protocol 3.2.1 One Protocol
One protocol MUST be specified for these Admin to PKI (RA/CA) One protocol MUST be specified for these Admin to PKI (RA/CA)
interaction. This protocol MUST support privacy, authorization, interaction. This protocol MUST support privacy, authorization,
IPsec Certificate Management Profile IPsec Certificate Management Profile
authentication, and integrity. PKCs for authorization of the Admin authentication, and integrity. PKCs for authorization of the Admin
can be initialized through an out-of-band mechanism. can be initialized through an out-of-band mechanism.
The transport used to carry the authorization SHOULD be reliable The transport used to carry the authorization SHOULD be reliable
(TCP). (TCP).
The protocol SHOULD be as lightweight as possible. The protocol SHOULD be as lightweight as possible.
3.2.2 Bulk Authorization 3.2.2 Bulk Authorization
Bulk authorization MUST be supported by the certificate management Bulk authorization MUST be supported by the certificate management
profile. Bulk authorization occurs when the Admin requests of the PKI profile. Bulk authorization occurs when the Admin requests of the PKI
that authorization be established for several different subjects with that authorization be established for several different subjects with
almost the same contents. A minimum of one value (more is also almost the same contents. A minimum of one value (more is also
acceptable) differs per subject. Because the authorizations may occur acceptable) differs per subject. Because the authorizations may occur
before any keys have been generated, the only way to ensure unique before any keys have been generated, the only way to ensure unique
authorization identifiers are issued is to have at least one value authorization identifiers are issued is to have at least one value
differ per subject. differ per subject.
skipping to change at page 17, line 7 skipping to change at page 16, line 7
PKI at the same time. Both of these authorization scenarios MUST be PKI at the same time. Both of these authorization scenarios MUST be
supported. supported.
A bulk authorization SHOULD occur in one single connection to the PKI A bulk authorization SHOULD occur in one single connection to the PKI
(RA/CA), with the number of subjects being one or greater. (RA/CA), with the number of subjects being one or greater.
Implementations SHOULD be able to handle one thousand subjects in a Implementations SHOULD be able to handle one thousand subjects in a
batch authorization. batch authorization.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.2.3 Authorization Scenario 3.2.3 Authorization Scenario
The authorization scenario for VPN-PKI transactions involves a two- The authorization scenario for VPN-PKI transactions involves a two-
step process: an authorization request and an authorization step process: an authorization request and an authorization
response. Figure 4 shows the salient interactions to perform response. Figure 4 shows the salient interactions to perform
authorization transactions. authorization transactions.
+--------------+ +-----------------------+ +--------------+ +-----------------------+
| Repository | | CA/RA | | Repository | | CA/RA |
+--------------+ +-----------------------+ +--------------+ +-----------------------+
^ ^
skipping to change at page 17, line 42 skipping to change at page 16, line 42
1) Authorization [A]. Admin sends a list of identities and PKC 1) Authorization [A]. Admin sends a list of identities and PKC
contents for the PKI System to authorize enrollment. See paragraph contents for the PKI System to authorize enrollment. See paragraph
3.2.4. 3.2.4.
2) Authorization Response [A]. The PKI returns a list of unique 2) Authorization Response [A]. The PKI returns a list of unique
authorization identifiers and one-time authorization tokens to be authorization identifiers and one-time authorization tokens to be
used for the enrollment of each PKC (1). Response may indicate used for the enrollment of each PKC (1). Response may indicate
success, failure, or errors for any particular authorization. See success, failure, or errors for any particular authorization. See
paragraph 3.2.5. paragraph 3.2.5.
3.2.4 Authorization Request 3.2.4 Authorization Request
3.2.4.1 Specifying Fields within the PKC 3.2.4.1 Specifying Fields within the PKC
The Admin authorizes individual PKCs or batches of PKC issuances The Admin authorizes individual PKCs or batches of PKC issuances
based on a pre-agreed template. This template is agreed by the VPN based on a pre-agreed template. This template is agreed by the VPN
Operator and PKI Operator and is referred to in each authorization Operator and PKI Operator and is referred to in each authorization
request. This allows the authorization requests to include the request. This allows the authorization requests to include the
minimal amount of information necessary to support a VPN System. minimal amount of information necessary to support a VPN System.
IPsec Certificate Management Profile IPsec Certificate Management Profile
The Admin can send the PKI System the set of PKC contents that it The Admin can send the PKI System the set of PKC contents that it
wants the PKI to issue to a group of IPsec Peers. In other words, it wants the PKI to issue to a group of IPsec Peers. In other words, it
tells the PKI System, "if you see a PKC request that looks like this, tells the PKI System, "if you see a PKC request that looks like this,
from this person, process it and issue the PKC." from this person, process it and issue the PKC."
Requirements for PKC fields used in IPsec transactions are specified Requirements for PKC fields used in IPsec transactions are specified
in [IKECERTPROFILE]. in [IKECERTPROFILE].
Requirements for PKC fields used in VPN-PKI transactions are Requirements for PKC fields used in VPN-PKI transactions are
specified in paragraph 3.1.5. specified in paragraph 3.1.5.
3.2.4.2 Authorizations for Renewal, Update, and Rekey 3.2.4.2 Authorizations for Renewal, Update, and Rekey
When the VPN Operator and PKI Operator pre-agree on a template, they When the VPN Operator and PKI Operator pre-agree on a template, they
MUST also agree on the local policy regarding PKC renewal and PKC MUST also agree on the local policy regarding PKC renewal and PKC
update. These are: update. These are:
- Admin MUST specify if automatic renewals are allowed, that is, - Admin MUST specify if automatic renewals are allowed, that is,
the Admin authorizes the PKI to process a future renewal for the the Admin authorizes the PKI to process a future renewal for the
specified Peer PKC. specified Peer PKC.
- Admin MUST specify if PKC update is allowed, that is, the Admin - Admin MUST specify if PKC update is allowed, that is, the Admin
skipping to change at page 19, line 7 skipping to change at page 18, line 7
- Specify at how long before the PKC expiration date the PKI will - Specify at how long before the PKC expiration date the PKI will
accept and process an update (i.e., N% of validity period, or accept and process an update (i.e., N% of validity period, or
the UTC time after which update is permitted). the UTC time after which update is permitted).
A new authorization by the Admin is REQUIRED for PKC rekey. No A new authorization by the Admin is REQUIRED for PKC rekey. No
parameters of prior authorizations need be considered. parameters of prior authorizations need be considered.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.2.4.3 Other Authorization Elements 3.2.4.3 Other Authorization Elements
The Admin MUST have the ability to specify the format for the The Admin MUST have the ability to specify the format for the
authorization ID and one-time authorization token. The one-time authorization ID and one-time authorization token. The one-time
authorization token SHOULD be unique per authorization ID. The more authorization token SHOULD be unique per authorization ID. The more
randomness that can be achieved in the relationship between an randomness that can be achieved in the relationship between an
authorization ID and its one-time authorization token, the better. authorization ID and its one-time authorization token, the better.
The one-time authorization token MUST be in UTF8 format to avoid The one-time authorization token MUST be in UTF8 format to avoid
incompatibilities that may occur due to international characters. It incompatibilities that may occur due to international characters. It
MUST support normalization as in [CERTPROFILE]. The Admin MUST have MUST support normalization as in [CERTPROFILE]. The Admin MUST have
the ability to constrain the UTF8 character set. the ability to constrain the UTF8 character set.
skipping to change at page 19, line 31 skipping to change at page 18, line 31
validation period is set, any PKC requests using this authorization validation period is set, any PKC requests using this authorization
ID and one-time authorization token that arrive at the PKI outside of ID and one-time authorization token that arrive at the PKI outside of
the validation period MUST be dropped and the event logged. the validation period MUST be dropped and the event logged.
The Protocol SHOULD consider what happens when Admin requested The Protocol SHOULD consider what happens when Admin requested
information conflicts with PKI settings such that the Admin request information conflicts with PKI settings such that the Admin request
cannot be issued as requested (e.g., Admin requests validation period cannot be issued as requested (e.g., Admin requests validation period
= 3 weeks and CA is configured to only allow validation periods = 1 = 3 weeks and CA is configured to only allow validation periods = 1
week). Proper conflict handling MUST be specified. week). Proper conflict handling MUST be specified.
3.2.4.4 Cancel Capability 3.2.4.4 Cancel Capability
Either the Admin or the Peer can send a cancel authorization message Either the Admin or the Peer can send a cancel authorization message
to PKI. The canceling entity MUST provide the authorization ID and to PKI. The canceling entity MUST provide the authorization ID and
one-time authorization token in order to cancel the authorization. At one-time authorization token in order to cancel the authorization. At
that point, the authorization will be erased from the PKI, and a log that point, the authorization will be erased from the PKI, and a log
entry of the event written. entry of the event written.
After the cancellation has been verified (a Cancel, Cancel ACK, ACK After the cancellation has been verified (a Cancel, Cancel ACK, ACK
type of a process is REQUIRED to cover a lost connections scenario), type of a process is REQUIRED to cover a lost connections scenario),
the PKI will accept a new authorization request with the exact same the PKI will accept a new authorization request with the exact same
skipping to change at page 20, line 7 skipping to change at page 19, line 7
The PKI MUST NOT process duplicate authorization requests. The PKI MUST NOT process duplicate authorization requests.
Note that if the PKI has already issued a PKC associated with an Note that if the PKI has already issued a PKC associated with an
authorization, then cancellation of the authorization is not authorization, then cancellation of the authorization is not
possible and the authorization request SHOULD be refused by the PKI. possible and the authorization request SHOULD be refused by the PKI.
Once a PKC has been issued it MUST be revoked in accordance with Once a PKC has been issued it MUST be revoked in accordance with
clause 3.6. clause 3.6.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.2.5 Authorization Response 3.2.5 Authorization Response
If the authorization request is acceptable, the PKI will respond to If the authorization request is acceptable, the PKI will respond to
the Admin with a unique authorization identifier per subject the Admin with a unique authorization identifier per subject
authorization requested and a one-time authorization token per authorization requested and a one-time authorization token per
authorization ID. See paragraph 3.2.4.3 for additional authorization authorization ID. See paragraph 3.2.4.3 for additional authorization
ID and one-time authorization token requirements. ID and one-time authorization token requirements.
The PKI can alter parameters of the authorization request submitted The PKI can alter parameters of the authorization request submitted
by the Admin. In that event, the PKI MUST return all the contents of by the Admin. In that event, the PKI MUST return all the contents of
the authorization request (as modified) to the Admin with the the authorization request (as modified) to the Admin with the
skipping to change at page 20, line 33 skipping to change at page 19, line 33
After receiving a bulk authorization request from the Admin, the PKI After receiving a bulk authorization request from the Admin, the PKI
MUST be able to reply YES to those individual PKC authorizations that MUST be able to reply YES to those individual PKC authorizations that
it has satisfied and NO or FAILED for those requests that cannot be it has satisfied and NO or FAILED for those requests that cannot be
satisfied, along with sufficient reason or error codes. satisfied, along with sufficient reason or error codes.
A method is REQUIRED to identify if there is a change in PKI setting A method is REQUIRED to identify if there is a change in PKI setting
between the time the authorization is granted and PKC request occurs, between the time the authorization is granted and PKC request occurs,
and what to do about the discrepancy. and what to do about the discrepancy.
3.2.5.1 Error Handling for Authorization 3.2.5.1 Error Handling for Authorization
Thorough error condition descriptions and handling instructions MUST Thorough error condition descriptions and handling instructions MUST
be provided to the Admin for each transaction in the authorization be provided to the Admin for each transaction in the authorization
process. Providing such error codes will greatly aid interoperability process. Providing such error codes will greatly aid interoperability
efforts between the PKI and IPsec products. efforts between the PKI and IPsec products.
3.3 Generation 3.3 Generation
This section refers to the [G] elements labeled in Figure 3. This section refers to the [G] elements labeled in Figure 3.
Once the PKI System has responded with authorization identifiers and Once the PKI System has responded with authorization identifiers and
authorization tokens (see paragraph 3.2), and this information is authorization tokens (see paragraph 3.2), and this information is
received at the Admin, the next step is to generate public and received at the Admin, the next step is to generate public and
private key pairs and to construct PKC requests using those key private key pairs and to construct PKC requests using those key
pairs. The key generations can occur at one of three places, pairs. The key generations can occur at one of three places,
depending on local requirements: at the IPsec Peer, at the Admin, or depending on local requirements: at the IPsec Peer, at the Admin, or
at the PKI. The PKC request can come from either the IPsec Peer, a at the PKI. The PKC request can come from either the IPsec Peer, a
combination of the Peer and the Admin, or not at all. combination of the Peer and the Admin, or not at all.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.3.1 Generation Method 1: IPsec Peer Generates Key Pair, Constructs 3.3.1 Generation Method 1: IPsec Peer Generates Key Pair, Constructs
PKC Request, and Signs PKC Request PKC Request, and Signs PKC Request
This option will be used most often in the field. This is the most This option will be used most often in the field. This is the most
secure method for keying, as the keys are generated on the end entity secure method for keying, as the keys are generated on the end entity
and the private key never leaves the end entity. However, it is the and the private key never leaves the end entity. However, it is the
most computationally intensive for the Peer as it must be "ASN.1 most computationally intensive for the Peer as it must be "ASN.1
aware" to support generating and digitally signing the PKC request. aware" to support generating and digitally signing the PKC request.
+--------------+ +-----------------------+ +--------------+ +-----------------------+
| Repository | | CA/RA | | Repository | | CA/RA |
skipping to change at page 22, line 7 skipping to change at page 21, line 7
2) Generation [G]. Peer receives authorization identifier, one-time 2) Generation [G]. Peer receives authorization identifier, one-time
authorization token, and any parameters. Peer generates key pair and authorization token, and any parameters. Peer generates key pair and
constructs PKC request. constructs PKC request.
Steps prior to these can be found in paragraph 3.2. The next step, Steps prior to these can be found in paragraph 3.2. The next step,
enrollment, can occur either directly between the Peer and PKI (see enrollment, can occur either directly between the Peer and PKI (see
paragraph 3.4.5) or through the Admin (see paragraph 3.4.6). paragraph 3.4.5) or through the Admin (see paragraph 3.4.6).
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.3.2 Generation Method 2: IPsec Peer Generates Key Pair, Admin 3.3.2 Generation Method 2: IPsec Peer Generates Key Pair, Admin
Constructs PKC Request, Admin Signs PKC Request Constructs PKC Request, Admin Signs PKC Request
This option also supports IPsec Peer generation of key pair, but This option also supports IPsec Peer generation of key pair, but
removes the requirement for the Peer to be ASN.1 aware because it removes the requirement for the Peer to be ASN.1 aware because it
does not have to construct or digitally sign the PKC request. The does not have to construct or digitally sign the PKC request. The
drawback is that the key pair does need to be provided to the Admin. drawback is that the key pair does need to be provided to the Admin.
+--------------+ +-----------------------+ +--------------+ +-----------------------+
| Repository | | CA/RA | | Repository | | CA/RA |
+--------------+ +-----------------------+ +--------------+ +-----------------------+
skipping to change at page 23, line 7 skipping to change at page 22, line 7
3) Opaque transaction [G]. Peer returns key pair to Admin. 3) Opaque transaction [G]. Peer returns key pair to Admin.
4) Generation [G]. Admin constructs and digitally signs PKC request. 4) Generation [G]. Admin constructs and digitally signs PKC request.
Steps prior to these can be found in paragraph 3.2. The next step, Steps prior to these can be found in paragraph 3.2. The next step,
enrollment, occurs through the Admin (see paragraph 3.4.7). enrollment, occurs through the Admin (see paragraph 3.4.7).
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.3.3 Generation Method 3: Admin Generates Key Pair, Constructs PKC 3.3.3 Generation Method 3: Admin Generates Key Pair, Constructs PKC
Request, and Signs PKC Request Request, and Signs PKC Request
This option exists for deployments where Peers cannot generate their This option exists for deployments where Peers cannot generate their
own key pairs. Some examples are for PDAs and handsets where to own key pairs. Some examples are for PDAs and handsets where to
generate an RSA key would be operationally impossible due to generate an RSA key would be operationally impossible due to
processing and battery constraints. Another case covers key recovery processing and battery constraints. Another case covers key recovery
requirements, where the same PKCs are used for other functions in requirements, where the same PKCs are used for other functions in
addition to IPsec, and key recovery is required (e.g. local data addition to IPsec, and key recovery is required (e.g. local data
encryption), therefore key escrow is needed off the Peer. If key encryption), therefore key escrow is needed off the Peer. If key
escrow is performed then the exact requirements and procedures for it escrow is performed then the exact requirements and procedures for it
skipping to change at page 24, line 7 skipping to change at page 23, line 7
template, Subject fields, SubjectAltName fields and more are part of template, Subject fields, SubjectAltName fields and more are part of
the request, and must be communicated in some way from the Admin to the request, and must be communicated in some way from the Admin to
the PKI. Instead of creating a new mechanism, the authorization the PKI. Instead of creating a new mechanism, the authorization
schema can be reused. This also allows for the feature of role-based schema can be reused. This also allows for the feature of role-based
administration, where Operator 1 is the only one allowed to have the administration, where Operator 1 is the only one allowed to have the
Admin function pre-authorize PKCs, but Operator 2 is the one doing Admin function pre-authorize PKCs, but Operator 2 is the one doing
batch enrollments and VPN device configurations. batch enrollments and VPN device configurations.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.3.4 Method 4: PKI Generates Key Pair 3.3.4 Method 4: PKI Generates Key Pair
This option exists for deployments where end entities cannot generate This option exists for deployments where end entities cannot generate
their own key pairs and the Admin function is a minimal their own key pairs and the Admin function is a minimal
implementation. The PKI and Admin pre-agree to have the PKI generate implementation. The PKI and Admin pre-agree to have the PKI generate
key pairs and PKCs. This is, in all likelihood, the easiest way to key pairs and PKCs. This is, in all likelihood, the easiest way to
deploy PKCs, though it sacrifices some security since both the CA and deploy PKCs, though it sacrifices some security since both the CA and
the Admin have access to the private key. However, in cases where key the Admin have access to the private key. However, in cases where key
escrow is required, this may be acceptable. The Admin effectively escrow is required, this may be acceptable. The Admin effectively
acts as a proxy for the Peer in the PKC enrollment process. acts as a proxy for the Peer in the PKC enrollment process.
skipping to change at page 24, line 39 skipping to change at page 23, line 39
+--------------------+ +--------+ +--------------------+ +--------+
Figure 8. Generation Interactions: Figure 8. Generation Interactions:
IPsec Peer Generates Key Pair, Admin Constructs PKC Request IPsec Peer Generates Key Pair, Admin Constructs PKC Request
1) Generation [G] The PKI generates the key pair. 1) Generation [G] The PKI generates the key pair.
Steps prior to these can be found in paragraph 3.2. The next step, Steps prior to these can be found in paragraph 3.2. The next step,
enrollment, occurs through the Admin (see paragraph 3.4.9). enrollment, occurs through the Admin (see paragraph 3.4.9).
3.3.5 Error Handling for Generation 3.3.5 Error Handling for Generation
Thorough error condition descriptions and handling instructions MUST Thorough error condition descriptions and handling instructions MUST
be provided for each transaction in the key generation and PKC be provided for each transaction in the key generation and PKC
request construction process. Providing such error codes will greatly request construction process. Providing such error codes will greatly
aid interoperability efforts between the PKI and IPsec products. aid interoperability efforts between the PKI and IPsec products.
Error conditions MUST be communicated to the Admin regardless of who Error conditions MUST be communicated to the Admin regardless of who
generated the key or PKC request. generated the key or PKC request.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.4 Enrollment 3.4 Enrollment
This section refers to the [E] elements labeled in Figure 3. This section refers to the [E] elements labeled in Figure 3.
Regardless of where the keys were generated and the PKC request Regardless of where the keys were generated and the PKC request
constructed, an enrollment process will need to occur to request that constructed, an enrollment process will need to occur to request that
the PKI issue a PKC and the corresponding PKC be returned. the PKI issue a PKC and the corresponding PKC be returned.
The protocol MUST be exactly the same regardless of whether the The protocol MUST be exactly the same regardless of whether the
enrollment occurs from the Peer to the PKI or from the Admin to the enrollment occurs from the Peer to the PKI or from the Admin to the
PKI. PKI.
3.4.1 One protocol 3.4.1 One protocol
One protocol MUST be specified for enrollment requests, responses, One protocol MUST be specified for enrollment requests, responses,
and confirmations. and confirmations.
3.4.2 On-line protocol 3.4.2 On-line protocol
The protocol MUST support enrollment that occurs over the Internet The protocol MUST support enrollment that occurs over the Internet
and without the need for manual intervention. and without the need for manual intervention.
3.4.3 Single Connection with Immediate Response 3.4.3 Single Connection with Immediate Response
Enrollment requests and responses MUST be able to occur in one on- Enrollment requests and responses MUST be able to occur in one on-
line connection between the Admin on behalf of the Peer or the Peer line connection between the Admin on behalf of the Peer or the Peer
itself and the PKI (RA/CA). itself and the PKI (RA/CA).
3.4.4 Manual Approval Option 3.4.4 Manual Approval Option
Manual approval of PKC enrollments is too time consuming for large Manual approval of PKC enrollments is too time consuming for large
scale implementations, and is therefore not required. scale implementations, and is therefore not required.
3.4.5 Enrollment Method 1: Peer Enrolls to PKI Directly 3.4.5 Enrollment Method 1: Peer Enrolls to PKI Directly
In this case, the IPsec Peer only communicates with the PKI after In this case, the IPsec Peer only communicates with the PKI after
being commanded to do so by the Admin. This enrollment mode is being commanded to do so by the Admin. This enrollment mode is
depicted in Figure 9 and the letters in the following description depicted in Figure 9 and the letters in the following description
refer to Figure 3. Prior authorization (see paragraph 3.2) and refer to Figure 3. Prior authorization (see paragraph 3.2) and
generation (see paragraph 3.3.1) steps are not shown. generation (see paragraph 3.3.1) steps are not shown.
IPsec Certificate Management Profile IPsec Certificate Management Profile
Most IPsec Systems have enough CPU power to generate a public and Most IPsec Systems have enough CPU power to generate a public and
skipping to change at page 27, line 7 skipping to change at page 26, line 7
suitable error indication. suitable error indication.
3) Enrollment Confirmation [E]. Peer positively acknowledges receipt 3) Enrollment Confirmation [E]. Peer positively acknowledges receipt
of new PKC. of new PKC.
4) Enrollment Confirmation Receipt [E]. PKI sends enrollment 4) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Peer. confirmation receipt back to the Peer.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.4.6 Enrollment Method 2a: Peer Enrolls through Admin 3.4.6 Enrollment Method 2a: Peer Enrolls through Admin
In this case, the IPsec Peer has generated the key pair and the PKC In this case, the IPsec Peer has generated the key pair and the PKC
request, but does not enroll directly to the PKI System. Instead, it request, but does not enroll directly to the PKI System. Instead, it
automatically sends its request to the Admin, and the Admin redirects automatically sends its request to the Admin, and the Admin redirects
the enrollment to the PKI System. The PKI System does not care where the enrollment to the PKI System. The PKI System does not care where
the enrollment comes from, as long as it is a valid enrollment. Once the enrollment comes from, as long as it is a valid enrollment. Once
the Admin receives the PKC response, it automatically forwards it to the Admin receives the PKC response, it automatically forwards it to
the IPsec Peer. the IPsec Peer.
Most IPsec Systems have enough CPU power to generate a public and Most IPsec Systems have enough CPU power to generate a public and
skipping to change at page 29, line 7 skipping to change at page 28, line 7
confirmation back to the PKI. confirmation back to the PKI.
7) Enrollment Confirmation Receipt [E]. PKI sends enrollment 7) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Admin. confirmation receipt back to the Admin.
8) Opaque Transaction [E]. Admin forwards PKI's enrollment 8) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the Peer. confirmation receipt back to the Peer.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.4.7 Enrollment Method 2b: Peer Enrolls Through Admin 3.4.7 Enrollment Method 2b: Peer Enrolls Through Admin
In this case, the IPsec Peer has generated the key pair, but the PKC In this case, the IPsec Peer has generated the key pair, but the PKC
request is constructed and signed by the Admin. The PKI System does request is constructed and signed by the Admin. The PKI System does
not care where the enrollment comes from, as long as it is a valid not care where the enrollment comes from, as long as it is a valid
enrollment. Once the Admin retrieves the PKC, it then automatically enrollment. Once the Admin retrieves the PKC, it then automatically
forwards it to the IPsec Peer along with the key pair. forwards it to the IPsec Peer along with the key pair.
Some IPsec Systems do not have enough CPU power to generate a public Some IPsec Systems do not have enough CPU power to generate a public
and private key pair of sufficient strength for secure IPsec. In this and private key pair of sufficient strength for secure IPsec. In this
case, the Admin needs to prove to the PKI that it has such a key case, the Admin needs to prove to the PKI that it has such a key
skipping to change at page 31, line 7 skipping to change at page 30, line 7
confirmation back to the PKI. confirmation back to the PKI.
6) Enrollment Confirmation Receipt [E]. PKI sends enrollment 6) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Admin. confirmation receipt back to the Admin.
7) Opaque Transaction [E]. Admin forwards PKI's enrollment 7) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the Peer. confirmation receipt back to the Peer.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.4.8 Enrollment Method 3a: Admin Authorizes and Enrolls Directly to 3.4.8 Enrollment Method 3a: Admin Authorizes and Enrolls Directly to
PKI PKI
In this case, the Admin generates the key pair, PKC request, and In this case, the Admin generates the key pair, PKC request, and
digitally signs the PKC request. The PKI System does not care where digitally signs the PKC request. The PKI System does not care where
the enrollment comes from, as long as it is a valid enrollment. Once the enrollment comes from, as long as it is a valid enrollment. Once
the Admin retrieves the PKC, it then automatically forwards it to the the Admin retrieves the PKC, it then automatically forwards it to the
IPsec Peer along with the key pair. IPsec Peer along with the key pair.
Some IPsec Systems do not have enough CPU power to generate a public Some IPsec Systems do not have enough CPU power to generate a public
and private key pair of sufficient strength for secure IPsec. In this and private key pair of sufficient strength for secure IPsec. In this
skipping to change at page 33, line 7 skipping to change at page 32, line 7
confirmation back to the PKI. confirmation back to the PKI.
6) Enrollment Confirmation Receipt [E]. PKI sends enrollment 6) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Admin. confirmation receipt back to the Admin.
7) Opaque Transaction [E]. Admin forwards PKI's enrollment 7) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the Peer. confirmation receipt back to the Peer.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.4.9 Enrollment Method 3b: Admin Authorizes and Enrolls Directly to 3.4.9 Enrollment Method 3b: Admin Authorizes and Enrolls Directly to
PKI PKI
In this instance, the PKI and Admin have previously agreed to have In this instance, the PKI and Admin have previously agreed to have
the PKI generate key and certificates when the PKI receives an the PKI generate key and certificates when the PKI receives an
authorization request. The PKI returns to the IPsec Peer through the authorization request. The PKI returns to the IPsec Peer through the
Admin, the final product of a key pair and PKC. Again, the mechanism Admin, the final product of a key pair and PKC. Again, the mechanism
for the Peer to Admin communication is opaque. for the Peer to Admin communication is opaque.
This enrollment mode is depicted in Figure 13 and the letters in the This enrollment mode is depicted in Figure 13 and the letters in the
following description refer to Figure 3. Prior authorization (see following description refer to Figure 3. Prior authorization (see
skipping to change at page 35, line 7 skipping to change at page 34, line 7
confirmation back to the PKI. confirmation back to the PKI.
5) Enrollment Confirmation Receipt [E]. PKI sends enrollment 5) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Admin. confirmation receipt back to the Admin.
6) Opaque Transaction [E]. Admin forwards PKI's enrollment 6) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the Peer. confirmation receipt back to the Peer.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.4.10 Confirmation Handshake 3.4.10 Confirmation Handshake
Any time a new PKC is issued by the PKI, a confirmation of PKC Any time a new PKC is issued by the PKI, a confirmation of PKC
receipt MUST be sent back to the PKI by the Peer or the Admin receipt MUST be sent back to the PKI by the Peer or the Admin
(forwarding the Peer’s confirmation). (forwarding the Peer’s confirmation).
Operationally, the Peer MUST send a confirmation to the PKI verifying Operationally, the Peer MUST send a confirmation to the PKI verifying
that it has received the PKC, loaded it, and can use it effectively that it has received the PKC, loaded it, and can use it effectively
in an IKE exchange. This requirement exists so that: in an IKE exchange. This requirement exists so that:
- The PKI does not publish the new PKC in the repository for others - The PKI does not publish the new PKC in the repository for others
skipping to change at page 36, line 7 skipping to change at page 35, line 7
The Admin MUST acknowledge the successful receipt of the The Admin MUST acknowledge the successful receipt of the
confirmation, thus signaling to the Peer that it may proceed using confirmation, thus signaling to the Peer that it may proceed using
this PKC in IKE connections. The PKI MUST complete all processing this PKC in IKE connections. The PKI MUST complete all processing
necessary to enable the Peer’s operational use of the new PKC (for necessary to enable the Peer’s operational use of the new PKC (for
example, writing the PKC to the repository) before sending the example, writing the PKC to the repository) before sending the
confirmation acknowledgement. The Peer MUST NOT begin using the PKC confirmation acknowledgement. The Peer MUST NOT begin using the PKC
until the PKI’s confirmation acknowledgement has been received. until the PKI’s confirmation acknowledgement has been received.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.4.11 Error Handling for Enrollment 3.4.11 Error Handling for Enrollment
Thorough error condition descriptions and handling instructions are Thorough error condition descriptions and handling instructions are
REQUIRED for each transaction in the enrollment process. Providing REQUIRED for each transaction in the enrollment process. Providing
such error codes will greatly aid interoperability efforts between such error codes will greatly aid interoperability efforts between
the PKI and IPsec products. the PKI and IPsec products.
The profile will clarify what happens if the request and retrieval The profile will clarify what happens if the request and retrieval
fails for some reason. The following cases MUST be covered: fails for some reason. The following cases MUST be covered:
- Admin or Peer cannot send the request. - Admin or Peer cannot send the request.
skipping to change at page 37, line 12 skipping to change at page 36, line 12
receives it, then the Peer MUST re-request with the same receives it, then the Peer MUST re-request with the same
authorization ID and one-time authorization token, and the PKI, authorization ID and one-time authorization token, and the PKI,
IPsec Certificate Management Profile IPsec Certificate Management Profile
seeing the authorization ID and authorization token, MUST send the seeing the authorization ID and authorization token, MUST send the
PKC again. PKC again.
Enrollment errors MUST be sent to the Admin regardless of entity that Enrollment errors MUST be sent to the Admin regardless of entity that
generated the enrollment request. generated the enrollment request.
3.5 Lifecycle 3.5 Lifecycle
This section refers to the [L] elements labeled in Figure 3. This section refers to the [L] elements labeled in Figure 3.
Once the PKI has issued a PKC for the end entity Peer, the Peer MUST Once the PKI has issued a PKC for the end entity Peer, the Peer MUST
be able to either contact the PKI directly or through the Admin for be able to either contact the PKI directly or through the Admin for
any subsequent renewals, updates, rekeys, or revocations. The PKI any subsequent renewals, updates, rekeys, or revocations. The PKI
MUST support either case for renewals, updates, and revocations. MUST support either case for renewals, updates, and revocations.
Rekeys are Admin initiated therefore Peer initiated rekeys MUST be Rekeys are Admin initiated therefore Peer initiated rekeys MUST be
transferred via the Admin. transferred via the Admin.
3.5.1 One Protocol 3.5.1 One Protocol
One protocol MUST be specified for rekey, renew, and update One protocol MUST be specified for rekey, renew, and update
requests, responses, and confirmations. It MUST be the same protocol requests, responses, and confirmations. It MUST be the same protocol
as is specified in paragraph 3.4. as is specified in paragraph 3.4.
Revocation requests MAY use the same protocol as rekey, renew, and Revocation requests MAY use the same protocol as rekey, renew, and
update operations. Revocation requests MAY also occur via email, update operations. Revocation requests MAY also occur via email,
telephone, Instant Messaging, etc. telephone, Instant Messaging, etc.
3.5.2 PKC Rekeys, Renewals, and Updates 3.5.2 PKC Rekeys, Renewals, and Updates
Renewals, updates, and rekeys are variants of a PKC enrollment Renewals, updates, and rekeys are variants of a PKC enrollment
request scenario with unique operational and management requirements. request scenario with unique operational and management requirements.
- A PKC rekey replaces an end entity's PKC with a new PKC that has a - A PKC rekey replaces an end entity's PKC with a new PKC that has a
new public key for the same SubjectName and SubjectAltName new public key for the same SubjectName and SubjectAltName
contents before the end entity’s currently held PKC expires. contents before the end entity’s currently held PKC expires.
- A PKC renewal replaces an end entity's PKC with the same public key - A PKC renewal replaces an end entity's PKC with the same public key
for the same SubjectName and SubjectAlternativeName contents as for the same SubjectName and SubjectAlternativeName contents as
skipping to change at page 39, line 10 skipping to change at page 38, line 10
occur once all connections that used the old PKC have expired. occur once all connections that used the old PKC have expired.
If a PKC has been revoked, it MUST NOT be allowed a renewal, update If a PKC has been revoked, it MUST NOT be allowed a renewal, update
or rekey. or rekey.
IPsec Certificate Management Profile IPsec Certificate Management Profile
Should the PKC expire without renewal, update or rekey, an entirely Should the PKC expire without renewal, update or rekey, an entirely
new request MUST be made. new request MUST be made.
3.5.2.1 Rekey Request 3.5.2.1 Rekey Request
Admins manage rekeys to ensure uninterrupted use of the VPN by Peers Admins manage rekeys to ensure uninterrupted use of the VPN by Peers
with new keys. Rekeys can occur automatically if the Admin is with new keys. Rekeys can occur automatically if the Admin is
configured to initiate a new authorization for the rekey. configured to initiate a new authorization for the rekey.
Scenarios for rekey are omitted as they use the same scenarios used Scenarios for rekey are omitted as they use the same scenarios used
in the original PKC enrollment from sections 3.2, 3.3, and 3.4. in the original PKC enrollment from sections 3.2, 3.3, and 3.4.
3.5.2.1 Renew Request 3.5.2.1 Renew Request
Admins manage renewals to ensure uninterrupted use of the VPN by Admins manage renewals to ensure uninterrupted use of the VPN by
Peers with the same key pair. Peers with the same key pair.
At the time of authorization, certain details about renewal At the time of authorization, certain details about renewal
acceptance will be conveyed by the Admin to the PKI, as stated in acceptance will be conveyed by the Admin to the PKI, as stated in
section 3.2.4.2. The renewal request MUST match the conditions that section 3.2.4.2. The renewal request MUST match the conditions that
were specified in the original authorization for: were specified in the original authorization for:
- Keys: New, existing, or either - Keys: New, existing, or either
- Requestor: End entity Peer, Admin, either - Requestor: End entity Peer, Admin, either
- Period: How soon before PKC expiry. - Period: How soon before PKC expiry.
- Time: Length of time before making the old PKC unusable. - Time: Length of time before making the old PKC unusable.
If any of these conditions are not met, the PKI must reject the If any of these conditions are not met, the PKI must reject the
renewal and log the event. renewal and log the event.
Scenarios for renewal are omitted as they use the same scenarios used Scenarios for renewal are omitted as they use the same scenarios used
in the original PKC enrollment from sections 3.2, 3.3, and 3.4. in the original PKC enrollment from sections 3.2, 3.3, and 3.4.
3.5.2.2 Update Request 3.5.2.2 Update Request
An update to the contents of a PKC will be necessary when details An update to the contents of a PKC will be necessary when details
about an end entity Peer’s identity change, but the Operator does not about an end entity Peer’s identity change, but the Operator does not
want to generate a new PKC from scratch, requiring a whole new want to generate a new PKC from scratch, requiring a whole new
authorization. For example, a gateway device may be moved from one authorization. For example, a gateway device may be moved from one
site to another. Its IPv4 Address will change in the SubjectAltName site to another. Its IPv4 Address will change in the SubjectAltName
extension, but all other information could stay the same. Another extension, but all other information could stay the same. Another
example is an end user who gets married and changes the last name or example is an end user who gets married and changes the last name or
moves from one department to another. In either case, only one field moves from one department to another. In either case, only one field
(the Surname or OU in the DN) need change. (the Surname or OU in the DN) need change.
skipping to change at page 40, line 46 skipping to change at page 39, line 46
during the PKC’s valid life. When such an update is desired, Admin during the PKC’s valid life. When such an update is desired, Admin
must notify the PKI System that an update is authorized for the end must notify the PKI System that an update is authorized for the end
entity, and to expect it coming, and specify the new contents. Admin entity, and to expect it coming, and specify the new contents. Admin
then initiates the update request with the given contents in whatever then initiates the update request with the given contents in whatever
mechanism the VPN System employs (direct from end entity to PKI, from mechanism the VPN System employs (direct from end entity to PKI, from
end entity through Admin, or directly from Admin). end entity through Admin, or directly from Admin).
Scenarios for update are omitted as they use the same scenarios used Scenarios for update are omitted as they use the same scenarios used
in the original PKC enrollment from sections 3.2, 3.3, and 3.4. in the original PKC enrollment from sections 3.2, 3.3, and 3.4.
3.5.2.3 Error Handling for Rekey, Renewal, and Update 3.5.2.3 Error Handling for Rekey, Renewal, and Update
Thorough error condition descriptions and handling instructions are Thorough error condition descriptions and handling instructions are
required for each transaction in the renewal, update or rekey required for each transaction in the renewal, update or rekey
process. Providing such error codes will greatly aid interoperability process. Providing such error codes will greatly aid interoperability
efforts between the PKI and IPsec products. efforts between the PKI and IPsec products.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.5.2.4 Confirmation Handshakes 3.5.2.4 Confirmation Handshakes
The confirmation handshake requirements are the same as in clauses The confirmation handshake requirements are the same as in clauses
3.2, 3.3, and 3.4 except that depending on the Adminitrative policy 3.2, 3.3, and 3.4 except that depending on the Adminitrative policy
the PKI MUST also issue a revocation on the original PKC before the PKI MUST also issue a revocation on the original PKC before
sending the confirmation response. sending the confirmation response.
3.5.3 Revocation 3.5.3 Revocation
The Peer MUST be able to initiate revocation for its own PKC. In this The Peer MUST be able to initiate revocation for its own PKC. In this
case the revocation request MUST be signed by the Peer’s current key case the revocation request MUST be signed by the Peer’s current key
pair for the PKC it wishes to revoke. Whether the actual revocation pair for the PKC it wishes to revoke. Whether the actual revocation
request transaction occurs directly with the PKI or is first sent to request transaction occurs directly with the PKI or is first sent to
Admin who proxies or forwards the request to the PKI is a matter of Admin who proxies or forwards the request to the PKI is a matter of
implementation. implementation.
The Admin MUST be able to initiate revocation for any PKC issued The Admin MUST be able to initiate revocation for any PKC issued
under a template it controls. The Admin will identify itself to the under a template it controls. The Admin will identify itself to the
skipping to change at page 42, line 7 skipping to change at page 41, line 7
NOT revoke its own PKC in this case. NOT revoke its own PKC in this case.
- AFTER UPDATE, BEFORE EXPIRATION: The PKI MUST be responsible for - AFTER UPDATE, BEFORE EXPIRATION: The PKI MUST be responsible for
the PKC revocation during an update transaction. PKI MUST revoke the PKC revocation during an update transaction. PKI MUST revoke
the PKC after receiving the confirm notification from the Peer, the PKC after receiving the confirm notification from the Peer,
and before sending the confirm-ack to the Peer. The Peer MUST and before sending the confirm-ack to the Peer. The Peer MUST
NOT revoke its own PKC in this case. NOT revoke its own PKC in this case.
IPsec Certificate Management Profile IPsec Certificate Management Profile
3.6 Repositories 3.6 Repositories
This section refers to the [R] elements labeled in Figure 3. This section refers to the [R] elements labeled in Figure 3.
3.6.1 Lookups 3.6.1 Lookups
The PKI System SHOULD be built so that lookups resolve directly and The PKI System SHOULD be built so that lookups resolve directly and
completely at the URL indicated in a CDP or AIA. The PKI SHOULD be completely at the URL indicated in a CDP or AIA. The PKI SHOULD be
built such that URL contents do not contain referrals to other hosts built such that URL contents do not contain referrals to other hosts
or URLs, as such referral lookups will increase the time to complete or URLs, as such referral lookups will increase the time to complete
the IKE negotiation, and can cause implementations to timeout. the IKE negotiation, and can cause implementations to timeout.
CDP MUST be flagged as required in the authorization request. The CDP MUST be flagged as required in the authorization request. The
method MUST also be specified: the HTTP method MUST be method; the method MUST also be specified: the HTTP method MUST be method; the
LDAP method MAY be supported. LDAP method MAY be supported.
skipping to change at page 43, line 14 skipping to change at page 42, line 14
IPsec Certificate Management Profile IPsec Certificate Management Profile
IPsec Peers should cache PKCs to reduce latency in setting up Phase IPsec Peers should cache PKCs to reduce latency in setting up Phase
1. Note that this is an operational issue, not an interoperability 1. Note that this is an operational issue, not an interoperability
issue. issue.
The use case for accomplishing lookups when PKCs are not sent in IKE The use case for accomplishing lookups when PKCs are not sent in IKE
is a stated non-goal of the profile at this time. is a stated non-goal of the profile at this time.
3.6.2 Error Handling for Repository Lookups 3.6.2 Error Handling for Repository Lookups
Thorough error condition descriptions and handling instructions are Thorough error condition descriptions and handling instructions are
required for each transaction in the repository lookup process. required for each transaction in the repository lookup process.
Providing such error codes will greatly aid interoperability efforts Providing such error codes will greatly aid interoperability efforts
between the PKI and IPsec products. between the PKI and IPsec products.
3.7 Trust 3.7 Trust
3.7.1 Trust Anchor PKC Acquisition 3.7.1 Trust Anchor PKC Acquisition
The root PKC MUST arrive on the Peer via one of two methods: The root PKC MUST arrive on the Peer via one of two methods:
(a) Peer can get the root PKC via its secure communication with (a) Peer can get the root PKC via its secure communication with
Admin. This requires the Peer to know less about interaction with the Admin. This requires the Peer to know less about interaction with the
PKI. PKI.
(b) Admin can command Peer to retrieve the root cert directly from (b) Admin can command Peer to retrieve the root cert directly from
the PKI. How retrieval of the root cert takes place is beyond scope, the PKI. How retrieval of the root cert takes place is beyond scope,
but is assumed to occur via an unauthenticated but confidential but is assumed to occur via an unauthenticated but confidential
enrollment protocol. enrollment protocol.
3.7.2 Certification Path Validation 3.7.2 Certification Path Validation
The IPsec Peer MUST perform identity verification based on the fields The IPsec Peer MUST perform identity verification based on the fields
of the PKC and parameters applicable to the VPN Security Association. of the PKC and parameters applicable to the VPN Security Association.
The fields of the PKC used for verification MAY include either the The fields of the PKC used for verification MAY include either the
X.500 Distinguished Name (DN) within the Subject Name, or a specific X.500 Distinguished Name (DN) within the Subject Name, or a specific
field within the Extension SubjectAltName (per [DOI] 4.6.2.1 field within the Extension SubjectAltName (per [DOI] 4.6.2.1
Identification Type Values). Usage descriptions for each follow. Identification Type Values). Usage descriptions for each follow.
The Peers or a SCVP server MUST validate the certification path, as The Peers or a SCVP server MUST validate the certification path, as
per RFC3280. The contents necessary in the PKC to allow this will be per RFC3280. The contents necessary in the PKC to allow this will be
skipping to change at page 44, line 12 skipping to change at page 43, line 12
itself, however Admin MUST be able to supply Peers with the trust itself, however Admin MUST be able to supply Peers with the trust
anchor and any chaining PKCs necessary. The Admin MAY ensure the anchor and any chaining PKCs necessary. The Admin MAY ensure the
IPsec Certificate Management Profile IPsec Certificate Management Profile
template uses the AIA extension in PKCs as a means of facilitating template uses the AIA extension in PKCs as a means of facilitating
path validation. path validation.
DNS MUST be supported by the Peers in order to support resolving URLs DNS MUST be supported by the Peers in order to support resolving URLs
present in CDPs and AIA extensions. present in CDPs and AIA extensions.
3.7.3 Revocation Checking and Status Information 3.7.3 Revocation Checking and Status Information
The PKI System MUST provide a mechanism whereby Peers can check the The PKI System MUST provide a mechanism whereby Peers can check the
revocation status of PKCs that are presented to it for IKE identity. revocation status of PKCs that are presented to it for IKE identity.
The mechanism should allow for access to extremely fresh revocation The mechanism should allow for access to extremely fresh revocation
information. CRLs have been chosen as the mechanism for communicating information. CRLs have been chosen as the mechanism for communicating
this information. Operators are RECOMMENDED to refresh CRLs as often this information. Operators are RECOMMENDED to refresh CRLs as often
as logistically possible. as logistically possible.
A single mandatory protocol mechanism for performing CRL lookups MUST A single mandatory protocol mechanism for performing CRL lookups MUST
be specified by the final specification. be specified by the final specification.
skipping to change at page 44, line 48 skipping to change at page 43, line 48
If the revocation of a PKC is used as the only means of deactivation If the revocation of a PKC is used as the only means of deactivation
of access authorization for the Peer (or user), then the speed of of access authorization for the Peer (or user), then the speed of
deactivation will be as rapid as the refresh rate of the CRL issued deactivation will be as rapid as the refresh rate of the CRL issued
and published by the PKI. If more immediate deactivation of access is and published by the PKI. If more immediate deactivation of access is
required than the CRL refreshing can provide, then another mechanism required than the CRL refreshing can provide, then another mechanism
for authorization that provides more immediate access deactivation for authorization that provides more immediate access deactivation
should be layered into the VPN deployment. Such a second mechanism is should be layered into the VPN deployment. Such a second mechanism is
out of the scope of this profile. (Examples are Xauth, L2TP’s out of the scope of this profile. (Examples are Xauth, L2TP’s
authentication, etc.). authentication, etc.).
3.7.4 Error Handling in Revocation Checking and Certificate Path 3.7.4 Error Handling in Revocation Checking and Certificate Path
Validation Validation
Thorough error condition descriptions and handling instructions are Thorough error condition descriptions and handling instructions are
required for each transaction in the revocation checking and path required for each transaction in the revocation checking and path
IPsec Certificate Management Profile IPsec Certificate Management Profile
validation process. Providing such error codes will greatly aid validation process. Providing such error codes will greatly aid
interoperability efforts between the PKI and IPsec products. interoperability efforts between the PKI and IPsec products.
4. Security Considerations 4 Security Considerations
This requirements document does not specify a concrete solution, and This requirements document does not specify a concrete solution, and
as such has no system-related security considerations per se. as such has no system-related security considerations per se.
However, the intent of the PKI4IPSEC WG was to profile and use However, the intent of the PKI4IPSEC WG was to profile and use
concrete protocols for certificate management (e.g., CMC, CMS, concrete protocols for certificate management (e.g., CMC, CMS,
CRMF). The individual security considerations of these protocols CRMF). The individual security considerations of these protocols
should be carefully considered in the profiling effort. should be carefully considered in the profiling effort.
In addition, this document allows significant flexibility in the In addition, this document allows significant flexibility in the
allocation of functions between the roles of Peer and Admin. This allocation of functions between the roles of Peer and Admin. This
functional allocation is crucial both to achieving successful functional allocation is crucial both to achieving successful
deployment, and to maintaining the integrity of the PKI enrollment deployment, and to maintaining the integrity of the PKI enrollment
and management processes. However, much of the responsibility for and management processes. However, much of the responsibility for
this allocation necessarily falls to product implementers and system this allocation necessarily falls to product implementers and system
operators through the selection of applicable use cases and operators through the selection of applicable use cases and
development of security policy constraints. These factors must be development of security policy constraints. These factors must be
carefully considered to ensure the security of PKI4IPSEC certificate carefully considered to ensure the security of PKI4IPSEC certificate
management. Appendix E catalogs some key system operator choices management.
that are not constrained by this document, and frames their possible
impacts.
7. Intellectual Property Rights
No new intellectual property rights are introduced by this document.
8. IANA Considerations 5 IANA Considerations
There are no known numbers which IANA will need to manage. There are no known numbers which IANA will need to manage.
IPsec Certificate Management Profile 6 References
A References
A.1 Normative References
None 6.1 Normative References
A.2 Non-Normative References None.
[STDPROCESS] Bradner, S., "The Internet Standards Process – Revision 6.2 Informative References
3", BCP 9, RFC 2026, October 1996.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[CERTPROFILE] Housley, R., et. al. "Internet X.509 Public Key [CERTPROFILE] Housley, R., et. al. "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Infrastructure Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002. Profile", RFC 3280, April 2002.
[DOI] Piper, D., "Internet IP Security Domain of Interpretation for [DOI] Piper, D., "Internet IP Security Domain of Interpretation for
ISAKMP", RFC 2407, November 1998. ISAKMP", RFC 2407, November 1998.
IPsec Certificate Management Profile
[FRAME] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu. S., [FRAME] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu. S.,
"Internet X.509 Public Key Infrastructure: Certificate Policy and "Internet X.509 Public Key Infrastructure: Certificate Policy and
Certificate Practices Framework", RFC 3647, November 2003. Certificate Practices Framework", RFC 3647, November 2003.
[GLOSSARY] Shirey, R., “Internet Security Glossary”, RFC 2828, May
2000.
[IKECERTPROFILE] Korver, B., “The Internet IP Security PKI Profile [IKECERTPROFILE] Korver, B., “The Internet IP Security PKI Profile
of IKEv1/ISAKMP, IKEv2, and PKIX”,draft-ietf-pki4ipsec-ikecert- of IKEv1/ISAKMP, IKEv2, and PKIX”,draft-ietf-pki4ipsec-ikecert-
profile-08, 15 February 2006. profile-11, 25 September 2006.
B. Acknowledgements 7 Acknowledgements
This draft is substantially based on a prior draft draft-dploy- This draft is substantially based on a prior draft draft-dploy-
requirements-00 developed by Project Dploy. The principle editor of requirements-00 developed by Project Dploy. The principle editor of
that draft was Gregory M. Lebovitz (NetScreen Technologies). that draft was Gregory M. Lebovitz (NetScreen Technologies).
Contributing authors included Lebovitz, Paul Hoffman (VPN Contributing authors included Lebovitz, Paul Hoffman (VPN
Consortium), Hank Mauldin (Cisco Systems), and Jussi Kukkonen (SSH Consortium), Hank Mauldin (Cisco Systems), and Jussi Kukkonen (SSH
Communications Security). Substantial editorial contributions were Communications Security). Substantial editorial contributions were
made by Leo Pluswick (ICSA), Tim Polk (NIST), Chris Wells (SafeNet), made by Leo Pluswick (ICSA), Tim Polk (NIST), Chris Wells (SafeNet),
Thomas Hardjono(VeriSign), Carlisle Adams (Entrust), and Michael Thomas Hardjono(VeriSign), Carlisle Adams (Entrust), and Michael
Shieh (NetScreen). Shieh (NetScreen).
Once brought to pki4ipsec, the following people made substantial Once brought to pki4ipsec, the following people made substantial
contributions: Jim Schaad and Stefan Santesson. contributions: Jim Schaad and Stefan Santesson.
IPsec Certificate Management Profile Editor’s Address
C. Editor’s Address
Chris Bonatti Chris Bonatti
IECA, Inc. IECA, Inc.
15309 Turkey Foot Road Bonattic(at)ieca.com
Darnestown, MD 20878-3640 USA
bonattic@ieca.com
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
1421 T Street NW #8 Turners(at)ieca.com
Washington, DC 20009 USA
turners@ieca.com
Gregory M. Lebovitz Gregory M. Lebovitz
Gregory-ietf@earthlink.net gregory.ietf(at)gmail.com
D. Change History
2007-October Draft-ietf-pki4ipsec-mgmt-profile-rqts-06
This issue of the document the same as the -05. This is a keep alive
version.
2006-March Draft-ietf-pki4ipsec-mgmt-profile-rqts-05
This issue of the document attempts to close out WG Last call
comments.
- Addressed editorial comments.
- In the last paragraph of 3.5.1 replace “can” with “MAY” as these
two sentences are stating requirements on the management
protocol.
- In 3.7.2 – Made DNS mandatory to align with 3.6.1
2006-February Draft-ietf-pki4ipsec-mgmt-profile-rqts-04
This issue of the document attempts to close out all issues as
perceived after IETF #63.
- Added text in introduction to state that there are other models
not addressed in this document and they are beyond the scope of
this document
- Removed requirements summary (Annex D).
IPsec Certificate Management Profile
- Removed operator choices (Annex E).
2005-March Draft-ietf-pki4ipsec-mgmt-profile-rqts-03
This issue of the document attempts to close out all non-contentious
issues as perceived after IETF #62.
- The term "non-repudiation" was removed from the document, as non-
repudiation support is supported by authentication.
- IPSec replaced with IPsec.
- The requirement for a "community realm" was removed from the
document.
- The requirement for an "update type" field was removed from the
document.
- Clarified requirements language – many MAYs were changed to can.
- Changed abstract, 1, and 1.2 to indicate that Admin-Peer
transaction's requirements, which were in the document from its
initial version, are within scope of the document.
- Reworded paras 1, 1.1, and 1.2 to remove duplication.
- Added in 1.2 statements to clarify protocol specifications to are
byond the scope of the document for any requirement addressed in
the document (i.e., this is a requirements document not a
protocol document).
- Clarified para 2.1.2 first para. The last paragraph in para
2.1.2 was moved to 3.1.3 Admin Availability requirements. First
bullet in second para of 2.1.2 was reworded to clarify PKCs are
part of the local security policy. The second bullet was
reworded to more fully define how the Admin uses templates. The
requirements for secure Admin-Peer interactions was moved to
para 3.1.2.
- In para 2.3: added [G] and [M] interactions between PKI and
Peers/Admin, [G], [E], [M], [R] transactions between Peer and
Admin, renamed [M] Management to [L] Lifecycle, changed [E] to
be sending PKC request, verifying response, and confirming PKC
response, placed validation with confirmation in [L], swapped
renwal, update, and rekey with repository lookups, add new last
para to explain remaining organization.
- Moved 2.3.1, 2.3.2, and 2.3.3 to later sections.
IPsec Certificate Management Profile
- Reorganized document based on general requirements and
requirements for [A], [G], [E], [L], and [R] requirements.
- Clarified the secure transaction requirements. [A], [E], [G], [L]
require secure transactions, while [R] repository lookup is an
operator decision (PKCs and CRLs are signed don't necessarily
need privacy for their retrieval).
- Moved requirements for a VPN-PKI PKC (para 3.5) to general
requirements (3.1.5). Changed para to indicate it is the
requirements for VPN-PKI PKC and not the IKE PKC. Identity
requirements reduced to indicate name forms that need to be
supported. Path validation requirements moved to later in the
profile. Changed key usage requirements to indicate the
requirement vice the field that must be supported. EKU
requirement changed to indicate EKUs are not required and
presence must not cause implementations to fail. Renamed pointer
to revocation checking to revocation information location and
reduced wording to say "must have location of revocation
location." Note that the PKC profile for VPN-PKI interactions
will be addressed in the certificate management profile.
- Indicated manual approval for enrollment requests will not be
supported.
- Renamed "protocol preference for authorization" to "one
authorization protocol". Removed redundant text describing PKI-
Admin interactions (it gets covered later). Moved "batch"
requirements to bulk authorizations.
- Clarified that DNS is supported to resolve IP addresses.
- Clarified that a PKC update can include a rekey.
- Clarified that Admin can initiate revocations for any PKC issued
under a template it controls, which supports the case where
multiple Admins are used.
- Added one protocol for Lifecycle requirements. One for rekey,
renew, update; revocation may be the same. Rekey, renew, update
must be same as enrollment protocol.
- Removed notion of update “type”.
- Added that rekeys are initiated by Admin and that the PKI need
not support direct interaction on rekey requests.
IPsec Certificate Management Profile
- Trust anchor acquisition, path validation, and revocation
checking were grouped together under a new paragraph called
Trust.
2004-December Draft-ietf-pki4ipsec-mgmt-profile-rqts-02
This issue of the document attempts to close out all non-contentious
issues as perceived after IETF #61. Numerous clarifications to
technical content were introduced, as well as revision to language
for purposes of internal consistency and consistency with the
[IKECERTPROFILE]. The following changes were introduced:
- Description of PKC “renewal” was clarified IAW [GLOSSARY].
- Replaced term “change” with “update” IAW [GLOSSARY].
- Added description of PKC “rekey” to complete the terminology set
employed in [GLOSSARY].
- Added [GLOSSARY] to the set of Non-Normative References.
- Updated use of the terminology throughout the document to align
with the above.
- Scrubbed instances of ambiguous requirements terminology in favor
of statements compliant with [MUSTSHOULD].
- Added reference to [IKECERTPROFILE] in several introductory text.
- Resolved editor’s note concerning renewal parameters in 3.2.3.1
and related text in 3.2.3.2.
- Clarified that any non-key-related field might be changed in a
PKC update operation.
- Resolved editor’s note concerning canceling authorizations in
3.2.4 so that either the Admin or the Peer may issue a
cancellation.
- Resolved editor’s note concerning replay attacks in 3.2.4 so
duplicate authorization request MUST have a new identifier.
- Clarified the scenario in 3.2.5 for the PKI modifying the
requested PKC template submitted by the Admin.
- Renumbered previous clauses 3.3.1 through 3.3.4 as subsections of
a new 3.3.1 entitled “Key Generation Scenarios”.
IPsec Certificate Management Profile
- Moved and renumbered the existing clause 3.3.5 as a new clause
3.10 since the topic of trust anchor acquisition applies
generically, and is not specifically subject to key generation
or PKC request construction.
- Added new key generation scenario as 3.3.1.5 in which the Peer
initiates a PKC request without a prior authorization exchange
between the Admin and the PKI.
- Added new Figures 7 through 11 to clauses 3.3.1.1 through 3.3.1.5
respectively to illustrate the steps of the different key
generation scenarios.
- Clarified in several places that the delivery of the requested
PKC is expected to occur directly as an in-band response, not
via lookup in the certificate repository.
- Resolved editor’s note in 3.5.3 concerning key usage so that only
the “digialSignature” bit will be required to be set based on
the understanding that this does not preclude a system from
using digital signatures as a part of a non-repudiation service.
- Added new text to section 4 on Security Considerations.
- Corrected paragraph numbering on Non-Normative Reference section.
- Incorporated a new Appendix E to summarize choices that must be
made by VPN implementers and VPN system operators, and describe
some of the potential impact of these decisions.
- Applied numerous minor editorial corrections throughout the
document.
2004-October Draft-ietf-pki4ipsec-mgmt-profile-rqts-01
This issue of the document addresses comments identified at IETF #60.
The bulk of the changes were editorial, but some residual technical
impact may have resulted. The following changes were introduced:
- Acronym fixes
- Clarification of PKC Change definition
- Rearranged and consolidated references
- Clarified what “off-line” communication (out of band) entails.
IPsec Certificate Management Profile
2004-August Draft-ietf-pki4ipsec-mgmt-profile-rqts-00
This issue of the document was merely a reposting of draft-bonatti-
pki4ipsec-profile-reqts-01 to bring the document under the WG
auspices after the I-D repository opened. No significant changes
were introduced.
2004-July Draft-bonatti-pki4ipsec-profile-reqts-01
This document was submitted as an individual draft in order to meet a
publication deadline though it has been accepted in to the working
group. The following salient changes were introduced:
- A new Figure 1 was added in section 2.1 to depict just the VPN
System.
- A new Figure 2 was added to depict 2.2 to depict just the PKI
System.
- The old Figure 1 was moved to section 2.3.
- Section 2.3 was split in to three sections to depict the New PKC,
Renewal, and Revocation. Also the text was modified to indicate
that the pictures are only for IPsec Peers generating key pairs
and requesting PKCs.
- Text and a Figure was added to Section 3.4.6 to show the
architectural difference for IPsec Peers enrolling through an
Admin.
- Text and a Figure was added to Section 3.4.7 to show the
architectural difference for Admins performing the entire
enrollment.
2004-January Draft-bonatti-pki4ipsec-profile-reqts-00
This is a revised requirements document based on the existing Project
Dploy requirements draft. It adapts the revisions to adapt the Dploy
requirements to the scope of the proposed charter for an IETF
PKI4IPSEC WG. It is submitted as an individual draft in anticipation
of formation of the WG. The following salient changes were
introduced:
- Rewrote the abstract to focus on the document rather than the
project.
IPsec Certificate Management Profile
- Rewrote and trimmed introduction to fit proposed scope of
deliverable (2) from IETF PKI4IPSEC charter.
- Rewrote sentences throughout to genericize the document for the
IETF and remove references to Project Dploy objectives.
- Removed reference to the Dploy Business Case.
- Removed the "Audience" subsection of the introduction because it
was redundant with other aspects of the introduction, and
unnecessary with the context of the proposed PKI4IPSEC WG.
- Added definition of Community Realm (used in 3.2.3.3) to the
"Definitions" subsection.
- Added definition of CRL Distribution Points (CDP) and Authority
Info Access (AIA) to the "Definitions" subsection.
- Restructured the "Architecture" section to bring the presentation
of Figure 1 to the front to go along with the overview of the
section, and to add a new step diagram to the "VPN-PKI
Interaction" subsection.
- Added a new subsection 2.1.2 to describe the VPN peer. Text of
the new subsection will be supplied in a subsequent draft.
- Added an editor’s note to subsection 3.1.2 noting that further
elaboration on the nature of "policy details" may be required.
- Subsection 3.2 was deleted to maintain the focus on generic
requirements agreed in Minneapolis. Selection of specific
protocols will be done in the deliverable (3) profile.
- Delete the requirement from 3.2.3.1 to include the maximum CRL
size in the certificate template. This may need to be specified
in the profile, but not be in the certificate itself.
- Revised 3.3.3 to clarify that key escrow requirements and any key
transport between the VPN admin and the peer are beyond scope.
- Adopted consistent spelling "enrollment" vs. "enrolment"
throughout.
- Replaced instances of "and/or" and other slashed terminology with
less ambiguous statements to clarify the requirements.
- Revised the text of 3.5.1 to clarify the proposed requirement in
terms of SHALL and MAY terms.
IPsec Certificate Management Profile
- Re-titled 3.5.2 as "Path Validation" instead of "Chaining".
- Added AIA extension as a MAY requirement in 3.5.2.
- Added an editor’s note to subsection 3.5.3 to question whether
additional keyUsage bits should be set in the certificate.
- Removed the requirement for HTTP support in favor of a
requirement for a single mandatory protocol to be specified in
the profile.
- Removed subsection on "Intra-IKE Considerations" as these should
be dealt with in the existing deliverable (1) PKI profiles.
- Deleted existing sections 5 and 6 dealing with the participating
vendors in Project Dploy.
- Added new section 4 on "Security Considerations". Text of the new
subsection will be supplied in a subsequent draft.
- Revised the "Acknowledgements" section to reflect this revision,
and provide appropriate credit to Project DPloy.
- Normalized "References" section with the ID-Nits promulgated by
the IESG.
- Added a stub for a proposed new Annex D to provide a requirements
summary table. Content of the annex will be supplied in a
subsequent draft.
2002-March Draft-dploy-requirements-00
- First public draft of the document released.
IPsec Certificate Management Profile IPsec Certificate Management Profile
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
 End of changes. 103 change blocks. 
583 lines changed or deleted 194 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/