Cached PMK und WPA2 Enterprise

[stefan.winter]

Hallo,

seit ich LCOS 6.10 installiert habe, gibt es wohl ein neues Feature in der WPA2 Implementierung: überspringen der 802.1X Authentifizierung beim roaming zwischen APs.
Das scheint aber nicht so 100%ig zu funktionieren: ein Client (Centrino2) wollte sich authentifizieren, der AP erkannte aber dass er schon einen cached PMK hat und wollte ihn eben *nicht* mehr authentifizieren.

Also das AP syslog sagt:
WLAN station 00:13:ce:xx:yy:zz (Intel-Corporate xx:yy:zz) [] has cached PMK, skip 802.1x

während auf dem Client immer nur stand, dass er sich zu authentifizieren versucht (Intel PROset/Wireless).

Jetzt weiß ich nicht, ob der AP da was falsch macht oder der Client es einfach nicht rafft. Hat da jemand ein paar Fakten zu? Immerhin sind Centrino2 Chipsets relativ häufig...

Grüße,

Stefan Winter

[alf29]

Moin,

da scheint der Client durcheinander zu sein. Das LANCOM
nutzt eventuell gecachte PMKs nur dann, wenn der Client das
anfordert, indem er im Association Request eine zu diesem
PMK passende PMKID anbietet. Das hat der Client in
diesem Fall offensichtlich getan, und dann muß er auch
damit rechnen, daß der AP auf das Angebot eingeht...

Wir haben dieses Feature hier sowohl mit AirLancer-
als auch mit Centrino-Clients getestet.

Gruß Alfred

[stefan.winter]

Hallo,

also leider ist so, dass das Problem mit 6.0x nie aufgetreten ist, seit meinem Upgrade auf 6.10 aber immer mal wieder auftaucht. Da der Client nichts geändert hat, bin ich mir relativ sicher, dass da AP-seitig was nicht mehr so ist wie früher.
Wie auch immer: kann man das Feature zum Skippen der Auth auch abschalten? Ich hab das Häkchen unter
WLAN-Sicherheit, Mobile Stationen können zwischen den Basisstationen im lokalen Netz wechseln (Roaming)" weggemacht, weil ich dachte damit wird die Fast Re-Auth deaktiviert. Das Problem ist aber heute (danach) nochmal aufgetreten.
Sowieso: was tut denn der AP, wenn er 802.1x skippt? Schickt er dann einfach ein EAPoL-Success? Übrigens: der Client benutzt EAP-TTLS, falls das was hilft.

Stefan

[alf29]

Moin,

also leider ist so, dass das Problem mit 6.0x nie aufgetreten ist, seit meinem Upgrade auf 6.10 aber immer mal wieder auftaucht.

Die 6.0x hat auch weder PMK-Caching noch Pre-Authentication unterstützt - deshalb
konnte das nicht passieren...

Da der Client nichts geändert hat, bin ich mir relativ sicher, dass da AP-seitig was nicht mehr so ist wie früher.

Wie gesagt, die 6.0x hat das Feature gar nicht unterstützt.

Wie auch immer: kann man das Feature zum Skippen der Auth auch abschalten? Ich hab das Häkchen unter
WLAN-Sicherheit, Mobile Stationen können zwischen den Basisstationen im lokalen Netz wechseln (Roaming)" weggemacht, weil ich dachte damit wird die Fast Re-Auth deaktiviert.

Dieser Schalter schaltet nur das IAPP-Protokoll für den Handover der MAC-Adresse ab.
Das PMK-Caching ist nicht zu deaktivieren, weil das bei unseren Versuchen mit keinem
Client Probleme gemacht hat (entweder hat der Client es gar nicht unterstützt oder es
hat einfach funktioniert). Einen weiteren Schalter, mit dem nur rumgespielt wird und der
nur Supportaufwand erzeugt, habe ich deswegen nicht für notwendig erachtet.

Das Problem ist aber heute (danach) nochmal aufgetreten.

Hilfreich wäre ein (EAP-)Trace davon. Ich weiß, das ist schwierig zu fassen, wenn es
nur ein paar Mal in der Woche auftritt, aber anders sehe ich da keine Chance, etwas
herauszufinden.

Sowieso: was tut denn der AP, wenn er 802.1x skippt? Schickt er dann einfach ein EAPoL-Success? Übrigens: der Client benutzt EAP-TTLS, falls das was hilft.

Der AP überspringt die 802.1x-Phase komplett und schickt direkt Paket 1 des Pairwise Key
Handshake. Dieses enthält im KeyData-Feld eine der PMKIDs, die der Client im
Association Request angeboten hat. Wenn der AP PMK-Caching nicht unterstützt
(wie mit der 6.0x) oder alle vom Client angebotenen PMKs bereits abgelaufen sind, dann
fängt der AP ganz 'normal' mit dem Identity Request von 802.1x an.

Versucht der Client übrigens auch Pre-Authentication?

Gruß Alfred

[stefan.winter]

Hallo,

Ja, Pre-auth beim roaming zwischen APs. Das Problem tritt aber auch auf, wenn gar nicht geroamt wird: re-auth ist eingeschaltet und war auf die standardmäßigen 3600 Sekunden gesetzt. Ergebnis: nach ein paar re-auths tauchte das Problem auf.

Ich habe jetzt mal das re-auth Intervall auf 60 Sekunden gesetzt um die Symptome hoffentlich schneller zu provozieren.

Vielleicht hilft ja auch schon die Info dass es nur beim re-auth einer aktiven Verbindung auftritt?

Stefan

[alf29]

Moin,

Vielleicht hilft ja auch schon die Info dass es nur beim re-auth einer aktiven Verbindung auftritt?

Wie gesagt, ich bräuchte einen EAP-Trace. Reauthentifizierung im 802.1x sollte
eigentlich nur dazu führen, daß auf 802.1x-Ebene etwas neu anläuft - dafür bedürfte
es aber keiner neuen Assoziation, in der der Client eine solche PMKID übermitteln
könnte. Was taucht denn im Log auf, wenn eine Reauthentifizierung klappt?

Übermittelt der RADIUS-Server in seinem Accept irgendeinen Session Timeout, aus dem
sich die Gültigkeit der PMKSA ableiten ließe?

Gruß Alfred

[stefan.winter]

Wie gesagt, ich bräuchte einen EAP-Trace. Reauthentifizierung im 802.1x sollteeigentlich nur dazu führen, daß auf 802.1x-Ebene etwas neu anläuft - dafür bedürfte es aber keiner neuen Assoziation, in der der Client eine solche PMKID übermitteln könnte. Was taucht denn im Log auf, wenn eine Reauthentifizierung klappt?

auf dem AP mit trace + EAP ?

Übermittelt der RADIUS-Server in seinem Accept irgendeinen Session Timeout, aus dem sich die Gültigkeit der PMKSA ableiten ließe?

Nein, kein Session-Timeout. Ich bin jetzt wieder auf FW 6.0 zurück, dann lief wieder alles einwandfrei.

Jetzt ist ja 6.12 rausgekommen. Gab es da Änderungen am PMK Caching gegenüber 6.10, also: lohnt es sich, 6.12 auszuprobieren?

Grüße,

Stefan

[alf29]

Moin

auf dem AP mit trace + EAP ?

Am besten ein trace + wlan eap, damit mian auch die
(Re)assoziation vom Client sieht.

Jetzt ist ja 6.12 rausgekommen. Gab es da Änderungen am PMK Caching gegenüber 6.10, also: lohnt es sich, 6.12 auszuprobieren?

Nein, an der Stelle hat sich nichts geändert.

Gruß Alfred

[alf29]

Hi,

ich habe gerade mal bei unserem 1x-Aufbau nachgeschaut,
wie das mit der Reauthentication nach einer Stunde aussieht -
da bucht sich der Client aber gar nicht neu ein. Für eine
Reauthentifizierung im 802.1x ist das auch gar nicht nötig...

Gruß Alfred

[alf29]

Moin,

bei näherer Untersuchung hat sich noch das Problem
gefunden, daß nach einer 1x-Reauthentifizierung kein neuer
Key-Handshake angestoßen wurde. Das war aber auch
schon bei der 6.0x so...

Gruß Alfred

[stefan.winter]

Hallo,

mit der 6.14 wurde das Problem auch nicht besser. Ich hab jetzt einen trace vom AP, da scheint man draus zu sehen dass der AP EAPoL Version 2 spricht, der Client mit EAPoL Version 1 antwortet und in der Folge angeblich ein falscher MIC dazu führt, dass der Vorgang abgebrochen wird.

Den trace würde ich lieber nicht ins Forum posten, alf29, kann ich vielleicht ne Mailadresse kriegen wo ich das per PM hinschicken kann?

Stefan