[Standards] MUC Spam and MUC invites

Peter Saint-Andre stpeter at stpeter.im
Wed Sep 5 23:27:33 UTC 2007

Alex Mauer wrote:
> Dave Cridland wrote:
>> Ah, that's a plan. Pawn ticket technologies have been deployed in
>> Lemonade's forward without download stuff, so there's some prior art we
>> can draw on. Take a look at the URLAUTH RFC, erm, RFC 4467.
>> 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)
> 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.
> your way:
> inviter -> muc:     What token should I use?
> muc -> invitee:     Here's the token
> inviter -> invitee: invite, here's the token
> invitee-> muc:      I'm joining, here's the token.
> muc -> invitee:     OK, you're joined.

One benefit of Dave's way is that it meshes with the original reason for
invites to go through the room (e.g., permissions check to determine
that the invitor is allowed to send invitations, room adds invitee to
the member list if the room is members-only). So I'd prefer Dave's
approach. But I haven't had a chance to look at RFC 4467 yet...


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070905/2d85b2b8/attachment.bin>

More information about the Standards mailing list