|
|
 Auteurs : S. Kent (BBN Corp) et R. Atkinson (@Home Network) Version française : Guillaume Desgeorge - http://www.guill.net - guill@guill.net Obsolète : 1825 Categorie : Standard Novembre 1998 Statut de ce document Ce document spécifie un protocole standard d'Internet, pour la communauté Internet, et ne sera éprouvé qu'après plusieurs discussions et suggestions. Referez-vous à l'édition courante de "Internet Official Protocol Standards" (STD 1) pour savoir l'état de sa standardisation et son statut. La distribution de cette note illimitée. Note de Copyright : Copyright (C) The Internet Society (1998). Tous droits réservés. Table des matières 1. Introduction
1.1 Résumé du contenu de ce document Ce document spécifie l'architecture de base pour les système compatible avec IPsec. Le but de cette architecture est d'apporter divers services en terme de sécurité du trafic au niveau de la couche IP, à la fois dans les environnements IPv4 et IPv6. Ce document décrit le but de tels systèmes, leurs composants, et comment ils se lient entre eux dans l'environnement IP. Il décrit également les services de sécurité offerts par le protocole IPsec, et comment ces services peuvent être employés dans l'environnement IP. Ce document ne détaille pas tous les aspects de l'architecture IPsec. D'autres documents s'intéresseront aux autres détails architecturaux de nature plus avancée, comme l'utilisation d'IPsec dans un environnement de translation d'adresse (NAT, Network Address Translation) ou encore pour un support plus complet du multicast IP. Les composants fondamentaux qui suivent sur l'architecture de sécurité Ipsec sont vus en termes de fonctionnalités fondamentales et nécessaires. D'autres RFC (voir la section 1.3 pour
avoir des liens vers d'autres documents) définissent les protocoles
en (a), (c) et (d).
Ce document ne décrit pas une architecture de sécurité complète pour Internet. Il s'intéresse seulement à la sécurité de couche IP, obtenue par l'utilisation combinée de la cryptographie et des mécanismes d'un protocole de sécurité. Les mots-clefs tels DEVOIR, RECOMMENDER, POUVOIR ou OPTIONNEL et leurs déclinaisons, lorqu'il 1000 s apparaissent dans ce document, sont à interpréter de la façon dont la RFC 2119 [Bra97] le décrit. 1.2 Audience L'audience ciblée par ce document inclut ceux qui doivent implémenter cette technologie de sécurité IP, où d'autres qui sont intéressés par l'acquisition d'une certaine compréhension de ce système. En particulier, les utilisateurs éventuels de cette technologie (utilisateurs finaux ou administrateurs de système) font partie du public ciblé. Un glossaire est donné en annexe pour combler les problèmes de vocabulaire ou de contexte. Ce document suppose que le lecteur connaît IP (Internet Protocol) et les technologies qui lui sont liés, ainsi que les termes et concepts généraux concernant la sécurité. 1.3 Documents liés au sujet Comme mentionné plus haut, d'autres
document donne des définitions détaillées de certains
composants d'IPsec et de leurs interactions. Cela inclut les RFC sur les
sujets suivants :
2.1 Description des objectifs, des besoins et des problèmes IPsec est conçu pour donner une sécurité de haute qualité, basée sur la cryptographie, sans problème d'interopérabilité, pour IPv4 et IPv6. L'ensemble des services de sécurité proposé inclut le contrôle d'accès, l'intégrité en mode non connecté, l'authentification de l'origine des données, la protection contre le rejeu (une forme d'intégrité), la confidentialité (chiffrement), et une certaine confidentialité sur le flux de trafic. Ces services sont offerts par IP ou par d'autres protocoles de couches supérieures. Ces objectifs sont atteints par l'utilisation de deux protocoles de sécurité de trafic, Authentication Header (AH) et Encapsulating Security Payload (ESP), et par l'utilisation de procédures et de protocoles de gestion de clefs de cryptographie. L'ensemble des protocoles IPsec, employés dans n'importe quel contexte, et la façon dont ils sont utilisés, seront déterminés par les besoins des utilisateurs ou/et des sites/organisations sur la sécurité et les systèmes. Quand ces mécanismes sont correctement implémentés et déployés, ils ne doivent pas compromettre les uti 1000 lisateurs, les hôtes, ni les autres composants d'Internet qui n'utilisent pas ces mécanismes de sécurité pour protéger leur trafic. Ces mécanismes sont également conçu pour être indépendant de tout algorithme. Cette modularité permet de sélectionner différents types d'algorithme sans affecter la partie implémentation. Par exemple, des communautés différentes d'utilisateurs peuvent sélectionner (ou même créer) différents types d'algorithmes si nécessaire. Un ensemble standard d'algorithmes par défaut est spécifié pour facilité l'interopérabilité avec l'ensemble d'Internet. L'utilisation de ces algorithmes, en conjonction avec la protection du trafic IPsec et des protocoles de gestion de clefs, devrait permettre aux développeurs d'applications et de systèmes de déployer des technologies de sécurité cryptographique de haute qualité sur la couche Internet. 2.2. Avertissements et suppositions La suite de protocoles IPsec et des algorithmes associés par défaut sont conçus pour donner de la sécurité de haute qualité pour le trafic d'Internet. Quoiqu'il en soit, la sécurité offerte par l'utilisation de ces protocoles dépend de la qualité de leur implémentation, qui n'est pas le sujet de ce standard. De plus, la sécurité d'un système ou d'un réseau est fonction de nombreux facteurs, qu'il soit entre autres personnels, physiques, procéduraux, d'émanations compromettantes, et de pratiques de sécurité informatique. Donc, IPsec est seulement une partie d'une architecture globale de sécurité d'un système. Finalement, la sécurité offerte par l'utilisation d'IPsec est extrêmement dépendante de plusieurs aspects de l'environnement dans lequel l'implémentation d'IPsec s'exécute. Par exemple, les problèmes de sécurité des systèmes d'exploitations, les sources de nombres aléatoires de piètre qualité, les pratiques et les protocoles négligés pour la gestion du système, etc. peuvent tous dégrader la sécurité offerte par IPsec. Comme vu plus haut, aucun de ces attributs environnementaux ne sont étudiés dans le présent standard, ou d'autres concernant IPsec. Cette section donne une description vue de haut du fonctionnement d'IPsec, des composants du système, et de la façon dont il interagissent entre eux, pour obtenir les services de sécurité décrits plus haut. Le but de cette description est de permettre au lecteur d'avoir en tête l'ensemble du processus/système, de voir comment il s'intègre à l'environnement IP, et de présenter le contexte avant les sections suivantes de ce document, qui décrit chacun des composants plus en détails. Une implémentation d'IPsec s'exécute dans un environnement hôte ou sur une passerelle de sécurité pour protéger le trafic IP. La protection offerte est basée sur des besoins définis par la base de données de la politique de sécurité (SPD, Security Policy Database) établie et maintenue par un utilisateur ou un administrateur système, ou par une application s'exécutant avec les contraintes & 1000 eacute;tablies par l'un des deux. En général, les paquets sont sélectionnés pour l'un des trois modes d'utilisation basés sur IP, selon l'information de la couche de transport (Sélecteurs, Section 4.4.2), empêchant les entrées dans la SPD. Chaque paquet peut utiliser les services de sécurité IPsec, ou de les éviter, selon les règles de la SPD identifiées par les Sélecteurs. 3.1 Que fait IPsec ? IPsec offre des services de sécurité au niveau de la couche IP en permettant au système de choisir le protocole de sécurité dont il a besoin, de déterminer l'algorithme à utiliser pour ce ou ces services, et de mettre en place les clefs de cryptographie nécessaire pour assurer ces services. IPsec peut être utilisé pour protéger un ou plusieurs accès entre deux hôtes, entre deux passerelles de sécurité, ou entre une passerelle de sécurité et un hôte (Le terme "passerelle de sécurité" ou "security gateway" est utilisé tout au long de ce document pour parler d'un système intermédiaire qui utilise les protocoles d'IPsec. Par exemple, un routeur ou un firewall utilisant IPsec est une passerelle de sécurité). L'ensemble des services de sécurité que peut proposer IPsec inclut le contrôle d'accès, l'intégrité en mode non connecté, l'authentification de l'origine des données, le rejet des paquets de rejeu (une forme d'intégrité), la confidentialité (chiffrement), et une certaine confidentialité sur le flux de trafic. Parce que ces services sont proposés au niveau IP, ils peuvent être utilisés par un protocole appartenant à une couche supérieure, comme TCP, UDP, ICMP, BGP, etc. Le DOI d'IPsec supporte également la négociation de compression IP [SMPT98], motivée entre autre par le fait que lorsque le chiffrement est utilisé au sein d'IPsec, il empêche une compression efficace par les protocoles des couches inférieures. 3.2 Comment fonctionne IPsec ? IPsec utilise deux protocoles pour
assurer la sécurité du trafic -- Authentication Header (AH)
et Encapsulating Security Payload (ESP). Ces deux protocoles sont décrits
en détails dans leurs RFC respectives [KA98a, KA98b].
Ces protocoles peuvent être impliqués seuls ou ensemble pour apporter l'ensemble d& 1000 eacute;siré des services de sécurité dans IPv4 et IPv6. Chaque protocole supporte deux modes d'utilisation : le mode transport et le mode tunnel. En mode transport, le protocole propose une protection préliminaire pour les protocoles supérieurs, et en mode tunnel, le protocole est utilisé dans les paquets IP envoyés en tunneling. La différence entre ces deux modes est évoqué dans la Section 4. IPsec permet à l'utilisateur
(ou l'administrateur système) de contrôler la granularité
de ce qui utilise un service de sécurité. Par exemple, on
peut créer un simple tunnel chiffré pour transporter tout
le trafic entre deux passerelles de sécurité ou un tunnel
chiffré séparé pour chaque connexion TCP entre les
deux hôtes communiquant par ces passerelles. La gestion d'IPsec doit
incorporer des équipements pour spécifier :
Comme ces services de sécurité utilisent des valeurs secrètes partagées (clefs de cryptographie), IPsec repose sur un ensemble séparé de mécanismes permettant de mettre ces clefs en place. (Les clefs sont utilisées pour l'authentification/intégrité et services de chiffrement.) Ce document nécessite d'autres supports pour la distribution automatique ou manuelle de clefs. Il spécifie une approche spécifique basée sur les clefs publiques (IKE -- [MSST97, Orm97, HC98]) pour la gestion automatique des clefs, mais d'autres techniques de distribution automatique de clef PEUVENT être utilisées. Par exemple, les systèmes basés sur KDC comme Kerberos ou d'autres systèmes à clefs publiques comme SKIP peuvent être utilisés. 3.3 Où IPsec peut-il être implémenté ? Il y a plusieurs façons d'implémenter
IPsec sur un hôte ou en conjonction avec un routeur ou un firewall
(pour créer une passerelle de sécurité). Plusieurs
exemples sont données ci-dessous :
Cette section définit les besoins en terme de gestion des Associations de Sécurité nécessaire à toute implémentation d'IPv6 et les implémentations d'IPv4 qui utilisent AH, ESP, ou les deux. Le concept de "Association de Sécurité" (SA, Security Association) est fondamental dans IPsec. AH et ESP utilisent tous les deux les SA et une des fonctions majeures de IKE est l'établissement et le maintien d'Associations de Sécurité. Toute implémentation de AH ou ESP DOIT supporter le concept d'Association de Sécurité comme décrit par la suite. Le reste de cette section décrit différents aspects de la gestion des Associations de Sécurité, définissant les caractéristiques requises pour la gestion d'une politique de SA, le traitement du trafic, et les techniques de gestion d'une SA. 4.1 Définition et étendue Une Association de Sécurité (SA) est une connexion simplex qui apporte des services de sécurité au trafic qui transite par elle. Les services de sécurité sont apportés par la SA par l'intermédiaire de AH ou de ESP, mais pas des deux. Si les protections de AH et ESP sont toutes deux appliquées à un flux, alors au moins deux SA sont créées pour apporter la protection de ce flux. Pour sécuriser une transmission bi-directionnelle typique entre deux hôtes, ou entre deux passerelles de sécurité, deux Associations de Sécurité (une dans chaque direction) sont nécessaires. Une Association de Sécurité est identifiée de façon unique par trois variables que sont l'index du paramètre de sécurité (SPI, Security Parameter Index), l'adresse IP destination, et l'identifiant du protocole de sécurité (AH ou ESP). En principe, l'adresse destination peut être une adresse unicast, broadcast ou de groupe multicast. Cependant, les mécanismes actuels de gestion des SA dans IPsec sont définis seulement pour les SA unicast. Par conséquent, dans les discussions qui suivent, les SA seront décrites dans le contexte d'une communication point-à-point, même si le concept est également applicable dans le cas d'une communication multipoint. Comme indiqué ci-dessus, deux types de SA sont définies : en mode transport et en mode tunnel. Le mode transport d'une SA est une Association de Sécurité entre deux hôtes. Dans IPv4, l'entête du protocole de sécurité en mode transport apparaît juste après l'entête d'IP et toutes ses options, et avant n'importe quel protocole des couches plus élevées (comme TCP ou UDP). Dans IPv6, l'entête du protocole de sécurité apparaît après l'entête IP et ses extensions de base, mais peut apparaître avant ou après les options de destination, et avant les protocoles des couches supérieures. Dans le cas d'ESP, le mode transport de SA fournit des services de sécurité uniquement pour les protocoles supérieurs, pas pour l'ent&eci 1000 rc;te IP ou tous les entêtes d'extension précédant l'entête ESP. Dans le cas d'AH, la protection est également étendue à certaines parties choisies de l'entête IP, à certaines parties choisies des entêtes d'extension, et à certaines options choisies (contenues dans l'entête IPv4, dans l'entête d'extension Hop-by-Hop et dans les entêtes d'extension de destination pour IPv6). Pour plus de détails sur la protection accordée par AH, référez-vous aux spécifications d'AH [KA98a]. Le mode tunnel d'une SA est essentiellement une SA appliquée à un tunnel IP. Chaque fois que l'extrémité d'une Association de Sécurité est une passerelle de sécurité, la SA DOIT être en mode tunnel. Ainsi, une SA entre deux passerelle de sécurité est toujours en mode tunnel, de même qu'une SA entre un hôte et une passerelle de sécurité. Notez que dans le cas d'un trafic destiné à une passerelle de sécurité, comme les commandes SNMP, la passerelle de sécurité agit en tant qu'hôte et que le mode transport est possible. Dans ce cas, la passerelle de sécurité n'agit pas en tant que passerelle, c'est-à-dire que le trafic ne transite pas par elle. Deux hôtes PEUVENT établir entre eux une SA en mode tunnel. Les conditions nécessaires au mode tunnel, pour une SA impliquant une passerelle de sécurité, sont plus sévères pour éviter d'éventuels problèmes de fragmentation et de réasssemblage de paquets IPsec, ou quand les accès sont multiples (comme par l'intermédiaire de différentes passerelles de sécurité), jusqu'à une même destination se trouvant derrière des passerelles de sécurité. Pour la SA en mode tunnel, il y a un entête IP "externe" qui indique la destination traitée par IPsec, plus un entête IP "interne" qui indique la destination finale (apparente) du paquet. L'entête du protocole de sécurité apparaît après l'entête IP externe, et avant l'entête IP interne. Si AH est utilisé en mode tunnel, les parties de l'entête IP externe sont protégées (comme vu ci-dessus), de même que tout paquet IP passant en tunneling (c.-à-d., tout l'entête IP interne est protégé, ainsi que les protocoles des couches plus élevées). Si ESP est utilisé, la protection est appliquée uniquement au paquet passant en mode tunneling, pas à l'entête externe. En résumé,
4.2 Fonctionnalités des SA L'ensemble des services de sécurité offerts par la SA dépend du protocole de sécurité choisi, du mode de la SA, des extrémités de la SA, et de l'utilisation des services optionnels du protocole. Par exemple, AH fournit l'authentification de l'origine de données et l'intégrité en mode non connecté des datagrammes IP (ci-après désignés sous le nom d'"au 1000 thentification"). La "précision" du service d'authentification est fonction de la granularité de l'association de sécurité avec laquelle AH est utilisé, comme nous le verrons dans la Section 4.4.2, sur les "Sélecteurs". AH offre également le service d'anti-rejeu (intégrité) pour le récepteur, afin de contrer les attaques de déni de service. AH est un protocole à utiliser quand la confidentialité n'est pas nécessaire (ou n'est pas autorisé, par exemple, en raison des restrictions du gouvernement sur le chiffrement). AH fournit également l'authentification pour les parties choisies de l'entête IP, ce qui peut être nécessaire dans certains cas. Par exemple, si l'intégrité d'un entête d'option IPv4 ou d'une extension IPv6 doit être assurée le long du chemin entre l'expéditeur et le récepteur, AH peut fournir ce service (sauf sur les parties non-prévisibles pouvant changer dans l'entête IP). ESP fournit en option la confidentialité du trafic (la puissance du service de confidentialité dépend en partie de l'algorithme de chiffrement utilisé). ESP peut également fournir l'authentification en option (comme défini ci-dessus). Si l'authentification est négociée pour une SA ESP, le récepteur peut également choisir d'imposer le service d'anti-rejeu avec les mêmes dispositifs que le service anti-rejeu d'AH. La portée de l'authentification offerte par ESP est plus étroite que celle d'AH, c'est-à-dire que le ou les entêtes IP situés hors de l'entête ESP ne sont pas protégés. Si les protocoles des couches supérieures sont les seuls qui doivent être authentifiés, alors l'authentification ESP est un choix approprié et plus efficace que l'utilisation de AH encapsulant ESP. Notons que même si la confidentialité et l'authentification sont facultatives, elles ne peuvent pas être toutes les deux absentes. Au moins l'une d'elles DOIT être choisie. Si le service de confidentialité est choisi, alors la SA ESP (en mode tunnel) peut offrir une confidentialité partielle du flux entre deux passerelles de sécurité. L'utilisation du mode tunnel permet aux entêtes IP internes d'être chiffrés, cachant l'identité de la source et de la destination (finale) du flux. D'ailleurs, le bourrage de la charge utile d'ESP peut également être utilisé pour cacher la taille des paquets. Des services similaires de confidentialité du flux peuvent être offerts quand un utilisateur mobile se voit assigner une adresse IP dynamique lors de la connexion. Ces services établissent une SA ESP (en mode tunnel) avec le firewall (agissant en tant que passerelle de sécurité). Notez que les SA de bonne granularité sont généralement plus vulnérables à l'analyse du trafic que ceux de granularité brute qui transportent le trafic de beaucoup d'abonnés. 4.3 Combiner les SA Les datagrammes IP transmis au-dessus d'une SA individuelle sont protégés par un unique protocole de sécurité, soit AH, soit ESP, mais pas les deux. Parfois, une politique de sécurité peut nécessiter une combinaison des services pour un flux particulier qui n'est pas réalisable avec une SA simple. Dans ce cas, il sera nécessaire d'utiliser plusieurs SA pour mettre en application la politique de sécurité demandée. Le terme "paquet d'associations de sé 1000 curité" ou "paquet de SA" est appliqué à une séquence de SA spécifiant le traitement que le trafic doit recevoir pour satisfaire une politique de sécurité. L'ordre de la séquence est définie par la politique (notons que les SA peuvent comporter un paquet qui peut être destiné aux différentes extrémités. Par exemple, une SA peut s'étendre d'un hôte mobile à une passerelle de sécurité et une autre SA emboîtée peut s'étendre jusqu'à un hôte placé derrière cette passerelle). Les Associations de Sécurité peuvent être combinées dans des paquets de deux façons : la juxtaposition du transport et la création d'un tunnel itératif. - La juxtaposition du transport se rapporte à l'application de plus d'un protocole de sécurité au même datagramme IP, sans demander la création d'un tunnel. Ce mélange d'AH et d'ESP est possible pour un seul niveau de combinaison ; davantage d'emboîtement n'apporte aucun autre avantage (utilisation d'algorithmes suffisamment forts pour chaque protocole) puisque le traitement est exécuté en une instance d'IPsec jusqu'à la destination (finale). Hôte 1 -- Passerelle --
Internet -- Passerelle -- Hôte 2
- Le tunneling itératif se rapporte à l'application de plusieurs couches de protocoles de sécurité par la création d'un tunnel IP. Cette approche tient compte de plusieurs niveaux d'emboîtement, puisque chaque tunnel peut commencer ou se terminer à un lieu IPsec différent tout au long du chemin. Aucun traitement spécial n'est prévu pour le trafic ISAKMP aux passerelles de sécurité intermédiaires autres que ce qui peut être indiqué par les entrées appropriées de la SPD (voir le cas 3 de la Section 4.5) Il y a 3 cas de base pour le tunneling itératif -- le support n'est nécessaire que pour les cas 2 et 3 : 1. Les deux extrémités de la SA sont les mêmes -- Les tunnels internes et externes peuvent être soit AH, soit ESP, bien qu'il soit peu probable que l'hôte 1 les indiquerait tous deux comme étant les mêmes, i.e., AH dans AH et ESP dans ESP.
& 1000 nbsp; Hôte 1 -- Passerelle --
Internet -- Passerelle -- Hôte 2
2. Une des deux extrémités de la SA est la même -- les tunnels internes et externes peuvent être soit AH, soit ESP.
Hôte 1 -- Passerelle -- Internet -- Passerelle -- Hôte 2
3. Aucunes des deux extrémités n'est la même -- les tunnels internes et externes peuvent être soit AH, soit ESP.
Hôte 1 -- Passerelle -- Internet 1000 -- Passerelle -- Hôte
2
Ces deux approches peuvent également être combinées. Par exemple, le paquet de SA pourrait être construit à partir d'une SA en mode tunnel et une ou deux SA en mode transport, appliquées dans un certain ordre (voir la Section 4.5 "Combinaisons de base des Associations de Sécurité"). Notons qu'il peut aussi arriver que des tunnels emboîtés n'aient en commun ni leurs sources, ni leurs destinations. Dans ce cas, il n'y aurait aucun hôte ou passerelle de sécurité ayant un paquet correspondant aux tunnels emboîtés. Pour les SA en mode transport, un seul ordre pour les protocoles de sécurité semble approprié. AH est appliqué à la fois aux protocoles des couches supérieures et à (certaines parties de) l'entête IP. Ainsi, si AH est utilisé en mode transport, en même temps qu'ESP, AH DEVRAIT apparaître dans le premier entête suivant IP, avant ESP. Dans ce cas, AH est appliqué au texte chiffré sorti d'ESP. En revanche, pour les SA en mode tunnel, on peut imaginer des ordres différents pour AH et ESP. L'ensemble des types de paquet de SA nécessaires DEVANT être supportés par une implémentation conforme d'IPsec est décrit dans la Section 4.5. 4.4 Les bases de données des Associations de Sécurité (Security Association Databases) Plusieurs détails associés au traitement du trafic IP d'une implémentation IPsec sont en grande partie des problèmes locaux, pas d'étalonnage. Cependant, quelques aspects externes du traitement doivent être normalisés, pour assurer leur interopérabilité et pour fournir une capacité minimum de gestion qui est essentielle pour assurer un usage productif d'IPsec. Cette section décrit un modèle général pour le traitement du trafic IP en relation avec des SA, en rapport avec ce but d'interopérabilité et de fonctionnalité. Le modèle décrit ci-dessous est nominal ; l 1000 es implémentations conformes n'ont pas besoin de correspondre aux détails du modèle tel qu'il est présenté, mais le comportement externe de telles implémentations doit pouvoir correspondre aux caractéristiques extérieurement observables de ce modèle. Il y a deux bases de données nominales dans ce modèle : la base de données de la politique de sécurité (SPD, Security Policy Database) et la base de données des Associations de Sécurité (SAD, Security Association Database). La première indique les politiques qui déterminent la destination de l'ensemble du trafic IP d'arrivée ou venant d'un hôte, d'une passerelle de sécurité, ou d'une implémentation IPsec BITS ou BITW. La seconde base de données contient les paramètres qui sont associés à chaque Association (active) de Sécurité. Cette section définit également le concept de Sélecteur, un ensemble de valeurs de champs de protocole IP des couches supérieures qui est utilisé par la base de données de la politique de sécurité pour faire correspondre un trafic à une politique, c.-à-d., une SA (ou le paquet de SA). Chaque interface où IPsec est activée exige nominalement des entrées séparées dans les bases de données (SAD et SPD), en raison de la directionalité de plusieurs des champs qui sont utilisées comme Sélecteurs. En général, il y a une seule interface, pour un hôte ou une passerelle de sécurité (SG). Notons qu'une SG aura toujours au minimum 2 interfaces, mais celle qui est "interne" au réseau n'a généralement pas IPsec activé et donc seules une paire de SAD et une paire de SPD seraient nécessaires. D'autre part, si un hôte ou une SG avait plusieurs interfaces externes, il pourrait être nécessaire d'avoir des paires SAD et SPD séparées pour chaque interface. 4.4.1 La base de données de la politique de sécurité (SPD, Security Policy Database) Finalement, une Association de Sécurité est un outil de gestion utilisé pour imposer une politique de sécurité dans un environnement IPsec. Ainsi, un élément essentiel au traitement de SA est la base de données fondamentale de politique de sécurité (SPD) qui indique quels services doivent être offerts aux datagrammes IP et de quelle façon. La forme de la base de données et de son interface ne sont pas abordés dans ces spécifications. Cependant, cette section indique quelles fonctionnalités minimum de gestion doivent être fournies, pour permettre à un utilisateur ou un administrateur système de contrôler la façon dont IPsec est appliqué au trafic transmis ou reçu par hôte, ou passant par une passerelle de sécurité. La SPD doit être consultée pendant le traitement de tout le trafic (ENTRANT et SORTANT), y compris le trafic non-IPsec. Afin d'assurer ceci, la SPD exige des entrées distinctes pour le trafic entrant et sortant. On peut utiliser des SPD séparées (entrante ou sortante). En outre, une SPD séparée doit être utilisée pour chaque interface où IPsec est activée. Une SPD doit distinguer le trafic qui est protégé par IPsec et celui qui passe IPsec. Ceci concerne la protection IPsec devan 1000 t être appliquée par un expéditeur et la protection IPsec qui doit être présente chez le récepteur. A n'importe quel datagramme entrant ou sortant, trois choix de traitement sont possibles : jeter, passer IPsec, ou appliquer IPsec. Le premier choix se rapporte au trafic qui n'est pas autorisé à quitter l'hôte, à traverser la passerelle de sécurité, ou à être fourni à une application. Le deuxième choix se rapporte au trafic qui est autorisé à passer sans protection IPsec supplémentaire. Le troisième choix se rapporte au trafic protégé par IPsec, et pour un tel trafic, la SPD doit indiquer les services de sécurité à fournir, les protocoles et les algorithmes à utiliser, etc... Pour chaque implémentation d'IPsec, il DOIT y avoir une interface administrative qui permet à un utilisateur ou un administrateur système de contrôler la SPD. Spécifiquement, chaque paquet entrant ou sortant est sujet au traitement IPsec, et la SPD doit indiquer l'action à effectuer dans chaque cas. Ainsi, cette interface administrative doit permettre à l'utilisateur (ou administrateur système) d'indiquer le traitement en sécurité à appliquer sur n'importe quel paquet entrant ou sortant du système, pour un paquet ou un type de paquets (dans une implémentation d'hôte IPsec utilisant une interface basée sur les sockets, on peut consulter la SPD pour un type de paquet, mais le résultat est le même). L'administrateur système de la SPD DOIT permettre la création d'entrées conformes aux Sélecteurs définis dans la Section 4.4.2, et DOIT permettre le contrôle total de ces entrées. On s'attend à ce que l'utilisation de types d'informations différents (wildcards) dans les Sélecteur pose problème, et ce parce que tous les paquets d'une connexion simple UDP ou TCP tendent à correspondre à une entrée simple de la SPD, mais cette condition n'imposera pas un niveau de détails irraisonnable dans les spécifications de la SPD. Les Sélecteurs sont identiques à ceux que l'on trouve actuellement dans un firewall ou un routeur filtrant. Dans des systèmes hôtes, on PEUT permettre à des applications de choisir quel traitement de sécurité doit être appliqué au trafic qu'elles produisent et consomment (les moyens de signaler de telles demandes dans l'implémentation IPsec ne sont pas du ressort de cette norme). Cependant, l'administrateur système DOIT pouvoir indiquer si un utilisateur ou une application peut ignorer les politiques du système (par défaut). Notez que les politiques indiquées par l'application peuvent répondre à certaines exigences du système, de sorte que le système ne soit pas obligé de procéder à un traitement IPsec supplémentaire pour répondre aux exigences d'une application. La forme de l'interface de gestion n'est pas indiquée par ce document et peut différer entre les hôtes et les passerelles de sécurité, et d'un hôte à l'autre, l'interface peut différer entre une implémentation BITS et une basée sur les sockets. Cependant, ce document indique un ensemble standard d'éléments de SPD que toutes les implémentations IPsec DOIVENT avoir. La SPD contient une liste ordonnée d'entrées de politique. Chaque entrée de politique est introduite par un ou plusieurs Sélecteurs qui définissent l'ensemble du trafic IP concerné par cette entr&e 1000 acute;e de politique (les types de Sélecteur exigés sont définis dans la Section 4.4.2). Ceux-ci définissent la granularité des politiques ou des SA. Chaque entrée inclut une indication permettant de savoir si le trafic correspondant à cette politique sera passé, rejeté, ou sujet à un traitement d'IPsec. Si le traitement par IPsec est nécessaire, l'entrée donne les spécifications de la SA (ou paquet de SA), précisant les protocoles IPsec, les modes, et les algorithmes à utiliser, ainsi que leurs interactions. Par exemple, une entrée peut nécessiter de protéger tout son trafic associé par ESP en mode transport, en utilisant 3DES-CBC avec un IV explicite, encapsulé à l'intérieur de AH en mode tunnel, utilisant HMAC/SHA-1. Pour chaque Sélecteur, l'entrée de la politique indique comment dériver les valeurs correspondantes pour obtenir une nouvelle entrée dans la base de données d'Association de Sécurité (SAD, voir la Section 4.4.3) de celles de le SPD et du paquet (notons qu'actuellement, les intervalles sont seulement supportés pour les adresses IP, mais les types d'informations différents (wildcarding) peuvent être exprimés pour tous les Sélecteurs): a. Utilisation de la valeur dans le paquet elle-même -- ceci limitera l'utilisation de la SA aux paquets qui ont la valeur de ce paquet pour le Sélecteur, même si le Sélecteur de l'entrée de la politique a un intervalle de valeurs autorisées ou un type d'informations différentes pour ce Sélecteur. b. Utilisation de la valeur associée à l'entrée de la politique -- si ça devaient être uniquement une valeur simple, alors il n'y aurait aucune différence entre (b) et (a). Cependant, si les valeurs autorisées pour le Sélecteur appartiennent à un intervalle (pour des adresses IP) ou un type d'informations différentes (wildcard), alors, dans le cas d'un intervalle, (b) permettrait l'utilisation de la SA par n'importe quel paquet avec une valeur de Sélecteur appartenant à cet intervalle, et pas seulement par les paquets dont la valeur de Sélecteur du paquet est celle qui a déclenché la création de la SA. Dans le cas d'un type d'informations différent (wildcard), (b) permettrait l'utilisation de la SA par des paquets ayant n'importe quelle valeur pour ce Sélecteur. Par exemple, supposez qu'il y a une entrée de la SPD où la valeur autorisée pour l'adresse source est une partie quelconque d'un intervalle d'hôtes (192.168.2.1 à 192.168.2.10). Supposez ensuite qu'un paquet doit être envoyé a l'adresse source de 192.168.2.3. La valeur à utiliser pour la SA pourrait être n'importe laquelle de des valeurs ci-dessous selon ce que l'entrée de la politique pour ce Sélecteur indique comme étant la source de valeur de Sélecteur: Source de la valeur
Exemple pour la nouvelle
Notez que si l'entrée de la SPD avait une valeur autorisée de type d'informations différentes (wildcard) pour l'adresse source, alors la valeur de Sélecteur SAD pourrait être d'un type d'informations différent (wildcard) (n'importe quel hôte). Le cas (a) peut être utilisé pour empêcher les partages, même entre les paquets correspondant à la même entrée de la SPD. Comme décrit ci-dessous dans la Section 4.4.3, les Sélecteurs peuvent inclure des entrées d'un type différent ("wildcard") et, par conséquent, les Sélecteurs de deux entrées peuvent se superposer (c'est analogue à la superposition apparaissant avec les acces-lists (ACL) ou les entrées de filtrage des paquets dans les routeurs ou firewalls). Ainsi, pour assurer un traitement conforme et prévisible, les entrées de la SPD DOIVENT être ordonnées et la SPD DOIT toujours être parcourue dans le même ordre, de sorte que la première entrée correspondante soit toujours la même (cette condition est nécessaire, de même que le fait de traiter le trafic, et les entrées de la SPD doivent être déterministes, mais on ne peut pas normaliser des entrées de la SPD, étant donné l'utilisation des types différents (wildcards) pour quelques Sélecteurs). On fournit plus de détails la correspondance des paquets et des entrées de la SPD dans la Section 5. Notons que si ESP est utilisé, soit l'authentification, soit le chiffrement (mais pas les deux) peuvent être supprimé. Par conséquent, il DOIT être possible de configurer la valeur de la SPD concernant les algorithmes d'authentification et de chiffrement comme étant "NULL". Quoiqu'il en soit, au moins un de ces services doit être sélectionné, c'est-à-dire qu'on NE DOIT PAS pouvoir configurer les deux à "NULL". La SPD peut être employée pour associer un trafic à certains SA ou paquets de SA. Ainsi, elle peut être utilisée comme base de données de référence pour la politique de sécurité et comme point de référence pour les SA (ou paquets de SA) existants (pour faciliter les politiques de rejet ou de passage citées ci-dessus, la SPD DOIT également fournir des moyens d'associer un trafic à ces fonctions, quoique ce ne soit pas, intrinsèquement, du traitement IPsec). La façon dont la SPD fonctionne est différente pour le trafic entrant et sortant. Ceci peut également différer pour un hôte et une passerelle de sécurité, ou pour les implémentations BITS et BITW. Les Sections 5.1 et 5.2 décrivent l'utilisation de la SPD pour le traitement du trafic entrant et sortant. Etant donné qu'une politique de sécurité peut demander que plus d'une SA soit appliquée dans un ordre précis à un certain trafic, l'entrée de la politique dans la SPD doit conserver ces conditions ordonnées, quand il y en a. Ainsi, il doit être possible pour une implémentation d'IPsec de savoir qu'un paquet entrant ou sortant doit être traité par une suite de SA. Conceptuellement, pour le traitement sortant, on a pourrait imaginer des liens (vers la SAD) à partir d'une entrée de la SPD pour laquelle il y a des SA actifs, et chaque entrée se composerait d'une simple SA ou d'une liste ordonnée de SA qui comportent un paquet de SA 1000 . Quand un paquet est associé à une entrée de la SPD et qu'il y a une SA ou un paquet de SA existant qui peut être utilisé pour transporter le trafic, le traitement du paquet est contrôlé par l'entrée de la SA ou du paquet de SA de la liste. Pour un paquet IPsec entrant ayant plusieurs SA IPsec devant être appliquées, une consultation basée sur l'adresse destination, le protocole IPsec, et le SPI devrait identifier une SA unique. La SPD est utilisée pour contrôler l'écoulement de l'ENSEMBLE du trafic par un système IPsec, ce qui comprend la sécurité et le trafic de gestion des clés (comme ISAKMP) allant ou venant d'entités se trouvant derrière une passerelle de sécurité. Cela signifie que le trafic ISAKMP doit être explicitement noté dans la SPD, sous peine d'être rejeté. Notez qu'une passerelle de sécurité pourrait interdire la traversée de paquets chiffrés de plusieurs façons, en ayant par exemple une entrée REJET dans la SPD pour les paquets ESP ou en fournissant un échange de clé par proxy. Dans ce dernier cas, le trafic serait routé en interne jusqu'au module de gestion des clefs dans la passerelle de sécurité. 4.4.2 Sélecteurs Une SA (ou paquet de SA) peut être à grain fin ou à grain grossier, selon les sélecteurs utilisés pour définir l'ensemble du trafic pour SA. Par exemple, tout trafic entre deux hôtes peut être transporté par l'intermédiaire d'une simple SA, et apporter un ensemble uniforme de services de sécurité. Alternativement, le trafic entre deux hôtes pourrait être réparti entre plusieurs SA, selon les applications utilisées (comme défini par les champs Next Protocol et Port), avec différents services de sécurité offerts par différentes SA. De même, tout le trafic entre deux passerelles de sécurité pourrait être transporté par une simple SA, ou une SA pourrait être assignée à chaque paire d'hôtes communicants. Les paramètres suivants de Sélecteurs DOIVENT être supportés pour que la gestion de SA facilite le contrôle de la granularité de la SA. Notez cela dans le cas de la réception d'un paquet ayant un entête ESP, par exemple, à une passerelle de sécurité encapsulante ou dans une implémentation BITW, le protocole de la couche transport, les ports source et destination, et le nom (si il y est) peuvent être "OPAQUES", c.-à-d., inaccessible en raison du chiffrement ou de la fragmentation. Notez également que les adresses source et destination devraient être au format IPv4 ou IPv6. - Adresse IP destination (IPv4 ou IPv6): ça peut être une adresse IP simple (unicast, anycast, broadcast (IPv4 seulement), ou groupe multicast), un intervalle d'adresses (bornes incluses), une adresse et un masque, ou une adresse de type différent (wildcard). Les trois derniers sont employés pour qu'un système destination puisse partager une même SA (par exemple, derrière une passerelle de sécurité). Notez que ce sélecteur est conceptuellement différent du champ "Adresse IP destination" dans l'ensemble <Adresse IP destination, protocole IPsec, SPI> employé pour identifier une SA unique. Quand un paquet tunnelé arrive à l'extrémité du tunnel, son SPI/Adresse Destination/Protocole sont utilisés pour rechercher la SA associ&ea 1000 cute;e au paquet dans la SAD. Cette adresse destination vient de l'entête IP encapsulée. Une fois que le paquet a été traité selon la SA du tunnel et est sorti du tunnel, ses sélecteurs "sont recherchés" dans la SPD d'arrivée. La SPD d'arrivée a un sélecteur appelé adresse destination. Cette adresse IP destination est celle de l'entête IP interne (encapsulé). Dans le cas d'un paquet transporté, il y aura seulement un entête IP donc aucune ambiguïté possible. [REQUIS pour toutes les implémentations] - Adresse(s) IP source (IPv4 ou IPv6): ça peut être une adresse IP simple (unicast, anycast, broadcast (IPv4 seulement), ou groupe multicast), un intervalle d'adresses (bornes incluses), une adresse et un masque, ou une adresse différente (wildcard). Les trois derniers sont employés que plus d'un système source puissent partager la même SA (par exemple, derrière une passerelle de sécurité ou dans un hôte "multihomed"). [REQUIS pour toutes les implémentations] - Nom : Il y a deux cas (notez que
ces formes de nom sont supportées par DOI d'IPsec).
Remarque : Une des valeurs possibles de ce sélecteur est "OPAQUE". [REQUIS pour les cas suivants. Notez que le support des formes de nom autres que les adresses n'est pas indispensable pour les SA ajoutées manuellement. o User ID
o Noms de systèmes -- toutes
implémentations]
Remarque : Pour localiser le protocole de transport, un système doit enchaîner les entêtes des paquets en contrôlant le champ "Protocole" ou "Next Header" jusqu'à ce qu'il en rencontre un qu'il reconnaît comme protocole de transport, ou jusqu'à ce qu'il en atteigne un qui n'est pas sur sa liste d'entêtes d'extension, ou jusqu'à ce qu'il rencontre un entête ESP qui rend le protocole de transport opaque. - Ports source et destination (par exemple, TCP/UDP): Ceux-ci peuvent être de différentes valeurs de ports de UDP ou de TCP ou un port de type différent (wildcard) (l'utilisation du champ "Prochain protocole" ou des champs "Ports source et/ou destination" (en même temps que les champs adresses source et/ou destination), comme sélecteur de SA est quelquefois abordé sous le nom de "session oriented keying"). Notez que les ports source et destination peuvent ne pas être disponibles en cas de réception d'un paquet ayant un entête ESP. Aussi, la valeur "OPAQUE" DEVRAIT être supportée. Le tableau suivant résume les relations entre la valeur du "Next Header" dans le paquet et la SPD, et la valeur du Sélecteur de Port qui en découle pour la SPD et la SAD. Next Header
Protocole de la couche Valeur dérivée
du champ Sélecteur
Si le paquet a été fragmenté, l'information de port peut ne pas être disponible dans le fragment traité. Dans ce cas, on jette le fragment. Un PMTU ICMP devrait être envoyé en premier fragment, qui aura l'information de port [PEUT être supporté] Le contexte d'implémentation IPsec détermine la façon dont les sélecteurs sont utilisés. Par exemple, une implémentation d'hôte au sein de la pile peut se servir d'une interface de "socket". Quand une nouvelle connexion est établie, la SPD peut être consultée et une SA (ou paquet de SA) s'occupe de la socket. Ainsi, le trafic envoyé par l'intermédiaire de cette socket n'a pas besoin de consultations s 1000 upplémentaires des SPD/SAD. En revanche, les implémentations BITS, BITW, ou d'une passerelle de sécurité doit scruter chaque paquet et consulter les SPD/SAD à partir des sélecteurs. Les valeurs autorisées pour les champs Sélecteur diffèrent en fonction du flux de trafic, de l'association de sécurité, et de la politique de sécurité. Le tableau suivante récapitule les différents types d'entrées nécessaires pour pouvoir être utilisés dans la SPD et la SAD. Il montre comment ils s'associent aux champs dans le trafic de données, étant soumis au criblage d'IPsec. (note: les entrées "sauvages" (wild) ou différentes (wildcard) pour les adresses source et destination comprennent un masque, un intervalle, etc...) Champ
Valeur du trafic Entrée de la SAD
Entrée de la SPD
* Les entrées SAD et SPD pour ces champs peuvent être "OPAQUE" si la valeur du trafic est chiffrée. Remarque : En principe, on peut avoir des sélecteurs et/ou des valeurs de sélecteur dans la SPD que l'on ne peut négocier pour une SA ou paquet de SA. Certains exemples pourraient montrer des valeurs de sélecteur employées pour choisir le trafic à jeter ou des listes énumératives qui engendrent la création d'une SA séparée pour chaque élément de la liste. Pour l'instant, ceci est laissé de côté et sera vu dans des futures versions de ce document et la liste de sélecteurs nécessaires et des valeurs de sélecteur est la même pour la SPD et la SAD. Cependant, il est acceptable d'avoir une interface administrative qui supporte l'utilisation des valeurs de sélecteur ne pouvant pas être négociées à condition qu'elles ne trompent pas l'utilisateur en lui faisant croire qu'il crée une SA avec ces valeurs de sélecteur. Par exemple, l'interface peut permettre à l'utilisateur d'indiquer une liste énumérative de valeurs mais cela aurait comme conséquence la création d'une politique et d'une SA séparée pour chaque élément de la liste. Un constructeur pourrait implémenter une telle interface pour que ce soit plus facile pour ses clients, et pour avoir des spécifications claires et précises de la politique. 1000 4.4.3 Base de données d'association de sécurité (SAD, Security Association Database) Dans chaque implémentation d'IPsec, il y a une base de données nominale d'association de sécurité, dans laquelle chaque entrée définit les paramètres associés à une SA. Chaque SA a une entrée dans la SAD. Pour le traitement sortant, les entrées sont pointées par les entrées de la SPD. Notez que si une entrée de SPD ne pointe pas vers la SA appropriée pour le paquet, l'implémentation crée une SA (ou paquet de SA) appropriée et relie l'entrée de la SPD à l'entrée de la SAD (voir Section 5.1.1). Pour le traitement du trafic entrant, chaque entrée de la SAD est classée par une adresse IP destination, un protocole IPsec, et un SPI. Les paramètres suivants sont associés à chaque entrée de la SAD. Cette description ne prétend pas être une MIB, mais seulement quelques spécifications de données élémentaires minimales et nécessaires au support d'une SA dans une implémentation IPsec. Pour le traitement entrant : Les champs
suivants du paquet sont utilisés pour trouver la SA dans la SAD
:
Pour chacun des Sélecteurs définis dans la Section 4.2.2, l'entrée de la SA dans la SAD DOIT contenir la ou les valeurs qui ont été négociées quand la SA a été créée. Pour l'émetteur, ces valeurs sont utilisées pour décider si une SA donnée est appropriée pour traiter un paquet sortant. Cela fait partie de la vérification permettant de voir s'il y a une SA existante qui peut être utilisée. Pour le récepteur, ces valeurs sont utilisées pour vérifier que les valeurs de sélecteurs dans un paquet entrant correspondent celles de la SA (et donc indirectement, celles de la police correspondante). Pour le récepteur, cela fait partie de la vérification permettant de s'assurer que la SA est appropriée pour ce paquet (voir Section 4.4.2 pour les messages ICMP). Ces champs peuvent être sous la forme de valeurs spécifiques, d'intervalles, de types différents(wildcards), ou "OPAQUE" comme décrit dans la section 4.4.2, "Les Sélecteurs". Notez que pour une SA de ESP, l'algorithme de chiffrement ou d'authentification peut être "NULL". Quoiqu'il en soit, ils ne peuvent pas tous les deux être "NULL". Les champs suivants de la SAD sont
utilisés pour le traitement IPsec :
4.5 Combinaisons de base d'Associations de Sécurité Cette section décrit quatre exemples de combinaisons d'Associations de Sécurité qui DOIVENT être supportées par les hôtes ou les passerelles de sécurité conforme à IPsec. Des combinaisons AH et/ou ESP en mode tunnel et/ou transport supplémentaires PEUVENT être supportés à la discrétion de celui qui fait l'implémentation. Les implémentations conformes DOIVENT être capable de produire ces quatre combinaisons et à la réception, de les traiter, mais DEVRAIENT pouvoir recevoir et traiter n'importe quelle combinaison. Les diagrammes et le texte ci-dessous décrivent les cas de base. La légende des diagrammes est :
==== = une ou plusieurs SA (AH ou ESP, tunnel ou transport)
Les SA suivantes peuvent être AH ou ESP. Le mode (tunnel ou transport) est déterminé par la nature des extrémités. Pour l 1000 es SA d'hôte-à-hôte, le mode peut être soit tunnel, soit transport. Cas 1. Le cas où on apporte une sécurité de bout en bout entre deux hôtes à travers Internet (ou un intranet).
====================================
Notez que soit le mode tunnel, soit le mode transport peut être activé par les hôtes. Donc les entêtes d'un paquet entre H1 et H2 peut ressembler à n'importe lequel des suivants :
Transport
Tunnel
Notez qu'il n'y a aucune condition sur le support de l'emboîtement, mais en mode transport, AH et ESP peuvent être appliqués au paquet. Dans ce cas, le procédé d'établissement de la SA DOIT s'assurer que d'abord ESP, puis AH sont appliqués au paquet. Cas 2. Ce cas illustre le support d'un simple VPN (Virtual Private Network).
===========================
Seul le mode tunnel est requis
ici. Donc les entêtes d'un paquet entre SG1 et SG2 peuvent ressembler
à n'importe laquelle des formes suivantes :
Tunnel
Cas 3. Ce cas combine les cas
1 et 2, en ajoutant une sécurité de bout en bout entre l'hôte
émetteur et l'hôte récepteur. Il n'impose aucune nouvelles
conditions sur les hôtes ou les passerelles de sécurité,
autre que la nécessité pour la passerelle de sécurité
d'être configurable pour laisser passer le trafic IPsec (dont le
trafic ISAKMP) pour les hôtes qui sont derrière elle.
===============================================================
Cas 4. Ce cas couvre la situation
où l'hôte distant (H1) utilise Internet pour atteindre le
firewall d'une organisation (SG2) pour accéder ensuite à
un serveur quelconque ou à toute autre machine (H2). L'hôte
distant pourrait être un hôte mobile (H1) se connectant à
un serveur local PPP/ARA (non montré) sur l'Internet et traversant
ensuite Internet jusqu'au firewall central de l'organisation (SG2), etc...
Les détails du support de ce cas, (comment H1 localise SG2, l'authentifie,
et vérifie son autorisation pour représenter H2) sont vus
dans la section 4.6.3 "Localiser une passerelle de sécurité".
======================================================
Seul le mode tunnel est demandé
entre H1 et SG2. Donc les choix de la SA entre H1 et SG2 serait une de
celles du cas 2. Les choix pour la SA entre H1 et H2 serait une de celles
du cas 1.
Notez que dans ce cas, l'émetteur
DOIT appliquer l'entête de transport avant l'entête du tunnel.
Par conséquent, l'interface de gestion de l'implémentation
d'IPsec DOIT offrir la possibilité de configurer la SPD et la SAD
pour assurer cet ordre dans l'application de l'entête IPsec.
Comme vu précédemment,
le support de combinaisons AH et ESP supplémentaires est optionnel.
L'utilisation d'autres combinaisons optionnelles peut compromettre l'interopérabilité.
4.6 SA et gestion des clefs
Les mandats IPsec supporte les SA manuelle
et automatisée, ainsi que la gestion des clefs de cryptographie.
Les protocoles IPsec, AH et ESP, sont en grande partie indépendants
des techniques de gestion des SA associées, bien que les techniques
impliquées affectent certains des services de sécurité
offerts par ces protocoles. Par exemple, l'anti-rejeu disponible pour AH
et ESP exige la gestion automatisée des SA. D'ailleurs, la granularité
de la distribution de clefs utilisée avec IPsec détermine
la granularité de l'authentification fournie (voir également
la discussion de ce point dans la section 4.7.). En général,
l'authentification de l'origine de données dans AH et ESP est limitée
par la taille des secrets utilisés avec l'algorithme d'authentification
(ou avec un protocole de gestion des clefs qui crée ces secrets)
qui sont partagés entre plusieurs sources possibles.
Le texte suivant décrit les
conditions minimum pour les deux types de gestion des SA.
4.6.1 Techniques
manuelles
La forme la plus simple de gestion
est la gestion manuelle, dans laquelle une personne configure manuellement
chaque système avec des données de gestion des Associations
de Sécurité et de matériel de base concernant la transmission
sécurisée avec d'autres systèmes. Les techniques manuelles
sont pratiques dans des environnements petits et statiques mais elles ne
s'étendent pas bien entre elles. Par exemple, une société
pourrait créer un réseau privé virtuel (VPN) utilisant
IPsec dans des passerelles de sécurité sur plusieurs sites.
Si le nombre de sites est petit 1000 , et puisque tous les sites relèvent
de la portée d'un seul domaine d'administration, c'est un contexte
où il est faisable d'utiliser des techniques de gestion manuelles.
Dans ce cas, la passerelle de sécurité pourrait, de façon
sélective, protéger le trafic en provenance ou à destination
d'autres sites de l'organisation en utilisant une clé configurée
manuellement, sans protéger le trafic vers d'autres destinations.
Cela peut également s'avérer utile quand seule une partie
sélectionnée des communications doivent être sécurisées.
Un argument similaire peut s'appliquer pour l'utilisation complète
d'IPsec au sein d'une organisation pour un nombre restreint d'hôtes
et/ou de passerelles. Les techniques manuelles de gestion utilisent souvent
des clefs symétriques configurées statiquement, bien qu'ils
existent d'autres possibilités.
4.6.2 Les
SA automatisées et la gestion des clefs
Le déploiement et l'utilisation
massive d'IPsec exige un protocole de gestion des SA standard sur Internet,
extensible et automatisé. Un tel support est exigé pour faciliter
l'utilisation des dispositifs d'anti-rejeu de AH et d'ESP, et pour faciliter
la création des SA sur demande, par exemple, pour l'introduction
d'utilisateurs et de sessions (notez que la notion de "réintroduction"
d'une SA implique réellement la création d'une nouvelle SA
avec un nouveau SPI, processus qui implique généralement
l'utilisation d'un protocole automatisé de gestion de SA et de clefs).
Le protocole de gestion automatisée
des clefs choisi par défaut pour IPsec est IKE [MSST97, Orm97, HC98]
dans son interprétation IPsec [Pip98]. D'autres protocoles de gestion
automatique de SA PEUVENT être utilisés.
Quand un protocole de gestion automatisée
de SA/clefs est utilisé, ce qui sort de ce protocole peut être
utilisé pour générer plusieurs clefs, comme par exemple,
pour une SA ESP simple. Cela peut arriver parce que :
Le système de gestion des clefs
peut fournir une suite de bits séparée pour chaque clé
ou il peut générer une suite de bits à partir desquels
toutes sont extraites. Si une simple suite de bits est fournie, il faut
prendre beaucoup de soin pour s'assurer que les parties du système
qui donnent cette suite de bits aux clés nécessaires le font
de la même façon aux deux extrémités de la SA.
Pour s'assurer que les implémentations d'IPsec situées à
chaque extrémité de la SA utilisent les mêmes bits
pour les mêmes clés, et indépendamment de la partie
du système qui divise la suite de bits en différentes clés,
la ou les clefs de chiffrement DOIVENT être prises à partir
des premiers bits (les bits de poids forts à gauche) et la ou les
clefs d'authentification DOIVENT être prises à partir des
bits restants. Le nombre de bits pour chaque clé est défini
dans la RFC donnant les spécifications de l'algorithme. Dans le
cas où il y a plusieurs clefs de chiffrement ou d'authentification,
1000 les spécifications de l'algorithme doivent indiquer l'ordre
dans lequel elles doivent être choisies dans la simple suite de bits
fournie à l'algorithme.
4.6.3 Localiser
une passerelle de sécurité
Cette section étudie les solutions
concernant la façon dont un hôte se renseigne sur l'existence
des passerelles de sécurité appropriées et une fois
qu'un hôte est entré en contact avec ces passerelles de sécurité,
comment sait-il que ce sont des passerelles de sécurité correctes.
Les détails sur l'endroit où sont stockées les informations
nécessaires relèvent d'un problème local.
Considérons la situation où
un hôte distant (H1) utilise Internet pour accéder à
un serveur ou à une autre machine (H2), et où il y a une
passerelle de sécurité (SG2), comme par exemple un firewall,
par lequel le trafic de H1 doit passer. Un exemple pour cette situation
serait un hôte mobile passant à travers Internet jusqu'au
firewall central de l'organisation (SG2) (voir le cas 4 des combinaisons
de base des SA, dans la section 4.5). Cette situation soulève plusieurs
questions :
Pour résoudre ces problèmes,
un hôte ou passerelle de sécurité DOIT avoir une interface
d'administration qui permet à l'utilisateur ou l'administrateur
de configurer l'adresse d'une passerelle de sécurité pour
toutes les adresses destination qui l'utilisent. Cela comprend la possibilité
de configurer :
On suppose que la SPD est également
configurée avec l'information de la politique qui couvre toutes
les autres conditions d'IPsec pour avoir accès à la passerelle
de sécurité et à l'hôte destination.
Ce document ne s'intéresse pas
aux solutions d'automatisation de la découverte ou vérification
des passerelles de sécurité.
4.7 Les Associations de
sécurité et le multicast
L'orientation "récepteur" de
l'Association de Sécurité implique, dans le cas d'un trafic
unicast, que normalement, le système destination choisit la valeur
du SPI. Si la destination choisit la valeur du SPI, il est impossible,
pour que les associations de sécurité configurées
manuellement (par exem 1000 ple, par un protocole de gestion de clés),
d'être en conflit avec des associations de sécurité
configurées automatiquement ou pour des associations de sécurité
ayant plusieurs sources d'être en conflit entre elles. Pour le trafic
multicast, il y a plusieurs systèmes destination par groupe multicast.
Donc, un système ou une personne devra se charger de la coordination
parmi tous les groupes multicast afin de choisir un SPI ou des SPIs au
nom de chaque groupe multicast, puis pour communiquer l'information IPsec
du groupe à tous les membres légitimes de ce groupe multicast,
par l'intermédiaire de mécanismes non définis ici.
Les multiples émetteurs vers
un groupe de multicast DEVRAIENT utiliser une association de sécurité
simple (et par conséquent, incrémenter le SPI) pour l'ensemble
du trafic à destination de ce groupe quand un algorithme de chiffrement
à clé symétrique ou d'authentification est utilisé.
Dans de telles circonstances, le récepteur sait seulement que le
message est venu d'un système possédant la clé de
ce groupe multicast. Dans de telles circonstances, un récepteur
ne pourra généralement pas authentifier le système
ayant envoyé le trafic multicast. Les spécifications sur
d'autres cas plus généraux ayant trait au multicast sont
reportées aux futurs documents IPsec.
Lorsque ces spécifications ont
été éditées, les protocoles automatisés
pour la distribution de clefs multicast n'ont pas été considérés
suffisamment mûrs pour leur standardisation. Pour les groupes multicast
ayant relativement peu de membres, une distribution manuelle des clefs
ou l'utilisation multiple d'algorithmes existants de distribution de clefs
unicast tels que Diffie-Hellman modifié semble possible. Pour les
groupes importants, de nouvelles techniques "scalable" seront nécessaires.
Un exemple de travail actuel dans ce domaine est le Group Key Management
Protocol (GKMP) [HM97].
Comme mentionné dans la Section
4.4.1 "La base de données de la politique de sécurité
(SPD, Security Policy Database), la SPD doit être consultée
pendant le traitement de tout trafic (ENTRANT et SORTANT), ce qui comprend
le trafic non-IP. Si aucune politique correspondant à ce paquet
(soit entrant, soit sortant) n'est trouvée dans la SPD, le paquet
DOIT être jeté.
Remarque : Tous les algorithmes de
cryptographie utilisés dans IPsec sont supposés avoir en
entrée "in canonical network byte order" (voir Annexe de la RFC
791) et génèrent à la sortie "in canonical network
byte order". Les paquets IP sont également transmis "in network
byte order".
5.1 Traitement du trafic
IP sortant
5.1.1 Choisir
et utiliser une SA ou un paquet de SA
Dans une passerelle de sécurité
ou une implémentation BITW (et dans beaucoup d'implémentations
BITS), chaque paquet sortant est comparé avec la SPD pour déterminer
le traitement exigé pour ce paquet. Si le paquet doit être
jeté, c'est un événement auditable. Si on permet au
le trafic de passer le traitement IPsec, le paquet suit ensuite le traitement
"normal" de l'environnement dans lequel le traitement IPsec 1000 a lieu.
Si le traitement IPsec est requis, le paquet est attaché à
une SA (ou paquet de SA) existante, ou une nouvelle SA (ou paquet de SA)
est créé pour ce paquet. Puisque les Sélecteurs d'un
paquet pourraient correspondre à plusieurs politiques ou plusieurs
SA existantes, et puisque la SPD est ordonnée, contrairement à
la SAD, IPsec DOIT:
Dans une implémentation d'hôte
IPsec basée sur les sockets, la SPD sera consultée à
chaque fois qu'une nouvelle socket est créée, pour déterminer
le traitement IPsec, s'il y en a un, à appliquer au trafic qui transitera
par cette socket.
Remarque : Une implémentation
conforme NE DOIT PAS autoriser l'instanciation d'une SA ESP qui utilise
à la fois des algorithmes de chiffrement et d'authentification NULL.
Le fait de négocier une telle SA est un évenèment
auditable.
5.1.2 Construction
de l'entête en mode tunnel
Cette section décrit comment
manipuler les entêtes IP internes et externes, les entêtes
d'extension, et les options des tunnels AH et ESP des tunnels. Ceci inclut
la façon de construire l'entête (externe) IP encapsulé,
la façon de manipuler les champs de l'entête IP interne, et
d'autres manipulations à effectuer. L'idée générale
est modelée d'après celle utilisée dans la RFC 2003,
"IP Encapsulation with IP":
Les tableaux des sous-sections suivantes montre la manipulation
à effectuer sur les champs des différents entêtes ou
options (construit = la valeur du champ externe est construit indépendamment
de la valeur en interne).
5.1.2.1 IPv4 -- Construction de
l'entête en le mode tunnel
<---- Lien en entête interne et externe ---->
1 - La version IP dans l'entête
d'encapsulation peut être différente de la valeur dans l'entête
interne.
2 - Le TTL de l'entête interne
est décrémenté par l'encapsulateur avant l'expédition
et par le décapsulateur s'il fait suivre le paquet (le checksum
change quand TTL change).
Remarque : Décrémenter
le TTL est une des actions habituelles lors de l'expédition d'un
paquet. Les paquets provenant du même noeud que l'encapsulateur n'ont
pas leur TTL décrémenté, car le noeud émetteur
est à l'origine du paquet plutôt qu'il ne le fait suivre.
3 - Les adresse source et destination
dépendent de la SA, qui est utilisée pour déterminer
l'adresse destination afin de déterminer quelle adresse source (interface
réseau) est utilisée pour faire suivre le paquet.
Remarque : En principe, l'adresse IP
source d'encapsulation peut être n'importe laquelle des adresses
d'interface d'encapsulateur ou même une adresse différente
de n'importe quelle adresse IP d'encapsulateur, (par exemple, si elle agit
en tant qu'appareil faisant du NAT) à condition que l'adresse soit
accessible par l'encapsulateur à partir de l'environnement dans
lequel le paquet est envoyé. Ceci ne pose pas de problème
parce qu'IPsec n'a actuellement aucune condition de traitement D'ARRIVÉE
qui implique l'adresse source de l'entête IP d'encapsulation. Ainsi,
tandis que l'extrémité réceptrice du tunnel regarde
l'adresse destination dans l'entête IP d'encapsulation, il regarde
seulement l'adresse source dans l'entête IP (encapsulé) interne.
4 - La configuration détermine
s'il faut copier l'entête interne (uniquement pour IPv4), l'effacer
ou mettre le DF.
5 - Si l'entête interne est IPv4
(Protocole = 4), on copie le TOS. Si l'entête interne est IPv6 (Protocole
= 41), on associe le Class au TOS.
5.1.2.2 IPv6 -- Construction de
l'entête en mode tunnel
Voir la section précédente
5.1.2 pour les notes 1 à 5 indiquées entre parenthèses.
<---- Lien en entête interne et externe ---->
6 - Si l'entête interne est IPv6
(Next Header = 41), on copie le Class. Si l'entête interne est IPv4
(Next Header = 4), on associe le TOS au Class.
5.2 Traitement du trafic
IP entrant
Avant d'exécuter le traitement
AH ou ESP, tous les fragments IP sont rassemblés. Chaque datagramme
IP entrant auquel le traitement IPsec sera appliqué est identifié
par la valeur de AH ou ESP du champ Next Header du protocole IP (ou de
AH ou ESP comme entête d'extension dans IPv6).
Remarque : L'annexe C contient l'exemple
du code pour le contrôle du bitmask pour une fenêtre de 32
paquets qui peut être utilisé pour mettre en application le
service d'anti-rejeu.
5.2.1 Choisir
et utiliser une SA ou un paquet de SA
Faire correspondre un datagramme IP
à la SA appropriée est simplifié grâce au SPI
dans l'entête AH ou ESP. Notez que les vérifica 1000 tions
du sélecteur (selector checks) sont fait sur les entêtes internes,
et non sur les entêtes externes (tunnels). Les étapes à
suivre sont :
1 - Utiliser l'adresse destination
du paquet (entête IP externe), le protocole IPsec, et le SPI pour
trouver la SA dans la SAD. Si la recherche de la SA échoue, jeter
le paquet et rapporter (et loguer) l'erreur.
2 - Utilisez la SA trouvée en
(1) pour effectuer le traitement IPsec, par exemple, authentifiez et déchiffrez.
Cette étape inclut le fait de faire correspondre les sélecteurs
du paquet (entête interne en cas de tunnel) aux sélecteurs
de la SA. La politique locale détermine la spécificité
des sélecteurs de la SA (valeur, liste, intervalle, wildcard simples).
En général, l'adresse source d'un paquet DOIT correspondre
à la valeur du sélecteur de la SA. Cependant, un paquet ICMP
reçu sur une SA en mode tunnel peut avoir une adresse source autre
que les valeurs limites de la SA et de tels paquets devraient être
autorisés comme des exceptions à ce contrôle. Pour
un paquet ICMP, les sélecteurs du paquet incluant le problème
(les adresses source et destination et les ports devraient être permutés)
devraient être comparés avec les sélecteurs de la SA.
Notez que quelques ou tous les sélecteurs peuvent être inaccessibles
en raison des limitations sur combien de bits du paquet posant problème
le paquet ICMP est autorisé à porter ou en raison du chiffrement.
Voir La Section 6.
Faire (1) et (2) pour chaque entête
IPsec jusqu'à ce qu'un entête de protocole de transport ou
un entête IP n'étant PAS pour ce système soit rencontré.
Garder une trace des SA utilisées et de l'ordre dans lequel elles
sont appliquées.
3 - Trouvez une politique entrante
dans la SPD qui correspond au paquet. Cela peut être fait, par exemple,
par l'utilisation de pointeurs inversés (backpointers) de la SA
vers la SPD, ou en faisant correspondre les sélecteurs du paquet
(entête interne en cas de tunnel) avec ceux des entrées de
politique dans la SPD.
4 - Vérifiez si le traitement
IPsec requis a été appliqué, c'est-à-dire vérifiez
que la SA trouvée en (1) et (2) correspond au type et à l'ordre
des SA requises par la politique trouvée en (3).
Remarque : La politique correcte "correspondante"
ne sera pas forcement la première politique entrante trouvée.
Si la vérification du (4) échoue, les étapes (3) et
(4) sont répétées jusqu'à ce que toutes les
entrées de politique aient été vérifiées
ou jusqu'à ce que la vérification soit un succès.
À la fin de ces étapes,
passez le paquet résultant à la couche transport ou expédiez
le paquet. Notez que tous les entêtes IPsec traités dans ces
étapes peuvent avoir été effacés, mais que
cette information, c.-à-d., quelles SAs ont été utilisés
et dans quel ordre elles sont appliquées, peut être nécessaire
pour un traitement IPsec ultérieur ou pour un traitement par un
firewall.
Notez que dans le cas d'une passerelle
de sécurité, si l'expédition entraine la sortie d'un
paquet par une interface IPsec, alors un traitement IPs 1000 ec supplémentaire
peut être appliqué.
5.2.2 Manipulation
des tunnels AH et ESP
La manipulation des entêtes IP
interne et externe, des entêtes d'extension et, des options pour
les tunnels AH et ESP devraient être réalisée comme
décrit dans les tableaux de la Section 5.1.
6. La traitement
d'ICMP (en relation avec IPsec)
Le but de cette section est la manipulation
des messages d'erreur ICMP. Le reste du trafic ICMP, comme l'Echo/Reply,
devrait être traité comme tous les autres flux et peut être
protégé sur la base du end-to-end utilisant des SA de façon
classique.
Un message d'erreur ICMP protégé
par AH ou ESP et produit par un routeur DEVRAIT être traité
et expédié par une SA en mode tunnel. La politique locale
détermine si elle est soumise aux contrôles de l'adresse source
par le routeur à l'extrémité sortante du tunnel. Notez
que si le routeur à l'extrémité entrante du tunnel
fait suivre le message d'erreur ICMP d'un autre routeur, le contrôle
de l'adresse source échouerait. Un message ICMP protégé
par AOH ou ESP et produit par un routeur NE DOIT PAS être expédié
par une SA en mode transport (à moins que la SA n'ait été
établie jusqu'au routeur en tant qu'hôte, comme par exemple,
une connexion Telnet employée pour contrôler un routeur).
Un message ICMP produit par un hôte DEVRAIT être comparé
avec les sélecteurs de l'adresse IP source liés à
la SA à laquelle le message arrive. Notez que même si la source
du message d'erreur ICMP est authentifiée, l'entête IP retourné
pourrait être incorrect. En conséquence, les valeurs de sélecteur
dans l'entête IP DEVRAIENT également être vérifiées
pour être sûres qu'elles sont conformes aux sélecteurs
de la SA par laquelle le message ICMP a été reçu.
Le tableau de l'annexe D caractérisent
les messages ICMP comme étant soit produit par l'hôte, soit
par le routeur, soit par les deux, ou inconnu/non-assigné. Les messages
ICMP entrant dans les deux dernières catégories devraient
être manipulés comme déterminés par la politique
du récepteur.
Un message ICMP non protégé
par AH ou ESP est non-authentifié et son traitement et/ou son expédition
peuvent avoir comme conséquence le déni de service. Ceci
suggère que, en général, il soit souhaitable d'ignorer
de tels messages. Cependant, on s'attend à ce que beaucoup de routeurs
(contrairement aux passerelles de sécurité) n'implémentent
pas IPsec pour le trafic transitant et une adhérence stricte à
cette règle causeraient le rejet de nombreux messages ICMP. Le résultat
serait que quelques fonctions critiques d'IP seraient détruites,
comme par exemple, la redirection et le traitement des PMTU. Ainsi, il
DOIT être possible de configurer une implémentation IPsec
pour recevoir ou rejeter (routeur) le trafic ICMP selon la politique locale
de sécurité.
Le reste de cette section s'intéresse
à comment le traitement des PMTU DOIT être exécuté
par les hôtes et les passerelles de sécuri 1000 té.
Il s'occupe du traitement des messages PMTU ICMP authentifiés et
non-authentifiés. Cependant, comme noté ci-dessus, les messages
ICMP non-authentifiés PEUVENT être jeté sur la base
de la politique locale.
6.1 Traitement des PMTU/DF
6.1.1 Bit
DF
Dans les cas où un système
(hôte ou passerelle) ajoute un entête d' encapsulation (tunnel
ESP ou AH), il DOIT supporter l'option de copie du bit de DF du paquet
initial à l'entête d'encapsulation (et le traitement des messages
PMTU ICMP). Ceci signifie qu'il DOIT être possible de configurer
le traitement système du bit DF (positionnement, effacement, copie
à partir de l'entête encapsulé) pour chaque interface.
(voir l'annexe B pour le raisonnement.)
6.1.2 Path
MTU Discovery (PMTU)
Cette section discute de la manipulation
IPsec pour les messages Path MTU Discovery. le PMTU ICMP est utilisé
ici pour référencer un message ICMP pour :
IPv4 (RFC 792):
IPv6 (RFC 1885):
6.1.2.1 Propagation du PMTU
La quantité d'information retournée
avec le message PMTU ICMP (IPv4 ou IPv6) est limitée et ceci affecte
quels sélecteurs sont disponibles pour l'utilisation de la propagation
avancée de l'information du PMTU. (voir l'annexe B pour une discussion
plus détaillée de ce sujet.)
- Le message PMTU avec 64 bits d'entête
IPsec -- Si le message PMTU ICMP contient seulment 64 bits d'entête
IPsec (minimum pour IPv4), alors une passerelle de sécurité
DOIT supporter les options suivantes pour la base SPI/SA:
a. Si l'hôte d'origine peut être
déterminé (ou si les sources possibles en nombre gérable),
envoyer l'information PM à tous les hôtes d'origine possibles.
- Message PMTU avec plus de 64 bits
d'entête IPsec -- Si le message ICMP contient plus d'information
du paquet initial, alors il peut y avoir assez d'informa 1000 tion non-opaque
pour déterminer immédiatement à quel hôte propager
le message PMTU ICMP et pour fournir à ce système les 5 champs
(adresse source, adresse destination, port source, port destination, protocole
de transport) requis pour déterminer où stocker ou mettre
à jour le PMTU. Dans ce cas, une passerelle de sécurité
DOIT produire un message PMTU ICMP dès la réception d'un
PMTU ICMP .. .. ..(from further down the path).
- Distribuer le PMTU à la couche
Transport -- Le mécanisme de l'hôte pour obtenir et mettre
à jour le PMTU à la couche Transport est inchangée,
comme spécifié dans la RFC 1191 (Path MTU Discovery).
6.1.2.2 Calcul du PMTU
Le calcul du PMTU à partir d'un
PMTU ICMP DOIT prendre en compte l'addition d'un entête IPsec quel
qu'il soit -- AH transport, ESP transport, AH/ESP transport, tunnel ESP,
tunnel AH (voir Annexe B pour les solutions d'implémentation).
Remarque : Dans certaines situations,
l'ajout des entêtes IPsec pourrait avoir comme conséquence
un PMTU efficace (vu par l'hôte ou l'application) qui est trop petit.
Pour éviter ce problème, l'implémentation peut établir
un seuil au-dessous duquel elle n'enregistrerait pas un PMTU réduit.
Dans ces cas-là, l'implémentation appliquerait IPsec et réduirait
ensuite fragmenterait le paquet résultant selon le PMTU. Ceci aurait
comme conséquence une utilisation plus efficace de la largeur de
bande disponible.
6.1.2.3 Granularité du traitement
du PMTU
Dans les hôtes, la granularité
avec laquelle le traitement PMTU ICMP peut être fait diffère
selon la situation de l'implémentation. En regardant un hôte,
il y a 3 situations intéressantes en ce qui concerne les possibilités
du PMTU (voir l'annexe B pour les détails supplémentaires
à ce sujet) :
C'est seulement dans le cas (a) que
les données PMTU pourraient être mises à jour avec
la même granularité que des associations de transmission.
En (b) et (c), la couche IP pourra seulement mettre à jour des données
du PMTU avec la granularité des adresses IP source et destination
(et éventuellement TOS), comme décrit dans la RFC 1191. C'est
une différence importante, parce que plus d'une association de transmission
peut correspondre aux mêmes adresses IP source et destination, et
chaque association de transmission peut avoir une quantité différente
d'entête IPsec supplémentaire (par exemple, en raison de l'utilisation
de différentes transformations ou différents algorithmes).
L'implémentation du calcul du
PMTU et du support des PMTU avec la granularité de différentes
associations de transmission est un probl&eg 1000 rave;me local. Cependant,
une implémentation d'IPsec basée sur les sockets sur un hôte
DEVRAIT mettre à jour l'information sur la base des sockets. La
mémoire annexe (bump) des systèmes par pile DOIT passer le
PMTU ICMP à l'implémentation de l'hôte IP, après
son ajustement à n'importe quel surdébit d'entête d'IPsec
ajouté par ces systèmes. Le calcul du surdébit DEVRAIT
être déterminé par l'analyse du SPI et de n'importe
quelle autre information de sélecteur présents dans un message
PMTU ICMP retourné.
6.1.2.4 Vieillissement du PMTU
Dans tous les systèmes (hôte
ou passerelle) mettant en application IPsec et mettant à jour l'information
de PMTU, le PMTU associé à une association de sécurité
(transport ou tunnel) DOIT "être vieilli" et un mécanisme
doit être mis en place pour mettre à jour le PMTU d'une façon
opportune, particulièrement pour découvrir si le PMTU est
plus petit qu'il ne doit l'être. Un PMTU donné doit rester
en place assez longtemps pour qu'un paquet aille de l'extrémité
source de l'Association de Sécurité au système à
l'autre extrémité de l'Association de Sécurité
et pour qu'il propage en retour un message d'erreur ICMP si le PMTU actuel
est trop grand. Notez que s'il y a les tunnels emboîtés, plusieurs
paquets et des temps de voyage ronds pourraient être exigés
pour recevoir un message ICMP en retour à un encapsulateur ou à
un hôte d'origine.
Les systèmes DEVRAIENT utiliser
l'approche décrite dans le document du Path MTU Discovery (RFC 1191,
Section 6.3), qui suggère un reset périodique du PMTU au
MTU de la liaison de données du premier saut et laisser ensuite
le processus normal du PMTU Discovery agir et mettre à jour le PMTU
si nécessaire. La période DEVRAIT être configurable.
Tous les systèmes implémentant
IPsec n'implémenteront pas l'audit. Pour la plupart, la granularité
de l'audit est un problème locale. Cependant, plusieurs événements
auditables sont identifiés dans les spécifications d'AH et
d'ESP et pour chacun de ces événements, un ensemble minimum
d'information DEVANT être inclus dans les logs d'audit est définie.
De l'information supplémentaire PEUT également être
incluse dans les logs d'audit pour chacun de ces événements,
et des événements supplémentaires, pas explicitement
exigés dans ces spécifications, POURRAIENT aussi entraîner
des entrées dans les logs d'audit. Il n'y a aucune obligation pour
le récepteur de transmettre n'importe quel message à un prétendu
émetteur lors de la détection d'un événement
auditable, à cause de la possibilité d'induire un déni
de service par l'intermédiaire d'une telle action.
8. Utilisation
dans les système supportant la sécurité du flux d'information
De l'information de niveaux de sensibilité
variés peut être transportée par un réseau simple.
Les étiquettes (labels) de l'information (par exemple, inclassable,
Propriété de la société, secret) [DoD85, DoD87]
sont souven 1000 t utilisés pour distinguer ces informations. L'utilisation
des étiquettes facilite la ségrégation de l'information,
comme par les modèles de sécurité du flux de l'information,
par exemple, le modèle Bell-LaPadula [BL73]. De tels modèles,
et leur technologie correspondante, sont conçus pour protéger
le flux non autorisé d'information, même face aux attaques
par chevaux de Troyes. Les mécanismes conventionnels et discrétionnaires
du contrôle d'accès (DAC, Discretionary Access Control), comme
par exemple, basés sur des listes de contrôle d'accès,
ne sont généralement pas suffisants pour supporter de telles
politiques, ainsi, les équipements tels que la SPD ne suffisent
pas dans de tels environnements.
Dans le contexte militaire, la technologie
qui supporte de tels modèles est souvent désigné sous
le nom de sécurité à plusieurs niveaux (MLS, Multi-Level
Security). Les ordinateurs et les réseaux sont souvent indiqués
comme étant "sécurisés à plusieurs niveaux"
s'ils supportent la séparation des données étiquetées
en même temps que des politiques de sécurité du flux
de l'information. Bien qu'une telle technologie soit plus largement utilisable
qu'uniquement pour des applications militaires, ce document utilise l'acronyme
"MLS" pour parler de cette technologie, ce qui est conforme à la
littérature existante.
Les mécanismes IPsec peuvent
facilement supporter les réseaux MLS. Les réseaux MLS exigent
l'utilisation de contrôles d'accès obligatoires forts (MAC),
où les utilisateurs non privilégiés ou les processus
non privilégiés sont incapables de faire du contrôle
ou de la violation. Cette section concerne seulement l'utilisation des
mécanismes de sécurité IP dans des environnements
MLS (politique de sécurité du flux de l'information). Rien
dans cette section ne s'applique aux systèmes ne prétendant
pas fournir de MLS.
Tel qu'il est utilisé dans cette
section, le terme "information de sensibilité" peut inclure des
niveaux hiérarchiques définis lors de l'implémentation,
des catégories, ou/et version d'information (releasability information).
AH peut être utilisé pour
fournir de l'authentification forte pour supporter les décisions
obligatoires de contrôle d'accès dans des environnements MLS.
Si de l'information IP explicite de sensibilité (par exemple, IPSO
[Ken91]) est utilisée et que la confidentialité n'est pas
considérée nécessaire dans un environnement opérationnel
particulier, AH peut être utilisé pour authentifier les liens
entre les étiquettes de sensibilité de l'entête IP
et la charge utile IP (y compris données d'utilisateur). C'est une
amélioration significative par rapport aux réseaux IPv4 étiquetés
où on fait confiance à l'information sensible quoiqu'il n'y
ait aucune authentification ou lien cryptographique entre l'information
et les données IP de l'entête et de l'utilisateur. Les réseaux
IPv4 pourraient ou ne pourraient pas utiliser un étiquetage explicite.
IPv6 utilisera normalement l'information implicite de sensibilité
qui fait partie de l'association de sécurité d'IPsec mais
non transmise par chaque paquet au lieu d'utiliser l'information explicite
de sensibilité. Toute l'information IP explicite de sensibilité
DOIT être authent 1000 ifiée en utilisant par AH, ESP, ou
les deux.
Le chiffrement est utile et peut être
souhaitable même lorsque tous les hôtes sont dans un environnement
protégé, comme par exemple derrière un firewall ou
dépourvu de toute connectivité externe. ESP peut être
utilisé, en même temps que des algorithmes appropriés
de gestion de clefs et de chiffrement, comme DAC et MAC (le choix des algorithmes
de chiffrement et d'authentification, et le niveau d'assurance d'une implémentation
IPsec détermineront les environnements dans lesquels une implémentation
peut être considérée comme suffisante pour répondre
à des exigences de la MLS). La gestion de clefs peut se servir de
l'information de sensibilité pour fournir du MAC. Les implémentations
d'IPsec sur des systèmes prétendant fournir de la MLS DEVRAIENT
être capables d'employer IPsec pour fournir du MAC pour les transmissions
IP.
8.1 Relations entre les
Associations de Sécurité et la sensibilité des données
AH et ESP peuvent tous deux être
combinés avec des politiques appropriées d'association de
sécurité pour arriver à des réseaux sécurisés
à plusieurs niveaux (MLS). Normalement, dans ce cas, chaque SA (ou
paquet de SA) est utilisé pour seulement une instance simple d'information
de sensibilité. Par exemple, "PROPRIÉTAIRES - ingénierie
Internet" doit être associé à une SA (ou paquet de
SA) différente de "PROPRIÉTAIRES - finances".
8.2 Vérification
de la cohérence de la sensibilité
Une implémentation MLS (hôte
et routeur) PEUT associer l'information de sensibilité, ou un intervalle
d'information de sensibilité, avec une interface, ou de adresse
IP configuré avec son préfixe associé (ce dernier
désigné parfois sous le nom d'interface logique, ou d'interface
alias). Si de telles propriétés existent, une implémentation
DEVRAIT comparer l'information de sensibilité associée au
paquet avec l'information de sensibilité associée à
l'interface ou à l'adresse/préfixe à partir duquel
le paquet est arrivé, ou celui par lequel le paquet partira. Ce
contrôle vérifiera soit que les sensibilités correspondent,
soit que la sensibilité du paquet fait partie de l'intervalle de
l'interface ou de l'adresse/préfixe.
Cette vérification DEVRAIT être
faite sur le traitement entrant et sortant.
8.3 Attributs MLS supplémentaires
pour la SAD
La section 4.4 s'est occupé
de deux bases de données d'association de sécurité
(la base de données de politique de sécurité (SPD)
et la base de données d'association de sécurité (SAD))
et des sélecteurs de politique associés et des attributs
de SA. Les réseaux MLS présente un selecteur/attribut supplémentaire:
L'information de sensibilité
aide à choisir les algorithmes appropriés et la longueur
des clefs, de sorte que le trafic obtienne un niveau de la protection en
relation avec son importance ou sa sensibilité comme décr
1000 it dans la section 8.1. La syntaxe exacte de l'information de sensibilité
est définie lors de l'implémentation.
8.4 Etapes supplémentaires
du traitement entrant pour les réseaux MLS
Après qu'un paquet entrant ait
traversé le traitement IPsec, une implémentation de MLS DEAVRAIT
d'abord vérifier la sensibilité du paquet (comme défini
par la SA (ou paquet de SA) utilisée pour ce paquet) avec l'interface
ou l'adresse/préfixe comme décrit dans la section 8.2 avant
de faire suivre le datagramme ou de le livrer au protocole de la couche
supérieure.
Le système MLS DOIT maintenir
la liaison entre les données reçues dans un paquet protégé
par IPsec et l'information de sensibilité de la SA ou les SA utilisées
pour le traitement, ainsi, des décisions appropriées de politique
peuvent être prises en livrant le datagramme à une application
ou en le faisant suivre. Les moyens de mettre à jour cette liaison
sont spécifique à l'implémentation.
8.5 Etapes supplémentaires
du traitement sortant pour les réseaux MLS
Une implémentation IPsec MLS
DOIT exécuter deux contrôles supplémentaires en plus
des étapes normales détaillées dans la section 5.1.1.
En consultant la SPD ou la SAD pour trouver une association sortante de
sécurité, l'implémentation MLS DOIT utiliser la sensibilité
des données pour choisir une SA (ou paquet de SA) sortante appropriée.
Le deuxième contrôle vient avant l'expédition du paquet
vers sa destination, et est le contrôle de cohérence de la
sensibilité décrit dans la section 8.2.
8.6 Traitement MLS supplémentaire
pour les passerelles de sécurité
Une passerelle de sécurité
MLS DOIT suivre les règle de traitement d'entrée et de sortie
précédemment mentionné, mais aussi exécuter
un traitement supplémentaire spécifique à la protection
intermédiaire des paquets dans un environnement MLS.
Une passerelle de sécurité
PEUT agir en tant que proxy de sortie, créant des SA pour les systèmes
MLS qui font suivre des paquets expédiés par la passerelle.
Ces systèmes MLS peuvent explicitement étiqueter les paquets
à expédier, ou l'ensemble du réseau d'origine peut
avoir des caractéristiques de sensibilité associées
à cela. La passerelle de sécurité DOIT créer
et employer les SA appropriées pour AH, ESP, ou les deux, pour protéger
ce trafic qu'il expédie.
De même, une telle passerelle
DEVRAIT accepter et traiter les paquets entrant AH ou/et ESP et les expédier
de façon appropriée, en utilisant un étiquetage explicite,
ou en passant le relais aux caractéristiques de sensibilité
du réseau destination.
L'utilisation d'IPsec impose des coûts
en terme de performance d'exécution sur les hôtes ou les passerelles
de sécurité qui implémentent ces protocoles. Ces coûts
sont associés à la mé 1000 ;moire nécessaire
pour le code et les structures données d'IPsec, et au calcul des
valeurs de contrôle d'intégrité, du chiffrage et du
déchiffrage, et des manipulations supplémentaires pour chaque
paquet. Les coûts de calcul par paquet se manifesteront par une latence
plus importante et probablement une réduction de tout. L'utilisation
d'un protocole de gestion de clefs/SA, particulièrement ceux qui
utilisent la cryptographie à clef public, ajoute également
des coûts de performance d'exécution à l'utilisation
d'IPsec. Ces coûts se manifesteront par l'augmentation de la latence
dans l'établissement d'association. Pour beaucoup d'hôtes,
on prévoit que la cryptographie logicielle ne réduira pas
sensiblement le débit, mais du matériel peut être nécessaire
pour des passerelles de sécurité (puisqu'ils représentent
des points d'agrégation), et pour quelques hôtes.
L'utilisation d'IPsec impose également
des coûts d'utilisation de bande passante pour les composants de
transmission, de commutation, et de routage de l'infrastructure Internet,
composants n'implémentant pas IPsec. C'est dû à l'augmentation
de la taille des paquets résultant de l'ajout des entêtes
AH et/ou ESP, du tunneling AH et ESP (qui ajoute un deuxième entête
IP), et l'augmentation du trafic de paquet associé aux protocoles
de gestion de clefs. On prévoit que, dans la plupart des cas, ce
besoin plus important de bande passante n'affectera pas vraiment l'infrastructure
Internet. Cependant, parfois, les effets peuvent être significatifs,
comme par exemple la transmission de trafic ESP chiffré par une
liaison dialup qui sans ça, aurait compressé le trafic.
Remarque : Le surdébit d'établissement
initiale de la SA sera ressenti dans le premier paquet. Ce retard peut
avoir un impact sur la couche transport et application. Par exemple, il
pourrait faire retransmettre le bit SYN par TCP avant que l'échange
ISAKMP ne soit fait. L'effet de ce retard serait différent sur UDP
parce que TCP ne devrait rien transmettre d'autre que le bit SYN jusqu'à
ce que la connexion soit établie tandis qu'UDP avancera et transmettra
des données au delà du premier paquet.
Remarque : Comme vu plus tôt,
la compression peut encore être utilisé sur les couches au-dessus
d'IP. Il y a un groupe de travail de l'IETF (IP Payload Compression Protocol
(ippcp)) qui travaille sur les "spécifications de protocole qui
permettent la compression sans perte sur différentes charges utiles
avant que la charge utile ne soit traitée par un protocole qui la
chiffre. Ces spécifications laisseront des opérations de
compression s'exécutées avant le chiffrement d'une charge
utile par des protocoles IPsec. "
Tous les systèmes IPv4 prétendant
implémenter IPsec DOIVENT être conformes à toutes les
conditions de ce document d'architecture de sécurité. Tous
les systèmes IPv6 DOIVENT être conformes à toutes les
conditions de ce document d'architecture de sécurité.
11. Considération
sur la sécurité
Le centre d'intérêt de
ce document est la sécurité; par conséquent, les considérations
sur la sécurité sont impré 1000 gnées dans
ces spécifications.
12. Différences
avec la RFC 1825
Ce document d'architecture diffère
sensiblement de la RFC 1825 dans les détails et dans son organisation,
mais les notions fondamentales sont inchangées. Ce document fournit
des détails supplémentaires considérables en termes
de spécifications de conformité. Il présente la SPD
et la SAD, et la notion de Ssélecteurs de SA. Il est en correspondance
avec les nouvelles versions de AH et ESP, qui diffèrent également
de leurs prédécesseurs. Des conditions spécifiques
pour les combinaisons de AH et ESP supportées sont nouvellement
ajoutées, de même que les détails sur la gestion du
PMTU.
Plusieurs des concepts incorporés
dans ces spécifications sont dérivés ou influencés
par le protocole de sécurité SP3 du gouvernement des USA,
les NLSP ISO/IEC, le protocole de sécurité proposé
par swIPe [SDNS, OIN, IB93, IBK93], et le travail effectué pour
la sécurité de SNMP et SNMPv2.
Pendant plus de 3 années (même
si ça semble parfois *beaucoup* plus long), ce document est passé
par plusieurs versions et itérations. Pendant tout ce temps, beaucoup
de gens ont contribué au processus et aux documents eux-mêmes
en apportant des idées significatives et de l'énergie. Les
auteurs voudraient remercier Karen Seo pour avoir apporté une aide
importante dans la relecture, l'édition, la recherche de fond, et
la coordination de cette version des spécifications. Les auteurs
voudraient également remercier les membres des groupes de travail
IPsec et IPng, avec une mention spéciale pour les efforts de (dans
l'ordre alphabétique): Steve Bellovin, Steve Deering, James Hughes,
Phil Karn, Kastenholz franc, Perry Metzger, David Mihelcic, Hilarie Orman,
Shulman normand, William Simpson, Harry Varnis, et Nina Yuan.
Cette section donne des définitions
pour plusieurs mots-clefs utilisés dans ce document. D'autres documents
donne des définitions supplémentaires et des informations
de base en rapport avec cette technologie, comme [VK83, HA94]. Des termes
relatifs aux mécanismes de sécurité ou à la
sécurité en général sont inclus dans ce glossaire,
ainsi que des termes spécifiques à IPsec.
Contrôle d'accès (Access
Control) : Le contrôle d'accès est un service de sécurité
qui prévient l'utilisation non-autorisée d'une ressource,
où l'utilisation d'une ressource d'une façon non-autorisée.
Dans le contexte IPsec, la ressource dont l'accès est contrôlé
est souvent :
Anti-rejeu (Anti-replay) : Voir "Intégrité"
plus bas.
Authentification : Ce terme est utilisé
de façon informelle pour désigner la combinaison de deux
1000 services de sécurité de base distincts, l'authentification
de l'origine des données et l'intégrité en mode non
connecté. Voir les définitions plus bas pour chacun de ces
services.
Disponibilité (Availability)
: La disponibilité, en tant que service de sécurité,
s'intéresse aux attaques contre les réseaux qui bloque ou
dégrade un service. Par exemple, dans le cas d'IPsec, l'utilisation
de mécanismes anti-rejeu dans AH et ESP supporte la disponibilité.
Confidentialité (Confidentiality)
: La confidentialité est le service de sécurité qui
protège les données d'une fuite non-autorisé. La confidentialité
de base concerne dans la plupart des cas la fuite non-autorisé aux
données de la couche application, mais les fuites des caractéristiques
externes de la communication peuvent être concernées dans
certaines circonstances. La confidentialité du flux du trafic est
le service qui s'occupe de ce dernier cas en cachant les adresses source
et destination, la taille des messages, ainsi que la fréquence des
échanges. Dans le cas d'IPsec, utilisant ESP en mode tunnel, surtout
sur une passerelle de sécurité, peut apporter un certain
niveau de confidentialité du flux du trafic (voir aussi "Analyse
du trafic" plus bas).
Chiffrement (Encryption) : Le chiffrement
est un mécanisme de sécurité utilisé pour transformer
les données d'une forme intelligible (texte) en une forme inintelligible
(texte chiffré), pour apporter la confidentialité. La transformation
inverse est appelé "déchiffrage". Souvent, le terme "chiffrement"
désigne les deux procédés.
Authentification de l'origine des données
(Data Origin Authentication) : L'authentification de l'origine des données
est un service de sécurité qui vérifie l'identité
de celui qui se réclame comme la source des données. Ce service
généralement combiné avec le service d'intégrité
en mode non connecté.
Intégrité (Integrity)
: L'intégrité est un service qui s'assure que les modifications
des données sont détectables. L'intégrité vient
de plusieurs façon correspondre avec les bsoins de l'application.
IPsec supporte deux formes d'intégrité : en mode non connecté
et une forme d'intégrité partielle des séquences.
L'intégrité en mode non connecté est un service qui
détecte les modifications sur un paquet IP particulier, sans s'occuper
de la place du datagramme dans le flux de trafic. La forme d'intégrité
partielle des séquences offerte par IPsec désigne l'intégrité
anti-rejeu, et détecte l'arrivée d'un datagramme IP recopié
(au sein d'une fenêtre limitée). Ceci est en opposition avec
l'intégrité en mode orienté-connexion, qui impose
des conditions plus sévère (stringent) sur le séquencement,
comme par exemple d'être capable de détecter les messages
perdus ou réordonnés. Même si l'authentification et
l'intégrité sont souvent citées séparément,
en pratique, elles sont intimement liées et sont toujours offertes
en même temps.
Association de Sécurité
(Security Association, SA) : Une connexion logique simplex (unidirectionnelle),
créée pour des b 1000 esoins de sécurité. Tout
le trafic passant par une SA reçoit le même traitement de
sécurité. Dans IPsec, une SA est une chose abstraite de la
couche Internet implémenté par l'utilisation d'AH ou d'ESP.
Passerelle de sécurité
(Security Gateway) : Une passerelle de sécurité est un système
intermédiaire qui agit comme interface de communication entre deux
réseaux. L'ensemble des hôtes (et des réseaux) du côté
extérieur de la passerelle de sécurité est en ensemble
d'entités en lesquelles on ne peut pas avoir confiance (ou moins
confiance), tandis que les réseaux et les hôtes côté
intérieur sont considérés comme sûrs (ou plus
sûrs). Les sous-réseaux internes et les hôtes servis
par une passerelles de sécurité sont présumés
sûrs grâce à l'administration de sécurité
commune, locale et partagée (voir "Sous-réseaux de confiance"
plus bas). Dans le cas d'IPsec, la passerelle de sécurité
est un point où AH et/ou ESP sont implémentés pour
servir un ensemble d'hôtes internes, en apportant des services de
sécurité à ces hôtes lorsqu'ils communiquent
avec des hôtes externes qui utilisent également IPsec (soit
directement, soit par une autre passerelle de sécurité).
SPI : Acronyme pour "Security Parameters
Index" ou Index des Paramètres de Sécurité. La combinaison
d'une adresse destination, d'un protocole de sécurité et
d'un SPI unique identifie une Association de Sécurité (voir
plus haut). Le SPI est transporté dans les protocoles AH et ESP
pour permettre au système récepteur de choisir la SA sous
laquelle le paquet reçu sera traité. Un SPI a uniquement
une signification locale, tel qu'il est défini par le créateur
de la SA (généralement le récepteur du paquet transportant
le SPI). Ainsi, un SPI est généralement vu comme une suite
opaque de bits. Quoiqu'il en soit, le créateur de la SA peut choisir
d'interpréter les bits du SPI pour faciliter le traitmeent local.
Analyse du trafic (Traffic Analysis)
: L'analyse d'un flux de trafic réseau pour en déduire des
informations est utile pour un adversaire. Les exemples d'information sont
la fréquence des transmissions, les identités des deux parties
en jeu, la taille des paquets, les identificateurs de flux, etc. [Sch94]
Sous-réseau de confiance (Trusted
Subnetwork) : Un sous-réseau contenant des hôtes et des routeurs
ont confiance les uns en les autres pour ne pas engager d'attaques actives
ou passives. Ici aussi, il y a une supposition, qui est que le canal de
transmission (par exemple, un LAN ou un CAN) n'est pas attaqué par
d'autres.
Annexe B
-- Analyse et discussion sur PMTU/DF/Fragmentation
B.1 Le bit DF
Au cas où un système
(hôte ou passerelle) ajoute un entête encapsulé (comme
un tunnel ESP), est-ce que le bit DF du paquet original doit être
copié dans l'entête encapsulé?
Le fait de fragmenter est approprié
dans certaines situations, par exemple, il peut être bon de fragmenter
des paquets sur un réseau ayant un petit MTU, comme par exemple
un réseau de paquets radio, ou po 1000 ur un saut depuis téléphone
cellulaire à un nœud mobile, plutôt que propager avant un
très petit PMTU tout au long du reste du chemin. Dans d'autres situations,
il peut être bon de mettre le bit DF pour obtenir un feedback des
derniers routeurs sur les contraintes du PMTU demandant de la fragmentation.
L'existence de ces deux situations donne une bonne raison de laisser le
système décider s'il doit ou non fragmenter sur une liaison
particulière, c'est-à-dire de demander à une implémentation
d'être capable de copier le bit DF (et de traiter les messages PMTU
ICMP), mais en en faisant une option à choisir à partir d'une
interface de base. En d'autres termes, un administrateur devrait pouvoir
configurer le traitement des routeurs sur les bit DF (donner une valeur,
effacer, copier de l'entête encapsulé) pour chaque interface.
Remarque : Si une implémentation
BITS d'IPsec essaie d'appliquer des algorithmes IPsec différents
basés sur les ports source et destination, il sera difficile d'appliquer
des ajustements du Path MTU.
B.2 Fragmentation
S'il y a lieu, la fragmentation IP
se produit après le traitement IPsec dans une implémentation
d'IPsec. Ainsi, le mode transport d'AH et d'ESP est appliqué seulement
aux datagrammes IP entiers (pas aux fragments IP). Un paquet IP auquel
AH ou ESP a été appliqué peut lui-même être
réduit en fragments par des routeurs au cours de l'acheminement,
et de tels fragments DOIVENT être rassemblés avant le traitement
IPsec du récepteur. En mode tunnel, AH ou ESP est appliqué
à un paquet IP, dont la charge utile peut être un paquet réduit
de fragments IP. Par exemple, une passerelle de sécurité,
une implémentation BITS ou BITW d'IPsec, peut appliquer le mode
tunnel d'AH à de tels fragments. Notez que les implémentations
BITS ou BITW sont des exemples à partir desquels une implémentation
d'hôte IPsec pourrait recevoir des fragments auxquels le mode tunnel
doit être appliqué. Cependant, si le mode transport doit être
appliqué, alors ces implémentations DOIVENT rassembler les
fragments avant d'appliquer IPsec.
NOTE: IPsec doit toujours savoir quels
sont les champs de l'entête IP encapsulé. C'est indépendant
de l'endroit où IPsec est inséré et c'est intrinsèque
à la définition d'IPsec. Toute implémentation IPsec
non intégrée à IP doit inclure le code pour construire
les entêtes nécessaires à IP (par exemple, IP2):
De façon générale,
l'approche par fragmentation/réassembage décrite ci-dessus
fonctionne pour tous les cas a étudiés.
AH Xport AH Tunnel ESP Xport ESP Tunnel
* Si le système par processeur
de crypto a sa propre adresse IP, alors il est couvert par le cas de la
passerelle de sécurité. Cette boîte reçoit le
paquet de l'hôte et exécute le traitement IPsec. Il doit pouvoir
manipuler de la même façon AH, ESP, et le traitement d'un
tunnel IPv4/IPv6 associé qu'une passerelle de sécurité
devrait manipuler. S'il n'a pas sa propre adresse, alors il est semblable
au implémentation BITS entre IP et les drivers réseau.
L'analyse suivante suppose que :
Pour chacune des trois catégories
ci-dessus, il y a IPv4 et IPv6, les modes transport et tunnel de ESP et
de AH -- pour un total de 24 cas (3 x 2 x 4).
Quelques champs d'entête et d'interface
sont énumérés ici pour la facilité de la référence
-- ils ne sont pas dans l'ordre de l'entête, mais plutôt énumérés
pour permettre la comparaison entre les deux colonne. (* = non couvert
par l'authentification AH. L'authentification ESP ne couvrent aucun entête
qui le précède).
Interface IP/Transport
? = AH couvre Option-Type et Option-Length,
mais peut ne pas couvrir Option-Data.
Les résultats des 20 cas est
donné ci-dessous ("works" = fonctionnera si le système fragmente
après le traitement IPsec sortant, réassemble avant le traitement
IPsec entrant). Les notes donne des indications pour l'implémentation.
a. Hôtes (intégré
dans la pile IP)
b. Hôte (BITS) -- met IPsec entre
la couche IP et les drivers réseau. Dans ce cas, le module IPsec
devrait suivre une des propositions suivantes pour la segmentation et le
réassemblage :
Au niveau de la couche réseau,
le module IPsec aura accès aux sélecteurs suivants du paquet
-- adresse SRC, adresse DST, Next Protocol, et s'il y a un entête
de la couche transport --> ports SRC et DST. On ne peut pas supposer qu'IPsec
a accès au Nom. On suppose que les informations disponibles du Sélecteur
sont suffisantes pour retrouver l'e 1000 ntrée de la Politique de
Sécurité et de(s) SA.
o AH-transport
--> (IP1-AH-Transport-Data)
c. Passerelles de sécurité
-- intégrer IPsec dans la pile IP
Remarque : Le module IPsec aura accès
accès aux Sélecteurs suivants du paquet -- adresse SRC, adresse
DST, Next Protocol, et s'il y a un entête transport --> port SRC
et port DST. Il n'aura pas accès au User ID (seuls les hôtes
ont accès au User ID). Contrairement à quelques implémentations
BITS, les passerelles de sécurité peuvent être capable
de retrouver l'adresse source dans le DNS pour avoir un nom de système,
comme par exemple dans le cas où on utilise des adresses IP assignées
dynamiquement avec des entrées DNS dynamiques et mises à
jour. Il n'aura également pas accès aux informations de la
couche transport s'il y a un entête ESP, ou si ce n'est pas le premier
fragment du message fragmenté. On suppose que les informations disponibles
du Sélecteur sont suffisantes pour retrouver l'entrée de
la Politique de Sécurité et de(s) SA.
o AH-tunnel
--> (IP2-AH-IP1-Transport-Data)
**********************************************************************
B.3 Path MTU Discovery
Comme vu plus haut, "PMTU ICMP" désigne
un message ICMP utilisé pour le Path MTU Discovery.
La légende du diagramme plus
bas en B.3.1 et B.3.3 (mais pas B.3.2) est :
==== = SA (AH ou ESP,
transport et tunnel)
IPv4:
IPv6 (RFC 1885):
Hx = hôte
x
B.3.1 Identifier
le ou les hôtes d'origine
L'ensemble des informations renvoyées
par le message ICMP est limité et affecte quels Sélecteurs
sont disponibles pour identifier les SA, les hôtes d'origine, etc.
dans l'utilisation pour la propagation des informations du PMTU.
En bref... Un message ICMP doit contenir
les informations suivantes dans le paquet du problème :
- IPv4 (RFC 792) -- Entête IP
plus un minimum de 64 bits
Par convention, dans le contexte IPv4,
un PMTU ICMP peut seulement identifier la première SA (externe).
Ceci est du au fait que le PMTU ICMP ne peut que contenir 64 bits du paquet
du problème dans l'entête IP, et ne capturerait que le premier
SPI de AH ou de ESP. Dans le contexte IPv6, un PMTU ICMP donnera probablement
tous les SPI et les Sélecteurs dans l'entête IP, mais peut-être
pas les ports SRC/DST (dans l'entête transport) ou les protocoles
encapsulés (TCP, UDP, etc.). De plus, si ESP est utilisé,
les ports transport et les Sélecteurs de protocoles peuvent être
chiffrés.
Regardons le diagramme suivant
d'un tunnel de passerelle de sécurité (comme dit autre part,
les passerelles de sécurité n'utilise pas le mode transport)...
H1
===================
H3
Supposez que la politique de sécurité
pour SG2 est utilisée pour une seule SA vers SG2 pour tout le trafic
entre les hôtes H0, H1 et H2 et les hôtes H3, H4 et H5. Et
supposez que H0 envoie un paquet de données à H5, ce qui
entraîne le fait que R1 envoie un message de PMTU ICMP à SG1.
Si le message PMTU a uniquement le SPI, SG1 sera capable de trouver la
SA et de retrouver la liste des hôtes possibles (H0, H1, H2, wildcard);
mais SG1 n'aura aucun moyen de trouver que H0 a envoyé le flux contenant
le message PMTU ICMP.
paquet original
après traitement IPsec paquet ICMP
(*) Les 64 bits incluront une partie
suffisante de l'entête ESP (ou AH) pour inclure le SPI.
Cette limitation des informations renvoyées
avec un message ICMP pose un problème pour identifier les hôtes
d'origine du paquet (donc pour savoir à qui propager l'information
PMTU ICMP). Si le message ICMP contient seulement 64 bits d'entête
IPsec (minimum pour IPv4), alors les Sélecteurs IPsec (par exemple
adresses source et destination, Next Protocol, ports source et destination,
etc.) seront perdus. Mais le message d'erreur ICMP donnera toujours SG1
avec le SPI, les informations PMTU et les passerelles source et destination
pour la SA associée.
La passerelle de sécurité
destination et le SPI définissent de façon unique une association
de sécurité pour définir un ensemble d'hôtes
d'origine possibles. Dans ce cas, SG1 pourrait :
Etant donné que seule la deuxième
approche est faisable dans tous les cas, une passerelle de sécurité
DOIT donner une telle possibilité en option. Quoiqu'il en soit,
si le message ICMP contient plus d'informations du paquet original, alors
on aura peut-être suffisamment d'informations pour déterminer
immédiatement l'hôte à qui on doit envoyer le message
PMTU ICMP et pour trouver ce système avec les 5 champs (adresse
source, adresse destination, port source, port destination, et protocole
de transport) nécessaires pour déterminer l'endroit où
stocker ou mettre à jour le PMTU. Dans ce cas, une passerelle de
sécurité DOIT générer un message PMTU ICMP
immédiatement après la réception d'un PMTU ICMP d'un
accès. Remarque : Le champ Next Protocol peut ne pas être
présent dans le message ICMP et l'utilisation du chiffrement ESP
peut cacher les champs du Sélecteur qui ont été chiffrés.
B.3.2 Calcul
du PMTU
Le calcul du PMTU à partir d'un
PMTU ICMP doit prendre en compte l'addition d'un éventuel entête
IPsec par H1 -- mode transport ou tunnel AH et/ou ESP. A partir d'un hôte
unique, plusieurs applications peuvent partager un SPI et un problème
de SA peut subvenir (Voir Section 4.5 "Combinaisons de base pour les SA"
1000 pour une description des combinaisons qui doivent être supportées).
Le diagramme suivant illustre un exemple de SA entre deux hôtes (telle
qu'elle est vu par l'un des hôtes). (ESPx ou AHx = mode transport)
Socket 1 -------------------------|
Pour retrouver le PMTU de chaque socket
qui correspond à SPI-B, il sera nécessaire d'avoir des pointeurs
de retour de SPI-B vers chacun des deux accès pour y parvenir --
Socket 1 et Socket 2/SPI-A.
B.3.3 Granularité
du maintien des données PMTU
Dans les hôtes, la granularité
avec laquelle le le traitement ICMP PMTU peut être exécuté
diffère en fonction de la situation d'implémentation. En
regardant l'hôte, il y a trois situations d'intérêt
en respect des règles du PMTU :
C'est seulement dans le cas (a) où
les données du PMTU pourraient être mises à jour avec
la même granularité que les associations de communication.
Dans les autres cas, la couche IP mettra à jour les données
du PMTU avec la granularité des adresses IP source et destination
(et sur option les TOS/Class), comme décrit dans la RFC 1191. C'est
une différence importante, parce que plus d'une association de communication
peuvent correspondre aux mêmes adresses IP source et destination,
et chaque association de communication peut avoir une quantité différente
d'entête IPsec supplémentaire (par exemple, en raison de l'utilisation
de différentes transformations ou différents algorithmes).
Les exemples ci-dessous illustrent ceci.
Dans les cas (a) et (b)... Supposez
que vous avez la situation suivante. H1 envoie à H2 et le paquet
à envoyer de R1 à R2 excède le PMTU du réseau
entre les deux.
==================================
Si R1 est configuré pour ne
pas fragmenter le trafic des abonnés, alors R1 envoie un message
PMTU ICMP avec le PMTU approprié à H1. Le traitement de H1
change selon le type d'implémentation. Dans le cas (a) (IP natif),
les services de sécurité seraient liés aux sockets
ou équivalent. Ici, l'implémentation d'IP/IPsec dans H1 peut
stocker ou mettre à jour le PMTU pour la socket associée.
Dans le cas (b), la couche IP de H1 peut stocker ou mettre à jour
le PMTU mais seulement avec la granularité des adresses source et
destination et probablement du TOS/Class, comme vu ci-dessus. Ainsi le
résultat peut être sub-optimal, puisque le PMTU pour un SRC/DST/TOS/Class
donné sera la soustraction de la plus grande taille d'entête
IPsec utilisée pour n'importe quelle association de communication
entre une source et une destination données.
Dans le cas (c), il doit y avoir une
passerelle de sécurité pour avoir un traitement IPsec. Supposez
ainsi que vous avez la situation suivante. H1 envoie à H2 et le
paquet à envoyer de SG1 à R excède le PMTU du réseau
qui les sépare.
================
Comme décrit ci-dessus pour
le cas (b), la couche IP de H1 peut stocker ou mettre à jour le
PMTU mais seulement avec la granularité des adresses source et destination,
et probablement le TOS/Class. Ainsi le résultat peut être
sub-optimal, puisque le PMTU pour un SRC/DST/TOS/Class donné sera
la soustraction de la plus grande quantité d'entête d'IPsec
utilisée pour n'importe quelle association de communication entre
une source et une destination données.
B.3.4 Maintenance
par socket des données PMTU
L'implémentation du calcul du
PMTU (Section B.3.2) et le support des PMTU à la granularité
d'"associations de communication" individuelles (Section B.3.3) est un
problème local. Cependant, une implémentation IPsec sur un
hôte basée sur les sockets DEVRAIT garder l'information pour
chaque socket. Les systèmes BITS DOIVENT passer un PMTU ICMP à
l'implémentation IP hôte, après l'avoir ajusté
pour un tout entête IPsec ajouté par ces systèmes.
La détermination de ce surplus DEVRAIT être déterminée
par l'analyse du SPI et de toute information de Sélecteur présente
dans le message PMTU ICMP renvoyé.
B.3.5 Livraison
des données PMTU à la c 1000 ouche transport
Le mécanisme hôte pour
mettre à jour le PMTU dans la couche transport est inchangé,
comme spécifié dans la RFC 1191 (Path MTU Discovery).
B.3.6 Durée
de vie des données PMTU
Ce sujet est vu dans la Section 6.1.2.4.
Annexe C
-- Exemple de code pour la fenêtre d'espace des séquences
Cette annexe contient une routine qui
implémente une vérification du bitmask pour une fenêtre
de 32 paquets. Elle est apportée par James Hughes (jim_hughes@stortek.com)
et Harry Varnis (hgv@anubis.network.com) et est un exemple d'implémentation.
Notez que ce code teste à la fois le rejeu et les mises à
jour de la fenêtre. Aussi, l'algorithme, tel qu'il est, devrait être
appelé uniquement APRES que le paquet a été authentifié.
Ceux qui implémentent pourraient vouloir étudier la possibilité
de découper le code pour effectuer la vérification de rejeu
avant de calculer l'ICV. Si le paquet n'est pas un rejeu, le code calculerait
alors l'ICV, (jetant tous les mauvais paquets), et si le paquet est OK,
on met à jour la fenêtre.
#include <stdio.h>
enum {
u_long bitmap = 0;
/* session state - must be 32 bits */
/* Returns 0 if packet disallowed,
1 if packet permitted */
int ChkReplayWindow(u_long seq)
{
if (seq ==
0) return 0;
/* first == 0 or wrapped */
char string_buffer[512];
#define STRING_BUFFER_SIZE sizeof(string_buffer)
int main() {
printf("Input
initial state (bits in hex, last msgnum):\n");
while (1)
{
Annexe D
-- Catégories des messages ICMP
IPv4
Type Nom/Codes
Référence
Type Nom/Codes
Référence
Type Nom/Codes
Référence
Type Nom/Codes
Référence
IPv6
Type Nom/Codes
Référence
Type Nom/Codes
Référence
Type Nom/Codes
Référence
[BL73] Bell, D.E. & LaPadula, L.J.,
"Secure Computer Systems : Mathematical Foundations and Model", Technical
Report M74-244, The MITRE Corporation, Bedford, MA, May 1973.
[Bra97] Bradner, S., "Key words for
use in RFCs to Indicate Requirement Level", 1000 BCP 14, RFC 2119, March
1997.
[DoD85] US National Computer Security
Center, "Department of Defense Trusted Computer System Evaluation Criteria",
DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985.
[DoD87] US National Computer Security
Center, "Trusted Network Interpretation of the Trusted Computer System
Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense,
Ft. Meade, MD., 31 July 1987.
[HA94] Haller, N., and R. Atkinson,
"On Internet Authentication", RFC 1704, October 1994.
[HC98] Harkins, D., and D. Carrel,
"The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HM97] Harney, H., and C. Muckenhirn,
"Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[ISO] ISO/IEC JTC1/SC6, Network Layer
Security Protocol, ISO-IEC DIS 11577, International Standards Organisation,
Geneva, Switzerland, 29 November 1992.
[IB93] John Ioannidis and Matt Blaze,
"Architecture and Implementation of Network-layer Security Under Unix",
Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993.
[IBK93] John Ioannidis, Matt Blaze,
& Phil Karn, "swIPe: Network-Layer Security for IP", presentation at
the Spring 1993 IETF Meeting, Columbus, Ohio
[KA98a] Kent, S., and R. Atkinson,
"IP Authentication Header", RFC 2402, November 1998.
[KA98b] Kent, S., and R. Atkinson,
"IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[Ken91] Kent, S., "US DoD Security
Options for the Internet Protocol", RFC 1108, November 1991.
[MSST97] Maughan, D., Schertler, M.,
Schneider, M., and J. Turner, "Internet Security Association and Key Management
Protocol (ISAKMP)", RFC 2408, November 1998.
[Orm97] Orman, H., "The OAKLEY Key
Determination Protocol", RFC 2412, November 1998.
[Pip98] Piper, D., "The Internet IP
Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[Sch94] Bruce Schneier, Applied Cryptography,
Section 8.6, John Wiley & Sons, New York, NY, 1994.
[SDNS] SDNS Secure Data Network System,
Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989,
published in NIST Publication NIST-IR-90-4250, February 1990.
[SMPT98] Shacham, A., Monsour, R.,
Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)",
RFC 2393, August 1998.
[TDG97] Thayer, R., Doraswamy, N.,
and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[VK83] V.L. Voydock & S.T. Kent,
"Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol.
15, No. 2, June 1983.
Les points de vue et les spécifications
exprimés dans ce document sont ceux des auteurs et ne sont pas nécessairement
ceux de leurs employeurs. Les auteurs et leurs employeurs démentent
spécifiquement la responsabilité de tous les problèmes
résultant de l'implémentation ou de l'utilisation correcte
ou incorrecte de ce concept.
Information
concernant ac5 les auteurs
Copyright (C) The Internet Society
(1998). Tous droits réservés.
This document and translations of it
may be copied and furnished to others, and derivative works that comment
on or otherwise explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this document
itself may not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages other than
English.
The limited permissions granted above
are perpetual and will not be revoked by the Internet Society or its successors
or assigns.
This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.0
|
|
|
|
|