(PEAP) problem introduced in wpa_supplicant 0.5.1

[Jouni Malinen]

On Mon, Feb 20, 2006 at 05:11:15PM +0100, Charles Bovy wrote:

> After an upgrade to wpa_supplicant 0.5.1, a problem occurs. Phase 2 of the 
> EAP-PEAP doesn't success anymore. I read that some of the EAP functions has 
> changed in the new version 0.5.1.

The main change was in adding support for EAP expanded types which
changes some of the core code to handle more complex EAP type
specification.

> wpa_supplicant 0.5.0:

> 1140175926.746735: EAP-PEAP: Decrypted Phase 2 EAP - hexdump(len=5): 01 ee 00 
> 05 06
> 1140175926.746741: EAP-PEAP: received Phase 2: code=1 identifier=238 length=5
> 1140175926.746746: EAP-PEAP: Phase 2 Request: type=6
> 1140175926.746750: EAP-PEAP: Phase 2 Request: Nak type=6
> 1140175926.746754: EAP-PEAP: Allowed Phase2 EAP types - hexdump(len=1): 1a
> 1140175926.746758: EAP-PEAP: Encrypting Phase 2 data - hexdump(len=6): 
> [REMOVED]

> 1140175926.754631: EAP: Received EAP-Request method=25 id=239
> 1140175926.754635: EAP: EAP entering state METHOD
> 1140175926.754640: SSL: Received packet(len=75) - Flags 0x01
> 1140175926.754644: EAP-PEAP: received 69 bytes encrypted data for Phase 2
> 1140175926.754662: EAP-PEAP: Decrypted Phase 2 EAP - hexdump(len=39): 01 ef 00 
> 27 1a 01 ef 00 22 10 7e d3 69 9b 4c 46 5c cb ea 04 d8 b3 a6 55 39 e1 4e 4c 4d 
> 54 52 2d 57 49 41 53 30 34 38
> 1140175926.754677: EAP-PEAP: received Phase 2: code=1 identifier=239 length=39
> 1140175926.754681: EAP-PEAP: Phase 2 Request: type=26

> wpa_supplicant 0.5.1:

> 1140175889.075199: EAP-PEAP: Decrypted Phase 2 EAP - hexdump(len=5): 01 eb 00 
> 05 06
> 1140175889.075205: EAP-PEAP: received Phase 2: code=1 identifier=235 length=5
> 1140175889.075209: EAP-PEAP: Phase 2 Request: type=6
> 1140175889.075213: EAP-PEAP: Phase 2 Request: Nak type=6
> 1140175889.075217: EAP-PEAP: Allowed Phase2 EAP types - hexdump(len=8): 00 00 
> 00 00 1a 00 00 00
> 1140175889.075224: EAP-PEAP: Encrypting Phase 2 data - hexdump(len=6): 
> [REMOVED]

This here should be same as the value send with 0.5.0. The debug log
here does not include this, so I cannot verify it based on this. Could
you please run both versions with -K added to the command line to
include all potentially private information in the log and make sure
that this Phase 2 Nak is indeed identival. The EAP identifier, i.e., the
second byte, can change, but other bytes should be the same for both
versions. You will probably not want to post those debug logs, but
sending these line should be fine, if there is difference in the
contents.

> 1140175889.089900: EAPOL: Received EAP-Packet frame
> 1140175889.089904: EAPOL: SUPP_BE entering state REQUEST
> 1140175889.089908: EAPOL: getSuppRsp
> 1140175889.089912: EAP: EAP entering state RECEIVED
> 1140175889.089916: EAP: Received EAP-Failure
> 1140175889.089920: EAP: EAP entering state FAILURE

It looks like the RADIUS server did not like the Phase 2 Nak for some
reason which could indeed indicate that something changed from 0.5.1.

> The difference I noticed, is: EAP-PEAP: Allowed Phase2 EAP types - 
> hexdump(len=8): 00 00 00 00 1a 00 00 00

This is the change to use EAP expanded types, i.e., EAP types are now
identified with 8-octet value (32-bit vendor id and 32-bit type). This
here would indeed be identical to '1a' in 0.5.0.

> So, leading zero's maybe let the EAP detection fail in wpa_supplicant 0.5.1.

If the Phase 2 Nak gets incorrect value, that would indeed explain the
behavior. It is supposed to be '1a' in this case.

I was able to reproduce this and indeed, the EAP type was zero in this
Nak:

EAP-PEAP: Allowed Phase2 EAP types - hexdump(len=8): 00 00 00 00 1a 00 00 00
EAP-PEAP: Encrypting Phase 2 data - hexdump(len=6): 02 08 00 06 03 00

The Phase 2 Nak generation did not apparently get all the needed changes
for expended types. This will likely break PEAP, TTLS, FAST for cases
where the EAP type selected by the authentication server is not
acceptable. I'll fix these.

-- 
Jouni Malinen                                            PGP id EFC895FA