Re: [OAUTH-WG] Refresh token security considerations
Key rotation I understand. Forcing expiry on every reissue seems extreme though. From: Brian Eaton bea...@google.com To: William J. Mills wmi...@yahoo-inc.com Cc: Torsten Lodderstedt tors...@lodderstedt.net; Eran Hammer-Lahav e...@hueniverse.com; OAuth WG oauth@ietf.org Sent: Tuesday, July 12, 2011 9:32 AM Subject: Re: [OAUTH-WG] Refresh token security considerations On Tue, Jul 12, 2011 at 8:29 AM, William J. Mills wmi...@yahoo-inc.com wrote: Why would you re-issue a refresh token every usage? What's the use case where this makes sense? It's key rotation built into the protocol. Even if a refresh token is stolen, it's going to become useless to the attacker very quickly. My main concern with rotating refresh tokens with every use is that it can cause problems with distributed client apps; they have to keep the refresh token in sync, and it adds complexity. But for desktop and mobile apps it's quite a good idea. (You can see a similar design in how Active Directory manages kerberos machine keys. They took a slightly different approach, in that the client machines phone home to change their keys, but it provides similar benefits.)___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Refresh token security considerations
Why? William J. Mills wmi...@yahoo-inc.com schrieb: I agree that this is something you could do, but it doesn't seem like a good design pattern. _ From: Torsten Lodderstedt tors...@lodderstedt.net To: Eran Hammer-Lahav e...@hueniverse.com; OAuth WG oauth@ietf.org Sent: Sunday, July 10, 2011 1:21 AM Subject: Re: [OAUTH-WG] Refresh token security considerations replacement of the refresh token with every access token refresh is an example. The authz server creates and returns a new refresh token value with every access token refreshment. The old value is invalidated and must not be used any further. Note: The authz server keeps track of all old (invalidated) refresh tokens. If a client presents one of those old refresh tokens, the legitimate client has been compromised most likely. The authz then revokes the refresh token and the associated access authorization. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: “the authorization server SHOULD deploy other means to detect refresh token abuse” This requires an example. EHL ___ 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
Re: [OAUTH-WG] Refresh token security considerations
Why would you re-issue a refresh token every usage? What's the use case where this makes sense? The way I always think about the design is that refresh tokens are indended to be multi-use. From: Torsten Lodderstedt tors...@lodderstedt.net To: William J. Mills wmi...@yahoo-inc.com; Eran Hammer-Lahav e...@hueniverse.com; OAuth WG oauth@ietf.org Sent: Tuesday, July 12, 2011 12:53 AM Subject: Re: [OAUTH-WG] Refresh token security considerations Why? William J. Mills wmi...@yahoo-inc.com schrieb: I agree that this is something you could do, but it doesn't seem like a good design pattern. From: Torsten Lodderstedt tors...@lodderstedt.net To: Eran Hammer-Lahav e...@hueniverse.com; OAuth WG oauth@ietf.org Sent: Sunday, July 10, 2011 1:21 AM Subject: Re: [OAUTH-WG] Refresh token security considerations replacement of the refresh token with every access token refresh is an example. The authz server creates and returns a new refresh token value with every access token refreshment. The old value is invalidated and must not be used any further. Note: The authz server keeps track of all old (invalidated) refresh tokens. If a client presents one of those old refresh tokens, the legitimate client has been compromised most likely. The authz then revokes the refresh token and the associated access authorization. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: “the authorization server SHOULD deploy other means to detect refresh token abuse” This requires an example. EHL ___ 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
Re: [OAUTH-WG] Refresh token security considerations
On Tue, Jul 12, 2011 at 8:29 AM, William J. Mills wmi...@yahoo-inc.com wrote: Why would you re-issue a refresh token every usage? What's the use case where this makes sense? It's key rotation built into the protocol. Even if a refresh token is stolen, it's going to become useless to the attacker very quickly. My main concern with rotating refresh tokens with every use is that it can cause problems with distributed client apps; they have to keep the refresh token in sync, and it adds complexity. But for desktop and mobile apps it's quite a good idea. (You can see a similar design in how Active Directory manages kerberos machine keys. They took a slightly different approach, in that the client machines phone home to change their keys, but it provides similar benefits.) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Refresh token security considerations
+1 Maybe either way at the issuers discretion (optional) until we have a strong feeling why one technique is particularly problematic. i.e. if the server chooses to provide a new refresh token the old token is expired. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-07-12, at 9:32 AM, Brian Eaton wrote: On Tue, Jul 12, 2011 at 8:29 AM, William J. Mills wmi...@yahoo-inc.com wrote: Why would you re-issue a refresh token every usage? What's the use case where this makes sense? It's key rotation built into the protocol. Even if a refresh token is stolen, it's going to become useless to the attacker very quickly. My main concern with rotating refresh tokens with every use is that it can cause problems with distributed client apps; they have to keep the refresh token in sync, and it adds complexity. But for desktop and mobile apps it's quite a good idea. (You can see a similar design in how Active Directory manages kerberos machine keys. They took a slightly different approach, in that the client machines phone home to change their keys, but it provides similar benefits.) ___ 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
Re: [OAUTH-WG] Refresh token security considerations
replacement of the refresh token with every access token refresh is an example. The authz server creates and returns a new refresh token value with every access token refreshment. The old value is invalidated and must not be used any further. Note: The authz server keeps track of all old (invalidated) refresh tokens. If a client presents one of those old refresh tokens, the legitimate client has been compromised most likely. The authz then revokes the refresh token and the associated access authorization. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: “the authorization server SHOULD deploy other means to detect refresh token abuse” This requires an example. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Refresh token security considerations
I agree that this is something you could do, but it doesn't seem like a good design pattern. From: Torsten Lodderstedt tors...@lodderstedt.net To: Eran Hammer-Lahav e...@hueniverse.com; OAuth WG oauth@ietf.org Sent: Sunday, July 10, 2011 1:21 AM Subject: Re: [OAUTH-WG] Refresh token security considerations replacement of the refresh token with every access token refresh is an example. The authz server creates and returns a new refresh token value with every access token refreshment. The old value is invalidated and must not be used any further. Note: The authz server keeps track of all old (invalidated) refresh tokens. If a client presents one of those old refresh tokens, the legitimate client has been compromised most likely. The authz then revokes the refresh token and the associated access authorization. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: “the authorization server SHOULD deploy other means to detect refresh token abuse” This requires an example. EHL ___ 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
