Differences

This shows you the differences between two versions of the page.

--- docpublic:reseaux:services:radius [2011/03/09 16:34]
PROCACCIA
+++ docpublic:reseaux:services:radius [2011/03/10 08:49] (current)
PROCACCIA
@@ Line 22: / Line 22: @@
   * Called-Station-Id adresse MAC du NAS
   * Calling-Station-Id adresse MAC du poste client terminal
+  * EAP-Message (n°79) transport dans radius des échanges EAP
 ==== Protocoles Radius ====
@@ Line 63: / Line 64: @@
   * EAP/TLS (Transport Layer Security, successeur de SSL) authentification par cetificats electronique mutuels (client et serveur)
-  * EAP/PEAP (Protected EAP)=> echange de mot de passe protégés dans un tunnel chiffré
+  * EAP/PEAP (Protected EAP)=> echange de mot de passe protégés dans un tunnel chiffré, mot de passe type microsoft/samba mschapv2 hash MD4
-  * EAP/TTLS (Tunneled TLS) => echange de mot de passe protégés dans un tunnel chiffré
+  * EAP/TTLS (Tunneled TLS) => echange de mot de passe protégés dans un tunnel chiffré, mot de passe type pap ou chap, compatible avec une base d'auth unix.
+==== protocole EAP ====
+=== 3 couches ===
+  - EAP, couche basse juste au dessus des trames 802 (niveau 2) , transmet les paquets de type //Request, Success, Failure//.
+  - EAP Peer et Authneticator, respectivement pour le poste terminal et le NAS ou serveur radius, interpretation du type de paquet //Request ou Response // puis orientation vers la couche suivante (EAP methode) suivant le protocole d'authentification (TLS, PEAP ...)
+  - EAP Method, couche "haute" de la pile EAP, contient le code logiciel du protocole d'authentification, cette couche n'est pas necessaire sur le NAS .
+=== 4 étapes ===
+  - Identité Externe, entre le NAS et le supplicant (terminal client), le NAS envoie un EAP-Request/Identity au client il repond par un EAP-response/Identity => identité externe configurée dans le supplicant (clée de recherche dans la base du serveur), celle ci sera recopiée par le NAS dans un attribut radius //User-Name// du paquet //Access-Request// adressé au serveur radius.
+  - Négociation du protocole, à la réception de l'//Access-Request//, le serveur construit un //Acces-Challenge// avec une proposition de liste de protocole d'authentification (PEAP, TLS ...), relayés par le NAS au supplicant .
+  - Protocole Transporté, il s'agit l'exécution du protocole d'authentification négocié (PEAP, TLS, TTLS ...) qui generera plus ou moins d'echanges EAP (request/Response) associés à l'encaspluation Radius (Request/Challenge).
+  - Gestion des clés de chiffrement, etape réservée au Wifi, elle permet la gestion dynamique des clés de chiffrement.
+=== EAP/PEAP ===
+authentification mutuelle entre le client et le serveur, mais asymetrique, le client authentifie le serveur sur la base du certificat serveur, le serveur authentifie le client sur la base d'un login/password . Le supplicant devra donc contenir une identité externe, une identité interne (au tunnel chiffré)existant dans la base d'authentification et son mot de passe associé.
+=== EAP/TTLS ===
+meme principe, authentification mutuelle et asymetrique (afin d'eviter de disposer d'une PKI => cas de EAP/TLS !) . TTLS interviens dans l'etape "3" d'EAP (Protocole Transporté) et se distingue de PEAP notament par l'insertion d'un serveur TTLS entre le NAS et le serveur Radius . De meme que PEAP, il y a une phase //TLS handshake// pour établir un tunnel chiffré et une //phase TLS Record// pour y faire passer un protocole d'authentification par mot de passe , mais ensuite ce sera dans des paquets TTLS qu circuleront les paquets du protocole d'authentification, paquets formés de couples Attribut/Valeur compatibles avec ceux de Radius.
+===== sécurité Wifi =====
+Le securisation de la liaison radio entre le client terminal et le NAS est primordiale. Les faiblesses de WEP (Wired Equivalent Privacy) ne sont plus a démontrer. WPA (Wifi Protected Access) en attendant la norme 802.11i puis WPA2 quand la norme est sortie en 2004, ont nettement ameliorés la securité du lien radio . Un changement périodique des clés de chiffrement a lieu, TKIP (Temporal Key Integrity Protocol) pour WPA, mais basé sur l'algo de chiffrement RC4, WPA2  est basé sur un meilleur algo; AES.
 ===== Freeradius 2.X =====
+==== Principes ====
+deux étapes, autorisation puis authentification ! curieux de prime abord mais cela fonctionne comme ça .
+Freeradius prepare le terrain en établissant la liste des autorisations qui sera envoyée au NAS quand l'authentification sera positive .
+=== base d'autorisation ===
+Pour ce faire radius s'appuie sur une base d'autorisation (fichier //users//) dont le point d'entré est l'identifiant radius (champ User-Name) suivit de trois catégorie d'attributs
+  - check-items, criteres supplémentaires à l'indetifiant (@Mac poste client, date/heure ...)
+  - reply-items, quand l'authentification sera positive, ils seront renvoyé avec la reponse, positionnement du vlan par exemple
+  - config-items, attributs interne au serveur radius, variables de configuration,rxp Auth-Type qui peux imposé un type d'authentification pour tel identifiant, par defaut methode EAP .
+=== base d'authentification ===
+simplement pour verifier le mot de passe de l'identifiant, souvent une base de compte externe (ldap, windows, sql fichier a plat etc ...) , ou la meme base que la base d'autorisation dans le cadre du simple fichier //users//.
 ==== installation a base de RPM ====
@@ Line 368: / Line 412: @@
 ===== FreeRadius EAP =====
-cinematique pour EAP à partir des fichiers de configuration
+cinematique pour EAP, qui est la methode par defaut ,  à partir des fichiers de configuration
+=== clients.conf ===
+contient la liste des NAS avec leur credential , donc la liste des "clients" radius qui ont le droit de communiquer avec le serveur .
+=== users ===
+<code>
+[root@radius raddb]# vim users
+sallestp Auth-Type:= EAP
+        Reply-Message = "t es bien une bonne machine",
+        Tunnel-Type := VLAN,
+        Tunnel-Medium-Type := IEEE-802,
+        Tunnel-Private-Group-Id = 15,
+        Fall-Through = No
+# default et check que NAS == Chillispot (patan), alors authZ de type ldap-chilli a suivre dans sites-enabled/default
+DEFAULT NAS-Identifier == "Chillispot", Autz-Type := ldap-chilli
+#On finis toujours ici, car "Fall-Through = Yes" (continue) ci-dessus
+#Affectation du Vlan poubelle 955 si aucune autre valeure (phase EAP)
+# ne viens l'ecraser, ce qui devrait etre le cas pour les auth positive
+DEFAULT
+        Tunnel-Type:1 = VLAN,
+        Tunnel-Medium-Type:1 = IEEE-802,
+        Tunnel-Private-Group-ID = 955,
+        Fall-Through = no
+</code>
 ==== Fichier principale ====
@@ Line 457: / Line 533: @@
+==== eap.conf ====
+<code>
+[root@radius raddb]# vim eap.conf
+ eap {
+                #  Invoke the default supported EAP type when
+                #  EAP-Identity response is received.
+...
+                #  If the EAP-Type attribute is set by another module,
+                #  then that EAP type takes precedence over the
+                #  default type configured here.
+                #
+                default_eap_type = peap
+..
+## EAP-TLS
+#  Note that you should NOT use a globally known CA here!
+                #  e.g. using a Verisign cert as a "known CA" means that
+                #  ANYONE who has a certificate signed by them can
+                #  authenticate via EAP-TLS!  This is likey not what you want.
+                tls {
+                        #
+                        #  These is used to simplify later configurations.
+                        #
+                        certdir = ${confdir}/certs
+                        cadir = ${confdir}/certs
+                        private_key_password = radius
+                        private_key_file = ${certdir}/radius_1347_pass.key
+ #  If CA_file (below) is not used, then the
+                        #  certificate_file below MUST include not
+                        #  only the server certificate, but ALSO all
+                        #  of the CA certificates used to sign the
+                        #  server certificate.
+                        #certificate_file = ${certdir}/cert-1347-radius.it-sudparis.eu.pem
+                        certificate_file = ${certdir}/radius-chain.pem
+                        #certificate_file = ${certdir}/chain-1347-radius.it-sudparis.eu.pem
+#  This parameter is used only for EAP-TLS,
+                        #  when you issue client certificates.  If you do
+                        #  not use client certificates, and you do not want
+                        #  to permit EAP-TLS authentication, then delete
+                        #  this configuration item.
+                        CA_file = ${cadir}/ca-bundle.crt
+#  If check_cert_cn is set, the value will
+                       #  be xlat'ed and checked against the CN
+                       #  in the client certificate.  If the values
+                       #  do not match, the certificate verification
+                       #  will fail rejecting the user.
+                       #
+                       #  This check is done only if the previous
+                       #  "check_cert_issuer" is not set, or if
+                       #  the check succeeds.
+                       #
+                        check_cert_cn = %{User-Name}
+ ttls {
+                        #  The tunneled EAP session needs a default
+                        #  EAP type which is separate from the one for
+                        #  the non-tunneled EAP module.  Inside of the
+                        #  TTLS tunnel, we recommend using EAP-MD5.
+                        default_eap_type = md5
+                        #  The tunneled authentication request does
+                        #  not usually contain useful attributes
+                        #  like 'Calling-Station-Id', etc.  These
+                        #  attributes are outside of the tunnel,
+                        #  and normally unavailable to the tunneled
+                        #  authentication request.
+                        #
+                        #  By setting this configuration entry to
+                        #  'yes', any attribute which NOT in the
+                        #  tunneled authentication request, but
+                        #  which IS available outside of the tunnel,
+                        #  is copied to the tunneled request.
+                        #
+                        # allowed values: {no, yes}
+                        copy_request_to_tunnel = yes
+#  The reply attributes sent to the NAS are
+                        #  usually based on the name of the user
+                        #  'outside' of the tunnel (usually
+                        #  'anonymous').  If you want to send the
+                        #  reply attributes based on the user name
+                        #  inside of the tunnel, then set this
+                        #  configuration entry to 'yes', and the reply
+                        #  to the NAS will be taken from the reply to
+                        #  the tunneled request.
+                        #
+                        # allowed values: {no, yes}
+                        use_tunneled_reply = yes
+  The inner tunneled request can be sent
+                        #  through a virtual server constructed
+                        #  specifically for this purpose.
+                        #
+                        #  If this entry is commented out, the inner
+                        #  tunneled request will be sent through
+                        #  the virtual server that processed the
+                        #  outer requests.
+                        #
+                        virtual_server = "inner-tunnel"
+                        #  The PEAP module needs the TLS module to be installed
+                #  and configured, in order to use the TLS tunnel
+                #  inside of the EAP packet.  You will still need to
+                #  configure the TLS module, even if you do not want
+                #  to deploy EAP-TLS in your network.  Users will not
+                #  be able to request EAP-TLS, as it requires them to
+                #  have a client certificate.  EAP-PEAP does not
+                #  require a client certificate.
+                peap {
+                        #  The tunneled EAP session needs a default
+                        #  EAP type which is separate from the one for
+                        #  the non-tunneled EAP module.  Inside of the
+                        #  PEAP tunnel, we recommend using MS-CHAPv2,
+                        #  as that is the default type supported by
+                        #  Windows clients.
+                        default_eap_type = mschapv2
+#  the PEAP module also has these configuration
+                        #  items, which are the same as for TTLS.
+                        copy_request_to_tunnel = yes
+                        use_tunneled_reply = yes
+#  The inner tunneled request can be sent
+                        #  through a virtual server constructed
+                        #  specifically for this purpose.
+                        #
+                        #  If this entry is commented out, the inner
+                        #  tunneled request will be sent through
+                        #  the virtual server that processed the
+                        #  outer requests.
+                        #
+                        virtual_server = "inner-tunnel"
+                }
+</code>
+==== inner-tunnel ====
+<code>
+[root@radius raddb]# vim sites-enabled/inner-tunnel
+</code>

docpublic/reseaux/services/radius.1299688470.txt.gz · Last modified: 2011/03/09 16:34 by PROCACCIA

Show page Old revisions

[unknown link type]Back to top