Subject: Re: [quicwg/base-drafts] Spoofed retry token attack on IP authentication (#2394)

From: Kazuho Oku <[email-masked]>
Date: Fri, 01 Feb 2019 04:00:09 -0800

This is an interesting attack, and I have several points that I would like to argue.

First, this is not an MOTS attack that we need to consider. Because the attack can be mounted by a malicious client. A client first obtains one token, then uses that token to create multiple connections. That is an attack vector that we need to fix (assuming that we haven't already).

Note also that we are giving up to have protection against on-path attackers injecting Initial packets.

Therefore, the protection method that @marten-seemann is fine. It's true that an MOTS attacker can race a Retry to prevent a legitimate client from establishing a connection. However that's not something we need to fix, considering that an MOTS attacker can simply inject an Initial packet containing a CONNECTION_CLOSE frame to disrupt the handshake.

Lastly, I would like to point out that there is another (possibly simpler) way of addressing the issue. A server can embed the server CID issued in the Retry packet in the Retry Token that it issues, and use the token to confirm that the Initial packet sent in response to the Retry contains the correct DCID.

I think we should recommend servers to implement some kind of protection.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459700403

---

From: MikkelFJ <[email-masked]>
Date: Fri, 01 Feb 2019 04:12:27 -0800

> However that's not something we need to fix, considering that an MOTS attacker can simply inject an Initial packet containing a CONNECTION_CLOSE frame to disrupt the handshake.

This is not about a DoS attack. It is about about privilege escalation. The man on the side can observe another connection and pretend to have the IP of the original client. If the server grants access to the observer based on the original clients IP, trust has been broken.

Racing the packet is sufficient to achieve that.

Racing will also close the original clients connection iff the token can only be used once, but that is a minor concern, I agree.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459703440

---

From: MikkelFJ <[email-masked]>
Date: Fri, 01 Feb 2019 04:18:21 -0800

I believe the fix is to only allow tokens to be used once as Marten suggests, and to add to the vulnerably section that a server SHOULD/MUST not grant privileged access based on the clients IP address verified by a Retry token since on-path devices and also path observing devices can race a Retry packet with a spoofed IP address.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459704800

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 01 Feb 2019 04:26:30 -0800

> This is not about a DoS attack. It is about about privilege escalation.

Would you mind elaborate what the “privilege” is under this context?

My understanding is that it is nothing more than the right to establish the connection. I think my arguments hold assuming that is true.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459706766

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 01 Feb 2019 04:32:22 -0800

> to add to the vulnerably section that a server SHOULD/MUST not grant privileged access based on the clients IP address verified by a Retry token since on-path devices and also path observing devices can race a Retry packet with a spoofed IP address.

I disagree, because a node that can receive packets going to address X and that can also send a packet that states to originate from X can initiate a new connection by itself.

For such a node, there is no need to piggyback on an Initial sent by the true owner of address X.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459708299

---

From: MikkelFJ <[email-masked]>
Date: Fri, 01 Feb 2019 04:50:47 -0800

I might be just the right to establish a connection, which is bad enough.

But a QUIC server implementation could also provide an API that indicates that 1) connections should be Retried to prove IP, and 2) provide the source IP of the application layer with a status of verified. From then on, things can go arbitrarily wrong.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459712735

---

From: MikkelFJ <[email-masked]>
Date: Fri, 01 Feb 2019 04:54:46 -0800

But even without Retry, I think things can go wrong if the server API indicates the IP is trusted. But without Retry the conclusion arrives later and requires an on-path attack.

So that begs the question: why would you Retry for other reasons than to redirect to a new host?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459713758

---

From: MikkelFJ <[email-masked]>
Date: Fri, 01 Feb 2019 05:01:21 -0800

Oh, but you can always create a new connection with a spoofed IP, you don't even need a Retry token.

But that makes me question the entire point of
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.8.1.1

> As long as it is not possible for an attacker to generate a valid token for its own address (see Section 8.1.3) and the client is able to return that token, it proves to the server that it received the token.

But an attacker does not need to forge a token, it can just pretend to have another IP that it can listen in on. The server will then voluntarily provide the token.

I suppose this requires a v2 authenticated handshake.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459715345

---

From: MikkelFJ <[email-masked]>
Date: Fri, 01 Feb 2019 05:13:52 -0800

So the conclusion is that you cannot do anything about it in v1. There isn't even much reason to strongly prevent token reuse since only path observers can reuse it, and they have powers anyway.

But there is reason to advise in vulnerability that Retry only protects against off-path attackers, not on-the-side or on-path attackers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459718522

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 01 Feb 2019 05:30:30 -0800

> So the conclusion is that you cannot do anything about it in v1. There isn't even much reason to strongly prevent token reuse since only path observers can reuse it, and they have powers anyway.

We cannot do anything in any version of QUIC to prevent a MOTS attacker from spoofing an address, because an IP address is never authenticated. From an endpoint's view, it is impossible to tell whether if it's talking with the legitimate owner of IP address X or if it's talking with somebody spoofing address X.

OTOH, as I pointed out in 
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459700403, we might want to prohibit a token from being used to create multiple connections. This is because one of the use-case of Retry tokens is to limit costly TLS handshake operations to connection establish attempts that have proved (probabilistically) to own the IP address (by responding to the Retry).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459722927

---

From: MikkelFJ <[email-masked]>
Date: Fri, 01 Feb 2019 05:45:49 -0800

I agree, but if you can get a signed initial packet it is easier to trust the IP, although not fool proof.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-459727050

---

From: Martin Thomson <[email-masked]>
Date: Sun, 03 Feb 2019 13:55:51 -0800

This is a fairly non-interesting attack.  I read this as saying that if you can send and receive packets for a given IP address you can make connections from that address.  From the perspective of what we can reasonably test, there is no distinction between that and genuinely owning the address.

The point about the number of times that Retry tokens can be used is a fine one.  Adding a note about expected lifetime of these tokens to [Section 8.1.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#validate-retry) is a fine idea.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2394#issuecomment-460092507