Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Hans Zandbelt <hzandbelt@pingidentity.com> Thu, 28 January 2016 00:38 UTC

Return-Path: <hzandbelt@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9541A00EF for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 16:38:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
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 h0paNltAOsNb for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 16:38:23 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 8A6491B3981 for <oauth@ietf.org>; Wed, 27 Jan 2016 16:38:22 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id r129so3149784wmr.0 for <oauth@ietf.org>; Wed, 27 Jan 2016 16:38:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=CROdAGnkgV+Jc3q72cgMPkNfFqljBeuocX1lcyv4wNg=; b=kESr/cwhQfF6maaK8kZPAT9ZFHyg8f3NMWasXamKLXsuw0UloaVNquNgfelS1WmjpP 9deR3mGbO6pmxb/RJDJNb7WAO08uPkx2nXf1+XdmNgbzcBjGtSM9xFNw/8/7h0m/A21V cGQbW2pmWggApyxucsCdo6LI1suiOFZHij4zY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=CROdAGnkgV+Jc3q72cgMPkNfFqljBeuocX1lcyv4wNg=; b=eAgM8qPhOLthYbb1gmkpSnErFHUo/YgEDp8Awu4rB7dy1sSe7GXxrlip/T0GbDZiy7 T+KBt0akDs0F7Si0/ok36ckDnCCglzYWUFbtr5K5BU1fX6aVpz/JUFpK2AZjSR2ZwKqD aXjKpGpJHqLE3KeWbrX37AdhvrmCl/H8Bqz7HrZzXHX31e9BNRjPR825MKrZ5hE9xg4V BQGVG3Ga+K2NM6YeEsCCmP6+BLbfa4sCR/RsXmbuwE0l4191PS5QVjwKRgC8lmtrEhaV Oxm4hZHff/wjbWx1p1aJKbmTS7hcEP59yvN2rWQBhPnzTbrTMAP3SihpA6OcGNdlw2Qz NWsA==
X-Gm-Message-State: AG10YOQJVqLqilRUFYZsXFnDtkGqZifOHTbmywQTXT4eyzBvUxp5oWVTLTwJrJF/QiJ+pAA6
X-Received: by 10.28.54.65 with SMTP id d62mr45915wma.35.1453941500914; Wed, 27 Jan 2016 16:38:20 -0800 (PST)
Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by smtp.gmail.com with ESMTPSA id m206sm343673wmf.16.2016.01.27.16.38.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 16:38:19 -0800 (PST)
To: Nat Sakimura <sakimura@gmail.com>, Justin Richer <jricher@mit.edu>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com> <DDFE7F75-46BB-4868-8548-CF449452EB69@gmail.com> <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com> <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com> <63914724-175F-47EA-BC48-5FB9E6C5FE87@ve7jtb.com> <CABzCy2A6UwB5PmwdAkvaWtz1UVE9r8E1qmOJYHWtG7O2S3FEPg@mail.gmail.com> <56A8BB7C.80702@aol.com> <56A8BCC3.6030903@aol.com> <CABzCy2BFP2pOoFML4DujF3Q9F0=1nqw_6uVaVrsjZFTs7hE1ow@mail.gmail.com> <F89550EB-EBED-4AB3-BF6F-B15D6B4DD7A3@mit.edu> <56A92F08.9050706@pingidentity.com> <CABzCy2BniK8586Ka_pb3Wz26MUkdRBZK1CsJe=W7TX179+Wh5A@mail.gmail.com>
From: Hans Zandbelt <hzandbelt@pingidentity.com>
Message-ID: <56A962FA.2010004@pingidentity.com>
Date: Thu, 28 Jan 2016 01:38:18 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CABzCy2BniK8586Ka_pb3Wz26MUkdRBZK1CsJe=W7TX179+Wh5A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/aHetT5i7bdSQ41gZ5-_hxN0ud3M>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 28 Jan 2016 00:38:27 -0000

indeed, if the attacker is able to phish the user, he can put up a 
script that first triggers the authorization request to the compromised 
AS (i.e. the AS at which he has access to the logs and gathers the state 
value from) through the Client, and subsequently trigger the redirect to 
the good AS using an auto-refresh of that same phishing page (with the 
stolen state value); no need to control the authorization endpoint of 
the compromised AS itself

Hans.

On 1/28/16 1:04 AM, Nat Sakimura wrote:
> Interesting.
> No code change even at the now compromised AS?
>
> I can see that the phase two, the cut-and-paste attack portion works,
> but I cannot see how the first portion works. Could you elaborate?
> 2016年1月28日(木) 5:56 Hans Zandbelt <hzandbelt@pingidentity.com
> <mailto:hzandbelt@pingidentity.com>>:
>
>     a perfectly valid - at first - AS may get compromised later and used to
>     attack other ASes; that attacj does not require code changes or control
>     over the authorization endpoint: a rogue employee that happens to have
>     access to log files (granted those include GET & POST data) on the AS
>     can mount the attack if only he can phish the user
>
>     we can't expect that Clients are able to judge whether an AS will become
>     compromised in the future; in fact that pushes the problems to the
>     really good AS who now needs to decide if it accepts Clients that are
>     able to make that judgement call about other ASes that it connects to
>
>     Hans.
>
>     On 1/27/16 8:48 PM, Justin Richer wrote:
>      > I propose we rename this the “Random ASs Attack”.
>      >
>      >   — Justin (only half joking)
>      >
>      >> On Jan 27, 2016, at 8:07 AM, Nat Sakimura <sakimura@gmail.com
>     <mailto:sakimura@gmail.com>
>      >> <mailto:sakimura@gmail.com <mailto:sakimura@gmail.com>>> wrote:
>      >>
>      >> Yup.
>      >>
>      >> For the RPs that would deal with valuable data, I also recommend
>     it to
>      >> become HTTPS only. This will effectively close the hole for the AS
>      >> Mix-Up.
>      >> Also, I would recommend to the clients to think twice before
>     accepting
>      >> random ASs.
>      >> To prevent the code phishing, it is a good idea to require the same
>      >> authority restriction. Otherwise, use some variant of discovery
>     to get
>      >> the authoritative token endpoints.
>      >>
>      >>
>      >> 2016年1月27日(水) 21:49 George Fletcher <gffletch@aol.com
>     <mailto:gffletch@aol.com>
>      >> <mailto:gffletch@aol.com <mailto:gffletch@aol.com>>>:
>      >>
>      >>     Based on Hans' response to Nat I understand why this doesn't
>     solve
>      >>     all the use cases. It does still seem like a good idea from a
>      >>     client perspective that would address the dynamic client
>      >>     registration cases where the Bad AS is returning mixed
>     endpoints.
>      >>
>      >>
>      >>     On 1/27/16 7:43 AM, George Fletcher wrote:
>      >>>     Following up on Nat's last paragraph... did the group in
>      >>>     Darmstadt discuss this option? Namely, to require that the
>      >>>     authority section of the AuthZ and Token endpoints be the same?
>      >>>     Are there known implementations already deployed where the
>      >>>     authority sections are different? It seems like a simple check
>      >>>     that would address the endpoint mix-up cases.
>      >>>
>      >>>     Thanks,
>      >>>     George
>      >>>
>      >>>     On 1/26/16 8:58 PM, Nat Sakimura wrote:
>      >>>>     John,
>      >>>>
>      >>>>     Nov is not talking about the redirection endpoint. I just
>      >>>>     noticed that 3.1.2.1 of RFC 6749 is just asking TLS by
>     "SHOULD"
>      >>>>     and I think it needs to be changed to "MUST" but that is not
>      >>>>     what he is talking about.
>      >>>>
>      >>>>     Instead, he is talking about before starting the RFC 6749
>     flow.
>      >>>>
>      >>>>     In many cases, a non TLS protected sites have "Login with
>     HIdP"
>      >>>>     button linked to a URI that initiates the RFC 6749 flow. This
>      >>>>     portion is not within  RFC 6749 and this endpoint has no
>     name or
>      >>>>     no requirement to be TLS protected. Right, it is very stupid,
>      >>>>     but there are many sites like that.
>      >>>>     As a result, the attacker can insert itself as a proxy, say by
>      >>>>     providing a free wifi hotspot, and either re-write the
>     button or
>      >>>>     the request so that the RP receives "Login with AIdP"
>     instead of
>      >>>>     "Login with HIdP".
>      >>>>
>      >>>>     I have add a note explaining this to
>      >>>>
>       <http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/
>      >>>>
>      >>>>     I also have added a bit of risk analysis on it and considered
>      >>>>     other risk control measures as well.
>      >>>>
>      >>>>     It does not seem to be worthwhile to introduce a new
>      >>>>     wire-protocol element to deal with this particular attack. (I
>      >>>>     regard code cut-and-paste attack a separate attack.) I am
>      >>>>     inclining to think that just to TLS protect the
>     pre-RFC6749 flow
>      >>>>     portion and add a check to disallow the ASs that has different
>      >>>>     authority section for the Auhtz EP and Token EP would be
>     adequate.
>      >>>>
>      >>>>     Nat
>      >>>>
>      >>>>     2016年1月27日(水) 2:18 John Bradley
>      >>>>     <<mailto:ve7jtb@ve7jtb.com
>     <mailto:ve7jtb@ve7jtb.com>>ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>
>      >>>>     <mailto:ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>>:
>      >>>>
>      >>>>         Nov,
>      >>>>
>      >>>>         Are you referring to Sec 3.1.2.1 of RFC 6749.
>      >>>>
>      >>>>         Stating that the the redirection endpoint SHOULD require
>      >>>>         TLS, and that the AS should warn the user if the redirect
>      >>>>         URI is not over TLS (Something I have never seen done
>     in the
>      >>>>         real world)
>      >>>>
>      >>>>         Not using TLS is reasonable when the redirect URI is
>     using a
>      >>>>         custom scheme for native apps.
>      >>>>
>      >>>>         It might almost be reasonable for the token flow where the
>      >>>>         JS page itself is not loaded over TLS so the callback to
>      >>>>         extract the fragment would not be as well.
>      >>>>         Note that the token itself is never passed over a non
>     https
>      >>>>         connection in tis case.
>      >>>>         I would argue now that it is irresponsible to have a
>     non TLS
>      >>>>         protected site, but not everyone is going to go along with
>      >>>>         that.
>      >>>>
>      >>>>         Using a http scheme URI for the redirect is allowed but is
>      >>>>         really stupid.   We did have a large debate about this
>     when
>      >>>>         profiling OAuth for Connect.
>      >>>>         We did tighten connect to say that if you are using
>     the code
>      >>>>         flow then a http scheme redirect URI is only allowed
>     if the
>      >>>>         client is confidential.
>      >>>>
>      >>>>         John B.
>      >>>>>         On Jan 26, 2016, at 1:14 AM, Phil Hunt (IDM)
>      >>>>>         <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>     <mailto:phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>> wrote:
>      >>>>>
>      >>>>>         Still don't see it. Though i think the diagram is wrong
>      >>>>>         (the rp should redirct to the ua and not call the authz
>      >>>>>         direct), the IDP should either return an error or
>     redirect
>      >>>>>         the RP to TLS.
>      >>>>>
>      >>>>>         I don't see this as proper oauth protocol since the RP is
>      >>>>>         MITM the UA rather than acting as a client.
>      >>>>>
>      >>>>>         Phil
>      >>>>>
>      >>>>>         On Jan 25, 2016, at 19:57, nov matake
>      >>>>>         <<mailto:matake@gmail.com
>     <mailto:matake@gmail.com>>matake@gmail.com <mailto:matake@gmail.com>
>      >>>>>         <mailto:matake@gmail.com <mailto:matake@gmail.com>>>
>     wrote:
>      >>>>>
>      >>>>>>         In this flow, AuthZ endpoint is forced to be
>     TLS-protected.
>      >>>>>>
>     http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png
>      >>>>>>
>      >>>>>>         However, RP’s redirect response which causes following
>      >>>>>>         AuthZ request is still not TLS-protected, and
>     modified on
>      >>>>>>         the attacker’s proxy.
>      >>>>>>
>      >>>>>>         Section 3.2 of this report also describes the same flow.
>      >>>>>> http://arxiv.org/pdf/1601.01229v2.pdf
>      >>>>>>
>      >>>>>>>         On Jan 26, 2016, at 12:37, Phil Hunt (IDM)
>      >>>>>>>         <<mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>
>      >>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>> wrote:
>      >>>>>>>
>      >>>>>>>         Also the authz endpoint is required to force tls. So if
>      >>>>>>>         the client doesn't do it the authz should reject (eg by
>      >>>>>>>         upgrading to tls).
>      >>>>>>>
>      >>>>>>>         Phil
>      >>>>>>>
>      >>>>>>>         On Jan 25, 2016, at 19:29, Phil Hunt (IDM)
>      >>>>>>>         <<mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>
>      >>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>> wrote:
>      >>>>>>>
>      >>>>>>>>         When the RP acting as the client issues a authorize
>      >>>>>>>>         redirect to the UA it has to make it with TLS
>      >>>>>>>>
>      >>>>>>>>         Phil
>      >>>>>>>>
>      >>>>>>>>         On Jan 25, 2016, at 17:53, Nov Matake
>      >>>>>>>>         <<mailto:matake@gmail.com
>     <mailto:matake@gmail.com>>matake@gmail.com <mailto:matake@gmail.com>
>      >>>>>>>>         <mailto:matake@gmail.com
>     <mailto:matake@gmail.com>>> wrote:
>      >>>>>>>>
>      >>>>>>>>>         It doen't say anything about the first request which
>      >>>>>>>>>         initiate the login flow.
>      >>>>>>>>>         It is still a reasonable assumption that RP puts a
>      >>>>>>>>>         "login with FB" button on a non TLS-protected page.
>      >>>>>>>>>
>      >>>>>>>>>         nov
>      >>>>>>>>>
>      >>>>>>>>>         On Jan 26, 2016, at 10:45, Phil Hunt
>      >>>>>>>>>         <<mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>
>      >>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>> wrote:
>      >>>>>>>>>
>      >>>>>>>>>>         I would find it hard to believe that is true.
>      >>>>>>>>>>
>      >>>>>>>>>>         From 6749 Sec 3.1
>      >>>>>>>>>>             Since requests to the authorization endpoint
>     result in user
>      >>>>>>>>>>             authentication and the transmission of
>     clear-text credentials (in the
>      >>>>>>>>>>             HTTP response), the authorization server
>     MUST require the use of TLS
>      >>>>>>>>>>             as described inSection 1.6
>      >>>>>>>>>>
>       <https://tools.ietf.org/html/rfc6749#section-1.6>  when sending
>     requests to the
>      >>>>>>>>>>             authorization endpoint.
>      >>>>>>>>>>
>      >>>>>>>>>>         Sec 3.1.2.1
>      >>>>>>>>>>             The redirection endpoint SHOULD require the
>     use of TLS as described
>      >>>>>>>>>>             inSection 1.6
>      >>>>>>>>>>
>       <https://tools.ietf.org/html/rfc6749#section-1.6>  when the
>     requested response type is "code" or "token",
>      >>>>>>>>>>             or when the redirection request will result
>     in the transmission of
>      >>>>>>>>>>             sensitive credentials over an open network.
>     This specification does
>      >>>>>>>>>>             not mandate the use of TLS because at the
>     time of this writing,
>      >>>>>>>>>>             requiring clients to deploy TLS is a
>     significant hurdle for many
>      >>>>>>>>>>             client developers.  If TLS is not available,
>     the authorization server
>      >>>>>>>>>>             SHOULD warn the resource owner about the
>     insecure endpoint prior to
>      >>>>>>>>>>             redirection (e.g., display a message during
>     the authorization
>      >>>>>>>>>>             request).
>      >>>>>>>>>>
>      >>>>>>>>>>             Lack of transport-layer security can have a
>     severe impact on the
>      >>>>>>>>>>             security of the client and the protected
>     resources it is authorized
>      >>>>>>>>>>             to access.  The use of transport-layer
>     security is particularly
>      >>>>>>>>>>             critical when the authorization process is
>     used as a form of
>      >>>>>>>>>>             delegated end-user authentication by the
>     client (e.g., third-party
>      >>>>>>>>>>             sign-in service).
>      >>>>>>>>>>
>      >>>>>>>>>>         Section 10.5 talks about transmission of
>     authorization
>      >>>>>>>>>>         codes in connection with redirects.
>      >>>>>>>>>>
>      >>>>>>>>>>         Also see 6819, Sec 4.4.1.1 regarding
>     eavesdropping or
>      >>>>>>>>>>         leaking of authz codes.
>      >>>>>>>>>>
>      >>>>>>>>>>
>      >>>>>>>>>>         Phil
>      >>>>>>>>>>
>      >>>>>>>>>>         @independentid
>      >>>>>>>>>>
>       <http://www.independentid.com/>www.independentid.com
>     <http://www.independentid.com>
>      >>>>>>>>>>         <http://www.independentid.com/>
>      >>>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>
>      >>>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>
>      >>>>>>>>>>
>      >>>>>>>>>>
>      >>>>>>>>>>
>      >>>>>>>>>>
>      >>>>>>>>>>
>      >>>>>>>>>>>         On Jan 25, 2016, at 4:52 PM, nov matake
>      >>>>>>>>>>>         <<mailto:matake@gmail.com
>     <mailto:matake@gmail.com>>matake@gmail.com <mailto:matake@gmail.com>
>      >>>>>>>>>>>         <mailto:matake@gmail.com
>     <mailto:matake@gmail.com>>> wrote:
>      >>>>>>>>>>>
>      >>>>>>>>>>>         The first assumption is coming from the original
>      >>>>>>>>>>>         security report at
>      >>>>>>>>>>>
>       <http://arxiv.org/abs/1601.01229>http://arxiv.org/abs/1601.01229.
>      >>>>>>>>>>>
>      >>>>>>>>>>>         RFC 6749 requires TLS between RS and AS, and also
>      >>>>>>>>>>>         between UA and AS, but not between UA and RS.
>      >>>>>>>>>>>
>      >>>>>>>>>>>         The blog post is based on my Japanese post, and it
>      >>>>>>>>>>>         describes multi-AS case.
>      >>>>>>>>>>>         Nat's another post describes the case which can
>      >>>>>>>>>>>         affect single-AS case too.
>      >>>>>>>>>>>
>       <http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/>http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
>      >>>>>>>>>>>
>      >>>>>>>>>>>         nov
>      >>>>>>>>>>>
>      >>>>>>>>>>>>         On Jan 26, 2016, at 08:22, Phil Hunt
>      >>>>>>>>>>>>         <<mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>
>      >>>>>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>> wrote:
>      >>>>>>>>>>>>
>      >>>>>>>>>>>>         Sorry, meant to reply-all.
>      >>>>>>>>>>>>
>      >>>>>>>>>>>>         Phil
>      >>>>>>>>>>>>
>      >>>>>>>>>>>>         @independentid
>      >>>>>>>>>>>>
>       <http://www.independentid.com/>www.independentid.com
>     <http://www.independentid.com>
>      >>>>>>>>>>>>         <http://www.independentid.com/>
>      >>>>>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>
>      >>>>>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>
>      >>>>>>>>>>>>
>      >>>>>>>>>>>>
>      >>>>>>>>>>>>
>      >>>>>>>>>>>>
>      >>>>>>>>>>>>
>      >>>>>>>>>>>>>         Begin forwarded message:
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>         *From: *Phil Hunt <phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>
>      >>>>>>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>>
>      >>>>>>>>>>>>>         *Subject: **Re: [OAUTH-WG] Call for Adoption:
>     OAuth
>      >>>>>>>>>>>>>         2.0 Mix-Up Mitigation*
>      >>>>>>>>>>>>>         *Date: *January 25, 2016 at 3:20:19 PM PST
>      >>>>>>>>>>>>>         *To: *Nat Sakimura <sakimura@gmail.com
>     <mailto:sakimura@gmail.com>
>      >>>>>>>>>>>>>         <mailto:sakimura@gmail.com
>     <mailto:sakimura@gmail.com>>>
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>         I am having trouble with the very first
>     assumption.
>      >>>>>>>>>>>>>         The user-agent sets up a non TLS protected
>      >>>>>>>>>>>>>         connection to the RP? That’s a fundamental
>      >>>>>>>>>>>>>         violation of 6749.
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>         Also, the second statement says the RP
>     (assuming it
>      >>>>>>>>>>>>>         acts as OAuth client) is talking to two IDPs.
>      >>>>>>>>>>>>>         That’s still a multi-AS case is it not?
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>         Phil
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>         @independentid
>      >>>>>>>>>>>>>
>       <http://www.independentid.com/>www.independentid.com
>     <http://www.independentid.com> <http://www.independentid.com/>
>      >>>>>>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>
>      >>>>>>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>>>         On Jan 25, 2016, at 2:58 PM, Nat Sakimura
>      >>>>>>>>>>>>>>         <<mailto:sakimura@gmail.com
>     <mailto:sakimura@gmail.com>>sakimura@gmail.com
>     <mailto:sakimura@gmail.com>
>      >>>>>>>>>>>>>>         <mailto:sakimura@gmail.com
>     <mailto:sakimura@gmail.com>>> wrote:
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>         Hi Phil,
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>         Since I was not in Darmstadt, I really do
>     not know
>      >>>>>>>>>>>>>>         what was discussed there, but with the
>     compromised
>      >>>>>>>>>>>>>>         developer documentation described in
>      >>>>>>>>>>>>>>
>       <http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/,
>      >>>>>>>>>>>>>>         all RFC6749 clients with a naive implementer
>     will
>      >>>>>>>>>>>>>>         be affected. The client does not need to be
>      >>>>>>>>>>>>>>         talking to multiple IdPs.
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>         Nat
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>         2016 年1月26日(火) 3:58 Phil Hunt (IDM)
>      >>>>>>>>>>>>>>         <<mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>
>      >>>>>>>>>>>>>>         <mailto:phil.hunt@oracle.com
>     <mailto:phil.hunt@oracle.com>>>:
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>             I recall making this point in Germany.
>     99% of
>      >>>>>>>>>>>>>>             existing use is fine. OIDC is probably the
>      >>>>>>>>>>>>>>             largest community that *might* have an
>     issue.
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>             I recall proposing a new security document
>      >>>>>>>>>>>>>>             that covers oauth security for dynamic
>      >>>>>>>>>>>>>>             scenarios. "Dynamic" being broadly
>     defined to
>      >>>>>>>>>>>>>>             mean:
>      >>>>>>>>>>>>>>             * clients who have configured at runtime or
>      >>>>>>>>>>>>>>             install time (including clients that do
>     discovery)
>      >>>>>>>>>>>>>>             * clients that communicate with more
>     than one
>      >>>>>>>>>>>>>>             endpoint
>      >>>>>>>>>>>>>>             * clients that are deployed in large volume
>      >>>>>>>>>>>>>>             and may update frequently (more
>     discussion of
>      >>>>>>>>>>>>>>             "public" cases)
>      >>>>>>>>>>>>>>             * clients that are script based (loaded into
>      >>>>>>>>>>>>>>             browser on the fly)
>      >>>>>>>>>>>>>>             * others?
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>             Phil
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>             > On Jan 25, 2016, at 10:39, George Fletcher
>      >>>>>>>>>>>>>>             <<mailto:gffletch@aol.com
>     <mailto:gffletch@aol.com>>gffletch@aol.com <mailto:gffletch@aol.com>
>      >>>>>>>>>>>>>>             <mailto:gffletch@aol.com
>     <mailto:gffletch@aol.com>>> wrote:
>      >>>>>>>>>>>>>>             >
>      >>>>>>>>>>>>>>             > would
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>
>       _______________________________________________
>      >>>>>>>>>>>>>>             OAuth mailing list
>      >>>>>>>>>>>>>>             <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>OAuth@ietf.org <mailto:OAuth@ietf.org>
>      >>>>>>>>>>>>>>             <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>
>      >>>>>>>>>>>>>>
>       <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>
>      >>>>>>>>>>>>
>      >>>>>>>>>>>>         _______________________________________________
>      >>>>>>>>>>>>         OAuth mailing list
>      >>>>>>>>>>>>         <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>OAuth@ietf.org <mailto:OAuth@ietf.org>
>      >>>>>>>>>>>>         <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
>      >>>>>>>>>>>>
>       <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
>      >>>>>>>>>>>
>      >>>>>>>>>>
>      >>>>>>>>         _______________________________________________
>      >>>>>>>>         OAuth mailing list
>      >>>>>>>>         <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>OAuth@ietf.org <mailto:OAuth@ietf.org>
>      >>>>>>>>         <mailto: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> <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>
>      >>>>> https://www.ietf.org/mailman/listinfo/oauth
>      >>>>
>      >>>>         _______________________________________________
>      >>>>         OAuth mailing list
>      >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>
>      >>>> https://www.ietf.org/mailman/listinfo/oauth
>      >>>>
>      >>>>
>      >>>>
>      >>>>     _______________________________________________
>      >>>>     OAuth mailing list
>      >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>
>      >>>> https://www.ietf.org/mailman/listinfo/oauth
>      >>>
>      >>>     --
>      >>>     Chief Architect
>      >>>     Identity Services Engineering
>     Work:george.fletcher@teamaol.com
>     <mailto:Work%3Ageorge.fletcher@teamaol.com>
>     <mailto:george.fletcher@teamaol.com
>     <mailto:george.fletcher@teamaol.com>>
>      >>>     AOL Inc.                          AIM:  gffletch
>      >>>     Mobile: +1-703-462-3494
>       Twitter:http://twitter.com/gffletch
>      >>>     Office: +1-703-265-2544
>       Photos:http://georgefletcher.photography
>      >>>     <http://georgefletcher.photography/>
>      >>>
>      >>>
>      >>>     _______________________________________________
>      >>>     OAuth mailing list
>      >>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>
>      >>> https://www.ietf.org/mailman/listinfo/oauth
>      >>
>      >>     --
>      >>     Chief Architect
>      >>     Identity Services Engineering
>     Work:george.fletcher@teamaol.com
>     <mailto:Work%3Ageorge.fletcher@teamaol.com>
>     <mailto:george.fletcher@teamaol.com
>     <mailto:george.fletcher@teamaol.com>>
>      >>     AOL Inc.                          AIM:  gffletch
>      >>     Mobile: +1-703-462-3494
>       Twitter:http://twitter.com/gffletch
>      >>     Office: +1-703-265-2544
>       Photos:http://georgefletcher.photography
>     <http://georgefletcher.photography/>
>      >>
>      >> _______________________________________________
>      >> OAuth mailing list
>      >> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>
>      >> https://www.ietf.org/mailman/listinfo/oauth
>      >
>      >
>      >
>      > _______________________________________________
>      > OAuth mailing list
>      > OAuth@ietf.org <mailto:OAuth@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/oauth
>      >
>
>     --
>     Hans Zandbelt              | Sr. Technical Architect
>     hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com> |
>     Ping Identity
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity