RE: [eap] Ordered delivery of EAP messages

["Avi Lior" <avi@bridgewatersystems.com>]

As a follow on to my previous email message

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?  

-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com] 
Sent: Tuesday, March 06, 2007 9:14 PM
To: Glen Zorn (gwz); Alper Yegin; Bernard Aboba; Pasi.Eronen@nokia.com;
eap@frascone.com
Cc: radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

Unless I am missing something most of the converstaion so far has been
related to efficiency.  That is, if the transport layer provides inorder
delivery the EAP works well.

I think we need to answer this question first:

Does EAP require to have inorder delivery to work correctly.  By work
correctly I mean that it does not falsely authenticate someone.

Can someone show how EAP falsely authenticate someone if packets arrive
in arbitrary order.


If this cant be shown the inorder delivery is not a MUST but a nice to
have feature of the transport layer and the statement in the RFC should
be changed from a MUST to a SHOULD.
 

-----Original Message-----
From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
Sent: Tuesday, March 06, 2007 6:45 PM
To: Alper Yegin; Bernard Aboba; Pasi.Eronen@nokia.com; eap@frascone.com
Cc: radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

Alper Yegin <mailto:alper.yegin@yegin.org> allegedly scribbled on
Tuesday, March 06, 2007 10:10 AM:

> The problem scenario requires EAP-layer retransmission, correct?

Yes, I suppose so.

> Authentication server does not perform such retransmission. 

>From the Abstract to RFC 3748 "EAP provides its own support for
duplicate elimination and retransmission..."; the Authenticator is
responsible for all retransmission.

> So, I
> don't see equivalence between the two legs of the EAP transport. 

You are imagining that there are always 2 legs, which is not true; the
quoted portion of RFC 3748 does not state that assumption, either.  But
actually, you are right: it appears that RADIUS would generally be in
far greater peril of the risk then EAP, especially in a proxied network.

> 
> Alper
> 
>> -----Original Message-----
>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>> Sent: Tuesday, March 06, 2007 4:35 PM
>> To: gwz@cisco.com; Pasi.Eronen@nokia.com; eap@frascone.com
>> Cc: radiusext@ops.ietf.org
>> Subject: Re: [eap] Ordered delivery of EAP messages
>> 
>> Glen Zorn said:
>> 
>> "There are a couple of problems with this statement that I think are 
>> pertinent to the question at hand.  First, RADIUS is a "lockstep"
>> protocol in almost (if not exactly) the same way that EAP is: the 
>> semantics of the Identifier field in the header of RADIUS messages 
>> are identical to that of the EAP version (RFC 2865 only says that the

>> Identifier must change on new requests, not how it must change -- in 
>> particular, monotonicity is not
>> assured) and requests are retransmitted.  The other problem is that 
>> neither RADIUS nor the underlying UDP transport guarantees in-order 
>> delivery of packets.  So, I would claim that this sentence is 
>> completely false."
>> 
>> I think you are correct.  If the RADIUS retransmission timer were 
>> under-estimated, RADIUS can deliver EAP messages out of order.  That
>>   is, the NAS could retransmit an Access-Request, and then could 
>> receive an Access-Challenge in response to an earlier Access-Request.

>> The NAS would then send a new Access-Request, which could cross paths

>> with the retransmitted one.
>> 
>> Note that if an Event-Timestamp attribute were to be included in the 
>> RADIUS Access-Request, then the Identifier would change on the 
>> retransmitted Access-Request.  The NAS would then be able to 
>> determine that a False Retransmission (FRTO) had occurred.  But from 
>> the point of view of the RADIUS server, I don't think it matters, 
>> since it won't be checking that the Event-Timestamp attribute is 
>> monotonically increasing.
>> 
>> 
>> _________________________________________________________________
>> 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
_________________________________________________________________
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/>