PEAP/MSCHAPv2 on a Samsung mobile - more than 50 EAP packets?
Hi, I'm seeing a strange behaviour for a 802.1X supplicant, and can't really explain it. The device (Samsung GT-S5560 mobile) claims to do PEAP/MSCHAPv2. In -X debug, the server certificate gets exchanged just fine, but the device doesn't proceed to the tunnel. It keeps sending EAP-Messages though - so it's not like the client device doesn't like the cert. In fact, we tried scenarios where it doesn't like the cert intentionally and in these cases it just aborts. So this here is when it *does* like the cert (ceritficate checking is off on the device). It sends packets like the following over and over again Wed Jan 20 10:24:34 2010 : Debug: Received Access-Request packet from host 158.64.X.Y port 1815, id=172, length=246 Wed Jan 20 10:24:34 2010 : Debug: User-Name = "someuser@somerealm.lu" Wed Jan 20 10:24:34 2010 : Debug: Calling-Station-Id = "C8-7E-75-F6-B1-7D" Wed Jan 20 10:24:34 2010 : Debug: Called-Station-Id = "00-1F-49-AA-EE-00:eduroam" Wed Jan 20 10:24:34 2010 : Debug: NAS-Port = 29 Wed Jan 20 10:24:34 2010 : Debug: NAS-IP-Address = 10.50.1.5 Wed Jan 20 10:24:34 2010 : Debug: NAS-Identifier = "ROC_WLC1" Wed Jan 20 10:24:34 2010 : Debug: Airespace-Wlan-Id = 3 Wed Jan 20 10:24:34 2010 : Debug: Service-Type = Framed-User Wed Jan 20 10:24:34 2010 : Debug: Framed-MTU = 1300 Wed Jan 20 10:24:34 2010 : Debug: NAS-Port-Type = Wireless-802.11 Wed Jan 20 10:24:34 2010 : Debug: Tunnel-Type:0 = VLAN Wed Jan 20 10:24:34 2010 : Debug: Tunnel-Medium-Type:0 = IEEE-802 Wed Jan 20 10:24:34 2010 : Debug: Tunnel-Private-Group-Id:0 = "\00036" Wed Jan 20 10:24:34 2010 : Debug: EAP-Message = 0x023200061900 Wed Jan 20 10:24:34 2010 : Debug: State = 0xe397bed9cca5a786162171ebc3153379 Wed Jan 20 10:24:34 2010 : Debug: Message-Authenticator = 0xd7a6608853e306106d5d8bca9d880cb1 Wed Jan 20 10:24:34 2010 : Debug: RESTENA-hotspot-Id = "somehotspot" Wed Jan 20 10:24:34 2010 : Debug: RESTENA-Service-Type = "eduroam-lu" Wed Jan 20 10:24:34 2010 : Debug: Proxy-State = 0x323336 ... Wed Jan 20 10:24:34 2010 : Debug: +- entering group authenticate {...} Wed Jan 20 10:24:34 2010 : Debug: [eap] Request found, released from the list Wed Jan 20 10:24:34 2010 : Debug: [eap] EAP/peap Wed Jan 20 10:24:34 2010 : Debug: [eap] processing type peap Wed Jan 20 10:24:34 2010 : Debug: [peap] processing EAP-TLS Wed Jan 20 10:24:34 2010 : Debug: [peap] Received TLS ACK Wed Jan 20 10:24:34 2010 : Debug: [peap] ACK handshake fragment handler in application data Wed Jan 20 10:24:34 2010 : Debug: [peap] eaptls_verify returned 1 Wed Jan 20 10:24:34 2010 : Debug: [peap] eaptls_process returned 13 Wed Jan 20 10:24:34 2010 : Debug: [peap] EAPTLS_HANDLED Wed Jan 20 10:24:34 2010 : Debug: ++[eap] returns handled Wed Jan 20 10:24:34 2010 : Debug: } # server split-outside Wed Jan 20 10:24:34 2010 : Debug: Sending Access-Challenge packet to host 158.64.1.8 port 1815, id=172, length=0 Wed Jan 20 10:24:34 2010 : Debug: EAP-Message = 0x013300061900 Wed Jan 20 10:24:34 2010 : Debug: Message-Authenticator = 0x00000000000000000000000000000000 Wed Jan 20 10:24:34 2010 : Debug: State = 0xe397bed9d3a4a786162171ebc3153379 Wed Jan 20 10:24:34 2010 : Debug: Proxy-State = 0x323336 Wed Jan 20 10:24:34 2010 : Debug: Finished request 4226376. That fragment handler seems strangely placed, and the EAP-Message is very short. It replies with the bytewise identical EAP-Message on the next round-trip. Up until the point where FreeRADIUS gives up: Wed Jan 20 10:24:34 2010 : Debug: Found Auth-Type = EAP Wed Jan 20 10:24:34 2010 : Debug: +- entering group authenticate {...} Wed Jan 20 10:24:34 2010 : Debug: [eap] More than 50 authentication packets for this EAP session. Aborted. Wed Jan 20 10:24:34 2010 : Debug: [eap] Either EAP-request timed out OR EAP-response to an unknown EAP-request Wed Jan 20 10:24:34 2010 : Debug: [eap] Failed in handler Wed Jan 20 10:24:34 2010 : Debug: ++[eap] returns invalid Wed Jan 20 10:24:34 2010 : Debug: Failed to authenticate the user. Wed Jan 20 10:24:34 2010 : Debug: } # server split-outside Wed Jan 20 10:24:34 2010 : Debug: Using Post-Auth-Type Reject I don't know what this device is talking here. Other PEAP clients don't do this kind of stuff. Anyone a clue what is going on? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
I'm seeing a strange behaviour for a 802.1X supplicant, and can't really explain it. The device (Samsung GT-S5560 mobile) claims to do PEAP/MSCHAPv2.
"Claims".
In -X debug, the server certificate gets exchanged just fine, but the device doesn't proceed to the tunnel. It keeps sending EAP-Messages though - so it's not like the client device doesn't like the cert. In fact, we tried scenarios where it doesn't like the cert intentionally and in these cases it just aborts. So this here is when it *does* like the cert (ceritficate checking is off on the device).
It sends packets like the following over and over again
I've seen this happen before when the client is expecting more data from the server. The server says "send me more data", and the client says "no, you send me more data".
That fragment handler seems strangely placed, and the EAP-Message is very short. It replies with the bytewise identical EAP-Message on the next round-trip.
My suggestion is that the phone is broken, and doesn't implement PEAP properly. This can happen when the supplicant *claims* to support one version of PEAP, and then expects data from a different version in the packets.
I don't know what this device is talking here. Other PEAP clients don't do this kind of stuff. Anyone a clue what is going on?
The client is broken. I say that a lot, don't I? :) Alan DeKok.
participants (2)
-
Alan DeKok -
Stefan Winter