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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
