idnits 2.17.1 draft-gutmann-scep-15.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 4, 2020) is 1536 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'CERT-NONEXISTENT' on line 384 -- Looks like a reference, but probably isn't: 'CERT-REQ-PENDING' on line 384 -- Looks like a reference, but probably isn't: 'CERT-ISSUED' on line 384 ** Obsolete normative reference: RFC 7230 (ref. '11') (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. '20') (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Gutmann 3 Internet-Draft University of Auckland 4 Intended status: Informational February 4, 2020 5 Expires: August 7, 2020 7 Simple Certificate Enrolment Protocol 8 draft-gutmann-scep-15 10 Abstract 12 This document specifies the Simple Certificate Enrolment Protocol 13 (SCEP), a PKI protocol that leverages existing technology by using 14 CMS (formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the 15 evolution of the enrolment protocol sponsored by Cisco Systems, which 16 enjoys wide support in both client and server implementations, as 17 well as being relied upon by numerous other industry standards that 18 work with certificates. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 7, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 68 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1.1. Client . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1.2. Certificate Authority . . . . . . . . . . . . . . . . 5 72 2.2. CA Certificate Distribution . . . . . . . . . . . . . . . 5 73 2.3. Client authentication . . . . . . . . . . . . . . . . . . 6 74 2.4. Enrolment authorisation . . . . . . . . . . . . . . . . . 7 75 2.5. Certificate Enrolment/Renewal . . . . . . . . . . . . . . 8 76 2.5.1. Client State Transitions . . . . . . . . . . . . . . 8 77 2.6. Certificate Access . . . . . . . . . . . . . . . . . . . 10 78 2.7. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 11 79 2.8. Certificate Revocation . . . . . . . . . . . . . . . . . 11 80 2.9. Mandatory-to-Implement Functionality . . . . . . . . . . 11 81 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 12 82 3.1. SCEP Message Object Processing . . . . . . . . . . . . . 14 83 3.2. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 14 84 3.2.1. Signed Transaction Attributes . . . . . . . . . . . . 14 85 3.2.1.1. transactionID . . . . . . . . . . . . . . . . . . 16 86 3.2.1.2. messageType . . . . . . . . . . . . . . . . . . . 17 87 3.2.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 17 88 3.2.1.4. failInfo and failInfoText . . . . . . . . . . . . 17 89 3.2.1.5. senderNonce and recipientNonce . . . . . . . . . 18 90 3.2.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . 18 91 3.3. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 19 92 3.3.1. PKCSReq/RenewalReq . . . . . . . . . . . . . . . . . 19 93 3.3.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 19 94 3.3.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 20 95 3.3.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 20 96 3.3.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 20 98 3.3.3. CertPoll (GetCertInitial) . . . . . . . . . . . . . . 21 99 3.3.4. GetCert and GetCRL . . . . . . . . . . . . . . . . . 21 100 3.4. Degenerate certificates-only CMS Signed-Data . . . . . . 22 101 3.5. CA Capabilities . . . . . . . . . . . . . . . . . . . . . 22 102 3.5.1. GetCACaps HTTP Message Format . . . . . . . . . . . . 22 103 3.5.2. CA Capabilities Response Format . . . . . . . . . . . 22 104 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 25 105 4.1. HTTP POST and GET Message Formats . . . . . . . . . . . . 25 106 4.2. Get CA Certificate . . . . . . . . . . . . . . . . . . . 26 107 4.2.1. Get CA Certificate Response Message Format . . . . . 27 108 4.2.1.1. CA Certificate Response Message Format . . . . . 27 109 4.2.1.2. CA Certificate Chain Response Message Format . . 27 110 4.3. Certificate Enrolment/Renewal . . . . . . . . . . . . . . 27 111 4.3.1. Certificate Enrolment/Renewal Response Message . . . 28 112 4.4. Poll for Client Initial Certificate . . . . . . . . . . . 28 113 4.4.1. Polling Response Message Format . . . . . . . . . . . 29 114 4.5. Certificate Access . . . . . . . . . . . . . . . . . . . 29 115 4.5.1. Certificate Access Response Message Format . . . . . 29 116 4.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 29 117 4.6.1. CRL Access Response Message Format . . . . . . . . . 29 118 4.7. Get Next Certificate Authority Certificate . . . . . . . 29 119 4.7.1. Get Next CA Response Message Format . . . . . . . . . 30 120 5. SCEP Transaction Examples . . . . . . . . . . . . . . . . . . 30 121 5.1. Successful Transactions . . . . . . . . . . . . . . . . . 30 122 5.2. Transactions with Errors . . . . . . . . . . . . . . . . 31 123 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 34 124 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 125 7.1. Registration of application/x-x509-ca-cert media type . . 35 126 7.2. Registration of application/x-x509-ca-ra-cert media type 36 127 7.3. Registration of application/x-x509-next-ca-cert media 128 type . . . . . . . . . . . . . . . . . . . . . . . . . . 37 129 7.4. Registration of application/x-pki-message media type . . 38 130 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 131 8.1. General Security . . . . . . . . . . . . . . . . . . . . 39 132 8.2. Use of the CA private key . . . . . . . . . . . . . . . . 39 133 8.3. ChallengePassword Shared Secret Value . . . . . . . . . . 40 134 8.4. Lack of Certificate Issue Confirmation . . . . . . . . . 40 135 8.5. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . 41 136 8.6. Lack of PoP in Renewal Requests . . . . . . . . . . . . . 41 137 8.7. Traffic Monitoring . . . . . . . . . . . . . . . . . . . 42 138 8.8. Unnecessary cryptography . . . . . . . . . . . . . . . . 42 139 8.9. Use of SHA-1 . . . . . . . . . . . . . . . . . . . . . . 42 140 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 141 9.1. Normative References . . . . . . . . . . . . . . . . . . 43 142 9.2. Informative References . . . . . . . . . . . . . . . . . 44 143 Appendix A. Background Notes . . . . . . . . . . . . . . . . . . 45 144 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 146 1. Introduction 148 X.509 certificates serve as the basis for several standardised 149 security protocols such as TLS [23], S/MIME [20], and IKE/IPsec [19]. 150 When an X.509 certificate is issued there typically is a need for a 151 certificate management protocol to enable a PKI client to request or 152 renew a certificate from a Certificate Authority (CA). This 153 specification defines a protocol, Simple Certificate Enrolment 154 Protocol (SCEP), for certificate management and certificate and CRL 155 queries. 157 The SCEP protocol supports the following general operations: 159 o CA public key distribution. 160 o Certificate enrolment and issue. 161 o Certificate renewal. 162 o Certificate query. 163 o CRL query. 165 SCEP makes extensive use of CMS [10] and PKCS #10 [13]. 167 1.1. Conventions Used in This Document 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in [1] 172 and [5] when, and only when, they appear in all capitals, as shown 173 here. 175 This document uses the Augmented Backus-Naur Form (ABNF) notation as 176 specified in [6] for defining formal syntax of commands. Non- 177 terminals not defined in [6] are defined in Section 4.1. 179 2. SCEP Overview 181 This section provides an overview of the functionality of SCEP. 183 2.1. SCEP Entities 185 The entity types defined in SCEP are a client requesting a 186 certificate and a Certificate Authority (CA) that issues the 187 certificate. These are described in the following sections. 189 2.1.1. Client 191 A client MUST have the following information locally configured: 193 1. The CA's fully qualified domain name or IP address. 195 2. Any identification and/or authorisation information required by 196 the CA before a certificate will be issued, as described in 197 Section 3.3.1. 198 3. The identifying information that is used for authentication of 199 the CA in Section 4.2.1, typically a certificate fingerprint. 201 2.1.2. Certificate Authority 203 A SCEP CA is the entity that signs client certificates. A CA may 204 enforce policies and apply them to certificate requests, and may 205 reject a request for any reason. 207 Since the client is expected to perform signature verification and 208 optionally encryption using the CA certificate, the keyUsage 209 extension in the CA certificate MUST indicate that it is valid for 210 digitalSignature and keyEncipherment (if the key is to be used for 211 en/decryption) alongside the usual CA usages of keyCertSign and/or 212 cRLSign. 214 2.2. CA Certificate Distribution 216 If the CA certificate(s) have not previously been acquired by the 217 client through some other means, the client MUST retrieve them before 218 any PKI operation (Section 3) can be started. Since no public key 219 has yet been exchanged between the client and the CA, the messages 220 cannot be secured using CMS, and the CA certificate request and 221 response data is instead transferred in the clear. 223 If an intermediate CA is in use, a certificates-only CMS Signed-Data 224 message with a certificate chain consisting of all CA certificates is 225 returned. Otherwise the CA certificate itself is returned. 227 The CA certificate MAY be provided out-of-band to the client. 228 Alternatively, the CA certificate fingerprint MAY be used to 229 authenticate a CA Certificate distributed by the GetCACert response 230 (Section 4.2) or via HTTP certificate-store access [17]. The 231 fingerprint is created by calculating a SHA-256 hash over the whole 232 CA certificate (for legacy reasons, a SHA-1 hash may be used by some 233 implementations). 235 After the client gets the CA certificate, it SHOULD authenticate it 236 in some manner unless this is deemed unnecessary, for example because 237 the device is being provisioned inside a trusted environment. For 238 example it could compare its fingerprint with locally configured, 239 out-of-band distributed, identifying information, or by some 240 equivalent means such as a direct comparison with a locally-stored 241 copy of the certificate. 243 Intermediate CA certificates, if any, are signed by a higher-level CA 244 so there is no need to authenticate them against the out-of-band 245 data. Since intermediate CA certificates are rolled over more 246 frequently than long-lived top-level CA certificates, clients MUST 247 verify intermediate-level CA certificates before use during protocol 248 exchanges in case the intermediate CA certificate has expired or 249 otherwise been invalidated. 251 When a CA certificate expires, certificates that have been signed by 252 it may no longer be regarded as valid. CA key rollover provides a 253 mechanism by which the CA can distribute a new CA certificate which 254 is valid in the future once the current certificate has expired. 255 This is done via the GetNextCACert message (section Section 4.7). 257 2.3. Client authentication 259 As with every protocol that uses public-key cryptography, the 260 association between the public keys used in the protocol and the 261 identities with which they are associated must be authenticated in a 262 cryptographically secure manner. Communications between the client 263 and the CA are secured using SCEP Secure Message Objects as explained 264 in Section 3, which specifies how CMS is used to encrypt and sign the 265 data. In order to perform the signing operation the client uses an 266 appropriate local certificate: 268 1. If the client does not have an appropriate existing certificate 269 then a locally generated self-signed certificate MUST be used. 270 The keyUsage extension in the certificate MUST indicate that it 271 is valid for digitalSignature and keyEncipherment (if available). 272 The self-signed certificate SHOULD use the same subject name and 273 key as in the PKCS #10 request. In this case the messageType is 274 PKCSReq (see Section 3.2.1.2). 275 2. If the client already has a certificate issued by the SCEP CA and 276 the CA supports renewal (see Section 2.5), that certificate 277 SHOULD be used. In this case the messageType is RenewalReq (see 278 Section 3.2.1.2). 279 3. Alternatively, if the client has no certificate issued by the 280 SCEP CA but has credentials from an alternate CA then the 281 certificate issued by the alternate CA MAY be used in a renewal 282 request as described above. The SCEP CA's policy will determine 283 whether the request can be accepted or not. 285 Note that although the above text describes several different types 286 of operations, for historical reasons most implementations always 287 apply the first one even if an existing certificate already exists. 288 For this reason support for the first case is mandatory while support 289 for the latter ones are optional (see Section 2.9). 291 During the certificate enrolment process, the client MUST use the 292 selected certificate's key when signing the CMS envelope (see 293 Section 3). This certificate will be either the self-signed one 294 matching the PKCS #10 request or the CA-issued one used to authorise 295 a renewal, and MUST be included in the signedData certificates field 296 (possibly as part of a full certificate chain). If the key being 297 certified allows encryption then the CA's CertResp will use the same 298 certificate's public key when encrypting the response. 300 Note that in the case of renewal operations this means that the 301 request will be signed and authenticated with the key in the 302 previously-issued certificate rather than the key in the PKCS #10 303 request, and the response may similarly be returned encrypted with 304 the key in the previously-issued certificate. This has security 305 implications, see Section 8.6. 307 2.4. Enrolment authorisation 309 PKCS #10 [13] specifies a PKCS #9 [12] challengePassword attribute to 310 be sent as part of the enrolment request. When utilizing the 311 challengePassword, the CA distributes a shared secret to the client 312 which will be used to authenticate the request from the the client. 313 It is RECOMMENDED that the challengePassword be a one-time 314 authenticator value to limit the ability of an attacker who can 315 capture the authenticator from the client or CA to re-use it to 316 request further certificates. 318 Inclusion of the challengePassword by the SCEP client is RECOMMENDED, 319 however its omission allows for unauthenticated authorisation of 320 enrolment requests (which may, however, require manual approval of 321 each certificate issue if other security measures to control issue 322 aren't in place, see below). Inclusion is OPTIONAL for renewal 323 requests that are authenticated by being signed with an existing 324 certificate. The CMS envelope protects the privacy of the 325 challengePassword. 327 A client that is performing certificate renewal as per Section 2.5 328 SHOULD omit the challengePassword but MAY send the originally 329 distributed shared secret in the challengePassword attribute. The 330 SCEP CA MAY use the challengePassword in addition to the previously 331 issued certificate that signs the request to authenticate the 332 request. The SCEP CA MUST NOT attempt to authenticate a client based 333 on a self-signed certificate unless it has been verified through out- 334 of-band means such as a certificate fingerprint. 336 To perform the authorisation in manual mode the client's request is 337 placed in the PENDING state until the CA operator authorises or 338 rejects it. Manual authorisation is used when the client has only a 339 self-signed certificate that hasn't been previously authenticated by 340 the CA and/or a challengePassword is not available. The SCEP CA MAY 341 either reject unauthorised requests or mark them for manual 342 authorisation according to CA policy. 344 2.5. Certificate Enrolment/Renewal 346 A client starts an enrolment transaction (Section 3.3.1) by creating 347 a certificate request using PKCS #10 and sends it to the CA enveloped 348 using CMS (Section 3). 350 If the CA supports certificate renewal and if the CA policy permits 351 then a new certificate with new validity dates can be issued even 352 though the old one is still valid. To renew an existing certificate, 353 the client uses the RenewalReq message (see Section 3.3) and signs it 354 with the existing client certificate. The client SHOULD use a new 355 keypair when requesting a new certificate, but MAY request a new 356 certificate using the old keypair. 358 If the CA returns a CertRep message (Section 3.3.2) with status set 359 to PENDING, the client enters into polling mode by periodically 360 sending a CertPoll message (Section 3.3.3) to the CA until the CA 361 operator completes the manual authentication (approving or denying 362 the request). The frequency of the polling operation is a CA/client 363 configuration issue, and may range from seconds or minutes when the 364 issue process is automatic but not instantaneous, through to hours or 365 days if the certificate issue operation requires manual approval. 367 If polling mode is being used then the client will send a single 368 PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more 369 CertPoll messages (Section 3.3.3). The CA will in return send 0 or 370 more CertRep messages (Section 3.3.2) with status set to PENDING in 371 response to CertPolls, followed by a single CertRep message 372 (Section 3.3.2) with status set to either SUCCESS or FAILURE. 374 2.5.1. Client State Transitions 376 The client state transitions during the SCEP process are indicated in 377 Figure 1. 379 CertPoll 380 +-----<----+ 381 | | 382 | | CertRep(PENDING) 383 | | 384 [CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] ---------> [CERT-ISSUED] 385 ^ PKCSReq | CertRep(SUCCESS) 386 | RenewalReq | 387 | | 388 +-----------------------+ 389 CertRep(FAILURE) or 390 Max-time/max-polls exceeded 392 Figure 1: State Transition Diagram 394 The certificate issue process starts at state CERT-NONEXISTENT. 395 Sending a PKCSReq/RenewalReq message changes the state to CERT-REQ- 396 PENDING. 398 If the CA returns a CertRep message with pkiStatus set to SUCCESS 399 then the state changes to CERT-ISSUED. 401 If the CA returns a CertRep message with pkiStatus set to FAILURE or 402 there is no response then the state reverts back to CERT-NONEXISTENT. 404 If the CA returns a CertRep message with pkiStatus set to PENDING 405 then the client will keep polling by sending a CertPoll message until 406 either a CertRep message with status set to SUCCESS or FAILURE is 407 received or a timeout occurs or the maximum number of polls has been 408 exceeded. 410 A successful transaction in automatic mode: 412 CLIENT CA SERVER 414 PKCSReq: PKI cert. enrolment message 415 --------------------------------> CertRep: pkiStatus = SUCCESS 416 Certificate attached 417 <------------------------------ 418 Receive issued certificate. 420 A successful transaction in manual mode: 422 CLIENT CA SERVER 424 PKCSReq: PKI cert. enrolment message 425 --------------------------------> CertRep: pkiStatus = PENDING 426 <------------------------------ 427 CertPoll: Polling message 428 --------------------------------> CertRep: pkiStatus = PENDING 429 <------------------------------ 430 ................ ............... 432 CertPoll: Polling message 433 --------------------------------> CertRep: pkiStatus = SUCCESS 434 Certificate attached 435 <------------------------------ 436 Receive issued certificate. 438 2.6. Certificate Access 440 A certificate query message is defined for clients to retrieve a copy 441 of their own certificate from the CA. It allows clients that do not 442 store their certificates locally to obtain a copy when needed. This 443 functionality is not intended to provide a general purpose 444 certificate access service, which may be instead be achieved via HTTP 445 certificate-store access [17] or LDAP. 447 To retrieve a certificate from the CA, a client sends a request 448 consisting of the certificate's issuer name and serial number. This 449 assumes that the client has saved the issuer name and the serial 450 number of the issued certificate from the previous enrolment 451 transaction. The transaction to retrieve a certificate consists of 452 one GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2) 453 message, as shown below. 455 CLIENT CA SERVER 457 GetCert: PKI certificate query message 458 -------------------------------> CertRep: pkiStatus = SUCCESS 459 Certificate attached 460 <----------------------------- 461 Receive the certificate. 463 2.7. CRL Access 465 SCEP clients MAY request a CRL via one of three methods: 467 1. If the CA supports the CRL Distribution Points (CRLDPs) extension 468 [14] in issued certificates, then the CRL MAY be retrieved via 469 the mechanism specified in the CRDLP. 470 2. If the CA supports HTTP certificate-store access [17], then the 471 CRL MAY be retrieved via the AuthorityInfoAcces [14] location 472 specified in the certificate. 473 3. Only if the CA does not support CRDLPs or HTTP access should a 474 CRL query be composed by creating a GetCRL message consisting of 475 the issuer name and serial number from the certificate whose 476 revocation status is being queried. 478 The message is sent to the SCEP CA in the same way as the other SCEP 479 requests. The transaction to retrieve a CRL consists of one GetCRL 480 PKI message and one CertRep PKI message, which contains only the CRL 481 (no certificates) in a degenerate certificates-only CMS Signed-Data 482 message (Section 3.4), as shown below. 484 CLIENT CA SERVER 486 GetCRL: PKI CRL query message 487 ----------------------------------> 488 CertRep: CRL attached 489 <----------------------------- 490 Receive the CRL 492 2.8. Certificate Revocation 494 SCEP does not specify a method to request certificate revocation. In 495 order to revoke a certificate, the client must contact the CA using a 496 non-SCEP defined mechanism. 498 2.9. Mandatory-to-Implement Functionality 500 At a minimum, all SCEP implementations compliant with this 501 specification MUST support GetCACaps (Section 3.5.1), GetCACert 502 (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response 503 messages), communication of binary data via HTTP POST (Section 4.1), 504 and the AES128-CBC [7] and SHA-256 [8] algorithms to secure 505 pkiMessages (Section 3.2). 507 For historical reasons implementations MAY support communications of 508 binary data via HTTP GET (Section 4.1), and the triple DES-CBC and 509 SHA-1 algorithms to secure pkiMessages (Section 3.2). 510 Implementations MUST NOT support the obsolete and/or insecure single 511 DES and MD5 algorithms used in earlier versions of this 512 specification, since the unsecured nature of GetCACaps means that an 513 in-path attacker can trivially roll back the encryption used to these 514 insecure algorithms, see Section 8.5. 516 3. SCEP Secure Message Objects 518 CMS is a general enveloping mechanism that enables both signed and 519 encrypted transmission of arbitrary data. SCEP messages that require 520 confidentiality use two layers of CMS, as shown using ASN.1-like 521 pseudocode in Figure 2. By applying both enveloping and signing 522 transformations, the SCEP message is protected both for the integrity 523 of its end-to-end transaction information and the confidentiality of 524 its information portion. 526 pkiMessage { 527 contentType = signedData { pkcs-7 2 }, 528 content { 529 digestAlgorithms, 530 encapsulatedContentInfo { 531 eContentType = data { pkcs-7 1 }, 532 eContent { -- pkcsPKIEnvelope, optional 533 contentType = envelopedData { pkcs-7 3 }, 534 content { 535 recipientInfo, 536 encryptedContentInfo { 537 contentType = data { pkcs-7 1 }, 538 contentEncrAlgorithm, 539 encryptedContent { 540 messageData -- Typically PKCS #10 request 541 } 542 } 543 } 544 } 545 }, 546 certificates, -- Optional 547 crls, -- Optional 548 signerInfo { 549 signedAttrs { 550 transactionID, 551 messageType, 552 pkiStatus, 553 failInfo, -- Optional 554 senderNonce / recipientNonce, 555 }, 556 signature 557 } 558 } 559 } 561 Figure 2: CMS Layering 563 When a particular SCEP message carries data, this data is carried in 564 the messageData. CertRep messages will lack any signed content and 565 consist only of a pkcsPKIEnvelope (Section 3.2.2). 567 The remainder of this document will refer only to 'messageData', but 568 it is understood to always be encapsulated in the pkcsPKIEnvelope 569 (Section 3.2.2). The format of the data in the messageData is 570 defined by the messageType attribute (see Section 3.2) of the Signed- 571 Data. If there is no messageData to be transmitted, the entire 572 pkcsPKIEnvelope MUST be omitted. 574 Samples of SCEP messages are available through the JSCEP project [18] 575 in the src/samples directory. 577 3.1. SCEP Message Object Processing 579 Creating a SCEP message consists of several stages. The content to 580 be conveyed (in other words the messageData) is first encrypted, and 581 the encrypted content is then signed. 583 The form of encryption to be applied depends on the capabilities of 584 the recipient's public key. If the key is encryption-capable (for 585 example RSA) then the messageData is encrypted using the recipient's 586 public key with the CMS KeyTransRecipientInfo mechanism. If the key 587 is not encryption-capable (for example DSA or ECDSA) then the 588 messageData is encrypted using the challengePassword with the CMS 589 PasswordRecipientInfo mechanism. 591 Once the messageData has been encrypted, it is signed with the 592 sender's public key. This completes the SCEP message that is then 593 sent to the recipient. 595 Note that some early implementations of this specification dealt with 596 non-encryption-capable keys by omitting the encryption stage, based 597 on the text in Section 3 that indicated that "the EnvelopedData is 598 omitted". This alternative processing mechanism SHOULD NOT be used 599 since it exposes in cleartext the challengePassword used to authorise 600 the certificate issue. 602 3.2. SCEP pkiMessage 604 The basic building block of all secured SCEP messages is the SCEP 605 pkiMessage. It consists of a CMS Signed-Data content type. The 606 following restrictions apply: 608 o The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7 609 1}). 610 o The signed content, if present (FAILURE and PENDING CertRep 611 messages will lack any signed content), MUST be a pkcsPKIEnvelope 612 (Section 3.2.2), and MUST match the messageType attribute. 613 o The SignerInfo MUST contain a set of authenticatedAttributes 614 (Section 3.2.1). 616 3.2.1. Signed Transaction Attributes 618 At a minimum, all messages MUST contain the following 619 authenticatedAttributes: 621 o A transactionID attribute (see Section 3.2.1.1). 623 o A messageType attribute (see Section 3.2.1.2). 624 o A fresh senderNonce attribute (see Section 3.2.1.5). Note however 625 the comment about senderNonces and polling in Section 3.3.2 626 o Any attributes required by CMS. 628 If the message is a CertRep, it MUST also include the following 629 authenticatedAttributes: 631 o A pkiStatus attribute (see Section 3.2.1.3). 632 o A failInfo and optional failInfotext attribute (see 633 Section 3.2.1.4) if pkiStatus = FAILURE. 634 o A recipientNonce attribute (see Section 3.2.1.5) copied from the 635 senderNonce in the request that this is a response to. 637 The following transaction attributes are encoded as authenticated 638 attributes, and are carried in the SignerInfo for this Signed-Data. 640 +----------------+-----------------+--------------------------------+ 641 | Attribute | Encoding | Comment | 642 +----------------+-----------------+--------------------------------+ 643 | transactionID | PrintableString | Unique ID for this | 644 | | | transaction as a text string | 645 | | | | 646 | messageType | PrintableString | Decimal value as a | 647 | | | numeric text string | 648 | | | | 649 | pkiStatus | PrintableString | Decimal value as a | 650 | | | numeric text string | 651 | | | | 652 | failInfo | PrintableString | Decimal value as a | 653 | | | numeric text string | 654 | | | | 655 | failInfoText | UTF8String | Descriptive text for the | 656 | | | failInfo value | 657 | | | | 658 | senderNonce | OCTET STRING | Random nonce as a 16-byte | 659 | | | binary data string | 660 | | | | 661 | recipientNonce | OCTET STRING | Random nonce as a | 662 | | | 16-byte binary data string | 663 +----------------+-----------------+--------------------------------+ 664 The OIDs used for these attributes are as follows: 666 +----------------------+--------------------------------------------+ 667 | Name | ASN.1 Definition | 668 +----------------------+--------------------------------------------+ 669 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 670 | | VeriSign(113733)} | 671 | | | 672 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 673 | | | 674 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki | 675 | | attributes(9)} | 676 | | | 677 | id-transactionID | OBJECT_IDENTIFIER ::= {id-attributes | 678 | | transactionID(7)} | 679 | | | 680 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 681 | | messageType(2)} | 682 | | | 683 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 684 | | pkiStatus(3)} | 685 | | | 686 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 687 | | failInfo(4)} | 688 | | | 689 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 690 | | senderNonce(5)} | 691 | | | 692 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 693 | | recipientNonce(6)} | 694 | | | 695 | id-scep | OBJECT IDENTIFIER ::= {id-pkix TBD1} | 696 | | | 697 | id-scep-failInfoText | OBJECT IDENTIFIER ::= {id-scep 1} | 698 +----------------------+--------------------------------------------+ 700 The attributes are detailed in the following sections. 702 3.2.1.1. transactionID 704 A PKI operation is a transaction consisting of the messages exchanged 705 between a client and the CA. The transactionID is a text string 706 provided by the client when starting a transaction. The client MUST 707 use a unique string as the transaction identifier, encoded as a 708 PrintableString, which MUST be used for all PKI messages exchanged 709 for a given operation such as a certificate issue. 711 Note that the transactionID must be unique, but not necessarily 712 randomly generated. For example it may be a value assigned by the CA 713 to allow the client to be identified by their transactionID, using a 714 value such as the client device's EUI or RTU ID or a similar unique 715 identifier. This can be useful when the client doesn't have a pre- 716 assigned Distinguished Name that the CA can identify their request 717 through, for example when enrolling SCADA devices. 719 3.2.1.2. messageType 721 The messageType attribute specifies the type of operation performed 722 by the transaction. This attribute MUST be included in all PKI 723 messages. The following message types are defined: 725 o CertRep ("3") -- Response to certificate or CRL request. 726 o RenewalReq ("17") -- PKCS #10 certificate request authenticated 727 with an existing certificate. 728 o PKCSReq ("19") -- PKCS #10 certificate request authenticated with 729 a shared secret. 730 o CertPoll ("20") -- Certificate polling in manual enrolment. 731 o GetCert ("21") -- Retrieve a certificate. 732 o GetCRL ("22") -- Retrieve a CRL. 734 Message types not defined above MUST be treated as an error unless 735 their use has been negotiated through GetCACaps (Section 3.5.1). 737 3.2.1.3. pkiStatus 739 All response messages MUST include transaction status information, 740 which is defined as a pkiStatus attribute: 742 o SUCCESS ("0") -- Request granted. 743 o FAILURE ("2") -- Request rejected. In this case the failInfo 744 attribute, as defined in Section 3.2.1.4, MUST also be present. 745 o PENDING ("3") -- Request pending for manual approval. 747 PKI status values not defined above MUST be treated as an error 748 unless their use has been negotiated through GetCACaps 749 (Section 3.5.1). 751 3.2.1.4. failInfo and failInfoText 753 The failInfo attribute MUST contain one of the following failure 754 reasons: 756 o badAlg ("0") -- Unrecognized or unsupported algorithm. 757 o badMessageCheck ("1") -- Integrity check (meaning signature 758 verification of the CMS message) failed. 760 o badRequest ("2") -- Transaction not permitted or supported. 761 o badTime ("3") -- The signingTime attribute from the CMS 762 authenticatedAttributes was not sufficiently close to the system 763 time. This condition may occur if the CA is concerned about 764 replays of old messages. 765 o badCertId ("4") -- No certificate could be identified matching the 766 provided criteria. 768 Failure reasons not defined above MUST be treated as an error unless 769 their use has been negotiated through GetCACaps (Section 3.5.1). 771 The failInfoText is a free-form UTF-8 text string that provides 772 further information in the case of pkiStatus = FAILURE. In 773 particular it may be used to provide details on why a certificate 774 request was not granted that go beyond what's provided by the near- 775 universal failInfo = badRequest status. Since this is a free-form 776 text string intended for interpretation by humans, implementations 777 SHOULD NOT assume that it has any type of machine-processable 778 content. 780 3.2.1.5. senderNonce and recipientNonce 782 The senderNonce and recipientNonce attributes are a 16 byte random 783 number generated for each transaction. These are intended to prevent 784 replay attacks. 786 When a sender sends a PKI message to a recipient, a fresh senderNonce 787 MUST be included in the message. The recipient MUST copy the 788 senderNonce into the recipientNonce of the reply as a proof of 789 liveliness. The original sender MUST verify that the recipientNonce 790 of the reply matches the senderNonce it sent in the request. If the 791 nonce does not match then the message MUST be rejected. 793 Note that since SCEP exchanges consist of a single request followed 794 by a single response, the use of distinct sender and recipient nonces 795 is redundant since the client sends a nonce in its request and the CA 796 responds with the same nonce in its reply. In effect there's just a 797 single nonce, identified as senderNonce in the client's request and 798 recipientNonce in the CA's reply. 800 3.2.2. SCEP pkcsPKIEnvelope 802 The information portion of a SCEP message is carried inside an 803 EnvelopedData content type, as defined in CMS, with the following 804 restrictions: 806 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}). 808 o encryptedContent MUST be the SCEP message being transported (see 809 Section 4), and must match the messageType authenticated Attribute 810 in the pkiMessage. 812 3.3. SCEP pkiMessage types 814 All of the messages in this section are pkiMessages (Section 3.2), 815 where the type of the message MUST be specified in the 'messageType' 816 authenticated Attribute. Each section defines a valid message type, 817 the corresponding messageData formats, and mandatory authenticated 818 attributes for that type. 820 3.3.1. PKCSReq/RenewalReq 822 The messageData for this type consists of a PKCS #10 Certificate 823 Request. The certificate request MUST contain at least the following 824 items: 826 o The subject Distinguished Name. 827 o The subject public key. 828 o For a PKCSReq and if authorisation based on a shared secret is 829 being used, a challengePassword attribute. 831 In addition the message must contain the the authenticatedAttributes 832 specified in Section 3.2.1. 834 3.3.2. CertRep 836 The messageData for this type consists of a degenerate certificates- 837 only CMS Signed-Data message (Section 3.4). The exact content 838 required for the reply depends on the type of request that this 839 message is a response to. The request types are detailed in 840 Section 3.3.2.1 and in Section 4. In addition the message must 841 contain the the authenticatedAttributes specified in Section 3.2.1. 843 Earlier versions of this specification required that this message 844 include a senderNonce alongside the recipientNonce, which was to be 845 used to chain to subsequent polling operations. However if a single 846 message was lost during the potentially extended interval over which 847 polling could take place (see Section 5 for an example of this) then 848 if the implementation were to enforce this requirement the overall 849 transaction would fail even though nothing had actually gone wrong. 850 Because of this issue, implementations mostly ignored the requirement 851 to carry this nonce over to subsequent polling messages or to verify 852 its presence. More recent versions of the specification no longer 853 require the chaining of nonces across polling operations. 855 3.3.2.1. CertRep SUCCESS 857 When the pkiStatus attribute is set to SUCCESS, the messageData for 858 this message consists of a degenerate certificates-only CMS Signed- 859 Data message (Section 3.4). The content of this degenerate 860 certificates-only Signed-Data depends on what the original request 861 was, as outlined below. 863 +--------------+----------------------------------------------------+ 864 | Request-type | Reply-contents | 865 +--------------+----------------------------------------------------+ 866 | PKCSReq | The reply MUST contain at least the issued | 867 | | certificate in the certificates field of the | 868 | | Signed-Data. The | 869 | | reply MAY contain additional certificates, but the | 870 | | issued | 871 | | certificate MUST be the leaf certificate. | 872 | | | 873 | RenewalReq | Same as PKCSReq | 874 | | | 875 | CertPoll | Same as PKCSReq | 876 | | | 877 | GetCert | The reply MUST contain at least the requested | 878 | | certificate in the certificates field of the | 879 | | Signed-Data. The | 880 | | reply MAY contain additional certificates, but the | 881 | | requested certificate MUST be the leaf | 882 | | certificate. | 883 | | | 884 | GetCRL | The reply MUST contain the CRL in the crls field | 885 | | of the Signed-Data. | 886 +--------------+----------------------------------------------------+ 888 3.3.2.2. CertRep FAILURE 890 When the pkiStatus attribute is set to FAILURE, the reply MUST also 891 contain a failInfo (Section 3.2.1.4) attribute set to the appropriate 892 error condition describing the failure. The reply MAY also contain a 893 failInfoText attribute providing extended details on why the 894 operation failed, typically to expand on the catch-all failInfo = 895 badRequest status. The pkcsPKIEnvelope (Section 3.2.2) MUST be 896 omitted. 898 3.3.2.3. CertRep PENDING 900 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 901 (Section 3.2.2) MUST be omitted. 903 3.3.3. CertPoll (GetCertInitial) 905 This message is used for certificate polling. For unknown reasons it 906 was referred to as "GetCertInitial" in earlier versions of this 907 specification. The messageData for this type consists of an 908 IssuerAndSubject: 910 issuerAndSubject ::= SEQUENCE { 911 issuer Name, 912 subject Name 913 } 915 The issuer is set to the subjectName of the CA (in other words the 916 intended issuerName of the certificate that's being requested). The 917 subject is set to the subjectName used when requesting the 918 certificate. 920 Note that both of these fields are redundant, the CA is identified by 921 the recipientInfo in the pkcsPKIEnvelope (or in most cases simply by 922 the server that the message is being sent to) and the client/ 923 transaction being polled is identified by the transactionID. Both of 924 these fields can be processed by the CA without going through the 925 cryptographically expensive process of unwrapping and processing the 926 issuerAndSubject. For this reason implementations SHOULD assume that 927 the polling operation will be controlled by the recipientInfo and 928 transactionID rather than the contents of the messageData. In 929 addition the message must contain the the authenticatedAttributes 930 specified in Section 3.2.1. 932 3.3.4. GetCert and GetCRL 934 The messageData for these types consist of an IssuerAndSerialNumber 935 as defined in CMS which uniquely identifies the certificate being 936 requested, either the certificate itself for GetCert or its 937 revocation status via a CRL for GetCRL. In addition the message must 938 contain the the authenticatedAttributes specified in Section 3.2.1. 940 These message types, while included here for completeness, apply 941 unnecessary cryptography and messaging overhead to the simple task of 942 transferring a certificate or CRL (see Section 8.8). Implementations 943 SHOULD prefer HTTP certificate-store access [17] or LDAP over the use 944 of these messages. 946 3.4. Degenerate certificates-only CMS Signed-Data 948 CMS includes a degenerate case of the Signed-Data content type in 949 which there are no signers. The use of such a degenerate case is to 950 disseminate certificates and CRLs. For SCEP the content field of the 951 ContentInfo value of a degenerate certificates-only Signed-Data MUST 952 be omitted. When carrying certificates, the certificates are 953 included in the 'certificates' field of the Signed-Data. When 954 carrying a CRL, the CRL is included in the 'crls' field of the 955 Signed-Data. 957 3.5. CA Capabilities 959 In order to provide support for future enhancements to the protocol, 960 CAs MUST implement the GetCACaps message to allow clients to query 961 which functionality is available from the CA. 963 3.5.1. GetCACaps HTTP Message Format 965 This message requests capabilities from a CA, with the format: 967 "GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF 969 as described in Section 4.1. 971 3.5.2. CA Capabilities Response Format 972 The response for a GetCACaps message is a list of CA capabilities, in 973 plain text and in any order, separated by or 974 characters. This specification defines the following keywords 975 (quotation marks are not sent): 977 +--------------------+----------------------------------------------+ 978 | Keyword | Description | 979 +--------------------+----------------------------------------------+ 980 | "AES" | CA supports the AES128-CBC encryption | 981 | | algorithm. | 982 | | | 983 | "DES3" | CA supports the triple DES-CBC encryption | 984 | | algorithm. | 985 | | | 986 | "GetNextCACert" | CA supports the GetNextCACert | 987 | | message. | 988 | | | 989 | "POSTPKIOperation" | CA supports PKIOPeration messages sent | 990 | | via HTTP POST. | 991 | | | 992 | "Renewal" | CA supports the Renewal CA operation. | 993 | | | 994 | "SHA-1" | CA supports the SHA-1 hashing algorithm. | 995 | | | 996 | "SHA-256" | CA supports the SHA-256 hashing algorithm. | 997 | | | 998 | "SHA-512" | CA supports the SHA-512 hashing algorithm. | 999 | | | 1000 | "SCEPStandard" | CA supports all mandatory-to-implement | 1001 | | sections of the SCEP standard. This keyword | 1002 | | implies "AES", | 1003 | | "POSTPKIOperation", and "SHA-256", as well | 1004 | | as the provisions of | 1005 | | Section 2.9. | 1006 +--------------------+----------------------------------------------+ 1008 The table above lists all of the keywords that are defined in this 1009 specification. A CA MAY provide additional keywords advertising 1010 further capabilities and functionality. A client MUST be able to 1011 accept and ignore any unknown keywords that might be sent by a CA. 1013 The CA MUST use the text case specified here, but clients SHOULD 1014 ignore the text case when processing this message. Clients MUST 1015 accept the standard HTTP-style -delimited text as well as the 1016 - delimited text specified in an earlier version of this 1017 specification. 1019 The client SHOULD use SHA-256 in preference to SHA-1 hashing and 1020 AES128-CBC in preference to triple DES-CBC if they are supported by 1021 the CA. Although the CMS format allows any form of AES and SHA-2 to 1022 be specified, in the interests of interoperability the de facto 1023 universal standards of AES128-CBC and SHA-256 SHOULD be used. 1025 Announcing some of these capabilities individually is redundant since 1026 they're required as mandatory-to-implement functionality (see 1027 Section 2.9) whose presence as a whole is signalled by the 1028 "SCEPStandard" capability, but it may be useful to announce them in 1029 order to deal with older implementations that would otherwise default 1030 to obsolete, insecure algorithms and mechanisms. 1032 If the CA supports none of the above capabilities it SHOULD return an 1033 empty message. A CA MAY simply return an HTTP error. A client that 1034 receives an empty message or an HTTP error SHOULD interpret the 1035 response as if none of the capabilities listed are supported by the 1036 CA. 1038 Note that at least one widely-deployed server implementation supports 1039 several of the above operations but doesn't support the GetCACaps 1040 message to indicate that it supports them, and will close the 1041 connection if sent a GetCACaps message. This means that the 1042 equivalent of GetCACaps must be performed through server 1043 fingerprinting, which can be done using the ID string "Microsoft- 1044 IIS". Newer versions of the same server, if sent a SCEP request 1045 using AES and SHA-2, will respond with an invalid response that can't 1046 be decrypted, requiring the use of 3DES and SHA-1 in order to obtain 1047 a response that can be processed even if AES and/or SHA-2 are 1048 allegedly supported. In addition the server will generate CA 1049 certificates that only have one, but not both, of the keyEncipherment 1050 and digitalSignature keyUsage flags set, requiring that the client 1051 ignore the keyUsage flags in order to use the certificates for SCEP. 1053 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1054 ignore the Content-type, as older implementations of SCEP may send 1055 various Content-types. 1057 Example: 1059 GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1 1060 might return: 1062 AES 1063 GetNextCACert 1064 POSTPKIOperation 1065 SCEPStandard 1066 SHA-256 1068 This means that the CA supports modern crypto algorithms, the 1069 GetNextCACert message, allows PKIOperation messages (PKCSReq/ 1070 RenewalReq, GetCert, CertPoll, ...) to be sent using HTTP POST, and 1071 is compliant with the final version of the SCEP standard. 1073 4. SCEP Transactions 1075 This section describes the SCEP Transactions and their HTTP [11] 1076 transport mechanism. 1078 Note that SCEP doesn't follow best current practices on usage of 1079 HTTP. In particular it recommends ignoring some Media Types and 1080 hardcodes specific URI paths. Guidance on the appropriate 1081 application of HTTP in these circumstances may be found in [16]. 1083 4.1. HTTP POST and GET Message Formats 1085 SCEP uses the HTTP "POST" and "GET" HTTP methods [11] to exchange 1086 information with the CA. The following defines the ABNF syntax of 1087 HTTP POST and GET methods sent from a client to a CA: 1089 POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION 1090 SP HTTP-version CRLF 1092 GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION 1093 "&message=" MESSAGE SP HTTP-version CRLF 1095 where: 1097 o SCEPPATH is the HTTP URL path for accessing the CA. Clients 1098 SHOULD set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe" 1099 unless directed to do otherwise by the CA. 1100 o OPERATION depends on the SCEP transaction and is defined in the 1101 following sections. 1102 o HTTP-version is the HTTP version string, which is "HTTP/1.1" for 1103 [11]. 1105 o SP and CRLF are space and carriage return/linefeed as defined in 1106 [6]. 1108 The CA will typically ignore SCEPPATH since it's unlikely to be 1109 issuing certificates via a web server. Clients SHOULD set SCEPPATH 1110 to the fixed string "/cgi-bin/pkiclient.exe" unless directed to do 1111 otherwise by the CA. The CA SHOULD ignore the SCEPPATH unless its 1112 precise format is critical to the CA's operation. 1114 Early SCEP drafts performed all communications via "GET" messages, 1115 including non-idempotent ones that should have been sent via "POST" 1116 messages, see [16] for details. This has caused problems because of 1117 the way that the (supposedly) idempotent GET interacts with caches 1118 and proxies, and because the extremely large GET requests created by 1119 encoding CMS messages may be truncated in transit. These issues are 1120 typically not visible when testing on a LAN, but crop up during 1121 deployment over WANs. If the remote CA supports POST, the CMS- 1122 encoded SCEP messages MUST be sent via HTTP POST instead of HTTP GET. 1123 This applies to any SCEP message except GetCACert, GetNextCACert, and 1124 GetCACaps, and avoids the need for base64- and URL-encoding that's 1125 required for GET messaging. The client can verify that the CA 1126 supports SCEP messages via POST by looking for the "SCEPStandard" or 1127 "POSTPKIOperation" capability (See Section 3.5.2). 1129 If a client or CA uses HTTP GET and encounters HTTP-related problems 1130 such as messages being truncated, seeing errors such as HTTP 414 1131 ("Request URI too long"), or simply having the message not sent/ 1132 received at all, when standard requests to the server (for example 1133 via a web browser) work, then this is a symptom of the problematic 1134 use of HTTP GET. The solution to this problem is to update the 1135 implementation to use HTTP POST instead. In addition when using GET 1136 it's recommended to test the implementation from as many different 1137 network locations as possible to determine whether the use of GET 1138 will cause problems with communications. 1140 When using GET messages to communicate binary data, base64 encoding 1141 as specified in [9] Section 4 MUST be used. The base64 encoded data 1142 is distinct from "base64url" and may contain URI reserved characters, 1143 thus it MUST be escaped as specified in [15] in addition to being 1144 base64 encoded. Finally, the encoded data is inserted into the 1145 MESSAGE portion of the HTTP GET request. 1147 4.2. Get CA Certificate 1149 To get the CA certificate(s), the client sends a GetCACert message to 1150 the CA. The OPERATION MUST be set to "GetCACert". There is no 1151 request data associated with this message. 1153 4.2.1. Get CA Certificate Response Message Format 1155 The response for GetCACert is different between the case where the CA 1156 directly communicates with the client during the enrolment and the 1157 case where an intermediate CA exists and the client communicates with 1158 this CA during the enrolment. 1160 4.2.1.1. CA Certificate Response Message Format 1162 If the CA does not have any intermediate CA certificates, the 1163 response consists of a single X.509 CA certificate. The response 1164 will have a Content-Type of "application/x-x509-ca-cert". 1166 "Content-Type: application/x-x509-ca-cert" 1168 1170 4.2.1.2. CA Certificate Chain Response Message Format 1172 If the CA has intermediate CA certificates, the response consists of 1173 a degenerate certificates-only CMS Signed-Data message (Section 3.4) 1174 containing the certificates, with the intermediate CA certificate(s) 1175 as the leaf certificate(s). The response will have a Content-Type of 1176 "application/x-x509-ca-ra-cert". Note that this designation is used 1177 for historical reasons due to its use in older versions of this 1178 specification, no special meaning should be attached to the label. 1180 "Content-Type: application/x-x509-ca-ra-cert" 1182 1184 4.3. Certificate Enrolment/Renewal 1186 A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a 1187 certificate enrolment or renewal transaction. The OPERATION MUST be 1188 set to "PKIOperation". Note that when used with HTTP POST, the only 1189 OPERATION possible is "PKIOperation", so many CAs don't check this 1190 value or even notice its absence. When implemented using HTTP POST 1191 the message is sent with a Content-Type of "application/x-pki- 1192 message" and might look as follows: 1194 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 1195 Content-Length: 1196 Content-Type: application/x-pki-message 1198 1200 When implemented using HTTP GET this might look as follows: 1202 GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ 1203 message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ 1204 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 1206 4.3.1. Certificate Enrolment/Renewal Response Message 1208 If the request is granted, a CertRep SUCCESS message 1209 (Section 3.3.2.1) is returned. If the request is rejected, a CertRep 1210 FAILURE message (Section 3.3.2.2) is returned. If the CA is 1211 configured to manually authenticate the client, a CertRep PENDING 1212 message (Section 3.3.2.3) MAY be returned. The CA MAY return a 1213 PENDING for other reasons. 1215 The response will have a Content-Type of "application/x-pki-message". 1217 "Content-Type: application/x-pki-message" 1219 1221 4.4. Poll for Client Initial Certificate 1223 When the client receives a CertRep message with pkiStatus set to 1224 PENDING, it will enter the polling state by periodically sending 1225 CertPoll messages to the CA until either the request is granted and 1226 the certificate is sent back or the request is rejected or some 1227 preconfigured time limit for polling or maximum number of polls is 1228 exceeded. The OPERATION MUST be set to "PKIOperation". 1230 CertPoll messages exchanged during the polling period MUST carry the 1231 same transactionID attribute as the previous PKCSReq/RenewalReq. A 1232 CA receiving a CertPoll for which it does not have a matching 1233 PKCSReq/RenewalReq MUST reject this request. 1235 Since at this time the certificate has not been issued, the client 1236 can only use its own subject name (which was contained in the 1237 original PKCS# 10 sent via PKCSReq/RenewalReq) to identify the polled 1238 certificate request (but see the note on identification during 1239 polling in Section 3.3.3). In theory there can be multiple 1240 outstanding requests from one client (for example, if different keys 1241 and different key-usages were used to request multiple certificates), 1242 so the transactionID must also be included to disambiguate between 1243 multiple requests. In practice however the client SHOULD NOT have 1244 multiple requests outstanding at any one time, since this tends to 1245 confuse some CAs. 1247 4.4.1. Polling Response Message Format 1249 The response messages for CertPoll are the same as in Section 4.3.1. 1251 4.5. Certificate Access 1253 A client can query an issued certificate from the SCEP CA, as long as 1254 the client knows the issuer name and the issuer assigned certificate 1255 serial number. 1257 This transaction consists of one GetCert (Section 3.3.4) message sent 1258 to the CA by a client, and one CertRep (Section 3.3.2) message sent 1259 back from the CA. The OPERATION MUST be set to "PKIOperation". 1261 4.5.1. Certificate Access Response Message Format 1263 In this case, the CertRep from the CA is same as in Section 4.3.1, 1264 except that the CA will either grant the request (SUCCESS) or reject 1265 it (FAILURE). 1267 4.6. CRL Access 1269 Clients can request a CRL from the SCEP CA as described in 1270 Section 2.7. The OPERATION MUST be set to "PKIOperation". 1272 4.6.1. CRL Access Response Message Format 1274 The CRL is sent back to the client in a CertRep (Section 3.3.2) 1275 message. The information portion of this message is a degenerate 1276 certificates-only Signed-Data (Section 3.4) that contains only the 1277 most recent CRL in the crls field of the Signed-Data. 1279 4.7. Get Next Certificate Authority Certificate 1281 When a CA certificate is about to expire, clients need to retrieve 1282 the CA's next CA certificate (i.e. the rollover certificate). This 1283 is done via the GetNextCACert message. The OPERATION MUST be set to 1284 "GetNextCACert". There is no request data associated with this 1285 message. 1287 4.7.1. Get Next CA Response Message Format 1289 The response consists of a Signed-Data CMS message, signed by the 1290 current CA signing key. Clients MUST validate the signature on the 1291 message before trusting any of its contents. The response will have 1292 a Content-Type of "application/x-x509-next-ca-cert". 1294 "Content-Type: application/x-x509-next-ca-cert" 1296 1298 The content of the Signed-Data message is a degenerate certificates- 1299 only Signed-Data message (Section 3.4) containing the new CA 1300 certificate(s) to be used when the current CA certificate expires. 1302 5. SCEP Transaction Examples 1304 The following section gives several examples of client to CA 1305 transactions. Client actions are indicated in the left column, CA 1306 actions are indicated in the right column, and the transactionID is 1307 given in parentheses (for ease of reading small integer values have 1308 been used, in practice full transaction IDs would be used). The 1309 first transaction, for example, would read like this: 1311 "Client Sends PKCSReq message with transactionID 1 to the CA. The CA 1312 signs the certificate and constructs a CertRep Message containing the 1313 signed certificate with a transaction ID 1. The client receives the 1314 message and installs the certificate locally". 1316 5.1. Successful Transactions 1318 Successful Enrolment Case: Automatic processing 1320 PKCSReq (1) ----------> CA issues certificate 1321 <---------- CertRep (1) SUCCESS 1322 Client installs certificate 1323 Successful Enrolment Case: Manual authentication required 1325 PKCSReq (2) ----------> Cert request goes into queue 1326 <---------- CertRep (2) PENDING 1327 CertPoll (2) ----------> Still pending 1328 <---------- CertRep (2) PENDING 1329 CertPoll (2) ----------> CA issues certificate 1330 <---------- CertRep (2) SUCCESS 1331 Client installs certificate 1333 CA certificate rollover case: 1335 GetNextCACert ----------> 1336 <---------- New CA certificate 1338 PKCSReq* ----------> CA issues certificate with 1339 new key 1340 <---------- CertRep SUCCESS 1341 Client stores certificate 1342 for installation when 1343 existing certificate expires. 1345 * Enveloped for the new CA certificate. The CA will use the envelope 1346 to determine which key to use to issue the client certificate. 1348 5.2. Transactions with Errors 1350 In the case of polled transactions that aren't completed 1351 automatically, there are two potential options for dealing with a 1352 transaction that's interrupted due to network or software/hardware 1353 issues. The first is for the client to preserve its transaction 1354 state and resume the CertPoll polling when normal service is 1355 restored. The second is for the client to begin a new transaction by 1356 sending a new PKCSReq/RenewalReq rather than continuing the previous 1357 CertPoll. Both options have their own advantages and disadvantages. 1359 The CertPoll continuation requires that the client maintain its 1360 transaction state for the time when it resumes polling. This is 1361 relatively simple if the problem is a brief network outage, but less 1362 simple when the problem is a client crash and restart. In addition 1363 the CA may treat a lost network connection as the end of a 1364 transaction, so that a new connection followed by a CertPoll will be 1365 treated as an error. 1367 The PKCSReq/RenewalReq continuation doesn't require any state to be 1368 maintained since it's a new transaction, however it may cause 1369 problems on the CA side if the certificate was successfully issued 1370 but the client never received it, since the resumed transaction 1371 attempt will appear to be a request for a duplicate certificate (see 1372 Section 8.4 for more on why this is a problem). In this case the CA 1373 may refuse the transaction, or require manual intervention to remove/ 1374 revoke the previous certificate before the client can request another 1375 one. 1377 Since the new-transaction resume is more robust in the presence of 1378 errors and doesn't require special-case handling by either the client 1379 or CA, clients SHOULD use the new-transaction option in preference to 1380 the resumed-CertPoll option to recover from errors. 1382 Resync Case 1: Client resyncs via new PKCSReq (recommended): 1384 PKCSReq (3) ----------> Cert request goes into queue 1385 <---------- CertRep (3) PENDING 1386 CertPoll (3) ----------> Still pending 1387 X-------- CertRep(3) PENDING 1388 (Network outage) 1389 (Client reconnects) 1390 PKCSReq (4) ----------> 1391 <---------- CertRep (4) PENDING 1392 etc... 1394 Resync Case 2: Client resyncs via resumed CertPoll after a network 1395 outage (not recommended, use PKCSReq to resync): 1397 PKCSReq (5) ----------> Cert request goes into queue 1398 <---------- CertRep (5) PENDING 1399 CertPoll (5) ----------> Still pending 1400 X-------- CertRep(5) PENDING 1401 (Network outage) 1402 (Client reconnects) 1403 CertPoll (5) ----------> CA issues certificate 1404 <---------- CertRep (5) SUCCESS 1405 Client installs certificate 1406 Resync Case 3: Special-case variation of case 2 where the CertRep 1407 SUCCESS rather than the CertRep PENDING is lost (recommended): 1409 PKCSReq (6) ----------> Cert request goes into queue 1410 <---------- CertRep (6) PENDING 1411 CertPoll (6) ----------> Still pending 1412 <---------- CertRep (6) PENDING 1413 CertPoll (6) ----------> CA issues certificate 1414 X-------- CertRep(6) SUCCESS 1415 (Network outage) 1416 (Client reconnects) 1417 PKCSReq (7) ----------> There is already a valid 1418 certificate with this DN. 1419 <---------- CertRep (7) FAILURE 1420 Admin revokes certificate 1421 PKCSReq (8) ----------> CA issues new certificate 1422 <---------- CertRep (8) SUCCESS 1423 Client installs certificate 1425 Resync Case 4: Special-case variation of case 1 where the CertRep 1426 SUCCESS rather than the CertRep PENDING is lost (not recommended, use 1427 PKCSReq to resync): 1429 PKCSReq (9) ----------> Cert request goes into queue 1430 <---------- CertRep (9) PENDING 1431 CertPoll (9) ----------> Still pending 1432 <---------- CertRep (9) PENDING 1433 CertPoll (9) ----------> CA issues certificate 1434 X-------- CertRep(9) SIGNED CERT 1435 (Network outage) 1436 (Client reconnects) 1437 CertPoll (9) ----------> Certificate already issued 1438 <---------- CertRep (9) SUCCESS 1439 Client installs certificate 1441 As these examples indicate, resumption from an error via a resumed 1442 CertPoll is tricky due to the state that needs to be held by both the 1443 client and/or the CA. A PKCSReq/RenewalReq resume is the easiest to 1444 implement since it's stateless and is identical for both polled and 1445 non-polled transactions, while a CertPoll resume treats the two 1446 differently (a non-polled transaction is resumed with a PKCSReq/ 1447 RenewalReq, a polled transaction is resumed with a CertPoll). For 1448 this reason error recovery SHOULD be handled via a new PKCSReq rather 1449 than a resumed CertPoll. 1451 6. Contributors/Acknowledgements 1453 The editor would like to thank all of the previous editors, authors 1454 and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David 1455 Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their 1456 work maintaining the draft over the years. The IETF reviewers 1457 provided much useful feedback that helped improve the draft, and in 1458 particular spotted a number of things that were present in SCEP 1459 through established practice rather than by being explicitly 1460 described in the text. Numerous other people have contributed during 1461 the long life cycle of the draft and all deserve thanks. In addition 1462 several PKCS #7 / CMS libraries contributed to interoperability by 1463 doing the right thing despite what earlier SCEP drafts required. 1465 The earlier authors would like to thank Peter William of ValiCert, 1466 Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. 1467 and Christopher Welles of IRE, Inc. for their contributions to early 1468 versions of this protocol and this document. 1470 7. IANA Considerations 1472 One object identifier for an arc to assign SCEP Attribute Identifiers 1473 was assigned in the SMI Security for PKIX (1.3.6.1.5.5.7) registry, 1474 Simple Certificate Enrollment Protocol Attributes denoted as id-scep: 1476 id-scep OBJECT IDENTIFIER ::= { id-pkix TBD1 } 1478 (Editor's note: When the OID is assigned, the values in the OID table 1479 in Section 3.2 will also need to be updated). 1481 This assignment created the new SMI Security for SCEP Attribute 1482 Identifiers ((1.3.6.1.5.5.7.TBD1) registry with the following entries 1483 with references to this document: 1485 id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 } 1487 Entries in the registry are assigned according to the "Specification 1488 Required" policy defined in [4]. 1490 Section 3.2.1.2 describes a SCEP Message Type Registry and 1491 Section 3.5 describes a SCEP CA Capabilities Registry to be 1492 maintained by the IANA, defining a number of such code point 1493 identifiers. Entries in the registry are to be assigned according to 1494 the "Specification Required" policy defined in [4]. 1496 This document defines four media types for IANA registration: 1498 "application/x-x509-ca-cert" 1499 "application/x-x509-ca-ra-cert" 1500 "application/x-x509-next-ca-cert" 1501 "application/x-pki-message" 1503 Note that these are grandfathered media types registered as per 1504 Appendix A of [2]. Templates for registrations are specified below. 1506 7.1. Registration of application/x-x509-ca-cert media type 1508 Type name: application 1510 Subtype name: x-x509-ca-cert 1512 Required parameters: none 1514 Optional parameters: none 1516 Encoding considerations: binary 1518 Security considerations: This media type contains a certificate, see 1519 the Security Considerations section of [14]. There is no executable 1520 content. 1522 Interoperability considerations: This is a grandfathered registration 1523 of an alias to application/pkix-cert (basically a single DER encoded 1524 Certification Authority certificate), which is only used in SCEP. 1526 Published specification: draft-gutmann-scep-15 1528 Applications that use this media type: SCEP uses this media type when 1529 returning a CA certificate. 1531 Fragment identifier considerations: N/A 1533 Additional information: 1535 Deprecated alias names for this type: N/A 1537 Magic number(s): none 1539 File extension(s): N/A 1541 Macintosh file type code(s): N/A 1542 Person and email address to contact for further information: See the 1543 Authors' Addresses section of draft-gutmann-scep-15 1545 Intended usage: LIMITED USE 1547 Restrictions on usage: SCEP protocol 1549 Author: See the Authors' Addresses section of draft-gutmann-scep-15 1551 Change controller: IETF 1553 Provisional registration? No 1555 7.2. Registration of application/x-x509-ca-ra-cert media type 1557 Type name: application 1559 Subtype name: x-x509-ca-ra-cert 1561 Required parameters: none 1563 Optional parameters: none 1565 Encoding considerations: binary 1567 Security considerations: This media type consists of a degenerate 1568 certificates-only CMS Signed-Data message (Section 3.4) containing 1569 the certificates, with the intermediate CA certificate(s) as the leaf 1570 certificate(s). There is no executable content. 1572 Interoperability considerations: This is a grandfathered registration 1573 which is only used in SCEP. 1575 Published specification: draft-gutmann-scep-15 1577 Applications that use this media type: SCEP uses this media type when 1578 returning CA Certificate Chain Response. 1580 Fragment identifier considerations: N/A 1582 Additional information: 1584 Deprecated alias names for this type: N/A 1586 Magic number(s): none 1588 File extension(s): N/A 1589 Macintosh file type code(s): N/A 1591 Person and email address to contact for further information: See the 1592 Authors' Addresses section of draft-gutmann-scep-15 1594 Intended usage: LIMITED USE 1596 Restrictions on usage: SCEP protocol 1598 Author: See the Authors' Addresses section of draft-gutmann-scep-15 1600 Change controller: IETF 1602 Provisional registration? no 1604 7.3. Registration of application/x-x509-next-ca-cert media type 1606 Type name: application 1608 Subtype name: x-x509-next-ca-cert 1610 Required parameters: none 1612 Optional parameters: none 1614 Encoding considerations: binary 1616 Security considerations: This media type consists of a Signed-Data 1617 CMS message, signed by the current CA signing key. There is no 1618 executable content. 1620 Interoperability considerations: This is a grandfathered registration 1621 which is only used in SCEP. 1623 Published specification: draft-gutmann-scep-15 1625 Applications that use this media type: SCEP uses this media type when 1626 returning a Get Next CA Response. 1628 Fragment identifier considerations: N/A 1630 Additional information: 1632 Deprecated alias names for this type: N/A 1634 Magic number(s): none 1636 File extension(s): N/A 1637 Macintosh file type code(s): N/A 1639 Person and email address to contact for further information: See the 1640 Authors' Addresses section of draft-gutmann-scep-15 1642 Intended usage: LIMITED USE 1644 Restrictions on usage: SCEP protocol 1646 Author: See the Authors' Addresses section of draft-gutmann-scep-15 1648 Change controller: IETF 1650 Provisional registration? no 1652 7.4. Registration of application/x-pki-message media type 1654 Type name: application 1656 Subtype name: x-pki-message 1658 Required parameters: none 1660 Optional parameters: none 1662 Encoding considerations: binary 1664 Security considerations: This media type consists of a degenerate 1665 certificates-only CMS Signed-Data message. There is no executable 1666 content. 1668 Interoperability considerations: This is a grandfathered registration 1669 which is only used in SCEP. 1671 Published specification: draft-gutmann-scep-15 1673 Applications that use this media type: SCEP uses this media type when 1674 returning a Certificate Enrolment/Renewal Response. 1676 Fragment identifier considerations: N/A 1678 Additional information: 1680 Deprecated alias names for this type: N/A 1682 Magic number(s): none 1684 File extension(s): N/A 1685 Macintosh file type code(s): N/A 1687 Person and email address to contact for further information: See the 1688 Authors' Addresses section of draft-gutmann-scep-15 1690 Intended usage: LIMITED USE 1692 Restrictions on usage: SCEP protocol 1694 Author: See the Authors' Addresses section of draft-gutmann-scep-15 1696 Change controller: IETF 1698 Provisional registration? no 1700 8. Security Considerations 1702 The security goal of SCEP is that no adversary can subvert the public 1703 key/identity binding from that intended. An adversary is any entity 1704 other than the client and the CA participating in the protocol. 1706 This goal is met through the use of CMS and PKCS #10 encryption and 1707 digital signatures using authenticated public keys. The CA's public 1708 key is authenticated via out-of-band means such as the checking of 1709 the CA fingerprint and the SCEP client's public key is authenticated 1710 through manual or pre-shared secret authentication. 1712 8.1. General Security 1714 Common key-management considerations such as keeping private keys 1715 truly private and using adequate lengths for symmetric and asymmetric 1716 keys must be followed in order to maintain the security of this 1717 protocol. This is especially true for CA keys which, when 1718 compromised, compromise the security of all relying parties. 1720 8.2. Use of the CA private key 1722 A CA private key is generally meant for, and is usually flagged as, 1723 being usable for certificate (and CRL) signing exclusively rather 1724 than data signing or encryption. The SCEP protocol however uses the 1725 CA private key to both sign and optionally encrypt CMS transport 1726 messages. This is generally considered undesirable as it widens the 1727 possibility of an implementation weakness and provides an additional 1728 location where the private key must be used (and hence is slightly 1729 more vulnerable to exposure) and where a side-channel attack might be 1730 applied. 1732 8.3. ChallengePassword Shared Secret Value 1734 The security measures that should be applied to the challengePassword 1735 shared secret depend on the manner in which SCEP is employed. In the 1736 simplest case, with SCEP used to provision devices with certificates 1737 in the manufacturing facility, the physical security of the facility 1738 may be enough to protect the certificate issue process with no 1739 additional measures explicitly required. In general though the 1740 security of the issue process depends on the security employed around 1741 the use of the challengePassword shared secret. While it's not 1742 possible to enumerate every situation in which SCEP may be utilised, 1743 the following security measures should be considered. 1745 o The challengePassword, despite its name, shouldn't be a 1746 conventional password but a high-entropy shared secret 1747 authentication string. Using the base64 encoding of a keying 1748 value generated or exchanged as part of standard device 1749 authentication protocols like EAP or DNP3 SA makes for a good 1750 challengePassword. The use of high-entropy shared secrets is 1751 particulary important when the PasswordRecipientInfo option is 1752 used to encrypt SCEP messages, see Section 3.1. 1753 o If feasible, the challengePassword should be a one-time value used 1754 to authenticate the issue of a single certificate (subsequent 1755 certificate requests will be authenticated by being signed with 1756 the initial certificate). If the challengePassword is single-use 1757 then the arrival of subsequent requests using the same 1758 challengePassword can then be used to indicate a security breach. 1759 o The lifetime of a challengePassword can be limited, so that it can 1760 be used during initial device provisioning but will have expired 1761 at a later date if an attacker manages to compromise the 1762 challengePassword value, for example by compromising the device 1763 that it's stored in. 1764 o The CA should take appropriate measures to protect the 1765 challengePassword, for example via physical security measures, or 1766 by storing it as a salted iterated hash or equivalent memory-hard 1767 function or as a keyed MAC value if it's not being used for 1768 encryption, or by storing it in encrypted form if it is being used 1769 for encryption. 1771 8.4. Lack of Certificate Issue Confirmation 1773 SCEP provides no confirmation that the issued certificate was 1774 successfully received and processed by the client. This means that 1775 if the CertRep message is lost or can't be processed by the client 1776 then the CA will consider the certificate successfully issued while 1777 the client won't. If this situation is of concern then the correct 1778 issuance of the certificate will need to be verified by out-of-band 1779 means, for example through the client sending a message signed by the 1780 newly-issued certificate to the CA. This also provides the proof of 1781 possession that's not present in the case of a renewal operation, see 1782 Section 8.6. 1784 8.5. GetCACaps Issues 1786 The GetCACaps response is not authenticated by the CA. This allows 1787 an attacker to perform downgrade attacks on the cryptographic 1788 capabilities of the client/CA exchange. In particular if the server 1789 were to support MD5 and single DES then an in-path attacker could 1790 trivially roll back the encryption to use these insecure algorithms. 1791 By taking advantage of the presence of large amounts of static known 1792 plaintext in the SCEP messages, as of 2017 a DES rainbow table attack 1793 can recover most encryption keys in under a minute, and MD5 chosen- 1794 prefix collisions can be calculated for a few tens of cents of 1795 computing time using tools like HashClash. It is for this reason 1796 that this specification makes single DES and MD5 a MUST NOT feature. 1797 Note that all known servers support at least triple DES and SHA-1 1798 (regardless of whether "DES3" and "SHA-1" are indicated in 1799 GetCACaps), so there should never be a reason to fall all the way 1800 back to single DES and MD5. One simple countermeasure to a GetCACaps 1801 downgrade attack is for clients that are operating in an environment 1802 where on-path attacks are possible and that expect the "SCEPStandard" 1803 capability to be indicated by the CA but don't see it in the 1804 GetCACaps response to treat its absence as a security issue, and 1805 either discontinue the exchange or continue as if "SCEPStandard" had 1806 been returned. This requires a certain tradeoff between 1807 compatibility with old servers and security against active attacks. 1809 8.6. Lack of PoP in Renewal Requests 1811 Renewal operations (but not standard certificate-issue operations) 1812 are processed via a previously-issued certificate and its associated 1813 private key, not the key in the PKCS #10 request. This means that a 1814 client no longer demonstrates proof of possession (PoP) of the 1815 private key corresponding to the public key in the PKCS #10 request. 1816 It is therefore possible for a client to re-certify an existing key 1817 used by a third party, so that two or more certificates exist for the 1818 same key. By switching out the certificate in a signature, an 1819 attacker can appear to have a piece of data signed by their 1820 certificate rather than the original signer's certificate. This, and 1821 other, attacks are described in S/MIME ESS [21]. 1823 Avoiding these types of attacks requires situation-specific measures. 1824 For example CMS/SMIME implementations may use the ESSCertID attribute 1825 from S/MIME ESS [21] or its successor S/MIME ESSv2 [22] to 1826 unambiguously identify the signing certificate. However since other 1827 mechanisms and protocols that the certificates will be used with 1828 typically don't defend against this problem, it's unclear whether 1829 this is an actual issue with SCEP. 1831 8.7. Traffic Monitoring 1833 SCEP messages are signed with certificates that may contain 1834 identifying information. If these are sent over the public Internet 1835 and real identity information (rather than placeholder values or 1836 arbitrary device IDs) are included in the signing certificate data, 1837 an attacker may be able to monitor the identities of the entities 1838 submitting the certificate requests. If this is an issue then [3] 1839 should be consulted for guidance. 1841 8.8. Unnecessary cryptography 1843 Some of the SCEP exchanges use unnecessary signing and encryption 1844 operations. In particular the GetCert and GetCRL exchanges are 1845 encrypted and signed in both directions. The information requested 1846 is public and thus encrypting the requests is of questionable value. 1847 In addition CRLs and certificates sent in responses are already 1848 signed by the CA and can be verified by the recipient without 1849 requiring additional signing and encryption. More lightweight means 1850 of retrieving certificates and CRLs such as HTTP certificate-store 1851 access [17] and LDAP are recommended for this reason. 1853 8.9. Use of SHA-1 1855 The majority of the large numbers of devices that use SCEP today 1856 default to SHA-1, with many supporting only that hash algorithm with 1857 no ability to upgrade to a newer one. SHA-1 is no longer regarded as 1858 secure in all situations, but as used in SCEP it's still safe. There 1859 are three reasons for this. The first is that attacking SCEP would 1860 require creating a fully general SHA-1 collision in close to real 1861 time alongside breaking AES (more specifically, it would require 1862 creating a fully general SHA-1 collision for the PKCS #10 request, 1863 breaking the AES encryption around the PKCS #10 request, and then 1864 creating a second SHA-1 collision for the signature on the encrypted 1865 data), which won't be feasible for a long time. 1867 The second reason is that the signature over the message, in other 1868 words the SHA-1 hash that isn't protected by encryption, doesn't 1869 serve any critical cryptographic purpose: The PKCS #10 data itself is 1870 authenticated through its own signature, protected by encryption, and 1871 the overall request is authorised by the (encrypted) shared secret. 1872 The sole exception to this will be the small number of 1873 implementations that support the Renewal operation, which may be 1874 authorised purely through a signature, but presumably any 1875 implementation recent enough to support Renewal also supports SHA-2. 1877 Any legacy implementation that supports the historic core SCEP 1878 protocol would not be affected. 1880 The third reason is that SCEP uses the same key for encryption and 1881 signing, so that even if an attacker were able to capture an outgoing 1882 Renewal request that didn't include a shared secret (in other words 1883 one that was only authorised through a signature), break the AES 1884 encryption, forge the SHA-1 hash in real time, and forward the forged 1885 request to the CA, they couldn't decrypt the returned certificate, 1886 which is protected with the same key that was used to generate the 1887 signature. While Section 8.8 points out that SCEP uses unnecessary 1888 cryptography in places, the additional level of security provided by 1889 the extra crypto makes it immune to any issues with SHA-1. 1891 This doesn't mean that SCEP implementations should continue to use 1892 SHA-1 in perpetuity, merely that there's no need for a panicked 1893 switch to SHA-2. 1895 9. References 1897 9.1. Normative References 1899 [1] Bradner, S., "Key words for use in RFCs to Indicate 1900 Requirement Levels", BCP 14, RFC 2119, March 1997. 1902 [2] Freed, N., Klensin, J., and T. Hansen, "Media Type 1903 Specifications and Registration Procedures", RFC 6838, 1904 January 2013. 1906 [3] Farrell, S. and H. Tschofenig, "Guidelines for Writing an 1907 IANA Considerations Section in RFCs", RFC 7258, May 2014. 1909 [4] Leiba, B. and T. Narten, "Guidelines for Writing an IANA 1910 Considerations Section in RFCs", RFC 8126, June 2017. 1912 [5] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1913 2119 Key Words", RFC 8174, May 2017. 1915 [6] Crocker, R. and P. Overell, "Augmented BNF for Syntax 1916 Specifications: ABNF", RFC 5234, January 2008. 1918 [7] Technology, U. N. I. O. S. A., "The Advanced Encryption 1919 Standard (AES)", FIPS 197, November 2001. 1921 [8] Technology, U. N. I. O. S. A., "Secure Hash Standard 1922 (SHS)", FIPS 180-3, October 2008. 1924 [9] Josefsson, S., "The Base16, Base32, and Base64 Data 1925 Encodings", RFC 4648, October 2006. 1927 [10] Housley, R., "Cryptographic Message Syntax (CMS)", 1928 RFC 5652, September 2009. 1930 [11] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1931 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1932 2014. 1934 [12] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1935 Classes and Attribute Types Version 2.0", RFC 2985, 1936 November 2000. 1938 [13] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1939 Request Syntax Specification Version 1.7", RFC 2986, 1940 November 2000. 1942 [14] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1943 Housley, R., and W. Polk, "Internet X.509 Public Key 1944 Infrastructure Certificate and Certificate Revocation List 1945 (CRL) Profile", RFC 5280, May 2008. 1947 [15] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1948 Resource Identifiers (URI): Generic Syntax", RFC 3986, 1949 January 2005. 1951 9.2. Informative References 1953 [16] Nottingham, M., "Building Protocols with HTTP", November 1954 2018. 1956 [17] Gutmann, P., "Internet X.509 Public Key Infrastructure 1957 Operational Protocols: Certificate Store Access via HTTP", 1958 RFC 4387, February 2006. 1960 [18] "A Java implementation of the Simple Certificate Enrolment 1961 Protocol", . 1963 [19] Alighieri, D., "Internet Key Exchange (IKEv2) Protocol", 1964 RFC 7296, March 1300. 1966 [20] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1967 Mail Extensions (S/MIME) Version 3.2 Message 1968 Specification", RFC 5751, January 2010. 1970 [21] Hoffman, P., "Enhanced Security Services for S/MIME", 1971 RFC 2634, June 1999. 1973 [22] Schaad, J., "Enhanced Security Services (ESS) Update: 1974 Adding CertID Algorithm Agility", RFC 5035, August 2007. 1976 [23] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1977 Version 1.3", RFC 8446, August 2018. 1979 Appendix A. Background Notes 1981 This specification has spent over twenty years in the draft stage. 1982 Its original goal, provisioning IPsec routers with certificates, has 1983 long since changed to general device/embedded system/IoT use. To fit 1984 this role, extra features were bolted on in a haphazard manner 1985 through the addition of a growing list of appendices and by inserting 1986 additional, often conflicting, paragraphs in various locations in the 1987 body text. Since existing features were never updated as newer ones 1988 were added, the specification accumulated large amounts of historical 1989 baggage over time. If OpenPGP was described as "a museum of 1990s 1990 crypto" then the SCEP draft was its graveyard. 1992 About five years ago the specification, which even at that point had 1993 seen only sporadic re-posts of the existing document, was more or 1994 less abandoned by its original sponsors. Due to its widespread use 1995 in large segments of the industry, the specification was rebooted in 1996 2015, cleaning up fifteen years worth of accumulated cruft, fixing 1997 errors, clarifying ambiguities, and bringing the algorithms and 1998 standards used into the current century (prior to the update, the de- 1999 facto lowest-common denominator algorithms used for interoperability 2000 were the insecure forty-year-old single DES and broken MD5 hash 2001 algorithms). 2003 Note that although the text of the current specification has changed 2004 significantly due to the consolidation of features and appendices 2005 into the main document, the protocol that it describes is identical 2006 on the wire to the original (with the unavoidable exception of the 2007 switch from single DES and MD5 to AES and SHA-2). The only two 2008 changes introduced, the "SCEPStandard" indicator in GetCACaps and the 2009 failInfoText attribute, are both optional values and would be ignored 2010 by older implementations that don't support them, or can be omitted 2011 from messages if they are found to cause problems. 2013 Other changes include: 2015 o Resolved contradictions in the text, for example a requirement 2016 given as a MUST in one paragraph and a SHOULD in the next, a MUST 2017 NOT in one paragraph and a MAY a few paragraphs later, a SHOULD 2018 NOT contradicted later by a MAY, and so on. 2020 o Merged several later fragmentary addenda placed in appendices (for 2021 example the handling of certificate renewal) with the body of the 2022 text. 2023 o Merged the SCEP Transactions and SCEP Transport sections, since 2024 the latter mostly duplicated (with occasional inconsistencies) the 2025 former. 2026 o Updated the algorithms to ones dating from at least this century. 2027 o Did the same for normative references to other standards. 2028 o Updated the text to use consistent terminology for the client and 2029 CA rather than a mixture of client, requester, requesting system, 2030 end entity, server, certificate authority, certification 2031 authority, and CA. 2032 o Corrected incorrect references to other standards, e.g. 2033 IssuerAndSerial -> IssuerAndSerialNumber. 2034 o Corrected errors such as a statement that when both signature and 2035 encryption certificates existed, the signature certificate was 2036 used for encryption. 2037 o Condensed redundant discussions of the same topic spread across 2038 multiple sections into a single location. For example the 2039 description of intermediate CA handling previously existed in 2040 three different locations, with slightly different reqirements in 2041 each one. 2042 o Added a description of how pkiMessages were processed, which was 2043 never made explicit in the original specification. This led to 2044 creative interpretations that had security problems but were 2045 employed anyway due to the lack of specific guidance on what to 2046 do. 2047 o Relaxed some requirements that didn't serve any obvious purpose 2048 and that major implementations didn't seem to be enforcing. For 2049 example the requirement that the self-signed certificate used with 2050 a request MUST contain a subject name that matched the one in the 2051 PKCS #10 request was relaxed to a SHOULD because a number of 2052 implementations either ignored the issue entirely or at worst 2053 performed some minor action like creating a log entry after which 2054 they continued anyway. 2055 o Removed discussion of the transactionID from the security 2056 considerations, since the instructions there were directly 2057 contradicted by the discussion of the use of the transactionID in 2058 Section 5. 2059 o Added a requirement that the signed message include the signing 2060 certificate(s) in the signedData certificates field. This was 2061 implicit in the original specification (without it, the message 2062 couldn't be verified by the CA) and was handled by the fact that 2063 most PKCS #7/CMS libraries do this by default, but was never 2064 explicitly mentioned. 2065 o Clarified sections that were unclear or even made no sense, for 2066 example the requirement for a "hash on the public key" [sic] 2067 encoded as a PrintableString. 2069 o Renamed "RA certificates" to "intermediate CA certificates". The 2070 original document at some point added mention of RA certificates 2071 without specifying how the client was to determine that an RA was 2072 in use, how the RA operations were identified in the protocol, or 2073 how it was used. It's unclear whether what was meant was a true 2074 RA or merely an intermediate CA, as opposed to the default 2075 practice of having certificates issued directly from a single root 2076 CA certificate. This update uses the term "intermediate CA 2077 certificates", since this seems to have been the original intent 2078 of the text. 2079 o Redid the PKIMessage diagram to match what was specified in CMS, 2080 the original diagram omitted a number of fields and nested data 2081 structures which meant that the diagram didn't match either the 2082 text or the CMS specification. 2083 o Removed the requirement for a CertPoll to contain a 2084 recipientNonce, since CertPoll is a client message and will never 2085 be sent in response to a message containing a senderNonce. See 2086 also the note in Section 3.3.2. 2087 o Clarified certificate renewal. This represents a capability that 2088 was bolted onto the original protocol with (at best) vaguely- 2089 defined semantics, including a requirement by the CA to guess 2090 whether a particular request was a renewal or not. In response to 2091 developer feedback that they either avoided renewal entirely 2092 because of this uncertainty or hardcoded in particular behaviour 2093 on a per-CA basis, this specification explicitly identifies 2094 renewal requests as such, and provides proper semantics for them. 2095 o Corrected the requirement that "undefined message types are 2096 treated as an error" since this negates the effect of GetCACaps, 2097 which is used to define new message types. In particular 2098 operations such as GetCACaps "Renewal" would be impossible if 2099 enforced as written, because the Renewal operation was an 2100 undefined message type at the time. 2101 o In line with the above, added IANA registries for several entries 2102 that had previously been defined in an ad-hoc manner in different 2103 locations in the text. 2104 o Added the "SCEPStandard" keyword to GetCACaps to indicate that the 2105 CA complies with the final version of the SCEP standard, since the 2106 definition of what constitutes SCEP standards compliance has 2107 changed significantly over the years. 2108 o Added the optional failInfoText attribute to deal with the fact 2109 that failInfo was incapable of adequately communicating to clients 2110 why a certificate request operation had been rejected. 2111 o Removed the discussion in the security considerations of 2112 revocation issues, since SCEP doesn't support revocation as part 2113 of the protocol. 2114 o Clarified the use of nonces, which if applied as originally 2115 specified would have made the use of polling in the presence of a 2116 lost message impossible. 2118 o Removed the discussion of generating a given transactionID by 2119 hashing the public key, since this implied that there was some 2120 special significance in the value generated this way. Since it 2121 was neither a MUST nor a MAY, it was unsound to imply that servers 2122 could rely on the value being generated a certain way. In 2123 addition it wouldn't work if multiple transactions as discussed in 2124 Section 4.4 were initiated, since the deterministic generation via 2125 hashing would lead to duplicate transactionIDs. 2126 o Added examples of SCEP messages to give implementers something to 2127 aim for. 2129 Author's Address 2131 Peter Gutmann 2132 University of Auckland 2133 Department of Computer Science 2134 Auckland 2135 New Zealand 2137 Email: pgut001@cs.auckland.ac.nz