From nobody Sat Jun 5 09:40:23 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D213A25DE for ; Sat, 5 Jun 2021 08:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verifiablecredentials.info Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBLFpJFR9v61 for ; Sat, 5 Jun 2021 08:09:36 -0700 (PDT) Received: from client-mail2.aiso.net (client-mail2.aiso.net [199.19.158.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBE53A25E1 for ; Sat, 5 Jun 2021 08:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=verifiablecredentials.info; s=mail; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l+o2YMN4f8mu2BbiG+0lBZGILeFsgZwQvvHWsCTHxMM=; b=WC41kUGEeroQyXCBaxN3aRXfdx Ql06ZZUxzT+bTpxU2hMY3VegtMvgI1qpLuAh4kqV+o6oV6yqe5a4lzWGL17fKpXEOgne0XeJQLy+g RMhzp8Tf+Ug2JRXTd4u1OPkubAHapwf72AddQM5tpqm1wB60IpTlqGrsYdcRYgYKhdHo=; Received: from [146.200.52.122] (helo=AdministorsMBP2.lan) by client-mail2.aiso.net (envelope-from ) with esmtpsa (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.94.2) id 1lpXvX-0009pg-A3; Sat, 05 Jun 2021 08:09:35 -0700 To: Justin Richer Cc: txauth@ietf.org References: <3950725f-26e5-0eb5-92bb-5e2ed977ac85@verifiablecredentials.info> <429623E4-5C45-474C-801A-6953E803BAE6@mit.edu> From: David Chadwick Organization: Verifiable Credentials Ltd Message-ID: <7deb4b8f-6d2e-c386-23d6-7286a5077cc6@verifiablecredentials.info> Date: Sat, 5 Jun 2021 16:09:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <429623E4-5C45-474C-801A-6953E803BAE6@mit.edu> Content-Type: text/html; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-AISO-Id: info@verifiablecredentials.info X-AISO-Outbound-SA-Spam-Score: 0.7 X-AISO-Outbound-SA-Spam-Score-Int: 7 X-AISO-Outbound-SA-Spam-Report: BAYES_00=-1.9, HTML_MESSAGE=0.001, KAM_INFOUSMEBIZ=2.5, MIME_HTML_ONLY=0.1, NICE_REPLY_A=-0.001 X-AISO-Report-Abuse: abuse@aiso.net Archived-At: X-Mailman-Approved-At: Sat, 05 Jun 2021 09:40:23 -0700 Subject: Re: [GNAP] Mix Up Attack against GNAP X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 15:09:42 -0000

Hi Justin

the point I am making is that the message created by the Client must be received by the ultimate recipient, knowing that the Client created it and that the ultimate recipient is the intended recipient. In the current flow both recipients know they are the intended recipients, but also know that different clients are talking to them. Thus any solution must have the message originator cryptographically protecting both the sender and recipient addresses. Once you do this, you thwart the current vulnerability.

Kind regards

David

On 05/06/2021 15:51, Justin Richer wrote:
Hi David,

I think it’s similar to message forwarding, but there’s one important difference — the AAS already is modifying the message to HAS. It doesn’t need to forward the complete message from (2), it creates a brand new message in (3) and signs it with its own key. So the client knows it’s talking to AAS and vice versa, and AAS knows it’s talking to HAS and vice versa. What’s different is that AAS is able to take pieces out of the (valid) message from the client and make its own message out of those parts, and then get value out of that.

But that does raise an interesting question: what if ASS :did: simply forward the signed message from the client to HAS? The signature method would need to protect the target of the HTTP request, but I think that should already be covered in most of the signature methods. We need to put some focus on these signature methods directly in the near future, so that’s something to keep in mind here.

 — Justin

On Jun 5, 2021, at 8:26 AM, David Chadwick <d.w.chadwick@verifiablecredentials.info> wrote:

This attack is similar to surreptitious forwarding (message 3). One solution is for the sender (Client) to identify the recipient in message 2 so that it cannot be altered by the AAS when it creates message 3. The grant endpoint of the AS that the client instance is talking to would seem to fit this solution

Kind regards

David

On 04/06/2021 15:59, Justin Richer wrote:
This week, some researchers reached out to the editors to describe an attack against GNAP in the front channel that’s inherited from OAuth 2. I will describe the attack, list out its preconditions, and then describe a proposed solution space. We’re looking for input and feedback from the group on managing this solution.

But first, many thanks to Åke Axeland and Adam Omar Oueidat for doing this analysis, putting together the diagram below, and bringing it to the group’s attention.

The attack is largely the same as one of the “AS Mix Up” attack cases in "Comprehensive Security Analysis of OAuth 2.0” by Daniel Fett and colleagues. It’s a kind of in-the-middle and/or phishing attack at its core. 

The attacker has their own authorization server (AAS) which can also act as a client instance. An uncompromised client (UC) instance and an uncompromised authorization server (HAS) are assumed. There is no compromise of secret keys or breaking of TLS in this attack.

1. UC is a client of AAS, and might also be a client of HAS. User wants to authorize at HAS but tells UC to use AAS.
2. UC starts a request at AAS, signed with UC’s key. AAS is imitating HAS.
3. AAS forwards UC’s request parameters (Client nonce, interaction finish URI) to HAS, but signed with AAS’s key.
4. HAS responds with an interaction start URL and server nonce to AAS
5. AAS forwards the interaction start URL and server nonce to UC
6. (Note) HAS is functionally telling the user to show up and interact, but doesn’t realize that the request is being proxied in this way.
7. UC launches interaction start url, which is a function of HAS
8. HAS returns the verification hash and interaction reference to UC
9. UC validates the hash (which is correct) and sends the interaction reference to AAS
10. AAS forwards the interaction reference to HAS 
11. AAS receives an access token for calling an RS protected by HAS. The client receives no access token.

The diagram from the researchers is attached here. I’ll be using the numbers in the text list here like (1) to refer to specific steps.

<PastedGraphic-2.png>
Some preconditions and analysis:

Step (1) is made easier if the client has choice over which AS to talk to for a given request, since that’s how it starts talking to AAS instead of HAS. The danger of allowing a client to choose its AS at runtime has been discussed, but it’s a known pattern that we can’t expect to go away.

AAS is treated as a legitimate client of HAS and UC is a legitimate client of AAS. While dynamic clients can exacerbate this problem at runtime, at no time does HAS always knows the requests are coming from AAS and UC always knows it’s talking to AAS. There is no cryptographic impersonation and no theft of keys. 

The attack occurs because the user and client think they’re dealing with different AS’s, and you can’t expect a user to always be able to tell them apart, especially when the backend calls like (2) are hidden. It’s assumed that the user actually wants to authorize UC for HAS, but UC talks to AAS instead because of configuration (1). AAS can imitate HAS to the user to facilitate (1), and imitate UC to HAS, but only for human-facing portions (7). Static pre-registration makes this more difficult, assuming that all registrations are reviewed by humans. If HAS has no idea that UC exists, it wouldn’t necessarily know that AAS is impersonating anyone.

The token at the end (11), assuming it’s a bound token, is only good with AAS’s key and not UC’s key. This is great for the attacker until UC starts to act funny and raise suspicion, since the process didn’t ever complete. With the OAuth attack, and with bearer tokens in GNAP, the token can be passed through to the UC making UC none the wiser. 

The hash validation (9) does not protect against this specific attack. Since AAS sits in the middle, it has access to the Client nonce from UC, the server nonce from AAS, and the interaction reference at the appropriate times. AAS doesn’t need to generate the hash, but can force HAS to generate an appropriate hash.

The proposed mitigation(s): 

In OAuth 2, the accepted mitigation is to provide another query parameter with the “issuer” URL of the AS. We could do that here, but that would have the same downsides: the client has to check this value explicitly. Therefore we’re proposing that instead we use the existing validation hash algorithm and add an additional field. This would need to be something known to UC and HAS that can’t be impersonated by AAS, even if it’s known. Therefore, it makes sense to use something that’s derived. There are a few ideas of what to do here, each with benefits and drawbacks:

- The grant endpoint of the AS that the client instance is talking to.
- The continuation endpoint that the client instance will send the interaction reference to. (This might be different from the above)
- The continuation access token value
- A key hash for the AS the client is talking to (TLS key to one of these endpoints? Some other external key added to the mix?)

The important thing here is that it’s a value that’s known but not a shared-secret that’s passed between parties. The client doesn’t need to check anything new, just needs to do the hash validation that it should be doing anyway.

Requested feedback:

The editors are requesting feedback and discussion on the attack and the proposed mitigation strategy. As a group, we would also benefit from additional formal analysis of the protocol with and without the mitigation in place. Additionally, we need to be sure we aren’t accidentally cutting off a legitimate use case, like AS bridges and proxies that aren’t trying to hide their presence.

 — Justin

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth