Network Device Enrollment Service (NDES) Basics

The Simple Certificate Enrollment Protocol (SCEP) was developed by Verisign for Cisco in the early 2000s to provide a simplified method for requesting certificates. Previously, network devices required manually generating a certificate request on each device, submitting it to a certificate authority, and then manually reinstalling the issued certificate on the corresponding device.

An IETF standardization did not take place until two decades later with the RFC 8894.

Originally, SCEP was intended for equipping network devices such as switches and routers with certificates. Today, however, significantly more device types support Certificate Enrollment via SCEP.

These may include, for example:

• Smartphones and tablets with Apple iOS or Android
• Personal computer with Microsoft Windows since version 8.1, as well as the corresponding Windows Server versions
• Telephone systems
• Thin clients
• Routers, switches, access points
• Mobile Device Management solutions like AirWatch or Microsoft Intune
• Also for Linux there are corresponding client implementations

Microsoft Actve Directory certificate services support the SCEP protocol through the Network Device Enrollment Service (NDES) since Windows Server 2003.

Functionality

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

The basic problem compared to an Active Directory domain member, to whom the Requesting certificates via RPC/DCOM available is that the devices in question do not have a centrally managed identity that could be used for their automated identification, as is the case with Kerberos in Active Directory, for example. In addition, all devices would need to speak a standardized interface that could be used to request certificates from any certificate authority product.

In this case, the SCEP server acts as an intermediary between the end device that requires a certificate and the certification authority.

First, an administrator (in the sense of: someone who manages a terminal device that is to receive a certificate) logs on to the SCEP server with his or her identifier. In the case of NDES, this is an Active Directory identifier. This is required for requesting certificates on an Certificate template authorized, which in turn is configured for use on the NDES server.

The original concept at this point was that the named administrator is a natural person who performs this step manually. In practice, however, this step is usually delegated to a management software (for example, mobile device management such as VMware AirWatch or Microsoft Intune).

If the NDES server determines that the administrator is authorized to request certificates, it issues him a one-time password (OTP).

This one-time password is now stored on the end device together with the address of the NDES server. The device is now able to generate a key pair and a certificate request and send them to the NDES server. It authenticates itself with the previously configured one-time password.

Instead of a one-time password, the device can also log in Identify with an existing certificateif it contains the same identity and was issued by the same certification authority (so-called renewal mode, works only if the certification authority that issued the certificates to be renewed is a member in NTAuthCertificates is). Likewise, it would be possible, configure a static, i.e. non-changing password, or completely disable the requirement of a passwordbut this should not be done for safety reasons.

Before the certificate request is generated, a request is sent to the NDES server (GetCACaps operation) to determine the supported functions of the server.

Likewise, the certification authority certificate (GetCACert operation) is requested. In the case of the NDES, however, not only the certification authority certificate is returned, but also the Registration Authority (RA) Certificateissued by the certification authority to the NDES server, thus appointing it as its proxy (more precisely, the "CEP Encryption" certificate).

After the end device has authenticated the certification authority using the Registration Authority certificate, a certificate request is created in the format PKCS#10. This contains the one-time password as an attribute (if used).

The PKCS#10 certificate request is then stored in a Cryptographic Message Syntax (CMS, a further development of the PKCS#7 standard) SignedData data structure and, depending on the case, signed with a self-signed (in the case of an initial application) or an existing certificate already issued by the same certification authority (in the case of a renewal) and then sent to the certification authority.

The confidential information such as the one-time password contained in the certificate request as the "ChallengePassword" attribute is encrypted with the public key of the previously requested RA certificate. For this reason, it is generally not possible for a third party to submit a manually generated certificate request via SCEP, since the private key for signing the CMS message (must match the public key of the certificate request) is not usually available to the third party, and the one-time password must be entered in the certificate request when it is created.

The NDES server, if authentication with one-time password or certificate was successful, now issues the certificate request via RPC/DCOM to the certification authority, where the certificate is issued (or the certificate request is rejected). The PKCS#10 certificate request is packaged into a new CMS (PKCS#7) message and signed by the NDES server using its RA certificate ("enrollment agent") so that the certification authority can verify the existence of a valid signature (unfortunately, this verification does not take place in the default setting), it must be activated separately). This prevents certificate requests bypassing the NDES service directly against the certification authority.

These are not around a Enroll on Behalf of (EOBO) process. Accordingly, the settings for restricted certificate enrollment agents on the certificate authority do not affect the process.

Once the certificate has been issued, it is transferred to the NDES server, which in turn delivers the certificate to the requesting terminal.

Variants

NDES can be configured for the following operating modes:

• Operation with a changing password (default setting) - each password can be used only once
• Operation with a static password - the password is the same every time, but can be changed regularly with a trick
• Operation without password - no password is required by NDES for certificate request (not recommended)

Safety concerns

When using a network device registration service, the following should be considered in terms of security:

• The authentication of the SCEP protocol is relatively weak. Knowledge of the identity of the device administrator account or one of the one-time passwords entitles to arbitrary Certificate Enrollment. NDES can also for the use of a static password or even to the Use without a password configured, which is even more insecure.
• NDES is not able to check certificate requests against a set of rules. The certificate template must be configured so that the identity contained in the certificate can be specified by the applicant. Accordingly, authorized applicants get any identity information signed. This circumstance can be avoided by using an extended Policy Modules for the Certification Authority like TameMyCerts however, be severely restricted.
• Even if this type of Certificate Enrollment does not involve a Enroll on Behalf of (EOBO) is used and, by default, the signatures of the certificate requests sent by NDES to the certification authority are not verified once, the Registration Authority certificates of the NDES server may be used to request certificates for other identities.
• The combination of these factors can make it Allow an attacker to arbitrarily request certificates via SCEP, which may allow an increase of authorization in the network up to the takeover of the Active Directory.

Special features

• The Microsoft implementation of the SCEP protocol called NDES can only handle a single combination of certificate authority and certificate template. Accordingly, multiple NDES servers must be operated if there are multiple use cases to be served via SCEP.
• The Registration Authority certificates can only with Cryptographic Service Providers (CSP) therefore only RSA keys can be used for them. For device certificates requested via NDES However, this restriction does not apply.
• High availability for NDES cannot be implemented in a meaningful way because the one-time passwords cannot be synchronized between multiple nodes.
• The installation of an NDES server unnecessarily requires Enterprise Administrator permissions, this however, can be circumvented.

Conclusion

With SCEP and the Microsoft implementation NDES, it is possible to automatically distribute certificates to devices that do not have an Active Directory identifier. These can be network devices such as switches or routers, as well as mobile devices such as smartphones and tablets. However, it is also possible, for example, Automatically equip servers in the cloud with certificates after they have been installed.

Related links:

• Configuring the Network Device Enrollment Service (NDES) to operate without a password.
• Authentication at the Network Device Enrollment Service (NDES) with an existing certificate (renewal mode)
• Configuring the Network Device Enrollment Service (NDES) to work with a static password.
• Using custom Registration Authority (RA) certificate templates for the Network Device Enrollment Service (NDES).
• Basics of manual and automatic Certificate Enrollment via Lightweight Directory Access Protocol (LDAP) and Remote Procedure Call / Distributed Common Object Model (RPC/DCOM)
• Configure Device Template for Network Device Enrollment Service (NDES)
• Certificate Enrollment for Windows Systems via the Network Device Enrollment Service (NDES) with Windows PowerShell
• Install SSCEP for Linux (Debian Buster) and apply for certificates via the Network Device Enrollment Service (NDES).

External sources

• Active Directory Certificate Services (AD CS): Network Device Enrollment Service (NDES) (Microsoft)
• Simple Certificate Enrollment Protocol Overview (Cisco)
• Simple Certificate Enrollment Protocol (Wikipedia)
• Vulnerability Note VU#971035 - Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests (Carnegie Mellon University)
• draft-nourse-scep-23 - Simple Certificate Enrollment Protocol (Internet Engineering Task Force)
• RFC 7030 - Enrollment over Secure Transport (Internet Engineering Task Force)
• RFC 8894 - Simple Certificate Enrolment Protocol (Internet Engineering Task Force)