9. Securing CoAP (Sécurisation de CoAP)
Cette section définit la liaison DTLS pour CoAP.
Pendant la phase de provisionnement, un appareil CoAP reçoit les informations de sécurité dont il a besoin pour fonctionner, y compris les matériaux de clé et les listes de contrôle d'accès. Cette spécification définit la configuration pour le mode RawPublicKey dans la Section 9.1.3.2.1. À la fin de la phase de provisionnement, l'appareil sera dans l'un des quatre modes de sécurité et aura les informations pour ce mode comme décrit ci-dessous. Les modes NoSec et RawPublicKey sont obligatoires à implémenter pour cette spécification.
NoSec: Il n'y a pas de sécurité au niveau du protocole (DTLS est désactivé). Des techniques alternatives pour fournir une sécurité de couche inférieure DEVRAIENT être utilisées lorsque cela est approprié. L'utilisation d'IPsec est discutée dans [IPsec-CoAP]. Certaines couches de liaison utilisées avec des nœuds contraints fournissent également une sécurité de couche de liaison, qui peut être appropriée avec une gestion de clés appropriée.
PreSharedKey: DTLS est activé, il existe une liste de clés pré-partagées [RFC4279], et chaque clé inclut une liste des nœuds avec lesquels elle peut être utilisée pour communiquer comme décrit dans la Section 9.1.3.1. À l'extrême, il peut y avoir une clé pour chaque nœud avec lequel ce nœud CoAP doit communiquer (rapport nœud/clé 1:1). Inversement, si plus de deux entités partagent une clé pré-partagée spécifique, cette clé permet uniquement aux entités de s'authentifier en tant que membre de ce groupe et non en tant que pair spécifique.
RawPublicKey: DTLS est activé et l'appareil possède une paire de clés asymétriques sans certificat (une clé publique brute) qui est validée à l'aide d'un mécanisme hors bande [RFC7250] comme décrit dans la Section 9.1.3.2. L'appareil possède également une identité calculée à partir de la clé publique et une liste d'identités des nœuds avec lesquels il peut communiquer.
Certificate: DTLS est activé et l'appareil possède une paire de clés asymétriques avec un certificat X.509 [RFC5280] qui le lie à son sujet et est signé par une racine de confiance commune comme décrit dans la Section 9.1.3.3. L'appareil possède également une liste d'ancres de confiance racine qui peuvent être utilisées pour valider un certificat.
En mode "NoSec", le système envoie simplement les paquets sur UDP normal sur IP. Ceci est indiqué par le schéma "coap" et le port par défaut CoAP. Le système est sécurisé uniquement en empêchant les attaquants d'être capables d'envoyer ou de recevoir des paquets depuis le réseau avec les nœuds CoAP; voir la Section 11.5 pour des complexités supplémentaires dans cette approche.
Les trois autres modes de sécurité utilisent DTLS et sont indiqués par le schéma "coaps" et le port par défaut CoAP sécurisé par DTLS. Le résultat est une association de sécurité qui peut être utilisée pour l'authentification (dans les limites du modèle de sécurité) et, sur la base de cette authentification, autoriser le partenaire de communication. CoAP lui-même ne fournit pas de primitives de protocole pour l'authentification ou l'autorisation; lorsque cela est requis, il peut être fourni par la sécurité de communication (c'est-à-dire IPsec ou DTLS) ou la sécurité d'objet (dans la charge utile). Les appareils qui nécessitent une autorisation pour certaines opérations sont censés nécessiter l'une de ces deux formes de sécurité. Nécessairement, lorsque la sécurité de communication est utilisée avec un proxy, cela ne fonctionne que lorsque ce proxy fait partie des relations de confiance. CoAP ne fournit pas de moyen de transférer différents niveaux d'autorisation que les clients peuvent avoir avec un intermédiaire vers d'autres intermédiaires ou serveurs d'origine -- c'est un problème partagé avec HTTP, où il est habituel que le premier intermédiaire effectue toute l'autorisation.
9.1. DTLS-Secured CoAP (CoAP Sécurisé par DTLS)
Tout comme HTTP est sécurisé en utilisant Transport Layer Security (TLS) sur TCP, CoAP est sécurisé en utilisant Datagram TLS (DTLS) [RFC6347] sur UDP (voir Figure 13). Cette section définit la liaison CoAP à DTLS, ainsi que les configurations minimales obligatoires à implémenter appropriées pour les environnements contraints. La liaison est définie par une série de deltas au CoAP unicast. En effet, DTLS est TLS avec des fonctionnalités supplémentaires pour traiter la nature non fiable du transport UDP.
+----------------------+
| Application |
+----------------------+
+----------------------+
| Requests/Responses |
|----------------------| CoAP
| Messages |
+----------------------+
+----------------------+
| DTLS |
+----------------------+
+----------------------+
| UDP |
+----------------------+
Figure 13: Couches Abstraites de CoAP Sécurisé par DTLS
Dans certains nœuds contraints (flash et/ou RAM limités) et réseaux (bande passante limitée ou exigences de scalabilité élevées), et selon la suite de chiffrement particulière utilisée, tous les modes de DTLS ne seront pas applicables. Certaines suites de chiffrement DTLS peuvent ajouter une complexité d'implémentation significative ainsi qu'un certain surcoût de handshake initial requis pour établir l'association de sécurité. Une fois le handshake initial terminé, DTLS ajoute un surcoût limité par datagramme d'environ 13 octets, sans compter tout vecteur d'initialisation/nonce (par exemple, 8 octets pour TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), valeur de vérification d'intégrité (par exemple, 8 octets pour TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), et rembourrage requis par la suite de chiffrement. La question de savoir si un mode donné de DTLS est applicable pour une utilisation avec une application basée sur CoAP doit être soigneusement pesée en considérant la suite de chiffrement spécifique qui peut être applicable, si la maintenance de session la rend compatible avec les flux d'application, et s'il y a suffisamment de ressources sur les nœuds contraints et pour le surcoût réseau ajouté. (Pour certains modes d'utilisation de DTLS, cette spécification identifie des suites de chiffrement obligatoires à implémenter; c'est une exigence d'implémentation pour maximiser l'interopérabilité dans les cas où ces suites de chiffrement sont effectivement appropriées. La politique de sécurité spécifique d'une application peut déterminer l'ensemble réel de suites de chiffrement qui peuvent être utilisées.) DTLS n'est pas applicable à la gestion de clés de groupe (communication multicast); cependant, il peut être un composant d'un futur protocole de gestion de clés de groupe.
9.1.1. Endpoint Identity (Identité du Point de Terminaison)
Le schéma "coaps" est basé sur le schéma "coap", et les considérations de sécurité dans la Section 11.1 de [RFC3986] s'appliquent également. La sécurité fournie par le schéma "coaps" est au niveau IP (IPsec) ou au niveau transport (DTLS); en conséquence, les intermédiaires peuvent ouvrir et fermer les messages "coaps", tout en étant capables de vérifier l'exactitude de toutes les vérifications d'intégrité de la couche application. Ceci est d'une importance particulière pour les proxys inter-protocoles HTTP/CoAP (voir Section 10). De plus, les clés de groupe peuvent être utilisées pour fournir la confidentialité pour les communications multicast, mais ne peuvent pas être utilisées pour valider l'origine (Section 11.3).
9.1.2. Security Modes (Modes de Sécurité)
Les quatre modes de sécurité décrits au début de la Section 9 sont implémentés en utilisant DTLS ou pas de sécurité au niveau du protocole CoAP. Les exigences d'implémentation (obligatoire à implémenter, etc.) peuvent être trouvées dans la Section 9.1.6.
9.1.3. Pre-Shared Keys (Clés Pré-Partagées)
9.1.3.1. PSK Mode (Mode PSK)
DTLS prend en charge l'utilisation de clés pré-partagées (PSK). DTLS avec des clés pré-partagées comme décrit dans [RFC4279] permet l'authentification et la confidentialité. Les modes PSK spécifiés dans [RFC4279] sont pris en charge par les nœuds CoAP compatibles DTLS qui implémentent ce mode.
TLS_PSK_WITH_AES_128_CCM_8, tel que profilé pour une utilisation dans CoAP dans [RFC7251], est la suite de chiffrement obligatoire à implémenter pour les nœuds CoAP qui implémentent ce mode.
Certains déploiements peuvent avoir besoin d'utiliser des certificats, des clés publiques brutes ou d'autres méthodes d'authentification au lieu de PSK. Si une implémentation CoAP veut être utile dans la gamme la plus large de déploiements, elle devrait prendre en charge les quatre modes de sécurité définis.
9.1.3.2. RawPublicKey Mode (Mode RawPublicKey)
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, tel que profilé dans [RFC7251], est la suite de chiffrement obligatoire à implémenter pour les nœuds CoAP qui implémentent ce mode. Les implémentations dans ce mode DOIVENT utiliser [RFC7250] pour envoyer et recevoir des clés publiques brutes.
9.1.3.2.1. Provisioning (Provisionnement)
Le mode RawPublicKey nécessite un provisionnement approprié du matériel de clé de l'appareil (clés asymétriques, matériel d'ancre de confiance).
Une implémentation peut choisir de déterminer le matériel de clé en utilisant une manière hors bande, via ce qu'on appelle le provisionnement implicite.
Alternativement, en plus du provisionnement implicite, une implémentation PEUT prendre en charge l'utilisation de protocoles de provisionnement en bande basés sur la clé publique brute. Notez qu'un protocole de provisionnement en bande complet ne peut être construit qu'au-dessus d'un protocole de bootstrap.
9.1.3.3. Certificate Mode (Mode Certificat)
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, tel que profilé dans [RFC7251], est la suite de chiffrement obligatoire à implémenter pour les nœuds CoAP qui implémentent ce mode. Les implémentations dans ce mode DOIVENT prendre en charge [RFC5280].
Les certificats, et la structure des chaînes de certificats, sont tels que spécifiés dans [RFC5280]. Le type d'identifiant URI-ID de la Section 6.4.3 de [RFC6125] DOIT être pris en charge.
9.1.4. Server Name Indication (Indication du Nom du Serveur)
Les serveurs contraints n'auront souvent pas de moyen d'identifier facilement quel URI (ou plus généralement quel contexte de sécurité) intéresse le client. Les implémentations peuvent trouver particulièrement utile d'utiliser l'extension Server Name Indication à DTLS/TLS [RFC6066] pour aider à identifier le contexte de sécurité pour traiter la requête entrante.
9.1.5. New Associations (Nouvelles Associations)
Chaque point de terminaison sélectionne les paramètres de sécurité utilisés, y compris la suite de chiffrement, conformément aux exigences de l'application et du système. Lorsqu'un client ouvre une nouvelle session avec un serveur, il demande que cette session soit associée aux paramètres de sécurité requis par le serveur. Les suites de chiffrement qui sont obligatoires à implémenter sont définies dans les sections pour chaque mode de fonctionnement DTLS (Sections 9.1.3.1, 9.1.3.2 et 9.1.3.3). Ces suites de chiffrement MTI peuvent ne pas être le bon choix pour chaque application ou déploiement: il est possible de les désactiver et d'utiliser différentes suites de chiffrement qui pourraient être plus appropriées.
9.1.6. DTLS Version (Version DTLS)
Les implémentations en mode "PreSharedKey", "RawPublicKey" et "Certificate" DOIVENT prendre en charge et DEVRAIENT préférer utiliser DTLS version 1.2 [RFC6347]. Si une implémentation détecte qu'une implémentation pair n'est capable que de DTLS version 1.0, elle PEUT utiliser DTLS 1.0 pour l'interopérabilité. DTLS 1.0 NE DEVRAIT PAS être utilisé avec la communication de groupe sécurisée par DTLS.
9.1.7. DTLS Connection Management (Gestion de Connexion DTLS)
Tant que le handshake DTLS n'est pas terminé, un nœud DEVRAIT attendre que le handshake soit terminé avant d'envoyer une requête. Cependant, si le handshake échoue, le handshake de sécurité devrait être considéré comme ayant échoué. Certains détails supplémentaires sur la gestion de connexion sont nécessaires ici, mais ceci est reporté pour une version ultérieure de la spécification.