Subject: RE: [eap] EAP-AKA review

From: <[email-masked]>
Date: Tue, 12 Oct 2004 17:54:58 +0300

Yoshihiro,

> RFC 3748 does not specify when to send an EAP-Request/Notification.
> If EAP-AKA allows EAP Notification, but does not specify when to sent,
> there is no specification so far that defines when to send an
> EAP-Request/Notification during EAP-AKA.  It seems that there are two
> choices:
> 
> (a) Have an explicit text saying that EAP-AKA does not prohibit EAP
> Notification but it is out of the scope of the document as to when an
> EAP-Request/Notification is sent within EAP-AKA.
> 
> (b) Just prohibit EAP Notifications during EAP-AKA.
> 
> My personal preference is (b) for simplicity unless there is specific
> reason to allow EAP Notification during EAP-AKA in addition to
> AKA-Notifications.

I agree that these are the choices we have. In case (a) we should also have
explicit text saying that EAP-AKA does not protect EAP Notifications.

I'm fine either way. I agree that (b) would be simpler. I'm not able to convince myself
that (a) would never be useful -- for example if EAP-AKA is run within 
a tunneling method. So if it was up to me I'd choose (a).

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

---

From: <[email-masked]>
Date: Sun, 17 Oct 2004 15:21:51 +0300

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: [email-masked] 
> [mailto:[email-masked]]On Behalf Of ext Yoshihiro Ohba
> Sent: 15 October, 2004 20:22
> To: Haverinen Henry (Nokia-ES/Jyvaskyla)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [eap] Re: EAP-AKA review
> 
> 
> Hi Henry,
> 
> Please see my comment below.
> 
> On Fri, Oct 15, 2004 at 06:18:42PM +0300, 
> [email-masked] 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