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

[Dick Hardt <[e-mail]>]

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