Subject: RE: [eap] Re: EAP silent discarding

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 21 Aug 2003 10:33:08 -0700

It doesn't seem like a good idea for EAP to selectively chose a mode of
operation based upon the lower layer's capabilities.  It is unnecessarily
complicating and restricting.   EAP should handle retransmission regardless.

Paul

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Thursday, August 21, 2003 9:30 AM
> To: Bernard Aboba
> Cc: Yoshihiro Ohba; [email-masked]
> Subject: [eap] Re: EAP silent discarding
> 
> 
> On Thu, Aug 21, 2003 at 05:42:48AM -0700, Bernard Aboba wrote:
> > 
> > 
> > On Wed, 20 Aug 2003, Yoshihiro Ohba wrote:
> > 
> > > The current RFC2284bis uses silent discard as a basis for error 
> > > handling (that is good).  I think the silent discarding 
> policy works 
> > > only when the EAP authenticator retransmits EAP Requests "at EAP 
> > > layer".
> > >
> > > For example, if EAP runs over a reliable lower-layer and thus the 
> > > authenticator disables EAP retransmission according to the 
> > > recommendation in section 4.3, there is some cases in 
> which silent 
> > > discarding makes EAP conversation stall, since the reliable 
> > > transport running at the lower-layer will not retransmit 
> a message 
> > > that has been successfully acknowledged and passed to the higher 
> > > layer protocol, i.e., EAP, for which retransmission is 
> disabled due 
> > > to the recommendation.
> > >
> > > EAP and lower-layer are not tightly coupled in most
> > > cases, and thus it is not appropriate to assume something 
> that EAP 
> > > can indicate the lower-layer to keep a copy of an acknowledged 
> > > message and to retransmit it when the message is silently 
> discarded 
> > > by EAP.
> > >
> > > So I think EAP layer retransmission is basically needed 
> regardless 
> > > of whether EAP runs over reliable transport or not.
> > >
> > > I maybe misunderstanding something, but if my observation 
> is correct 
> > > the following text in section section 4.3 needs to be revised:
> > >
> > >    "When run over a reliable lower layer (e.g., EAP over 
> ISAKMP/TCP, as
> > >    within [PIC]), the authenticator retransmission timer 
> SHOULD be set
> > >    to an infinite value, so that retransmissions do not 
> occur at the EAP
> > >    layer.  The peer may still maintain a timeout value so 
> as to avoid
> > >    waiting indefinitely for a Request."
> > >
> > >
> > > What do you think?
> > 
> > Let's look at a specific scenario to understand the issue:
> > 
> > EAP peer A is authenticating to Authenticator B.  Attacker 
> C is also 
> > sending EAP packets to Authenticator B.  Authenticator B is in 
> > "pass-through" mode with Authentication Server D.
> > 
> > To mount the attack, Attacker C is having to generate 
> packets with the 
> > correct Identifier as well as potentially the correct MIC. 
> > Authenticator B checks the Code, Identifier and Length fields and 
> > silently discards many of the packets.  Packets with 
> invalid MICs are 
> > silently discarded at AS D and Authenticator B then sends the next 
> > packet in the queue.
> > 
> > Occasionally the queue at Authenticator B may fill up and 
> as a result, 
> > a packet from EAP peer A may be dropped.  In EAP this is 
> addressed by 
> > retransmission from Authenticator B.  Presumably in such a 
> situation 
> > Authenticator B would not have sent an ACK within a 
> reliable transport 
> > either, so that for a reliable transport retransmission might occur 
> > from the peer side, with backoff.
> > 
> > It would appear to me that no stalls will occur if:
> > 
> > a. Neither peer nor authenticator send a transport ACK unless the 
> > packet is actually handed up to EAP for processing;
> > 
> > b. Neither peer nor authenticator is sending invalid EAP 
> packets (e.g. 
> > packets w/invalid Code, Identifier, Length or bad MICs)
> > 
> > Note that if b) is true then retransmission at any layer 
> will not help 
> > because the retransmitted packet will also be discarded.
> > 
> 
> My point is that we probably need additional condition:
> 
> c. Authenticator does EAP layer retransmission even if the
>    lower-layer does retransmission unless the lower-layer is secured.
> 
> Without c), an invalid EAP message sent from an attacker will 
> be processed as a valid message by the lower-layer and handed 
> up to the EAP layer, then EAP will found it invalid and 
> discard it.  Then the result would be that neither 
> lower-layer nor EAP will retransmit the outstanding message 
> which is needed for continuing the EAP conversation.  Of 
> course if the lower-layer is not only reliable but also 
> secure, this will not occur.
> 
> A protocol that employs silent discarding has the 
> responsibility to do retransmission.  In other words, silent 
> discarding and retransmission are closely related 
> functionalities.  The current EAP specification recommends an 
> option to disable EAP-layer retransmission when the 
> lower-layer provides reliability, but this will make silent 
> discarding and retransmission independent in many cases, 
> which I think we need more consideration.  
> 
> 
> Yoshihiro Ohba
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap