Internet Draft Chris Bonatti, IECA draft-bonatti-pki4ipsec-profile-reqts-00.txt Sean Turner, IECA January 30, 2003 Gregory Lebovitz, NetScreen Expires July 30, 2004 Requirements for an IPsec Certificate Management Profile Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [STDPROCESS]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This informational document describes and identifies the requirements for a profile of a certificate management protocol to handle Public Key Certificate (PKC) lifecycle interactions between Internet Protocol Secuity (IPsec) Virtual Private Network (VPN) systems using IKE (versions 1 and 2) and Public Key Infrastructure (PKI) systems. These requirements are designed so that they meet the needs of enterprise scale IPsec VPN deployments. It is intended that a standards track profile will be created that fulfills these requirements. Table of Contents 1. Introduction 3 1.1 Scope 4 1.2 Non-Goals 4 1.3 Definitions 5 1.4 Requirements Terminology 6 2. Architecture 6 2.1 VPN System 7 2.1.1 VPN Peer(s) 7 2.1.2 VPN Administration Function (Admin) 8 2.2 PKI System 9 2.3 VPN-PKI interaction 9 3. Requirements 11 3.1 General requirements 11 3.1.1 One Protocol 11 3.1.2 Secure Transactions 12 3.1.3 PKI Availability 12 3.1.4 End-User Transparency 12 3.1.5 Error Handling 12 3.2 Authorization Transactions 12 3.2.1 Bulk Authorization 12 3.2.2 Protocol Preferences for Authorization 13 3.2.3 Admin Authorization Requests to PKI 13 3.2.4 Cancel Capability 15 3.2.5 PKI response to Admin 15 3.2.6 Error Handling for Authorization Transactions 16 3.3 Key Generation and Certificate Request Construction 16 3.3.1 IPsec Peer Generates Key Pair and Constructs Request 16 3.3.2 IPsec Peer Generates Key Pair, Admin Constructs Request 17 3.3.3 Admin Generates Key Pair and Constructs Request 17 3.3.4 PKI Generates Key Pair and Passes to Peer via Admin 17 3.3.5 Trust Anchor Certificate Acquisition 17 3.3.6 Error Handling for Key Generation and Request Construction 18 3.4 Enrollment (Sending Request and Certificate Retrieval) 18 3.4.1 One protocol 18 3.4.2 On-line protocol 18 3.4.3 Single Connection with Immediate Response 18 3.4.4 Manual Approval Option 19 3.4.5 Enrollment Method 1: Peer Enrolls to PKI Directly 19 3.4.6 Enrollment Method 2: IPsec Peer Enrolls to PKI through Admin 19 3.4.7 Enrollment Method 3: Admin Enrolls to the PKI Directly 19 3.4.8 Enrollment Type Field 20 3.4.9 Confirmation Handshake 20 3.4.10 Failure Cases 20 3.5 Certificate Profile for PKI Interaction 21 3.5.1 Identity Usage 22 3.5.2 Path Validation 22 3.5.3 KeyUsage 22 3.5.4 Extended KeyUsage 22 3.5.5 Pointer to Revocation Checking 23 3.6 Certificate Renewals and Changes 23 3.6.1 Renew Request for a New Certificate (before expiry) 25 3.6.2 Change Request for a New Certificate 25 3.6.3 Error Handling for Renewal and Change 26 3.7 Finding certificates in repositories 26 3.7.1 Error Handling for Repository Lookups 27 3.8 Revocation Action 27 3.9 Revocation Checking and Status Information 28 3.9.1 Error Handling in Revocation Checking 28 4. Security Considerations 28 A. References 29 B. Acknowledgements 29 C. Editor's Address 29 D. Summary of Requirements 30 E. Change History 30 1. Introduction This document enumerates requirements for PKC management interaction among different IPsec VPN products and PKI products in order to better enable large scale, PKI-supported IPsec VPN deployments. Requirements for both the IPsec and the PKI products are discussed. The goal is to create a set of requirements from which a profile document will be derived. The specification will clarify the transactions necessary between the VPN system and the PKI system that enable the deployment of easily manageable, easily scalable VPNs. When implemented, the specification will enable improved interoperability between IPsec and PKI products. The requirements are carefully designed to achieve security without compromising ease of management and deployment, even where the deployment involves tens of thousands of IPsec users and devices. Within IPsec VPNs, the PKI supports authentication of peers through digital signatures during security association establishment using IKE. The protocol and PKI operational usages are considered in order to define a common, single set of methods (which forces interoperability) between PKI systems and VPN systems for large-scale deployments. The requirements address the entire lifecycle for PKI usage within IPsec transactions: pre-authorization of certificate issuance, enrollment process (certificate request and retrieval), certificate renewals and changes, revocation, validation and repository lookups. They enable a VPN Operator to: - Authorize individual or batches of certificate issuances based on locally defined criteria, and do so from the VPN Admin point - Provision PKI-based user or machine identity to VPN peers, on large scale. Provision means the IPsec peer ends up with a valid public and private key pair and PKC based on the IETF Public Key Infrastructure X.509 (PKIX) certificate profile. These are used in the IKE negotiation for tunnel setup. - Set the corresponding gateway or client authorization policy for remote access and site-to-site connections - Establish automatic renewal for certificates, or changes - Ensure timely revocation information is available for certificates used in IKE exchanges The desired outcome is that interoperable products would be created by both IPsec and PKI vendors to enable such scalable deployments, and do so as quickly as possible. For example, an IPsec operator should be able to use any conforming IPsec implementation of the certificate management profile with any conforming PKI vendor's implementation to perform the VPN rollout and management as described below. The certificate management profile will also clarify and constrain existing PKIX and IPsec standards and protocols for easier understanding and the limiting of complexity in deployment. Some new elements are identified that may require either a new protocol, or changes or extensions to an existing protocol, especially in the area of bulk authorization for certificate issuance. The document introduces the idea of a VPN administration function (Admin) within the VPN system. This Admin function bears great responsibility for the task of managing pre-authorization for certificate issuance and of distributing the results between the VPN system and the PKI system. 1.1 Scope The solution described in this document focuses on the requirements for the interaction between the VPN system and the PKI systems. The internals of the operation of these systems are beyond scope. The solution focuses on the needs of large-scale rollouts, i.e. VPNs including hundereds or thousands of managed VPN gateways or VPN remote access clients. The needs of small deployments are a stated non-goal, however service providers employing the scoped solution and applying it to many smaller deployments in aggregate may address them. Gateway-to-gateway access and end-user remote access (to a gateway) are both covered. End to end communications are not necessarily excluded but are intentionally not a focus. We do not intend to discuss all or other PKI issues here. The scope is limited to requirements for easing and enabling scalable IPsec with PKI deployments. The requirements strive to meet eighty percent of the market needs for large-scale deployments. Environments will understandably exist in which large-scale deployment tools 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. 1.2 Non-Goals The scenario for certificate cross-certification will not be addressed. The specification for the communication method and transactions between Admin and peers is up to vendor implementation and therefore is not expected to be included in the certificate management profile. Such a protocol may be standardized at a later date to enable interoperability between Admin stations and IPsec Peers from different vendors, but is far beyond the scope of this current effort, and will be considered opaque by the certificate management profile. 1.3 Definitions VPN System The VPN System is comprised of the VPN Admin function (defined below), the IKE peers, and the communication mechanism between the Admin and the peers. VPN System is defined in more detail in section 2.1. PKI System The PKI System is the set of functions needed to authorize and issue certificates and provide revocation information about those certificates. PKI System is defined in more detail in section 2.2. (VPN) Operator The person or group of people that define security policy and configure the VPN system to enforce that policy. IPsec Peer (Gateway or Client) For the purposes of this document, an IPsec Peer--or simply "peer"--is any IPsec system 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 system can pass traffic with no IPsec protection, and can add IPsec protection to chosen traffic streams. (VPN) Admin The function of the VPN System that manages and distributes policy to Peers and who interacts with the PKI System to define policy for Certificate provisioning for the VPN connections. See Section 2.1.1 below for more details. End Entity An end entity is the entity or subject that a Certificate exists to authenticate. The end entity is the one entity that will finally use a private key associated with a Certificate to sign data. In this document, the end entity is also an IPsec Peer. Community Realm The set of IPsec peers and VPN admin that operate under a common policy, and PKI authorizations. Certificate Renewal The acquisition of a new certificate (often accompanied by a new key) due to the expiration of an existing certificate. Renewal occurs prior to the expiration of the existing certificate to avoid any connection outages. Certificate Change A special case of a renewal; like occurrence where a certificate needs to be changed prior to expiration due to some change in its subject's information. Examples might include change in the address or identifying information of the end entity. Registration Authority 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 certificate. Certificate Authority An authority in a PKI system trusted by one or more users to create and assign public key certificates. It is important to note that the CA is responsible for the public key certificates 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 certificates 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 time stamped list identifying revoked certificates that is signed by a CA and made freely available in a public repository. Peers retrieve the CRL to verify that a certificate being presented to them as identity in an IKE transaction has not been revoked. CRL Distribution Point (CDP) The CRL distribution point extension in a certificate identifies the location from which end entities should retrieve CRLs for perform local validity checking. Authority Info Access (AIA) The authority information access extension in a certificate indicates how to access CA information and services for the issuer of the certificate in which the extension appears. Information and services may include on-line validation services and CA policy 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]. 2. Architecture This section describes the overall architecture for a PKI-supported IPsec VPN deployment, which is depicted in Figure 1 below. First an explanation of the VPN System is presented. Second, key points about the PKI System are stated. Third, the architecture picture is presented. Last, the process of the interaction between the two systems for large scale deployment is described. +---------------------------------------------+ | PKI System | | | | +--------------+ | | | Repository | +----+ +----+ | | | Certs & CRLs | | CA | | RA | | | +--------------+ +----+ +----+ | | | +---------------------------------------------+ ^ ^ ^ | | | |[E] |[A] |[E] |[M] |[E] |[M] |[R] | |[R] | | | +--------+------------------+----------------+------+ | | v | | | | +----------+ | | | | [G] | VPN | [G] | | | | +---------->| Admin |<-------+ | | | | | | Function | | | | | | | +----------+ | | | | v v v v | | +---------+ +---------+ | | | VPN | [I] | VPN | | | | Peer 1 |<=======================>| Peer 2 | | | +---------+ +---------+ | | | | VPN System | +---------------------------------------------------+ [A] = Authorization [G] = Generation of public and private key pair, certificate request [E] = Enrollment (request and retrieval) [I] = IKE and IPsec communication [M] = Maintenance: validation, revocation, lookups [R] = Renewal (and changes) Figure 1. Architectural Framework for VPN-PKI Interaction 2.1 VPN System The VPN System consists of the IPsec Peers and the Admin. 2.1.1 VPN Peer(s) The Peers are two entities between which the Operator requires an IPsec tunnel establishment. Two Peers are shown in Figure 1, but implementations MAY support an actual number in the hundreds or thousands. The Peers could be either gateway-to-gateway, remote-access-host-to-gateway, or a mix of both. The peers authenticate themselves in the IKE negotiation using digital signatures through 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 solution. The Admin is a centralized function. It defines the VPN system policy and informs the PKI and peers how it wants each to enforce that policy. One main role defined here is that Admin specifies to the PKI the contents and use parameters of the credentials the PKI will issue, or at least references a template or policy-set for a peer or set of peers. In this way Admin MAY perform many RA-like functions, for example authorization of certificate issuance and revocation. It is important to note that, within this document, 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 may be performed on a stand alone work station, on a gateway, on an administration software component, etc. It is also possible for the Admin function to be one in the same as the gateway or client device or software. They are represented in the architectural diagram below as different functions, but they need not be different physical entities. As such, Admin's architecture and the means by which it interacts with the participating VPN Peers will vary widely from implementation to implementation. However some basic functions of the Admin are assumed. - It will be the place where certificate policy for use in the VPN is defined, not the PKI. In VPN Systems the Operator chooses to strengthen the VPN by using PKI; PKI is a bolt-on to the VPN system. The certificate characteristics and contents are a function of the local security policy the VPN serves to enforce. Therefore the Operator will configure policy and contents for certificates in the Admin, and apply those templates to groups of IPsec peers. - It will interact directly with the PKI system to initiate authorization for end-entity certificates by sending the parameters and contents for those certificates, or by referring to a template or policy-set on the PKI. (Such templates would likely have been created in conjunction with the VPN Operator.) It will receive back from the PKI identification values and authorization codes to be used in the certificate requests for each of the pre-authorized certificates. - It will deliver instructions to the IPsec Peers, and the Peers will carry out those instructions. An example of such an instruction is an IKE policy configuration. Therefore, the communication mechanism between the Admin and the IPsec peers MUST be private, authenticated and employ integrity checks. The contents of some such instructions will be defined below. However, the communication mechanism will be handled completely within the VPN System and is out of the scope of this document (see Scope, Section 1.1 above). The Admin MUST be reachable by the Peers. Most implementations will meet this requirement by ensuring the Peer can connect to the Admin from anywhere on the network or Internet. However, communication between the Admin and Peer may not necessarily be "on-line". It may, in some environments, be "moving media," i.e. the configuration or data may be loaded on to a floppy disk or other media and physically moved to the IPsec Peer. This reality should be considered when requirements are defined, and when supporting networks are architected. 2.2 PKI System The PKI system may be set up and operated by the VPN Operator (in-house), may be provided by third party PKI providers to which connectivity is available at the time of provisioning (managed PKI service), or may be integrated with the VPN product. This framework assumes that all components of the VPN will obtain certificates from a single PKI community. An IPsec peer MAY accept a certificate from a peer that is from a CA outside of the PKI community, but the auto provision and life cycle management for such a certificate or its trust anchor certificate fall out of scope. The PKI System will contain a mechanism for handling Admin's authorization requests and certificate enrollments. These mechanisms are referred to as the Registration Authority (RA) below. The PKI system contains a Repository used by the Peers to look up each others certificates. Last, the PKI System contains the core function of a Certificate Authority (CA) that uses a public and private key pair and signs certificates. The PKI system SHOULD be built so that lookups resolve directly and completely at the URL indicated in a CRL Distribution Point, or Authority Info Access. 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 may cause implementations to timeout. 2.3 VPN-PKI interaction The interaction between the VPN system and the PKI systems is the key focus of this requirements document. It is therefore sensible to consider the steps necessary to set up, use and manage certificates for one VPN peer to establish an association with another peer. Figure 2 (below) illustrates the information flow associated with the steps relative to the architecture diagram. For simplicity only the steps associated with VPN Peer 1 are shown. +--------------+ +------------------------------+ | | 6 | | | Repository |<-----| Certificate Authority | | | | | +--------------+ +------------------------------+ | ^ | ^ | ^ | ^ | | | | | | | | | | +----+ | 11 | | | | | | 12 | | | | | | | | | +----+ 5 | | 4 | | | | 7 | | | | | | | | | | +---------+ | 2 | | 1 8 | +------+ | | | | | | | | | | | +---------+ v | +------+ | | | | | +----------+ | | | | | | 3 | | | | | | | | +------------| VPN | | | | | | | | | Admin | | | | | | | | +---------| Function | | | | | | | | | 10 | | | | | | | | | | +----------+ v | v | v | v v +-------------------------+ +--------+ | VPN | 9 | VPN | | Peer 1 |<===========>| Peer 2 | +-------------------------+ +--------+ Figure 2. VPN-PKI Interaction Steps The steps of the VPN-PKI interaction are summarized here. The letters refer to Figure 1. The numbers refer to Figure 2. The detailed requirements are described below in Section 3. 1) Authorization [A]. Admin sends a list of IDs and certificate contents for the PKI systems to authorize enrollment. The PKI returns a list of unique identifiers and one-time tokens to be used for the enrollment of each certificate. Other certificate usage policy is also set at this time, for example parameters for renewals or changes, key lengths, etc. The amount of information that the Admin communicates to the PKI about how it wants the certificates built could be very small, perhaps just a reference to a template already existing in the PKI system. Likewise it could be very large, with several fields being specified along with their contents. [EDITOR'S NOTE: We need some work on this line of thought.] 2) Authorization Response [A]. The PKI system acknowledges the authorizations provided in (1). Response may indicate success or failure for any particular authorization. 3) Generate Keys and Certificate Request [G]. The Admin communicates with the Peer to either give it information so that it can generate a public and private key pair and certificate request and send the request directly to the PKI, or to give them a key pair and certificate request that the Peers can send to the PKI. In some cases, the Peers MAY generate the key pair and certificate locally, then send the certificate request back to the VPN Admin Station who will send the request to the PKI System for them (more about these options will be discussed in section 3.3 below) 4) Enrollment [E]. The VPN Peer requests a certificate from the PKI, providing the generated public key. The key pair and certificate request will either be provided in (3) above, or generated by the VPN Peer. 5) Enrollment Response [E]. The PKI responds to the enrollment request sent in (4), providing either the new certificate that was generated or a suitable error indication. Peer must positively acknowledge receipt of new certificate. 6) Certificate Posting. The newly-generated certificate for VPN Peer 1 is posted to the certificate repository. 7) Maintenance [M]. The VPN Peer accesses the PKI to support look-up of certificates for other VPN peers, certificate path validation, and revocation checking. This step consists of sending requests for specific certificates or CRLs, or requests for the PKI system to perform validation checks. 8) Maintenance Response [M]. The PKI responds to the maintenance request sent in (7), providing either the requested certificate or CRL, indicating the validity status of a certificate, or indicating an error condition. 9) IKE/IPsec Communication [I]. The Peers communicate authenticated by the certificates they received from the PKI. 10) Rekey or Renewal Initiation. The Admin station communicates renewal or change instructions to the Peers. Renewal may also be signalled to the PKI (not shown), particularly if authorization changes are necessary. Initiation of this process by the Admin enables VPN Peers to automatically generate renewal or change requests as needed with minimal user burden, and for those requests to be immediately granted by the PKI System. 11) Renewals and Changes [R]. The VPN Peer requests renewal or change of an existing certificate. Rekey MAY also occur depending upon policy constraints. The renewal or change request will either be provided in (10) above, or will be generated by the VPN Peer. 12) Renewal/Change Response [R]. The PKI responds to the renewal or change request sent in (11), providing either the new certificate that was generated or a suitable error indication. Steps not shown in the illustration include VPN Peers or the Admin can also communicate with the PKI to revoke a certificate if keys have been compromised. Also not shown in is the re-posting of the renewed certificate after step (12). 3. Requirements 3.1 General requirements 3.1.1 One Protocol This target profile will call for ONE PROTOCOL or ONE USE PROFILE for each main element of the requirements. It is a specific goal to avoid multiple protocols or profiles to solve the same requirement whenever possible so as 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. Conforming implementations MUST implement the ONE PROTOCOL or ONE USE PROFILE that is specified for a given requirement. 3.1.2 Secure Transactions The target profile will specify the transactions for certificate management between VPN and PKI systems and their components, as needed to ease large scale VPN deployment and management. Specifically, Admin and PKI will transmit between themselves policy details, identities and keys. As such, the method of communication for these transactions MUST be secured in a manner that ensures privacy, authentication, message data integrity and non-repudiation. This method will require that mutual trust be established between the PKI and the VPN Admin. [EDITOR'S NOTE: Need to perhaps elaborate on "policy details" above.] 3.1.3 PKI Availability Central availability is required initially for authorization transactions between the PKI and Admin. Further availability will be required in most cases, but is a decision point for the operator. Most requirements and scenarios below assume on-line availability of the PKI system and Admin for the life of the VPN. Off-line interaction between the VPN and PKI systems (i.e., where physical media is used as the transport method) is beyond the scope of this document. 3.1.4 End-User Transparency PKI interactions are to be transparent to the user. Users need not even be aware that PKI is in use. First time connections need consist of no more than a prompt for some identification and pass phrase, and a status bar notifying the user that setup is in progress. 3.1.5 Error Handling The certificate transaction protocol for the PKI and VPN system transactions MUST specify error handling for each transaction. Thorough error condition descriptions and handling instructions will greatly aid interoperability efforts between the PKI and IPsec products. 3.2 Authorization Transactions 3.2.1 Bulk Authorization The Admin requests of the PKI that authorization be established for several different subjects with almost the same contents. A minimum of one field (more is also acceptable) MUST differ per subject. Because the authorization may occur before any keys have been generated, the only way to determine one authorization from another for the purpose of issuing unique identifiers is by having at least one field differ. The authorization MAY occur prior to the event of a certificate enrollment request (in which case it is a "pre-authorization"), or within the same connection. 3.2.2 Protocol Preferences for Authorization A single connection per multiple transactions. It is preferred that the setup for all subjects in an authorization batch occurs in one single connection to the RA/CA, with the number of subjects being one or greater. Implementations should be able to handle tens of thousands at a time. ONE protocol must be specified for these VPN Administration to RA/CA interaction. The PKI responds to the VPN Administration station with Authorization identifiers (maybe serial numbers or such) and a corresponding pre-authorization key (not to be confused with the public and private key pair) for each identifier. It is preferred that the transport used to carry the pre-authorization be reliable (TCP). The protocol should be as lightweight as possible. A method for securing the communication between the Admin and the PKI MUST be defined, including privacy, authorization, and integrity. Certificates and authorization of the VPN Admin may need to be initialized by physical rather than on-line means. 3.2.3 Admin Authorization Requests to PKI 3.2.3.1 Specifying Fields within the Certificate The VPN may send the PKI System the set of certificate contents that make up a certificate template that it wants the PKI to use. In other words, it tells the PKI System, "if you see a certificate request that looks like this, from this person, process it and issue the certificate." Likewise, such a template may have already been defined on the PKI System, and the Admin may simply reference it. In the former case, the elements that the VPN Admin MAY send to the PKI to authorize the eventual creation of certificates include: - DN fields - Any number of locally defined CNs with their contents [EDITOR'S NOTE: this is difficult to do. We may need to say just one CN.] - Validation Period of the Certificate - Renewal parameters (i.e. N% of validity period, and certificate overlap duration in N [EDITOR'S NOTE: Should consider other factors. Measurement? Minutes? Hours? Percentage?], or just let it expire) - Any of SubjAlt fields - Key type - key length - Any of the extension fields (Key usage, extended key usage, Policy constraints, etc.) - Require a CDP be filled in by the PKI in issuance. The specification should define who will handle the CDP contents. Suggest the PKI, not Admin, but further research is needed. 3.2.3.2 Authorizations for Renewal and Change When the Admin sends its authorization request information it MUST also send information to the PKI about the local policy regarding renewal and changes. These are: - Admin MUST specify if automatic renewals are allowed, that is, the Admin is presently authorizing the PKI to process a future renewal for the specified end-entity certificate. - Admin MUST specify if any changes are allowed, that is, the Admin is presently authorizing the PKI to accept a future request for a new certificate creation with some element of the Subject or SubjectAlt changed. If a renewal is authorized, the Admin MUST further specify: - Whether or not a new key must be used for the new certificate. - Who can renew, i.e. can only the admin send a renewal request or can the end-entity Peer send a request directly to the PKI, or either. - Specify at how long before the certificate expiration date the PKI will accept and process a renewal. - Length of time (if ever) after PKI receives end entity peer confirmation (see 3.4.8 and 3.6.1 below) that the old certificate is revoked, and removed from repository. If change request is authorized, the Admin MUST further specify: - The fields in the Subject and SubjectAltName that are changeable - The entity that can send the change request, i.e. only the Admin, only the end entity, or either. - Length of time (if ever) after PKI receives end entity peer confirmation (see 3.6.1 below) that the old certificate is revoked, and removed from repository. 3.2.3.3 Other authorization elements CDP MUST be flagged as required in the authorization request. The method MUST also be specified; HTTP is the MUST method, LDAP is MAY. There will be an option to specify a Validation Period for the authorization ID and its one-time-key. If such a Validation Period is set, any requests using this authorization id and key that arrive outside of the validation period MUST be dropped and the event logged. Ability to communicate the Community Realm for the certificate to the PKI. Community Realm is an important component in provisioning that allows the Admin to specify for the Peer various elements of the certificate's contents that the PKI will fill in, and are not defined by the Admin. It may be used to specify various local policy definitions. It also will be used to label different groups to have different CRLs (for example small CRLs with only gateways in the listing for use by Remote Access peers, or large CRLs with all Remote Access peers and gateways to be used by the Gateways). There will be a need for an import and export for easily synchronizing the Community Realm lists between the Admin and PKI systems. The Protocol should consider what happens when Admin requested information conflicts with PKI settings such that the Admin request cannot be issued as requested. (Ex: 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 Cancel Capability Admin can send a cancel authorization message to PKI. [EDITOR'S NOTE: Should the peer be able to send a cancel message as well?] Admin MUST provide the authorization ID and code 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 with the Admin (a Cancel, Cancel ACK, ACK type of a process is required to cover a lost connections scenario), the PKI will accept another Authorization request with the exact same contents as the canceled one. The PKI MUST NOT accept a second authorization request for the same identity [EDITOR'S NOTE: How do we decide what defines "identity"?] if one already exists. 3.2.5 PKI response to Admin If the authorization is acceptable, the PKI will respond to the Admin with a unique identifier per subject authorization required and a one-time-authorization key per authorization ID. Strongly recommend the one-time-authorization key be unique per authorization ID. The more randomness that can be achieved in the relationship between an identifier and its key the better. The key MUST be in ASCII format to avoid incompatibilities that may occur due to international characters. All the contents of the certificate that it intends to issue will be returned to the Admin. This will allow the Admin to perform an "operational test" to verify that the issued certificates will meet its requirements. For any request, the PKI cannot change any of the specified values in request within its response. We need to prevent a change in certificate contents that may occur due to a change in PKI configuration right in the middle of a batch pre-authorization request. [EDITOR'S NOTE: what if the VPN admin sends a parameter that the PKI cannot fulfil, i.e. the parameter contradicts PKI policy? Would need to return an error code and description and refuse to authorize the enrollment.] After receiving a bulk authorization request from the Admin, the PKI must be able to reply YES to those individual certificate authorizations that it can satisfy and NO or FAILED for those requests that cannot be satisfied, along with sufficient reason or error codes. A method is needed to identify if there is a change in PKI setting between the time the authorization is granted and certificate request occurs, and what to do about the discrepancy. 3.2.6 Error Handling for Authorization Transactions Thorough error condition descriptions and handling instructions are required for each transaction in the authorization process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products. 3.3 Key Generation and Certificate Request Construction Once the PKI System has responded with authorization identifiers and keys, and this information is received at the Admin, the next step is to generate public and private key pairs and to construct certificate requests using those key pairs. The key generations MAY occur at one of two places, depending on local requirements: at the IPsec Peer or at the Admin. The certificate constructions MAY occur at either the IPsec Peer or a combination of the Peer and the Admin. 3.3.1 IPsec Peer Generates Key Pair and Constructs Request This case will be used most often in the field. This is the most secure method for keying; the keys are generated on the end entity and never leave the end entity. The Admin will send the authorization identifier and authorization key to the end entity, the IPsec Peer. The Admin will also send any other parameters needed by the Peer to generate the certificate request, including key type and size. Recall that the mechanism for how this information is communicated from the Admin to the Peer is opaque. Receiving the command and the necessary information from the Admin, the Peer will proceed to generate the key pair and construct the certificate request. 3.3.2 IPsec Peer Generates Key Pair, Admin Constructs Request In this case, the Admin sends a command to the peer to generate the key pair. The Admin then constructs the certificate request on behalf of the peer, except for the signing. It sends the construction to the peer for signing, and the peer returns the signed request construction back to the Admin. The Admin then proceeds to enroll on behalf of the client. The advantage of this solution is that the private key never leaves the IPsec Peer, but limits the amount the Peer must know and do regarding certificate generation. 3.3.3 Admin Generates Key Pair and Constructs Request The use case exists for deployments where end entities 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 certificates are used for other functions in addition to IPsec, and key recovery is required (e.g. local data encryption), therefore key escrow is needed off the end-entity station. If key escrow is performed then the exact requirements and procedures for it are beyond the scope of this document. The Admin will generate the key pair, construct the certificate request, and enroll on behalf of the Peer. Once the certificate has been retrieved, the keys and certificate will be sent to the Peer using a secure method. The nature of this secure method is beyond the scope of this document. Performing a separate pre-authorization step is still of value even though the Admin is the also performing the key generation. The Community Realm, Subject fields, SubjectAlt fields and more are part of the request, and must be communicated in some way from the Admin to the PKI. Instead of creating a new mechanism, we simply use the pre-authorize schema again. This also allows for the feature of role-based administration, where Operator1 is the only one allowed to have the Admin function pre-authorize certificates, but Operator2 is the one doing batch enrollments and VPN device configurations. 3.3.4 PKI Generates Key Pair and Passes to Peer via Admin TBD - [EDITOR'S NOTE: There is another use case here: PKI generates the key pair AND the certificate and simply hands it down to the Admin for installation into the Peer. This is, in all likelihood, the easiest way to deploy Certs, though sacrafices a bit in security. Do we just specify PKCS12 and try to create some requirements for how the Admin will say, "I need a cert for NNNNN," and how PKI will respond with the PKCS12?] 3.3.5 Trust Anchor Certificate Acquisition The root certificate MUST arrive on the peer via one of two methods: (a) Peer can get the root certificate 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.3.6 Error Handling for Key Generation and Request Construction Thorough error condition descriptions and handling instructions are required for each transaction in the authorization process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products. 3.4 Enrollment (Sending Request and Certificate Retrieval) Regardless of where the keys were generated and the certificate request constructed, an enrollment process will need to occur to request a certificate creation from the PKI and to retrieve that certificate. The protocol MUST be exactly the same regardless of whether the enrollment occurs from the Peer to the PKI or from the Admin to the PKI (as seen below in sections 3.4.5 through 3.4.7). 3.4.1 One protocol One protocol MUST be specified for both request and retrieval. 3.4.2 On-line protocol The protocol MUST supports automated enrollment that occurs over the Internet and without the need for manual intervention. 3.4.3 Single Connection with Immediate Response Request and retrieval MUST be able to occur in one on-line connection between the end-entity and the PKI (RA/CA). The end entity sends the request, attaching the Authorization identifier and key. The RA/CA receives the request and uses the Authorization identifier and key to match it to the proper pre-authorization entry. Since the contents of the certificate match, and the Authorization identifier and key are correct, the certificate is generated immediately, with no need for manual intervention or review on the PKI system before issuance. The PKI makes the certificate available immediately for retrieval, or possibly sends the certificate to the end entity as a response in the request or retrieval exchange. 3.4.4 Manual Approval Option The optional capability to queue and manually approve certificate requests MUST exist within the protocol for those organizations that will not permit automation of credential issuing as described above. Likewise, polling to determine if request has been satisfied and to try to retrieve the certificate MUST exist within the protocol for those organizations that will not permit automation of credential issuing as described above. End-entities and the PKI must disclose and agree upon which mode they will support (automated approval or manual approval) within the protocol. 3.4.5 Enrollment Method 1: Peer Enrolls to PKI Directly The enrollment MAY occur in one of three fashions, and valid use cases exist for all three. First, and most straight forward, the Admin can instruct the IPsec Peer to execute an enrollment, telling it where to enroll, and providing any necessary parameters. In this case the IPsec Peer only talks to the PKI after being commanded to do so by the Admin. 3.4.6 Enrollment Method 2: IPsec Peer Enrolls to PKI through Admin In this case, the IPsec Peer has generated the key pair and the certificate request, but does not enroll directly to the PKI system. Instead, it automatically sends its request to the Admin, and the Admin automatically performs the enrollment to the PKI system. The PKI System does not care where the enrollment comes from, as long as it is a valid enrollment. Once the Admin retrieves the certificate, it then automatically forwards it to the IPsec Peer, and the peer can begin using it in security policy. The communication of the request, retrieval, renewal, or change, can go directly from the end-entity to the PKI, or be passed from end-entity through the admin to the PKI. In the latter case, the end-entity need not know how to do all the direct communication with the PKI; the function becomes focused in the Admin station. In either case, the format of messages should be identical regardless of who is sending the request. Most IPsec systems have enough CPU power to generate a public and private key pair of sufficient strength for secure IPsec. In this case, the end entity needs to prove to the VPN Admin that they have such a key pair; this is normally done by the VPN Admin sending the end entity a nonce, which the end entity signs and returns to the VPN Admin along with the end entity's public key. 3.4.7 Enrollment Method 3: Admin Enrolls to the PKI Directly In this instance, the Admin is performing a function similar to that of a Registration Authority (RA), as defined in [CERTPROFILE]. The Admin will have likely generated the key pair and constructed the request on behalf of the IPsec Peer. It proceeds to handle the entire enrollment directly with the PKI, and returns to the IPsec Peer the final product of a key pair and certificate. Again, the mechanism for the Peer to Admin communication is opaque. 3.4.8 Enrollment Type Field A field must exist in the request to specify the TYPE of request being made. Request types include new request, renew request, and change request (renewals and changes are discussed in detail in section 4.6). The type field is required for monitoring, logging and auditing purposes. They will help the operator to know exactly what type of request was made so that suspicious activities, even if the request is denied, can be identified. 3.4.9 Confirmation Handshake Any time a new certificate is issued by the PKI, a confirmation must be sent back to the PKI. This is true for first time issuances, renewals, and changes alike. Operationally, the Peer MUST send a confirmation to the PKI verifying that the end-entity has received the certificate, loaded it, and can use it effectively in an IKE exchange. This requirement exists so that: - The PKI does not publish the new certificate in the repository for others until that certificate is able to be used effectively by the Peer, and; - A revocation may be invoked if the certificate 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 the end entity peer that it may proceed using this certificate in IKE connections. The PKI MUST complete all processing necessary to enable the end entity's operational use of the new certificate (for example, writing the certificate to the repository) before sending the confirmation acknowledgement. The PKI MUST also issue a revoke on the original certificate before sending the confirmation ACK (see section 4.X). The end entity peer MUST NOT begin using the certificate until the PKI's confirmation acknowledgement has been received. 3.4.10 Failure Cases 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 must clarify what happens if the request and retrieval fails for some reason. The following cases will 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 certificate - The PKI system generated the certificate, but could not send it - The PKI sent the certificate, but the requestor (Admin or Peer) did not receive it - The Requestor (Admin or Peer) received the certificate, but could not process it due to incorrect contents, or other certificate-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 certificate and before the peer receives it, then the peer MUST re-request with the same Authorization ID and one-time-key, and the PKI, seeing the ID and key, MUST send the certificate again. 3.5 Certificate Profile for PKI Interaction A certificate used for identity in IKE transactions MUST include all the X509v3 mandatory fields. It must also contain the minimal contents necessary for path validation and chaining (these items will be enumerated in the profile). It is preferable that the certificate profiles for IPsec and certificate management were the same so that one certificate could be used for both protocols. If the profiles are inconsistent then different certificates (and perhaps different processing requirements) might be required for certificate management transactions vs. IKE transactions. However, failure to achieve this requirement in the profile MUST NOT hold up the standardization effort. 3.5.1 Identity Usage The VPN Peer SHALL perform identity verification based on the fields of the certificate and parameters applicable to the VPN tunnel. The fields of the certificate used for verification MAY include either the X.500 Distinguished Name (DN) within the Subject Name, or a specific field within the Extension SubjectAlternativeName (per [DOI] 4.6.2.1 Identification Type Values). Usage descriptions for each follow. The certificate field(s) that will be used for identity verification MUST be included in the certificate request by the Admin or the Peer. In addition to the DN, the following identity-related values may be included in the SubjectAltName: - Fully-Qualified Domain Name (FQDN) - RFC 822 (also called USER FQDN) - IPv4 Address - IPv6 Address While substrings of these identity values may also be present in elements of the DN, they will not be looked for in the DN, only in SubjectAltName. 3.5.2 Path Validation The Peers must validate the certificate path. The contents necessary in the certificate to allow this will be enumerated in the profile document. The peer MAY have the ability to construct the certificate path itself, however Admin MUST be able to supply peers with the trust anchor and any chaining certificates necessary. The Admin MAY include the AIA extension in certificates as a means of facilitating path validation. DNS SHOULD be supported by the Peers in order to do certificate path lookups, as well as those for revocation. 3.5.3 KeyUsage The certificate's KeyUsage digialSignature bit [CERTPROFILE] MUST be flagged on. [EDITOR'S NOTE: Shouldn't the non-repudiation bit also be required? It's in the stated requirements, and PKIX treats it separately. Also check whether the key exchange or key agreement bits should be required. These are employed by both CMC and IPsec.] 3.5.4 Extended KeyUsage EKU's are not required. The presence or lack of an EKU MUST NOT cause an implementation to fail an IKE connection. Default behavior is to not check EKU. However, your local security policy MAY check EKU, and if so the implementation SHOULD allow the acceptance or rejection based on the presence of each EKU. Those EKUs are defined as: - serverAuth, - clientAuth, or an IKE specific EKU which are defined as one of the four currently issued IANA EKU's: - IPsec user, - IPsec computer, - IPsec intermediate, - IKE IPsec intermediate. 3.5.5 Pointer to Revocation Checking The certificate contents must be constructed in a manner such that any peer who hold the certificate locally will know exactly where to go and how to request the CRL. The location and method for either a CDP or an AIA [CERTPROFILE] MUST be included in the certificate. Including such contents avoids the need to send the CRL to the peer, and allows the receiving peer to look up the CRL on their own. Certificates MUST contain the full name of the CDP and AIA. Issuer-relative names are not considered sufficient. 3.6 Certificate Renewals and Changes In order to allow for continued certificate usage, a new certificate will need to be issued for an end-entity before the end entity's currently held certificate expires. A renewal is defined as a new certificate issuance with the same SubjectName and SubjectAlternativeName contents as an existing certificate for the same end entity before expiration of the end entity's current certificate. A change is defined as a new certificate issuance with an altered SubjectName or SubjectAlternativeName for the same end-entity before expiration of the end-entity's current certificate. Renewals and changes are variants of a certificate request scenario with unique operational and management requirements. Once the PKI has issued a certificate for the end entity Peer, the Peer MUST be able to either contact the PKI directly or through the Admin for any subsequent renewals or changes. The PKI MUST support either case. It is desired that a renew or change request contain an element that identifies the request as either type=renewal, or type=change. This element MUST be specified in the profile. This will allow for better management, logging and auditing of certificate management. When sending a renew or change request, the entire contents of the certificate request needs to be sent to the PKI, just as in the case of the original enrollment. Keeping the request format as similar as possible between new, renewal, and change cases will make for easier implementations; e.g. the format of the request is identitical except for a type=[renew | change] instead of type=new. The renew and change requests MUST be signed by the private key of the old certificate. 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 certificate with another end entity's identity. Whether or not a new key is used for the new certificate in a renew and change 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 change 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 certificate. [EDITOR'S NOTE: Is there a way to do this?] The new certificate resulting from a renew or change will be retrieved in-band, using the same mechanism as a new certificate request. For the duration of time after a renew or change has been processed and before PKI has received confirmation of the peer's successful receipt of the new certificate (as described above in section 3.4.9), both certificates--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 certificate while the renewal process occurs. In the case where new keys were generated for a renew or change request, once the end entity peer receives the confirmation acknowledgement from the PKI, it is good practice for the old key pair be destroyed as soon as possible. Deletion of the keys and the certificate can occur once all connections that used the old certificate have expired. After the renew or change occurs, the question now exists for the PKI of what to do about the old certificate. If the old certificate is to be made unusable, the PKI will need add it to the revocation list and removed from the repository. The decision about if the old certificate should be made unusable is a decision of local policy. Either the PKI or the Admin will need to 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 certificate) that will pass before the old certificate is made unusable. If a certificate has been revoked, it MUST NOT be allowed a renew or change. Should the certificate expire without renewal or change, an entirely new request MUST be made. 3.6.1 Renew Request for a New Certificate (before expiry) VPN Operators may choose to force renewals for several reasons: - To enforce an automated "clean up" of unused certificates that have not been specifically revoked - To force re-keys - To have manual review control over re-issuance. In the latter case, automated renewals will likely not be used. In the former two cases automated renewal is a very attractive option. 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.3.2 above. The renewal request MUST match the conditions that were specified in the original authorization for: - Keys: new or existing or either - Requestor: End-entity Peer, Admin, either - Renewal Period - Length of time before making the old certificate unusable If any of these conditions are not met, the PKI must reject the renewal and log the event. 3.6.2 Change Request for a New Certificate A change in contents will be necessary when details about an end entity peer's identity change, but the Operator does not want to generate a new certificate 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. A Change differs from a Renew in a few ways: - A re-key is not necessary (though MAY be specified) - The timing of the Change event is not predictable, as is the case with a scheduled renewal - The change request may occur at any time during a certificate's period of validity - Once the Change is completed, and the new certificate is confirmed, the old certificate should cease to be usable, as its contents no longer accurately describe the subject - The existence of a "change" type allows for better logging and tracking of why the new issuance occurred, and why the old certificate was made unusable. At the time of authorization, certain details about change acceptance MAY be conveyed by the Admin to the PKI, as stated in section 3.2.3.2 above. The change request MUST match the conditions that were specified in the original authorization for: - Keys: new or existing or either - Requestor: End-entity Peer, Admin, either - The fields in the Subject and SubjectAltName that are changeable - Length of time before making the old certificate unusable If any of these conditions are not met, the PKI must reject the renewal. If a Change authorization was not made at the time of original authorization, one may be made from Admin to the PKI at any time during the certificate's valid life. When such a Change is desired, Admin must notify the PKI system that a chance is authorized for the end-entity, and to expect it coming, and specify the new contents. Admin then initiates the Change 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). 3.6.3 Error Handling for Renewal and Change Thorough error condition descriptions and handling instructions are required for each transaction in the renew or change process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products. 3.7 Finding certificates in repositories The complete hierarchical validation chain (except the trust point) MUST be able to be searched in their respective repositories. The information to accomplish these searches MUST be adequately communicated in the certificates sent during the IKE transaction. All certificates 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 directory on a specific ID element that was given to it in a standard certificate field. Other considerations include: -relative speed -relative ease of administration -scalability Intermediate certificates will be needed for the case of re-keying of the CA, or a system where multiple CAs exist. Certificates MAY have extendedKeyusage to help identify the proper certificate for IPsec, though the default behavior is to not use them. See the above section on extendedKeyusage. IPsec peers MUST be able to resolve Internet domain names and support the manadatory repository access protocol at the time of starting up so they can perform the certificate lookups. IPsec peers should cache certificates 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 certificates are not sent in IKE is a stated non-goal of the profile at this time. 3.7.1 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.8 Revocation Action The peer MUST be able to initiate revocation for its own certificate. In this case the revocation request MUST be signed by the peer's current key pair for the certificate 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 certificate for which it authorized the creation. The Admin will identify itself to the PKI by use of its own certificate; it MUST sign any revocation request to the PKI with the private key from its own certificate. The PKI MUST have the ability to configure Admin(s) with revocation authority, as identified by its certificate. Any certificate authorizations must specify if said certificate 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 certificate revocation during a renew transaction. PKI MUST revoke the certificate after receiving the confirm notification from the peer, and before sending the confirm-ack to the peer. The peer MUST NOT revoke its own certificate in this case. - AFTER CHANGE, BEFORE EXPIRATION: The PKI MUST be responsible for the certificate revocation during a change transaction. PKI MUST revoke the certificate after receiving the confirm notification from the peer, and before sending the confirm-ack to the peer. The peer MUST NOT revoke its own certificate in this case. 3.9 Revocation Checking and Status Information The PKI system MUST provide a mechanism whereby peers can check the revocation status of certificates 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 manadatory protocol mechanism for performing CRL lookups MUST be specified by the final specification. All certificates used in IKE MUST have cRLDistributionPoint and authorityInfoAccess fields populated with valid URLs. This will allow all recipients of the certificate 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 certificate as valid identity in the exchange and need not perform any check. If the revocation of a certificate is used as the only means of deactivation of access authorization for the VPN 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.9.1 Error Handling in Revocation Checking Thorough error condition descriptions and handling instructions are required for each transaction in the revocation checking process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products. 4. Security Considerations TBD 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. 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 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. Change History 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. - 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 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. - Retitled 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 partipating 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. draft-bonatti-pki4ipsec-profile-reqts-00.txt expires July 30, 2004.