[Standards-JIG] Jingle vs. Zoep

Peter Saint-Andre stpeter at jabber.org
Fri Feb 10 18:27:26 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dirk.griffioen at voipster.com wrote:

>> And I feel that is the discussion sofar, there has been some good points
>> on either case - what then is the route? Are they collected and
>> summarized, upon which a decision is based? This would be a good thing

Back when the JEP Editor (me) decided which JEPs to accept, I was
completely liberal about accepting proposals because I'm of the "let a
thousand flowers bloom" philosophy. But we added more process a while
back and now the Jabber Council decides which proposals to accept. If it
were up to me I'd probably just say accept the proposal as a JEP, we can
discuss it more, and may the best protocol win.

That said, I find it a bit frustrating that you have not yet provided
substantive answers to my questions about authenticated identities,
validated from addresses, the relationship between XMPP identifiers and
SIP identifiers, and content validation. To me, these are major security
issues.

I'll repost the questions here (with updates so that my concerns are clear):

******

1. Authenticated identities. XMPP has them, SIP doesn't. My
understanding from SIP security gurus is that authentication is OPTIONAL
in SIP (since it was originally envisioned as a peer-to-peer system, and
has only more recently been shoehorned into a client-server architecture
in which clients auth with servers). There are major security concerns
here with allowing unauthenticated entities onto the network. How does
Zoep deal with that?

2. Validated from addresses. XMPP has them, SIP doesn't. You can't trust
the from addresses in SIP, which leads to security problems with
unauthorized call transfers, deregistrations, etc. How does Zoep deal
with that?

3. Mixing of XMPP and SIP identifiers. The Zoep spec right now has
things like <sip:user at host/resource>. What is that? It doesn't look like
a SIP identifier to me, it looks like an XMPP identifier. (Though the
SIP URI scheme is so complicated that even SIP gurus cannot easily tell
whether a SIP URI is valid or not). There are also issues of
internationalization here (SIP identifiers are US-ASCII only, how are
our friends in East Asia going to handle that?). In Zoep, what is the
relationship is between XMPP identifiers and (asserted) SIP identifiers?
How does anyone know that the SIP identifiers in the Zoep payload have
anything to do with the XMPP identifiers on the stanzas? Do you just
pass along the SIP stuff without doing any kind of validation or
associating the SIP identifier with the XMPP identifier? Since SIP has
many of the same problems as email in this regard (see #1 and #2 above),
encapsulating raw SIP in an XMPP wrapper strikes me as similar to
sending email over XMPP (just encapsulate your email in an XMPP wrapper
and you get the best of both worlds! but how do we know that the email
address in the encapsulated From: header bears any relation to the
'from' attribute of the XMPP stanza?).

4. Content validation. Some very significant adopters of XMPP like the
technology because it is pure XML and they can validate all the XML that
flows across the wire using standard XML tools. It is much more
difficult to parse SIP as it goes over the wire (yes, there are
SIP-specific firewall products, but they are specialized and expensive).
So if we send SIP over XMPP, it is quite likely that these adopters will
not use it.

******

There is also:

5. Use cases. What are the use cases for Zoep? (I agree we need to
clearly define the use cases for Jingle as well, but it would be helpful
to define them for Zoep so that we can compare the two in a productive
fashion.)

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD7NsONF1RSzyt3NURAql9AJ9Wzf0XO9WrwdZ7diWzytFzPpVOtACg0x0t
PX+0psVDIY6aJkjXzR+MKgQ=
=B593
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060210/4486b899/attachment.bin>


More information about the Standards mailing list