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

[Fabien Imbault <[e-mail]>]

Great.

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

> 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 <[e-mail]>
> wrote:
>
>> 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 <[e-mail]> a écrit :
>>
>>> 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 <[e-mail]>
>>> 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.
>>>>
>>>> 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 <[e-mail]> a
>>>> écrit :
>>>>
>>>>> 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 <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> These statements are in conflict with each other:
>>>>>>
>>>>>> > I agree we should default to a secure stance and not rely on an
>>>>>> implementer to deeply understand all the security considerations.
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> 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 <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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 <[e-mail]>
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> ᐧ
>>>>>>>>>
>>>>>>>>> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki <[e-mail]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt <[e-mail]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> ᐧ
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>> ---
>>>>>>>> Aaron Parecki
>>>>>>>> https://aaronparecki.com
>>>>>>>>
>>>>>>>> --
>>>>> TXAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>