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
