EAP-AKA patch for Freeradius 1.1.2
awaneeshkmr at yahoo.com
Mon Apr 2 08:03:56 CEST 2007
I have downloaded patch from http://bugs.freeradius.org/show_bug.cgi?id=386.
I have succesfully applied patch to Freeradius1.1.2. Few questions i have..
a) Does patch supports optional identity privacy support, optional result indications, and an optional fast re-authentication procedure.
b) After receiving EAP-Request/AKA-Challenge from server, client should calculate AT_MAC and compares with the received one. If it matches it should send back the EAP-Response/AKA-Challenge with AT_RES and new AT_MAC.
As per section 10.8 of RFC 4187, AT_RES should be encoded as follows.
The value field of this attribute begins with the 2-byte RES Length,which identifies the exact length of the RES in bits. The RES length is followed by the AKA RES parameter. According to [TS33.105], the length of the AKA RES can vary between 32 and 128 bits. Because the length of the AT_RES attribute must be a multiple of 4 bytes, the sender pads the RES with zero bits where necessary
Trace below is packet from client to server:-
c) As per section 3 (Figure 2) from RFC 4187, if server is unable to authenticate client if AT_MAC or AT_RES is incorrect, it should back the EAP-Request/AKA-Notification to client and client should respond back with EAP-Response/AKA-Notification. Then only server should send back EAP result as Failure. But Freeradius1.1.2 sends back the EAP Result (FAILURE) with Access-Reject. How ever success scenarion works perfectly.
d) After receiving AKA-Challenge from Radius server, does patch supports the checking of Sequence No from AUTN parameter?
Do we have any latest patch to support EAP-AKA?
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Freeradius-Devel