G. LebovitzM. Bhatia (Alcatel-Lucent)B. Weis (Cisco Systems)March20132013-03-02
Le groupe de travail
KARP de l'IETF travaille sur une partie
bien spécifique du vaste programme de la sécurisation du
routage sur l'Internet : il s'occupe de
l'authentification réciproque des routeurs et de comment l'améliorer. Ce RFC
fait l'analyse des menaces pesant sur cette authentification et expose
le cahier des charges pour les nouveaux RFC qui vont s'attaquer à ces
menaces (le premier RFC du groupe KARP, le , le recouvre partiellement mais se focalisait sur les
tâches à long terme à accomplir).
Ce ne spécifie pas un nouveau protocole, il
sert de base au travail concret que le groupe KARP a désormais
entamé. D'abord, l'analyse des menaces : comme le documente la section
8.1 du (le compte-rendu d'un atelier sur le trafic Internet non
sollicité), la meilleure solution pour un méchant qui veut perturber
l'activité des autres est souvent de s'attaquer aux routeurs. Le détaillait
les attaques contre les protocoles de routage, et le dénonçait le fait que les mécanismes de sécurité
existant dans les routeurs étaient bien primitifs, par exemple parce
qu'ils ne permettaient pas de changer les clés sans perturber
sérieusement le fonctionnement du réseau (ce qui casserait les SLA), avec le résultat que bien
des opérateurs ne changent jamais ces clés. (On peut aussi consulter
le , un glossaire de la
sécurité sur l'Internet.)
Quels sont les protocoles de routage concernés ?
BGP, OSPF,
IS-IS, LDP et
RIP ont tous déjà des mécanismes
cryptographiques de protection de la communication entre routeurs. Le
but du projet KARP est d'améliorer ces mécanismes, pour lesquels il
existe déjà du code qui tourne et de l'expérience opérationnelle, pas
de les jeter et de les remplacer (principe dit « crawl, walk,
run », autrement dit, ramper lorsqu'on n'a pas le choix,
marcher si on peut, courir dans le meilleur des cas ; c'est tiré d'une citation célèbre de Martin Luther King). KARP est donc un
projet incrémental (section 2.2). Parmi les raisons qui ne
permettent pas d'envisager un passage à court terme vers des solutions
radicalement différentes, avec de la cryptographie forte, partout, il
y a le fait que les routeurs actuellement déployés ont des capacités
matérielles très variables, par exemple, ils n'ont pas forcément
d'accélérateur cryptographique. D'une manière
générale, KARP essaie d'être réaliste et de coller aux témoignages des
opérateurs, tels qu'exprimés dans le
rapport Arbor.
Ce rapport note, par exemple, qu'aucun des opérateurs interrogés
n'utilise IPsec entre ses routeurs (alors qu'il
résoudrait un bon nombre des problèmes de sécurité de KARP). Par contre, 70 %
utilisent les mots de passe MD5 sur les sessions BGP externes et 55 %
sur les internes. Les clés sont très peu changées (des clés de plus de
cinq ans sont courantes), en raison des conséquences (en BGP, changer
la clé coupe la session, faisant osciller les routes) et des difficultés opérationnelles
que cause leur changement (il faut se concerter avec le pair dont,
bien souvent, on n'a plus les coordonnées, puis organiser le
changement pile au même moment). Tout ceci pour un
ROI nul. La décision du
PHB est donc vite prise : on ne change pas les clés.
Le rapport Arbor cite même un opérateur qui utilisait la même clé
pour tous ses clients et, à ceux qui s'inquiétaient de la sécurité et
demandaient une clé spécifique, répondait que ce n'était pas
possible. C'est gonflé, mais cela simplifiait beaucoup la vie de cet opérateur.
Ce travail de KARP, comme décrit dans le ,
aura deux phases :
La phase 1 portera sur cette amélioration de l'existant,La phase
2 portera sur un protocole de gestion de clés.
Un bon exemple d'amélioration par déploiement incrémental a été pour BGP, où
l'antédiluvien mécanisme de sécurité du
a d'abord été remplacé par l'AO (Authentication
Option) du , alors même qu'il
n'existait pas encore de protocole de gestion de clés, que plusieurs
cryptographes estimaient indispensable. AO résout une partie des
problèmes des mots de passe MD5 (notamment l'agilité cryptographique,
la possibilité de changer d'algorithme) mais n'essaie pas de tout
résoudre d'un coup.
Un peu de vocabulaire au passage :
une KDF (Key Derivation Function) est une fonction
qui génère une clé à partir d'une autre clé et de données
diverses. Par exemple, une KDF possible est de concaténer la clé de
départ (clé de dérivation) et une adresse IP, puis de
condenser cryptographiquement le tout.
Un KMP (Key Management Protocol, le protocole
qui fera l'objet de la phase 2) est un
protocole de gestion de clés cryptographiques, permettant leur
distribution aux routeurs. Le but d'un KMP est de permettre le
changement relativement fréquent des clés (à l'heure actuelle, le
changement des clés dans les protocoles de routage est manuel : comme
c'est une opération pénible, elle n'est en général pas faite et les
routeurs gardent en général les mêmes clés toute leur vie).
Une PSK (Pre-Shared Key) est une clé secrète
partagée entre N routeurs, par exemple les mots de passe d'OSPF v2 ou
bien les « mots de passe MD5 » de BGP. En l'absence de KMP, elles sont
distribuées manuellement (copier-coller dans un terminal virtuel, par
exemple).
Une bonne analyse de sécurité nécessite d'être conscient des
capacités de l'adversaire. Première catégorie, les attaquants
extérieurs à l'organisation (outsiders, section
3.1.1). Ils n'ont pas les clés. Notre RFC fait une distinction importante
entre les attaquants extérieurs mais situés sur le chemin entre deux routeurs (on-path
attackers) et ceux situés en dehors (off-path
attackers). Les premiers peuvent écouter le trafic et
injecter des paquets qui seront indistinguables des vrais. Les seconds
ne peuvent pas écouter le trafic, peuvent parfois injecter des paquets
mais, comme ils travaillent en aveugle, ils auront beaucoup plus de
mal à les faire accepter comme authentiques. Le méchant situé sur le
chemin (le plus dangereux) peut donc :
rejouer des vieux paquets (qui pouvaient être signés pour
l'authentification),insérer des paquets,changer des paquets.
Les méchants extérieurs, qu'ils soient sur le chemin ou pas, peuvent aussi tenter de découvrir un mot de passe par force brute,
en essayant de se connecter avec plein de mots de passe courants. Ou
essayer de découvrir les clés par des essais systématiques (qui
peuvent réussir si la clé est trop courte.)
Deuxième catégorie, les attaquants qui ont réussi à avoir une clé
(section 3.1.2). Un exemple typique est un ex-employé mécontent (le
taux de rotation du personnel est élevé dans ce métier). C'est à cause d'eux qu'il faut changer régulièrement
les clés : on ne peut jamais être 100 % sûr que la clé n'a pas fuité
et il est donc nécessaire de ne pas l'utiliser éternellement.
Enfin, il y a les byzantins, les pires
(section 3.1.3). Ce sont les participants légitimes qui, pour une
raison ou une autre, trahissent. Cela peut être un routeur bogué, qui
émet des paquets incorrects. Ou un routeur piraté par le
méchant. Comme le projet KARP vise à une meilleure authentification
des pairs, le cas d'un pair légitime, mais traître, n'est pas traité
dans le cadre de ce projet. (Idem pour un routeur qui jouerait
correctement les protocoles de routage, mais jetterait ensuite les
paquets, créant un trou noir.)
Avec de telles capacités, même les autres attaquants peuvent causer beaucoup de
dégâts. À noter que les attaques par déni de
service utilisant les protocoles de routage font partie des menaces considérées par KARP, par
exemple des paquets signés ou chiffrés qui entraînent des calculs
cryptographiques
lourds. Les attaques par déni de service volumétriques (pure force
brute, on envoie plein de paquets ordinaires) ne sont par contre pas
prises en compte par KARP. D'autres attaques par déni de service sont
des objectifs de KARP. Par exemple, si on faisait tourner BGP sur
TLS, pour le sécuriser, un attaquant sur le
chemin pourrait toujours envoyer des paquets
TCPRST
(ReSeT) qui couperaient la connexion. KARP vise à
empêcher aussi ce genre d'attaques. (Si l'attaquant en question n'est
pas sur le chemin, et travaille donc en aveugle, cette attaque sera
plus compliquée pour lui, voir le .)
Il y aussi trois « non-objectifs », que KARP n'essaie même pas d'atteindre :
Protection de la vie privée. Les
sniffeurs purement passifs
peuvent apprendre des choses, mais pas perturber le routage. Les
sections 2.1 et 3.3 rappellent donc que la confidentialité est un non-but.Vérification de la validité des messages. En effet, faire
confiance à un routeur n'est pas la même chose que faire confiance au
contenu de ses mises à jour. Les attaques comme celle de Pakistan Telecom dépendent donc
d'un autre groupe de
travail.La non-répudiation des paquets par les routeurs.
Et les solutions ? KARP se propose de mieux sécuriser les
communications entre routeurs (il existe déjà des tas de techniques,
mais imparfaites). Cette amélioration doit être incrémentale (pas
question de faire de la table rase).
Le cahier des charges du travail de KARP (la « phase 1 »,
l'amélioration de l'existant, est déjà largement entamée)
est donc ici, sous forme d'une longue liste d'exigences (section 4 du RFC) :
Une meilleure description de ce qu'on protège,Des algorithmes cryptographiques sûrs
(MD5 doit être abandonné),Une agilité de ces algorithmes, permettant leur remplacement (la question n'est pas de savoir si un algorithme
cryptographique sera cassé mais quand),Changement des clés (rekeying) sans casser
les sessions en cours,Mécanismes pour une utilisation plus sûre des PSK (secrets partagés),Une sécurité par pair (et pas globale),Possibilité d'utiliser aujourd'hui la gestion manuelle des clés
(la seule réaliste actuellement) tout en permettant l'usage futur d'un
KMP (protocole de gestion automatique des clés),La compatibilité avec l'existant, si on veut avoir la moindre
chance que ce soit déployé un jour.