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

[David Schinazi <[e-mail]>]

Hi Yoav, responses inline.

> On Feb 16, 2018, at 10:25, Yoav Nir <[e-mail]> wrote:
> 
>> On 16 Feb 2018, at 20:13, Tero Kivinen <[e-mail]> wrote:
>> 
>> 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).
> 
> 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.

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.

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

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

Thanks,
David Schinazi