Return-Path: 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 7D52C1A1F20 for ; Tue, 2 Dec 2014 11:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 TUvcZYhleZLr for ; Tue, 2 Dec 2014 11:56:38 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 709071A6FE2 for ; Tue, 2 Dec 2014 11:56:37 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8BE5CB2E088; Tue, 2 Dec 2014 14:56:36 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 7F1ADB2E105; Tue, 2 Dec 2014 14:56:36 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 14:56:35 -0500 From: "Richer, Justin P." To: Bill Mills Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgABMtwCAAAciAIAAAPSAgAABWoCAAAMSAIAACQgA Date: Tue, 2 Dec 2014 19:56:35 +0000 Message-ID: References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> In-Reply-To: <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_EA29FCACB69040D3A6EF345F4483856Emitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/C5qa8xxT60y2KuM1dAWsvTYRbIM Cc: "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 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:56:40 -0000 --_000_EA29FCACB69040D3A6EF345F4483856Emitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed, which is why we've got space for the "sub" and "user_id" fields but= not anything else about the user, and we've got a privacy considerations s= ection for dealing with that. If you can help make the wording on that sect= ion stronger, I'd appreciate it. -- Justin On Dec 2, 2014, at 2:25 PM, Bill Mills > wrote: If introspection returns any other user data beyond what is strictly requir= ed to validate the token based solely on possession of the public part it w= ould be a mistake. On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." > wrote: That's all fine -- it's all going over TLS anyway (RS->AS) just like the or= iginal 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 > wrote: Fetching the public key for a token might be fine, but what if the introspe= ction 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." > wrote: The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it an= d the request. What I'm saying is that you introspect the identifier and ge= t back something that lets you, the RS, check the signature. -- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills > 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 tok= en introspection client auth in play I think. Otherwise I can as an attack= er take that toklen and get info about it that might be useful, and I don't= think that's what we want. -bill --_000_EA29FCACB69040D3A6EF345F4483856Emitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Agreed, which is why we've got space for the "sub" and "user= _id" fields but not anything else about the user, and we've got a priv= acy considerations section for dealing with that. If you can help make the = wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

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


On Tuesday, December 2, 20= 14 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). D= oesn't mean you need TLS *into* the RS (C->RS) with a good PoP token.&nb= sp;

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 retu= rns the symmetric key?  Data about the user?  Where does this blur the line between this and "act on be= half of"?


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


The call to intr= ospection has a TLS requirement, but the call to the RS wouldn't necessaril= y have that requirement. The signature and the token identifier are two dif= ferent 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 sig= nature.

 -- Justin<= /div>

On Dec 2, 2014, = at 1:40 PM, Bill Mills <wmills_921= 05@yahoo.com> wrote:

"However, I think it's ver= y 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 i= s 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








--_000_EA29FCACB69040D3A6EF345F4483856Emitreorg_--