>>>>> "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
