Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol

[Yaron Sheffer <[e-mail]>]

Hi Hugo,

We know what to expect from IKEv2 with mutual certificate or PSK 
authentication.

I *think* we also know what IKEv2 provides when both sides are NOT 
authenticated. To summarize my own understanding: the IKE exchange and 
any resulting Child SAs are confidential (only encrypted payloads of 
course) and integrity protected, provided there was no MITM attacker at 
the time of the initial IKE exchange. If there was one, all bets are off.

The document is unclear about the security properties of the proposed 
1-way auth, but from the discussion, many people believe it is similar 
to TLS. I agree that a serious analysis of this option is called for.

The document's introduction does give the impression that the main point 
of this document is one-way auth, but I think most of the people who 
support this document are more interested in fully anonymous key 
exchange. So I would like to focus the WG adoption discussion right now 
on the anonymous use case, and then, if the WG decides to adopt the 
document, go back to the question you raised.

Thanks,
	Yaron

On 09/11/2014 07:01 AM, Hugo Krawczyk wrote:
> 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 <[e-mail]
> <mailto:[e-mail]>> 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, <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>
>             On Sep 7, 2014, at 2:53 PM, Yaron Sheffer
>             <[e-mail] <mailto:[e-mail]>> wrote:
>
>             > Dear working group,
>             >
>             > This is a call foradopting 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
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/ipsec
>
>
>         ------------------------------------------------------------------------
>
>         _______________________________________________
>         IPsec mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>