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