Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCA13A0879 for ; Tue, 17 Mar 2020 07:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tLB3wVgn_9I for ; Tue, 17 Mar 2020 07:47:32 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980CB3A0878 for ; Tue, 17 Mar 2020 07:47:32 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id a6so20330314ilc.4 for ; Tue, 17 Mar 2020 07:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QHF6IlEHancy7m2CQ/Evt/IrTp1zw7HT2Gfq3GApV5M=; b=eh30hsAJ2H7TeJzTjRaKF32FG/1Bvw8x2AE1XnT0EZRpXZjIg6zIljXZdacLpng1nY lDFiB18dAzzsEN/HbQB4hO5pynEq0vDHapP9VjRcuy2BNud+oLumKz62oLOkI3l2GRhq rPQY8IlEKDKU1Kc36T3Tp84uqXniTPThq3uLYRrFWOvYAj6o3E/yzJpKLqIFHz8i/6ux J0MzFkNxyEqO0NIrcGgnrTyQp2mh04EcY3hOOdLnPi0IFpueyBXUZdZbYmBK9jXoBtJt +QhBA437Zd9JrTMub4BMRhPyWeAsb5mc5cBGBhz02cQiRDB2b2NGe4a3T4eW7dX1BSs1 bwkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QHF6IlEHancy7m2CQ/Evt/IrTp1zw7HT2Gfq3GApV5M=; b=mKb7aOo3S02oj5IHxTEHHyASYmTcqH94W4gUKtG6L2V8sEQXOaPHkOUq55CTTLlcA9 93c75w3X6cznr/7KlQjWBTAXEXzu8cQgEJCZuD3V8gdbOcnscn1Goa24qNvjKvzV4M/P 2u8BdJT90L5+5MyI9fVNBXbXus7OQbTjiBkl5W/ExV/HuhHIF8V5IwnIQnGn9WPhn64a DtUySPBjA2VSTGQiV2JW2M4lyy9Ip5Odj/Pl6P4zgNo9IO0mjB3LqTqpzbyUS2CShDqt cZSJgzSZmI7MX4/nfdG4aW6NQ8gMMO8Lhj5XPpmoV2DE5ZI/XAs3MWlLa4AbRmIntw/y jySw== X-Gm-Message-State: ANhLgQ0hmabDKb6daCTcs7/HkTVluNZAGu6ez0MKlntZLLT2VYuM0Mnj 1SqO3OHBKHxxvqzWtRGN1wnTUHbLOCfzT3cHMvyuEaTF X-Google-Smtp-Source: =?utf-8?q?ADFU+vvRoN7Z8OhrUKx3rPkdITZYqBeZetDpjMuLhGC+?= =?utf-8?q?J1Y9Ym64aCMYFfjXa3ngrEW8+9sFRTXiIR7rZvdrrXv+PI8=3D?= X-Received: by 2002:a92:5f98:: with SMTP id i24mr5577719ill.73.1584456451425; Tue, 17 Mar 2020 07:47:31 -0700 (PDT) MIME-Version: 1.0 References: =?utf-8?q?=3CAM0PR08MB3716E48583372E610EA016F6FAF60=40AM0PR08MB3?= =?utf-8?q?716=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?= In-Reply-To: =?utf-8?q?=3CAM0PR08MB3716E48583372E610EA016F6FAF60=40AM0PR08MB?= =?utf-8?q?3716=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?= From: Rifaat Shekh-Yusef Date: Tue, 17 Mar 2020 10:47:19 -0400 Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="000000000000f30d2d05a10e0351" Archived-At: Subject: Re: [OAUTH-WG] Meeting Notes (9th March 2020) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 14:47:36 -0000 --000000000000f30d2d05a10e0351 Content-Type: text/plain; charset="UTF-8" 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 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000f30d2d05a10e0351 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The slides that Brian presented, and the minutes with a li= nk to the recording of the meeting=C2=A0are now available on the following = link:

Regards,
=C2= =A0Rifaat
=C2=A0

On Tue, Mar 17, 2020 at 8:12 AM Hannes = Tschofenig <Hannes.Tschofen= ig@arm.com> wrote:

Participants:

=C2=A0

- 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

=C2=A0

Notes:

=C2=A0

Rifaat showed the list of documents relevant for the= discussion

=C2=A0

=C2=A0

Several documents are relevant to this discussion, i= ncluding

https://tools.ietf.org/html/draf= t-ietf-oauth-pop-architecture-08

https://tools.ietf.org/html/d= raft-ietf-oauth-signed-http-request-03

https://tools.ietf.org/htm= l/draft-richanna-oauth-http-signature-pop-00

https://tools.ietf.org/html/draft-cav= age-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

=C2=A0

Brian went through his presentation.

=C2=A0

Hannes notes that OSCORE, a solution presented from = the ACE group, is missing in the list.

=C2=A0

Brian responds that nobody in the OAuth world cares = about OSCORE.

=C2=A0

Discussion about whether the ACE group uses the key = distribution parameters for use with HTTP. Jim believes it does.

=C2=A0

Justin explained the work Annabelle was doing.

=C2=A0

Rifaat asked whether PoP + HTTP signing will solve h= is problem.

=C2=A0

Brian does not believe that HTTP signing solves anyt= hing and if it gets done then it will take a long time. It also does not co= ver the refresh token case.

=C2=A0

HTTP Signing is a lot about HTTP canonicalization. I= t will allow for signing and HMAC computation over the resulting string.=

=C2=A0

Roman: For some HTTP signing may still be too expens= ive?

=C2=A0

Justin: Yes, we are starting with the cavage-http-si= gnatures draft. There are some big problems with it. For example, what part= s are signed. Depends on we sign it will be necessary to re-create the sign= ature with every request.

We need a profile for OAuth use to indicate where to= send the token and what to include in the signature.

=C2=A0

Brian: I believe that every request should require a= new signature. Finding out whether a signature can be omitted will be proh= ibitive.

=C2=A0

Justin: DPOP signs only a small number of elements a= nd does not require HTTP signing.

=C2=A0

Justin: For the HTTP signature solution we are plann= ing to offer a symmetric and an asymmetric key version.

=C2=A0

Justin: DPOP is a key presentation for single page a= pplication and it can probably be used with other apps too. We are going to= have a PoP solution with an generic HTTP message mechanism.<= /p>

=C2=A0

Torsten: How many deployable solutions do we have? <= u>

=C2=A0

Brian: We have probably 3 or 4 solutions. =

=C2=A0

Justin: In terms of implementations we have 3.

=C2=A0

?: What if we split the key distribution from the HT= TP signing?

=C2=A0

Justin: That's how we wanted to do the generic a= pproach. It is how we do it with HTTP signing.

=C2=A0

?: What are you signing in the HTTP message? =

=C2=A0

Justin: I believe if we have generic HTTP signing th= en we could re-use it with DPOP.

=C2=A0

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 sym= metric key solution).

=C2=A0

The working group needs to make a decision on how to= add symmetric key distribution.

=C2=A0

Filip: We would also like to see adoption.

=C2=A0

Roman: three options

=C2=A0

1) Stay with POP key distribution

2) DPOP (as is)

3) Use ECDHE exchange from Neil

=C2=A0

Brian: We could add (3) to (2) but it would be diffi= cult 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.

=C2=A0

Torsten: Is the concern that (2) is too slow?=

=C2=A0

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.

=C2=A0

Mike: It depends on the use case.

=C2=A0

Phil: How does TLS 1.3 alter some of the requirement= s? What about the HTTP group doing the work on signing?

=C2=A0

Brian: I don't think there is any dependency.

=C2=A0

Justin: I do think that there is room for both. I do= n't think DPOP should be stretched to a generic solution and it isn'= ;t. It is a clever hack for a specific use case.

=C2=A0

Brian: I wouldn't agree on the term "hack&q= uot;..

=C2=A0

Phil: I am concerned that the market tries to apply = a limited solution to everything.

=C2=A0

Justin: That's why we need to standardize many s= olutions. DPOP makes a lot of sense as it is today. If you can layer a symm= etric key solution then that's fine too. I think AWS should not use DPO= P.

=C2=A0

Phil: I think we need to make clear that PoP is orth= ogonal to message signing. Saying that those things are separate going forw= ard. I am worried that we are repeating the cycle for the 3rd or 4th time i= n 10 years.

=C2=A0

Mike: The market left OAuth 1.0 because of HTTP sign= ing interoperability problems.

=C2=A0

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.

=C2=A0

Mike: I like DPOP because it does very little. It ju= st as little as possible to demonstrate PoP for the token.

=C2=A0

Phil: Yes, I like that.

=C2=A0

Brian: There is certainly opportunity in the draft t= o make the draft clear. It is certainly for more use cases than for SPA-typ= e apps.

=C2=A0

Rifaat: Any other comments?

=C2=A0

Next step is to take it to the list. There is also a= nother question about the use of symmetric key in addition to asymmetric ke= y.

=C2=A0

Roman: We will only do a call for adoption of the DP= OP solution and not for any other option.

=C2=A0

Rifaat: Yes.

=C2=A0

Rifaat: Neither I nor Hannes will be at the Vancouve= r IETF meeting.

=C2=A0

The following participants are planning to be there:= Justin, Aaron, Mike, Brian, David, Spencer, Tony, Matthew.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000f30d2d05a10e0351--