Torsten,
I'm not tracking how cookies are relevant to the discussion. I'm guessing
that's because we're not on the same page regarding use cases, so allow me to
clearly state mine:
The use case I am concerned with is requests between services where end-to-end
TLS cannot be guaranteed. For example, an enterprise service running
on-premise, communicating with a service in the cloud, where the enterprise's
outbound traffic is routed through a TLS Inspection (TLSI) appliance. The TLSI
appliance sits in the middle of the communication, terminating the TLS session
established by the on-premise service and establishing a separate TLS
connection with the cloud service.
In this kind of environment, there is no end-to-end TLS connection between
on-premise service and cloud service, and it is very unlikely that the TLSI
appliance is configurable enough to support TLS-based sender-constraint
mechanisms without significantly compromising on the scope of "sender" (e.g.,
"this service at this enterprise" becomes "this enterprise"). Even if it is
possible, it is likely to require advanced configuration that is non-trivial
for administrators to deploy. It's no longer as simple as the developer passing
a self-signed certificate to the HTTP stack.
–
Annabelle Richard Backman
AWS Identity
On 11/23/19, 9:50 AM, "Torsten Lodderstedt" <tors...@lodderstedt.net> wrote:
> On 23. Nov 2019, at 00:34, Richard Backman, Annabelle
<richa...@amazon.com> wrote:
>
>> how are cookies protected from leakage, replay, injection in a setup
like this?
> They aren’t.
Thats very interesting when compared to what we are discussing with respect
to API security.
It effectively means anyone able to capture a session cookie, e.g. between
TLS termination point and application, by way of an HTML injection, or any
other suitable attack is able to impersonate a legitimate user by injecting the
cookie(s) in an arbitrary user agent. The impact of such an attack might be
even worse than abusing an access token given the (typically) broad scope of a
session.
TLS-based methods for sender constrained access tokens, in contrast,
prevent this type of replay, even if the requests are protected between client
and TLS terminating proxy, only. Ensuring the authenticity of the client
certificate when forwarded from TLS terminating proxy to service, e.g. through
another authenticated TLS connection, will even prevent injection within the
data center/cloud environment.
I come to the conclusion that we already have the mechanism at hand to
implement APIs with a considerable higher security level than what is accepted
today for web applications. So what problem do we want to solve?
> 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).
Can you please describe the challenges arising in these settings? I assume
those proxies won’t support CONNECT style pass through otherwise we wouldn’t
talk about them.
>
>> 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.
We will do so.
>
> –
> 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
