IETF Logo Mail Archive

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

Nat Sakimura <sakimura@gmail.com> Fri, 29 April 2016 08:08 UTC

Return-Path: <sakimura@gmail.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 7F4B312D54E for <oauth@ietfa.amsl.com>; Fri, 29 Apr 2016 01:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 Aw0SF9tYUs0k for <oauth@ietfa.amsl.com>; Fri, 29 Apr 2016 01:08:26 -0700 (PDT)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 4835C12D54A for <oauth@ietf.org>; Fri, 29 Apr 2016 01:08:26 -0700 (PDT)
Received: by mail-qg0-x22e.google.com with SMTP id f92so39765996qgf.0 for <oauth@ietf.org>; Fri, 29 Apr 2016 01:08:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ri880DrGn1aoVIsrNDMGlafNG8y5WgNCwsTo4fBeNPg=; b=WMzhxGt7UURG32OiJnOnsjI1NaQX1oGO/iUHyY3rCpKcg0Rb1JFOHEFxKasXQKi3hX N3E4on1ouKNwm4R5oxJ1/eAqsYi2HC25vBt4Yk4SKUthrJnksvWNvfXClNNYTulkCkCd tgSttnUeCkRoHF4TkrU3Hg52xqlKOxwBu/mdXb2tUU1bxGyU4FUnCGgLft2CPx5+s6dq 93hbvVKnBCTfTAYinOWaIJy+BmWrZfHNPF7JBJBnnfkA+JRyVPgiDNiiPV6NCbiYDc5T RbNVFKXsnLokciOrzX79SmB4mcLqTTyVetxVdOII+pGG1WGaSN6RJ/d2zDXdgnB3YqTS qhew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ri880DrGn1aoVIsrNDMGlafNG8y5WgNCwsTo4fBeNPg=; b=jxwpxc5gARFmyC1DDAY17k1wBGpQW1SiAc3kPtpGixKySIKzQCGaf/iUSudbe8+Tze 4ADCP+7cx2D6b6sL6k1qBD4MbZr0aHrrDdIB1DB0jmiOV0tQ7LAfsR1y37IppK6MoY2V 9WqyTTkIQK9y1AikrZcp+otyWWHgNyQFXixcGWtAucHclUNI0VG9DWIzCta85GU7GuTK zpJBfpLS78OlPSZLoy/W22ExzpwH1x2G2/3FQ3CdqUMlKrkcmGQ7lXWZGWHan8RZtl1c 3ffAqlf36RC+WlT7cDrZQSTZT5IAJkRPUEao8OAiWlblqCYwTxPxtCZPWoBV55egwkGx 7TUA==
X-Gm-Message-State: AOPr4FWG8/h5sk7jM31B7ZRz5h6SJiLUJlPDuE89nh+OKN9gFD2rn24EDNeftUgaGTTQU00hi0YTOFYvneZMVQ==
X-Received: by 10.140.92.65 with SMTP id a59mr17161497qge.93.1461917305300; Fri, 29 Apr 2016 01:08:25 -0700 (PDT)
MIME-Version: 1.0
References: <571B60BA.8090301@lodderstedt.net>
In-Reply-To: <571B60BA.8090301@lodderstedt.net>
From: Nat Sakimura <sakimura@gmail.com>
Date: Fri, 29 Apr 2016 08:08:15 +0000
Message-ID: <CABzCy2DeMSGc_yjKi=NWJjh7RLoVsb+KyD9S_MuiQ_gJNg5+fw@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="001a113ab29eac71a605319b2581"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/LqrWWzzAygogrsUCqPvE6yeXSyk>
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: Fri, 29 Apr 2016 08:08:28 -0000

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>
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
> 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)
> - 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
> https://www.ietf.org/mailman/listinfo/oauth
>

v2.23.0 | Report a Bug | By Email