Subject: [IPsec] Additional charter items 4/4: Mitigating privacy concerns

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Feb 2018 20:13:20 +0200

This item does not have charter text yet, we do have text which
explains what the problem is, but I think it requires some
reformatting to fit as charter text.

The problem description is:

----------------------------------------------------------------------

IKEv2 is currently vulnerable to the two following privacy concerns:

1) It's not possible to run a server that obfuscates IKEv2/IPsec using
   TLS.

    Today thanks to RFC 8229 it is possible to run an IKEv2/IPsec
    server on TCP port 443 with TLS. However if a government agent
    tries to send an SA_INIT over that it will discover that this
    server runs IKEv2/IPsec, and may blacklist it. We should add a
    mechanism to IKEv2 that allows the server to only respond to
    SA_INIT from known entities (e.g. that possess a shared secret).

2) The privacy of the initiator's identity in the presence of a man in 
   the middle attacker is not protected.

    Today an attacker with full control of the network can receive the
    IDi/IDr sent by the initiator in the first AUTH packet. We should
    add a mechanism to IKEv2 that allows the initiator to only send
    IDi/IDr to known entities (e.g. that possess a shared secret).
    
----------------------------------------------------------------------

Is this something that we should add to charter? Do people understand
the issue?

Note, that there are multiple ways of solving these issues, for
example the 2nd problem can also be solved by using pseudonyms, i.e.,
sending random one use ID payloads during the IKE_AUTH, and after the
peers have authenticated each other, they can do new exchange which
will change the pseudonyms for next use. I think the 2nd option should
be rewritten in bit more generic ways to allow that kind of option
too.

Send your comments and whether you support adding this to the charter
to the ipsec list in next two weeks.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 16 Feb 2018 20:25:23 +0200

> On 16 Feb 2018, at 20:13, Tero Kivinen <[email-masked]> wrote:
> 

That would require that within the SA_INIT request, the initiator proves possession of a shared secret and does so in a non-replayable way.

Wouldn’t it be better for the initiator to prove identity or group membership in the TLS handshake?

>    IDi/IDr to known entities (e.g. that possess a shared secret).

This is more feasible. I understand the issue, but the only use case where I think it’s important is remote access. It would make sense in remote access to reverse the order of authentication so that the responder identifies and authenticates first, but you’d still need the initiator to send the IDr first.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Feb 2018 21:09:57 +0200

Yoav Nir writes:
> This is more feasible. I understand the issue, but the only use case
> where I think it’s important is remote access. It would make sense
> in remote access to reverse the order of authentication so that the
> responder identifies and authenticates first, but you’d still need
> the initiator to send the IDr first. 

The reason why we defined IKEv2 so that initiator provides identity
first, was that if responder provides identity first, then attackers
can make probe attacks and collect identities of the remote peers,
even when the IPsec is not currently in use. I.e., like we might run
nmap to find out the open ports, this would also provide authenticated
(if using certificateS) identity of the peer...
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 16 Feb 2018 21:36:22 +0200

> On 16 Feb 2018, at 21:09, Tero Kivinen <[email-masked]> wrote:
> 
> Yoav Nir writes:
> (if using certificateS) identity of the peer…

I realize this, but one side has to identify itself first, and with remote access I think it’s more important to protect the initiator identity than to protect that fact that some organization has an IPsec remote access concentrator.

In fact we can run nmap and find which ports are open, and we can and do scan for HTTP(S) servers on ports 80 and 443, and we do get their certificates.

---

From: David Schinazi <[email-masked]>
Date: Fri, 16 Feb 2018 11:51:28 -0800

Hi Yoav, responses inline.

> On Feb 16, 2018, at 10:25, Yoav Nir <[email-masked]> wrote:
> 

Actually, replay protection is not critical here. In the TLS scenario, attackers would not be able to observe SA_INITs from trusted peers.
In the privacy scenario, replaying the initiator SA_INIT will only get the SA_INIT of the responder which doesn't include IDi/IDr.
One approach to solving this would be to share a secret with the IKEv2 config to all the clients and have the initiator HMAC its SA_INIT with that secret.

> Wouldn’t it be better for the initiator to prove identity or group membership in the TLS handshake?

As defined in RFC 8229, IKEv2 encapsulation does not rely on any security properties from TLS.
I don't think we should change that. Especially in the case of TLS <= 1.2, the client certificates are not encrypted so this would defeat privacy gains.

> This is more feasible. I understand the issue, but the only use case where I think it’s important is remote access. It would make sense in remote access to reverse the order of authentication so th…

Agreed, changing the order would protect the IDi but not the IDr.

Thanks,
David Schinazi

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Feb 2018 15:09:11 -0500 (EST)

> Is this something that we should add to charter? Do people understand

I would be in favour of adding this issue to the charter in some to be
written text.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Feb 2018 22:15:24 +0200

Yoav Nir writes:
> I realize this, but one side has to identify itself first, and with
> remote access I think it’s more important to protect the initiator
> identity than to protect that fact that some organization has an
> IPsec remote access concentrator.

IKE is not unidirectional, it is not only client and server, it is
host to host. I.e., the remote access initiator should also respond to
the incoming connections as it might be the restarted remote peer
reconnecting etc.

There might actually be real IP connection between (i.e., no NAT)
which allows remote peer to connect to you too :-)

> In fact we can run nmap and find which ports are open, and we can
> and do scan for HTTP(S) servers on ports 80 and 443, and we do get
> their certificates. 

For server yes, but my web browser does not listen port 80 or 443, and
will not respond to them. My ipsec client will listen port 500 and
4500 and will respond to them. It might not allow incoming
IKE_SA_INITs to them, or might not even implement them, but originally
IPsec was seen more host to host than client to server...
-- 
[email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 16 Feb 2018 15:50:28 -0800

+1 to adding privacy text to the charter. This seems like it will be increasingly relevant if we’re doing host-to-host communication and we want to protect the privacy of various peers.

—Tommy

> On Feb 16, 2018, at 12:09 PM, Paul Wouters <[email-masked]> wrote:
>