version PDF - Flash informatique

Contrôle d’accès
Daniel.Grandjean@epfl.ch, Domaine IT
L’
accès fiable et efficace aux réseaux IP est devenu
indispensable pour la recherche, l’éducation et la
production. L’usage de cette précieuse ressource est souvent
considéré comme étant un accessoire (ou attribut) de l’outil
informatique alors qu’elle en est le noyau.
Repères historiques
1994-2003: PPP (Point to Point Protocol) (des dizaines de RFC!)
1997-2000: RADIUS (Remote Authentication Dial In User Service)
(RFC 2058 remplacé par 2138, puis 2865)
1998-2004: EAP (Extensible Authentication Protocol) (RFC 2284
remplacé par 3748)
1999-2003: TLS (Transport Layer Security protocol) (RFC 2246 et
étendu par 3646)
2001:
IEEE 802.1X
2003:
WPA Wi-Fi Protected Access
2004:
IEEE 802.11i
Un objet raccordé de manière permanente au réseau,
hérite de ce fait une connexion réseau avec les privilèges
(ou les contraintes) alloués à cette machine. Dans ce cas de
figure, l’accès au réseau se résume alors à l’accès physique à
la machine, ou du moins à son raccordement physique. Il
faut toucher pour être raccordé.
Le système d’exploitation de la machine peut encore
présenter une ligne de défense ténue: l’utilisateur en quête
de connectivité devra ouvrir une session. C’est-à-dire se faire
authentifier par le système. Le système autorise ensuite
l’usager à faire ce qu’il est en droit d’accomplir.
Dans le cas de systèmes multi-utilisateurs, l’accès au
réseau est partagé par tous les utilisateurs hébergés simultanément par la machine. Les communications ne sont
généralement pas ventilées par utilisateur, ce service n’étant
pas inclus dans la majorité des systèmes d’exploitation. La
totalité du trafic est donc imputée à la machine.
Si cette vision du monde prévaut encore dans de nombreux cas, la multiplication des objets dépendants de la
présence d’une connexion réseau introduit de nouveaux
modèles:
❚ les objets sont portables ou transportables, ils peuvent
sauter d’une prise murale à l’autre, mais toujours dans
les limites du campus. Des indélicats peuvent être tentés
de se substituer à des équipements fixes.
Exemple: notebook mobile, imprimante fixe.
❚ les réseaux utilisent les technologies sans fil (radio). Les
objets ne sont plus trivialement localisables. L’accès
physique au réseau n’est plus nécessaire. Le trafic est
facilement observable par la brute, le bon et le méchant.
Exemple: notebook avec carte WIFI, PDA, téléphone
❚ les utilisateurs ont plusieurs objets, ils peuvent être personnels ou de fonction.
Exemple: un PDA privé et un téléphone de service.
❚ les utilisateurs appartiennent à des entités administratives
disparates.
Exemple: étudiants, collaborateurs, consultants, visiteurs,...
Pour allouer au nomade (par l’intermédiaire de l’objet
qu’il utilise) les services réseau qu’il est en droit d’obtenir,
l’infrastructure doit être pourvue de certaines fonctionnalités
nouvelles:
❚ un moyen d’authentifier un utilisateur ou une machine;
❚ être à même de concrétiser les décisions prises comme
suite à l’authentification, c’est-à-dire les résultats de
l’autorisation;
❚ et le cas échéant de protéger la confidentialité du trafic.
En fin de compte si les outils sont nouveaux, les tâches ont
un air de déjà vu: rappelez-vous votre bonne vieille connexion
modem sur votre ligne téléphonique. Vous vous connectez.
Vous montrez patte blanche et vous êtes sur l’Internet. Votre
opérateur vient de vous authentifier et de vous fournir une
prestation correspondante à votre plan tarifaire. Le tout étant
bien sûr comptabilisé.
Concrètement, vous avez établi une communication
point à point entre votre ordinateur et un port dans le central
téléphonique avec le protocole PPP. Vous avez été authentifié
par le serveur RADIUS de votre fournisseur d’accès Internet
[ISP](Internet Service Provider).
Le succès de PPP dans les environnements les plus variés
a mis en évidence qu’il était difficile de lui adjoindre de nouvelles méthodes d’authentification. Il en découla la création
d’un système d’authentification modulaire reposant sur un
socle unique: le protocole EAP.
Un a s s e m b l a g e d e s p r o t o c o l e s P P P, E A P,
IEEE802{.3 .5 .11} et subsidiairement de RADIUS est connu
comme la norme
IEEE802.1X.
802.1X définit un
mécanisme relais
d’authentification
au niveau de la
couche 2 du modèle ISO 2 (fig. 1)
pour les réseaux
physiques de type
IEEE802 {Ethernet, Token Ring,
r a d i o } e t P P P.
Le mécanisme
d’authentification
802.1X intervient
avant d’éventuels
mécanismes d’auto
configuration tels
fig. 1 – les sept couches ISO
que DHCP (Dynafi 2 – 1er mars 2005 – page 3
Contrôle d’accès
mic Host Configuration Protocol) ou PXE (Pre-Boot Execution
Environment).
802.1X
❚ permet le contrôle d’accès aux ressources même si l’accès
physique au réseau est incontrôlable;
❚ organise, le cas échéant, la distribution de clefs cryptographiques aux clients sans fil.
❚ est conçu pour être utilisé partout où l’on peut appliquer
le concept de point d’accès (port ou interface pour les
anglophones).
802.1X introduit le concept de port contrôlé (PAE
pour Port Access Entity).
fig.2 – port PAE
Les acteurs principaux du protocole
Trois entités interagissent et sont nécessaires à une
authentification 802.1X:
L’authentificateur ou l’authenticator. Il gère l’état du port
contrôlé. Il a la responsabilité d’exiger une authentification
de la part du système à authentifier.
Un authentificateur est typiquement le port physique ou
logique d’un commutateur ou switch réseau. Dans une infrastructure sans fil, l’authentificateur peut être une borne radio
ou Access Point [AP]. L’authentificateur relaie les informations
d’authentification vers le serveur d’authentification.
L’authentifié, le client, nommé supplicant dans la littérature 802.1X ou peer dans la terminologie EAP. Le supplicant
a la tâche de présenter les informations d’autorisation à la
demande de l’authentificateur. Dans certaines configurations,
le supplicant peut agir spontanément.
Concrètement, l’adaptateur Ethernet d’un notebook est
un supplicant s’il est pourvu d’un client logiciel conforme
à la norme 802.1X. Par extension, ce logiciel est souvent
nommé supplicant. Un composant de l’infrastructure réseau
peut aussi jouer le rôle de supplicant. Tel un port de switch
raccordé à un autre switch. Un Access Point utilisé comme
passerelle ou bridge radio.
Le serveur d’authentification ou authentication server
procure un service d’authentification à l’authentificateur.
Ce service détermine, à partir des éléments (essentiellement
l’identité) de la requête du demandeur, les services qui lui
sont accessibles. Ce serveur peut être sur la machine qui sert
d’authentificateur ou accessible à ce dernier via le réseau.
Concrètement un serveur RADIUS doté des extensions
EAP remplit ce rôle. Il assortit son message d’acceptation de paramètres de configuration du port à l’usage de
l’authentificateur.
fi 2 – 1er mars 2005 – page 4
fig. 3 – acteurs principaux
Fonctionnement général du protocole
L’état du port de l’authentificateur détermine si le supplicant est autorisé à accéder le réseau. L’état initial d’un port
est non contrôlé ou non autorisé. C’est-à-dire que le port est
imperméable à tout le trafic qui n’appartient pas à 802.1X.
Le port passe dans l’état autorisé ou contrôlé dès que le
supplicant est positivement authentifié. Tout le trafic du client
circule alors librement au travers du port.
Le trafic reste bien sûr subordonné à la présence de la connectivité au niveau physique ou à l’établissement du link. Les
ports des équipements doivent être en mode actif ou up.
Les échanges EAP reposent sur seulement quatre messages:
❚ EAP-Request
❚ EAP-Success
❚ EAP-Response
❚ EAP-Failure
Le cœur de 802.1X est la définition de l’encapsulation
des paquets EAP pour les réseaux IEEE802. Les trames EAP
over LAN [EAPoL] sont pour les réseaux filaires, les trames
EAP over WLAN [EAPoW] pour les réseaux Wi-FI.
Quatre messages, non indispensables, sont ajoutés:
❚ EAPoL/EAPoW-Start
❚ EAPoL/EAPoW-Logoff
❚ EAPoL/EAPoW-Key
❚ EAPoL/EAPoW-Encapsulated-ASF-Alert
L’échange 802.1X peut se résumer à ce dialogue au niveau
de la couche ISO 2
Contrôle d’accès
Le supplicant utilise le EAPol/EAPoW-Start pour tester
la présence d’un Authenticateur. Mais l’authenticateur peut
devancer le supplicant en émettant un EAP-Request dès la
détection d’une connexion.
Le supplicant n’est pas forcé de demander sa déconnexion
par un EAPoL/EAPoW-Logoff. Il peut filer à l’anglaise. La
perte du link provoque le retour du port dans l’état non
autorisé. Le client doit se re-authentifier s’il est physiquement
débranché ou s’il perd son association avec la borne radio.
Une authentification 802.1X
EAP est le socle de base. De nombreuses autres méthodes
d’authentification peuvent venir se greffer par-dessus. Les
plus répandues sont EAP-MD5, LEAP, EAP-TLS, EAPTTLS, PEAP.
La grande majorité des supplicants disponibles aujourd’hui
suppportent la méthode PEAP/MS-CHAP-V2. Cette méthode illustre bien comment les différents protocoles sont
imbriqués à la manière de poupées russes. Passons succintement en revue une authentification PEAP/MS-CHAP-V2
sur un réseau filaire:
❚ le link est up. L’authentificateur émet une EAP-Request:
identity.
❚ le supplicant émet une EAP-Response où il donne son
identité et exprime le souhait d’utiliser PEAP. Cette
identité est l’outer identity et est visible d’un observateur
extérieur. L’authentificateur relaie l’EAP-Response au
serveur RADIUS mais cette fois emballée dans une trame
RADIUS-Access-request.
❚ la réponse du serveur RADIUS est un RADIUS-Access-Challenge emballant une EAP-Request:start PEAP.
L’authentificateur passe l’EAP-Request:start PEAP au
supplicant.
❚ le supplicant et le serveur RADIUS échangent une série
de messages EAP-PEAP.
Le but de cet échange est d’établir un tunnel TLS. Dans
cette opération le certificat du serveur RADIUS est vérifié.
Le client a donc la certitude qu’il s’adresse à un serveur de
confiance. Ils négocient également l’établissement d’un canal chiffré entre eux. Ce canal est similaire à celui entre un
navigateur Web et un site bancaire.
Le canal TLS établi est utilisé pour mener à bien une
authentification EAP-MS-CHAP-V2. L’authentificateur
se contente de transformer les trames EAP-Response du
supplicant en trame RADIUS-Access-Request et les trames
RADIUS-Access-Challenge en trames EAP-Request. Comme
tous les observateurs potentiels de ce trafic réseau, il n’est pas
capable d’en décrypter le contenu.
Tout ce qui suit à lieu sur le canal sécurisé et entre la
supplicant et le serveur RADIUS:
❚ le serveur RADIUS émet une EAP-Request:identity.
❚ le supplicant émet une EAP-Response avec son identité.
Cette identité est l’inner identity et est invisible d’un
observateur.
❚ RADIUS émet une EAP-Request:EAP-MS-CHAP-V2
Challenge et lance un défi au client.
❚ le supplicant relève le défi du serveur RADIUS et en
profite pour le défier à son tour dans un EAP-Response:
EAP-MS-CHAP-V2 Response.
❚ RADIUS émet un EAP-Request:EAP-MS-CHAP-V2
Success qui informe le client que le défi est relevé et il
relève celui du client.
❚ le supplicant répond avec un EAP-Response:EAP-MSCHAP-V2 Ack si le serveur RADIUS a relevé son défi.
A ce moment, il est établi que le client et le serveur
connaissent le même mot de passe pour une identité donnée. Le client a la certitude qu’il n’a pas conversé avec un
imposteur.
❚ Toujours dans le tunnel, RADIUS émet un EAP-Success.
Mais comme l’emballage extérieur est un RADIUS-Access-Accept, l’authentificateur sait qu’il est temps d’ouvrir
le port contrôlé.
Le client a accès au réseau. Le cas échéant, c’est ici que
prend place la phase de configuration de la connexion IP:
DHCP acquisition d’une adresse, PXE boot réseau...
fig. 5 – Exemple d’une configuration Ethernet
Rapide à configurer pour l’utilisateur final, EAP/MSCHAP-V2 est aussi bien adapté au contrôle d’accès sur un
port Ethernet que pour les réseaux Wi-Fi. Toutefois, la mise
en œuvre d’une grande infrastructure sans fil offrant un bon
confort en déplacement sur un campus et un nomadisme
extra-muros requiert un soin tout particulier dans le choix
et l’assemblage des composants. Dans un prochain article,
nous aurons l’occasion d’aborder plus en détail les solutions
techniques mises en œuvre dans les réseaux radio utilisant
le protocole 802.1X.
Mais sans attendre, il est déjà possible de pratiquer le
contrôle d’accès par 802.1X à l’EPFL. Les utilisateurs du
réseau radio de l’école qui souhaitent s’affranchir du client
VPN peuvent visiter l’URL http://network.epfl.ch/ara. Ils
y trouveront les informations sur le déploiement du Wi-Fi
Protected Access [WPA] sur notre campus. Les amateurs de
802.1X câblés sont bien sûr aussi cordialement invités à se
rendre sur cette page! ■
fig. 4 – imbrication des protocoles
fi 2 – 1er mars 2005 – page 5