[Security] Unsubscribe on Userdelete (Was: [Standards] Password protected rooms)

[Michael Grigutsch]

Hi everybody!

Matthew Wild wrote on the Standard-List:

> On Wed, Feb 11, 2009 at 3:01 PM, Jonathan Schleifer
> <js-xmpp-standards at webkeks.org> wrote:
>> Just a reason NOT to require a PW for the owner: Some admin might have
>> changed it and now the owner can't join the room anymore or change it back.
>>
> 
> That same admin could simply remove the owner from the owner list and be done :)
> 
> This single issue aside however, I do think that the total lack of any
> way to track which services a JID is affiliated with is scary. This
> affects transports/gateways, MUCs, etc. Are roster subscriptions even
> cancelled on account removal?

Thats an very interesting point - in many respects. 
Two more examples:
- I have a service with many users from other servers subscribed.
  As there is no unsubscribe if the user has been deleted, I have many 
  "zombie"-subscription. I can only check the subscriptions from my own 
  server if the accounts still exist. And even that is not so easy.
- A friend subscribed my presence. He was some time in hospital, so I never 
  noticed, that his account was deleted on the server (due to inactivity?).
  As the jid came back online I wrote him gladly, how he is after the 
  surgery...   I realised very late, that the account was now new assigned.

I see only the solution, that there has to be an unsubscribe-request to 
every contact in the roster of an user if that user is going to be deleted.

> 
> The hardest case to cover is that of a server going down, and coming
> back up with an empty user database. It is a flaw in our otherwise
> secure identity. 

Thats a special problem, as the mentioned solution would no be effective in 
that case.
The only idea I have for this would be, that the server sends an 
unsubscribe-request or an "user-does-not-exist" message if it get something 
for an account that does not exist.
But I fear, that this could be used for finding out which jid exist (e.g. to 
use that information for spamming) or - even worse - for a DDOS-attack.

> Perhaps it isn't seen as worth solving though? (I
> have seen little discussion of this problem to date)

Thanks for pointing out that issue. Here we go. Any concepts?

> 
> Matthew.

/MiGri