Grundlagen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)

Das Simple Certificate Enrollment Protocol (SCEP) wurde in den frühen 2000er Jahren von Verisign für Cisco entwickelt, um eine vereinfachte Methode zum Beantragen von Zertifikaten verwenden zu können. Zuvor musste für Netzwerkgeräte manuell eine Zertifikatanforderung auf jedem Gerät erzeugt, zu einer Zertifizierungsstelle übermittelt und anschließend das ausgestellte Zertifikat wieder manuell auf dem entsprechenden Gerät installiert werden.

Eine IETF-Standardisierung erfolgte erst zwei Jahrzehnte später mit dem RFC 8894.

Ursprünglich war SCEP dafür gedacht, Netzwerkgeräte, wie etwa Switche und Router mit Zertifikaten auszurüsten. Heutzutage unterstützen jedoch deutlich mehr Gerätetypen die Zertifikatbeantragung via SCEP.

Hierzu können beispielsweise gehören:

Smartphones und Tablets mit Apple iOS oder Android
Personal Computer mit Microsoft Windows seit Version 8.1, ebenso die entsprechenden Windows Server Versionen
Telefonanlagen
Thin Clients
Router, Switche, Access Points
Mobile Device Management Lösungen wir AirWatch oder Microsoft Intune
Auch für Linux gibt es entsprechende Client-Implementierungen

Die Microsoft Actve Directory Zertifikatdienste unterstützen das SCEP Protokoll durch den Registrierungsdient für Netzwerkgeräte (Network Device Enrollment Service, NDES) seit Windows Server 2003.

Funktionsweise

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Das Grundlegende Problem im Vergleich zu einem Active Directory Domänen-Mitglied, welchem die Zertifikatbeantragung via RPC/DCOM zur Verügung steht, ist, dass die betreffenden Geräte nicht über eine zentral verwaltete Identität verfügen, die man für deren automatisierte Identifikation verwenden könnte, wie es etwa bei Kerberos in Active Directory der Fall ist. Außerdem müssten alle Geräte eine standardisierte Schnittstelle sprechen, über die Zertifikate von beliebigen Zertifizierungsstellen-Produkten beantragt werden können.

Der SCEP-Server agiert in diesem Fall als Vermittler zwischen dem Endgerät, das ein Zertifikat benötigt, und der Zertifizierungsstelle.

Zunächst meldet sich ein Administrator (im Sinne von: jemand, der ein Endgerät verwaltet, welches ein Zertifikat bekommen soll) mit seiner Kennung am SCEP-Server an. Im Falle des NDES ist dies eine Active Directory-Kennung. Diese ist für die Beantragung von Zertifikaten auf einer Zertifikatvorlage berechtigt, welche wiederum auf dem NDES-Server zur Verwendung konfiguriert ist.

Das ursprüngliche Konzept sah an dieser Stelle vor, dass es sich bei dem genannten Administrator um eine natürliche Person handelt, welche diesen Schritt manuell durchführt. In der Praxis wird dieser Schritt aber üblicherweise an eine Managementsoftware delegiert (beispielsweise Mobile Device Management wie VMware AirWatch oder Microsoft Intune).

Stellt der NDES-Server nun also fest, dass der Administrator für die Beantragung von Zertifikaten berechtigt ist, händigt er ihm ein Einmalkennwort (engl. One Time Password, OTP) aus.

Beispiel: ein von NDES generiertes Einmalkennwort

Dieses Einmalkennwort wird nun zusammen mit der Adresse des NDES-Servers auf dem Endgerät hinterlegt. Das Gerät ist nun in der Lage, ein Schlüsselpaar sowie eine Zertifikatanforderung zu erzeugen und an den NDES-Server zu senden. Es authentifiziert sich mit dem zuvor konfigurierten Einmalkennwort.

Anstelle eines Einmalkennwortes kann das Gerät sich auch mit einem bestehenden Zertifikat ausweisen, wenn es die gleiche Identität enthält und von der gleichen Zertifizierungsstelle ausgestellt wurde (sog. Renewal Modus, funktioniert nur, wenn die Zertifizierungsstelle, welche die zu erneuernden Zertifikate ausgestellt hat, Mitglied in NTAuthCertificates ist). Ebenso wäre es möglich, ein statisches, also nicht wechselndes Kennwort zu konfigurieren, oder das Verlangen eines Kennwortes komplett zu deaktivieren, was aus Sicherheitsgründen aber nicht erfolgen sollte.

Bevor die Zertifikatanforderung erzeugt wird, wird eine Anfrage an den NDES-Server gesendet (GetCACaps Operation), um die unterstützen Funktionen des Servers zu ermitteln.

Beispiel: Die von NDES unterstützten Funktionen als Antwort auf die GetCACaps Anfrage

Ebenso wird das Zertifizierungsstellen-Zertifikat (GetCACert Operation) angefragt. Im Falle des NDES wird jedoch nicht nur das Zertifizierungsstellen-Zertifikat zurückgesendet, sondern auch das Registration Authority (RA) Zertifikat, welches die Zertifizierungsstelle dem NDES-Server ausgestellt hat, und ihn somit zu ihrem Stellvertreter ernannt hat (genauer gesagt das "CEP Encryption" Zertifikat).

Beispiel: Eine von NDES auf die GetCACerts Anfrage zurückgegebene Zertifikatkette

Nachdem das Endgerät die Zertifizierungsstelle anhand des Registration Authority Zertifikats authentisiert hat, wird eine Zertifikatanforderung im Format PKCS#10 erstellt. Diese beinhaltet als Attribut (sofern verwendet) das Einmalkennwort.

Die PKCS#10 Zertifikatanforderung wird anschließend in einer Cryptographic Message Syntax (CMS, einer Weiterentwicklung des PKCS#7 Standards) SignedData Datenstruktur verpackt und je nach Fall mit einem selbstsignierten (im Falle einer Erstbeantragung) oder einem bereits von der gleichen Zertifizierungsstelle ausgestellten vorhandenen (im Falle einer Erneuerung) Zertifikat signiert und anschließend an die Zertifizierungsstelle gesendet.

Die vertraulichen Informationen wie das in der Zertifikatanforderung als "ChallengePassword" Attribut enthaltene Einmalkennwort wird mit dem öffentlichen Schlüssel des zuvor angefragten RA-Zertifikats verschlüsselt. Aus diesem Grund ist es in der Regel auch nicht möglich, eine manuell generierte Zertifikatanforderung via SCEP durch einen Dritten einzureichen, da diesem in der Regel der private Schlüssel zum Signieren der CMS Nachricht (muss zum öffentlichen Schlüssel der Zertifikatanforderung passen) nicht vorliegt, und das Einmalkennwort bereits bei der Erstellung der Zertifikatanforderung in diese mit eingetragen werden muss.

Der NDES-Server gibt, sofern die Authentisierung mit Einmalkennwort oder Zertifikat erfolgreich war, die Zertifikatanforderung nun per RPC/DCOM an die Zertifizierungsstelle weiter, wo das Zertifikat ausgestellt (oder die Zertifikatanforderung abgelehnt) wird. Die PKCS#10 Zertifikatanforderung wird hierbei in eine neue CMS (PKCS#7) Nachricht verpackt und durch den NDES-Server mittels seines RA-Zertifikats ("Enrollment Agent") signiert, sodass die Zertifizierungsstelle das Vorhandensein einer gültigen Signatur überprüfen kann (in der Standardeinstellung findet diese Überprüfung allerdings leider nicht statt, sie muss gesondert aktiviert werden). Dies verhindert Zertifikatanforderungen am NDES Dienst vorbei direkt gegen die Zertifizierungsstelle.

Hierbei handelt es sich nicht um einen Enroll on Behalf of (EOBO) Prozess. Entsprechend haben die Einstellungen für eingeschränkte Zertifikatregistrierungs-Agenten auf der Zertifizierungsstelle keine Auswirkungen auf den Prozess.

Wurde das Zertifikat ausgestellt, wird es an den NDES Server übergeben, welcher das Zertifikat wiederum an das antragstellende Endgerät ausliefert.

Übersicht: Abfolge der SCEP Kommunikation

Varianten

NDES kann für die folgenden Betriebsmodi konfiguriert werden:

Betrieb mit einem wechselnden Kennwort (Standardeinstellung) – jedes Kennwort kann nur ein einziges Mal verwendet werden
Betrieb mit einem statischen Kennwort – das Kennwort ist jedes Mal das gleiche, kann mit einem Trick jedoch regelmäßig geändert werden
Betrieb ohne Kennwort – es wird durch NDES kein Kennwort für die Zertifikatbeantragung verlangt (nicht empfohlen)

Sicherheitsbedenken

Beim Einsatz eines Registrierungsdienstes für Netzwerkgeräte ist in Hinsicht auf die Sicherheit folgende zu beachten:

Die Authentifizierung des SCEP-Protokolls ist relativ schwach. Kenntnis der Identität des Geräte-Administrator-Kontos oder eines der Einmalkennwörter berechtigt zu beliebiger Zertifikatbeantragung. NDES kann auch für die Verwendung eines statischen Passwortes oder gar zur Verwendung ohne ein Passwort konfiguriert werden, was noch deutlich unsicherer ist.
NDES ist nicht in der Lage, Zertifikatanforderungen gegen ein Regelwerk zu überprüfen. Die Zertifikatvorlage muss konfiguriert sein, dass die im Zertifikat enthaltene Identität durch den Antragsteller angegeben werden kann. Entsprechend bekommen berechtigte Antragsteller jegliche Identitäts-Informationen signiert. Dieser Umstand kann durch Einsatz eines erweiterten Policy Moduls für die Zertifizierungsstelle wie TameMyCerts jedoch stark eingeschränkt werden.
Auch wenn bei dieser Art der Zertifikatbeantragung kein Enroll on Behalf of (EOBO) zum Einsatz kommt und in der Standardeinstellung die Signaturen der durch NDES an die Zertifizierungsstelle gesendeten Zertifikatanforderungen nich einmal überprüft werden, kann mit den Registration Authority Zertifikaten des NDES Servers unter Umständen eine Zertifikatbeantragung für andere Identitäten erfolgen.
Die Kombination dieser Faktoren kann es einem Angreifer ermöglichen, beliebig Zertifikate über SCEP zu beantragen, die unter Umständen eine Erhöhung der Berechtigung im Netzwerk bis hin zur Übernahme des Active Directory ermöglichen.

Besonderheiten

Die Microsoft-Implementierung des SCEP Protokolls namens NDES kann nur mit einer einzigen Kombination aus Zertifizierungsstelle und Zertifikatvorlage umgehen. Entsprechend müssen mehrere NDES Server betrieben werden, wenn es mehrere Use Cases gibt, die per SCEP bedient werden sollen.
Die Registration Authority Zertifikate können nur mit Cryptographic Service Providern (CSP) umgehen, daher können nur RSA Schlüssel für diese verwendet werden. Für die über NDES beantragten Geräte-Zertifikate gilt diese Einschränkung jedoch nicht.
Eine Hochverfügbarkeit für NDES kann nicht sinnvoll implementiert werden, da die Einmalkennwörter nicht zwischen mehreren Knoten synchronisiert werden können.
Die Installation eines NDES Servers benötigt unnötigerweise Enterprise Administrator Berechtigungen, dies kann allerdings umgangen werden.

Fazit

Mit SCEP und der Microsoft-Implementierung NDES ist eine automatische Verteilung von Zertifikaten an Geräte möglich, welche über keine Active Directory Kennung verfügen. Dies können sowohl Netzwerkgeräte wie Switche oder Router sein, als auch mobile Geräte wie Smartphones und Tablets. Es ist aber beispielsweise auch möglich, Server in der Cloud automatisch mit Zertifikaten auszurüsten, nachdem diese installiert wurden.

Weiterführende Links:

Externe Quellen

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)