| EAP-SIM Notifications | <– Date –> <– Thread –> |
From: Uma Shankar Ch (umas intotoinc.com)
|
|
| Date: Thu, 19 Aug 2004 07:23:34 -0400 (EDT) | |
Contradicting/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 nround.
Pl. clarify.
-Uma Shankar K Ch
www.intoto.com
--------------------------------------------------------------------------------------------------
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 nround.
Pl. clarify.
-Uma Shankar K Ch
www.intoto.com
-
EAP-SIM Notifications Uma Shankar Ch, August 19 2004
-
EAP-SIM Notifications Uma Shankar Ch, August 21 2004
- RE: EAP-SIM Notifications Joseph Salowey, August 22 2004
- RE: EAP-SIM Notifications Uma Shankar Ch, August 23 2004
-
EAP-SIM Notifications Uma Shankar Ch, August 21 2004
Results generated by Tiger Technologies using MHonArc.