eap Mailing List: Re: Ordered delivery of EAP messages

[Glen Zorn (gwz) (gwz]

Yoshihiro Ohba <mailto:yohba [at] tari.toshiba.com> allegedly scribbled on
Wednesday, March 07, 2007 1:05 PM:
...
>> 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.  

Just to be clear, we're talking about EAP packets here, not IP packets.

> 
> Yoshihiro Ohba
> 
> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: Yoshihiro Ohba [mailto:yohba [at] tari.toshiba.com]
>> Sent: Wednesday, March 07, 2007 2:43 PM
>> To: Avi Lior
>> Cc: Bernard Aboba; gwz [at] cisco.com; alper.yegin [at] yegin.org;
>> Pasi.Eronen [at] nokia.com; eap [at] frascone.com; radiusext [at] 
>> 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 [at] hotmail.com]
>>> Sent: Tuesday, March 06, 2007 11:43 PM
>>> To: Avi Lior; gwz [at] cisco.com; alper.yegin [at] yegin.org;
>>> Pasi.Eronen [at] nokia.com; eap [at] frascone.com
>>> Cc: radiusext [at] 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