On Apr 10, 2023, at 4:54 AM, Karl Norrman <karl.norr...@ericsson.com> wrote: > [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?
People authenticating via EAP have no control over the AAA infrastructure. So they have very few choices for making trade-offs. > [K]: Indeed. These long-lived sessions are exactly what make the attack on > the MSK's PFS possible. I would suggest that these attacks aren't very relevant. Or if they are, there is very little which can be done about them. > [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. In some cases the AAA operators have control over the EAP methods used, (3G/4G/etc. and universities). In other cases (proxying) the AAA operators are themselves perhaps untrusted by the end users. I agree that PFS is good, but I'm not sure what anyone can do about the attacks outlined here. > [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. i.e. someone operating the AAA servers? Or the people operating the local network, who are usually the same people operating the AAA servers. Or someone watching the radio-layer traffic. Which are the attacks I suggested earlier. I'm not sure there are many different ones. > [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. What is this person going to do about it? Lobby the AAA operators to re-key their sessions more often? I'm struggling to find practical steps that people can take here. > [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. Raising awareness is good. But again, what can the average user of EAP do about this? Or the average AAA operator? I don't see many defences here. PFS only helps protect the current session, and prevents using the current session to attack past / future sessions. PFS offers minimal additional protection from a nation-state adversary who can simply record all of the traffic. Rekeying every second or every day makes little difference here. The only difference between rekeying intervals is the number of user authentications which can be compromised per AAA session being cracked. And if an adversary has those resources, it's probably much simpler to just attack the network directly. Everything has buffer overflows, zero-day attacks, etc. Just log into the AP, and steal all of the keys as they flow through it. > 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. What advice do you have for AAA operators? How often should the sessions be rekeyed? What impact will this have on AAA operations? Every time an AAA connection drops, there is a chance that the EAP sessions transported over it will simply fail. This is because proxying and fail-over are poorly defined in RADIUS. There is the possibility that all EAP sessions using a particular connection will simply fail. So the increased security has the potential to also increase the number of failed authentications. Which means in order to fully support small lifetime for AAA connections, we need to first ensure that the AAA system is robust to such small lifetime connections. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
