Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"

John Bradley <ve7jtb@ve7jtb.com> Fri, 18 March 2016 23:01 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 18D8112D705 for <oauth@ietfa.amsl.com>; Fri, 18 Mar 2016 16:01:09 -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 tFP3_BV6z6p9 for <oauth@ietfa.amsl.com>; Fri, 18 Mar 2016 16:01:06 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 2A5EC12D7ED for <oauth@ietf.org>; Fri, 18 Mar 2016 16:01:06 -0700 (PDT)
Received: by mail-qg0-x235.google.com with SMTP id w104so112957851qge.1 for <oauth@ietf.org>; Fri, 18 Mar 2016 16:01:06 -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=HsAxOFqTIYjYLB87cc6GI3Ls4DbTtfHoI05x4fVqf9w=; b=f3SRK9apm+v8KZQSlRowO0xFrAnsQRZcIPE1xB0D5RfxBIn4/8mJp0rxOWORfI4Czh yDSTTbqKF/cT02tH99zNtbhHtSTJZGvyg0Am23ZorDR9iSVNx1dUUMkP6955Yr9t8PrB 6MEZ8XGDNrJlKHruO/UOhJ5zlH6s9HPXMOlK5F/eUuDGiimqOTTx6VZmfCNeBPMliScW AXfoiTjK8z+Dq8/leCOE+mrHuUoesVPgOVdNin75dCaSVHgdtxp2JaO0BQ4YpAZ1JUuc Z1jkiVD5QyxmXHloaoz2sZbNJ8Gq7QwA5QpWXnenqj+FvvxpNPQaTZzFtURKvDg87YJ/ V5vQ==
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=HsAxOFqTIYjYLB87cc6GI3Ls4DbTtfHoI05x4fVqf9w=; b=FF2tSxXN87HMF0D29qPYo5u80OOR4GdWYAwFwRl7eIDmnHuIhUhHASOEbZzPKD7qJt nRQfAopw21HyS9XC8u6GzE+vwst20+DiVIhwtwSzJohsOjmoUee21uRaE/McknVLqt4R 45gr8fHVWAqOTDnDjjRkfewvihhk+EZyy4NhNt39XCn6JP5WE790jtGDlM14o/kR/riI e/xgW3Beg2lLhZfG3HrTDvj9l4Ojtq2h82tUcPeidYJpnSgRiJhHKtwmI9utKucR/UWN OA+6pzI7VaMw4PkxdoHtCQVY+wODrJAlnZtTZxUGW5wRbEZEzrCf0mjUYOliAmdMWgxs Aidw==
X-Gm-Message-State: AD7BkJJD8RGivAL2Aauj3MVqNpSFwkzAovWWvSu4Jp/g/NVzsMY9qd0dCWNkdREQgChDlg==
X-Received: by 10.140.98.98 with SMTP id n89mr26614248qge.9.1458342065119; Fri, 18 Mar 2016 16:01:05 -0700 (PDT)
Received: from [192.168.8.101] ([181.202.83.141]) by smtp.gmail.com with ESMTPSA id y129sm7001348qka.33.2016.03.18.16.01.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Mar 2016 16:01:04 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_06FAE696-9E57-48E2-98FF-65CCAD9813DB"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <20024B1B-7EC0-4354-A173-94F9F58AE1A3@oracle.com>
Date: Fri, 18 Mar 2016 20:01:00 -0300
Message-Id: <DA183442-992A-4166-843D-32EFA58D9C11@ve7jtb.com>
References: <56EAEB54.8010208@aol.com> <CA+k3eCQ-C+MuAV__JnPMJqeKWMn=Qe2yGB06qzpet=xx1xGZ0g@mail.gmail.com> <B05D6061-BB5A-4593-B77A-9FF84AFE16F6@oracle.com> <CA+k3eCR+NDPqrnjGEZbKiuN-FZX730ubnUruk3=YyG6amN=6Vg@mail.gmail.com> <20024B1B-7EC0-4354-A173-94F9F58AE1A3@oracle.com>
To: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/a4nSGqRFc0hpjv8ajBbDMQ1_46w>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
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, 18 Mar 2016 23:01:09 -0000

The Mitigation we agreed on for the bad token endpoint is returning the issuer and client_id form the authorization endpoint.

Phil are you saying that you no longer agree with that? 

The question that was unresolved was how the client would get a bad resource URI, and what the correct mitigation is if any.

John B.


> On Mar 18, 2016, at 7:52 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> By convincing the client to use a bad URL.  That’s kinda why we’re worried about bad discovery no?
> 
> Depending on the type of client authentication, the client will establish a valid connection to the hacker’s proxy which then replays the token request to the real endpoint.  The hacker now has the token.
> 
> Same thing for the resource endpoint - except worse. The hacker doesn’t need the token as they now see the payload.
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
> 
> 
> 
> 
> 
>> On Mar 18, 2016, at 3:38 PM, Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
>> 
>> How does one Mitm the token endpoint?
>> 
>> On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>> There are two variations. 
>> 
>> Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection. 
>> 
>> In the mitm version you don't need multiple AS's.
>> 
>> Phil
>> 
>> On Mar 18, 2016, at 15:04, Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
>> 
>>> The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
>>> 
>>> Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
>>> 
>>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher <gffletch@aol.com <mailto:gffletch@aol.com>> wrote:
>>> Goals:
>>> 
>>> 1. Help the client not send a token to the "wrong" endpoint
>>>    a. wrong AS /token endpoint
>>>    b. evil RS endpoint(s)
>>> 2. Allow good RS to determine if the token being validated was intended for that RS
>>> 
>>> Other high-level goals?
>>> 
>>> Use cases:
>>> 
>>> 1. RS that supports multiple AS (we've had this in production since 2011)
>>> 2. RS rejects token not issued for use at the RS
>>> 3. Client that dynamically supports new RS (say any client that supports the jabber API)
>>> 4. Client that dynamically supports new AS
>>> 
>>> Feel free to add to the list :)
>>> 
>>> _______________________________________________
>>> 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 <https://www.ietf.org/mailman/listinfo/oauth>
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth