Authentifizierung mit LEPS schlägt nach Update fehl

[Looping]

Hallo,

auf einem L-151E war LEPS schon unter 9.24.0433 eingerichtet und funktionierte einwandfrei. Nach dem Update auf 10.20Rel sollte jetzt LEPS-MAC konfiguriert sein. Mit den Clients kommt aber keine Verbindung mehr zustande. Im Syslog findet sich der Eintrag "Possibly wrong passphrase in key handshake with peer..."

Zurück auf 9.24 läuft die Authentifizierung wieder problemlos. Auf einem anderen Lancom-Router ohne LEPS-Konfiguration gab es nach dem Update keine Probleme; ebenfalls 9.24 -> 10.20.

Kann mir hier bitte jemand auf die Sprünge helfen? In der Konfiguration kann ich einfach keinen Fehler entdecken.

[alf29]

Moin,

was erzählt denn ein EAP-Trace während der Anmeldung? Irgendwo da müßte gemeldet werden, welche Passphrase benutzt wird.

Viele Grüße

Alfred

[Looping]

Hallo Alfred,

danke für Deine Rückmeldung. Die richtige Passphrase hat er schon mal genommen. Nur was er mit "MIC failure" meint, sagt mir nicht wirklich etwas; ich hoffe Dir dafür um so mehr.

Viele Grüße, Markus

Code: Alles auswählen

[EAP] 2018/10/03 13:42:50,279  Devicetime: 2018/10/03 13:42:52,202
Passphrase used for WPA/PSK-based key handshake with peer 1c232cxxxxxx on SSID [MeineSSID] is [Die richtige Passphrase]

[EAP] 2018/10/03 13:42:50,279  Devicetime: 2018/10/03 13:42:52,202
***Creating WPA(2)/802.11i key handshake context with supplicant 1c:23:2c:xx:xx:xx (Samsung xx:xx:xx)
-->PMK not yet available, postpone negotiation

[EAP] 2018/10/03 13:42:50,279  Devicetime: 2018/10/03 13:42:52,203
***PMK became available for negotiation with 1c:23:2c:xx:xx:xx (Samsung xx:xx:xx)
-->PMK to be used is:
00: 1f
-->Switching to pairwise key handshake phase 1, send corresponding packet
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 95
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 3 Pairwise Key-Index 0 ACK
Key Length          : 16
Replay Counter      : 0000000000000001
Nonce               : d2 95 7c 18 1d 60 0b 8f ..|..`..
                      85 2e 39 f8 e6 a8 9d 2b ..9....+
                      38 fa 79 75 20 5f 68 f2 8.yu _h.
                      1d 49 90 9e 1b 7c e2 35 .I...|.5
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 00 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key Data Length     : 0

[EAP] 2018/10/03 13:42:50,279  Devicetime: 2018/10/03 13:42:52,213
***Received EAP packet on WLAN-1-2 from 1c:23:2c:xx:xx:xx (Samsung xx:xx:xx):
-->EAPOL Header
Protocol Version    : 1
Packet Type         : Key
Packet Length       : 123
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 3 Pairwise Key-Index 0 MIC
Key Length          : 0
Replay Counter      : 0000000000000001
Nonce               : b8 4b a3 ae aa 5f 9c 01 .K..._..
                      a8 de ad fb a8 15 4b d4 ......K.
                      5c f6 6c 95 30 03 c2 9f \.l.0...
                      26 04 ba e3 38 0a f4 ac &...8...
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 00 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : ec 2a 48 67 10 4b f5 f7 .*Hg.K..
                      ab 90 1c 54 d1 ab f3 b5 ...T....
Key Data Length     : 28
Key Data            :
<<<
RSN Cipher Info     : Version 1
                      Group Cipher TGI-CSE-CCMP128
                      Pairwise Ciphers TGI-CSE-CCMP128
                      Authentication Selectors TGI-AUTHSE-PSK-SHA256
                      Capabilities: Mgmt-Frame-Prot-Supp 16 PTKSA replay counters 16 GTKSA replay counters
                      Group Mgmt Cipher TGI-CSE-BIPCMAC128
>>>
-->Received properly sequenced packet from supplicant for phase 2
-->Computing PTK
  -->PRF-X Data:
00: 02 a0 57 22 52 5e 1c 23 - 2c 56 11 7d b8 4b a3 ae
10: aa 5f 9c 01 a8 de ad fb - a8 15 4b d4 5c f6 6c 95
20: 30 03 c2 9f 26 04 ba e3 - 38 0a f4 ac d2 95 7c 18
30: 1d 60 0b 8f 85 2e 39 f8 - e6 a8 9d 2b 38 fa 79 75
40: 20 5f 68 f2 1d 49 90 9e - 1b 7c e2 35
  -->Resulting PTK:
00: bc c8 aa d2 c6 41 a6 eb - 6d be 7f 02 20 36 78 99
10: e9 9c 39 47 21 cc 05 c8 - 22 13 5c fc c4 af 0a 15
20: 3b 36 04 d6 40 e4 c0 bd - 14 ef 82 ee 68 a9 e5 2d
  -->KCK:
00: bc c8 aa d2 c6 41 a6 eb - 6d be 7f 02 20 36 78 99
  -->KEK:
00: e9 9c 39 47 21 cc 05 c8 - 22 13 5c fc c4 af 0a 15
  -->TK:
00: 3b 36 04 d6 40 e4 c0 bd - 14 ef 82 ee 68 a9 e5 2d
-->MIC failure, discarding

[EAP] 2018/10/03 13:42:50,576  Devicetime: 2018/10/03 13:42:52,506
***Authenticator timeout occured for negotiation with 1c:23:2c:xx:xx:xx (Samsung xx:xx:xx) in phase 1
-->Retrying, this time with 51 ms timeout...
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 95
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 3 Pairwise Key-Index 0 ACK
Key Length          : 16
Replay Counter      : 0000000000000002
Nonce               : d2 95 7c 18 1d 60 0b 8f ..|..`..
                      85 2e 39 f8 e6 a8 9d 2b ..9....+
                      38 fa 79 75 20 5f 68 f2 8.yu _h.
                      1d 49 90 9e 1b 7c e2 35 .I...|.5
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 00 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key Data Length     : 0

...
...
...

[EAP] 2018/10/03 13:42:52,604  Devicetime: 2018/10/03 13:42:54,550
***Authenticator timeout occured for negotiation with 1c:23:2c:56:11:7d (Samsung 56:11:7d) in phase 1
-->Maximum number of retries reached
-->Terminating handshake and deauthenticating client, better luck next time
   (please check for passphrase mismatch)

[alf29]

Moin,

"MIC failure" ist im Prinzip das, was auf Lowlevel-Ebene passiert, wenn beide Seiten nicht die gleiche Passphrase benutzen. Bekommt der AP bei allen Antworten vonm Client so einen MIC-Fehler, dann schreibt er die von Dir gesehene Meldung ins Syslog, daß wohl die Passphrase verkehrt ist.

Interessant ist aber das hier:

[EAP] 2018/10/03 13:42:50,279 Devicetime: 2018/10/03 13:42:52,203
***PMK became available for negotiation with 1c:23:2c:xx:xx:xx (Samsung xx:xx:xx)
-->PMK to be used is:
00: 1f

Das PMK sollte eigentlich 32 und nicht 1 Byte lang sein. Da werde ich wohl morgen mal suchen, wo in der 10.20 bool und int durcheinander geraten sind

Viele Grüße

Alfred

[alf29]

Moin,

ich habe eben bestimmt eine Stunde versucht, Dein Problem nachzustellen, und es ist mir nicht gelungen. Weder bekomme ich das auf ein Byte abgeschnittene PMK im Trace (hast Du da vielleicht am Trace herumeditiert?), noch scheitert bei mir die Anmeldung. Ich habe das sowohl mit einem LANCOM als Client als auch mit einem WPAsupplicant probiert, der üblicherweise in Android-Handys zum Einsatz kommt. Dein Samsung-Client ist doch vermutlich irgendetwas Android-basiertes?

Tut mir leid, aber wenn ich das Problem weiter untersuchen soll, brauche ich die vollständige Geräte-Konfig und Angaben zum Client.

Viele Grüße

Alfred

[Looping]

Hallo Alfred,

am Trace habe ich an der Stelle ganz sicher nicht editiert. Das Problem habe ich auch nochmal mit einem Microsoft-Client nachgestellt. Auch dort ist im Trace nur ein Byte zu sehen. Der Samsung-Client ist ein Android-Tablett, aber da es auch mit dem Microsoft-Client happert, wird es wohl nichts Android-spezifisches sein.

Die Konfiguration habe ich vor und nach dem Update gesichert. Beide Konfigurationen schicke ich Dir als Script-Dateien per PM. Ebenso weitere Informationen zu Samsung-Client.

Viele Grüße und vielen Dank,

Markus

[hacowi]

Ich habe hier das gleiche Problem. Bei mir sieht das so aus:

<code>
[EAP] 2018/10/05 10:10:44,101 Devicetime: 2018/10/05 10:10:54,972
***PMK became available for negotiation with dc:4f:22:11:45:8a
-->PMK to be used is:
00: 13
-->Switching to pairwise key handshake phase 1, send corresponding packet
-->EAPOL Header
Protocol Version : 2
Packet Type : Key
Packet Length : 95
Key Type : 2
-->802.11i RSN Key Descriptor
Key Information : Version 2 Pairwise Key-Index 0 ACK
Key Length : 16
Replay Counter : 0000000000000001
Nonce : 88 61 3b 35 8e 8b 7b b8 .a;5..{.
f5 30 d6 fe 53 21 ac 2d .0..S!.-
24 a7 1c cf bc e9 5f 15 $....._.
dc 34 18 68 53 9b 25 b3 .4.hS.%.
Key IV : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key RSC : 00 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key Data Length : 0</code>

[KarlKlammer]

Hallo zusammen,

bei mir sieht es nach Update von 10.12RU9 auf 10.20Rel mit zwei Geräten und APs genau so aus. Ich klinke mich hier mal mit ein.

1. ein Sony Xperia XZ will sich zum L-452agn verbinden

Code: Alles auswählen

[EAP] 2018/10/05 10:04:02,232  Devicetime: 2018/10/05 10:04:06,738
***PMK became available for negotiation with 84:c7:ea:31:9a:7d (Sony-Mobile 31:9a:7d)
-->PMK to be used is:
00: b7
-->Switching to pairwise key handshake phase 1, send corresponding packet

2. ein Logitech Harmony Hub will sich zum LN-830acn verbinden

Code: Alles auswählen

[EAP] 2018/10/05 10:31:04,476  Devicetime: 2018/10/05 10:31:05,049
***PMK became available for negotiation with 00:04:20:f5:9d:9b (Slim-Devices f5:9d:9b)
-->PMK to be used is:
00: 5b
-->Switching to pairwise key handshake phase 1, send corresponding packet

[alf29]

Moin,

ich denke, das Problem ist gefunden und gelöst.

Viele Grüße

Alfred

[Jirka]

Hallo Alfred,

hört sich gut an. Scheinen ja jetzt schon 3 Leute gewesen zu sein mit dem gleichen Problem. Was hättest Du beim Nachstellen anders machen müssen, damit das Problem auch bei Dir zum Tragen gekommen wäre?
Mich wundert, dass LEPS noch so viel genutzt wird, ich bin hier eher am Abschaffen, weil dieses ständige Smartphone-Gewechsel den Administrationsaufwand so hoch getrieben hat.

Viele Grüße,
Jirka

[alf29]

N'Abend,

hört sich gut an. Scheinen ja jetzt schon 3 Leute gewesen zu sein mit dem gleichen Problem. Was hättest Du beim Nachstellen anders machen müssen, damit das Problem auch bei Dir zum Tragen gekommen wäre?

Müßte ich jetzt noch einmal nachschauen, was bei mir anders war. Ich meine, ich hatte die Spalte für die SSID in der Regeltabelle frei gelassen, da verhält sich das Modul bezüglich der Vorberechnung der PMKs anders.

Mich wundert, dass LEPS noch so viel genutzt wird, ich bin hier eher am Abschaffen, weil dieses ständige Smartphone-Gewechsel den Administrationsaufwand so hoch getrieben hat.

Google, Apple & Co. randomisieren ja schon bei den Probe Requests die MAC-Adressen. Wie man so hört, werden sie das demnächst auch bei der eigentlichen Verbindung machen. Will heißen, das Handy denkt sich für jede SSID eine eigene, zufällige MAC aus. Die hält es zwas so lange konstant, wie man das Profil nicht löscht und neu anlegt, aber rein an der MAC-Adresse irgendwas festzumachen wird in Zukunft schwieriger werden.

Es gibt halt Features, die hatten vor 15 Jahren mal mehr Bedeutung als heute (mache ich den Krempel wirklich schon so lange?).

Ehrlich gesagt: bei WPA1 habe ich auch etwas in der 10.20 verbaselt und es hat keiner in der Freigabe/Betatest gemerkt. Ist aber auch irgendwo gut, daß dieser alte Kram kaum noch benutzt wird.

Viele Grüße

Alfred

[hacowi]

Also ich nutze LEPS noch recht häufig.
Wobei mit LEPS-U der Administrationsaufwand etwas gesenkt wird. Allerdings kann dann wieder jeder machen was er will. Wenn man LEPS-U auf eine definierte Anzahl Clients begrenzen könnte, wäre es perfekt. Somit kann ein Mitarbeiter nur seine Notebook und sein Diensthandy anmelden. Wenn ein Gerät wechselt, muss man es erst abmelden b.z.w dem Admin Bescheid geben um es aus der Liste zu entfenen. Ich muss dann aber nicht erst die MAC-Adresse vom neuen Gerät ermitteln.... (Featurewunsch)

Ach ja, ich hatte gestern mit dem Support den Fehler im LEPS am Wickel. Da ist scheinbar doch ein kleiner Fehler in der Firmware. Es wird bald eine Neue geben...

Gruß
Jens

[Jirka]

Hallo,

Google, Apple & Co. randomisieren ja schon bei den Probe Requests die MAC-Adressen. Wie man so hört, werden sie das demnächst auch bei der eigentlichen Verbindung machen. Will heißen, das Handy denkt sich für jede SSID eine eigene, zufällige MAC aus. Die hält es zwar so lange konstant, wie man das Profil nicht löscht und neu anlegt, aber rein an der MAC-Adresse irgendwas festzumachen wird in Zukunft schwieriger werden.

na toll, das kann ja heiter werden. In manchen Fällen nehme ich die MAC-Adresse eines solchen Gerätes und kopiere sie an andere Standorte oder nutze sie dort für Firewall-Regeln...

Ach ja, ich hatte gestern mit dem Support den Fehler im LEPS am Wickel. Da ist scheinbar doch ein kleiner Fehler in der Firmware. Es wird bald eine Neue geben...

Hat Alfred das nicht geschrieben?!

Viele Grüße,
Jirka