On Apr 10, 2023, at 12:20 PM, Karl Norrman <karl.norr...@ericsson.com> wrote: > [K]: What above made you believe I meant the clients authenticating via EAP?
You mentioned EAP session keys being compromised. That would tend to imply end users being affected. > 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. Organizations can do whatever they want inside of their closed garden. It's useful to give guidance for these situations, but ultimately the IETF standards are about public uses. > [K]: If PFS as such is relevant, I keep using the word *practical*. What practical impact does it have if the session keys are compromised? What are the practical costs for protecting against these attacks? I've seen a lot of theoretical arguments. I don't see much in the way of practical points of view. My contention is that there are few practical consequences to these attacks. And, that mitigations like quick re-keying of AAA sessions have practical costs which out-weigh the benefits. > [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. That's all well and good. What happens then? How is the user affected? The attacker who can monitor the IPSec traffic can likely also monitor all of the network traffic sent by the end user. In which case the MSK is irrelevant: the traffic is sent over wired Ethernet, unprotected by the MSK. Perhaps MACSec will help here. But at some point the traffic is either (a) unencrypted, in which case the attacker can see it. Or (b) encrypted, in which case an attacker compromising IPSec can also presumably crack that, too. This looks a lot to me like putting a $2000 lock on your front door, and leaving the window next to it open. These attacks are irrelevant because they have little practical consequences, and the attacker already has access to the same information, elsewhere in the network. > [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 did mean "people" to include "AAA operators". As an AAA operator, I don't see any practical thing I can do to protect myself, or the users authenticating via my AAA servers. "Use PFS methods" is a good step. Warning people of the limitations of PFS is a good step. Past that, I don't see any recommendations which I can implement. >> 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. I understand that. My point was that rekeying takes the attack from "compromises 10 minutes of traffic" to "compromises 10 seconds of traffic". It's better, but there's minimal long-term benefit. >> 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. Until that issue is fixed, solutions like re-keying are largely impractical. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
