Dans le combat qui oppose les technologies économiques aux technologies de qualité, IP constitue le cheval de bataille des petits et moyens budgets. Dès lors, on essaie d'utiliser ce ``couteau suisse'' afin d'atteindre des objectifs - en apparence - dignes d'un gros-oeuvre, tels que la téléphonie, la diffusion vidéo ou radio, ou encore les réseaux privés étendus (de type WAN), etc, qui restaient les fiefs de technologies bien plus coûteuses, comme ATM, X25, le RTC, le RNIS, le réseau hertzien, les satellites... Le pari IP tient-il de l'audace ou de l'extravagance ? Dans le cadre des réseaux privés, comme souvent sur Internet, de nombreuses solutions - incompatibles et non standardisées - ont été initialement développées (et continuent de l'être !) sans concertations mutuelles. Quelques directions sont désormais tracées dans cet espace ; PPTP, L2TP, TLS, SSL et SSH en font parties. Une autre de ces directions commence à acquérir de la valeur : IPsec. Cette étude va se focaliser sur l'utilisation d'IPsec pour la constitution de réseaux privés virtuels impliquant des utilisateurs dotés d'une mobilité réduite - i.e. sans support du ``hand-over'' - et appelés ``télétravailleurs''. IPsec en mode tunnel est évidemment au premier plan, mais ses capacités sont trop limitées pour faire face à la complexité du problème : il est épaulé par d'autres protocoles spécialement conçus ou mis à niveau pour l'occasion, notamment PIC [6], DHCPv4 [5] et L2TP [9]. Interviennent aussi d'autres systèmes, comme des autorités de certifications ou des serveurs d'authentification. Tous ces points seront abordés ici mais, avant tout, il convient de préciser les sources d'informations qui ont été utilisées. De nombreux logiciels proposent déjà des implémentations d'IPsec pour le télétravail, mais leur compatibilité n'est pas assurée. Une information moins spécifique et moins propriétaire devait constituer la base de ce rapport. Pour cette raison, une attention particulière a été portée sur les travaux de standardisation du groupe IPSRA (IPsec Remote Access) de l'IETF. Ce groupe a produit trois drafts à ce jour, [2], [5] et [6], qui apportent de nombreuses précisions sur des points spécifiques. Les personnes les plus impliquées dans ces travaux sont Bernard Aboba (Microsoft) et Scott Kelly. Par ailleurs, le RFC 2401 [1], ``Architecture de Sécurité pour IP'' et les livres [3], [4] précisent comment est perçu l'accès distant d'un point de vue général, quels sont les besoins auxquels il doit répondre, et comment il doit s'intégrer à la stratégie de sécurité pré-existante de l'entreprise. Les scénarios d'accès distant [2], les protocoles utilisés ([5] et [6]), les entités réseaux nécessaires ([2] et [6]), seront les objets successivement abordés dans cette analyse. Comme le processus de standardisation en est encore à ses balbutiements, nous étudierons la solution adoptée par Cisco et Microsoft dans leurs implémentations. En effet, cette solution bénéficiera d'une diffusion exceptionnelle auprès des entreprises et du public, et ne peut donc être ignorée.
Dans ce scénario, décrit dans [2], les télétravailleurs utilisent un modem (rtc, rnis, dsl, câble...) pour accéder à une ressource distante. IPsec est intégré au poste de l'utilisateur.
Accès par Modem Remarque: Au lieu d'intégrer IPsec dans le poste client, il est possible d'utiliser une passerelle de sécurité entre le poste client et le modem (cela est très fréquent pour les connexions dsl ou câble). Cela ne fait que déplacer le problème, car la passerelle de sécurité ainsi introduite se comporte à l'image d'un client vis à vis de la ressource distante à accéder. Cependant, cette passerelle se justifie dans un scénario 'agence satellite' (solution ``Satellite-Office - Home-Office'' (SOHO)), ou lorsque les besoins de performances nécessitent l'utilisation d'un appareil spécialisé comportant une pile IPsec dite ``Bump In The Wire'' (BITW). Le télétravail nécessite de la part de l'utilisateur nomade de s'authentifier auprès de la passerelle de sécurité de son entreprise. La table suivante résume les besoins en terme d'authentification (quel que soit le protocole utilisé pour y parvenir) dans ce scénario (voir [2] pour plus de précisions) :
Considérations Politiques et Stratégiques
Commentaires
Les risques rencontrés :
Risque N°1
Un Cheval de Troie a pris le contrôle total du client ; la sécurité est compromise et il n'y a pas de solution standard. Il est important de noter que ce risque existe notamment par le fait que le poste client a accès à Internet, et peut donc télécharger des codes hostiles. Une disquette ou un cdrom peut aussi contenir un tel programmme. Le troyen peut alors accéder via la connexion sécurisée au réseau privé de l'entreprise, s'y propager, y récupérer des données qu'il renverra directement sur Internet depuis le client (en simultané si la connexion Internet n'est pas désactivée pendant la connexion sécurisée, sinon en différé), via la passerelle Internet de l'entreprise, ou au travers de canaux cachés (par exemple en envoyant un mail ou en effectuant des requêtes DNS fantaisistes).
Risque N°2
Un intrus utilise la connexion de l'utilisateur. La re-authentification périodique permet de rompre la connexion avec l'intrus.
Risque N°3
Les données d'accréditation de l'utilisateur (mot de passe, jeton d'accès...) peuvent être subtilisées par un intrus. L'emploi de mots de passe fréquemment renouvelés, de données d'accréditation avec des durées de vie faibles, limitent les conséquences d'une telle situation: le pirate n'obtiendra qu'un accès temporaire (cela peut cependant lui permettre d'ouvrir des brèches permanentes). Par ailleurs, soulignons que s'il est interdit d'établir deux connexions simultanées avec les mêmes données d'accréditation, alors soit l'utilisateur peut se connecter, et le pirate ne le peut, soit le pirate est connecté, ce qui empêche l'utilisateur de se connecter et permet donc de suspecter la présence d'un intrus.
Risque N°4
Des mécanismes peuvent interagir avec IPsec (NAPT notamment). Il convient de s'assurer que ces mécanismes ne compromettent pas la connectivité. Ce risque ne relève pas de la sécurité du service, mais plutôt de sa disponibilité ou de sa sûreté.
Dans ce scénario, le télétravailleur se connecte depuis un réseau A pour accéder à une ressource distante située dans un réseau B. Pour plus de précisions, [2] décline ce scénario en trois versions dans ses sections 3.2, 3.3 et 3.4.
Accès depuis un réseau Les associations de sécurité se font, au choix :
i) Entre les extrémités (client <-> serveur)
Les modes d'authentification sont dans ce cas similaires à ceux décrits dans le premier scénario.
ii) Entre le télétravailleur et la passerelle de sécurité du réseau distant (PB)
Seul le trafic télétravailleur <-> serveur est alors autorisé par PB. Les modes d'authentification sont similaires à ceux décrits dans le premier scénario. Dans ce type de scénario, le réseau B est généralement supposé ``de confiance'', alors que le réseau A, d'où se connecte le télétravailleur, n'est pas sûr. L'association de sécurité décrite ici assure, sous ces hypothèses, un niveau de sécurité suffisant.
iii) Entre les passerelles de sécurité des deux réseaux
Seul le trafic télétravailleur <-> serveur est autorisé. Le niveau de sécurité réel dépend fortement de celui du réseau A. Notamment, il faut déterminer au niveau de quelle passerelle et via quel protocole se fait l'authentification de l'utilisateur, et il serait plus sûr de sécuriser le lien entre le télétravailleur et PA ; le réseau B doit donc avoir une certaine confiance dans les mécanismes de sécurité du réseau A, et plus particulièrement en PA ; en matière de sécurité, ce cas est déjà complexe et peut mener à des failles. En revanche, une telle association de sécurité posera moins de problèmes d'incompatibilités avec le NAT que les deux solutions précédentes. Remarque: Dans ce scénario, il est possible de considérer une unité administrative du réseau A comme un ensemble de télétravailleurs autorisés, auquel cas une politique de sécurité peut être définie pour chaque machine et/ou utilisateur de l'unité administrative. Il est aussi possible d'isoler cette unité administrative (via une passerelle de sécurité, un VLAN...).
Considérations Politiques et Stratégiques
Risques
Les risques majeurs rencontrés dans ce scénario sont de type opérationnels : suivant si les adresses des machines sont routables, suivant s'il existe des mécanismes de translation d'adresse, suivant si les protocoles d'IPsec sont filtrés sur des noeuds intermédiaires, l'établissement des associations de sécurité pourra être difficile ou compromis. Remarque: Ce scénario englobe tout un ensemble de cas : coopération entre départements A et B d'entreprises, prestataire avec un ordinateur de bureau du site A, intervenant pourvu de son propre portable, etc (voir [2], sections 3.3 et 3.4). Quand la machine cliente est originellement issue du site B (cas d'un ordinateur portable), on pourrait se contenter d'effectuer une authentification de la machine et non de l'utilisateur. En réalité, il faut aussi considérer que le portable peut être utilisé à l'insu de son propriétaire ; l'authentification de l'utilisateur, si possible renouvelée périodiquement, est donc préférable.
Dans ce scénario, le télétravailleur se connecte depuis un terminal d'un réseau public pour accéder à une ressource distante située dans un réseau privé. Remarque: [2] présente ce scénario ainsi que le suivant dans une seule section (3.5). Or le présent rapport est plus concerné par la vision opérateur de l'accès distant, ce qui a nécessité une séparation plus explicite, en deux parties
Connexion depuis un terminal du réseau public Dans ce scénario, on ne peut avoir confiance en la machine cliente. L'authentification ne se fera donc pas sur l'identité de la machine mais sur celle de l'utilisateur. Il convient de noter que la machine cliente peut observer les mots de passe, modifier les données saisies par l'utilisateur et maintenir des connexions ouvertes.
Par conséquent
Remarque: Concernant l'utilisation d'IPsec dans ce scénario, cela n'est possible que si celui-ci est disponible sur la machine cliente. Mais encore une fois, il n'y a aucune garantie quand au niveau de confiance que l'on peut avoir en cette machine. De plus, la configuration locale d'IPsec risque d'être contradictoire avec celle du réseau privé : si le réseau public utilise le NAT et propose le mode tunnel alors que le réseau privé n'accepte que le mode transport, la négociation de ISAKMP échouera.
Audit
Comme pour le scénario précédent, il convient d'archiver les caractéristiques des connexions (dates de début et de fin, utilisateur, machines et données impliquées, etc). De plus, le client doit explicitement et périodiquement maintenir l'état de la connexion.
Les Problèmes Majeurs
Comme dans le scénario précédent, dans ce scénario, le télétravailleur se connecte depuis un terminal d'un réseau public pour accéder à une ressource distante située dans un réseau privé. La différence avec le scénario précédent est que l'opérateur de réseau public est ici un partenaire de confiance (un contrat lie les deux entités).
Connexion depuis un opérateur public de confiance Dans ce cas, la machine cliente est de confiance. On peut donc effectuer une authentification conjointe de la machine et du client. De plus, l'utilisation d'un mot de passe statique devient tolérable, par exemple en utilisant PIC (voir plus bas) pour construire un canal sécurisé entre le client et la passerelle de sécurité. En revanche, limiter la durée de la connexion et effectuer des vérifications périodiques de l'identité de l'utilisateur restent indispensables.
Audit
Comme dans le scénario 3, il convient d'archiver les caractéristiques des connexions (dates de début et de fin, utilisateur, machines et données impliquées, etc). Le client doit explicitement et périodiquement maintenir l'état de la connexion.
PIC est l'acronyme de ``Pre-IKE Credential'' ; il est décrit dans le draft [6]. Grâce à ce protocole, le télétravailleur peut obtenir des jetons ou des certificats temporaires qui lui permettront de négocier une association de sécurité avec une passerelle de sécurité. PIC a été conçu pour s'intégrer au mieux dans le système de sécurité pré-existant de l'entreprise.
Architecture d'exploitation de PIC Le schéma ci-dessus décrit dans quel existant PIC s'intègre. Une entreprise désire fournir un service d'accès distant sécurisé avec IPsec, et dispose donc d'une passerelle de sécurité (à droite sur le schéma) donnant accès aux services de son réseau privé. Cette passerelle est en mesure d'établir des associations de sécurité en utilisant IKE. Aucune hypothèse n'est faite sur la machine cliente (sauf, bien sûr, la présence des protocoles indispensables !), et c'est donc l'utilisateur qui sera authentifié. Malheureusement, IKE ne permet pas l'authentification d'une extrémité par un simple mot de passe. C'est à ce niveau que PIC intervient. PIC est en réalité une version allégée du couple ISAKMP/IKE, et augmentée de quelques caractéristiques, plus précisément de ``payloads'' EAP ( Extended Authentication Protocol ). Par l'entremise de PIC, l'utilisateur va obtenir un certificat qui lui permettra de négocier par IKE une association de sécurité avec la passerelle de sécurité. Pour cela, dans un premier temps, l'utilisateur se connecte à un serveur PIC. Ce dernier achemine les données d'authentification de l'utilisateur auprès d'un serveur d'authentification (de type Radius ou Diameter, qui garde notamment une trace de la transaction). Si l'authentification réussit, le serveur PIC renvoie un jeton/certificat à l'utilisateur, qui lui permettra d'entamer une négociation via IKE avec la passerelle de sécurité, en utilisant son adresse IP actuelle comme identité. Remarque: Le scénario précédent peut être enrichi en fonction des éléments pré-existants du réseau ; notamment, le serveur PIC peut être connecté à un serveur spécialisé en tant qu'autorité de certification et l'utiliser, après une authentification réussie de l'utilisateur, pour générer un certificat temporaire.
Les échanges du protocole
Le schéma suivant présente les échanges du protocole. Ils ressemblent fortement à la mise en oeuvre d'un mode agressif avec ISAKMP/IKE. Comme souvent dans ce type d'échange, deux messages (II' et I) sont introduits pour prévenir un déni de service et/ou pour protéger les identités des acteurs. Le champ Nrc créé par le récepteur dans le message II' s'appelle ``Routability Cookie'' et a pour but de vérifier que l'initiateur est bien joignable sur Internet. Pour cette raison, ce cookie est renvoyé en confirmation dans le message I (ce qui n'est pas le cas pour les ``Nonces'' Ni et Nr). Le serveur peut décider d'utiliser ou non ce système de cookies, et donc choisir entre un échange à six ou à quatre messages, en fonction de sa charge.
Les échanges de PIC (client - serveur PIC) Concernant les payloads transportés dans l'échange, quelques précisions complémentaires s'imposent ; certains payloads sont en effet définis pour la première fois dans le draft de PIC [6] :
En conclusion, PIC répond a un besoin précis et a été conçu de façon à s'intégrer en souplesse avec les solutions de sécurité existantes. En revanche, la relative maturité du draft (cinquième version) peut être menacée par l'émergence prochaine d'une nouvelle version de IKE (laquelle risque de s'accompagner de modifications majeures de ISAKMP).
Le groupe IPSRA a émis un draft [5] concernant les mises à jour à effectuer sur DHCPv4 pour une utilisation en mode tunnel dans le cadre de l'accès distant. En effet, les scénarios présentés précédemment (issus de [2]), nécessitent un tel protocole pour la configuration de la machine cliente. Ce draft, qui en est tout de même à sa treizième version, se réfère aux besoins des scénarios d'accès distants pour la configuration à distance, plus précisément :
Paramètres de configuration distante
Tous ces pré-requis, qualifiés de ``basiques'' dans le draft, sont déjà pris en charges par DHCPv4, au contraire d'autres solutions, comme IKECFG (dont le draft a expiré). En revanche, pour une utilisation plus ``avancée'', DHCPv4 doit être mis à niveau :
L'objet de [5] est surtout de définir un processus d'utilisation des différents protocoles impliqués dans le scénario d'accès distant : IKE, ISAKMP, IPsec, DHCPv4, etc. Le scénario standard décrit dans le draft se décompose en trois étapes :
A l'issue de ces étapes, le client est configuré et accède de façon sécurisée et transparente à son réseau. En conclusion, DHCPv4 est la solution la plus cohérente, et la plus transparente pour l'existant de l'entreprise si ce protocole est déjà utilisé localement pour la configuration des machines. L'administration aussi s'en voit simplifiée (administration commune du serveur DHCP pour les deux contextes local et distant).
Nous avons pu remarquer un certain nombre de points communs dans les scénarios présentés ; notamment :
Il faut aussi souligner les absences ou les manques des solutions présentées :
La place de l'opérateur
Cette étude a permis d'établir quelques scénarios dans lesquels un opérateur peut s'intercaler pour fournir un service à valeur ajoutée :
En Novembre 2001, un document écrit conjointement par des équipes de Microsoft et de Cisco a acquis le statut de RFC 3193 [7]; Ce RFC décrit l'utilisation de L2TP au-dessus d'IPsec et constitue la fondation de la solution d'accès distant de ces deux entreprises [8].
L2TP: Utilisation et Encapsulation Le document [7] est particulièrement obscur en ce qui concerne le contexte d'utilisation de L2TP sur IP. C'est en réalité parfaitement normal: les RFCs 2661 [9] et 2888 [10] traitent déjà de ces sujets. Le cas le plus général est présenté sur le schéma ci-dessus: le couple (L2TP,IPsec) y est utilisé pour acheminer un trafic PPP entre un relais, aussi appelé ``LAC'' (L2TP Access Concentrator), auquel est connecté un client, et un serveur PPP. Dans le cas qui nous intéresse, la connexion entre le relais et le serveur se fait sur Internet, d'où l'intérêt d'utiliser IPsec pour procéder à une authentification par paquet et à une vérification d'intégrité. En effet, la couche de sécurité de PPP ne fournit qu'une authentification initiale (à la connexion), et du chiffrement (en utilisant l'extension ``PPP Encryption Control Protocol (ECP)''); les caractéristiques de sécurité des deux protocoles se complètent donc bien. En revanche le trafic Client - Relais est faiblement sécurisé. Dans le cadre de la solution d'accès distant fournie par Microsoft et Cisco, le Client et le Relais sont une seule et même machine. Voyons en quoi cela permet de construire un réseau privé virtuel:
En réalité, cette méthode d'accès distant sécurisé s'inscrit dans une forme de tradition : L'accès distant se faisait avant par modem sur un RAS (``Remote Access Server'', aussi appelé ``L2TP Network Server (LNS)'' dans le contexte L2TP) de l'entreprise, qui allouait au client une adresse IP du domaine privé via PPP. La couche de sécurité était alors liée à l'utilisation du réseau téléphonique, jugé sûr. Cet aspect ``traditionnel'' de cette solution pourrait jouer en sa faveur. Malheureusement, elle introduit des effets de bords néfastes, conséquences inévitables d'un processus d'encapsulation lourd (voir pile de protocoles ci-dessus) : pour un client classique (modem RTC), l'encapsulation, pour du trafic http, sera: "données" -> http -> tcp -> IP -> PPP -> L2TP -> UDP -> IPsec -> PPP -> RTC.
Il est intéressant d'observer comment Microsoft et Cisco mènent la standardisation de cette solution en parallèle avec son implémentation et son déploiement. L2TP [9] est devenu un RFC en août 1999, et il s'agissait déjà d'une publication conjointe Cisco-Microsoft. Un an plus tard, la solution d'accès distant était disponible dans Windows 2000 (ce qui implique que l'implémentation était déjà en cours en 1999) et en même temps sortait le RFC 2888 -"Secure Remote Access with L2TP" [10]- qui, curieusement, n'a pas été produit par Microsoft ou Cisco. Enfin, le dernier pas a été franchi en novembre 2001 avec le RFC 3193 [7]. Quelle que soit la qualité de cette solution, le poids des acteurs fait qu'elle sera omniprésente. Cela ne signifie pas qu'il n'y en aura pas d'autres, ni même que ce sera la meilleure. Personnellement, j'y vois deux intérêts majeurs: sa disponibilité justement, et l'utilisation de PPP, qui s'inscrit dans la tradition de l'accès distant, et permet donc de maintenir des structures uniques (serveurs PPP) pour les clients qui se connectent via Internet et pour ceux qui se connectent directement via le RTC. J'y vois aussi un inconvénient majeur: cette solution dessine un fossé entre l'accès distant et Internet, qui sert en fait de medium. En ignorant les caractéristiques de IP, elle provoque un empilage conséquent de couches de protocoles. Une solution plus légère et plus cohérente avec l'usage d'IP peut être construite, en faisant fi de l'héritage de PPP. Le groupe IPSRA se tourne aujourd'hui vers ce dernier type de solutions. Microsoft est d'ailleurs aussi au premier plan, notamment au travers de ses contributeurs (les mêmes qui ont standardisé L2TP et son utilisation avec IPsec).
IP a des avantages indéniables dans un contexte d'accès distant :
En revanche, on ne peut nier l'aspect quelque peu ``bricolage'' des solutions de sécurité présentées. Si certains protocoles sont tout à fait matures (ESP surtout), d'autres sont difficiles à mettre en oeuvre (IKE et PIC). Dans le contexte de la mobilité réduite, le nombre important d'éléments nécessaires (serveurs, passerelles, configuration des clients) constituent un frein pour le déploiement et tendent à rendre difficile le passage à l'échelle. L'intégration d'IPsec dans IPv6, soutenue par l'apparition de protocoles plus matures (IKEv2) et renforcée par la disparition de mécanismes tels que le NAT, pourrait constituer une bel avenir pour le support de la mobilité réduite sécurisée (et un bon tremplin pour celui de la mobilité forte sécurisée).
Références
|