Subject: [eap] RE: EAP-AKA review

From: <[email-masked]>
Date: Fri, 15 Oct 2004 18:18:42 +0300

Hi Yoshihiro,

> My detailed comments are available at:
> http://www.opendiameter.org/draft-arkko-pppext-eap-aka-12_ohba
> -comments.txt.

Thank you for these very clear detailed comments. I'm currently incorporating
them in EAP-AKA. 

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?

Best regards,
Henry
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 15 Oct 2004 13:22:02 -0400

Hi Henry,

Please see my comment below.

> 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