802.1x EAP-TTLS met FreeRadius, SecureW2 en Linksys WAP54G

[Verwijderd]

Ik ben al een aantal dagen aan het proberen om mijn wlan beter te beveiligen door middel van 802.1x. Wat ik nu aan het doen ben is niet noodzakelijk voor mij thuis, maar ik wil het als een proeftuin gebruiken voor wat er mogelijk is op grotere schaal. Helaas zijn de features van FreeRadius die hiervoor nodig zijn nog experimenteel, en is er erg weinig informatie over het opzetten van radius authenticatie met het accesspoint te vinden. De installatie verloopt dan ook niet probleemloos.

Mijn opstelling:

server: linux 2.6.0, freeradius, snapshot van 26-12-2003, openssl 0.9.7 (uit debian sid package) - 10.0.0.2
accesspoint: Linksys WAP54G, firmware 1.08 - 10.0.0.254
client: Windows XP, WPA update, Alfa&Ariss SecureW2 1.0.8, DHCP

Configuratie:

In de testopstelling is WPA nog uitgeschakeld, zodat ik eerst de 802.1x aanmelding apart kan testen. De client moet zich via een anonieme outer authentication en een PAP inner authentication (in de tunnel, EAP-TTLS-PAP dus) aanmelden. In onderstaand overzicht staan alle relevante configuratiebestanden en instellingen.

radius server:
http://www.luite.com/radius/clients.conf
http://www.luite.com/radius/proxy.conf
http://www.luite.com/radius/radiusd.conf
http://www.luite.com/radius/users

accesspoint:


client:


Probleem:
De aanmelding van de client werkt niet goed:

server-log: http://www.luite.com/radius/radius-tlsfailed.log
ethereal-capture op de client: http://www.luite.com/radius/ethereal-client.txt
(zelfde bestand in binaire, in ethereal leesbare vorm: http://www.luite.com/radius/ethereal-client.bin )

Zoals te zien in de server-log, krijgt de TTLS layer in de server steeds status 13 terug van de TLS layer. Deze status is EAPTLS_HANDLED, wat betekent dat het huidige packet volledig door de TLS layer in de server is afgehandeld. De tunnel wordt dus niet opgezet, en de authenticatie is misschien ergens in de TLS handshake vastgelopen.

(broncode in /src/modules/rlm_eap/types/rlm_eap_tls/ en /src/modules/rlm_eap/types/rlm_eap_ttls/ in het archief van FreeRadius)

Ik zocht eerst het probleem bij de OpenSSL error in de server-log. Deze foutmelding blijkt echter ook te zitten in de log van een succesvolle aanmelding in de FreeRadius + EAP-TLS howto op http://www.freeradius.org/doc/EAPTLS.pdf .

[edit: aanvulling]
De certificaten van de server komen wel goed aan op de client. Ik heb de certificaten geaccepteerd en geinstalleerd.
[/edit]

Helaas kan ik weinig gegevens krijgen uit het Linksys accesspoint, en is de nas binary (die de radius authenticatie verzorgt) alleen verkrijgbaar in binaire vorm, broncode is niet aanwezig in de GPL download van Linksys.

Weet iemand wat hier misgaat? Moet ik de fouten bij de radius server zoeken (de client werkt met SecureW2 en hetzelde soort aanmelding wel goed op het utwente wlan), of zou het accesspoint roet in het eten gooien?

[ Voor 7% gewijzigd door Verwijderd op 28-12-2003 23:13 ]

[Maarten @klet.st]

Heb je al met andere 802.1x methoden ge-experimenteerd? Ik moest ff zoeken naar wat EAP-TTLS precies inhoudt, maar als ik in dit artikel lees, begrijp ik dat het een door Funk (steel-belt) ontwikkelde methode is. Wellicht is deze een beetje vendor specific.

Zelf heb ik de boel draaiend gekregen met PEAP. EAP-TLS (dus niet EAP-TTLS) is imho een alternatief. LEAP is vulnerable (dictionary attack), dus die valt af. Logischerwijs zou PEAP ook vulnerable kunnen zijn voor een dictionary attack, maar misschien hanteer ik daarbij de verkeerde logica
PEAP staat niet in het bovengenoemde artikel, maar voor zover ik begrepen heb is het redelijk veilig (dictionary attack moet ik dus nog naar kijken), zolang je er voor zorgt dat het certificaat (dat op de Radius server gebruikt wordt) maar 'vertrouwd' is, anders zou iemand de netwerkkant kunnen spoofen.

Mijn proof-of-concept implementatie maakt gebruik van Cisco ACS, ik weet dus niet of FreeRadius ook PEAP ondersteunt, maar als alternatief schijnt Cisco ook een gratis Radius server te hebben. Voordeel dat ik in de PEAP authenticatie zie is dat alleen aan de serverzijde een certificaat nodig is en dat er aan de client kant geen speciale software nodig is. Doordat ik Cisco ACS gebruik zouden de gebruikers in theorie met een Windows domeinlogin moeten kunnen authenticeren, maar daar moet ik nog naar kijken, dat werkte niet 1-2-3.

Na enig/behoorlijk prutsen aan de clientside werkt het met de Microsoft WPA/802.1x update. Daarbij moet je diep in de opties, vooral als de username/pass verschillende zijn van die waarmee je ingelogd bent, maar het werkt Als je het op 1 machine aan de praat hebt is de volgende een fluitje van een cent, ik gok dat er wel uitbreidingen voor de AD zijn om dit met een policy op clients te distribueren als je in een Windows 200x domein werkt.

Uiteraard heb ik ook 'even' gekeken of de WEP sleutels inderdaad dynamisch zijn (die zouden dynamisch gegenereerd moeten worden). Dat is wat lastig testen zonder debugsoftware enzo, maar een paar uur airsnort gaf GEEN (?) weak keys. En nee, ik gebruik geen speciale drivers die weak keys omzeilen (zoals 3com die heeft).

Anyway, laat ff in deze thread weten hoe het je vergaat, ben benieuwd. Eventueel kan je natuurlijk ook mailen, als dit topic verder weinig reacties van anderen oplevert.

[ Voor 13% gewijzigd door Maarten @klet.st op 29-12-2003 20:37 . Reden: vooral typo's ]

[Maarten @klet.st]

Verwijderd schreef op 28 december 2003 @ 22:12:
server-log: http://www.luite.com/radius/radius-tlsfailed.log

Ik heb nog even gekeken, ik kom een paar keer het volgende tegen:

code:

  modcall[authorize]: module "preprocess" returns ok for request 5
  modcall[authorize]: module "chap" returns noop for request 5
  modcall[authorize]: module "mschap" returns noop for request 5
    rlm_realm: No '@' in User-Name = "anonymous", looking up realm NULL
    rlm_realm: No such realm "NULL"
  modcall[authorize]: module "suffix" returns noop for request 5
  rlm_eap: EAP packet type response id 5 length 5
  rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
  modcall[authorize]: module "eap" returns updated for request 5
  modcall[authorize]: module "files" returns notfound for request 5

Ik weet niet precies wat alle modules doen, maar er zijn wel twee opmerkelijkheden:

1. CHAP geeft een error en lijkt aan te geven dat er geen correcte login credentials gestuurd zijn
2. Je geeft aan PAP te gebruiken, maar ik zie nergens een module voor PAP geladen worden?

Als je inderdaad PAP wilt gebruiken is het logisch dat CHAP de inhoud van de verzoeken niet snapt, maar dan mis je misschien een module in FreeRadius? (nogmaals, ik ken FreeRadius verder niet).

[ Voor 6% gewijzigd door Maarten @klet.st op 29-12-2003 20:49 . Reden: code netjes in blok ]

[Verwijderd]

Maarten.O schreef op 29 december 2003 @ 20:33:
Heb je al met andere 802.1x methoden ge-experimenteerd? Ik moest ff zoeken naar wat EAP-TTLS precies inhoudt, maar als ik in dit artikel lees, begrijp ik dat het een door Funk (steel-belt) ontwikkelde methode is. Wellicht is deze een beetje vendor specific.

Het is niet vendor-specifiek. Het is een lichte uitbreiding op TLS, die het mogelijk maakt om binnen TLS met een ander (tunneled) protocol authenticatie te verrichten. In dit geval is dat dus het Password Authentication Protocol, kortweg PAP. Momenteel is het protocol in versie draft-3, de specificaties zijn verder volledig open. De client die ik gebruik is dan ook van een heel ander bedrijf, en ook open1x ondersteunt EAP-TTLS.

Zelf heb ik de boel draaiend gekregen met PEAP. EAP-TLS (dus niet EAP-TTLS) is imho een alternatief. LEAP is vulnerable (dictionary attack), dus die valt af. Logischerwijs zou PEAP ook vulnerable kunnen zijn voor een dictionary attack, maar misschien hanteer ik daarbij de verkeerde logica

TLS is niet geschikt omdat ik niet met certificaten wil authenticeren, met TTLS heb je de voordelen van TLS, met daarbij de keuze van een geschikte "inner" authenticatie methode.

Maar mijn vraag ging over EAP-TTLS, dat wil ik gebruiken, en daar blijf ik ook bij, totdat ik zeker weet dat het onmogelijk is vanwege het accesspoint, of totdat het gelukt is.

Ik weet niet precies wat alle modules doen, maar er zijn wel twee opmerkelijkheden:

1. CHAP geeft een error en lijkt aan te geven dat er geen correcte login credentials gestuurd zijn
2. Je geeft aan PAP te gebruiken, maar ik zie nergens een module voor PAP geladen worden?

PAP wordt zeker geladen, zie ook radiusd.conf, PAP gebruikt in mijn config nu nog het encryption scheme crypt (wat wel in een later stadium nog problemen kan geven met de authenticatie, aangezien die nu op SYSTEM staat (check aan de hand van systeemaccounts, /etc/passwd en /etc/shadow dus), en ik md5 passwords gebruik). Maar dit probleem komt pas veel later aan de orde, als de TLS tunnel opgebouwd is en de inner authenticatie plaatsvindt.

Ik weet niet waarom dit request niet door PAP afgehandeld wordt (en dan een noop terugkrijgt), maar het maakt ook niets uit, de PAP authenticatie komt pas binnen de tunnel. In eerste instantie zou de EAP handler het pakket moeten afhandelen, en een subhandler voor het onderliggende protocol (TTLS) moeten gebruiken voor de daadwerkelijke afhandeling. Pas binnen de TTLS handler zou er gebruik gemaakt moeten worden van de PAP module.

Ik denk dat die noops betekenen dat de module het packet niet herkend als "voor hem bestemd", en dat er daardoor doorgegaan wordt met de volgende module. In de PDF tutorial voor het opzetten van TLS komen er ook noops voor, weliswaar voor andere modules.