Hi! > From a practical point of view, I think PFS issues are less of a problem > than > other issues.
[K]: OK. I don't argue that PFS is important here. My point is just that those who *do* believe that PFS is important need to take care when using long-lived TLS/IPsec sessions. That is: 1. Assuming a system user wants PFS, the question is whether they get it by enabling PFS-enabled TLS cipher suites for RADIUS/DIAMETER and a PFS-enabled EAP method. Answer: not in the sense one may expect. 2. What trade-offs do they need to make? > Systems like Eduroam currently transport 2-5K full EAP sessions per second > for > national proxies, with 10+ packets per session. OpenRoaming systems have > similar or larger amounts of traffic. > > Which means that it is not realistically practical to re-key the AAA > connection > after every successful EAP authentication. Even re-keying the AAA connections > once a second is a lot to ask. [K]: Indeed. These long-lived sessions are exactly what make the attack on the MSK's PFS possible. > So what can be done here? What solutions should be implemented which are > practical, and which also increase security? [K]: As I wrote in the initial mail, one need to be aware of that one may not get PFS for the MSK until the next rekeying of the IPsec/TLS tunnel between the EAP server and the pass-through authenticator. So, one need to do a risk assessment and trade-off security/efficiency on how frequently one need to rekey. The trade-off means a more relaxed version of PFS. The important part IMO is that it is a conscious decision and trade-off. > I think this issue is more theoretical than practical. If someone can snoop > random AAA traffic, then either (a) they are a trusted member of the AAA > ecosystem, or (b) they have nation-state level access to network traffic. > There are few practical defences against either of those attacks. [K]: There are more possibilities than (a) and (b). The threat situation depends on the deployments and adversaries one considers. For example, an adversary may have access to traffic passing to a number of WiFi access points in a certain area of importance. The area may be strategically important so that anyone passing by is an interesting attack target, or specific targets may be likely to move through the area. > For me, this issue falls into the same area as "my front door lock is > insecure, > because the lock-picking lawyer can pick it in 30 seconds". Well, $2000 for > a > perfect front door lock is impractical, because the determined adversary will > simply throw a rock through a side window, and bypass the lock entirely. > > To put it another way, the theoretical attacks are much less interesting > than > the practical attacks. And the defences against theoretical attacks are not > interesting if the defences are entirely impractical. [K]: It could be argued whether PFS as such is such a feature, yes. It depends on whom you ask and what their threat model is, whether PFS is a theoretical threat or not. However, for anyone who wants PFS, then the attack I described seems a worry. Recall: PFS here roughly means that an MSK generated and used in a certain session should be secure in the future if the long-term secret is then compromised. *If* that is a worry, then one should be almost equally worried about compromise of the TLS/IPsec session state, which may even reside in the same physical server as the long-term secret. One may even view the TLS/IPsec session state as part of the long-term secret. > What solutions can be implemented here? What recommendations can we > make which are both practical, and secure? [K]: 1. Make the system-level issue known so that those who do care about PFS can make an informed decision and risk-based security policy when designing their systems. 2. Recommend to make a risk assessment and trade-off between how long time after the session using MSK should achieve PFS and rekey the TLS/IPsec tunnel accordingly. Several EAP RFCs mention, and even recommends PFS, e.g., Section 4.2 of RFC6421. If my attack is correct, such recommendations may give the incorrect impression that one gets PFS immediately, e.g., by using PFS-enabled TLS cipher suites and a PFS-enabled EAP method. BR Karl > > Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
