<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">It is not directly important. It make it easier for clients that want to use “code id_token” to do that easily and securely as they don’t need to have JS on the return page. The default fragment encoding is now not as secure as POST due to browser changes. <div class=""><br class=""></div><div class="">So fragment encoding is a separate issue, but related due to one of the best mitigations for mix-up being the “code id_token” response type.</div><div class=""><br class=""></div><div class="">John B.<br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 14, 2016, at 6:01 AM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" class="">torsten@lodderstedt.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Hi William,<br class="">
<br class="">
why is form post important to prevent mix up? Are there variants of
this attack utilizing changed treatment of URI fragments by
browsers?<br class="">
<br class="">
best regards,<br class="">
Torsten.<br class="">
<br class="">
<div class="moz-cite-prefix">Am 12.04.2016 um 21:23 schrieb William
Denniss:<br class="">
</div>
<blockquote cite="mid:CAAP42hD8=G2Td8Q9qgeRtHeXtMcGL_TKHaLDMk5OL9fEEWSLmQ@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">
<div class="">Good point.</div>
<div class=""><br class="">
</div>
<div class="">Regarding the OP tests, the following are relevant to
mitigate the cut-and-paste and mix-up attacks:</div>
<div class="">
<div class="">
<ol class="">
<li class="">ID Token has nonce when requested for code flow
[Basic] (OP-nonce-code)<br class="">
</li>
<li class="">Request with response_mode=form_post [Extra]
(OP-Response-form_post)<br class="">
</li>
</ol>
</div>
</div>
<div class="">1) is important for preventing cut-and-paste (the id token
needs to contain the 'nonce')</div>
<div class="">2) is important for preventing mix-up as it means the
redirect endpoint gets the id_token on the response at the
server, as opposed to in the URI fragment.</div>
<div class=""><br class="">
</div>
<div class="">Unfortunately, form_post is optional for OPs, and sending
the nonce on the code flow is optional for RPs (though
fortunately to it is compulsory for OPs to support thanks to
OP-nonce-code).</div>
<div class=""><br class="">
</div>
<div class="">We could add an hardened OP test for:</div>
<div class="">– Forcing nonce to be present on the code flow</div>
<div class=""><br class="">
</div>
<div class="">We should definitely have RP tests for:</div>
<div class="">– sending and validating nonce on the code flow</div>
<div class="">– validating the c_hash, iss, aud on the hybrid flow</div>
<div class=""><br class="">
</div>
<div class="">How we would profile these tests I'm not sure; would they
go in the Basic testing profile, or in a new Hardened one? We
could move OP-Response-form_post to the Basic profile if we
wanted to be opinionated, or define a new profile.</div>
<div class=""><br class="">
</div>
<div class="">The good news is that supporting the features required to
mitigate mix-up & cut-and-paste is not all that hard to do
in Connect.</div>
<div class=""><br class="">
</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Tue, Apr 12, 2016 at 10:46 AM, Nick
Roy <span dir="ltr" class=""><<a moz-do-not-send="true" href="mailto:nroy@internet2.edu" target="_blank" class="">nroy@internet2.edu</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap: break-word; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class="">
<div class="">
<div class="">Would it be possible to check for the secure
behavior in Roland's test suite and either not
certify non-mitigating implementations, or offer a
risk mitigation add-on cert for those that do the
right thing?</div>
<div class=""><br class="">
</div>
<div class="">Nick</div>
</div>
</div>
<div class=""><br class="">
</div>
<span class="">
<div style="font-family: Calibri; font-size: 12pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span>Openid-specs-ab
<<a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank" class="">openid-specs-ab-bounces@lists.openid.net</a>>
on behalf of William Denniss <<a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank" class=""></a><a class="moz-txt-link-abbreviated" href="mailto:wdenniss@google.com">wdenniss@google.com</a>><br class="">
<span style="font-weight:bold" class="">Date: </span>Tuesday,
April 12, 2016 at 11:01 AM<br class="">
<span style="font-weight:bold" class="">To: </span>"<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank" class=""></a><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>"
<<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank" class="">openid-specs-ab@lists.openid.net</a>><br class="">
<span style="font-weight:bold" class="">Subject: </span>[Openid-specs-ab]
Defining a Hardened (Mix-up and Cut-and-Paste Proof)
OpenID Connect Profile<br class="">
</div>
<div class="">
<div class="h5">
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div dir="ltr" class="">One item that came out of the
discussions on the sidelines of IETF95 with
folk from this WG (specifically Nat, Mike,
John, Brian and myself) was the need for the
Connect community to respond to the
<a moz-do-not-send="true" href="http://arxiv.org/abs/1508.04324v2/" target="_blank" class="">recently</a> <a moz-do-not-send="true" href="http://arxiv.org/abs/1601.01229v2/" target="_blank" class="">
documented</a> security threats.
<div class=""><br class="">
</div>
<div class="">Connect is actually in a much stronger
place for mitigating these attacks (as noted
in the papers themselves) than pure OAuth,
with the id_token offering a cryptographic
binding of the code to the issuer, audience
and session identifier (nonce).</div>
<div class=""><br class="">
</div>
<div class="">However, certain steps need to be
followed, for example using 'nonce' with the
code flow (which is optional to implement
for clients) to protect against
cut-and-paste, and using the form-post
response type with the hybrid flow to verify
that the code was issued by the expected
IdP, to ensure the code is exchanged at the
correct token endpoint (mitigating mix-up).</div>
<div class=""><br class="">
</div>
<div class="">We discussed last week creating a profile
of Connect that recommends those practices
to mitigate these classes of attack as a
response to the security researchers'
findings. I wanted to share that suggestion
with the list, and continue the
conversation.</div>
<div class=""><br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</span>
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></div></body></html>