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

[George Fletcher <[e-mail]>]

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.

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.

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.

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] 
> <mailto:[e-mail]>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth