I have been looking at TEAP and am worried about silent discarding of packets.
Since in the ABFAB environment, it is assumed that the transport is reliable, there is a possibility that a difference of opinion about what constitutes a good packet between the server and the client could cause a dead-lock situation in the protocol. For TEAP, it says that you silently discard if the flags are wrong, but if the server and the client disagree if the EAP length field should be present then the server will discard and the client will wait forever for a response. Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Yoshihiro Ohba > Sent: Wednesday, October 24, 2012 5:37 AM > To: Sam Hartman > Cc: [email protected] > Subject: Re: [abfab] EAP Applicability: retransmissions > > Sam, > > EAP-IKEv2 supports silent discarsion. > > Yoshihiro Ohba > > > (2012/10/24 20:02), Sam Hartman wrote: > >>>>>> "Yoshihiro" == Yoshihiro Ohba <[email protected]> > writes: > > Yoshihiro> There are two separate issues here. First, Regardless > > Yoshihiro> whether lower-layer provides reliabilty or not, I believe > > Yoshihiro> EAP-layer retransmissions can improve robustness against > > Yoshihiro> DoS attack by sending malformed EAP requests, which > > Yoshihiro> otherwise can stall the EAP conversation. EAP-layer > > Yoshihiro> retransmission is not needed if the lower-layer provides > > Yoshihiro> secure reliable transport of EAP, such as IKEv2. I am > > Yoshihiro> not an expert of GSS-API, but it would have been better > > Yoshihiro> if EAP-layer retrasnmissions were allowed in GSS-EAP. > > > > We both agree that a reliable lower layer needs to be sufficient to deal > > with network problems. > > > > As I understand it, we're exploring the case where retransmissions > > would deal with an attacker. > > So, I think what you're saying is that if an implementation performs a > > retransmit when it gets a malicious packet, it can be more robust. > > > > We're presumably talking about an attacker that can insert packets but > > not modify them or suppress them. > > An attacker who can modify or suppress packets can fairly clearly DOS > > the EAP conversation. > > If nothing else, they can simply make sure the packet is always > > corrupted. > > > > For this to be valuable there need to be EAP methods that are robust > > under EAP-layer retransmission but not other higher-layer > > retransmission. > > It's not good enough for EAP layer retransmissions to help with some > > packets in a method if it doesn't help with others. If there's some > > packet an attacker can easily send that will break the conversation, > > the method is not robust under EAP layer transmission. > > For example it wouldn't be particularly valuable if EAP layer > > retransmission protects against garbled packets but not packets with > > unknown critical options added, because an attacker could easily add > > an unknown critical option. > > > > I then started to consider the existing EAP methods. > > I am not able to think of an EAP method that is robust under EAP layer > > retransmission. I think you can fairly consistently break an EAP > > conversation by inserting packets. > > The most obvious thing to try is an EAP failure packet, then an EAP > > NACK. > > I also quickly considered methods like GPSK and TLS-based methods, and > > am fairly sure those are not robust either. > > So, would you be willing to pick an EAP method that is robust and go > > through a fairly detailed argument about how insertion DOS attacks are > > avoided? > > > > > > > > Yoshihiro> Second, Regarding peer-initiated lower-layer > > Yoshihiro> retransmission, it is characterized by authenticator > > Yoshihiro> lower-layer to retransmit an EAP request based on an > > Yoshihiro> external event of receiving a peer-initiated duplicate > > Yoshihiro> request, instead of use of an internal timer event. This > > Yoshihiro> means that if the peer lower-layer receives a lower-layer > > Yoshihiro> response carrying an EAP request (so the corresponding > > Yoshihiro> lower-layer request is no longer outstanding) and the EAP > > Yoshihiro> request is discarded by EAP peer layer for some reason, > > Yoshihiro> then the peer lower-layer will not retransmit the > > Yoshihiro> lower-layer request to serve as the external event for > > Yoshihiro> the authenticator lower-layer to retransmit the EAP > > Yoshihiro> request. As a result, if my understanding is correct, the > > Yoshihiro> EAP conversation will stall unless there is some > > Yoshihiro> additional mechanism that can keep the EAP conversation > > Yoshihiro> going. The issue is more significant for insecure > > Yoshihiro> lower-layers where attackers can inject malformed EAP > > Yoshihiro> requests. The issue is less significant for secure > > Yoshihiro> lower-layers such as IKEv2. I agree that this issue is > > Yoshihiro> complex. Note that PANA does not have this issue because > > Yoshihiro> it is based on authenticator-initiated lower layer > > Yoshihiro> retransmission. > > > > It's absolutely true that if a peer discards an EAP request in such a > > scheme, the conversation stalls. > > If you're introducing that into an application, that would decrease > > robustness. > > There are a lot of TCP applications though where it is a violation of > > a protocol to discard a message. LDAP clients do not just get to > > ignore a SASL challenge or any other non-authentication protocol message. > > If an IMAP client ignores the capability response (happens before > > authentication), things will stall. > > If your application already depends on people not discarding > > responses, depending on that for authentication is fine. > > > > I think more or less all of our security layers are vulnerable to DOS > > attacks from people inserting or modifying their negotiations. > > The only thing I can think of that clearly does not have this > > vulnerability is statically keyed TCP-AO or IPSec. > > I'm fairly sure very little of anything we standardize gives the > > robustness you're looking for. > > > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
