PKI4IPSEC Working Group Internet Draft Chris Bonatti, IECA draft-ietf-pki4ipsec-mgmt-profile-rqts-03.txt Sean Turner, IECA July 20, 2005 Gregory Lebovitz, Juniper Expires February 20, 2006 Requirements for an IPsec Certificate Management Profile Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This informational document describes and identifies the requirements for 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, Turner, Lebovitz 1 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 1 Introduction 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 renewal, updates, or rekeys. - Ensure timely revocation information is available for PKCs used in IKE exchanges. These requirements will 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 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. Bonatti, Turner, Lebovitz 2 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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 Admin 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 address 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 lowest ten percent of convenience requirements. Use cases will be considered or rejected based upon this eighty percent rule. The needs of small deployments are a stated non-goal, however service providers employing the scoped solution and applying it to many smaller deployments in aggregate may address them. Gateway-to-gateway access and end-user remote access (to a gateway) are both covered. End-to-end communications are not necessarily excluded but are intentionally not a focus. Only VPN-PKI transactions that ease and enable scalable PKI-enabled IPsec deployments are addressed. 1.2 Non-Goals The scenario for PKC cross-certification will not be addressed. The protocol specification for the VPN-PKI interactions will not be addressed. The protocol specification for the 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 is far beyond the scope of this current effort, and will described as opaque transactions in this document. Bonatti, Turner, Lebovitz 3 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile The protocol specification for RA-CA, CA-Repository, and RA- Repository interactions will not be addressed. 1.3 Definitions VPN System The VPN System is comprised of the VPN Administration function (defined below), the IPsec Peers, and the communication mechanism between the VPN Administration and the IPsec Peers. VPN System is defined in more detail in section 2.1. PKI System 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 a secure tunnel for communications. It can be either a traditional security gateway (with two network interfaces, one for the protected network and one for the unprotected network), or it can be an IPsec client (with a single network interface). In both cases, the Peer can pass traffic with no IPsec protection, and can add IPsec protection to chosen traffic streams. See Section 2.1.1 for more details. (VPN) Admin The Admin is the VPN System function that interacts with the PKI System to establish PKC provisioning for the VPN connections. See Section 2.1.2 for more details. End Entity An end entity is the entity or subject that is identified in a PKC. The end entity is the one entity that will finally use a private key associated with a PKC to digitally sign data. In this document, an IPsec Peer is certainly an end entity, but the VPN Admin can also constitute an end entity. Note that end entities can have different PKCs for different purposes (e.g., signature vs. key exchange, Admin- functions vs. Peer-functions). Bonatti, Turner, Lebovitz 4 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile PKC Renewal The acquisition of a new PKC with the same public key due to the expiration of an existing PKC. Renewal occurs prior to the expiration of the existing PKC to avoid any connection outages. A renewal process can rely on the existing key pair to bootstrap authentication for the new enrollment. PKC Update A special case of a renewal-like occurrence where a PKC needs to be changed prior to expiration due to some change in its subjectÆs information. Examples might include change in the address, telephone number, or name change due to marriage of the end entity. An update process can rely on the existing key pair to bootstrap authentication for the new enrollment. PKC Rekey 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. Registration Authority (RA) An optional entity in a PKI System given responsibility for performing some of the administrative tasks necessary in the registration of end entities, such as confirming the subjectÆs identity and verifying that the subject has possession of the private key associated with the public key requested for a PKC. Certificate Authority (CA) An authority in a PKI System that is trusted by one or more users to create and sign PKCs. It is important to note that the CA is responsible for the PKCs during their whole lifetime, not just for issuing them. Repository An Internet-accessible server in a PKI System that stores and makes available for retrieval PKCs and Certificate Revocation Lists (CRLs). Root CA/Trust Anchor A CA that is directly trusted by an end entity; that is, securely acquiring the value of a Root CA public key requires some out-of-band step(s). This term is not meant to imply that a Root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly. Certificate Revocation List (CRL) A CRL is a CA-signed, time stamped list identifying revoked PKCs and made freely available in a repository. Peers retrieve the CRL to Bonatti, Turner, Lebovitz 5 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile verify that a PKC being presented to them as the identity in an IKE transaction has not been revoked. CRL Distribution Point (CDP) The CDP 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 Though this document is not an Internet Draft, we use the convention that 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, Turner, Lebovitz 6 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 2. Architecture This section describes the overall architecture for a PKI-supported IPsec VPN deployment. First, an explanation of the VPN System is presented. Second, key points about the PKI System are stated. Third, the VPN-PKI architecture 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 require an IPsec tunnel establishment. 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 for 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 Bonatti, Turner, Lebovitz 7 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile options, and PKC fields) for groups of IPsec Peers. The Admin also authorizes PKC issuance and it can act as the Peer's PKI System 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 in the same as the gateway or 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). Bonatti, Turner, Lebovitz 8 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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. +---------------------------------------------+ | +-------------------------+ | | 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. These mechanisms are referred to as the 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. It is therefore sensible to consider the steps necessary to set up, use and manage PKCs for one Peer to establish an association with another Peer. Bonatti, Turner, Lebovitz 9 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile +-----------------------------------------------+ | 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, and 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 paragraphs 3.2-3.6. However, only requirement for [A], [E], [L], and [R] will be addressed by the certificate management profile. Requirements for [I] transactions are 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, Turner, Lebovitz 10 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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. It is a specific goal to avoid multiple competing protocols or profiles to solve the same requirement whenever possible to reduce complexity and improve interoperability. Meeting some of the requirements may necessitate the creation of a new protocol or new extension for an existing protocol; however, the later 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 paragraph 3.7.1. [R] transactions do not require authentication or message data integrity because the responses (i.e., PKCs and CRLs) are already digital 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 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). Bonatti, Turner, Lebovitz 11 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile Likewise, it can be entered directly on the IPsec Peer via a User Interface (UI). In this case, the Admin function is co-located on the 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.3 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.4 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.5 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, failure to achieve PKC profile consensus MUST NOT hold up the standardization effort. Bonatti, Turner, Lebovitz 12 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 3.1.5.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.5.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.5.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.5.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.6 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 these Admin to PKI (RA/CA) interaction. This protocol MUST support privacy, authorization, Bonatti, Turner, Lebovitz 13 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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). 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. Bonatti, Turner, Lebovitz 14 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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. +--------------+ +-----------------------+ | Repository | | CA/RA | +--------------+ +-----------------------+ ^ | 1 2 | v +-------+ | Admin | +-------+ +--------------------+ +--------+ | IPsec | | IPsec | | Peer 1 | | Peer 2 | +--------------------+ +--------+ Figure 4. Authorization Transactions 1) Authorization [A]. Admin sends a list of identities and PKC contents for the PKI System to authorize enrollment. The PKI returns a list of unique authorization identifiers and one-time authorization tokens to be used for the enrollment of each PKC. See paragraph 3.2.4. 2) Authorization Response [A]. The PKI System acknowledges the authorizations provided in (1). Response may indicate success, failure, or errors for any particular authorization. See paragraph 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 Bonatti, Turner, Lebovitz 15 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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]. Requirements for PKC fields used in VPN-PKI transactions are specified in paragraph 3.1.5. 3.2.4.2 Authorizations for Renewal, Update, and Rekey When the VPN Operator and PKI Operator pre-agree on a template, 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. - Specify at how long before the PKC expiration date the PKI will accept and process a renewal (i.e., N% of validity period, or the UTC time after which renewal is permitted). If PKC update is authorized, the Admin MUST further specify: - The aspects of non-key-related fields that are changeable. - The entity that can send the PKC Update request, that is, only the Admin, only the Peer, or either. - Specify at how long before the PKC expiration date the PKI will accept and process an update (i.e., N% of validity period, or the UTC time after which update is permitted). Bonatti, Turner, Lebovitz 16 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile A new authorization by the Admin is REQUIRED for PKC rekey. No parameters of prior authorizations need be considered. 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 UTF8 format to avoid incompatibilities that may occur due to international characters. It MUST support normalization as in (certificate management profile). The Admin MUST have the ability to constrain the UTF8 character set. There MUST be an option to specify a validation period for the authorization ID and its one-time authorization token. If such a validation period is set, any PKC requests using this 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 clause 3.6. Bonatti, Turner, Lebovitz 17 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 3.2.5 Authorization Response If the authorization is acceptable, the PKI will respond to the Admin with a unique authorization identifier per subject authorization requested and a one-time authorization token per authorization ID. See paragraph 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 perform an "operational test" to verify that the issued PKCs will meet its requirements. If the Admin determines that the modified parameters are unacceptable, then the authorization should be cancelled in accordance with clause 3.2.4.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 setting between the time the authorization is granted and 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 paragraph 3.2), and this information is received at the Admin, the next step is to generate public and private key pairs and to construct PKC requests using those key pairs. The key generations 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, Turner, Lebovitz 18 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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. 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 paragraph 3.2. The next step, enrollment, can occur either directly between the Peer and PKI (see paragraph 3.4.5) or through the Admin (see paragraph 3.4.6). 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 key pair, but removes the requirement for the Peer to be ASN.1 aware because it Bonatti, Turner, Lebovitz 19 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile does not have to construct or digitally sign the PKC request. The drawback is that the key pair does need to be provided to the Admin. +--------------+ +-----------------------+ | Repository | | CA/RA | +--------------+ +-----------------------+ 3 +-------+ +------>| Admin | 4 | +-------+ | | 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. 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 paragraph 3.2. The next step, enrollment, occurs through the Admin (see paragraph 3.4.7). 3.3.3 Generation Method 3: Admin Generates Key Pair, 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 off the Peer. If key escrow is performed then the exact requirements and procedures for it are beyond the scope of this document. Bonatti, Turner, Lebovitz 20 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile +--------------+ +-----------------------+ | 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 paragraph 3.2. The next step, enrollment, occurs through the Admin (see paragraph 3.4.8). Note that separate authorizations step are still of value even though the Admin is the 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 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. Bonatti, Turner, Lebovitz 21 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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 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 paragraph 3.2. The next step, enrollment, occurs through the Admin (see paragraph 3.4.9). 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. Bonatti, Turner, Lebovitz 22 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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 is therefore not required. 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 (see paragraph 3.2) and generation (see paragraph 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 they have such a Bonatti, Turner, Lebovitz 23 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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 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) Enrollment Confirmation [E]. Peer positively acknowledges receipt of new PKC. 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 Bonatti, Turner, Lebovitz 24 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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 they have such a key pair; this is normally done by the Admin sending the end entity a nonce, which the end entity signs and returns to the Admin along with 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 (see paragraph 3.2) and generation (see paragraph 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. 2) Enrollment [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. Bonatti, Turner, Lebovitz 25 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 5) Opaque Transaction [E]. Peer must positively acknowledge receipt of new PKC back to the Admin. 6) Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI. 7) 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 they have 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. This enrollment mode is depicted in Figure 11 and the letters in the following description refer to Figure 3. Prior authorization (see paragraph 3.2) and generation (see paragraph 3.3.2) steps are not shown. Bonatti, Turner, Lebovitz 26 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile +--------------+ +-----------------------+ | 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 [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 acknowledge 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, Turner, Lebovitz 27 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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 they have 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. This enrollment mode is depicted in Figure 12 and the letters in the following description refer to Figure 3. Prior authorization (see paragraph 3.2) and generation (see paragraph 3.3.3) steps are not shown. +--------------+ +-----------------------+ | Repository | | CA/RA | +--------------+ +-----------------------+ ^ 1,5 | | v 2,6 4 +-------+ +->| Admin | | +-------+ | | 3,7 v +--------------------+ +--------+ | IPsec | | IPsec | | Peer 1 | | Peer 2 | +--------------------+ +--------+ Figure 12. VPN-PKI Interaction Steps: Admin Generates Keys, PKC Request, and Enrolls Directly with PKI 1) Enrollment [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. Bonatti, Turner, Lebovitz 28 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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 acknowledge 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 Authorizes and Enrolls Directly to PKI In this instance, the PKI and Admin have previously agreed to have the PKI generate key 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. This enrollment mode is depicted in Figure 13 and the letters in the following description refer to Figure 3. Prior authorization (see paragraph 3.2) and generation (see paragraph 3.3.4) steps are not shown. Bonatti, Turner, Lebovitz 29 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile +--------------+ +-----------------------+ | Repository | | CA/RA | +--------------+ +-----------------------+ ^ 4 | | v 1,5 3 +-------+ +->| Admin | | +-------+ | | 2,6 v +--------------------+ +--------+ | IPsec | | IPsec | | Peer 1 | | Peer 2 | +--------------------+ +--------+ Figure 13. VPN-PKI Interaction Steps: PKI Generates Keys, 1) Enrollment Response [E]. The PKI responds to the 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, Turner, Lebovitz 30 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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 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, Turner, Lebovitz 31 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile - 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. 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, and the PKI, seeing the authorization ID and authorization token, MUST send the PKC again. Enrollment errors MUST be sent to the Admin regardless of 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 renewals, updates, rekeys, 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. Bonatti, Turner, Lebovitz 32 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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 paragraph 3.4. Revocation requests can be the same protocol as rekey, renew, and update operations. Revocation requests can also occur via email, telephone, Instant Messaging, etc. 3.5.2 PKC Rekeys, Renewals, and Updates Renewals, updates, and rekeys are variants of a PKC enrollment request scenario with unique operational and management requirements. - A PKC rekey 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 the end entityÆs currently held PKC expires. - A PKC update is defined as a new PKC issuance with the same public for an altered SubjectName or SubjectAlternativeName before expiration of the end entityÆs current PKC. When sending renew, update, or rekey requests, the entire contents of the PKC request needs to be sent to the PKI, just as in the case of the original enrollment. The renew, update and rekey 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. Re- using 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 renew, update or rekey will be retrieved in-band, using the same mechanism as a new PKC request. Bonatti, Turner, Lebovitz 33 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile For the duration of time after a renew, update, or rekey 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 renewal, update, or rekey process occurs. After the renewal, update or rekey occurs, the question now exists for the PKI of what to do about 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 a decision of local policy. Either the PKI or the Admin MUST specify this parameter during the authorization phase. In this case, the specifying party, either the Admin or the PKI, MUST also specify during authorization the length of time after the PKI receives the end entity PeerÆs confirmation (of receipt of the PKC) that will pass before 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 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 renewal, update or rekey. Should the PKC expire without renewal, update or rekey, 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.1 Renew Request Admins manage renewals to ensure uninterrupted use of the VPN by Peers with the same key pair. Bonatti, Turner, Lebovitz 34 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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, either - Period: How soon before PKC expiry. - Time: Length of time before making the old PKC unusable. 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.2 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 OU in the DN) need change. An update differs from renewal and rekeys 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 renewal or rekey - 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 or existing or either Bonatti, Turner, Lebovitz 35 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile - Requestor: End entity Peer, Admin, either - The fields in the Subject and SubjectAltName that are changeable - 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 must notify the PKI System that an update is authorized for the end entity, and to expect it coming, and specify the new contents. Admin then initiates the update request with the given contents in whatever mechanism the VPN System employs (direct from end entity to PKI, from end entity through Admin, or directly from Admin). Scenarios for update are 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 Error Handling for Rekey, Renewal, and Update Thorough error condition descriptions and handling instructions are required for each transaction in the renewal, update or rekey process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products. 3.5.2.4 Confirmation Handshakes The confirmation handshake requirements are the same as in clauses 3.2, 3.3, and 3.4 except that depending on the the PKI MUST also issue a revocation on the original PKC before sending the confirmation response. 3.5.3 Revocation The Peer MUST be able to initiate revocation for its own PKC. In this case the revocation request MUST be signed by the PeerÆs current key 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 Bonatti, Turner, Lebovitz 36 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile ability to configure Admin(s) with revocation authority, as identified by its PKC. Any PKC authorizations must specify if said PKC may be revoked by the Admin (see section 3.2.3.2 for more details). The profile MUST identify the one protocol or transaction within a protocol to be used for both Peer and Admin initiated revocations. The profile MUST identify the size of CRL the client will be prepared to support. Below are guidelines for revocation in specific transactions: - AFTER RENEW, BEFORE EXPIRATION: The PKI MUST be responsible for the PKC revocation during a renew transaction. PKI MUST revoke the PKC after receiving the confirm notification from the Peer, and before sending the confirm-ack to the Peer. The Peer MUST NOT revoke its own PKC in this case. - AFTER UPDATE, BEFORE EXPIRATION: The PKI MUST be responsible for the PKC revocation during an update transaction. PKI MUST revoke the PKC after receiving the confirm notification from the Peer, and before sending the confirm-ack to the Peer. The Peer MUST NOT revoke its own PKC in this case. 3.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; HTTP is the MUST method, LDAP is MAY. The complete hierarchical PKC chain (except the trust anchor) MUST be able to be searched in their respective repositories. The information to accomplish these searches MUST be adequately communicated in the PKCs sent during the IKE transaction. Bonatti, Turner, Lebovitz 37 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile All PKCs must be retrievable through a single protocol. The final specification will identify one protocol as a "MUST", others MAY be listed as "OPTIONAL". The general requirements for the retrieval protocol include: - The protocol can be easily Firewalled (including NAT or PAT). - 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. 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. Bonatti, Turner, Lebovitz 38 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 3.7 Trust 3.7.1 Trust Anchor PKC Acquisition The root PKC MUST arrive on the Peer via one of two methods: (a) Peer can get the root PKC via its secure communication with Admin. This requires the Peer to know less about interaction with the PKI. (b) Admin can command Peer to retrieve the root cert directly from the PKI. How retrieval of the root cert takes place is beyond scope, but is assumed to occur via an unauthenticated but confidential enrollment protocol. 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 tunnel. 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 SCVP server MUST validate the certification path, as per RFC3280. 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 SHOULD 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. Bonatti, Turner, Lebovitz 39 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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. If the revocation of a PKC is used as the only means of deactivation of access authorization for the Peer (or user), then the speed of deactivation will be as rapid as the refresh rate of the CRL issued and published by the PKI. If more immediate deactivation of access is required than the CRL refreshing can provide, then another mechanism for authorization that provides more immediate access deactivation should be layered into the VPN deployment. Such a second mechanism is out of the scope of this profile. (Examples are Xauth, L2TPÆs authentication, etc.). 3.7.3 Error Handling in Revocation Checking and Certificate Path Validation Thorough error condition descriptions and handling instructions are required for each transaction in the revocation checking and path validation process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products. 4. Security Considerations This requirements document does not specify a concrete solution, and as such has no system-related security considerations per se. However, the PKI4IPSEC model requires profiling and use of concrete protocols for certificate management (e.g., CMC, CMS, CRMF). The individual security considerations of these protocols should be carefully considered in the profiling effort. In addition, this document allows significant flexibility in the allocation of functions between the roles of Peer and Admin. This functional allocation is crucial both to achieving successful deployment, and to maintaining the integrity of the PKI enrollment and management processes. However, much of the responsibility for this allocation necessarily falls to product implementers and system Bonatti, Turner, Lebovitz 40 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile operators through the selection of applicable use cases and development of security policy constraints. These factors must be carefully considered to ensure the security of PKI4IPSEC certificate management. Appendix E catalogs some key system operator choices that are not constrained by this document, and frames their possible impacts. A References A.1 Normative References None A.2 Non-Normative References [STDPROCESS] Bradner, S., "The Internet Standards Process û Revision 3", BCP 9, RFC 2026, October 1996. [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [CERTPROFILE] Housley, R., et. al. "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [DOI] Piper, D., "Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [FRAME] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu. S., "Internet X.509 Public Key Infrastructure: Certificate Policy and Certificate Practices Framework", RFC 3647, November 2003. [GLOSSARY] Shirey, R., ôInternet Security Glossaryö, RFC 2828, May 2000. [IKECERTPROFILE] Korver, B., ôThe Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIXö,draft-ietf-pki4ipsec-ikecert- profile-03, 30 September 2004. B. Acknowledgements This draft is substantially based on a prior draft draft-dploy- requirements-00 developed by Project Dploy. The principle editor of that draft was Gregory M. Lebovitz (NetScreen Technologies). Contributing authors included Lebovitz, Paul Hoffman (VPN Consortium), Hank Mauldin (Cisco Systems), and Jussi Kukkonen (SSH Communications Security). Substantial editorial contributions were Bonatti, Turner, Lebovitz 41 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile made by Leo Pluswick (ICSA), Tim Polk (NIST), Chris Wells (SafeNet), Thomas Hardjono(VeriSign), Carlisle Adams (Entrust), and Michael Shieh (NetScreen). Once brought to pki4ipsec, the following people made substantial contributions: [TBD] ... C. EditorÆs Address Chris Bonatti IECA, Inc. 15309 Turkey Foot Road Darnestown, MD 20878-3640 USA bonattic@ieca.com Sean Turner IECA, Inc. 1421 T Street NW #8 Washington, DC 20009 USA turners@ieca.com Gregory M. Lebovitz NetScreen Technologies, Inc. gregory@netscreen.com D. Summary of Requirements TBD - EDITORÆS NOTE: Plan to add a summary table similar to those in RFCs 1122, 1123, and 2975. Table will briefly describe requirement, state the requirement level (i.e., "MAY", "SHOULD", "MUST", etc.), and cite the applicable paragraph in this draft. E. System Operator Choices This appendix catalogs some key choices that must be made by product implementers and system operators. These choices are not constrained by this document, but can have profound impacts on PKI4IPSEC certificate management operation and overall security. Where possible we attempt to frames the specific security and operational impacts associated with these choices. 1. Whether or not PKCs are allowed to be renewed or whether new PKCs need to be issued. 2. Certificate renewal initiated by the VPN Peer or the VPN Admin Bonatti, Turner, Lebovitz 42 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile F. Change History 2005-March Draft-ietf-pki4ipsec-mgmt-profile-rqts-03 This issue of the document attempts to close out all non-contentious issues as perceived after IETF #62. - The term "non-repudiation" was removed from the document, as non- repudiation support is supported by authentication. - IPSec replaced with IPsec. - The requirement for a "community realm" was removed from the document. - The requirement for an "update type" field was removed from the document. - Clarified requirements language û many MAYs were changed to can. - Changed abstract, 1, and 1.2 to indicate that Admin-Peer transaction's requirements, which were in the document from its initial version, are within scope of the document. - Reworded paras 1, 1.1, and 1.2 to remove duplication. - Added in 1.2 statements to clarify protocol specifications to are byond the scope of the document for any requirement addressed in the document (i.e., this is a requirements document not a protocol document). - Clarified para 2.1.2 first para. The last paragraph in para 2.1.2 was moved to 3.1.3 Admin Availability requirements. First bullet in second para of 2.1.2 was reworded to clarify PKCs are part of the local security policy. The second bullet was reworded to more fully define how the Admin uses templates. The requirements for secure Admin-Peer interactions was moved to para 3.1.2. - In para 2.3: added [G] and [M] interactions between PKI and Peers/Admin, [G], [E], [M], [R] transactions between Peer and Admin, renamed [M] Management to [L] Lifecycle, changed [E] to be sending PKC request, verifying response, and confirming PKC response, placed validation with confirmation in [L], swapped renwal, update, and rekey with repository lookups, add new last para to explain remaining organization. - Moved 2.3.1, 2.3.2, and 2.3.3 to later sections. Bonatti, Turner, Lebovitz 43 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile - Reorganized document based on general requirements and requirements for [A], [G], [E], [L], and [R] requirements. - Clarified the secure transaction requirements. [A], [E], [G], [L] require secure transactions, while [R] repository lookup is an operator decision (PKCs and CRLs are signed don't necessarily need privacy for their retrieval). - Moved requirements for a VPN-PKI PKC (para 3.5) to general requirements (3.1.5). Changed para to indicate it is the requirements for VPN-PKI PKC and not the IKE PKC. Identity requirements reduced to indicate name forms that need to be supported. Path validation requirements moved to later in the profile. Changed key usage requirements to indicate the requirement vice the field that must be supported. EKU requirement changed to indicate EKUs are not required and presence must not cause implementations to fail. Renamed pointer to revocation checking to revocation information location and reduced wording to say "must have location of revocation location." Note that the PKC profile for VPN-PKI interactions will be addressed in the certificate management profile. - Indicated manual approval for enrollment requests will not be supported. - Renamed "protocol preference for authorization" to "one authorization protocol". Removed redundant text describing PKI- Admin interactions (it gets covered later). Moved "batch" requirements to bulk authorizations. - Clarified that DNS is supported to resolve IP addresses. - Clarified that a PKC update can include a rekey. - Clarified that Admin can initiate revocations for any PKC issued under a template it controls, which supports the case where multiple Admins are used. - Added one protocol for Lifecycle requirements. One for rekey, renew, update; revocation may be the same. Rekey, renew, update must be same as enrollment protocol. - Removed notion of update ôtypeö. - Added that rekeys are initiated by Admin and that the PKI need not support direct interaction on rekey requests. Bonatti, Turner, Lebovitz 44 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile - Trust anchor acquisition, path validation, and revocation checking were grouped together under a new paragraph called Trust. 2004-December Draft-ietf-pki4ipsec-mgmt-profile-rqts-02 This issue of the document attempts to close out all non-contentious issues as perceived after IETF #61. Numerous clarifications to technical content were introduced, as well as revision to language for purposes of internal consistency and consistency with the [IKECERTPROFILE]. The following changes were introduced: - Description of PKC ôrenewalö was clarified IAW [GLOSSARY]. - Replaced term ôchangeö with ôupdateö IAW [GLOSSARY]. - Added description of PKC ôrekeyö to complete the terminology set employed in [GLOSSARY]. - Added [GLOSSARY] to the set of Non-Normative References. - Updated use of the terminology throughout the document to align with the above. - Scrubbed instances of ambiguous requirements terminology in favor of statements compliant with [MUSTSHOULD]. - Added reference to [IKECERTPROFILE] in several introductory text. - Resolved editorÆs note concerning renewal parameters in 3.2.3.1 and related text in 3.2.3.2. - Clarified that any non-key-related field might be changed in a PKC update operation. - Resolved editorÆs note concerning canceling authorizations in 3.2.4 so that either the Admin or the Peer may issue a cancellation. - Resolved editorÆs note concerning replay attacks in 3.2.4 so duplicate authorization request MUST have a new identifier. - Clarified the scenario in 3.2.5 for the PKI modifying the requested PKC template submitted by the Admin. - Renumbered previous clauses 3.3.1 through 3.3.4 as subsections of a new 3.3.1 entitled ôKey Generation Scenariosö. Bonatti, Turner, Lebovitz 45 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile - Moved and renumbered the existing clause 3.3.5 as a new clause 3.10 since the topic of trust anchor acquisition applies generically, and is not specifically subject to key generation or PKC request construction. - Added new key generation scenario as 3.3.1.5 in which the Peer initiates a PKC request without a prior authorization exchange between the Admin and the PKI. - Added new Figures 7 through 11 to clauses 3.3.1.1 through 3.3.1.5 respectively to illustrate the steps of the different key generation scenarios. - Clarified in several places that the delivery of the requested PKC is expected to occur directly as an in-band response, not via lookup in the certificate repository. - Resolved editorÆs note in 3.5.3 concerning key usage so that only the ôdigialSignatureö bit will be required to be set based on the understanding that this does not preclude a system from using digital signatures as a part of a non-repudiation service. - Added new text to section 4 on Security Considerations. - Corrected paragraph numbering on Non-Normative Reference section. - Incorporated a new Appendix E to summarize choices that must be made by VPN implementers and VPN system operators, and describe some of the potential impact of these decisions. - Applied numerous minor editorial corrections throughout the document. 2004-October Draft-ietf-pki4ipsec-mgmt-profile-rqts-01 This issue of the document addresses comments identified at IETF #60. The bulk of the changes were editorial, but some residual technical impact may have resulted. The following changes were introduced: - Acronym fixes - Clarification of PKC Change definition - Rearranged and consolidated references - Clarified what ôoff-lineö communication (out of band) entails. Bonatti, Turner, Lebovitz 46 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 2004-August Draft-ietf-pki4ipsec-mgmt-profile-rqts-00 This issue of the document was merely a reposting of draft-bonatti- pki4ipsec-profile-reqts-01 to bring the document under the WG auspices after the I-D repository opened. No significant changes were introduced. 2004-July Draft-bonatti-pki4ipsec-profile-reqts-01 This document was submitted as an individual draft in order to meet a publication deadline though it has been accepted in to the working group. The following salient changes were introduced: - A new Figure 1 was added in section 2.1 to depict just the VPN System. - A new Figure 2 was added to depict 2.2 to depict just the PKI System. - The old Figure 1 was moved to section 2.3. - Section 2.3 was split in to three sections to depict the New PKC, Renewal, and Revocation. Also the text was modified to indicate that the pictures are only for IPsec Peers generating key pairs and requesting PKCs. - Text and a Figure was added to Section 3.4.6 to show the architectural difference for IPsec Peers enrolling through an Admin. - Text and a Figure was added to Section 3.4.7 to show the architectural difference for Admins performing the entire enrollment. 2004-January Draft-bonatti-pki4ipsec-profile-reqts-00 This is a revised requirements document based on the existing Project Dploy requirements draft. It adapts the revisions to adapt the Dploy requirements to the scope of the proposed charter for an IETF PKI4IPSEC WG. It is submitted as an individual draft in anticipation of formation of the WG. The following salient changes were introduced: - Rewrote the abstract to focus on the document rather than the project. Bonatti, Turner, Lebovitz 47 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile - Rewrote and trimmed introduction to fit proposed scope of deliverable (2) from IETF PKI4IPSEC charter. - Rewrote sentences throughout to genericize the document for the IETF and remove references to Project Dploy objectives. - Removed reference to the Dploy Business Case. - Removed the "Audience" subsection of the introduction because it was redundant with other aspects of the introduction, and unnecessary with the context of the proposed PKI4IPSEC WG. - Added definition of Community Realm (used in 3.2.3.3) to the "Definitions" subsection. - Added definition of CRL Distribution Points (CDP) and Authority Info Access (AIA) to the "Definitions" subsection. - Restructured the "Architecture" section to bring the presentation of Figure 1 to the front to go along with the overview of the section, and to add a new step diagram to the "VPN-PKI Interaction" subsection. - Added a new subsection 2.1.2 to describe the VPN peer. Text of the new subsection will be supplied in a subsequent draft. - Added an editorÆs note to subsection 3.1.2 noting that further elaboration on the nature of "policy details" may be required. - Subsection 3.2 was deleted to maintain the focus on generic requirements agreed in Minneapolis. Selection of specific protocols will be done in the deliverable (3) profile. - Delete the requirement from 3.2.3.1 to include the maximum CRL size in the certificate template. This may need to be specified in the profile, but not be in the certificate itself. - Revised 3.3.3 to clarify that key escrow requirements and any key transport between the VPN admin and the peer are beyond scope. - Adopted consistent spelling "enrollment" vs. "enrolment" throughout. - Replaced instances of "and/or" and other slashed terminology with less ambiguous statements to clarify the requirements. - Revised the text of 3.5.1 to clarify the proposed requirement in terms of SHALL and MAY terms. Bonatti, Turner, Lebovitz 48 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile - Re-titled 3.5.2 as "Path Validation" instead of "Chaining". - Added AIA extension as a MAY requirement in 3.5.2. - Added an editorÆs note to subsection 3.5.3 to question whether additional keyUsage bits should be set in the certificate. - Removed the requirement for HTTP support in favor of a requirement for a single mandatory protocol to be specified in the profile. - Removed subsection on "Intra-IKE Considerations" as these should be dealt with in the existing deliverable (1) PKI profiles. - Deleted existing sections 5 and 6 dealing with the participating vendors in Project Dploy. - Added new section 4 on "Security Considerations". Text of the new subsection will be supplied in a subsequent draft. - Revised the "Acknowledgements" section to reflect this revision, and provide appropriate credit to Project DPloy. - Normalized "References" section with the ID-Nits promulgated by the IESG. - Added a stub for a proposed new Annex D to provide a requirements summary table. Content of the annex will be supplied in a subsequent draft. 2002-March Draft-dploy-requirements-00 - First public draft of the document released. Intellectual Property Statement 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. Bonatti, Turner, Lebovitz 49 Internet-Draft Requirements for an July 2005 IPsec Certificate Management Profile 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Expires February 20, 2006 Bonatti, Turner, Lebovitz 50