<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; 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 id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<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">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">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><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>
</span>
</body>
</html>