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 “administrative”
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 “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”. 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’t 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.
[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.
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.
I would also like to hear the opinion of other WG members on this topic.
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.
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 “company” based
parameters, which requires us to register them with the “OAuth
Parameter Registry”. I meant the usage of such “company” parameters
would be short termed.
Understood.
I do not view the need to identify the type of token being revoked as
“short term”. 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 “suspect” 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 “optional” 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.
regards,
Torsten.
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: (949) 636-8571
Email: [email protected]
<mailto:[email protected]>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
