eap Mailing List: Re: EAP-AKA review

[Yoshihiro Ohba (yohba]

Hi Henry,

Please see my comment below.

On Fri, Oct 15, 2004 at 06:18:42PM +0300, henry.haverinen [at] nokia.com wrote:
> 
> I have a question about the following comment in Section 9.6:
> 
> >   Because EAP-AKA is not a tunneling method, EAP-Request/Notification,
> >   EAP-Response/Notification, EAP-Success or EAP-Failure packets are not
> >   confidential, integrity protected or replay protected. On physically
> >   insecure networks, this may enable an attacker to mount denial of
> >   service attacks by spoofing these packets. As discussed in Section
> >   4.4, the peer will only accept EAP-Success after successful
> >   authentication. Hence, the attacker cannot force the peer to believe
> >   successful authentication has occurred when mutual authentication
> >   failed or has not happened yet.
> >
> >$ohba: This is true only when the optional method-specific success
> >indication is used.
> 
> This paragraph refers to section 4.4.4, which specifies the processing 
> of EAP-Success. In EAP-AKA, the peer authenticates 
> the server already based on EAP-Request/AKA-Challenge or 
> EAP-Request/AKA-reauthentication.
> Section 4.4.4 specifies for full authentication that "The peer MUST 
> silently discard any EAP-Success packets if they are received before 
> the peer has successfully authenticated the server and sent the EAP-Response/
> AKA-Challenge packet.". For fast re-authentication, section 4.4.4
> specifies that "The peer MUST silently discard any EAP-Success packets 
> if they are received before the peer has successfully authenticated the 
> server and sent the EAP-Response/AKA-Reauthentication packet.".
> 
> To me it seems that the quoted text is true even if method-specific
> success indication was not used. Do you agree?

I agree that above quoted text taken from section 4.4.4 is true even
if method-specific success indication was not used (and thus there was
no comment in section 4.4.4).

However, I don't think the text in section 9.6 precisely refers to the
quoted text for the following reason:

- The quoted text taken from section 4.4.4 discusses the peer's
behavior *before* the peer has successfully authenticated the server.
The quoted text does not say anything about what the peer should do
*after* the peer has successfully authenticated the server.

- The text in section 9.6, i.e., "the peer will only accept
EAP-Success after successful authentication", discusses the peer's
behavior *after* the peer has successfully authenticated the server.

I think these two are different things.

With regard to the peer's behavior *after* the peer has successfully
authenticated the server, I have the following observation:

Since the server *may or may not* succeed to validate the
EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication
message sent by the peer, the peer must be ready to accept both an
EAP-Success message (sent when the validation succeeds) and an
EAP-Request/AKA-Notification message (sent when the validation fails),
if the method-specific success indication is NOT used.  When the
server fails to validate the response, if an attacker sends an
EAP-Success message and the peer receives it before receiving an
EAP-Request/AKA-Notification message sent from the real server, the
peer will end up with accepting the EAP-Success.  Thus I believe that
the following sentence in section 9.6 is not true:

  "Hence, the attacker cannot force the peer to believe successful
  authentication has occurred when mutual authentication failed or has
  not happened yet."

Regards,

Yoshihiro Ohba


> 
> Best regards,
> Henry