eap Mailing List: RE: EAP-SIM Notifications

[Uma Shankar Ch (umas]

Hi,

> > [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:] Thanks for the reply. As you said, even though draft didn't
> mention  any thing other than 32768 Success Notify. But, as per rule
> (1) mentioned below any body can send a Notify message with code
> >32768, and peer  would be responding the same making the round
> trip to complete.
> As you suggested, if draft forces for only failure codes in
> notify before authenticated message begin, we can get away with this
> problem.
>
>
> Many Thanks,
> Uma
> www.intoto.com
>
>
> At 10:40 PM 8/22/04 -0700, you wrote:
>
>
> > 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