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

[henry.haverinen (henry.haverinen]

Thanks, Yoshihiro. That looks good to me.

Best regards,
Henry

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:yohba [at] tari.toshiba.com]
> Sent: 18 October, 2004 06:31
> 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: Re: [eap] Re: EAP-AKA review
> 
> 
> Hi Henry,
> 
> On Sun, Oct 17, 2004 at 03:21:51PM +0300, 
> henry.haverinen [at] nokia.com wrote:
> > 
> > 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. 
> 
> Yes.  More precisely something like ("authentication of the network"
> is ambiguous to me):
> 
> "
> As discussed in Section 4.4, the peer will only accept EAP-Success
> after the peer successfully authenticates the server.  Hence, the
> attacker cannot force the peer to believe successful mutual
> authentication has occurred before the peer successfully authenticates
> the server or after the peer failed to authenticate the server.
> "
> 
> Regards,
> 
> Yoshihiro Ohba
> 
> > 
> > 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
> > > 
>