Subject: [GNAP] Mix Up Attack against GNAP

From: Justin Richer <[email-masked]>
Date: Fri, 4 Jun 2021 10:59:36 -0400

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.

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

---

From: David Chadwick <[email-masked]>
Date: Sat, 5 Jun 2021 13:26:43 +0100

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

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.

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.

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)

- 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

---

From: Justin Richer <[email-masked]>
Date: Sat, 5 Jun 2021 10:51:59 -0400

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 <[email-masked]> 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:
> -- 
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Sat, 5 Jun 2021 12:39:51 -0400

But that’s what I’m saying — the client knows it’s 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 says “this message is for AAS” explicitly, the attack surface doesn’t change. Only if the client thought it was talking to HAS would this make a difference, but that’s not what’s happening here. This, I believe, is what makes this kind of attack much more subtle than a simple message relay.

 — Justin

> On Jun 5, 2021, at 11:09 AM, David Chadwick <[email-masked]> 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,
>> 
>>> On Jun 5, 2021, at 8:26 AM, David Chadwick <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>

---

From: David Chadwick <[email-masked]>
Date: Sat, 5 Jun 2021 16:09:28 +0100

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
<[email-masked]>
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.

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.

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)

- 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

[email-masked]

---

From: David Chadwick <[email-masked]>
Date: Sat, 5 Jun 2021 20:43:39 +0100

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’s what I’m saying — the client knows it’s 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 says “this message is for AAS”
explicitly, the attack surface doesn’t change. Only if the client
thought it was talking to HAS would this make a difference, but
that’s not what’s happening here. This, I believe, is what makes
this kind of attack much more subtle than a simple message relay.

— Justin

On Jun 5, 2021, at 11:09 AM, David Chadwick
<[email-masked]>
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’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 <[email-masked]>
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.

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

[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Sat, 5 Jun 2021 16:35:26 -0400

It’s 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’t assume that everything 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’m of the school of thought that we should expect the minimum number of very specific things from the client in order to enforce security principles.

 — Justin

> On Jun 5, 2021, at 3:43 PM, David Chadwick <[email-masked]> 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:
>>> On Jun 5, 2021, at 11:09 AM, David Chadwick <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Justin
>>>

---

From: David Chadwick <[email-masked]>
Date: Sun, 6 Jun 2021 09:20:44 +0100

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:

It’s 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’t assume that everything 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’m of the
school of thought that we should expect the minimum number of very
specific things from the client in order to enforce security
principles.

— Justin

On Jun 5, 2021, at 3:43 PM, David Chadwick
<[email-masked]>
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’s what I’m saying — the client
knows it’s 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 says “this message
is for AAS” explicitly, the attack surface doesn’t
change. Only if the client thought it was talking to
HAS would this make a difference, but that’s not
what’s happening here. This, I believe, is what makes
this kind of attack much more subtle than a simple
message relay.

— Justin

On Jun 5, 2021, at 11:09 AM, David
Chadwick <[email-masked]>
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’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 <[email-masked]>
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.

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

[email-masked]

---

From: Warren Parad <[email-masked]>
Date: Sun, 6 Jun 2021 11:33:43 +0200

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 <https://authress.io/>.

On Sun, Jun 6, 2021 at 10:21 AM David Chadwick <
[email-masked]> 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 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:
>
> It’s 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’t assume that everything 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’m of the school of thought that
> we should expect the minimum number of very specific things from the client
> in order to enforce security principles.
>
>  — Justin
>
> On Jun 5, 2021, at 3:43 PM, David Chadwick <
> [email-masked]> 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
> But that’s what I’m saying — the client knows it’s 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 says
> “this message is for AAS” explicitly, the attack surface doesn’t change.
> Only if the client thought it was talking to HAS would this make a
> difference, but that’s not what’s happening here. This, I believe, is what
> makes this kind of attack much more subtle than a simple message relay.
>
>  — Justin
>
> On Jun 5, 2021, at 11:09 AM, David Chadwick <
> [email-masked]> 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
> 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 <
> [email-masked]> 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
> 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.
> 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.
> 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.
>
> *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
> 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 continuation endpoint that the client instance will send the
> interaction reference to. (This might be different from the above)
> - 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
> [email-masked]

---

From: David Chadwick <[email-masked]>
Date: Sun, 6 Jun 2021 12:10:37 +0100

My understanding is that all these types of federated systems
with redirections: SAML, Oauth, OIDC, are open to phishing
attacks. To counteract this you should remove redirections from
the protocol. OIDC SIOPv2 with verifiable
credentials/presentations should solve this type of attack I
believe. Also it is using a TTP for verification, which is one of
your proposed solutions.

Your proposed solution of adding data to the auth code is what I
have already suggested: the message should  cryptographically
contain the identity of the sender and receiver and then all
parties know who the intended recipient and originator are. And if
you want to add a redirection in the response then that should
also be inside the protected message.

Kind regards

David

On 06/06/2021 10:33, Warren Parad
wrote:

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:

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

* 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 <[email-masked]>
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 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

It’s 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’t assume that everything
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’m of the school
of thought that we should expect the minimum number of
very specific things from the client in order to enforce
security principles.

— Justin

On Jun 5, 2021, at 3:43 PM, David Chadwick <[email-masked]>
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

But that’s what I’m
saying — the client knows it’s 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 says “this
message is for AAS” explicitly, the attack
surface doesn’t change. Only if the client
thought it was talking to HAS would this make
a difference, but that’s not what’s happening
here. This, I believe, is what makes this kind
of attack much more subtle than a simple
message relay.

— Justin

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

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 <[email-masked]>
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.

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

[email-masked]

--

TXAuth mailing list

[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Sun, 6 Jun 2021 12:42:38 +0000

David, 

A key difference with GNAP is that it doesn't rely only on redirects. Instead they are just one of many extensible options for interaction. Presenting VC's can happen using VCHTTPAPI or CHAPI or even DIDCOMM and the user never redirects. Redirects are inherently phishable even with the mitigation you describe, and so if you want to avoid them and use something else, that's great and GNAP has space for that explicitly. It's one of the most important breaks from OAuth core: don't start with the assumption the user is in a browser. But redirects aren't going away for everyone and so it's important that when people do choose to use them, they are as secure as they can be. You still have to deal with the trade-off and that's why security analysis like this is so important! 

- Justin
________________________________________
From: TXAuth [[email-masked]] on behalf of David Chadwick [[email-masked]]
Sent: Sunday, June 6, 2021 7:10 AM
To: [email-masked]
Subject: Re: [GNAP] Mix Up Attack against GNAP

My understanding is that all these types of federated systems with redirections: SAML, Oauth, OIDC, are open to phishing attacks. To counteract this you should remove redirections from the protocol. OIDC SIOPv2 with verifiable credentials/presentations should solve this type of attack I believe. Also it is using a TTP for verification, which is one of your proposed solutions.

Your proposed solution of adding data to the auth code is what I have already suggested: the message should  cryptographically contain the identity of the sender and receiver and then all parties know who the intended recipient and originator are. And if you want to add a redirection in the response then that should also be inside the protected message.

Kind regards

David

On 06/06/2021 10:33, Warren Parad wrote:
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.

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

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO

Secure your user data with IAM authorization as a service. Implement Authress<https://authress.io/>.

On Sun, Jun 6, 2021 at 10:21 AM David Chadwick <[email-masked]<mailto:[email-masked]>> 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 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

 — Justin

On Jun 5, 2021, at 3:43 PM, David Chadwick <[email-masked]<mailto:[email-masked]>> wrote:

Kind regards

David

 — Justin

On Jun 5, 2021, at 11:09 AM, David Chadwick <[email-masked]<mailto:[email-masked]>> wrote:

Hi Justin

Kind regards

David

 — Justin

On Jun 5, 2021, at 8:26 AM, David Chadwick <[email-masked]<mailto:[email-masked]>> wrote:

Kind regards

David

Requested feedback:

 — Justin

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 7 Jun 2021 14:08:33 -0400

David,

I’m not sure that we’re on the same page yet, and I want to make sure that I am (personally) not missing something important in this discussion. Can you please lay out in more detail what your proposed mitigation to this attack would look like, given the diagram/flow at the top of the thread? What pieces of information would each party need access to, and how does it stop the vulnerability?

Thank you,
 — Justin

> On Jun 6, 2021, at 7:10 AM, David Chadwick <[email-masked]> wrote:
> 
>> Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>.
>> 
>> 
>> On Sun, Jun 6, 2021 at 10:21 AM David Chadwick <[email-masked] <mailto:[email-masked]>> wrote:
>>>> On Jun 5, 2021, at 3:43 PM, David Chadwick <[email-masked] <mailto:[email-masked]>> wrote:
>>>>

---

From: David Chadwick <[email-masked]>
Date: Mon, 7 Jun 2021 21:02:44 +0100

Hi Justin

I thought that a resolution had been reached, which is why I did
not respond to Warren's message. If the auth code contains the
sender, recipient and the redirection destination, all
cryptographically protected, then it should be watertight.

Kind regards

David

On 07/06/2021 19:08, Justin Richer
wrote:

David,

I’m not sure that we’re on the same page yet, and I
want to make sure that I am (personally) not missing something
important in this discussion. Can you please lay out in more
detail what your proposed mitigation to this attack would look
like, given the diagram/flow at the top of the thread? What
pieces of information would each party need access to, and how
does it stop the vulnerability?

Thank you,

— Justin

On Jun 6, 2021, at 7:10 AM, David Chadwick
<[email-masked]>
wrote:

My understanding is that all these types of
federated systems with redirections: SAML, Oauth,
OIDC, are open to phishing attacks. To counteract this
you should remove redirections from the protocol. OIDC
SIOPv2 with verifiable credentials/presentations
should solve this type of attack I believe. Also it is
using a TTP for verification, which is one of your
proposed solutions.

Your proposed solution of adding data to the
auth code is what I have already suggested: the
message should  cryptographically contain the identity
of the sender and receiver and then all parties know
who the intended recipient and originator are. And if
you want to add a redirection in the response then
that should also be inside the protected message.

Kind regards

David

On 06/06/2021 10:33, Warren
Parad wrote:

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:

* 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 <[email-masked]>
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
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

It’s
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’t assume that everything
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’m
of the school of thought that we should expect
the minimum number of very specific things
from the client in order to enforce security
principles.

— Justin

On Jun 5, 2021, at 3:43
PM, David Chadwick <[email-masked]>
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’s what I’m saying — the
client knows it’s 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 says
“this message is for AAS”
explicitly, the attack surface
doesn’t change. Only if the client
thought it was talking to HAS
would this make a difference, but
that’s not what’s happening here.
This, I believe, is what makes
this kind of attack much more
subtle than a simple message
relay.

— Justin

On Jun 5,
2021, at 11:09 AM, David

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

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.

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

[email-masked]

--

TXAuth mailing list

[email-masked]

--

TXAuth mailing list

[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Mon, 7 Jun 2021 16:15:06 -0400

Thank you for clarifying, and thanks for the feedback and discussion on the attack and proposal!

 — Justin

> On Jun 7, 2021, at 4:02 PM, David Chadwick <[email-masked]> wrote:
> 
> Hi Justin
> 
> I thought that a resolution had been reached, which is why I did not respond to Warren's message. If the auth code contains the sender, recipient and the redirection destination, all cryptographically protected, then it should be watertight.
> 
> Kind regards
> 
> David
> 
> On 07/06/2021 19:08, Justin Richer wrote:
>> David,
>> 
>>> On Jun 6, 2021, at 7:10 AM, David Chadwick <[email-masked] <mailto:[email-masked]>> wrote:
>>>