On Oct 24, 2012, at 2:02 PM, 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.
Sam, Correction to your statement above: We are talking about the necessity of EAP-layer or EAP lower-layer server-side re-transmission being necessary. You are proposing getting by with client-side re-transmissions. > 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. Nope. A random EAP payload to your EAP-o-PCP method that is sent from the server side can totally stall your solution. EAP layer or the EAP method layer on the client will discard that message. But since your EAP-o-PCP on the client side thinks it happily got a response to its earlier request, it'll sit there by itself. The discarded message won't generate a response from the EAP layer or EAP method layer on the client, so nothing will tell the EAP-o-PCP to send its next request. This situation does not happen to server-driven rexmits, as the server would rexmit the request if it does not receive a response. A random packet injected cannot stall the flow. > The most obvious thing to try is an EAP failure packet, then an EAP > NACK. From 3748: A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an authenticator receiving an unexpected Nak SHOULD discard it and log the event. ... Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not explicitly permitted MUST silently discard it. Alper > 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
