Hi Yoav, responses inline.
> On Feb 16, 2018, at 10:25, Yoav Nir <[email protected]> wrote:
>
>> On 16 Feb 2018, at 20:13, Tero Kivinen <[email protected]> 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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
