Skip to main content

Minutes interim-2021-oauth-01: Mon 12:00
minutes-interim-2021-oauth-01-202103151200-01

Meeting Minutes Web Authorization Protocol (oauth) WG
Date and time 2021-03-15 16:00
Title Minutes interim-2021-oauth-01: Mon 12:00
State Active
Other versions markdown
Last updated 2021-03-17

minutes-interim-2021-oauth-01-202103151200-01

OAuth WG Interim Meeting - DPoP

Date

15 March 2021

Notes

Note takers: Hannes and Tony

Topic

OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)
Presenter: Brian Campbell
Slides: DPoP Slides

Rifaat starts the meeting with an outlook of the upcoming virtual interim meetings.

Brian goes through his DPoP slides. He mentions the open issues, which can be found in the slide deck - slide #14ff.

Freshness & Signature Coverage: Mike looked at the internal Microsoft implementation, which aims to prevent malware from minting tokens, and it offers a server provided nonce. The nonce is provided by an "unauthenticated" response, which includes the nonce. A new nonce is provided in the 200 OK. The first nonce requires an extra roundtrip. Mike will find out the details and will send the details to the list.

Justin to talk about the OAuth PoP draft and HTTP Signing. He believed that the DPoP is (deliberately) a point-solution. Are there easy bits in DPoP that can have positive contributions?

Brian talks about the different approaches to address the freshness properties, which triggered a response from Francis Pouatcha on chat saying "Incorporating a hash of the request in the proof might solve this problem (or atleat limit it down to rplay)"

Justin (on chat) responsed that "the problem isn't the hash, the problem is normalization of the request so that the hash is at all meaningful. This is what we're trying to do with HTTP Message Signatures. DPoP takes a decidedly limited approach to this, with a specific set of tradeoffs."

Francis says "This is what was solved with SHIMP. This will be a meaningfull complement to make it solid enougth for the interdented purpose. Without being a replacement for HTTP Signature."

Francis believes that DPoP needs the extension offered by SHIMP. SHIMP is Simple HTTP Message Integrity Protocol.

Brian does not believe SHIMP provides any benefits for this specific problem but adds lots of complexity.

Justin: +1 to what Brian says. The problem with the HTTP message signing is the normalization. My preference for DPoP to have it be very simple access token hash. This does not get into the normalization of the message.

I am working with Annabell on the HTTP signature spec. I hope to get an RFC this year.

Francis: DPoP should be by no way a replacement for HTTP signing. Agrees with Mike about the nonce aspect.

Hannes: Will HTTP signing be finished ealier than DPoP

Justin: General purpose HTTP signing has lots of corner cases. DPoP should remain simple & extensible. He sees DPoP as a building block that offers

Here are my backup notes:

Overview

New header added – DPOP Proof, to provide a POP, it’s a JWT, only supports asymmetric key pair
Crypto agility provided.
Negotiation exchange challenge/response messages – errors and negotiations

Path forward for open issues

No new draft since last meeting, there are a few open issues
1. Refresh issue, claim that there is a chance that the proof can be replayed as there is no timeliness since there are sever input. Mike J. says that their implementation includes sever nonce, the nonce can be reused, there can be a new nonce in the 200 response, thus 1 extra trip for the first nonce and no additional after that. Brian asked how that the nonce was conveyed, Mike will get back.
a. Maybe its OK as it is? Maybe suggest key rotation that will be sufficient.
b. incorporate a hash of the access token
c. Allow server to supply nonce (like what Mike had suggested)
Brian, way forward is editorial changes, that describe the attack and using key rotation and leave it as that.

DPOP should not be a replacement for http signing. There has been progress in HTTP signing. DPDP was meant to be a quick solution. DPOP should remain simple and extensible. There is value in keeping DPOP.

Justin says its ok to take DPOP as is with the editorial changes and just publish.

Brian is maybe ok in adding a hash as a compromise to get this out the door or do nothing. Brian things we are close to publish and have something useable with the caveats

Dennis made some comments, should include audience restrictions

Poll, leave as is (with editorial changes, no protocol changes) – 8 , add mechanism - ? No consensus

Consensus bias – add the JWK token in the header, this would be a change in the protocol, this this would not be increasing the size, just moving the JWT. Justin does not like this as it changes the parallelism of the protocol

Attendees

  • Rifaat Shekh-Yusef (chair)
  • Hannes Tschofenig (chair)
  • Brian Campbell (Presenter)
  • Justin Richer
  • Torsten Lodderstedt
  • Vittorio Bertocci
  • Aaron Parecki
  • Bjorn Hjelm
  • Mike Jones
  • Dick Hardt
  • Filip Skokan
  • Michael Palage
  • Pedro do Vale
  • Anthony Nadalin
  • Denis Pinkas
  • Brian Campbell
  • Francis Pouatcha
  • Jon Meyler
  • Dario Savarese
  • Phil Hunt

Document

IETF DPoP Draft

Recording

https://ietf.webex.com/webappng/sites/ietf/recording/02031991f24841dabade66e5ba73a72c/playback

Next Interim Meetings