Re: Ordered delivery of EAP messages

Yoshihiro Ohba <mailto:yohbatari.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:yohbatari.toshiba.com]
>> Sent: Wednesday, March 07, 2007 2:43 PM
>> To: Avi Lior
>> Cc: Bernard Aboba; gwzcisco.com; alper.yeginyegin.org;
>> Pasi.Eronennokia.com; eapfrascone.com; radiusextops.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_abobahotmail.com]
>>> Sent: Tuesday, March 06, 2007 11:43 PM
>>> To: Avi Lior; gwzcisco.com; alper.yeginyegin.org;
>>> Pasi.Eronennokia.com; eapfrascone.com
>>> Cc: radiusextops.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 or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap