Subject: [eap] EAP-SIM Notifications

From: Uma Shankar Ch <[email-masked]>
Date: Sun, 22 Aug 2004 00:40:16 +0530

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.

-Uma Shankar Ch

www.intoto.com

---

From: "Joseph Salowey" <[email-masked]>
Date: Sun, 22 Aug 2004 22:40:07 -0700

Uma Shankar Ch wrote:
>    MUST respond to the EAP server with an
>    EAP-Response/SIM/Notification packet, even if the peer did not
> recognize the notification code." 
> 
> (2) "An EAP-SIM full authentication exchange or a fast
>    re-authentication exchange MUST NOT include more than one EAP-SIM
> notification round." 
> 
> 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.
> 
> AT_RESULT_IND just by sending an unprotected notify after or  just
> before EAP-Request/SIM/Start round trip.     
> 
> 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.  

> www.intoto.com

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