idnits 2.17.1 draft-pritikin-est-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4671 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: 'TLS' is mentioned on line 102, but not defined == Missing Reference: 'RFC5785' is mentioned on line 636, but not defined ** Obsolete undefined reference: RFC 5785 (Obsoleted by RFC 8615) ** Downref: Normative reference to an Informational RFC: RFC 2315 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5430 (Obsoleted by RFC 6460) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Pritikin, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track July 11, 2011 5 Expires: January 12, 2012 7 Enrollment over Secure Transport 8 draft-pritikin-est-02 10 Abstract 12 This document specifies a protocol for certificate Enrollment over 13 Secure Transport (EST). EST is a certificate enrollment protocol 14 that operates over HTTPS, and thus should be trivially accessible by 15 modern clients. The Certificate Management over CMS (CMC) "Simple 16 PKI Request" and "Simple PKI Response" messages are leveraged. EST 17 is designed to be easily implemented by clients and servers running 18 other common enrollment mechanisms such as Simple Certificate 19 Enrollment Protocol (SCEP). Renewal and rekey mechanisms are 20 described consistent with Certificate Management Protocol (CMP). 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 12, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 58 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3. Secure Transport . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.1. HTTPS-Based Server Authentication . . . . . . . . . . . . 9 61 3.2. Server Authentication and Authorization . . . . . . . . . 10 62 3.3. HTTPS-Based Client Authentication . . . . . . . . . . . . 11 63 3.4. HTTP-Based Client Authentication . . . . . . . . . . . . . 11 64 3.5. Client Authorization . . . . . . . . . . . . . . . . . . . 12 65 3.6. Proof-of-Possession . . . . . . . . . . . . . . . . . . . 12 66 3.7. Peer Authentication . . . . . . . . . . . . . . . . . . . 13 67 4. HTTP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 5.1. Distribution of CA certificates . . . . . . . . . . . . . 15 70 5.1.1. Distribution of CA certificates response . . . . . . . 15 71 5.2. Simple Enrollment of Clients . . . . . . . . . . . . . . . 16 72 5.2.1. Simple Re-Enrollment of Clients . . . . . . . . . . . 16 73 5.2.2. Simple Enroll and Re-Enroll Response . . . . . . . . . 17 74 5.3. Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 5.3.1. Full CMC Request . . . . . . . . . . . . . . . . . . . 18 76 5.3.2. Full CMC Response . . . . . . . . . . . . . . . . . . 18 77 6. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 18 78 7. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 19 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 84 Appendix A. Server Discovery . . . . . . . . . . . . . . . . . . 22 85 Appendix B. External TLS concentrator . . . . . . . . . . . . . . 22 86 Appendix C. CGI Server implementation . . . . . . . . . . . . . . 23 87 Appendix D. Updating SCEP implementations . . . . . . . . . . . . 23 88 Appendix E. Key Update mechanisms . . . . . . . . . . . . . . . . 25 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 This document profiles certificate enrollment for clients using 94 Certificate Management over CMS [RFC5272] messages over a secure 95 transport. This profile describes a simple yet functional 96 certificate management protocol targeting simple PKI clients that 97 need to acquire client certificate(s) and associated infrastructure 98 certificate(s). 100 "CMC: Transport Protocols" [RFC5273] provides some guidance for 101 running CMC over HTTP [RFC2617] but notes only that "clients MAY 102 attempt to send HTTP requests using TLS 1.0 [TLS] or later, although 103 servers are not required to support TLS". No attempt is made in that 104 document to specify how the client and server might take advantage of 105 a secured transport to better leverage the Simple PKI messages. This 106 profile specifies secure transport mechanisms and how values from the 107 TLS exchange, the HTTP exchange, and the CMC Simple PKI messages 108 layers are used for authentication (and authorization) purposes by 109 the server. 111 The aspects profiled from TLS/HTTPS, CMS and CMP are summarized in 112 Figure 1: 114 Profiled Layers: 116 Protocol: 117 +---------------------------------------------------+ 118 | | 119 | 3) Message types | 120 | CMC "Simple PKI" messages. | 121 | PEM encoded certifiate chains. | 122 | Optionally "Full" CMC messages. | 123 | | 124 +---------------------------------------------------+ 125 | | 126 | 2) HTTP headers and URLs for control | 127 | URLs used to specify the PKI operation | 128 | (including renew/rekey). | 129 | Content-Type headers specify the message type. | 130 | Headers profiled for control/error messages. | 131 | Username/password methods supported for | 132 | client proof-of-identity. | 133 | | 134 | | 135 +- ----(combination is known as HTTPS)--+ 136 | | 137 | | 138 | 1) TLS for transport security | 139 | Provides proof-of-identity for | 140 | EST Server authentication and | 141 | EST Client authentication. | 142 | "Channel binding" type techniques used to | 143 | during Proof-of-Possesion. | 144 | | 145 +---------------------------------------------------+ 146 | | 147 | TCP/IP layer etc included in diagram for context | 148 | | 149 +---------------------------------------------------+ 151 Application Logic: 152 +------------------------------------+ 153 | | 154 | 4) Certificate Chain Validation | 155 | Certificate chains that include | 156 | rekey/renewed certificates as | 157 | specified in CMP. | 158 | | 159 +------------------------------------+ 160 Figure 1 162 The following provides a high level overview describing how these 163 layers are used. Each aspect is profiled in detail in the sections 164 below. 166 1) TLS for transport security: 168 CMC section 3.1 notes that "the Simple PKI Request MUST NOT be 169 used if a proof-of-identity needs to be included". This precludes 170 use of these messages if inline authentication and/or 171 authorization is required, unless a secured transport that 172 provides proof-of-identity is also specified. Many simple clients 173 engaged in certificate enrollment operations will have a TLS 174 client implementation available for secure transport, so use of 175 TLS is specified herein. This document specifies a method for 176 authorizing client enrollment requests using existing 177 certificates. Such existing certificates may have been issued by 178 the CA (from which the client is requesting a certificate) or they 179 may have been issued under a distinct PKI (e.g. an IEEE 802.1AR 180 IDevID [IDevID] credential). Additionally this document specifies 181 username/password authentication methods beyond those included in 182 CMC. Authentication and authorization mechanisms required for 183 certificate issuance (and renew/rekey) are provided by HTTP and 184 TLS (HTTPS) mechanisms as described in this document. 186 Proof-of-possession is a distinct issue from proof-of-identity and 187 is addressed in Section 3.6. 189 This document also defines an appropriate transport for the full 190 CMC specification compliant with CMC Transport Protocols. 192 2) HTTP Headers and URLs for control: 194 This profile supports two operations indicated by specific URLs: 196 * Distribution of CA certificates 198 * Authorized enrollment and re-enrollment of clients 200 This document profiles HTTP headers to indicate the message type 201 and to provide the protocol control messages. Support for the 202 HTTP username/password methods is profiled. 204 CMC also states that: "No special services are provided for doing 205 either renewal (new certificates with the same key) or rekeying 206 (new certificates on new keys) of clients. Instead a renewal/ 207 rekey message looks the same as any enrollment message, with the 208 identity proof being supplied by existing certificates from the 209 CA." This profile clarifies the renewal and rekey behavior of 210 both the client and server. It does so by specifying the HTTP 211 control mechanisms required of the client and server without 212 require a distinct message type. 214 3) Message Types: 216 Some messages types used here are defined in CMC and include 217 subsets of the PKCS#10 Certification Request [RFC2986] and the 218 PKCS#7 [RFC2315] message specifications. 220 This document profiles the use of two Certificate Management over 221 CMS messages: "Simple PKI Request" and "Simple PKI Response" and 222 does not require full implementation of all CMC features. This is 223 consistent with the CMC protocol specification of "simple" 224 messages for clients to use "in the event no other services are 225 needed". Additional simple message formats are defined in this 226 document. To support distribution of the CA certificate chain a 227 simple PEM format is specified. Full CMC messages MAY be used as 228 specified below. 230 HTTP Content-Type headers are as specified in CMC: Transport 231 Protocols, Table 1. This document introduces new content types 232 for the simple format messages not specified by CMC. 234 4) Certificate Chain Validation: 236 A small clarification of the application layer certificate chain 237 validation logic is provided by a normative reference to CMP. The 238 certificate renewal and rekey certificate chaining mechanisms 239 documented in CMP [RFC4210] are referenced. 241 An EST server providing certificate management functions is operated 242 by (or on behalf of) a CA or RA. 244 An EST server MAY provide additional, non-EST services on other URLs. 245 The server also MAY support full CMC messages over HTTP. 247 [[EDNOTE: Comments such as this one, included within double brackets 248 and initiated with an 'EDNOTE', are for editorial use and shall be 249 removed as the document is polished.]] 251 1.1. Requirements Language 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 255 document are to be interpreted as described in [RFC2119]. 257 2. Requirements 259 [[EDNOTE: The following section is still included here for 260 succinctness. It will eventually be published independently as 261 draft-pritikin-estr-00.]] 263 The following describes goals and technical requirements for initial 264 PKI certificate enrollment along with a rationale for each 265 requirement. 267 G1 "Completeness". Server and client implementations compliant with 268 this document MUST be able to interoperate without reference to 269 subsequent profiles or additional future specifications. 271 The goal of this enrollment protocol is to provide a simple and easy- 272 to-implement method for end-entities to request, obtain and update a 273 certificate issued from a specified Certification Authority. The 274 following certificate management operations are required. Additional 275 operations NEED NOT be supported (via this protocol) although the 276 protocol design SHOULD be extensible: 278 M1 "Distribution of current CA certificates". Clients MUST be able 279 to obtain the current certificate for the CA under which the 280 client's certificate was issued. Certificates have a finite 281 lifetime and will need to be updated on a periodic basis. It must 282 be possible for the client to obtain the updated CA certificates. 284 M2 "Enrollment". A client MUST be able to use the protocol to submit 285 a certificate request and obtain a certificate. 287 M3 "Renew/Rekey". Certificates have a finite lifetime and will need 288 to be updated on a periodic basis. A client MUST be able to use 289 the protocol for certificate renewal or rekey operations. 291 End-Entity Proof of Identity authentication mechanisms: 293 A1 "Username/Password". It MUST be possible to identify a username 294 specified client as being in possession of an associated symmetric 295 key. This allows users currently in possession of a username and 296 password to obtain a certificate. 298 A2 "Password". It MUST be possible to identity a client wihtout 299 reference to a "username". A common operational model is to 300 distribute a "one time password" that is presented to a CA or RA 301 to authorize enrollment. 303 A3 "Existing Certificate". It MUST be possible to authenticate a 304 client by making use of an existing certificate associated with 305 the client. A certificate used for client identification need not 306 be issued under the same PKI as the certificate that is being 307 requested. This allows clients that are already in a PKI to use a 308 certificate from that PKI to obtain additional certificates. 309 Additionally this capability allows a client who has a certificate 310 issued by a 3rd party, such as a certificate issued by a device 311 manufacturer, to leverage that credential during initial 312 enrollment. 314 A4 "Username/password and Certificate". It MUST be possible to 315 authenticate a client by using a combination of a username and 316 password and an existing certificate. This is a combination of A1 317 and A3. This supports "two factor authentication" where the 318 client proves possession of the private keys for an existing 319 certificate stored within a hardware device and knowledge of a 320 username/password. 322 A5 "Password and certificate". It MUST be possible to authenticate a 323 client by using a combination of a secrete value that is not 324 associated with a "username" and an existing certificate. This is 325 a combination of A2 and A3. This requirement is similar to A4 326 except that the client is in possession of a "one time password". 328 End-Entity Proof of Possession: 330 P1 Proof-of-Possession of subject keys MUST be supported. As 331 discussed in Appendix C of [RFC4211] Proof-of-Possession "means 332 that the CA is adequately convinced that the entity requesting a 333 certificate for the public key Y, has access to the corresponding 334 private key X". 336 Key algorithms: 338 K1 "Algorithm agility". The protocol MUST support algorithm agility. 339 It must be possible to employ different cryptographic algorithms 340 for securing the transport or for signing the certificates. The 341 protocol SHOULD demonstrate this agility by being shown to work 342 with existing RSA based solutions as well as providing for other 343 algorithms such as Elliptic Curve cryptography. 345 Server Identity mechanism: 347 I1 "RA certificate". It MUST be possible for a client to verify 348 authorization of the EST server as a representative of the CA. 349 The protocol operations allow the client to send a username/ 350 password or (one time) password to the EST server. These values 351 cannot be safely transmitted to an unauthorized server. 353 3. Secure Transport 355 HTTPS MUST be used. TLS 'session resumption' SHOULD be supported. 357 HTTPS is defined in HTTP Over TLS [RFC2818] and is a definition of 358 how HTTP messages are carried over TLS. HTTPS (HTTP over TLS) is a 359 commonly used transport and can be easily layered on top of extremely 360 simple client or server code. In some environments HTTPS can be 361 utilized through an external process. Specifying HTTPS as the 362 secured transport for PKI enrollment messages introduces two 363 potential 'layers' for communication of authorization data or for 364 status/informative responses during the protocol exchange: TLS and 365 HTTPS. This profile specifies when information is used from each 366 layer. 368 3.1. HTTPS-Based Server Authentication 370 The client MUST validate the HTTPS server certificate presented 371 during the TLS [RFC5246] defined Server Certificate message or the 372 client MUST independently validate the response contents. The cipher 373 suites are detailed in Section 6. 375 There are multiple methods of validation depending on the current 376 state of the client: 378 1. If the client has a store of trust anchors, which may be in the 379 form of certificates, for validating HTTPS connections the client 380 MAY validate the HTTPS server certificate using the standard HTTP 381 logic of checking the server's identity as presented in the 382 server's Certificate message against the URL provisioned for the 383 EST server (see HTTPS Over TLS, Section 3.1 Server Identity. 384 This method makes it possible for clients with a large store of 385 HTTPS certificates to securely obtain the CA server certificate 386 by leveraging the HTTPS security model. Note that the EST server 387 URL MUST be made available to the client in a secure fashion and 388 many systems are configured with many trust anchors from a wide 389 range of CAs and this would make such systems vulnerable to 390 spoofing of the ETS server certificate by an attacker that is 391 ablet to obtain an erroneous certificate from a lax CA. As 392 detailed in Section 9 clients are RECOMMENDED to ship with a 393 carefully chosen list of initial trust anchors. Proper selection 394 of initial trust anchors is out of scope of this document. 396 [[EDNOTE: is there an RFC discussing this problem in the HTTPS 397 space that we can reference?]] 399 2. If the client already has one or more trust anchors associated 400 with this EST server, the client MAY validate the EST server 401 certificate using these trust anchors. The EST server URL MAY be 402 made available to the client in an insecure fashion. 404 3. If the client does not yet have a trust anchor associated with 405 this EST server then the client MAY provisionally accept the TLS 406 connection, but the HTTP content data must be accepted manually 407 as described in Section 5.1. HTTP authentication requests MUST 408 NOT be responded to. 410 If one of these validation methods succeeds the CA certificate are 411 stored and made available for future use. If none of these 412 validation methods succeeds the client MUST reject the EST server 413 response and SHOULD log or inform the end user. 415 The EST server MUST present an end-entity certificate such as the CMC 416 Local Registration Authority (LRA) certificate. The client MUST 417 support validating the EST server certificate using the "Verifying 418 Certificates" logic specified in CMP section 4.4. Appendix E 419 provides an informative summary of key renewal and the associated 420 validation logic. 422 3.2. Server Authentication and Authorization 424 The client MUST check the EST server authorization. 426 If the client has a securely configured and authorized URI for the 427 EST server it SHOULD check the URI "against the server's identity as 428 presented in the server's Certificate message" (Section 3.1 Server 429 Identity [RFC2818]). The securely configured URI provides the 430 authorization statement and the server's authenticated identity 431 confirms it is the authorized server. 433 If this check fails, or if the URI was configured using an insecure 434 method, then the client MUST verify the server's authorization by 435 checking that the [RFC5280] defined certificate policy extension 436 sequence contains the 'LRA Authorization' policy OID. 438 The LRA Authorization policy OID is defined as: id-cmc [[EDNOTE: TBD, 439 perhaps 35]]. The LRA Authorization policy information MUST NOT 440 contain any optional qualifiers. 442 3.3. HTTPS-Based Client Authentication 444 The server MUST send a TLS section 7.4.4 "Certificate Request" and 445 the client MUST respond. The client MUST respond with a certificate 446 that allows it to subsequently send the a TLS Section 7.4.8 447 "Certificate Verify" (i.e. the client MUST use an end entity "client 448 certificate that has signing capability"). The server MUST verify 449 the Certificate Verify message. 451 The certificate presented by the client MAY be from the same PKI as 452 the Server Certificate, from a completely different PKI, or as a last 453 resort the client MAY respond with a self-signed certificate. The 454 certificate supplied during authentication is used during client 455 authorization (Section 3.5). 457 The server MUST support the validation of the EST client certificate 458 using normal certificate validation logic including rekey/renew 459 support as specified in CMP section 4.4. Appendix E provides an 460 informative summary of key renewal and the associated validation 461 logic. 463 3.4. HTTP-Based Client Authentication 465 As specified in CMC: Transport Protocols the server "MUST NOT assume 466 client support for any type of HTTP authentication such as cookies, 467 Basic authentication, or Digest authentication". Clients intended 468 for deployments where password authentication is advantageous SHOULD 469 support the Basic and Digest authentication mechanism. Servers MAY 470 provide configuration mechanisms for administrators to enable Basic 471 and Digest authentication methods. 473 Servers that support Basic and Digest authentication methods reject 474 requests using the HTTP defined WWW-Authenticate response-header 475 (Section 14.47). At which point the client SHOULD repeat the 476 request, including the appropriate HTTP [RFC2617] Authorization 477 Request Header (Section 3.2.2). 479 Support for Basic authentication as specified in HTTP allows the 480 server access to the client's cleartext password. This provides 481 integration with legacy username password databases but requires 482 exposing the plaintext password to the EST server. The client MUST 483 NOT respond to this request unless the EST server has been 484 authenticated (as per Section 3.2). 486 Clients MAY set the username to the empty string ("") if they wish to 487 present a "one time password" or "PIN" that is not associated with a 488 username. 490 3.5. Client Authorization 492 When the CA server receives a CMC Simple PKI Enrollment or re- 493 enrollment message, the decision to issue a certificates is always a 494 matter of local policy. Thus the CA can use any data it wishes in 495 making that determination. The EST protocol exchange provides the 496 EST server access to the TLS client Certificate in addition to the 497 HTTP user authentication credentials to help in that determination. 498 The communication channel between the TLS implementation and the EST 499 software implementation is out-of-scope of this document. 501 3.6. Proof-of-Possession 503 As discussed in Appendix C of CRMF [RFC4211] Proof-of-Possession 504 "means that the CA is adequately convinced that the entity requesting 505 a certificate for the public key Y, has access to the corresponding 506 private key X". 508 This specification provides proof-of-possession by including 509 information specific to the current TLS session within the signed 510 certification request. This proves to the server that the TLS client 511 has possession of the private key associated with the certification 512 request and that the client was able to sign the certification 513 request after the TLS session was established. The value included 514 within the certification request is very similar to "tls-unique" as 515 defined in Channel Bindings for TLS [RFC5929]. The value is defined 516 as: 518 tls-unique-securerenegotiation: The first TLS Finished message 519 sent in the _first_ TLS handshake of the TLS connection that is 520 being bound to is the TLS "channel binding" value. Any TLS 521 renegotiation MUST use "secure_renegotiation" [RFC5746] (thus 522 maintaining the binding). Mandating secure renegotiation allows 523 implementations to avoid the synchronization issues encountered 524 with tls-unique. 526 The client generating the request SHOULD obtain the tls-unique- 527 securerenegotation value, encode it using base64 encoding, and place 528 the resulting string in the certification request challenge password 529 field. 531 The server SHOULD verify the tls-unique-securerenegotation 532 information. This ensures that the authenticated TLS client is in 533 possession of the private key used to sign the certification request. 535 The tls-unique-securerenegotiation value is encoded into the 536 certification request by the client but back-end infrastructure 537 elements that process the request might not have access to the 538 initial TLS session. Such infrastructure elements validate the 539 source of the certification request to determine if proof-of- 540 possession checks have already been performed. For example if the 541 client authentication results in an authenticated client identity of 542 an RA that is known to independently verify the proof-of-possession, 543 then the back-end infrastructure does not need to perform proof-of- 544 possession checks a second time. 546 Implementation Note: The tls-unique value is consistent with tls- 547 unique-securerenegotiation until after a renegotiation (at which 548 point the tls-unique value is the TLS Finished message of the "most 549 recent TLS handshake" instead of the "first handshake"). A valid 550 tls-unique-securerenegotiation value can be obtained by careful use 551 of the implementation's tls-unique channel binding TLS APIs so long 552 as renegotiation has not yet taken place. 554 The use of tls-unique-securerenegotiation makes it possible for 555 servers to wait to request TLS client authentication until after the 556 URI has been parsed, as is commonly implemented. 558 3.7. Peer Authentication 560 The EST server can itself be an EST client when an RA uses EST to 561 communicate with back-end infrastructure elements. Authentication of 562 credentials identifying an EST peer is in scope in that appropriate 563 generic credential authentication in an environment supporting Root 564 CA Key Update is mandated. EST clients validating peer (other EST 565 client) certificates MUST support the Root CA Key Update verification 566 mechanisms specified in CMP section 4.4 when validating the peer 567 certificates. Appendix E provides an informative summary on key 568 renewal. 570 4. HTTP URLs 572 EST uses the HTTP "GET" and "POST" messages to communicate with the 573 EST server. The following describes the syntax of these messages: 574 "GET" BASEPATH OPERATIONPATH 575 "POST" BASEPATH OPERATIONPATH 577 where: 579 o BASEPATH is a common path for all EST operations 581 o OPERATIONPATH specifies the specific operation. 583 When an URL is formed the BASEPATH and OPERATIONPATH are combined to 584 form the abs_path [RFC2616]. The server and port and MUST be pre- 585 configured or otherwise discovered by the client as described in 586 Appendix A. The means by which clients acquire the base URL are 587 outside the scope of this document. The following are two example 588 base URLs: 590 o https://example.org/BASEPATH 592 o https://example.org:8080/arbitrary/base/path 594 These can be conveniently distributed as they are in a form with 595 which many end users are already familiar. The following operation 596 URLs for client to access are defined relative to the EST base URL: 598 o /CACerts - The server responds to an HTTPS GET with the CA 599 certificates as defined in Distribution of CA certificates 600 (Section 5.1). 602 o /simpleEnroll - The client sends a CMC Simple PKI Enrollment 603 message as specified in Enrollment of Clients (Section 5.2), the 604 response is a CMC Simple PKI Response. message as specified in 605 Enroll Response (Section 5.2.2). 607 o /simpleReEnroll - Exactly the same as 'simpleEnroll' except that 608 the request is for re-enrollment or re-issuance purposes. 610 o /fullCMC - Provides for a CMC transport (optional). 612 The following examples are valid complete URLs under this 613 specification: 615 o https://example.org/BASEPATH/CACerts 617 o https://example2.org/arbitrary/base/path/simpleEnroll 619 o https://example2.org/arbitrary/base/path/simpleReEnroll 621 o https://example3.org/example/ca/fullCMC 623 The mechanisms by which the EST server interacts with an HTTPS server 624 to handle GET and POST operations at these URLs is outside the scope 625 of this document. The use of distinct URLs simplifies implementation 626 for servers that do not perform client authentication when 627 distributing "CACerts" responses. 629 Implementation note: A simple Common Gateway Interface (CGI) 630 application at each fully specified path, with the HTTPS server 631 configured to provide Section 3.3, is sufficient for a working 632 example (the web service can forward the Section 3.6 proof-of- 633 possession information to the application using the CGI interface). 635 [[EDNOTE: This does not use the mechanism specified in "Defining 636 Well-Known Uniform Resource Identifiers (URIs)" [RFC5785]. That 637 would be a possibility here for a base URL of 638 "https://example.org/.well-known/EST" but such would preclude the 639 flexibility associated with multiple base urls being handled by the 640 same server unless some form of "?designator=value" is included.]] 642 5. Messages 644 5.1. Distribution of CA certificates 646 Before engaging in enrollment operations, clients MUST request trust 647 anchor information by sending an HTTPS GET message to the EST base 648 URL with the relative path extension 'CACerts'. Clients SHOULD 649 request an up to date response before stored information has expired. 651 The EST server SHOULD NOT require client authentication or 652 authorization to reply to this request. 654 The client MUST authenticate the EST server as specified in 655 Authentication and Authorization (Section 3). If the authentication 656 and authorization is successful, the client accepts the response and 657 stores it. If the authentication and authorization is not 658 successful, then when the response is received the client MUST 659 extract the CA certificate and engage the end-user or otherwise 660 authorize the credential using out-of-band pre-configuration data 661 such as a CA certificate "fingerprint" (e.g., a SHA-1, SHA-256, SHA- 662 512, or MD5 hash on the whole CA certificate). 664 The client MUST NOT accept the CA certificate without validating it 665 via one of the mechanisms described above. 667 Subsequent connections to the EST server validate the TLS server 668 certificate using the stored CA certificates as described in 669 Authentication and Authorization (Section 3). 671 5.1.1. Distribution of CA certificates response 673 The EST server MUST respond to the client HTTPS GET message with 674 trust anchor information in the form of a certificate. Additionally 675 the server MUST include any "Root CA Key Update" CMP certificates 676 (Appendix E provides an informative summary of "Root CA Key Update"). 678 The response format is a text file containing a list of certificates 679 each formatted as specified in Section 6.1 of [RFC4945]. Each 680 certificate is delimited by a newline. The content-type of 681 "application/x-est-cacerts" MUST be specified. 683 5.2. Simple Enrollment of Clients 685 At any time the client MAY request a certificate from the EST base 686 URL with the relative path extension "simpleEnroll'. 688 When HTTPS POSTing to the 'Enroll' location the client MUST include a 689 CMC Simple PKI Enrollment request as specified in CMC Section 3.1 (a 690 PKCS#10 Certification Request). 692 The content-type of "application/x-est-pkcs10" MUST be specified. 693 The format of the request is as specified in Section 6.4 of 694 [RFC4945]. 696 The server MUST authenticate the client as specified in 697 Authentication and Authorization (Section 3). The server applies 698 whatever authorization or policy logic it chooses determining if the 699 certificate should be issued. The server MAY choose to issue a 700 certificate different from the certificate request as specified in 701 CMC Section 3.1. The client MAY request an additional certificate 702 even when using an existing certificate in the TLS client 703 authentication. 705 The client MUST authenticate the EST server as specified in 706 Section 3.1. 708 If the EST server forwards the request to a back-end process it 709 SHOULD communicate the authentication results. For example using the 710 CMC "RA POP Witness Control" in a CMC Full PKI Request message. 712 5.2.1. Simple Re-Enrollment of Clients 714 At any time a client MAY request renew/rekey of its certificate from 715 the EST base URL with the relative path extension "simpleReEnroll'. 716 The certificate request is the same format as for the "simpleEnroll" 717 path extension with the same content-type. 719 The EST server MUST handle enrollment requests submitted to the 720 "simpleReEnroll" URL as renewal or rekey requests rather than 721 depending only on the method of identifying a renewal or rekey 722 request specified in Section 2 of RFC5272 [RFC5272], that "renewal 723 and rekey requests look the same as any certification request, except 724 that the identity proof is supplied by existing certificates from a 725 trusted CA". The proof of client identity is supplied by client 726 authentication during the HTTPS handshake. When attempting to renew 727 or rekey the client MUST use its existing certificate for TLS client 728 authentication. 730 [[EDNOTE: draft-turner-suiteb-cmc defines a method of recognizing an 731 re-enroll based on PKCS10 contents, see section 4.1. The method 732 described herein is explicit.]] 734 If the server forwards the request to a back-end process it SHOULD 735 communicate that this is a renew/rekey attempt. Implementation note: 736 if using this protocol to communicate with a CA the /simpleReEnroll 737 URL is used. 739 5.2.2. Simple Enroll and Re-Enroll Response 741 The server responds to a 'simpleEnroll' or 'simpleReEnroll' request 742 with the client's newly issued certificate or it provides an error 743 response. 745 If the enrollment is successful the server response MUST have a 746 response code of 200 with a content-type of "application/x-est-x509". 747 The response data is the certificate formatted as specified in 748 Section 6.1 of [RFC4945]. The issued certificate MAY be signed by a 749 new CA key established as described in CMP. 751 When rejecting a request the server MUST specify either an HTTP 4xx/ 752 401 error, or an HTTP 5xx error. A simple CMC response with content- 753 type of "application/pkcs7-mime" MAY be included in the response data 754 for any error response. If the content-type is not set the response 755 data MUST be a plain text human readable error message. A client MAY 756 elect to not parse a CMC error response in favor of a generic error 757 message. 759 If the server responds with an HTTP 202 this indicates that the 760 request has been accepted for processing but that a response is not 761 yet available. The server MUST include a Retry-After header as 762 defined for 503 responses and MAY include informative human readable 763 content. The client MUST wait at least the specified 'retry-after' 764 time before repeating the same request. The client repeats the 765 initial enrollment request after the appropriate 'retry-after' 766 interval as expired. The client SHOULD log or inform the end user of 767 this event. The server is responsible for maintaining all state 768 necessary to recognize and handle retry operations as the client is 769 stateless in this regard (it simply sends the same request repeatedly 770 until it receives a different response code). 772 All other return codes are handled as specified in HTTP. 774 5.3. Full CMC 776 At any time the client MAY request a certificate from the EST base 777 URL with the relative path extension "fullCMC". 779 The client MUST authenticate the server as specified in Server 780 Authentication (Section 3.1) if an HTTPS url is used. 782 The server SHOULD authenticate the client as specified in 783 Authentication and Authorization (Section 3). The server MAY depend 784 on CMC client authentication methods instead. 786 In addition to the normal CMC proof-of-identity mechanisms the client 787 SHOULD include the Section 3.6 value. 789 5.3.1. Full CMC Request 791 When HTTP(S) POSTing to the 'fullCMC' location the client MUST 792 include a valid CMC message. The content-type MUST be set to 793 "application/pkcs7-mime" as specified in CMC: Transport Protocols. 795 5.3.2. Full CMC Response 797 The server responds with the client's newly issued certificate or 798 provides an error response. 800 If the enrollment is successful the server response MUST have a 801 response code of 200 with a content-type of "application/pkcs7-mime" 802 as specified in CMC: Transport Protocols. The response data includes 803 either the CMC Simple PKI Response or the CMC Full PKI Response. 805 When rejecting a request the server MAY specify either an HTTP 4xx/ 806 401 error, an HTTP 5xx error or a response code 200. A CMC response 807 with content-type of "application/pkcs7-mime" MUST be included in the 808 response data for any error response. The client MUST parse the CMC 809 response to determine the current status. 811 All other return codes are handled as specified in Section 5.2.2 or 812 HTTP [RFC2616]. 814 6. Cryptographic Algorithms 816 This section details the specific cryptographic algorithms and cipher 817 suite requirements. 819 When the TLS connection is established the supported cipher suite 820 codes are exchanged in the ClientHello and ServerHello messages. The 821 negotiated cipher suite denotes the algorithms used during client and 822 server authentication and these are negotiated to match the 823 credentials available to the peers. 825 The client SHOULD offer the Suite B compliant cipher suites as 826 indicated in [RFC5430], Section 4 "Suite B Compliance and 827 Interoperability Requirements". For greatest interoperability the 828 client SHOULD also offer TLS_RSA_WITH_AES_128_CBC_SHA. 830 When the client accesses the "simpleReEnroll" method the cipher suite 831 MUST be appropriate for the existing certificate. The certificate 832 type used determines the appropriate signatureAlgorithm for the 833 PKCS#10 Certification Request. For example if a [RFC5430] cipher 834 suite is used the signatureAlgorithm MAY be ecdsa-with-sha256 for 835 P-256 certification requests, or MAY be ecdsa-with-sha384 for P-384 836 certification requests. 838 [[EDNOTE: This is in alignment with draft-turner-suitb-cmc-03 section 839 4.1. To encourage algorithm agility, discussions of the MUST/SHOULD 840 algorithms should be in a distinct document.]] 842 7. Contributors/Acknowledgements 844 The editor would like to thank Stephen Kent, Vinod Arjun, Jan 845 Vilhuber and others for their feedback and prototypes of early 846 drafts. 848 8. IANA Considerations 850 (This section is incomplete) 852 The following aspects should be registered with IANA Considerations: 854 The LRA Authorization certificate policy extension OID as discussed 855 in Section 3.2 requires registration with IANA. 857 [[EDNOTE: The URLs specified in Section 1 probably do not need to be 858 registered with IANA.]] 860 9. Security Considerations 862 (This section is incomplete) 864 "Badges? We ain't got no badges. We don't need no badges! I don't 865 have to show you any stinkin' badges!" -- The Treasure of the Sierra 866 Madre. 868 As described in CMC Section 6.7, "For keys that can be used as 869 signature keys, signing the certification request with the private 870 key serves as a POP on that key pair". The inclusion of tls-unique- 871 securerenegotiation within the certification request provides 872 timeliness to the proof-of-possession. For support of keys that can 873 not be used for signing the certification request the full CMC 874 specification MUST be used. 876 As described in Section 3.3 clients use an existing certificate for 877 TLS client authentication. If a certificate with appropriate key 878 usage is not available the client MAY generate one. If a self-signed 879 certificate with appropriate key usage is used the server SHOULD 880 require HTTP based client authentication according to server policy 881 as described in Section 3.3 and Section 3.5. The server MAY fall 882 back on manual authorization by the server administrator. 884 As described in Section 3.1 servers use an existing certificate for 885 TLS server authentication. When the server certificate is issued by 886 a mutually trusted PKI hierarchy validation proceeds as specified in 887 Section 3.2. In this situation the client has validated the server 888 as being a valid responder for the URI configured but can not 889 directly verify that the responder is authorized as an RA within the 890 to-be-enrolled PKI hierarchy. A client may thus be enticed to expose 891 username/password or certificate enrollment requests to an 892 unauthorized server (if the server presents a valid HTTPS certificate 893 for an erroneous URL that the client has been tricked into using). 894 Proof-of-Identity and Proof-of-Possession checks by the CA prevent an 895 illegitimate RA from leveraging such misconfigured clients to act as 896 a man-in-the-middle during client authenticated operations but it is 897 possible for such illegitimate RAs to send the client doctored 898 messages or erroneous CA certificate lists. If the illegitimate RA 899 has successfully phished a username/password or PIN from the client 900 it might try to use these values to enroll its own keypair with the 901 real PKI hierarchy. EST servers identified with an externally issued 902 server certificate SHOULD require HTTPS based client authentication 903 (Section 3.3). Similarly EST clients SHOULD use an existing client 904 certificate to identify themselves and otherwise prevent "private 905 data" (obviously including passwords but also including private 906 identity information) from being exposed during the enrollment 907 exchange a weak server authorization method is used. 909 10. References 910 10.1. Normative References 912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 913 Requirement Levels", BCP 14, RFC 2119, March 1997. 915 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 916 Version 1.5", RFC 2315, March 1998. 918 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 919 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 920 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 922 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 923 Leach, P., Luotonen, A., and L. Stewart, "HTTP 924 Authentication: Basic and Digest Access Authentication", 925 RFC 2617, June 1999. 927 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 929 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 930 Request Syntax Specification Version 1.7", RFC 2986, 931 November 2000. 933 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 934 "Internet X.509 Public Key Infrastructure Certificate 935 Management Protocol (CMP)", RFC 4210, September 2005. 937 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 938 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 940 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 941 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 943 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 944 (CMC)", RFC 5272, June 2008. 946 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 947 (CMC): Transport Protocols", RFC 5273, June 2008. 949 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 950 Housley, R., and W. Polk, "Internet X.509 Public Key 951 Infrastructure Certificate and Certificate Revocation List 952 (CRL) Profile", RFC 5280, May 2008. 954 [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile 955 for Transport Layer Security (TLS)", RFC 5430, March 2009. 957 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 958 "Transport Layer Security (TLS) Renegotiation Indication 959 Extension", RFC 5746, February 2010. 961 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 962 for TLS", RFC 5929, July 2010. 964 10.2. Informative References 966 [IDevID] IEEE Std, "IEEE 802.1AR Secure Device Identifier", 967 December 2009, . 970 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 971 Certificate Request Message Format (CRMF)", RFC 4211, 972 September 2005. 974 Appendix A. Server Discovery 976 (informative) 978 (This section is incomplete) 980 Clients MAY use DNS-SD or similar discovery algorithms to determine 981 the EST base URL. In such cases it is expected that method 2 982 (Section 3.1) be used during server authentication. 984 Appendix B. External TLS concentrator 986 (informative) 988 In some deployments it may be beneficial to use a TLS concentrator to 989 offload the TLS processing from the server. In such a deployment the 990 TLS client authentication result must, in some way, be forwarded to 991 the server. 993 The TLS server SHOULD NOT reject the connection based on PKIX 994 validation of the client certificate. The client certificate SHOULD 995 be passed to the EST layer for verification and authorization. This 996 allows support of external TLS concentrators, or an external web 997 server, that might provide an independent TLS implementation. 999 The TLS concentrator MUST validate the TLS Section 7.4.8 'Certificate 1000 Verify'. 1002 A TLS concentrator MUST insert the client certificate into the HTTP 1003 header. The TLS concentrator MUST first remove any existing client 1004 certificates, possibly inserted by a nefarious client, from the HTTP 1005 headers before forwarding the HTTP connection to the server. 1007 [TBD - need to better understand what would happen in the case of 1008 proxy's or multiple concentrators. Or specifically state that as out 1009 of scope.] 1011 [TBD - the HTTP header field names etc shall be specified here] 1013 The EST server MUST be specifically configured by the administrator 1014 to accept this mechanism. 1016 Appendix C. CGI Server implementation 1018 (informative) 1020 In some deployments it may be beneficial to use a HTTPS server that 1021 runs the EST server as a CGI application. In such a deployment the 1022 HTTPS server client authentication result must, in some way, be 1023 forwarded to the server. 1025 An HTTPS server MUST insert the client certificate into environment 1026 variables before calling a server CGI application. 1028 [TBD - describe the CGI environment variables here. Can likely 1029 follow the apache example]. 1031 An HTTP server MUST insert the client certificate into environment 1032 variables before calling a server CGI application. 1034 [TBD - describe the CGI environment variables here. Can likely 1035 follow the apache example]. 1037 Appendix D. Updating SCEP implementations 1039 (informative) 1041 SCEP has been used instead of a full implementation of CMC for the 1042 same simplicity reasons discussed in Section 1. Such implementations 1043 would benefit from being updated to this specification in the 1044 following ways: 1046 o Implementing a subset of CMC provides an enhancement path if the 1047 full CMC functionality is required. 1049 o The use of HTTPS as a transport is often perceived as more secure. 1050 Although the SCEP protocol specification includes mechanisms (and 1051 complexity) to address security issues avoiding a vendor 1052 requirement to educate systems administrators is beneficial. 1053 Implementors can benefit from the wide availability of existing 1054 HTTPS/TLS libraries. 1056 o SCEP servers can use their CA certificate to protect SCEP traffic 1057 in ways that are not appropriate. (See SCEP draft Section 8.2). 1058 This specification precludes those misuses. 1060 o The SCEP draft Appendix D renew and rekey functionalities imply a 1061 'flag moment' where the PKI infrastructure transitions from an 1062 (expired) CA certificate to a new CA certificate. This 1063 specification specifies the better mechanism defined in CMP. 1065 Updating an SCEP client implementation to support this protocol 1066 involves the following changes to the SCEP implementation. There is 1067 no server side indication that SCEP clients should be so modified so 1068 this depends on a client side configuration: 1070 o The SCEP client supports HTTPS server authentication and 1071 authorization as detailed Section 3.1. 1073 o The SCEP client supports HTTPS client authentication as detailed 1074 in Section 3.3. 1076 o When performing the "Get CA Cert" SCEP transaction the client 1077 supports the Section 5.1 described CMC Simple PKI Response (ref 1078 CMC 4.1, which is extremely similar to the SCEP "CA/RA Certificate 1079 Response Message Format" if not exactly the same). 1081 o When performing the certificate enrollment via SCEP PKCSReq the 1082 outgoing message is simplified to be only the inner PKCS10 (ref 1083 CMC section 3.2.1.2.1). 1085 o When handling the certificate enrollment response the response 1086 format is simplified to be only the SCEP inner 'messageData' 1087 containing the actual certificates in the degenerate PKCS7 form. 1088 (ref CMC 4.1) The only 'authenticatedAttributes' value of 1089 remaining importance is the 'pkiStatus' and this value is now 1090 found in the HTTP header as defined in Section 5.2.2. 1092 o Polling is simplified with clients repeatedly establishing the 1093 full HTTPS connection; no polling specific state information is 1094 encoded into the EST messages. 1096 o GetCert is deprecated. 1098 o GetCRL is deprecated. 1100 These simplifications to an existing SCEP implementation result in an 1101 SCEP client that is compliant with CMC when using the EST transport. 1103 Implementation note: The use of tls-unique-securerenegotiation 1104 precludes the use of SCEP 'challenge-password' within the pkcs10 for 1105 password/PIN assertion. Instead these values must be asserted with 1106 the Section 3.4 described mechanism. A side effect of this is that a 1107 client communicating with an EST server can not embed an SCEP 1108 'challenge-password' within the PKCS#10. An EST service running as 1109 an RA thus can not forward the PKCS#10 using SCEP to an SCEP server 1110 that expects the 'challenge-password' to be populated. 1112 Appendix E. Key Update mechanisms 1114 (informative) 1116 (This section is incomplete) 1118 The CMP section 4.4 defined Root CA Key Update mechanisms are 1119 repeated here for easier reference. 1121 Author's Address 1123 Max Pritikin (editor) 1124 Cisco Systems, Inc. 1125 510 McCarthy Drive 1126 Milpitas, CA 1127 USA 1129 Email: pritikin@cisco.com