AT_NOTIFICATION is missing on the EAP_AKA server (authenticator)

[Gang Lu]

Hi, Jouni:

Thanks for responding so fast. I went through your
change and compare with RFC and come up with the below
list that probably need more changes:

1. RFC says: " Unrecognized or unexpected EAP-AKA
Subtype in the EAP Response".

This is not satisfied because EAP-AKA subtype checking
is done in eap_aka_check(), which is called in eap.c
by calling sm->m->check(...) in INTEGRITY_CHECK state.
When that returns true, EAP state machine enters
DISCARD state while EAP-AKA RFC requires to exchange
one round of AT_NOTIFICATION between server and
client. This seems to be issue with the code
structure. I suggest to move the type checking for
EAP-AKA from eap_aka_check() into eap_aka_process().

2. RFC says: "On receipt of AT_COUNTER_TOO_SMALL, the
server verifies AT_MAC and verifies that AT_COUNTER
contains the same counter value as in the 
EAP-Request/AKA-Reauthentication packet.  If not, the
server terminates the authentication exchange by
sending the  EAP-Request/AKA-Notification packet with
AT_NOTIFICATION code   "General failure" (16384).

However, eap_sim_parse_attr() in eap_sim_common.c is
not even checking AT_COUNTER_TOO_SMALL. However, the
wpa_supplicant code returns AT_COUNTER_TOO_SMALL in
the required cases.

3. According to the attribute/message type matrix in
RFC section 10.1 on page 52, the client side response
should not include AT_NOTIFICATION. So,
eap_aka_response_notification() should not inclyde the
following line:  eap_sim_msg_add(msg,
EAP_SIM_AT_NOTIFICATION, notification, NULL, 0);

4. In RFC section 9.10, it says" The AT_MAC attribute
MUST be included if the P bit of the  AT_NOTIFICATION
code is set to zero, and MUST NOT be included if the 
P bit is set to one.  The P bit is discussed in
Section 6.".

If so, the eap_aka_build_notification() in eap_aka.c
should check the P bit in the code and decide to
include AT_MAC or not according to the P bit.

5. Same as 4, in RFC section 9.10, it says "If
EAP-Request/AKA-Notification is used on a fast
re-authentication  exchange, and if the P bit in
AT_NOTIFICATION is set to zero, then AT_COUNTER is
used for replay protection.  In this case, the
AT_ENCR_DATA and AT_IV attributes MUST be included,
and the encapsulated plaintext attributes MUST include
the AT_COUNTER attribute.  The counter value included
in AT_COUNTER MUST be the same as in the
EAP-Request/AKA-Reauthentication packet on the same
fast re-authentication exchange.".

This again points to more complex handlings are needed
in eap_aka_build_notification as in 4. 

Gang

--- Jouni Malinen <j at w1.fi> wrote:

> On Mon, Apr 02, 2007 at 07:36:39AM -0700, Gang Lu
> wrote:
> 
> > I am using the hostapd 0.5.7 version code (latest
> > stable). However, I can't see anywhere the code
> tries
> > to generate AT_NOTICATION back to the client as
> > required by RFC in certain cases. However, the
> client
> > side code (wpa-supplicant) does do that,
> generating
> > AT_NOTICATION back to server upon receing
> > AT_NOTIFICATIOn froms erver according to the RFC.
> > 
> > So, I see the client is doing the right thing but
> the
> > server (hostapd) seems missing the implementation
> to
> > generate AT_NOTIFICATION.
> 
> Yes, indeed. I do remember not implementing
> protected result
> notification on purpose, but I don't remember why
> this was left out.
> Anyway, I added support for going through the
> notification round in
> error cases before sending out EAP-Failure. I did
> not go through all
> cases in RFC yet, so I may have missed something,
> but at least most
> cases should now be sending out notification and
> only the notification
> response or client error result in EAP-Failure to be
> sent out. Please
> let me know if you notice anything wrong with this.
> The changes are only
> in the 0.6.x development branch (Git tree) for the
> time being.
> 
> Testing this revealed a minor issue in
> wpa_supplicant, too. It was
> discarding notification request after challenge
> exchange. This is also
> fixed in 0.6.x.
> 
> -- 
> Jouni Malinen                                       
>     PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>