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

Ralph Bragg ralph.bragg at raidiam.com
Sun Aug 12 07:12:18 UTC 2018


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
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> 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 Ab <openid-specs-ab at lists.openid.net>; openid-specs-fapi at lists.openid.net
Cc: Filip Skokan <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180812/f33ee1a2/attachment.html>


More information about the Openid-specs-fapi mailing list