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 94D7D12025D for ; Fri, 10 Jan 2020 08:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 ZAzJ_wQpAbuw for ; Fri, 10 Jan 2020 08:42:54 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB2812099C for ; Fri, 10 Jan 2020 08:42:52 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00AGgnTA023572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 11:42:49 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Fri, 10 Jan 2020 11:42:48 -0500 Cc: Torsten Lodderstedt , Dave Tonge , oauth , Nat Sakimura Content-Transfer-Encoding: quoted-printable Message-Id: <07A0FC76-3BEC-4103-81CD-520243AC8CC3@mit.edu> References: <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com> <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com> <234E2C28-4CF5-4626-83D5-719B176C418B@amazon.com> <70997D70-0DFF-4C39-B712-F916BFB04EDF@lodderstedt.net> To: "Richard Backman, Annabelle" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR metadata 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: Fri, 10 Jan 2020 16:42:57 -0000 +1 to this being a security consideration =E2=80=94 Justin > On Jan 8, 2020, at 3:46 PM, Richard Backman, Annabelle = wrote: >=20 > I almost included text to that effect, but thought it was getting too = wordy. However your suggestion is simple and concise. +1 >=20 > Given all of this discussion, we should include a section on request = validation in Security Considerations, to provide some context on what = might be validated when and where, what kinds of problems deployments = need to consider, etc. I think this is useful to have in the document, = but would be too much clutter in the main body. We should keep that = focused on the precise normative requirements. >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 > =EF=BB=BFOn 1/8/20, 2:11 AM, "Torsten Lodderstedt" = wrote: >=20 > Hi Annabelle,=20 >=20 > thanks for your proposal, which reads reasonable to me.=20 >=20 > I suggest to extend =E2=80=9Cand that the request has not been = modified in a way that would affect the outcome of the omitted steps.=E2=80= =9D a bit to also consider policy changes that may have occurred between = push and authorization request processing.=20 >=20 > "and that the request or the authorization server=E2=80=99s policy = has not been modified in a way that would affect the outcome of the = omitted steps." >=20 > best regards, > Torsten.=20 >=20 >> On 8. Jan 2020, at 03:25, Richard Backman, Annabelle = wrote: >>=20 >> I think it=E2=80=99s clearer if we split out the requirements for the = PAR endpoint and the requirements for the authorization endpoint, given = that they are each covered in different sections of the doc (2 and 4, = respectively). With that in mind, here are a couple suggestions: >>=20 >> For the text in Section 2.1: >>=20 >> 3. The AS MUST validate the pushed request as it would an = authorization >>=20 >> request sent to the authorization endpoint, however the AS MAY = omit >>=20 >> validation steps that it is unable to perform when processing the >>=20 >> pushed request. >>=20 >>=20 >>=20 >> Additional text for Section 4 (note that this section pertains to the = authorization endpoint): >>=20 >> The AS MUST validate authorization requests arising from a pushed = request as >>=20 >> it would any other authorization request. The AS MAY omit validation = steps >>=20 >> that it performed when the request was pushed, provided that it can = validate >>=20 >> that the request was a pushed request, and that the request has not = been >>=20 >> modified in a way that would affect the outcome of the omitted steps. >>=20 >>=20 >>=20 >> This is longer than the current text and the other proposals, but it = adds a few important points: >> =E2=80=A2 Turns the 2.1 SHOULD back into a MUST, with an = explicit exception for validation that can=E2=80=99t be done yet. >> =E2=80=A2 Reinforces the fact that the authorization endpoint = still needs to do validation. >> =E2=80=A2 Clearly states requirements for when an AS can trust = that validation happened at the PAR endpoint. >>=20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >>=20 >>=20 >> From: Brian Campbell >> Date: Tuesday, January 7, 2020 at 2:54 PM >> To: Vladimir Dzhuvinov >> Cc: Filip Skokan , "Richard Backman, Annabelle" = , Dave Tonge , oauth = , Nat Sakimura >> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: = PAR metadata >>=20 >> A little more context about that proposed wording is in a github = issue at >>>=20 >>>>> =E2=80=A2 >>>>> =E2=80=A2 >>>>> =E2=80=A2 >>>>> =E2=80=A2 >>>>> =E2=80=A2 > https://github.com/oauthstuff/draft-oauth-par/issues/38, which is = different driver than allowing a PAR endpoint to stash the encrypted = request object rather than decrypting/validating it. But it's kind of = the same concept at some level too - that there are some things that = can't or won't be validated at the PAR endpoint and those then have to = be validated at the authorization endpoint.. >=20 > I rather like your suggested text, Vladimir, and have mentioned it = in a comment on the aforementioned issue. >=20 >=20 > On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov = wrote: > On 07/01/2020 00:22, Filip Skokan wrote: > We've been discussing making the following change to the language >=20 > The AS SHOULD validate the request in the same way as at the = authorization endpoint. The AS MUST ensure that all parameters to the = authorization request are still valid at the time when the request URI = is used. > Could you expand a bit on the second sentence? > Alternative suggestion: > The AS MUST validate the request in the same way as at the = authorization endpoint, or complete the request validation at the = authorization endpoint. > Vladimir >=20 > This would allow the PAR endpoint to simply stash the encrypted = request object instead of decrypting and validating it. All within the = bounds of "SHOULD - We=E2=80=99d like you to do this, but we can=E2=80=99t= always require it". This supports "light weight PAR" implementation = rather than introducing the unnecessary complexity in the form of a = second JWKS. >=20 > Best, > Filip >=20 >=20 > On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle = wrote: > The issue isn=E2=80=99t that the PAR endpoint needs access to one = specific request object decryption key that could reasonably be shared = across AS endpoints, but that it actually needs access to the private = keys for all encryption public keys in the JWK set pointed to by the = AS=E2=80=99s jwks_uri metadata property. Since there is no way to = designate one particular key as the one to use for encrypting request = objects, clients may reasonably use any encryption public key in the JWK = set to encrypt a request object. As one example of how this could expose = sensitive data to the PAR endpoint, if the PAR endpoint has all the = decryption keys for the keys in the AS=E2=80=99s JWK set, it would be = able to decrypt ID Tokens sent in id_token_hint request parameters. As = more and more use cases develop for encrypting blobs for the AS, this = issue will only get worse. >=20 >=20 >=20 > The PAR endpoint can=E2=80=99t simply stash the encrypted request = object, as it is required to verify the request, according to =C2=A72.1: >=20 >=20 >=20 > The AS MUST process the request as follows: >=20 > ..... >=20 > 3. The AS MUST validate the request in the same way as at the > authorization endpoint. ... >=20 > This language needs to be more flexible, IMHO, to allow for = lightweight PAR endpoints that may not have the information or authority = needed to perform all the validation that happens at the authorization = endpoint. I need to think about this more before I can say if it would = adequately address my concerns, but it=E2=80=99d be a good start and = makes sense in its own right. >=20 >=20 >=20 > I think it=E2=80=99s pretty risky for us to base decision on an = assumption that no one is going to need or want to encrypt pushed = request objects, particularly when they=E2=80=99re JWTs, and JWTs have = well established support for encryption, and encrypted JWTs are = supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if = you insist, here are a few examples for why someone might want to do = this: >=20 > The request object is passed by reference, and accessible on the = public Internet. > The request object contains sensitive transaction-related data in = RAR parameters that the client=E2=80=99s authN/authZ stack doesn=E2=80=99t= need to have access to. > The AS requires request object encryption to minimize exposure to = the hosted PAR endpoint service it uses. > #2, but the threat vector is gaps in end-to-end TLS. > Any of the above, but the concern is message integrity, and the AS = requires requested objects to be encrypted for confidentiality and = integrity protection and does not support signed request objects. >=20 >=20 > =E2=80=93=20 >=20 > Annabelle Richard Backman >=20 > AWS Identity >=20 >=20 >=20 >=20 >=20 > From: Neil Madden > Date: Monday, January 6, 2020 at 6:29 AM > To: Brian Campbell > Cc: "Richard Backman, Annabelle" , Nat = Sakimura , Dave Tonge , = Torsten Lodderstedt , oauth > Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata >=20 >=20 >=20 > Agreed. >=20 >=20 >=20 > In addition, I'm not sure why the PAR endpoint would need access to = the decryption keys at all. If you're using encrypted request objects = then the PAR endpoint receives an encrypted JWT and then later makes the = same (still encrypted) JWT available to the authorization endpoint. If = the PAR endpoint is doing any kind of decryption or validation on behalf = of the authorization endpoint then they are clearly not in separate = trust boundaries. >=20 >=20 >=20 > -- Neil >=20 >=20 >=20 >=20 >=20 > On 6 Jan 2020, at 13:57, Brian Campbell = wrote: >=20 >=20 >=20 > I really struggle to see the assumption that an entity be able to = use the same key to decrypt the same type of message ultimately intended = for the same purpose as an artificial limit. The same general assumption = underlies everything else in OAuth/OIDC (Vladimir's post points to = some but not all examples of such). There's no reason for PAR to make a = one-off exception. And should there be some deployment specific reason = that truly requires that kind of isolation, there are certainly = implementation options that aren't compatibility-breaking. And having = said all that, I'm honestly a little surprised anyone is thinking much = about encrypted request objects with PAR as, at least with my limited = imagination, there's not really a need for it. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle = wrote: >=20 > PAR introduces an added wrinkle for encrypted request objects: the = PAR endpoint and authorization endpoint may not have access to the same = cryptographic keys, even though they're both part of the "authorization = server." Since they're different endpoints with different roles, it's = reasonable to put them in separate trust boundaries. There is no way to = support this isolation with just a single "jwks_uri" metadata property. >=20 > The two options that I see are: >=20 > 1. Define a new par_jwks_uri metadata property. > 2. Explicitly state that this separation is not supported. >=20 > I strongly perfer #1 as it has a very minor impact on deployments = that don't care (i.e., they just set par_jwks_uri and jwks_uri to the = same value) and failing to support this trust boundary creates an = artificial limit on implementation architecture and could lead to = compatibility-breaking workarounds. >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 > On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" = wrote: >=20 > Hi Filip,=20 >=20 >> On 31. Dec 2019, at 16:22, Filip Skokan wrote: >>=20 >> I don't think we need a *_auth_method_* metadata for every endpoint = the client calls directly, none of the new specs defined these (e.g. = device authorization endpoint or CIBA), meaning they also didn't follow = the scheme from RFC 8414 where introspection and revocation got its own = metadata. In most cases the unfortunately named = `token_endpoint_auth_method` and its related metadata is what's used by = clients for all direct calls anyway. >>=20 >> The same principle could be applied to signing (and encryption) = algorithms as well. >>=20 >> This I do not follow, auth methods and their signing is dealt with by = using `token_endpoint_auth_methods_supported` and = `token_endpoint_auth_signing_alg_values_supported` - there's no = encryption for the `_jwt` client auth methods.=20 >> Unless it was meant to address the Request Object signing and = encryption metadata, which is defined and IANA registered by OIDC. PAR = only references JAR section 6.1 and 6.2 for decryption/signature = validation and these do not mention the metadata (e.g. = request_object_signing_alg) anymore since draft 07. >=20 > Dammed! You are so right. Sorry, I got confused somehow.=20 >=20 >>=20 >> PS: I also found this comment related to the same question about auth = metadata but for CIBA. >=20 > Thanks for sharing.=20 >=20 >>=20 >> Best, >> Filip >=20 > thanks, > Torsten.=20 >=20 >>=20 >>=20 >> On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt = wrote: >> Hi all, >>=20 >> Ronald just sent me an email asking whether we will define metadata = for=20 >>=20 >> pushed_authorization_endpoint_auth_methods_supported and >> pushed_authorization_endpoint_auth_signing_alg_values_supported. >>=20 >> The draft right now utilises the existing token endpoint = authentication methods so there is basically no need to define another = parameter. The same principle could be applied to signing (and = encryption) algorithms as well.=20 >>=20 >> What=E2=80=99s your opinion? >>=20 >> best regards, >> Torsten. >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > 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 mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth