Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Bill Mills <wmills_92105@yahoo.com> Tue, 02 December 2014 19:25 UTC

Return-Path: <wmills_92105@yahoo.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 A439F1A6FCD for <oauth@ietfa.amsl.com>; Tue, 2 Dec 2014 11:25:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.39
X-Spam-Level:
X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 m-uBvx0fIRKC for <oauth@ietfa.amsl.com>; Tue, 2 Dec 2014 11:25:04 -0800 (PST)
Received: from nm42-vm5.bullet.mail.bf1.yahoo.com (nm42-vm5.bullet.mail.bf1.yahoo.com [216.109.114.204]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5367E1A6EDA for <oauth@ietf.org>; Tue, 2 Dec 2014 11:25:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417548303; bh=G1zUUIXUcuI9E/gsBTKelc4KAmYaFtsom+gFRoOhieM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=lgul0131xpKjjppsughTO05+0tYF570lfmtLIDBJRPLxPAg2HkYERGAaQuTMCOjxalmPiQSobJH37BW842xhageKh+IszUWFUNwhsIlR+6ozqsjK5YyJ0nzIBuzEQi8VHVJoBmvmfEaIVduEypuEyRqIEoAlEl6gDHWbDqQXThei1wQZwW3VpJuzjNvRrQPB8QJW5wjXuXncxEIbsKmgPTplPQhynJ6iBaH16pr/rDsa1dNjbKbyAtf4HR0uhUXbvVb3Xq1oytfgDktu4ow5r0Cfu7oWDgTOzzKAp4C5/rh2wii7JTuxLBhl4HSKuVRmqFyhI744hdV8gt/03Qy75A==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=hIidOl8lovwbKt7VZUbpfaIE6aDGMfBlM8YCp2D9Bp+M8ZvvHBwDwPNBYrLAl+Ifz9t78MY5OUtiM0GXGi5hMu5ivPTu+ZXur1nbYy2tr1XVZ/0u07kZ/rQyuFVQJOdGpYZTRIJd0h/8C2RZO6UbKwt6kYiom4b9AgbbtO/IZlFtCn1rFJd17j1Pbi+/rRTbgdIShyx6LNm9EpmOzaKuWrVDqZUVwsLbD1Ancl9Twjwv9qmabAX6xcbo6MLuUsQyIFqi+T6iJ1pAPMu4CKXUVCiiEmswOKgWpJUI6R2IVU4S6V3BKHBPdXO6zns+pMAQ4Ha60MppekrbOr4seSa2zQ==;
Received: from [98.139.212.149] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 19:25:03 -0000
Received: from [98.139.212.220] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 19:25:03 -0000
Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 19:25:03 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 469752.26755.bm@omp1029.mail.bf1.yahoo.com
X-YMail-OSG: qYU82DIVM1lIaunxtgB0HRZnNXPS5WO2MxGEjLEoT0wjp03jdGiHxmaJlKLCcCd H1dEg5ybw91Dzo99hbG3zAT4E4Qd0FoAkFh.FONeeEBz0KeKBweSvWU9KDszHCaEeVIKJniiPhjy nDqLV2OQW2LLzFMO8LQjZ9n6zy_dQOPbpLvp4bn2PLlFxFFdeACAafA7JETYFJqHyUuZRz07ASd1 Ve3spJWth0Ss6YbGvWwRziveCT7W9b4gKUiPMrBh.yN4cthTezxTKExxPKFdNmERJoo7Sh5wn2MS LRR9PzYri684JKaDBtDSbgytJKv_HhCE4LLZMmJ5K1_O6c0MR5QYfRRUGiIErFviKs9HJDS_XOBq EFf3S5E423rohx1W5dyEB.pFUy1jYQM5Iz8uoI6yf9g0qAel4Iv8kf.gUD7T.cPoom0.tFbQS13t IX7ILk3xHOn4CgIcDI3djXzDObWcea9LB0uEMR35w58bvAen52UEjj.B3tNSWUO9EoIZgJDKJoeI-
Received: by 66.196.81.114; Tue, 02 Dec 2014 19:25:03 +0000
Date: Tue, 02 Dec 2014 19:25:02 +0000
From: Bill Mills <wmills_92105@yahoo.com>
To: "Richer, Justin P." <jricher@mitre.org>
Message-ID: <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com>
In-Reply-To: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org>
References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3962315_695460837.1417548302661"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fF8CGrHBNFJODvD3fPn54vvRLe0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <wmills_92105@yahoo.com>
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: <http://www.ietf.org/mail-archive/web/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: Tue, 02 Dec 2014 19:25:05 -0000

If introspection returns any other user data beyond what is strictly required to validate the token based solely on possession of the public part it would be a mistake. 

     On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:
   

 That's all fine -- it's all going over TLS anyway (RS->AS) just like the original token fetch by the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP token. 
Can you explain how this is related to "act on behalf of"? I don't see any connection.
 -- Justin
On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what if the introspection endpoint returns the symmetric key?  Data about the user?  Where does this blur the line between this and "act on behalf of"?

On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


The call to introspection has a TLS requirement, but the call to the RS wouldn't necessarily have that requirement. The signature and the token identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.
 -- Justin
On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear how PoP tokens would work. ..."
I don't know if that's true.  POP tokens (as yet to be fully defined) would then also have a TLS or transport security requirement unless there is token introspection client auth in play I think.  Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.
-bill