Simple Certificate Enrollment Protocol

Dieser Artikel wurde am 16. September 2024 auf den Seiten der Qualitätssicherung eingetragen. Bitte hilf mit, ihn zu verbessern, und beteilige dich bitte an der Diskussion! Folgendes muss noch verbessert werden: Zumindest die EinleitungOMA-tauglich machen Lutheraner (Diskussion) 17:21, 16. Sep. 2024 (CEST)

Simple Certificate Enrollment Protocol (SCEP) ist ein IP-Protokoll und De-facto-Industriestandard für die pragmatische Bereitstellung von digitalen Zertifikaten für Netzwerkgeräte. Das Protokoll wurde entwickelt, um die Anforderung und Ausstellung von digitalen Zertifikaten so einfach wie möglich für jeden Standardnetzwerkbenutzer zu gestalten. Diese Prozesse erforderten normalerweise intensive Eingriffe von Netzwerkadministratoren und waren daher nicht für großflächige Implementierungen geeignet.

Das Simple Certificate Enrollment Protocol ist nach wie vor das beliebteste und am weitesten verbreitete Zertifikatsanforderungsprotokoll und wird von zahlreichen Herstellern von Netzwerkgeräten und Software verwendet, die vereinfachte Methoden zur Handhabung von Zertifikaten für eine großflächige Implementierung für den täglichen Benutzer entwickeln. Es wird beispielsweise vom Cisco Internetworking Operating System (IOS) verwendet, obwohl Cisco das Enrollment over Secure Transport (EST) mit zusätzlichen Funktionen bevorzugt, sowie von iPhones (iOS) zur Registrierung in einer unternehmensweiten Public-Key-Infrastruktur (PKI).^[1] Die meisten PKI-Softwarelösungen (insbesondere RA-Implementierungen) unterstützen es, einschließlich des Network Device Enrollment Service (NDES) von Active Directory Certificate Services und Intune.^[2]

• Ältere Versionen von SCEP, die in der überwiegenden Mehrheit der Implementierungen noch verwendet werden, sind auf die Anforderung von Zertifikaten für RSA-Schlüssel beschränkt.
• Aufgrund der Verwendung des selbstsignierten PKCS#10-Formats für Zertifikatsanfragen (CSR) können Zertifikate nur für Schlüssel angefordert werden, die (in gewisser Form) die Signierung unterstützen. Eine Einschränkung, die auch bei anderen auf PKCS#10-CSRs basierenden Anforderungsprotokollen besteht, z. B. EST und ACME oder auch im webbasierten Anforderungs-Workflow der meisten PKI-Softwarelösungen, bei denen der Antragsteller mit der Erstellung eines Schlüsselpaares und eines CSRs im PKCS#10-Format beginnt. Beispielsweise stellt ACME, das ebenfalls PKCS#10 verwendet, TLS-Zertifikate aus, die per Definition für die Signierung im TLS-Handshake in der Lage sein müssen. Diese Unterscheidung ist jedoch bisher meist theoretisch, da in der Praxis alle Algorithmen, die üblicherweise mit Zertifikaten verwendet werden, die Signierung unterstützen. Dies könnte sich mit der Post-Quanten-Kryptografie ändern, bei der einige Schlüssel nur KEM unterstützen. Das CRMF-Format, das vom Certificate Management Protocol (CMP) und CMS verwendet wird, ist hier flexibler und unterstützt auch Schlüssel, die nur für die Verschlüsselung verwendet werden können.
• Obwohl der Nachweis der Herkunft von Zertifikatsanträgen, d. h. die Authentifizierung des Zertifikatsantragstellers, die wichtigste Sicherheitsanforderung ist, wird seine Unterstützung aus pragmatischen Gründen innerhalb von SCEP nicht streng vorgeschrieben. Die clientseitige Authentifizierung mittels Signatur unter Verwendung eines bereits vorhandenen Zertifikats wäre der bevorzugte Mechanismus, ist jedoch in vielen Anwendungsfällen nicht möglich oder wird von den entsprechenden Implementierungen nicht unterstützt. Alternativ bietet SCEP lediglich die Verwendung eines gemeinsamen Geheimnisses, das spezifisch für den Client und nur einmal verwendet werden sollte.
• Die Vertraulichkeit des gemeinsam genutzten Geheimnisses, das optional zur Quellenauthentifizierung verwendet wird, ist fragil, da es im 'challengePassword'-Feld des CSRs enthalten sein muss, das dann durch eine äußere Verschlüsselung geschützt wird. Es wäre sicherer gewesen, einen auf Passwörtern basierenden MAC-Algorithmus wie HMAC zu verwenden.
• Die Verschlüsselung der gesamten PKCS#10-Struktur zum Schutz des 'challengePassword'-Feldes (das für die selbstenthaltene Quellenauthentifizierung verwendet wird) hat einen weiteren Nachteil: Der gesamte CSR wird für alle Parteien außer dem beabsichtigten endgültigen Empfänger (dem CA) unlesbar, obwohl die meisten seiner Inhalte nicht vertraulich sind. Die PKCS#10-Struktur kann daher von Zwischenstellen wie einer RA nicht überprüft werden.

SCEP wurde von Verisign für Cisco^[3] als schlanke Alternative zu Certificate Management over CMS (CMC) und dem sehr leistungsstarken, aber auch eher sperrigen Certificate Management Protocol (CMP) entwickelt. Es erhielt frühzeitig Unterstützung von Microsoft mit seiner kontinuierlichen Integration in Windows, beginnend mit Windows 2000.^[4] Um 2010 stellte Cisco die Arbeit an SCEP ein und entwickelte stattdessen EST. Im Jahr 2015 nahm Peter Gutmann den Internet-Draft aufgrund der weiten Verbreitung von SCEP in der Industrie und in anderen Standards wieder auf.^[5] Er aktualisierte den Entwurf mit moderneren Algorithmen und behob zahlreiche Probleme in der ursprünglichen Spezifikation. Im September 2020 wurde der Entwurf als informative IETF RFC 8894 veröffentlicht, mehr als zwanzig Jahre nach Beginn des Standardisierungsprozesses.^[6] Die neue Version unterstützt auch die Anforderung von Nicht-RSA-Zertifikaten (z. B. für ECC-Schlüssel).

• Präsentation zur Beschreibung von SCEP: pkix-3.pdf

1. ↑ SCEP | Device Management Profile. In: developer.apple.com (english)
2. ↑ Configure infrastructure to support SCEP with Intune. In: mirosoft.com, 2023 (english)
3. ↑ SCEP: The Simple Certificate Enrollment Protocol. (first draft). In: ietf.org, Januar 2000 (englisch)
4. ↑ Nick Sirikulbut: SCEP and NDES, A Brief History. In: pkisolutions.com, 9. September 2022. (englisch)
5. ↑ Simple Certificate Enrollment Protocol - draft-gutmann-scep-00. In: ietf.org, 2. April 2015. (englisch)
6. ↑ Simple Certificate Enrollment Protocol | RFC 8894. In: ietf.org, 20. Januar 2022. (englisch)