[Openid-specs-ab] Defining a Hardened (Mix-up and Cut-and-Paste Proof) OpenID Connect Profile

William Denniss wdenniss at google.com
Tue Apr 12 21:34:45 UTC 2016


On Tue, Apr 12, 2016 at 2:28 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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.
> That should be a test all-ready.
>

There is: *ID Token has nonce when requested for code flow [Basic]
(OP-nonce-code) *

So for this, it's more that we need to add an RP test to ensure that RPs
are actually sending and verifying nonce.

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.
>
> Servers really should support the form post response mode.
>
> 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.
>
> That is secure.
>
> There are other mitigations we talked about in OAuth with returning the
> client_id and iss as parameters rather than returning a id_token.
>
> 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.
>

+1 to all the above


>
>
>
> John B.
>
> On Apr 12, 2016, at 4:58 PM, William Denniss <wdenniss at google.com> wrote:
>
>
> On Tue, Apr 12, 2016 at 12:50 PM, Hans Zandbelt <
> hzandbelt at pingidentity.com> wrote:
>
>> 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
>>
>> so I'd favor response_mode=form_post, response_type="id_token token" over
>> hybrid
>>
>> 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
>>
>> anything wrong with that line of reasoning?
>>
>
> 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.
>
> 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.
>
> You raise an interesting point regarding client confidentiality.
>
>
>> On 4/12/16 9:23 PM, William Denniss wrote:
>>
>>> Good point.
>>>
>>> Regarding the OP tests, the following are relevant to mitigate the
>>> cut-and-paste and mix-up attacks:
>>>
>>>  1. ID Token has nonce when requested for code flow [Basic]
>>> (OP-nonce-code)
>>>  2. Request with response_mode=form_post [Extra] (OP-Response-form_post)
>>>
>>> 1) is important for preventing cut-and-paste (the id token needs to
>>> contain the 'nonce')
>>> 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.
>>>
>>> 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).
>>>
>>> We could add an hardened OP test for:
>>> – Forcing nonce to be present on the code flow
>>>
>>> We should definitely have RP tests for:
>>> – sending and validating nonce on the code flow
>>> – validating the c_hash, iss, aud on the hybrid flow
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>> On Tue, Apr 12, 2016 at 10:46 AM, Nick Roy <nroy at internet2.edu
>>> <mailto:nroy at internet2.edu>> wrote:
>>>
>>>     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?
>>>
>>>     Nick
>>>
>>>     From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net
>>>     <mailto:openid-specs-ab-bounces at lists.openid.net>> on behalf of
>>>     William Denniss <wdenniss at google.com <mailto:wdenniss at google.com>>
>>>     Date: Tuesday, April 12, 2016 at 11:01 AM
>>>     To: "openid-specs-ab at lists.openid.net
>>>     <mailto:openid-specs-ab at lists.openid.net>"
>>>     <openid-specs-ab at lists.openid.net
>>>     <mailto:openid-specs-ab at lists.openid.net>>
>>>     Subject: [Openid-specs-ab] Defining a Hardened (Mix-up and
>>>     Cut-and-Paste Proof) OpenID Connect Profile
>>>
>>>     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
>>>     recently <http://arxiv.org/abs/1508.04324v2/> documented
>>>     <http://arxiv.org/abs/1601.01229v2/> security threats.
>>>
>>>     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).
>>>
>>>     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).
>>>
>>>     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.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>> --
>> Hans Zandbelt              | Sr. Technical Architect
>> hzandbelt at pingidentity.com | Ping Identity
>>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160412/f454b60f/attachment.html>


More information about the Openid-specs-ab mailing list