Eran: I think the issue of refreshing tokens should be a configurable parameter (security policy) that the authorization server (ie. admin managing it) sets. Perhaps the parameter value should be advertised in the "service documentation" of the authorization end-point. So the client can choose to accept or walkaway when it sees this parameter (depending on its own security policies). Changing keying material is necessary to prevent crypto-attacks on stale keys.
Just to give an idea about timing: many large scale Kerberos infra require the user to get a new TGT every 24-hours, and some even sooner. Brian: I don't fully understand your earlier email: >>> Requiring client authentication doesn't defend against >>> attacks directly; it makes recovery after a successful >>> attack easier. I presume you mean direct attacks on the authorization server. But wouldn't requiring OAuth clients to authenticate (in some manner to the authorization server) at least reduce the opportunity for DOS attacks to the authorization server. Thanks. /thomas/ _____________ > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Wednesday, June 15, 2011 9:19 PM > To: Brian Eaton > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Client authentication requirement > > Your comment was that having client authentication makes it easier to > recovery from an attack. I don't understand how the comments below > about changing client secrets every 30 days are relevant. Are you > suggesting to wait until the next routine secret cycle to revoke > compromised credentials? Or that 30 days is a reasonable time period > for ignoring an attack? > > EHL > > From: Brian Eaton [mailto:bea...@google.com] > Sent: Wednesday, June 15, 2011 6:15 PM > To: Eran Hammer-Lahav > Cc: Brian Campbell; OAuth WG > Subject: Re: [OAUTH-WG] Client authentication requirement > > On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > How does it make recovery easier? Why is revoking refresh token any > harder than changing client secret? > > Changing a client secret can be done without disrupting users. You can > even schedule it, do it every 30 days as part of your general > operational procedures. It's part of a healthy system. > > Revoking refresh tokens every 30 days is not really feasible. > > As for the assertion grant type, where is the specified that the > refresh token is bound to the private keys used to produce the > assertion used to obtain the refresh token in the first place? > > Well, the spec currently has refresh tokens bound to client ids. > > And the assertion spec proposal authenticated client ids with > public/private key pairs. > > You wouldn't bind the refresh token directly to a private key, for the > same reason that you don't bind the refresh token directly to the > client secret. You bind refresh tokens to clients, and then you > require client authentication. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
