[RADIATOR] ] RADIATOR: EAP-FAST-MSCHAPv2

Thu Apr 19 04:28:04 CDT 2012

On 04/18/2012 12:26 PM, Sudhir Harwalkar wrote:

> We are not creating any client log file, we are using Dock light for debug and will check wire shark for more details.

Hmm, wireshark is not that useful for this type of work where you need
to see what the peers are doing. You would greatly benefit you could get
log directly from the client.

> See the eap_fast MSCHAPv2 wire shark details and radius logfile.  This log will explain both success and failure case(after restarting the radius)

Yes, I see that everything works well in the beginning when the client
does not have a PAC and Radiator allocates one to it. As long as
Radiator is not restarted the client successfully authenticates with the
PAC it was provisioned by Radiator.

Once you stop and start Radiator, it will no longer remember the PAC.
When the client sends its PAC, Radiator does not recognise it and
allocates a new PAC to the client. The client then fails to continue and
sends a SSL alert.

My opinion is the client has problems recovering from the possibility of
RADIUS server loosing its PAC knowledge.

If you use e.g. SQLite to store the PACs across Radiator restarts, it
should work as long as the SQLite DB is there and the PACs do not time
out. PACs can have limited lifetime and the client should be prepared
for this too.

Heikki

> - Sudhir
> 
> -----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 1:38 PM
> To: radiator at open.com.au
> Subject: Re: [RADIATOR] ] RADIATOR: EAP-FAST-MSCHAPv2
> 
> 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.
> _______________________________________________
> 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.