<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#002060;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">It is always mandatory for the server to include the nonce in the ID Token if provided in the request and it is likewise always mandatory for the RP to validate
the nonce, if present in the ID Token. For all response_type values other than “code”, including a nonce in the request is also mandatory.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"><o:p> </o:p></span></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Openid-specs-ab [mailto:openid-specs-ab-bounces@lists.openid.net]
<b>On Behalf Of </b>John Bradley<br>
<b>Sent:</b> Tuesday, April 12, 2016 5:31 PM<br>
<b>To:</b> William Denniss <wdenniss@google.com><br>
<b>Cc:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] Defining a Hardened (Mix-up and Cut-and-Paste Proof) OpenID Connect Profile<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If they send it and don’t detect if it has changed from the request then that is a definite error.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If they don’t send it, it should be a warning as there are some cases with a simple preconfigured client that not checking may be OK.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I personally argued at the time to always check it, so I am not going to push back very hard on making it mandatory to check other than it is a change to the spec.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Apr 12, 2016, at 5:34 PM, William Denniss <<a href="mailto:wdenniss@google.com">wdenniss@google.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On Tue, Apr 12, 2016 at 2:28 PM, John Bradley<span class="apple-converted-space"> </span><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>><span class="apple-converted-space"> </span>wrote:<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">The AS is all-ready required to include nonce in the id_token if it is present in the request. That is a MUST in the spec.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">That should be a test all-ready.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">There is: </span><i><span style="font-size:9.5pt;font-family:"Helvetica",sans-serif">ID Token has nonce when requested for code flow [Basic] (OP-nonce-code)</span></i><i><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span></i><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">So for this, it's more that we need to add an RP test to ensure that RPs are actually sending and verifying nonce.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Basically fragment encoding is not a good idea any more other than for JS in the browser or for native apps using view controllers or system browsers.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Servers really should support the form post response mode.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">A client that wants to be secure can send nonce and use “code id_token” if they want offline or “token id_token” if they don’t want offline.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">That is secure. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">There are other mitigations we talked about in OAuth with returning the client_id and iss as parameters rather than returning a id_token.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">The client really only needs to check those two values in the front channel, but I would not want to change the spec to say that.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">+1 to all the above<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">John B.<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On Apr 12, 2016, at 4:58 PM, William Denniss <<a href="mailto:wdenniss@google.com">wdenniss@google.com</a>> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
On Tue, Apr 12, 2016 at 12:50 PM, Hans Zandbelt <<a href="mailto:hzandbelt@pingidentity.com">hzandbelt@pingidentity.com</a>> wrote:<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">from an implementers/deployment standpoint I would argue that if the id_token is delivered in the front channel, I may just as well get the access token from there too rather
than having to deal with the overhead of calling the token endpoint, esp. since at_hash is there to protect integrity<br>
<br>
so I'd favor response_mode=form_post, response_type="id_token token" over hybrid<br>
<br>
I realize that this doesn't leverage the possibility of using a client secret to get the access token but it doesn't really seem to matter security-wise at this point as the id_token was delivered without leveraging it as well<br>
<br>
anything wrong with that line of reasoning?<o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">1) Server won't have offline access with "id_token token". 2) The primary case we are dealing with today is the code flow, and we are really just suggesting clients add security
checks onto their existing flows by leveraging id_token.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">It's true that you could do many of the same checks with "id_token token" to verify that the access token was issued by the correct party and avoid cut-and-paste and mix-up,
if you only needed a once-off access token.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">You raise an interesting point regarding client confidentiality.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On 4/12/16 9:23 PM, William Denniss wrote:<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Good point.<br>
<br>
Regarding the OP tests, the following are relevant to mitigate the<br>
cut-and-paste and mix-up attacks:<br>
<br>
1. ID Token has nonce when requested for code flow [Basic] (OP-nonce-code)<br>
2. Request with response_mode=form_post [Extra] (OP-Response-form_post)<br>
<br>
1) is important for preventing cut-and-paste (the id token needs to<br>
contain the 'nonce')<br>
2) is important for preventing mix-up as it means the redirect endpoint<br>
gets the id_token on the response at the server, as opposed to in the<br>
URI fragment.<br>
<br>
Unfortunately, form_post is optional for OPs, and sending the nonce on<br>
the code flow is optional for RPs (though fortunately to it is<br>
compulsory for OPs to support thanks to OP-nonce-code).<br>
<br>
We could add an hardened OP test for:<br>
– Forcing nonce to be present on the code flow<br>
<br>
We should definitely have RP tests for:<br>
– sending and validating nonce on the code flow<br>
– validating the c_hash, iss, aud on the hybrid flow<br>
<br>
How we would profile these tests I'm not sure; would they go in the<br>
Basic testing profile, or in a new Hardened one? We could move<br>
OP-Response-form_post to the Basic profile if we wanted to be<br>
opinionated, or define a new profile.<br>
<br>
The good news is that supporting the features required to mitigate<br>
mix-up & cut-and-paste is not all that hard to do in Connect.<br>
<br>
<br>
On Tue, Apr 12, 2016 at 10:46 AM, Nick Roy <<a href="mailto:nroy@internet2.edu">nroy@internet2.edu</a><br>
<mailto:<a href="mailto:nroy@internet2.edu">nroy@internet2.edu</a>>> wrote:<br>
<br>
<span class="apple-converted-space"> </span>Would it be possible to check for the secure behavior in Roland's<br>
<span class="apple-converted-space"> </span>test suite and either not certify non-mitigating implementations, or<br>
<span class="apple-converted-space"> </span>offer a risk mitigation add-on cert for those that do the right thing?<br>
<br>
<span class="apple-converted-space"> </span>Nick<br>
<br>
<span class="apple-converted-space"> </span>From: Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a><br>
<span class="apple-converted-space"> </span><mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>>> on behalf of<br>
<span class="apple-converted-space"> </span>William Denniss <<a href="mailto:wdenniss@google.com">wdenniss@google.com</a> <mailto:<a href="mailto:wdenniss@google.com">wdenniss@google.com</a>>><br>
<span class="apple-converted-space"> </span>Date: Tuesday, April 12, 2016 at 11:01 AM<br>
<span class="apple-converted-space"> </span>To: "<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<span class="apple-converted-space"> </span><mailto:<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>"<br>
<span class="apple-converted-space"> </span><<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<span class="apple-converted-space"> </span><mailto:<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>><br>
<span class="apple-converted-space"> </span>Subject: [Openid-specs-ab] Defining a Hardened (Mix-up and<br>
<span class="apple-converted-space"> </span>Cut-and-Paste Proof) OpenID Connect Profile<br>
<br>
<span class="apple-converted-space"> </span>One item that came out of the discussions on the sidelines of IETF95<br>
<span class="apple-converted-space"> </span>with folk from this WG (specifically Nat, Mike, John, Brian and<br>
<span class="apple-converted-space"> </span>myself) was the need for the Connect community to respond to the<br>
<span class="apple-converted-space"> </span>recently <<a href="http://arxiv.org/abs/1508.04324v2/">http://arxiv.org/abs/1508.04324v2/</a>> documented<br>
<span class="apple-converted-space"> </span><<a href="http://arxiv.org/abs/1601.01229v2/">http://arxiv.org/abs/1601.01229v2/</a>> security threats.<br>
<br>
Connect is actually in a much stronger place for mitigating these<br>
attacks (as noted in the papers themselves) than pure OAuth, with<br>
the id_token offering a cryptographic binding of the code to the<br>
issuer, audience and session identifier (nonce).<br>
<br>
However, certain steps need to be followed, for example using<br>
'nonce' with the code flow (which is optional to implement for<br>
clients) to protect against cut-and-paste, and using the form-post<br>
response type with the hybrid flow to verify that the code was<br>
issued by the expected IdP, to ensure the code is exchanged at the<br>
correct token endpoint (mitigating mix-up).<br>
<br>
We discussed last week creating a profile of Connect that recommends<br>
those practices to mitigate these classes of attack as a response to<br>
the security researchers' findings. I wanted to share that<br>
suggestion with the list, and continue the conversation.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#888888"><br>
-- <br>
Hans Zandbelt | Sr. Technical Architect<br>
<a href="mailto:hzandbelt@pingidentity.com">hzandbelt@pingidentity.com</a> | Ping Identity</span><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>