From nobody Sun Jun 6 02:34:05 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 625F83A12E7 for ; Sun, 6 Jun 2021 02:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch 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 IRDhF_2xwT5q for ; Sun, 6 Jun 2021 02:33:56 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858CC3A12E4 for ; Sun, 6 Jun 2021 02:33:56 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id b13so20396064ybk.4 for ; Sun, 06 Jun 2021 02:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N686vVvkcBLocBd8LBXMopUDgsmsV/SH66sRamiVQnY=; b=YrvPpi0Ic5+u+++ba207wGiTSsljJ8xByjGw25NmedsxS+5iCR2Y0ZO2r9P44X9mc7 5t3zLRDBGsf+zireIGGTwQkJ+7/AIKzWRo31NuxdRy085miVfw4Gzacjp4bNcMoru+yA a0yh4omCW9BsHnU/EcBdf/CaSEdUYEFBIbuQteN0G7xt9MXaI51Nrd9P5u5Wk0gtix1K Zfvnb8KbnI3qClVNvU4USuxTE0nP2nWjrCNiivXRMDhpl4RbezeGo6NdRcemO5GL3Ppv j0hCsz01r35GEFoYvpgBIlZm6L5j6Ogjn+igJb8J0wEtjt0f3OOHi47rugFyuLcq7LGT YzwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N686vVvkcBLocBd8LBXMopUDgsmsV/SH66sRamiVQnY=; b=Y1p6Hqi9muCvn+5KPrG50S7WcUeZMmmvpnbU3yW81lw2+u5nsFkuFM0K7WdZvEOz3I JIjwNvxz+Ux2XvDsmH70zFt+clWMyOGA/cVQSGuax3CYc+5C9Ph1r8w7zeyGvBZVUwEd v2XC/l8w+91o5FesdRMv/+s2lv/551hcV7j8AG4N9g40WwMcJ1vp5OM+ZE3oSnXnzNvT 4DVmxT3Qjrj6JlbZ2mme/iTnL5WEG4ndf7VV6nXr2RnPk9skG+PDcXN8ArDxR+Me7BRB U3YQVghNLkC4LS4X229+4QXHSrBanIX2hxYC6JlHb3FDTaiuF0Mn723YxVWnHNg0gteT NwiQ== X-Gm-Message-State: AOAM530Ej3Yr8koLcclr8q8lSMOCkFx4FKEqGy1w7bC3YPPSz1i1GogL 9LMZVAhBOd/XF5nMb47ScELOHfEwQU8ZqvrewIPk1EUbMA== X-Google-Smtp-Source: ABdhPJztwlyo6WqtyYuyKWI+IVIn4uoeK0lPR6S1GOF2vMLhQv3/MMnntr1yNmc01XPtaIkBxv978bRk2fBDZbVAFpE= X-Received: by 2002:a25:aa66:: with SMTP id s93mr5539143ybi.260.1622972034619; Sun, 06 Jun 2021 02:33:54 -0700 (PDT) MIME-Version: 1.0 References: <3950725f-26e5-0eb5-92bb-5e2ed977ac85@verifiablecredentials.info> <429623E4-5C45-474C-801A-6953E803BAE6@mit.edu> <7deb4b8f-6d2e-c386-23d6-7286a5077cc6@verifiablecredentials.info> <9259F10A-7E27-4D1B-BF3C-32905928F847@mit.edu> <9482fcaa-80ae-83e6-eec9-0b757df4b900@verifiablecredentials.info> In-Reply-To: <9482fcaa-80ae-83e6-eec9-0b757df4b900@verifiablecredentials.info> From: Warren Parad Date: Sun, 6 Jun 2021 11:33:43 +0200 Message-ID: To: David Chadwick Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000009abcb305c4159f0e" Archived-At: 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: Sun, 06 Jun 2021 09:34:03 -0000 --0000000000009abcb305c4159f0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think that would solve the problem, although it might give the user client a second chance to avoid the vulnerability, it isn't a fix so far as I understand it. I like Justin's writeup, and knowing that it took me some time to appreciate the challenge, perhaps reframing the problem might help make it more clear. (And a real case that has happened) 1. An app network exists, and anyone can register an app. A malicious app registers a client with which itself is granted AS-like capabilities to the app network. The app pretends to be Google Drive, and the login screen is a perfect match for google's login. 2. Through a phishing attack, users are sent an email and directed to login to this malicious app. 3. The user navigates through the flow and returns to a legit application with an auth code 4. All along this malicious app has been intercepting the data the user has been providing and using it to authenticate itself as a valid app. If the user completes the flow the malicious app, will have a valid token for the HAS with the privileges the user thought they were granting the honest app. At this point the users client only has two* pieces of information: * Where the initial request to start the flow was sent * The Auth Code To break the vulnerability it must intentionally be so that the user client does NOT send the auth code to the same place where the initial request to start the flow was sent. Which means that the only available piece of information in the auth code. In OAuth, it has been introduced to create a third piece of information, the ISS url. Which can be used to look up where to send the auth code. It doesn't matter what endpoints or secrets are shared, none of them will be of any use, because the client is intentionally always communicating with the malicious app. The user may not want to, but they are anyway. the PKCE prevents interception or vulnerabilities in the flow, but this isn't a vulnerability in the flow, it is a malicious proxy. The only way to avoid this attack is one of: * Trust a third party for verification * include data in the auth code that the client can use to identify where to send the auth code * include data adjacent to the auth code which identifies how to handle the auth code Hope that helps. Warren Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Sun, Jun 6, 2021 at 10:21 AM David Chadwick < d.w.chadwick@verifiablecredentials.info> wrote: > So effectively you are saying that a client can be redirected to anywhere > in the world and not know whether this is correct or not, or, it has to > assume that it is correct regardless of where it is. In this case I sugge= st > that these two locations should share a secret that they can both give to > the client so that it knows these two endpoints are collaborating togethe= r. > If you use something like the OIDC PKCE scheme then the first endpoint ca= n > send the hash of the secret, and the second endpoint can send the secret > itself for the client to hash. > > Kind regards > > David > On 05/06/2021 21:35, Justin Richer wrote: > > It=E2=80=99s completely reasonable for any legitimate AS to split the hos= ting of > its user-facing stuff from its backend stuff. Google already does this wi= th > OAuth/OIDC today, and expecting this to change to something more > constrained would be a non-starter for many deployments. Additionally, we > can=E2=80=99t assume that everything is web-based and that things are hap= pening > within a browser. Furthermore, relying on the client to do some kind of > comparison between the URL it starts the transaction with and the URL use= d > for interaction is going to lead to misbehaving clients simply being more > susceptible to this and related attacks. I=E2=80=99m of the school of tho= ught that > we should expect the minimum number of very specific things from the clie= nt > in order to enforce security principles. > > =E2=80=94 Justin > > On Jun 5, 2021, at 3:43 PM, David Chadwick < > d.w.chadwick@verifiablecredentials.info> wrote: > > But the start URL has HAS in it (message 5), when the client was talking > to AAS. So this should be sufficient should it not to determine that > something is wrong? Especially if SOP is being enforced, then the url of > HAS and AAS wont have the same origin > > Kind regards > > David > On 05/06/2021 17:39, Justin Richer wrote: > > But that=E2=80=99s what I=E2=80=99m saying =E2=80=94 the client knows it= =E2=80=99s talking to AAS and not > HAS so with this kind of solution it would just create a message > cryptographically tagged to AAS. And then on the next step, AAS creates a > message cryptographically bound to HAS. So even if the client already say= s > =E2=80=9Cthis message is for AAS=E2=80=9D explicitly, the attack surface = doesn=E2=80=99t change. > Only if the client thought it was talking to HAS would this make a > difference, but that=E2=80=99s not what=E2=80=99s happening here. This, I= believe, is what > makes this kind of attack much more subtle than a simple message relay. > > =E2=80=94 Justin > > On Jun 5, 2021, at 11:09 AM, David Chadwick < > d.w.chadwick@verifiablecredentials.info> wrote: > > 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 an= d > that the ultimate recipient is the intended recipient. In the current flo= w > 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 vulnerabili= ty. > > Kind regards > > David > On 05/06/2021 15:51, Justin Richer wrote: > > Hi David, > > I think it=E2=80=99s similar to message forwarding, but there=E2=80=99s o= ne important > difference =E2=80=94 the AAS already is modifying the message to HAS. It = doesn=E2=80=99t > 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=E2= =80=99s > talking to AAS and vice versa, and AAS knows it=E2=80=99s talking to HAS = and vice > versa. What=E2=80=99s 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 pu= t > some focus on these signature methods directly in the near future, so > that=E2=80=99s something to keep in mind here. > > =E2=80=94 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 see= m > 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=E2=80=99s inherited from OA= uth 2. I > will describe the attack, list out its preconditions, and then describe a > proposed solution space. We=E2=80=99re looking for input and feedback fro= m the > group on managing this solution. > > But first, many thanks to =C3=85ke Axeland and Adam Omar Oueidat for doin= g this > analysis, putting together the diagram below, and bringing it to the > group=E2=80=99s attention. > > The attack is largely the same as one of the =E2=80=9CAS Mix Up=E2=80=9D = attack cases in > "Comprehensive Security Analysis of OAuth 2.0=E2=80=9D by Daniel Fett and > colleagues. It=E2=80=99s a kind of in-the-middle and/or phishing attack a= t 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 t= o > authorize at HAS but tells UC to use AAS. > 2. UC starts a request at AAS, signed with UC=E2=80=99s key. AAS is imita= ting HAS. > 3. AAS forwards UC=E2=80=99s request parameters (Client nonce, interactio= n finish > URI) to HAS, but signed with AAS=E2=80=99s 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=E2=80=99t 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=E2=80=99ll be using = the > numbers in the text list here like (1) to refer to specific steps. > > > *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=E2=80=99s how it starts talking to AAS in= stead of > HAS. The danger of allowing a client to choose its AS at runtime has been > discussed, but it=E2=80=99s a known pattern that we can=E2=80=99t expect = to go away. > > AAS is treated as a legitimate client of HAS and UC is a legitimate clien= t > 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=E2=80=99s talking to AAS. There is no cryptographic impersonatio= n and no > theft of keys. > > The attack occurs because the user and client think they=E2=80=99re deali= ng with > different AS=E2=80=99s, and you can=E2=80=99t expect a user to always be = able to tell them > apart, especially when the backend calls like (2) are hidden. It=E2=80=99= 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=E2=80=99t necessarily know that AAS is impersonating anyone. > > The token at the end (11), assuming it=E2=80=99s a bound token, is only g= ood with > AAS=E2=80=99s key and not UC=E2=80=99s key. This is great for the attacke= r until UC starts > to act funny and raise suspicion, since the process didn=E2=80=99t ever c= omplete. > 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 appropria= te > times. AAS doesn=E2=80=99t need to generate the hash, but can force HAS t= o generate > an appropriate hash. > > *The proposed mitigation(s): * > > In OAuth 2, the accepted mitigation is to provide another query parameter > with the =E2=80=9Cissuer=E2=80=9D URL of the AS. We could do that here, b= ut that would have > the same downsides: the client has to check this value explicitly. > Therefore we=E2=80=99re proposing that instead we use the existing valida= tion hash > algorithm and add an additional field. This would need to be something > known to UC and HAS that can=E2=80=99t be impersonated by AAS, even if it= =E2=80=99s known. > Therefore, it makes sense to use something that=E2=80=99s 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=E2=80=99s a value that=E2=80=99s know= n but not a > shared-secret that=E2=80=99s passed between parties. The client doesn=E2= =80=99t need to > check anything new, just needs to do the hash validation that it should b= e > 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 mitigatio= n > in place. Additionally, we need to be sure we aren=E2=80=99t accidentally= cutting > off a legitimate use case, like AS bridges and proxies that aren=E2=80=99= t trying > to hide their presence. > > =E2=80=94 Justin > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000009abcb305c4159f0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think that would solve the problem, although i= t might give the user client a second chance to avoid the vulnerability, it= isn't a fix so far as I understand it.

I like Justi= n's writeup, and knowing that it=C2=A0took me some time to appreciate t= he challenge, perhaps reframing the problem might help make it more clear. = (And a real case that has happened)

1. An app netw= ork exists, and anyone can register an app. A malicious app registers a cli= ent with which itself=C2=A0is granted AS-like capabilities to the app netwo= rk. The app pretends to be Google Drive, and the login screen is a perfect = match for google's login.
2. Through a phishing attack, users= are sent an email and directed to login to this malicious app.
3= . The user navigates through the flow and returns to a legit application wi= th an auth code
4. All along this malicious app has been intercep= ting the data the user has been providing and using it to authenticate itse= lf as a valid app. If the user completes the flow the malicious app, will h= ave a valid token for the HAS with the privileges the user thought they wer= e granting the honest app.

At this point the users= client only has two* pieces of information:
* Where the initial = request to start the flow was sent
* The Auth Code

=
To break the vulnerability it must intentionally be so that the = user=C2=A0client does NOT send the auth code to the same place where the in= itial request to start the flow was sent. Which means that the only availab= le piece of information in the auth code.

In OAuth= , it has been introduced to create a third piece of information, the ISS ur= l. Which can be used to look up where to send the auth code. It doesn't= matter what endpoints or secrets are shared, none of them will be of any u= se, because the client is intentionally always communicating with the malic= ious app. The user may not want to, but they are anyway. the PKCE prevents = interception or vulnerabilities in the flow, but this isn't a vulnerabi= lity=C2=A0in the flow, it is a malicious proxy.

Th= e only way to avoid this attack is one of:
* Trust a third party = for verification
* include data in the auth code that the client = can use to identify where to send the auth code
* include data ad= jacent to the auth code which identifies how to handle the auth code
<= div>

Hope that helps.
Warren

Warren Parad

Founder, C= TO

Secure your user data with IAM authorization as a service. Implement= =C2=A0Authress.
=


On Sun, Jun 6, 2021 at 10:21 AM David Cha= dwick <d.w.ch= adwick@verifiablecredentials.info> wrote:
=20 =20 =20

So effectively you are saying that a client can be redirected to anywhere in the world and not know whether this is correct or not, or, it has to assume that it is correct regardless of where it is. In this case I suggest that these two locations should share a secret that they can both give to the client so that it knows these two endpoints are collaborating together. If you use something like the OIDC PKCE scheme then the first endpoint can send the hash of the secret, and the second endpoint can send the secret itself for the client to hash.

Kind regards

David

On 05/06/2021 21:35, Justin Richer wrote:
=20 It=E2=80=99s completely reasonable for any legitimate AS to split the hosting of its user-facing stuff from its backend stuff. Google already does this with OAuth/OIDC today, and expecting this to change to something more constrained would be a non-starter for many deployments. Additionally, we can=E2=80=99t assume that everythi= ng is web-based and that things are happening within a browser. Furthermore, relying on the client to do some kind of comparison between the URL it starts the transaction with and the URL used for interaction is going to lead to misbehaving clients simply being more susceptible to this and related attacks. I=E2=80=99m of th= e school of thought that we should expect the minimum number of very specific things from the client in order to enforce security principles.

=C2=A0=E2=80=94 Justin

On Jun 5, 2021, at 3:43 PM, David Chadwick <d.w.chadwick@verifiablecredentials.info> wrote:

=20

But the start URL has HAS in it (message 5), when the client was talking to AAS. So this should be sufficient should it not to determine that something is wrong? Especially if SOP is being enforced, then the url of HAS and AAS wont have the same origin

Kind regards

David

On 05/06/2021 17:39, Justin Richer wrote:
But that=E2=80=99s what I=E2=80= =99m saying =E2=80=94 the client knows it=E2=80=99s talking to AAS and not HAS so with thi= s kind of solution it would just create a message cryptographically tagged to AAS. And then on the next step, AAS creates a message cryptographically bound to HAS. So even if the client already says =E2=80=9Cthis mes= sage is for AAS=E2=80=9D explicitly, the attack surface doesn= =E2=80=99t change. Only if the client thought it was talking to HAS would this make a difference, but that=E2=80=99s not what=E2=80=99s happening here. This, I believe, is what m= akes this kind of attack much more subtle than a simple message relay.

=C2=A0=E2=80=94 Justin

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

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=E2=80=99s similar to message forwarding, but there=E2=80=99s one important difference =E2=80=94 the AAS alre= ady is modifying the message to HAS. It doesn=E2=80=99t need to forward the complet= e message from (2), it creates a brand new message in (3) and signs it with its own key. So the client knows it=E2=80=99s talki= ng to AAS and vice versa, and AAS knows it=E2=80= =99s talking to HAS and vice versa. What=E2=80= =99s 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=E2=80= =99s something to keep in mind here.

=C2=A0=E2=80=94 Justin

On Jun 5, 2021, at 8:26 AM, David Chadwick <d.w.c= hadwick@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 wee= k, some researchers reached out to the editors to describe an attack against GNAP in the front channel that=E2=80=99s inherited = from OAuth 2. I will describe the attack, list out its preconditions, and then describe a proposed solution space. We=E2=80=99re looking for = input and feedback from the group on managing this solution.

But first, many thanks to =C3=85ke Axeland and Adam Omar Oueidat for doing this analysis, putting together the diagram below, and bringing it to the group=E2=80=99s attention.

The attack is largely the same as one of the =E2=80=9CAS Mix Up=E2=80=9D= attack cases in "Comprehensive Security Analysis=C2=A0of OAuth 2.0=E2= =80=9D by Daniel Fett and colleagues. It=E2=80=99s a kind of in-the-m= iddle and/or phishing attack at its core.=C2=A0

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=E2=80=99s key. AAS is imitat= ing HAS.
3. AAS forwards UC=E2=80=99s request parameters (Client nonce, interaction finish URI) to HAS, but signed with AAS=E2=80=99s key.<= /div>
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=E2=80=99t 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=C2=A0
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=E2=80=99ll be using the numbers in the text list here like (1) to refer to specific steps.

<Pas= tedGraphic-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=E2=80=99s how it sta= rts talking to AAS instead of HAS. The danger of allowing a client to choose its AS at runtime has been discussed, but it=E2=80=99s a known patter= n that we can=E2=80=99t 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=E2= =80=99s talking to AAS. There is no cryptographic impersonation and no theft of keys.=C2=A0

The attack occurs because the user and client think they=E2=80=99re de= aling with different AS=E2=80=99s, an= d you can=E2=80=99t expect a user to always be able to tell them apart, especially when the backend calls like (2) are hidden. It=E2=80=99s assumed th= at 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=E2=80=99t necessarily kn= ow that AAS is impersonating anyone.

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

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=E2=80=99t need to generat= e the hash, but can force HAS to generate an appropriate hash.

The proposed mitigation(s):=C2=A0=

In OAuth 2, the accepted mitigation is to provide another query parameter with the =E2=80=9Ciss= uer=E2=80=9D 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=E2=80=99re proposing that in= stead 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=E2=80=99t be impersonated by AAS, even if it=E2=80=99s known. Therefore, = it makes sense to use something that=E2=80=99s derived. There a= re 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=E2=80=99s= a value that=E2=80=99s known but = not a shared-secret that=E2=80=99s pa= ssed between parties. The client doesn=E2=80=99t 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=E2=80=99t accidentally cutting off a legitimate use case, like AS bridges and proxies that aren=E2=80=99t trying to hide t= heir presence.

=C2=A0=E2=80=94 Justin

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



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