eap Mailing List: Re: EAP-AKA review

[Yoshihiro Ohba (yohba]

On Mon, Oct 11, 2004 at 03:50:43PM +0300, Jari Arkko wrote:
> A couple of comments (with the author hat on):
> 
> >    1c. Justifications for the claims? Is an explanation or
> >        reference provided to each of the claims?
> >
> >Missing reference or explanation for mutual authentication in Section
> >10.
> 
> Yes. Section 9.2 should refer to [TS 33.102] to support this
> claim, and then Section 10 should point to either Section 9.2
> or the reference. Would this make your problem go away?

Yes.

> 
> >    3c. Does the method comply with request/response processing
> >        rules as defined in Section 4.1 of RFC 3748?
> >
> >The following text in section 7.13 of
> >draft-arkko-pppext-eap-aka-12.txt does not seem to comply with EAP
> >request/response processing if "another EAP-Request/AKA-Identity with
> >the same attributes as in the previous request" means a new EAP
> >request.  (According to section 4.1 of RFC 3748, the EAP server is not
> >allowed to generate a new EAP request until a valid EAP response is
> >received, an optional retry counter expires, or a lower layer failure
> >indication is received.)
> >
> >"
> >   After sending EAP-Response/
> >   AKA-Identity, if the peer receives another EAP-Request/AKA-Identity
> >   with the same attributes as in the previous request, then the peer's
> >   response to the first request must have been lost. In this case the
> >   peer must not include the first request and its response in the
> >   calculation of the checkcode.
> >"
> 
> It seems unnecessary to talk about lost messages. By RFC 3748,
> the server will retry sending until it fails. Perhaps this part
> of the text should just be deleted.

I agree with you on just deleting the text.

> 
> >    3f. Does the method comply with the usage defined for
> >        Notification, as defined in Section 5.2 of RFC 3748?
> >
> >It is unclear whether EAP Notification is allowed or prohibited in
> >EAP-AKA.
> 
> Question: Why do you think its unclear? There's a lot of
> AKA-Nofification messages, but is there some text that
> talks about EAP Notification messages? If yes, that text
> should probably be changed. If not, I think we can assume
> that RFC 3748 is followed -- I don't think methods need
> to repeat the requirements or prohibitions of RFC 3748,
> as long as the methods don't themselves require something
> which is in violation of RFC 3748, such as suggest sending
> EAP Notifications in a place where they are not allowed.

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.

Best regards,

Yoshihiro Ohba


> 
> --Jari
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap