[IPsec] Privacy attack vectors against IKEv2 and Postquantum

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[IPsec] Privacy attack vectors against IKEv2 and Postquantum

David Schinazi
Hi everyone,

I'd like to start off by saying that I have read draft-fluhrer-qr-ikev2-04 and I really like it, particularly the fact that it is a minor change, does not add RTTs and keeps existing properties.

I have however come across two privacy attack vectors that IKEv2 is vulnerable to, with and without postquantum, that I think the postquantum draft could also help mitigate.

1) Active man-in-the-middle attack against the initiator
An attacker that can intercept and spoof packets can complete the SA_INIT part of the exchange with both sides and get the initiator to disclose its IDi (and PPK_id). This allows an attacker to fingerprint devices and/or users.

2) Passive off-path attack against a "hidden" responder
Today an IKEv2 server cannot hide the fact that it exists - the initiator's SA_INIT is not authenticated so the responder must respond to it even if it is forged, leaking the fact that it is running an IKEv2 server. Hypothetically speaking, if one were to run IKEv2 over TLS and sharing port 443 with a web server to obfuscate the fact that it is using IKEv2, an attacker could open a TLS connection and sending an SA_INIT to divulge the fact that this HTTPS server also supports IKEv2.

Straw man Proposal:

We slightly change the PPK_SUPPORT status notification payload to include notification data, and that data would contain a MAC of the SA_INIT using the PPK. Note that this would not contain the PPK_ID, just the MAC. The MAC would be defined as
PPK_MAC = prf( prf(PPK, "PPK MAC for IKEv2"), <SAInitOctets>)
where SAInitOctets is the entire SA_INIT, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload, with PPK_MAC set to all zeroes (this is inspired by the IP header checksum) and where prf is the PRF of the first proposal in the SA_INIT.
Both peers MUST send this PPK_MAC on all SA_INIT that contain PPK_SUPPORT.

Upon receiving an SA_INIT, each endpoint has two options:
- if it knows only of a small number of PPKs, it tries all of them and if none of them match it silently drops the SA_INIT.
- if it has too many PPKs or if it is worried about DoS attacks, it MAY choose to ignore PPK_MAC entirely (and continue the IKEv2 exchange with PPK in the IKE_AUTH exchange)

If the responder does not support the PRF from the first initiator's proposal, it can either
- ignore PPK_MACi entirely and continue the IKEv2 exchange with PPK in the IKE_AUTH exchange
- silently drop the SA_INIT if it was configured to only use a set of PRFs when provisioned with the PPK. The initiator can retry with a different PRF.

I believe this proposal does not reduce the security properties of the current draft, it also does not leak any information to any party that does not possess PPK, and it mitigates the attack vectors discussed above.

What are your thoughts?

Thanks,
David Schinazi
Apple

_______________________________________________
IPsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ipsec
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Privacy attack vectors against IKEv2 and Postquantum

Paul Wouters-4
On Fri, 11 Aug 2017, David Schinazi wrote:

> 1) Active man-in-the-middle attack against the initiator
> An attacker that can intercept and spoof packets can complete the SA_INIT part of the exchange with both sides and get the initiator to disclose its IDi (and PPK_id). This allows an attacker to fingerprint devices and/or users.

One of the two will have to show ID before the other can make a decision
(before revealing itself) if it sees an attacker or a valid endpoint.
There have been suggestions in the past (eg BTNS with channel binding)
but no one thought it was worth the extra round trips. In theory you
could still do this using NULL-AUTH on the client, which authenticates
the server without losing any privacy and then running a second
authentication to 'upgrade' the client.

> 2) Passive off-path attack against a "hidden" responder
> Today an IKEv2 server cannot hide the fact that it exists - the initiator's SA_INIT is not authenticated so the responder must respond to it even if it is forged, leaking the fact that it is running an IKEv2 server. Hypothetically speaking, if one were to run IKEv2 over TLS and sharing port 443 with a web server to obfuscate the fact that it is using IKEv2, an attacker could open a TLS connection and sending an SA_INIT to divulge the fact that this HTTPS server also supports IKEv2.

Maybe we should run DH on all webserver's for IKE :)

> Straw man Proposal:

[...]

> I believe this proposal does not reduce the security properties of the current draft, it also does not leak any information to any party that does not possess PPK, and it mitigates the attack vectors discussed above.
>
> What are your thoughts?

I think the tor people will tell you that you would still be able to
fingerprint this enough to tell it is IKE over TLS.

I'd also prefer a mechanism not tied to PPKs. Those are supposed to be
a bandaid that wouldn't be used anymore in the future where we have
quantum safe algorithms.

Paul

_______________________________________________
IPsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ipsec
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Privacy attack vectors against IKEv2 and Postquantum

David Schinazi
Thanks Paul, responses inline.

> On Aug 11, 2017, at 18:23, Paul Wouters <[hidden email]> wrote:
>
> On Fri, 11 Aug 2017, David Schinazi wrote:
>
>> 1) Active man-in-the-middle attack against the initiator
>> An attacker that can intercept and spoof packets can complete the SA_INIT part of the exchange with both sides and get the initiator to disclose its IDi (and PPK_id). This allows an attacker to fingerprint devices and/or users.
>
> One of the two will have to show ID before the other can make a decision
> (before revealing itself) if it sees an attacker or a valid endpoint.
> There have been suggestions in the past (eg BTNS with channel binding)
> but no one thought it was worth the extra round trips. In theory you
> could still do this using NULL-AUTH on the client, which authenticates
> the server without losing any privacy and then running a second
> authentication to 'upgrade' the client.

[DS] I think "showing ID" is exactly what we're avoiding here. You can think of this in terms of the Socialist Millionaire Problem - we want to be able to assert identity without anyone disclosing anything first. And the proposed solution is to send a MAC without the identity of the key used to MAC. Peers can than iterate their list of peers to check the MAC against.

>> 2) Passive off-path attack against a "hidden" responder
>> Today an IKEv2 server cannot hide the fact that it exists - the initiator's SA_INIT is not authenticated so the responder must respond to it even if it is forged, leaking the fact that it is running an IKEv2 server. Hypothetically speaking, if one were to run IKEv2 over TLS and sharing port 443 with a web server to obfuscate the fact that it is using IKEv2, an attacker could open a TLS connection and sending an SA_INIT to divulge the fact that this HTTPS server also supports IKEv2.
>
> Maybe we should run DH on all webserver's for IKE :)
>
>> Straw man Proposal:
>
> [...]
>
>> I believe this proposal does not reduce the security properties of the current draft, it also does not leak any information to any party that does not possess PPK, and it mitigates the attack vectors discussed above.
>>
>> What are your thoughts?
>
> I think the tor people will tell you that you would still be able to
> fingerprint this enough to tell it is IKE over TLS.

[DS] Some security is still better than less security, you can imagine timing attacks and such but this is better than what we have today.

> I'd also prefer a mechanism not tied to PPKs. Those are supposed to be
> a bandaid that wouldn't be used anymore in the future where we have
> quantum safe algorithms.

[DS] I was initially going to make this a separate proposal that only involved a pre shared key and SA_INIT MAC, but it was pointed out to me that once you have that might as well include the benefits of PPK. If you know of a way to solve the described privacy attack vectors without a pre shared key and without adding round trips, I'm interested - I couldn't come up with one myself.

David

_______________________________________________
IPsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ipsec
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Privacy attack vectors against IKEv2 and Postquantum

Paul Wouters-4
On Mon, 14 Aug 2017, David Schinazi wrote:

> [DS] I think "showing ID" is exactly what we're avoiding here. You can think of this in terms of the Socialist Millionaire Problem - we want to be able to assert identity without anyone disclosing anything first. And the proposed solution is to send a MAC without the identity of the key used to MAC. Peers can than iterate their list of peers to check the MAC against.

But when you are using X.509 based clients, you will have never seen the
cert/ID until you receive it via IKE ? So your use case is limited to
very static type deployments (which suffer less from this issue as they
tend to not move around)

> [DS] Some security is still better than less security, you can imagine timing attacks and such but this is better than what we have today.

But I think we would need something a little better to make it part of
an RFC standard.

> [DS] I was initially going to make this a separate proposal that only involved a pre shared key and SA_INIT MAC, but it was pointed out to me that once you have that might as well include the benefits of PPK. If you know of a way to solve the described privacy attack vectors without a pre shared key and without adding round trips, I'm interested - I couldn't come up with one myself.

A PreSharedKey based solution is also very limiting, and people should
be migrating away from PSK in favour of RSA/ECC based solutions :P

I understand your use case (prevent blocking of hidden IKE over TCP/TLS
servers) but it might not be a use case the IETF can solve. From an
IETF perspective, the way to solve this would be to IPsec everything,
so that blocking based on ESP visibility becomes impossible. Which
is why I'd like to see more Opportunistic IPsec.

But if we can fit in your goal, that would be great. And I think if
that takes another roundtrip people can make that decision. But I
think nation state actors are already active attackers, so I see
not too much value in a passive attackers only solution, which
IKE over TCP/TLS already is.

Paul

_______________________________________________
IPsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ipsec
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Privacy attack vectors against IKEv2 and Postquantum

Christopher Wood
On Wed, Aug 16, 2017 at 9:34 AM, Paul Wouters <[hidden email]> wrote:

> On Mon, 14 Aug 2017, David Schinazi wrote:
>
>> [DS] I think "showing ID" is exactly what we're avoiding here. You can
>> think of this in terms of the Socialist Millionaire Problem - we want to be
>> able to assert identity without anyone disclosing anything first. And the
>> proposed solution is to send a MAC without the identity of the key used to
>> MAC. Peers can than iterate their list of peers to check the MAC against.
>
>
> But when you are using X.509 based clients, you will have never seen the
> cert/ID until you receive it via IKE ? So your use case is limited to
> very static type deployments (which suffer less from this issue as they
> tend to not move around)
>
>> [DS] Some security is still better than less security, you can imagine
>> timing attacks and such but this is better than what we have today.
>
>
> But I think we would need something a little better to make it part of
> an RFC standard.
>
>> [DS] I was initially going to make this a separate proposal that only
>> involved a pre shared key and SA_INIT MAC, but it was pointed out to me that
>> once you have that might as well include the benefits of PPK. If you know of
>> a way to solve the described privacy attack vectors without a pre shared key
>> and without adding round trips, I'm interested - I couldn't come up with one
>> myself.
>
>
> A PreSharedKey based solution is also very limiting, and people should
> be migrating away from PSK in favour of RSA/ECC based solutions :P

David's original email suggested that this technique was enabled by
(and perhaps constrained to) draft-fluhrer-qr-ikev2, which assumes the
existence of a long-term PPK.

Best,
Chris

_______________________________________________
IPsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ipsec
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Privacy attack vectors against IKEv2 and Postquantum

David Schinazi
Paul,

I understand your concerns, and I do agree with them. However, the proposal isn't meant to solve all issues - the idea is that if we're building a PPK infrastructure already, I believe this is an incremental improvement to it that solves a few more attack vectors without compromising anything.

> On Aug 16, 2017, at 09:50, Christopher Wood <[hidden email]> wrote:
>
> On Wed, Aug 16, 2017 at 9:34 AM, Paul Wouters <[hidden email]> wrote:
>> On Mon, 14 Aug 2017, David Schinazi wrote:
>>
>>> [DS] I think "showing ID" is exactly what we're avoiding here. You can
>>> think of this in terms of the Socialist Millionaire Problem - we want to be
>>> able to assert identity without anyone disclosing anything first. And the
>>> proposed solution is to send a MAC without the identity of the key used to
>>> MAC. Peers can than iterate their list of peers to check the MAC against.
>>
>>
>> But when you are using X.509 based clients, you will have never seen the
>> cert/ID until you receive it via IKE ? So your use case is limited to
>> very static type deployments (which suffer less from this issue as they
>> tend to not move around)

On the contrary, if you were to run IPsec over point-to-point links between several mobile devices you own then you have a configuration that doesn't change much but devices that are very mobile - this allows you to have this type of configuration and ensure that there is no way for attackers to fingerprint who you are and where you go.

>>
>>> [DS] Some security is still better than less security, you can imagine
>>> timing attacks and such but this is better than what we have today.
>>
>>
>> But I think we would need something a little better to make it part of
>> an RFC standard.

I'm happy to hear proposals to make this a little better. Do you have an alternative that solves these use cases?

>>> [DS] I was initially going to make this a separate proposal that only
>>> involved a pre shared key and SA_INIT MAC, but it was pointed out to me that
>>> once you have that might as well include the benefits of PPK. If you know of
>>> a way to solve the described privacy attack vectors without a pre shared key
>>> and without adding round trips, I'm interested - I couldn't come up with one
>>> myself.
>>
>>
>> A PreSharedKey based solution is also very limiting, and people should
>> be migrating away from PSK in favour of RSA/ECC based solutions :P
>
> David's original email suggested that this technique was enabled by
> (and perhaps constrained to) draft-fluhrer-qr-ikev2, which assumes the
> existence of a long-term PPK.
>
>> I understand your use case (prevent blocking of hidden IKE over TCP/TLS
>> servers) but it might not be a use case the IETF can solve. From an
>> IETF perspective, the way to solve this would be to IPsec everything,
>> so that blocking based on ESP visibility becomes impossible. Which
>> is why I'd like to see more Opportunistic IPsec.

I don't see how adding a MAC in an extension data field is something the IETF can't handle. I'm being realistic here, and have an actual problem to solve. Are you telling me to go build and deploy my own proprietary solution instead of working with the IETF?

David

_______________________________________________
IPsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ipsec
Loading...