Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd)

[Paul Wouters <[e-mail]>]

On Mon, 26 Jan 2015, Tero Kivinen wrote:

> For the same reason IKE users who already do Diffie-Hellman during the
> IEK SA creation, might want to do separate PFS for different Child
> SAs, just to make things harder for attacker. Again as we are talking
> about un-authenticated connections, NSA can just do MitM in the
> beginning, and gain all traffic, but that is active attack, which
> might get detected. Doing passive storing of the all traffic and then
> breaking Diffie-Hellman later provides better ways of staying
> undetected for them.

But you are most likely initiating IKE because you were trying to send
one kind of protocol/port, so most likely you will end up with one SA.

If you do this for every port 80 connection that closes, and build up
new SA's for each random source port you use, then you're just causing
your user unneccessary delays while they are waiting on CREATE_CHILD_SA
exchanges. It is much better for the user to get one proper IPsec SA
in. If you are concerned about passive offline breakability, bump your
modp group to modp8192.

> If we do one 1024-bit Diffie-Hellman using un-authenticated exchange,
> then they  can break that one 1024-bit Diffie-Hellman and get all
> traffic protected by each Child SA. If we do PFS for each Child SA
> then they need first to break the IKE SA Diffie-Helman and then for
> each traffic flow second one...

It's better to make everything unbreakable by a higher modp group than
to hope that only part of your traffic got broken :P

> There are people who want this kind of feature.

Yes and people want to use different modp groups for IKE and IPsec SA, and
different PRFs from INTEGs, and different size GCM/CCM tags and different
SHA2 length. Those were all useless knobs we should have never created.

> Thats why this draft
> should not have any text restricting per-flow SAs...

I still have not seen a single valid use case for this. I do have
described how this feature would cause issues during active attacks.

> It might have comment saying that because clients are
> un-authenticated, there might be need for tighter resource limits than
> for authenticated clients.

And this new swiss army knife has the auto-rotating circular hack saw.
Please only use responsibly.

>> It will only cause interop failures. The client will not pick a
>> host-to-host but picks say port 80 only. Then it wants port 443 and
>> gets NO_ADDITIONAL_SAS. Then it needs to drop the port 80 SA and
>> restart everything to get the full range single SA.
>
> Why should that cause interop failures? This is all standard RFC7296
> stuff already. We are not changing anything here related to this.

Yes. Nothing should ever cause interop failures if everyone followed
the RFCs properly :P Welcome to the real world Neo :)

>> If you are not authenticated, what is the point in splitting up the
>> traffic in different IPsec SA's per protocol or port?
>
> Causing more work for the passive monitoring people breaking your
> multiple 1024-bit Diffie-Hellmans, instead of just breaking one.

That modp1024 is too weak! Use modp8192. That's much safer. What's
your next use case?

> And
> you might use shorter Diffe-Hellman groups for performance reasons
> than with authneticated use cases.

So 200 PFS CREATE_CHILD_SA requestions of 1024 is less resources than
1 modp8192 initial exchange?

>> The only use case I have heard of that could apply, is the use case
>> of being mandated to NOT encrypt something for auditing purposes. But
>> traffic selectors really suck for "everything but sip and smtp and pop
>> and imap" :P
>
> Yes, usually traffic selectors are either per IP, or per-flow.
> Anything else are usually just silly... And for most normal
> authenticated use cases per-flow SAs are not really that useful, but
> we still have them in RFC7296, and I do not see any reason why they
> should be removed in this document.

We are talking about two things here:

1) IP ranges
2) protocol and port ranges

1) is dangerous because unauthenticated peers cannot be trusted to make
    any claims about IPs that are not themselves.
2) we discussed in the previous email and above here :P

Paul