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:

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 and is available under a free license. It can downloaded via GitHub and can be used free of charge.

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).

Example: a one-time password generated by NDES

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.

Example: The functions supported by NDES in response to the GetCACaps request

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).

Example: A certificate chain returned by NDES on the GetCACerts request

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.

Overview: Sequence of SCEP communication

Variants

NDES can be configured for the following operating modes:

Safety concerns

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

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:

External sources

21 thoughts on “Grundlagen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)”

Comments are closed.

en_USEnglish