[Openid-specs-fapi] [Openid-specs-ab] Proposal for "Required Request Object Use" Dynamic Registration extension

Mike Jones Michael.Jones at microsoft.com
Sun Aug 12 17:08:22 UTC 2018


Wow – I’d forgotten the we even specified how to do symmetric encryption.  Are you aware of anyone actually doing this?

I do think I agree with Ralph that it’s up to the RP whether to do encryption.  I do agree that the OP wants to be able to reject requests that aren’t signed if that’s what its security profile requires.

                                                       -- Mike

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Filip Skokan via Openid-specs-ab
Sent: Sunday, August 12, 2018 1:51 AM
To: openid-specs-ab at lists.openid.net Ab <openid-specs-ab at lists.openid.net>; openid-specs-fapi at lists.openid.net
Cc: Filip Skokan <panva.ip at gmail.com>
Subject: Re: [Openid-specs-ab] [Openid-specs-fapi] Proposal for "Required Request Object Use" Dynamic Registration extension

I also gave a thought to just a new property saying encryption is required. But there’s a big difference in the symmetrical/non-symmetrical algs here.

Anyone can encrypt for the OP using its public assymetrical keys published in jwks_uri. But only the parties knowing a client secret can encrypt using the symmetrical ones. And since the current encryption alg language clearly says the RP may in the end use any supported alg, I went the route of proposing for enforcing the negotiated ones like so.
Odesláno z iPhonu

12. 8. 2018 v 9:32, Filip Skokan <panva.ip at gmail.com<mailto:panva.ip at gmail.com>>:
Hello Mike, Ralph,

Mike> It’s not clear to me that this is needed.  Rather, we could clarify that if “request_object_signing_alg” is present, it’s also to be interpreted as a request by the server to only send signed requests.  That would be simpler than adding an additional parameter.

Was this the initial intention of request_object_signing_alg or just algorithm negotiation again? Clarify how? IIRC you can't change the normative requirement, and currently there's none to be found in the language that would enforce this.

Mike> And again, I believe that the OP can already require the use of encryption by publishing “request_object_encryption_alg_values_supported” and  “request_object_encryption_enc_values_supported” metadata values.

Neither one of these discovery metadata nor the registered client metadata makes making use of an encrypted Request Object a MUST.

Ralph> None of the OB implementors have called out confusion with these values yet.

I'm not confused with the existing values either, it's just that they don't enforce the secure mode of operation that I think we should have the possibility of requiring. It's rather easy for FAPI implementers since they have a MUST in the spec so then they take these parameters as such. But I'd like to see that possible for a regular OP/PR, not just FAPI ones, without going against the normative language.

Mike> Let’s talk about this on one of the upcoming working group calls.

I'll do my best to be there.

Bottom line, if this comes down to be request_object_signing_alg missing a normative requirement to reject requests without it I believe errata would be a wrong choice here as there can't be any confusions with the current language that this is only applied IF request object is provided.

Best,
Filip

On Sun, Aug 12, 2018 at 9:12 AM Ralph Bragg via Openid-specs-fapi <openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>> wrote:
Personally I agree with Mike. None of the OB implementors have called out confusion with these values yet. Specifying whether or not I need to encrypt or sign a request should be up to the RP not the OP, if the content is sensitive, for example it includes claim values to be verified it should be encrypted, if it does not then signing works for me.

Additionally, for FAPI, given the focus on requirement for non repudiation and UA /MITB attacks, I’d prefer to see the language tightened up so that all requests are sent by the signed request so mikes langauage change to use the presence of the alg a requirement for use as well works for me. Ultimately it doesn’t make a huge difference except to improve consistency of configuration which is a good thing so if the majority wants to explicitly add these IANA types then that’s fine as well. existing implementations can be extended easily enough.


________________________________
From: 31002760740n behalf of
Sent: Sunday, August 12, 2018 00:15
To: Artifact Binding/Connect Working Group; openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>
Cc: Mike Jones
Subject: Re: [Openid-specs-fapi] [Openid-specs-ab] Proposal for "Required Request Object Use" Dynamic Registration extension

Thanks for sending this, Filip.  I’ve added some initial thoughts inline below, prefixed by “Mike>”.

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>> On Behalf Of Filip Skokan via Openid-specs-ab
Sent: Saturday, August 11, 2018 6:50 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net> Ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>; openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>
Cc: Filip Skokan <panva.ip at gmail.com<mailto:panva.ip at gmail.com>>
Subject: [Openid-specs-ab] Proposal for "Required Request Object Use" Dynamic Registration extension

Hello everyone,

I'd like to propose an additional (or Dynamic Registration 1.1) entry into the openid spec family / IANA "OAuth Dynamic Client Registration Metadata" that allows for OPs and RPs to get assurances about the used JWT Request Objects in Authorization Requests.


1) signaling that a request object must always be present in Client's authorization requests

why are current parameters not enough?

The closest comes request_object_signing_alg, but its worded as "All Request Objects from this Client MUST be rejected, if not signed with this algorithm. ... This algorithm MUST be used both when the Request Object is passed by value or ...".
Meaning if there's no request object at all, request is still valid. This allows a malicious user to form his own authorization request with the properties the RP wishes to protect (e.g. claims containing PII, required amr or other sensitive information necessary for the authorization request, max_age, acr_values) in the query instead.

Proposed client registration metadata:
request_object_required
OPTIONAL. Boolean value specifying whether the OP should accept an Authorization Request without a Request Object for processing. If true, the OP MUST reject Authorization Requests without Request Object passed by value (using the request parameter) or by reference (using the request_uri parameter) with the error invalid_request. If omitted, the default value is false.

Mike> It’s not clear to me that this is needed.  Rather, we could clarify that if “request_object_signing_alg” is present, it’s also to be interpreted as a request by the server to only send signed requests.  That would be simpler than adding an additional parameter.

2) enforcing request object encryption - this one I didn't quite figure out a vector for yet

why are current parameters not enough?

request_object_encryption_alg states "JWE algorithm the RP is declaring that it may use for encrypting Request Objects sent to the OP. ... The RP MAY still use other supported encryption algorithms or send unencrypted Request Objects, even when this parameter is present." so the request object may still be sent without encryption.
This smells of a very easy downgrade-attack (when symmetrical encryption is used) vulnerability with no normative protection against it. I mention I can't figure out a vector for this but just plain possibility of abandoning high-quality mode of operation directly in the specification is what I wish to get rid of.

Mike> This parameter (and the “enc” variant) are about telling the OP about the encryption capabilities of the RP.  This is one half of the algorithm negotiation.  I believe that it’s the OP’s decision whether to require encryption of request objects – not the RP’s.

Proposed client registration metadata:
request_object_encryption_alg_required
OPTIONAL. Boolean value specifying whether the alg algorithm specified by request_object_encryption_alg MUST be used for encrypting Request Objects sent to the OP. When request_object_encryption_alg_required is true all Authorization Requests with Request Objects from this Client MUST be rejected with the error invalid_request_object, if not encrypted with this algorithm or not encrypted at all. When request_object_encryption_alg_required is true, request_object_encryption_alg MUST also be provided and this algorithm MUST be used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). If omitted, the default value is false.
request_object_encryption_enc_required
OPTIONAL. Boolean value specifying whether the enc algorithm specified by request_object_encryption_enc MUST be used for encrypting Request Objects sent to the OP. When request_object_encryption_enc_required is true all Authorization Requests with Request Objects from this Client MUST be rejected with the error invalid_request_object, if not encrypted with this algorithm or not encrypted at all. When request_object_encryption_enc_required is true, request_object_encryption_enc MUST also be provided and this algorithm MUST be used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). If omitted, the default value is false.

Additionally, having these metadata defined allows an OP to send these in Dynamic Registration Response as a policy of sorts.

Mike> First, these two parameters really should just be one – if adopted, because what you’re really saying is that encryption is required.  (It just happens that you need two algorithms values to say *how* the encryption is done.)  And again, I believe that the OP can already require the use of encryption by publishing “request_object_encryption_alg_values_supported” and  “request_object_encryption_enc_values_supported” metadata values.  I believe that adding this RP metadata value would likely be redundant.

I'd like to get your feedback on this proposal and I am also able to form a specification around this if it's welcome.

I'm sending this to both AB/Connect and FAPI working groups, considering that FAPI requires the use of signed and/or encrypted request objects Mike Jones figured it'd be something you might be interested in. While some form of normative requirement is already present in the FAPI specifications introducing these metadata MAY allow a single OP to operate both in secure and insecure modes at the same time depending on the provisioned or dynamically registered client.

Since my IPR Agreement for FAPI WG is not yet processed someone please forward there.

Kind Regards,
Filip

Mike> Let’s talk about this on one of the upcoming working group calls.
                                                       Thanks,
                                                       -- Mike

_______________________________________________
Openid-specs-fapi mailing list
Openid-specs-fapi at lists.openid.net<mailto:Openid-specs-fapi at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-fapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180812/a9a1d670/attachment-0001.html>


More information about the Openid-specs-fapi mailing list