[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/>