<div dir="ltr"><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 14, 2016 at 3:01 AM, Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    Hi William,<br>
    <br>
    why is form post important to prevent mix up? Are there variants of
    this attack utilizing changed treatment of URI fragments by
    browsers?<br>
    <br></div></blockquote><div><br></div><div>If you have a server side flow, and want to prevent mix up you need to validate c_hash so the token is bound to the code, and you can trust the other attributes like issuer, to verify the correct token endpoint to send the code to.<div><br></div><div>It isn't practical to ask developers to host javascript on the token endpoint that simply turns the id_token around and re-posts it to the server, hence to <i>realistically</i> solve this we need to support form-post.  If the solution is too wacky, nobody will adopt it so in my opinion, it's a non-starter without form_post.</div><div><br>Fortunately it's a very easy response mode to add, my team is already looking at it.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF">
    best regards,<br>
    Torsten.<div><div class="gmail-h5"><br>
    <br>
    <div>Am 12.04.2016 um 21:23 schrieb William
      Denniss:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="gmail-h5">
      <div dir="ltr">
        <div>Good point.</div>
        <div><br>
        </div>
        <div>Regarding the OP tests, the following are relevant to
          mitigate the cut-and-paste and mix-up attacks:</div>
        <div>
          <div>
            <ol>
              <li>ID Token has nonce when requested for code flow
                [Basic] (OP-nonce-code)<br>
              </li>
              <li>Request with response_mode=form_post [Extra]
                (OP-Response-form_post)<br>
              </li>
            </ol>
          </div>
        </div>
        <div>1) is important for preventing cut-and-paste (the id token
          needs to contain the 'nonce')</div>
        <div>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><br>
        </div>
        <div>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><br>
        </div>
        <div>We could add an hardened OP test for:</div>
        <div>– Forcing nonce to be present on the code flow</div>
        <div><br>
        </div>
        <div>We should definitely have RP tests for:</div>
        <div>– sending and validating nonce on the code flow</div>
        <div>– validating the c_hash, iss, aud on the hybrid flow</div>
        <div><br>
        </div>
        <div>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><br>
        </div>
        <div>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><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Apr 12, 2016 at 10:46 AM, Nick
          Roy <span dir="ltr"><<a href="mailto:nroy@internet2.edu">nroy@internet2.edu</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
            <div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:calibri,sans-serif">
              <div>
                <div>
                  <div>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><br>
                  </div>
                  <div>Nick</div>
                </div>
              </div>
              <div><br>
              </div>
              <span>
                <div style="font-family:calibri;font-size:12pt;text-align:left;color:black;border-width:1pt medium medium;border-style:solid none none;border-bottom-color:initial;border-left-color:initial;padding:3pt 0in 0in;border-top-color:rgb(181,196,223);border-right-color:initial">
                  <span style="font-weight:bold">From: </span>Openid-specs-ab
                  <<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>>
                  on behalf of William Denniss <<a href="mailto:wdenniss@google.com"></a><a href="mailto:wdenniss@google.com">wdenniss@google.com</a>><br>
                  <span style="font-weight:bold">Date: </span>Tuesday,
                  April 12, 2016 at 11:01 AM<br>
                  <span style="font-weight:bold">To: </span>"<a href="mailto:openid-specs-ab@lists.openid.net"></a><a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>"
                  <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>><br>
                  <span style="font-weight:bold">Subject: </span>[Openid-specs-ab]
                  Defining a Hardened (Mix-up and Cut-and-Paste Proof)
                  OpenID Connect Profile<br>
                </div>
                <div>
                  <div>
                    <div><br>
                    </div>
                    <div>
                      <div>
                        <div dir="ltr">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 href="http://arxiv.org/abs/1508.04324v2/">recently</a> <a href="http://arxiv.org/abs/1601.01229v2/">
                            documented</a> security threats.
                          <div><br>
                          </div>
                          <div>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><br>
                          </div>
                          <div>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><br>
                          </div>
                          <div>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><br>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </span>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><span class="gmail-"><pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </span></blockquote>
    <br>
  </div>

</blockquote></div><br></div></div></div>