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

[Fabien Imbault <[e-mail]>]

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
>