Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Annabelle, > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle > : > > Torsten, > > I'm not tracking how cookies are relevant to the discussion. I’m still trying to understand why you and others argue mTLS cannot be used in public cloud deployments (and thus focus on application

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

ossession proof in the > token request could be enough). > Any recipient that wishes to validate the token must have the public key for > the AS. > Any recipient that wishes to add a layer must have a public key that is known > to its callers. > Any recipient that perfor

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

 > On 27 Nov 2019, at 20:30, Richard Backman, Annabelle > wrote: >  > > That is true, but is IMO more of a hindrance than an advantage for a PoP > > scheme. The very fact that the signature is valid at every RS is why you > > need additional measures to prevent cross-RS token reuse. > The

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> On 27 Nov 2019, at 19:19, Brian Campbell wrote: > >> On Wed, Nov 27, 2019 at 3:31 AM Neil Madden >> wrote: >> >> That is true, but is IMO more of a hindrance than an advantage for a PoP >> scheme. The very fact that the signature is valid at every RS is why you >> need additional

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On Tue, Nov 26, 2019 at 6:26 PM Richard Backman, Annabelle < richa...@amazon.com> wrote: > > That’s not directly attached to the access token. This means that every > RS has to know about DPoP. > > True, but you could avoid that by embedding the access token in the DPoP > proof (similar to

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On Wed, Nov 27, 2019 at 3:31 AM Neil Madden wrote: > > That is true, but is IMO more of a hindrance than an advantage for a PoP > scheme. The very fact that the signature is valid at every RS is why you > need additional measures to prevent cross-RS token reuse. This downside of > signatures for

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On 27 Nov 2019, at 01:26, Richard Backman, Annabelle wrote: > >  > > That’s not proof of possession, that’s just verifying a MAC. PoP requires > > the other party (client) to provide a fresh proof that they control a key. > > The client isn’t using any key in this case. > > I think we’re

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

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

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

possible with macaroons). Neil > > – > Annabelle Richard Backman > AWS Identity > > > From: Neil Madden > Date: Sunday, November 24, 2019 at 12:56 AM > To: "Richard Backman, Annabelle" > Cc: Brian Campbell , oauth > Subject: Re: [OAUTH-WG] New

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> On 25. Nov 2019, at 17:06, Aaron Parecki wrote: > > I agree, the Facebook issue had nothing to do with extracting access tokens > via a hack, it was entirely facebook’s fault for issuing access tokens > improperly in the first place. They posted some amazing details on what > happened on

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

I agree, the Facebook issue had nothing to do with extracting access tokens via a hack, it was entirely facebook’s fault for issuing access tokens improperly in the first place. They posted some amazing details on what happened on their website. https://about.fb.com/news/2018/09/security-update/

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

+1 -Jared Skype:jaredljennings Signal:+1 816.730.9540 WhatsApp: +1 816.678.4152 On Mon, Nov 25, 2019 at 8:08 AM Neil Madden wrote: > On 25 Nov 2019, at 12:09, Torsten Lodderstedt > wrote: > > > > Hi Neil, > > > >> On 25. Nov 2019, at 12:38, Neil Madden > wrote: > >> > > Do you think we

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On 25 Nov 2019, at 12:09, Torsten Lodderstedt wrote: > > Hi Neil, > >> On 25. Nov 2019, at 12:38, Neil Madden wrote: >> >> But for web-based SPAs and so on, I'm not sure the cost/benefit trade off is >> really that good. The biggest threat for tokens being stolen/misused is >> still XSS,

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Neil, > On 25. Nov 2019, at 12:38, Neil Madden wrote: > > But for web-based SPAs and so on, I'm not sure the cost/benefit trade off is > really that good. The biggest threat for tokens being stolen/misused is still > XSS, and DPoP does nothing to protect against that. It also doesn't

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Dave, > On 25 Nov 2019, at 08:28, Dave Tonge wrote: > > Hi Neil and Torsten > > I agree that the risk is about token theft / leakage. My understanding is > that we should assume that at some point access tokens will be leaked, > e.g.Facebook: >

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Neil and Torsten I agree that the risk is about token theft / leakage. My understanding is that we should assume that at some point access tokens will be leaked, e.g.Facebook: https://auth0.com/blog/facebook-access-token-data-breach-early-look/ If access tokens were cryptographically

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On 24 Nov 2019, at 07:59, Torsten Lodderstedt wrote: > > Hi Neil, > > I would like to summarize what I believe to have understood is your opinion > before commenting: > 1) audience restricted access tokens is the way to cope with replay attempts > between RSs It’s one way, but yes that is

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

ovember 22, 2019 at 3:09 PM > To: "Richard Backman, Annabelle" > Cc: Brian Campbell , oauth > Subject: Re: [OAUTH-WG] New Version Notification for > draft-fett-oauth-dpop-03.txt > > > > On 22 Nov 2019, at 01:42, Richard Backman, Annabelle > wrote: &

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Neil, I would like to summarize what I believe to have understood is your opinion before commenting: 1) audience restricted access tokens is the way to cope with replay attempts between RSs 2) TLS prevents replay at the same RS re 1) that works as long as ASs support audience restrictions

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On 22 Nov 2019, at 13:33, Torsten Lodderstedt wrote: > > Hi Neil, > >> On 22. Nov 2019, at 20:50, Neil Madden wrote: >> >> Hi Torsten, >> >>> On 22 Nov 2019, at 12:15, Torsten Lodderstedt >>> wrote: >>> >>> Hi Neil, >>> On 22. Nov 2019, at 18:08, Neil Madden wrote: I

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> On 23. Nov 2019, at 00:34, Richard Backman, Annabelle > 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

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> 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

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle > 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

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

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

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle > 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

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Neil, > On 22. Nov 2019, at 20:50, Neil Madden wrote: > > Hi Torsten, > > On 22 Nov 2019, at 12:15, Torsten Lodderstedt wrote: >> >> Hi Neil, >> >>> On 22. Nov 2019, at 18:08, Neil Madden wrote: >>> >>> I think the phrase "token replay" is ambiguous. Traditionally it refers to >>> an

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Torsten, On 22 Nov 2019, at 12:15, Torsten Lodderstedt wrote: > > Hi Neil, > >> On 22. Nov 2019, at 18:08, Neil Madden wrote: >> >> 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 >>

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

eil Madden > Date: Friday, November 22, 2019 at 3:09 PM > To: "Richard Backman, Annabelle" > Cc: Brian Campbell , oauth > Subject: Re: [OAUTH-WG] New Version Notification for > draft-fett-oauth-dpop-03.txt > > On 22 Nov 2019, at 01:42, Richard Backman, Annabelle >

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

pbell Cc: oauth Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt At the end of my previous email I mentioned that you can achieve some of the same aims as DPoP without needing a PoP mechanism at all. This email is that follow-up. OAuth is agnostic about the format

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> > Petteri > > Fetch API - https://fetch.spec.whatwg.org/ > > -Original Message- > From: OAuth On Behalf Of Torsten Lodderstedt > Sent: perjantai 22. marraskuuta 2019 10.54 > To: Mike Jones > Cc: oauth ; Torsten Lodderstedt > ; Rob Otto > > Subject: Re: [OA

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Neil, > On 22. Nov 2019, at 18:08, Neil Madden wrote: > > On 22 Nov 2019, at 07:53, Torsten Lodderstedt > wrote: >> >> >> >>> On 22. Nov 2019, at 15:24, Justin Richer wrote: >>> >>> I’m going to +1 Dick and Annabelle’s question about the scope here. That >>> was the one major thing

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Lodderstedt ; Rob Otto Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt I couldn't agree more. I think we should, again, try to find a way to utilise TLS in the browser as well. > On 22. Nov 2019, at 16:50, Mike Jones > wrote: > > I he

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

It's not a different threat profile. This is the same assumption people made when introducing HttpOnly cookies, which just led to attackers switching to proxy everything through the browser as per things like https://beefproject.com . (This is actually nicer for the

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

The main concern about token replay in a SPA is that the access token may be extracted from the app, such as via XSS. Using the Web Crypto API has the advantage of being able to generate a public private key pair where the JS code can't access the private key at all, it can only be used to sign

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On 22 Nov 2019, at 07:53, Torsten Lodderstedt wrote: > > > >> On 22. Nov 2019, at 15:24, Justin Richer 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

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On 22 Nov 2019, at 07:13, Dick Hardt wrote: > > On Fri, Nov 22, 2019 at 3:08 PM Neil Madden > wrote: > On 22 Nov 2019, at 01:42, Richard Backman, Annabelle > wrote: >> There are key distribution challenges with that if you are doing

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> *Cc:* oauth > *Subject:* [EXTERNAL] Re: [OAUTH-WG] New Version Notification for > draft-fett-oauth-dpop-03.txt > > Hi Rob, > > > On 22. Nov 2019, at 16:10, Rob Otto 40pingidentity@dmarc.ietf.org> wrote: > > > > Hi Torsten - thanks for the reply.. >

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

ct: [EXTERNAL] Re: [OAUTH-WG] New Version Notification for > draft-fett-oauth-dpop-03.txt > > Hi Rob, > > > On 22. Nov 2019, at 16:10, Rob Otto > > wrote: > > > > Hi Torsten - thanks for the reply.. > > > > Responses in line. > > > > Grüsse

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Sent: Friday, November 22, 2019 4:20:58 PM To: Rob Otto Cc: oauth Subject: [EXTERNAL] Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt Hi Rob, > On 22. Nov 2019, at 16:10, Rob Otto > wrote: > > Hi Torsten - thanks for the reply.. > > Responses i

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Rob, > On 22. Nov 2019, at 16:10, Rob Otto > wrote: > > Hi Torsten - thanks for the reply.. > > Responses in line. > > Grüsse > Rob > > On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt > wrote: > Hi Rob, > > > On 22. Nov 2019, at 15:52, Rob Otto > > wrote: > > > > Hi everyone > >

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Rob, I agree that managing roots of trust, validating/OCSP etc is not "easy" per se, but the MTLS setup gets really simple with the Self-Signed Certificate Mutual-TLS Method and we made sure combined traffic is simple to signal by

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Torsten - thanks for the reply. Responses in line. Grüsse Rob On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt wrote: > Hi Rob, > > > On 22. Nov 2019, at 15:52, Rob Otto 40pingidentity@dmarc.ietf.org> wrote: > > > > Hi everyone > > > > I'd agree with this. I'm looking at DPOP as an

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

I agree with Torsten, plus we're getting sender-constrained refresh tokens for said public clients and SPAs so that the AS doesn't have to (according to the browser based apps draft) rotate them, we all know the pain SPA developers have with those. S pozdravem, *Filip Skokan* On Fri, 22 Nov

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

and sender constrained tokens. best regards, Torsten. > > -- Mike > > -Original Message- > From: OAuth On Behalf Of Torsten Lodderstedt > Sent: Thursday, November 21, 2019 11:54 PM > To: Justin Richer > Cc: oauth > Subject: [E

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Version Notification for draft-fett-oauth-dpop-03.txt > On 22. Nov 2019, at 15:24, Justin Richer 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’

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Rob, > On 22. Nov 2019, at 15:52, Rob Otto > wrote: > > Hi everyone > > I'd agree with this. I'm looking at DPOP as an alternative and ultimately > simpler way to accomplish what we can already do with MTLS-bound Access > Tokens, for use cases such as the ones we address in Open

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi everyone I'd agree with this. I'm looking at DPOP as an alternative and ultimately simpler way to accomplish what we can already do with MTLS-bound Access Tokens, for use cases such as the ones we address in Open Banking; these are API transactions that demand a high level of assurance and as

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

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

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On Fri, Nov 22, 2019 at 3:08 PM Neil Madden wrote: > On 22 Nov 2019, at 01:42, Richard Backman, Annabelle > wrote: > > There are key distribution challenges with that if you are doing > validation at the RS, but validation at the RS using either approach means > you’ve lost protection against

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

e: Friday, November 22, 2019 at 4:40 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] New Version Notification for > draft-fett-oauth-dpop-03.txt > > At the end of my previous email I mentioned that you can achieve some of the > same aims as DPoP without needing

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Notification for draft-fett-oauth-dpop-03.txt At the end of my previous email I mentioned that you can achieve some of the same aims as DPoP without needing a PoP mechanism at all. This email is that follow-up. OAuth is agnostic about the format of access tokens and many vendors support either

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

At the end of my previous email I mentioned that you can achieve some of the same aims as DPoP without needing a PoP mechanism at all. This email is that follow-up. OAuth is agnostic about the format of access tokens and many vendors support either random string database tokens or JWTs. But

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Yeah, suggestions and/or an MTI about algorithm support would probably be worthwhile. Perhaps also some defined means of signaling when an unsupported algorithm is used along with any other reason a DPoP is invalid or rejected. There are a lot of tradeoffs in what claims are required and what

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Thanks for the reply, Brian. Collecting my thoughts up here rather than responding blow by blow. Public key signatures are simpler in some respects, more complex in others. There are currently 10 public key JWS signature schemes defined (ES256/384/512, RS256/384/512, PS256/384/512, EdDSA) -

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On Thu, Nov 14, 2019 at 7:20 PM Neil Madden wrote: > I can't attend Singapore either in person or remotely due to other > commitments. I broadly support adoption of this draft, but I have some > comments/suggestions about it. > Thanks Neil. And sorry to hear that you won't be in Singapore. This

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> Am 17.11.2019 um 04:06 schrieb David Waite : > > You’ll be audience-scoping either way, so it may make sense to use a > symmetric algorithm for both. It starts to look like kerberos in HTTP and > JSON when you squint. Even if audience restriction is a recommended practice, I‘m not fully

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On Nov 15, 2019, at 8:32 AM, Paul Querna wrote: > Supporting `HS256` or similar signing of the proof would be one way to > reduce the CPU usage concerns. There are a number of other potential asymmetrically signed messages, such as the access token. Is the assumption that these are also

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

A few comments below. On 15 Nov 2019, at 15:32, Paul Querna wrote: > > Echoing Neil's concerns, I posted this to the issue tracker: > https://github.com/danielfett/draft-dpop/issues/56 > > I've been talking to several large scale API operators about DPoP. A > consistent concern is the CPU

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Echoing Neil's concerns, I posted this to the issue tracker: https://github.com/danielfett/draft-dpop/issues/56 I've been talking to several large scale API operators about DPoP. A consistent concern is the CPU cost of doing an asymmetric key validation on every HTTP Request at the RS.

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

I can't attend Singapore either in person or remotely due to other commitments. I broadly support adoption of this draft, but I have some comments/suggestions about it. Section 2 lists the main objective as being to harden against compromised/malicious AS or RS, which may attempt to replay