9. Securing CoAP (Sicherung von CoAP)
Dieser Abschnitt definiert die DTLS-Bindung für CoAP.
Während der Bereitstellungsphase wird einem CoAP-Gerät die Sicherheitsinformationen bereitgestellt, die es für den Betrieb benötigt, einschließlich Schlüsselmaterialien und Zugriffskontrolllisten. Diese Spezifikation definiert die Konfiguration für den RawPublicKey-Modus in Abschnitt 9.1.3.2.1. Am Ende der Bereitstellungsphase befindet sich das Gerät in einem der vier Sicherheitsmodi und verfügt über die Informationen für diesen Modus, wie unten beschrieben. Die Modi NoSec und RawPublicKey sind für diese Spezifikation obligatorisch zu implementieren.
NoSec: Es gibt keine Sicherheit auf Protokollebene (DTLS ist deaktiviert). Alternative Techniken zur Bereitstellung von Sicherheit auf niedrigerer Ebene SOLLTEN bei Bedarf verwendet werden. Die Verwendung von IPsec wird in [IPsec-CoAP] diskutiert. Bestimmte Link-Layer, die mit eingeschränkten Knoten verwendet werden, bieten auch Link-Layer-Sicherheit, die bei ordnungsgemäßem Schlüsselmanagement geeignet sein kann.
PreSharedKey: DTLS ist aktiviert, es gibt eine Liste von vorinstallierten Schlüsseln [RFC4279], und jeder Schlüssel enthält eine Liste der Knoten, mit denen er zur Kommunikation verwendet werden kann, wie in Abschnitt 9.1.3.1 beschrieben. Im Extremfall kann es einen Schlüssel für jeden Knoten geben, mit dem dieser CoAP-Knoten kommunizieren muss (1:1 Knoten/Schlüssel-Verhältnis). Umgekehrt, wenn mehr als zwei Entitäten einen bestimmten vorinstallierten Schlüssel teilen, ermöglicht dieser Schlüssel den Entitäten nur, sich als Mitglied dieser Gruppe zu authentifizieren, nicht als bestimmter Peer.
RawPublicKey: DTLS ist aktiviert und das Gerät verfügt über ein asymmetrisches Schlüsselpaar ohne Zertifikat (ein roher öffentlicher Schlüssel), das mit einem Out-of-Band-Mechanismus [RFC7250] validiert wird, wie in Abschnitt 9.1.3.2 beschrieben. Das Gerät verfügt auch über eine aus dem öffentlichen Schlüssel berechnete Identität und eine Liste von Identitäten der Knoten, mit denen es kommunizieren kann.
Certificate: DTLS ist aktiviert und das Gerät verfügt über ein asymmetrisches Schlüsselpaar mit einem X.509-Zertifikat [RFC5280], das es an sein Subjekt bindet und von einer gemeinsamen Vertrauenswurzel signiert ist, wie in Abschnitt 9.1.3.3 beschrieben. Das Gerät verfügt auch über eine Liste von Vertrauensankern, die zur Validierung eines Zertifikats verwendet werden können.
Im "NoSec"-Modus sendet das System die Pakete einfach über normales UDP über IP. Dies wird durch das "coap"-Schema und den CoAP-Standardport angezeigt. Das System ist nur dadurch gesichert, dass Angreifer daran gehindert werden, Pakete vom Netzwerk mit den CoAP-Knoten senden oder empfangen zu können; siehe Abschnitt 11.5 für zusätzliche Komplexitäten bei diesem Ansatz.
Die anderen drei Sicherheitsmodi verwenden DTLS und werden durch das "coaps"-Schema und den DTLS-gesicherten CoAP-Standardport angezeigt. Das Ergebnis ist eine Sicherheitsassoziation, die für die Authentifizierung (innerhalb der Grenzen des Sicherheitsmodells) verwendet werden kann und basierend auf dieser Authentifizierung den Kommunikationspartner autorisieren kann. CoAP selbst bietet keine Protokollprimitive für Authentifizierung oder Autorisierung; wo dies erforderlich ist, kann es durch Kommunikationssicherheit (d.h. IPsec oder DTLS) oder Objektsicherheit (innerhalb der Nutzlast) bereitgestellt werden. Geräte, die für einige Operationen eine Autorisierung benötigen, werden voraussichtlich eine dieser beiden Formen der Sicherheit benötigen. Notwendigerweise funktioniert die Kommunikationssicherheit bei Verwendung mit einem Proxy nur, wenn dieser Proxy Teil der Vertrauensbeziehungen ist. CoAP bietet keine Möglichkeit, verschiedene Autorisierungsebenen, die Clients mit einem Intermediär haben können, an weitere Intermediäre oder Ursprungsserver weiterzuleiten -- dies ist ein Problem, das mit HTTP geteilt wird, wo es üblich ist, dass der erste Intermediär alle Autorisierungen durchführt.
9.1. DTLS-Secured CoAP (DTLS-gesichertes CoAP)
So wie HTTP mit Transport Layer Security (TLS) über TCP gesichert wird, wird CoAP mit Datagram TLS (DTLS) [RFC6347] über UDP gesichert (siehe Abbildung 13). Dieser Abschnitt definiert die CoAP-Bindung an DTLS zusammen mit den minimalen obligatorisch zu implementierenden Konfigurationen, die für eingeschränkte Umgebungen geeignet sind. Die Bindung wird durch eine Reihe von Deltas zu Unicast-CoAP definiert. Tatsächlich ist DTLS TLS mit zusätzlichen Funktionen, um mit der unzuverlässigen Natur des UDP-Transports umzugehen.
+----------------------+
| Application |
+----------------------+
+----------------------+
| Requests/Responses |
|----------------------| CoAP
| Messages |
+----------------------+
+----------------------+
| DTLS |
+----------------------+
+----------------------+
| UDP |
+----------------------+
Abbildung 13: Abstrakte Schichtung von DTLS-gesichertem CoAP
In einigen eingeschränkten Knoten (begrenzter Flash und/oder RAM) und Netzwerken (begrenzte Bandbreite oder hohe Skalierbarkeitsanforderungen) und abhängig von der verwendeten spezifischen Cipher Suite sind nicht alle Modi von DTLS anwendbar. Einige DTLS-Cipher-Suiten können erhebliche Implementierungskomplexität sowie einen anfänglichen Handshake-Overhead hinzufügen, der für die Einrichtung der Sicherheitsassoziation erforderlich ist. Sobald der anfängliche Handshake abgeschlossen ist, fügt DTLS einen begrenzten Overhead pro Datagramm von etwa 13 Bytes hinzu, ohne Initialisierungsvektor/Nonce (z.B. 8 Bytes für TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), Integritätsprüfwert (z.B. 8 Bytes für TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]) und von der Cipher Suite erfordertes Padding. Ob ein bestimmter Modus von DTLS für die Verwendung mit einer CoAP-basierten Anwendung anwendbar ist, sollte sorgfältig abgewogen werden, wobei die spezifische Cipher Suite, die anwendbar sein kann, ob Sitzungswartung sie mit Anwendungsflüssen kompatibel macht, und ob auf den eingeschränkten Knoten und für den zusätzlichen Netzwerk-Overhead ausreichende Ressourcen vorhanden sind, berücksichtigt werden sollten. (Für einige Modi der Verwendung von DTLS identifiziert diese Spezifikation obligatorisch zu implementierende Cipher-Suiten; dies ist eine Implementierungsanforderung, um die Interoperabilität in Fällen zu maximieren, in denen diese Cipher-Suiten tatsächlich geeignet sind. Die spezifische Sicherheitsrichtlinie einer Anwendung kann den tatsächlichen Satz von Cipher-Suiten bestimmen, die verwendet werden können.) DTLS ist nicht auf Gruppenschlüsselung (Multicast-Kommunikation) anwendbar; es kann jedoch eine Komponente eines zukünftigen Gruppenschlüsselverwaltungsprotokolls sein.
9.1.1. Endpoint Identity (Endpunkt-Identität)
Das "coaps"-Schema basiert auf dem "coap"-Schema, und die Sicherheitsüberlegungen in Abschnitt 11.1 von [RFC3986] gelten ebenfalls. Die durch das "coaps"-Schema bereitgestellte Sicherheit befindet sich auf der IP-Schicht (IPsec) oder der Transportschicht (DTLS); infolgedessen können Intermediäre "coaps"-Nachrichten öffnen und schließen, während sie dennoch in der Lage sind, die Korrektheit von Integritätsprüfungen auf Anwendungsschicht zu überprüfen. Dies ist von besonderer Bedeutung für HTTP/CoAP-Cross-Protocol-Proxys (siehe Abschnitt 10). Außerdem können Gruppenschlüssel verwendet werden, um Vertraulichkeit für Multicast-Kommunikationen bereitzustellen, können aber nicht zur Validierung der Herkunft verwendet werden (Abschnitt 11.3).
9.1.2. Security Modes (Sicherheitsmodi)
Die vier zu Beginn von Abschnitt 9 beschriebenen Sicherheitsmodi werden mit DTLS oder ohne Sicherheit auf CoAP-Protokollebene implementiert. Die Implementierungsanforderungen (obligatorisch zu implementieren usw.) finden sich in Abschnitt 9.1.6.
9.1.3. Pre-Shared Keys (Vorinstallierte Schlüssel)
9.1.3.1. PSK Mode (PSK-Modus)
DTLS unterstützt die Verwendung von vorinstallierten Schlüsseln (PSK). DTLS mit vorinstallierten Schlüsseln, wie in [RFC4279] beschrieben, ermöglicht Authentifizierung und Vertraulichkeit. Die in [RFC4279] spezifizierten PSK-Modi werden von DTLS-fähigen CoAP-Knoten unterstützt, die diesen Modus implementieren.
TLS_PSK_WITH_AES_128_CCM_8, wie für die Verwendung in CoAP in [RFC7251] profiliert, ist die obligatorisch zu implementierende Cipher Suite für CoAP-Knoten, die diesen Modus implementieren.
Einige Bereitstellungen müssen möglicherweise Zertifikate, rohe öffentliche Schlüssel oder andere Authentifizierungsmethoden anstelle von PSK verwenden. Wenn eine CoAP-Implementierung in der breitesten Palette von Bereitstellungen nützlich sein möchte, sollte sie alle vier definierten Sicherheitsmodi unterstützen.
9.1.3.2. RawPublicKey Mode (RawPublicKey-Modus)
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, wie in [RFC7251] profiliert, ist die obligatorisch zu implementierende Cipher Suite für CoAP-Knoten, die diesen Modus implementieren. Implementierungen in diesem Modus MÜSSEN [RFC7250] verwenden, um rohe öffentliche Schlüssel zu senden und zu empfangen.
9.1.3.2.1. Provisioning (Bereitstellung)
Der RawPublicKey-Modus benötigt eine angemessene Bereitstellung von Geräteschlüsselmaterial (asymmetrische Schlüssel, Vertrauensanker-Material).
Eine Implementierung kann wählen, das Schlüsselmaterial auf Out-of-Band-Weise zu bestimmen, über die sogenannte implizite Bereitstellung.
Alternativ kann eine Implementierung zusätzlich zur impliziten Bereitstellung die Verwendung von In-Band-Bereitstellungsprotokollen basierend auf dem rohen öffentlichen Schlüssel unterstützen. Beachten Sie, dass ein vollständiges In-Band-Bereitstellungsprotokoll nur auf einem Bootstrapping-Protokoll aufgebaut werden kann.
9.1.3.3. Certificate Mode (Zertifikatsmodus)
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, wie in [RFC7251] profiliert, ist die obligatorisch zu implementierende Cipher Suite für CoAP-Knoten, die diesen Modus implementieren. Implementierungen in diesem Modus MÜSSEN [RFC5280] unterstützen.
Zertifikate und die Struktur von Zertifikatsketten sind wie in [RFC5280] spezifiziert. Der URI-ID-Identifikatortyp aus Abschnitt 6.4.3 von [RFC6125] MUSS unterstützt werden.
9.1.4. Server Name Indication (Server-Namensanzeige)
Eingeschränkte Server haben oft keine Möglichkeit, leicht zu identifizieren, welcher URI (oder allgemeiner welcher Sicherheitskontext) für den Client von Interesse ist. Implementierungen können es besonders hilfreich finden, die Server Name Indication-Erweiterung zu DTLS/TLS [RFC6066] zu verwenden, um den Sicherheitskontext für die Verarbeitung der eingehenden Anfrage zu identifizieren.
9.1.5. New Associations (Neue Assoziationen)
Jeder Endpunkt wählt die verwendeten Sicherheitsparameter, einschließlich der Cipher Suite, gemäß den Anwendungs- und Systemanforderungen aus. Wenn ein Client eine neue Sitzung mit einem Server öffnet, fordert er an, dass diese Sitzung mit den vom Server erforderlichen Sicherheitsparametern verknüpft wird. Cipher-Suiten, die obligatorisch zu implementieren sind, sind in den Abschnitten für jeden Modus des DTLS-Betriebs definiert (Abschnitte 9.1.3.1, 9.1.3.2 und 9.1.3.3). Diese MTI-Cipher-Suiten sind möglicherweise nicht die richtige Wahl für jede Anwendung oder Bereitstellung: Es ist möglich, sie zu deaktivieren und verschiedene Cipher-Suiten zu verwenden, die möglicherweise geeigneter sind.
9.1.6. DTLS Version (DTLS-Version)
Implementierungen im Modus "PreSharedKey", "RawPublicKey" und "Certificate" MÜSSEN DTLS Version 1.2 [RFC6347] unterstützen und SOLLTEN es bevorzugen. Wenn eine Implementierung erkennt, dass eine Peer-Implementierung nur DTLS Version 1.0 unterstützt, KANN sie DTLS 1.0 für Interoperabilität verwenden. DTLS 1.0 SOLLTE NICHT mit DTLS-gesicherter Gruppenkommunikation verwendet werden.
9.1.7. DTLS Connection Management (DTLS-Verbindungsverwaltung)
Solange der DTLS-Handshake nicht abgeschlossen ist, SOLLTE ein Knoten warten, bis der Handshake abgeschlossen ist, bevor er eine Anfrage sendet. Wenn jedoch der Handshake fehlschlägt, sollte der Sicherheits-Handshake als fehlgeschlagen betrachtet werden. Einige weitere Details zur Verbindungsverwaltung werden hier benötigt, aber dies wird für eine spätere Version der Spezifikation aufgeschoben.