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

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 <svanru@gmail.com> 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, <Paul_Koning@dell.com> wrote:
>
>>
>> On Sep 7, 2014, at 2:53 PM, Yaron Sheffer <yaronf.ietf@gmail.com> 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
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>  ------------------------------
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>