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 612BB1A6FC9 for ; Tue, 2 Dec 2014 11:13:25 -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 IMESlY_zxUsn for ; Tue, 2 Dec 2014 11:13:19 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 638081A6FB7 for ; Tue, 2 Dec 2014 11:13:18 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1970572E1B2; Tue, 2 Dec 2014 14:13:18 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 0BDF172E1BB; Tue, 2 Dec 2014 14:13:18 -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:13:17 -0500 From: "Richer, Justin P." To: Bill Mills Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgABMtwCAAAciAIAAAPSAgAABWoA= Date: Tue, 2 Dec 2014 19:13:16 +0000 Message-ID: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> References: <131139F2-0F73-4315-B52A-9F609B55EF4C@mitre.org> <244078391.3267266.1417547353925.JavaMail.yahoo@jws10601.mail.bf1.yahoo.com> In-Reply-To: <244078391.3267266.1417547353925.JavaMail.yahoo@jws10601.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_46D29E355A694687BC4445462DEA8D47mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2gR-wlZ333tJz4DYXXXJ5pqJDqA 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:13:25 -0000 --_000_46D29E355A694687BC4445462DEA8D47mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_46D29E355A694687BC4445462DEA8D47mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <29A28B68A0874D468B5E8A849AE1AE65@imc.mitre.org> Content-Transfer-Encoding: quoted-printable 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? &nb= sp;Data about the user?  Where does this blur the line between this and "act on behalf of"?


On Tuesday, Decembe= r 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 r= equirement. 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 wit= h 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, B= ill Mills <wmills_92105@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_46D29E355A694687BC4445462DEA8D47mitreorg_--