idnits 2.17.00 (12 Aug 2021) /tmp/idnits31309/draft-ietf-pkix-est-00.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 (January 4, 2012) is 3789 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 633, but not defined ** Obsolete undefined reference: RFC 5785 (Obsoleted by RFC 8615) == Unused Reference: 'RFC4210' is defined on line 926, but no explicit reference was found in the text ** 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) ** Downref: Normative reference to an Informational RFC: RFC 2818 ** 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) ** Downref: Normative reference to an Informational RFC: RFC 5967 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX M. Pritikin, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track P. Yee, Ed. 5 Expires: July 7, 2012 AKAYLA, Inc. 6 January 4, 2012 8 Enrollment over Secure Transport 9 draft-ietf-pkix-est-00 11 Abstract 13 This document profiles certificate enrollment for clients using 14 Certificate Management over CMS (CMC) messages over a secure 15 transport. This profile, called Enrollment over Secure Transport 16 (EST), describes a simple yet functional certificate management 17 protocol targeting simple Public Key Infrastructure clients that need 18 to acquire client certificate(s) and associated Certification 19 Authority (CA) certificate(s). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 7, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 57 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Secure Transport . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.1. TLS-Based Server Authentication . . . . . . . . . . . . . 9 60 3.2. Server Authentication and Authorization . . . . . . . . . 10 61 3.3. TLS-Based Client Authentication . . . . . . . . . . . . . 11 62 3.4. HTTP-Based Client Authentication . . . . . . . . . . . . . 11 63 3.5. Client Authorization . . . . . . . . . . . . . . . . . . . 12 64 3.6. Proof-of-Possession . . . . . . . . . . . . . . . . . . . 12 65 3.7. Linking Identity and POP information . . . . . . . . . . . 12 66 4. HTTP URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 5.1. Distribution of CA certificates . . . . . . . . . . . . . 15 69 5.1.1. Distribution of CA certificates response . . . . . . . 15 70 5.2. Simple Enrollment of Clients . . . . . . . . . . . . . . . 16 71 5.2.1. Simple Re-Enrollment of Clients . . . . . . . . . . . 16 72 5.2.2. Simple Enroll and Re-Enroll Response . . . . . . . . . 17 73 5.3. Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.3.1. Full CMC Request . . . . . . . . . . . . . . . . . . . 18 75 5.3.2. Full CMC Response . . . . . . . . . . . . . . . . . . 18 76 6. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 18 77 7. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 19 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 83 Appendix A. Server Discovery . . . . . . . . . . . . . . . . . . 22 84 Appendix B. External TLS concentrator . . . . . . . . . . . . . . 22 85 Appendix C. CGI Server implementation . . . . . . . . . . . . . . 23 86 Appendix D. Updating SCEP implementations . . . . . . . . . . . . 23 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 89 1. Introduction 91 This document specifies a protocol for certificate Enrollment over 92 Secure Transport (EST). EST is a certificate enrollment protocol 93 that operates over HTTPS, and thus should be trivially accessible by 94 most clients. Certificate Management over CMS (CMC) [RFC5272] 95 "Simple PKI Request" and "Simple PKI Response" messages are 96 leveraged. EST is designed to be easily implemented by clients and 97 servers running other common enrollment mechanisms such as the non- 98 standard Simple Certificate Enrollment Protocol (SCEP). 100 "CMC: Transport Protocols" [RFC5273] provides some guidance for 101 running CMC over HTTP [RFC2616] 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 Simple PKI messages layers 108 are used for authentication (and authorization) purposes by the 109 server. For some simple operations, TLS client authentication is 110 required. When TLS client authentication cannot be leveraged as 111 required by a particular operation, EST also provides a conduit for 112 full CMC operations. It is assumed that reader is familiar with the 113 terms and concepts found in Certificate Management over CMS (CMC) 114 [RFC5272], Certificate Request Message Format (CRMF) [RFC4211], etc. 115 Unlike [RFC5273], EST uses both HTTPS GET and POST to support its 116 functions. 118 The aspects profiled from HTTPS (HTTP over TLS) and CMC are 119 summarized in Figure 1: 121 Profiled Layers: 123 Protocol: 124 +---------------------------------------------------+ 125 | | 126 | 3) Message types | 127 | CMC "Simple PKI" messages | 128 | Base64-encoded certificate chain | 129 | Optionally "Full" CMC messages | 130 | | 131 +---------------------------------------------------+ 132 | | 133 | 2) HTTP headers and URIs for control | 134 | URIs used to specify the PKI operation | 135 | (including renew/rekey). | 136 | Content-Type headers specify the message type. | 137 | Headers profiled for control/error messages. | 138 | Username/password methods supported for | 139 | client proof-of-identity. | 140 | | 141 | | 142 +- ----(combination is known as HTTPS)--+ 143 | | 144 | | 145 | 1) TLS for transport security | 146 | Provides proof-of-identity for | 147 | EST Server authentication and | 148 | EST Client authentication. | 149 | "Channel binding" type techniques used to | 150 | during Proof-of-Possession. | 151 | | 152 +---------------------------------------------------+ 153 | | 154 | TCP/IP layer etc included in diagram for context | 155 | | 156 +---------------------------------------------------+ 158 Figure 1 160 Base64 [RFC4648] is used as specified in Section 4 of that RFC. 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 Certification Authority (CA) (from which the client is 179 requesting a certificate) or they may have been issued under a 180 distinct PKI (e.g., an IEEE 802.1AR IDevID [IDevID] credential). 181 Additionally this document specifies username/password 182 authentication methods beyond those included in CMC. 183 Authentication and authorization mechanisms required for 184 certificate issuance (and renew/rekey) are provided by HTTP and 185 HTTPS mechanisms as described in this document. 187 Proof-of-possession is a distinct issue from proof-of-identity and 188 is addressed in Section 3.6. 190 This document also defines transport for the full CMC 191 specification compliant with CMC Transport Protocols. 193 2) HTTP Headers and URIs for control: 195 This profile supports two operations indicated by specific URIs: 197 * Distribution of CA certificates 199 * Authorized enrollment and re-enrollment of clients 201 This document profiles the HTTP content-type header to indicate 202 the message type and to provide the protocol control messages. 203 Support for the HTTP username/password methods is profiled. 205 CMC does not provide explicit messages for renewal and rekey. 206 This profile clarifies the renewal and rekey behavior of both the 207 client and server. It does so by specifying the HTTP control 208 mechanisms required of the client and server without requiring a 209 distinct message type. 211 Various media types as indicated in the HTTP content-type header 212 are used to transport EST messages. For simple certificate 213 enrollment and re-enrollment requests, application/pkcs10 (defined 214 in [RFC5967]) is used as specified in Section 5.2. Certificate 215 responses to enrollment and re-enrollment requests are carried as 216 application/pkix-cert (defined in [RFC2585]) as specified in 217 Section 5.2.2. FullCMC requests and responses are both 218 transported as application/pkcs7-mime (as given in [RFC5273]. 219 Requests for CA certificates generate a response with the media 220 type multipart/parallel. Within each parallel part is an entity 221 of media type application/pkix-cert. See Section 5.1. 223 3) Message Types: 225 Some message types used here are defined in CMC and include 226 subsets of the PKCS#10 Certification Request [RFC2986] and the 227 PKCS#7 [RFC2315] message specifications. 229 This document profiles the use of two Certificate Management over 230 CMS messages: "Simple PKI Request" and "Simple PKI Response" and 231 does not require full implementation of all CMC features. This is 232 consistent with the CMC protocol specification of "simple" 233 messages for clients to use "in the event no other services are 234 needed". To support distribution of the CA certificate chain a 235 simple Base 64 format is specified. Full CMC messages MAY also be 236 used. 238 HTTP Content-Type headers are as specified in [RFC5273], Table 1. 239 This document reuses media types for the simple format messages as 240 specified by Internet X.509 Public Key Infrastructure Operational 241 Protocols: FTP and HTTP [RFC2585] and The application/pkcs10 Media 242 Type [RFC5967]. See the next section for details. 244 An EST server providing certificate management functions is operated 245 by (or on behalf of) a CA or RA. 247 An EST server MAY provide additional, non-EST services on other URIs. 248 The server also MAY support full CMC messages over HTTPS. 250 [[EDNOTE: Comments such as this one, included within double brackets 251 and initiated with an 'EDNOTE', are for editorial use and shall be 252 removed as the document is polished.]] 254 1.1. Requirements Language 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 258 document are to be interpreted as described in [RFC2119]. 260 2. Requirements 262 [[EDNOTE: The following section is still included here for 263 succinctness. It will eventually be published independently as 264 draft-ietf-pkix-estr-00.]] 266 The following describes goals and technical requirements for initial 267 PKI certificate enrollment along with a rationale for each 268 requirement. 270 G1 "Completeness". Server and client implementations compliant with 271 this document MUST be able to interoperate without reference to 272 subsequent profiles or additional future specifications. 274 The goal of this enrollment protocol is to provide a simple and easy- 275 to-implement method for end-entities to request, obtain, and update a 276 certificate issued from a specified Certification Authority. The 277 following certificate management operations are required. Additional 278 operations NEED NOT be supported (via this protocol) although the 279 protocol design SHOULD be extensible: 281 M1 "Distribution of current CA certificates". Clients MUST be able 282 to obtain the current certificate for the CA under which the 283 client's certificate was issued. Certificates have a finite 284 lifetime and will need to be updated on a periodic basis. It must 285 be possible for the client to obtain the updated CA certificates. 287 M2 "Enrollment". A client MUST be able to use the protocol to submit 288 a certificate request and obtain a certificate. 290 M3 "Renew/Rekey". Certificates have a finite lifetime and will need 291 to be updated on a periodic basis. A client MUST be able to use 292 the protocol for certificate renewal or rekey operations. 294 End-Entity Proof of Identity authentication mechanisms: 296 A1 "Username/Password". It MUST be possible to identify a username 297 specified client as being in possession of an associated symmetric 298 key. This allows users currently in possession of a username and 299 password to obtain a certificate. 301 A2 "Password". It MUST be possible to identify a client without 302 reference to a "username". A common operational model is to 303 distribute a "one-time password" that is presented to a CA or RA 304 to authorize enrollment. 306 A3 "Existing Certificate". It MUST be possible to authenticate a 307 client by making use of an existing certificate associated with 308 the client. A certificate used for client identification need not 309 be issued under the same PKI as the certificate that is being 310 requested. This allows clients that are already in a PKI to use a 311 certificate from that PKI to obtain additional certificates. 312 Additionally this capability allows a client who has a certificate 313 issued by a 3rd party, such as a certificate issued by a device 314 manufacturer, to leverage that credential during initial 315 enrollment. 317 A4 "Username/password and Certificate". It MUST be possible to 318 authenticate a client by using a combination of a username and 319 password and an existing certificate. This is a combination of A1 320 and A3. This supports "two-factor authentication" where the 321 client proves possession of the private keys for an existing 322 certificate stored within a hardware device and knowledge of a 323 username/password. 325 A5 "Password and certificate". It MUST be possible to authenticate a 326 client by using a combination of a secret value that is not 327 associated with a "username" and an existing certificate. This is 328 a combination of A2 and A3. This requirement is similar to A4 329 except that the client is in possession of a "one-time password". 331 End-Entity Proof of Possession: 333 P1 Proof-of-Possession of subject keys MUST be supported. As 334 discussed in Appendix C of [RFC4211], Proof-of-Possession "means 335 that the CA is adequately convinced that the entity requesting a 336 certificate for the public key Y, has access to the corresponding 337 private key X". 339 Key algorithms: 341 K1 "Algorithm agility". The protocol MUST support algorithm agility. 342 It must be possible to employ different cryptographic algorithms 343 for securing the transport or for signing the certificates. The 344 protocol SHOULD demonstrate this agility by being shown to work 345 with existing RSA-based solutions as well as providing for other 346 algorithms such as Elliptic Curve cryptography. 348 Server Identity mechanism: 350 I1 "RA certificate". It MUST be possible for a client to verify 351 authorization of the EST server as a representative of the CA. 352 The protocol operations allow the client to send a username/ 353 password or (one-time) password to the EST server. These values 354 cannot be safely transmitted to an unauthorized server. 356 3. Secure Transport 358 HTTPS MUST be used. TLS 'session resumption' SHOULD be supported. 360 HTTPS is defined in HTTP Over TLS [RFC2818] and is a definition of 361 how HTTP messages are carried over TLS. HTTPS is a commonly used 362 secure transport and can be easily layered on top of extremely simple 363 client or server code. In some environments HTTPS can be utilized 364 through an external process. Specifying HTTPS as the secured 365 transport for PKI enrollment messages introduces two potential 366 'layers' for communication of authorization data or for status/ 367 informative responses during the protocol exchange: TLS and HTTPS. 368 This profile specifies when information is used from each layer. 370 3.1. TLS-Based Server Authentication 372 The client MUST validate the TLS server certificate presented during 373 the TLS [RFC5246] exchange-defined Server Certificate message or the 374 client MUST independently validate the response contents. Validation 375 is performed as given in [RFC5280] and [RFC6125]. The cipher suites 376 are detailed in Section 6. 378 There are multiple methods of validation depending on the current 379 state of the client: 381 1. If the client has a store of trust anchors, which may be in the 382 form of certificates, for validating TLS connections the client 383 MAY validate the TLS server certificate using the standard HTTPS 384 logic of checking the server's identity as presented in the 385 server's Certificate message against the URI provisioned for the 386 EST server (see HTTP Over TLS, Section 3.1 Server Identity and 387 [RFC6125]). This method makes it possible for clients with a 388 store of trust anchors, possibly in the the form of certificates, 389 to securely obtain the CA certificate by leveraging the HTTPS 390 security model. The EST server URI MUST be made available to the 391 client in a secure fashion so that the client only obtains EST 392 functions from a desired server. 394 2. If the client already has one or more trust anchors associated 395 with this EST server, the client MUST validate the EST server 396 certificate using these trust anchors. The EST server URI MAY be 397 made available to the client in an insecure fashion. The EST 398 server certificate MUST contain the id-kp-cmcRA [CMC RFC5272bis] 399 extended key usage extension. 401 3. If the client does not yet have a trust anchor associated with 402 this EST server then the client MAY provisionally accept the TLS 403 connection, but the HTTP content data MUST be accepted manually 404 as described in Section 5.1. HTTP authentication requests MUST 405 NOT be responded to. 407 Methods 1 and 2 are essentially validation as given in [RFC5280] with 408 the addition of authorization. Method 1 is as described in [RFC6125] 409 Section 6.6.1 "Match Found". Method 2 is described in [RFC6125] as 410 "No Match Found, Pinned Certificate". Method 3 is described in 411 [RFC6125] as "Fallback" and describes the process of "pinning" the 412 recieved certificate. 414 If one of these validation methods succeeds the CA certificates are 415 stored and made available for future use. If none of these 416 validation methods succeeds the client MUST reject the EST server 417 response and SHOULD log and/or inform the end user. 419 The EST server MUST present an end-entity certificate such as a CMC 420 Registration Authority (RA) certificate. 422 3.2. Server Authentication and Authorization 424 The client MUST check the EST server authorization before accepting 425 the server's response. 427 If the client has a securely configured and authorized URI for the 428 EST server it MUST check the URI "against the server's identity as 429 presented in the server's Certificate message" (Section 3.1 Server 430 Identity [RFC2818] and [RFC6125]). The securely configured URI 431 provides the authorization statement and the server's authenticated 432 identity confirms it is the authorized server. 434 If this check fails, or if the URI was configured using an insecure 435 method, then the client MUST verify the server's authorization by 436 checking that the [RFC5280] defined certificate policy extension 437 sequence contains the 'RA Authorization' policy OID. 439 The RA Authorization policy OID is defined as: id-cmc [[EDNOTE: TBD, 440 perhaps 35]]. The RA Authorization policy information MUST NOT 441 contain any optional qualifiers. 443 3.3. TLS-Based Client Authentication 445 Clients MUST support client-side certificate authentication 446 [RFC5246]. To authenticate the client, the server sends the 447 certificate request message to the client, the client returns a 448 client certificate and a certificate verify message to the server, 449 and the server verifies the certificate verify message with the 450 certificate in the client certificate message. As required by 451 [RFC5246], the client certificate needs to indicate support for 452 digital signatures. 454 The certificate presented by the client MAY be from the same PKI as 455 the Server Certificate, from a completely different PKI, or as a last 456 resort the client MAY respond with a self-signed certificate. The 457 certificate supplied during authentication is used during client 458 authorization (Section 3.5). 460 3.4. HTTP-Based Client Authentication 462 As specified in CMC: Transport Protocols [RFC5273] the server "MUST 463 NOT assume client support for any type of HTTP authentication such as 464 cookies, Basic authentication, or Digest authentication". Clients 465 intended for deployments where password authentication is 466 advantageous SHOULD support the Basic and Digest authentication 467 mechanism. Servers MAY provide configuration mechanisms for 468 administrators to enable Basic [RFC2616] and Digest [RFC2617] 469 authentication methods. Basic and Digest authentication MUST be 470 performed over TLS [RFC5246]. 472 Servers that support Basic and Digest authentication methods MAY 473 reject requests using the HTTP defined WWW-Authenticate response- 474 header (Section 14.47). At that point the client SHOULD repeat the 475 request, including the appropriate HTTP [RFC2617] Authorization 476 Request Header (Section 3.2.2). 478 Support for Basic authentication as specified in HTTP allows the 479 server access to the client's cleartext password. This provides 480 integration with legacy username/password databases but requires 481 exposing the plaintext password to the EST server. The client MUST 482 NOT respond to this request unless the client has authenticated the 483 EST server (as per Section 3.2). 485 Clients MAY set the username to the empty string ("") if they wish to 486 present a "one-time password" or "PIN" that is not associated with a 487 username. 489 3.5. Client Authorization 491 When the EST server receives a CMC Simple PKI Request or rekey/renew 492 message, the decision to issue a certificates is always a matter of 493 local policy. Thus the CA can use any data it wishes in making that 494 determination. The EST protocol exchange provides the EST server 495 access to the TLS client certificate in addition to any HTTP user 496 authentication credentials to help in that determination. The 497 communication channel between the TLS server implementation and the 498 EST software implementation is out-of-scope of this document. 500 3.6. Proof-of-Possession 502 As discussed in Appendix C of CRMF [RFC4211], Proof-of-Possession 503 "means that the CA is adequately convinced that the entity requesting 504 a certificate for the public key Y, has access to the corresponding 505 private key X". 507 The signed enrollment request provides a "Signature"-based proof-of- 508 posession. The mechanism described in Section 3.7 strengthens this 509 by optionally including identity linking information within the data 510 covered by the enrollment request signature (thus ensuring that the 511 enrollment request was signed after the TLS tunnel was established). 513 3.7. Linking Identity and POP information 515 This specification provides a method of linking identity and proof- 516 of-possession by including information specific to the current 517 authenticated TLS session within the signed certification request. 518 This proves to the server that the authenticated TLS client has 519 possession of the private key associated with the certification 520 request and that the client was able to sign the certification 521 request after the TLS session was established. This is an 522 alternative to the [RFC5272] Section 6.3-defined "Linking Identity 523 and POP information" method available if fullCMC messages are used. 525 The client generating the request SHOULD obtain the tls-unique value 526 as defined in Channel Bindings for TLS [RFC5929] from the TLS 527 subsystem, encode it using base64 encoding, and place the resulting 528 string in the certification request challenge password field. 530 The tls-unique specification includes a synchronization issue as 531 described in Channel Bindings for TLS [RFC5929] section 3.1. This 532 problem is avoided for EST implementations. The tls-unique value 533 used MUST be from the first TLS handshake. EST client and servers 534 must use their tls-unique implementation specific synchronization 535 methods to obtain this first tls-unique value. 537 Any TLS renegotiation MUST use "secure_renegotiation" [RFC5746] (thus 538 maintaining the binding). Mandating secure renegotiation secures 539 this method of avoiding the synchronization issues encountered when 540 using the most recent tls-unique value (which is defined as the the 541 value from the most recent TLS handshake). 543 The server SHOULD verify the tls-unique information. This ensures 544 that the authenticated TLS client is in possession of the private key 545 used to sign the certification request. 547 The tls-unique value is encoded into the certification request by the 548 client but back-end infrastructure elements that process the request 549 after the EST server might not have access to the initial TLS 550 session. Such infrastructure elements validate the source of the 551 certification request to determine if POP checks have already been 552 performed. For example if the EST client authentication results in 553 an authenticated client identity of an RA that is known to 554 independently verify the proof-of-possession then the back-end 555 infrastructure does not need to perform proof-of-possession checks a 556 second time. If the EST server forwards a request to a back-end 557 process it SHOULD communicate the authentication results. This 558 communication might use the CMC "RA POP Witness Control" in a CMC 559 Full PKI Request message or other mechanisms which are out-of-scope 560 of this document. 562 4. HTTP URIs 564 EST uses the HTTPS "GET" and "POST" messages to communicate with the 565 EST server. The following describes the syntax of these messages: 566 "GET" BASEPATH OPERATIONPATH 567 "POST" BASEPATH OPERATIONPATH 569 where: 571 o BASEPATH is a common path for all EST operations 573 o OPERATIONPATH specifies the specific operation. 575 When a URI is formed, the BASEPATH and OPERATIONPATH are combined to 576 form the abs_path [RFC2616]. The means by which clients acquire the 577 BASEPATH URI are outside the scope of this document. The following 578 are two example base URIs: 580 o With BASEPATH having the value of /arbitrary/base/path 582 o https://example.org/arbitrary/base/path 583 o https://example2.org:8080/arbitrary/base/path 585 These can be conveniently distributed as they are in a form with 586 which many end users are already familiar. The following operation 587 paths for clients to access are defined relative to the EST base URL: 589 o /CACerts - The server responds to an HTTPS GET with the CA 590 certificates as defined in Distribution of CA certificates 591 (Section 5.1). 593 o /simpleEnroll - The client sends a CMC Simple PKI Request message 594 as specified in Enrollment of Clients (Section 5.2), the response 595 is a CMC Simple PKI Response message as specified in Enroll 596 Response (Section 5.2.2). 598 o /simpleReEnroll - Exactly the same as 'simpleEnroll' except that 599 the request is for re-enrollment or re-issuance purposes. Only 600 certificates that are suitable for TLS client authentication can 601 be re-enrolled using this operation because of the reliance on the 602 TLS authentication. For other types of certificates, use of the 603 fullCMC operation is required. 605 o /fullCMC - Provides for Full CMC messages (OPTIONAL). 607 The following examples are valid complete URIs under this 608 specification: 610 o With BASEPATH having the value /base/path 612 o https://example.org/base/path/CACerts 614 o https://example2.org:8080/base/path/simpleEnroll 616 o https://example3.org/base/path/fullCMC 618 The mechanisms by which the EST server interacts with an HTTPS server 619 to handle GET and POST operations at these URIs is outside the scope 620 of this document. The use of distinct URIs simplifies implementation 621 for servers that do not perform client authentication when 622 distributing "CACerts" responses. 624 Implementation note: A simple Common Gateway Interface (CGI) 625 application at each fully specified path, with the HTTPS server 626 configured to provide Section 3.3, is sufficient for a working 627 example (the web service can forward the Section 3.6 proof-of- 628 possession information to the application using the CGI interface). 629 Additional dicussion regarding the use of CGI can be found in 630 Appendix C. 632 [[EDNOTE: This does not use the mechanism specified in "Defining 633 Well-Known Uniform Resource Identifiers (URIs)" [RFC5785]. That 634 would be a possibility here for a base URL of 635 "https://example.org/.well-known/EST" but such would preclude the 636 flexibility associated with multiple base URLs being handled by the 637 same server unless some form of "?designator=value" is included.]] 639 5. Messages 641 5.1. Distribution of CA certificates 643 Before engaging in enrollment operations, clients MUST request trust 644 anchor information (in the form of certificates) by sending an HTTPS 645 GET message to the EST base URI with the relative path extension 646 '/CACerts'. Clients SHOULD request an up-to-date response before 647 stored information has expired. 649 The EST server SHOULD NOT require client authentication or 650 authorization to reply to this request. 652 The client MUST authenticate the EST server as specified in 653 Authentication and Authorization (Section 3). If the authentication 654 and authorization is successful, the client accepts the response and 655 stores it. If the authentication and authorization is not 656 successful, then when the response is received the client MUST 657 extract the CA certificate and engage the end-user or otherwise 658 authorize the credential using out-of-band pre-configuration data 659 such as a CA certificate "fingerprint" (e.g., a SHA-1, SHA-256, SHA- 660 512, or MD5 hash on the whole CA certificate). 662 The client MUST NOT accept the CA certificate without validating it 663 via one of the mechanisms described in Section 3.1. 665 Subsequent connections to the EST server validate the TLS server 666 certificate using the stored CA certificates as described in 667 Authentication and Authorization (Section 3). 669 5.1.1. Distribution of CA certificates response 671 The EST server MUST respond to the client HTTPS GET message with CA 672 trust anchor information in the form of a certificate. Additionally 673 the server MUST include any "Root CA Key Update" CMP certificates. 675 The response format is the media type multipart/parallel. Within 676 each parallel part is an entity of media type application/pkix-cert. 677 One part MUST be the the current self-signed CA certificate. 678 Additional parts MAY be included. If additional parts are included 679 they MUST be the three additional CMP-defined Root CA Key Update 680 certificates: OldWithOld, OldWithNew, and NewWithOld. 682 The client can always find the current self-signed CA certificate by 683 examining the certificates received. The NewWithNew certificate is 684 self-signed and has the latest NotAfter date. 686 The NewWithNew certificate is the certificate that is extracted and 687 authorized using out-of-band information as described in Section 5.1. 688 When out-of-band validation occurs each of the other three 689 certificates MUST be validated using normal [RFC5280] certificate 690 path validation (using the NewWithNew certificate as the trust 691 anchor) before they can be used to build certificate paths during 692 peer certificate validation. 694 5.2. Simple Enrollment of Clients 696 At any time the client MAY request a certificate from the EST base 697 URI with the OPERATIONPATH "/simpleEnroll'. 699 When HTTPS POSTing to the 'SimpleEnroll' location the client MUST 700 include a CMC Simple PKI Request as specified in CMC Section 3.1 701 (i.e., a PKCS#10 Certification Request). 703 The content-type of "application/pkcs10" MUST be specified. The 704 format of the request is as specified in Section 6.4 of [RFC4945]. 706 The server MUST authenticate the client as specified in 707 Authentication and Authorization (Section 3). The server applies 708 whatever authorization or policy logic it chooses determining if the 709 certificate should be issued. The client MAY request an additional 710 certificate even when using an existing certificate in the TLS client 711 authentication. 713 The client MUST authenticate the EST server as specified in 714 Section 3.1. 716 5.2.1. Simple Re-Enrollment of Clients 718 At any time a client MAY request renew/rekey of its certificate from 719 the EST base URI with the OPERATIONPATH "/simpleReEnroll'. The 720 certificate request is the same format as for the "simpleEnroll" path 721 extension with the same content-type. 723 The EST server MUST handle enrollment requests submitted to the 724 "simpleReEnroll" URI as renewal or rekey requests rather than 725 depending only on the method of identifying a renewal or rekey 726 request specified in Section 2 of [RFC5272], that "renewal and rekey 727 requests look the same as any certification request, except that the 728 identity proof is supplied by existing certificates from a trusted 729 CA". The proof of client identity is supplied by client 730 authentication during the HTTPS handshake. When attempting to renew 731 or rekey the client MUST use its existing certificate for TLS client 732 authentication. 734 [[EDNOTE: draft-turner-suiteb-cmc defines a method of recognizing a 735 re-enroll based on PKCS10 contents, see section 4.1. The method 736 described herein is explicit.]] 738 5.2.2. Simple Enroll and Re-Enroll Response 740 The server responds to a 'simpleEnroll' or 'simpleReEnroll' request 741 with the client's newly issued certificate or it provides an error 742 response. 744 If the enrollment is successful the server response MUST have a 745 response code of 200 with a content-type of "application/pkix-cert". 746 The response data is the certificate formatted as specified in 747 Section 6.1 of [RFC4945]. 749 When rejecting a request the server MUST specify either an HTTP 4xx/ 750 401 error, or an HTTP 5xx error. A CMC Simple PKI Response with an 751 HTTP content-type of "application/pkcs7-mime" MAY be included in the 752 response data for any error response. If the content-type is not set 753 the response data MUST be a plain text human-readable error message. 754 A client MAY elect not to parse a CMC error response in favor of a 755 generic error message. 757 If the server responds with an HTTP 202 this indicates that the 758 request has been accepted for processing but that a response is not 759 yet available. The server MUST include a Retry-After header as 760 defined for 503 responses and MAY include informative human-readable 761 content. The client MUST wait at least the specified 'retry-after' 762 time before repeating the same request. The client repeats the 763 initial enrollment request after the appropriate 'retry-after' 764 interval has expired. The client SHOULD log or inform the end user 765 of this event. The server is responsible for maintaining all state 766 necessary to recognize and handle retry operations as the client is 767 stateless in this regard (it simply sends the same request repeatedly 768 until it receives a different response code). 770 All other return codes are handled as specified in HTTP. 772 5.3. Full CMC 774 At any time the client MAY request a certificate from the EST base 775 URI with the OPERATIONPATH "/fullCMC". 777 The client MUST authenticate the server as specified in Server 778 Authentication (Section 3.1). 780 The server SHOULD authenticate the client as specified in 781 Authentication and Authorization (Section 3). The server MAY depend 782 on CMC client authentication methods instead. 784 5.3.1. Full CMC Request 786 When HTTPS POSTing to the "fullCMC" location the client MUST include 787 a valid CMC message. The content-type MUST be set to "application/ 788 pkcs7-mime" as specified in [RFC5273]. 790 5.3.2. Full CMC Response 792 The server responds with the client's newly issued certificate or 793 provides an error response. 795 If the enrollment is successful the server response MUST have a 796 response code of 200 with a content-type of "application/pkcs7-mime" 797 as specified in [RFC5273]. The response data includes either the CMC 798 Simple PKI Response or the CMC Full PKI Response. 800 When rejecting a request the server MAY specify either an HTTP 4xx/ 801 401 error, an HTTP 5xx error, or a response code 200. A CMC response 802 with content-type of "application/pkcs7-mime" MUST be included in the 803 response data for any error response. The client MUST parse the CMC 804 response to determine the current status. 806 All other return codes are handled as specified in Section 5.2.2 or 807 HTTP [RFC2616]. 809 6. Cryptographic Algorithms 811 This section details the specific cryptographic algorithms and cipher 812 suite requirements. 814 The client SHOULD offer the Suite B compliant cipher suites as 815 indicated in [RFC5430], Section 4 "Suite B Compliance and 816 Interoperability Requirements". For greatest interoperability the 817 client SHOULD also offer TLS_RSA_WITH_AES_128_CBC_SHA. 819 When the client accesses the "simpleReEnroll" method the TLS cipher 820 suite in use MUST be appropriate for the existing certificate. The 821 certificate type used determines the appropriate signatureAlgorithm 822 for the PKCS#10 Certification Request. For example if a [RFC5430] 823 cipher suite is used the signatureAlgorithm MAY be ecdsa-with-sha256 824 for P-256 certification requests, or MAY be ecdsa-with-sha384 for 825 P-384 certification requests. 827 [[EDNOTE: This is in alignment with draft-turner-suitb-cmc-03 section 828 4.1. To encourage algorithm agility, discussions of the MUST/SHOULD 829 algorithms should be in a distinct document.]] 831 7. Contributors/Acknowledgements 833 The editors would like to thank Stephen Kent, Vinod Arjun, Jan 834 Vilhuber, Sean Turner, and others for their feedback and prototypes 835 of early drafts. 837 8. IANA Considerations 839 (This section is incomplete) 841 The following aspects should be registered with IANA Considerations: 843 The RA Authorization certificate policy extension OID as discussed in 844 Section 3.2 requires registration with IANA. 846 [[EDNOTE: The URLs specified in Section 1 probably do not need to be 847 registered with IANA.]] 849 9. Security Considerations 851 (This section is incomplete) 853 "Badges? We ain't got no badges. We don't need no badges! I don't 854 have to show you any stinkin' badges!" -- The Treasure of the Sierra 855 Madre. 857 As described in CMC Section 6.7, "For keys that can be used as 858 signature keys, signing the certification request with the private 859 key serves as a POP on that key pair". The inclusion of tls-unique 860 within the certification request provides timeliness to the proof-of- 861 possession. For support of keys that can not be used for signing the 862 certification request the full CMC specification MUST be used. 864 As described in Section 3.3 clients use an existing certificate for 865 TLS client authentication. If a certificate with appropriate key 866 usage is not available the client MAY generate one. If a self-signed 867 certificate with appropriate key usage is used the server SHOULD 868 require HTTP-based client authentication according to server policy 869 as described in Section 3.3 and Section 3.5. The server MAY fall 870 back on manual authorization by the server administrator. 872 As described in Section 3.1 servers use an existing certificate for 873 TLS server authentication. When the server certificate is issued by 874 a mutually trusted PKI hierarchy validation proceeds as specified in 875 Section 3.2. In this situation the client has validated the server 876 as being a valid responder for the URI configured but can not 877 directly verify that the responder is authorized as an RA within the 878 to-be-enrolled PKI hierarchy. A client may thus be enticed to expose 879 username/password or certificate enrollment requests to an 880 unauthorized server (if the server presents a valid HTTPS certificate 881 for an erroneous URL that the client has been tricked into using). 882 Proof-of-Identity and Proof-of-Possession checks by the CA prevent an 883 illegitimate RA from leveraging such misconfigured clients to act as 884 a man-in-the-middle during client authenticated operations but it is 885 possible for such illegitimate RAs to send the client doctored 886 messages or erroneous CA certificate lists. If the illegitimate RA 887 has successfully phished a username/password or PIN from the client 888 it might try to use these values to enroll its own keypair with the 889 real PKI hierarchy. EST servers identified with an externally issued 890 server certificate SHOULD require HTTPS-based client authentication 891 (Section 3.3). Similarly EST clients SHOULD use an existing client 892 certificate to identify themselves and otherwise prevent "private 893 data" (obviously including passwords but also including private 894 identity information) from being exposed during the enrollment 895 exchange a weak server authorization method is used. 897 10. References 899 10.1. Normative References 901 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 902 Requirement Levels", BCP 14, RFC 2119, March 1997. 904 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 905 Version 1.5", RFC 2315, March 1998. 907 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 908 Infrastructure Operational Protocols: FTP and HTTP", 909 RFC 2585, May 1999. 911 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 912 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 913 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 915 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 916 Leach, P., Luotonen, A., and L. Stewart, "HTTP 917 Authentication: Basic and Digest Access Authentication", 918 RFC 2617, June 1999. 920 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 922 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 923 Request Syntax Specification Version 1.7", RFC 2986, 924 November 2000. 926 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 927 "Internet X.509 Public Key Infrastructure Certificate 928 Management Protocol (CMP)", RFC 4210, September 2005. 930 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 931 Encodings", RFC 4648, October 2006. 933 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 934 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 936 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 937 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 939 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 940 (CMC)", RFC 5272, June 2008. 942 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 943 (CMC): Transport Protocols", RFC 5273, June 2008. 945 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 946 Housley, R., and W. Polk, "Internet X.509 Public Key 947 Infrastructure Certificate and Certificate Revocation List 948 (CRL) Profile", RFC 5280, May 2008. 950 [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile 951 for Transport Layer Security (TLS)", RFC 5430, March 2009. 953 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 954 "Transport Layer Security (TLS) Renegotiation Indication 955 Extension", RFC 5746, February 2010. 957 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 958 for TLS", RFC 5929, July 2010. 960 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 961 August 2010. 963 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 964 Verification of Domain-Based Application Service Identity 965 within Internet Public Key Infrastructure Using X.509 966 (PKIX) Certificates in the Context of Transport Layer 967 Security (TLS)", RFC 6125, March 2011. 969 10.2. Informative References 971 [IDevID] IEEE Std, "IEEE 802.1AR Secure Device Identifier", 972 December 2009, . 975 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 976 Certificate Request Message Format (CRMF)", RFC 4211, 977 September 2005. 979 Appendix A. Server Discovery 981 (informative) 983 (This section is incomplete) 985 Clients MAY use DNS-SD or similar discovery algorithms to determine 986 the EST base URL. In such cases it is expected that method 2 987 (Section 3.1) be used during server authentication. 989 Appendix B. External TLS concentrator 991 (informative) 993 In some deployments it may be beneficial to use a TLS concentrator to 994 offload the TLS processing from the server. In such a deployment the 995 TLS client authentication result must, in some way, be forwarded to 996 the server. 998 The TLS server SHOULD NOT reject the connection based on PKIX 999 validation of the client certificate. The client certificate SHOULD 1000 be passed to the EST layer for verification and authorization. This 1001 allows support of external TLS concentrators, or an external web 1002 server, that might provide an independent TLS implementation. 1004 The TLS concentrator MUST validate the TLS Section 7.4.8 'Certificate 1005 Verify'. 1007 A TLS concentrator MUST insert the client certificate into the HTTP 1008 header. The TLS concentrator MUST first remove any existing client 1009 certificates, possibly inserted by a nefarious client, from the HTTP 1010 headers before forwarding the HTTP connection to the server. 1012 [TBD - need to better understand what would happen in the case of 1013 proxy's or multiple concentrators. Or specifically state that as out 1014 of scope.] 1016 [TBD - the HTTP header field names etc shall be specified here] 1018 The EST server MUST be specifically configured by the administrator 1019 to accept this mechanism. 1021 Appendix C. CGI Server implementation 1023 (informative) 1025 In some deployments it may be beneficial to use a HTTPS server that 1026 runs the EST server as a CGI application. In such a deployment the 1027 HTTPS server client authentication result must, in some way, be 1028 forwarded to the server. 1030 An HTTPS server MUST insert the client certificate into environment 1031 variables before calling a server CGI application. 1033 [TBD - describe the CGI environment variables here. Can likely 1034 follow the apache example]. 1036 An HTTP server MUST insert the client certificate into environment 1037 variables before calling a server CGI application. 1039 [TBD - describe the CGI environment variables here. Can likely 1040 follow the apache example]. 1042 Appendix D. Updating SCEP implementations 1044 (informative) 1046 SCEP has been used instead of a full implementation of CMC for the 1047 same simplicity reasons discussed in Section 1. Such implementations 1048 would benefit from being updated to this specification in the 1049 following ways: 1051 o Implementing a subset of CMC provides an enhancement path if the 1052 full CMC functionality is required. 1054 o The use of HTTPS as a transport is often perceived as more secure. 1055 Although the SCEP protocol specification includes mechanisms (and 1056 complexity) to address security issues avoiding a vendor 1057 requirement to educate systems administrators is beneficial. 1058 Implementors can benefit from the wide availability of existing 1059 HTTPS/TLS libraries. 1061 o SCEP servers can use their CA certificate to protect SCEP traffic 1062 in ways that are not appropriate. (See SCEP draft Section 8.2). 1063 This specification precludes those misuses. 1065 o The SCEP draft Appendix D renew and rekey functionalities imply a 1066 'flag moment' where the PKI infrastructure transitions from an 1067 (expired) CA certificate to a new CA certificate. This 1068 specification specifies the better mechanism defined in CMP. 1070 Updating an SCEP client implementation to support this protocol 1071 involves the following changes to the SCEP implementation. There is 1072 no server-side indication that SCEP clients should be so modified so 1073 this depends on a client-side configuration: 1075 o The SCEP client supports HTTPS server authentication and 1076 authorization as detailed Section 3.1. 1078 o The SCEP client supports HTTPS client authentication as detailed 1079 in Section 3.3. 1081 o When performing the "Get CA Cert" SCEP transaction the client 1082 supports the Section 5.1 described CMC Simple PKI Response (ref 1083 CMC 4.1, which is extremely similar to the SCEP "CA/RA Certificate 1084 Response Message Format" if not exactly the same). 1086 o When performing the certificate enrollment via SCEP PKCSReq the 1087 outgoing message is simplified to be only the inner PKCS10 (ref 1088 CMC section 3.2.1.2.1). 1090 o When handling the certificate enrollment response the response 1091 format is simplified to be only the SCEP inner 'messageData' 1092 containing the actual certificates in the degenerate PKCS7 form. 1093 (ref CMC 4.1) The only 'authenticatedAttributes' value of 1094 remaining importance is the 'pkiStatus' and this value is now 1095 found in the HTTP header as defined in Section 5.2.2. 1097 o Polling is simplified with clients repeatedly establishing the 1098 full HTTPS connection; no polling specific state information is 1099 encoded into the EST messages. 1101 o GetCert is deprecated. 1103 o GetCRL is deprecated. 1105 These simplifications to an existing SCEP implementation result in an 1106 SCEP client that is compliant with CMC when using the EST transport. 1108 Implementation note: The use of tls-unique-securerenegotiation 1109 precludes the use of SCEP 'challenge-password' within the pkcs10 for 1110 password/PIN assertion. Instead these values must be asserted with 1111 the Section 3.4 described mechanism. A side effect of this is that a 1112 client communicating with an EST server can not embed an SCEP 1113 'challenge-password' within the PKCS#10. An EST service running as 1114 an RA thus can not forward the PKCS#10 using SCEP to an SCEP server 1115 that expects the 'challenge-password' to be populated. 1117 Authors' Addresses 1119 Max Pritikin (editor) 1120 Cisco Systems, Inc. 1121 510 McCarthy Drive 1122 Milpitas, CA 95035 1123 USA 1125 Email: pritikin@cisco.com 1127 Peter E. Yee (editor) 1128 AKAYLA, Inc. 1129 7150 Moorland Drive 1130 Clarksville, MD 21029 1131 USA 1133 Email: peter@akayla.com