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

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> >> I think it is a server's policy issue. It can always restrict
> >> the number of IPsec SAs from a single peer
> >> by using NO_ADDITIONAL_SAS notification.
> >> The document should not impose any restrictions here, IMHO.
> >
> > Agree. Implementations might also have different limits depending
> > whether the other end is authenticated or unauthenticated, i.e.
> > unauthenticated clients might only be able to create for example 10
> > Child SAs, and authenticated clients can create 1000 Child SAs... And
> > btw child SAs are quite cheap, so the limit does not need to be 1 and
> > 3... :)
> 
> But what's the point? Just to protect th per-port IPsec SA's with
> more PFS in CREATE_CHILD_SA ?

For some reason people wnat to turn on PFS on TLS, so that NSA cannot
break all the http-connections by just stealing that one key from the
server.

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.

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...

There are people who want this kind of feature. Thats why this draft
should not have any text restricting per-flow SAs...

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

> 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.

> 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. And
you might use shorter Diffe-Hellman groups for performance reasons
than with authneticated use cases.

> 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.

The most common use cases for per-flow SAs is when you have multiuser
system where different users use different IKE SAs and per-flow SAs. I
have not really seen those used that much lately...
-- 
[e-mail]