Propositions de solutions aux problèmes de sécurité (Session Initiation Protocol) Boucadair Mohamed France Télécom R&D- DMI/SIR 42 rue des Coutures, 14066 Caen Cedex, France. mohamed.boucadair@rd.francetelecom.com RÉSUMÉ Le protocole (Session Initiation Protocol) s impose parmi les protocoles de signalisation dédiés à la téléphonie sur IP. Mais souffre de quelques lacunes dont la sécurité. La norme a fait seulement signe au chiffrement des données, mais en aucun cas à la sécurisation des flux média ou de signalisation. Dans cette article, on présentera quelques solutions possibles à ces failles de sécurité. ABSTRACT (Session Initiation Protoco) is an emerging VoIP (Voice Over IP) protocol used for setting up conferencing, telephony, multimedia and other types of communication sessions on the Internet. But this protocol has some difficulties with setting a secure communication. In this paper, we will present some solutions to the s security problems. MOTS-CLÉS : pare-feu, NAT,, Sécurité, R, IP, IPSec, Chiffrement, DOS, VoIP, Facturation. KEYWORDS: Firewalls, NAT,, Security, R, IP, IPSec, Encryption, DOS, VoIP, Billing
2 GRES, Décembre 2001, Marrakech. 1. Etude des solutions aux problèmes, Firewalls et NAT 1.1 ALG (Session Initiation Protocol) est un protocole de signalisation qui gère des sessions multimédias. Le protocole utilise ainsi des adresses IP(Internet Protocol) au sein de ses messages, ce qui rend fastidieux la traversée des mécanismes de NAT(Network Address Translation) sans une ALG(Application Level Gateway). Mais le développement d un tel programme nécessite la connaissance du diagramme d état d un appel et comment on peut identifier une session. Notons qu une ALG_ devrait être capable de modifier les données des paquets sortants aussi que les paquets entrants. Tous les champs du message qui intègrent l adresse IP et le numéro du port doivent être modifiés. Dans la suite, on présentera quelques champs qu on juge sensibles, car tout changement de ces champs affecte directement le passage des paquets et la trace des chemins. 1.1.1 Modification de l informations VIA Dans une requête, l'information VIA doit être modifier pour que les réponses soient envoyées au serveur NAT et au port auquel est attaché le client. Ceci implique la modification de la liste des ports mentionnés dans ce champ. 1.1.2 Modification de l information CONTACT Cette information est important à modifier pour permettre d envoyer les requêtes au bon client. 1.1.3 Modification du message SDP Si le message contient une demande de type «application/sdp» alors on doit traiter ce message pour extraire les informations concernant l adresse IP à modifier. Avantages L ALG- filtre les «mauvais» messages et les messages qui n'ont aucun destinataire sur le réseau local interne. Les messages pourraient par exemple être des messages non écrits selon la version de que supporte l'alg ou il se pourrait que l appelant ou l appelé émette des retransmissions beaucoup plus fréquemment que comme indiqué dans la RFC. Il se pourrait également que quelqu un essaye de rejouer des anciens messages. De plus, la performance de l'alg dépend du fait qu elle garde la trace des anciens messages ; plus cette option est développée plus le filtrage est pertinent. De point de vue sécurité, cela pose quelques problèmes qu on développe ci-dessus. Inconvénients L'ALG ne peut pas manipuler les messages chiffrés de, et donc elle ne permet pas d utiliser en cascade un mécanisme de chiffrement. De plus l'alg ne supporte pas le concept des messages signés, l ALG détruira toujours la signature.
Propositions de solutions aux problèmes de sécurité 3 La présence d une ALG permet à n importe quelle machine d envoyer des messages aléatoires dans le but de traverser un firewall. C est ainsi qu'une attaque par déni de service pourrait se produire, en l occurrence envoyer des messages UDP(User Datagramm Protocol) sur un intervalle de ports réservés aux entités. Un autre problème qu on rencontre avec l'alg_ est le problème du multicast ; en effet, puisque le NAT traditionnel n utilise qu un seul état pour identifier une session, on ne pourra pas décider si un paquet est une réponse à une requête multicast ou le début d une autre session. En fin, les entités NAT peuvent être sujet d attaque par déni de service comme le SYN FLOOD et le PING FLOOD. 1.2 R 1.2.1 Introduction Comme alternative au NAT, R( assure l intégrité de bout en bout des messages en profitant de son architecture client/serveur. Dans la suite, on donnera une comparaison entre le choix d une ALG ou d un serveur R. Mais avant, détaillons comment R supporte la sécurisation de bout en bout. 1.2.2 R et la sécurisation bout en bout R est un mécanisme compatible avec IPSec(IP Security), qu on peut utiliser de bout en bout tout en partageant des adresses IP. Puisque IPSec peut chiffrer les numéros de ports TCP/UDP, ces champs ne peuvent pas être utilisés en tant que champs de démultiplexage. Cependant, IPSec insère l'en-tête AH(IP Authentification Header) ou ESP(IP Encapsulating Security Payload) après celle d IP(Internet Protocol) dans tous les paquets IPSec protégés ( les paquets qui sont transmis sur une association de sécurité d' IPSec (SA)). Ces en-têtes contiennent un champs de 32 bits dit paramètre de sécurité SPI ( Security Parameter Index), dont la valeur est déterminée par le receveur. Le champs SPI est toujours en clair. Ainsi, pendant la négociation SA, un serveur R peut utiliser une valeur particulière de SPI. Cette valeur de SPI et l adresse IP assignée, peuvent être employées par une passerelle R seulement pour identifier et router les paquets vers des clients ou serveurs R. Afin de garantir que les serveurs R utilisent une SPI par adresse, il est nécessaire que la passerelle R assigne des SPIs uniques aux demandeurs en fonction de l adresse IP et le numéro du port. 1.2.3 Comparaison avec l ALG R offre la possibilité d utiliser le chiffrement et l authentification, chose que ne permet pas le NAT, un avantage qui facilite le passage d une version à une nouvelle. Mais R ne dispose pas d une fonction de test qui permet de valider les messages qui sont correctement formés ; une fonction qu assure l ALG.
4 GRES, Décembre 2001, Marrakech. 1.3 MidCom L IETF a publié au mois de février 2001, un draft qui propose une solution aux problèmes de traversée des firewalls et des NAT : Middlebox Communication. Cette architecture propose d ajouter de nouveaux dispositifs de signalisation pour le contrôle des dispositifs existants. On se contentera ici de présenter seulement l architecture générale de la solution. Client Client Client Serveur de politiques de sécurité Le protocole MIDCOM Firewall NAT DIFFSERV QOS ACL,BINDS Détection d intrusion Figure 1 : Architecture MIDCOM Proxy Client Proxy RTCP Proxy RTCP Serveur de politiques de sécurité Couche MIDCOM Firewall NAT DIFFSERV QOS Détection d intrusion Figure 2 : Architecture MIDCOM avec un proxy
Propositions de solutions aux problèmes de sécurité 5 Cette architecture pose plusieurs problèmes, car il faut intégrer des mécanismes d authentification et de chiffrement. Les entités MIDCOM doivent être protégées. Les flux véhiculés vers le proxy doivent être sujet à l authentification. 1.4 Proxies RTP 1.4.1 Introduction "!$#%!&! #%' ()&)*,+-' *,. /0213&)*43#)* 15!6,087908#%0%'' 08+;:<6 /=' *,:34>0%+-'?. /@ 0)6 6,02/' * 6 *,+;02ACBEDFG15:</9&H6,! #%:3IJIE! 43790K730%+L+-0%+;+ *:343+M0%4N6@ :3#%#)/O&&%0%43#%0P6,@ :</OQR0)& ' /O&%0S0%'T6!SU0)&%IE0%' /O&%0S790%+V+;0%+-+ *,:343+W15!& 730%+YX[Z\^]=_ ` arbdcfevg5h)i jjh%k klm3krln,m3o^nqp,hrk i l sntubdcfenh%m3k i htph%odi%v%o-h%lwoxpn,m3k h)i%t%y3m3m3h%t%k v%o;z La présente solution résout les problèmes que présentent le NAT quand il est utilisé avec. En terminant toutes les sessions multimédias dans un proxy RTP qui se situe dans la zone de démilitarisation (DMZ) et en reliant de ce point les paquets RTP à leurs destinations finales, nous ne s intéresserons plus aux problèmes posés par le NAT même si le réseau interne utilise des adresses privées. 1.4.2 Configuration On doit ajouter des règles de filtrage de paquets dans les firewalls afin de permettre le passage des paquets UDP destinés au proxy RTP. De même, on doit permettre à des paquets de quitter la DMZ s' ils sont émis par le proxy RTP. Un proxy contrôle le proxy RTP en utilisant le protocole MGCP. La solution exige qu'un agent d'appel MGCP soit intégré dans le proxy. 1.4.3 Architecture de la solution Client I1 Client X2 Réseau public Firewall Client I4 Client X1 Réseau DMZ Proxy RTP Proxy Réseau interne Figure 3 : Architecture proposée {} ~" ƒ q "ˆ[ Š Œ Ž - J 3 % % 3 % % f ;š<, N 9 Pœš< =ž, % rÿe % ; - % "Ž - % O T 9š< R % 3œ5 %œ % œ 3 ; ) % % " % 3œ % ž, % % ; %, 3œ ) 3 E %œ[ž, %, 3œ ) ª% % P )«dœ ) % 3 % ; } 3 3 % fÿj % - ; % Ž C -š3 3œ[ % ) = -Ōž ± [²³^ )µ - J¹º%»"º%¼}½3¹,¾<,º)À Á½5¾<ÂOÀ Ã%¾3Ä3Å À%Æ<¹º)À ¹,ºdÇÈÉ^Ê)ËÍÌRÎfÏ Ð9Ñ Ò Ñ)Ó Ó,Ñ Ô-Õ<Ö%Ò Ñ Ø=ÑfÒÕ<ØÔÓ,Ñ%Ô=Ù5Õ<Ö ÒÔ2ÌdÎfÏ Ð3Ú
6 GRES, Décembre 2001, Marrakech. Û=Ü3ÝßÞ;Ý%Þ;Þ^à,á3Üãâ}ÛOä,å àâjæ%ç%à,èßþ-á<à,ý%ü3åéá<ûoêrý)ë%å Þ;ì9íÝ)ë âjæ%þ-î}ïjèü3þ ð%ý)ë åèàü3þ ð%è ÞMä,Ýqñ[òó^ô)õ ö øùûú3ü<ýþ ÿ þ ü3ú<ýý ú ú þ%þ ö øù5ü! " $# % &ý ü ' þ ý,ü ý ( ÿ ) ü<ý,þ (Rü* ÿ ú +!,3þ ÿ) - þ ú /.10 234 56 6 7 8:9<;>=<?A@CBED F>GIHKJLNMPORQTSCUWVXV Y Z\[^] _ V`Y V'a V _ b c ]edgf'uwh ikj] [[Vml ]ndgopuw] XprqZ\sta V _`Y ]vukwxnypzk{g P}W~ \ ƒ ~ \ ~ ƒ ~+ˆ ~ 'Š ƒ Œ ƒ ƒ ~ Š Ž Ž 'Š ƒ ~ Ž ~ ƒ ƒ KŽ Ž ~ ~ ^ ~ {g '} Kš œ ežgÿp > ª «^ > K «C \ K «< r±k²³n µe T C ¹ º» ¼½ ¾: À ^ Á ºÂ ¾Ã Ä»KÀ ½ ½À Å ÆÀº» ÇrÀ ¾»+È'À ^ ¾ É ÀÊgË' À Äà º¹Á ÌÍ\¾Â r½ ÀÈ'À ^ ¾ É ÀÊgÎ^ Ϲ ¾ ¼½ ÀÑÐKÒÓ Ô Õ+Ög ^Ø ÙÚ Û Ü Ý Þ ß Ûà>á Ú\Û â1ã Ý ß Úäãå æ Ý ç àý Ú ã'æ èã ã Ý á ç èéê ß éàë\ì>ý<íkîïnð ñ$òtócôaõö øúù ûüýÿþ û þ þ õö Kü þ ü ö rø ö\ö û õ û ö øýÿþù:òrócô >ö! #"%$ &('*)(+&(,-,/.10324+!,/,/.105)(.6,24+!768.6',:9<;>=?,& )(@ + "606.6,/,-.A".A"%.6,/' &(B+ ' &($BC$ 8D,/$ 8#06E6.A.6,-'F)(.GHIKJMLDNPO QR SUTWVYX Le protocole MGCP est utilisé comme protocole de commande entre le proxy et le proxy RTP. Le proxy intègre la partie client du protocole, l'agent d'appel (CA), et le proxy RTP devront mettre en application la partie serveur du protocole (CAS). Le CAS utilisera le port de MGCP (2427). Il est commode d utiliser MGCP à cette fin puisqu'il utilise également le SDP en tant que protocole de description de session, juste comme le. De cette façon le proxy peut juste copier la partie SDP des messages aux commandes de MGCP envoyées au proxy RTP. 1.4.4 Fonctionnement Ajouter un proxy RTP à côté d un proxy a pour rôle de faciliter le passage et le traitement des paquets tout en faisant attention aux besoins du NAT et du passage dans des dispositifs de firewalls. La question est comment peut-on interagir ces entités? La solution étant de tirer profit du protocole MGCP. C est ainsi qu on adoptera l architecture suivante : CA Proxy RTP CA MGC Proxy Figure 4 : Architecture logique de la solution 1.4.5 Exemples de connexions Ouverture de connexion
Propositions de solutions aux problèmes de sécurité 7 CA 1 Proxy Proxy RTP CA 2 MGCP(Créer connexion#1) MGCP(200 OK) MGCP(Créer connexion#2) MGCP(200 OK) (INVITE) (200 OK) MGCP(modifier connexion#2) MGCP(200 OK) MGCP(modifier connexion#1) MGCP(200 OK) (200 OK) MGCP(modifier connexion) MGCP(200 OK) (ACK) CONVERSATION Figure 5 : Invitation à une session Dans cet exemple, le client n 1 invite un deuxième client pour participer à une conversation. C est ainsi qu une première phase consiste à initialiser la communication en mettant d accord les deux proxies et RTP par la création d une connexion MGCP. Dans cet exemple, le proxy ordonne au proxy RTP de créer une connexion pour la session en cours. Le message SDP est copié et analysé par le CAS dans le proxy RTP. Tant que le CA1 n a pas d informations sur le CA2, il n envoie pas de messages SDP. Une fois le CA2 contacté, il envoie un message ACK qui sera transmis au CA1 tout en modifiant les connexions MGCP intermédiaires.
8 GRES, Décembre 2001, Marrakech. Fermeture de connexion CA 1 Proxy Proxy RTP CA 2 (BYE) (BYE) (200 OK) MGCP(effacer connexion#1) MGCP(250 OK) MGCP(effacer connexion#2) MGCP(250 OK) (200 OK) Figure 6 : Fermeture de session Le CA 1 envoie une demande de déconnexion en envoyant un message BYE. Le proxy fait suivre le message au CA n 2, ce dernier confirme la déconnexion en envoyant une message OK au proxy. Le proxy demande au proxy RTP de fermer la session MGCP.nAprès avoir fermé la session MGCP, le proxy RTP envoie un message OK pour chaque connexion effacée au proxy. 1.4.6 Conclusions Cette solution apparaît simple à comprendre, mais il faut ajouter un proxy RTP qui doit répondre à des besoins spécifiques. Ceci peut être un handicap pour cette solution, car on préfère utiliser une infrastructure déjà existante que d ajouter d autres éléments qui poseront d autres problèmes de sécurité. Par exemple, si le proxy ne fait pas la différence entre un message provenant de l extérieur et un provenant de l intérieur du réseau, et compte tenu du fait que les deux entités à savoir le proxy et le proxy RTP se font confiance, on sera capable d ouvrir des sessions en envoyant vers le proxy RTP pour notre propre INVITE un 200 OK.
Propositions de solutions aux problèmes de sécurité 9 1.3 Proxy Agent 1.3.1 Introduction Dans cette partie du rapport, nous présenterons une méthode qui permet aux protocoles orientés sessions en temps réel, tels que le, H.323, H.248 et MGCP, de traverser les firewalls et les mécanismes de NATs. La solution n'exige aucune modification au niveau du firewall et du NAT, de plus, elle est transparente vis à vis du destinataire. 1.3.2 Fonctionnement Architecture d un système de voix sur IP La figure suivante reprend les entités mises en œuvre lors du déploiement d une architecture de voix sur IP : Site A Site B A B PIA A Firewall NAT Réseau public NAT Firewall PIA B Firewall PIA : proxy interface agent Serveur proxy Centre de service Figure 7 : Architecture d un système de voix sur IP La figure ci-dessus reprend l architecture d un système de communication entre deux sites A et B, chacun des deux sites utilise un plan d adressage privé. l adressage privé peut être attribué par un serveur DHCP. Pour supporter la traversée des dispositifs de frontière vers le monde extérieur, le réseau privé contient une PIA (Proxy Agent Interface) qui peut être intégrée dans le terminal. De plus la configuration du firewall doit permettre ces opérations de traversée. L avantage de cette configuration est que les numéros de ports utilisés seront accessibles par le firewall.
10 GRES, Décembre 2001, Marrakech. Exemple d opération avec un appel Un appel passe par plusieurs phases : on commence par s enregistrer auprès du serveur proxy par la biais des canaux logiques, cette phase se caractérise par l allocation des ports UDP auxquels seront attachés les flux RTP(Real Time Protocol). Après cette phase, le serveur a les informations nécessaires pour l initiation d une session, les messages seront envoyés au PIA qui les fait suivre au CA. A ce stade de la communication, le CA est capable d envoyer des paquets UDP. On résume dans la figure suivante le déroulement d une communication : Téléphone PIA Serveur INVITE+ PORTS Créer connexion Paquets UDP INVITE+ PORTS Créer un port UDP Paquets UDP Firewall NAT 200 OK 200 OK ACK Messages de contrôle Création de canaux UDP Figure 8 : Appel 1.3.3 Solutions apportées Cette solution est souple dans la mesure où elle permet d intégrer de nouveaux dispositifs sans modifier la structure existante. De plus, elle résout les problèmes de traversée de firewall du fait que les numéros de ports sont connus et qu il suffit seulement de les communiquer aux entités qu en ont besoin. Mais cette solution pose des problèmes de sécurité puisqu elle introduit des entités sensibles aux attaques. 1.4 Résumé On a présenté un éventail de solutions aux problèmes identifiés dans (Boucadair1, 2001). Ces solutions peuvent être divisées en trois catégories :
Propositions de solutions aux problèmes de sécurité 11 1. Celles qui tentent de garder l infrastructure existante et de traverser les dispositifs qui posent des problèmes. 2. Celles qui introduisent d autres entités de contrôle 3. Celles qui mettent à jour la partie logicielle des dispositifs tels que les firewalls et les ALG Mais malheureusement, toutes ces solutions restent théoriques et une implémentation opérationnelle n est pas disponible. 2 Etude des solutions aux problèmes protocolaires On s intéressera dans cette partie aux solutions des problèmes protocolaires énumérés dans le chapitre précédent. C est ainsi qu on mettra le point sur les problèmes suivants : Les attaques par réflexion Le problème du forking La protection des flux RTP La gestion des clefs La sécurisation nœud à nœud Différentes solutions seront possibles, dont certaines se basent sur les architectures de sécurité et dont d autres sont de simples idées pour remédier aux lacunes. Deux grandes catégories sont à distinguer : La gestion des clefs : Kerberos ou IKE Le chiffrement : IPSec, TLS ou les mécanismes de protection de RTP. Dans la suite, on présentera brièvement chaque solution en mettant en exergue les avantages de chaque choix. Mais avant de ce faire, on résumera ici les solutions qui nous semblent adaptées aux problèmes de sécurité Problème Attaques par réflexion Le forking La gestion des clefs Flux RTP Tableau 1 : Propositions de solutions 2.1 IPSEC 2.1.1 Introduction Solutions PGP Signature numérique PKI Mémoriser le CALL-ID 1 ère solution Diffie Helman pour SDP PGP pour authentifier les messages 2 ème solution IKE 3 ème solution Kerberos PKI IPSec est une norme qui définit un ensemble de protocoles de sécurité pour le protocole IP afin de permettre la sécurisation des réseaux. Les services de sécurité
12 GRES, Décembre 2001, Marrakech. fournis par IPSec sont la confidentialité, l'authentification, l'intégrité, la protection contre le rejeu et le contrôle d'accès. 2.1.2 IPSEC et L utilisation du protocole IPSec peut être une solution pour assuerer le chiffremlent des données. Le mode ESP apparaît convenable au chiffrement nœud à nœud. 2.2 TLS 2.2.1 Introduction Le protocole TLS (Transport Layer Security) est un protocole qui vise à assurer la confidentialité et l intégrité des données entre deux applications communicantes. La protocole TLS fonctionne en collaboration avec des protocoles s appuyant sur TCP. 2.2.2 TLS et ZY[ \4]1^`_*^_ a b a(c/]1d5b(]\d6e_ef6e b(]ghjia\4e ^#db(] f6k a(lmlnd6]6o>]6[_p%]6c:p%e[[q6]6c/r#zy[ \4]1^`_Fb(]\d q6lq1d ]1d sutmv i*]6fuw ^%ax\d6q6c-]6[_]6[_y\b ^`cza(]1^#d6c{p%q6l ^_c/rx}>]~\b ^`cghji ]6c-_ f1b( a d xcz^llna(c/]6o>o>]6[_ [e d6o> b a(c-qƒ]6 e ^_]6cb(]A \\b af6 _ ae[c c/q6]6cc^#dw gg v lme[f6_ a(e[[]6[_p ]6f5gĥ i*r 2.3 Kerberos 2.3.1 Introduction Kerberos est un protocole d'authentification réseau. Il est conçu pour fournir l'authentification forte pour des applications de type client/serveur en utilisant le cryptographie à clé secrète. Kerberos est disponible dans beaucoup de produits commerciaux. 2.3.2 Kerberos et Š1Œ Š1Œ6Ž -ŠD PŠ1 Œ Ž 4Ž Ž 6Ž (Š zš( (Š Š6 (Šœ 6Ž 4 mœ6 >ž3ÿm ˆ Y 6! YŽ š( - Ž Œ6Š6 6Ž Œ6Š1Œ6 ` ƒ Œ6Ž 6 YŠ4 š( A D ƒ #š( / Š4 ( ª Œ Š6 / -Šƒ -ŠA Œ Ž % Šƒª% Šƒ š( 6«FŠ6 2.4 SRTP : Secure RTP Une autre solution qui a vue le jour est le Secure Real Time Protocol (Février 2001) Les avantages de la solution SRTP sont : Calcul rapide des résultats des fonctions de hachage et de chiffrement La conservation de l'efficacité de compression de l'en-tête RTP L utilisation simultanée des clés cryptographiques par des sessions RTP multiples. Indépendant du protocole de transport utilisé par RTP.
Propositions de solutions aux problèmes de sécurité 13 Pas de propagation d erreur (par exemple, changer un bit d un paquet SRTP devrait ne changer au plus qu un bit du paquet RTP correspondant) SRTP peut être concurrent à TLS et IPSec. De plus, il ne s intéresse qu aux flus RTP. Le bas coût des calculs SRTP répond aux besoins du temps réel et permet de réduire les délais de réponse des serveurs en question.