RE: [eap] Ordered delivery of EAP messages

["Avi Lior" <avi@bridgewatersystems.com>]

Okay Yoshi fair enough.  But that is the most important question to
answer.

Because if the answer is YES.  Then it means that despite the best
effort of EAP method designers, a man in the middle could simply
re-order packets and get authenticated.  If true, this has got to be the
weak point of EAP.  I don't think its true or I hope that its not true.
The IETF will have egg on its face.

So the other part of my question on another thread is the issue with the
contradiction in 3748

RFC 3748, section 3.1 says: [6] Ordering guarantees.  

Lower layer transports for EAP MUST preserve ordering between a 
       source and destination at a given priority level (the ordering 
       guarantee provided by [IEEE-802]). 

A little further down it says:

"It is RECOMMENDED that EAP only be run over lower layers that provide
ordering guarantees; "

Isn't that a requirement contradiction of the previous statement, or am
I missing something? Do you have any opinions on this?



 

-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
Sent: Wednesday, March 07, 2007 4:05 PM
To: Avi Lior
Cc: Yoshihiro Ohba; Bernard Aboba; gwz@cisco.com; alper.yegin@yegin.org;
Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

Hi Avi,

On Wed, Mar 07, 2007 at 03:41:31PM -0500, Avi Lior wrote:
> Hi Yoshi
> 
> Very good so an authenticatble user will not be authenticated.
> Understood.
> 
> But you didn't answer the first part -- which is the key part.  If you

> had unordered delivery of packets, could an unAuthenticatble user be 
> authenticated?

I have been thinking about this, and so far I have not found an example
case of unauthenticatble user be authenticated when misordering happens.
The answer is "I don't know."

> 
> If the answer to this question is NO, then EAP does not require in 
> order delivery of packets and RFC 3748 has an error.

I am not sure what makes you conclude like this.  I don't want my
authentication attempt to fail just because IP packets are arriving out
of order.

Yoshihiro Ohba


> 
> 
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Wednesday, March 07, 2007 2:43 PM
> To: Avi Lior
> Cc: Bernard Aboba; gwz@cisco.com; alper.yegin@yegin.org; 
> Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
> Subject: Re: [eap] Ordered delivery of EAP messages
> 
> 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/>