Hi! > > [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]: What above made you believe I meant the clients authenticating via EAP? I mean that the organization(s) deploying EAP and the authentication infrastructure and who are interested in authenticating clients can have a choice in how they design their networks. > > [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. [K]: If PFS as such is relevant, one need to consider how the adversary may get hold of the long-term key. One such attack is that the adversary compromises the authentication server. Then, as I said earlier, it is not contrived to believe that the adversary also gets hold of the TLS session keys. From this perspective I don't understand why you suggest the attack as irrelevant. If you find PFS irrelevant, then I understand that the attacks do not make things worse. > Or if they are, there is > very little which can be done about them. [K]: I can only repeat what I wrote earlier. It depends on the scale of the network and which risks the organization deploying it is ready to take. > 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. [K]: In what sense do you mean untrusted? If the end user doesn’t trust that the other party will keep the session key secret, then the value of the entire process seems limited. The PFS would not provide much value either and then these attacks are of course not of interest. So, in this specific case I agree that they are not very relevant. > I agree that PFS is good, but I'm not sure what anyone can do about the > attacks > outlined here. [K]: I will suggest the recommendations I mentioned earlier to the EAP-AKA'-FS draft then. This way the concerns will be documented for other use cases where PFS may be of interest. > > > [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]: I have described only one. I also gave a concrete example, which may have caused confusion. I will try to describe it again in clearer terms, but shorter. Point 2 answers the direct question. 1. There is an EAP server S and a pass-through authenticator A. For simplicity, say they are operated by a single honest organization, which the client trusts. S and A protect the traffic sent between them using IPsec. 2. An adversary listens to the IPsec encrypted traffic sent between S and A. The adversary cannot decrypt the traffic, but records the encrypted traffic anyway. (This is who and what I meant by having access to the traffic). 3. After a successful EAP authentication between a client and S, S will send the established MSK to A over the IPsec tunnel. 4. The adversary records the (encrypted) MSK. But at this point the adversary cannot decrypt the MSK. 5. The MSK is used to protect a session. The session terminates. If one cares about PFS, the MSK and any data from which it can be derived shall be deleted when the session terminates. Otherwise, the MSK would not be forward secret. 6. If one cares about PFS, then one would worry that the adversary would hack into the server S, obtain the IPsec session keys and decrypt the encrypted MSK from step 4. > > [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]: This seems to be a misunderstanding that the choice would be up to the end users. The AAA operators are the ones who would be best positioned to do this. > 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. [K]: No, that is session key independence. PFS roughly translates to that the session key remains secure in the future even if the long-term key/endpoint is compromised. > 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. [K]: I don’t understand the attack here. The rekeying is to prevent an adversary that compromises the endpoint from getting hold of the MSK. >The only difference between rekeying intervals is the > number of user authentications which can be compromised per AAA session > being cracked. [K]: That is not how I see it. Ones the IPsec session is rekeyed, all previously sent MSKs will be secure even if the server is compromised the current IPsec session state becomes available to the adversary. > 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. [K]: Yes, this is exactly the type of attacks that are of concern here. > What advice do you have for AAA operators? How often should the sessions be > rekeyed? What impact will this have on AAA operations? [K]: As I wrote, exact values need to come from a risk assessment for the particular use case and deployment. > 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. [K]: That seems to be a problem that needs to be taken into account. BR Karl > > Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
