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
