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

[Fabien Imbault <[e-mail]>]

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