Subject: [GNAP] security concerns / issues with data in URLs

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Nov 2020 15:03:57 -0800

Hey Aaron,

In the WG meeting you referenced work in the OAuth WG about removing data
that is in URLs for security reaasons. Would you elaborate on what you were
referring to?

/Dick
ᐧ

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 18 Nov 2020 15:38:02 -0800

I was referring to the work being done to reduce the reliance on the front
channel:

* Dropping the Implicit grant
* Adding PAR to initiate an OAuth request from a POST request instead of GET

---
Aaron Parecki
https://aaronparecki.com

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Nov 2020 17:04:35 -0800

Got it, thanks!

As we know, there is no certainty of who the originator of a redirect was,
and there is no assurance about the integrity or secrecy of the URL
contents.

Those are not the case in GNAP with the client calling the AS -- so what is
the risk of having information in the URL?

You had mentioned the information leaking into logs -- but the AS controls
those logs -- and the logs are a concern, the AS could put an encrypted
token in the URL.

ᐧ

---

From: Leif Johansson <[email-masked]>
Date: Thu, 19 Nov 2020 10:36:52 +0100

On 2020-11-19 02:04, Dick Hardt wrote:
> Got it, thanks!
> 
> As we know, there is no certainty of who the originator of a redirect was, and there is no assurance about the integrity or secrecy of the URL contents.

With my hat off, I heard Aaron say that it helps to keep state out of URLs because
it reduces the risk that state winds up in logs. Its a practical considaration that
imo shouldn't be dismissed out of hand.

	Cheers Leif

---

From: Kyle Larose <[email-masked]>
Date: Thu, 19 Nov 2020 08:12:21 -0500

> imo shouldn't be dismissed out of hand.

As an example of where this is likely to happen, many cloud-based
implementations of HTTP services use reverse proxies for load
balancing amongst other things. These often log requests without
understanding the request's intention.

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 19 Nov 2020 06:55:16 -0800

You asked specifically what work in the OAuth group I was referring to.

While it’s true that those two concerns I pointed out in OAuth are more
specifically about the use of the front channel than the fact that the URL
contains data, there are still concerns with putting data in URLs as
pointed out already in this thread.

The most straightforward issue is that in practice there are often gateways
or reverse proxies in front of servers and they may not be aware of what’s
behind them or that they should avoid logging certain things. While it’s
certainly possible to deploy this in a way that *is* secure and properly
configure it to avoid logging where possible, or encrypt data in the URL
instead of sign it and such, these seem like just additional concerns that
we’ll need to spell out in a security considerations section and are
additional ways that an implementation may end up with security issues.

Since we have the opportunity to recommend the best path for new
developments right now, it feels like we should be taking a more secure
stance on this and avoid creating situations that we need to explain our
way out of while we can.

Aaron Parecki

On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt <[email-masked]> wrote:

> Those are not the case in GNAP with the client calling the AS -- so what
> is the risk of having information in the URL?
>
>> I was referring to the work being done to reduce the reliance on the
>> front channel:
>>
>>> In the WG meeting you referenced work in the OAuth WG about removing
>>> data that is in URLs for security reaasons. Would you elaborate on what you
>>> were referring to?
>>>
>>> /Dick
>>> ᐧ
>>>
>> --
---
Aaron Parecki
https://aaronparecki.com

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Nov 2020 16:47:45 -0800

I agree we should default to a secure stance and not rely on an
implementer to deeply understand all the security considerations.

There is a large difference though between the effort in OAuth and having
state in a URL in GNAP.

In OAuth, an implementation MUST put all the parameters into the redirect.
PAR allows an implementation to not have to do that.

In GNAP, putting state in an "access token" is an implementation choice.
Given the client is authenticating on each subsequent call, the server can
maintain state on its side, which I think will be in the vast majority of
implementations.

wrt. state being in the log -- without the client key, what are the risks
that are different from seeing the URLs and methods?

ᐧ

On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki <[email-masked]> wrote:

> The most straightforward issue is that in practice there are often
> gateways or reverse proxies in front of servers and they may not be aware
> of what’s behind them or that they should avoid logging certain things.
> While it’s certainly possible to deploy this in a way that *is* secure and
> properly configure it to avoid logging where possible, or encrypt data in
> the URL instead of sign it and such, these seem like just additional
> concerns that we’ll need to spell out in a security considerations section
> and are additional ways that an implementation may end up with security
> issues.
>
>> As we know, there is no certainty of who the originator of a redirect
>> was, and there is no assurance about the integrity or secrecy of the URL
>> contents.
>>
>> You had mentioned the information leaking into logs -- but the AS
>> controls those logs -- and the logs are a concern, the AS could put an
>> encrypted token in the URL.
>>
>> ᐧ
>>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 19 Nov 2020 17:19:59 -0800

and
> In GNAP, putting state in an "access token" is an implementation choice.

If we give people the option of doing something a less secure way (putting
state into the URL), then we have to explain all the security
considerations of doing so. By not giving people the option (requiring the
access token be sent in a header) then it's secure by default.

The risk is if these URLs start containing state, e.g. a JWT, then the
contents of the payload may be visible by parties that were not expected to
be able to see them, which may have unintended consequences that are not
obvious right now.

---
Aaron Parecki
https://aaronparecki.com

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Nov 2020 17:24:02 -0800

Let me clarify -- putting state in what the client sends back to the AS is
an implementation choice. The protocol does not have to require it, or
provide it as an option.
ᐧ

On Thu, Nov 19, 2020 at 5:20 PM Aaron Parecki <[email-masked]> wrote:

>> In OAuth, an implementation MUST put all the parameters into the
>> redirect. PAR allows an implementation to not have to do that.
>>
>>>> Those are not the case in GNAP with the client calling the AS -- so
>>>> what is the risk of having information in the URL?
>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 20 Nov 2020 03:28:54 +0100

Hi Dick,

A requirement (must) brings the nice property that it gives no ambiguity in
the protocol. Having 2 ways of doing things here will hurt more than it
solves anything.

Or is there another linked issue you'd like to address (http headers?)
before we can close this one?

Thanks
Fabien

Le ven. 20 nov. 2020 à 02:24, Dick Hardt <[email-masked]> a écrit :

>> If we give people the option of doing something a less secure way
>> (putting state into the URL), then we have to explain all the security
>>> There is a large difference though between the effort in OAuth and
>>> having state in a URL in GNAP.
>>>
>>> wrt. state being in the log -- without the client key, what are the
>>> risks that are different from seeing the URLs and methods?
>>>
>>>
>>>
>>> ᐧ
>>>
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Nov 2020 18:58:42 -0800

Hi Fabien

While I agree that a MUST removes ambiguity -- I'm not sure what issue you
are referring to that can be closed as I was not referring to any specific
issue.

I was getting clarity on what the security issues were in having state in
the URL.

The issue seems to be state information in logs.

While the same issue exists with OAuth redirects, which were held up as an
example in the GNAP WG meeting, there are many more security issues with
the OAuth redirect that do not apply to having state in a GNAP URL.

ᐧ

On Thu, Nov 19, 2020 at 6:29 PM Fabien Imbault <[email-masked]>
wrote:

> Hi Dick,
>
> A requirement (must) brings the nice property that it gives no ambiguity
> in the protocol. Having 2 ways of doing things here will hurt more than it
> solves anything.
>
>> Let me clarify -- putting state in what the client sends back to the AS
>> is an implementation choice. The protocol does not have to require it, or
>> provide it as an option.
>> ᐧ
>>
>>>> In GNAP, putting state in an "access token" is an implementation
>>>> choice. Given the client is authenticating on each subsequent call, the
>>>> server can maintain state on its side, which I think will be in the vast
>>>> majority of implementations.
>>>>
>>>>> While it’s true that those two concerns I pointed out in OAuth are
>>>>> more specifically about the use of the front channel than the fact that the
>>>>> URL contains data, there are still concerns with putting data in URLs as
>>>>>>>> In the WG meeting you referenced work in the OAuth WG about
>>>>>>>> removing data that is in URLs for security reaasons. Would you elaborate on
>>>>>>>> what you were referring to?
>>>>>>>>
>>>>>>>> /Dick
>>>>>>>> ᐧ
>>>>>>>>
>>>>>>> --
>>>>> ---
>>>>> Aaron Parecki
>>>>> https://aaronparecki.com
>>>>>
>>>>> --
>> TXAuth mailing list
>> [email-masked]

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 20 Nov 2020 04:17:27 +0100

I was referring to issue 67, discussed during the call (and during which
Aaron made the comment you're discussing in the current thread).

Fabien

Le ven. 20 nov. 2020 à 03:59, Dick Hardt <[email-masked]> a écrit :

>>>> choice.
>>>>>>> As we know, there is no certainty of who the originator of a
>>>>>>> redirect was, and there is no assurance about the integrity or secrecy of
>>>>>>> the URL contents.
>>>>>>>
>>>>>>>> I was referring to the work being done to reduce the reliance on
>>>>>>>> the front channel:
>>>>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Nov 2020 19:59:56 -0800

Got it.

I have not yet had time to go over the issues and comment. I did look at
67, and I have a fair amount of feedback on it that I hope to provide soon.

ᐧ

On Thu, Nov 19, 2020 at 7:17 PM Fabien Imbault <[email-masked]>
wrote:

>> While I agree that a MUST removes ambiguity -- I'm not sure what issue
>> you are referring to that can be closed as I was not referring to any
>> specific issue.
>>
>> While the same issue exists with OAuth redirects, which were held up as
>> an example in the GNAP WG meeting, there are many more security issues with

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 20 Nov 2020 05:37:23 +0100

Great.

Le ven. 20 nov. 2020 à 05:00, Dick Hardt <[email-masked]> a écrit :

>>> I was getting clarity on what the security issues were in having state
>>> in the URL.
>>>
>>>> A requirement (must) brings the nice property that it gives no
>>>> ambiguity in the protocol. Having 2 ways of doing things here will hurt
>>>> more than it solves anything.
>>>>
>>>>> Let me clarify -- putting state in what the client sends back to the
>>>>> AS is an implementation choice. The protocol does not have to require it,
>>>>> or provide it as an option.
>>>>> ᐧ
>>>>>
>>>>>> The risk is if these URLs start containing state, e.g. a JWT, then
>>>>>> the contents of the payload may be visible by parties that were not
>>>>>> expected to be able to see them, which may have unintended consequences
>>>>>> that are not obvious right now.
>>>>>>
>>>>>> ---
>>>>>> Aaron Parecki
>>>>>> https://aaronparecki.com
>>>>>>
>>>>>>
>>>>>>>>> Those are not the case in GNAP with the client calling the AS --
>>>>>>>>> so what is the risk of having information in the URL?
>>>>>>>>>