idnits 2.17.1 draft-ietf-pki4ipsec-mgmt-profile-rqts-07.txt: -(137): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(198): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(301): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(316): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(421): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(479): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1455): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1458): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1480): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1547): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1580): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1595): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1646): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1664): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1686): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1715): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1950): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1951): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2015. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2005. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 28 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 699 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 14 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 8, 2007) is 6198 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'G' is mentioned on line 1058, but not defined == Missing Reference: 'E' is mentioned on line 1425, but not defined == Missing Reference: 'L' is mentioned on line 1521, but not defined == Missing Reference: 'R' is mentioned on line 1754, but not defined == Missing Reference: 'I' is mentioned on line 539, but not defined == Missing Reference: 'A' is mentioned on line 741, but not defined -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. 'CERTPROFILE') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-11 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKI4IPSEC Working Group 2 Internet Draft Chris Bonatti, IECA 3 draft-ietf-pki4ipsec-mgmt-profile-rqts-07.txt Sean Turner, IECA 4 November 8, 2006 Gregory Lebovitz, Juniper 5 Expires May 8, 2007 7 Requirements for an IPsec Certificate Management Profile 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 8, 2007. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 This informational document describes and identifies the requirements 40 for transactions to handle Public Key Certificate (PKC) lifecycle 41 transactions between Internet Protocol Security (IPsec) Virtual 42 Private Network (VPN) Systems using Internet Key Exchange (IKE) 43 (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These 44 requirements are designed to meet the needs of enterprise scale IPsec 45 VPN deployments. It is intended that a standards track profile of a 46 management protocol will be created to address many of these 47 requirements. 49 IPsec Certificate Management Profile 51 Table of Contents 53 1 Introduction....................................................3 54 1.1 Scope.........................................................5 55 1.2 Non-Goals.....................................................5 56 1.3 Definitions...................................................6 57 1.4 Requirements Terminology.......................................8 58 2 Architecture....................................................8 59 2.1 VPN System....................................................8 60 2.1.1 IPsec Peer(s)...............................................9 61 2.1.2 VPN Administration Function (Admin).........................9 62 2.2 PKI System...................................................10 63 2.3 VPN-PKI Interaction..........................................10 64 3 Requirements...................................................12 65 3.1 General Requirements.........................................12 66 3.1.1 One Protocol...............................................12 67 3.1.2 Secure Transactions........................................12 68 3.1.3 Admin Availability.........................................12 69 3.1.3 PKI Availability...........................................13 70 3.1.4 End-User Transparency......................................13 71 3.1.5 PKC Profile for PKI Interaction............................13 72 3.1.5.1 Identity.................................................14 73 3.1.5.2 Key Usage................................................14 74 3.1.5.3 Extended Key Usage.......................................14 75 3.1.5.4 Revocation Information Location..........................14 76 3.1.6 Error Handling.............................................14 77 3.2 Authorization................................................14 78 3.2.1 One Protocol...............................................14 79 3.2.2 Bulk Authorization.........................................15 80 3.2.3 Authorization Scenario.....................................16 81 3.2.4 Authorization Request......................................16 82 3.2.4.1 Specifying Fields within the PKC.........................16 83 3.2.4.2 Authorizations for Renewal, Update, and Rekey............17 84 3.2.4.3 Other Authorization Elements.............................18 85 3.2.4.4 Cancel Capability........................................18 86 3.2.5 Authorization Response.....................................19 87 3.2.5.1 Error Handling for Authorization.........................19 88 3.3 Generation...................................................19 89 3.3.1 Generation Method 1: IPsec Peer Generates Key Pair, 90 Constructs PKC Request, and Signs PKC Request..............20 91 3.3.2 Generation Method 2: IPsec Peer Generates Key Pair, Admin 92 Constructs PKC Request, Admin Signs PKC Request............21 93 3.3.3 Generation Method 3: Admin Generates Key Pair, Constructs PKC 94 Request, and Signs PKC Request.............................22 95 3.3.4 Method 4: PKI Generates Key Pair...........................23 96 3.3.5 Error Handling for Generation..............................23 97 3.4 Enrollment...................................................24 98 3.4.1 One protocol...............................................24 99 3.4.2 On-line protocol...........................................24 100 IPsec Certificate Management Profile 102 3.4.3 Single Connection with Immediate Response..................24 103 3.4.4 Manual Approval Option.....................................24 104 3.4.5 Enrollment Method 1: Peer Enrolls to PKI Directly..........24 105 3.4.6 Enrollment Method 2a: Peer Enrolls through Admin...........26 106 3.4.7 Enrollment Method 2b: Peer Enrolls Through Admin...........28 107 3.4.8 Enrollment Method 3a: Admin Authorizes and Enrolls 108 Directly to PKI............................................30 109 3.4.9 Enrollment Method 3b: Admin Authorizes and Enrolls 110 Directly to PKI............................................32 111 3.4.10 Confirmation Handshake....................................34 112 3.4.11 Error Handling for Enrollment.............................35 113 3.5 Lifecycle....................................................36 114 3.5.1 One Protocol...............................................36 115 3.5.2 PKC Rekeys, Renewals, and Updates..........................36 116 3.5.2.1 Rekey Request............................................38 117 3.5.2.1 Renew Request............................................38 118 3.5.2.2 Update Request...........................................38 119 3.5.2.3 Error Handling for Rekey, Renewal, and Update............39 120 3.5.2.4 Confirmation Handshakes..................................40 121 3.5.3 Revocation.................................................40 122 3.6 Repositories.................................................41 123 3.6.1 Lookups....................................................41 124 3.6.2 Error Handling for Repository Lookups......................42 125 3.7 Trust........................................................42 126 3.7.1 Trust Anchor PKC Acquisition...............................42 127 3.7.2 Certification Path Validation..............................42 128 3.7.3 Revocation Checking and Status Information.................43 129 3.7.4 Error Handling in Revocation Checking and Certificate 130 Path Validation...........................................43 131 4 Security Considerations........................................44 132 5 IANA Considerations............................................44 133 6 References.....................................................44 134 6.1 Normative References.........................................44 135 6.2 Informative References.......................................44 136 7 Acknowledgements...............................................45 137 Editor�s Address..................................................45 139 1 Introduction 141 This document contains requirements for a transaction-based 142 approach. Other models are conceivable, for example a directory- 143 centric approach, but their requirements are beyond the scope of 144 this document. 146 This document enumerates requirements for Public Key Certificate 147 (PKC) lifecycle transactions between different VPN System and PKI 148 System products in order to better enable large scale, PKI-enabled 149 IPsec deployments with a common set of transactions. Requirements for 150 IPsec Certificate Management Profile 152 both the IPsec and the PKI products are discussed. The requirements 153 are carefully designed to achieve security without compromising ease 154 of management and deployment, even where the deployment involves tens 155 of thousands of IPsec users and devices. 157 The requirements address transactions for the entire PKC lifecycle 158 for PKI-enabled VPN System: authorization (of PKC issuance), 159 generation (public-private key pair and PKC request), enrollment (PKC 160 request, PKC response, and confirmation), maintenance (rekey, renew, 161 update, revoke, and confirm), and repository lookups. These 162 transactions enable a VPN Operator to: 164 - Use a VPN Administration function (Admin), which is introduced in 165 this document, to manage PKC authorization and possibly act as 166 the sole interface for the VPN System and the PKI System. 168 - Authorize individual or batches of PKC issuances based on a pre- 169 agreed template (i.e., both types of authorization requests 170 refer to the pre-agreed template). These authorizations can 171 occur either prior to the enrollment or in the same transaction 172 as the enrollment. 174 - Provision PKI-based user or machine identity to IPsec Peers, on a 175 large scale. 177 - Set the corresponding gateway or client authorization policy for 178 remote access and site-to-site connections. 180 - Establish policies for automatic PKC renewal, updates, or rekeys. 182 - Ensure timely revocation information is available for PKCs used 183 in IKE exchanges. 185 These requirements are intended to be used to profile a certificate 186 management protocol that the VPN System will use to communicate with 187 the PKI System. Note that this profile will be in another document. 188 The certificate management profile will also clarify and constrain 189 existing PKIX and IPsec standards to limit the complexity of 190 deployment. Some requirements may require either a new protocol, or 191 changes or extensions to an existing protocol. 193 The desired outcome of the requirements and profile documents is that 194 both IPsec and PKI vendors create interoperable products to enable 195 large-scale IPsec System deployments, and do so as quickly as 196 possible. For example, a VPN Operator should be able to use any 197 conforming IPsec implementation (VPN Admin or IPsec Peer) of the 198 certificate management profile with any conforming PKI vendor�s 199 implementation to perform the VPN rollout and management. 201 IPsec Certificate Management Profile 203 1.1 Scope 205 The document addresses requirements on transactions between the VPN 206 Systems and the PKI Systems and between the VPN Administration and 207 IPsec Peers. The requirements strive to meet eighty percent of the 208 market needs for large-scale deployments (i.e., VPNs including 209 hundreds or thousands of managed VPN gateways or VPN remote access 210 clients). Environments will understandably exist in which large-scale 211 deployment tools are desired, but local security policy stringency 212 will not allow for the use of such commercial tools. The solution 213 will possibly miss the needs of the highest ten percent of stringency 214 and lowest ten percent of convenience requirements. Use cases will be 215 considered or rejected based upon this eighty percent rule. The needs 216 of small deployments are a stated non-goal, however service providers 217 employing the scoped solution and applying it to many smaller 218 deployments in aggregate may address them. 220 Gateway-to-gateway access and end-user remote access (to a gateway) 221 are both covered. End-to-end communications are not necessarily 222 excluded but are intentionally not a focus. 224 Only VPN-PKI transactions that ease and enable scalable PKI-enabled 225 IPsec deployments are addressed. 227 1.2 Non-Goals 229 The scenario for PKC cross-certification will not be addressed. 231 The protocol specification for the VPN-PKI interactions will not be 232 addressed. 234 The protocol specification for the VPN Administrator to Peer 235 transactions will not be addressed. These interactions are considered 236 vendor proprietary. These interactions may be standardized later to 237 enable interoperability between VPN Administration function stations 238 and IPsec Peers from different vendors, but are far beyond the scope 239 of this current effort, and will be described as opaque transactions 240 in this document. 242 The protocol specification for RA-CA, CA-Repository, and RA- 243 Repository interactions will not be addressed. 245 IPsec Certificate Management Profile 247 1.3 Definitions 249 VPN System 250 The VPN System is comprised of the VPN Administration function 251 (defined below), the IPsec Peers, and the communication mechanism 252 between the VPN Administration and the IPsec Peers. VPN System is 253 defined in more detail in section 2.1. 255 PKI System 256 The PKI System, or simply PKI, is the set of functions needed to 257 authorize, issue, and manage PKCs. PKI System is defined in more 258 detail in section 2.2. 260 (VPN) Operator 261 The Operator is the person or group of people that define security 262 policy and configure the VPN System to enforce that policy, with the 263 VPN Administration function. 265 IPsec Peer (Gateway or Client) 266 For the purposes of this document, an IPsec Peer, or simply "Peer", 267 is any VPN System component that communicates IKE and IPsec to 268 another Peer in order to create an IPsec Security Association for 269 communications. It can be either a traditional security gateway (with 270 two network interfaces, one for the protected network and one for the 271 unprotected network), or it can be an IPsec client (with a single 272 network interface). In both cases, the Peer can pass traffic with no 273 IPsec protection, and can add IPsec protection to chosen traffic 274 streams. See Section 2.1.1 for more details. 276 (VPN) Admin 277 The Admin is the VPN System function that interacts with the PKI 278 System to establish PKC provisioning for the VPN connections. See 279 Section 2.1.2 for more details. 281 End Entity 282 An end entity is the entity or subject that is identified in a PKC. 283 The end entity is the one entity that will finally use a private key 284 associated with a PKC to digitally sign data. In this document, an 285 IPsec Peer is certainly an end entity, but the VPN Admin can also 286 constitute an end entity. Note that end entities can have different 287 PKCs for different purposes (e.g., signature vs. key exchange, Admin- 288 functions vs. Peer-functions). 290 PKC Renewal 291 The acquisition of a new PKC with the same public key due to the 292 expiration of an existing PKC. Renewal occurs prior to the expiration 293 of the existing PKC to avoid any connection outages. A renewal 294 process can rely on the existing key pair to bootstrap authentication 295 for the new enrollment. 297 IPsec Certificate Management Profile 299 PKC Update 300 A special case of a renewal-like occurrence where a PKC needs to be 301 changed prior to expiration due to some change in its subject�s 302 information. Examples might include change in the address, telephone 303 number, or name change due to marriage of the end entity. An update 304 process can rely on the existing key pair to bootstrap authentication 305 for the new enrollment. 307 PKC Rekey 308 The routine procedure for replacement of a PKC with a new PKC with a 309 new public key for the same subject name. A rekey process can rely 310 on the existing key pair to bootstrap authentication for the new 311 enrollment. 313 Registration Authority (RA) 314 An optional entity in a PKI System given responsibility for 315 performing some of the administrative tasks necessary in the 316 registration of end entities, such as confirming the subject�s 317 identity and verifying that the subject has possession of the private 318 key associated with the public key requested for a PKC. 320 Certificate Authority (CA) 321 An authority in a PKI System that is trusted by one or more users to 322 create and sign PKCs. It is important to note that the CA is 323 responsible for the PKCs during their whole lifetime, not just for 324 issuing them. 326 Repository 327 An Internet-accessible server in a PKI System that stores and makes 328 available for retrieval PKCs and Certificate Revocation Lists (CRLs). 330 Root CA/Trust Anchor 331 A CA that is directly trusted by an end entity; that is, securely 332 acquiring the value of a Root CA public key requires some out-of-band 333 step(s). This term is not meant to imply that a Root CA is 334 necessarily at the top of any hierarchy, simply that the CA in 335 question is trusted directly. 337 Certificate Revocation List (CRL) 338 A CRL is a CA-signed, time stamped list identifying revoked PKCs and 339 made freely available in a repository. Peers retrieve the CRL to 340 verify that a PKC being presented to them as the identity in an IKE 341 transaction has not been revoked. 343 CRL Distribution Point (CDP) 344 The CDP is a PKC extension that identifies the location from which 345 end entities should retrieve CRLs to check status information. 347 IPsec Certificate Management Profile 349 Authority Info Access (AIA) 350 The AIA is a PKC extension that indicates how to access CA 351 information and services for the issuer of the PKC in which the 352 extension appears. Information and services may include on-line 353 validation services and Certificate Policy (CP) data. 355 1.4 Requirements Terminology 357 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 358 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 359 document are to be interpreted as described in [MUSTSHOULD]. 361 2 Architecture 363 This section describes the overall architecture for a PKI-supported 364 IPsec VPN deployment. First, an explanation of the VPN System is 365 presented. Second, key points about the PKI System are stated. Third, 366 the VPN-PKI architecture is presented. 368 2.1 VPN System 370 The VPN System consists of the IPsec Peers and the VPN Administration 371 function, as depicted in Figure 1. 373 +---------------------------------------------------+ 374 | | 375 | +----------+ | 376 | | VPN | | 377 | +---------->| Admin |<-------+ | 378 | | | Function | | | 379 | | +----------+ | | 380 | v v | 381 | +---------+ +---------+ | 382 | | IPsec | | IPsec | | 383 | | Peer 1 |<=======================>| Peer 2 | | 384 | +---------+ +---------+ | 385 | | 386 | VPN System | 387 +---------------------------------------------------+ 389 Figure 1: VPN System 391 IPsec Certificate Management Profile 393 2.1.1 IPsec Peer(s) 395 The Peers are two entities between which establishment of an IPsec 396 Security Association is required. Two Peers are shown in Figure 1, 397 but implementations can support an actual number in the hundreds or 398 thousands. The Peers can be gateway-to-gateway, remote-access-host- 399 to-gateway, or a mix of both. The Peers authenticate themselves in 400 the IKE negotiation using digital signatures generated with PKCs for 401 a PKI System. 403 2.1.2 VPN Administration Function (Admin) 405 This document defines the notion of a VPN Administration function, 406 hereafter referred to as Admin, and gives the Admin great 407 responsibility within the VPN System. The Admin is a centralized 408 function used by the Operator to interact with the PKI system to 409 establish PKI policy (e.g., algorithms, key lengths, lifecycle 410 options, and PKC fields) for groups of IPsec Peers. The Admin also 411 authorizes PKC issuance and it can act as the Peer's PKI System 412 interface, which allows the Admin to perform many RA-like functions. 414 It is important to note that, within this document, the Admin is 415 neither a device nor a person; rather it is a function. Every large- 416 scale VPN deployment will contain the Admin function. The function 417 can be performed on a stand-alone workstation, on a gateway, or on an 418 administration software component. The Admin function can also be one 419 and the same as the gateway or client device or software. They are 420 represented in the architectural diagram as different functions, but 421 they need not be different physical entities. As such, the Admin�s 422 architecture and the means by which it interacts with the 423 participating IPsec Peers will vary widely from implementation to 424 implementation. However, some basic functions of the Admin are 425 assumed. 427 - It and not the PKI will define the Certificate Policy (CP) 428 [FRAME] for use in a VPN System. The PKC's characteristics and 429 contents are a function of the CP. In VPN Systems, the Operator 430 chooses to strengthen the VPN by using PKI; PKI is a bolt-on to 431 the VPN System. The Operator will configure local security 432 policy in part through the Admin and its authorized PKI-enabled 433 Peers. 435 - It will interact directly with the PKI System to initiate 436 authorization for end entity PKCs by sending the parameters and 437 contents for individual PKCs or batches of PKCs based on a pre- 438 agreed template (i.e., both types of authorization requests 439 refer to the pre-agreed template). Templates will be agreed in 440 an out-of-band mechanism by the VPN Operator and the PKI 441 IPsec Certificate Management Profile 443 Operator. It will receive back from the PKI a unique tuple of 444 authorization identifiers and one-time authorization tokens that 445 will authorize Peers to request a PKC. 447 - It will deliver instructions to the IPsec Peers, and the Peers 448 will carry out those instructions (e.g., Admin passes Peer 449 information necessary to generate keys and PKC request). 451 2.2 PKI System 453 The PKI System, as depicted in Figure 2, can be set up and operated 454 by the Operator (in-house), be provided by third party PKI providers 455 to which connectivity is available at the time of provisioning 456 (managed PKI service), or be integrated with the VPN product. 458 +---------------------------------------------+ 459 | +-------------------------+ | 460 | v | | 461 | +--------------+ v | 462 | | Repository | +----+ +----+ | 463 | | Certs & CRLs |<-> | CA |<->| RA | | 464 | +--------------+ +----+ +----+ | 465 | | 466 +---------------------------------------------+ 468 Figure 2: PKI System 470 This framework assumes that all components of the VPN obtain PKCs 471 from a single PKI community. An IPsec Peer can accept a PKC from a 472 Peer that is from a CA outside of the PKI community, but the auto 473 provision and life cycle management for such a PKC or its trust 474 anchor PKC fall out of scope. 476 The PKI System contains a mechanism for handling Admin�s 477 authorization requests and PKC enrollments. This mechanism is 478 referred to as the Registration Authority (RA). The PKI System 479 contains a Repository for Peers to retrieve each other�s PKCs and 480 revocation information. Last, the PKI System contains the core 481 function of a CA that uses a public and private key pair and signs 482 PKCs. 484 2.3 VPN-PKI Interaction 486 The interaction between the VPN System and the PKI System is the key 487 focus of this requirements document, as shown in Figure 3. It is 488 therefore sensible to consider the steps necessary to set up, use and 489 IPsec Certificate Management Profile 491 manage PKCs for one Peer to establish an association with another 492 Peer. 494 +-----------------------------------------------+ 495 | PKI System | 496 | | 497 | +--------------+ | 498 | | Repository | +----+ +----+ | 499 | | Certs & CRLs | | CA | | RA | | 500 | +--------------+ +----+ +----+ | 501 | | 502 +-----------------------------------------------+ 503 ^ ^ ^ 504 |[G] |[A] |[G] 505 |[E] |[G] |[E] 506 |[L] |[E] |[L] 507 |[R] |[R] |[R] 508 | |[L] | 509 +-----+------------------+-------------------+-------+ 510 | | v | | 511 | | +----------+ | | 512 | | [G][E][L][R]| VPN |[G][E][L][R] | | 513 | | +---------->| Admin |<----------+ | | 514 | | | | Function | | | | 515 | | | +----------+ | | | 516 | v v v v | 517 | +---------+ +---------+ | 518 | | IPsec | [I] | IPsec | | 519 | | Peer 1 |<========================>| Peer 2 | | 520 | +---------+ +---------+ | 521 | | 522 | VPN System | 523 +----------------------------------------------------+ 525 [A] = Authorization: PKC issuance 526 [G] = Generation: Public key, and private key, and PKC request 527 [E] = Enrollment: Sending PKC request, verifying PKC response, and 528 confirming PKC response 529 [I] = IKE and IPsec communication 530 [L] = Lifecycle: Rekey, renewal, update, revocation, and 531 confirmation 532 [R] = Repository: Posting and lookups 534 Figure 3. Architectural Framework for VPN-PKI Interaction 536 Requirements for each of the interactions, [A], [G], [E], [L], and 537 [R], are addressed in paragraphs 3.2-3.6. However, only requirements 538 for [A], [E], [L], and [R] will be addressed by the certificate 539 management profile. Requirements for [I] transactions are beyond the 540 IPsec Certificate Management Profile 542 scope of this document. Additionally, the act of certification (i.e., 543 binding the public key to the name) is performed at the CA and is not 544 shown in the Figure. 546 3 Requirements 548 3.1 General Requirements 550 3.1.1 One Protocol 552 The target profile, to be based on this requirements document, MUST 553 call for ONE PROTOCOL or ONE USE PROFILE for each main element of the 554 [A], [E], [L], and [R] interactions. It is a specific goal to avoid 555 multiple competing protocols or profiles to solve the same 556 requirement whenever possible to reduce complexity and improve 557 interoperability. 559 Meeting some of the requirements may necessitate the creation of a 560 new protocol or new extension for an existing protocol; however, the 561 latter is much preferred. 563 3.1.2 Secure Transactions 565 The target certificate management profile MUST specify the [A], [E], 566 [L], and [R] transactions between VPN and PKI Systems. To support 567 these transactions, the Admin and PKI MUST exchange policy details, 568 identities, and keys. As such, the method of communication for [A], 569 [E], and [L] transactions MUST be secured in a manner that ensures 570 privacy, authentication, and message data integrity. The 571 communication method MUST require that mutual trust be established 572 between the PKI and the Admin. See paragraph 3.7.1. [R] transactions 573 do not require authentication or message data integrity because the 574 responses (i.e., PKCs and CRLs) are already digital signed. Whether 575 [R] transactions require privacy is determined by the local security 576 policy. 578 The target certificate management profile will not specify [G] 579 transactions; however, these transactions MUST be secured in a manner 580 that ensures privacy, authentication, and message data integrity 581 because these transactions are the basis for the other transactions. 583 3.1.3 Admin Availability 585 The Admin MUST be reachable by the Peers. Most implementations will 586 meet this requirement by ensuring Peers can connect to the Admin from 587 anywhere on the network or Internet. However, communication between 588 IPsec Certificate Management Profile 590 the Admin and Peers can be "off-line". It can, in some environments, 591 be "moving media" (i.e., the configuration or data is loaded on to a 592 floppy disk or other media and physically moved to the IPsec Peers). 593 Likewise, it can be entered directly on the IPsec Peer via a User 594 Interface (UI). In this case, the Admin function is co-located on the 595 Peer device itself. Most requirements and scenarios in this document 596 assume on-line availability of the Admin for the life of the VPN 597 System. 599 3.1.3 PKI Availability 601 Availability is REQUIRED initially for authorization transactions 602 between the PKI and Admin. Further availability is required in most 603 cases, but the extent of this availability is a decision point for 604 the Operator. Most requirements and scenarios in this document assume 605 on-line availability of the PKI for the life of the VPN System. 607 Off-line interaction between the VPN and PKI Systems (i.e., where 608 physical media is used as the transport method) is beyond the scope 609 of this document. 611 3.1.4 End-User Transparency 613 PKI interactions are to be transparent to the user. Users SHOULD NOT 614 even be aware that PKI is in use. First time connections SHOULD 615 consist of no more than a prompt for some identification and pass 616 phrase, and a status bar notifying the user that setup is in 617 progress. 619 3.1.5 PKC Profile for PKI Interaction 621 A PKC used for identity in VPN-PKI transactions MUST include all the 622 [CERTPROFILE] mandatory fields. It MUST also contain contents 623 necessary to support path validation and certificate status checking. 625 It is preferable that the PKC profiles for IPsec transactions 626 [IKECERTPROFILE] and VPN-PKI transactions (in the certificate 627 management profile) are the same so that one PKC could be used for 628 both transaction sets. If the profiles are inconsistent then 629 different PKCs (and perhaps different processing requirements) might 630 be required. However, the authors urge that process on other aspects 631 of this standardization effort continue regardless of the status of 632 efforts to achieve PKC profile consensus. 634 IPsec Certificate Management Profile 636 3.1.5.1 Identity 638 PKCs MUST support identifying (i.e., naming) Peers and Admins. The 639 following name forms MUST be supported: 641 - Fully-Qualified Domain Name (FQDN) 642 - RFC 822 (also called USER FQDN) 643 - IPv4 Address 644 - IPv6 Address 646 3.1.5.2 Key Usage 648 PKCs MUST support indicating the purposes for which the key (i.e., 649 digital signature) can be used. Further, PKCs MUST always indicate 650 that relying parties (i.e., Peers) need to understand the indication. 652 3.1.5.3 Extended Key Usage 654 Extended Key Usage (EKU) indications are not required. The presence 655 or lack of an EKU MUST NOT cause an implementation to fail an IKE 656 connection. 658 3.1.5.4 Revocation Information Location 660 PKCs MUST indicate the location of CRL such that any Peer who holds 661 the PKC locally will know exactly where to go and how to request the 662 CRL. 664 3.1.6 Error Handling 666 The protocol for the VPN-PKI transactions MUST specify error handling 667 for each transaction. Thorough error condition descriptions and 668 handling instructions will greatly aid interoperability efforts 669 between the PKI and VPN System products. 671 3.2 Authorization 673 This section refers to the [A] elements labeled in Figure 3. 675 3.2.1 One Protocol 677 One protocol MUST be specified for these Admin to PKI (RA/CA) 678 interaction. This protocol MUST support privacy, authorization, 679 IPsec Certificate Management Profile 681 authentication, and integrity. PKCs for authorization of the Admin 682 can be initialized through an out-of-band mechanism. 684 The transport used to carry the authorization SHOULD be reliable 685 (TCP). 687 The protocol SHOULD be as lightweight as possible. 689 3.2.2 Bulk Authorization 691 Bulk authorization MUST be supported by the certificate management 692 profile. Bulk authorization occurs when the Admin requests of the PKI 693 that authorization be established for several different subjects with 694 almost the same contents. A minimum of one value (more is also 695 acceptable) differs per subject. Because the authorizations may occur 696 before any keys have been generated, the only way to ensure unique 697 authorization identifiers are issued is to have at least one value 698 differ per subject. 700 Authorization can occur prior to a PKC enrollment request, or the 701 authorization and the PKC enrollment request can be presented to the 702 PKI at the same time. Both of these authorization scenarios MUST be 703 supported. 705 A bulk authorization SHOULD occur in one single connection to the PKI 706 (RA/CA), with the number of subjects being one or greater. 707 Implementations SHOULD be able to handle one thousand subjects in a 708 batch authorization. 710 IPsec Certificate Management Profile 712 3.2.3 Authorization Scenario 714 The authorization scenario for VPN-PKI transactions involves a two- 715 step process: an authorization request and an authorization 716 response. Figure 4 shows the salient interactions to perform 717 authorization transactions. 719 +--------------+ +-----------------------+ 720 | Repository | | CA/RA | 721 +--------------+ +-----------------------+ 722 ^ 723 | 1 724 2 | 725 v 726 +-------+ 727 | Admin | 728 +-------+ 730 +--------------------+ +--------+ 731 | IPsec | | IPsec | 732 | Peer 1 | | Peer 2 | 733 +--------------------+ +--------+ 735 Figure 4. Authorization Transactions 737 1) Authorization [A]. Admin sends a list of identities and PKC 738 contents for the PKI System to authorize enrollment. See paragraph 739 3.2.4. 741 2) Authorization Response [A]. The PKI returns a list of unique 742 authorization identifiers and one-time authorization tokens to be 743 used for the enrollment of each PKC (1). Response may indicate 744 success, failure, or errors for any particular authorization. See 745 paragraph 3.2.5. 747 3.2.4 Authorization Request 749 3.2.4.1 Specifying Fields within the PKC 751 The Admin authorizes individual PKCs or batches of PKC issuances 752 based on a pre-agreed template. This template is agreed by the VPN 753 Operator and PKI Operator and is referred to in each authorization 754 request. This allows the authorization requests to include the 755 minimal amount of information necessary to support a VPN System. 757 IPsec Certificate Management Profile 759 The Admin can send the PKI System the set of PKC contents that it 760 wants the PKI to issue to a group of IPsec Peers. In other words, it 761 tells the PKI System, "if you see a PKC request that looks like this, 762 from this person, process it and issue the PKC." 764 Requirements for PKC fields used in IPsec transactions are specified 765 in [IKECERTPROFILE]. 767 Requirements for PKC fields used in VPN-PKI transactions are 768 specified in paragraph 3.1.5. 770 3.2.4.2 Authorizations for Renewal, Update, and Rekey 772 When the VPN Operator and PKI Operator pre-agree on a template, they 773 MUST also agree on the local policy regarding PKC renewal and PKC 774 update. These are: 776 - Admin MUST specify if automatic renewals are allowed, that is, 777 the Admin authorizes the PKI to process a future renewal for the 778 specified Peer PKC. 780 - Admin MUST specify if PKC update is allowed, that is, the Admin 781 authorizes the PKI to accept a future request for a new PKC with 782 changes to non-key-related fields. 784 If a PKC renewal is authorized, the Admin MUST further specify: 786 - Who can renew, that is, can only the Admin send a renewal request 787 or can the Peer send a request directly to the PKI, or either. 789 - Specify at how long before the PKC expiration date the PKI will 790 accept and process a renewal (i.e., N% of validity period, or 791 the UTC time after which renewal is permitted). 793 If PKC update is authorized, the Admin MUST further specify: 795 - The aspects of non-key-related fields that are changeable. 797 - The entity that can send the PKC Update request, that is, only 798 the Admin, only the Peer, or either. 800 - Specify at how long before the PKC expiration date the PKI will 801 accept and process an update (i.e., N% of validity period, or 802 the UTC time after which update is permitted). 804 A new authorization by the Admin is REQUIRED for PKC rekey. No 805 parameters of prior authorizations need be considered. 807 IPsec Certificate Management Profile 809 3.2.4.3 Other Authorization Elements 811 The Admin MUST have the ability to specify the format for the 812 authorization ID and one-time authorization token. The one-time 813 authorization token SHOULD be unique per authorization ID. The more 814 randomness that can be achieved in the relationship between an 815 authorization ID and its one-time authorization token, the better. 816 The one-time authorization token MUST be in UTF8 format to avoid 817 incompatibilities that may occur due to international characters. It 818 MUST support normalization as in [CERTPROFILE]. The Admin MUST have 819 the ability to constrain the UTF8 character set. 821 There MUST be an option to specify a validation period for the 822 authorization ID and its one-time authorization token. If such a 823 validation period is set, any PKC requests using this authorization 824 ID and one-time authorization token that arrive at the PKI outside of 825 the validation period MUST be dropped and the event logged. 827 The Protocol SHOULD consider what happens when Admin requested 828 information conflicts with PKI settings such that the Admin request 829 cannot be issued as requested (e.g., Admin requests validation period 830 = 3 weeks and CA is configured to only allow validation periods = 1 831 week). Proper conflict handling MUST be specified. 833 3.2.4.4 Cancel Capability 835 Either the Admin or the Peer can send a cancel authorization message 836 to PKI. The canceling entity MUST provide the authorization ID and 837 one-time authorization token in order to cancel the authorization. At 838 that point, the authorization will be erased from the PKI, and a log 839 entry of the event written. 841 After the cancellation has been verified (a Cancel, Cancel ACK, ACK 842 type of a process is REQUIRED to cover a lost connections scenario), 843 the PKI will accept a new authorization request with the exact same 844 contents as the canceled one, except that the identifier MUST be new. 845 The PKI MUST NOT process duplicate authorization requests. 847 Note that if the PKI has already issued a PKC associated with an 848 authorization, then cancellation of the authorization is not 849 possible and the authorization request SHOULD be refused by the PKI. 850 Once a PKC has been issued it MUST be revoked in accordance with 851 clause 3.6. 853 IPsec Certificate Management Profile 855 3.2.5 Authorization Response 857 If the authorization request is acceptable, the PKI will respond to 858 the Admin with a unique authorization identifier per subject 859 authorization requested and a one-time authorization token per 860 authorization ID. See paragraph 3.2.4.3 for additional authorization 861 ID and one-time authorization token requirements. 863 The PKI can alter parameters of the authorization request submitted 864 by the Admin. In that event, the PKI MUST return all the contents of 865 the authorization request (as modified) to the Admin with the 866 confirmation of authorization success. This will allow the Admin to 867 perform an "operational test" to verify that the issued PKCs will 868 meet its requirements. If the Admin determines that the modified 869 parameters are unacceptable, then the authorization should be 870 cancelled in accordance with clause 3.2.4.4. 872 After receiving a bulk authorization request from the Admin, the PKI 873 MUST be able to reply YES to those individual PKC authorizations that 874 it has satisfied and NO or FAILED for those requests that cannot be 875 satisfied, along with sufficient reason or error codes. 877 A method is REQUIRED to identify if there is a change in PKI setting 878 between the time the authorization is granted and PKC request occurs, 879 and what to do about the discrepancy. 881 3.2.5.1 Error Handling for Authorization 883 Thorough error condition descriptions and handling instructions MUST 884 be provided to the Admin for each transaction in the authorization 885 process. Providing such error codes will greatly aid interoperability 886 efforts between the PKI and IPsec products. 888 3.3 Generation 890 This section refers to the [G] elements labeled in Figure 3. 892 Once the PKI System has responded with authorization identifiers and 893 authorization tokens (see paragraph 3.2), and this information is 894 received at the Admin, the next step is to generate public and 895 private key pairs and to construct PKC requests using those key 896 pairs. The key generations can occur at one of three places, 897 depending on local requirements: at the IPsec Peer, at the Admin, or 898 at the PKI. The PKC request can come from either the IPsec Peer, a 899 combination of the Peer and the Admin, or not at all. 901 IPsec Certificate Management Profile 903 3.3.1 Generation Method 1: IPsec Peer Generates Key Pair, Constructs 904 PKC Request, and Signs PKC Request 906 This option will be used most often in the field. This is the most 907 secure method for keying, as the keys are generated on the end entity 908 and the private key never leaves the end entity. However, it is the 909 most computationally intensive for the Peer as it must be "ASN.1 910 aware" to support generating and digitally signing the PKC request. 912 +--------------+ +-----------------------+ 913 | Repository | | CA/RA | 914 +--------------+ +-----------------------+ 916 +-------+ 917 +------>| Admin | 918 | +-------+ 919 | 920 | 1 921 V 922 +--------------------+ +--------+ 923 2 | IPsec | | IPsec | 924 | Peer 1 | | Peer 2 | 925 +--------------------+ +--------+ 927 Figure 5. Generation Interactions: 928 IPsec Peer Generates Key Pair and Constructs PKC Request 930 1) Opaque transaction. Admin sends authorization identifier, one-time 931 authorization token, and any other parameters needed by the Peer to 932 generate the PKC request, including key type and size. 934 2) Generation [G]. Peer receives authorization identifier, one-time 935 authorization token, and any parameters. Peer generates key pair and 936 constructs PKC request. 938 Steps prior to these can be found in paragraph 3.2. The next step, 939 enrollment, can occur either directly between the Peer and PKI (see 940 paragraph 3.4.5) or through the Admin (see paragraph 3.4.6). 942 IPsec Certificate Management Profile 944 3.3.2 Generation Method 2: IPsec Peer Generates Key Pair, Admin 945 Constructs PKC Request, Admin Signs PKC Request 947 This option also supports IPsec Peer generation of key pair, but 948 removes the requirement for the Peer to be ASN.1 aware because it 949 does not have to construct or digitally sign the PKC request. The 950 drawback is that the key pair does need to be provided to the Admin. 952 +--------------+ +-----------------------+ 953 | Repository | | CA/RA | 954 +--------------+ +-----------------------+ 956 3 +-------+ 957 +------>| Admin | 4 958 | +-------+ 959 | 960 | 1 961 V 962 +--------------------+ +--------+ 963 2 | IPsec | | IPsec | 964 | Peer 1 | | Peer 2 | 965 +--------------------+ +--------+ 967 Figure 6. Generation Interactions: 968 IPsec Peer Generates Key Pair, Admin Constructs PKC Request 970 1) Opaque transaction. Admin sends command to Peer to generate key 971 pair, based on parameters provided in the command. 973 2) Generation [G]. Peer generates key pair. 975 3) Opaque transaction [G]. Peer returns key pair to Admin. 977 4) Generation [G]. Admin constructs and digitally signs PKC request. 979 Steps prior to these can be found in paragraph 3.2. The next step, 980 enrollment, occurs through the Admin (see paragraph 3.4.7). 982 IPsec Certificate Management Profile 984 3.3.3 Generation Method 3: Admin Generates Key Pair, Constructs PKC 985 Request, and Signs PKC Request 987 This option exists for deployments where Peers cannot generate their 988 own key pairs. Some examples are for PDAs and handsets where to 989 generate an RSA key would be operationally impossible due to 990 processing and battery constraints. Another case covers key recovery 991 requirements, where the same PKCs are used for other functions in 992 addition to IPsec, and key recovery is required (e.g. local data 993 encryption), therefore key escrow is needed off the Peer. If key 994 escrow is performed then the exact requirements and procedures for it 995 are beyond the scope of this document. 997 +--------------+ +-----------------------+ 998 | Repository | | CA/RA | 999 +--------------+ +-----------------------+ 1001 +-------+ 1002 | Admin | 1 1003 +-------+ 1005 +--------------------+ +--------+ 1006 | IPsec | | IPsec | 1007 | Peer 1 | | Peer 2 | 1008 +--------------------+ +--------+ 1010 Figure 7. Generation Interactions: 1011 Admin Generates Key Pair and Constructs PKC Request 1013 1) Generation [G]. Admin generates key pair, constructs PKC request, 1014 and digitally signs PKC request. 1016 Steps prior to these can be found in paragraph 3.2. The next step, 1017 enrollment, occurs through the Admin (see paragraph 3.4.8). 1019 Note that separate authorizations step are still of value even though 1020 the Admin is the also performing the key generation. The PKC 1021 template, Subject fields, SubjectAltName fields and more are part of 1022 the request, and must be communicated in some way from the Admin to 1023 the PKI. Instead of creating a new mechanism, the authorization 1024 schema can be reused. This also allows for the feature of role-based 1025 administration, where Operator 1 is the only one allowed to have the 1026 Admin function pre-authorize PKCs, but Operator 2 is the one doing 1027 batch enrollments and VPN device configurations. 1029 IPsec Certificate Management Profile 1031 3.3.4 Method 4: PKI Generates Key Pair 1033 This option exists for deployments where end entities cannot generate 1034 their own key pairs and the Admin function is a minimal 1035 implementation. The PKI and Admin pre-agree to have the PKI generate 1036 key pairs and PKCs. This is, in all likelihood, the easiest way to 1037 deploy PKCs, though it sacrifices some security since both the CA and 1038 the Admin have access to the private key. However, in cases where key 1039 escrow is required, this may be acceptable. The Admin effectively 1040 acts as a proxy for the Peer in the PKC enrollment process. 1042 +--------------+ +-----------------------+ 1043 | Repository | | CA/RA | 1 1044 +--------------+ +-----------------------+ 1046 +-------+ 1047 | Admin | 1048 +-------+ 1050 +--------------------+ +--------+ 1051 | IPsec | | IPsec | 1052 | Peer 1 | | Peer 2 | 1053 +--------------------+ +--------+ 1055 Figure 8. Generation Interactions: 1056 IPsec Peer Generates Key Pair, Admin Constructs PKC Request 1058 1) Generation [G] The PKI generates the key pair. 1060 Steps prior to these can be found in paragraph 3.2. The next step, 1061 enrollment, occurs through the Admin (see paragraph 3.4.9). 1063 3.3.5 Error Handling for Generation 1065 Thorough error condition descriptions and handling instructions MUST 1066 be provided for each transaction in the key generation and PKC 1067 request construction process. Providing such error codes will greatly 1068 aid interoperability efforts between the PKI and IPsec products. 1070 Error conditions MUST be communicated to the Admin regardless of who 1071 generated the key or PKC request. 1073 IPsec Certificate Management Profile 1075 3.4 Enrollment 1077 This section refers to the [E] elements labeled in Figure 3. 1079 Regardless of where the keys were generated and the PKC request 1080 constructed, an enrollment process will need to occur to request that 1081 the PKI issue a PKC and the corresponding PKC be returned. 1083 The protocol MUST be exactly the same regardless of whether the 1084 enrollment occurs from the Peer to the PKI or from the Admin to the 1085 PKI. 1087 3.4.1 One protocol 1089 One protocol MUST be specified for enrollment requests, responses, 1090 and confirmations. 1092 3.4.2 On-line protocol 1094 The protocol MUST support enrollment that occurs over the Internet 1095 and without the need for manual intervention. 1097 3.4.3 Single Connection with Immediate Response 1099 Enrollment requests and responses MUST be able to occur in one on- 1100 line connection between the Admin on behalf of the Peer or the Peer 1101 itself and the PKI (RA/CA). 1103 3.4.4 Manual Approval Option 1105 Manual approval of PKC enrollments is too time consuming for large 1106 scale implementations, and is therefore not required. 1108 3.4.5 Enrollment Method 1: Peer Enrolls to PKI Directly 1110 In this case, the IPsec Peer only communicates with the PKI after 1111 being commanded to do so by the Admin. This enrollment mode is 1112 depicted in Figure 9 and the letters in the following description 1113 refer to Figure 3. Prior authorization (see paragraph 3.2) and 1114 generation (see paragraph 3.3.1) steps are not shown. 1116 IPsec Certificate Management Profile 1118 Most IPsec Systems have enough CPU power to generate a public and 1119 private key pair of sufficient strength for secure IPsec. In this 1120 case, the end entity needs to prove to the PKI that it has such a key 1121 pair; this is normally done by the PKI sending the end entity a 1122 nonce, which the end entity signs and returns to the Admin along with 1123 the end entity�s public key. 1125 +--------------+ +-----------------------+ 1126 | Repository | | CA/RA | 1127 +--------------+ +-----------------------+ 1128 ^ 1129 1,3 | 1130 | 1131 | 1132 | +-------+ 1133 | | Admin | 1134 | +-------+ 1135 | 1136 2,4 | 1137 v 1138 +--------------------+ +--------+ 1139 | IPsec | | IPsec | 1140 | Peer 1 | | Peer 2 | 1141 +--------------------+ +--------+ 1143 Figure 9. VPN-PKI Interaction Steps: 1144 IPsec Peer Generates Keys and PKC Request, 1145 Enrolls Directly with PKI 1147 1) Enrollment Request [E]. The IPsec Peer sends PKC requests from the 1148 PKI, providing the generated public key. 1150 2) Enrollment Response [E]. The PKI responds to the enrollment 1151 request, providing either the new PKC that was generated or a 1152 suitable error indication. 1154 3) Enrollment Confirmation [E]. Peer positively acknowledges receipt 1155 of new PKC. 1157 4) Enrollment Confirmation Receipt [E]. PKI sends enrollment 1158 confirmation receipt back to the Peer. 1160 IPsec Certificate Management Profile 1162 3.4.6 Enrollment Method 2a: Peer Enrolls through Admin 1164 In this case, the IPsec Peer has generated the key pair and the PKC 1165 request, but does not enroll directly to the PKI System. Instead, it 1166 automatically sends its request to the Admin, and the Admin redirects 1167 the enrollment to the PKI System. The PKI System does not care where 1168 the enrollment comes from, as long as it is a valid enrollment. Once 1169 the Admin receives the PKC response, it automatically forwards it to 1170 the IPsec Peer. 1172 Most IPsec Systems have enough CPU power to generate a public and 1173 private key pair of sufficient strength for secure IPsec. In this 1174 case, the end entity needs to prove to the Admin that it has such a 1175 key pair; this is normally done by the Admin sending the end entity a 1176 nonce, which the end entity signs and returns to the Admin along with 1177 the end entity�s public key. 1179 This enrollment mode is depicted in Figure 10 and the letters in the 1180 following description refer to Figure 3. Prior authorization (see 1181 paragraph 3.2) and generation (see paragraph 3.3.1) steps are not 1182 shown. 1184 IPsec Certificate Management Profile 1186 +--------------+ +-----------------------+ 1187 | Repository | | CA/RA | 1188 +--------------+ +-----------------------+ 1189 ^ 2,6 1190 | 1191 | 1192 v 3,7 1193 1,5 +-------+ 1194 +> | Admin | 1195 | +-------+ 1196 | 1197 | 1198 4,8 v 1199 +--------------------+ +--------+ 1200 | IPsec | | IPsec | 1201 | Peer 1 | | Peer 2 | 1202 +--------------------+ +--------+ 1204 Figure 10. VPN-PKI Interaction Steps: 1205 IPsec Peer Generates Keys and PKC Request, 1206 Enrolls Through Admin 1208 1) Opaque Transaction [E]. The IPsec Peer requests a PKC from the 1209 Admin, providing the generated public key. 1211 2) Enrollment [E]. The Admin forwards the enrollment request to the 1212 PKI. 1214 3) Enrollment Response [E]. The PKI responds to the enrollment 1215 request, providing either the new PKC that was generated or a 1216 suitable error indication. 1218 4) Opaque Transaction [E]. The Admin forwards the enrollment response 1219 back to the IPsec Peer. 1221 5) Opaque Transaction [E]. Peer must positively acknowledge receipt 1222 of new PKC back to the Admin. 1224 6) Enrollment Confirmation [E]. Admin forwards enrollment 1225 confirmation back to the PKI. 1227 7) Enrollment Confirmation Receipt [E]. PKI sends enrollment 1228 confirmation receipt back to the Admin. 1230 8) Opaque Transaction [E]. Admin forwards PKI's enrollment 1231 confirmation receipt back to the Peer. 1233 IPsec Certificate Management Profile 1235 3.4.7 Enrollment Method 2b: Peer Enrolls Through Admin 1237 In this case, the IPsec Peer has generated the key pair, but the PKC 1238 request is constructed and signed by the Admin. The PKI System does 1239 not care where the enrollment comes from, as long as it is a valid 1240 enrollment. Once the Admin retrieves the PKC, it then automatically 1241 forwards it to the IPsec Peer along with the key pair. 1243 Some IPsec Systems do not have enough CPU power to generate a public 1244 and private key pair of sufficient strength for secure IPsec. In this 1245 case, the Admin needs to prove to the PKI that it has such a key 1246 pair; this is normally done by the PKI sending the Admin a nonce, 1247 which the Admin signs and returns to the PKI along with the end 1248 entity�s public key. 1250 This enrollment mode is depicted in Figure 11 and the letters in the 1251 following description refer to Figure 3. Prior authorization (see 1252 paragraph 3.2) and generation (see paragraph 3.3.2) steps are not 1253 shown. 1255 IPsec Certificate Management Profile 1257 +--------------+ +-----------------------+ 1258 | Repository | | CA/RA | 1259 +--------------+ +-----------------------+ 1260 ^ 1,5 1261 | 1262 | 1263 v 2,6 1264 4 +-------+ 1265 +->| Admin | 1266 | +-------+ 1267 | 1268 | 1269 3,7 v 1270 +--------------------+ +--------+ 1271 | IPsec | | IPsec | 1272 | Peer 1 | | Peer 2 | 1273 +--------------------+ +--------+ 1275 Figure 11. VPN-PKI Interaction Steps: 1276 IPsec Peer Generates Keys, Admin Constructs and 1277 Signs PKC Request, Enrolls Through Admin 1279 1) Enrollment [E]. The Admin requests a PKC from the PKI, providing 1280 the generated public key. 1282 2) Enrollment Response [E]. The PKI responds to the enrollment 1283 request, providing either the new PKC that was generated or a 1284 suitable error indication. 1286 3) Opaque Transaction [E]. The Admin forwards the enrollment response 1287 back to the IPsec Peer. 1289 4) Opaque Transaction [E]. Peer positively acknowledge receipt of new 1290 PKC back to the Admin. 1292 5) Enrollment Confirmation [E]. Admin forwards enrollment 1293 confirmation back to the PKI. 1295 6) Enrollment Confirmation Receipt [E]. PKI sends enrollment 1296 confirmation receipt back to the Admin. 1298 7) Opaque Transaction [E]. Admin forwards PKI's enrollment 1299 confirmation receipt back to the Peer. 1301 IPsec Certificate Management Profile 1303 3.4.8 Enrollment Method 3a: Admin Authorizes and Enrolls Directly to 1304 PKI 1306 In this case, the Admin generates the key pair, PKC request, and 1307 digitally signs the PKC request. The PKI System does not care where 1308 the enrollment comes from, as long as it is a valid enrollment. Once 1309 the Admin retrieves the PKC, it then automatically forwards it to the 1310 IPsec Peer along with the key pair. 1312 Some IPsec Systems do not have enough CPU power to generate a public 1313 and private key pair of sufficient strength for secure IPsec. In this 1314 case, the Admin needs to prove to the PKI that it has such a key 1315 pair; this is normally done by the PKI sending the Admin a nonce, 1316 which the Admin signs and returns to the PKI along with the end 1317 entity�s public key. 1319 This enrollment mode is depicted in Figure 12 and the letters in the 1320 following description refer to Figure 3. Prior authorization (see 1321 paragraph 3.2) and generation (see paragraph 3.3.3) steps are not 1322 shown. 1324 IPsec Certificate Management Profile 1326 +--------------+ +-----------------------+ 1327 | Repository | | CA/RA | 1328 +--------------+ +-----------------------+ 1329 ^ 1,5 1330 | 1331 | 1332 v 2,6 1333 4 +-------+ 1334 +->| Admin | 1335 | +-------+ 1336 | 1337 | 1338 3,7 v 1339 +--------------------+ +--------+ 1340 | IPsec | | IPsec | 1341 | Peer 1 | | Peer 2 | 1342 +--------------------+ +--------+ 1344 Figure 12. VPN-PKI Interaction Steps: 1345 Admin Generates Keys, PKC Request, and Enrolls Directly 1346 with PKI 1348 1) Enrollment [E]. The Admin requests a PKC from the PKI, providing 1349 the generated public key. 1351 2) Enrollment Response [E]. The PKI responds to the enrollment 1352 request, providing either the new PKC that was generated or a 1353 suitable error indication. 1355 3) Opaque Transaction [E]. The Admin forwards the enrollment response 1356 back to the IPsec Peer, along with the keys. 1358 4) Opaque Transaction [E]. Peer positively acknowledge receipt of new 1359 PKC back to the Admin. 1361 5) Enrollment Confirmation [E]. Admin forwards enrollment 1362 confirmation back to the PKI. 1364 6) Enrollment Confirmation Receipt [E]. PKI sends enrollment 1365 confirmation receipt back to the Admin. 1367 7) Opaque Transaction [E]. Admin forwards PKI's enrollment 1368 confirmation receipt back to the Peer. 1370 IPsec Certificate Management Profile 1372 3.4.9 Enrollment Method 3b: Admin Authorizes and Enrolls Directly to 1373 PKI 1375 In this instance, the PKI and Admin have previously agreed to have 1376 the PKI generate key and certificates when the PKI receives an 1377 authorization request. The PKI returns to the IPsec Peer through the 1378 Admin, the final product of a key pair and PKC. Again, the mechanism 1379 for the Peer to Admin communication is opaque. 1381 This enrollment mode is depicted in Figure 13 and the letters in the 1382 following description refer to Figure 3. Prior authorization (see 1383 paragraph 3.2) and generation (see paragraph 3.3.4) steps are not 1384 shown. 1386 IPsec Certificate Management Profile 1388 +--------------+ +-----------------------+ 1389 | Repository | | CA/RA | 1390 +--------------+ +-----------------------+ 1391 ^ 4 1392 | 1393 | 1394 v 1,5 1395 3 +-------+ 1396 +->| Admin | 1397 | +-------+ 1398 | 1399 | 1400 2,6 v 1401 +--------------------+ +--------+ 1402 | IPsec | | IPsec | 1403 | Peer 1 | | Peer 2 | 1404 +--------------------+ +--------+ 1406 Figure 13. VPN-PKI Interaction Steps: 1407 PKI Generates Keys, 1409 1) Enrollment Response [E]. The PKI responds to the authorization 1410 request sent, providing either the new PKC and public-private key 1411 pair that were generated or a suitable error indication. 1413 2) Opaque Transaction [E]. The Admin forwards the enrollment response 1414 back to the IPsec Peer, along with the keys. 1416 3) Opaque Transaction [E]. Peer positively acknowledge receipt of new 1417 PKC back to the Admin. 1419 4) Enrollment Confirmation [E]. Admin forwards enrollment 1420 confirmation back to the PKI. 1422 5) Enrollment Confirmation Receipt [E]. PKI sends enrollment 1423 confirmation receipt back to the Admin. 1425 6) Opaque Transaction [E]. Admin forwards PKI's enrollment 1426 confirmation receipt back to the Peer. 1428 IPsec Certificate Management Profile 1430 3.4.10 Confirmation Handshake 1432 Any time a new PKC is issued by the PKI, a confirmation of PKC 1433 receipt MUST be sent back to the PKI by the Peer or the Admin 1434 (forwarding the Peer�s confirmation). 1436 Operationally, the Peer MUST send a confirmation to the PKI verifying 1437 that it has received the PKC, loaded it, and can use it effectively 1438 in an IKE exchange. This requirement exists so that: 1440 - The PKI does not publish the new PKC in the repository for others 1441 until that PKC is able to be used effectively by the Peer, and; 1443 - A revocation may be invoked if the PKC is not received and 1444 operational within an allowable window of time. 1446 To assert such proof the Peer MUST sign a portion of data with the 1447 new key. The result MUST be sent to the PKI. The entity that actually 1448 sends the result to the PKI MAY be either the Peer (sending it 1449 directly to the PKI) or Admin (the Peer would send it to Admin, and 1450 Admin can in turn send it to the PKI). 1452 The Admin MUST acknowledge the successful receipt of the 1453 confirmation, thus signaling to the Peer that it may proceed using 1454 this PKC in IKE connections. The PKI MUST complete all processing 1455 necessary to enable the Peer�s operational use of the new PKC (for 1456 example, writing the PKC to the repository) before sending the 1457 confirmation acknowledgement. The Peer MUST NOT begin using the PKC 1458 until the PKI�s confirmation acknowledgement has been received. 1460 IPsec Certificate Management Profile 1462 3.4.11 Error Handling for Enrollment 1464 Thorough error condition descriptions and handling instructions are 1465 REQUIRED for each transaction in the enrollment process. Providing 1466 such error codes will greatly aid interoperability efforts between 1467 the PKI and IPsec products. 1469 The profile will clarify what happens if the request and retrieval 1470 fails for some reason. The following cases MUST be covered: 1472 - Admin or Peer cannot send the request. 1474 - Admin or Peer sent the request but the PKI did not receive the 1475 request. 1477 - PKI received the request but could not read it effectively. 1479 - PKI received and read the request, but some contents of the 1480 request violated the PKI�s configured policy such that the PKI 1481 was unable to generate the PKC. 1483 - The PKI System generated the PKC, but could not send it. 1485 - The PKI sent the PKC, but the requestor (Admin or Peer) did not 1486 receive it. 1488 - The Requestor (Admin or Peer) received the PKC, but could not 1489 process it due to incorrect contents, or other PKC-construction- 1490 related problem. 1492 - The Requestor failed trying to generate the confirmation. 1494 - The Requestor failed trying to send the confirmation. 1496 - The Requestor sent the confirmation, but the PKI did not receive 1497 it. 1499 - The PKI received the confirmation but could not process. 1501 In each case the following questions MUST be addressed: 1503 - What does Peer do? 1504 - What does Admin do? 1505 - What does PKI do? 1506 - Is Authorization used? 1508 If a failure occurs after the PKI sends the PKC and before the Peer 1509 receives it, then the Peer MUST re-request with the same 1510 authorization ID and one-time authorization token, and the PKI, 1511 IPsec Certificate Management Profile 1513 seeing the authorization ID and authorization token, MUST send the 1514 PKC again. 1516 Enrollment errors MUST be sent to the Admin regardless of entity that 1517 generated the enrollment request. 1519 3.5 Lifecycle 1521 This section refers to the [L] elements labeled in Figure 3. 1523 Once the PKI has issued a PKC for the end entity Peer, the Peer MUST 1524 be able to either contact the PKI directly or through the Admin for 1525 any subsequent renewals, updates, rekeys, or revocations. The PKI 1526 MUST support either case for renewals, updates, and revocations. 1527 Rekeys are Admin initiated therefore Peer initiated rekeys MUST be 1528 transferred via the Admin. 1530 3.5.1 One Protocol 1532 One protocol MUST be specified for rekey, renew, and update 1533 requests, responses, and confirmations. It MUST be the same protocol 1534 as is specified in paragraph 3.4. 1536 Revocation requests MAY use the same protocol as rekey, renew, and 1537 update operations. Revocation requests MAY also occur via email, 1538 telephone, Instant Messaging, etc. 1540 3.5.2 PKC Rekeys, Renewals, and Updates 1542 Renewals, updates, and rekeys are variants of a PKC enrollment 1543 request scenario with unique operational and management requirements. 1545 - A PKC rekey replaces an end entity's PKC with a new PKC that has a 1546 new public key for the same SubjectName and SubjectAltName 1547 contents before the end entity�s currently held PKC expires. 1549 - A PKC renewal replaces an end entity's PKC with the same public key 1550 for the same SubjectName and SubjectAlternativeName contents as 1551 an existing PKC before that PKC expires. 1553 - A PKC update is defined as a new PKC issuance with the same public 1554 key for an altered SubjectName or SubjectAlternativeName before 1555 expiration of the end entity�s current PKC. 1557 IPsec Certificate Management Profile 1559 When sending renew, update, or rekey requests, the entire contents of 1560 the PKC request needs to be sent to the PKI, not just the changed 1561 elements. 1563 The renew, update and rekey requests MUST be signed by the private 1564 key of the old PKC. This will allow the PKI to verify the identity of 1565 the requestor, and ensure that an attacker does not submit a request 1566 and receive a PKC with another end entity�s identity. 1568 Whether or not a new key is used for the new PKC in a renew or update 1569 scenario is a matter of local security policy, and MUST be specified 1570 by the Admin to the PKI in the original authorization request. Re- 1571 using the same key is permitted, but not encouraged. If a new key is 1572 used, the update or renew request must be signed by both the old key 1573 -- to prove the right to make the request -- and the new key -- to 1574 use for the new PKC. 1576 The new PKC resulting from a renew, update or rekey will be retrieved 1577 in-band, using the same mechanism as a new PKC request. 1579 For the duration of time after a renew, update, or rekey has been 1580 processed and before PKI has received confirmation of the Peer�s 1581 successful receipt of the new PKC, both PKCs (the old and the new) 1582 for the end entity will be valid. This will allow the Peer to 1583 continue with uninterrupted IKE connections with the previous PKC 1584 while the renewal, update, or rekey process occurs. 1586 After the renewal, update or rekey occurs, the question now exists 1587 for the PKI of what to do about the old PKC. If the old PKC is to be 1588 made unusable, the PKI will need to add it to the revocation list, 1589 removed from the repository; however this should only occur once all 1590 connections that used the old PKC have expired. The decision about if 1591 the old PKC should be made unusable is a decision of local policy. 1592 Either the PKI or the Admin MUST specify this parameter during the 1593 authorization phase. In this case, the specifying party, either the 1594 Admin or the PKI, MUST also specify during authorization the length 1595 of time after the PKI receives the end entity Peer�s confirmation (of 1596 receipt of the PKC) that will pass before the old PKC is made 1597 unusable. 1599 In the case where the new keys were generated for a renew or update 1600 request and for rekey requests, once the Peer receives the 1601 confirmation acknowledgement from the PKI, it is good practice for 1602 the old key pair to be destroyed as soon as possible. Deletion can 1603 occur once all connections that used the old PKC have expired. 1605 If a PKC has been revoked, it MUST NOT be allowed a renewal, update 1606 or rekey. 1608 IPsec Certificate Management Profile 1610 Should the PKC expire without renewal, update or rekey, an entirely 1611 new request MUST be made. 1613 3.5.2.1 Rekey Request 1615 Admins manage rekeys to ensure uninterrupted use of the VPN by Peers 1616 with new keys. Rekeys can occur automatically if the Admin is 1617 configured to initiate a new authorization for the rekey. 1619 Scenarios for rekey are omitted as they use the same scenarios used 1620 in the original PKC enrollment from sections 3.2, 3.3, and 3.4. 1622 3.5.2.1 Renew Request 1624 Admins manage renewals to ensure uninterrupted use of the VPN by 1625 Peers with the same key pair. 1627 At the time of authorization, certain details about renewal 1628 acceptance will be conveyed by the Admin to the PKI, as stated in 1629 section 3.2.4.2. The renewal request MUST match the conditions that 1630 were specified in the original authorization for: 1632 - Keys: New, existing, or either 1633 - Requestor: End entity Peer, Admin, either 1634 - Period: How soon before PKC expiry. 1635 - Time: Length of time before making the old PKC unusable. 1637 If any of these conditions are not met, the PKI must reject the 1638 renewal and log the event. 1640 Scenarios for renewal are omitted as they use the same scenarios used 1641 in the original PKC enrollment from sections 3.2, 3.3, and 3.4. 1643 3.5.2.2 Update Request 1645 An update to the contents of a PKC will be necessary when details 1646 about an end entity Peer�s identity change, but the Operator does not 1647 want to generate a new PKC from scratch, requiring a whole new 1648 authorization. For example, a gateway device may be moved from one 1649 site to another. Its IPv4 Address will change in the SubjectAltName 1650 extension, but all other information could stay the same. Another 1651 example is an end user who gets married and changes the last name or 1652 moves from one department to another. In either case, only one field 1653 (the Surname or OU in the DN) need change. 1655 IPsec Certificate Management Profile 1657 An update differs from renewal and rekeys in a few ways: 1659 - A new key is not necessary 1661 - The timing of the update event is not predictable, as is the case 1662 with a scheduled renewal or rekey 1664 - The update request may occur at any time during a PKC�s period of 1665 validity 1667 - Once the update is completed, and the new PKC is confirmed, the 1668 old PKC should cease to be usable, as its contents no longer 1669 accurately describe the subject 1671 At the time of authorization, certain details about update acceptance 1672 can be conveyed by the Admin to the PKI, as stated in section 1673 3.2.4.2. The update request MUST match the conditions that were 1674 specified in the original authorization for: 1676 - Keys: new or existing or either 1677 - Requestor: End entity Peer, Admin, either 1678 - The fields in the Subject and SubjectAltName that are changeable 1679 - Length of time before making the old PKC unusable 1681 If any of these conditions are not met, the PKI MUST reject the 1682 update and log the event. 1684 If an update authorization was not made at the time of original 1685 authorization, one can be made from Admin to the PKI at any time 1686 during the PKC�s valid life. When such an update is desired, Admin 1687 must notify the PKI System that an update is authorized for the end 1688 entity, and to expect it coming, and specify the new contents. Admin 1689 then initiates the update request with the given contents in whatever 1690 mechanism the VPN System employs (direct from end entity to PKI, from 1691 end entity through Admin, or directly from Admin). 1693 Scenarios for update are omitted as they use the same scenarios used 1694 in the original PKC enrollment from sections 3.2, 3.3, and 3.4. 1696 3.5.2.3 Error Handling for Rekey, Renewal, and Update 1698 Thorough error condition descriptions and handling instructions are 1699 required for each transaction in the renewal, update or rekey 1700 process. Providing such error codes will greatly aid interoperability 1701 efforts between the PKI and IPsec products. 1703 IPsec Certificate Management Profile 1705 3.5.2.4 Confirmation Handshakes 1707 The confirmation handshake requirements are the same as in clauses 1708 3.2, 3.3, and 3.4 except that depending on the Adminitrative policy 1709 the PKI MUST also issue a revocation on the original PKC before 1710 sending the confirmation response. 1712 3.5.3 Revocation 1714 The Peer MUST be able to initiate revocation for its own PKC. In this 1715 case the revocation request MUST be signed by the Peer�s current key 1716 pair for the PKC it wishes to revoke. Whether the actual revocation 1717 request transaction occurs directly with the PKI or is first sent to 1718 Admin who proxies or forwards the request to the PKI is a matter of 1719 implementation. 1721 The Admin MUST be able to initiate revocation for any PKC issued 1722 under a template it controls. The Admin will identify itself to the 1723 PKI by use of its own PKC; it MUST sign any revocation request to the 1724 PKI with the private key from its own PKC. The PKI MUST have the 1725 ability to configure Admin(s) with revocation authority, as 1726 identified by its PKC. Any PKC authorizations must specify if said 1727 PKC may be revoked by the Admin (see section 3.2.3.2 for more 1728 details). 1730 The profile MUST identify the one protocol or transaction within a 1731 protocol to be used for both Peer and Admin initiated revocations. 1733 The profile MUST identify the size of CRL the client will be prepared 1734 to support. 1736 Below are guidelines for revocation in specific transactions: 1738 - AFTER RENEW, BEFORE EXPIRATION: The PKI MUST be responsible for 1739 the PKC revocation during a renew transaction. PKI MUST revoke 1740 the PKC after receiving the confirm notification from the Peer, 1741 and before sending the confirm-ack to the Peer. The Peer MUST 1742 NOT revoke its own PKC in this case. 1744 - AFTER UPDATE, BEFORE EXPIRATION: The PKI MUST be responsible for 1745 the PKC revocation during an update transaction. PKI MUST revoke 1746 the PKC after receiving the confirm notification from the Peer, 1747 and before sending the confirm-ack to the Peer. The Peer MUST 1748 NOT revoke its own PKC in this case. 1750 IPsec Certificate Management Profile 1752 3.6 Repositories 1754 This section refers to the [R] elements labeled in Figure 3. 1756 3.6.1 Lookups 1758 The PKI System SHOULD be built so that lookups resolve directly and 1759 completely at the URL indicated in a CDP or AIA. The PKI SHOULD be 1760 built such that URL contents do not contain referrals to other hosts 1761 or URLs, as such referral lookups will increase the time to complete 1762 the IKE negotiation, and can cause implementations to timeout. 1764 CDP MUST be flagged as required in the authorization request. The 1765 method MUST also be specified: the HTTP method MUST be method; the 1766 LDAP method MAY be supported. 1768 The complete hierarchical PKC chain (except the trust anchor) MUST be 1769 able to be searched in their respective repositories. The information 1770 to accomplish these searches MUST be adequately communicated in the 1771 PKCs sent during the IKE transaction. 1773 All PKCs must be retrievable through a single protocol. The final 1774 specification will identify one protocol as a "MUST", others MAY be 1775 listed as "OPTIONAL". 1777 The general requirements for the retrieval protocol include: 1779 - The protocol can be easily Firewalled (including NAT or PAT). 1781 - The protocol can easily perform some query against a remote 1782 repository on a specific ID element that was given to it in a 1783 standard PKC field. 1785 Other considerations include: 1787 - Relative speed 1788 - Relative ease of administration 1789 - Scalability 1791 Intermediate PKCs will be needed for the case of re-keying of the CA, 1792 or a PKI System where multiple CAs exist. 1794 PKCs MAY have extendedKeyusage to help identify the proper PKC for 1795 IPsec, though the default behavior is to not use them (see 3.1.5.3). 1797 IPsec Peers MUST be able to resolve Internet domain names and support 1798 the mandatory repository access protocol at the time of starting up 1799 so they can perform the PKC lookups. 1801 IPsec Certificate Management Profile 1803 IPsec Peers should cache PKCs to reduce latency in setting up Phase 1804 1. Note that this is an operational issue, not an interoperability 1805 issue. 1807 The use case for accomplishing lookups when PKCs are not sent in IKE 1808 is a stated non-goal of the profile at this time. 1810 3.6.2 Error Handling for Repository Lookups 1812 Thorough error condition descriptions and handling instructions are 1813 required for each transaction in the repository lookup process. 1814 Providing such error codes will greatly aid interoperability efforts 1815 between the PKI and IPsec products. 1817 3.7 Trust 1819 3.7.1 Trust Anchor PKC Acquisition 1821 The root PKC MUST arrive on the Peer via one of two methods: 1823 (a) Peer can get the root PKC via its secure communication with 1824 Admin. This requires the Peer to know less about interaction with the 1825 PKI. 1827 (b) Admin can command Peer to retrieve the root cert directly from 1828 the PKI. How retrieval of the root cert takes place is beyond scope, 1829 but is assumed to occur via an unauthenticated but confidential 1830 enrollment protocol. 1832 3.7.2 Certification Path Validation 1834 The IPsec Peer MUST perform identity verification based on the fields 1835 of the PKC and parameters applicable to the VPN Security Association. 1836 The fields of the PKC used for verification MAY include either the 1837 X.500 Distinguished Name (DN) within the Subject Name, or a specific 1838 field within the Extension SubjectAltName (per [DOI] 4.6.2.1 1839 Identification Type Values). Usage descriptions for each follow. 1841 The Peers or a SCVP server MUST validate the certification path, as 1842 per RFC3280. The contents necessary in the PKC to allow this will be 1843 enumerated in the profile document. 1845 The Peer MAY have the ability to construct the certification path 1846 itself, however Admin MUST be able to supply Peers with the trust 1847 anchor and any chaining PKCs necessary. The Admin MAY ensure the 1848 IPsec Certificate Management Profile 1850 template uses the AIA extension in PKCs as a means of facilitating 1851 path validation. 1853 DNS MUST be supported by the Peers in order to support resolving URLs 1854 present in CDPs and AIA extensions. 1856 3.7.3 Revocation Checking and Status Information 1858 The PKI System MUST provide a mechanism whereby Peers can check the 1859 revocation status of PKCs that are presented to it for IKE identity. 1860 The mechanism should allow for access to extremely fresh revocation 1861 information. CRLs have been chosen as the mechanism for communicating 1862 this information. Operators are RECOMMENDED to refresh CRLs as often 1863 as logistically possible. 1865 A single mandatory protocol mechanism for performing CRL lookups MUST 1866 be specified by the final specification. 1868 All PKCs used in IKE MUST have cRLDistributionPoint and 1869 authorityInfoAccess fields populated with valid URLs. This will allow 1870 all recipients of the PKC to know immediately how revocation is to be 1871 accomplished, and where to find the revocation information. The AIA 1872 is needed in an environment where multiple layers of CAs exist and 1873 for the case of a CA key roll-over. 1875 IPsec Systems have an OPTION to turn off revocation checking. Such 1876 may be desired when the two Peers are communicating over a network 1877 without access to the CRL service, such as at a trade show, in a lab, 1878 or in a demo environment. If revocation checking is OFF, the 1879 implementation MUST proceed to use the PKC as valid identity in the 1880 exchange and need not perform any check. 1882 If the revocation of a PKC is used as the only means of deactivation 1883 of access authorization for the Peer (or user), then the speed of 1884 deactivation will be as rapid as the refresh rate of the CRL issued 1885 and published by the PKI. If more immediate deactivation of access is 1886 required than the CRL refreshing can provide, then another mechanism 1887 for authorization that provides more immediate access deactivation 1888 should be layered into the VPN deployment. Such a second mechanism is 1889 out of the scope of this profile. (Examples are Xauth, L2TP�s 1890 authentication, etc.). 1892 3.7.4 Error Handling in Revocation Checking and Certificate Path 1893 Validation 1895 Thorough error condition descriptions and handling instructions are 1896 required for each transaction in the revocation checking and path 1897 IPsec Certificate Management Profile 1899 validation process. Providing such error codes will greatly aid 1900 interoperability efforts between the PKI and IPsec products. 1902 4 Security Considerations 1904 This requirements document does not specify a concrete solution, and 1905 as such has no system-related security considerations per se. 1906 However, the intent of the PKI4IPSEC WG was to profile and use 1907 concrete protocols for certificate management (e.g., CMC, CMS, 1908 CRMF). The individual security considerations of these protocols 1909 should be carefully considered in the profiling effort. 1911 In addition, this document allows significant flexibility in the 1912 allocation of functions between the roles of Peer and Admin. This 1913 functional allocation is crucial both to achieving successful 1914 deployment, and to maintaining the integrity of the PKI enrollment 1915 and management processes. However, much of the responsibility for 1916 this allocation necessarily falls to product implementers and system 1917 operators through the selection of applicable use cases and 1918 development of security policy constraints. These factors must be 1919 carefully considered to ensure the security of PKI4IPSEC certificate 1920 management. 1922 5 IANA Considerations 1924 There are no known numbers which IANA will need to manage. 1926 6 References 1928 6.1 Normative References 1930 None. 1932 6.2 Informative References 1934 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 1935 Requirement Levels", BCP 14, RFC 2119, March 1997. 1937 [CERTPROFILE] Housley, R., et. al. "Internet X.509 Public Key 1938 Infrastructure Certificate and Certificate Revocation List (CRL) 1939 Profile", RFC 3280, April 2002. 1941 [DOI] Piper, D., "Internet IP Security Domain of Interpretation for 1942 ISAKMP", RFC 2407, November 1998. 1944 IPsec Certificate Management Profile 1946 [FRAME] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu. S., 1947 "Internet X.509 Public Key Infrastructure: Certificate Policy and 1948 Certificate Practices Framework", RFC 3647, November 2003. 1950 [IKECERTPROFILE] Korver, B., �The Internet IP Security PKI Profile 1951 of IKEv1/ISAKMP, IKEv2, and PKIX�,draft-ietf-pki4ipsec-ikecert- 1952 profile-11, 25 September 2006. 1954 7 Acknowledgements 1956 This draft is substantially based on a prior draft draft-dploy- 1957 requirements-00 developed by Project Dploy. The principle editor of 1958 that draft was Gregory M. Lebovitz (NetScreen Technologies). 1959 Contributing authors included Lebovitz, Paul Hoffman (VPN 1960 Consortium), Hank Mauldin (Cisco Systems), and Jussi Kukkonen (SSH 1961 Communications Security). Substantial editorial contributions were 1962 made by Leo Pluswick (ICSA), Tim Polk (NIST), Chris Wells (SafeNet), 1963 Thomas Hardjono(VeriSign), Carlisle Adams (Entrust), and Michael 1964 Shieh (NetScreen). 1966 Once brought to pki4ipsec, the following people made substantial 1967 contributions: Jim Schaad and Stefan Santesson. 1969 Editor�s Address 1971 Chris Bonatti 1972 IECA, Inc. 1973 Bonattic(at)ieca.com 1975 Sean Turner 1976 IECA, Inc. 1977 Turners(at)ieca.com 1979 Gregory M. Lebovitz 1980 gregory.ietf(at)gmail.com 1981 IPsec Certificate Management Profile 1983 Intellectual Property Statement 1985 The IETF takes no position regarding the validity or scope of any 1986 Intellectual Property Rights or other rights that might be claimed 1987 to pertain to the implementation or use of the technology described 1988 in this document or the extent to which any license under such 1989 rights might or might not be available; nor does it represent that 1990 it has made any independent effort to identify any such rights. 1991 Information on the procedures with respect to rights in RFC 1992 documents can be found in BCP 78 and BCP 79. 1994 Copies of IPR disclosures made to the IETF Secretariat and any 1995 assurances of licenses to be made available, or the result of an 1996 attempt made to obtain a general license or permission for the use 1997 of such proprietary rights by implementers or users of this 1998 specification can be obtained from the IETF on-line IPR repository 1999 at http://www.ietf.org/ipr. 2001 The IETF invites any interested party to bring to its attention any 2002 copyrights, patents or patent applications, or other proprietary 2003 rights that may cover technology that may be required to implement 2004 this standard. Please address the information to the IETF at ietf- 2005 ipr@ietf.org. 2007 Disclaimer of Validity 2009 This document and the information contained herein are provided on 2010 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2011 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2012 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2013 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2014 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2015 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2017 Copyright Statement 2019 Copyright (C) The Internet Society (2006). This document is subject 2020 to the rights, licenses and restrictions contained in BCP 78, and 2021 except as set forth therein, the authors retain all their rights. 2023 Acknowledgment 2025 Funding for the RFC Editor function is currently provided by the 2026 Internet Society.