Re: [OAUTH-WG] Registration: RESTful client lifecycle management
I agree. If we have it at all, DELETE should be a declaration by the Client that requests by it should no longer be honored. It should be up to the Server whether to implement this as suspension or deletion. At most, I believe it should be an optional operation, which MAY be supported. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Saturday, February 16, 2013 10:04 PM To: John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management > When sending an update, a client MUST send all metadata fields > returned from the server in its initial registration or previous read > or update call, including its client_id. A server MAY replace any > missing or invalid fields with default values, or it MAY return an > error as described in the Error Response section. A server MUST return > all provisioned fields in its response. A server MUST NOT change the > client_id field. A server MAY change the client_secret and/or > refresh_access_token fields. Say the client registered some value. Sometime later, the server changed a value due to some policy or security reasons etc. The client when UPDATES with the previously registered value, what is going to happen to the changed value? >> DELETE to be used correctly is I think going to delete the client_id and all >> associated tokens and cause a ripple effect in removing grants associated >> with that client_id. > > This is how I would interpret it as well. It's de-provisioning the > client, not resetting it. For DELETE, I can think of an attack such that 1. Register as a client. 2. Send spam links to random users. 3. When user "authorizes", suck the user data such as contacts out. 4. DELETE the registration and disappear. To prevent something like this, it should probably be something more akin to "suspend" rather than completely de-provisioning. ___ 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] Registration: RESTful client lifecycle management
> When sending an update, a client MUST send all metadata fields returned > from the server in its initial registration or previous read or update > call, including its client_id. A server MAY replace any missing or > invalid fields with default values, or it MAY return an error as > described in the Error Response section. A server MUST return all > provisioned fields in its response. A server MUST NOT change the > client_id field. A server MAY change the client_secret and/or > refresh_access_token fields. Say the client registered some value. Sometime later, the server changed a value due to some policy or security reasons etc. The client when UPDATES with the previously registered value, what is going to happen to the changed value? >> DELETE to be used correctly is I think going to delete the client_id and all >> associated tokens and cause a ripple effect in removing grants associated >> with that client_id. > > This is how I would interpret it as well. It's de-provisioning the > client, not resetting it. For DELETE, I can think of an attack such that 1. Register as a client. 2. Send spam links to random users. 3. When user "authorizes", suck the user data such as contacts out. 4. DELETE the registration and disappear. To prevent something like this, it should probably be something more akin to "suspend" rather than completely de-provisioning. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
+1 2013/2/13 Torsten Lodderstedt : > > Am 12.02.2013 um 15:57 schrieb Justin Richer : > >> >> I think that's a very important difference. > > I fully agree. > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Registration: Client secret rotation
Sounds reasonable. # just started to catch up with the emails of past 6 days... 2013/2/13 Mike Jones : > +1 > > > From: John Bradley > Sent: 2/12/2013 8:20 AM > To: Justin Richer > Cc: Mike Jones; oauth@ietf.org > Subject: Re: [OAUTH-WG] Registration: Client secret rotation > > Yes, that agrees with my thoughts on it. > > John B. > On 2013-02-12, at 11:29 AM, Justin Richer 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 >> >> On 02/11/2013 08:42 PM, John Bradley wrote: >>> 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. >>> On 2013-02-11, at 10:18 PM, Mike Jones >>> wrote: >>> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Monday, February 11, 2013 1:15 PM To: oauth@ietf.org 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
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
Who has a rather detailed description about the three key distribution machanisms? Please tell me if I am wrong in understanding them only from the ppt and previouse mac and hotk document: 1. The key distributuon means AS distributing a short-term-key to client and RS; 2. AS and RS has another way of sharing a long-term-key which is not covered by the design team; 3. Client-AS and Client-RS may have their ways of authentication not using the short-term-key; 4. short-term-key is only used for protecting access token from being stolen or abused by entities other than the client(as bear token); then there are 3 possible approaches for generating an access token (suppose short-term-key is irrelevant with long-term-key): 1) access token=F(...,short-term-key) // not secure, and equivalent to the case that access token being short-term-key 2) access token=F(...,longt-term-key) //pass. for no short-term-key is invloved 3) access token=F(...,short-term-key,long-term-key)// I guess this case is the base on which the design team is discussing ? Based on the above pre-assumption,the following is my opinion on the 3 key distribution mechanisms: key-transport: in this meachanism short-term-key is transported from AS to client, then to RS, short-term-key could be transported inside or outside of access token, which is no big difference, the security of this mecha is actually guaranteed by long-term-key; key-retrieval: short-term-key is obtained from AS by RS directly, it is more secure, but need an extra information exchange between RS and AS each time Client is requesting resource to RS. key-agreement: short-term-key could be derived from long-term-key and some other information included in (or accompanying) access token, this mecha is actually not different from case 2) above, that is no short-term-key is required to send actually. oauth-boun...@ietf.org 写于 2013-02-12 17:10:27: > Here are my notes. > > Participants: > > * John Bradley > * Derek Atkins > * Phil Hunt > * Prateek Mishra > * Hannes Tschofenig > * Mike Jones > * Antonio Sanso > * Justin Richer > > Notes: > > My slides are available here: http://www.tschofenig.priv.at/OAuth2- > Security-11Feb2013.ppt > > Slide #2 summarizes earlier discussions during the conference calls. > > -- HTTP vs. JSON > > Phil noted that he does not like to use the MAC Token draft as a > starting point because it does not re-use any of the work done in > the JOSE working group and in particular all the libraries that are > available today. He mentioned that earlier attempts to write the MAC > Token code lead to problems for implementers. > > Justin responded that he does not agree with using JSON as a > transport mechanism since this would replicate a SOAP style. > > Phil noted that he wants to send JSON but the signature shall be > computed over the HTTP header field. > > -- Flexibility for the keyed message digest computation > > From earlier discussion it was clear that the conference call > participants wanted more flexibility regarding the keyed message > digest computation. For this purpose Hannes presented the DKIM based > approach, which allows selective header fields to be included in the > digest. This is shown in slide #4. > > After some discussion the conference call participants thought that > this would meet their needs. Further investigations would still be > useful to determine the degree of failed HMAC calculations due to > HTTP proxies modifying the content. > > -- Key Distribution > > Hannes presented the open issue regarding the choice of key > distribution. Slides #6-#8 present three techniques and Hannes asked > for feedback regarding the preferred style. Justin and others didn't > see the need to decide on one mechanism - they wanted to keep the > choice open. Derek indicated that this will not be an acceptable > approach. Since the resource server and the authorization server > may, in the OAuth 2.0 framework, be entities produced by different > vendors there is an interoperability need. Justin responded that he > disagrees and that the resource server needs to understand the > access token and referred to the recent draft submission for the > token introspection endpoint. Derek indicated that the resource > server has to understand the content of the access token and the > token introspection endpoint just pushes the problem around: the > resource server has to send the access token to the authorization > server and then the resource server gets the result back (which he then a > gain needs to understand) in order to make a meaningful > authorization decision. > > Everyone agreed that the client must receive the session key from > the authorization server and that this approach has to be > standardized. It was also agreed that this is a common approach > among all three key distribution mechanisms. > > Hannes asked the
