[Security] client-to-client security :: Summary and todo's
pavlix at pavlix.net
Sat Aug 23 11:47:06 CDT 2008
On Sat, 23 Aug 2008 18:21:38 +0200
Dirk Meyer <dmeyer at tzi.de> wrote:
> Pavel Simerda wrote:
> > On Sat, 23 Aug 2008 16:23:28 +0200
> > Dirk Meyer <dmeyer at tzi.de> wrote:
> >> Pedro Melo wrote:
> >> > Hi,
> >> >
> >> > On Aug 23, 2008, at 2:12 PM, Dirk Meyer wrote:
> >> >> IMHO OAuth is kind of stupid. I have to trust a server I do not
> >> >> know. No, the point is that I can upload a certificate to my
> >> >> XMPP server and the owner of that certificate (a bot, a client
> >> >> I do not trust) can log in using SASL-EXTERNAL as me without
> >> >> having the password.
> >> >
> >> > OAuth is not stupid. The server you do not trust is your own XMPP
> >> > server. If you don't trust that, well, what are you doing
> >> > connected to him?
> >> Oops, sorry, I messed up OAuth and OpenID. My fault, ignore me.
> > Neither OpenID seems stupid to me. "Stupid" is a word that only
> > means you didn't bother to find more information. When one knows
> > what's going on, he might use "insuitable for oure purpose
> > because...".
> OK, "stupid" is a bad word. Maybe: good good idea lost. The propblem
> is that OpenID provider do not trust each other (except for blogs
> maybe). E.g. every Yahoo id is an OpenID ... great. But I need a Yahoo
> id to log on into flickr because they do not trust my OpenID
> server. We also plan to install OpenID here at the university for some
> stuff but you must have an OpenID from the university because we do
> not trust Yahoo. So instead to have one OpenID (good idea) you have
> several (good idea lost). But that is my opinion.
1) I only use one and that is "pavlix.net"
It is delegated to http://xmppid.net/pavlix[AT]pavlix.net ([AT] = @),
that is verified through Jabber and that's it.
2) If a service requires a particular OpenID provieder for
authentication, it's their problem, it doesn't fit the main OpenID use
This is not a drawback of OpenID but it is a use of OpenID for private
This would be like saying that Jabber is bad because we don't trust
jabberfr.org and we won't talk to them unless they are given JIDs from
If you don't trust decentralized URL-based authentication, this is
OpenID's fault but your security policy.
> >> > I can ask my XMPP server for a opaque token that I provide to my
> >> > bot and he can use that to authenticate.
> >> >
> >> > Having said that, I also like your "upload-certificate" idea.
> >> Combine OAuth with SASL for server login .... nice one. Use your
> >> XMPP connection to generate a token and give that to the new
> >> not-so-trusted client and it can log in with it. The client gives
> >> away its certificate for future logins.
> > Isn't OAuth HTTP? Does it bring anything useful enough for XMPP
> > instead of a need to use HTTP besides? Correct me if I'm wrong.
> >> Direct should be possible if only one is behind a NAT or a
> >> firewall. If both are you need the help of a TURN server. Well,
> >> there is STUNT (STUN over TCP) but IMHO this is a bad hack and it
> >> won't work with all router. You could also add UPnP IGD to open a
> >> port on your router, or the similar method apple used (I can not
> >> remember the name right now, it is an IETF draft) or you can put a
> >> TURN server on your router.
> > Erm, there are many possibilities to start a session between two
> > clients behind a NAT. Why do we have Jingle-ICE if not for sending
> > data over NATs? UPNP is a good choice when users have access to
> > router administration (home use).
> UPnP is a working choice, but bad. Just google for it.
I know what UPnP is.
> Since it is
> based on HTTP attackers found a way to open ports on your
Please be more precise, this is not a useful piece of information at
> Besides that, I do not like the idea that every app can open
This is how TCP/IP works. Any application may open a socket and talk to
Jabber won't work if a jabber client can't open a socket.
Again, please be more precise so others understand what security issues
you actually mean.
Jabber & Mail: pavlix(at)pavlix.net
More information about the Security