<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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. <div><br></div><div>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. <br><br><div id="AppleMailSignature">Odesláno z iPhonu</div><div><br>12. 8. 2018 v 9:32, Filip Skokan <<a href="mailto:panva.ip@gmail.com">panva.ip@gmail.com</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hello Mike, Ralph,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,32,96)">Mike> It’s not clear to me that this is needed. Rather, we could clarify that if “</span><i>request_object_signing_alg</i><span style="color:rgb(0,32,96)">” 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.</span></blockquote></div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,32,96)">Mike> And again, I believe that the OP can already require the use of encryption by publishing “request_object_encryption_</span><span style="color:rgb(0,32,96)">alg_values_supported” and “request_object_encryption_</span><span style="color:rgb(0,32,96)">enc_values_supported” metadata values.</span></blockquote><div><br></div><div>Neither one of these discovery metadata nor the registered client metadata makes making use of an encrypted Request Object a MUST. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0)">Ralph> None of the OB implementors have called out confusion with these values yet.</span></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,32,96)">Mike> Let’s talk about this on one of the upcoming working group calls.</span></blockquote><div><br></div><div>I'll do my best to be there.</div><div><br></div><div>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.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature">Best,<br><b>Filip</b></div></div></div><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Aug 12, 2018 at 9:12 AM Ralph Bragg via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net">openid-specs-fapi@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<div>
<div>
<div style="direction:ltr">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.
</div>
<div><br>
</div>
<div style="direction:ltr">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. </div>
</div>
<div><br>
</div>
<div class="gmail-m_-1445566292094227388ms-outlook-ios-signature"></div>
</div>
<div> </div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-1445566292094227388divRplyFwdMsg" dir="dir="ltr""><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> 31002760740n behalf of
<br>
<b>Sent:</b> Sunday, August 12, 2018 00:15<br>
<b>To:</b> Artifact Binding/Connect Working Group; <a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a><br>
<b>Cc:</b> Mike Jones<br>
<b>Subject:</b> Re: [Openid-specs-fapi] [Openid-specs-ab] Proposal for "Required Request Object Use" Dynamic Registration extension
<div> </div>
</font></div>
<div class="gmail-m_-1445566292094227388WordSection1">
<p class="MsoNormal"><span style="color:rgb(0,32,96)">Thanks for sending this, Filip. I’ve added some initial thoughts inline below, prefixed by “Mike>”.</span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> </span></p>
<p class="MsoNormal"><b>From:</b> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>>
<b>On Behalf Of </b>Filip Skokan via Openid-specs-ab<br>
<b>Sent:</b> Saturday, August 11, 2018 6:50 AM<br>
<b>To:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a> Ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>; <a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a><br>
<b>Cc:</b> Filip Skokan <<a href="mailto:panva.ip@gmail.com" target="_blank">panva.ip@gmail.com</a>><br>
<b>Subject:</b> [Openid-specs-ab] Proposal for "Required Request Object Use" Dynamic Registration extension</p>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">Hello everyone,</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><b>1) signaling that a request object must always be present in Client's authorization requests</b></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">why are current parameters not enough?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">The closest comes <i>request_object_signing_alg</i>, but its worded as
<i>"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 ...".</i></p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Proposed client registration metadata:</p>
</div>
<div>
<p class="MsoNormal" style="margin-top:6pt"><span style="font-size:10pt;font-family:"Courier New";color:black">request_object_required</span><span style="font-size:10pt;color:black"></span></p>
<p class="MsoNormal" style="margin-right:24pt;margin-left:0.5in;margin-bottom:0.0001pt">
<span style="font-size:10pt;font-family:"Courier New";color:black">OPTIONAL. Boolean value specifying whether the OP should accept an Authorization Request without a Request Object for processing. If <samp>true</samp>, the OP MUST reject Authorization Requests
without Request Object passed by value (using the <samp>request</samp> parameter) or by reference (using the <samp>request_uri</samp> parameter) with the error <samp>invalid_request</samp>. If omitted, the default value is <samp>false</samp>.</span><span style="font-size:10pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)">Mike> It’s not clear to me that this is needed. Rather, we could clarify that if “</span><i>request_object_signing_alg</i><span style="color:rgb(0,32,96)">” 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.</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><b>2) enforcing request object encryption</b> - this one I didn't quite figure out a vector for yet</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">why are current parameters not enough?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><i>request_object_encryption_alg</i> states <i>"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."</i> so the request object may still be sent without encryption.</p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)">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.</span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> </span></p>
</div>
<div>
<p class="MsoNormal">Proposed client registration metadata:</p>
</div>
<div>
<p class="MsoNormal" style="margin-top:6pt"><span style="font-size:10pt;font-family:"Courier New";color:black">request_object_encryption_alg_required</span><span style="font-size:10pt;color:black"></span></p>
<p class="MsoNormal" style="margin-right:24pt;margin-left:0.5in;margin-bottom:0.0001pt">
<span style="font-size:10pt;font-family:"Courier New";color:black">OPTIONAL. Boolean value specifying whether the <samp>alg</samp> algorithm specified by <samp>request_object_encryption_alg</samp> MUST be used for encrypting Request Objects sent to the
OP. When <samp>request_object_encryption_alg_required</samp> is <samp>true</samp> all Authorization Requests with Request Objects from this Client MUST be rejected with the error <samp>invalid_request_object</samp>, if not encrypted with this algorithm or
not encrypted at all. When <samp>request_object_encryption_alg_required</samp> is <samp>true</samp>, <samp>request_object_encryption_alg </samp>MUST also be provided and this algorithm MUST be used both when the Request Object is passed by value (using the <samp>request</samp> parameter)
and when it is passed by reference (using the <samp>request_uri</samp> parameter). If omitted, the default value is <samp>false</samp>.</span><span style="font-size:10pt;color:black"></span></p>
<p class="MsoNormal" style="margin-top:6pt"><span style="font-size:10pt;font-family:"Courier New";color:black">request_object_encryption_enc_required</span><span style="font-size:10pt;color:black"></span></p>
<p class="MsoNormal" style="margin-right:24pt;margin-left:0.5in;margin-bottom:0.0001pt">
<span style="font-size:10pt;font-family:"Courier New";color:black">OPTIONAL. Boolean value specifying whether the <samp>enc</samp> algorithm specified by <samp>request_object_encryption_enc</samp> MUST be used for encrypting Request Objects sent to the
OP. When <samp>request_object_encryption_enc_required</samp> is <samp>true</samp> all Authorization Requests with Request Objects from this Client MUST be rejected with the error <samp>invalid_request_object</samp>, if not encrypted with this algorithm or
not encrypted at all. When <samp>request_object_encryption_enc_required</samp> is <samp>true</samp>, <samp>request_object_encryption_enc </samp>MUST also be provided and this algorithm MUST be used both when the Request Object is passed by value (using the <samp>request</samp> parameter)
and when it is passed by reference (using the <samp>request_uri</samp> parameter). If omitted, the default value is <samp>false</samp>.</span><span style="font-size:10pt;color:black"></span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Additionally, having these metadata defined allows an OP to send these in Dynamic Registration Response as a policy of sorts.</p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)">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 *<b>how</b>*
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.</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Since my IPR Agreement for FAPI WG is not yet processed someone please forward there.</p>
</div>
<div>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> </span></p>
<div>
<div>
<p class="MsoNormal">Kind Regards,<br>
<b>Filip</b></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)">Mike> Let’s talk about this on one of the upcoming working group calls.</span><br clear="all">
<span style="color:rgb(0,32,96)"></span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> Thanks,</span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> -- Mike</span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> </span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
</blockquote></div></div>
</div></blockquote></div></body></html>