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

Filip Skokan panva.ip at gmail.com
Sun Aug 12 07:32:14 UTC 2018


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> 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
> *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
>
>
> _______________________________________________
> Openid-specs-fapi mailing list
> 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/3c949e95/attachment-0001.html>


More information about the Openid-specs-fapi mailing list