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 64C191A1BFB for ; Tue, 2 Dec 2014 14:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, URI_NOVOWEL=0.5] 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 Jzr1mTagx_mC for ; Tue, 2 Dec 2014 14:26:59 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5671A1B21 for ; Tue, 2 Dec 2014 14:26:59 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E951552E0AA; Tue, 2 Dec 2014 17:26:58 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id DC94852E010; Tue, 2 Dec 2014 17:26:58 -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 17:26:58 -0500 From: "Richer, Justin P." To: John Bradley Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgABMtwCAAAciAIAAAPSAgAABWoCAAAMSAIAACQgAgAAE5gCAAB4oAIAAAxKAgAAD6YA= Date: Tue, 2 Dec 2014 22:26:57 +0000 Message-ID: References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> In-Reply-To: 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_C62B72064F9F4FB2A7AE6C2EB55C09D1mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ivzAoNOmjJyaGGufIDhRjcFgPZU 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 22:27:05 -0000 --_000_C62B72064F9F4FB2A7AE6C2EB55C09D1mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree that there's some use in this (and in fact I've deployed a version = that uses a signed JWT to indicate its authorization server), but it should= remain outside the scope of this spec. It's a service discovery problem, i= t's orthogonal. -- Justin On Dec 2, 2014, at 5:13 PM, John Bradley > wrote: Yes, but unless there is something new the introspection endpoint in UMA i= s tied to the resource. In some cases having the token indicate the introspection endpoint may be u= seful. John B. Sent from my iPhone On Dec 2, 2014, at 10:02 PM, Eve Maler > wrote: FWIW, UMA goes ahead and standardizes a good deal about the trust establish= ment between the RS and the AS, and (of course) profiles and wraps the toke= n introspection spec as part of the resulting =93authorization API=94 that = the AS presents to the RS. A big part of the motivation for this is to supp= ort an n:n relationship between AS and RS entities. EVe On 2 Dec 2014, at 12:14 PM, John Bradley > wrote: Many of the proprietary introspection protocols in use return scope, role o= r other meta data for the RS to make its access policy decision on. One of the reasons for using opaque tokens rather than JWT is to prevent le= akage of that info. Making authentication to the introspection endpoint a MUST if additional at= tributes are present is OK, I might even be inclined to say that authentic= ation of some sort is always required, but that might be going a bit far fo= r some use cases. We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. = It would be nice if we could standardize it. Precluding other attributes = would not be helpful for adoption. One issue that we haven=92t addressed in this spec is what happens if there= are multiple AS for the RS and how it would decide what introspection endp= oint to use. Perhaps that needs to be a extension, leaving this for the simple case. However having more than on e AS per RS is not as unusual as it once was in= larger environments. John B. On Dec 2, 2014, at 4:56 PM, Richer, Justin P. > wrote: 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --_000_C62B72064F9F4FB2A7AE6C2EB55C09D1mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I agree that there's some use in this (and in fact I've deployed a version = that uses a signed JWT to indicate its authorization server), but it should= remain outside the scope of this spec. It's a service discovery problem, i= t's orthogonal. 

 -- Justin


On Dec 2, 2014, at 5:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes,  but unless there is something new the introspection endpoin= t in UMA is tied to the resource.   

In some cases having the token indicate the introspection endpoint may= be useful. 

John B. 

Sent from my iPhone

On Dec 2, 2014, at 10:02 PM, Eve Maler <eve@xmlgrrl.com> wrote:

FWIW, UMA goes ahead and standardizes a good deal about the= trust establishment between the RS and the AS, and (of course) profiles an= d wraps the token introspection spec as part of the resulting =93authorizat= ion API=94 that the AS presents to the RS. A big part of the motivation for this is to support an n:n relationshi= p between AS and RS entities.

EVe

On 2 Dec 2014, at 12:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Many of the proprietary introspection protocols in use return scope, role o= r other meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rather than JWT = is to prevent leakage of that info.

Making authentication to the introspection endpoint a MUST = if additional attributes are present is OK,  I might even be inclined = to say that authentication of some sort is always required, but that might = be going a bit far for some use cases.

We have a lot of proprietary ways to do this from IBM, Laye= r 7, Ping etc.  It would be nice if we could standardize it.   Pr= ecluding other attributes would not be helpful for adoption.


One issue that we haven=92t addressed in this spec is what = happens if there are multiple AS for the RS and how it would decide what in= trospection endpoint to use.
Perhaps that needs to be a extension, leaving this for the = simple case.

However having more than on e AS per RS is not as unusual a= s it once was in larger environments.

John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <jricher@mitre.org> wrote:
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:<= /div>
If introspection return= s any other user data beyond what is strictly required to validate the toke= n based solely on possession of the public part it would be a mistake.


On T= uesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:<= br class=3D"">


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 Po= P 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.co= m> wrote:

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


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


The c= all 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 signatur= e that's associated with it and the request. What I'm saying is that you in= trospect the identifier and get back something that lets you, the RS, check= the signature.

 = ;-- Justin

On De= c 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"How= ever, 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 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








_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth


Eve Maler                   &n= bsp;              http://www.xmlgrrl.com/blog
+1 425 345 6756                =         http://www.twitter.com/xmlgrrl


--_000_C62B72064F9F4FB2A7AE6C2EB55C09D1mitreorg_--