Re: 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

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

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