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

> On 16 Feb 2018, at 20:13, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> 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).

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?

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

> ----------------------------------------------------------------------
> 
> 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.
> --
> kivinen@iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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

Attachment: signature.asc