Re: [OAUTH-WG] Meeting Notes (9th March 2020)

[Rifaat Shekh-Yusef <[e-mail]>]

The slides that Brian presented, and the minutes with a link to the
recording of the meeting are now available on the following link:
https://datatracker.ietf.org/meeting/interim-2020-oauth-02/session/oauth

Regards,
 Rifaat


On Tue, Mar 17, 2020 at 8:12 AM Hannes Tschofenig <[e-mail]>
wrote:

> Participants:
>
>
>
> - Roman Danyliw
>
> - Torsten Lodderstedt
>
> - Travis Spencer
>
> - Aaron Parecki
>
> - Ben Kaduk
>
> - Brian Campbell
>
> - Cigdem Sengul
>
> - Daniel Fett
>
> - David Waite
>
> - Filip
>
> - Jim Schaad
>
> - Justin Richer
>
> - Marco Tiloca
>
> - Matthew de Haast
>
> - Michael Peck
>
> - Mike Jones
>
> - Phil Hunt
>
> - Hannes Tschofenig
>
> - Joseph Heenan
>
> - David Waite
>
> - Bjorn Hjelm
>
> - Cristofer Gonzales
>
> - Tony Nadalin
>
> - Vittori
>
> - Rifaat
>
>
>
> Notes:
>
>
>
> Rifaat showed the list of documents relevant for the discussion
>
>
>
>
>
> Several documents are relevant to this discussion, including
>
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08
>
> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
>
> https://tools.ietf.org/html/draft-richanna-oauth-http-signature-pop-00
>
> https://tools.ietf.org/html/draft-cavage-http-signatures-12
>
> https://tools.ietf.org/html/rfc8613
>
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07
>
> https://tools.ietf.org/html/rfc7800
>
> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33
>
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-17
>
>
>
> Brian went through his presentation.
>
>
>
> Hannes notes that OSCORE, a solution presented from the ACE group, is
> missing in the list.
>
>
>
> Brian responds that nobody in the OAuth world cares about OSCORE.
>
>
>
> Discussion about whether the ACE group uses the key distribution
> parameters for use with HTTP. Jim believes it does.
>
>
>
> Justin explained the work Annabelle was doing.
>
>
>
> Rifaat asked whether PoP + HTTP signing will solve his problem.
>
>
>
> Brian does not believe that HTTP signing solves anything and if it gets
> done then it will take a long time. It also does not cover the refresh
> token case.
>
>
>
> HTTP Signing is a lot about HTTP canonicalization. It will allow for
> signing and HMAC computation over the resulting string.
>
>
>
> Roman: For some HTTP signing may still be too expensive?
>
>
>
> Justin: Yes, we are starting with the cavage-http-signatures draft. There
> are some big problems with it. For example, what parts are signed. Depends
> on we sign it will be necessary to re-create the signature with every
> request.
>
> We need a profile for OAuth use to indicate where to send the token and
> what to include in the signature.
>
>
>
> Brian: I believe that every request should require a new signature.
> Finding out whether a signature can be omitted will be prohibitive.
>
>
>
> Justin: DPOP signs only a small number of elements and does not require
> HTTP signing.
>
>
>
> Justin: For the HTTP signature solution we are planning to offer a
> symmetric and an asymmetric key version.
>
>
>
> Justin: DPOP is a key presentation for single page application and it can
> probably be used with other apps too. We are going to have a PoP solution
> with an generic HTTP message mechanism.
>
>
>
> Torsten: How many deployable solutions do we have?
>
>
>
> Brian: We have probably 3 or 4 solutions.
>
>
>
> Justin: In terms of implementations we have 3.
>
>
>
> ?: What if we split the key distribution from the HTTP signing?
>
>
>
> Justin: That's how we wanted to do the generic approach. It is how we do
> it with HTTP signing.
>
>
>
> ?: What are you signing in the HTTP message?
>
>
>
> Justin: I believe if we have generic HTTP signing then we could re-use it
> with DPOP.
>
>
>
> Mike: Microsoft is internally deployed the old HTTP signing. The reason is
> that it is stable (although abandoned). Our product groups that is simple,
> like DPOP. John and I talked at the last IETF on how we wanted to do
> symmetric DPOP. Inherently you have to do a key distribution step. I would
> like to see the DPOP draft adopted as a WG draft (recognizing that it may
> be revised to include a symmetric key solution).
>
>
>
> The working group needs to make a decision on how to add symmetric key
> distribution.
>
>
>
> Filip: We would also like to see adoption.
>
>
>
> Roman: three options
>
>
>
> 1) Stay with POP key distribution
>
> 2) DPOP (as is)
>
> 3) Use ECDHE exchange from Neil
>
>
>
> Brian: We could add (3) to (2) but it would be difficult and prohibitively
> difficult. (3) should its own thing. Or maybe if the push for performance
> improvements is so big that we need to jump straight to (3). There is the
> risk of too many options.
>
>
>
> Torsten: Is the concern that (2) is too slow?
>
>
>
> Filip: At the last meeting there was a concern from AWS that signing of
> each request is prohibitively complex. But (2) works in my deployment.
>
>
>
> Mike: It depends on the use case.
>
>
>
> Phil: How does TLS 1.3 alter some of the requirements? What about the HTTP
> group doing the work on signing?
>
>
>
> Brian: I don't think there is any dependency.
>
>
>
> Justin: I do think that there is room for both. I don't think DPOP should
> be stretched to a generic solution and it isn't. It is a clever hack for a
> specific use case.
>
>
>
> Brian: I wouldn't agree on the term "hack"..
>
>
>
> Phil: I am concerned that the market tries to apply a limited solution to
> everything.
>
>
>
> Justin: That's why we need to standardize many solutions. DPOP makes a lot
> of sense as it is today. If you can layer a symmetric key solution then
> that's fine too. I think AWS should not use DPOP.
>
>
>
> Phil: I think we need to make clear that PoP is orthogonal to message
> signing. Saying that those things are separate going forward. I am worried
> that we are repeating the cycle for the 3rd or 4th time in 10 years.
>
>
>
> Mike: The market left OAuth 1.0 because of HTTP signing interoperability
> problems.
>
>
>
> Phil: When I was looking at MTLS there was a similar perception about
> whether it is actually needed. There are two extreme: (1) sign everything
> and encrypt everything and then (2) just use the existing stuff.
>
>
>
> Mike: I like DPOP because it does very little. It just as little as
> possible to demonstrate PoP for the token.
>
>
>
> Phil: Yes, I like that.
>
>
>
> Brian: There is certainly opportunity in the draft to make the draft
> clear. It is certainly for more use cases than for SPA-type apps.
>
>
>
> Rifaat: Any other comments?
>
>
>
> Next step is to take it to the list. There is also another question about
> the use of symmetric key in addition to asymmetric key.
>
>
>
> Roman: We will only do a call for adoption of the DPOP solution and not
> for any other option.
>
>
>
> Rifaat: Yes.
>
>
>
> Rifaat: Neither I nor Hannes will be at the Vancouver IETF meeting.
>
>
>
> The following participants are planning to be there: Justin, Aaron, Mike,
> Brian, David, Spencer, Tony, Matthew.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>