eap Mailing List: RE: EAP-AKA review

[henry.haverinen (henry.haverinen]

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