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 2AB4112009E for ; Fri, 10 Jan 2020 06:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 IoxQOKgvU0ER for ; Fri, 10 Jan 2020 06:56:21 -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 237A21200B7 for ; Fri, 10 Jan 2020 06:56:21 -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 00AEuDqh017015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 09:56:15 -0500 From: Justin Richer Message-Id: <3E119888-EF1E-4462-ABC6-93313811C481@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_5BBA4C70-72A4-4ADE-85F0-E55A4B4F7923" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 10 Jan 2020 09:56:12 -0500 In-Reply-To: <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com> Cc: Neil Madden , Brian Campbell , Dave Tonge , oauth , Nat Sakimura To: "Richard Backman, Annabelle" 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> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] [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 14:56:24 -0000 --Apple-Mail=_5BBA4C70-72A4-4ADE-85F0-E55A4B4F7923 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I just want to add that the requirement to validate the request at PAR = the same way as you would at the auth endpoint is something that I want = to see relaxed, and I hope it doesn=E2=80=99t make it through to the = final standard.=20 Also keep in mind that this is barely started as a WG document so any = requirement is soft at best. When discussing things like this, we should = keep this in mind by discussing the consequences of having a phrase in = there, not behaving as if things are unchangeable.=20 =E2=80=94 Justin > On Jan 6, 2020, at 4:59 PM, Richard Backman, Annabelle = wrote: >=20 > 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 > 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 > 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 > 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: > 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 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =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 > Agreed.=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 > -- Neil > =20 >=20 >=20 >> On 6 Jan 2020, at 13:57, Brian Campbell = > wrote: >> =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 >> On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle = > wrote: >>> 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" = on behalf of = torsten=3D40lodderstedt.net@dmarc.ietf.org = > 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 >> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_5BBA4C70-72A4-4ADE-85F0-E55A4B4F7923 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = just want to add that the requirement to validate the request at PAR the = same way as you would at the auth endpoint is something that I want to = see relaxed, and I hope it doesn=E2=80=99t make it through to the final = standard. 

Also = keep in mind that this is barely started as a WG document so any = requirement is soft at best. When discussing things like this, we should = keep this in mind by discussing the consequences of having a phrase in = there, not behaving as if things are unchangeable. 

 =E2=80= =94 Justin

On Jan 6, 2020, at 4:59 PM, Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = 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.
 
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:
 
The AS MUST process =
the request as follows:
 
...
 
3.  The AS MUST validate the =
request in the same way as at the
      =
    authorization endpoint. ...
 
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=99= d be a good start and makes sense in its own right.
 
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:
  1. The request object is passed by reference, and = accessible on the public Internet.
  2. 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.
  3. The AS requires request object encryption to minimize = exposure to the hosted PAR endpoint service it uses.
  4. #2, but the threat vector is gaps in end-to-end TLS.
  5. 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.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Neil Madden <neil.madden@forgerock.com>
Date: Monday, January 6, 2020 = at 6:29 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: "Richard Backman, = Annabelle" <richanna@amazon.com>, Nat Sakimura <nat@sakimura.org>, Dave = Tonge <dave.tonge@moneyhub.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, = oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: = [OAUTH-WG] PAR metadata
 
Agreed. 
 
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.
 
-- Neil
 


On 6 Jan 2020, at 13:57, Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:
 
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.
 
 
 
 
 
 
 
 
On Fri, = Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
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.

The two options that I see = are:

1. Define a new par_jwks_uri metadata = property.
2. Explicitly state that this separation is not = supported.

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.

=E2=80=93 
Annabelle = Richard Backman
AWS Identity


On 12/31/19, 8:07 AM, "OAuth on behalf of = Torsten Lodderstedt" <oauth-bounces@ietf.org on behalf of torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

    Hi Filip, 

    > On 31. Dec 2019, at 16:22, Filip Skokan = <panva.ip@gmail.com> wrote:
    = > 
    > 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.
    > 
  =   > The same principle could be applied to signing (and = encryption) algorithms as well.
    > 
  =   > 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. 
  =   > 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.

    Dammed! You are so right. Sorry, I got confused = somehow. 

    > 
  =   > PS: I also found this comment related to the same question = about auth metadata but for CIBA.

  =   Thanks for sharing. 

    > 
  =   > Best,
    > Filip
    thanks,
    = Torsten. 

    > 
  =   > 
    > On Tue, 31 Dec 2019 at 15:38, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
  =   > Hi all,
    > 
  =   > Ronald just sent me an email asking whether we will define = metadata for 
    > 
  =   > pushed_authorization_endpoint_auth_methods_supported and
    > = pushed_authorization_endpoint_auth_signing_alg_values_supported.
    > 
  =   > 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. 
  =   > 
    > What=E2=80=99s your opinion?
    > 
  =   > best regards,
    > Torsten.



_______________________________________________
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 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

= --Apple-Mail=_5BBA4C70-72A4-4ADE-85F0-E55A4B4F7923--