Re: [OAUTH-WG] draft-ietf-oauth-revocation-04

["Donald F Coffin" <[e-mail]>]

George,

 

Thanks for the quick response.  I've added my comments after your responses
below.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:      [phone]

Email:        <mailto:[e-mail]>
[e-mail]

 

From: George Fletcher [mailto:[e-mail]] 
Sent: Tuesday, January 29, 2013 3:29 PM
To: Donald F Coffin
Cc: Torsten Lodderstedt; John Adkins; Scott Crowder; Dave Robin; John
Teeter; [e-mail]; Edward Denson; Marty Burns; Uday Verma;
Ray Perlner; Anne Hendry; Lynne Rodoni; [e-mail]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04

 

First, just want to say this is a great write up of the situation. Thanks!

A couple of additional thoughts regarding token management and processing...

1. If all tokens being revoked are tokens issued by the same Authorization
Server (AS) then it can easily mark which are refresh and which are access
such that I'm not sure an additional parameter is needed. If the issue is
integrating with legacy tokens, then I can see a short term need as an
optimization while the tokens rotate through. The question is whether the
short term need of the parameter justifies it if long term it's not needed.
Maybe an option is for the ESPI profile to specify an additional parameter
that is not required by this spec.

[Don] A few utilities have launched "Connect My Data" programs with Third
Party applications, but these are using Certificates as a means of
identifying Third Party applications.  There are no utilities, to my
knowledge, with "Connect My Data" programs that have implemented OAuth 2.0.
The current ESPI Standard requires the implementation of OAuth 1.0.
Therefore, there should not be a legacy token issue.  As a result of the
work our group is doing, we will shortly submit a request to NAESB to revise
the existing standard to reflect the migration from OAuth 1.0 to OAuth 2.0.

Your suggestion to "mark which are refresh and which are access" tokens
while providing a method to identify what type of token was issued after it
has been found, still poses a processing problem if the only parameter on
the Token Revocation request is the Token.  Even implementing your
suggestion it will still be necessary to scan the entire set of Tokens to
locate and identify what type of Token is being revoked.  If a token_type
parameter is provided with the Token Revocation request the only Tokens that
need to be scanned are those matching the type being revoked.  This will
significantly reduce the size of the dataset and therefore expedite the
search.  I realize assigning the Token value as an index key would also
improve the retrieval time.  Since that is an implementation feature, it is
beyond the scope of the activity our group is chartered to perform.


2. I don't think you can always revoke the refresh_token if an access_token
is revoked. I can see a use case where a client gets a refresh_token and an
access_token. The client uses the access_token for 5 minutes but the
access_token is good for an hour. So the client revokes the access_token to
ensure it can't be used again. The client will just use it's refresh_token
when it needs another access_token. In this case, revoking the refresh_token
would "break" the client. In addition, unless you add audience style
checking to the token processing rules, you open up the AS to a denial of
service attack. Basically, if 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's refresh_token to be revoked.
To prevent this, the tokens should be bound to the client_id to which they
were issued, and should only be revocable from that client_id.

 

[Don] The focus of the ESPI Standard is to provide Retail Customer's 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:

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

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

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

.         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's 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.

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.

Thanks,
George

On 1/29/13 3:28 PM, Donald F Coffin wrote:

Hi Thorsten,

 

I am working with the OpenADE Task Force to document how the "Energy Service
Provider Interface (ESPI) Standard " 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
"Download My Data", 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 "Connect My Data", 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 "Token Revocation (draft-ietf-oath-revocation-xx)" work
being done by you and your working group. 

 

Token Revocation Request

 

The Token Revocation request has only the "token" 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
"token_type" be added to the request.  The "token_type" parameter could be
optional and would define the type of token being revoked (i.e. "access",
"refresh", "registration access", etc.).

 

The ESPI Standard was developed to support the Advanced Meter Interface
(AMI) which is the interface used by "Smart Meters" to provide automated
energy usage collection and other operational information about a Retail
Customer's residence to their Data Custodian.  Third Party applications will
be required to obtain the approval if each Retail Customer that has had a
"Smart Meter" installed before they will be able to access the data provided
by their "Smart Meter".  The number of "Smart Meters" 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 "Smart Meters" each of
the three utilities had installed as of May 2012:

 


Utility

"Smart Meters" 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 "Utility-Scale Smart Meter
Deployments, Plans, & Proposals -- IEE Report" published May 2012 by The
Edison Foundation Institute for Electric Efficiency" which I have attached.
The number of "Smart Meters" currently installed are even larger than shown
in the report as I compose this email.  Assuming 10% of Pacific Gas &
Electric's 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's authorization server to
"automatically" 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's authorization server would show a
significant time savings to process the request.

 

Authorization Server Revocation Policy

 

 

      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 "junk" 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:      [phone]

Email:       [e-mail]

 






_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth