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

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Jan 2015 11:39:41 -0500 (EST)

(seems previous message was lost)

>> https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth

So since the WGLC came onto us a little early, the document authors
still have some different opinions about some of this. So let me raise
those in the WGLC :)

INITIAL_CONTACT

Section 2.3 tries to address the problem of not being able to trust
INITIAL_CONTACT. Normally this payload is only honoured after
authentication, but we don't have a real authentication here, and one
anonymous IKE SA should not be allowed to obsolete another IKE SA.

Valery suggests sending liveness checks to all IKE SA's that used
AUTH_NONE.

I suggested sending liveness checks only to those IKE SA's that used
the same IP address, thus limiting the scope to a more likely pool
of possible orphaned SA's by a remote that crashed/restarted.

Of course, implementations can be smart, and skip liveness checks for
those IKE SA's whose IPsec SA is showing traffic now in in the very
recent past.

We need to consider the harm of leaving orphaned SA's versus the harm
of being tricked into sending too many liveness probes.

And in general, we need to ensure one IKE SA isn't sending a zillion
useless IKE messages - as we've lost the protection of a real
authentication to punish abusers by locking them out. (if you thought
ddos-puzzles were interesting, come tackle this problem :)

Traffic Selectors

We touched a bit on the traffic selector problem. If a peer is able
to pick its own address, it could attempt to steal traffic (say 8.8.8.8)
from the server. We advise people to isolate these peers. We cannot
fully disallow this because we need NAT-traversal support. Valery
preferred server assigned IP addresses (using CP) which will work great
in the "sensor network" but would cause overlapping problems with IKE
peers that talk to multiple peers that hand out their own range of
addresses. And opens up the reverse attack of the server stealing the
client's 8.8.8.8 traffic. Some more discussion and insights on this
would be useful.

Additionally, if we allow some kind of narrowed traffic selector,
malicious IKE peers would only need their one IP and could setup
(protocol * sport * dport) IPsec SAs. Or a variant of this could
be done with when allowing CREATE_CHILD_SA to setup a plethora of
IPsec SAs. Restrictions based on IP address is hard, again because
of the NAT support problem.

What we tried to do with the security consideration section is to keep
advise generic. Then specific opportunistic IPsec related issues could
find themselves in a soon to be draft-ipsec-opportunistic document.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 14 Jan 2015 11:32:39 +0300

Some clarifications below.

> of possible orphaned SA's by a remote that crashed/restarted.

I don't think that restricting liveness checks in this case to the same 
IP address covers all the situations. The peer may crash,
reboot and get new IP from its ISP and then create new IKE SA.
In this situation (very common, not?) the proposed restriction
will prevent the server from finding that old stale SA and it will continue
to consume resources untill the server decides to send smth.
over it or to check its liveness based on a long period of its
inactivity or until its lifetime is over.

I don't think that the document should impose such a restriction,
but instead it should give some guidance of how implementation
should behave in this situation. 

To clarify my position: I don't propose that implementation
should blindly send liveness check messages on 
every SA once new one is created. If SA is active
(there was recent incoming traffic over it) or implementation
has just successfully finished liveness check on that 
particular SA, then there is no need to do it again.
But if some unauthenticated SAs are idle for a while, then the event of 
creating new unauthenticated IKE SA  MAY (not SHOULD, not MUST) 
trigger the liveness check on those SAs, regardless of their IP addresses.

> ddos-puzzles were interesting, come tackle this problem :)

This is interesting problem, but I think that in general
implementations should be robust enough to deal with that.
Of course you may punish abusers if you know their
IDs, but it would be a shame on you if those abusers
could crash your implementation, just because their 
implementations are buggy and send zillion messages.

> addresses.

The server assigned IP addresses using CP is a standard
way of dealing with it. I admit that others are possible
and don't want to limit implementations to the only one.

And in general the problem of overlapping is irrelevant to NULL Auth.

> And opens up the reverse attack of the server stealing the

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.

> find themselves in a soon to be draft-ipsec-opportunistic document.

Exactly.

> Paul

Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Jan 2015 16:33:57 +0200

> trigger the liveness check on those SAs, regardless of their IP addresses.

Or the implementation could just do n liveness checks for
unauthenticated clients per second. I.e. go through all your
unauthentication clients ever now and while, and see whether you need
to clear the resources. How fast you want to go through them depends
how much resources you have left. If you have plenty of resources,
there is no need to wast other resources to clean up some other
resources. If you are running out of memory because you have too many
unauthenticated IKE SAs then send liveness check to them faster (==
consume more CPU resource), to clean up resource you are running out
(==memory).

This all is implementation details. We could give some hints here, but
I do not think we want to make any hard rules...

> > Traffic Selectors
...
> > client's 8.8.8.8 traffic. Some more discussion and insights on this

Actually I think I am missing something. How can server steal clients
8.8.8.8 traffic? Even if it assigns client 8.8.8.7 IP address, that
does not mean 8.8.8.8 is sent to the server. Server can assign 8.8.8.8
for the client, which means that 8.8.8.8 traffic from the client does
not go anywhere (i.e. it is routed to localhost, because client think
it is his own IP), but that does not allow stealing traffic.

Assigning address using configuration payloads do not affect routing
table. Only traffic selectors and perhaps INTERNAL_IP*_SUBNET stuff
might affect routing, and client should not ever allow traffic
selectors which are wider than what his policy allows. For
unauthenticated host-to-host conection client would always put exactly
one IP address (servers IP-address) to the TSr when proposing traffic
selectors, and server cannot make it wider than that.

Also client can easily limit that address assigned to it via
configuration payload must be from the private address range, as there
is no reason for server to assign client real routable IP-address in
unauthenticated user case. But again this is policy decision which
implementations need to do.

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

On the other hand on some environments Child SAs are expensive, for
example if you have hardware acceleration which  only supports limited
amount of SAs. In those environments the server's policy might
disallow per flow SA.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Jan 2015 10:19:35 -0500 (EST)

> it is his own IP), but that does not allow stealing traffic.

You are right. I was thinking of 8.8.8.8 <-> 0.0.0.0/0 but you don't do
that. I guess you would just use the equivalent of:

 	ip route add serverip src 8.8.8.8

> implementations need to do.

Sure. and this discussion is suitable for the opportunistic document,
not auth_null. We should only put in a short summary here.

> btw child SAs are quite cheap, so the limit does not need to be 1 and

But what's the point? Just to protect th per-port IPsec SA's with
more PFS in CREATE_CHILD_SA ?

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.

If you are not authenticated, what is the point in splitting up the
traffic in different IPsec SA's per protocol or port?

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

We need less buttons and possibly interop issues, not more. So Instead
of trying to allow as much of IKEv2 features as you can dream of, lets
stick to those bells and whistles that make sense in the unauthenticated
scenario.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Jan 2015 17:24:16 +0200

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

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

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

> traffic selectors really suck for "everything but sip and smtp and pop

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...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 26 Jan 2015 10:55:58 -0500 (EST)

> breaking Diffie-Hellman later provides better ways of staying

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.

> 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

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.

> for authenticated clients.

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

> 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 :)

> 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

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

> 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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Jan 2015 19:11:32 +0200

> On Jan 26, 2015, at 5:24 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Paul Wouters writes:

This is an unfortunate naming issue. PFS in IKE vs PFS in TLS are very different beasts.

PFS in TLS is for protecting against a future compromise of the long-term private key associated with the server certificate. RSA keying protects the pre-master secret with the public key, requiring only the private key to decipher. So a future compromise of the (long-term) private key allows the attacker to decrypt your connection (very useful for debugging in wireshark)

PFS in IKE protects you against a future compromise of the ephemeral SK_d. Unlike the certificate private key, SK_d is generated during IKE, and is deleted at the expiration of the IKE SA. For a software-only implementation there is no reason to believe that the SK_d is any easier to steal than the traffic keys. Configurations tend to give IKE SAs a longer lifetime than the child SAs, but that is not required by the protocol.

PFS in TLS makes enough sense that UTA is recommending it for all TLS connections and the TLS working group is requiring it for the next version of TLS.  The thing that this group calls PFS is far less important, and doesn’t always justify the cost.

Yoav