Simple Certificate Enrollment Protocol (SCEP) is described by the informational RFC 8894. Older versions of this protocol became a de facto industrial standard for pragmatic provisioning of digital certificates mostly for network equipment.

The protocol has been designed to make the request and issuing of digital certificates as simple as possible for any standard network user. These processes have usually required intensive input from network administrators, and so have not been suited to large-scale deployments.

Popularity

The Simple Certificate Enrollment Protocol still is the most popular and widely available certificate enrollment protocol, being used by numerous manufacturers of network equipment and software who are developing simplified means of handling certificates for large-scale implementation to everyday users. It is used for example by the Cisco IOS operating system (even if Cisco is now pushing the slightly more featured EST) and iPhones to enroll in enterprise PKIs.[1] Most PKI software (specifically RA implementations) supports it, including the Network Device Enrollment Service (NDES) of Active Directory Certificate Service and Intune.[2]

Criticism

  • Legacy versions of SCEP, which still are employed in the vast majority of implementations, are limited to enrolling certificates for RSA keys only.
  • Due to the use of the self-signed PKCS#10 format for Certificate Signing Requests (CSR), certificates can be enrolled only for keys that support signing. A limitation shared by other enrollment protocols based on PKCS#10 CSRs, e.g., EST and ACME, or even the web-based enrollment workflow of most PKI software where the requester starts by generating a key pair and a CSR in PKCS#10 format. The CRMF format, as used by CMP and CMS, is more flexible here, supporting also keys that are usable for encryption or key agreement only. However this distinction is mostly theoretical since in practice all algorithms commonly used with certificates support signing. For example ACME, which also uses PKCS#10, issues TLS certificates which by definition must be capable of signing for the TLS handshake.
  • Although proof-of-origin of certificate enrollment requests, i.e., authentication of the certificate requestor, is the most critical security requirement, for pragmatic reasons its support is not strictly required within SCEP. Signature-based client authentication using an already existing certificate would be the preferred mechanism but in many use cases is not possible or not supported by the given deployments. As an alternative, SCEP just provides the use of a shared secret, which should be client-specific and used only once.
  • The confidentiality of the shared secret optionally used for source authentication is fragile because it must be included in the 'challengePassword' field of the CSR, which is then protected by an outer encryption. It would have been more secure to use a password-based MAC algorithm such as HMAC.
  • Encrypting the whole PKCS#10 structure in order to protect the 'challengePassword' field (which is used for self-contained source authentication) has a further drawback: the whole CSR becomes unreadable for all parties except the intended ultimate receiver (the CA), although most of its contents is not confidential. So the PKCS#10 structure cannot be checked by intermediate agents such as an RA.

History

SCEP was designed by Verisign for Cisco[3] as a lean alternative to Certificate Management over CMS (CMC) and the very powerful but also rather bulky Certificate Management Protocol (CMP). It had support from Microsoft early with its continuous inclusion in Windows starting with Windows 2000[4]. In around 2010, Cisco suspended work on SCEP and developed EST instead. In 2015, Peter Gutmann revived the Internet Draft due to SCEP widespread use in industry and in other standards.[5] He updated the draft with more modern algorithms corrected numerous issues in the original specification. In September 2020, the draft was published as informational RFC 8894, more than twenty years after the beginning of the standardization effort.[6] The new version also supports enrollment of non-RSA certificates (e.g., for ECC public keys).

See also

References

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.