Re: EAP-AKA review
From: Jari Arkko (jari.arkkopiuha.net)
Date: Tue, 12 Oct 2004 00:43:52 -0400 (EDT)
Yoshihiro,

>>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.

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?

--Jari

Results generated by Tiger Technologies using MHonArc.