Hi Dirk
Dirk Meyer wrote:
Pavel Simerda wrote:
On Sat, 23 Aug 2008 16:23:28 +0200
Dirk Meyer <[EMAIL PROTECTED]> 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.
That's sort of funny given that the OpenID designers came up with their
new protocol just to avoid depending on federations as they were
required to get SAML to work. Now, you essentially have something
similar....
Btw, for SIP we have been working on an extension for SAML:
http://tools.ietf.org/html/draft-ietf-sip-saml-04
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.
http://www.xmpp.org/extensions/xep-0235.html
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. Since it is
based on HTTP attackers found a way to open ports on your
router.
There are indeed a couple of issues. Because of these security issues
manufacturers often ship their devices with UPnP turned off.
Besides that, I do not like the idea that every app can open
ports.
With ICE every application can open ports as well...
There is nothing special about ICE in that sense since the NAT (or
firewall) just treats it like a data packet.
Ciao
Hannes
Dirk
