Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

John Bradley <ve7jtb@ve7jtb.com> Sat, 30 April 2016 18:59 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEE212B074 for <oauth@ietfa.amsl.com>; Sat, 30 Apr 2016 11:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmp4d_ndZz8X for <oauth@ietfa.amsl.com>; Sat, 30 Apr 2016 11:59:49 -0700 (PDT)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56F912B047 for <oauth@ietf.org>; Sat, 30 Apr 2016 11:59:49 -0700 (PDT)
Received: by mail-pa0-x22a.google.com with SMTP id iv1so58366212pac.2 for <oauth@ietf.org>; Sat, 30 Apr 2016 11:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=8dMufa9phYtj7I/CdcxQxMOqIcV1nX/xy7n05KHpN6w=; b=IrAgePGOA92Q0JuxJKD7VJbQN1OYKmkRDtlQOtNYxHguc/EqG8A9XLAfQC37OQu9Vc iMnTa+8iKUClarW66clWKhhTmFRmcyxYYqgreVn/0dqxSGuJ4RZ14Ynkd8Tx1ntzYUHP ATDLu0wBApoC0DUiRkpBZasVGrZigahSpfW0dXVEGEjk61NJ3X0kc/0+xb3u4Xz712Gr YJLERo+Qy3IKy9OD9pWUxpKPzrU1dPcsHIuV/KaNP3uh0/f6O0BJnzcMcH3SOzXQgYWP i37HQVLuDfO4JWejCwveKl7Dwi20C1IdG+88g/uS79R/1vc0VOEot2z/JpAsPd/xvbCB jYnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8dMufa9phYtj7I/CdcxQxMOqIcV1nX/xy7n05KHpN6w=; b=EFKHnEGl5GLYxhrSXRa9I5HuLuvLyHIcQFgfdz/plZicOp4vo2YlRC+/8VsBkwA+o5 cKbTCZnkWLDxvX6EqQaa4/qz9Pp+ys+Kdct+iDo/8wczzmzFJbh3+cWkCPe3lOciBmhv CYqyxCiKKYw2pgNeI+uBQsyrWT1fZNtyQHu9BgzJSn5eGyf4zSvQYYpru1PE+kPUeAx1 b+BlH71yCT9IgyhjU99BrCPtpNLYw7s7DqFulY+10955azRC7xNqI9tHbjhhG8Ve4N5e xhFqdaJKTVB0ziFZQF2/r1dUcuqdHTlem+3KYU0JDfb6tZ34ZP2VGfhRm/rKTaSiQ+27 O+Ag==
X-Gm-Message-State: AOPr4FW8fm5VvqjjUYdx3THjkmmgXeoOSpTVsKckTf1n2tMTuwvz7wti9x9AueNeaVXirQ==
X-Received: by 10.66.231.98 with SMTP id tf2mr38881823pac.56.1462042789120; Sat, 30 Apr 2016 11:59:49 -0700 (PDT)
Received: from [192.168.6.172] (ip-64-134-232-170.public.wayport.net. [64.134.232.170]) by smtp.gmail.com with ESMTPSA id 82sm33088917pfb.64.2016.04.30.11.59.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 30 Apr 2016 11:59:48 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_65217B67-236F-4196-8E63-4060565E5EC2"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <7qet832ak9vsv4hji4buqow3.1462041761585@com.syntomo.email>
Date: Sat, 30 Apr 2016 11:59:45 -0700
Message-Id: <043FE1DF-B448-4EBE-929E-24268957224C@ve7jtb.com>
References: <571B60BA.8090301@lodderstedt.net> <CABzCy2DeMSGc_yjKi=NWJjh7RLoVsb+KyD9S_MuiQ_gJNg5+fw@mail.gmail.com> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> <A22A4BA7-26BE-4DB7-8946-32CEA142CCD9@ve7jtb.com> <7qet832ak9vsv4hji4buqow3.1462041761585@com.syntomo.email>
To: torsten@lodderstedt.net
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/8SGFfDb6olFw0IhZFnYQBbpiGWk>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Apr 2016 18:59:52 -0000

I made it in the draft.

Adding a identifier for the AS and the client_id to the response allows the client to detect if the request has been misdirected. 

I did have another proposal for integrity protecting the the request by having the client and AS calculate a HMAC over parts of the request and the code from the response.   That was the least crypto solution I could come up with for integrity protecting the request in a way the client can validate.

The problem is that not every client has a secret to sign the request with, so that leaves the AS effectively signing what it received in the request.

The other option is for OAuth clients not to talk to multiple AS, and not allow XSRF to trigger login requests.

The impression I have from the work group is that they are not comfortable enough understanding the attacks and there implications to work on mitigations yet.

I would be happy if someone else has a better idea on how to close these holes that requires minimal extra work by the client and AS.

At the moment I am trying to focus on Token binding and other things that people are interested in making progress on.

John B.

> On Apr 30, 2016, at 11:42 AM, torsten@lodderstedt.net wrote:
> 
> So what's your proposal for OAuth?
> 
> 
> 
> -------- Originalnachricht --------
> Betreff: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection
> Von: John Bradley <ve7jtb@ve7jtb.com>
> An: Torsten Lodderstedt <torsten@lodderstedt.net>
> Cc: Nat Sakimura <sakimura@gmail.com>,oauth@ietf.org
> 
> The attacks we are talking about (other than cut and paste) are not compromising the integrity of the response.
> 
> They rely on the response not containing enough information about the request that is received by the AS for the client to detect tampering with the request, or tricking the client into creating a new client_id based on bad information that includes the token or RS endpoint of the attacker.
> 
> As we discussed at IIW we need to do a better job creating a taxonomy for the parts of the attacks.  
> 
> At the moment when we say mixup that may mean quite different things to people.
> 
> Signing the response on it’s own is not much help.   The reason the connect id_token helps is not so much the signature, but rather that it contains the issuer and client_id as proposed in the draft Mike and I worked on.
> 
> If we wanted to sign something it would be better to sign the request to prevent a authorization request sent to one AS from being modified and sent to another AS.
> 
> It is also worth noting that the per AS redirect URI are not effective on there own agains all of the things in the bucket of mix up attacks.
> 
> I personally prefer that OpenID Connect not add anything new to mitigate this, however education on how to use the existing features for people who are concerned, or at risk is a responsible thing to do.
> 
> John B.
>> On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
>> 
>> Hi Nat,
>> 
>> sure, one could also authenticate and cryptographically protect the redirect response. Leveraging OIDC concepts is an idea worth considering but they should be adopted to the OAuth philosophy. The id token as used in the hybrid flows mixes an identity assertion with elements of transport security measures. A OAuth AS does not provide identity data to clients, so we only need the transport security part. 
>> I personally would prefer a OAuth response object (similar to request object you have proposed) over the id token. Such a response object could contain (and directly protect) state, code and other response values. I consider this the more elegant design and it is easier to implement then having detached signatures over hash values of codes or access tokens. Moreover, it would allow to encrypt the response as well. 
>> Generally, our threat analysis so far does not have provided justification for cryptographically protected redirect responses. All proposals currently on the table stop mix up and code injection using simpler mechanisms. 
>> I think OAuth 2.0 is a huge success due to its balance of versatility, security and _simplicity_. We definitely need to keep it secure, but we should also keep it as simple as possible.
>> kind regards,
>> Torsten.
>> Am 29.04.2016 um 10:08 schrieb Nat Sakimura:
>>> As I look at it more and more, it started to look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it. 
>>> 
>>> Any concrete ideas? 
>>> 
>>> On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
>>> Hi all,
>>> 
>>> discussion about Mix-Up and CnP seems to have stopped after the session
>>> in BA - at least in the OAuth WG. There is a discussion about
>>> mitigations in OpenId Connect going on at the OpenId Connect mailing list.
>>> 
>>> I'm very much interested to find a solution within the OAuth realm as
>>> I'm not interested to either implement two solutions (for OpenId Connect
>>> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens
>>> in the front channel). I therefore would like to see progress and
>>> propose to continue the discussion regarding mitigations for both threats.
>>> 
>>> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 <https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00>
>>> proposes reasonable mitigations for both attacks. There are alternatives
>>> as well:
>>> - mix up:
>>> -- AS specific redirect uris
>>> -- Meta data/turi
>>> (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5 <https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5>)
>>> - CnP:
>>> -- use of the nonce parameter (as a distinct mitigation beside state for
>>> counter XSRF)
>>> 
>>> Anyone having an opinion?
>>> 
>>> best regards,
>>> Torsten.
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>