Okay Yoshi fair enough. But that is the most important
question to
answer.
Because if the answer is YES. Then it means that despite
the best
effort of EAP method designers, a man in the middle could
simply
re-order packets and get authenticated. If true, this has
got to be the
weak point of EAP. I don't think its true or I hope that
its not true.
The IETF will have egg on its face.
So the other part of my question on another thread is the
issue with the
contradiction in 3748
RFC 3748, section 3.1 says: [6] Ordering guarantees.
Lower layer transports for EAP MUST preserve ordering
between a
source and destination at a given priority level (the
ordering
guarantee provided by [IEEE-802]).
A little further down it says:
"It is RECOMMENDED that EAP only be run over lower
layers that provide
ordering guarantees; "
Isn't that a requirement contradiction of the previous
statement, or am
I missing something? Do you have any opinions on this?
-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba tari.toshiba.com]
Sent: Wednesday, March 07, 2007 4:05 PM
To: Avi Lior
Cc: Yoshihiro Ohba; Bernard Aboba; gwzcisco.com; alper.yeginyegin.org;
Pasi.Eronennokia.com; eapfrascone.com; radiusextops.ietf.org
Subject: 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: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
|
