Nat's attack vector presumes lack of logging on the server side, where
doing a "delete" means that you can no longer see anything about who did
what. You could make the same argument if you have a system where users
can register themselves and delete their accounts at will -- someone
creates a fly-by-night account, does bad things, deletes the account. If
the site doesn't have detailed logs in both of these cases, yes, they'll
be in the dark about the bad things that happened when the
account/client was active. It's a valuable security consideration, but I
don't think that it's enough to say that delete is no longer a valid
operation.
I think it's up to the server what "delete" means under the hood, but
the important bit for the protocol is that as far as the client is
concerned, that client_id is dead now. I don't think it's worthwhile to
specify it as a "suspend" operation, because to me "suspend" implies an
ability to "unsuspend", and I really don't think we want to get into the
complicated zombie OAuth client business. But whether on the server side
"delete" translates to "delete everything from the database immediately
and burn all records of it" or instead "set a flag on that client and
all of its outstanding grants so that it can't be used but
administrators can still poke it with a stick" is completely up to the
implementation and its security considerations.
That said, I think it would make sense to at least describe this
potential problem in the security considerations, and note that the
client MUST NOT use the client_id again.
-- Justin
On 02/17/2013 01:11 AM, Mike Jones wrote:
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
