iPad PEAP MSCHAPv2

Fri Jan 15 17:37:43 CET 2016

Good afternoon,

I have continued investigating this issue, reproducing the problem with
eapol_test.
Disabling tlsv1_2 did not affect the result, and I was still having
problems.

So I have installed the new freeradius version on the old server, in order
to being able to compare the results, and I have found that the new
freeradius works ok on the old server!

* Radius server: freeradius 3.0.10 on both cases, with the same
configuration.

* Radius client: eapol_test, Ubuntu 14.04, OpenSSL 1.0.1f
Configuration:
network={
   ssid="example"
   key_mgmt=WPA-EAP
   eap=PEAP
   identity="oscarrdg at unav.es"
   anonymous_identity="anonino at unav.es"
   password="xxx"
   phase2="autheap=MSCHAPV2"
   ca_cert="/path/to/AddTrustExternalCARoot.crt"
   subject_match="radius.unav.es"
}

Case #1: RedHat 5.4 with OpenSSL 0.9.8e-fips -> it works ok.

Case #2: CentOS Linux release 7.1 with OpenSSL 1.0.1e-fips -> it doesn't
work!!!

Comparing the debug logs, line by line, I see that the first difference is
in the EAP-Message of Access-Request #6, much bigger in case #2:

In Case #1:
(6) Received Access-Request Id 6 from 159.237.8.31:44007 to
159.237.12.8:1812 length 142
(6)   User-Name = "anonino at unav.es"
(6)   NAS-IP-Address = 127.0.0.1
(6)   Calling-Station-Id = "02-00-00-00-00-01"
(6)   Framed-MTU = 1400
(6)   NAS-Port-Type = Wireless-802.11
(6)   Connect-Info = "CONNECT 11Mbps 802.11b"
(6)   EAP-Message = 0x020600061900
(6)   State = 0x8b3943f38e3f5a55c9ac9b72d18645f9
(6)   Message-Authenticator = 0xcd67323c10f8d7f439dc359154e0ad1f
...

In Case #2:
(6) Received Access-Request Id 6 from 159.237.8.31:32965 to
159.237.18.104:1812 length 280
(6)   User-Name = "anonino at unav.es"
(6)   NAS-IP-Address = 127.0.0.1
(6)   Calling-Station-Id = "02-00-00-00-00-01"
(6)   Framed-MTU = 1400
(6)   NAS-Port-Type = Wireless-802.11
(6)   Connect-Info = "CONNECT 11Mbps 802.11b"
(6)   EAP-Message =
0x02060090198000000086160301004610000042410483144b3e8df35650f6435c0906f39d3d33301f98f391c1bc73127ff72afe7ef82d6aa40707f062c2eaab73383292ca022f1469df43863eda1d869a64b3607c5014030100010116030100303b6e2063d8d994c891195fb9e8c3103b1344b7b90b063b
(6)   State = 0x8341512f864748c0e4521fbd4bfec62c
(6)   Message-Authenticator = 0x31f13ba6367085271478a2c313113ada

And it starts getting different from here... [1]

I have seen that there are also some problems with versions OpenSSL 1.0.1f
and 1.0.1g:
http://lists.freeradius.org/pipermail/freeradius-users/2015-December/081251.html

Is it correct if I conclude that this version (OpenSSL 1.0.1e) is also not
working properly??

Is there a way to make freeradius use a different version of openssl on the
same server?

Thank you so much for your support.

Regards,

[1] If it helps in some way, I can send the whole debug log.

*Oscar Remírez de Ganuza Satrústegui*
IT Services
Universidad de Navarra
Tel. +34 948425600 x803130
http://www.unav.edu/web/it/

On Fri, Nov 20, 2015 at 8:41 AM, Óscar Remírez de Ganuza Satrústegui <
oscarrdg at unav.es> wrote:

> Good morning,
>
> Yes: new server (RHEL 5.4 -> CentOS 7.1) + new version of openssl (OpenSSL
> 0.9.8e-fips -> OpenSSL 1.0.1e-fips)
>
> I will have a look to your suggestions:
> - examining and comparing the access accept packets
> - disabling tlsv1_2
>
> Thank you so much for your help, Alan and Arran!
>
> Regards,
>
>
>
> *Oscar Remírez de Ganuza Satrústegui*
> IT Services
> Universidad de Navarra
> Tel. +34 948425600 x803130
> http://www.unav.edu/web/it/
>
> On Thu, Nov 19, 2015 at 9:21 PM, <A.L.M.Buxey at lboro.ac.uk> wrote:
>
>> Hi,
>>
>> > As I told on a previous email, we are migrating previous radius (2.1.9)
>> > authentication to a new instance of freeradius (3.0.10).
>>
>> new server? new version of openssl on the new server?
>>
>> if the access accept packet is the same as that from 2.1.9 then the issue
>> is somewhere else. I'd examine that last access accept packet.
>>
>>
>> but my first instinct is that this is a MPPE key issue - access accept
>> okay
>> but the IOS device not likeing the derived keys - validate this by
>> putting
>>
>> disable_tlsv1_2 = yes
>>
>> into the tls {} section of your eap module
>>
>>
>> i think this issue is fixed in 3.0.x HEAD  (?)
>>
>>
>> alan
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>
>
>