5. Writing Security Considerations Sections (Rédaction des sections considérations de sécurité)
5. Writing Security Considerations Sections (Rédaction des sections considérations de sécurité)
Bien qu'il ne soit pas exigé qu'un protocole ou système donné soit immunisé contre toutes les formes d'attaque, il est nécessaire que les auteurs envisagent autant de formes que possible. Une partie du rôle de la section Security Considerations est d'expliquer quelles attaques sont hors champ et quelles contre-mesures peuvent être appliquées pour s'en défendre. De plus, il DOIT y avoir une description claire des types de menaces sur le protocole ou la technologie décrite. Cela DOIT être abordé comme un effort de « due diligence » pour décrire tous les risques et menaces connus ou prévisibles aux implémenteurs et utilisateurs potentiels.
Les auteurs DOIVENT décrire :
- quelles attaques sont hors champ (et pourquoi !)
- quelles attaques sont dans le champ
- 2.1 et auxquelles le protocole est susceptible
- 2.2 et contre lesquelles le protocole protège
Les formes d'attaque suivantes DOIVENT au minimum être envisagées : écoute clandestine, rejeu, insertion, suppression, modification de messages, et attaque de l'homme du milieu. Les attaques par déni de service potentielles DOIVENT également être identifiées. Si le protocole incorpore des mécanismes de protection cryptographique, il convient d'indiquer clairement quelles portions des données sont protégées et quelles sont les protections (c.-à-d. intégrité seule, confidentialité, et/ou authentification des extrémités, etc.). Une indication DOIT aussi être donnée sur les types d'attaques auxquels la protection cryptographique est susceptible. Les données qui DOIVENT rester secrètes (matériel de clé, graines aléatoires, etc.) DOIVENT être clairement étiquetées.
Si la technologie implique l'authentification, en particulier l'authentification utilisateur-hôte, la sécurité de la méthode d'authentification DOIT être clairement spécifiée. C'est-à-dire que les auteurs DOIVENT documenter les hypothèses sur lesquelles repose la sécurité de cette méthode d'authentification. Par exemple, dans le cas de la méthode de connexion UNIX nom d'utilisateur/mot de passe, une déclaration du type :
L'authentification dans le système n'est sécurisée que dans la mesure où il est difficile de deviner ou d'obtenir un mot de passe ASCII d'au plus 8 caractères. Ces mots de passe peuvent être obtenus en écoutant des sessions telnet ou en exécutant le programme « crack » avec le contenu du fichier /etc/passwd. Les tentatives de protection contre la devination en ligne du mot de passe en (1) déconnectant après plusieurs tentatives de connexion infructueuses et (2) en attendant entre des invites de mot de passe successives ne sont efficaces que dans la mesure où les attaquants sont impatients.
Parce que le fichier /etc/passwd associe les noms d'utilisateur aux identifiants utilisateur, groupes, etc., il DOIT être lisible par tous. Afin de permettre cet usage tout en rendant l'exécution de crack plus difficile, le fichier est souvent divisé en /etc/passwd et un fichier de mots de passe « shadow ». Le fichier shadow n'est pas lisible par tous et contient le mot de passe chiffré. Le fichier /etc/passwd ordinaire contient un mot de passe factice à sa place.
Il ne suffit pas de déclarer simplement que le protocole DOIT être exécuté sur un protocole de sécurité de couche inférieure. Si un système repose sur des services de sécurité de couche inférieure pour la sécurité, les protections que ces services sont censés fournir DOIVENT être clairement spécifiées. De plus, les propriétés résultantes du système combiné DOIVENT être spécifiées.
Note : En général, l'IESG n'approuvera pas les protocoles sur la voie des standards qui ne prévoient pas d'authentification forte, soit interne au protocole, soit par liaison étroite à un protocole de sécurité de couche inférieure.
L'environnement de menace traité par la section Security Considerations DOIT au minimum inclure le déploiement sur l'Internet mondial à travers plusieurs frontières administratives sans supposer que des pare-feu sont en place, ne serait-ce que pour fournir une justification du fait qu'une telle considération est hors champ pour le protocole. Il n'est pas acceptable de ne discuter que des menaces applicables aux LAN et d'ignorer l'environnement de menace plus large. Tous les protocoles sur la voie des standards de l'IETF sont considérés comme susceptibles d'être déployés sur l'Internet mondial. Dans certains cas, il peut y avoir une Applicability Statement décourageant l'utilisation d'une technologie ou d'un protocole dans un environnement particulier. Néanmoins, les problèmes de sécurité d'un déploiement plus large DOIVENT être discutés dans le document.
Il DOIT y avoir une description claire du risque résiduel pour l'utilisateur ou l'opérateur de ce protocole après le déploiement de l'atténuation des menaces. De tels risques peuvent provenir d'un compromis dans un protocole connexe (par ex. IPsec est inutile si la gestion des clés a été compromise), d'une implémentation incorrecte, du compromis de la technologie de sécurité utilisée pour réduire le risque (par ex. un chiffrement avec une clé de 40 bits), ou il peut y avoir des risques non traités par la spécification du protocole (par ex. attaques par déni de service sur un protocole de liaison sous-jacent). Un soin particulier DOIT être pris lorsque le compromis d'un seul système compromettrait un protocole entier. Par exemple, en général les concepteurs de protocoles supposent que les systèmes terminaux sont inviolés et ne se soucient pas de l'attaque physique. Cependant, dans les cas (tels qu'une autorité de certification) où le compromis d'un seul système pourrait conduire à des compromis généralisés, il convient d'envisager la sécurité des systèmes et physique.
Il DOIT aussi y avoir une discussion des risques de sécurité potentiels découlant de mauvaises applications possibles du protocole ou de la technologie décrite dans le RFC. Cela peut être couplé avec une Applicability Statement pour ce RFC.