Re: [eap] Ordered delivery of EAP messages

[Yoshihiro Ohba <yohba@tari.toshiba.com>]

On Wed, Mar 07, 2007 at 11:40:39AM -0500, Avi Lior wrote:
> Bernard,
> 
> You said: 
> 
> "So overall, I don't think that the majority of EAP methods deployed
> today are capable of handling arbitrary reordering."
> 
> Okay, but what is the result when this occurs, would this result in an
> Unauthenticateable user to be Authenticated?
> 
> If NOT, then EAP Methods do not require in order delivery by the
> underlying transport(s) to give results that are secure.
> 
> In order delivery is desirable for optimal performance -- an
> Authenticateble user getting authenticated without having to retry the
> method.

Orderly delivery is required for authenticable user to be
authenticated.  Without orderly delivery, authentication for
authenticable user can fail even if (i) EAP and lower layer are doing
their jobs correctly as specified in their specifications, (ii) valid
credentials are being used and (iii) there is no attacking.  From
operational perspective, this is something that should not happen, IMO.

Yoshihiro Ohba


> 
> 
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
> Sent: Tuesday, March 06, 2007 11:43 PM
> To: Avi Lior; gwz@cisco.com; alper.yegin@yegin.org;
> Pasi.Eronen@nokia.com; eap@frascone.com
> Cc: radiusext@ops.ietf.org
> Subject: RE: [eap] Ordered delivery of EAP messages
> 
> Avi Lior said:
> 
> "If an EAP method designer designed their method assuming the in order
> delivery of packets then this would be a bad thing I think.
> 
> A hacker could then exploit this assumption by re-order the packets.
> Surely EAP methods are not susceptible to this type of attack. Right?"
> 
> Certainly, it is a good thing for an EAP method to protect itself
> against replay.  Using the mechanism provided in RFC 3579, an EAP method
> could discard replayed packets and ask the NAS to send another one.
> 
> On the other hand, there are EAP methods that are not protected against
> replay (e.g. Identity, Notification, etc.).  There are also situations
> in which EAP packets can be fragmented, and if reassembled in the wrong
> order, this could cause failure of the MIC which can be a terminal error
> (e.g. in TLS-based methods).
> 
> So overall, I don't think that the majority of EAP methods deployed
> today are capable of handling arbitrary reordering.
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>