AT_NOTIFICATION is missing on the EAP_AKA server (authenticator)

[Gang Lu]

Jouni:

Thank you very much! EAP-AKA implementation looks very
good now.

I persoanlly feel the P bit thing is a very confusing
point in the RFC and agree that the optional
protection success notification doesn't have much
benefit. I will let you if I ever get across one
instance of that. The existing way is fine even from
RFC perspective. 

Gang





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

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