eap Mailing List: RE: Re: EAP-AKA review

[henry.haverinen (henry.haverinen]

Hi Yoshihiro,

Thanks for clarifying the issue, now I understand. Would
the following change be an appropriate way of fixing this
issue in your opinion:

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 authentication of the network
failed or has not happened yet. 

Best regards,
Henry

> -----Original Message-----
> From: eap-admin [at] frascone.com 
> [mailto:eap-admin [at] frascone.com]On Behalf Of ext Yoshihiro Ohba
> Sent: 15 October, 2004 20:22
> To: Haverinen Henry (Nokia-ES/Jyvaskyla)
> Cc: yohba [at] tari.toshiba.com; stephen.hayes [at] ericsson.com; 
> jari.arkko [at] piuha.net; eap [at] frascone.com
> Subject: [eap] Re: EAP-AKA review
> 
> 
> 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
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>