eap Mailing List: RE: EAP-AKA review

[henry.haverinen (henry.haverinen]

Yoshihiro, Jari,

First of all, many thanks to Yoshihiro for reviewing EAP-AKA!

Please see my comment below.

> > The following text in section 9.6 made me come up with the 
> comment on
> > EAP Notification:
> > 
> > "
> >    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.
> >                                                             
>                     
> >    The security considerations of EAP-AKA result 
> indications are covered
> >    in Section 9.8
> >                                                             
>                     
> >    An eavesdropper will see the EAP Notification, EAP_Success and
> >    EAP-Failure packets sent in the clear. With EAP-AKA, confidential
> >    information MUST NOT be transmitted in EAP Notification packets.
> > "
> > 
> > The text seems to indicate that there is some case in which EAP
> > Notification packets are sent in EAP-AKA, but I failed to find some
> > text that explains when they are sent besides AKA-Notification
> > packets.
> 
> Ah, I see the problem now. I don't think the intention was to
> allow EAP Notifications in any sense disallowed by RFC 3748.
> Perhaps we could delete the Notification parts from the above,
> or add a statement that the draft does not specify that they
> should be used and that if they are used they should be used
> according to RFC 3748. Henry?

The definition of the integrity protection security claim in RFC 3748 
says that "When making this claim, a method specification MUST describe the EAP 
packets and fields within the EAP packet that are protected."
There is similar language for other security claims, too.

The text in Section 9.6 discusses which EAP packets are protected,
and EAP Notifications are only mentioned in order to make it clear
that EAP-AKA does not protect them. Of course it is possible to 
specify the scope of protection without mentioning EAP Notifications
at all. So I think we could remove all discussion about EAP Notifications.
I could not find anything in RFC 3748 that would require the method
specification to state whether EAP Notifications are protected.

Best regards,
Henry