Why aren't these IKEv1 implementation defending against Bleichenbacher by hiding the nature of error (decryption error or authentication error) like what TLS 1.2 does [1]? Is this option documented in any of the IPsec/IKE documents? Is there a reason why it would not work in IKEv1 as it worked for TLS?
[1] RFC 5246 Sec 7.4.7.1 Hugo On Tue, Aug 14, 2018 at 2:16 PM, Tero Kivinen <[email protected]> wrote: > 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 >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
