+1 to this being a security consideration — Justin
> On Jan 8, 2020, at 3:46 PM, Richard Backman, Annabelle > <richanna=40amazon....@dmarc.ietf.org> wrote: > > I almost included text to that effect, but thought it was getting too wordy. > However your suggestion is simple and concise. +1 > > 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. > > – > Annabelle Richard Backman > AWS Identity > > > On 1/8/20, 2:11 AM, "Torsten Lodderstedt" > <torsten=40lodderstedt....@dmarc.ietf.org> wrote: > > Hi Annabelle, > > thanks for your proposal, which reads reasonable to me. > > I suggest to extend “and that the request has not been modified in a way > that would affect the outcome of the omitted steps.” a bit to also consider > policy changes that may have occurred between push and authorization request > processing. > > "and that the request or the authorization server’s policy has not been > modified in a way that would affect the outcome of the omitted steps." > > best regards, > Torsten. > >> On 8. Jan 2020, at 03:25, Richard Backman, Annabelle >> <richanna=40amazon....@dmarc.ietf.org> wrote: >> >> I think it’s 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: >> >> For the text in Section 2.1: >> >> 3. The AS MUST validate the pushed request as it would an authorization >> >> request sent to the authorization endpoint, however the AS MAY omit >> >> validation steps that it is unable to perform when processing the >> >> pushed request. >> >> >> >> Additional text for Section 4 (note that this section pertains to the >> authorization endpoint): >> >> The AS MUST validate authorization requests arising from a pushed request as >> >> it would any other authorization request. The AS MAY omit validation steps >> >> that it performed when the request was pushed, provided that it can validate >> >> that the request was a pushed request, and that the request has not been >> >> modified in a way that would affect the outcome of the omitted steps. >> >> >> >> This is longer than the current text and the other proposals, but it adds a >> few important points: >> • Turns the 2.1 SHOULD back into a MUST, with an explicit exception for >> validation that can’t be done yet. >> • Reinforces the fact that the authorization endpoint still needs to do >> validation. >> • Clearly states requirements for when an AS can trust that validation >> happened at the PAR endpoint. >> >> – >> Annabelle Richard Backman >> AWS Identity >> >> >> From: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> >> Date: Tuesday, January 7, 2020 at 2:54 PM >> To: Vladimir Dzhuvinov <vladi...@connect2id.com> >> Cc: Filip Skokan <panva...@gmail.com>, "Richard Backman, Annabelle" >> <richa...@amazon.com>, Dave Tonge <dave.to...@moneyhub.com>, oauth >> <oauth@ietf.org>, Nat Sakimura <n...@sakimura.org> >> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR >> metadata >> >> A little more context about that proposed wording is in a github issue at >>> >>>>> • >>>>> • >>>>> • >>>>> • >>>>> • > 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.. > > I rather like your suggested text, Vladimir, and have mentioned it in a > comment on the aforementioned issue. > > > On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov > <vladi...@connect2id.com> wrote: > On 07/01/2020 00:22, Filip Skokan wrote: > We've been discussing making the following change to the language > > 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 > > 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’d like you to do this, but we can’t always require it". This > supports "light weight PAR" implementation rather than introducing the > unnecessary complexity in the form of a second JWKS. > > Best, > Filip > > > On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle > <richanna=40amazon....@dmarc.ietf.org> wrote: > The issue isn’t 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’s 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’s 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’t simply stash the encrypted request object, as it is > required to verify the request, according to §2.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’d be a good start and makes sense in its own right. > > > > I think it’s 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’re 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’s authN/authZ stack doesn’t 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. > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > From: Neil Madden <neil.mad...@forgerock.com> > Date: Monday, January 6, 2020 at 6:29 AM > To: Brian Campbell <bcampb...@pingidentity.com> > Cc: "Richard Backman, Annabelle" <richa...@amazon.com>, Nat Sakimura > <n...@sakimura.org>, Dave Tonge <dave.to...@moneyhub.com>, Torsten > Lodderstedt <tors...@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=40pingidentity....@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=40amazon....@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. > > – > Annabelle Richard Backman > AWS Identity > > > On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" > <oauth-boun...@ietf.org on behalf of > torsten=40lodderstedt....@dmarc.ietf.org> wrote: > > Hi Filip, > >> On 31. Dec 2019, at 16:22, Filip Skokan <panva...@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 <tors...@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’s your opinion? >> >> best regards, >> Torsten. > > > > _______________________________________________ > 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 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
