idnits 2.17.00 (12 Aug 2021) /tmp/idnits54835/draft-bonatti-pki4ipsec-profile-reqts-01.txt: 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 3667, Section 5.1 on line 14. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Expected the document's filename to be given on the first page, but didn't find any == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 41 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 386: '... implementations MAY support an actual...' RFC 2119 keyword, line 402: '... this way Admin MAY perform many RA-l...' RFC 2119 keyword, line 443: '... MUST be private, authenticated ...' RFC 2119 keyword, line 449: '... The Admin MUST be reachable by the ...' RFC 2119 keyword, line 483: '...y. An IPsec Peer MAY accept a PKC from...' (93 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 19, 2005) is 6330 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 section? 'STDPROCESS' on line 1952 looks like a reference -- Missing reference section? 'CERTPROFILE' on line 1958 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 1955 looks like a reference -- Missing reference section? 'G' on line 1389 looks like a reference -- Missing reference section? 'I' on line 1418 looks like a reference -- Missing reference section? 'A' on line 1385 looks like a reference -- Missing reference section? 'E' on line 1395 looks like a reference -- Missing reference section? 'M' on line 1412 looks like a reference -- Missing reference section? 'R' on line 691 looks like a reference -- Missing reference section? 'DOI' on line 1962 looks like a reference -- Missing reference section? 'TBD' on line 1978 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 14 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-profile-reqts-01.txt Sean Turner, IECA 4 July 19, 2004 Gregory Lebovitz, Netscreen 5 Expires January 19, 2005 7 Requirements for an IPsec Certificate Management Profile 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of [STDPROCESS]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This informational document describes and identifies the requirements 37 for a profile of a certificate management protocol to handle Public 38 Key Certificate (PKC) lifecycle interactions between Internet 39 Protocol Secuity (IPsec) Virtual Private Network (VPN) Systems using 40 IKE (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. 41 These requirements are designed so that they meet the needs of 42 enterprise scale IPsec VPN deployments. It is intended that a 43 standards track profile will be created that fulfills these 44 requirements. 46 1 INTRODUCTION.....................................................3 47 1.1 SCOPE..........................................................4 48 1.2 NON-GOALS......................................................5 50 Bonatti, Turner, Lebovitz 1 51 IPsec Certificate Management Profile 53 1.3 DEFINITIONS....................................................5 54 1.4 REQUIREMENTS TERMINOLOGY.......................................7 55 2. ARCHITECTURE....................................................7 56 2.1 VPN SYSTEM.....................................................7 57 2.1.1 IPSEC PEER(S)................................................8 58 2.1.2 VPN ADMINISTRATION FUNCTION (ADMIN)..........................8 59 2.2 PKI SYSTEM.....................................................9 60 2.3 VPN-PKI INTERACTION...........................................10 61 2.3.1 NEW PKC.....................................................11 62 2.3.2 RENEWAL PKC.................................................13 63 2.3.3 REVOCATION..................................................14 64 3 REQUIREMENTS....................................................15 65 3.1 GENERAL REQUIREMENTS..........................................15 66 3.1.1 ONE PROTOCOL................................................15 67 3.1.2 SECURE TRANSACTIONS.........................................16 68 3.1.3 PKI AVAILABILITY............................................16 69 3.1.4 END-USER TRANSPARENCY.......................................16 70 3.1.5 ERROR HANDLING..............................................16 71 3.2 AUTHORIZATION TRANSACTIONS....................................17 72 3.2.1 BULK AUTHORIZATION..........................................17 73 3.2.2 PROTOCOL PREFERENCES FOR AUTHORIZATION......................17 74 3.2.3 ADMIN AUTHORIZATION REQUESTS TO PKI.........................17 75 3.2.3.1 SPECIFYING FIELDS WITHIN THE PKC..........................17 76 3.2.3.2 AUTHORIZATIONS FOR RENEWAL AND CHANGE.....................18 77 3.2.3.3 OTHER AUTHORIZATION ELEMENTS..............................19 78 3.2.4 CANCEL CAPABILITY...........................................20 79 3.2.5 PKI RESPONSE TO ADMIN.......................................20 80 3.2.6 ERROR HANDLING FOR AUTHORIZATION TRANSACTIONS...............21 81 3.3 KEY GENERATION AND PKC REQUEST CONSTRUCTION...................21 82 3.3.1 IPSEC PEER GENERATES KEY PAIR AND CONSTRUCTS REQUEST........21 83 3.3.2 IPSEC PEER GENERATES KEY PAIR, ADMIN CONSTRUCTS REQUEST.....21 84 3.3.3 ADMIN GENERATES KEY PAIR AND CONSTRUCTS REQUEST.............22 85 3.3.4 PKI GENERATES KEY PAIR AND PASSES TO PEER VIA ADMIN.........22 86 3.3.5 TRUST ANCHOR PKC ACQUISITION................................22 87 3.3.6 ERROR HANDLING FOR KEY GENERATION AND REQUEST CONSTRUCTION..23 88 3.4 ENROLLMENT (SENDING REQUEST AND PKC RETRIEVAL)................23 89 3.4.1 ONE PROTOCOL................................................23 90 3.4.2 ON-LINE PROTOCOL............................................23 91 3.4.3 SINGLE CONNECTION WITH IMMEDIATE RESPONSE...................23 92 3.4.4 MANUAL APPROVAL OPTION......................................24 93 3.4.5 ENROLLMENT METHOD 1: PEER ENROLLS TO PKI DIRECTLY...........24 94 3.4.6 ENROLLMENT METHOD 2: IPSEC PEER ENROLLS TO PKI THROUGH ADMIN24 95 3.4.7 ENROLLMENT METHOD 3: ADMIN ENROLLS TO THE PKI DIRECTLY......26 96 3.4.8 ENROLLMENT TYPE FIELD.......................................28 97 3.4.9 CONFIRMATION HANDSHAKE......................................28 98 3.4.10 FAILURE CASES..............................................29 99 3.5 PKC PROFILE FOR PKI INTERACTION...............................30 100 3.5.1 IDENTITY USAGE..............................................30 101 3.5.2 PATH VALIDATION.............................................31 102 3.5.3 KEYUSAGE....................................................31 103 3.5.4 EXTENDED KEY USAGE..........................................31 104 3.5.5 POINTER TO REVOCATION CHECKING..............................32 106 Bonatti, Turner, Lebowitz 2 107 IPsec Certificate Management Profile 109 3.6 PKC RENEWALS AND CHANGES......................................32 110 3.6.1 RENEW REQUEST FOR A NEW PKC (BEFORE EXPIRY).................33 111 3.6.2 CHANGE REQUEST FOR A NEW PKC................................34 112 3.6.3 ERROR HANDLING FOR RENEWAL AND CHANGE.......................35 113 3.7 FINDING PKCS IN REPOSITORIES..................................35 114 3.7.1 ERROR HANDLING FOR REPOSITORY LOOKUPS.......................36 115 3.8 REVOCATION ACTION.............................................36 116 3.9 REVOCATION CHECKING AND STATUS INFORMATION....................37 117 3.9.1 ERROR HANDLING IN REVOCATION CHECKING.......................38 118 4. SECURITY CONSIDERATIONS........................................38 119 A REFERENCES......................................................38 120 A.1 NORMATIVE REFERENCES..........................................38 121 A.1 NON-NORMATIVE REFERENCES......................................38 122 B. ACKNOWLEDGEMENTS...............................................38 123 C. EDITOR'S ADDRESS...............................................39 124 D. SUMMARY OF REQUIREMENTS........................................39 125 E. CHANGE HISTORY.................................................39 127 1 Introduction 129 This document enumerates requirements for PKC management interaction 130 among different IPsec VPN products and PKI products in order to 131 better enable large scale, PKI-supported IPsec VPN deployments. 132 Requirements for both the IPsec and the PKI products are discussed. 133 The goal is to create a set of requirements from which a profile 134 document will be derived. The specification will clarify the 135 transactions necessary between the VPN System and the PKI System that 136 enable the deployment of easily manageable, easily scalable VPNs. 137 When implemented, the specification will enable improved 138 interoperability between IPsec and PKI products. The requirements are 139 carefully designed to achieve security without compromising ease of 140 management and deployment, even where the deployment involves tens of 141 thousands of IPsec users and devices. 143 Within IPsec VPNs, the PKI supports authentication of IPSec Peers 144 through digital signatures during security association establishment 145 using IKE. The protocol and PKI operational usages are considered in 146 order to define a common, single set of methods (which forces 147 interoperability) between PKI Systems and VPN Systems for large-scale 148 deployments. The requirements address the entire lifecycle for PKI 149 usage within IPsec transactions: pre-authorization of PKC issuance, 150 enrollment process (PKC request and retrieval), PKC renewals and 151 changes, revocation, validation and repository lookups. They enable a 152 VPN Operator to: 154 - Authorize individual or batches of PKC issuances based on locally 155 defined criteria, and do so from the VPN Administration point. 157 - Provision PKI-based user or machine identity to IPsec Peers, on a 158 large scale. Provision means the IPsec Peer ends up with a valid 159 public and private key pair and PKC based on the IETF Public Key 161 Bonatti, Turner, Lebowitz 3 162 IPsec Certificate Management Profile 164 Infrastructure X.509 (PKIX) PKC profile from [CERTPROFILE]. 165 These are used in the IKE negotiation for tunnel setup. 167 - Set the corresponding gateway or client authorization policy for 168 remote access and site-to-site connections. 170 - Establish automatic renewal for PKCs, or changes. 172 - Ensure timely revocation information is available for PKCs used 173 in IKE exchanges. 175 The desired outcome is that both IPSec and PKI vendors create 176 interoperable products to enable such scalable deployments, and do so 177 as quickly as possible. For example, an VPN Operator should be able 178 to use any conforming IPsec implementation of the certificate 179 management profile with any conforming PKI vendor's implementation to 180 perform the VPN rollout and management as described below. 182 The certificate management profile will also clarify and constrain 183 existing PKIX and IPsec standards and protocols for easier 184 understanding and the limiting of complexity in deployment. Some new 185 elements are identified that may require either a new protocol, or 186 changes or extensions to an existing protocol, especially in the area 187 of bulk authorization for PKC issuance. The document introduces the 188 idea of a VPN Administration function (Admin) within the VPN System. 189 This VPN Administration function bears great responsibility for the 190 task of managing pre-authorization for PKC issuance and of 191 distributing the results between the VPN System and the PKI System. 193 1.1 Scope 195 The solution described in this document focuses on the requirements 196 for the interaction between the VPN Systems and the PKI Systems. The 197 internals of the operation of these systems are beyond scope. 199 The solution focuses on the needs of large-scale rollouts, i.e. VPNs 200 including hundereds or thousands of managed VPN gateways or VPN 201 remote access clients. The needs of small deployments are a stated 202 non-goal, however service providers employing the scoped solution and 203 applying it to many smaller deployments in aggregate may address 204 them. 206 Gateway-to-gateway access and end-user remote access (to a gateway) 207 are both covered. End-to-end communications are not necessarily 208 excluded but are intentionally not a focus. 210 There is no intention to discuss all or other PKI issues here. The 211 scope is limited to requirements for easing and enabling scalable 212 IPsec with PKI deployments. 214 Bonatti, Turner, Lebowitz 4 215 IPsec Certificate Management Profile 217 The requirements strive to meet eighty percent of the market needs 218 for large-scale deployments. Environments will understandably exist 219 in which large-scale deployment tools are desired, but local security 220 policy stringency will not allow for the use of such commercial 221 tools. The solution will possibly miss the needs of the highest ten 222 percent of stringency and lowest ten percent of convenience 223 requirements. Use cases will be considered or rejected based upon 224 this eighty percent rule. 226 1.2 Non-Goals 228 The scenario for PKC cross-certification will not be addressed. 230 The specification for the communication method and transactions 231 between VPN Administration function and IPSec Peers is up to vendor 232 implementation and therefore is not expected to be included in the 233 certificate management profile. Such a protocol may be standardized 234 at a later date to enable interoperability between VPN Administration 235 function stations and IPsec Peers from different vendors, but is far 236 beyond the scope of this current effort, and will be considered 237 opaque by the certificate management profile. 239 1.3 Definitions 241 VPN System 242 The VPN System is comprised of the VPN Admininistration function 243 (defined below), the IPsec Peers, and the communication mechanism 244 between the VPN Administration and the IPsec Peers. VPN System is 245 defined in more detail in section 2.1. 247 PKI System 248 The PKI System, or simply PKI, is the set of functions needed to 249 authorize and issue PKCs and provide revocation information about 250 those PKCs. PKI System is defined in more detail in section 2.2. 252 (VPN) Operator 253 The Operator is the person or group of people that define security 254 policy and configure the VPN System to enforce that policy. 256 IPsec Peer (Gateway or Client) 257 For the purposes of this document, an IPsec Peer, or simply "Peer", 258 is any IPsec System that communicates IKE and IPsec to another Peer 259 in order to create a secure tunnel for communications. It can be 260 either a traditional security gateway (with two network interfaces, 261 one for the protected network and one for the unprotected network), 262 or it can be an IPsec client (with a single network interface). In 263 both cases, the IPsec System can pass traffic with no IPsec 264 protection, and can add IPsec protection to chosen traffic streams. 266 (VPN) Admin 268 Bonatti, Turner, Lebowitz 5 269 IPsec Certificate Management Profile 271 The function of the VPN System that manages and distributes policy to 272 Peers and who interacts with the PKI System to define policy for PKC 273 provisioning for the VPN connections. See Section 2.1.1 below for 274 more details. 276 End Entity 277 An end entity is the entity or subject that a PKC exists to 278 authenticate. The end entity is the one entity that will finally use 279 a private key associated with a PKC to sign data. In this document, 280 the end entity is also an IPsec Peer. 282 Community Realm 283 A community realm is the set of IPsec Peers and VPN Administration 284 function that operate under a common policy, and PKI authorizations. 286 PKC Renewal 287 The acquisition of a new PKC (often accompanied by a new key) due to 288 the expiration of an existing PKC. Renewal occurs prior to the 289 expiration of the existing PKC to avoid any connection outages. 291 PKC Change 292 A special case of a renewal; like occurrence where a PKC needs to be 293 changed prior to expiration due to some change in its subject's 294 information. Examples might include change in the address or 295 identifying information of the end entity. 297 Registration Authority (RA) 298 An optional entity in a PKI System given responsibility for 299 performing some of the administrative tasks necessary in the 300 registration of end entities, such as confirming the subject's 301 identity and verifying that the subject has possession of the private 302 key associated with the public key requested for a PKC. 304 Certificate Authority (CA) 305 An authority in a PKI System trusted by one or more users to create 306 and assign PKCs. It is important to note that the CA is responsible 307 for the PKCs during their whole lifetime, not just for issuing them. 309 Repository 310 An Internet-accessible server in a PKI System that stores and makes 311 available for retrieval PKCs and Certificate Revocation Lists (CRLs). 313 Root CA/Trust Anchor 314 A CA that is directly trusted by an end entity; that is, securely 315 acquiring the value of a Root CA public key requires some out-of-band 316 step(s). This term is not meant to imply that a Root CA is 317 necessarily at the top of any hierarchy, simply that the CA in 318 question is trusted directly. 320 Certificate Revocation List (CRL) 321 A CRL is a time stamped list identifying revoked PKCs that is signed 322 by a CA and made freely available in a public repository. Peers 324 Bonatti, Turner, Lebowitz 6 325 IPsec Certificate Management Profile 327 retrieve the CRL to verify that a PKC being presented to them as 328 identity in an IKE transaction has not been revoked. 330 CRL Distribution Point (CDP) 331 The CDP extension in a PKC identifies the location from which end 332 entities should retrieve CRLs to perform local validity checking. 334 Authority Info Access (AIA) 335 The AIA extension in a PKC indicates how to access CA information and 336 services for the issuer of the PKC in which the extension appears. 337 Information and services may include on-line validation services and 338 Certificate Policy (CP) data. 340 1.4 Requirements Terminology 342 Though this document is not an Internet Draft, we use the convention 343 that the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 344 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 345 this document are to be interpreted as described in [MUSTSHOULD]. 347 2. Architecture 349 This section describes the overall architecture for a PKI-supported 350 IPsec VPN deployment. First an explanation of the VPN System is 351 presented. Second, key points about the PKI System are stated. Third, 352 the architecture picture is presented. Last, the process of the 353 interaction between the two Systems for large-scale deployment is 354 described. 356 2.1 VPN System 358 The VPN System consists of the IPsec Peers and the VPN Administration 359 function, as depicted in Figure 1. 361 Bonatti, Turner, Lebowitz 7 362 IPsec Certificate Management Profile 364 +---------------------------------------------------+ 365 | | 366 | +----------+ | 367 | | VPN | | 368 | +---------->| Admin |<-------+ | 369 | | | Function | | | 370 | | +----------+ | | 371 | v v | 372 | +---------+ +---------+ | 373 | | IPsec | | IPsec | | 374 | | Peer 1 |<=======================>| Peer 2 | | 375 | +---------+ +---------+ | 376 | | 377 | VPN System | 378 +---------------------------------------------------+ 380 Figure 1: VPN System 382 2.1.1 IPsec Peer(s) 384 The Peers are two entities between which the Operator requires an 385 IPsec tunnel establishment. Two Peers are shown in Figure 1, but 386 implementations MAY support an actual number in the hundreds or 387 thousands. The Peers could be either gateway-to-gateway, remote- 388 access-host-to-gateway, or a mix of both. The Peers authenticate 389 themselves in the IKE negotiation using digital signatures through a 390 PKI System. 392 2.1.2 VPN Administration Function (Admin) 394 This document defines the notion of a VPN Administration function, 395 hereafter referred to as Admin, and gives the Admin great 396 responsibility within the solution. The Admin is a centralized 397 function. It defines the VPN System policy and informs the PKI and 398 Peers how it wants each to enforce that policy. One main role defined 399 here is that Admin specifies to the PKI the contents and use 400 parameters of the credentials the PKI will issue, or at least 401 references a template or policy-set for a Peer or set of Peers. In 402 this way Admin MAY perform many RA-like functions, for example 403 authorization of PKC issuance and revocation. 405 It is important to note that, within this document, Admin is neither 406 a device nor a person, rather it is a function. Every large-scale VPN 407 deployment will contain the Admin function. The function may be 408 performed on a stand-alone work station, on a gateway, on an 409 administration software component, etc. It is also possible for the 410 Admin function to be one in the same as the gateway or client device 411 or software. They are represented in the architectural diagram below 412 as different functions, but they need not be different physical 413 entities. As such, Admin's architecture and the means by which it 414 interacts with the participating IPsec Peers will vary widely from 416 Bonatti, Turner, Lebowitz 8 417 IPsec Certificate Management Profile 419 implementation to implementation. However some basic functions of the 420 Admin are assumed. 422 - It will be the place where Certificate Policy (CP) (see RFC 3647) 423 for use in the VPN is defined, not the PKI. In VPN Systems the 424 Operator chooses to strengthen the VPN by using PKI; PKI is a 425 bolt-on to the VPN System. The PKC characteristics and contents 426 are a function of the local security policy the VPN serves to 427 enforce. Therefore the Operator will configure policy and 428 contents for PKCs in the Admin, and apply those templates to 429 groups of IPsec Peers. 431 - It will interact directly with the PKI System to initiate 432 authorization for end entity PKCs by sending the parameters and 433 contents for those PKCs, or by referring to a template or 434 policy-set on the PKI. (Such templates would likely have been 435 created in conjunction with the Operator.) It will receive back 436 from the PKI identification values and authorization codes to be 437 used in the PKC requests for each of the pre-authorized PKCs. 439 - It will deliver instructions to the IPsec Peers, and the Peers 440 will carry out those instructions. An example of such an 441 instruction is an IKE policy configuration. Therefore, the 442 communication mechanism between the Admin and the IPsec Peers 443 MUST be private, authenticated and employ integrity checks. The 444 contents of some such instructions will be defined below. 445 However, the communication mechanism will be handled completely 446 within the VPN System and is out of the scope of this document 447 (see Scope, Section 1.1 above). 449 The Admin MUST be reachable by the Peers. Most implementations will 450 meet this requirement by ensuring the Peer can connect to the Admin 451 from anywhere on the network or Internet. However, communication 452 between the Admin and Peer may not necessarily be "on-line". It may, 453 in some environments, be "moving media," i.e. the configuration or 454 data may be loaded on to a floppy disk or other media and physically 455 moved to the IPsec Peer. This reality should be considered when 456 requirements are defined, and when supporting networks are 457 architected. 459 2.2 PKI System 461 The PKI System, as depicted in Figure 2, may be set up and operated 462 by the Operator (in-house), may be provided by third party PKI 463 providers to which connectivity is available at the time of 464 provisioning (managed PKI service), or may be integrated with the VPN 465 product. 467 Bonatti, Turner, Lebowitz 9 468 IPsec Certificate Management Profile 470 +---------------------------------------------+ 471 | +-------------------------+ | 472 | v | | 473 | +--------------+ v | 474 | | Repository | +----+ +----+ | 475 | | Certs & CRLs |<-> | CA |<->| RA | | 476 | +--------------+ +----+ +----+ | 477 | | 478 +---------------------------------------------+ 480 Figure 2: PKI System 482 This framework assumes that all components of the VPN will obtain 483 PKCs from a single PKI community. An IPsec Peer MAY accept a PKC from 484 a Peer that is from a CA outside of the PKI community, but the auto 485 provision and life cycle management for such a PKC or its trust 486 anchor PKC fall out of scope. 488 The PKI System will contain a mechanism for handling Admin's 489 authorization requests and PKC enrollments. These mechanisms are 490 referred to as the RA. The PKI System contains a Repository used by 491 the Peers to look up each other's PKCs. Last, the PKI System contains 492 the core function of a CA that uses a public and private key pair and 493 signs PKCs. 495 The PKI System SHOULD be built so that lookups resolve directly and 496 completely at the URL indicated in a CDP, or AIA. The PKI ought to be 497 built such that URL contents do not contain referrals to other hosts 498 or URLs, as such referral lookups will increase the time to complete 499 the IKE negotiation, and can cause implementations to timeout. 501 2.3 VPN-PKI Interaction 503 The interaction between the VPN System and the PKI System is the key 504 focus of this requirements document, as shown in Figure 3. It is 505 therefore sensible to consider the steps necessary to set up, use and 506 manage PKCs for one Peer to establish an association with another 507 Peer. Figure 4 (below) illustrates the information flow associated 508 with the steps initial PKC generation relative to the architecture 509 diagram. Figure 5 (below) illustrates the information flow associated 510 with the steps PKC renewal relative to the architecture diagram. 511 Figure 6 (below) illustrates the information flow associated with the 512 steps PKC renewal relative to the architecture diagram. For 513 simplicity only the steps associated with IPsec Peer 1 are shown. 515 Bonatti, Turner, Lebowitz 10 516 IPsec Certificate Management Profile 518 +---------------------------------------------+ 519 | PKI System | 520 | | 521 | +--------------+ | 522 | | Repository | +----+ +----+ | 523 | | Certs & CRLs | | CA | | RA | | 524 | +--------------+ +----+ +----+ | 525 | | 526 +---------------------------------------------+ 527 ^ ^ ^ 528 | | | 529 |[E] |[A] |[E] 530 |[M] |[E] |[M] 531 |[R] | |[R] 532 | | | 533 +--------+------------------+----------------+------+ 534 | | v | | 535 | | +----------+ | | 536 | | [G] | VPN | [G] | | 537 | | +---------->| Admin |<-------+ | | 538 | | | | Function | | | | 539 | | | +----------+ | | | 540 | v v v v | 541 | +---------+ +---------+ | 542 | | IPsec | [I] | IPsec | | 543 | | Peer 1 |<=======================>| Peer 2 | | 544 | +---------+ +---------+ | 545 | | 546 | VPN System | 547 +---------------------------------------------------+ 549 [A] = Authorization of PKC issuance and revocation 550 [G] = Generation of public and private key pair, PKC request 551 [E] = Enrollment (request and retrieval) 552 [I] = IKE and IPsec communication 553 [M] = Maintenance: validation, revocation, repository lookups 554 [R] = Renewal (and changes) 556 Figure 3. Architectural Framework for VPN-PKI Interaction 558 2.3.1 New PKC 560 The steps of the VPN-PKI interaction are summarized here for 561 generating a new PKC. The letters refer to Figure 3. The numbers 562 refer to Figure 4. The detailed requirements are described below in 563 Section 3. Note that there are a number of architectul options 564 available and that the most common architecture is depecited in 565 Figure 4; IPsec Peer generated Keys and IPsec Peer generated PKC 566 Request. Other architectural options are discussed in Section 3. 568 Bonatti, Turner, Lebowitz 11 569 IPsec Certificate Management Profile 571 +--------------+ 7 +-----------------------+ 572 | Repository |<----| Certificate Authority | 573 +--------------+ +-----------------------+ 574 ^ ^ ^ 575 | 8 4, 6 | | 1 576 | | 2 | 577 | | v 578 | | +-------+ 579 | | +- | Admin | 580 | | | +-------+ 581 | | | 582 | 9 5 | | 3 583 v v v 584 +--------------------+ +--------+ 585 | IPsec | 10 | IPsec | 586 | Peer 1 |<========>| Peer 2 | 587 +--------------------+ +--------+ 589 Figure 4. VPN-PKI Interaction Steps: 590 IPsec Peer Generates Keys and PKC Request, 591 Enrolls Directly with PKI 593 1) Authorization [A]. Admin sends a list of IDs and PKC contents for 594 the PKI System to authorize enrollment. The PKI returns a list of 595 unique identifiers and one-time tokens to be used for the enrollment 596 of each PKC. Other PKC usage policy is also set at this time, for 597 example parameters for renewals or changes, key lengths, etc. The 598 amount of information that the Admin communicates to the PKI about 599 how it wants the PKCs built could be very small, perhaps just a 600 reference to a template already existing in the PKI System. Likewise 601 it could be very large, with several fields being specified along 602 with their contents. [EDITOR'S NOTE: We need some work on this line 603 of thought.] 605 2) Authorization Response [A]. The PKI System acknowledges the 606 authorizations provided in (1). Response may indicate success or 607 failure for any particular authorization. 609 3) Generate Keys and PKC Request [G]. The Admin communicates with the 610 Peer to either give it information so that it can generate a public 611 and private key pair and PKC request and send the request directly to 612 the PKI. 614 4) Enrollment [E]. The IPsec Peer requests a PKC from the PKI, 615 providing the generated public key. The IPsec Peer generates the key 616 pair and PKC request. 618 5) Enrollment Response [E]. The PKI responds to the enrollment 619 request sent in (4), providing either the new PKC that was generated 620 or a suitable error indication. 622 Bonatti, Turner, Lebowitz 12 623 IPsec Certificate Management Profile 625 6) Enrollment Confirmation. Peer must positively acknowledge receipt 626 of new PKC. 628 7) PKC Posting. The newly-generated PKC for IPsec Peer 1 is posted to 629 the repository. 631 8) Maintenance [M]. The IPsec Peer accesses the PKI to support look- 632 up of PKCs for other IPsec Peers, certification path validation, and 633 revocation checking. This step consists of sending requests for 634 specific PKCs or CRLs, or requests for the PKI System to perform 635 validation checks. 637 9) Maintenance Response [M]. The PKI responds to the maintenance 638 request sent in (7), providing either the requested PKC or CRL, 639 indicating the validity status of a PKC, or indicating an error 640 condition. 642 10) IKE/IPsec Communication [I]. The Peers communicate authenticated 643 by the PKCs they received from the PKI. 645 2.3.2 Renewal PKC 647 The steps of the VPN-PKI interaction are summarized here for rewal 648 PKCs. The letters refer to Figure 3. The numbers refer to Figure 5. 649 The detailed requirements are described below in Section 3. Note that 650 there are a number of architectul options available and that the most 651 common architecture is depecited in Figure 4; IPsec Peer generated 652 Keys and IPsec Peer generated PKC Request. Other architectural 653 options are discussed in Section 3. 655 +--------------+ 5 +-----------------------+ 656 | Repository |<----| Certificate Authority | 657 +--------------+ +-----------------------+ 658 ^ ^ 659 | 6 | 2, 4 660 | | 661 | | 662 | | +-------+ 663 | | +- | Admin | 664 | | | +-------+ 665 | | | 666 | 7 3 | | 1 667 v v v 668 +--------------------+ +--------+ 669 | IPsec | 8 | IPsec | 670 | Peer 1 |<========>| Peer 2 | 671 +--------------------+ +--------+ 673 Figure 5. VPN-PKI Interaction Steps: Renewal by IPsec Peer 1 675 Bonatti, Turner, Lebowitz 13 676 IPsec Certificate Management Profile 678 1) Rekey or Renewal Initiation. The Admin communicates renewal or 679 change instructions to the Peers. Renewal may also be signalled to 680 the PKI (not shown), particularly if authorization changes are 681 necessary. Initiation of this process by the Admin enables IPsec 682 Peers to automatically generate renewal or change requests as needed 683 with minimal user burden, and for those requests to be immediately 684 granted by the PKI System. 686 2) Renewals and Changes [R]. The IPsec Peer requests renewal or 687 change of an existing PKC. Rekey MAY also occur depending upon policy 688 constraints. The renewal or change request will either be provided in 689 (10) above, or will be generated by the IPsec Peer. 691 3) Renewal/Change Response [R]. The PKI responds to the renewal or 692 change request sent in (11), providing either the new PKC that was 693 generated or a suitable error indication. 695 4) Enrollment Confirmation. Peer must positively acknowledge receipt 696 of new PKC. 698 5) PKC Posting. The newly-generated PKC for IPsec Peer 1 is posted to 699 the repository. 701 6) Maintenance [M]. The IPsec Peer accesses the PKI to support look- 702 up of PKCs for other IPsec Peers, certification path validation, and 703 revocation checking. This step consists of sending requests for 704 specific PKCs or CRLs, or requests for the PKI System to perform 705 validation checks. 707 7) Maintenance Response [M]. The PKI responds to the maintenance 708 request sent in (7), providing either the requested PKC or CRL, 709 indicating the validity status of a PKC, or indicating an error 710 condition. 712 8) IKE/IPsec Communication [I]. The Peers communicate authenticated 713 by the PKCs they received from the PKI. 715 2.3.3 Revocation 717 The steps of the VPN-PKI interaction are summarized here for 718 generating a new PKC. The letters refer to Figure 3. The numbers 719 refer to Figure 6. The detailed requirements are described below in 720 Section 3. 722 Bonatti, Turner, Lebowitz 14 723 IPsec Certificate Management Profile 725 +--------------+ 2 +-----------------------+ 726 | Repository |<----| Certificate Authority | 727 +--------------+ +-----------------------+ 728 ^ ^ ^ 729 | 3 | 1 | 1, 1'' 730 | | | 731 | | | 732 | | 1' +-------+ 733 | | +> | Admin | 734 | | | +-------+ 735 | | | 736 | 4 | | 737 v | | 738 +--------------------+ 739 | IPsec | 740 | Peer 1 | 741 +--------------------+ 743 Figure 6. VPN-PKI Interaction Steps: Revocation 745 1) Revocation. The IPsec Peer or Admin requests revocation of IPsec 746 Peer 1's PKC directly from the PKI. 748 1') Revocation. The IPsec Peer requests revocation of their PKC 749 through admin. 751 1'') Revocation. The Admin forwards IPsec Peer 1's PKC revocation 752 request to PKI. 754 2) CRL Posting. The newly-generated CRL revoking IPsec Peer 1's PKC 755 is posted to the repository. 757 3) Maintenance [M]. The IPsec Peer accesses the PKI to support look- 758 up of CRL. 760 4) Maintenance Response [M]. The PKI responds to the maintenance 761 request sent in (3), providing either the requested CRL, indicating 762 the validity status of a PKC, or indicating an error condition. 764 3 Requirements 766 3.1 General Requirements 768 3.1.1 One Protocol 770 This target profile will call for ONE PROTOCOL or ONE USE PROFILE for 771 each main element of the requirements. It is a specific goal to avoid 772 multiple protocols or profiles to solve the same requirement whenever 773 possible so as to reduce complexity and improve interoperability. 775 Bonatti, Turner, Lebowitz 15 776 IPsec Certificate Management Profile 778 Meeting some of the requirements may necessitate the creation of a 779 new protocol or new extension for an existing protocol. 781 Conforming implementations MUST implement the ONE PROTOCOL or ONE USE 782 PROFILE that is specified for a given requirement. 784 3.1.2 Secure Transactions 786 The target profile will specify the transactions for certificate 787 management between VPN and PKI Systems and their components, as 788 needed to ease large scale VPN deployment and management. 789 Specifically, Admin and PKI will transmit between themselves policy 790 details, identities, and keys. As such, the method of communication 791 for these transactions MUST be secured in a manner that ensures 792 privacy, authentication, message data integrity and non-repudiation. 793 This method will require that mutual trust be established between the 794 PKI and the Admin. 796 [EDITOR'S NOTE: Need to perhaps elaborate on "policy details" above.] 798 3.1.3 PKI Availability 800 Central availability is required initially for authorization 801 transactions between the PKI and Admin. Further availability will be 802 required in most cases, but is a decision point for the Operator. 803 Most requirements and scenarios below assume on-line availability of 804 the PKI and Admin for the life of the VPN. 806 Off-line interaction between the VPN and PKI Systems (i.e., where 807 physical media is used as the transport method) is beyond the scope 808 of this document. 810 3.1.4 End-User Transparency 812 PKI interactions are to be transparent to the user. Users need not 813 even be aware that PKI is in use. First time connections need consist 814 of no more than a prompt for some identification and pass phrase, and 815 a status bar notifying the user that setup is in progress. 817 3.1.5 Error Handling 819 The PKC transaction protocol for the PKI and VPN System transactions 820 MUST specify error handling for each transaction. Thorough error 821 condition descriptions and handling instructions will greatly aid 822 interoperability efforts between the PKI and IPsec products. 824 Bonatti, Turner, Lebowitz 16 825 IPsec Certificate Management Profile 827 3.2 Authorization Transactions 829 3.2.1 Bulk Authorization 831 Bulk authoriztion occurs when the Admin requests of the PKI that 832 authorization be established for several different subjects with 833 almost the same contents. A minimum of one field (more is also 834 acceptable) MUST differ per subject. Because the authorization may 835 occur before any keys have been generated, the only way to determine 836 one authorization from another for the purpose of issuing unique 837 identifiers is by having at least one field differ. 839 The authorization MAY occur prior to the event of a PKC enrollment 840 request (in which case it is a "pre-authorization"), or within the 841 same connection. 843 3.2.2 Protocol Preferences for Authorization 845 A single connection per multiple transactions. It is preferred that 846 the setup for all subjects in an authorization batch occurs in one 847 single connection to the RA/CA, with the number of subjects being one 848 or greater. Implementations should be able to handle tens of 849 thousands at a time. 851 ONE protocol must be specified for these Admin to RA/CA interaction. 853 The PKI responds to the Admin station with Authorization identifiers 854 (maybe serial numbers or such) and a corresponding pre-authorization 855 key (not to be confused with the public and private key pair) for 856 each identifier. 858 It is preferred that the transport used to carry the pre- 859 authorization be reliable (TCP). 861 The protocol should be as lightweight as possible. 863 A method for securing the communication between the Admin and the PKI 864 MUST be defined, including privacy, authorization, and integrity. 865 PKCs and authorization of the Admin may need to be initialized by 866 physical rather than on-line means. 868 3.2.3 Admin Authorization Requests to PKI 870 3.2.3.1 Specifying Fields within the PKC 872 The VPN may send the PKI System the set of PKC contents that make up 873 a PKC template that it wants the PKI to use. In other words, it tells 874 the PKI System, "if you see a PKC request that looks like this, from 875 this person, process it and issue the PKC." Likewise, such a template 877 Bonatti, Turner, Lebowitz 17 878 IPsec Certificate Management Profile 880 may have already been defined on the PKI System, and the Admin may 881 simply reference it. 883 In the former case, the elements that the Admin MAY send to the PKI 884 to authorize the eventual creation of PKCs include: 886 - DN fields 888 - Any number of locally defined CNs with their contents [EDITOR'S 889 NOTE: this is difficult to do. We may need to say just one CN.] 891 - Validation Period of the PKC 893 - Renewal parameters (i.e., N% of validity period, and PKC overlap 894 duration in N [EDITOR'S NOTE: Should consider other factors. 895 Measurement? Minutes? Hours? Percentage?], or just let it 896 expire) 898 - Any of SubjAltName fields 900 - Key type 902 - Key length 904 - Any of the extension fields (Key usage, extended key usage, 905 Policy constraints, etc.) 907 - Require a CDP be filled in by the PKI in issuance. The 908 specification should define who will handle the CDP contents. 909 Suggest the PKI, not Admin, but further research is needed. 911 3.2.3.2 Authorizations for Renewal and Change 913 When the Admin sends its authorization request information it MUST 914 also send information to the PKI about the local policy regarding 915 renewal and changes. These are: 917 - Admin MUST specify if automatic renewals are allowed, that is, 918 the Admin is presently authorizing the PKI to process a future 919 renewal for the specified end entity PKC. 921 - Admin MUST specify if any changes are allowed, that is, the Admin 922 is presently authorizing the PKI to accept a future request for 923 a new PKC creation with some element of the Subject or 924 SubjectAltName changed. 926 If a renewal is authorized, the Admin MUST further specify: 928 - Whether or not a new key must be used for the new PKC. 930 Bonatti, Turner, Lebowitz 18 931 IPsec Certificate Management Profile 933 - Who can renew, i.e. can only the admin send a renewal request or 934 can the end entity Peer send a request directly to the PKI, or 935 either. 937 - Specify at how long before the PKC expiration date the PKI will 938 accept and process a renewal. 940 - Length of time (if ever) after PKI receives end entity Peer 941 confirmation (see 3.4.8 and 3.6.1 below) that the old PKC is 942 revoked, and removed from repository. 944 If change request is authorized, the Admin MUST further specify: 946 - The fields in the Subject and SubjectAltName that are changeable 948 - The entity that can send the change request, i.e. only the Admin, 949 only the end entity, or either. 951 - Length of time (if ever) after PKI receives end entity Peer 952 confirmation (see 3.6.1 below) that the old PKC is revoked, and 953 removed from repository. 955 3.2.3.3 Other Authorization Elements 957 CDP MUST be flagged as required in the authorization request. The 958 method MUST also be specified; HTTP is the MUST method, LDAP is MAY. 960 There will be an option to specify a Validation Period for the 961 authorization ID and its one-time-key. If such a Validation Period is 962 set, any requests using this authorization id and key that arrive 963 outside of the validation period MUST be dropped and the event 964 logged. 966 Ability to communicate the Community Realm for the PKC to the PKI. 967 Community Realm is an important component in provisioning that allows 968 the Admin to specify for the Peer various elements of the PKC's 969 contents that the PKI will fill in, and are not defined by the Admin. 970 It may be used to specify various local policy definitions. It also 971 will be used to label different groups to have different CRLs (for 972 example small CRLs with only gateways in the listing for use by 973 Remote Access Peers, or large CRLs with all Remote Access Peers and 974 gateways to be used by the Gateways). There will be a need for an 975 import and export for easily synchronizing the Community Realm lists 976 between the Admin and PKI System. 978 The Protocol should consider what happens when Admin requested 979 information conflicts with PKI settings such that the Admin request 980 cannot be issued as requested. (Ex: Admin requests Validation Period 981 = 3 weeks and CA is configured to only allow Validation Periods = 1 982 week.) Proper conflict handling MUST be specified. 984 Bonatti, Turner, Lebowitz 19 985 IPsec Certificate Management Profile 987 3.2.4 Cancel Capability 989 Admin can send a cancel authorization message to PKI. [EDITOR'S NOTE: 990 Should the Peer be able to send a cancel message as well?] Admin MUST 991 provide the authorization ID and code in order to cancel the 992 Authorization. At that point, the authorization will be erased from 993 the PKI, and a log entry of the event written. After the cancellation 994 has been verified with the Admin (a Cancel, Cancel ACK, ACK type of a 995 process is required to cover a lost connections scenario), the PKI 996 will accept another Authorization request with the exact same 997 contents as the canceled one. The PKI MUST NOT accept a second 998 authorization request for the same identity [EDITOR'S NOTE: How do we 999 decide what defines "identity"?] if one already exists. 1001 3.2.5 PKI response to Admin 1003 If the authorization is acceptable, the PKI will respond to the Admin 1004 with a unique identifier per subject authorization required and a 1005 one-time-authorization key per authorization ID. Strongly recommend 1006 the one-time-authorization key be unique per authorization ID. The 1007 more randomness that can be achieved in the relationship between an 1008 identifier and its key the better. The key MUST be in ASCII format to 1009 avoid incompatibilities that may occur due to international 1010 characters. 1012 All the contents of the PKC that it intends to issue will be returned 1013 to the Admin. This will allow the Admin to perform an "operational 1014 test" to verify that the issued PKCs will meet its requirements. 1016 For any request, the PKI cannot change any of the specified values in 1017 request within its response. We need to prevent a change in PKC 1018 contents that may occur due to a change in PKI configuration right in 1019 the middle of a batch pre-authorization request. 1021 [EDITOR'S NOTE: what if the Admin sends a parameter that the PKI 1022 cannot fulfil, i.e. the parameter contradicts PKI policy? Would need 1023 to return an error code and description and refuse to authorize the 1024 enrollment.] 1026 After receiving a bulk authorization request from the Admin, the PKI 1027 must be able to reply YES to those individual PKC authorizations that 1028 it can satisfy and NO or FAILED for those requests that cannot be 1029 satisfied, along with sufficient reason or error codes. 1031 A method is needed to identify if there is a change in PKI setting 1032 between the time the authorization is granted and PKC request occurs, 1033 and what to do about the discrepancy. 1035 Bonatti, Turner, Lebowitz 20 1036 IPsec Certificate Management Profile 1038 3.2.6 Error Handling for Authorization Transactions 1040 Thorough error condition descriptions and handling instructions are 1041 required for each transaction in the authorization process. Providing 1042 such error codes will greatly aid interoperability efforts between 1043 the PKI and IPsec products. 1045 3.3 Key Generation and PKC Request Construction 1047 Once the PKI System has responded with authorization identifiers and 1048 keys, and this information is received at the Admin, the next step is 1049 to generate public and private key pairs and to construct PKC 1050 requests using those key pairs. The key generations MAY occur at one 1051 of two places, depending on local requirements: at the IPsec Peer or 1052 at the Admin. The PKC constructions MAY occur at either the IPsec 1053 Peer or a combination of the Peer and the Admin. 1055 [EDITOR's NOTE: Should we have different arrow diagrams for each 1056 option? Option 1 is already depicted in Figure 4. Should we show 1057 the differences amongst the other three?] 1059 3.3.1 IPsec Peer Generates Key Pair and Constructs Request 1061 This case will be used most often in the field. This is the most 1062 secure method for keying; the keys are generated on the end entity 1063 and never leave the end entity. 1065 The Admin will send the authorization identifier and authorization 1066 key to the end entity, the IPsec Peer. The Admin will also send any 1067 other parameters needed by the Peer to generate the PKC request, 1068 including key type and size. Recall that the mechanism for how this 1069 information is communicated from the Admin to the Peer is opaque. 1071 Receiving the command and the necessary information from the Admin, 1072 the Peer will proceed to generate the key pair and construct the PKC 1073 request. 1075 3.3.2 IPsec Peer Generates Key Pair, Admin Constructs Request 1077 In this case, the Admin sends a command to the Peer to generate the 1078 key pair. The Admin then constructs the PKC request on behalf of the 1079 Peer, except for the signing. It sends the construction to the Peer 1080 for signing, and the Peer returns the signed request construction 1081 back to the Admin. The Admin then proceeds to enroll on behalf of the 1082 client. 1084 The advantage of this solution is that the private key never leaves 1085 the IPsec Peer, but limits the amount the Peer must know and do 1086 regarding PKC generation. 1088 Bonatti, Turner, Lebowitz 21 1089 IPsec Certificate Management Profile 1091 3.3.3 Admin Generates Key Pair and Constructs Request 1093 The use case exists for deployments where end entities cannot 1094 generate their own key pairs. Some examples are for PDAs and handsets 1095 where to generate an RSA key would be operationally impossible due to 1096 processing and battery constraints. Another case covers key recovery 1097 requirements, where the same PKCs are used for other functions in 1098 addition to IPsec, and key recovery is required (e.g. local data 1099 encryption), therefore key escrow is needed off the end entity 1100 station. If key escrow is performed then the exact requirements and 1101 procedures for it are beyond the scope of this document. 1103 The Admin will generate the key pair, construct the PKC request, and 1104 enroll on behalf of the Peer. Once the PKC has been retrieved, the 1105 keys and PKC will be sent to the Peer using a secure method. The 1106 nature of this secure method is beyond the scope of this document. 1108 Performing a separate pre-authorization step is still of value even 1109 though the Admin is the also performing the key generation. The 1110 Community Realm, Subject fields, SubjectAlt fields and more are part 1111 of the request, and must be communicated in some way from the Admin 1112 to the PKI. Instead of creating a new mechanism, we simply use the 1113 pre-authorize schema again. This also allows for the feature of role- 1114 based administration, where Operator1 is the only one allowed to have 1115 the Admin function pre-authorize PKCs, but Operator2 is the one doing 1116 batch enrollments and VPN device configurations. 1118 3.3.4 PKI Generates Key Pair and Passes to Peer via Admin 1120 TBD - [EDITOR'S NOTE: There is another use case here: PKI generates 1121 the key pair AND the PKC and simply hands it down to the Admin for 1122 installation into the Peer. This is, in all likelihood, the easiest 1123 way to deploy Certs, though sacrafices a bit in security. Do we just 1124 specify PKCS12 and try to create some requirements for how the Admin 1125 will say, "I need a cert for NNNNN," and how PKI will respond with 1126 the PKCS12?] 1128 3.3.5 Trust Anchor PKC Acquisition 1130 The root PKC MUST arrive on the Peer via one of two methods: 1132 (a) Peer can get the root PKC via its secure communication with 1133 Admin. This requires the Peer to know less about interaction with the 1134 PKI. 1136 (b) Admin can command Peer to retrieve the root cert directly from 1137 the PKI. How retrieval of the root cert takes place is beyond scope, 1139 Bonatti, Turner, Lebowitz 22 1140 IPsec Certificate Management Profile 1142 but is assumed to occur via an unauthenticated but confidential 1143 enrollment protocol. 1145 3.3.6 Error Handling for Key Generation and Request Construction 1147 Thorough error condition descriptions and handling instructions are 1148 required for each transaction in the authorization process. Providing 1149 such error codes will greatly aid interoperability efforts between 1150 the PKI and IPsec products. 1152 3.4 Enrollment (Sending Request and PKC Retrieval) 1154 Regardless of where the keys were generated and the PKC request 1155 constructed, an enrollment process will need to occur to request a 1156 PKC creation from the PKI and to retrieve that PKC. 1158 The protocol MUST be exactly the same regardless of whether the 1159 enrollment occurs from the Peer to the PKI or from the Admin to the 1160 PKI (as seen below in sections 3.4.5 through 3.4.7). 1162 3.4.1 One protocol 1164 One protocol MUST be specified for both request and retrieval. 1166 3.4.2 On-line protocol 1168 The protocol MUST supports automated enrollment that occurs over the 1169 Internet and without the need for manual intervention. 1171 3.4.3 Single Connection with Immediate Response 1173 Request and retrieval MUST be able to occur in one on-line connection 1174 between the end entity and the PKI (RA/CA). 1176 The end entity sends the request, attaching the Authorization 1177 identifier and key. 1179 The RA/CA receives the request and uses the Authorization identifier 1180 and key to match it to the proper pre-authorization entry. 1182 Since the contents of the PKC match, and the Authorization identifier 1183 and key are correct, the PKC is generated immediately, with no need 1184 for manual intervention or review on the PKI System before issuance. 1186 The PKI makes the PKC available immediately for retrieval, or 1187 possibly sends the PKC to the end entity as a response in the request 1188 or retrieval exchange. 1190 Bonatti, Turner, Lebowitz 23 1191 IPsec Certificate Management Profile 1193 3.4.4 Manual Approval Option 1195 The optional capability to queue and manually approve PKC requests 1196 MUST exist within the protocol for those organizations that will not 1197 permit automation of credential issuing as described above. Likewise, 1198 polling to determine if request has been satisfied and to try to 1199 retrieve the PKC MUST exist within the protocol for those 1200 organizations that will not permit automation of credential issuing 1201 as described above. 1203 End-entities and the PKI must disclose and agree upon which mode they 1204 will support (automated approval or manual approval) within the 1205 protocol. 1207 3.4.5 Enrollment Method 1: Peer Enrolls to PKI Directly 1209 The enrollment MAY occur in one of three fashions, and valid use 1210 cases exist for all three. First, and most straight forward, the 1211 Admin can instruct the IPsec Peer to execute an enrollment, telling 1212 it where to enroll, and providing any necessary parameters. 1214 In this case the IPsec Peer only talks to the PKI after being 1215 commanded to do so by the Admin. Note that this enrollment mode is 1216 depicted in Figure 4. 1218 3.4.6 Enrollment Method 2: IPsec Peer Enrolls to PKI through Admin 1220 In this case, the IPsec Peer has generated the key pair and the PKC 1221 request, but does not enroll directly to the PKI System. Instead, it 1222 automatically sends its request to the Admin, and the Admin 1223 automatically performs the enrollment to the PKI System. The PKI 1224 System does not care where the enrollment comes from, as long as it 1225 is a valid enrollment. Once the Admin retrieves the PKC, it then 1226 automatically forwards it to the IPsec Peer, and the Peer can begin 1227 using it in security policy. 1229 The communication of the request, retrieval, renewal, or change, can 1230 go directly from the end entity to the PKI, or be passed from end 1231 entity through the Admin to the PKI. In the latter case, the end 1232 entity need not know how to do all the direct communication with the 1233 PKI; the function becomes focused in the Admin station. In either 1234 case, the format of messages should be identical regardless of who is 1235 sending the request. 1237 Most IPsec Systems have enough CPU power to generate a public and 1238 private key pair of sufficient strength for secure IPsec. In this 1239 case, the end entity needs to prove to the Admin that they have such 1240 a key pair; this is normally done by the Admin sending the end entity 1241 a nonce, which the end entity signs and returns to the Admin along 1242 with the end entity's public key. 1244 Bonatti, Turner, Lebowitz 24 1245 IPsec Certificate Management Profile 1247 The steps of the VPN-PKI interaction are summarized here for the 1248 IPSec Peer enrolling through the Admin. The letters refer to Figure 1249 3. The numbers refer to Figure 7. 1251 +--------------+ 10 +-----------------------+ 1252 | Repository |<----| Certificate Authority | 1253 +--------------+ +-----------------------+ 1254 ^ ^ 1255 | 11 | 1, 5, 9 1256 | 2, 6 | 1257 | v 1258 | +-------+ 1259 | +> | Admin | 1260 | 4, 8 | +-------+ 1261 | | 1262 | 12 | 3,7 1263 v v 1264 +--------------------+ +--------+ 1265 | IPsec | 13 | IPsec | 1266 | Peer 1 |<========>| Peer 2 | 1267 +--------------------+ +--------+ 1269 Figure 7. VPN-PKI Interaction Steps: 1270 IPsec Peer Generates Keys and PKC Request, 1271 Enrolls Through Admin 1273 1) Authorization [A]. Admin sends a list of IDs and PKC contents for 1274 the PKI System to authorize enrollment. The PKI returns a list of 1275 unique identifiers and one-time tokens to be used for the enrollment 1276 of each PKC. Other PKC usage policy is also set at this time, for 1277 example parameters for renewals or changes, key lengths, etc. The 1278 amount of information that the Admin communicates to the PKI about 1279 how it wants the PKCs built could be very small, perhaps just a 1280 reference to a template already existing in the PKI System. Likewise 1281 it could be very large, with several fields being specified along 1282 with their contents. [EDITOR'S NOTE: We need some work on this line 1283 of thought.] 1285 2) Authorization Response [A]. The PKI System acknowledges the 1286 authorizations provided in (1). Response may indicate success or 1287 failure for any particular authorization. 1289 3) Generate Keys and PKC Request [G]. The Admin communicates with the 1290 Peer to give it information so that it can generate a public and 1291 private key pair and PKC request and send the request back to the 1292 Admin. 1294 4) Enrollment [E]. The IPsec Peer requests a PKC from the Admin, 1295 providing the generated public key. 1297 Bonatti, Turner, Lebowitz 25 1298 IPsec Certificate Management Profile 1300 5) Enrollment [E]. The Admin forwards the enrollment request to the 1301 PKI. 1303 6) Enrollment Response [E]. The PKI responds to the enrollment 1304 request sent in (5), providing either the new PKC that was generated 1305 or a suitable error indication. 1307 7) Enrollment Response [E]. The Admin forwards the enrollment 1308 response back to the IPsec Peer. 1310 8) Enrollment Confirmation. Peer must positively acknowledge receipt 1311 of new PKC back to the Admin. 1313 9) Enrollment Confirmation. Admin forwards enrollment confirmation 1314 back to the PKI. 1316 10) PKC Posting. The newly-generated PKC for IPsec Peer 1 is posted 1317 to the repository. 1319 11) Maintenance [M]. The IPsec Peer accesses the PKI to support look- 1320 up of PKCs for other IPsec Peers, certification path validation, and 1321 revocation checking. This step consists of sending requests for 1322 specific PKCs or CRLs, or requests for the PKI System to perform 1323 validation checks.[EDITOR's NOTE û is the Admin going to the 1324 repository lookup for the IPsec Peer?] 1326 12) Maintenance Response [M]. The PKI responds to the maintenance 1327 request sent in (11), providing either the requested PKC or CRL, 1328 indicating the validity status of a PKC, or indicating an error 1329 condition. 1331 13) IKE/IPsec Communication [I]. The Peers communicate authenticated 1332 by the PKCs they received from the PKI. 1334 3.4.7 Enrollment Method 3: Admin Enrolls to the PKI Directly 1336 In this instance, the Admin is performing a function similar to that 1337 of a Registration Authority (RA), as defined in [CERTPROFILE]. The 1338 Admin will have likely generated the key pair and constructed the 1339 request on behalf of the IPsec Peer. It proceeds to handle the entire 1340 enrollment directly with the PKI, and returns to the IPsec Peer the 1341 final product of a key pair and PKC. Again, the mechanism for the 1342 Peer to Admin communication is opaque. 1344 The steps of the VPN-PKI interaction are summarized here for the 1345 Admin enrolling directly to the PKI. The letters refer to Figure 3. 1346 The numbers refer to Figure 8. 1348 Bonatti, Turner, Lebowitz 26 1349 IPsec Certificate Management Profile 1351 +--------------+ 7 +-----------------------+ 1352 | Repository |<----| Certificate Authority | 1353 +--------------+ +-----------------------+ 1354 ^ ^ 1355 | 8 | 1, 4, 6 1356 | 2, 5 | 1357 | v 1358 | 9 +-------+ 1359 +--------------+> | Admin | 3 1360 | +-------+ 1361 | 1362 10 | 1363 v 1364 +--------------------+ +--------+ 1365 | IPsec | 11 | IPsec | 1366 | Peer 1 |<========>| Peer 2 | 1367 +--------------------+ +--------+ 1369 Figure 8. VPN-PKI Interaction Steps: 1370 Admin Generates Keys and PKC Request, 1371 Admin Performs Enrollment 1373 1) Authorization [A]. Admin sends a list of IDs and PKC contents for 1374 the PKI System to authorize enrollment. The PKI returns a list of 1375 unique identifiers and one-time tokens to be used for the enrollment 1376 of each PKC. Other PKC usage policy is also set at this time, for 1377 example parameters for renewals or changes, key lengths, etc. The 1378 amount of information that the Admin communicates to the PKI about 1379 how it wants the PKCs built could be very small, perhaps just a 1380 reference to a template already existing in the PKI System. Likewise 1381 it could be very large, with several fields being specified along 1382 with their contents. [EDITOR'S NOTE: We need some work on this line 1383 of thought.] 1385 2) Authorization Response [A]. The PKI System acknowledges the 1386 authorizations provided in (1). Response may indicate success or 1387 failure for any particular authorization. 1389 3) Generate Keys and PKC Request [G]. The Admin generates the public 1390 private key pair and PKC request. 1392 4) Enrollment [E]. The Admin requests a PKC from the PKI providing 1393 the generated public key. 1395 5) Enrollment Response [E]. The PKI responds to the enrollment 1396 request sent in (4), providing either the new PKC that was generated 1397 or a suitable error indication. 1399 6) Enrollment Confirmation. Admin must positively acknowledge receipt 1400 of new PKC back to the PKI. 1402 Bonatti, Turner, Lebowitz 27 1403 IPsec Certificate Management Profile 1405 7) PKC Posting. The newly-generated PKC for IPsec Peer 1 is posted to 1406 the repository. 1408 8) Maintenance [M]. The Admin accesses the PKI to retrieve the new 1409 PKC. [EDITOR's NOTE û is the Admin going to the repository lookup 1410 for the IPsec Peer?] 1412 9) Maintenance Response [M]. The PKI responds to the maintenance 1413 request sent in (8), providing the requested PKC, or indicating an 1414 error condition. 1416 10) Admin sends newly generated PKC and private key to IPsec Peer. 1418 11) IKE/IPsec Communication [I]. The Peers communicate authenticated 1419 by the PKCs they received from the PKI. 1421 3.4.8 Enrollment Type Field 1423 A field must exist in the request to specify the TYPE of request 1424 being made. Request types include new request, renew request, and 1425 change request (renewals and changes are discussed in detail in 1426 section 3.6). The type field is required for monitoring, logging and 1427 auditing purposes. They will help the Operator to know exactly what 1428 type of request was made so that suspicious activities, even if the 1429 request is denied, can be identified. 1431 3.4.9 Confirmation Handshake 1433 Any time a new PKC is issued by the PKI, a confirmation must be sent 1434 back to the PKI. This is true for first time issuances, renewals, and 1435 changes alike. 1437 Operationally, the Peer MUST send a confirmation to the PKI verifying 1438 that the end entity has received the PKC, loaded it, and can use it 1439 effectively in an IKE exchange. This requirement exists so that: 1441 - The PKI does not publish the new PKC in the repository for others 1442 until that PKC is able to be used effectively by the Peer, and; 1444 - A revocation may be invoked if the PKC is not received and 1445 operational within an allowable window of time. 1447 To assert such proof the Peer MUST sign a portion of data with the 1448 new key. The result MUST be sent to the PKI. The entity that actually 1449 sends the result to the PKI MAY be either the Peer (sending it 1450 directly to the PKI) or Admin (the Peer would send it to Admin, and 1451 Admin can in turn send it to the PKI). 1453 The Admin MUST acknowledge the successful receipt of the 1454 confirmation, thus signaling the end entity Peer that it may proceed 1455 using this PKC in IKE connections. The PKI MUST complete all 1457 Bonatti, Turner, Lebowitz 28 1458 IPsec Certificate Management Profile 1460 processing necessary to enable the end entity's operational use of 1461 the new PKC (for example, writing the PKC to the repository) before 1462 sending the confirmation acknowledgement. The PKI MUST also issue a 1463 revoke on the original PKC before sending the confirmation ACK (see 1464 section 4.X). The end entity Peer MUST NOT begin using the PKC until 1465 the PKI's confirmation acknowledgement has been received. 1467 3.4.10 Failure Cases 1469 Thorough error condition descriptions and handling instructions are 1470 required for each transaction in the enrollment process. Providing 1471 such error codes will greatly aid interoperability efforts between 1472 the PKI and IPsec products. 1474 The profile must clarify what happens if the request and retrieval 1475 fails for some reason. The following cases will be covered: 1477 - Admin or Peer cannot send the request. 1479 - Admin or Peer sent the request but the PKI did not receive the 1480 request. 1482 - PKI received the request but could not read it effectively. 1484 - PKI received and read the request, but some contents of the 1485 request violated the PKI's configured policy such that the PKI 1486 was unable to generate the PKC. 1488 - The PKI System generated the PKC, but could not send it. 1490 - The PKI sent the PKC, but the requestor (Admin or Peer) did not 1491 receive it. 1493 - The Requestor (Admin or Peer) received the PKC, but could not 1494 process it due to incorrect contents, or other PKC-construction- 1495 related problem. 1497 - The Requestor failed trying to generate the confirmation. 1499 - The Requestor failed trying to send the confirmation. 1501 - The Requestor sent the confirmation, but the PKI did not receive 1502 it. 1504 - The PKI received the confirmation but could not process. 1506 In each case the following questions MUST be addressed: 1508 - What does Peer do? 1509 - What does Admin do? 1510 - What does PKI do? 1512 Bonatti, Turner, Lebowitz 29 1513 IPsec Certificate Management Profile 1515 - Is Authorization used? 1517 If a failure occurs after the PKI sends the PKC and before the Peer 1518 receives it, then the Peer MUST re-request with the same 1519 Authorization ID and one-time-key, and the PKI, seeing the ID and 1520 key, MUST send the PKC again. 1522 3.5 PKC Profile for PKI Interaction 1524 A PKC used for identity in IKE transactions MUST include all the 1525 X509v3 mandatory fields. It must also contain the minimal contents 1526 necessary for path validation and chaining (these items will be 1527 enumerated in the profile). 1529 It is preferable that the PKC profiles for IPsec and certificate 1530 management were the same so that one PKC could be used for both 1531 protocols. If the profiles are inconsistent then different PKCs (and 1532 perhaps different processing requirements) might be required for 1533 certificate management transactions vs. IKE transactions. However, 1534 failure to achieve this requirement in the profile MUST NOT hold up 1535 the standardization effort. 1537 3.5.1 Identity Usage 1539 The IPsec Peer SHALL perform identity verification based on the 1540 fields of the PKC and parameters applicable to the VPN tunnel. The 1541 fields of the PKC used for verification MAY include either the X.500 1542 Distinguished Name (DN) within the Subject Name, or a specific field 1543 within the Extension SubjectAltName (per [DOI] 4.6.2.1 Identification 1544 Type Values). Usage descriptions for each follow. 1546 The PKC field(s) that will be used for identity verification MUST be 1547 included in the PKC request by the Admin or the Peer. In addition to 1548 the DN, the following identity-related values may be included in the 1549 SubjectAltName: 1551 - Fully-Qualified Domain Name (FQDN) 1552 - RFC 822 (also called USER FQDN) 1553 - IPv4 Address 1554 - IPv6 Address 1556 While substrings of these identity values may also be present in 1557 elements of the DN, they will not be looked for in the DN, only in 1558 SubjectAltName. 1560 Bonatti, Turner, Lebowitz 30 1561 IPsec Certificate Management Profile 1563 3.5.2 Path Validation 1565 The Peers must validate the certification path. The contents 1566 necessary in the PKC to allow this will be enumerated in the profile 1567 document. 1569 The Peer MAY have the ability to construct the certification path 1570 itself, however Admin MUST be able to supply Peers with the trust 1571 anchor and any chaining PKCs necessary. The Admin MAY include the AIA 1572 extension in PKCs as a means of facilitating path validation. 1574 DNS SHOULD be supported by the Peers in order to do certification 1575 path lookups, as well as those for revocation. 1577 3.5.3 KeyUsage 1579 The PKC's KeyUsage digialSignature bit [CERTPROFILE] MUST be flagged 1580 on. 1582 [EDITOR'S NOTE: Shouldn't the non-repudiation bit also be required? 1583 It's in the stated requirements, and PKIX treats it separately. Also 1584 check whether the key exchange or key agreement bits should be 1585 required. These are employed by both CMC and IPsec.] 1587 3.5.4 Extended Key Usage 1589 EKU's are not required. The presence or lack of an EKU MUST NOT cause 1590 an implementation to fail an IKE connection. 1592 Default behavior is to not check EKU. However, local security policy 1593 MAY check EKU, and if so the implementation SHOULD allow the 1594 acceptance or rejection based on the presence of each EKU. Those EKUs 1595 are defined as: 1597 - serverAuth, 1598 - clientAuth, 1600 or an IKE specific EKU which are defined as one of the four currently 1601 issued IANA EKU's: 1603 - IPsec user, 1604 - IPsec computer, 1605 - IPsec intermediate, 1606 - IKE IPsec intermediate. 1608 Bonatti, Turner, Lebowitz 31 1609 IPsec Certificate Management Profile 1611 3.5.5 Pointer to Revocation Checking 1613 The PKC contents must be constructed in a manner such that any Peer 1614 who hold the PKC locally will know exactly where to go and how to 1615 request the CRL. 1617 The location and method for either a CDP or an AIA [CERTPROFILE] MUST 1618 be included in the PKC. Including such contents avoids the need to 1619 send the CRL to the Peer, and allows the receiving Peer to look up 1620 the CRL on their own. 1622 PKCs MUST contain the full name of the CDP and AIA. Issuer-relative 1623 names are not considered sufficient. 1625 3.6 PKC Renewals and Changes 1627 In order to allow for continued PKC usage, a new PKC will need to be 1628 issued for an end entity before the end entity's currently held PKC 1629 expires. A renewal is defined as a new PKC issuance with the same 1630 SubjectName and SubjectAlternativeName contents as an existing PKC 1631 for the same end entity before expiration of the end entity's current 1632 PKC. 1634 A change is defined as a new PKC issuance with an altered SubjectName 1635 or SubjectAlternativeName for the same end entity before expiration 1636 of the end entity's current PKC. Renewals and changes are variants of 1637 a PKC request scenario with unique operational and management 1638 requirements. 1640 Once the PKI has issued a PKC for the end entity Peer, the Peer MUST 1641 be able to either contact the PKI directly or through the Admin for 1642 any subsequent renewals or changes. The PKI MUST support either case. 1644 It is desired that a renew or change request contain an element that 1645 identifies the request as either type=renewal, or type=change. This 1646 element MUST be specified in the profile. This will allow for better 1647 management, logging and auditing of certificate management. 1649 When sending a renew or change request, the entire contents of the 1650 PKC request needs to be sent to the PKI, just as in the case of the 1651 original enrollment. Keeping the request format as similar as 1652 possible between new, renewal, and change cases will make for easier 1653 implementations; e.g. the format of the request is identitical except 1654 for a type=[renew | change] instead of type=new. 1656 The renew and change requests MUST be signed by the private key of 1657 the old PKC. This will allow the PKI to verify the identity of the 1658 requestor, and ensure that an attacker does not submit a request and 1659 receive a PKC with another end entity's identity. 1661 Bonatti, Turner, Lebowitz 32 1662 IPsec Certificate Management Profile 1664 Whether or not a new key is used for the new PKC in a renew and 1665 change scenario is a matter of local security policy, and MUST be 1666 specified by the Admin to the PKI in the original authorization 1667 request. Re-using the same key is permitted, but not encouraged. If a 1668 new key is used, the change or renew request must be signed by both 1669 the old key -- to prove the right to make the request -- and the new 1670 key -- to use for the new PKC. [EDITOR'S NOTE: Is there a way to do 1671 this?] 1673 The new PKC resulting from a renew or change will be retrieved in- 1674 band, using the same mechanism as a new PKC request. 1676 For the duration of time after a renew or change has been processed 1677 and before PKI has received confirmation of the Peer's successful 1678 receipt of the new PKC (as described above in section 3.4.9), both 1679 PKCs--the old and the new--for the end entity will be valid. This 1680 will allow the Peer to continue with uninterrupted IKE connections 1681 with the previous PKC while the renewal process occurs. 1683 In the case where new keys were generated for a renew or change 1684 request, once the end entity Peer receives the confirmation 1685 acknowledgement from the PKI, it is good practice for the old key 1686 pair be destroyed as soon as possible. Deletion of the keys and the 1687 PKC can occur once all connections that used the old PKC have 1688 expired. 1690 After the renewal or change occurs, the question now exists for the 1691 PKI of what to do about the old PKC. If the old PKC is to be made 1692 unusable, the PKI will need to add it to the revocation list and 1693 removed from the repository. The decision about if the old PKC should 1694 be made unusable is a decision of local policy. Either the PKI or the 1695 Admin will need to specify this parameter during the authorization 1696 phase. In this case the specifying party --either the Admin or the 1697 PKI-- MUST also specify during authorization the length of time after 1698 the PKI receives the end entity Peer's confirmation (of receipt of 1699 the PKC) that will pass before the old PKC is made unusable. 1701 If a PKC has been revoked, it MUST NOT be allowed a renewal or 1702 change. 1704 Should the PKC expire without renewal or change, an entirely new 1705 request MUST be made. 1707 3.6.1 Renew Request for a New PKC (before expiry) 1709 Operators can choose to force renewals for several reasons: 1711 - To enforce an automated "clean up" of unused PKCs that have not 1712 been specifically revoked 1714 - To force re-keys 1716 Bonatti, Turner, Lebowitz 33 1717 IPsec Certificate Management Profile 1719 - To have manual review control over re-issuance. 1721 In the latter case, automated renewals will likely not be used. In 1722 the former two cases automated renewal is a very attractive option. 1724 At the time of authorization, certain details about renewal 1725 acceptance will be conveyed by the Admin to the PKI, as stated in 1726 section 3.2.3.2 above. The renewal request MUST match the conditions 1727 that were specified in the original authorization for: 1729 - Keys: new or existing or either 1730 - Requestor: End entity Peer, Admin, either 1731 - Renewal Period 1732 - Length of time before making the old PKC unusable 1734 If any of these conditions are not met, the PKI must reject the 1735 renewal and log the event. 1737 3.6.2 Change Request for a New PKC 1739 A change in contents will be necessary when details about an end 1740 entity Peer's identity change, but the Operator does not want to 1741 generate a new PKC from scratch, requiring a whole new authorization. 1742 For example, a gateway device may be moved from one site to another. 1743 Its IPv4 Address will change in the SubjectAltName extension, but all 1744 other information could stay the same. Another example is an end user 1745 who gets married and changes the last name or moves from one 1746 department to another. In either case, only one field (the Surname or 1747 OU in the DN) need change. 1749 A Change differs from a Renew in a few ways: 1751 - A re-key is not necessary (though MAY be specified) 1753 - The timing of the Change event is not predictable, as is the case 1754 with a scheduled renewal 1756 - The change request may occur at any time during a PKC's period of 1757 validity 1759 - Once the Change is completed, and the new PKC is confirmed, the 1760 old PKC should cease to be usable, as its contents no longer 1761 accurately describe the subject 1763 - The existence of a "change" type allows for better logging and 1764 tracking of why the new issuance occurred, and why the old PKC 1765 was made unusable. 1767 At the time of authorization, certain details about change acceptance 1768 MAY be conveyed by the Admin to the PKI, as stated in section 3.2.3.2 1770 Bonatti, Turner, Lebowitz 34 1771 IPsec Certificate Management Profile 1773 above. The change request MUST match the conditions that were 1774 specified in the original authorization for: 1776 - Keys: new or existing or either 1777 - Requestor: End entity Peer, Admin, either 1778 - The fields in the Subject and SubjectAltName that are changeable 1779 - Length of time before making the old PKC unusable 1781 If any of these conditions are not met, the PKI must reject the 1782 renewal. 1784 If a Change authorization was not made at the time of original 1785 authorization, one may be made from Admin to the PKI at any time 1786 during the PKC's valid life. When such a Change is desired, Admin 1787 must notify the PKI System that a chance is authorized for the end 1788 entity, and to expect it coming, and specify the new contents. Admin 1789 then initiates the Change request with the given contents in whatever 1790 mechanism the VPN System employs (direct from end entity to PKI, from 1791 end entity through Admin, or directly from Admin). 1793 3.6.3 Error Handling for Renewal and Change 1795 Thorough error condition descriptions and handling instructions are 1796 required for each transaction in the renewal or change process. 1797 Providing such error codes will greatly aid interoperability efforts 1798 between the PKI and IPsec products. 1800 3.7 Finding PKCs in repositories 1802 The complete hierarchical validation chain (except the trust point) 1803 MUST be able to be searched in their respective repositories. The 1804 information to accomplish these searches MUST be adequately 1805 communicated in the PKCs sent during the IKE transaction. 1807 All PKCs must be retrievable through a single protocol. The final 1808 specification will identify one protocol as a "MUST", others MAY be 1809 listed as "OPTIONAL". 1811 The general requirements for the retrieval protocol include: 1813 - The protocol can be easily Firewalled (including NAT or PAT); 1815 - The protocol can easily perform some query against a remote 1816 repository on a specific ID element that was given to it in a 1817 standard PKC field. 1819 Other considerations include: 1821 -relative speed 1822 -relative ease of administration 1824 Bonatti, Turner, Lebowitz 35 1825 IPsec Certificate Management Profile 1827 -scalability 1829 Intermediate PKCs will be needed for the case of re-keying of the CA, 1830 or a PKI System where multiple CAs exist. 1832 PKCs MAY have extendedKeyusage to help identify the proper PKC for 1833 IPsec, though the default behavior is to not use them. See the above 1834 section on extendedKeyUsage. 1836 IPsec Peers MUST be able to resolve Internet domain names and support 1837 the manadatory repository access protocol at the time of starting up 1838 so they can perform the PKC lookups. 1840 IPsec Peers should cache PKCs to reduce latency in setting up Phase 1841 1. Note that this is an operational issue, not an interoperability 1842 issue. 1844 The use case for accomplishing lookups when PKCs are not sent in IKE 1845 is a stated non-goal of the profile at this time. 1847 3.7.1 Error Handling for Repository Lookups 1849 Thorough error condition descriptions and handling instructions are 1850 required for each transaction in the repository lookup process. 1851 Providing such error codes will greatly aid interoperability efforts 1852 between the PKI and IPsec products. 1854 3.8 Revocation Action 1856 The Peer MUST be able to initiate revocation for its own PKC. In this 1857 case the revocation request MUST be signed by the Peer's current key 1858 pair for the PKC it wishes to revoke. Whether the actual revocation 1859 request transaction occurs directly with the PKI or is first sent to 1860 Admin who proxies or forwards the request to the PKI is a matter of 1861 implementation. 1863 The Admin MUST be able to initiate revocation for any PKC for which 1864 it authorized the creation. The Admin will identify itself to the PKI 1865 by use of its own PKC; it MUST sign any revocation request to the PKI 1866 with the private key from its own PKC. The PKI MUST have the ability 1867 to configure Admin(s) with revocation authority, as identified by its 1868 PKC. Any PKC authorizations must specify if said PKC may be revoked 1869 by the Admin (see section 3.2.3.2 for more details). 1871 The profile MUST identify the one protocol or transaction within a 1872 protocol to be used for both Peer and Admin initiated revocations. 1874 The profile MUST identify the size of CRL the client will be prepared 1875 to support. 1877 Bonatti, Turner, Lebowitz 36 1878 IPsec Certificate Management Profile 1880 Below are guidelines for revocation in specific transactions: 1882 - AFTER RENEW, BEFORE EXPIRATION: The PKI MUST be responsible for 1883 the PKC revocation during a renew transaction. PKI MUST revoke 1884 the PKC after receiving the confirm notification from the Peer, 1885 and before sending the confirm-ack to the Peer. The Peer MUST 1886 NOT revoke its own PKC in this case. 1888 - AFTER CHANGE, BEFORE EXPIRATION: The PKI MUST be responsible for 1889 the PKC revocation during a change transaction. PKI MUST revoke 1890 the PKC after receiving the confirm notification from the Peer, 1891 and before sending the confirm-ack to the Peer. The Peer MUST 1892 NOT revoke its own PKC in this case. 1894 3.9 Revocation Checking and Status Information 1896 The PKI System MUST provide a mechanism whereby Peers can check the 1897 revocation status of PKCs that are presented to it for IKE identity. 1898 The mechanism should allow for access to extremely fresh revocation 1899 information. CRLs have been chosen as the mechanism for communicating 1900 this information. Operators are RECOMMENDED to refresh CRLs as often 1901 as logistically possible. 1903 A single manadatory protocol mechanism for performing CRL lookups 1904 MUST be specified by the final specification. 1906 All PKCs used in IKE MUST have cRLDistributionPoint and 1907 authorityInfoAccess fields populated with valid URLs. This will allow 1908 all recipients of the PKC to know immediately how revocation is to be 1909 accomplished, and where to find the revocation information. The AIA 1910 is needed in an environment where multiple layers of CAs exist and 1911 for the case of a CA key roll-over. 1913 IPsec Systems have an OPTION to turn off revocation checking. Such 1914 may be desired when the two Peers are communicating over a network 1915 without access to the CRL service, such as at a trade show, in a lab, 1916 or in a demo environment. If revocation checking is OFF, the 1917 implementation MUST proceed to use the PKC as valid identity in the 1918 exchange and need not perform any check. 1920 If the revocation of a PKC is used as the only means of deactivation 1921 of access authorization for the Peer (or user), then the speed of 1922 deactivation will be as rapid as the refresh rate of the CRL issued 1923 and published by the PKI. If more immediate deactivation of access is 1924 required than the CRL refreshing can provide, then another mechanism 1925 for authorization that provides more immediate access deactivation 1926 should be layered into the VPN deployment. Such a second mechanism is 1927 out of the scope of this profile. (Examples are Xauth, L2TP's 1928 authentication, etc.). 1930 Bonatti, Turner, Lebowitz 37 1931 IPsec Certificate Management Profile 1933 3.9.1 Error Handling in Revocation Checking 1935 Thorough error condition descriptions and handling instructions are 1936 required for each transaction in the revocation checking process. 1937 Providing such error codes will greatly aid interoperability efforts 1938 between the PKI and IPsec products. 1940 4. Security Considerations 1942 TBD 1944 A References 1946 A.1 Normative References 1948 None 1950 A.1 Non-Normative References 1952 [STDPROCESS] Bradner, S., "The Internet Standards Process û Revision 1953 3", BCP 9, RFC 2026, October 1996. 1955 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 1956 Requirement Levels", BCP 14, RFC 2119, March 1997. 1958 [CERTPROFILE] Housley, R., et. al. "Internet X.509 Public Key 1959 Infrastructure Certificate and Certificate Revocation List (CRL) 1960 Profile", RFC 3280, April 2002. 1962 [DOI] Piper, D., "Internet IP Security Domain of Interpretation for 1963 ISAKMP", RFC 2407, November 1998. 1965 B. Acknowledgements 1967 This draft is substantially based on a prior draft draft-dploy- 1968 requirements-00 developed by Project Dploy. The principle editor of 1969 that draft was Gregory M. Lebovitz (NetScreen Technologies). 1970 Contributing authors included Lebovitz, Paul Hoffman (VPN 1971 Consortium), Hank Mauldin (Cisco Systems), and Jussi Kukkonen (SSH 1972 Communications Security). Substantial editorial contributions were 1973 made by Leo Pluswick (ICSA), Tim Polk (NIST), Chris Wells (SafeNet), 1974 Thomas Hardjono(VeriSign), Carlisle Adams (Entrust), and Michael 1975 Shieh (NetScreen). 1977 Once brought to pki4ipsec, the following people made substantial 1978 contributions: [TBD] ... 1980 Bonatti, Turner, Lebowitz 38 1981 IPsec Certificate Management Profile 1983 C. Editor's Address 1985 Chris Bonatti 1986 IECA, Inc. 1987 15309 Turkey Foot Road 1988 Darnestown, MD 20878-3640 USA 1989 bonattic@ieca.com 1991 Sean Turner 1992 IECA, Inc. 1993 1421 T Street NW #8 1994 Washington, DC 20009 USA 1995 turners@ieca.com 1997 Gregory M. Lebovitz 1998 NetScreen Technologies, Inc. 1999 gregory@netscreen.com 2001 D. Summary of Requirements 2003 TBD - EDITOR'S NOTE: Plan to add a summary table similar to those in 2004 RFCs 1122, 1123, and 2975. Table will briefly describe requirement, 2005 state the requirement level (i.e., "MAY", "SHOULD", "MUST", etc.), 2006 and cite the applicable paragraph in this draft. 2008 E. Change History 2010 2004-July Draft-bonatti-pki4ipsec-profile-reqts-01 2012 It is submitted as an individual draft in order to meet a publication 2013 deadline though it has been accepted in to the working group. The 2014 following salient changes were introduced: 2016 - A new Figure 1 was added in section 2.1 to depict just the VPN 2017 System. 2019 - A new Figure 2 was added to depict 2.2 to depict just the PKI 2020 System. 2022 - The old Figure 1 was moved to section 2.3. 2024 - Section 2.3 was split in to three sections to depict the New PKC, 2025 Renewal, and Revocation. Also the text was modified to indicate 2026 that the pictures are only for IPsec Peers generating key pairs 2027 and requesting PKCs. 2029 - Text and a Figure was added to Section 3.4.6 to show the 2030 architectural difference for IPsec Peers enrolling through an 2031 Admin. 2033 Bonatti, Turner, Lebowitz 39 2034 IPsec Certificate Management Profile 2036 - Text and a Figure was added to Section 3.4.7 to show the 2037 architectural difference for Admins performing the entire 2038 enrollment. 2040 2004-January Draft-bonatti-pki4ipsec-profile-reqts-00 2042 This is a revised requirements document based on the existing Project 2043 Dploy requirements draft. It adapts the revisions to adapt the Dploy 2044 requirements to the scope of the proposed charter for an IETF 2045 PKI4IPSEC WG. It is submitted as an individual draft in anticipation 2046 of formation of the WG. The following salient changes were 2047 introduced: 2049 - Rewrote the abstract to focus on the document rather than the 2050 project. 2052 - Rewrote and trimmed introduction to fit proposed scope of 2053 deliverable (2) from IETF PKI4IPSEC charter. 2055 - Rewrote sentences throughout to genericize the document for the 2056 IETF and remove references to Project Dploy objectives. 2058 - Removed reference to the Dploy Business Case. 2060 - Removed the "Audience" subsection of the introduction because it 2061 was redundant with other aspects of the introduction, and 2062 unnecessary with the context of the proposed PKI4IPSEC WG. 2064 - Added definition of Community Realm (used in 3.2.3.3) to the 2065 "Definitions" subsection. 2067 - Added definition of CRL Distribution Points (CDP) and Authority 2068 Info Access (AIA) to the "Definitions" subsection. 2070 - Restructured the "Architecture" section to bring the presentation 2071 of Figure 1 to the front to go along with the overview of the 2072 section, and to add a new step diagram to the "VPN-PKI 2073 Interaction" subsection. 2075 - Added a new subsection 2.1.2 to describe the VPN peer. Text of 2076 the new subsection will be supplied in a subsequent draft. 2078 - Added an editor's note to subsection 3.1.2 noting that further 2079 elaboration on the nature of "policy details" may be required. 2081 - Subsection 3.2 was deleted to maintain the focus on generic 2082 requirements agreed in Minneapolis. Selection of specific 2083 protocols will be done in the deliverable (3) profile. 2085 - Delete the requirement from 3.2.3.1 to include the maximum CRL 2086 size in the certificate template. This may need to be specified 2087 in the profile, but not be in the certificate itself. 2089 Bonatti, Turner, Lebowitz 40 2090 IPsec Certificate Management Profile 2092 - Revised 3.3.3 to to clarify that key escrow requirements and any 2093 key transport between the VPN admin and the peer are beyond 2094 scope. 2096 - Adopted consistent spelling "enrollment" vs. "enrolment" 2097 throughout. 2099 - Replaced instances of "and/or" and other slashed terminology with 2100 less ambiguous statements to clarify the requirements. 2102 - Revised the text of 3.5.1 to clarify the proposed requirement in 2103 terms of SHALL and MAY terms. 2105 - Retitled 3.5.2 as "Path Validation" instead of "Chaining". 2107 - Added AIA extension as a MAY requirement in 3.5.2. 2109 - Added an editor's note to subsection 3.5.3 to question whether 2110 additional keyUsage bits should be set in the certificate. 2112 - Removed the requirement for HTTP support in favor of a 2113 requirement for a single mandatory protocol to be specified in 2114 the profile. 2116 - Removed subsection on "Intra-IKE Considerations" as these should 2117 be dealt with in the existing deliverable (1) PKI profiles. 2119 - Deleted existing sections 5 and 6 dealing with the partipating 2120 vendors in Project Dploy. 2122 - Added new section 4 on "Security Considerations". Text of the new 2123 subsection will be supplied in a subsequent draft. 2125 - Revised the "Acknowledgements" section to reflect this revision, 2126 and provide appropriate credit to Project DPloy. 2128 - Normalized "References" section with the ID-Nits promulgated by 2129 the IESG. 2131 - Added a stub for a proposed new Annex D to provide a requirements 2132 summary table. Content of the annex will be supplied in a 2133 subsequent draft. 2135 2002-March Draft-dploy-requirements-00 2137 - First public draft of the document released. 2139 Copyright (C) The Internet Society 2004. This document is subject 2140 to the rights, licenses and restrictions contained in BCP 78, and 2141 except as set forth therein, the authors retain all their rights." 2143 Bonatti, Turner, Lebowitz 41 2144 IPsec Certificate Management Profile 2146 "This document and the information contained herein are provided on 2147 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2148 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2149 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2150 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2151 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2152 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2154 Expires January 2005 2156 Bonatti, Turner, Lebowitz 42