[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [eap] Ordered delivery of EAP messages



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.


-----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 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/>