Subject: [OAUTH-WG] Registration: Client secret rotation

From: Justin Richer <[email-masked]>
Date: Mon, 11 Feb 2013 16:14:39 -0500

Draft -05 of OAuth Dynamic Client Registration [1] defines a means of 
the client requesting a new client_secret (if applicable) and a new 
registration_access_token. Client secrets MAY expire after some period 
of time, and this method allows for a refresh of that secret. Draft -00 
defined no such operation, drafts -01 through -04 defined this operation 
in terms of the operation=rotate_secret parameter, and draft -05 defines 
it through a secondary endpoint, the Client Secret Rotation Endpoint. 
This raises several questions:

  - Should the client be allowed to request rotation of its secret?
  - Would a client ever take this action of its own accord?
  - Can a server rotate the secret of the client without the client 
asking? (This seems to be an obvious "yes")

Alternatives that keep this functionality include defining the 
rotate_secret operation in terms of an HTTP verb, a query parameter, or 
separate endpoint. Alternatively, we could drop the rotate_secret 
operation all together. If we do this, we have to decide if the client 
secret can still expire. If it can, then we need a way for the client to 
get this new secret through a means that doesn't require it to request a 
change in secret, such as sending it back as part of the client READ 
operation (see other thread on RESTful verbs).

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Feb 2013 01:18:39 +0000

The rotate_secret operation was added to OpenID Connect Registration as a workaround to the fact that registration updates used to be authenticated using the client secret, so it seemed overly dangerous to have an update operation potentially return an updated secret and have the secret be lost due to communication problems - leaving the client stranded.  Since then, registration was changed to use a bearer token to authenticate update operations, and so this failure mode can't occur anymore.  It was an omission not to have deleted the unneeded operation then.

It's been deleted from OpenID Connect Registration and should likewise be deleted from OAuth registration, since it is unneeded.  If a new client secret is needed, there's nothing stopping the registration server from returning it in the result of an update operation.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: [email-masked]
Subject: [OAUTH-WG] Registration: Client secret rotation

Draft -05 of OAuth Dynamic Client Registration [1] defines a means of the client requesting a new client_secret (if applicable) and a new registration_access_token. Client secrets MAY expire after some period of time, and this method allows for a refresh of that secret. Draft -00 defined no such operation, drafts -01 through -04 defined this operation in terms of the operation=rotate_secret parameter, and draft -05 defines it through a secondary endpoint, the Client Secret Rotation Endpoint. 
This raises several questions:

  - Should the client be allowed to request rotation of its secret?
  - Would a client ever take this action of its own accord?
  - Can a server rotate the secret of the client without the client asking? (This seems to be an obvious "yes")

Alternatives that keep this functionality include defining the rotate_secret operation in terms of an HTTP verb, a query parameter, or separate endpoint. Alternatively, we could drop the rotate_secret operation all together. If we do this, we have to decide if the client secret can still expire. If it can, then we need a way for the client to get this new secret through a means that doesn't require it to request a change in secret, such as sending it back as part of the client READ operation (see other thread on RESTful verbs).

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Feb 2013 22:42:30 -0300

OAuth doesn't say anything about client secrets other than they are provisioned in a magic realm outside the OAuth spec (Getting in the mood for the next IETF).

Rotating client secrets was something I made up for connect because it seemed like a good idea at the time given that someone breaking in to the registration endpoint could take over a connection.

We later separated the authentication to the token endpoint from the registration endpoint,in what I think was a good move.

It is sort of up to the authorization server to make decisions about rotating client secrets, I expect that in the real world a client would try access ing the token endpoint and get back a invalid_client error response and then heck it's registration to see if the client_secret has changed.

I suppose that a client could request rotating its secret if it thinks it has been compromised,  however the compromiser is more likely to quickly change the secret to lock out the legitimate clients before the good one notices.    I think the client wanting to rotate is enough of a edge case that it could deal with it out of band.

Letting the server rotate the client secret according to what ever policy it decides is best is probably safest.

We didn't have anything for rotating the access token.  I suspect that rotating it under the clients control is going to create as many problems as it solves.

If you want to rotate it,  make it a refresh token that is issues and use OAuth to provide access tokens from the token endpoint.   Creating a new endpoint to duplicate existing OAuth functionality is overkill.

John B.

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Feb 2013 09:29:42 -0500

This is actually the approach that I favor now as well -- let the server 
do the secret rotation if it wants to, and have the client be prepared 
to receive a new client_secret or registration_access_token on any read 
or update request.

This would necessitate changing the returned values, essentially 
collapsing the returns from the read/update and rotate actions into one 
structure that's closer to the one returned from initial registration. 
This has the added benefit of parallelizing the responses for these 
three actions, which I like as well.

  -- Justin

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Feb 2013 13:20:28 -0300

Yes, that agrees with my thoughts on it.

John B.
On 2013-02-12, at 11:29 AM, Justin Richer <[email-masked]> wrote:

> This is actually the approach that I favor now as well -- let the server do the secret rotation if it wants to, and have the client be prepared to receive a new client_secret or registration_access_token on any read or update request.
> 
> This would necessitate changing the returned values, essentially collapsing the returns from the read/update and rotate actions into one structure that's closer to the one returned from initial registration. This has the added benefit of parallelizing the responses for these three actions, which I like as well.
> 
> -- Justin
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Feb 2013 17:56:14 +0000

+1

________________________________
From: John Bradley
Sent: 2/12/2013 8:20 AM
To: Justin Richer
Cc: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Registration: Client secret rotation

John B.

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 17 Feb 2013 14:53:38 +0900

Sounds reasonable.

# just started to catch up with the emails of past 6 days...

2013/2/13 Mike Jones <[email-masked]>:
>> do the secret rotation if it wants to, and have the client be prepared to
>> receive a new client_secret or registration_access_token on any read or
>> update request.
>>
>> structure that's closer to the one returned from initial registration. This
>> has the added benefit of parallelizing the responses for these three
>> actions, which I like as well.
>>
>> -- Justin
>>
>>> OAuth doesn't say anything about client secrets other than they are
>>> provisioned in a magic realm outside the OAuth spec (Getting in the mood for
>>> the next IETF).
>>>
>>> Rotating client secrets was something I made up for connect because it
>>> seemed like a good idea at the time given that someone breaking in to the
>>> registration endpoint could take over a connection.
>>>
>>> We later separated the authentication to the token endpoint from the
>>> registration endpoint,in what I think was a good move.
>>>
>>> It is sort of up to the authorization server to make decisions about
>>> rotating client secrets, I expect that in the real world a client would try
>>> access ing the token endpoint and get back a invalid_client error response
>>> and then heck it's registration to see if the client_secret has changed.
>>>
>>> I suppose that a client could request rotating its secret if it thinks it
>>> has been compromised,  however the compromiser is more likely to quickly
>>> change the secret to lock out the legitimate clients before the good one
>>> notices.    I think the client wanting to rotate is enough of a edge case
>>> that it could deal with it out of band.
>>>
>>> We didn't have anything for rotating the access token.  I suspect that
>>> rotating it under the clients control is going to create as many problems as
>>> it solves.
>>>
>>> If you want to rotate it,  make it a refresh token that is issues and use
>>> OAuth to provide access tokens from the token endpoint.   Creating a new
>>> endpoint to duplicate existing OAuth functionality is overkill.
>>>
>>> John B.
>>>> The rotate_secret operation was added to OpenID Connect Registration as
>>>> a workaround to the fact that registration updates used to be authenticated
>>>> using the client secret, so it seemed overly dangerous to have an update
>>>> operation potentially return an updated secret and have the secret be lost
>>>> due to communication problems - leaving the client stranded.  Since then,
>>>> registration was changed to use a bearer token to authenticate update
>>>> operations, and so this failure mode can't occur anymore.  It was an
>>>> omission not to have deleted the unneeded operation then.
>>>>
>>>> It's been deleted from OpenID Connect Registration and should likewise
>>>> be deleted from OAuth registration, since it is unneeded.  If a new client
>>>> secret is needed, there's nothing stopping the registration server from
>>>> returning it in the result of an update operation.
>>>>
>>>>                              -- Mike
>>>>
>>>> registration_access_token. Client secrets MAY expire after some period of
>>>> time, and this method allows for a refresh of that secret. Draft -00 defined
>>>> no such operation, drafts -01 through -04 defined this operation in terms of
>>>> the operation=rotate_secret parameter, and draft -05 defines it through a
>>>> secondary endpoint, the Client Secret Rotation Endpoint.
>>>> separate endpoint. Alternatively, we could drop the rotate_secret operation
>>>> all together. If we do this, we have to decide if the client secret can
>>>> still expire. If it can, then we need a way for the client to get this new
>>>> secret through a means that doesn't require it to request a change in
>>>> secret, such as sending it back as part of the client READ operation (see
>>>> other thread on RESTful verbs).
>>>>
>>>>  -- Justin
>>>>
>>>>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en