Kris - Thanks for pointing back to where this started!
I more or less agree with what Allen said in response to Torsten's proposal: http://www.ietf.org/mail-archive/web/oauth/current/msg02295.html. The devil is in the details. I'd be interested in tackling client secret rotation at the same time as handling refresh token rotation... they are similar problems. BUT, if we do this, we should do it reasonably well. In particular, I think we'd need: - a way for clients to opt-in to this, probably when they first get a refresh token - a system that worked for distributed clients - a system that allowed rotation of the client secret I don't think any of that would be impractical, long-term. Windows and AD have had automatic rotation of kerberos service keys for a while, for example. And here's a more far-fetched idea... installed applications could self-generate public/private key pairs, which could then be used to authenticate to the authorization server using something like Yaron's recent proposal for client assertion authentication. Cheers, Brian On Tue, Jul 13, 2010 at 5:55 PM, Kris Selden <kris.sel...@gmail.com> wrote: > Torsten Lodderstedt > [OAUTH-WG] Refresh tokens security enhancement > http://www.ietf.org/mail-archive/web/oauth/current/msg02292.html > > Eran Hammer-Lahav > Re: [OAUTH-WG] Refresh tokens security enhancement > http://www.ietf.org/mail-archive/web/oauth/current/msg02390.html > > On Jul 13, 2010, at 7:04 AM, Eran Hammer-Lahav wrote: > >> >> >> >> On 7/12/10 10:36 PM, "Brian Eaton" <bea...@google.com> wrote: >> >>> Draft 10 has the following sentence in section 4.1.4: >>> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 >>> >>> "The authorization server MAY issue a new refresh token." >> >> The capability was there since -02. >> >> -04 added the following text in an attempt to clarify how the refresh_token >> output can be used (returning a refresh token was briefly discussed as part >> of the general idea of always allowing a refresh token in token responses): >> >> The authorization server >> MAY issue a new refresh token in which case the client MUST NOT use >> the previous refresh token and replace it with the newly issued >> refresh token. >> >> In -10 I dropped the restriction because people expressed a general issue >> with having to revoke tokens. >> >>> That carries a surprising amount of baggage. I suggest removing the >>> sentence, or changing it to MUST NOT, pending a discussion of the use >>> cases for issuing new refresh tokens. >>> >>> Does anyone remember why that sentence got added to the spec? >>> >>> There are two reasons I can see for issuing new refresh tokens: >>> 1) secrets are like underwear, change them frequently >>> 2) someone has a cryptographically implemented refresh token that >>> needs to be re-signed or re-issued >>> >>> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, >>> these pretty much have to be backed by server-side state or there is >>> no way to run your system. So I'm going to ignore that possibility, >>> and guess that someone was interested in changing secrets... >> >> There was no requirement to support changing refresh tokens. If there is no >> interest in this, I suggest we forbid it (otherwise all clients will need to >> accommodate the chance of a new refresh token, and then will need guidelines >> on how to handle it). >> >>> So if we want to issue new refresh tokens because we like to change >>> secrets, we should cover: >>> - whether existing refresh tokens are revoked. (I'd vote for MUST be >>> revoked) >> >> I agree. >> >>> - the minimum latency between issuing a new refresh token and revoking >>> the old one. (I'd vote for minimum latency measured in hours or >>> longer. Clients that have cached refresh tokens need to refresh their >>> cache within this time period, or they're borked.) >>> - the maxium latency for revoking the old token. (I'd vote for >>> maximum latency measured in hours or days, just for security reasons. >>> But I can't think of what would break if servers ignored this advice.) >> >> Why is this required? Can it be specified as a general recommendation? >> >> EHL >> >>> Cheers, >>> Brian >>> _______________________________________________ >>> 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 >> > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
