eap Mailing List: RE: EAP-SIM Notifications

[Joseph Salowey (jsalowey]

Uma Shankar Ch wrote:
> Can any body clarify, Not-Clear MUST conditions with EAP-SIM
> Notifications 
> 
> 
> In section 4.4.1, regarding EAP-SIM Notifications, the draft
> "draft-haverinen-pppext-eap-sim-13.txt" says 
> 
> (1) "When the EAP server issues an EAP-Request/SIM/Notification
>    packet to the peer, the peer MUST process the notification packet.
>    The peer MAY show a notification message to the user and the peer
>    MUST respond to the EAP server with an
>    EAP-Response/SIM/Notification packet, even if the peer did not
> recognize the notification code." 
> 
> And after that draft also says
> 
> (2) "An EAP-SIM full authentication exchange or a fast
>    re-authentication exchange MUST NOT include more than one EAP-SIM
> notification round." 
> 
> Now, consider the situation where EAP server issued an
> EAP-Request/SIM/Challenge with the optional AT_RESULT_IND attibute,
> and peer responded with EAP-Response/SIM/Challenge with AT_RESULT_IND
> attibute, after this there MUST be a protected Notification reslut
> round before the actual SUCCESS/FAILURE from the EAP Server, as
> result indications are negotiated.     
> 
> If server sends a notification before the Challenge request, peer
> would respond with the Notification response as per rule (1)
> mentioned, so the chance of one notification round trip is completed.
> Now EAP server and peer can not use AT_RESULT_IND in Challenge
> request round, even though peer is capable of supporting protected
> result indications as already one notification response sent earlier.
> 
> As the Notification requests are not protected before successful
> EAP-Request/SIM/Challenge round trip in full authentication or
> successful  EAP-Request/SIM/Re-authentication round trip in fast
> re-authentication, any attacker can force peer not to negotiate
> AT_RESULT_IND just by sending an unprotected notify after or  just
> before EAP-Request/SIM/Start round trip.     
> 
> With this it seems, either one of the above MUST conditions should be
> relaxed, to enable peer to go for result indication negotiation, even
> when an attacker sends a notification before AT_RESULT_IND
> negotiation or a peer implementation MUST be given a flexibility to
> ignore all notifications before EAP-Request/SIM/Challenge round or
> EAP-Request/SIM/Re-authentication round.     

[Joe] Currently the draft defines notification codes that are either failure
messages that result is a termination of the conversation or messages which
are intended to be used only after authentication has completed. So I don't
think the scenario you describe above occurs with the current notifications.
In order to avoid the problem stated we could recommend that only failure
codes may be sent before authenticated message begin.  



> 
> -Uma Shankar Ch
> 
> www.intoto.com