<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Depends if you want to expose the access token to the browser/user machine/outside your server - as opposed to wanting it to use pure server-side.</div> <br> <div id="bloop_sign_1460558103056109824" class="bloop_sign"><div>— </div><div>cheers<br>Dominick Baier</div></div> <br><p class="airmail_on">On 12 April 2016 at 20:58:41, Hans Zandbelt (<a href="mailto:hzandbelt@pingidentity.com">hzandbelt@pingidentity.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>from an implementers/deployment standpoint I would argue that if the  
<br>id_token is delivered in the front channel, I may just as well get the  
<br>access token from there too rather than having to deal with the overhead  
<br>of calling the token endpoint, esp. since at_hash is there to protect  
<br>integrity
<br>
<br>so I'd favor response_mode=form_post, response_type="id_token token"  
<br>over hybrid
<br>
<br>I realize that this doesn't leverage the possibility of using a client  
<br>secret to get the access token but it doesn't really seem to matter  
<br>security-wise at this point as the id_token was delivered without  
<br>leveraging it as well
<br>
<br>anything wrong with that line of reasoning?
<br>
<br>Hans.
<br>
<br>On 4/12/16 9:23 PM, William Denniss wrote:
<br>> 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 <nroy@internet2.edu
<br>> <mailto:nroy@internet2.edu>> wrote:
<br>>
<br>>     Would it be possible to check for the secure behavior in Roland's
<br>>     test suite and either not certify non-mitigating implementations, or
<br>>     offer a risk mitigation add-on cert for those that do the right thing?
<br>>
<br>>     Nick
<br>>
<br>>     From: Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net
<br>>     <mailto:openid-specs-ab-bounces@lists.openid.net>> on behalf of
<br>>     William Denniss <wdenniss@google.com <mailto:wdenniss@google.com>>
<br>>     Date: Tuesday, April 12, 2016 at 11:01 AM
<br>>     To: "openid-specs-ab@lists.openid.net
<br>>     <mailto:openid-specs-ab@lists.openid.net>"
<br>>     <openid-specs-ab@lists.openid.net
<br>>     <mailto:openid-specs-ab@lists.openid.net>>
<br>>     Subject: [Openid-specs-ab] Defining a Hardened (Mix-up and
<br>>     Cut-and-Paste Proof) OpenID Connect Profile
<br>>
<br>>     One item that came out of the discussions on the sidelines of IETF95
<br>>     with folk from this WG (specifically Nat, Mike, John, Brian and
<br>>     myself) was the need for the Connect community to respond to the
<br>>     recently <http://arxiv.org/abs/1508.04324v2/> documented
<br>>     <http://arxiv.org/abs/1601.01229v2/> 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>> Openid-specs-ab@lists.openid.net
<br>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
<br>>
<br>
<br>--  
<br>Hans Zandbelt              | Sr. Technical Architect
<br>hzandbelt@pingidentity.com | Ping Identity
<br>_______________________________________________
<br>Openid-specs-ab mailing list
<br>Openid-specs-ab@lists.openid.net
<br>http://lists.openid.net/mailman/listinfo/openid-specs-ab
<br></div></div></span></blockquote></body></html>