I didn't know (or remember) that IKEv2 allows for different directional authentication mechanisms. In any case, as a general rule, the fact that two methods are secure, doesn't mean that mix-and-match-ing them (or taking a subset) is still secure. Particularly for IKEv2, I do not know of any work that has shown such security.
Hugo On Tue, Sep 9, 2014 at 7:58 AM, Valery Smyslov <[email protected]> wrote: > Hi Hugo, > > The subject line (and the comment on Bellovin attack) caught my eye. I > don't follow the discussions in this list so I don't know how much the need > and dangers of unauthenticated methods were discussed here. I want to point > out that (and probably many did before me) that un-authentication is a very > tricky option especially in a protocol that was created with mutual > authentication as a core requirement and assumption. I can see potential > benefits and uses but I can also see it abused and misused (the internet > draft doesn't do too good a job warning about it but even if it did, people > will misuse it). > > I agree that the draft's Security Consideration section in its current > form is incomplete. > And I hope that if the draft is adopted then it will draw an attention of > many people, > who will help to improve the Security Considerations to list all the > caveats, > to make all possible warning and to give advice how to safely use this > mode. > > But requirements aside, I cannot vow for the security of IKE's key > exchange in a one-way authentication mode. No one (that I know, definitely > not me) designed this protocol to support one-way authentication. So the > question of whether it is secure in this setting has not been investigated. > Moreover, I see that the draft uses shared-key fields for theanonymous side > of the communication and, I imagine, the other can use signature-based > authentication. What security properties do you get from that mix-and-match > authentication methods? > > IKEv2 currently allows the peers to use different authentication methods. > So, if one of the peers uses preshared key, while the other uses > digital signature, then it is considered legal and secure from > protocol's design point of view. If the peer, using preshared key in this > scenario, > uses key, known to everyone, then we will get one-way authentication > with the current IKEv2. The next step, that the draft does - get rid of > well-known preshared key and compute the content of the AUTH Payload > the same way it is computed currently in IKEv2 when it is used > with non key generating EAP methods - using SK_pi (or SK_Pr) as the key > I believe the draft doesn't change the way cryptography is used in IKEv2. > > One likely misuse of this technique is that people will use > unauthenticated (or one-way) IKE and will run some other authentication on > top of it (say, password based or whatever). Well, protocols do not > necessarily compose securely. TLS had many failures like that (BEAST, > re-negotiation, triple handshake, ...) and IPsec saw examples of that in > the combinations of unauthenticated ESP and AH. IKE's cryptographic design > has endured the test of time but these variations (or improvisations) > endanger it. > > Well, sometimes mutual authentication is impossible or undesirable. > Sometimes privacy is more important and people are ready to > sacrifice some level of security to keep their privacy. > And sometimes the choice is - either use plaintext > or unauthenticated encryption. The latter at least > prevents passive eavesdropping... > > Finally, since Bellovin's attack was mentioned, I want to make sure that > no one is thinking of not using the MAC authentication at the IP packet > level, right? > > Absolutely. > > Hugo > > Regards, > Valery Smyslov. > > On Mon, Sep 8, 2014 at 10:54 AM, <[email protected]> wrote: > >> >> On Sep 7, 2014, at 2:53 PM, Yaron Sheffer <[email protected]> wrote: >> >> > Dear working group, >> > >> > This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a >> WG document. Please respond to this mail with a Yes or No and a short >> rationale, at latest by Friday Sep. 12. >> >> Maybe. >> >> I understand and support the rationale for this draft. >> >> The Security Considerations seems to be inadequate. Whenever possible, >> real authentication should be used. So the Security Considerations should >> explicitly and strongly emphasize that, and recommend that products that >> incorporate Null authentication should strive to avoid its use whenever >> possible, and steer users away from its use when they can. >> >> A related question: does the use of Null authentication open up the >> Bellovin attack? It seems that it would. If so, my answer changes to “NO”. >> >> paul >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >> > > ------------------------------ > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
