doc: Add RFC documents

1 files changed, 2523 insertions, 0 deletions

diff --git a/doc/rfc/rfc4809.txt b/doc/rfc/rfc4809.txt
new file mode 100644
index 0000000..69e4a3a
--- /dev/null
+++ b/doc/rfc/rfc4809.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+Network Working Group                                    C. Bonatti, Ed.
+Request for Comments: 4809                                S. Turner, Ed.
+Category: Informational                                             IECA
+                                                        G. Lebovitz, Ed.
+                                                                 Juniper
+                                                           February 2007
+
+
+       Requirements for an IPsec Certificate Management Profile
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This informational document describes and identifies the requirements
+   for transactions to handle Public Key Certificate (PKC) lifecycle
+   transactions between Internet Protocol Security (IPsec) Virtual
+   Private Network (VPN) Systems using Internet Key Exchange (IKE)
+   (versions 1 and 2) and Public Key Infrastructure (PKI) Systems.
+   These requirements are designed 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 to address many of these
+   requirements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                       [Page 1]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Scope ......................................................5
+      1.2. Non-Goals ..................................................6
+      1.3. Definitions ................................................6
+      1.4. Requirements Terminology ...................................8
+   2. Architecture ....................................................9
+      2.1. VPN System .................................................9
+           2.1.1. IPsec Peer(s) .......................................9
+           2.1.2. VPN Administration Function (Admin) .................9
+      2.2. PKI System ................................................10
+      2.3. VPN-PKI Interaction .......................................11
+   3. Requirements ...................................................13
+      3.1. General Requirements ......................................13
+           3.1.1. One Protocol .......................................13
+           3.1.2. Secure Transactions ................................13
+           3.1.3. Admin Availability .................................13
+           3.1.4. PKI Availability ...................................14
+           3.1.5. End-User Transparency ..............................14
+           3.1.6. PKC Profile for PKI Interaction ....................14
+                  3.1.6.1. Identity ..................................15
+                  3.1.6.2. Key Usage .................................15
+                  3.1.6.3. Extended Key Usage ........................15
+                  3.1.6.4. Revocation Information Location ...........15
+           3.1.7. Error Handling .....................................15
+      3.2. Authorization .............................................15
+           3.2.1. One Protocol .......................................15
+           3.2.2. Bulk Authorization .................................16
+           3.2.3. Authorization Scenario .............................16
+           3.2.4. Authorization Request ..............................17
+                  3.2.4.1. Specifying Fields within the PKC ..........17
+                  3.2.4.2. Authorizations for Rekey, Renewal,
+                           and Update ................................18
+                  3.2.4.3. Other Authorization Elements ..............18
+                  3.2.4.4. Cancel Capability .........................19
+           3.2.5. Authorization Response .............................19
+                  3.2.5.1. Error Handling for Authorization ..........20
+      3.3. Generation ................................................20
+           3.3.1. Generation Method 1: IPsec Peer Generates Key Pair,
+                  Constructs PKC Request, and Signs PKC Request ......21
+           3.3.2. Generation Method 2: IPsec Peer Generates Key Pair,
+                  Admin Constructs PKS Request, Admin Signs PKC
+                  Request ............................................22
+           3.3.3. Generation Method 3: Admin Generates Key Pair,
+                  Constructs PKC Request, and Signs PKC Request ......23
+           3.3.4. Method 4: PKI Generates Key Pair ...................24
+           3.3.5. Error Handling for Generation ......................25
+
+
+
+Bonatti, et al.             Informational                       [Page 2]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+      3.4. Enrollment ................................................25
+           3.4.1. One Protocol .......................................25
+           3.4.2. On-line Protocol ...................................25
+           3.4.3. Single Connection with Immediate Response ..........25
+           3.4.4. Manual Approval Option .............................25
+           3.4.5. Enrollment Method 1: Peer Enrolls to PKI Directly ..26
+           3.4.6. Enrollment Method 2a: Peer Enrolls through Admin ...27
+           3.4.7. Enrollment Method 2b: Peer Enrolls through Admin ...28
+           3.4.8. Enrollment Method 3a: Admin Authorizes and
+                  Enrolls Directly to PKI ............................30
+           3.4.9. Enrollment Method 3b: Admin Requests and PKI
+                  Generates and Sends PKC ............................31
+           3.4.10. Confirmation Handshake ............................32
+           3.4.11. Error Handling for Enrollment .....................33
+      3.5. Lifecycle .................................................34
+           3.5.1. One Protocol .......................................34
+           3.5.2. PKC Rekeys, Renewals, and Updates ..................35
+                  3.5.2.1. Rekey Request .............................36
+                  3.5.2.2. Renew Request .............................36
+                  3.5.2.3. Update Request ............................37
+                  3.5.2.4. Error Handling for Rekey, Renewal,
+                           and Update ................................38
+                  3.5.2.5. Confirmation Handshakes ...................38
+           3.5.3. Revocation .........................................38
+      3.6. Repositories ..............................................39
+           3.6.1. Lookups ............................................39
+           3.6.2. Error Handling for Repository Lookups ..............40
+      3.7. Trust .....................................................40
+           3.7.1. Trust Anchor PKC Acquisition .......................40
+           3.7.2. Certification Path Validation ......................41
+           3.7.3. Revocation Checking and Status Information .........41
+           3.7.4. Error Handling in Revocation Checking and
+                  Certificate Path Validation ........................42
+   4. Security Considerations ........................................42
+   5. References .....................................................43
+      5.1. Normative References ......................................43
+      5.2. Informative References ....................................43
+   6. Acknowledgements ...............................................43
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                       [Page 3]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+1.  Introduction
+
+   This document describes and identifies the requirements for
+   transactions to handle PKC lifecycle transactions between [IPsec] VPN
+   Systems using IKE ([IKEv1] and [IKEv2]) and PKI Systems.  This
+   document contains requirements for a transaction-based approach.
+   Other models are conceivable, for example, a directory-centric
+   approach, but their requirements are beyond the scope of this
+   document.
+
+   This document enumerates requirements for Public Key Certificate
+   (PKC) lifecycle transactions between different VPN System and PKI
+   System products in order to better enable large scale, PKI-enabled
+   IPsec deployments with a common set of transactions.  Requirements
+   for both the IPsec and the PKI products are discussed.  The
+   requirements are carefully designed to achieve security without
+   compromising ease of management and deployment, even where the
+   deployment involves tens of thousands of IPsec users and devices.
+
+   The requirements address transactions for the entire PKC lifecycle
+   for PKI-enabled VPN System: authorization (of PKC issuance),
+   generation (public-private key pair and PKC request), enrollment (PKC
+   request, PKC response, and confirmation), maintenance (rekey, renew,
+   update, revoke, and confirm), and repository lookups.  These
+   transactions enable a VPN Operator to:
+
+     - Use a VPN Administration function (Admin), which is introduced in
+       this document, to manage PKC authorization and possibly act as
+       the sole interface for the VPN System and the PKI System.
+
+     - Authorize individual or batches of PKC issuances based on a pre-
+       agreed template (i.e., both types of authorization requests refer
+       to the pre-agreed template).  These authorizations can occur
+       either prior to the enrollment or in the same transaction as the
+       enrollment.
+
+     - Provision PKI-based user or machine identity to IPsec Peers, on a
+       large scale.
+
+     - Set the corresponding gateway or client authorization policy for
+       remote access and site-to-site connections.
+
+     - Establish policies for automatic PKC rekeys, renewals, and
+       updates.
+
+     - Ensure timely revocation information is available for PKCs used
+       in IKE exchanges.
+
+
+
+
+Bonatti, et al.             Informational                       [Page 4]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   These requirements are intended to be used to profile a certificate
+   management protocol that the VPN System will use to communicate with
+   the PKI System.  Note that this profile will be in another document.
+   The certificate management profile will also clarify and constrain
+   existing PKIX (PKI for X.509 Certificates) and IPsec standards to
+   limit the complexity of deployment.  Some requirements may require
+   either a new protocol, or changes or extensions to an existing
+   protocol.
+
+   The desired outcome of the requirements and profile documents is that
+   both IPsec and PKI vendors create interoperable products to enable
+   large-scale IPsec System deployments, and do so as quickly as
+   possible.  For example, a VPN Operator should be able to use any
+   conforming IPsec implementation (VPN Administration or IPsec Peer) of
+   the certificate management profile with any conforming PKI vendor's
+   implementation to perform the VPN rollout and management.
+
+1.1.  Scope
+
+   The document addresses requirements on transactions between the VPN
+   Systems and the PKI Systems and between the VPN Administration and
+   IPsec Peers.  The requirements strive to meet eighty percent of the
+   market needs for large-scale deployments (i.e., VPNs including
+   hundreds or thousands of managed VPN gateways or VPN remote access
+   clients).  Environments will understandably exist in which large-
+   scale deployment tools are desired, but local security policy
+   stringency will not allow for the use of such commercial tools.  The
+   solution will possibly miss the needs of the highest ten percent of
+   stringency and the lowest ten percent of convenience requirements.
+   Use cases will be considered or rejected based upon this eighty
+   percent rule.  The needs of small deployments are a stated non-goal;
+   however, service providers employing the scoped solution and applying
+   it to many smaller deployments in aggregate may address them.
+
+   Gateway-to-gateway access and end-user remote access (to a gateway)
+   are both covered.  End-to-end communications are not necessarily
+   excluded, but are intentionally not a focus.
+
+   Only VPN-PKI transactions that ease and enable scalable PKI-enabled
+   IPsec deployments are addressed.
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                       [Page 5]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+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 VPN Administrator to Peer
+   transactions will not be addressed.  These interactions are
+   considered vendor proprietary.  These interactions may be
+   standardized later to enable interoperability between VPN
+   Administration function stations and IPsec Peers from different
+   vendors, but are far beyond the scope of this current effort, and
+   will be described as opaque transactions in this document.
+
+   The protocol specification for Registration Authority - Certificate
+   Authority (RA-CA), CA-Repository, and RA-Repository interactions will
+   not be addressed.
+
+1.3.  Definitions
+
+   VPN System
+   The VPN System is comprised of the VPN Administration function
+   (defined below), the IPsec Peers, and the communication mechanism
+   between the VPN Administration and the IPsec Peers.  VPN System is
+   defined in more detail in Section 2.1.
+
+   PKI System
+   The PKI System, or simply PKI, is the set of functions needed to
+   authorize, issue, and manage PKCs.  PKI System is defined in more
+   detail in Section 2.2.
+
+   (VPN) Operator
+   The Operator is the person or group of people that define security
+   policy and configure the VPN System to enforce that policy, with the
+   VPN Administration function.
+
+   IPsec Peer (Gateway or Client)
+   For the purposes of this document, an IPsec Peer, or simply "Peer",
+   is any VPN System component that communicates IKE and IPsec to
+   another Peer in order to create an IPsec Security Association for
+   communications.  It can be either a traditional security gateway
+   (with two network interfaces, one for the protected network and one
+   for the unprotected network) or an IPsec client (with a single
+   network interface).  In both cases, the Peer can pass traffic with no
+   IPsec protection, and can add IPsec protection to chosen traffic
+   streams.  See Section 2.1.1 for more details.
+
+
+
+
+Bonatti, et al.             Informational                       [Page 6]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   (VPN) Admin
+   The Admin is the VPN System function that interacts with the PKI
+   System to establish PKC provisioning for the VPN connections.  See
+   Section 2.1.2 for more details.
+
+   End Entity
+   An end entity is the entity or subject that is identified in a PKC.
+   The end entity is the one entity that will finally use a private key
+   associated with a PKC to digitally sign data.  In this document, an
+   IPsec Peer is certainly an end entity, but the VPN Admin can also
+   constitute an end entity.  Note that end entities can have different
+   PKCs for different purposes (e.g., signature vs. key exchange,
+   Admin-functions vs. Peer-functions).
+
+   PKC Rekey
+   The routine procedure for replacement of a PKC with a new PKC with a
+   new public key for the same subject name.  A rekey process can rely
+   on the existing key pair to bootstrap authentication for the new
+   enrollment.
+
+   PKC Renewal
+   The acquisition of a new PKC with the same public key due to the
+   expiration of an existing PKC.  Renewal occurs prior to the
+   expiration of the existing PKC to avoid any connection outages.  A
+   renewal process can rely on the existing key pair to bootstrap
+   authentication for the new enrollment.
+
+   PKC Update
+   A special case of a renewal-like occurrence where a PKC needs to be
+   changed prior to expiration due to some change in its subject's
+   information.  Examples might include change in the address, telephone
+   number, or name change due to marriage of the end entity.  An update
+   process can rely on the existing key pair to bootstrap authentication
+   for the new enrollment.
+
+   Registration Authority (RA)
+   An optional entity in a PKI System given responsibility for
+   performing some of the administrative tasks necessary in the
+   registration of end entities, such as confirming the subject's
+   identity and verifying that the subject has possession of the private
+   key associated with the public key requested for a PKC.
+
+   Certificate Authority (CA)
+   An authority in a PKI System that is trusted by one or more users to
+   create and sign PKCs.  It is important to note that the CA is
+   responsible for the PKCs during their whole lifetime, not just for
+   issuing them.
+
+
+
+
+Bonatti, et al.             Informational                       [Page 7]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   Repository
+   An Internet-accessible server in a PKI System that stores and makes
+   available for retrieval PKCs and Certificate Revocation Lists (CRLs).
+
+   Root CA/Trust Anchor
+   A CA that is directly trusted by an end entity; that is, securely
+   acquiring the value of a Root CA public key requires some out-of-band
+   step(s).  This term is not meant to imply that a Root CA is
+   necessarily at the top of any hierarchy, simply that the CA in
+   question is trusted directly.
+
+   Certificate Revocation List (CRL)
+   A CRL is a CA-signed, timestamped list identifying revoked PKCs and
+   made freely available in a repository.  Peers retrieve the CRL to
+   verify that a PKC being presented to them as the identity in an IKE
+   transaction has not been revoked.
+
+   CRL Distribution Point (CDP)
+   The CDP is a PKC extension that identifies the location from which
+   end entities should retrieve CRLs to check status information.
+
+   Authority Info Access (AIA)
+   The AIA is a PKC extension that indicates how to access CA
+   information and services for the issuer of the PKC in which the
+   extension appears.  Information and services may include on-line
+   validation services and Certificate Policy (CP) data.
+
+1.4.  Requirements Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [MUSTSHOULD].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                       [Page 8]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+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 is presented.
+
+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 establishment of an IPsec
+   Security Association is required.  Two Peers are shown in Figure 1,
+   but implementations can support an actual number in the hundreds or
+   thousands.  The Peers can be gateway-to-gateway, remote-access-host-
+   to-gateway, or a mix of both.  The Peers authenticate themselves in
+   the IKE negotiation using digital signatures generated with PKCs from
+   a PKI System.
+
+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 VPN System.  The Admin is a centralized
+   function used by the Operator to interact with the PKI System to
+   establish PKI policy (e.g., algorithms, key lengths, lifecycle
+   options, and PKC fields) for groups of IPsec Peers.  The Admin also
+
+
+
+Bonatti, et al.             Informational                       [Page 9]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   authorizes PKC issuance and can act as the Peer's PKI System
+   interface, which allows the Admin to perform many RA-like functions.
+
+   It is important to note that, within this document, the Admin is
+   neither a device nor a person; rather, it is a function.  Every
+   large-scale VPN deployment will contain the Admin function.  The
+   function can be performed on a stand-alone workstation, on a gateway,
+   or on an administration software component.  The Admin function can
+   also be one and the same as the gateway, client device, or software.
+   They are represented in the architectural diagram 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 CP.  In VPN Systems, the Operator
+       chooses to strengthen the VPN by using PKI; PKI is a bolt-on to
+       the VPN System.  The Operator will configure local security
+       policy in part through the Admin and 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 individual PKCs or batches of PKCs based on a pre-
+       agreed template (i.e., both types of authorization requests refer
+       to the pre-agreed template).  Templates will be agreed in an
+       out-of-band mechanism by the VPN Operator and the PKI Operator.
+       It will receive back from the PKI a unique tuple of authorization
+       identifiers and one-time authorization tokens that will authorize
+       Peers to request a PKC.
+
+     - It will deliver instructions to the IPsec Peers, and the Peers
+       will carry out those instructions (e.g., Admin passes Peer
+       information necessary to generate keys and PKC request).
+
+2.2.  PKI System
+
+   The PKI System, as depicted in Figure 2, can be set up and operated
+   by the Operator (in-house), be provided by third party PKI providers
+   to which connectivity is available at the time of provisioning
+   (managed PKI service), or be integrated with the VPN product.
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 10]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+               +---------------------------------------------+
+               |        +-------------------------+          |
+               |        v                         |          |
+               |   +--------------+               v          |
+               |   |  Repository  |    +----+   +----+       |
+               |   | Certs & CRLs |<-> | CA |<->| RA |       |
+               |   +--------------+    +----+   +----+       |
+               |                                             |
+               +---------------------------------------------+
+
+                              Figure 2: PKI System
+
+   This framework assumes that all components of the VPN obtain PKCs
+   from a single PKI community.  An IPsec Peer 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 contains a mechanism for handling Admin's
+   authorization requests and PKC enrollments.  This mechanism is
+   referred to as the Registration Authority (RA).  The PKI System
+   contains a Repository for Peers to 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.
+
+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.
+   Therefore, it is sensible to consider the steps necessary to set up,
+   use, and manage PKCs for one Peer to establish an association with
+   another Peer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 11]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+          +-----------------------------------------------+
+          |                  PKI System                   |
+          |                                               |
+          |   +--------------+                            |
+          |   |  Repository  |     +----+    +----+       |
+          |   | Certs & CRLs |     | CA |    | RA |       |
+          |   +--------------+     +----+    +----+       |
+          |                                               |
+          +-----------------------------------------------+
+               ^                  ^                   ^
+               |[G]               |[A]                |[G]
+               |[E]               |[G]                |[E]
+               |[L]               |[E]                |[L]
+               |[R]               |[R]                |[R]
+               |                  |[L]                |
+         +-----+------------------+-------------------+-------+
+         |     |                  v                   |       |
+         |     |             +----------+             |       |
+         |     | [G][E][L][R]|   VPN    |[G][E][L][R] |       |
+         |     | +---------->|  Admin   |<----------+ |       |
+         |     | |           | Function |           | |       |
+         |     | |           +----------+           | |       |
+         |     v v                                  v v       |
+         |  +---------+                          +---------+  |
+         |  |  IPsec  |          [I]             |  IPsec  |  |
+         |  |  Peer 1 |<========================>|  Peer 2 |  |
+         |  +---------+                          +---------+  |
+         |                                                    |
+         |                     VPN System                     |
+         +----------------------------------------------------+
+
+   [A] = Authorization: PKC issuance
+   [G] = Generation: Public key, private key, and PKC request
+   [E] = Enrollment: Sending PKC request, verifying PKC response, and
+         confirming PKC response
+   [I] = IKE and IPsec communication
+   [L] = Lifecycle: Rekey, renewal, update, revocation, and confirmation
+   [R] = Repository: Posting and lookups
+
+        Figure 3.  Architectural Framework for VPN-PKI Interaction
+
+   Requirements for each of the interactions, [A], [G], [E], [L], and
+   [R], are addressed in Sections 3.2 through 3.6.  However, only
+   requirements for [A], [E], [L], and [R] will be addressed by the
+   certificate management profile.  Requirements for [I] transactions
+   are beyond the scope of this document.  Additionally, the act of
+   certification (i.e., binding the public key to the name) is performed
+   at the CA and is not shown in the figure.
+
+
+
+Bonatti, et al.             Informational                      [Page 12]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+3.  Requirements
+
+3.1.  General Requirements
+
+3.1.1.  One Protocol
+
+   The target profile, to be based on this requirements document, MUST
+   call for ONE PROTOCOL or ONE USE PROFILE for each main element of the
+   [A], [E], [L], and [R] interactions.  In order to reduce complexity
+   and improve interoperability, having multiple competing protocols or
+   profiles to solve the same requirement should be avoided whenever
+   possible.
+
+   Meeting some of the requirements may necessitate the creation of a
+   new protocol or new extension for an existing protocol; however, the
+   latter is much preferred.
+
+3.1.2.  Secure Transactions
+
+   The target certificate management profile MUST specify the [A], [E],
+   [L], and [R] transactions between VPN and PKI Systems.  To support
+   these transactions, the Admin and PKI MUST exchange policy details,
+   identities, and keys.  As such, the method of communication for [A],
+   [E], and [L] transactions MUST be secured in a manner that ensures
+   privacy, authentication, and message data integrity.  The
+   communication method MUST require that mutual trust be established
+   between the PKI and the Admin (see Section 3.7.1).  [R] transactions
+   do not require authentication or message data integrity because the
+   responses (i.e., PKCs and CRLs) are already digitally signed.
+   Whether [R] transactions require privacy is determined by the local
+   security policy.
+
+   The target certificate management profile will not specify [G]
+   transactions.  However, these transactions MUST be secured in a
+   manner that ensures privacy, authentication, and message data
+   integrity because these transactions are the basis for the other
+   transactions.
+
+3.1.3.  Admin Availability
+
+   The Admin MUST be reachable by the Peers.  Most implementations will
+   meet this requirement by ensuring Peers can connect to the Admin from
+   anywhere on the network or Internet.  However, communication between
+   the Admin and Peers can be "off-line".  It can, in some environments,
+   be "moving media" (i.e., the configuration or data is loaded on to a
+   floppy disk or other media and physically moved to the IPsec Peers).
+   Likewise, it can be entered directly on the IPsec Peer via a User
+   Interface (UI).  In this case, the Admin function is co-located on
+
+
+
+Bonatti, et al.             Informational                      [Page 13]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   the Peer device itself.  Most requirements and scenarios in this
+   document assume on-line availability of the Admin for the life of the
+   VPN System.
+
+3.1.4.  PKI Availability
+
+   Availability is REQUIRED initially for authorization transactions
+   between the PKI and Admin.  Further availability is required in most
+   cases, but the extent of this availability is a decision point for
+   the Operator.  Most requirements and scenarios in this document
+   assume on-line availability of the PKI for the life of the VPN
+   System.
+
+   Off-line interaction between the VPN and PKI Systems (i.e., where
+   physical media is used as the transport method) is beyond the scope
+   of this document.
+
+3.1.5.  End-User Transparency
+
+   PKI interactions are to be transparent to the user.  Users 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.6.  PKC Profile for PKI Interaction
+
+   A PKC used for identity in VPN-PKI transactions MUST include all the
+   [CERTPROFILE] mandatory fields.  It MUST also contain contents
+   necessary to support path validation and certificate status checking.
+
+   It is preferable that the PKC profiles for IPsec transactions
+   [IKECERTPROFILE] and VPN-PKI transactions (in the certificate
+   management profile) are the same so that one PKC could be used for
+   both transaction sets.  If the profiles are inconsistent, then
+   different PKCs (and perhaps different processing requirements) might
+   be required.  However, the authors urge that progress continue on
+   other aspects of this standardization effort regardless of the status
+   of efforts to achieve PKC profile consensus.
+
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 14]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+3.1.6.1.  Identity
+
+   PKCs MUST support identifying (i.e., naming) Peers and Admins.  The
+   following name forms MUST be supported:
+
+     - Fully-Qualified Domain Name (FQDN)
+     - RFC 822 (also called USER FQDN)
+     - IPv4 Address
+     - IPv6 Address
+
+3.1.6.2.  Key Usage
+
+   PKCs MUST support indicating the purposes for which the key (i.e.,
+   digital signature) can be used.  Further, PKCs MUST always indicate
+   that relying parties (i.e., Peers) need to understand the indication.
+
+3.1.6.3.  Extended Key Usage
+
+   Extended Key Usage (EKU) indications are not required.  The presence
+   or lack of an EKU MUST NOT cause an implementation to fail an IKE
+   connection.
+
+3.1.6.4.  Revocation Information Location
+
+   PKCs MUST indicate the location of CRL such that any Peer who holds
+   the PKC locally will know exactly where to go and how to request the
+   CRL.
+
+3.1.7.  Error Handling
+
+   The protocol for the VPN-PKI transactions MUST specify error handling
+   for each transaction.  Thorough error condition descriptions and
+   handling instructions will greatly aid interoperability efforts
+   between the PKI and VPN System products.
+
+3.2.  Authorization
+
+   This section refers to the [A] elements labeled in Figure 3.
+
+3.2.1.  One Protocol
+
+   One protocol MUST be specified for the Admin to PKI (RA/CA)
+   interactions.  This protocol MUST support privacy, authorization,
+   authentication, and integrity.  PKCs for authorization of the Admin
+   can be initialized through an out-of-band mechanism.
+
+   The transport used to carry the authorization SHOULD be reliable
+   (TCP).
+
+
+
+Bonatti, et al.             Informational                      [Page 15]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   The protocol SHOULD be as lightweight as possible.
+
+3.2.2.  Bulk Authorization
+
+   Bulk authorization MUST be supported by the 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) differs per subject.  Because the authorizations may
+   occur before any keys have been generated, the only way to ensure
+   unique authorization identifiers are issued is to have at least one
+   value differ per subject.
+
+   Authorization can occur prior to a PKC enrollment request, or the
+   authorization and the PKC enrollment request can be presented to the
+   PKI at the same time.  Both of these authorization scenarios MUST be
+   supported.
+
+   A bulk authorization SHOULD occur in one single connection to the PKI
+   (RA/CA), with the number of subjects being one or greater.
+   Implementations SHOULD be able to handle one thousand subjects in a
+   batch authorization.
+
+3.2.3  Authorization Scenario
+
+   The 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 16]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+       +--------------+     +-----------------------+
+       |  Repository  |     |         CA/RA         |
+       +--------------+     +-----------------------+
+                                        ^
+                                        | 1
+                                      2 |
+                                        v
+                                     +-------+
+                                     | Admin |
+                                     +-------+
+
+
+                +--------------------+          +--------+
+                |       IPsec        |          | IPsec  |
+                |      Peer 1        |          | Peer 2 |
+                +--------------------+          +--------+
+
+                  Figure 4.  Authorization Transactions
+
+   1) Authorization Request [A].  Admin sends a list of identities and
+      PKC contents for the PKI System to authorize enrollment.  See
+      Section 3.2.4.
+
+   2) Authorization Response [A].  The PKI returns a list of unique
+      authorization identifiers and one-time authorization tokens to be
+      used for the enrollment of each PKC (1).  Response may indicate
+      success, failure, or errors for any particular authorization.  See
+      Section 3.2.5.
+
+3.2.4.  Authorization Request
+
+3.2.4.1.  Specifying Fields within the PKC
+
+   The Admin authorizes individual PKCs or batches of PKC issuances
+   based on a pre-agreed template.  This template is agreed by the VPN
+   Operator and PKI Operator and is referred to in each authorization
+   request.  This allows the authorization requests to include the
+   minimal amount of information necessary to support a VPN System.
+
+   The Admin can send the PKI System the set of PKC contents that it
+   wants the PKI to issue to a group of IPsec Peers.  In other words, it
+   tells the PKI System, "if you see a PKC request that looks like this,
+   from this person, process it and issue the PKC."
+
+   Requirements for PKC fields used in IPsec transactions are specified
+   in [IKECERTPROFILE].
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 17]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   Requirements for PKC fields used in VPN-PKI transactions are
+   specified in Section 3.1.6.
+
+3.2.4.2.  Authorizations for Rekey, Renewal, and Update
+
+   When the VPN Operator and PKI Operator pre-agree on a template, they
+   MUST also agree on the local policy regarding PKC renewal and PKC
+   update.  These are:
+
+     - Admin MUST specify if automatic renewals are allowed, that is,
+       the Admin authorizes the PKI to process a future renewal for the
+       specified Peer PKC.
+
+     - Admin MUST specify if PKC update is allowed, that is, the Admin
+       authorizes the PKI to accept a future request for a new PKC with
+       changes to non-key-related fields.
+
+       If a PKC renewal is authorized, the Admin MUST further specify:
+
+     - Who can renew, that is, can only the Admin send a renewal request
+       or can the Peer send a request directly to the PKI, or either.
+
+     - 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 a 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 Peer, or either.
+
+     - 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).
+
+   A new authorization by the Admin is REQUIRED for PKC rekey.  No
+   parameters of prior authorizations need be considered.
+
+3.2.4.3.  Other Authorization Elements
+
+   The Admin MUST have the ability to specify the format for the
+   authorization ID and one-time authorization 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 UTF-8 format to avoid
+
+
+
+Bonatti, et al.             Informational                      [Page 18]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   incompatibilities that may occur due to international characters.  It
+   MUST support normalization as in [CERTPROFILE].  The Admin MUST have
+   the ability to constrain the UTF-8 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 is set, any PKC requests using the authorization ID
+   and one-time authorization token that arrive at the PKI outside of
+   the validation period MUST be dropped, and the event logged.
+
+   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
+   = 3 weeks and CA is configured to only allow validation periods = 1
+   week).  Proper conflict handling MUST be specified.
+
+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 authorization token in order to cancel the 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 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 Section
+   3.6.
+
+3.2.5.  Authorization Response
+
+   If the authorization request is acceptable, the PKI will respond to
+   the Admin with a unique authorization identifier per subject
+   authorization requested and a one-time authorization token per
+   authorization ID.  See Section 3.2.4.3 for additional authorization
+   ID and one-time authorization token requirements.
+
+   The PKI can alter parameters of the authorization request submitted
+   by the Admin.  In that event, the PKI MUST return all the contents of
+   the authorization request (as modified) to the Admin with the
+   confirmation of authorization success.  This will allow the Admin to
+
+
+
+Bonatti, et al.             Informational                      [Page 19]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   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 Section 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 has satisfied and NO or FAILED for those requests that cannot be
+   satisfied, along with sufficient reason or error codes.
+
+   A method is REQUIRED to identify if there is a change in PKI settings
+   between the time the authorization is granted and the PKC request
+   occurs, and what to do about the discrepancy.
+
+3.2.5.1.  Error Handling for Authorization
+
+   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.  Generation
+
+   This section refers to the [G] elements labeled in Figure 3.
+
+   Once the PKI System has responded with authorization identifiers and
+   authorization tokens (see Section 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 can occur at one of three places,
+   depending on local requirements: at the IPsec Peer, at the Admin, or
+   at the PKI.  The PKC request can come from either the IPsec Peer, a
+   combination of the Peer and the Admin, or not at all.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 20]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+3.3.1.  Generation Method 1: IPsec Peer Generates Key Pair, Constructs
+        PKC Request, and Signs PKC Request
+
+   This option will be used most often in the field.  This is the most
+   secure method for keying, as the keys are generated on the end entity
+   and the private key never leaves the end entity.  However, it is the
+   most computationally intensive for the Peer, as it must be "ASN.1
+   aware" to support generating and digitally signing the PKC request.
+
+       +--------------+     +-----------------------+
+       |  Repository  |     |         CA/RA         |
+       +--------------+     +-----------------------+
+
+
+
+
+                                     +-------+
+                             +------>| Admin |
+                             |       +-------+
+                             |
+                             | 1
+                             V
+                +--------------------+          +--------+
+              2 |       IPsec        |          | IPsec  |
+                |      Peer 1        |          | Peer 2 |
+                +--------------------+          +--------+
+
+                  Figure 5.  Generation Interactions:
+      IPsec Peer Generates Key Pair and Constructs PKC Request
+
+   1) Opaque transaction [G].  Admin sends authorization identifier,
+      one-time authorization token, and any other parameters needed by
+      the Peer to generate the PKC request, including key type and size.
+
+   2) Generation [G].  Peer receives authorization identifier, one-time
+      authorization token, and any parameters.  Peer generates key pair
+      and constructs PKC request.
+
+   Steps prior to these can be found in Section 3.2.  The next step,
+   enrollment, can occur either directly between the Peer and PKI (see
+   Section 3.4.5) or through the Admin (see Section 3.4.6).
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 21]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+3.3.2.  Generation Method 2: IPsec Peer Generates Key Pair, Admin
+        Constructs PKC Request, Admin Signs PKC Request
+
+   This option also supports IPsec Peer generation of a key pair, but
+   removes the requirement for the Peer to be ASN.1 aware because it
+   does not have to construct or digitally sign the PKC request.  The
+   drawback is that the key pair does need to be provided to the Admin.
+   In the most probable cases where the Admin function is remotely
+   located from the peer, this means that the private key will leave the
+   cryptographic boundary of the peer, which is a significant security
+   trade-off consideration.  Whenever possible, it is always better to
+   have private keys generated and never leave the cryptographic
+   boundary of the generating system.
+
+       +--------------+     +-----------------------+
+       |  Repository  |     |         CA/RA         |
+       +--------------+     +-----------------------+
+
+
+
+
+                                   3 +-------+
+                             +------>| Admin | 4
+                             |       +-------+
+                             |
+                             | 1
+                             V
+                +--------------------+          +--------+
+              2 |       IPsec        |          | IPsec  |
+                |      Peer 1        |          | Peer 2 |
+                +--------------------+          +--------+
+
+                  Figure 6.  Generation Interactions:
+      IPsec Peer Generates Key Pair, Admin Constructs PKC Request
+
+   1) Opaque transaction [G].  Admin sends command to Peer to generate
+      key pair, based on parameters provided in the command.
+
+   2) Generation [G].  Peer generates key pair.
+
+   3) Opaque transaction [G].  Peer returns key pair to Admin.
+
+   4) Generation [G].  Admin constructs and digitally signs PKC request.
+
+   Steps prior to these can be found in Section 3.2.  The next step,
+   enrollment, occurs through the Admin (see Section 3.4.7).
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 22]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+3.3.3.  Generation Method 3: Admin Generates Key Pair, Constructs PKC
+        Request, and Signs PKC Request
+
+   This option exists for deployments where Peers cannot generate their
+   own key pairs.  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 from the Peer.  If key
+   escrow is performed then the exact requirements and procedures for it
+   are beyond the scope of this document.
+
+       +--------------+     +-----------------------+
+       |  Repository  |     |         CA/RA         |
+       +--------------+     +-----------------------+
+
+
+
+
+                                     +-------+
+                                     | Admin | 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, constructs PKC request,
+      and digitally signs PKC request.
+
+   Steps prior to these can be found in Section 3.2.  The next step,
+   enrollment, occurs through the Admin (see Section 3.4.8).
+
+   Note that separate authorizations steps are still of value even
+   though the Admin is also performing the key generation.  The PKC
+   template, Subject fields, 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, the authorization
+   schema can be reused.  This also allows for the feature of role-based
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 23]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   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.
+
+3.3.4.  Method 4: PKI Generates Key Pair
+
+   This option exists for deployments where end entities cannot generate
+   their own key pairs and the Admin function is a minimal
+   implementation.  The PKI and Admin pre-agree to have the PKI generate
+   key pairs and PKCs.  This is, in all likelihood, the easiest way to
+   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.  The Admin
+   effectively acts as a proxy for the Peer in the PKC enrollment
+   process.
+
+       +--------------+     +-----------------------+
+       |  Repository  |     |         CA/RA         | 1
+       +--------------+     +-----------------------+
+
+
+
+
+                                     +-------+
+                                     | Admin |
+                                     +-------+
+
+
+
+                +--------------------+          +--------+
+                |       IPsec        |          | IPsec  |
+                |      Peer 1        |          | Peer 2 |
+                +--------------------+          +--------+
+
+                  Figure 8.  Generation Interactions:
+      IPsec Peer Generates Key Pair, Admin Constructs PKC Request
+
+   1) Generation [G] The PKI generates the key pair.
+
+   Steps prior to these can be found in Section 3.2.  The next step,
+   enrollment, occurs through the Admin (see Section 3.4.9).
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 24]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+3.3.5.  Error Handling for Generation
+
+   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.
+
+3.4.  Enrollment
+
+   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 that
+   the PKI issue a PKC and 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.
+
+3.4.1.  One Protocol
+
+   One protocol MUST be specified for enrollment requests, responses,
+   and confirmations.
+
+3.4.2.  On-line Protocol
+
+   The protocol MUST 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
+
+   Manual approval of PKC enrollments is too time consuming for large
+   scale implementations, and is therefore not required.
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 25]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+3.4.5.  Enrollment Method 1: Peer Enrolls to PKI Directly
+
+   In this case, the IPsec Peer only communicates with the PKI after
+   being commanded to do so by the Admin.  This enrollment mode is
+   depicted in Figure 9 and the letters in the following description
+   refer to Figure 3.  Prior authorization (Section 3.2) and generation
+   (Section 3.3.1) steps are not shown.
+
+   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 PKI that it has such a key
+   pair; this is normally done by the PKI sending the end entity a
+   nonce, which the end entity signs and returns to the Admin along with
+   the end entity's public key.
+
+       +--------------+     +-----------------------+
+       |  Repository  |     |         CA/RA         |
+       +--------------+     +-----------------------+
+                               ^
+                           1,3 |
+                               |
+                               |
+                               |     +-------+
+                               |     | Admin |
+                               |     +-------+
+                               |
+                           2,4 |
+                               v
+                +--------------------+          +--------+
+                |       IPsec        |          | IPsec  |
+                |      Peer 1        |          | Peer 2 |
+                +--------------------+          +--------+
+
+                  Figure 9.  VPN-PKI Interaction Steps:
+                IPsec Peer Generates Keys and PKC Request,
+                         Enrolls Directly with PKI
+
+   1) Enrollment Request [E].  The IPsec Peer sends PKC requests to the
+      PKI, providing the generated public key.
+
+   2) Enrollment Response [E].  The PKI responds to the enrollment
+      request, providing either the new PKC that was generated or a
+      suitable error indication.
+
+   3) Enrollment Confirmation [E].  Peer positively acknowledges receipt
+      of new PKC back to the Admin.
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 26]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   4) Enrollment Confirmation Receipt [E].  PKI sends enrollment
+      confirmation receipt back to the Peer.
+
+3.4.6  Enrollment Method 2a: Peer Enrolls through Admin
+
+   In this case, the IPsec Peer has generated the key pair and the PKC
+   request, but does not enroll directly to the PKI System.  Instead, it
+   automatically sends its request to the Admin, and the Admin redirects
+   the enrollment to the PKI System.  The PKI System does not care where
+   the enrollment comes from, as long as it is a valid enrollment.  Once
+   the Admin receives the PKC response, it automatically forwards it to
+   the 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
+   case, the end entity needs to prove to the Admin that it has 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
+   the end entity's public key.
+
+   This enrollment mode is depicted in Figure 10 and the letters in the
+   following description refer to Figure 3.  Prior authorization
+   (Section 3.2) and generation (Section 3.3.1) steps are not shown.
+
+       +--------------+     +-----------------------+
+       |  Repository  |     |         CA/RA         |
+       +--------------+     +-----------------------+
+                                        ^ 2,6
+                                        |
+                                        |
+                                        v 3,7
+                                1,5  +-------+
+                                  +> | Admin |
+                                  |  +-------+
+                                  |
+                                  |
+                              4,8 v
+                +--------------------+          +--------+
+                |       IPsec        |          | IPsec  |
+                |      Peer 1        |          | Peer 2 |
+                +--------------------+          +--------+
+
+                  Figure 10.  VPN-PKI Interaction Steps:
+                IPsec Peer Generates Keys and PKC Request,
+                         Enrolls Through Admin
+
+   1) Opaque Transaction [E].  The IPsec Peer requests a PKC from the
+      Admin, providing the generated public key.
+
+
+
+Bonatti, et al.             Informational                      [Page 27]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   2) Enrollment Request [E].  The Admin forwards the enrollment request
+      to the PKI.
+
+   3) Enrollment Response [E].  The PKI responds to the enrollment
+      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.
+
+   5) Opaque Transaction [E].  Peer positively acknowledges receipt of
+      new PKC back to the Admin.
+
+   6) Enrollment Confirmation [E].  Admin forwards enrollment
+      confirmation back to the PKI.
+
+   7) Enrollment Confirmation Receipt [E].  PKI sends enrollment
+      confirmation receipt back to the Admin.
+
+   8) Opaque Transaction [E].  Admin forwards PKI's enrollment
+      confirmation receipt back to the Peer.
+
+3.4.7.  Enrollment Method 2b: Peer Enrolls through Admin
+
+   In this case, the IPsec Peer has generated the key pair, but the PKC
+   request is constructed and signed by the Admin.  The PKI System does
+   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 along with the key pair.
+
+   Some IPsec Systems do not have enough CPU power to generate a public
+   and private key pair of sufficient strength for secure IPsec.  In
+   this case, the Admin needs to prove to the PKI that it has such a key
+   pair; this is normally done by the PKI sending the Admin a nonce,
+   which the Admin signs and returns to the PKI along with the end
+   entity's public key.  A drawback to this case is that the private key
+   will eventually be sent over the wire (though hopefully securely so)
+   from Admin to the IPsec Peer; whenever possible, it is preferred to
+   keep a key within its cryptographic boundary of origin.  Failing to
+   do so opens the system to risk of the private keys being sniffed and
+   discerned.
+
+   This enrollment mode is depicted in Figure 11 and the letters in the
+   following description refer to Figure 3.  Prior authorization
+   (Section 3.2) and generation (Section 3.3.2) steps are not shown.
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 28]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+       +--------------+     +-----------------------+
+       |  Repository  |     |         CA/RA         |
+       +--------------+     +-----------------------+
+                                        ^ 1,5
+                                        |
+                                        |
+                                        v 2,6
+                                  4  +-------+
+                                  +->| Admin |
+                                  |  +-------+
+                                  |
+                                  |
+                              3,7 v
+                +--------------------+          +--------+
+                |       IPsec        |          | IPsec  |
+                |      Peer 1        |          | Peer 2 |
+                +--------------------+          +--------+
+
+                  Figure 11.  VPN-PKI Interaction Steps:
+           IPsec Peer Generates Keys, Admin Constructs and
+               Signs PKC Request, Enrolls through Admin
+
+   1) Enrollment Request [E].  The Admin requests a PKC from the PKI,
+      providing the generated public key.
+
+   2) Enrollment Response [E].  The PKI responds to the enrollment
+      request, providing either the new PKC that was generated or a
+      suitable error indication.
+
+   3) Opaque Transaction [E].  The Admin forwards the enrollment
+      response back to the IPsec Peer.
+
+   4) Opaque Transaction [E].  Peer positively acknowledges receipt of
+      new PKC back to the Admin.
+
+   5) Enrollment Confirmation [E].  Admin forwards enrollment
+      confirmation back to the PKI.
+
+   6) Enrollment Confirmation Receipt [E].  PKI sends enrollment
+      confirmation receipt back to the Admin.
+
+   7) Opaque Transaction [E].  Admin forwards PKI's enrollment
+      confirmation receipt back to the Peer.
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 29]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+3.4.8.  Enrollment Method 3a: Admin Authorizes and Enrolls Directly to
+        PKI
+
+   In this case, the Admin generates the key pair, PKC request, and
+   digitally signs the PKC request.  The PKI System does not care where
+   the enrollment comes from, as long as it is a valid enrollment.  Once
+   the Admin retrieves the PKC, it then automatically forwards it to the
+   IPsec Peer along with the key pair.
+
+   Some IPsec Systems do not have enough CPU power to generate a public
+   and private key pair of sufficient strength for secure IPsec.  In
+   this case, the Admin needs to prove to the PKI that it has such a key
+   pair; this is normally done by the PKI sending the Admin a nonce,
+   which the Admin signs and returns to the PKI along with the end
+   entity's public key.  A drawback to this case is that the private key
+   will eventually be sent over the wire (though hopefully securely so)
+   from Admin to the IPsec Peer; whenever possible, it is preferred to
+   keep a key within its cryptographic boundary of origin.  Failing to
+   do so opens the system to risk of the private keys being sniffed and
+   discerned.
+
+   This enrollment mode is depicted in Figure 12 and the letters in the
+   following description refer to Figure 3.  Prior authorization
+   (Section 3.2) and generation (Section 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 and PKC Request, and Enrolls Directly
+                              with PKI
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 30]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   1) Enrollment Request [E].  The Admin requests a PKC from the PKI,
+      providing the generated public key.
+
+   2) Enrollment Response [E].  The PKI responds to the enrollment
+      request, providing either the new PKC that was generated or a
+      suitable error indication.
+
+   3) Opaque Transaction [E].  The Admin forwards the enrollment
+      response back to the IPsec Peer, along with the keys.
+
+   4) Opaque Transaction [E].  Peer positively acknowledges receipt of
+      new PKC back to the Admin.
+
+   5) Enrollment Confirmation [E].  Admin forwards enrollment
+      confirmation back to the PKI.
+
+   6) Enrollment Confirmation Receipt [E].  PKI sends enrollment
+      confirmation receipt back to the Admin.
+
+   7) Opaque Transaction [E].  Admin forwards PKI's enrollment
+      confirmation receipt back to the Peer.
+
+3.4.9.  Enrollment Method 3b: Admin Requests and PKI Generates and
+        Sends PKC
+
+   In this instance, the PKI and Admin have previously agreed to have
+   the PKI generate keys and certificates when the PKI receives an
+   authorization request.  The 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.
+
+   A drawback to this case is that the private key will eventually be
+   sent over the wire (though hopefully securely so) from Admin to the
+   IPsec Peer; whenever possible, it is preferred to keep a key within
+   its cryptographic boundary of origin.  Failing to do so opens the
+   system to risk of the private keys being sniffed and discerned.
+
+   This enrollment mode is depicted in Figure 13 and the letters in the
+   following description refer to Figure 3.  Prior authorization
+   (Section 3.2) and generation (Section 3.3.4) steps are not shown.
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 31]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+       +--------------+     +-----------------------+
+       |  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, PKC Request, and Enrolls
+                             Directly with PKI
+
+   1) Enrollment Response [E].  The PKI responds to the authorization
+      request sent, providing either the new PKC and public-private key
+      pair that were generated or a suitable error indication.
+
+   2) Opaque Transaction [E].  The Admin forwards the enrollment
+      response back to the IPsec Peer, along with the keys.
+
+   3) Opaque Transaction [E].  Peer positively acknowledge receipt of
+      new PKC back to the Admin.
+
+   4) Enrollment Confirmation [E].  Admin forwards enrollment
+      confirmation back to the PKI.
+
+   5) Enrollment Confirmation Receipt [E].  PKI sends enrollment
+      confirmation receipt back to the Admin.
+
+   6) Opaque Transaction [E].  Admin forwards PKI's enrollment
+      confirmation receipt back to the Peer.
+
+3.4.10.  Confirmation Handshake
+
+   Any time a new PKC is issued by the PKI, a confirmation of PKC
+   receipt MUST be sent back to the PKI by the Peer or the Admin
+   (forwarding the Peer's confirmation).
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 32]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   Operationally, the Peer MUST send a confirmation to the PKI verifying
+   that it has received the PKC, loaded it, and can use it effectively
+   in an IKE exchange.  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 is not received and
+       operational within an allowable window of time.
+
+   To assert such proof, the Peer MUST sign a portion of data with the
+   new key.  The result MUST be sent to the PKI.  The entity that
+   actually sends the result to the PKI MAY be either the Peer (sending
+   it directly to the PKI) or Admin (the Peer would send it to Admin,
+   and Admin can, in turn, send it to the PKI).
+
+   The Admin MUST acknowledge the successful receipt of the
+   confirmation, thus signaling to the Peer that it may proceed using
+   this PKC in IKE connections.  The PKI MUST complete all the
+   processing necessary to enable the Peer's operational use of the new
+   PKC (for example, writing the PKC to the repository) before sending
+   the confirmation acknowledgement.  The Peer MUST NOT begin using the
+   PKC 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 enrollment process.  Providing
+   such error codes will greatly aid interoperability efforts between
+   the PKI and IPsec products.
+
+   The profile will clarify what happens if the request and retrieval
+   fails for some reason.  The following cases MUST be covered:
+
+     - Admin or Peer cannot send the request.
+
+     - Admin or Peer sent the request, but the PKI did not receive the
+       request.
+
+     - PKI received the request, but could not read it effectively.
+
+     - PKI received and read 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.
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 33]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+     - The PKI sent the PKC, but the requestor (Admin or Peer) did not
+       receive it.
+
+     - The Requestor (Admin or Peer) received 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 to send the confirmation.
+
+     - The Requestor sent the confirmation, but the PKI did not receive
+       it.
+
+     - The PKI received the confirmation but could not process it.
+
+   In each case the following questions MUST be addressed:
+
+     - What does Peer do?
+     - What does Admin do?
+     - What does PKI do?
+     - Is Authorization used?
+
+   If a failure occurs after the PKI sends the PKC and before the Peer
+   receives it, then the Peer MUST re-request with the same
+   authorization ID and one-time authorization token.  The PKI, seeing
+   the authorization ID and authorization token, MUST send the PKC
+   again.
+
+   Enrollment errors MUST be sent to the Admin regardless of the entity
+   that generated the enrollment request.
+
+3.5.  Lifecycle
+
+   This section refers to the [L] elements labeled in Figure 3.
+
+   Once the PKI has issued a PKC for the end entity Peer, the Peer MUST
+   be able to either contact the PKI directly or through the Admin for
+   any subsequent rekeys, renewals, updates, or revocations.  The PKI
+   MUST support either case for renewals, updates, and revocations.
+   Rekeys are Admin initiated; therefore, Peer initiated rekeys MUST be
+   transferred via the Admin.
+
+3.5.1.  One Protocol
+
+   One protocol MUST be specified for rekey, renew, and update requests,
+   responses, and confirmations.  It MUST be the same protocol as is
+   specified in Section 3.4.
+
+
+
+Bonatti, et al.             Informational                      [Page 34]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   Revocation requests MAY use the same protocol as rekey, renew, and
+   update operations.  Revocation requests MAY also occur via email,
+   telephone, Instant Messaging, etc.
+
+3.5.2.  PKC Rekeys, Renewals, and Updates
+
+   Rekeys, renewals, and updates are variants of a PKC enrollment
+   request scenario with unique operational and management requirements.
+
+     - A PKC rekey replaces an end entity's PKC with a new PKC that has
+       a new public key for the same SubjectName and SubjectAltName
+       contents before the end entity's currently held PKC expires.
+
+     - A PKC renewal replaces an end entity's PKC with the same public
+       key for the same SubjectName and SubjectAlternativeName contents
+       as an existing PKC before that PKC expires.
+
+     - A PKC update is defined as a new PKC issuance with the same
+       public key for an altered SubjectName or SubjectAlternativeName
+       before expiration of the end entity's current PKC.
+
+   When sending rekey, renew, or update requests, the entire contents of
+   the PKC request needs to be sent to the PKI, not just the changed
+   elements.
+
+   The rekey, renew, and update requests MUST be signed by the private
+   key of the old PKC.  This will allow the PKI to verify the identity
+   of the requestor, and ensure that 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 new PKC in a renew or update
+   scenario is a matter of local security policy, and MUST be specified
+   by the Admin to the PKI in the original authorization request.
+   Reusing the same key is permitted, but not encouraged.  If a new key
+   is used, the update or 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 resulting from a rekey, renew, or update will be
+   retrieved in-band, using the same mechanism as a new PKC request.
+
+   For the duration of time after a rekey, renew, or update has been
+   processed and before PKI has received confirmation of the Peer's
+   successful receipt of the new PKC, both PKCs (the old and the new)
+   for the end entity will be valid.  This will allow the Peer to
+   continue with uninterrupted IKE connections with the previous PKC
+   while the rekey, renewal, or update process occurs.
+
+
+
+
+Bonatti, et al.             Informational                      [Page 35]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   After the rekey, renewal, or update occurs, the question now exists
+   for the PKI of what to do about the old PKC.  If the old PKC is to be
+   made unusable, the PKI will need to add it to the revocation list,
+   removed from the repository; however this should only occur once all
+   connections that used the old PKC have expired.  The decision about
+   if the old PKC should be made unusable is determined by local policy.
+   Either the PKI or the Admin MUST specify this parameter during the
+   authorization phase.  In this case, the PKI or the Admin MUST also
+   specify the length of time from when the PKI receives the end entity
+   Peer's confirmation (of receipt of the PKC) until when the old PKC is
+   made unusable.
+
+   In the case where the new keys were generated for a renew or update
+   request and for rekey requests, once the Peer receives the
+   confirmation acknowledgement from the PKI, it is good practice for
+   the old key pair to be destroyed as soon as possible.  Deletion can
+   occur once all connections that used the old PKC have expired.
+
+   If a PKC has been revoked, it MUST NOT be allowed a rekey, renewal,
+   or update.
+
+   Should the PKC expire without rekey, renewal, or update, an entirely
+   new request MUST be made.
+
+3.5.2.1.  Rekey Request
+
+   Admins manage rekeys to ensure uninterrupted use of the VPN by Peers
+   with new keys.  Rekeys can occur automatically if the Admin is
+   configured to initiate a new authorization for the rekey.
+
+   Scenarios for rekey are omitted as they use the same scenarios used
+   in the original PKC enrollment from Sections 3.2, 3.3, and 3.4.
+
+3.5.2.2.  Renew Request
+
+   Admins manage renewals to ensure uninterrupted use of the VPN by
+   Peers with the same key pair.
+
+   At the time of authorization, certain details about renewal
+   acceptance will be conveyed by the Admin to the PKI, as stated in
+   Section 3.2.4.2.  The renewal request MUST match the conditions that
+   were specified in the original authorization for:
+
+     - Keys: New, existing, or either.
+     - Requestor: End entity Peer, Admin, or either.
+     - Period: How soon before PKC expiry.
+     - Time: Length of time before making the old PKC unusable.
+
+
+
+
+Bonatti, et al.             Informational                      [Page 36]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   If any of these conditions are not met, the PKI must reject the
+   renewal and log the event.
+
+   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.3.  Update Request
+
+   An update to the contents of a PKC will be necessary when details
+   about an end entity Peer's identity change, but the Operator does not
+   want to generate a new PKC from scratch, requiring a whole new
+   authorization.  For example, a gateway device may be moved from one
+   site to another.  Its IPv4 Address will change in the SubjectAltName
+   extension, but all other information could stay the same.  Another
+   example is an end user who gets married and changes the last name or
+   moves from one department to another.  In either case, only one field
+   (the Surname or Organizational Unit (OU) in the DN) need change.
+
+   An update differs from a rekey or a renewal in a few ways:
+
+     - A new key is not necessary
+
+     - The timing of the update event is not predictable, as is the case
+       with a scheduled rekey or renewal.
+
+     - The update request may occur at any time during a PKC's period of
+       validity.
+
+     - Once the update is completed, and the new PKC is confirmed, the
+       old PKC should cease to be 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 Section
+   3.2.4.2.  The update request MUST match the conditions that were
+   specified in the original authorization for:
+
+     - Keys: new, existing, or either.
+     - Requestor: End entity Peer, Admin, or either.
+     - The fields in the Subject and SubjectAltName that are changeable.
+     - Time: Length of time before making the old PKC unusable.
+
+   If any of these conditions are not met, the PKI MUST reject the
+   update and log the event.
+
+   If an update authorization was not made at the time of original
+   authorization, one can be made from Admin to the PKI at any time
+   during the PKC's valid life.  When such an update is desired, Admin
+
+
+
+Bonatti, et al.             Informational                      [Page 37]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   must notify the PKI System that an update is authorized for the end
+   entity and must specify the new contents.  Admin then initiates the
+   update request with the given contents in whichever mechanism the VPN
+   System employs (direct from end entity to PKI, from end entity
+   through Admin, or directly from Admin).
+
+   Scenarios for update are omitted as they use the same scenarios used
+   in the original PKC enrollment from Sections 3.2, 3.3, and 3.4.
+
+3.5.2.4.  Error Handling for Rekey, Renewal, and Update
+
+   Thorough error condition descriptions and handling instructions are
+   required for each transaction in the rekey, renewal, or update
+   process.  Providing such error codes will greatly aid
+   interoperability efforts between the PKI and IPsec products.
+
+3.5.2.5.  Confirmation Handshakes
+
+   The confirmation handshake requirements are the same as in Sections
+   3.2, 3.3, and 3.4 except that depending on the Administrative policy
+   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 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 issued
+   under a template it 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
+   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.
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 38]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   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.6.  Repositories
+
+   This section refers to the [R] elements labeled in Figure 3.
+
+3.6.1.  Lookups
+
+   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.
+
+   CDP MUST be flagged as required in the authorization request.  The
+   method MUST also be specified: the HTTP method MUST be method; the
+   Lightweight Directory Access Protocol (LDAP) method MAY be supported.
+
+   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.
+
+   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 Network Address
+       Translation (NAT) or Port Address Translation (PAT)).
+
+     - The protocol can easily perform some query against a remote
+       repository on a specific ID element that was given to it in a
+       standard PKC field.
+
+
+
+
+Bonatti, et al.             Informational                      [Page 39]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   Other considerations include:
+
+     - Relative speed
+     - Relative ease of administration
+     - Scalability
+
+   Intermediate PKCs will be needed for the case of re-keying of the CA,
+   or a PKI System where multiple CAs exist.
+
+   PKCs MAY have extendedKeyusage to help identify the proper PKC for
+   IPsec, though the default behavior is to not use them (see 3.1.5.3).
+
+   IPsec Peers MUST be able to resolve Internet domain names and support
+   the mandatory repository access protocol at the time of starting up
+   so they can perform the PKC lookups.
+
+   IPsec Peers should cache PKCs to reduce latency in setting up Phase
+   1.  Note that this is an operational issue, not an interoperability
+   issue.
+
+   The use case for accomplishing lookups when PKCs are not sent in IKE
+   is a stated non-goal of the profile at this time.
+
+3.6.2.  Error Handling for Repository Lookups
+
+   Thorough error condition descriptions and handling instructions are
+   required for each transaction in the repository lookup process.
+   Providing such error codes will greatly aid interoperability efforts
+   between the PKI and IPsec products.
+
+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
+       the scope of this document, but is assumed to occur via an
+       unauthenticated but confidential enrollment protocol.
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 40]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+3.7.2.  Certification Path Validation
+
+   The IPsec Peer MUST perform identity verification based on the fields
+   of the PKC and parameters applicable to the VPN Security Association.
+   The fields of the PKC used for verification MAY include either the
+   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 Simple Certificate Validation Protocol (SCVP) server
+   MUST validate the certification path, as per RFC 3280.  The contents
+   necessary in the PKC to allow this will be enumerated in the profile
+   document.
+
+   The Peer MAY have the ability to construct the certification path
+   itself; however, Admin MUST be able to supply Peers with the trust
+   anchor and any chaining PKCs necessary.  The Admin MAY ensure the
+   template uses the AIA extension in PKCs as a means of facilitating
+   path validation.
+
+   DNS MUST be supported by the Peers in order to support resolving URLs
+   present in CDPs and AIA extensions.
+
+3.7.3.  Revocation 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.
+
+   All PKCs used in IKE MUST have cRLDistributionPoint and
+   authorityInfoAccess fields populated with valid URLs.  This will
+   allow all recipients of the PKC to know immediately how revocation is
+   to be accomplished, and where to find the revocation information.
+   The AIA is needed in an environment where multiple layers of CAs
+   exist and for the 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.
+
+
+
+Bonatti, et al.             Informational                      [Page 41]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   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.4.  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 intent of the PKI4IPSEC WG was to profile and use
+   concrete protocols for certificate management (e.g., Cryptographic
+   Message Syntax (CMS), Certificate Management over CMS (CMC),
+   Certificate Request Message Format (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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 42]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+5.  References
+
+5.1.  Normative References
+
+   [MUSTSHOULD]     Bradner, S., "Key words for use in RFCs to Indicate
+                    Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+5.2.  Informative References
+
+   [CERTPROFILE]    Housley, R., Polk, W., Ford, W., and D. Solo,
+                    "Internet X.509 Public Key Infrastructure
+                    Certificate and Certificate Revocation List (CRL)
+                    Profile", RFC 3280, April 2002.
+
+   [DOI]            Piper, D., "The Internet IP Security Domain of
+                    Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [FRAME]          Chokhani, S., Ford, W., Sabett, R., Merrill, C., and
+                    S. Wu, "Internet X.509 Public Key Infrastructure
+                    Certificate Policy and Certification Practices
+                    Framework", RFC 3647, November 2003.
+
+   [IKECERTPROFILE] Korver, B., "The Internet IP Security PKI Profile of
+                    IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress,
+                    February 2007.
+
+   [IKEv1]          Harkins, D. and D. Carrel, "The Internet Key
+                    Exchange (IKE)", RFC 2409, November 1998.
+
+   [IKEv2]          Kaufman, C., "Internet Key Exchange (IKEv2)
+                    Protocol", RFC 4306, December 2005.
+
+   [IPsec]          Kent, S. and K. Seo, "Security Architecture for the
+                    Internet Protocol", RFC 4301, December 2005.
+
+6.  Acknowledgements
+
+   This RFC is substantially based on a prior document developed by
+   Project Dploy.  The principle editor of that document was Gregory M.
+   Lebovitz (NetScreen/Juniper).  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), and Michael Shieh (NetScreen/Juniper).
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 43]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+   Once brought to the IETF's PKI4IPSEC WG, the following people made
+   substantial contributions: Jim Schaad and Stefan Santesson.
+
+Editors' Addresses
+
+   Chris Bonatti
+   IECA, Inc.
+   EMail: Bonattic@ieca.com
+
+   Sean Turner
+   IECA, Inc.
+   EMail: Turners@ieca.com
+
+   Gregory M. Lebovitz
+   Juniper
+   EMail: gregory.ietf@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 44]
+
+RFC 4809        Reqs for IPsec Certificate Mgmt Profile    February 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   The 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 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 procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Bonatti, et al.             Informational                      [Page 45]
+