EAP-FAST inner Auth Fails

ramprasad.rajendran at wipro.com ramprasad.rajendran at wipro.com
Fri Dec 8 01:06:03 EST 2006



>-----Original Message-----
>From: hostap-bounces+ramprasad.rajendran=wipro.com at shmoo.com 
>[mailto:hostap-bounces+ramprasad.rajendran=wipro.com at shmoo.com]
> On Behalf Of Jouni Malinen
>Sent: Friday, December 08, 2006 11:15 AM
>To: hostap at shmoo.com
>Subject: Re: EAP-FAST inner Auth Fails
>
>> EAP-FAST: Decrypted Phase 2 TLV(s) - hexdump(len=9): 80 09 
>00 05 01 01 
>> 00 05 01
>> EAP-FAST: received Phase 2: TLV type 9 length 5 (mandatory)
>> EAP-FAST: EAP Payload TLV - hexdump(len=5): 01 01 00 05 01
>> EAP-FAST: Phase 2 Request: type=1
>
>And the server is sending out EAP-Request/Identity frame in 
>the tunnel and that is received successfully.

Is this fine. Can the server just ask for a request identity inside the
tunnel instead of using any authentication method like GTC or MSCHAPV2.
The documentation at the server says, the following
"
1. In Phase 0, a client without a valid PAC opens a connection through a
RAS to the
Steel-Belted Radius server. Steel-Belted Radius uses EAP-MS-CHAPv2 to
authenticate the user. If authentication is successful, Steel-Belted
Radius generates a
PAC for the user. and returns an Access-Reject message that contains the
PAC.
If a client already has a valid PAC, Phase 0 is omitted.

2. In Phase 1, the client and the Steel-Belted Radius server establish a
TLS tunnel
based on the PAC presented by the user. During Phase 1, the server
verifies that the
PAC presented by the client was generated by its current or retired
server secret.

3. In Phase 2, the server authenticates the user or machine credentials
using EAP-GTC
inside the protected TLS tunnel. If the PAC is valid and the user's
credentials are
correct, the authentication succeeds and Steel-Belted Radius returns an
Access-Accept message. If the user's PAC is due to expire soon,
Steel-Belted Radius
provisions the client with a new PAC over the secure network connection
at the end
of Phase 2..

I don't think the server shows this behaviour.

>
>> EAP: using real identity - hexdump_ascii(len=4):
>>      74 65 73 74                                       test
>> EAP-FAST: Encrypting Phase 2 data - hexdump(len=13): 80 09 
>00 09 02 04 
>> 00 09 01 74 65 73 74
>
>The EAP-Response/Identity from the client looks fine, too.
>
>> EAP-FAST: Decrypted Phase 2 TLV(s) - hexdump(len=6): 80 03 
>00 02 00 02
>> EAP-FAST: Result TLV - hexdump(len=2): 00 02
>> EAP-FAST: Result: Failure
>
>But the server is rejecting this identity.
>
>Have you been able to use this server with another client 
>implementation? Are you sure that the server is configured to 
>allow this identity to be used? Do you have access to the logs 
>from the server?

The server's log says the following

==> authReports/rejects_20061208.csv <==
"2006-12-08","11:29:51","<ANY>","test","EAP-FAST","User name or
credential incorrect","Inner EAP-FAST authentication
failed","10.114.2.53"

==> 20061208.log <==
12/08/2006 11:29:51 User test ultimately failed challenge sequence
12/08/2006 11:29:51 Sent reject response

I haven't tried the server with any other client. 
Though I've tested this SBR server and the supplicant with EAP-MSCHAPV2
and EAP-MD5 and they are working perfectly fine.

--
ram

>-- 
>Jouni Malinen                                            PGP 
>id EFC895FA
>_______________________________________________
>HostAP mailing list
>HostAP at shmoo.com
>http://lists.shmoo.com/mailman/listinfo/hostap
>


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
 
www.wipro.com



More information about the HostAP mailing list