Gérard Florin
- CNAM -
- Laboratoire CEDRIC -
1
Généralités sécurité liaison/réseau et VPN
Le niveau liaison
Transmission en sécurité de niveau liaison
Réseaux privés virtuels: VPN de niveau liaison
Le niveau réseau
IPSEC : Transmissions en sécurité et tunnels
Réseaux privés virtuels de niveau réseau: VPN en MPLS
Conclusion
Bibliographie
Généralités sécurité niveaux liaison et
réseau et VPN
? Objectif : réaliser des fonctions de sécurité pour un niveau. ? Fonctionnement en mode ‘transport’ :
? Les fonctions de sécurité sont appliquées à la charge utile d’une trame ou d’un paquet.
? 1 Authentification
? Le problème le plus souvent traité car aux niveaux liaison et réseau on contrôle que des utilisateurs peuvent accéder à un réseau.
? Très grand nombre de solutions proposées au niveau liaison.
? Solutions également très correctes au niveau réseau IPSEC
? 2 Confidentialité
? Peu de propositions au niveau liaison avant les réseaux sans fils.
? Renouvellement des besoins avec les réseaux sans fils.
? Solutions très correctes au niveau réseau avec le protocole IPSEC
? 3 Intégrité
? Pratiquement rien au niveau liaison sauf réseaux locaux .
? Solutions très correctes au niveau réseau IPSEC.
? Une solution VPN
Routeur/Passerelle d’accès
Entreprise site A Entreprise site B
? Solution fonctionnellement équivalente à :
Objectif : réaliser un réseau privé sécurisé en utilisant l’infrastructure d’un réseau partagé (ouvert).
? 1 Réseau (‘network’)
? Interconnecter un ensemble de systèmes informatiques dispersés.
Résoudre des problèmes de commutation/routage (niveau 2/3).
? 2 Privé (‘private’)
? Transporter des flots de messages d’une communauté ‘privée’ de façon indépendante de ceux d’autres usagers.
? Les usagers doivent recevoir une garantie de sécurité
(confidentialité, intégrité ou protection) sur leurs données.
? Les usagers autorisés peuvent communiquer en utilisant des adresses, une topologie, un routage privés.
? 3 Virtuel (‘virtual’)
? Le réseau physique ne correspond pas forcément au réseau visé.
? Le réseau privé est réalisé en partageant les ressources d’un (ou de plusieurs) fournisseur d’accès.
? 1 Communications sécurisées sur une infrastructure partagée.
? Sécurité visée : mécanismes de protection
=> implantation en modifiant des protocoles de réseaux classiques.
? Solutions: adressage et routage privé offerts par des mécanismes de protection garantis par un constructeur de routeur et un fournisseur d’accès.
? Sécurité visée : mécanismes pour la confidentialité et l’intégrité => protocoles de sécurité utilisant des techniques de cryptographie.
? Solutions: authentification, chiffrement en confidentialité, signatures.
? 2 Economies de coûts en partageant des plates-formes de communication à haut débit.
? Efficacité du partage de voies physiques à haut débit: coût des communications très réduit dans un réseau partagé (type l’Internet).
? Solutions alternatives non VPN : construire sa propre infrastructure complètement privée en louant des liaisons spécialisées ou des circuits => surcoûts de location, d’administration.
Motivations pour les VPN :
? 3 Communications fiables : sûres de fonctionnement ‘dependable’.
? Critères : Disponibilité, fiabilité, sécurité (‘safety’), maintenabilité.
? Sûreté assurée par les redondances du réseau (maillage du réseau sous-jacent) => utilisation de protocoles de routage multi-chemin.
? 4 Performances pour des infrastructures extensibles (qui passent à l’échelle, ‘scalable’).
? Critères : Temps de latence (temps jusqu’au commencement de la réponse à une requête), temps de réponse total , débit. Possibilité d’accroître la taille du réseau privé (extensibilité).
? Performances en VPN: souvent beaucoup de surcharges (protocoles supplémentaires, algorithmes cryptographiques).
? 5 Solutions pratiques (‘flexible’) : les VPN : sont souvent considérés comme difficiles à gérer.
? Facilité, simplicité d’établissement des connexions et de l’administration.
? A) Classification selon le niveau du modèle OSI.
? VPN de niveau liaison (éventuellement même de niveau physique).
? VPN de niveau réseau.
? VPN de niveau transport.
? VPN de niveau application.
? B) Classification selon l’approche de sécurité
? Protection: Solutions de niveau 3 en routage pair à pair (‘VPN Peer to peer’), de niveau (1) ou 2 ou 3 en recouvrement (VPN ‘overlay’)
? Authentification, Confidentialité, Intégrité : Solutions de niveau quelconque (2,3,4,7) basées sur l’utilisation de tunnels (‘Secure VPN Tunnelling’).
? C) Nombreux choix possibles selon des critères qualité :
? Analyse des risques couverts ou non par une implantation.
? Possibilités de passage à l’échelle de la solution.
? Complexité d’implantation puis de maintenance. …..
? 1) Approche de VPN (niveau 3) basée sur le contrôle d’accès (routage) :
? On parle quelquefois de ‘Trusted VPN’, VPN de confiance.
? Solution implantée essentiellement dans les VPN MPLS: L3VPN.
? 2) Construction de groupes fermés d’usagers d’un réseau => VPN
? Sur la figure groupe A rose, B bleu.
? 3) Un routage est défini pour chaque groupe (VPN)
? Sur la figure VPN A : routes en traits pointillés courts ou VPN B : traits pointillés longs.
? 4) Idée de routage pair à pair : Le routage dans un VPN pair à pair est réalisé comme dans les routages Internet classiques (RIP, OSPF,…): les routeurs voisins
? Contrôle d’accès (protection) appliqué au routage : pour chaque VPN et dans chaque routeur gestion de la liste des routes autorisées (en fait une C-liste liste de capacités pour des routes).
? Les routes associées à un VPN ne sont pas annoncées à l’extérieur.
? Les routes extérieures au VPN ne sont pas annoncées dans le VPN.
? La protection dans le VPN est réalisée par l’impossibilité d’acheminer des paquets (dans les deux sens, intérieur extérieur) avec des adresses externes au VPN (absence d’infos dans la table de routage du VPN).
?Notion de tunnel : utiliser un protocole pour acheminer des messages d’un autre protocole.
?Encapsulation des messages du protocole transporté dans des messages du protocole transporteur.
?Solution fréquente en réseau.
?Architecture en couches des réseaux (OSI) : encapsuler des messages de niveau N+1 dans des messages de niveau N (inférieur).
?Différence mode tunnel et modèle OSI:
Tunnel = encapsuler des messages d’un niveau donné dans des messages du même niveau ou de niveaux supérieurs.
? 1) Le protocole ‘porteur’ utilisé (‘Carrier Protocol’):
? Le protocole d’un réseau existant permettant d’acheminer des informations => N’importe quel protocole robuste et répandu.
? Exemples : Surtout les protocoles de l’Internet PPP/IP/TCP/HTTP mais aussi ATM. ? 2) Le protocole d’encapsulation (‘Tunneling Protocol’):
? Le protocole qui est ajouté pour encapsuler les données usagers en les sécurisant => le protocole qui réalise les objectifs VPN de sécurité.
? Exemples : GRE, voir la liste sur le transparent suivant etc…
? 3) Le protocole transporté (‘Passenger Protocol’):
? Le protocole utilisateur que l’on souhaite acheminer.
? Exemples : un protocole Internet IP ou un protocole non Internet IPX, NETBIOS/NetBeui …. dans le protocole IP.
?GRE : Generic Routing Encapsulation (niveau 3 sur un autre niveau 3) (RFC 1701): uniquement dédié aux tunnels.
?PPPoE : Point to Point Protocol over Ethernet (niveau 2 sur niveau 2).
?PPPoA : Point to Point Protocol over ATM (niveau 2 sur niveau 2).
?IP in IP Tunneling : IP (V4) encapsulé dans IP (V4) (niveau 3 sur niveau 3) (RFC 1853).
?6to4 : Tunnelage de IPV6 sur IPV4 (niveau 3 sur niveau 3). ?IEEE 802.1Q : Ethernet VLANs (niveau 2 sur niveau 2).
?DLSw : Data Link Switching SNA over TCP (niveau 7 sur 4).
?XOT X.25 over TCP : (niveau 3 sur niveau 4).
? GRE : Origine Cisco, norme RFC 1701 (1994) modifiée RFC 2784 (2000).
? Objectifs : permettre d’encapsuler n’importe quel protocole sous GRE.
? Problèmes résolus par GRE : en version de base.
? Utiliser un code protocole IP : pour extension GRE (47).
? Création d’une structure de données assez simple essentiellement pour identifier le protocole transporté.
? Exemples d’encapsulation de protocoles : ICMP=1, IP=4
? Codes types GRE gérés par l’IANA RFC 1700 : la liste est en ligne .
? Problèmes résolus en version étendue:
? Contrôle d’erreurs à fenêtre glissante sur le tunnel (numéros de séquences, d’acquittements) ? Autres indicateurs.
| Protocole réseau transporté |
| GRE |
| Protocole réseau transporteur |
| C | Réservé | Ver | Protocole |
| Somme de contrôle | Réservé (si c=1) | ||
0 13 15 16 31
? C : Présence ou absence de la somme de contrôle (cheksum).
? Réservé : Bits réservés pour un usage futur.
? Ver : numéro de version (zéro actuellement).
? Protocole : contient un code numérique définissant le protocole transporté.
? Somme de contrôle : la même somme de contrôle que celle de IP portant sur l’entête GRE et le paquet transporté (si le bit c est à 1).
? Conclusion: Un protocole très simple
? Utilisé avec les tunnels L2TP (‘Layer 2 Tunneling Protoclol’).
? Peut être remplacé par l’obtention d’un code type protocole en IP.
? Pour construire une approche VPN en mode tunnel :
?Partir d’un protocole de tunnelage : GRE avec si nécessaire un protocole d’extension donnant de nouvelles fonctions.
?Parmi ces nouvelles fonctions :
?Introduire des fonctions de sécurité (authentification, confidentialité , intégrité …).
?Transformant des protocoles transporteurs et transportés non sécurisés en un ensemble sécurisé.
?On parle alors de tunnel sécurisé, VPN en mode tunnel, ‘Secure VPN’.
? 1 VPN Tunnels de niveau liaison en point à point.
? L2F : ‘Layer Two Forwarding’ (RFC 2341) Cisco (obsolete).
? PPTP : ‘Point to Point Tunneling Protocol’ (RFC 2637) Microsoft.
? L2TP : ‘Layer 2 Tunneling Protocol’ (RFC 2661) Cisco.
? 2 VPN Tunnels de niveau réseau.
? Tunnels VPN à recouvrement (« overlay ») en circuits virtuels.
? Tunnels sur réseaux ATM ou relais de trame. ? IPSEC : ‘IP Security’ ? Deux modes : Transport = sécurisation , Tunnel = IP sur IP.
? 3 VPN Tunnels de niveau transport.
? Sécurisation de niveau transport utilisable en mode tunnel : SSL ‘Secure Socket Layer’
? Exemple de tunnel : IP sur SSL
? 4 VPN Tunnels de niveau application.
? IP sur SSH (Secure SHell), PPP sur SSH, IP sur HTTPS
Cas desVPN à recouvrement
? 1) Solution considérée encore comme des VPN, VPN ‘overlay’ réalisés par un niveau 2 (L2VPN) : des accès externes prennent en charge le trafic et l’acheminent au moyen d’un réseau sous-jacent considéré comme de niveau liaison (point à point ou réseaux à circuits virtuels X25, ATM, FR, MPLS).
? 2) Utilisation de circuits virtuels permanents PVC ou commutés SVC pour interconnecter des points d’accès (routeurs) => d’où l’idée d’overlay.
? VPN également baptisés en anglais: ‘cut through’ = coupe à travers (‘travel across’/’pass over’).
? Un peu un abus de langage si aucun mécanisme précis de protection (contrôle d’accès), confidentialité, authentification n’est développé => cependant il faut gérer les adresses, le mode multipoint, l’encapsulation, …. (en fait un tunnel sans sécurité).
? Exemple : Transport de Lan (trames Ethernet), PPP, ATM, FR, FC, …avec MPLS PWE3 (Pseudo Wire Emulation Edge to Edge) et VPLS (Virtual Private LAN Services).
Protocoles de sécurité
VPN de niveau liaison
Introduction
I Protocoles de confidentialité de niveau liaison.
II Protocoles d’authentification de niveau liaison.
Sécurité au niveau liaison :
? Définition de base des protocoles de liaison : aucune sécurité
? Besoins qui s’expriment au niveau liaison:
? Essentiellement : Contrôle d’accès à des réseaux.
? Réseaux d’entreprise devant protéger leurs accès
? Fournisseurs de transport de données (FAI) offrant un service payant. ? Echange de données protégées en confidentialité.
? Plus rarement : contrôle d’intégrité (plutôt réseaux locaux) ? Réseau pratiquement le seul considéré : Internet ? Les protocoles de liaison concernés sont PPP et réseaux locaux.
? Principal problème traité: authentification des usagers (autorisation des accès pour les services offerts par l’Internet).
? Authentification au moment de l’accès au réseau Internet: protocoles en cause niveau liaison (PPP, Ethernet, Wifi).
? Autre problème traité : confidentialité.
?Mode de base: le plus répandu (‘PPP in HDLC Framing’)
?Délimitation des trames.
?Détection d’erreurs et destruction silencieuse.
?Protocole de contrôle de liaison : LCP
‘Link Control Protocol’ protocole de mise en connexion avec négociation, tests, fermeture de connexion.
?Protocoles NCP : ‘Network Control Protocols’ pour supporter des fonctions de niveau 3
?Exemple IPCP Internet : distribution d’adresses IP.
? PPP protocole support d’extensions d’authentification, de confidentialité.
? Trames de sécurités incluses dans des trames PPP (format type HDLC).
? Zone protocole: permet de le multiplexage de différents flots de messages associés à des protocoles différents associés à PPP (suite des protocoles PPP).
Exemples de codes : IP 0x0021
LCP 0xC021 PAP 0xC023
CHAP 0x0223
MPPE 0x00FD
Rappel : Protocole LCP
? LCP est la partie contrôle de liaison PPP: gestion de connexion, authentification …
? Le format des trames LCP est utilisé pour LCP mais aussi pour les protocoles de sécurité
? La partie données d’une trame PPP dans le cas LCP.
? Format des trames PAP, CHAP mais aussi format des messages RADIUS.
0 1 2 4
| Code | Ident | Longueur | Données |
? Code (‘Code’)
Sur un octet le type d’un message LCP. ? Identificateur (‘ Identifier’)
Sur un octet il permet d’associer les requêtes et les réponses.
? Longueur (‘Length’)
Sur deux octets, la longueur totale des infos LCP incluant le code, l ‘identificateur et la donnée.
? Données (‘Data’)
La zone données est vide ou son format de la zone est défini par le code. Elle est généralement composée d’attributs (de variables transportées) selon une représentation classique type, longueur, valeur (attributs typiques un nom d’usager, un mot de passe …).
1 Protocoles associé à PPP
DESE , 3DESE
Microsoft MPPE
2 Protocoles avec les réseaux locaux
? Cadre général : le protocole ECP Encryption Control Protocol qui permet de sélectionner en PPP une méthode de chiffrement (RFC 1968 juin 1996)
? Chiffrement en DES : DESE (DES Encryption)
? Version 2 RFC 2419 (septembre 1998) : type = 3 (Version 1 RFC 1969 type=0, obsolete)
? DESE : Solution de type CBC Cipher Block Chaining
? C[i] = DES (P[i] ? C[i-1])
? Vecteur d’initialisation C[1] : un nonce transmis en clair.
? Autres caractéristiques
? Règle de bourrage : pour alignement blocs de 8 octets pour le DES.
? Numéro de séquence : pour le décodage en cas de perte de trame.
? Autre protocole : 3DESE RFC 2420 basé sur 3DES (type =2)
?MPPE : RFC 3078 (mars 2001).
?Voisin de la confidentialité Wifi WEP :
?Chiffre RC4 (de RSA Security).
?Correction de défauts du WEP.
?Longueur de clé privée négociable : choix possibles 40 ou 128 bits.
?La clé RC4 MPPE est changée fréquemment :
?La fréquence de changement dépend d’une négociation (la clé change éventuellement pour chaque trame).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol |A|B|C|D| Coherency Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
? Protocole : 0x00FD Valeur figurant pour la confidentialité MPPE après la phase de négociation PPP (négociant également la compression).
? Bit A : tables RC4 réinitialisée avant la transmission de la trame (donc le destinataire doit réinitialiser pour déchiffrer).
? Bits B, C : inutilisés.
? Bit D : indique une trame chiffrée ou en clair.
? Coherency Count : un numéro de séquence qui permet de conserver la synchronisation sur la clé utilisée (changements fréquents de clé).
? Encrypted data: La charge utile chiffrée.
? Problème de la réutilisation de la même clé en RC4 sur une donnée : le chiffre est cassé.
? MPPE : une méthode pour générer des clés successives en utilisant un hachage itéré (hachage utilisé SHA).
? StartKey est la première clé utilisée (clé d’origine).
? SessionKey est la nouvelle clé secrète utilisée pour générer la clé RC4 à chaque changement de clé.
? InterimKey est une clé temporaire pour chiffrer une phase de trafic.
? La table du chiffre RC4 est réinitialisée à partir de InterimKey:
rc4_key(RC4Key, Length_Of_Key, InterimKey)
? La nouvelle clé secrète sessionKey est obtenue par chiffrement RC4 de InterimKey:
SessionKey = rc4(RC4Key, Length_Of_Key, InterimKey)
? void GetNewKeyFromSHA( IN unsigned char *StartKey, IN unsigned char *SessionKey, IN unsigned long SessionKeyLength OUT unsigned char *InterimKey )
{
unsigned char Digest[20]; ZeroMemory(Digest, 20);
SHAInit(Context);
SHAUpdate(Context, StartKey, SessionKeyLength);
SHAUpdate(Context, SHApad1, 40);
SHAUpdate(Context, SessionKey, SessionKeyLength); SHAUpdate(Context, SHApad2, 40);
SHAFinal(Context, Digest);
MoveMemory(InterimKey, Digest, SessionKeyLength); }
? SHAInit(), SHAUpdate() and SHAFinal() sont des procédures de calcul de SHA Secure Hash Algorithm (initialisation, calcul, terminaison)
?Essentiellement réseaux locaux sans fils WIFI. ?Versions successives : WEP , WPA, WPA2
?Solutions traitées dans le cours sur la sécurité du WIFI.
1 Protocoles de base PAP/CHAP
Protocole PAP ‘Password Authentication Protocol’
Protocole CHAP ‘CHallenge Authentication Protocol’
2 Protocole RADIUS
‘Remote Authentication Dial-In User Service’
3 Protocole TACACS
‘Terminal Access Controller Access Control System’
4 La famille des protocoles EAP
‘Extensible Authentication Protocol’
Protocoles d’authentification
Protocole PAP ‘Password Authentication Protocol’
Protocole CHAP ‘CHallenge Authentication Protocol’
PAP : ‘Password
? PAP - RFC 1334 Octobre 1992 : un protocole d’authentification simpliste : authentification à mots de passe en clair sur le réseau.
? Protocole:
? Types de trames PAP
1 Authenticate-Request
2 Authenticate-Ack
3 Authenticate-Nak
? Emission par le demandeur d’un Authenticate_request avec un attribut mot de passe en clair.
? Acceptation du site distant par Authenticate_ack (mot de passe correct). ? Rejet par Authenticate_nak (mot de passe incorrect).
? Très faible sécurité de la circulation des mots de passe en clair compte tenu de la nature du réseau Internet.
? Variante propriétaire : SPAP ‘Shiva Password Authentication Protocol’ ? PAP sans améliorations très significatives.
CHAP : ‘CHallenge
? CHAP (RFC 1994 Aout 1996) : un protocole d’authentification à mots de passe qui améliore la sécurité du protocole PAP en échangeant les mots de passe chiffrés sur le réseau.
? Principe général : protocole avec défi ‘challenge’
? B s’authentifie auprès de A
? Un message "challenge" est émis par A vers B qui s’authentifie.
? Ce message comporte un nonce c’est à dire une valeur dans l’idéal imprévisible et unique (par exemple dépendant du temps et d’un secret).
? B répond en envoyant le mot de passe et le nonce haché au moyen d’un fonction de hachage à sens unique (MD5 par défaut).
? Le mot de passe doit être conservé en clair sur A pour permettre la vérification (le calcul par A de la fonction de hachage).
? L’authentification étant correcte : A renvoie une acceptation sinon un rejet.
? Intégration PPP :
? CHAP type de protocole PPP : 0x0223 . Structure des trames LCP;
? Types de messages utilisés
1 Challenge
2 Response
3 Success
4 Failure
? Message ‘Challenge’ : Principal attribut
? Le défi ‘challenge’ (le nonce) : une valeur aléatoire déterminée par le demandeur qui est imprévisible et unique.
? Message ‘Response’ : Principaux attributs
? A) Le nom d’usager,
? B) le MD5 (16 octets de MD5) de la chaîne
Identificateur, Mot de passe secret, nonce (la valeur de challenge)
? Messages ‘Success’ ou ‘Failure’
? Deux messages sans attributs (simplement typés) pour indiquer que la valeur reçue correspond à la valeur calculée ou non.
? CHAP résiste aux écoutes des mots de passe (‘sniffing’).
? CHAP résiste aux attaques de répétition.
? CHAP ne résiste pas à une écoute puis attaque à dictionnaire.
? CHAP est incapable de résister à toute attaque de type insertion d’un programme dans le flot des échanges qui peut aussi modifier les messages (‘active wiretapping’, ‘spoofing’).
? CHAP est peu pratique pour une utilisation distribuée
? Obligation de stocker les mots de passe en clair.
? Le service d’authentification doit être réalisé dans tous les points d’accès à un réseau (NAS, routeurs …) => Améliorations nécessaires.
? Variante propriétaire ARAP
? ARAP ‘Appletalk Remote Access Protocol’
? Protocole bidirectionnel (Authentification mutuelle client serveur) ? Avec challenge/réponse utilisant le DES pour le hachage.
? Variante propriétaire MS-CHAP (‘MicroSoft CHAP’)
? MS-CHAP V1 RFC 2433 Microsoft PPP CHAP Extensions
? Pour éviter de stocker le fichier des mots de passe en clairs sur le serveur CHAP on transmet aussi un hachage (selon une méthode propriétaire) du mot de passe.
? Le haché est comparé à un fichier de mots de passe hachés.
? Problème: faiblesse de la fonction de hachage retenue par Microsoft.
? MS-CHAP V2 RFC 2759 Janvier 2000 Microsoft PPP CHAP Extensions V2
? Correction des faiblesses de sécurité du hachage.
? Utilisation d’une valeur aléatoire à hacher avec le mot de passe.
? Réalisation d’une authentification mutuelle (dans les deux sens client serveur et serveur client).
? Abandon de la transmission directe du mot de passe haché.
? Possibilité : attaque force brute/à dictionnaire.
Scénario d’échange avec
? Demande_serveur_client : vérification_d'authentification avec identifiant_de_session, chaîne_aléatoire1 (cad un nonce1)
? Réponse_client_serveur : nom d'utilisateur, haché (chaîne_aléatoire1 , identifiant_de session, mot_de_passe), chaîne_aléatoire2) (cad un nonce2)
? Authentification du client : vérification par le serveur de la réponse du client.
? Réponse_serveur_client : succès ou d'échec , haché(chaîne_aléatoire2, la réponse hachée du client, mot de passe).
? Authentification du serveur : vérification par le client de la réponse du serveur.
? En cas de succès début des échanges.
2 Protocole RADIUS
Remote Authentication Dial-In User Service
? Radius ‘Remote Authentication Dial In User Service’: Société Linvingston donné à la communauté Internet : RFC 2138 (1997) dernière version RFC 2865 (2000)
Objectifs poursuivis
? 1- Proposer une approche centralisée de l’authentification
=> Solution souhaitée dans de nombreux cas (prestataires d’accès…)
? 2- Proposer une authentification à mot de passe originale (propre à RADIUS) mais proposer aussi de pouvoir utiliser plusieurs autres méthodes existantes au choix (PAP, CHAP, Kerberos ….).
=> On peut ainsi choisir un protocole plus ou moins sûr.
? 3- Etendre les fonctions d’authentification à des fonctions plus larges AAA
? ‘Authentication’ : Vérification d’identité
? ‘Authorization’ : Contrôle des droits ? ‘Accounting’ : Comptabilité
Radius fonctionnement client-serveur
(requête réponse)
Client Serveur radius radius
Un système d’accès Base
à un réseau Internet D’authentification d’informations AAA
(NAS)
? Client Radius : a priori un serveur d’accès à Internet ou à un service Internet au niveau liaison PPP.
? Cas le plus fréquent : le client RADIUS est un serveur de communication NAS ‘Network Access Server’
? Egalement possible un routeur ou un pare_feu ou une application nécessitant une authentification: telnet, rlogin
? Serveur Radius : un site centralisé implantant le service AAA.
? Un serveur RADIUS peut agir comme un proxy client pour un autre serveur RADIUS.
?Principes de sécurité
? Les échanges RADIUS sont sécurisés par une clé secrète partagée entre client et serveur, qui ne circule sur le réseau que hachée.
? Les usagers sont authentifiés par un mot de passe qui ne circule sur le réseau que haché.
?Protocole extensible
? Tous les échanges utilisent des attributs typés : syntaxe de transferts type, longueur, valeur.
? De nouveaux attributs peuvent être ajoutés sans modifier l’existant.
? Mécanismes d’authentification variés : dans le cadre RADIUS on peut utiliser PPP/PAP, PPP/CHAP,
UNIX/login (local ou NIS), ou d’autres authentifications (Kerberos).
Acheminement des messages
?Utilisation d’un transport Internet
? Un seul serveur Radius par réseau.
? Besoin d’acheminement des messages RADIUS entre clients et serveur Radius très éloignés.
? Utilisation naturelle de l’infrastructure Internet au niveau transport.
?Choix de UDP
? UDP est plus rapide.
? Le protocole Radius est sans état ‘stateless’.
? UDP simplifie l’implantation du serveur.
=> Chaque message RADIUS est encapsulé dans la zone donnée d’un segment UDP (port numéro 1812).
Tolérance aux pannes en
?Tolérer les pertes de messages avec UDP
?Conservation d’une copie des messages et utilisation de temporisateurs de retransmission.
?Tolérance à la panne du serveur Radius
?Mise en place d’une architecture en redondance passive de serveurs Radius.
?Serveurs primaires et secondaires.
?Si une requête vers le primaire échoue après quelques tentatives le secondaire est sollicité
0 1 2 3
? Code: Identifie le type du message.
| Code | Ident | Longueur |
| Authentificateur (16 octets) | ||
| Attributs | ||
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting-Response
11 Access-Challenge
12 Status-Server (experimental)
13 Status-Client (experimental)
255 Reserved
? Identificateur (‘identifier’) : associe requêtes et réponses (un octet).
? Longueur (‘length’) : longueur de toutes les zones données (deux octets)
?Authentificateur (‘Authenticator’): utilisé pour authentifier la réponse du serveur et pour protèger les mots de passe (nonce) (16 octets).
? Attributs (‘Attributes’): format (type, longueur, valeur) utilisés pour véhiculer toutes les informations nécessaires.
| Type | Longueur | Valeur … |
1 User-Name 2 User-Password 3 CHAP-Password
4 NAS-IP-Address 5 NAS-Port 6 Service-Type
7 Framed-Protocol 8 Framed-IP-Addres 9 Framed-IP-Netmask
10 Framed-Routing 11 Filter-Id 12 Framed-MTU
13 Framed-Compression 14 Login-IP-Host 15 Login-Service
16 Login-TCP-Port 17 (unassigned) 18 Reply-Message
19 Callback-Number 20 Callback-Id 21 (unassigned)
22 Framed-Route 23 Framed-IPX-Network 24 State
25 Class 26 Vendor-Specific
? Version de base
Client Serveur Access-Request
Access-Accept ou Access-Reject
? Version complète
Client Serveur
Access-Request
Access-Challenge
Access-Request
Access-Accept ou Access-Reject
Authentification simple:
? Deux attributs principaux :
? Attribut de type nom d’usager : pour identifier l’usager.
? Attribut de type mot de passe : contient le mot de passe usager protégé par :
MD5 ( secret , authentificateur ) XOR Mot_de_passe
? MD5 : fonction de hachage à sens unique pour créer un MAC de 16 octets.
? XOR : ou exclusif avec le mot de passe de 16 octets (cas particulier pour les mots de passe de plus de 16 octets)
? Sécurité : le serveur vérifie la connaissance du secret et du mot de passe
? Seul un client autorisé connaît le secret.
? L’authentificateur introduit de la variabilité/entropie dans MD5.
? MD5 protège le secret.
? XOR ou exclusif avec un nombre aléatoire protège le mot de passe.
?L’authentification complète avec challenge du client vis à vis du serveur RADIUS
? Une authentification renforcée.
? Exemple de la norme : pour l’utilisation d’une carte à puce.
?Message Access-Challenge
? Comporte un authentificateur de réponse : il permet l’authentification du serveur vis-à-vis du client.
? Un attribut type ‘state’ contient une chaîne binaire définie à la discrétion du serveur (un nonce, le challenge).
? Un attribut type ‘reply_message’ contient une chaîne une chaîne de caractère explicative.
? A la réception de ‘access-challenge’ : le client doit répondre par ‘access-request’ comme dans la première transmission avec:
? un nouvel identificateur
? un nouvel authentificateur
? la chaîne binaire fournie par l’attribut state doit être ajoutée au mot de passe.
? A la réception de ‘access-request’ :
? un calcul identique à celui de l’access-request simple est effectué par le serveur.
? qui accepte ou rejette la demande d’authentification par ‘accessaccept’ ou ‘access-reject’.
? Dans les messages Access-Accept, Access-Reject, Access-Challenge : présence du champ authentificateur calculé comme un authentificateur de réponse.
? Valeur du ‘Response Authenticator’
? MD5 ( Code , Identificateur, Longueur, Authentificateur requête, Attributs de la réponse ,Secret partagé).
? Ce hachage calculé par le serveur et vérifié par le client permet d’authentifier le serveur qui est le seul à connaître le secret partagé.
? Les identificateurs et l’utilisation de l’authentificateur contenu dans le précédent message access-request du client protègent des répétitions.
Protocole Radius :
? Protocole très largement utilisé ? Par les prestataires d’accès Internet.
? Dans les réseaux Intranet.
? Pour sa gestion centralisée des informations AAA.
? Très nombreuses fonctions d’administration, de configuration ou de comptabilité :
? Associées à la possibilité d’échanger un grand nombre d’attributs par exemple des certificats.
? Fourniture d’adresse IP par un serveur centralisé.
? Gestion d’informations comptables en vue de la facturation (temps de connexion).
? RADIUS n’est plus de niveau liaison
? Activé au niveau liaison avec des formats de message de liaison.
? RADIUS utilise UDP et est en fait un protocole d’application.
? Pour fonctionner un client RADIUS doit déjà avoir accès au réseau.
3 Protocoles TACACS
TACACS, XTACACS, TACACS+
Terminal Access Controller Access Control System
? Tacacs se place sur le même créneau que RADIUS.
? Authentification centralisée.
? Fonctions AAA
? Tacacs est un protocole CISCO
? Diffusion industrielle liée aux produits CISCO.
? Trois versions successives: ? TACACS, XTACACS, TACACS+
? Dernière version TACAS+ => version d’actualité.
? Incompatible avec les précédentes versions.
? Reprend de nombreux aspects (les meilleurs aspects) de Radius.
? Venant après RADIUS Tacacs+ peut proposer des éléments d’amélioration.
START (authentication) : usager essayant de se connecter
REPLY (authentication) : demande de nom d’usager
CONTINUE (authentication) : réponse de nom d’usager
REPLY (authentication) : demande de mot de passe
CONTINUE (authentication) : fourniture du mot de passe
REPLY (authentication) : réussite ou échec de l’authentification
REQUEST (authorization) : usager demande accès au shell
RESPONSE (authorization) : statut de l’autorisation d’accès (oui ou non)
REQUEST (accounting) : début d’une session
RESPONSE (accounting) : acquittement début de session enregistré
…… Suite des requêtes réponse d’autorisation etc
REQUEST (accounting) : fin d’une session
RESPONSE (accounting) : acquittement fin de session enregistré
? 1) Méthodes très similaires au niveau sécurité.
? 2) Mais TACACS+ utilise TCP (RADIUS utilise UDP).
? TACACS: meilleur contrôle d’erreur et meilleur gestion de congestion. ? TACAS plus coûteux et plus lent.
? 3) TACACS+ encrypte toute la charge utile des messages (tous les attributs) pas uniquement le mot de passe.
? 4) TACACS sépare les requête d’authentification des requêtes d’autorisation ou de comptabilité
? Radius mélange les attributs concernant les fonctions AAA dans les messages.
4 La famille des protocoles EAP
(‘Extensible Authentication Protocol’)
1 EAP de base
2 EAPOL
3 EAP-MD5
4 LEAP
5 EAP-SIM
6 EAP-TLS
7 EAP TTLS
8 PEAP
Protocole EAP
? 1) Rappel de l’évolution des points de vue sur l’authentification.
? 1) La génération des protocoles intégrés à PPP (PAP/CHAP): problème chaque point d’accès doit être un serveur d’authentification.
? 2) La génération des protocoles d’accès à des serveurs d’authentification (RADIUS/TACACS).
? 2) EAP contrôle l’accès en PPP d’un poste de travail à un réseau avec une approche à trois entités :
? Un client : qui n’a pas encore l’accès au réseau et communique en PPP, ? Un point d’accès : qui peut communiquer sur le réseau avec un serveur, ? Un serveur d’authentification : connecté au réseau.
? 3) EAP: un protocole ‘générique’ pour supporter de très nombreuses variantes de protocoles d’authentification sans trop polluer PPP.
? EAP: un canevas (‘framework’) pour récupérer toutes les solutions d’authentification désirées anciennes ou nouvelles.
? Solutions existantes (‘héritées’ ‘legacy’) : PAP/CHAP/MS-CHAP.
? Solutions utilisant des matériels : cartes à puces ou clé USB ou cartes à jetons.
? Mots de passe à usage unique : ‘One time passwords’ RFC 1760.
? Authentification par clé publique : utilisant des certificats.
? Plusieurs dizaines de versions de protocoles d’authentification déployés sous EAP.
? RFC 2284 mars 1998 : dernière version RFC 3748 juin 2004
? EAP et les réseaux locaux: EAP d’abord défini dans le cadre de PPP est adapté aux réseaux locaux sous les références IEEE 802.1x (EAPOL) .
Protocole EAP
? 1) Le poste à authentifier (‘Supplicant’): un poste client.
? 2) Le point d’accès (‘Authenticator’) : un serveur d’accès réseau NAS, une borne Wifi AP, un routeur, un commutateur de réseau local …)
? 3) Le serveur d’authentification (AS ‘Authentication Server’) : typiquement un serveur RADIUS ou TACACS.
Un poste client Un point d’accès Un réseau d’authentificationUn serveur
? 1) Quatre types de messages : client/serveur
? EAP-Request , EAP-Response, EAP-Success, EAP-Failure.
? 2) Messages qui servent uniquement :
? A acheminer des requêtes réponses dans un protocole client serveur.
? A notifier une réussite ou un échec d’authentification.
? 3) EAP ne définit aucun mécanisme en propre d’authentification
? Les contenus des messages EAP sont des attributs ‘transparents’ .
? On peut mettre des contenus d’un autre protocole (exemple un certificat sous la forme d’un attribut RADIUS).
? 4) Le plus important c’est d’atteindre une situation ou après un échange de requêtes réponses on a un succès ou un échec utilisable par le point d’accès.
EAP : un échange type
Protocole EAP sur réseaux locaux :
? EAP défini à l’origine : uniquement pour des liaisons PPP (accès réseau par modems, ADSL, liaisons spécialisées).
? Objectif EAPOL : transmettre des messages EAP sur des réseaux locaux (filaires Ethernet ou sans fil Wifi) pour supporter tous les protocoles d’authentification EAP sur LAN.
? EAPOL définit un nouveau type de protocole : champ type de la trame IEEE 802 Ethernet pour que les 4 messages EAP puissent être transmis sur réseau local.
? Normalisation dans les réseaux locaux : IEEE 802.1X.
? Utilisation EAPOL significative dans les réseaux WIFI :
normes de sécurité WPA Wireless Protected Access.
? EAP-MD5: la méthode d’authentification la plus basique transportée par EAP.
? Très similaire à CHAP.
? Le serveur transmet un nonce (une valeur aléatoire de défi).
? Le client concatène le mot de passe et le nonce et le hache en MD5. Retourne cette valeur au serveur.
? Le serveur vérifie le hachage.
? Solution sensible aux écoutes du trafic suivie d’une attaque hors ligne par dictionnaire ou par force brute.
Protocole LEAP
? Solution Cisco: pour améliorer la sécurité trop faible du
WEP
? Première implantation de EAP et 802.1X pour réseaux sans fils.
? Solution à mot de passe secret partagé basée sur MSCHAP.
? On échange également une clé de session : échange sécurisé par le secret partagé MS-CHAP.
? Comme MS-CHAP : ne résiste pas aux écoutes et attaque par dictionnaire ou force brute.
Echanges
Du client
Phase
?Utilisation d’une carte à puce.
?Protocole défini pour des téléphones GSM => carte SIM des téléphones portables GSM ?Utilisation possible également en WIFI.
?Authentification EAP-SIM : différente de l’authentification GSM de base (protocoles A3-A5).
?Utilisation du secret de la carte SIM partagé avec le point d’accès pour une authentification challenge/réponse puis dérivation d’une clé de session.
? TLS Transport Layer Security (RFC 2246) définit une méthode d’authentification pour le niveau transport :
? Une méthode est basée sur les clés publiques.
? Nécessité de certificats client et serveur.
? Autres solutions possibles aussi (clés secrètes pré partagées).
? Partie authentification de TLS et échange de clé de session : portée sous EAP.
? Client et server s’authentifient mutuellement :.
? Terminaison par l’échange de clé secrète de session : notion de ‘pre-master key’ p et de master key .
? Solution recommandée pour un bon niveau de sécurité (à condition de vérifier les certificats).
Protocole EAP-TLS: un scénario de
Request (Random)
Générer c= random Response (c)
Générer s= random
Request (s,certificat_serveur)
Générer p= random Response (RSA_cle_publique_serveur(p), certificat_Client, signature_client)
Authentification du client
Request (TLS_finished, HASH (contenu_messages_précédents dont p))
Authentification Response (TLS_finished) du serveur
Success Success
Clé maitresse partagée HASH (c,s,p)
? Méthode utilisant le début du protocole TLS.
? Pour éviter d’avoir à gérer des certificats clients: création d’une connexion TLS chiffrée en utilisant la clé publique serveur (les échanges EAP sont protégés par la clé de session échangée selon la méthode TLS).
? Poursuite de l’authentification : généralement par une méthode à mot de passe
? Liste des principales méthodes supportées en TTLS : PAP, CHAP , MS-CHAP, MS-CHAPV2, EAP-MD5, EAP-GTC, EAP-TLS.
? EAP-GTC Generic Token Card : RFC 2284 Une solution générale EAP pour transporter des infos d’authentification fournies par des cartes à jetons (token cards). Dans la pratique GTC achemine un couple usager:mot-de-passe.
Request (Random)
Générer c= random Response (c)
Générer s= random
Request (s,certificat_serveur)
Générer p= random Response (RSA_cle_publique_serveur(p))
Clé maitresse partagée K= HASH (c,s,p)
Request (K (message_d_un_protocle_d_authentification))
Response (K (message_d_un_protocle_d_authentification))
Authentification du client
Success Success
Protocole PEAP
? Solution propriètaire très voisine de EAP-TTLS proposée par Microsoft, CISCO et RSA Security: se différencie surtout par le format des données transportées.
? Comme EAP-TTLS : utilisation de la clé publique serveur pour échanger une clé de session et chiffrer en confidentialité des échanges EAP.
? Deux authentifications souvent citées : PEAPv0/EAPMSCHAPv2 , PEAPv1/EAP-GTC (mais sont aussi possibles EAP-MD5, EAP-SIM, EAP-TLS)
? Utilisation de EAP-PEAP dans le Wifi : standards WPA , WPA2 Wired Protected Access.
?EAP : un cadre pour transporter tous les protocoles d’authentification connus au niveau liaison :
? avec PPP sur liaison spécialisée.
? ou sur réseau local EAPOL 802.1x.
?Beaucoup de propositions pour supporter toutes les solutions d’authentification connues.
?Utilisation en croissance significative.
1 Point to Point Tunneling Protocol (PPTP)
2 Layer 2 Tunneling Protocol (L2TP)
Non traité Layer 2 Forwarding (L2F)
‘Point to Point Tunneling Protocol’ PPTP :
? 1) Origine : Consortium d’industriels avec Microsoft
(architecture RAS Remote Access Service) mais aussi US
Robotics/3COM, Ascend, etc … Norme : RFC 2637 en 1999.
? 2) Objectif de base : permettre d’acheminer des protocoles non Internet (NetBios, IPX, Appletalk…) sur un réseau Internet => encapsulation dans le protocole de liaison PPP.
? 3) Utilisation dans des communications en mode tunnel quelconques: en fait pour les protocoles Internet IP sur PPP. ? 4) Construction de tunnels selon deux modes:
? Volontaire (‘Voluntary’) : le client décide de construire un tunnel jusqu’au serveur.
? Obligatoire (‘Compulsory’) : le tunnel est imposé automatiquement.
? 5) Mise en œuvre de fonctions de sécurité :
authentification, confidentialité pour une approche VPN de niveau liaison.
Protocoles utilisés
? 1) Au début le client PPTP établit avec le NAS serveur d’accès une liaison PPP : partie LCP Link Control Protocol de PPP.
? 2) Le client PPTP établit une connexion de transport TCP avec le serveur PPTP (le PNS) : pour négocier les paramètres de fonctionnement du tunnel PPTP (notion de connexion de contrôle PPTP).
? 3) Le client PPTP peut alors fonctionner en mode tunnel en utilisant le protocole GRE d’encapsulation.
? 4) Au dessus de GRE, le client et le serveur dialoguent en utilisant le protocole PPP, le lien PPP établi entre le client et le serveur :
? Permet d’acheminer n’importe quel protocole de niveau 3 avec PPP comme protocole de niveau 2.
? Tout se passe comme s’il existait une liaison filaire gérée en PPP entre le client PPTP et le serveur PPTP sans que le FAI n’ait à en connaître.
? 1) Pas de définition particulière de sécurité dans la RFC 2637 PPTP.
? 2) La RFC PPTP indique qu’on peut sécuriser un tunnel PPTP est utilisant tous les protocoles de sécurisation classiques des communications PPP.
? Authentification Password Authentication Protocol (PAP), Challenge Handshake
Authentication Protocol (CHAP), Extensible Authentication Protocol (EAP) avec par exemple EAP-TLS Transport Layer Security Protocol
? Confidentialité : Encryption Control Protocol (ECP) pour négocier la confidentialité, PPP DES Encryption Protocol (DESE) ou PPP Triple DES (3DESE)
? Authentification MS-CHAP ‘Microsoft Challenge Authentication Protocol’
? En V2
? Confidentialité MPPE ‘Microsoft Point to Point Encryption’
? Autre possibilité : compression MPPC ‘Microsoft Point to Point Compression’
? 1) PPTP transporte différents protocoles : IP/IPX/NetBios.
? 2) Protocoles de sécurité : les protocoles de sécurité du niveau liaison PPP => niveau de sécurité de moyen à bon en relation avec ces protocoles.
? 3) Utilisation de PPTP : due aux difficultés de l’utilisation de IPSEC avec NAT (de même que tous les tunnels de liaison).
? 4) Limitations de PPTP:
? Ne fonctionne que sur le réseau Internet.
? Surcharges protocolaires liées aux choix d’encapsulation.
? Surtout supporté en raison des implantations Microsoft.
? Evolution vers le standard L2TP.
2) L2TP ‘Layer Two Tunneling Protocol’
? RFC 2661 (1999) : Support principal CISCO mais aussi Microsoft.
? Dernière version (mars 2005) (RFC 3931) : L2TP V3.
? L2TP : une amélioration des tunnels antérieurs PPTP/L2F.
? L2TP construit des tunnels utilisables pour différents protocoles transportés et différents transporteurs:
? Le protocole transporté visé est surtout PPP (Point to Point Protocol) ? Le protocole transporteur est surtout UDP/IP.
| Entête MAC | Entête IP | Entête UDP | Entête L2TP | Entête PPP | Charge utile |
? La meilleure sécurité L2TP est réalisée par IPSEC : combinaison des deux protocoles sous le sigle L2TP/IPsec (RFC 3193 : ‘Securing L2TP using IPsec’).
? Extrémités d’un tunnel L2TP :
? Client (initiateur de tunnel) :
LAC ‘L2TP Access Concentrator’.
? Serveur (en attente d’ouverture de tunnels) :
LNS ‘L2TP Network Server’.
? Tunnels et session L2TP :
? Session : une communication identifiée pour des usagers de L2TP.
? Tunnel : une communication sécurisée permettent de créer de multiples sessions à l’intérieur d’un même tunnel.
? Types de messages dans un tunnel L2TP
? Messages de contrôle L2TP :
? Protégés en contrôle d’erreur par L2TP.
? Messages de données du protocole transporté:
? Le contrôle d’erreur est celui du protocole transporté (souvent rien).
?1) Sécurité : aucune méthode en propre n’est définie.
?2) Confidentialité:
?Possibil
