For many years SCEP was a simple and widely used protocol for obtaining X.509 certificates. However, not too so long ago another protocol called EST (RFC 7030) was developed.
What are the main reasons to move out from SCEP in favor of EST?
Add a comment
|
5 Answers
What is SCEP?
Simple Certificate Enrollment Protocol is a certificate enrollment protocol originally defined by Cisco in the 2011 IETF Internet-Draft draft-nourse-scep, and more recently in the 2018 IETF Internet-Draft draft-gutmann-scep out of the University of Auckland.
The official specification was published in September 2020 as RFC 8894
What is EST?
Enrollment over Secure Transport (EST) is a certificate enrollment protocol defined by Cisco, Akayla, and Aruba Networks in RFC 7030. EST can be thought of as an evolution of SCEP. Cisco provides a nice guide to understanding EST, which is spun to favour EST.
SCEP vs EST
Similarities
Both protocols are very similar in that the client sends CMS (aka PKCS#7) and CSR (aka PKCS#10) messages to the Certificate Authority, signed with a pre-existing certificate in order to enroll for a new certificate with the given CA.
They both support the following methods for the client to prove its identity to the CA (though the exact details differ):
- CMS / CSR messages signed with a previously issued client certificate (e.g., an existing certificate issued by the CA). This is typical for a certificate renewal.
- CMS / CSR messages signed with a previously installed certificate that the CA has been configured to trust (e.g., manufacturer- installed certificate or a certificate issued by some other party). This is typical for IoT devices, mobile devices, etc, that have a certificate injected during manufacture, and where the CA has been configured to trust the manufacturing CA.
- A shared secret that has been distributed to the client out-of-band.
Differences
The main difference between them is that EST uses standard TLS as the transport security layer, requiring that the certificates above be provided for TLS client-authentication in addition to signing the CMS and CSR messages.
In SCEP, the shared secret auth method is done by including the secret in the challengePassword field of the CSR, and creating a disposable self-signed certificate to sign the CMS message with.
Since EST uses standard TLS, it has two methods for enrollment using a shared secret:
Server-only TLS with HTTP username/password basic auth, where the username and password are the shared secret distributed out of band.
Mutual-auth TLS using a Pre-Shared Key (PSK) cipher suite. Neat side-effect is that this allows the client to authenticate the CA without needing to know in advance which CA it will be getting a cert from (ie no need to distribute the Root CA cert in advance).
Summary
Both are acceptable protocols for automated certificate enrollment with a PKI and offer similar security characteristics.
The advantages of EST are that it outsources its transport layer security to standard TLS, and therefore will continue to pick up security and performance improvements as new versions of TLS are released. This can also be an downside for constrained devices that do not want to dedicate code-space to a TLS implementation.
answered Dec 1, 2017 at 0:55
-
EST being CMC over secure transport, it absolutely cannot be understood as an evolution of SCEP. It's an usable profile of CMC basically. Sep 28, 2022 at 17:34
There are a lot of reasons to prefer EST over SCEP,
EST promotes enrollment based on X.509 client certificate authentication, helping on removing passwords from the past. EST can enroll clients (give an operational certificate) presenting a certificate of a third-party CA (a birth certificate). One a client is enrolled, it can renew its certificate authenticating again with its operational.
EST supports Elliptic Curves and separates very well transport and authentication from enrolling:
Transport is based on TLS. EST does not need to be updated to benefit from better cryptosuites.
Authentication can be implemented in TLS (client certificate authentication), in the HTTP transport channel (Basic Authentication), and in the CSR challenge code. Or even in the three layers at the same time!!!!
Enrollment is based on PKCS#10 (a standard Certificate Signing Request), and response is a plain X.509 certificate embedded in a PKCS#7. It is so simple that I am pretty sure that the EST protocol does not need to be updated if any of these (PKCS#10, PKCS#7, X.509) are updated.
EST provides the /serverkeygen method which may be a very interesting option for very compact IoT devices (i.e. AVR devices like Arduino).
EST is a lot easier to implement than SCEP, and therefore more secure and less dangerous than an overbloated protocol. In fact it can be implemented using curl and openssl.
If things got really complicated it can act as a CMC proxy offering the optional method /fullcmc.
I have implemented recently a EST client (PEST) written with Perl with a EST test suite (TEST) for configuring and testing EST servers. It can be downloaded from Github https://github.com/killabytenow/pest. I am pretty sure that writing a similar tool for SCEP would have ben a lot of harder. Personally and IMHO EST is always better than SCEP.
-
SCEP does support elliptic curves. Old implementations don't but then SCEP predates the widespread use of elliptic curves. Oct 6, 2022 at 10:38
-
"I am pretty sure that writing a similar tool for SCEP would have ben a lot of harder". It's only true because you outsourced most of the complexity to the TLS stack you didn't write. EST is only simpler if you already have a TLS stack, which is often the case, but not always especially in IoT context. Oct 6, 2022 at 13:03
An advantage of EST is that it supports Elliptic Curve Cryptography (ECC) encryption compared to SCEP's RSA encryption. The major advantage of ECC over RSA is that it can provide the same amount of security but with much smaller (50% smaller) key sizes. Therefore if you have two identical limited memory devices, the one that integrates the EST protocol would have much securer certificates than the one that only integrates SCEP. A 15,360 bit RSA key has the same cryptographic strength as a 521 bit ECC key - 15,360 bits may seem like overkill but a discussion here shows sides saying quantum computers could be able to break RSA in a decade or so (though some answers say both are as easily breakable so read all the answers and make your own decision on it ^-^).
Another factor is that in EST the certificate can only be given to the client, from the certificate authority, who holds the unique private key or username/password. Hence the client can only get the certificate for themselves and not anyone else (EDIT: unless they share their username/password, thus using a private key is better).
SCEP - on the other hand - is given to a client from the certificate authority using a shared key which is meant to be secret, however, the problem arises that anyone who knows the key can get a certificate, thus the client could generate copies of the certificate to pass on to someone else and so on...
These are only the security advantages that EST holds over SCEP - Cisco have an interesting document about other advantages and differences here.
EDIT: As discussed in comments.
-
A 1024 bit RSA key is certainly not overkill given that 768 bit keys were vulnerable more than 5 years ago, 1024 is the bare minimum now. Also, quantum computing will break ECC just as much as RSA. Nov 28, 2017 at 20:21
-
1It was more as an example to show that ECC and RSA keys can have the same strength even though ECC can be 10-50% smaller bit-wise. And as to whether quantum computers will be able to break either or both encryptions, you should look at this question which has very interesting answers supporting both sides - discussing how the architecture of the chips and whatnot affect it.– adamNov 28, 2017 at 20:37
-
Interesting, I just found out that RSA actually could be quantum safe. Either way though, both RSA and ECC as used today are vulnerable to Shor's algorithm. Nov 28, 2017 at 20:59
-
1@AndrolGenhald LOL Bernstein's joke paper strikes again! RSA is quantum safe if you use 1TB keys, and are willing to wait 2 months for your laptop's full disk encryption after each reboot. The point of that paper is to settle the debate among academic about whether "Post Quantum RSA" could ever be practical. The answer is a fat No. Nov 29, 2017 at 3:42
-
@AdamBromiley Minor quibble, technically username/password is a form of shared secret, so if you argue that "anyone who knows the key can get a certificate", then you need to make the same statement about the username / password method. Nov 29, 2017 at 3:46
To kill a few often claimed misconceptions...
- SCEP is still the most widely supported of the two (e.g. the widely used Active Directory Certificate Service supports SCEP but not EST at the time of writing, SCEP is also what is expected to enroll the very popular iPhone).
- SCEP now supports elliptic curves. Cisco still likes to claim it doesn't tho (but that's actually the case for older implementations).
- SCEP doesn't need a TLS protocol stack.
- EST is a simpler protocol than SCEP only if you don't count the necessity of having a full TLS stack. The fact that EST is based over TLS can be an issue : a TLS stack is pretty big, complex and fraught with potential security issues, and actually too big for some lightweight devices that needs a certificate but don't intend to use it for TLS.
- Many devices do have a TLS stack anyway, and for them EST is a pretty good choice.
It's odd that no one mentioned that most SCEP implementations are a dumpster fire. They tend to lack any input validation beyond the challenge password. The requestor can pick any cert contents they like.
