[Standards] MUC Spam and MUC invites

Dave Cridland dave at cridland.net
Thu Sep 6 07:53:03 UTC 2007


On Wed Sep  5 23:45:10 2007, Alex Mauer wrote:
> Dave Cridland wrote:
> > That model would have the room supply the token for the use of the
> > invitee, so there's an additional round-trip involved, but it's  
> nicely
> > secure.
> 
> Is it insecure to have the inviter supply the token instead?  I  
> can't
> see any problems, unless the inviter's client doesn't bother to  
> generate
> a different token each time or something dumb like that. (and you  
> could
> theoretically have the same problem with the server, though I guess  
> it
> would be easier to fix)
> 
> 
It allows the server to enforce the room's security model. From the  
security perspective, then, you've only got to analyse how strong the  
token mechanism is, and since that's also controlled by the server,  
it should in principle be simpler to be agile.


> I think it works out the same , as round-trips go:
> 
> my way:
> inviter -> muc:     here's the token
> muc -> inviter:     OK, got it
> inviter -> invitee: invite, here's the token
> invitee -> muc:     I'm joining, here's the token.
> muc: -> invitee:    OK, you're joined.
> 
> 
Ah, yes, you do need an extra round-trip, since you have to know the  
MUC room has got the token. Good point.


> your way:
> inviter -> muc:     What token should I use?

Actually, "What token should I use to invite <invitee>?" If it's  
snooped on the wire, or invitee is a bad actor who passes it along,  
or whatever, then it won't work.


> muc -> invitee:     Here's the token
> inviter -> invitee: invite, here's the token
> invitee-> muc:      I'm joining, here's the token.

"Here's the token I got from <inviter>", but yes. Again, this is to  
reduce the sceop of the token.


> muc -> invitee:     OK, you're joined.

And here, the MUC can invalidate the token, potentially, but URLAUTH  
went the way of using time-limited tokens rather than single use  
tokens, since it's cheaper to implement.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list