4. Common Issues (Questions courantes)

Bien que les exigences de sécurité de chaque système soient uniques, certaines exigences communes apparaissent dans de nombreux protocoles. Souvent, lorsque des concepteurs de protocoles naïfs sont confrontés à ces exigences, ils choisissent une solution évidente mais non sécurisée alors que de meilleures solutions existent. Cette section décrit un certain nombre de problèmes observés dans de nombreux protocoles et les éléments courants de technologie de sécurité qui peuvent être utiles pour y répondre.

4.1. User Authentication

En pratique, tout système qui souhaite contrôler l'accès à ses ressources a besoin d'un moyen d'authentifier les utilisateurs. Un nombre presque incalculable de tels mécanismes a été conçu à cette fin. Les sections suivantes décrivent certaines de ces techniques.

4.1.1. Username/Password

Le mécanisme de contrôle d'accès le plus courant est le simple USERNAME/PASSWORD. L'utilisateur fournit un nom d'utilisateur et un mot de passe réutilisable à l'hôte qu'il souhaite utiliser. Ce système est vulnérable à une attaque passive simple où l'attaquant renifle le mot de passe sur le fil puis initie une nouvelle session en présentant le mot de passe. Cette menace peut être atténuée en hébergeant le protocole sur une connexion chiffrée telle que TLS ou IPSEC. Les systèmes nom d'utilisateur/mot de passe non protégés (en clair) ne sont pas acceptables dans les normes IETF.

4.1.2. Challenge Response and One Time Passwords

Les systèmes qui souhaitent une sécurité supérieure à USERNAME/PASSWORD emploient souvent soit un schéma ONE TIME PASSWORD [OTP], soit un CHALLENGE-RESPONSE. Dans un schéma à mot de passe à usage unique, l'utilisateur reçoit une liste de mots de passe à utiliser en séquence, un seul usage chacun. (Souvent ces mots de passe sont générés à partir d'une clé secrète afin que l'utilisateur puisse simplement calculer le mot de passe suivant dans la séquence.) SecureID et DES Gold sont des variantes de ce schéma. Dans un schéma défi-réponse, l'hôte et l'utilisateur partagent un secret (souvent représenté comme un mot de passe). Pour authentifier l'utilisateur, l'hôte lui présente un défi (généré aléatoirement). L'utilisateur calcule une fonction basée sur le défi et le secret et la fournit à l'hôte, qui la vérifie. Souvent ce calcul est effectué dans un dispositif portable, tel qu'une carte DES Gold.

Les deux types de schéma protègent contre la reprise, mais restent souvent vulnérables à une OFFLINE KEYSEARCH ATTACK (forme d'attaque passive) : comme indiqué, le mot de passe à usage unique ou la réponse est souvent calculé à partir d'un secret partagé. Si l'attaquant connaît la fonction utilisée, il peut essayer tous les secrets partagés possibles jusqu'à trouver celui qui produit la bonne sortie. C'est plus facile si le secret partagé est un mot de passe, auquel cas il peut mener une DICTIONARY ATTACK : il essaie une liste de mots (ou chaînes) courants plutôt que des chaînes purement aléatoires.

Ces systèmes sont aussi souvent vulnérables à une attaque active. À moins que la sécurité des communications ne soit assurée pour toute la session, l'attaquant peut attendre que l'authentification soit effectuée puis détourner la connexion.

4.1.3. Shared Keys

Les systèmes de type CHALLENGE-RESPONSE peuvent être rendus sûrs contre l'attaque par dictionnaire en utilisant des clés partagées générées aléatoirement au lieu de mots de passe générés par l'utilisateur. Si les clés sont suffisamment grandes, les attaques par recherche de clé deviennent impraticables. Cette approche fonctionne le mieux lorsque les clés sont configurées dans les nœuds terminaux plutôt que mémorisées et saisies par les utilisateurs, car ces derniers ont du mal à retenir des clés suffisamment longues.

Comme les systèmes basés sur mot de passe, les systèmes à clé partagée souffrent de problèmes de gestion. Chaque paire de parties communicantes doit avoir sa propre clé convenue, ce qui conduit à un très grand nombre de clés.

4.1.4. Key Distribution Centers

Une approche pour résoudre le problème du grand nombre de clés consiste à utiliser une « tierce partie de confiance » en ligne qui médie entre les parties authentifiantes. La tierce partie de confiance (généralement appelée KEY DISTRIBUTION CENTER (KDC)) partage une clé symétrique ou un mot de passe avec chaque partie du système. Elle contacte d'abord le KDC qui lui donne un TICKET contenant une clé symétrique générée aléatoirement chiffrée sous les clés des deux pairs. Comme seuls les bons pairs peuvent déchiffrer la clé symétrique, le billet peut servir à établir une association de confiance. De loin le système KDC le plus populaire est Kerberos [KERBEROS].

4.1.5. Certificates

Une approche simple consiste à ce que tous les utilisateurs aient des CERTIFICATES [PKIX] qu'ils utilisent ensuite pour s'authentifier de manière spécifique au protocole, comme dans [TLS] ou [S/MIME]. Un certificat est une preuve signée liant l'identité d'une entité à sa clé publique. Le signataire d'un certificat est une CERTIFICATE AUTHORITY (CA), dont le certificat peut lui-même être signé par une CA supérieure. Pour que ce système fonctionne, la confiance en une ou plusieurs CA doit être établie hors bande. De telles CA sont appelées TRUSTED ROOTS ou ROOT CAS. Le principal obstacle à cette approche dans les systèmes client-serveur est qu'elle exige que les clients aient des certificats, ce qui peut poser un problème de déploiement.

4.1.6. Some Uncommon Systems

Il existe des moyens de faire mieux que les schémas mentionnés ci-dessus, mais ils n'ajoutent typiquement pas beaucoup de sécurité à moins que la sécurité des communications (au moins l'intégrité des messages) ne soit employée pour sécuriser la connexion, car sinon l'attaquant peut simplement détourner la connexion après l'authentification. Plusieurs protocoles ([EKE], [SPEKE], [SRP]) permettent d'amorcer de manière sûre le

mot de passe de l'utilisateur vers une clé partagée utilisable comme entrée d'un protocole cryptographique. Un obstacle majeur au déploiement de ces protocoles a été le statut de propriété intellectuelle extrêmement peu clair. De même, l'utilisateur peut s'authentifier à l'aide de certificats à clé publique (par ex. authentification client S-HTTP). Typiquement ces méthodes sont utilisées dans le cadre d'un protocole de sécurité plus complet.

4.1.7. Host Authentication

L'authentification d'hôte pose un problème particulier. Très souvent, les adresses des services sont présentées au moyen d'un nom d'hôte DNS, par exemple comme URL [URL]. Lorsqu'on demande un tel service, il faut s'assurer que l'entité avec laquelle on parle a non seulement un certificat, mais que ce certificat correspond à l'identité attendue du serveur. L'essentiel est d'avoir une liaison sûre entre le certificat et le nom d'hôte attendu.

Par exemple, il n'est généralement pas acceptable que le certificat contienne une identité sous forme d'adresse IP si la requête portait sur un nom d'hôte donné. Cela ne fournit pas de sécurité de bout en bout car l'association nom d'hôte-IP n'est pas sûre sans résolution de noms sécurisée [DNSSEC]. C'est un problème particulier lorsque le nom d'hôte est présenté à la couche application mais que l'authentification est effectuée à une couche inférieure.

4.2. Generic Security Frameworks

Fournir des fonctionnalités de sécurité dans un protocole peut être difficile. Outre le choix des mécanismes d'authentification et d'établissement de clé, il faut les intégrer au protocole. Une réponse à ce problème (incarnée dans IPsec et TLS) est de créer un protocole de sécurité de niveau inférieur puis d'exiger que les nouveaux protocoles s'exécutent sur ce protocole. Une autre approche récemment populaire est de concevoir des cadres de sécurité génériques au niveau application. L'idée est de concevoir un protocole permettant de négocier divers mécanismes de sécurité de façon modulaire. Les concepteurs de protocoles d'application arrangent alors le transport des PDU du protocole de sécurité dans leur protocole d'application. Des exemples de tels cadres incluent GSS-API [GSS] et SASL [SASL].

L'approche par cadre générique pose plusieurs problèmes. D'abord, elle est très sensible aux DOWNGRADE ATTACKS. Dans une attaque par rétrogradation, un attaquant actif altère la négociation pour forcer les parties à négocier une protection plus faible qu'elles ne le feraient autrement. On peut inclure un contrôle d'intégrité après la négociation et l'établissement de clé, mais la force de ce contrôle est nécessairement limitée au plus faible algorithme commun. Ce problème existe avec toute approche de négociation, mais

les cadres génériques l'aggravent en encourageant l'auteur du protocole d'application à ne spécifier que le cadre plutôt que de réfléchir aux mécanismes sous-jacents appropriés, d'autant que les mécanismes peuvent varier fortement en niveau de sécurité offert.

Un autre problème est qu'il n'est pas toujours évident comment les diverses fonctionnalités de sécurité du cadre interagissent avec le protocole de couche application. Par exemple, SASL peut servir uniquement de cadre d'authentification — l'échange SASL a lieu mais le reste de la connexion n'est pas protégé — mais peut aussi négocier la protection du trafic, par ex. via GSS, comme mécanisme. Savoir dans quels cas la protection du trafic est facultative et dans quels cas elle est requise exige de réfléchir au modèle de menace.

En général, les cadres d'authentification sont surtout utiles lorsque de nouveaux protocoles sont ajoutés à des systèmes disposant déjà d'authentification héritée. Un cadre permet aux nouvelles installations de fournir une meilleure authentification sans forcer les sites existants à refaire entièrement leur authentification héritée. Lorsque les exigences de sécurité d'un système sont clairement identifiées et que seules quelques formes d'authentification sont utilisées, le choix d'un mécanisme unique apporte plus de simplicité et de prévisibilité. Lorsqu'un cadre doit être utilisé, les concepteurs DEVRAIENT examiner attentivement les options du cadre et ne spécifier que les mécanismes adaptés à leur modèle de menace particulier. Si un cadre est nécessaire, les concepteurs DEVRAIENT choisir l'un des cadres établis plutôt que d'en concevoir un propre.

4.3. Non-repudiation

L'approche naïve de la non-répudiation consiste simplement à utiliser des signatures numériques à clé publique sur le contenu. La partie qui souhaite être liée (la SIGNING PARTY) signe numériquement le message en question. La contrepartie (la RELYING PARTY) peut ensuite invoquer la signature comme preuve que la partie signataire a à un moment accepté le message contesté. Malheureusement, cette approche est insuffisante.

Le moyen le plus facile pour la partie signataire de répudier le message est de prétendre que sa clé privée a été compromise et qu'un attaquant (pas nécessairement la partie dépendante) a signé le message contesté. Pour se défendre contre cette attaque, la partie dépendante doit montrer que la clé de la partie signataire n'était pas compromise au moment de la signature. Cela exige une infrastructure substantielle, incluant l'archivage des informations de révocation de certificats et des serveurs d'horodatage pour établir l'heure de la signature.

De plus, la partie dépendante peut tenter d'amener la partie signataire à signer un message en croyant en signer un autre. Ce problème est particulièrement grave lorsque la partie dépendante contrôle l'infrastructure utilisée par la partie signataire pour signer, comme dans les situations de kiosque. Dans beaucoup de ces cas la clé de la partie signataire est tenue sur une carte à puce mais le message à signer est affiché par la partie dépendante.

Toutes ces complications font de la non-répudiation un service difficile à déployer en pratique.

4.4. Authorization vs. Authentication

L'AUTHORIZATION est le processus par lequel on détermine si une partie authentifiée a la permission d'accéder à une ressource ou un service particulier. Bien qu'étroitement liées, il importe de réaliser que l'authentification et l'autorisation sont deux mécanismes distincts. Peut-être à cause de ce couplage étroit, on pense parfois à tort que l'authentification implique l'autorisation. L'authentification identifie simplement une partie ; l'autorisation définit si elle peut effectuer une certaine action.

L'autorisation repose nécessairement sur l'authentification, mais l'authentification seule n'implique pas l'autorisation. Avant d'accorder la permission d'une action, le mécanisme d'autorisation doit être consulté pour déterminer si cette action est permise.

4.4.1. Access Control Lists

Une forme courante de mécanisme d'autorisation est une liste de contrôle d'accès (ACL), qui énumère les utilisateurs autorisés à accéder à une ressource. Comme attribuer des permissions d'autorisation individuelles à chaque ressource est fastidieux, les ressources sont souvent organisées hiérarchiquement de sorte que l'ACL de la ressource parente soit héritée par les ressources enfants. Cela permet aux administrateurs de définir des politiques de haut niveau et de les surcharger si nécessaire.

4.4.2. Certificate Based Systems

Alors que la distinction entre authentification et autorisation est intuitive avec des mécanismes simples comme nom d'utilisateur et mot de passe (tout le monde comprend la différence entre compte administrateur et compte utilisateur), avec des mécanismes plus complexes la distinction se perd parfois.

Avec les certificats, par exemple, présenter une signature valide n'implique pas l'autorisation. La signature doit être étayée par une chaîne de certificats contenant une racine de confiance, et cette racine doit être

digne de confiance dans le contexte donné. Par exemple, les utilisateurs titulaires de certificats émis par l'Acme MIS CA peuvent avoir des privilèges d'accès Web différents de ceux titulaires de certificats émis par l'Acme Accounting CA, même si les deux CA sont « de confiance » pour le serveur Web Acme.

Les mécanismes pour imposer ces propriétés plus complexes n'ont pas encore été entièrement explorés. Une approche consiste simplement à attacher aux ACL des politiques décrivant quels types de certificats sont dignes de confiance. Une autre consiste à porter cette information avec le certificat, soit comme extension/attribut de certificat [PKIX, SPKI], soit comme « Attribute Certificate » séparé.

4.5. Providing Traffic Security

Les protocoles bien conçus devraient prévoir un mécanisme pour sécuriser (c'est-à-dire protéger en intégrité, authentifier et éventuellement chiffrer) tout le trafic sensible. Une approche consiste à sécuriser le protocole lui-même, comme dans [DNSSEC], [S/MIME] ou [S-HTTP]. Bien que cela fournisse une sécurité la mieux adaptée au protocole, cela exige aussi un effort considérable pour être correct.

De nombreux protocoles peuvent être suffisamment sécurisés à l'aide de l'un des systèmes de sécurité de canal disponibles. Nous examinons les deux plus courants, IPsec [AH, ESP] et [TLS].

4.5.1. IPsec

Les protocoles IPsec (en particulier AH et ESP) peuvent fournir la sécurité de transmission pour tout le trafic entre deux hôtes. IPsec prend en charge des granularités variables d'identification d'utilisateur, par exemple « sous-réseau IP », « adresse IP », « nom de domaine pleinement qualifié » et utilisateur individuel (« nom de boîte aux lettres »). Ces niveaux d'identification servent d'entrées aux dispositifs de contrôle d'accès qui font partie intégrante d'IPsec. Cependant, une implémentation IPsec donnée peut ne pas prendre en charge tous les types d'identité. En particulier, les passerelles de sécurité peuvent ne pas fournir d'authentification utilisateur-à-utilisateur ni de mécanismes pour fournir ces informations d'authentification aux applications.

Lorsque AH ou ESP est utilisé, le programmeur d'applications peut ne rien avoir à faire (si AH ou ESP est activé à l'échelle du système) ou devoir apporter des modifications logicielles spécifiques (par ex. ajouter des appels setsockopt() spécifiques) — selon l'implémentation AH ou ESP utilisée. Malheureusement, les API de contrôle des implémentations IPsec ne sont pas encore normalisées.

Le principal obstacle à l'utilisation d'IPsec pour sécuriser d'autres protocoles est le déploiement. L'usage majeur d'IPsec à présent est pour les applications VPN, surtout l'accès réseau distant. Sans coordination extrêmement étroite entre administrateurs de sécurité et développeurs d'applications, l'usage VPN convient mal à fournir des services de sécurité pour des applications individuelles, car il est difficile pour ces applications de déterminer quels services de sécurité ont en fait été fournis.

Le déploiement d'IPsec en environnement hôte-à-hôte a été lent. Contrairement aux systèmes de sécurité applicatifs tels que TLS, ajouter IPsec à un système non-IPsec implique généralement de modifier le système d'exploitation, soit le noyau soit en installant de nouveaux pilotes. C'est un effort nettement plus important que d'installer simplement une nouvelle application. Cependant, les versions récentes de nombreux systèmes d'exploitation grand public incluent des piles IPsec, ce qui facilite le déploiement.

Dans les environnements où IPsec est sûr d'être disponible, il représente une option viable pour protéger le trafic des communications applicatives. Si le trafic à protéger est UDP, IPsec et la sécurité d'objet spécifique à l'application sont les seules options. Cependant, les concepteurs NE DOIVENT PAS supposer qu'IPsec sera disponible. Une politique de sécurité pour un protocole de couche application générique NE DEVRAIT PAS simplement énoncer qu'IPsec doit être utilisé, sauf s'il existe une raison de croire qu'IPsec sera disponible dans l'environnement de déploiement visé. Dans les environnements où IPsec peut ne pas être disponible et le trafic est uniquement TCP, TLS est la méthode de choix, car le développeur d'application peut facilement garantir sa présence en incluant une implémentation TLS dans son paquetage.

Dans le cas particulier d'IPv6, AH et ESP sont obligatoires à implémenter. Il est donc raisonnable de supposer qu'AH/ESP sont déjà disponibles pour des protocoles ou déploiements IPv6 uniquement. Cependant, la gestion automatique des clés (IKE) n'est pas requise à implémenter, donc les concepteurs de protocoles NE DEVRAIENT pas supposer qu'elle sera présente. [USEIPSEC] fournit de nombreuses indications sur quand IPsec est un bon choix.

4.5.2. SSL/TLS

Actuellement, l'approche la plus courante est d'utiliser SSL ou son successeur TLS. Ils fournissent la sécurité de canal pour une connexion TCP au niveau application. C'est-à-dire qu'ils s'exécutent sur TCP. Les implémentations SSL fournissent typiquement une interface de type Berkeley Sockets pour faciliter la programmation. La question principale lors de la conception d'une solution de protocole autour de TLS est de distinguer les connexions protégées par TLS de celles qui ne le sont pas.

Les deux approches principales sont d'avoir un port bien connu séparé pour les connexions TLS (par ex. le port HTTP sur TLS est 443) [HTTPTLS] ou d'avoir un mécanisme de négociation ascendante du protocole de base vers TLS comme dans [UPGRADE] ou [STARTTLS]. Lorsqu'une stratégie de négociation ascendante est utilisée, il faut veiller à ce qu'un attaquant ne puisse pas forcer une connexion en clair lorsque les deux parties souhaitent utiliser TLS.

Notez que TLS dépend d'un protocole fiable tel que TCP ou SCTP. Cela pose deux difficultés notables. D'abord, il ne peut pas servir à sécuriser les protocoles à datagrammes utilisant UDP. Ensuite, TLS est sensible à des attaques de couche IP qu'IPsec ne l'est pas. Typiquement, ces attaques prennent la forme d'un déni de service ou d'une « assassination » de connexion. Par exemple, un attaquant peut forger un TCP RST pour fermer des connexions SSL. TLS a des mécanismes pour détecter les attaques par troncature mais ils permettent seulement à la victime de savoir qu'elle est attaquée et n'assurent pas la survie de la connexion face à de telles attaques. En revanche, si IPsec était utilisé, un tel RST forgé pourrait être rejeté sans affecter la connexion TCP. Si les RST forgés ou autres attaques similaires sur la connexion TCP sont une préoccupation, AH/ESP ou l'option TCP MD5 [TCPMD5] sont les choix préférés.

4.5.2.1. Virtual Hosts

Si l'approche « ports séparés » pour TLS est utilisée, TLS est négocié avant tout trafic de couche application. Cela peut poser problème aux protocoles utilisant des hôtes virtuels, tels que [HTTP], car le serveur ne sait pas quel certificat offrir au client pendant la poignée de main TLS. L'extension de nom d'hôte TLS [TLSEXT] peut servir à résoudre ce problème, bien qu'elle soit trop récente pour avoir connu un large déploiement.

4.5.2.2. Remote Authentication and TLS

Une difficulté avec TLS est que le serveur est authentifié via un certificat. Cela peut être gênant dans des environnements où auparavant la seule forme d'authentification était un mot de passe partagé entre client et serveur. Il est tentant d'utiliser TLS sans serveur authentifié (c'est-à-dire avec DH anonyme ou un certificat RSA auto-signé) puis de s'authentifier via un mécanisme défi-réponse tel que SASL avec CRAM-MD5.

Malheureusement, cette composition de SASL et TLS est moins forte qu'on ne l'attendrait. Il est facile pour un attaquant actif de détourner cette connexion. Le client place l'homme du milieu sur la connexion SSL (rappelez-vous que nous n'authentifions pas le serveur, ce qui empêche ordinairement cette attaque) puis relaie simplement la poignée de main SASL. Ensuite, c'est comme si la connexion était en

clair, du moins pour cet attaquant. Pour empêcher cette attaque, le client doit vérifier le certificat du serveur.

Cependant, si le serveur est authentifié, le défi-réponse devient moins souhaitable. Si vous avez déjà un canal renforcé, des mots de passe simples suffisent. En fait, ils sont sans doute supérieurs au défi-réponse car ils n'exigent pas que le mot de passe soit stocké en clair sur le serveur. Ainsi, la compromission du fichier de clés avec les systèmes défi-réponse est plus grave que si de simples mots de passe étaient utilisés.

Notez que si le client a un certificat, l'authentification client basée sur SSL peut être utilisée. Pour faciliter cela, SASL fournit le mécanisme EXTERNAL, par lequel le client SASL peut dire au serveur « examinez le canal externe pour mon identité ». Évidemment, cela n'est pas soumis aux attaques de superposition décrites ci-dessus.

Dans certains cas particuliers il peut valoir la peine de fournir la sécurité au niveau canal directement dans l'application plutôt qu'en utilisant IPSEC ou SSL/TLS. Un tel cas est la sécurité du terminal distant. Les caractères sont typiquement livrés du client au serveur un à la fois. Comme SSL/TLS et AH/ESP authentifient et chiffrent chaque paquet, cela peut signifier une expansion des données par un facteur 20. L'option de chiffrement telnet [ENCOPT] évite cette expansion en renonçant à l'intégrité des messages.

Lors de l'utilisation d'un service de terminal distant, on souhaite souvent effectuer en sécurité d'autres types de services de communication. Outre la connexion distante, SSH [SSH] fournit aussi le transfert de port sécurisé pour des ports TCP arbitraires, permettant aux utilisateurs d'exécuter des applications TCP arbitraires sur le canal SSH. Notez que le transfert de port SSH peut poser un problème de sécurité s'il est utilisé de manière inappropriée pour contourner un pare-feu et exposer indûment des applications internes non sécurisées au monde extérieur.

4.6. Denial of Service Attacks and Countermeasures

Les attaques par déni de service sont trop souvent considérées comme un fait de la vie. Un problème est qu'un attaquant peut souvent choisir parmi de nombreuses attaques par déni de service à infliger à une victime, et comme la plupart de ces attaques ne peuvent être contrées, le sens commun suppose souvent qu'il est inutile de se protéger contre un type d'attaque par déni de service lorsque beaucoup d'autres sont possibles mais ne peuvent être empêchées.

Cependant, toutes les attaques par déni de service ne sont pas équivalentes et, plus important encore, on peut concevoir des protocoles de sorte que les attaques par déni de service deviennent plus difficiles, sinon impraticables. Les récentes attaques SYN flood [TCPSYN] illustrent ces deux propriétés : les SYN flood sont si faciles, anonymes et efficaces qu'ils attirent plus les attaquants que d'autres attaques ; et parce que la conception de TCP permet cette attaque.

Comme une protection DoS complète est si difficile, la sécurité contre le DoS doit être traitée pragmatiquement. En particulier, certaines attaques qu'il serait souhaitable de contrer ne peuvent pas l'être économiquement. L'objectif devrait être de gérer le risque en se défendant contre les attaques dont le rapport gravité sur coût de la défense est suffisamment élevé. La gravité des attaques et le coût de la défense évoluent avec la technologie et donc aussi l'ensemble des attaques contre lesquelles il faut se défendre.

Les auteurs de normes Internet DOIVENT décrire à quelles attaques par déni de service leur protocole est susceptible. Cette description DOIT inclure les raisons pour lesquelles il était déraisonnable ou hors champ de tenter d'éviter ces attaques par déni de service.

Les attaques par déni de service BLIND sont particulièrement pernicieuses. Dans une attaque aveugle l'attaquant a un avantage significatif. Si l'attaquant doit pouvoir recevoir du trafic de la victime, il doit soit subvertir le tissu de routage soit utiliser sa propre adresse IP. L'une ou l'autre donne à la victime une chance de tracer l'attaquant et/ou filtrer son trafic. Dans une attaque aveugle l'attaquant peut utiliser des adresses IP forgées, rendant extrêmement difficile pour la victime de filtrer ses paquets. L'attaque SYN flood TCP est un exemple d'attaque aveugle. Les concepteurs devraient tout tenter pour empêcher les attaques par déni de service aveugles.

4.6.2. Distributed Denial of Service

Encore plus dangereuses sont les attaques par déni de service DISTRIBUÉES (DDoS) [DDOS]. Dans un DDoS l'attaquant organise pour qu'un nombre de machines attaquent la cible simultanément. Habituellement cela se fait en infectant un grand nombre de machines d'un programme permettant l'initiation à distance d'attaques. Les machines qui effectuent réellement l'attaque sont appelées ZOMBIEs et appartiennent probablement à des tiers qui ne se doutent de rien, à un endroit tout à fait différent du vrai attaquant. Les attaques DDoS peuvent être très difficiles à contrer car les zombies semblent souvent faire des requêtes de protocole légitimes et

simplement évincent les vrais utilisateurs. Les attaques DDoS peuvent être difficiles à contrer, mais on attend des concepteurs de protocoles qu'ils tiennent compte de ces formes d'attaque lors de la conception.

4.6.3. Avoiding Denial of Service

Il existe deux approches courantes pour rendre les attaques par déni de service plus difficiles :

4.6.3.1. Make your attacker do more work than you do

Si un attaquant consomme plus de ses ressources que des vôtres en lançant une attaque, les attaquants moins dotés en ressources que vous ne pourront pas lancer d'attaques efficaces. Une technique courante est d'exiger que l'attaquant effectue une opération coûteuse en temps, telle qu'une opération cryptographique. Notez qu'un attaquant peut encore monter une attaque par déni de service s'il peut rassembler une puissance CPU largement suffisante. Par exemple, cette technique n'empêcherait pas les attaques distribuées décrites dans [TCPSYN].

4.6.3.2. Make your attacker prove they can receive data from you

Une attaque aveugle peut être contrée en forçant l'attaquant à prouver qu'il peut recevoir des données de la victime. Une technique courante est d'exiger que l'attaquant réponde en utilisant une information obtenue plus tôt dans l'échange de messages. Si cette contre-mesure est utilisée, l'attaquant doit soit utiliser sa propre adresse (facile à tracer) soit forger une adresse qui sera routée en retour le long d'un chemin traversant l'hôte d'où l'attaque est lancée.

Les hôtes sur de petits sous-réseaux sont donc inutiles à l'attaquant (au moins dans le contexte d'une attaque par usurpation) car l'attaque peut être tracée jusqu'à un sous-réseau (ce qui devrait suffire à localiser l'attaquant) afin de mettre en place des mesures anti-attaque (par ex. un routeur de bordure peut être configuré pour rejeter tout le trafic de ce sous-réseau). Une technique courante est d'exiger que l'attaquant réponde en utilisant une information obtenue plus tôt dans l'échange de messages.

4.6.4. Example: TCP SYN Floods

TCP/IP est vulnérable aux attaques SYN flood (décrites à la section 3.3.2) en raison de la conception de la poignée de main à 3 voies. D'abord, un attaquant peut forcer une victime à consommer des ressources significatives (ici, la mémoire) en envoyant un seul paquet. Ensuite, comme l'attaquant peut effectuer cette action sans jamais avoir reçu de données de la victime, l'attaque peut être menée de manière anonyme (et donc avec un grand nombre d'adresses source forgées).

4.6.5. Example: Photuris

[PHOTURIS] spécifie un mécanisme anti-encombrement qui empêche des attaques sur Photuris ressemblant à l'attaque SYN flood. Photuris emploie un secret variant dans le temps pour générer un « cookie » renvoyé à l'attaquant. Ce cookie doit être renvoyé dans les messages suivants pour que l'échange progresse. La particularité intéressante est que ce cookie peut être régénéré par la victime plus tard dans l'échange, et ainsi aucun état n'a besoin d'être conservé par la victime jusqu'à ce que l'attaquant ait prouvé qu'il peut recevoir des paquets de la victime.

4.7. Object vs. Channel Security

Il est utile de distinguer conceptuellement la sécurité d'objet et la sécurité de canal. La sécurité d'objet désigne les mesures de sécurité qui s'appliquent à des objets de données entiers. Les mesures de sécurité de canal fournissent un canal sûr sur lequel les objets peuvent être transportés de façon transparente, mais le canal n'a pas de connaissance particulière des limites d'objet.

Considérez un message de courrier électronique. Lorsqu'il est transporté sur une connexion sécurisée IPSEC ou TLS, le message est protégé pendant la transmission. Cependant, il n'est pas protégé dans la boîte aux lettres du destinataire ni dans les fichiers de spoule intermédiaires. De plus, comme les serveurs de messagerie s'exécutent généralement en tant que démon et non qu'utilisateur, l'authentification des messages signifie en général l'authentification du démon, pas de l'utilisateur. Enfin, comme le transport du courrier est saut par saut, même si l'utilisateur s'authentifie au premier relais, l'authentification ne peut pas être vérifiée en toute sécurité par le destinataire.

En revanche, lorsqu'un message est protégé par S/MIME ou OpenPGP, l'intégralité du message est chiffrée et protégée en intégrité jusqu'à ce que le destinataire l'examine et le déchiffre. Cela fournit aussi une authentification forte de l'émetteur réel, par opposition à la machine d'où venait le message. C'est la sécurité d'objet. De plus, le destinataire peut prouver au tiers l'authenticité du message signé.

Notez que la différence entre sécurité d'objet et de canal est une question de perspective. La sécurité d'objet à une couche de la pile de protocoles ressemble souvent à la sécurité de canal à la couche supérieure. Ainsi, du point de vue de la couche IP, chaque paquet ressemble à un objet sécurisé individuellement. Mais du point de vue d'un client Web, IPSEC ne fournit qu'un canal sûr.

La distinction n'est pas toujours nette. Par exemple, S-HTTP fournit la sécurité au niveau objet pour une seule transaction HTTP, mais une page Web consiste typiquement en plusieurs transactions HTTP (la page de base et

de nombreuses images intégrées). Ainsi, du point de vue de la page Web totale, cela ressemble plutôt à la sécurité de canal. La sécurité d'objet pour une page Web consisterait en la sécurité pour la clôture transitive de la page et de tout son contenu intégré comme une unité unique.

4.8. Firewalls and Network Topology

Il est de pratique courante de sécurité dans les réseaux modernes de partitionner le réseau en réseaux externes et internes à l'aide d'un pare-feu. Le réseau interne est alors supposé sûr et seules des mesures de sécurité limitées y sont utilisées. La partie interne d'un tel réseau est souvent appelée WALLED GARDEN.

Les concepteurs de protocoles Internet ne peuvent pas supposer en toute sécurité que leurs protocoles seront déployés dans un tel environnement, pour trois raisons. D'abord, les protocoles conçus à l'origine pour des environnements fermés sont souvent déployés plus tard sur Internet, créant de graves vulnérabilités.

Ensuite, les réseaux qui semblent topologiquement déconnectés peuvent ne pas l'être. Une raison peut être que le réseau a été reconfiguré pour permettre l'accès depuis l'extérieur. De plus, les pare-feu laissent de plus en plus passer des protocoles de couche application génériques tels que [SOAP] ou [HTTP]. Les protocoles réseau basés sur ces protocoles génériques ne peuvent en général pas supposer qu'un pare-feu les protégera. Enfin, l'une des menaces de sécurité les plus graves pour les systèmes vient des initiés, pas des externes. Comme les initiés ont par définition accès au réseau interne, les protections topologiques telles que les pare-feu ne les protègent pas.