---------- Forwarded message ----------
Date: Wed, 15 Nov 2023 09:12:17
From: Paul Wouters via Devel <[email protected]>
Cc: [email protected]
To: Andrew Cagney <[email protected]>
Subject: Re: [devel-ipsec] Fwd: Strange IPSEC traffic
On Tue, 14 Nov 2023, Andrew Cagney via Devel wrote:
Subject: Re: [devel-ipsec] Fwd: Strange IPSEC traffic
The paper attacks the IKE_SA_INIT + IKE_AUTH exchange.
On Mon, 13 Nov 2023 at 20:51, Dave Taht via Devel <[email protected]>
wrote:
We are seeing a new ipsec attack in the wild. I am curious if there
are any additional defenses against it. More details are on the nanog
thread here:
https://mailman.nanog.org/pipermail/nanog/2023-November/224003.html
The paper link is https://eprint.iacr.org/2023/1711.pdf
I find the paper.... odd. It says things like:
Thus an adversary who obtains the secret signing key for only one side
of the connection may be able to cryptographically impersonate that
host.
But why would any faulty RSA signature be needed in this case? If you
steal the private key, yeah game over? If you don't have the
private key and need to see the signatures to find a "faulty signature"
to somehow compute the private key from this, you need to see the
signature but in IKEv1 Main Mode and IKEv2 (including EAP!) these do not appear
unencrypted on the wire. It then mumbles about EAP where it would appear
in the clear, but the authors clearly misread the RFC:
HDR, SK {IDi, [CERTREQ,]
[IDr,] SAi2,
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
EAP}
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr}
Here everything withing {} is encrypted to the DH, so all AUTH payloads
are encrypted. So EAP is not affected differently from non-EAP IKEv2
exchanges for passive attacks. For active attacks, yes they can get
the AUTH payload unencrypted. I suspect the authors misread the Appendix
C, which does not indicate which payloads are encrypted.
( https://datatracker.ietf.org/doc/html/rfc7296#appendix-C.3 )
But also note that only IKEv2's legacy Authentication Method (value 1) uses
RSA PKCS#v1.5, where as Authentication Method Digitial Signaures (value
14) uses RSASSA-PSS (see RFC 8247, Section 3.2)
Findings from the paper as I can see related to IKE/IPsec:
1) For IKEv1, 6M hosts were scanned obtaining 0 private RSA keys.
2) For IKEv2 8.5M hosts were scanned obtaining 0 private RSA keys (I
assume, the authors forgot to actually state it clearly in the document)
3) 8800 (16%) of PSK based authentications could be broken with the rockyou
wordlist. This _is_ pretty sad.
What I take from this:
- Maybe look at a new EAP method to prevent AUTH payload from the server to be
send before client is authenticated.
- Implementations MUST reject weak PSKs that are easy to detect.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
