[RADIATOR] ] RADIATOR: EAP-FAST-MSCHAPv2

Wed Apr 18 03:07:49 CDT 2012

On 04/18/2012 08:08 AM, Sudhir Harwalkar wrote:

> Still I am not clear about the working of EAP-FAST with MSCHAPv2.
> In this case:
> Whenever I flash the code to the device(client), its generating the new PAC with this radius server and the client are authenticated successfully.

Yes. If the client does not present a PAC, the RADIUS server will create
an send it (provision) it a PAC.

> If I restart the radius server means by pressing ctrl+c it stop the radius sever and again I run the same config file, at that time PAC key is same and authentication is failing.

The client can send a PAC, but if the RADIUS server does not recognize
(e.g., PAC is unknown or too old) it, it will provision a new PAC to the
client.

> As radius server is remembering the key so it's not authenticated is this true?, if not when I restart the server it should authenticate right because for radius server it's a new PAC key that's not happening here.

The log you sent earlier shows your client did not like the new PAC or
for some other reason refused to continue the authentication. It is the
RADIUS server that decides if the PAC is valid or not. Client must be
prepared for the case when the PAC it sends it not accepted or a new PAC
is provisioned.

> Note: My device(client) will generate new PAC whenever flash the code.

Is it prepared to accept a new PAC if the RADIUS server wants to
provision a new PAC. Also, the client can not generate a PAC. It can
only accept and save a PAC from the RADIUS server.

Some examples:
Tue Apr 17 11:58:11 2012: DEBUG: EAP-FAST received PAC_OPAQUE
Tue Apr 17 11:58:11 2012: DEBUG: Query is: 'select PAC_LIFETIME, PAC_KEY
from EAPFAST_PAC where
PAC_OPAQUE='fdba49cd98ff8bc9788e5be77a6757e616801327461dac23b865a6e701d62b6e'
and PAC_LIFETIME >= 1334644091':
Tue Apr 17 11:58:11 2012: DEBUG: EAP-FAST requested PAC not found
Tue Apr 17 11:58:11 2012: DEBUG: EAP-FAST a new PAC will be provisioned

This is from the log you sent. Your client is sending a PAC, but
RADIATOR did not find it from the SQL db. So it will provision a new PAC.

The authentication then continues but client does not want to continue.
A bit later your client sends an alert:

Tue Apr 17 11:58:11 2012: ERR: EAP-FAST TLS Handshake unsuccessful:
4924: 1 - error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert
unexpected message

If the PAC is not sent by the client, the log message is different but
still clearly tells what Radiator is doing.

So please check your client log and Radiator log for what is happening.
The presence and provisioning of PAC can be seen from the log.

Thanks!
Heikki

> Regards
> Sudhir H
> 
> -----Original Message-----
> From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au] On Behalf Of Heikki Vatiainen
> Sent: Wednesday, April 18, 2012 3:08 AM
> To: radiator at open.com.au
> Subject: Re: [RADIATOR] RADIATOR: EAP-FAST-MSCHAPv2
> 
> On 04/17/2012 01:29 PM, Sudhir Harwalkar wrote:
>>
>> Because previously it was working fine without any modification from client side, does modification in EAP_43.pm is affecting for authentication?
>> From the client log its failing after username and Pw. See the screen shot of the client log.
> 
> The change in EAP_43.pm does one thing. If Server-Unauthenticated provisioning is done, instead of requiring just one ciphersuite
> (TLS_DH_anon_WITH_AES_128_CBC_SHA) the mode is entered when this ciphersuite is present with possible other suites. One such suite is TLS_EMPTY_RENEGOTIATION_INFO_SCSV from RFC 5746.
> 
> If you want to go back to EAP_43.pm, just take it from Radiator distribution and copy it over to any existing EAP_43.pm you have in your system.
> 
> The PAC provisioning is not affected and using SQL (SQLite in your case) for storing the PAC does not change how it is generated and provisioned.
> 
> You should experiment with your client and see its logs for why it does not work. The configuration I returned to you was working and tested fine here.
> 
> Thanks!
> Heikki
> 
> 
> --
> Heikki Vatiainen <hvn at open.com.au>
> 
> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
> 
> 
> Larsen & Toubro Limited
> 
> www.larsentoubro.com
> 
> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.