AT_NOTIFICATION is missing on the EAP_AKA server (authenticator)

[Jouni Malinen]

On Wed, Apr 04, 2007 at 01:57:15PM -0700, Gang Lu wrote:

> 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:

Thanks!

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

OK, fixed.

> 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.

OK. This turned out to be more complex issue than just using
AKA-Notification. Server is required to start full authentication
in this case if AT_MAC and AT_COUNTER are correct. In addition,
wpa_supplicant was not calculating AT_MAC correctly for this case.
All of these issues are now fixed.

> 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);

OK, fixed.

> 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.

There is no places in the current implementation that would set P bit to
zero.

> 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. 

I'm not aware of any case that would actually set P bit to zero and as
such, I haven't seen need to add this extra complexity. The only case
that would use this is the optional protected result indication and I
have not bothered implementing it because use of optional feature for
protected result indication does not sound very useful. Are you aware of
any other message sequence that would actually end up using
AKA-Notification with P bit set to zero?

-- 
Jouni Malinen                                            PGP id EFC895FA