Re: [OAUTH-WG] Meeting Notes (9th March 2020)
Brian Campbell <bcampbell@pingidentity.com> Tue, 17 March 2020 16:09 UTC
Return-Path: <bcampbell@pingidentity.com>
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 B398C3A0404 for <oauth@ietfa.amsl.com>; Tue, 17 Mar 2020 09:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=pingidentity.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 4RzmYRtnHejJ for <oauth@ietfa.amsl.com>; Tue, 17 Mar 2020 09:09:49 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 BD7D53A040B for <oauth@ietf.org>; Tue, 17 Mar 2020 09:09:48 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id r24so23592372ljd.4 for <oauth@ietf.org>; Tue, 17 Mar 2020 09:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eSQjLo1yfl7cIcBbjc5gzNeOB3C3OxhJGhms9NEXZK8=; b=Y2S6wlhTS+rSEQAGV2fjzDsAtQzTWv69u7GjwPNW9kI0GUyhY9hbcX9FO0SMC76/St FWXlmq/Gk4g7l+Vy+N6i57jNBH7cV3VUXEPVgp+1BAt96JJyhRQoAnHnqiDTVFRwEwBC Pl6yS079DKpj4vwTX8aSJj9RUO9VEWpnYNdGVEaXNS0WadkCtmkj0PD9cPh3DYbY1fRW cTj6OKIEes/cjtUeRtA7k0uiJge95r4rxX7dcsrarPrCzL2WqY+Eciuz2cL8fnbwT7Ze B2HRBGDs6q1vvHAOYg+Goio4yz5G4K2SQEN30VlOwAYNxyEpurtYq7YDWXFT2kLNIb5+ LAQA==
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=eSQjLo1yfl7cIcBbjc5gzNeOB3C3OxhJGhms9NEXZK8=; b=CC1imjAIyj1cWio5z2T5BQ5YUwNiJk4ytw+oty5W7gc2DZEaatnp/QIaWHLM7uR3x9 ldj1qUTR0hvBVuLuEt+2S4T102au0lb1A9FFIQrYZ6noUY9+0RQL3+YpC71l6q64BZn6 s3USxbzk+OvpJbVwdoiAX+YgVVQ5ObAFk888tE7Qwva6h328ndIIv8SOqeqRv0rSJJiB fKy/yQtTYtwU/U/6fZ+L8lhhPU474Zz4TX1QW51/9VtSgTZ1pnPziXZCs71CP2O9TnIg Qis1eEFwG2L7/ZL7lgEKv1pl25cGMgRxO0krMPdGvLcii42QrzYWU5JjI6RLQ9r+w1sC JpPw==
X-Gm-Message-State: ANhLgQ1xXL/fyiyy7zzIvIrukUQ30oS9wVvMFjSQziWf9R8iGott5erm EH+W11JhqpS9HBPbfxoCSmwP33knIqfbNR4dEKphObUDX8EY5zUidt3x4WgVKe3ONBI/EEQ7Y48 hIWi5YEme/413Uw==
X-Google-Smtp-Source: ADFU+vsTAVcXc/hzO7f1/S2onKciSwxASytjHzWbb/wRtbjv+BPwP4pvYz7G6IkNEer0WEptko6B5YmVSt6lN5vTobg=
X-Received: by 2002:a2e:730e:: with SMTP id o14mr3287831ljc.273.1584461386585; Tue, 17 Mar 2020 09:09:46 -0700 (PDT)
MIME-Version: 1.0
References: <AM0PR08MB3716E48583372E610EA016F6FAF60@AM0PR08MB3716.eurprd08.prod.outlook.com> <CAGL6epKUX6XO_XsGS=BaTmAbPdVz+-4DTVSMpNNDnSYV94o=_A@mail.gmail.com>
In-Reply-To: <CAGL6epKUX6XO_XsGS=BaTmAbPdVz+-4DTVSMpNNDnSYV94o=_A@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 17 Mar 2020 10:09:20 -0600
Message-ID: <CA+k3eCQzpsbvkbkGzHNQ-rm6V6S+aXUE2gkiBtgWZLm2UadY1w@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001c0eba05a10f2ac9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-spHo7NbbDuJc7duPaGlc84tBqk>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2020 16:09:52 -0000
Thanks Rifaat, It's only been eight days but that last slide hasn't aged well and now seems foolishly optimistic :/ On Tue, Mar 17, 2020 at 8:48 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote: > 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 < > Hannes.Tschofenig@arm.com> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
- [OAUTH-WG] Meeting Notes (9th March 2020) Hannes Tschofenig
- Re: [OAUTH-WG] Meeting Notes (9th March 2020) Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Meeting Notes (9th March 2020) Brian Campbell