Valery Smyslov writes: > after reading the paper I still don’t understand why authors > mentioned IKEv2 there.
Of course they mention, just to get more exposure... > Their example attack in Section 4.4 on (allegedly) IKEv2 in fact > uses secondary responder supporting IKEv1 Public Key Encryption > mode, without which the attack is impossible (as far as I > understand). So, in my opinion, the authors are at least not > accurate in claiming that IKEv2 itself is susceptible. Or am I > missing something? That is my understanding also. On the other hand breaking signature method of the IKEv2 using IKEv1 oracle for the same RSA key is quite clever, and just points out that we must not use same key pair with different protocols / modes etc. We had this dicussion in when writing RFC8247 and recommending RFC7427 Digital Signatures using RSASSA-PSS. Some implementors used same key pair for both RSASSA-PKCS1-v1_5 and RSASSA-PSS. This paper just points you that you must not do that kind of things. The text about the IKEv2 pre-shared keys is just already known fact, and the RFC7296 warns about that several times, i.e., it does say use EAP for those, and for EAP you should not use the weak EAP methods, but instead you should use key generating methods. Also because it is known fact that IKEv2 shared secret authentication is vulnerable to the off-line dictionary attacks, we created RFC6467 for secure password methods. I.e., PACE (RFC6631), AugPAKE (RFC6628), abd Secure PSK Authentication (RFC6617) should all be protected against offline dictionary attacks. Anyways, I think proper fix would be to disable IKEv1 support completely, not to just disable RSA encryption mode... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
