Return-Path: 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 18DA821F88A1 for ; Sun, 3 Feb 2013 13:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYMQW1MKIPee for ; Sun, 3 Feb 2013 13:59:43 -0800 (PST) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 83F5121F889D for ; Sun, 3 Feb 2013 13:59:41 -0800 (PST) Received: (qmail 28736 invoked by uid 0); 3 Feb 2013 21:59:17 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy12.bluehost.com with SMTP; 3 Feb 2013 21:59:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=0vQAepDVMtG26XTKF85kQKGveB6KO24cVrGwp/fyIU0=; b=nZzXILmTCNlsof7sPvITeL5cdZxzM9Q4rPKkUM9PcgaOaijItY39flYCzBzc0JcesOoHmiIV1tAQc3N/GI7qBY9yXLFs1SubrmiwDVX59lp3EhtxdQvnzZYbKJDQwYuz; Received: from [68.4.207.246] (port=2098 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U27an-0007OF-2A; Sun, 03 Feb 2013 14:59:17 -0700 From: "Donald F Coffin" To: "'Torsten Lodderstedt'" References: <006401cdfe5f$2555f170$7001d450$@reminetworks.com> <51085B43.3080103@aol.com> <00c901cdfe80$e7d0eb30$b772c190$@reminetworks.com> <9DFD603A-1170-41D8-A22F-8654D55546B3@lodderstedt.net> <00a301ce0205$b6b1ca00$24155e00$@reminetworks.com> <510E560A.4090107@lodderstedt.net> <003e01ce024f$6894feb0$39befc10$@reminetworks.com> <446E24A6-1E3A-4596-AAEA-8B6F1AD7D1A0@lodderstedt.net> In-Reply-To: <446E24A6-1E3A-4596-AAEA-8B6F1AD7D1A0@lodderstedt.net> Date: Sun, 3 Feb 2013 13:59:06 -0800 Message-ID: <006601ce0259$b05db840$111928c0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01CE0216.A2406BB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGqJs1aP2O8OPoDFE4j2TX8/D0+WgJbNiMKAkqArjkBxPa5mwH8o5RMAdFqZ0cBjwcubAIIPbhsmEHfmFA= Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Cc: 'John Adkins' , 'Marty Burns' , 'Scott Crowder' , 'Dave Robin' , 'John Teeter' , pmadsen@pingidentity.com, 'Edward Denson' , oauth@ietf.org, 'Ray Perlner' , 'Anne Hendry' , 'Lynne Rodoni' , 'Uday Verma' Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 21:59:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0067_01CE0216.A2406BB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, =20 The Third Party will utilize an access_token they obtain utilizing the = client_credentials to obtain data from the RS for all Retail Customers = who have granted them access to their data. Therefore, the Third Party = will also have an access_token they obtain utilizing the = authentication_code response_type (i.e. grant_type of code for the = access_token) for each of the Retail Customers who have authorized them = access to their data. =20 Although an access_token will exist for the Third Party, Retail = Customer, and RS relationship its usage will be infrequent compared to = the access_token the Third Party obtains using the client_credentials = grant_type. This is another reason why I believe in the ESPI Standard = implementation it will be necessary to revoke the access_token and = refresh_token simultaneously. The RS should not include in the data = stream (covered by the client_credentials access_token) data that is = based on the authorization_code access_token when the Retail Customer = has indicated (either by alteration of the authorization scope or an = outright revocation) the Third Party no longer is authorized to access = the data. Only revoking the refresh_token possess a privacy. Only = revoking the access_token, as you pointed out, poses a potential = security issue allowing for the possibility of a denial of service = attack. =20 I hope this makes sense and clarifies my situation.. =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 Sent: Sunday, February 03, 2013 1:14 PM To: Donald F Coffin Cc: George Fletcher; John Adkins; Scott Crowder; Dave Robin; John = Teeter; ; Edward Denson; Marty Burns; Uday = Verma; Ray Perlner; Anne Hendry; Lynne Rodoni; Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 =20 Hi Donald, =20 Thanks for the clarification. Let me see whether I got you right. = Although the retail customer has to authorize the access by the 3rd = party application, there is no external representation of this = authorization grant (e.g a refresh token). Instead, the actual access = token is issued based on client credentials. Is there any correlation = between the access token and the particular customer? =20 Please note: we highly appreciate your feedback as an implementer. =20 Best regards, Torsten. Am 03.02.2013 um 21:45 schrieb "Donald F Coffin" = : Hi Torsten, =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 =20 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com =20 From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 Sent: Sunday, February 03, 2013 4:20 AM To: Donald F Coffin Cc: 'George Fletcher'; 'John Adkins'; 'Scott Crowder'; 'Dave Robin'; = 'John Teeter'; pmadsen@pingidentity.com; 'Edward Denson'; 'Marty Burns'; = 'Uday Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni'; = oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 =20 Hi Donald, Am 03.02.2013 12:57, schrieb Donald F Coffin: =20 =20 [Don] A typical Third Party application built to use the ESPI Standard = will interact with a Retail Customer and their energy provider. The = nature of interaction with the Retail Customer will utilize short = interactive sessions. However, the interaction with their energy = provider will require the application obtain new energy information for = the previous 24-hours once a day. Therefore, I anticipate access_tokens = will be granted for long periods of time as well as any supporting = refresh_tokens. Because of the amount of data being exchanged between = the Third Party application and the energy provider, both in number of = retail customers and the amount of energy meter data, it will be = necessary to minimize the amount of =E2=80=9Cadministrative=E2=80=9D = traffic required in the exchange. Therefore, although I understand the = use case you described, I anticipate such an implementation would be = rare. =20 =20 The need to perform an audience style check to prevent exposure of the = AS to a denial of service attack, appears primarily due to the fact the = Revocation RFC requires an access_token and refresh_token to be revoked = independently. Should a client need to revoke both Tokens the sequence = of the revocation request is extremely significant. A simple solution = to this problem would be to provide a method that allows a request to = revoke both tokens simultaneously, as stated in one of the responses you = referenced in the archives. =20 =20 The example you gave in your response demonstrating how a denial of = service attack might occur is incorrect. You said =E2=80=9Cif the AS = revokes the refresh_token when an access_token is revoked, I can steal = an access_token and send it to the revocation endpoint causing the real = client=E2=80=99s refresh_token to be revoked=E2=80=9D. I fail to see = how that could occur, since the AS revoked both the access_token and the = refresh_token when it received the request to revoke the access_token. = Rather than explaining why a refresh_token shouldn=E2=80=99t be revoked = concurrently when an access_token is revoked, your example does the = exact opposite. It shows why a refresh_token should be revoked = concurrently when an access_token is revoked. =20 [Don] The focus of the ESPI Standard is to provide Retail = Customer=E2=80=99s with access to a single UsagePoint (i.e. their Smart = Meter). Therefore an access and refresh token will be tightly = correlated with the type and frequency of data the Smart Meter provides. = There are only a few reasons defined within the ESPI Standard list of = use cases that will require the Token Revocation request to be issued. = The following summarizes the situations that require a Token Revocation = request: =C2=B7 A Third Party application wishes to terminate their = relationship with a Retail Customer. =C2=B7 A Third Party application wishes to terminate their = relationship with a Data Custodian. =C2=B7 A Retail Customer wishes to terminate their relationship = with a Third Party application. =C2=B7 A Retail Customer wishes to change the data (i.e. scope) = a Third Party application has permission to access. In none of the above situations will it be valid to retain a refresh = token, which I realize is implementation dependent, due to the nature of = the ESPI Standard. Perhaps the section on the Server=E2=80=99s Revocation Policy should = address a few of the reasons why a client may want or need to revoke a = token. The current description provides no consideration for the = relationship between tokens and scope, although there clearly is a = relationship. I'm confident client or resource owner would revoke refresh (and not = access) tokens in all use cases you listed above. In my opinion, access = tokens are revoked only if the authorization server does not support = refresh tokens and therefore uses long term access tokens or in = high-security applications. =20 [Don] Based on the above statement it would appear you assume an access = token is only valid for a short period of time. However, as I explained = in my last response, due to the nature of the access required by the = client and the manner in which the RS provides that data, access token = durations will typically be in days not minutes. Therefore, merely = revoking a refresh_token will expose the data to access that the = resource owner meant to prevent unless the access_token is also revoked. I don't understand why access tokens need such a long duration in your = scenario, even if the client needs to obtain energy data once a day. Any = client can (potentially) obtain a new access token at any time if the = access token expires if the authorization server issues corresponding = refresh tokens. So even in your scenario, access tokens could have a = short duration. If you want to issue long-living access tokens in order = to minimize load on the authorization servers, then you have to consider = the extra complexitity and load required to notify resource servers of = access token revocation. It's a tradeoff decision, which we tried to = describe in = http://tools.ietf.org/html/draft-ietf-oauth-revocation-04#section-3.=20 =20 [Don] A critical fact I omitted in my last response is the data obtained = on a daily basis by a Third Party application will utilize an = access_token obtained using the client_credentials grant_type. = Therefore no refresh_token will be issued with the access_token. The = ESPI Standard requires the Retail Customer (resource owner) and the RS = to be notified whenever an authorization is modified or revoked by = either the Third Party (client) or Retail Customer (resource owner). = Therefore, the tradeoff decision has already been made. =20 I personally feel that short lived access_tokens provide greater = security, but in discussions with several utilities who have the = responsibility of supporting the AS and RS functionality, they currently = are planning on implementing long duration access_tokens. This view may = change once the begin to implement =E2=80=9CConnect My Data=E2=80=9D = solutions, but that again is an implementation feature, which is beyond = the scope of my groups current work product. =20 I would also like to hear the opinion of other WG members on this topic. =20 3. If the standard OAuth spec does not provide enough control, your = profile of OAuth2 for the ESPI can tighten it to provide the protections = desired. [Don] I am aware we can provide additional parameters required to = integrate OAuth 2.0 with the ESPI Standard by submitting those parameter = values to the OAuth Parameters registry. I would prefer not to do that, = given the large amount of work being done on RFC-drafts to resolve many = of the issues we are facing to integrate OAuth 2.0 with the ESPI = Standard, since the need to use those extensions will most likely be = short lived. =20 Hmmm, if the need is only short lived, why do you want to make it part = of the long living revocation RFC? =20 [Don] My response was to the suggestion that if the OAuth specification = does not provide enough control then the ESPI profile of OAuth 2.0 could = tighten it to provide the protections desired. I assumed George meant = we could add additional =E2=80=9Ccompany=E2=80=9D based parameters, = which requires us to register them with the =E2=80=9COAuth Parameter = Registry=E2=80=9D. I meant the usage of such =E2=80=9Ccompany=E2=80=9D = parameters would be short termed. Understood. I do not view the need to identify the type of token being revoked as = =E2=80=9Cshort term=E2=80=9D. Even the previous exchanges on the topic = within the WG indicates it feels there may be a need to add an = additional parameter to the request. However, because the draft is too = far along, the WG seems to prefer releasing an RFC they = =E2=80=9Csuspect=E2=80=9D will need to be adjusted and let the = implementers confirm their suspicions. This seems to be a very selfish = and rather foolish attitude given we are discussing a security protocol. = Not to mention it would seem easier and faster to add an additional = =E2=80=9Coptional=E2=80=9D parameter now, rather than requiring another = RFC cycle. A parameter I sensed in reading the archives the WG feels = will very likely need to be added in the future. Since this is a WG item, it is up to the WG to decide. =20 [Don] I fully understand it is the WG=E2=80=99s decision. I am only = providing my opinion as an implementer, who the WG desires to obtain = feedback from before making the final decision. regards, Torsten. Thanks, George On 1/29/13 3:28 PM, Donald F Coffin wrote: Hi Thorsten, =20 I am working with the OpenADE Task Force to document how the = =E2=80=9CEnergy Service Provider Interface (ESPI) Standard =E2=80=9D = published by the North American Energy Standards Board (NAESB) in = October of 2011 should be implemented. The ESPI Standard defines how = Retail Customers, Third Party applications, and Data Custodians (i.e. = electrical, gas, or water utility) must interface to each other and the = data format used to exchange energy information. The interface between = the Retail Customer and the Data Custodian is known as =E2=80=9CDownload = My Data=E2=80=9D, which defines how a Retail Customer receives their = energy information in an XML file downloaded to them by the Data = Custodian. The interface between the Third Party application and the = Data Custodian is known as =E2=80=9CConnect My Data=E2=80=9D, which = defines the message exchanges between the Third Party application and = the Data Custodian to allow the Third Party to access data at the Data = Custodian after a Retail Customer has granted the Third Party = application access. =20 It is my responsibility within the OpenADE Task Force to document the = integration of the OAuth 2.0 protocol with the ESPI Standard. Since the = ESPI Standard requires Retail Customers, Third Party applications, and = Data Custodians to revoke Tokens (i.e. Access and Refresh Tokens) I am = very interested in the =E2=80=9CToken Revocation = (draft-ietf-oath-revocation-xx)=E2=80=9D work being done by you and your = working group.=20 =20 Token Revocation Request =20 The Token Revocation request has only the =E2=80=9Ctoken=E2=80=9D = parameter with the description that the authorization server is supposed = to detect the token type automatically. I would like to request that an = addition parameter =E2=80=9Ctoken_type=E2=80=9D be added to the request. = The =E2=80=9Ctoken_type=E2=80=9D parameter could be optional and would = define the type of token being revoked (i.e. =E2=80=9Caccess=E2=80=9D, = =E2=80=9Crefresh=E2=80=9D, =E2=80=9Cregistration access=E2=80=9D, etc.). =20 The ESPI Standard was developed to support the Advanced Meter Interface = (AMI) which is the interface used by =E2=80=9CSmart Meters=E2=80=9D to = provide automated energy usage collection and other operational = information about a Retail Customer=E2=80=99s residence to their Data = Custodian. Third Party applications will be required to obtain the = approval if each Retail Customer that has had a =E2=80=9CSmart = Meter=E2=80=9D installed before they will be able to access the data = provided by their =E2=80=9CSmart Meter=E2=80=9D. The number of = =E2=80=9CSmart Meters=E2=80=9D currently installed at the three largest = California utilities (Pacific Gas & Electric, Southern California = Edison, and San Diego Gas & Electric) is in excess of 10.0 M and = growing. The following table indicates the number of =E2=80=9CSmart = Meters=E2=80=9D each of the three utilities had installed as of May = 2012: =20 Utility =E2=80=9CSmart Meters=E2=80=9D Installed Pacific Gas & Electric (PG&E) 4,696,000 San Diego Gas & Electric (SDG&E) 1,364,000 Southern California Edison (SCE) 3,900,000 =20 The numbers in the chart were taken from the =E2=80=9CUtility-Scale = Smart Meter Deployments, Plans, & Proposals -- IEE Report=E2=80=9D = published May 2012 by The Edison Foundation Institute for Electric = Efficiency=E2=80=9D which I have attached. The number of =E2=80=9CSmart = Meters=E2=80=9D currently installed are even larger than shown in the = report as I compose this email. Assuming 10% of Pacific Gas & = Electric=E2=80=99s Retail Customers decide to utilize a Third Party = application (3 Third Party applications are currently supported and are = 3 more Third Party applications are preparing to be supported) in order = to support the ability to revoke a token they would be required to track = 500,000 access tokens and 500,000 refresh tokens. Requiring = PG&E=E2=80=99s authorization server to =E2=80=9Cautomatically=E2=80=9D = determine the type of Token being revoked begins to negatively impact = their processing capability. If the Token Revocation request was = capable of indicating the type of Token to be revoked, the amount of = time it will take PG&E=E2=80=99s authorization server would show a = significant time savings to process the request. =20 Authorization Server Revocation Policy =20 =20 6. Does the revocation of the access token also revoke the = refresh token (if it was provided) ? Or is this a revocation policy = decision ? =20 - if the token passed to the request is a refresh token and the server = supports access token revocation, the server SHOULD also revoke them. - if the token passed to the request is an access token, the server may = decide to revoke the respective refresh token as well. =20 I believe that if the token passed in the request is an access token, = the server MUST revoke any respective refresh token. Otherwise, their = exist a potential security risk of the respective refresh token being = used to gain access to the resources for which the access token was = issued. It also means the authorization server will have potential = =E2=80=9Cjunk=E2=80=9D in the refresh token file to search through for = any additional Token Revocation request. =20 I look forward to receiving your response. =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 =20 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 ------=_NextPart_000_0067_01CE0216.A2406BB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Torsten,

 

The Third Party will utilize an access_token they obtain utilizing the = client_credentials to obtain data from the RS for all Retail Customers = who have granted them access to their data.=C2=A0 Therefore, the Third = Party will also have an access_token they obtain utilizing the = authentication_code response_type (i.e. grant_type of code for the = access_token) for each of the Retail Customers who have authorized them = access to their data.

 

Although an access_token will exist for the Third Party, Retail = Customer, and RS relationship its usage will be infrequent compared to = the access_token the Third Party obtains using the client_credentials = grant_type.=C2=A0 This is another reason why I believe in the ESPI = Standard implementation it will be necessary to revoke the access_token = and refresh_token simultaneously.=C2=A0 The RS should not include in the = data stream (covered by the client_credentials access_token) data that = is based on the authorization_code access_token when the Retail Customer = has indicated =C2=A0(either by alteration of the authorization scope or = an outright revocation) the Third Party no longer is authorized to = access the data.=C2=A0 Only revoking the refresh_token possess a = privacy.=C2=A0 Only revoking the access_token, as you pointed out, poses = a potential security issue allowing for the possibility of a denial of = service attack.

 

I hope this makes sense and clarifies my = situation..

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO=

 

<= p class=3DMsoNormal>REMI = Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, = CA=C2=A0 92688-3836

 

<= p class=3DMsoNormal>Phone:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (949) 636-8571

Email:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 donald.coffin@reminetworks.com=

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] =
Sent: Sunday, February 03, 2013 1:14 PM
To: Donald = F Coffin
Cc: George Fletcher; John Adkins; Scott Crowder; Dave = Robin; John Teeter; <pmadsen@pingidentity.com>; Edward Denson; = Marty Burns; Uday Verma; Ray Perlner; Anne Hendry; Lynne Rodoni; = <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-ietf-oauth-revocation-04

 

Hi = Donald,

 

Thanks for the clarification. Let me see whether I got = you right. Although the retail customer has to authorize the access by = the 3rd party application, there is no external representation of this = authorization grant (e.g a refresh token). Instead, the actual access = token is issued based on client credentials. Is there any correlation = between the access token and the particular = customer?

 

Please note: we highly appreciate your feedback as an = implementer.

 

Best regards,

Torsten.


Am 03.02.2013 um 21:45 schrieb = "Donald F Coffin" <donald.coffin@reminetworks= .com>:

Hi Torsten,

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO=

 

<= p class=3DMsoNormal>REMI = Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, = CA  92688-3836

 

<= p class=3DMsoNormal>Phone:    = ;  (949) 636-8571

Email:    = ;   donald.coffin@reminetworks= .com

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, February 03, 2013 4:20 AM
To: = Donald F Coffin
Cc: 'George Fletcher'; 'John Adkins'; 'Scott = Crowder'; 'Dave Robin'; 'John Teeter'; pmadsen@pingidentity.com; = 'Edward Denson'; 'Marty Burns'; 'Uday Verma'; 'Ray Perlner'; 'Anne = Hendry'; 'Lynne Rodoni'; oauth@ietf.org
Subject: Re: = [OAUTH-WG] = draft-ietf-oauth-revocation-04

 

Hi Donald,

Am 03.02.2013 12:57, schrieb Donald F = Coffin:

<snip>

 

[Don] A typical Third Party application built to use the ESPI Standard = will interact with a Retail Customer and their energy provider.  = The nature of interaction with the Retail Customer will utilize short = interactive sessions.  However, the interaction with their energy = provider will require the application obtain new energy information for = the previous 24-hours once a day.  Therefore, I anticipate = access_tokens will be granted for long periods of time as well as any = supporting refresh_tokens.  Because of the amount of data being = exchanged between the Third Party application and the energy provider, = both in number of retail customers and the amount of energy meter data, = it will be necessary to minimize the amount of = =E2=80=9Cadministrative=E2=80=9D traffic required in the exchange.  = Therefore, although I understand the use case you described, I = anticipate such an implementation would be rare.  =

 

The need to perform an audience style check to prevent exposure of the = AS to a denial of service attack, appears primarily due to the fact the = Revocation RFC requires an access_token and refresh_token to be revoked = independently.  Should a client need to revoke both Tokens the = sequence of the revocation request is extremely significant.  A = simple solution to this problem would be to provide a method that allows = a request to revoke both tokens simultaneously, as stated in one of the = responses you referenced in the archives. 

 

The example you gave in your response demonstrating how a denial of = service attack might occur is incorrect.  You said =E2=80=9Cif the = AS revokes the refresh_token when an access_token is revoked, I can = steal an access_token and send it to the revocation endpoint causing the = real client=E2=80=99s refresh_token to be revoked=E2=80=9D.  I fail = to see how that could occur, since the AS revoked both the access_token = and the refresh_token when it received the request to revoke the = access_token.  Rather than explaining why a refresh_token = shouldn=E2=80=99t be revoked concurrently when an access_token is = revoked, your example does the exact opposite.  It shows why a = refresh_token should be revoked concurrently when an access_token is = revoked.

 

[D= on] The focus of the ESPI Standard is to provide Retail = Customer=E2=80=99s with access to a single UsagePoint (i.e. their Smart = Meter).  Therefore an access and refresh token will be tightly = correlated with the type and frequency of data the Smart Meter = provides.  There are only a few reasons defined within the ESPI = Standard list of use cases that will require the Token = Revocation request to be issued.  The following summarizes the = situations that require a Token Revocation = request:

=C2=B7         = A = Third Party application wishes to terminate their relationship with a = Retail Customer.

=C2=B7         = A = Third Party application wishes to terminate their relationship with a = Data Custodian.

=C2=B7         = A = Retail Customer wishes to terminate their relationship with a Third = Party application.

=C2=B7         = A = Retail Customer wishes to change the data (i.e. scope) a Third Party = application has permission to access.

In= none of the above situations will it be valid to retain a refresh = token, which I realize is implementation dependent, due to the nature of = the ESPI Standard.

Pe= rhaps the section on the Server=E2=80=99s Revocation Policy = should address a few of the reasons why a client may want or need to = revoke a token.  The current description provides no consideration = for the relationship between tokens and scope, although there clearly is = a relationship.

I'm confident client = or resource owner would revoke refresh (and not access) tokens in all = use cases you listed above. In my opinion, access tokens are revoked = only if the authorization server does not support refresh tokens and = therefore uses long term access tokens or in high-security = applications.

 

[Don] Based on the above statement it would appear you assume an access = token is only valid for a short period of time.  However, as I = explained in my last response, due to the nature of the access required = by the client and the manner in which the RS provides that data, access = token durations will typically be in days not minutes. =   Therefore, merely revoking a refresh_token will expose the = data to access that the resource owner meant to prevent unless the = access_token is also revoked.


I = don't understand why access tokens need such a long duration in your = scenario, even if the client needs to obtain energy data once a day. Any = client can (potentially) obtain a new access token at any time if the = access token expires if the authorization server issues corresponding = refresh tokens. So even in your scenario, access tokens could have a = short duration. If you want to issue long-living access tokens in order = to minimize load on the authorization servers, then you have to consider = the extra complexitity and load required to notify resource servers of = access token revocation. It's a tradeoff decision, which we tried to = describe in http://tools.ietf.org/html/draft-ietf-oauth-revocation-04#section-3.


 

[Don] A critical fact I omitted in my = last response is the data obtained on a daily basis by a Third Party = application will utilize an access_token obtained using the = client_credentials grant_type.  Therefore no refresh_token will be = issued with the access_token.  The ESPI Standard requires the = Retail Customer (resource owner) and the RS to be notified whenever an = authorization is modified or revoked by either the Third Party (client) = or Retail Customer (resource owner).  Therefore, the tradeoff = decision has already been made.

 

I personally feel that short lived = access_tokens provide greater security, but in discussions with several = utilities who have the responsibility of supporting the AS and RS = functionality, they currently are planning on implementing long duration = access_tokens.  This view may change once the begin to implement = =E2=80=9CConnect My Data=E2=80=9D solutions, but that again is an = implementation feature, which is beyond the scope of my groups current = work product.


Hmmm, if the need is = only short lived, why do you want to make it part of the long living = revocation RFC?

 

[Don] My response was to the suggestion that if the OAuth specification = does not provide enough control then the ESPI profile of OAuth 2.0 could = tighten it to provide the protections desired.  I assumed George = meant we could add additional =E2=80=9Ccompany=E2=80=9D based = parameters, which requires us to register them with the =E2=80=9COAuth = Parameter Registry=E2=80=9D.  I meant the usage of such = =E2=80=9Ccompany=E2=80=9D parameters would be short = termed.


Understood.



I do not view the need to identify the type of token being revoked as = =E2=80=9Cshort term=E2=80=9D.  Even the previous exchanges on the = topic within the WG indicates it feels there may be a need to add an = additional parameter to the request.  However, because the draft is = too far along, the WG seems to prefer releasing an RFC they = =E2=80=9Csuspect=E2=80=9D will need to be adjusted and let the = implementers confirm their suspicions.   This seems to be a = very selfish and rather foolish attitude given we are discussing a = security protocol.  Not to mention it would seem easier and faster = to add an additional =E2=80=9Coptional=E2=80=9D parameter now, rather = than requiring another RFC cycle.  A parameter I sensed in reading = the archives the WG feels will very likely need to be added in the = future.


Since this is a WG item, it is up to the WG to = decide.

 

[Don] I fully understand it is the WG=E2=80=99s decision.  I am = only providing my opinion as an implementer, who the WG desires to = obtain feedback from before making the final = decision.



regards,
Torsten.



<= /o:p>





Thanks,
George

Hi = Thorsten,

 

I am working = with the OpenADE Task Force to document how the =E2=80=9CEnergy = Service Provider Interface (ESPI) Standard =E2=80=9D published = by the North American Energy Standards Board (NAESB) in October = of 2011 should be implemented.  The ESPI Standard defines = how Retail Customers, Third Party applications, and Data Custodians = (i.e. electrical, gas, or water utility) must interface to each other = and the data format used to exchange energy information.   The = interface between the Retail Customer and the Data Custodian is known as = =E2=80=9CDownload My Data=E2=80=9D, which defines how a Retail = Customer receives their energy information in an XML file downloaded to = them by the Data Custodian.  The interface between the Third Party = application and the Data Custodian is known as =E2=80=9CConnect My = Data=E2=80=9D, which defines the message exchanges between the Third = Party application and the Data Custodian to allow the Third Party to = access data at the Data Custodian after a Retail Customer has granted = the Third Party application access.

 

It is my = responsibility within the OpenADE Task Force to document the integration = of the OAuth 2.0 protocol with the ESPI Standard.  = Since the ESPI Standard requires Retail Customers, Third Party = applications, and Data Custodians to revoke Tokens (i.e. Access and = Refresh Tokens) I am very interested in the =E2=80=9CToken = Revocation (draft-ietf-oath-revocation-xx)=E2=80=9D work being = done by you and your working group.

 

Token = Revocation Request

 

The Token = Revocation request has only the =E2=80=9Ctoken=E2=80=9D parameter = with the description that the authorization server is supposed to detect = the token type automatically.  I would like to request that an = addition parameter =E2=80=9Ctoken_type=E2=80=9D be added to the = request.  The =E2=80=9Ctoken_type=E2=80=9D parameter could be = optional and would define the type of token being revoked (i.e. = =E2=80=9Caccess=E2=80=9D, =E2=80=9Crefresh=E2=80=9D, = =E2=80=9Cregistration access=E2=80=9D, etc.).

 

The ESPI = Standard was developed to support the Advanced Meter = Interface (AMI) which is the interface used by =E2=80=9CSmart = Meters=E2=80=9D to provide automated energy usage collection and other = operational information about a Retail Customer=E2=80=99s residence to = their Data Custodian.  Third Party applications will be required to = obtain the approval if each Retail Customer that has had a = =E2=80=9CSmart Meter=E2=80=9D installed before they will be able to = access the data provided by their =E2=80=9CSmart Meter=E2=80=9D.  = The number of =E2=80=9CSmart Meters=E2=80=9D currently installed at the = three largest California utilities (Pacific Gas & Electric, Southern = California Edison, and San Diego Gas & Electric) is in excess of = 10.0 M and growing.  The following table indicates the number of = =E2=80=9CSmart Meters=E2=80=9D each of the three utilities had installed = as of May 2012:

 

Utility

=E2=80=9CSmart = Meters=E2=80=9D Installed

Pacific Gas = & Electric (PG&E)

4,696,000=

San Diego Gas = & Electric (SDG&E)

1,364,000=

Southern = California Edison (SCE)

3,900,000=

 

The numbers in = the chart were taken from the =E2=80=9CUtility-Scale Smart Meter = Deployments, Plans, & Proposals -- IEE Report=E2=80=9D = published May 2012 by The Edison Foundation Institute for Electric = Efficiency=E2=80=9D which I have attached.  The number of = =E2=80=9CSmart Meters=E2=80=9D currently installed are even larger than = shown in the report as I compose this email.  Assuming 10% of = Pacific Gas & Electric=E2=80=99s Retail Customers decide to utilize = a Third Party application (3 Third Party applications are currently = supported and are 3 more Third Party applications are preparing to be = supported) in order to support the ability to revoke a token they would = be required to track 500,000 access tokens and 500,000 refresh = tokens.  Requiring PG&E=E2=80=99s authorization server to = =E2=80=9Cautomatically=E2=80=9D determine the type of Token being = revoked begins to negatively impact their processing capability.  = If the Token Revocation request was capable of indicating the = type of Token to be revoked, the amount of time it will take = PG&E=E2=80=99s authorization server would show a significant time = savings to process the request.

 

Authorization = Server Revocation Policy

 

 

  &nbs= p;   6.       Does the = revocation of the access token also revoke the refresh token (if it was = provided) ? Or is this a revocation policy decision ?

 

- if the token passed to the request is a refresh token = and the server supports access token revocation, the server SHOULD also = revoke them.
- if the token passed to the request is an access token, = the server may decide to revoke the respective refresh token as = well.

 

I believe that if the token passed in the request is an = access token, the server MUST revoke any respective refresh token.  = Otherwise, their exist a potential security risk of the respective = refresh token being used to gain access to the resources for which the = access token was issued.  It also means the authorization server = will have potential =E2=80=9Cjunk=E2=80=9D in the refresh token file to = search through for any additional Token Revocation = request.

 

I look forward to receiving your = response.

 

Best = regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI = Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, CA  = 92688-3836

 

Phone:      (949) = 636-8571

Email:       donald.coffin@reminetworks= .com

 







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

 

 

------=_NextPart_000_0067_01CE0216.A2406BB0--