> how are cookies protected from leakage, replay, injection in a setup like
> this?
They aren't. But my primary concern here isn't web browser traffic, it's calls
from services/apps running inside a corporate network to services outside a
corporate network (e.g., service-to-service API calls that pass through a
corporate TLS gateway).
> That’s a totally valid point. But again, such a solution makes the life of
> client developers harder.
> I personally think, we as a community need to understand the pros and cons of
> both approaches. I also think we have not even come close to this point,
> which, in my option, is the prerequisite for making informed decisions.
Agreed. It's clear that there are a number of parties coming at this from a
number of different directions, and that's coloring our perceptions. That's why
I think we need to nail down the scope of what we're trying to solve with DPoP
before we can have a productive conversation how it should work.
–
Annabelle Richard Backman
AWS Identity
On 11/22/19, 10:51 PM, "Torsten Lodderstedt" <tors...@lodderstedt.net> wrote:
> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle
<richanna=40amazon....@dmarc.ietf.org> wrote:
>
> The service provider doesn't own the entire connection. They have no
control over corporate or government TLS gateways, or other terminators that
might exist on the client's side. In larger organizations, or when cloud
hosting is involved, the service team may not even own all the hops on their
side.
how are cookies protected from leakage, replay, injection in a setup like
this?
> While presumably they have some trust in them, protection against leaked
bearer tokens is an attractive defense-in-depth measure.
That’s a totally valid point. But again, such a solution makes the life of
client developers harder.
I personally think, we as a community need to understand the pros and cons
of both approaches. I also think we have not even come close to this point,
which, in my option, is the prerequisite for making informed decisions.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> On 11/22/19, 9:37 PM, "OAuth on behalf of Torsten Lodderstedt"
<oauth-boun...@ietf.org on behalf of torsten=40lodderstedt....@dmarc.ietf.org>
wrote:
>
>
>
>> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle
<richanna=40amazon....@dmarc.ietf.org> wrote:
>>
>> The dichotomy of "TLS working" and "TLS failed" only applies to a single
TLS connection. In non-end-to-end TLS environments, each TLS terminator between
client and RS introduces additional token leakage/exfiltration risk,
irrespective of the quality of the TLS connections themselves. Each terminator
also introduces complexity for implementing mTLS, Token Binding, or any other
TLS-based sender constraint solution, which means developers with
non-end-to-end TLS use cases will be more likely to turn to DPoP.
>
> The point is we are talking about different developers here. The
client developer does not need to care about the connection between proxy and
service. She relies on the service provider to get it right. So the developers
(or DevOps or admins) of the service provider need to ensure end to end
security. And if the path is secured once, it will work for all clients.
>
>> If DPoP is intended to address "cases where neither mTLS nor OAuth Token
Binding are available" [1], then it should address this risk of token leakage
between client and RS. If on the other hand DPoP is only intended to support
the SPA use case and assumes the use of end-to-end TLS, then the document
should be updated to reflect that.
>
> I agree.
>
>>
>> [1]: https://tools.ietf.org/html/draft-fett-oauth-dpop-03#section-1
>>
>> –
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>> On 11/22/19, 8:17 PM, "OAuth on behalf of Torsten Lodderstedt"
<oauth-boun...@ietf.org on behalf of torsten=40lodderstedt....@dmarc.ietf.org>
wrote:
>>
>> Hi Neil,
>>
>>> On 22. Nov 2019, at 18:08, Neil Madden <neil.mad...@forgerock.com>
wrote:
>>>
>>> On 22 Nov 2019, at 07:53, Torsten Lodderstedt
<torsten=40lodderstedt....@dmarc.ietf.org> wrote:
>>>>
>>>>
>>>>
>>>>> On 22. Nov 2019, at 15:24, Justin Richer <jric...@mit.edu> wrote:
>>>>>
>>>>> I’m going to +1 Dick and Annabelle’s question about the scope here.
That was the one major thing that struck me during the DPoP discussions in
Singapore yesterday: we don’t seem to agree on what DPoP is for. Some
(including the authors, it seems) see it as a quick point-solution to a
specific use case. Others see it as a general PoP mechanism.
>>>>>
>>>>> If it’s the former, then it should be explicitly tied to one specific
set of things. If it’s the latter, then it needs to be expanded.
>>>>
>>>> as a co-author of the DPoP draft I state again what I said yesterday:
DPoP is a mechanism for sender-constraining access tokens sent from SPAs only.
The threat to be prevented is token replay.
>>>
>>> I think the phrase "token replay" is ambiguous. Traditionally it refers
to an attacker being able to capture a token (or whole requests) in use and
then replay it against the same RS. This is already protected against by the
use of normal TLS on the connection between the client and the RS. I think
instead you are referring to a malicious/compromised RS replaying the token to
a different RS - which has more of the flavour of a man in the middle attack
(of the phishing kind).
>>
>> I would argue TLS basically prevents leakage and not replay. The
threats we try to cope with can be found in the Security BCP. There are
multiple ways access tokens can leak, including referrer headers, mix-up, open
redirection, browser history, and all sorts of access token leakage at the
resource server
>>
>> Please have a look at
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.
>>
>>
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8
also has an extensive discussion of potential counter measures, including
audience restricted access tokens and a conclusion to recommend sender
constrained access tokens over other mechanisms.
>>
>>>
>>> But if that's the case then there are much simpler defences than those
proposed in the current draft:
>>>
>>> 1. Get separate access tokens for each RS with correct audience and
scopes. The consensus appears to be that this is hard to do in some cases,
hence the draft.
>>
>> How many deployments do you know that today are able to issue
RS-specific access tokens?
>> BTW: how would you identify the RS?
>>
>> I agree that would be an alternative and I’m a great fan of such
tokens (and used them a lot at Deutsche Telekom) but in my perception this
pattern needs still to be established in the market. Moreover, they basically
protect from a rough RS (if the URL is used as audience) replaying the token
someplace else, but they do not protect from all other kinds of leakage/replay
(e.g. log files).
>>
>>> 2. Make the DPoP token be a simple JWT with an "iat" and the origin of
the RS. This stops the token being reused elsewhere but the client can reuse it
(replay it) for many requests.
>>> 3. Issue a macaroon-based access token and the client can add a correct
audience and scope restrictions at the point of use.
>>
>> Why is this needed if the access token is already audience restricted?
Or do you propose this as alternative?
>>
>>>
>>> Protecting against the first kind of replay attacks only becomes an
issue if we assume the protections in TLS have failed. But if DPoP is only
intended for cases where mTLS can't be used, it shouldn't have to protect
against a stronger threat model in which we assume that TLS security has been
lost.
>>
>> I agree.
>>
>> best regards,
>> Torsten.
>>
>>>
>>> -- Neil
>>
>>
>>
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
