AT_NOTIFICATION is missing on the EAP_AKA server (authenticator)
Wed Apr 11 12:19:16 PDT 2007
Thank you very much! EAP-AKA implementation looks very
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
--- Jouni Malinen <j at w1.fi> wrote:
> On Wed, Apr 04, 2007 at 01:57:15PM -0700, Gang Lu
> > Thanks for responding so fast. I went through your
> > change and compare with RFC and come up with the
> > list that probably need more changes:
> > 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,
> > server verifies AT_MAC and verifies that
> > contains the same counter value as in the
> > EAP-Request/AKA-Reauthentication packet. If not,
> > server terminates the authentication exchange by
> > sending the EAP-Request/AKA-Notification packet
> > AT_NOTIFICATION code "General failure" (16384).
> > However, eap_sim_parse_attr() in eap_sim_common.c
> > not even checking AT_COUNTER_TOO_SMALL. However,
> > wpa_supplicant code returns AT_COUNTER_TOO_SMALL
> > the required cases.
> OK. This turned out to be more complex issue than
> just using
> AKA-Notification. Server is required to start full
> 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
> > RFC section 10.1 on page 52, the client side
> > should not include AT_NOTIFICATION. So,
> > eap_aka_response_notification() should not inclyde
> > 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
> > MUST be included if the P bit of the
> > code is set to zero, and MUST NOT be included if
> > P bit is set to one. The P bit is discussed in
> > Section 6.".
> > If so, the eap_aka_build_notification() in
> > 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
> > 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
> > and the encapsulated plaintext attributes MUST
> > the AT_COUNTER attribute. The counter value
> > in AT_COUNTER MUST be the same as in the
> > EAP-Request/AKA-Reauthentication packet on the
> > fast re-authentication exchange.".
> > This again points to more complex handlings are
> > 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
More information about the Hostap