view Side-By-Side changes
PKI4IPSEC Working Group
Internet Draft Chris Bonatti, IECA
draft-ietf-pki4ipsec-mgmt-profile-rqts-02.txt
draft-ietf-pki4ipsec-mgmt-profile-rqts-03.txt Sean Turner, IECA
December 12, 2004
July 20, 2005 Gregory Lebovitz, Netscreen Juniper
Expires June 12, 2005 February 20, 2006
Requirements for an IPsec Certificate Management Profile
Status of this Memo
By submitting this Internet-Draft, I certify each author represents that any
applicable patent or other IPR claims of which I am he or she is aware
have been disclosed, or will be disclosed, and any of which I become he or she becomes
aware will be disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 6 of [STDPROCESS]. BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
http://www.ietf.org/ietf/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This informational document describes and identifies the requirements
for a profile of a certificate management protocol transactions to handle Public Key Certificate (PKC) lifecycle interactions
transactions between Internet Protocol Secuity Security (IPsec) Virtual
Private Network (VPN) Systems using
IKE Internet Key Exchange (IKE)
(versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These
requirements are designed so that they to meet the needs of enterprise scale IPsec
VPN deployments. It is intended that a standards track profile of a
management protocol will be created that fulfills to address many of these
requirements.
STATUS OF THIS MEMO................................................1
ABSTRACT...........................................................1
Bonatti, Turner, Lebovitz 1
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
1 INTRODUCTION.....................................................3
1.1 SCOPE..........................................................4
1.2 NON-GOALS......................................................5
1.3 DEFINITIONS....................................................5
1.4 REQUIREMENTS TERMINOLOGY.......................................7
2. ARCHITECTURE....................................................8
2.1 VPN SYSTEM.....................................................8
2.1.1 IPSEC PEER(S)................................................8
2.1.2 VPN ADMINISTRATION FUNCTION (ADMIN)..........................9
2.2 PKI SYSTEM....................................................10
2.3 VPN-PKI INTERACTION...........................................11
2.3.1 NEW PKC.....................................................12
2.3.2 RENEWAL PKC.................................................14
2.3.3 REVOCATION..................................................16
3 REQUIREMENTS....................................................17
3.1 GENERAL REQUIREMENTS..........................................17
3.1.1 ONE PROTOCOL................................................17
3.1.2 SECURE TRANSACTIONS.........................................17
3.1.3 PKI AVAILABILITY............................................17
3.1.4 END-USER TRANSPARENCY.......................................18
3.1.5 ERROR HANDLING..............................................18
3.2 AUTHORIZATION TRANSACTIONS....................................18
3.2.1 BULK AUTHORIZATION..........................................18
3.2.2 PROTOCOL PREFERENCES FOR AUTHORIZATION......................18
3.2.3 ADMIN AUTHORIZATION REQUESTS TO PKI.........................19
3.2.3.1 SPECIFYING FIELDS WITHIN THE PKC..........................19
3.2.3.2 AUTHORIZATIONS FOR RENEWAL AND UPDATE.....................20
3.2.3.3 OTHER AUTHORIZATION ELEMENTS..............................21
3.2.4 CANCEL CAPABILITY...........................................21
3.2.5 PKI RESPONSE TO ADMIN.......................................22
3.2.6 ERROR HANDLING FOR AUTHORIZATION TRANSACTIONS...............22
3.3 KEY GENERATION AND PKC REQUEST CONSTRUCTION...................22
3.3.1 KEY GENERATION SCENARIOS....................................23
3.3.1.1 IPSEC PEER GENERATES KEY PAIR AND CONSTRUCTS REQUEST......23
3.3.1.2 IPSEC PEER GENERATES KEY PAIR, ADMIN CONSTRUCTS REQUEST...24
3.3.1.3 ADMIN GENERATES KEY PAIR AND CONSTRUCTS REQUEST...........26
3.3.1.4 PKI GENERATES KEY PAIR AND PASSES TO PEER VIA ADMIN.......27
3.3.1.5 PEER GENERATES KEY PAIR WITHOUT PRIOR AUTHORIZATION.......28
3.3.2 ERROR HANDLING FOR KEY GENERATION AND PKC REQUEST CONSTRUCTION
..................................................................29
3.4 ENROLLMENT (SENDING REQUEST AND PKC RETRIEVAL)................30
3.4.1 ONE PROTOCOL................................................30
3.4.2 ON-LINE PROTOCOL............................................30
3.4.3 SINGLE CONNECTION WITH IMMEDIATE RESPONSE...................30
3.4.4 MANUAL APPROVAL OPTION......................................30
3.4.5 ENROLLMENT METHOD 1: PEER ENROLLS TO PKI DIRECTLY...........30
3.4.6 ENROLLMENT METHOD 2: IPSEC PEER ENROLLS TO PKI THROUGH ADMIN31
3.4.7 ENROLLMENT METHOD 3: ADMIN ENROLLS TO THE PKI DIRECTLY......33
3.4.8 ENROLLMENT TYPE FIELD.......................................35
Bonatti, Turner, Lebovitz 2
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
3.4.9 CONFIRMATION HANDSHAKE......................................35
3.4.10 FAILURE CASES..............................................36
3.5 PKC PROFILE FOR PKI INTERACTION...............................37
3.5.1 IDENTITY USAGE..............................................37
3.5.2 PATH VALIDATION.............................................38
3.5.3 KEYUSAGE....................................................38
3.5.4 EXTENDED KEY USAGE..........................................38
3.5.5 POINTER TO REVOCATION CHECKING..............................39
3.6 PKC RENEWALS AND UPDATES......................................39
3.6.1 RENEW REQUEST FOR A NEW PKC (BEFORE EXPIRY).................41
3.6.2 UPDATE REQUEST FOR A NEW PKC................................41
3.6.3 ERROR HANDLING FOR RENEWAL AND CHANGE.......................42
3.7 FINDING PKCS IN REPOSITORIES..................................42
3.7.1 ERROR HANDLING FOR REPOSITORY LOOKUPS.......................43
3.8 REVOCATION ACTION.............................................43
3.9 REVOCATION CHECKING AND STATUS INFORMATION....................44
3.9.1 ERROR HANDLING IN REVOCATION CHECKING.......................45
3.10 TRUST ANCHOR PKC ACQUISITION.................................45
4. SECURITY CONSIDERATIONS........................................45
A REFERENCES......................................................46
A.1 NORMATIVE REFERENCES..........................................46
A.2 NON-NORMATIVE REFERENCES......................................46
B. ACKNOWLEDGEMENTS...............................................47
C. EDITORÆS ADDRESS...............................................47
D. SUMMARY OF REQUIREMENTS........................................47
E. SYSTEM OPERATOR CHOICES........................................48
F. CHANGE HISTORY.................................................48
1 Introduction
This document enumerates requirements for Public Key Certificate
(PKC) management interaction among lifecycle transactions between different IPsec VPN products System and PKI
System products in order to better enable large scale, PKI-supported PKI-enabled
IPsec VPN deployments. deployments with a common set of transactions. Requirements for
both the IPsec and the PKI products are discussed. The goal is requirements
are carefully designed to create a set achieve security without compromising ease
of requirements
from which a profile document will be derived. The specification will
clarify the transactions necessary between the VPN System management and the PKI
System that enable deployment, even where the deployment of easily manageable, easily
scalable VPNs. When implemented, the specification will enable
improved interoperability between IPsec and PKI products. The
requirements are carefully designed to achieve security without
compromising ease of management and deployment, even where the
deployment involves tens involves tens
of thousands of IPsec users and devices.
Within IPsec VPNs, the PKI supports authentication of IPSec Peers
through digital signatures during security association establishment
using IKE. The protocol and PKI operational usages are considered in
order to define a common, single set of methods (which forces
Bonatti, Turner, Lebovitz 3
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
interoperability) between PKI Systems and VPN Systems for large-scale
deployments.
The requirements address transactions for the entire PKC lifecycle
for PKI
usage within IPsec transactions: pre-authorization of PKI-enabled VPN System: authorization (of PKC issuance),
generation (public-private key pair and PKC issuance, request), enrollment process (PKC request and retrieval),
request, PKC renewals, updates response, and rekeys, revocation, validation confirmation), maintenance (rekey, renew,
update, revoke, and confirm), and repository lookups. They These
transactions enable a VPN Operator to:
- Use a VPN Administration function (Admin), which is introduced in
this document, to manage PKC authorization and possibly act as
the sole interface for the VPN System and the PKI System.
- Authorize individual or batches of PKC issuances based on locally
defined criteria, and do so from a pre-
agreed template (i.e., both types of authorization requests
refer to the VPN Administration point. pre-agreed template). These authorizations can
occur either prior to the enrollment or in the same transaction
as the enrollment.
- Provision PKI-based user or machine identity to IPsec Peers, on a
large scale. Provision means the IPsec Peer ends up with a valid
public and private key pair and PKC based on the IETF Public Key
Infrastructure X.509 (PKIX) PKC profile from [CERTPROFILE] and
the specific requirements of IPsec PKCs [IKECERTPROFILE]. These
are used in the IKE negotiation for tunnel setup.
- Set the corresponding gateway or client authorization policy for
remote access and site-to-site connections.
- Establish automatic renewal policies for PKCs, automatic PKC renewal, updates, or rekey. rekeys.
- Ensure timely revocation information is available for PKCs used
in IKE exchanges.
The desired outcome is that both IPSec and PKI vendors create
interoperable products
These requirements will be used to enable such scalable deployments, and do so
as quickly as possible. For example, profile a VPN Operator should be able to
use any conforming IPsec implementation of the certificate management
profile with any conforming PKI vendorÆs implementation to perform
protocol that the VPN rollout and management as described below. System will use to communicate with the PKI
System. Note that this profile will be in another document. The
certificate management profile will also clarify and constrain
existing PKIX and IPsec standards and protocols for easier
understanding and to limit the limiting of complexity in of
deployment. Some new
elements are identified that requirements may require either a new protocol, or
changes or extensions to an existing protocol, especially in the area
of bulk authorization protocol.
Bonatti, Turner, Lebovitz 2
Internet-Draft Requirements for PKC issuance. an July 2005
IPsec Certificate Management Profile
The document introduces the
idea desired outcome of a VPN Administration function (Admin) within the VPN System.
This VPN Administration function bears great responsibility for the
task of managing pre-authorization for PKC issuance requirements and profile documents is that
both IPsec and PKI vendors create interoperable products to enable
large-scale IPsec System deployments, and do so as quickly as
possible. For example, a VPN Operator should be able to use any
conforming IPsec implementation (VPN Admin or IPsec Peer) of
distributing the results between
certificate management profile with any conforming PKI vendorÆs
implementation to perform the VPN System rollout and the PKI System. management.
1.1 Scope
The solution described in this document focuses on the address requirements
for the interaction on transactions between the VPN
Systems and the PKI Systems. The
internals of Systems and between the operation of these systems are beyond scope.
Bonatti, Turner, Lebovitz 4
Internet-Draft Requirements for an December 2004 VPN Administration and
IPsec Certificate Management Profile Peers. The solution focuses on requirements strive to meet eighty percent of the
market needs of for large-scale rollouts, i.e. deployments (i.e., VPNs including
hundreds or thousands of managed VPN gateways or VPN remote access clients. The needs of small deployments are a stated non-goal,
however service providers employing the scoped solution and applying
it to many smaller deployments in aggregate may address them.
Gateway-to-gateway access and end-user remote access (to a gateway)
are both covered. End-to-end communications are not necessarily
excluded but are intentionally not a focus.
There is no intention to discuss all or other PKI issues here. The
scope is limited to requirements for easing and enabling scalable
IPsec with PKI deployments.
The requirements strive to meet eighty percent of the market needs
for large-scale deployments. Environments will understandably exist
in which large-scale deployment tools
clients). Environments will understandably exist in which large-scale
deployment tools are desired, but local security policy stringency
will not allow for the use of such commercial tools. The solution
will possibly miss the needs of the highest ten percent of stringency
and lowest ten percent of convenience requirements. Use cases will be
considered or rejected based upon this eighty percent rule. The needs
of small deployments are a stated non-goal, however service providers
employing the scoped solution and applying it to many smaller
deployments in aggregate may address them.
Gateway-to-gateway access and end-user remote access (to a gateway)
are both covered. End-to-end communications are not necessarily
excluded but are intentionally not a focus.
Only VPN-PKI transactions that ease and enable scalable PKI-enabled
IPsec deployments are addressed.
1.2 Non-Goals
The scenario for PKC cross-certification will not be addressed.
The protocol specification for the VPN-PKI interactions will not be
addressed.
The protocol specification for the communication method and transactions
between VPN Administration function and IPSec Peers is up Administrator to vendor
implementation and therefore is Peer
transactions will not expected to be included in the
certificate management profile. Such a protocol addressed. These interactions are considered
vendor proprietary. These interactions may be standardized
at a later date to
enable interoperability between VPN Administration function stations
and IPsec Peers from different vendors, but is far beyond the scope
of this current effort, and will be considered described as opaque by the certificate management profile. transactions in
this document.
Bonatti, Turner, Lebovitz 3
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
The protocol specification for RA-CA, CA-Repository, and RA-
Repository interactions will not be addressed.
1.3 Definitions
VPN System
The VPN System is comprised of the VPN Administration function
(defined below), the IPsec Peers, and the communication mechanism
between the VPN Administration and the IPsec Peers. VPN System is
defined in more detail in section 2.1.
PKI System
Bonatti, Turner, Lebovitz 5
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
The PKI System, or simply PKI, is the set of functions needed to
authorize and issue PKCs
authorize, issue, and provide revocation information about
those manage PKCs. PKI System is defined in more
detail in section 2.2.
(VPN) Operator
The Operator is the person or group of people that define security
policy and configure the VPN System to enforce that policy. policy, with the
VPN Administration function.
IPsec Peer (Gateway or Client)
For the purposes of this document, an IPsec Peer, or simply "Peer",
is any IPsec VPN System component that communicates IKE and IPsec to
another Peer in order to create a secure tunnel for communications.
It can be either a traditional security gateway (with two network
interfaces, one for the protected network and one for the unprotected
network), or it can be an IPsec client (with a single network
interface). In both cases, the IPsec System Peer can pass traffic with no IPsec
protection, and can add IPsec protection to chosen traffic streams.
See Section 2.1.1 for more details.
(VPN) Admin
The function of Admin is the VPN System function that manages and distributes policy to
Peers and who interacts with the PKI
System to define policy for establish PKC provisioning for the VPN connections. See
Section 2.1.1 below 2.1.2 for more details.
End Entity
An end entity is the entity or subject that is identified in a PKC exists to
authenticate. PKC.
The end entity is the one entity that will finally use a private key
associated with a PKC to digitally sign data. In this document, an
IPsec Peer is certainly an end entity, but the VPN Admin may can also
constitute an end entity. Note that end entities may can have different
PKCs for different purposes (e.g., signature vs. key exchange).
Community Realm
A community realm is the set of exchange, Admin-
functions vs. Peer-functions).
Bonatti, Turner, Lebovitz 4
Internet-Draft Requirements for an July 2005
IPsec Peers and VPN Administration
function that operate under a common policy, and PKI authorizations. Certificate Management Profile
PKC Renewal
The acquisition of a new PKC with the same public key due to the
expiration of an existing PKC. Renewal occurs prior to the expiration
of the existing PKC to avoid any connection outages. A renewal
process can rely on the existing key pair to bootstrap authentication
for the new enrollment.
PKC Update
A special case of a renewal-like occurrence where a PKC needs to be
changed prior to expiration due to some change in its subjectÆs
information. Examples might include change in the address, telephone
number, or name change due to marriage of the end entity. An update
process can rely on the existing key pair to bootstrap authentication
for the new enrollment.
PKC Rekey
Bonatti, Turner, Lebovitz 6
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
The routine procedure for replacement of a PKC with a new PKC with a
new public key for the same subject name. A rekey process may can rely
on the existing key pair to bootstrap authentication for the new
enrollment.
Registration Authority (RA)
An optional entity in a PKI System given responsibility for
performing some of the administrative tasks necessary in the
registration of end entities, such as confirming the subjectÆs
identity and verifying that the subject has possession of the private
key associated with the public key requested for a PKC.
Certificate Authority (CA)
An authority in a PKI System that is trusted by one or more users to
create and assign sign PKCs. It is important to note that the CA is
responsible for the PKCs during their whole lifetime, not just for
issuing them.
Repository
An Internet-accessible server in a PKI System that stores and makes
available for retrieval PKCs and Certificate Revocation Lists (CRLs).
Root CA/Trust Anchor
A CA that is directly trusted by an end entity; that is, securely
acquiring the value of a Root CA public key requires some out-of-band
step(s). This term is not meant to imply that a Root CA is
necessarily at the top of any hierarchy, simply that the CA in
question is trusted directly.
Certificate Revocation List (CRL)
A CRL is a CA-signed, time stamped list identifying revoked PKCs that is signed
by a CA and
made freely available in a public repository. Peers retrieve the CRL to
Bonatti, Turner, Lebovitz 5
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
verify that a PKC being presented to them as the identity in an IKE
transaction has not been revoked.
CRL Distribution Point (CDP)
The CDP extension in is a PKC extension that identifies the location from which
end entities should retrieve CRLs to perform local validity checking. check status information.
Authority Info Access (AIA)
The AIA extension in is a PKC extension that indicates how to access CA
information and services for the issuer of the PKC in which the
extension appears. Information and services may include on-line
validation services and Certificate Policy (CP) data.
1.4 Requirements Terminology
Though this document is not an Internet Draft, we use the convention
that the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
Bonatti, Turner, Lebovitz 7
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [MUSTSHOULD].
Bonatti, Turner, Lebovitz 6
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
2. Architecture
This section describes the overall architecture for a PKI-supported
IPsec VPN deployment. First, an explanation of the VPN System is
presented. Second, key points about the PKI System are stated. Third,
the VPN-PKI architecture picture is presented. Last, the process of the
interaction between the two Systems for large-scale deployment is
described.
2.1 VPN System
The VPN System consists of the IPsec Peers and the VPN Administration
function, as depicted in Figure 1.
+---------------------------------------------------+
| |
| +----------+ |
| | VPN | |
| +---------->| Admin |<-------+ |
| | | Function | | |
| | +----------+ | |
| v v |
| +---------+ +---------+ |
| | IPsec | | IPsec | |
| | Peer 1 |<=======================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+---------------------------------------------------+
Figure 1: VPN System
2.1.1 IPsec Peer(s)
The Peers are two entities between which the Operator requires require an IPsec tunnel
establishment. Two Peers are shown in Figure 1, but implementations MAY
can support an actual number in the hundreds or thousands. The Peers could
can be either gateway-to-gateway, remote-
access-host-to-gateway, remote-access-host-to-gateway, or a mix of
both. The Peers authenticate themselves in the IKE negotiation using
digital signatures through generated with PKCs for a PKI System.
Bonatti, Turner, Lebovitz 8
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
2.1.2 VPN Administration Function (Admin)
This document defines the notion of a VPN Administration function,
hereafter referred to as Admin, and gives the Admin great
responsibility within the solution. VPN System. The Admin is a centralized
function. It defines the VPN System policy and informs
function used by the PKI and
Peers how it wants each to enforce that policy. One main role defined
here is that Admin specifies Operator to interact with the PKI the contents and use
parameters of the credentials the system to
establish PKI will issue, or at least
references a template or policy-set policy (e.g., algorithms, key lengths, lifecycle
Bonatti, Turner, Lebovitz 7
Internet-Draft Requirements for a Peer or set an July 2005
IPsec Certificate Management Profile
options, and PKC fields) for groups of IPsec Peers. In
this way, The Admin also
authorizes PKC issuance and it can act as the Peer's PKI System
interface, which allows the Admin MAY to perform many RA-like functions, for example
authorization of PKC issuance and revocation. functions.
It is important to note that, within this document, the Admin is
neither a device nor a person, person rather it is a function. Every large-scale large-
scale VPN deployment will contain the Admin function. The function MAY
can be performed on a stand-alone workstation, on a gateway, or on an
administration software component. The Admin function MAY can also be one
in the same as the gateway or client device or software. They are
represented in the architectural diagram below as different functions, but
they need not be different physical entities. As such, the AdminÆs
architecture and the means by which it interacts with the
participating IPsec Peers will vary widely from implementation to
implementation. However, some basic functions of the Admin are
assumed.
- It and not the PKI will define the Certificate Policy (CP)
[FRAME] for use in a VPN System. The PKC's characteristics and
contents are a function of the
VPN, not the PKI. CP. In VPN Systems Systems, the Operator
chooses to strengthen the VPN by using PKI; PKI is a bolt-on to
the VPN System. The PKC characteristics and contents are a function of
the local security policy the VPN serves to enforce. Therefore,
the Operator will configure local security
policy and contents for PKCs in part through the
Admin, Admin and apply those templates to groups of IPsec its authorized PKI-enabled
Peers.
- It will interact directly with the PKI System to initiate
authorization for end entity PKCs by sending the parameters and
contents for those PKCs, individual PKCs or by referring to batches of PKCs based on a pre-
agreed template or
policy-set on (i.e., both types of authorization requests
refer to the PKI. (Such templates would likely have been
created pre-agreed template). Templates will be agreed in conjunction with
an out-of-band mechanism by the VPN Operator and the Operator.) PKI
Operator. It will receive back from the PKI a unique tuple of
authorization identifiers and one time one-time authorization tokens that
will authorize Peers to be used in the PKC requests for each of the pre-
authorized PKCs. request a PKC.
- It will deliver instructions to the IPsec Peers, and the Peers
will carry out those instructions. An example of such an
instruction is an IKE policy configuration. Therefore, the
communication mechanism between the instructions (e.g., Admin passes Peer
information necessary to generate keys and the IPsec Peers
MUST be private, authenticated, employ integrity checks, and
support non-repudiation. The contents of some such instructions
Bonatti, Turner, Lebovitz 9
Internet-Draft Requirements for an December 2004 PKC request).
Bonatti, Turner, Lebovitz 8
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
will be defined below. However, the communication mechanism will
be handled completely within the VPN System and is out of the
scope of this document (see Scope, Section 1.1 above).
The Admin MUST be reachable by the Peers. Most implementations will
meet this requirement by ensuring the Peer can connect to the Admin
from anywhere on the network or Internet. However, communication
between the Admin and Peer may not necessarily be "on-line". It MAY,
in some environments, be "moving media," i.e. the configuration or
data MAY be loaded on to a floppy disk or other media and physically
moved to the IPsec Peer. Likewise, it MAY be entered directly on the
IPsec Peer via a User Interface (UI). In this case, the Admin
function is co-located on the Peer device itself. This reality SHOULD
be considered when requirements are defined, and when supporting
networks are architected.
2.2 PKI System
The PKI System, as depicted in Figure 2, MAY can be set up and operated
by the Operator (in-house), MAY be provided by third party PKI providers
to which connectivity is available at the time of provisioning
(managed PKI service), or MAY be integrated with the VPN product.
+---------------------------------------------+
| +-------------------------+ |
| v | |
| +--------------+ v |
| | Repository | +----+ +----+ |
| | Certs & CRLs |<-> | CA |<->| RA | |
| +--------------+ +----+ +----+ |
| |
+---------------------------------------------+
Figure 2: PKI System
This framework assumes that all components of the VPN MUST obtain PKCs
from a single PKI community. An IPsec Peer MAY can accept a PKC from a
Peer that is from a CA outside of the PKI community, but the auto
provision and life cycle management for such a PKC or its trust
anchor PKC fall out of scope.
The PKI System MUST contain contains a mechanism for handling AdminÆs
authorization requests and PKC enrollments. These mechanisms are
referred to as the RA. The PKI System MUST contain contains a Repository for Peers
to look up retrieve each otherÆs PKCs and revocation information. Last, the
PKI System contains the core function of a CA that uses a public and
private key pair and signs PKCs.
Bonatti, Turner, Lebovitz 10
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
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
built such that URL contents do not contain referrals to other hosts
or URLs, as such referral lookups will increase the time to complete
the IKE negotiation, and can cause implementations to timeout.
2.3 VPN-PKI Interaction
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
therefore sensible to consider the steps necessary to set up, use and
manage PKCs for one Peer to establish an association with another
Peer. Figure 4 (below) illustrates the information flow associated
with the initial PKC generation steps relative to the architecture
diagram. Figure 5 (below) illustrates the information flow associated
with the PKC renewal steps relative to the architecture diagram.
Figure 6 (below) illustrates the information flow associated with the
PKC revocation steps relative to the architecture diagram. For
simplicity, only the steps associated with IPsec Peer 1 are shown.
Bonatti, Turner, Lebovitz 11 9
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
+---------------------------------------------+
+-----------------------------------------------+
| PKI System |
| |
| +--------------+ |
| | Repository | +----+ +----+ |
| | Certs & CRLs | | CA | | RA | |
| +--------------+ +----+ +----+ |
| |
+---------------------------------------------+
+-----------------------------------------------+
^ ^ ^
| | |
|[E]
|[G] |[A] |[G]
|[E] |[G] |[E]
|[M]
|[L] |[E] |[M] |[L]
|[R] |[R] |[R]
| |[L] | |
+--------+------------------+----------------+------+
+-----+------------------+-------------------+-------+
| | v | |
| | +----------+ | |
| | [G] | [G][E][L][R]| VPN | [G] |[G][E][L][R] | |
| | +---------->| Admin |<-------+ |<----------+ | |
| | | | Function | | | |
| | | +----------+ | | |
| v v v v |
| +---------+ +---------+ |
| | IPsec | [I] | IPsec | |
| | Peer 1 |<=======================>| |<========================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+---------------------------------------------------+
+----------------------------------------------------+
[A] = Authorization of Authorization: PKC issuance and revocation
[G] = Generation of public Generation: Public key, and private key pair, key, and PKC request
[E] = Enrollment (request Enrollment: Sending PKC request, verifying PKC response, and retrieval)
confirming PKC response
[I] = IKE and IPsec communication
[M]
[L] = Maintenance: validation, Lifecycle: Rekey, renewal, update, revocation, and repository lookups
confirmation
[R] = Renewal (also update Repository: Posting and rekey) lookups
Figure 3. Architectural Framework for VPN-PKI Interaction
2.3.1 New PKC
The steps
Requirements for each of the VPN-PKI interaction are summarized here for
generating a new PKC. The letters refer to Figure 3. The numbers
refer to Figure 4. The detailed requirements interactions, [A], [G], [E], [L], and
[R], are described below addressed in
Section 3. Note that there paragraphs 3.2-3.6. However, only requirement
for [A], [E], [L], and [R] will be addressed by the certificate
management profile. Requirements for [I] transactions are a number beyond the
scope of architectural options
available and that this document. Additionally, the most common architecture act of certification (i.e.,
binding the public key to the name) is depicted in Figure
4; IPsec Peer generated Keys performed at the CA and IPsec Peer generated PKC Request.
Other architectural options are discussed is not
shown in Section 3. the Figure.
Bonatti, Turner, Lebovitz 12 10
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
+--------------+ 7 +-----------------------+
| Repository |<----| Certificate Authority |
+--------------+ +-----------------------+
^ ^ ^
| 8 4, 6 | | 1
| | 2 |
| | v
| | +-------+
| | +- | Admin |
| | | +-------+
| | |
| 9 5 | |
3
v v v
+--------------------+ +--------+
| IPsec | 10 | IPsec |
| Peer 1 |<========>| Peer 2 |
+--------------------+ +--------+
Figure 4. VPN-PKI Interaction Steps:
IPsec Peer Generates Keys and PKC Request,
Enrolls Directly with PKI
1) Authorization [A]. Admin sends a list of IDs and PKC contents for
the PKI System to authorize enrollment. Requirements
3.1 General Requirements
3.1.1 One Protocol
The PKI returns a list of
unique authorization identifiers and one-time tokens target profile, to be used for
the enrollment of each PKC. Other PKC usage policy is also set at based on this time, for example parameters requirements document, MUST
call for renewals, updates ONE PROTOCOL or rekeys,
key lengths, etc. The amount ONE USE PROFILE for each main element of information that the Admin
communicates to the PKI about how it wants the PKCs built could be
very small, perhaps just
[A], [E], [L], and [R] interactions. It is a reference specific goal to a template already existing
in the PKI System. Likewise, it could be very large, with several
fields being specified along with their contents.
2) Authorization Response [A]. The PKI System acknowledges the
authorizations provided in (1). Response may indicate success avoid
multiple competing protocols or
failure for any particular authorization.
3) Generate Keys and PKC Request [G]. The Admin communicates with the
Peer profiles to give solve the Peer information so that it can generate a public
and private key pair and PKC request same
requirement whenever possible to reduce complexity and send improve
interoperability.
Meeting some of the request directly to requirements may necessitate the PKI.
4) Enrollment [E]. The IPsec Peer requests creation of a PKC from the PKI,
providing
new protocol or new extension for an existing protocol; however, the generated public key.
later is much preferred.
3.1.2 Secure Transactions
The IPsec Peer generates target certificate management profile MUST specify the key
pair [A], [E],
[L], and [R] transactions between VPN and PKC request.
Bonatti, Turner, Lebovitz 13
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
5) Enrollment Response [E]. The PKI responds to Systems. To support
these transactions, the enrollment
request sent in (4), providing either Admin and PKI MUST exchange policy details,
identities, and keys. As such, the new PKC that was generated
or a suitable error indication.
6) Enrollment Confirmation. Peer positively acknowledges receipt method of
new PKC.
7) PKC Posting. The newly-generated PKC communication for IPsec Peer 1 is posted to
the repository.
8) Maintenance [M]. [A],
[E], and [L] transactions MUST be secured in a manner that ensures
privacy, authentication, and message data integrity. The IPsec Peer accesses
communication method MUST require that mutual trust be established
between the PKI to support look-
up of PKCs for other IPsec Peers, certification path validation, and
revocation checking. This step consists of sending requests for
specific PKCs or CRLs, the Admin. See paragraph 3.7.1. [R] transactions
do not require authentication or requests for message data integrity because the PKI System to perform
validation checks.
9) Maintenance Response [M]. The PKI responds to
responses (i.e., PKCs and CRLs) are already digital signed. Whether
[R] transactions require privacy is determined by the maintenance
request sent local security
policy.
The target certificate management profile will not specify [G]
transactions; however, these transactions MUST be secured in (7), providing either a manner
that that ensures privacy, authentication, and message data integrity
because these transactions are the requested PKC or CRL,
indicating basis for the validity status of a PKC, or indicating an error
condition.
10) IKE/IPsec Communication [I]. other transactions.
3.1.3 Admin Availability
The Peers communicate authenticated Admin MUST be reachable by the PKCs they received Peers. Most implementations will
meet this requirement by ensuring Peers can connect to the Admin from
anywhere on the PKI.
2.3.2 Renewal PKC
The steps of network or Internet. However, communication between
the VPN-PKI interaction are summarized here for renewal
of PKCs. The letters refer to Figure 3. The numbers refer to Figure
5. The detailed requirements are described below in Section 3. Note
that there are a number of architectural options available Admin and that Peers can be "off-line". It can, in some environments,
be "moving media" (i.e., the most common architecture configuration or data is depicted in Figure 5; IPsec Peer
generated Keys loaded on to a
floppy disk or other media and physically moved to the IPsec Peer generated PKC Request. Other
architectural options are discussed in Section 3. Peers).
Bonatti, Turner, Lebovitz 14 11
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
+--------------+ 5 +-----------------------+
| Repository |<----| Certificate Authority |
+--------------+ +-----------------------+
^ ^
| 6 | 2, 4
| |
| |
| | +-------+
| | +- | Admin |
| | | +-------+
| | |
| 7 3 | | 1
v v v
+--------------------+ +--------+
| IPsec | 8 |
Likewise, it can be entered directly on the IPsec |
| Peer 1 |<========>| Peer 2 |
+--------------------+ +--------+
Figure 5. VPN-PKI Interaction Steps: Renewal by IPsec via a User
Interface (UI). In this case, the Admin function is co-located on the
Peer 1
1) Rekey or Renewal Initiation. The device itself. Most requirements and scenarios in this document
assume on-line availability of the Admin communicates renewal,
update or rekey instructions to for the Peers. Renewal may also be
signaled to life of the VPN
System.
3.1.3 PKI (not shown), particularly if Availability
Availability is REQUIRED initially for authorization
changes are necessary. Initiation transactions
between the PKI and Admin. Further availability is required in most
cases, but the extent of this process by availability is a decision point for
the Admin
enables IPsec Peers to automatically generate renewal, update or
rekey requests as needed with minimal user burden, Operator. Most requirements and for those
requests to be immediately granted by scenarios in this document assume
on-line availability of the PKI for the life of the VPN System. Local security
policy will determine whether Admin allows EE renewal without
authorization from Admin. Additionally, local policy will determine
whether EEs must renew or be reissued PKCs.
2) Renewals
Off-line interaction between the VPN and Updates [R]. The IPsec Peer requests renewal or
update of an existing PKC. Rekey MAY also occur depending upon policy
constraints. The renewal or change request will either be provided in
(10) above, or will be generated by PKI Systems (i.e., where
physical media is used as the IPsec Peer.
3) Renewal/Update Response [R]. The transport method) is beyond the scope
of this document.
3.1.4 End-User Transparency
PKI responds interactions are to be transparent to the renewal or
update request sent user. Users SHOULD NOT
even be aware that PKI is in (11), providing either use. First time connections SHOULD
consist of no more than a prompt for some identification and pass
phrase, and a status bar notifying the new PKC user that was
generated or a suitable error indication.
4) Enrollment Confirmation. Peer positively acknowledges receipt of
new PKC.
5) setup is in
progress.
3.1.5 PKC Posting. The newly-generated Profile for PKI Interaction
A PKC used for IPsec Peer 1 is posted to
the repository.
6) Maintenance [M]. The IPsec Peer accesses identity in VPN-PKI transactions MUST include all the PKI
[CERTPROFILE] mandatory fields. It MUST also contain contents
necessary to support look-
up of PKCs for other IPsec Peers, certification path validation, validation and
Bonatti, Turner, Lebovitz 15
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
revocation certificate status checking. This step consists of sending requests for
specific PKCs or CRLs, or requests for the PKI System to perform
validation checks.
7) Maintenance Response [M]. The PKI responds to the maintenance
request sent in (7), providing either
It is preferable that the requested PKC or CRL,
indicating the validity status of a PKC, or indicating an error
condition.
8) IKE/IPsec Communication [I]. The Peers communicate authenticated
by profiles for IPsec transactions
[IKECERTPROFILE] and VPN-PKI transactions (in the PKCs they received from certificate
management profile) are the PKI.
2.3.3 Revocation
The steps of same so that one PKC could be used for
both transaction sets. If the VPN-PKI interaction profiles are summarized here for
generating a new PKC. The letters refer to Figure 3. The numbers
refer inconsistent then
different PKCs (and perhaps different processing requirements) might
be required. However, failure to Figure 6. The detailed requirements are described below in
Section 3.
+--------------+ 2 +-----------------------+
| Repository |<----| Certificate Authority |
+--------------+ +-----------------------+
^ ^ ^
| 3 | 1 | 1, 1ÆÆ
| | |
| | |
| | 1Æ +-------+
| | +> | Admin |
| | | +-------+
| | |
| 4 | |
v | |
+--------------------+
| IPsec |
| Peer 1 |
+--------------------+
Figure 6. VPN-PKI Interaction Steps: Revocation
1) Revocation. The IPsec Peer or Admin requests revocation of IPsec
Peer 1Æs achieve PKC directly from profile consensus MUST
NOT hold up the PKI.
1Æ) Revocation. The IPsec Peer requests revocation of their PKC
through admin. standardization effort.
Bonatti, Turner, Lebovitz 16 12
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
1ÆÆ) Revocation. The Admin forwards IPsec Peer 1Æs PKC revocation
request to PKI.
2) CRL Posting.
3.1.5.1 Identity
PKCs MUST support identifying (i.e., naming) Peers and Admins. The newly-generated CRL revoking IPsec Peer 1Æs PKC
is posted to the repository.
3) Maintenance [M]. The IPsec Peer accesses the PKI to
following name forms MUST be supported:
- Fully-Qualified Domain Name (FQDN)
- RFC 822 (also called USER FQDN)
- IPv4 Address
- IPv6 Address
3.1.5.2 Key Usage
PKCs MUST support look-
up of CRL.
4) Maintenance Response [M]. The PKI responds to indicating the maintenance
request sent in (3), providing either purposes for which the requested CRL, indicating key (i.e.,
digital signature) can be used. Further, PKCs MUST always indicate
that relying parties (i.e., Peers) need to understand the validity status of a PKC, indication.
3.1.5.3 Extended Key Usage
Extended Key Usage (EKU) indications are not required. The presence
or indicating lack of an error condition.
3 Requirements
3.1 General Requirements
3.1.1 One Protocol
The target profile, EKU MUST NOT cause an implementation to be based on this requirements document, fail an IKE
connection.
3.1.5.4 Revocation Information Location
PKCs MUST
call for ONE PROTOCOL or ONE USE PROFILE for each main element of indicate the
requirements. It is a specific goal to avoid multiple competing
protocols or profiles to solve location of CRL such that any Peer who holds
the same requirement whenever possible
so as PKC locally will know exactly where to reduce complexity go and improve interoperability.
Meeting some of the requirements MAY necessitate how to request the creation of a
new
CRL.
3.1.6 Error Handling
The protocol or new extension for an existing protocol; however, the
late is much preferred.
3.1.2 Secure Transactions
The target profile VPN-PKI transactions MUST specify the transactions error handling
for certificate
management between VPN each transaction. Thorough error condition descriptions and
handling instructions will greatly aid interoperability efforts
between the PKI Systems and their components, to ease
large-scale VPN deployment and management. Specifically, Admin and
PKI MUST transmit between themselves policy details, identities, and
keys. As such, System products.
3.2 Authorization
This section refers to the method of communication for these transactions
MUST be secured [A] elements labeled in a manner that ensures privacy, authentication,
message data integrity and non-repudiation. This communication method Figure 3.
3.2.1 One Protocol
One protocol MUST require that mutual trust be established between the PKI and the
Admin.
3.1.3 PKI Availability
Central availability is REQUIRED initially specified for authorization
transactions between the these Admin to PKI and Admin. Further availability MAY be
required in most cases, but is a decision point for the Operator. (RA/CA)
interaction. This protocol MUST support privacy, authorization,
Bonatti, Turner, Lebovitz 17 13
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
Most requirements and scenarios below assume on-line availability of
the PKI
authentication, and Admin integrity. PKCs for the life authorization of the VPN.
Off-line interaction between the VPN and PKI Systems (i.e., where
physical media is used as the transport method) is beyond the scope
of this document.
3.1.4 End-User Transparency
PKI interactions are to Admin
can be transparent initialized through an out-of-band mechanism.
The transport used to carry the user. Users authorization SHOULD NOT
even be aware that PKI is in use. First time connections SHOULD
consist of no more than a prompt for some identification and pass
phrase, and a status bar notifying the user that setup is in
progress.
3.1.5 Error Handling reliable
(TCP).
The PKC transaction protocol for the PKI and VPN System transactions
MUST specify error handling for each transaction. Thorough error
condition descriptions and handling instructions will greatly aid
interoperability efforts between the PKI and IPsec products.
3.2 Authorization Transactions
This section refers to the [A] elements labeled in Figure 3.
3.2.1 SHOULD be as lightweight as possible.
3.2.2 Bulk Authorization
Bulk authorization MUST be supported by the target certificate management
profile. Bulk authorization occurs when the Admin requests of the PKI
that authorization be established for several different subjects with
almost the same contents. A minimum of one value (more is also
acceptable) MUST differ differs per subject. Because the authorization authorizations may occur
before any keys have been generated, the only way to determine
one authorization from another for the purpose of issuing ensure unique
authorization identifiers are issued is by having to have at least one value differ.
The authorization MAY
differ per subject.
Authorization can occur prior to the event of a PKC enrollment
request (in which case it is a "pre-authorization"), request, or within the
authorization and the PKC enrollment request can be presented to the
PKI at the same connection.
3.2.2 Protocol Preferences for Authorization
The setup for all subjects in an time. Both of these authorization scenarios MUST be
supported.
A bulk authorization batch SHOULD occur in one single connection to the RA/CA, PKI
(RA/CA), with the number of subjects being
Bonatti, Turner, Lebovitz 18
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile one or greater.
Implementations SHOULD be able to handle one thousand
at subjects in a time.
ONE protocol MUST be specified
batch authorization.
Bonatti, Turner, Lebovitz 14
Internet-Draft Requirements for these Admin to RA/CA interaction. an July 2005
IPsec Certificate Management Profile
3.2.3 Authorization Scenario
The PKI responds to authorization scenario for VPN-PKI transactions involves a two-
step process: an authorization request and an authorization
response. Figure 4 shows the salient interactions to perform
authorization transactions.
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
| 1
2 |
v
+-------+
| Admin station with |
+-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 4. Authorization identifiers
(maybe serial numbers or such) Transactions
1) Authorization [A]. Admin sends a list of identities and PKC
contents for the PKI System to authorize enrollment. The PKI returns
a corresponding list of unique authorization key
(not identifiers and one-time authorization
tokens to be confused with the public and private key pair) used for the enrollment of each
identifier. PKC. See paragraph
3.2.4.
2) Authorization Response [A]. The transport used to carry PKI System acknowledges the pre-authorization SHOULD be reliable
(TCP).
The protocol SHOULD be as lightweight as possible.
A method
authorizations provided in (1). Response may indicate success,
failure, or errors for securing the communication between any particular authorization. See paragraph
3.2.5.
3.2.4 Authorization Request
3.2.4.1 Specifying Fields within the PKC
The Admin and authorizes individual PKCs or batches of PKC issuances
based on a pre-agreed template. This template is agreed by the VPN
Operator and PKI
MUST be defined, including privacy, authorization, authentication,
integrity, Operator and non-repudiation. PKCs for is referred to in each authorization of
Bonatti, Turner, Lebovitz 15
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
request. This allows the Admin
MAY need to be initialized by physical rather than on-line means.
3.2.3 Admin Authorization Requests authorization requests to PKI
3.2.3.1 Specifying Fields within include the PKC
minimal amount of information necessary to support a VPN System.
The Admin MAY can send the PKI System the set of PKC contents that make
up a PKC template that it
wants the PKI to use. 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,
from this person, process it and issue the PKC." Likewise, such
Requirements for PKC fields used in IPsec transactions are specified
in [IKECERTPROFILE].
Requirements for PKC fields used in VPN-PKI transactions are
specified in paragraph 3.1.5.
3.2.4.2 Authorizations for Renewal, Update, and Rekey
When the VPN Operator and PKI Operator pre-agree on a
template MAY have already been defined template, they
MUST also agree on the PKI System, local policy regarding PKC renewal and PKC
update. These are:
- Admin MUST specify if automatic renewals are allowed, that is,
the Admin may simply reference it.
In authorizes the former case, PKI to process a future renewal for the elements
specified Peer PKC.
- Admin MUST specify if PKC update is allowed, that is, the Admin MAY send to
authorizes the PKI to authorize accept a future request for a new PKC with
changes to non-key-related fields.
If a PKC renewal is authorized, the eventual creation of PKCs include:
- DN fields with CN, C, O, OU naming attributes
- Any number of locally defined CNs with their contents
- Validity Period of the PKC
- Renewal parameters (i.e., renewal not permitted, N% of validity
period, or the UTC time after which renewal is permitted)
- Key type
- Key length
- Extension fields:
Bonatti, Turner, Lebovitz 19
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
- KeyUsage set digitalSignature, nonRepudiation, or both bits.
- SubjAltName fields: FQDN, User_FDQN, IPv4_ADDR, and IPv6_ADDR.
- Require a CDP be filled in by the PKI in issuance. The profile,
based on these requirements, SHOULD define who will handle the
CDP contents.
3.2.3.2 Authorizations for Renewal and Update
When the Admin sends its authorization request information it MUST
also send information to the PKI about the local policy regarding PKC
renewal and PKC update. These are:
- Admin MUST specify if automatic renewals are allowed, that is,
the Admin is presently authorizing the PKI to process a future
renewal for the specified end entity PKC.
- Admin MUST specify if PKC update is allowed, that is, the Admin
is presently authorizing the PKI to accept a future request for
a new PKC creation with changes to non-key-related fields.
If a PKC renewal is authorized, the Admin MUST further specify: Admin MUST further specify:
- Who can renew, that is, can only the admin Admin send a renewal request
or can the end entity Peer send a request directly to the PKI, or either.
- Specify at how long before the PKC expiration date the PKI will
accept and process a renewal (i.e., N% of validity period, or
the UTC time after which renewal is permitted).
If PKC update is authorized, the Admin MUST further specify:
- The aspects of non-key-related fields that are changeable.
- The entity that can send the PKC Update request, that is, only
the Admin, only the end entity, Peer, or either.
- Specify at how long before the PKC expiration date the PKI will
accept and process an update (i.e., N% of validity period, or
the UTC time after which update is permitted).
Bonatti, Turner, Lebovitz 16
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
A new authorization by the Admin is REQUIRED for PKC rekey. No
parameters of prior authorizations need be considered.
Bonatti, Turner, Lebovitz 20
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
3.2.3.3
3.2.4.3 Other Authorization Elements
CDP MUST be flagged as required in the authorization request.
The
method Admin MUST also be specified; HTTP is have the MUST method, LDAP is MAY.
There MUST be an option ability to specify a Validation Period the format for the
authorization ID and its one-time authorization key. If token. The one-time
authorization token SHOULD be unique per authorization ID. The more
randomness that can be achieved in the relationship between an
authorization ID and its one-time authorization token the better. The
one-time authorization token MUST be in UTF8 format to avoid
incompatibilities that may occur due to international characters. It
MUST support normalization as in (certificate management profile).
The Admin MUST have the ability to constrain the UTF8 character set.
There MUST be an option to specify a validation period for the
authorization ID and its one-time authorization token. If such a Validation
Period
validation period is set, any PKC requests using this authorization id
ID and key one-time authorization token that arrive at the PKI outside of
the validation period MUST be dropped and the event logged.
The Admin MUST have the ability to communicate the Community Realm
for the PKC to the PKI. Community Realm is an important component in
provisioning that allows the Admin to specify for the Peer various
elements of the PKCÆs contents that the PKI will fill in, and are not
defined by the Admin. It may be used to specify various local policy
definitions. It also will be used to label different groups to have
different CRLs (for example small CRLs with only gateways in the
listing for use by Remote Access Peers, or large CRLs with all Remote
Access Peers and gateways to be used by the Gateways). There will be
a need for an import and export for easily synchronizing the
Community Realm lists between the Admin and PKI System.
The Protocol SHOULD consider what happens when Admin requested
information conflicts with PKI settings such that the Admin request
cannot be issued as requested (e.g., Admin requests Validation Period validation period
= 3 weeks and CA is configured to only allow Validation Periods validation periods = 1
week). Proper conflict handling MUST be specified.
3.2.4
3.2.4.4 Cancel Capability
Either the Admin or the Peer can send a cancel authorization message
to PKI. The canceling entity MUST provide the authorization ID and
one-time-token
one-time authorization token in order to cancel the Authorization. authorization. At
that point, the authorization will be erased from the PKI, and a log
entry of the event written.
After the cancellation has been verified (a Cancel, Cancel ACK, ACK
type of a process is REQUIRED to cover a lost connections scenario),
the PKI will accept a new Authorization authorization request with the exact same
contents as the canceled one, except that the identifier MUST be new.
The PKI MUST NOT process duplicate authorization requests.
Note that if the PKI has already issued a PKC associated with an
authorization, then cancellation of the authorization is not
possible and the authorization request SHOULD be refused by the PKI.
Once a PKC has been issued it MUST be revoked in accordance with
clause 3.8. 3.6.
Bonatti, Turner, Lebovitz 21 17
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
3.2.5 PKI response to Admin Authorization Response
If the authorization is acceptable, the PKI will respond to the Admin
with a unique authorization identifier per subject authorization
requested and a one-time authorization key token per authorization ID. The one-time
See paragraph 3.2.4.3 for additional authorization key SHOULD be unique per ID and one-time
authorization ID. token requirements.
The more
randomness that PKI can be achieved in the relationship between an
identifier and its key the better. The key MUST be in ASCII format to
avoid incompatibilities that may occur due to international
characters.
The PKI MAY alter parameters of alter parameters of the authorization request submitted
by the Admin. In that event, the PKI MUST return all the contents of
the authorization template request (as modified) to the Admin with the
confirmation of authorization success. This will allow the Admin to
perform an "operational test" to verify that the issued PKCs will
meet its requirements. If the Admin determines that the modified
parameters are unacceptable, then the authorization should be
cancelled in accordance with clause 3.2.4. 3.2.4.4.
After receiving a bulk authorization request from the Admin, the PKI
MUST be able to reply YES to those individual PKC authorizations that
it can satisfy has satisfied and NO or FAILED for those requests that cannot be
satisfied, along with sufficient reason or error codes.
A method is required REQUIRED to identify if there is a change in PKI setting
between the time the authorization is granted and PKC request occurs,
and what to do about the discrepancy.
3.2.6
3.2.5.1 Error Handling for Authorization Transactions
Thorough error condition descriptions and handling instructions MUST
be provided to the Admin for each transaction in the authorization
process. Providing such error codes will greatly aid interoperability
efforts between the PKI and IPsec products.
3.3 Key Generation and PKC Request Construction
This section refers to the [G] elements labeled in Figure 3.
Once the PKI System has responded with authorization identifiers and
keys,
authorization tokens (see paragraph 3.2), and this information is
received at the Admin, the next step is to generate public and
private key pairs and to construct PKC requests using those key
pairs. The key generations MAY can occur at one of three places,
depending on local requirements: at the IPsec Peer, at the Admin, or
at the PKI. The PKC constructions MAY occur at request can come from either the IPsec Peer or Peer, a
combination of the Peer and the Admin. Admin, or not at all.
Bonatti, Turner, Lebovitz 22 18
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
3.3.1 Key Generation Scenarios
3.3.1.1 Method 1: IPsec Peer Generates Key Pair and Pair, Constructs
PKC Request, and Signs PKC Request
This case 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
and never leave the end entity.
The Admin will send the authorization identifier and authorization private key to never leaves the end entity, the IPsec Peer. The Admin will also send any
other parameters needed by the Peer to generate the PKC request,
including key type and size. Recall that the mechanism for how this
information is communicated from the Admin to the Peer entity. However, it is opaque.
Receiving the command and the necessary information from the Admin,
most computationally intensive for the Peer will proceed as it must be "ASN.1
aware" to generate the key pair support generating and construct digitally signing the PKC request. Figure 7 illustrates this scenario.
+---------------------------+
| Certificate Authority |
+---------------------------+
^
+--------------+ +-----------------------+
| ^ Repository | | CA/RA |
+--------------+ +-----------------------+
+-------+
+------>| Admin |
| +-------+
|
| 5 1 | |
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| | | v
| | +-----------+
| | | Admin |
4 | | +-----------+
| | |
| | | 3
| | |
| v v
+--------------------+
| IPsec Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 7. Key 5. Generation and Enrollment
Request Construction by Interactions:
IPsec Peer
1) Authorization
2) Authorization Response
3) Generates Key Pair and Constructs PKC Request Information
- PKC Request Unique Identifier
Bonatti, Turner, Lebovitz 23
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
- One-time Authorization Key
4) Enrollment Request
- Completed PKC field assertions
- PKC Request Unique Identifier
- One-time Authorization Key
- Public Key
- Proof of Possession of Associated Private Key
5) Enrollment Response
- Distribute PKC
3.3.1.2 IPsec Peer Generates Key Pair, Admin Constructs Request
In this case, the
1) Opaque transaction. Admin sends a command to authorization identifier, one-time
authorization token, and any other parameters needed by the Peer to
generate the PKC request, including key pair. The Admin then type and size.
2) Generation [G]. Peer receives authorization identifier, one-time
authorization token, and any parameters. Peer generates key pair and
constructs the PKC request on behalf of the
Peer, except for the signing. It sends the construction request.
Steps prior to these can be found in paragraph 3.2. The next step,
enrollment, can occur either directly between the Peer
for signing, and PKI (see
paragraph 3.4.5) or through the Admin (see paragraph 3.4.6).
3.3.2 Generation Method 2: IPsec Peer returns the signed request construction
back to the Admin. The Generates Key Pair, Admin then proceeds to enroll on behalf of the
client. Figure 8 illustrates this scenario.
The advantage
Constructs PKC Request, Admin Signs PKC Request
This option also supports IPsec Peer generation of this solution is that the private key never leaves
the IPsec Peer, pair, but limits
removes the amount requirement for the Peer must know and do
regarding PKC generation. to be ASN.1 aware because it
Bonatti, Turner, Lebovitz 24 19
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
+---------------------------+
| Certificate Authority |
+---------------------------+
^
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.
+--------------+ +-----------------------+
| ^ Repository | | CA/RA |
+--------------+ +-----------------------+
3 +-------+
+------>| Admin | 4
| +-------+
|
| 5 1 | |
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| | | v
| | +-----------+
| | | Admin |
4 | | +-----------+
| | |
| | | 3
| | |
| v v
+--------------------+
| IPsec Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 8. Key 6. Generation By Interactions:
IPsec Peer with Generates Key Pair, Admin Construction of Enrollment Constructs PKC Request
1) Authorization Opaque transaction. Admin sends command to Peer to generate key
pair, based on parameters provided in the command.
2) Authorization Response Generation [G]. Peer generates key pair.
3) PKC Request Template
- Pre-authorized PKC fields
- PKC Request Unique Identifier
- One-time Authorization Key Opaque transaction [G]. Peer returns key pair to Admin.
4) Enrollment Request
- PKC Request Template
- Public Key
- Proof of Possession of Associated Private Key
5) Enrollment Response
- Distribute Generation [G]. Admin constructs and digitally signs PKC
Bonatti, Turner, Lebovitz 25
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
3.3.1.3 request.
Steps prior to these can be found in paragraph 3.2. The next step,
enrollment, occurs through the Admin (see paragraph 3.4.7).
3.3.3 Generation Method 3: Admin Generates Key Pair and Pair, Constructs PKC
Request, and Signs PKC Request
The use case
This option exists for deployments where end entities Peers cannot generate their
own key pairs. Figure 9 illustrates the steps
entailed. Some examples are for PDAs and handsets where to
generate an RSA key would be operationally impossible due to
processing and battery constraints. Another case covers key recovery
requirements, where the same PKCs are used for other functions in
addition to IPsec, and key recovery is required (e.g. local data
encryption), therefore key escrow is needed off the end entity station. Peer. If key
escrow is performed then the exact requirements and procedures for it
are beyond the scope of this document.
The
Bonatti, Turner, Lebovitz 20
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+-------+
| Admin will generate the | 1
+-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 7. Generation Interactions:
Admin Generates Key Pair and Constructs PKC Request
1) Generation [G]. Admin generates key pair, construct the constructs PKC request,
and
enroll on behalf of the Peer. Once the PKC has been retrieved, the
keys and digitally signs PKC will be sent request.
Steps prior to the Peer using a secure method. these can be found in paragraph 3.2. The
nature of this secure method is beyond next step,
enrollment, occurs through the scope of this document.
Performing a Admin (see paragraph 3.4.8).
Note that separate pre-authorization authorizations step is are still of value even though
the Admin is the also performing the key generation. The
Community Realm, PKC
template, Subject fields, SubjectAlt SubjectAltName fields and more are part of
the request, and must be communicated in some way from the Admin to
the PKI. Instead of creating a new mechanism, we simply use the
pre-authorize authorization
schema again. can be reused. This also allows for the feature of role-
based role-based
administration, where Operator 1 is the only one allowed to have the
Admin function pre-authorize PKCs, but Operator 2 is the one doing
batch enrollments and VPN device configurations.
+---------------------------+
| Certificate Authority |
+---------------------------+
^ | ^ |
| | | |
| | 5 1 | | 2
| | | |
| | | v
| | +-----------+
| | | Admin |
4 | | +-----------+
| | |
| | | 3
| | |
| v v
+--------------------+
| IPsec |
| Peer |
+--------------------+
Figure 9. Key and Enrollment Request
Bonatti, Turner, Lebovitz 26 21
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
Generation By VPN Admin
1) Authorization
2) Authorization Response
3) PKC Request Template
- Pre-authorized PKC fields
- PKC Request Unique Identifier
- One-time Authorization Key
- Public Key
- Private Key
- Proof of Possession of Associated Private Key
4) Enrollment Request
- PKC Request Template
5) Enrollment Response
- Distributed PKC
3.3.1.4
3.3.4 Method 4: PKI Generates Key Pair and Passes to Peer via Admin
This use case allows the PKI to option exists for deployments where end entities cannot generate the
their own key pair pairs and the PKC
after which it simply hands the PKC down to the Admin for
installation into function is minimal implementation.
The PKI and Admin pre-agree to have the Peer. PKI generate 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 the Admin
have access to the private key. However, in cases where key escrow is
required, this may be acceptable. Figure 10
illustrates this scenario. The Admin effectively acts as a
proxy for the Peer in the PKC enrollment process.
Bonatti, Turner, Lebovitz 27
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
+---------------------------+
| Certificate Authority
+--------------+ +-----------------------+
|
+---------------------------+
^ Repository | | CA/RA | 1 | | 2
| |
| v
+-----------+
+--------------+ +-----------------------+
+-------+
| Admin |
+-----------+
|
+-------+
+--------------------+ +--------+
| 3 IPsec |
v
+--------------------+ | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 10. Key 8. Generation By PKI with
Proxy Enrollment via VPN Admin
1) Authorization & PKC Enrollment Request
- PKC field assertions
- Public Key
- Proof of Possession of Associated Private Key
2) Enrollment Response
- Distributed PKC
- Associated private key
3) Peer Provisioning
- Distributed PKC
- Associated private key
3.3.1.5 Interactions:
IPsec Peer Generates Key Pair Without Prior Authorization
In many situations, a use case in which the VPN Peer makes sole
contact with the Pair, Admin Constructs PKC Request
1) Generation [G] The PKI can simplify the enrollment process. This
would allow individuals or small organizations to obtain PKCs for
Bonatti, Turner, Lebovitz 28
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
VPNs without a significant administrative footprint. Figure 11
illustrates this scenario.
This scenario uses essentially generates the same enrollment steps as key pair.
Steps prior
scenarios, but has the additional facet that some proof of identity
mechanism, proof of payment, or other mechanisms may to these can be required by found in paragraph 3.2. The next step,
enrollment, occurs through the PKI as a precondition of PKC issuance.
+---------------------------+
| Certificate Authority |
+---------------------------+
^ |
| |
1 | | 2
| |
| v
+--------------------+
| IPsec |
| Peer |
+--------------------+
Figure 11. Key Generation By IPsec Peer
Without Prior Authorization
1) Enrollment Request
- PKC field assertions
- Proof of Identity, Payment, etc.
- Public Key
- Proof of Possession of Associated Private Key
2) Enrollment Response
- Distributed PKC
3.3.2 Admin (see paragraph 3.4.9).
3.3.5 Error Handling for Key Generation and PKC Request Construction
Thorough error condition descriptions and handling instructions MUST
be provided for each transaction in the key generation and PKC
request construction process. Providing such error codes will greatly
aid interoperability efforts between the PKI and IPsec products.
Error conditions MUST be communicated to the Admin regardless of who
generated the key or PKC request.
Bonatti, Turner, Lebovitz 29 22
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
3.4 Enrollment (Sending Request and PKC Retrieval)
This section refers to the [E] elements labeled in Figure 3.
Regardless of where the keys were generated and the PKC request
constructed, an enrollment process will need to occur to request a
PKC creation from that
the PKI issue a PKC and to retrieve that PKC.
The protocol MUST the corresponding PKC be returned.
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
PKI (as seen below in sections 3.4.5 through 3.4.7).
PKI.
3.4.1 One protocol
One protocol MUST be specified for both enrollment requests requests, responses,
and
responses. confirmations.
3.4.2 On-line protocol
The protocol MUST supports support enrollment that occurs over the Internet
and without the need for manual intervention.
3.4.3 Single Connection with Immediate Response
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
itself and the PKI (RA/CA).
3.4.4 Manual Approval Option
The optional capability to queue and manually approve PKC requests
MUST exist within the protocol for those organizations that will not
permit automation
Manual approval of credential issuing as described above. Likewise,
polling to determine if request has been satisfied and to try to
retrieve the PKC MUST exist within the protocol enrollments is too time consuming for those
organizations that will large
scale implementations is therefore not permit automation of credential issuing
as described above.
The Admin and the PKI must disclose and agree upon which mode they
will support (automated approval or manual approval) within the
protocol. required.
3.4.5 Enrollment Method 1: Peer Enrolls to PKI Directly
In this case, the Admin can instruct the IPsec Peer to execute an
enrollment, telling it where to enroll, and providing any necessary
parameters.
Bonatti, Turner, Lebovitz 30
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
In this case, the IPsec Peer only communicates with the PKI after
being commanded to do so by the Admin. Note that this This enrollment mode is
depicted in Figure 4.
3.4.6 Enrollment Method 2: 9 and the letters in the following description
refer to Figure 3. Prior authorization (see paragraph 3.2) and
generation (see paragraph 3.3.1) steps are not shown.
Most IPsec Peer Enrolls Systems have enough CPU power to PKI through Admin generate a public and
private key pair of sufficient strength for secure IPsec. In this
case, the IPsec Peer has generated end entity needs to prove to the PKI that they have such a
Bonatti, Turner, Lebovitz 23
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
key pair and the PKC
request, but does not enroll directly to pair; this is normally done by the PKI System. Instead, it
automatically sends its request to sending the Admin, end entity a
nonce, which the end entity signs and returns to the Admin
automatically performs 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 Admin retrieves the PKC, it then
automatically forwards it to the IPsec Peer, and the Peer can begin
using it in security policy.
The communication of the request, retrieval, renewal, update or
rekey, can go directly from the end entity to the PKI, or be passed
from end entity through the Admin to the PKI. In the latter case, the
end entity need not know how to do all the direct communication with
the PKI; the function becomes focused in the Admin station. In either
case, the format of messages should be identical regardless of who is
sending the request.
Most IPsec Systems have enough CPU power to generate a public and
private key pair of sufficient strength for secure IPsec. In this
case, the end entity needs to prove to the Admin that they have such
a key pair; this is normally done by the Admin sending the end entity
a nonce, which the end entity signs and returns to the Admin along
with along with
the end entityÆs public key.
The steps of the VPN-PKI interaction are summarized here for the
IPSec Peer enrolling through the Admin. The letters refer to Figure
3. The numbers refer to Figure 12.
Bonatti, Turner, Lebovitz 31
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
+--------------+ 10 +-----------------------+
| Repository |<----| Certificate Authority | | CA/RA |
+--------------+ +-----------------------+
^ ^
| 11 | 1, 5, 9
1,3 | 2, 6
|
| v
| +-------+
| +> | Admin |
| 4, 8 | +-------+
|
2,4 |
| 12 | 3,7
v
v
+--------------------+ +--------+
| IPsec | 13 | IPsec |
| Peer 1 |<========>| | | Peer 2 |
+--------------------+ +--------+
Figure 12. 9. VPN-PKI Interaction Steps:
IPsec Peer Generates Keys and PKC Request,
Enrolls Through Admin Directly with PKI
1) Authorization [A]. Admin sends a list of IDs and PKC contents for
the PKI System to authorize enrollment. The PKI returns a list of
unique identifiers and one-time tokens to be used for the enrollment
of each PKC. Other PKC usage policy is also set at this time, for
example parameters for renewals, updates or rekey, key lengths, etc.
The amount of information that the Admin communicates to the PKI
about how it wants the PKCs built could be very small, perhaps just a
reference to a template already existing in the PKI System. Likewise
it could be very large, with several fields being specified along
with their contents.
2) Authorization Response [A]. The PKI System acknowledges the
authorizations provided in (1). Response may indicate success or
failure for any particular authorization.
3) Generate Keys and PKC Request [G]. The Admin communicates with the
Peer to give it information so that it can generate a public and
private key pair and PKC request and send the request back to the
Admin.
4) Enrollment Request [E]. The IPsec Peer requests a sends PKC requests from the Admin,
PKI, providing the generated public key.
5) Enrollment [E]. The Admin forwards the enrollment request to the
PKI.
Bonatti, Turner, Lebovitz 32
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
6)
2) Enrollment Response [E]. The PKI responds to the enrollment
request sent in (5),
request, providing either the new PKC that was generated or a
suitable error indication.
7)
3) Enrollment Response Confirmation [E]. The Admin forwards the enrollment
response back to the IPsec Peer.
8) Enrollment Confirmation. Peer must positively acknowledge acknowledges receipt
of new PKC back to the Admin.
9) PKC.
4) Enrollment Confirmation. Admin forwards Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the PKI.
10) PKC Posting. The newly-generated PKC for IPsec Peer.
3.4.6 Enrollment Method 2a: Peer 1 is posted
to Enrolls through Admin
In this case, the repository.
11) Maintenance [M]. The IPsec Peer accesses has generated the PKI to support look-
up of PKCs for other IPsec Peers, certification path validation, key pair and
revocation checking. This step consists of sending requests for
specific PKCs or CRLs, or requests for the PKI System PKC
request, but does not enroll directly to perform
validation checks.
12) Maintenance Response [M]. The the PKI responds System. Instead, it
automatically sends its request to the maintenance
request sent in (11), providing either Admin, and the requested PKC or CRL,
indicating Admin redirects
the validity status of a PKC, or indicating an error
condition.
13) IKE/IPsec Communication [I]. enrollment to the PKI System. The Peers communicate authenticated
by PKI System does not care where
the PKCs they received from enrollment comes from, as long as it is a valid enrollment. Once
Bonatti, Turner, Lebovitz 24
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
the PKI.
3.4.7 Enrollment Method 3: Admin Enrolls receives the PKC response, it automatically forwards it to
the PKI Directly IPsec Peer.
Most IPsec Systems have enough CPU power to generate a public and
private key pair of sufficient strength for secure IPsec. In this instance,
case, the Admin is performing a function similar end entity needs to that
of a Registration Authority (RA), as defined in [CERTPROFILE]. The prove to the Admin will that they have likely generated the such
a key pair and constructed the
request on behalf of pair; this is normally done by the IPsec Peer. It proceeds to handle Admin sending the entire
enrollment directly with end entity
a nonce, which the PKI, end entity signs and returns to the IPsec Peer Admin along
with the
final product of a key pair end entityÆs public key.
This enrollment mode is depicted in Figure 10 and PKC. Again, the mechanism for letters in the
Peer to Admin communication is opaque.
The steps of the VPN-PKI interaction are summarized here for the
Admin enrolling directly to the PKI. The letters refer
following description refer to Figure 3.
The numbers refer to Figure 13.
Bonatti, Turner, Lebovitz 33
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile Prior authorization (see
paragraph 3.2) and generation (see paragraph 3.3.1) steps are not
shown.
+--------------+ 7 +-----------------------+
| Repository |<----| Certificate Authority | | CA/RA |
+--------------+ +-----------------------+
^ ^
| 8 | 1, 4, 6
| 2, 5 2,6
|
|
v
| 9 3,7
1,5 +-------+
+--------------+>
+> | Admin | 3
| +-------+
|
10
|
4,8 v
+--------------------+ +--------+
| IPsec | 11 | IPsec |
| Peer 1 |<========>| | | Peer 2 |
+--------------------+ +--------+
Figure 13. 10. VPN-PKI Interaction Steps:
Admin
IPsec Peer Generates Keys and PKC Request,
Enrolls Through Admin Performs Enrollment
1) Authorization [A]. Admin sends a list of IDs and PKC contents for
the PKI System to authorize enrollment. The PKI returns a list of
unique identifiers and one-time tokens to be used for the enrollment
of each PKC. Other PKC usage policy is also set at this time, for
example parameters for renewals, updates or rekey, key lengths, etc.
The amount of information that the Admin communicates to the PKI
about how it wants the PKCs built could be very small, perhaps just a
reference to a template already existing in the PKI System. Likewise
it could be very large, with several fields being specified along
with their contents.
2) Authorization Response [A]. The PKI System acknowledges the
authorizations provided in (1). Response may indicate success or
failure for any particular authorization.
3) Generate Keys and PKC Request [G]. The Admin generates the public
private key pair and PKC request.
4) Enrollment Opaque Transaction [E]. The Admin IPsec Peer requests a PKC from the PKI
Admin, providing the generated public key.
5)
2) Enrollment [E]. The Admin forwards the enrollment request to the
PKI.
3) Enrollment Response [E]. The PKI responds to the enrollment
request sent in (4),
request, providing either the new PKC that was generated or a
suitable error indication.
4) Opaque Transaction [E]. The Admin forwards the enrollment response
back to the IPsec Peer.
Bonatti, Turner, Lebovitz 34 25
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
6) Enrollment Confirmation. Admin
5) Opaque Transaction [E]. Peer must positively acknowledge receipt
of new PKC back to the Admin.
6) Enrollment Confirmation [E]. Admin forwards enrollment
confirmation back to the PKI.
7) PKC Posting. The newly-generated PKC for IPsec Peer 1 is posted Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the repository. Admin.
8) Maintenance [M]. The Opaque Transaction [E]. Admin accesses the PKI to retrieve the new
PKC.
9) Maintenance Response [M]. The PKI responds forwards PKI's enrollment
confirmation receipt back to the maintenance
request sent in (8), providing the requested PKC, or indicating an
error condition.
10) Peer.
3.4.7 Enrollment Method 2b: Peer Enrolls Through Admin sends newly
In this case, the IPsec Peer has generated the key pair, but the PKC
request is constructed and private key to IPsec Peer.
11) IKE/IPsec Communication [I]. The Peers communicate authenticated signed by the PKCs they received from the PKI.
3.4.8 Enrollment Type Field
A field MUST exist in Admin. The PKI System does
not care where the enrollment request comes from, as long as it is a valid
enrollment. Once the Admin retrieves the PKC, it then automatically
forwards it to specify the TYPE of
request being made. Request types include new request, renew request,
update request, and rekey request (renewals, updates IPsec Peer along with the key pair.
Some IPsec Systems do not have enough CPU power to generate a public
and rekeys are
discussed in detail in section 3.6). The type field is required private key pair of sufficient strength for
monitoring, logging and auditing purposes. They will help secure IPsec. In this
case, the
Operator Admin needs to prove to know exactly what type of request was made so that
suspicious activities, even if the request is denied, can be
identified.
3.4.9 Confirmation Handshake
Any time PKI that they have such a new PKC key
pair; this is issued normally done by the PKI, PKI sending the Admin a confirmation of PKC
receipt MUST be sent back to the PKI by the Peer or nonce,
which the Admin
(forwarding the PeerÆs confirmation). This is true for first time
issuances, renewals, updates signs and rekeys alike.
Operationally, the Peer MUST send a confirmation returns to the PKI verifying
that it has received along with the PKC, loaded it, and can use it effectively
in an IKE exchange. end
entityÆs public key.
This requirement exists so that:
- The PKI does not publish the new PKC in the repository for others
until that PKC is able to be used effectively by the Peer, and;
- A revocation may be invoked if the PKC enrollment mode is not received depicted in Figure 11 and
operational within an allowable window of time.
To assert such proof the Peer MUST sign a portion of data with letters in the
new key. The result MUST be sent
following description refer to the PKI. The entity that actually Figure 3. Prior authorization (see
paragraph 3.2) and generation (see paragraph 3.3.2) steps are not
shown.
Bonatti, Turner, Lebovitz 35 26
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
sends the result to the PKI MAY be either the Peer (sending it
directly to the PKI) or
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 1,5
|
|
v 2,6
4 +-------+
+->| Admin (the |
| +-------+
|
|
3,7 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer would send it to Admin, 1 | | Peer 2 |
+--------------------+ +--------+
Figure 11. VPN-PKI Interaction Steps:
IPsec Peer Generates Keys, Admin Constructs and
Signs PKC Request, Enrolls Through Admin can in turn send it to the PKI).
1) Enrollment [E]. The Admin MUST acknowledge requests a PKC from the successful receipt of PKI, providing
the
confirmation, thus signaling to the Peer that it may proceed using
this PKC in IKE connections. generated public key.
2) Enrollment Response [E]. The PKI MUST complete all processing
necessary responds to enable the PeerÆs operational use of enrollment
request, providing either the new PKC (for
example, writing the PKC to the repository) before sending the
confirmation acknowledgement. The PKI MUST also issue that was generated or a revocation on
suitable error indication.
3) Opaque Transaction [E]. The Admin forwards the original PKC before sending enrollment response
back to the confirmation ACK (see section
4.X). The IPsec Peer.
4) Opaque Transaction [E]. Peer MUST NOT begin using the positively acknowledge receipt of new
PKC until back to the PKIÆs Admin.
5) Enrollment Confirmation [E]. Admin forwards enrollment
confirmation acknowledgement has been received.
3.4.10 Failure Cases
Thorough error condition descriptions and handling instructions are
REQUIRED for each transaction in back to the PKI.
6) Enrollment Confirmation Receipt [E]. PKI sends enrollment process. Providing
such error codes will greatly aid interoperability efforts between
confirmation receipt back to the PKI and IPsec products.
The profile will clarify what happens if Admin.
7) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the request and retrieval
fails Peer.
Bonatti, Turner, Lebovitz 27
Internet-Draft Requirements for some reason. The following cases MUST be covered:
- an July 2005
IPsec Certificate Management Profile
3.4.8 Enrollment Method 3a: Admin or Peer cannot send Authorizes and Enrolls Directly to
PKI
In this case, the request.
- Admin or Peer sent the request but generates the PKI did not receive key pair, PKC request, and
digitally signs the PKC request.
- The PKI received the request but could System does not read it effectively.
- PKI received and read care where
the request, but some contents of the
request violated the PKIÆs configured policy such that the PKI
was unable to generate the PKC.
- The PKI System generated the PKC, but could not send it.
- The PKI sent the PKC, but enrollment comes from, as long as it is a valid enrollment. Once
the requestor (Admin or Peer) did not
receive it.
- The Requestor (Admin or Peer) received Admin retrieves the PKC, but could not
process it due to incorrect contents, or other PKC-construction-
related problem.
- The Requestor failed trying to generate the confirmation.
- The Requestor failed trying then automatically forwards it to send the confirmation.
Bonatti, Turner, Lebovitz 36
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
- The Requestor sent the confirmation, but the PKI did not receive
it.
- The PKI received Peer along with the confirmation but could key pair.
Some IPsec Systems do not process. have enough CPU power to generate a public
and private key pair of sufficient strength for secure IPsec. In each case this
case, the following questions MUST be addressed:
- What does Peer do?
- What does Admin do?
- What does needs to prove to the PKI do?
- Is Authorization used?
If that they have such a failure occurs after key
pair; this is normally done by the PKI sends sending the PKC and before Admin a nonce,
which the Peer
receives it, then Admin signs and returns to the Peer MUST re-request PKI along with the same
Authorization ID and one-time-key, end
entityÆs public key.
This enrollment mode is depicted in Figure 12 and the PKI, seeing the ID and
key, MUST send letters in the
following description refer to Figure 3. Prior authorization (see
paragraph 3.2) and generation (see paragraph 3.3.3) steps are not
shown.
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 1,5
|
|
v 2,6
4 +-------+
+->| Admin |
| +-------+
|
|
3,7 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 12. VPN-PKI Interaction Steps:
Admin Generates Keys, PKC again.
3.5 PKC Profile for Request, and Enrolls Directly
with PKI Interaction
A
1) Enrollment [E]. The Admin requests a PKC used for identity in IKE transactions MUST include all from the
[CERTPROFILE] mandatory fields. It MUST also contain PKI, providing
the minimal
contents necessary for path validation and chaining (these items will
be enumerated in generated public key.
2) Enrollment Response [E]. The PKI responds to the profile).
It is preferable that enrollment
request, providing either the new PKC profiles for IPsec and certificate
management were the same so that one PKC could be used was generated or a
suitable error indication.
Bonatti, Turner, Lebovitz 28
Internet-Draft Requirements for both
protocols. If an July 2005
IPsec Certificate Management Profile
3) Opaque Transaction [E]. The Admin forwards the profiles are inconsistent then different PKCs (and
perhaps different processing requirements) MAY be required for
certificate management transactions vs. IKE transactions. However,
failure enrollment response
back to achieve this requirement in the profile MUST NOT hold up the standardization effort.
3.5.1 Identity Usage
The IPsec Peer SHALL perform identity verification based on Peer, along with the
fields keys.
4) Opaque Transaction [E]. Peer positively acknowledge receipt of the new
PKC and parameters applicable back to the VPN tunnel. The
fields of the PKC used for verification MAY include either the X.500
Distinguished Name (DN) within Admin.
5) Enrollment Confirmation [E]. Admin forwards enrollment
confirmation back to the Subject Name, or a specific field
within PKI.
6) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Extension SubjectAltName (per [DOI] 4.6.2.1 Identification
Type Values). Usage descriptions for each follow.
The PKC field(s) that will be used for identity verification MUST be
included in Admin.
7) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the PKC request by Peer.
3.4.9 Enrollment Method 3b: Admin Authorizes and Enrolls Directly to
PKI
In this instance, the PKI and Admin or have previously agreed to have
the Peer. PKI generate key and certificates when the PKI receives an
authorization request. The following
identity-related values MAY be included PKI returns to the IPsec Peer through the
Admin, the final product of a key pair and PKC. Again, the mechanism
for the Peer to Admin communication is opaque.
This enrollment mode is depicted in Figure 13 and the SubjectAltName:
- Fully-Qualified Domain Name (FQDN)
- RFC 822 (also called USER FQDN) letters in the
following description refer to Figure 3. Prior authorization (see
paragraph 3.2) and generation (see paragraph 3.3.4) steps are not
shown.
Bonatti, Turner, Lebovitz 37 29
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
- IPv4 Address
- IPv6 Address
While substrings of these identity values MAY also be present in
elements of
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 4
|
|
v 1,5
3 +-------+
+->| Admin |
| +-------+
|
|
2,6 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 13. VPN-PKI Interaction Steps:
PKI Generates Keys,
1) Enrollment Response [E]. The PKI responds to the DN, they will not be looked for in authorization
request sent, providing either the DN, only in
SubjectAltName.
3.5.2 Path Validation new PKC and public-private key
pair that were generated or a suitable error indication.
2) Opaque Transaction [E]. The Peers MUST validate Admin forwards the certification path. The contents
necessary in enrollment response
back to the IPsec Peer, along with the keys.
3) Opaque Transaction [E]. Peer positively acknowledge receipt of new
PKC back to allow this will be enumerated in the profile
document.
The Peer MAY have Admin.
4) Enrollment Confirmation [E]. Admin forwards enrollment
confirmation back to the ability PKI.
5) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to construct the certification path
itself, however Admin.
6) Opaque Transaction [E]. Admin MUST be able forwards PKI's enrollment
confirmation receipt back to supply Peers with the trust
anchor and any chaining PKCs necessary. The Admin MAY include Peer.
3.4.10 Confirmation Handshake
Any time a new PKC is issued by the AIA
extension in PKCs as PKI, a means confirmation of facilitating path validation.
DNS SHOULD PKC
receipt MUST be supported sent back to the PKI by the Peers in order to do certification
path lookups, as well as those for revocation.
3.5.3 KeyUsage
The PKCÆs KeyUsage digitalSignature bit as specified [CERTPROFILE]
MUST be flagged on. The KeyUsage extension SHOULD be marked critical
IAW [CERTPROFILE].
3.5.4 Extended Key Usage
Extended Key Usage (EKU) indications are not required. The presence Peer or lack of the Admin
(forwarding the PeerÆs confirmation).
Bonatti, Turner, Lebovitz 30
Internet-Draft Requirements for an EKU July 2005
IPsec Certificate Management Profile
Operationally, the Peer MUST NOT cause an implementation to fail an IKE
connection.
Default behavior is send a confirmation to not check EKU. However, local security policy
MAY check EKU, and if so the implementation SHOULD allow PKI verifying
that it has received the
acceptance or rejection based on the presence of each EKU. Those EKUs
are defined as:
- serverAuth,
- clientAuth,
or PKC, loaded it, and can use it effectively
in an IKE specific EKU which are defined as one of the four currently
issued IANA EKUÆs:
- IPsec user,
- IPsec computer,
Bonatti, Turner, Lebovitz 38
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
- IPsec intermediate, exchange. This requirement exists so that:
- IKE IPsec intermediate.
3.5.5 Pointer to Revocation Checking The PKI does not publish the new PKC contents MUST be constructed in a manner such that any Peer
who holds the repository for others
until that PKC locally will know exactly where to go and how is able to
request be used effectively by the CRL.
The location Peer, and;
- A revocation may be invoked if the PKC is not received and method for either a CDP or
operational within an AIA [CERTPROFILE] allowable window of time.
To assert such proof the Peer MUST sign a portion of data with the
new key. The result MUST be included in sent to the PKC. Including such contents avoids PKI. The entity that actually
sends the need result to
send the CRL to PKI MAY be either the Peer, and allows Peer (sending it
directly to the receiving PKI) or Admin (the Peer would send it to Admin, and
Admin can in turn send it to look up the CRL on their own.
PKCs PKI).
The Admin MUST contain acknowledge the full name successful receipt of the CDP and AIA. Issuer-relative
names are not considered sufficient.
3.6 PKC Renewals and Updates
In order
confirmation, thus signaling to allow for continued the Peer that it may proceed using
this PKC usage, a in IKE connections. The PKI MUST complete all processing
necessary to enable the PeerÆs operational use of the new PKC will need to be
issued for an end entity before the end entityÆs currently held PKC
expires. A renewal is defined as a new PKC issuance with (for
example, writing the same
SubjectName and SubjectAlternativeName contents as an existing PKC
for to the same end entity repository) before expiration of sending the
confirmation acknowledgement. The Peer MUST NOT begin using the end entityÆs current
PKC.
A PKC Update is defined as a new PKC issuance with an altered
SubjectName or SubjectAlternativeName
until the PKIÆs confirmation acknowledgement has been received.
3.4.11 Error Handling for Enrollment
Thorough error condition descriptions and handling instructions are
REQUIRED for each transaction in the same end entity before
expiration of enrollment process. Providing
such error codes will greatly aid interoperability efforts between
the end entityÆs current PKC. Renewals, updates PKI and
rekeys are variants of a PKC IPsec products.
The profile will clarify what happens if the request scenario with unique operational and management requirements.
Once the PKI has issued a PKC retrieval
fails for the end entity Peer, the Peer some reason. The following cases MUST be able to either contact the PKI directly covered:
- Admin or through Peer cannot send the request.
- Admin for
any subsequent renewals, updates or rekeys. The PKI MUST support
either case.
It is desired that a renew, update or rekey request contain an
element that identifies Peer sent the request as either type=renewal,
type=update, or type=rekey. This element MUST be specified in but the
profile. This will allow for better management, logging and auditing
of certificate management.
When sending a renew, update or rekey request, PKI did not receive the entire contents of
request.
- PKI received the PKC request needs to be sent to the PKI, just as in but could not read it effectively.
- PKI received and read the case request, but some contents of the original enrollment. Keeping the
request format as similar as
possible between new, renewal, update and rekey cases will make for violated the PKIÆs configured policy such that the PKI
was unable to generate the PKC.
- The PKI System generated the PKC, but could not send it.
Bonatti, Turner, Lebovitz 39 31
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
easier implementations; e.g.
- The PKI sent the format of PKC, but the request is identical
except for a type=[renew | update | rekey] instead of type=new. requestor (Admin or Peer) did not
receive it.
- The renew, update and rekey requests MUST be signed by the private
key of Requestor (Admin or Peer) received the old PKC. This will allow PKC, but could not
process it due to incorrect contents, or other PKC-construction-
related problem.
- The Requestor failed trying to generate the PKI confirmation.
- The Requestor failed trying to verify send the identity of confirmation.
- The Requestor sent the requestor, and ensure that an attacker does confirmation, but the PKI did not submit a request
and receive a PKC with another end entityÆs identity.
Whether or
it.
- The PKI received the confirmation but could not a new key is used for process.
In each case the new PKC in a renew or update
scenario is a matter of local security policy, and following questions MUST be specified
by the addressed:
- What does Peer do?
- What does Admin to do?
- What does PKI do?
- Is Authorization used?
If a failure occurs after the PKI in sends the original authorization request. Re-
using PKC and before the same key is permitted, but not encouraged. If a new key is
used, Peer
receives it, then the update or renew request must be signed by both Peer MUST re-request with the old key
-- to prove same
authorization ID and one-time authorization token, and the right to make PKI,
seeing the request -- authorization ID and authorization token, MUST send the new key -- to
use for the new PKC.
The new
PKC resulting from a renew, update or rekey will again.
Enrollment errors MUST be retrieved
in-band, using the same mechanism as a new PKC request.
For sent to the duration of time after a renew, update or rekey has been
processed and before PKI has received confirmation Admin regardless of entity that
generated the PeerÆs
successful receipt of enrollment request.
3.5 Lifecycle
This section refers to the new PKC (as described above [L] elements labeled in section
3.4.9), both PKCs--the old and Figure 3.
Once the new--for PKI has issued a PKC for the end entity will be
valid. This will allow Peer, the Peer MUST
be able to continue with uninterrupted IKE
connections with the previous PKC while either contact the renewal process occurs.
In PKI directly or through the case where new keys were generated Admin for a renew, update
any subsequent renewals, updates, rekeys, or
rekey request, once the end entity revocations. The PKI
MUST support either case for renewals, updates, and revocations.
Rekeys are Admin initiated therefore Peer receives the confirmation
acknowledgement from initiated rekeys MUST be
transferred via the PKI, it is good practice Admin.
Bonatti, Turner, Lebovitz 32
Internet-Draft Requirements for the old key
pair an July 2005
IPsec Certificate Management Profile
3.5.1 One Protocol
One protocol MUST be destroyed as soon as possible. Deletion of the keys specified for rekey, renew, and update
requests, responses, and confirmations. It MUST be the
PKC same protocol
as is specified in paragraph 3.4.
Revocation requests can occur once all connections that used the old PKC have
expired.
After be the renewal, same protocol as rekey, renew, and
update or operations. Revocation requests can also occur via email,
telephone, Instant Messaging, etc.
3.5.2 PKC Rekeys, Renewals, and Updates
Renewals, updates, and rekeys are variants of a PKC enrollment
request scenario with unique operational and management requirements.
- A PKC rekey occurs, the question now exists replaces an end entity's PKC with a new PKC that has a
new public key for the PKI of what to do about the old PKC. If same SubjectName and SubjectAltName
contents before the old end entityÆs currently held PKC is to be
made unusable, expires.
- A PKC renewal replaces an end entity's PKC with the PKI will need to add it to same public key
for the revocation list same SubjectName and
removed from the repository. The decision about if SubjectAlternativeName contents as
an existing PKC before the old end entityÆs currently held PKC should
be made unusable
expires.
- A PKC update is defined as a decision new PKC issuance with the same public
for an altered SubjectName or SubjectAlternativeName before
expiration of local policy. Either the PKI end entityÆs current PKC.
When sending renew, update, or rekey requests, the
Admin will need to specify this parameter during entire contents of
the authorization
phase. In this case PKC request needs to be sent to the specifying party --either PKI, just as in the Admin or case of
the
PKI-- original enrollment.
The renew, update and rekey requests MUST also specify during authorization be signed by the length private
key of time after
the PKI receives the end entity PeerÆs confirmation (of receipt old PKC. This will allow the PKI to verify the identity of
the PKC) requestor, and ensure that will pass before an attacker does not submit a request
and receive a PKC with another end entityÆs identity.
Whether or not a new key is used for the old new PKC in a renew or update
scenario is made unusable.
If a PKC has been revoked, it matter of local security policy, and MUST NOT be allowed specified
by the Admin to the PKI in the original authorization request. Re-
using the same key is permitted, but not encouraged. If a renewal, new key is
used, the update or rekey.
Should renew request must be signed by both the old key
-- to prove the right to make the request -- and the new key -- to
use for the new PKC.
The new PKC expire without renewal, resulting from a renew, update or rekey, an entirely
new request MUST rekey will be made. retrieved
in-band, using the same mechanism as a new PKC request.
Bonatti, Turner, Lebovitz 40 33
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
3.6.1 Renew Request for
For the duration of time after a New renew, update, or rekey has been
processed and before PKI has received confirmation of the PeerÆs
successful receipt of the new PKC (before expiry)
Operators can choose to force renewals both PKCs, the old and the new, for several reasons:
- To enforce an automated "clean up" of unused PKCs that have not
been specifically revoked
- To force re-keys
- To have manual review control over re-issuance.
In
the latter case, automated renewals end entity will likely not be used. In valid. This will allow the former two cases automated renewal is a very attractive option.
At Peer to continue
with uninterrupted IKE connections with the time of authorization, certain details previous PKC while the
renewal, update, or rekey process occurs.
After the renewal, update or rekey occurs, the question now exists
for the PKI of what to do about renewal
acceptance will the old PKC. If the old PKC is to be conveyed by
made unusable, the Admin PKI will need to add it to the PKI, as stated in
section 3.2.3.2 above. The renewal request MUST match revocation list,
removed from the conditions repository; however this should only occur once all
connections that were specified in used the original authorization for:
- Keys: new or existing or either
- Requestor: End entity Peer, Admin, either
- Renewal Period
- Length of time before making old PKC have expired. The decision about if
the old PKC should be made unusable
If any is a decision of these conditions are not met, local policy.
Either the PKI must reject or the
renewal and log Admin MUST specify this parameter during the event.
3.6.2 Update Request for a New PKC
An update to
authorization phase. In this case, the contents specifying party, either the
Admin or the PKI, MUST also specify during authorization the length
of a PKC will be necessary when details
about an time after the PKI receives the end entity PeerÆs identity change, but confirmation (of
receipt of the Operator does not
want to generate a new PKC) that will pass before the old PKC from scratch, requiring a whole is made
unusable.
In the case where the new
authorization. For example, keys were generated for a gateway device may be moved from one
site to another. Its IPv4 Address will change in renew or update
request and for rekey requests, once the SubjectAltName
extension, but all other information could stay Peer receives the same. Another
example
confirmation acknowledgement from the PKI, it is an end user who gets married and changes good practice for
the last name or
moves from one department to another. In either case, only one field
(the Surname or OU in old key pair be destroyed as soon as possible. Deletion can occur
once all connections that used the DN) need change.
An Update differs from old PKC have expired.
If a Renew in PKC has been revoked, it MUST NOT be allowed a few ways:
- A re-key is not necessary (though MAY renewal, update
or rekey.
Should the PKC expire without renewal, update or rekey, an entirely
new request MUST be specified)
- The timing made.
3.5.2.1 Rekey Request
Admins manage rekeys to ensure uninterrupted use of the Update event VPN by Peers
with new keys. Rekeys can occur automatically if the Admin is not predictable,
configured to initiate a new authorization for the rekey.
Scenarios for rekey are omitted as is they use the case same scenarios used
in the original PKC enrollment from sections 3.2, 3.3, and 3.4.
3.5.2.1 Renew Request
Admins manage renewals to ensure uninterrupted use of the VPN by
Peers with a scheduled Renewal or Rekey the same key pair.
Bonatti, Turner, Lebovitz 41 34
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
- The Update request may occur at any
At the time during a PKCÆs period of
validity
- Once the Update is completed, and the new PKC is confirmed, authorization, certain details about renewal
acceptance will be conveyed by the
old PKC should cease Admin to be usable, as its contents no longer
accurately describe the subject
- PKI, as stated in
section 3.2.4.2. The existence of a "update" type allows for better logging and
tracking of why the new issuance occurred, and why the old PKC
was made unusable.
At the time of authorization, certain details about update acceptance
MAY be conveyed by the Admin to the PKI, as stated in section 3.2.3.2
above. The update renewal request MUST match the conditions that
were specified in the original authorization for:
- Keys: new or existing New, existing, or either
- Requestor: End entity Peer, Admin, either
- The fields in the Subject and SubjectAltName that are changeable Period: How soon before PKC expiry.
- Time: Length of time before making the old PKC unusable unusable.
If any of these conditions are not met, the PKI must reject the
update
renewal and log the event.
If an
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.
3.5.2.2 Update authorization was not made at Request
An update to the time contents of original
authorization, one a PKC will be necessary when details
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
authorization. For example, a gateway device may be made moved from Admin one
site to another. Its IPv4 Address will change in the PKI at any time
during SubjectAltName
extension, but all other information could stay the PKCÆs valid life. When such an Update same. Another
example is desired, Admin
must notify the PKI System that an update is authorized for the end
entity, and to expect it coming, user who gets married and specify the new contents. Admin
then initiates the Update request with the given contents in whatever
mechanism changes the VPN System employs (direct last name or
moves from end entity one department to PKI, from
end entity through Admin, another. In either case, only one field
(the Surname or directly OU in the DN) need change.
An update differs from Admin).
3.6.3 Error Handling for Renewal and Change
Thorough error condition descriptions renewal and handling instructions are
required for each transaction rekeys in a few ways:
- A new key is not necessary
- The timing of the renewal, update event is not predictable, as is the case
with a scheduled renewal or rekey
process. Providing such error codes will greatly aid interoperability
efforts between
- The update request may occur at any time during a PKCÆs period of
validity
- Once the PKI update is completed, and IPsec products.
3.7 Finding PKCs in repositories
The complete hierarchical validation chain (except the trust point)
MUST be able new PKC is confirmed, the
old PKC should cease to be searched usable, as its contents no longer
accurately describe the subject
At the time of authorization, certain details about update acceptance
can be conveyed by the Admin to the PKI, as stated in their respective repositories. section
3.2.4.2. The
information to accomplish these searches update request MUST be adequately
communicated in match the PKCs sent during conditions that were
specified in the IKE transaction. original authorization for:
- Keys: new or existing or either
Bonatti, Turner, Lebovitz 42 35
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
All PKCs must be retrievable through a single protocol. The final
specification will identify one protocol as a "MUST", others MAY be
listed as "OPTIONAL".
The general requirements for the retrieval protocol include:
- The protocol can be easily Firewalled (including NAT or PAT); Requestor: End entity Peer, Admin, either
- The protocol can easily perform some query against a remote
repository on a specific ID element that was given to it fields in a
standard PKC field.
Other considerations include:
-relative speed
-relative ease of administration
-scalability
Intermediate PKCs will be needed for the case of re-keying Subject and SubjectAltName that are changeable
- Length of time before making the CA,
or a PKI System where multiple CAs exist.
PKCs MAY have extendedKeyusage to help identify the proper old PKC for
IPsec, though the default behavior is to unusable
If any of these conditions are not use them. See met, the above
section on extendedKeyUsage.
IPsec Peers PKI MUST be able to resolve Internet domain names reject the
update and support log the mandatory repository access protocol event.
If an update authorization was not made at the time of starting up
so they original
authorization, one can perform the PKC lookups.
IPsec Peers should cache PKCs be made from Admin to reduce latency in setting up Phase
1. Note that this is the PKI at any time
during the PKCÆs valid life. When such an operational issue, not update is desired, Admin
must notify the PKI System that an interoperability
issue.
The use case update is authorized for accomplishing lookups when PKCs the end
entity, and to expect it coming, and specify the new contents. Admin
then initiates the update request with the given contents in whatever
mechanism the VPN System employs (direct from end entity to PKI, from
end entity through Admin, or directly from Admin).
Scenarios for update are not sent omitted as they use the same scenarios used
in IKE
is a stated non-goal of the profile at this time.
3.7.1 original PKC enrollment from sections 3.2, 3.3, and 3.4.
3.5.2.3 Error Handling for Repository Lookups Rekey, Renewal, and Update
Thorough error condition descriptions and handling instructions are
required for each transaction in the repository lookup renewal, update or rekey
process. Providing such error codes will greatly aid interoperability
efforts between the PKI and IPsec products.
3.8 Revocation Action
3.5.2.4 Confirmation Handshakes
The Peer MUST be able to initiate revocation for its own PKC. In this
case confirmation handshake requirements are the revocation request MUST be same as in clauses
3.2, 3.3, and 3.4 except that depending on the
the PKI MUST also issue a revocation on the original PKC before
sending the confirmation response.
3.5.3 Revocation
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
Bonatti, Turner, Lebovitz 43
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
pair for the PKC it wishes to revoke. Whether the actual revocation
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
implementation.
The Admin MUST be able to initiate revocation for any PKC for which issued
under a template it authorized the creation. controls. The Admin will identify itself to the
PKI by use of its own PKC; it MUST sign any revocation request to the
PKI with the private key from its own PKC. The PKI MUST have the
Bonatti, Turner, Lebovitz 36
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
ability to configure Admin(s) with revocation authority, as
identified by its PKC. Any PKC authorizations must specify if said
PKC may be revoked by the Admin (see section 3.2.3.2 for more
details).
The profile MUST identify the one protocol or transaction within a
protocol to be used for both Peer and Admin initiated revocations.
The profile MUST identify the size of CRL the client will be prepared
to support.
Below are guidelines for revocation in specific transactions:
- AFTER RENEW, BEFORE EXPIRATION: The PKI MUST be responsible for
the PKC revocation during a renew transaction. PKI MUST revoke
the PKC after receiving the confirm notification from the Peer,
and before sending the confirm-ack to the Peer. The Peer MUST
NOT revoke its own PKC in this case.
- AFTER UPDATE, BEFORE EXPIRATION: The PKI MUST be responsible for
the PKC revocation during an update transaction. PKI MUST revoke
the PKC after receiving the confirm notification from the Peer,
and before sending the confirm-ack to the Peer. The Peer MUST
NOT revoke its own PKC in this case.
3.9 Revocation Checking and Status Information
3.6 Repositories
This section refers to the [R] elements labeled in Figure 3.
3.6.1 Lookups
The PKI System MUST provide a mechanism whereby Peers can check the
revocation status of PKCs SHOULD be built so that are presented to it for IKE identity. lookups resolve directly and
completely at the URL indicated in a CDP or AIA. The mechanism should allow for access PKI SHOULD be
built such that URL contents do not contain referrals to extremely fresh revocation
information. CRLs have been chosen other hosts
or URLs, as such referral lookups will increase the mechanism for communicating
this information. Operators are RECOMMENDED time to refresh CRLs as often
as logistically possible.
A single mandatory protocol mechanism for performing CRL lookups complete
the IKE negotiation, and can cause implementations to timeout.
CDP MUST be specified by the final specification.
All PKCs used flagged as required in IKE the authorization request. The
method MUST have cRLDistributionPoint and
authorityInfoAccess fields populated with valid URLs. This will allow
all recipients of also be specified; HTTP is the PKC to know immediately how revocation MUST method, LDAP is to be MAY.
The complete hierarchical PKC chain (except the trust anchor) MUST be
able to be searched in their respective repositories. The information
to accomplish these searches MUST be adequately communicated in the
PKCs sent during the IKE transaction.
Bonatti, Turner, Lebovitz 44 37
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
accomplished, and where to find
All PKCs must be retrievable through a single protocol. The final
specification will identify one protocol as a "MUST", others MAY be
listed as "OPTIONAL".
The general requirements for the revocation information. retrieval protocol include:
- The AIA
is needed protocol can be easily Firewalled (including NAT or PAT).
- The protocol can easily perform some query against a remote
repository on a specific ID element that was given to it in an environment where multiple layers a
standard PKC field.
Other considerations include:
- Relative speed
- Relative ease of CAs exist and administration
- Scalability
Intermediate PKCs will be needed for the case of re-keying of the CA,
or a CA key roll-over.
IPsec Systems PKI System where multiple CAs exist.
PKCs MAY have an OPTION extendedKeyusage to turn off revocation checking. Such
may be desired when help identify the two Peers are communicating over a network
without access to proper PKC for
IPsec, though the CRL service, such as at a trade show, in a lab,
or in a demo environment. If revocation checking default behavior is OFF, the
implementation MUST proceed to not use them (see 3.1.5.3).
IPsec Peers MUST be able to resolve Internet domain names and support
the PKC as valid identity in mandatory repository access protocol at the
exchange and need not time of starting up
so they can perform any check.
If the revocation of a PKC lookups.
IPsec Peers should cache PKCs to reduce latency in setting up Phase
1. Note that this is used as the only means of deactivation
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
and published by the PKI. If more immediate deactivation of access is
required than the CRL refreshing can provide, then another mechanism an operational issue, not an interoperability
issue.
The use case for authorization that provides more immediate access deactivation
should be layered into the VPN deployment. Such a second mechanism accomplishing lookups when PKCs are not sent in IKE
is
out a stated non-goal of the scope of profile at this profile. (Examples are Xauth, L2TPÆs
authentication, etc.).
3.9.1 time.
3.6.2 Error Handling in Revocation Checking for Repository Lookups
Thorough error condition descriptions and handling instructions are
required for each transaction in the revocation checking repository lookup process.
Providing such error codes will greatly aid interoperability efforts
between the PKI and IPsec products.
3.10
Bonatti, Turner, Lebovitz 38
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
3.7 Trust
3.7.1 Trust Anchor PKC Acquisition
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
Admin. This requires the Peer to know less about interaction with the
PKI.
(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,
but is assumed to occur via an unauthenticated but confidential
enrollment protocol.
4. Security Considerations
This requirements document does not specify an concrete solution,
and as such has no system-related security considerations per se.
However, the PKI4IPSEC model requires profiling and use of concrete
Bonatti, Turner, Lebovitz 45
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
protocols for certificate management (e.g., CMC, CMS, CRMF).
3.7.2 Certification Path Validation
The
individual security considerations of these protocols should be
carefully considered in the profiling effort.
In addition, this document allows significant flexibility in IPsec Peer MUST perform identity verification based on the
allocation fields
of functions between the roles of IPsec Peer PKC and VPN
Admin. This functional allocation is crucial both parameters applicable to achieving
successful deployment, and to maintaining the integrity VPN tunnel. The fields of
the PKI
enrollment and management processes. However, much of PKC used for verification MAY include either the
responsibility X.500
Distinguished Name (DN) within the Subject Name, or a specific field
within the Extension SubjectAltName (per [DOI] 4.6.2.1 Identification
Type Values). Usage descriptions for each follow.
The Peers or a SCVP server MUST validate the certification path, as
per RFC3280. The contents necessary in the PKC to allow this allocation necessarily falls will be
enumerated in the profile document.
The Peer MAY have the ability to product
implementers and system operators through construct the selection of
applicable use cases and development of security policy constraints.
These factors must certification path
itself, however Admin MUST be carefully considered able to supply Peers with the trust
anchor and any chaining PKCs necessary. The Admin MAY ensure the security
template uses the AIA extension in PKCs as a means of
PKI4IPSEC certificate management. Appendix E catalogs some key
system operator choices that are not constrained facilitating
path validation.
DNS SHOULD be supported by this document,
and frames their possible impacts.
A References
A.1 Normative References
None
A.2 Non-Normative References
[STDPROCESS] Bradner, S., "The Internet Standards Process ¡ Revision
3", BCP 9, RFC 2026, October 1996.
[MUSTSHOULD] Bradner, S., "Key words for use the Peers in RFCs order to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CERTPROFILE] Housley, R., et. al. "Internet X.509 Public Key
Infrastructure Certificate support resolving
URLs present in CDPs and Certificate AIA extensions.
3.7.3 Revocation List (CRL)
Profile", RFC 3280, April 2002.
[DOI] Piper, D., "Internet IP Security Domain of Interpretation for
ISAKMP", RFC 2407, November 1998.
Bonatti, Turner, Lebovitz 46
Internet-Draft Checking and Status Information
The PKI System MUST provide a mechanism whereby Peers can check the
revocation status of PKCs that are presented to it for IKE identity.
The mechanism should allow for access to extremely fresh revocation
information. CRLs have been chosen as the mechanism for communicating
this information. Operators are RECOMMENDED to refresh CRLs as often
as logistically possible.
A single mandatory protocol mechanism for performing CRL lookups MUST
be specified by the final specification.
Bonatti, Turner, Lebovitz 39
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
[FRAME] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu. S.,
"Internet X.509 Public Key Infrastructure: Certificate Policy and
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
of IKEv1/ISAKMP, IKEv2,
All PKCs used in IKE MUST have cRLDistributionPoint and PKIX",draft-ietf-pki4ipsec-ikecert-
profile-03, 30 September 2004.
B. Acknowledgements
authorityInfoAccess fields populated with valid URLs. This draft will allow
all recipients of the PKC to know immediately how revocation is substantially based on a prior draft draft-dploy-
requirements-00 developed by Project Dploy. to be
accomplished, and where to find the revocation information. The principle editor AIA
is needed in an environment where multiple layers of
that draft was Gregory M. Lebovitz (NetScreen Technologies).
Contributing authors included Lebovitz, Paul Hoffman (VPN
Consortium), Hank Mauldin (Cisco Systems), and Jussi Kukkonen (SSH
Communications Security). Substantial editorial contributions were
made by Leo Pluswick (ICSA), Tim Polk (NIST), Chris Wells (SafeNet),
Thomas Hardjono(VeriSign), Carlisle Adams (Entrust), CAs exist and Michael
Shieh (NetScreen).
Once brought to pki4ipsec,
for the following people made substantial case of a CA key roll-over.
IPsec Systems have an OPTION to turn off revocation checking. Such
may be desired when the two Peers are communicating over a network
without access to the CRL service, such as at a trade show, in a lab,
or in a demo environment. If revocation checking is OFF, the
implementation MUST proceed to use the PKC as valid identity in the
exchange and need not perform any check.
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
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
required than the CRL refreshing can provide, then another mechanism
for authorization that provides more immediate access deactivation
should be layered into the VPN deployment. Such a second mechanism is
out of the scope of this profile. (Examples are Xauth, L2TPÆs
authentication, etc.).
3.7.3 Error Handling in Revocation Checking and Certificate Path
Validation
Thorough error condition descriptions and handling instructions are
required for each transaction in the revocation checking and path
validation process. Providing such error codes will greatly aid
interoperability efforts between the PKI and IPsec products.
4. Security Considerations
This requirements document does not specify a concrete solution, and
as such has no system-related security considerations per se.
However, the PKI4IPSEC model requires profiling and use of concrete
protocols for certificate management (e.g., CMC, CMS, CRMF). The
individual security considerations of these protocols should be
carefully considered in the profiling effort.
In addition, this document allows significant flexibility in the
allocation of functions between the roles of Peer and Admin. This
functional allocation is crucial both to achieving successful
deployment, and to maintaining the integrity of the PKI enrollment
and management processes. However, much of the responsibility for
this allocation necessarily falls to product implementers and system
Bonatti, Turner, Lebovitz 40
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
operators through the selection of applicable use cases and
development of security policy constraints. These factors must be
carefully considered to ensure the security of PKI4IPSEC certificate
management. Appendix E catalogs some key system operator choices
that are not constrained by this document, and frames their possible
impacts.
A References
A.1 Normative References
None
A.2 Non-Normative References
[STDPROCESS] Bradner, S., "The Internet Standards Process û Revision
3", BCP 9, RFC 2026, October 1996.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CERTPROFILE] Housley, R., et. al. "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[DOI] Piper, D., "Internet IP Security Domain of Interpretation for
ISAKMP", RFC 2407, November 1998.
[FRAME] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu. S.,
"Internet X.509 Public Key Infrastructure: Certificate Policy and
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
of IKEv1/ISAKMP, IKEv2, and PKIXö,draft-ietf-pki4ipsec-ikecert-
profile-03, 30 September 2004.
B. Acknowledgements
This draft is substantially based on a prior draft draft-dploy-
requirements-00 developed by Project Dploy. The principle editor of
that draft was Gregory M. Lebovitz (NetScreen Technologies).
Contributing authors included Lebovitz, Paul Hoffman (VPN
Consortium), Hank Mauldin (Cisco Systems), and Jussi Kukkonen (SSH
Communications Security). Substantial editorial contributions were
Bonatti, Turner, Lebovitz 41
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
made by Leo Pluswick (ICSA), Tim Polk (NIST), Chris Wells (SafeNet),
Thomas Hardjono(VeriSign), Carlisle Adams (Entrust), and Michael
Shieh (NetScreen).
Once brought to pki4ipsec, the following people made substantial
contributions: [TBD] ...
C. EditorÆs Address
Chris Bonatti
IECA, Inc.
15309 Turkey Foot Road
Darnestown, MD 20878-3640 USA
bonattic@ieca.com
Sean Turner
IECA, Inc.
1421 T Street NW #8
Washington, DC 20009 USA
turners@ieca.com
Gregory M. Lebovitz
NetScreen Technologies, Inc.
gregory@netscreen.com
D. Summary
NetScreen Technologies, Inc.
gregory@netscreen.com
D. Summary of Requirements
TBD - EDITORÆS NOTE: Plan to add a summary table similar to those in
RFCs 1122, 1123, and 2975. Table will briefly describe requirement,
state the requirement level (i.e., "MAY", "SHOULD", "MUST", etc.),
and cite the applicable paragraph in this draft.
E. System Operator Choices
This appendix catalogs some key choices that must be made by product
implementers and system operators. These choices are not constrained
by this document, but can have profound impacts on PKI4IPSEC
certificate management operation and overall security. Where
possible we attempt to frames the specific security and operational
impacts associated with these choices.
1. Whether or not PKCs are allowed to be renewed or whether new
PKCs need to be issued.
2. Certificate renewal initiated by the VPN Peer or the VPN Admin
Bonatti, Turner, Lebovitz 42
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
F. Change History
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.
Bonatti, Turner, Lebovitz 43
Internet-Draft Requirements for an July 2005
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 Requirements update ôtypeö.
- Added that rekeys are initiated by Admin and that the PKI need
not support direct interaction on rekey requests.
Bonatti, Turner, Lebovitz 47 44
Internet-Draft Requirements for an December 2004 July 2005
IPsec Certificate Management Profile
TBD
- EDITORÆS NOTE: Plan to add a summary table similar to those in
RFCs 1122, 1123, and 2975. Table will briefly describe requirement,
state the requirement level (i.e., "MAY", "SHOULD", "MUST", etc.),
and cite the applicable paragraph in this draft.
E. System Operator Choices
This appendix catalogs some key choices that must be made by product
implementers and system operators. These choices are not constrained
by this document, but can have profound impacts on PKI4IPSEC
certificate management operation and overall security. Where
possible we attempt to frames the specific security Trust anchor acquisition, path validation, and operational
impacts associated with these choices.
1. Whether or not PKCs are allowed to be renewed or whether revocation
checking were grouped together under a new
PKCs need to be issued.
2. Certificate renewal initiated by the VPN Peer or the VPN Admin
F. Change History 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" ôrenewalö was clarified IAW [GLOSSARY].
- Replaced term "change" ôchangeö with "update" ôupdateö IAW [GLOSSARY].
- Added description of PKC "rekey" ô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.
Bonatti, Turner, Lebovitz 48
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
- 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 ôKey Generation Scenarios". Scenariosö.
Bonatti, Turner, Lebovitz 45
Internet-Draft Requirements for an July 2005
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" ô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.
Bonatti, Turner, Lebovitz 49
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
- 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" ôoff-lineö communication (out of band) entails.
Bonatti, Turner, Lebovitz 46
Internet-Draft Requirements for an July 2005
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.
Bonatti, Turner, Lebovitz 50
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
- 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.
Bonatti, Turner, Lebovitz 47
Internet-Draft Requirements for an July 2005
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.
Bonatti, Turner, Lebovitz 51
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
- 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.
Bonatti, Turner, Lebovitz 48
Internet-Draft Requirements for an July 2005
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.
Bonatti, Turner, Lebovitz 52
Internet-Draft Requirements for an December 2004
IPsec Certificate Management Profile
2002-March Draft-dploy-requirements-00
- First public draft of the document released.
Copyright (C)
Intellectual Property Statement
The Internet Society 2004. This IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document is subject or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the rights, licenses and restrictions contained procedures with respect to rights in RFC
documents can be found in BCP 78, 78 and
except as set forth therein, BCP 79.
Bonatti, Turner, Lebovitz 49
Internet-Draft Requirements for an July 2005
IPsec Certificate Management Profile
Copies of IPR disclosures made to the authors retain all their rights."
"This IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expires June 2005 February 20, 2006
Bonatti, Turner, Lebovitz 53 50
----