[Standards-JIG] Jingle vs. Zoep
jean-louis.seguineau at laposte.net
Fri Feb 10 21:41:22 UTC 2006
These are very legitimate questions. And we need answers to allow a fair
assessment of these two technologies. I agree with Peter that in many cases,
the tunneling of un-trusted data through XMPP is to be avoided.
I would only like to reformulate points 1 and 2 in order for the Zoep team
to be in position to properly sustain their ground.
1/ SIP include a single authentication mechanism based on HTTP digest (which
is also the basis of the SASL Digest-MD5 required by XMPP) It is true that
authentication is not a MUST is the RFC, but I haven't come across any
service provider that does not require authentication. Due to its
peer-to-peer origin, authentication can be carried out at a request level,
meaning that certain request may or may not require authentication. Once
authenticated, all requests in the same dialog will have to prove previous
authentication to be allowed.
SIP also provides ways for the various proxies on the path of a call
establishment to require authentication at the request level. In the same
way as the end to end authentication, all requests flowing through the same
proxies will have to ascertain their previous authentication.
If we reformulate Peter's question, how does Zoep ensure a proper SIP level
end to end authentication? On which requests would this authentication
apply? How does Zoep reconcile the SIP authentication with the XMPP
2/ The SIP digest authentication include the possibility to specify a
'quality of protection' (qop) such as to ensure that the content of the
request is not modified. This is on way to re-enforce the trust associated
with the request addresses.
Reformulating the second question, how does Zoep apply qop on the SIP
requests? How does Zoep reconcile the SIP qop with the XMPP authorization?
Does Zoep implements the principles of SIP asserted identity extensions? How
deos Zoep ensure the proxy path on the SIP side (i.e ensure the requests in
a dialog always come from the same source through the same way)
I believe that if we cannot get an adequate position on these preliminary
topics, it would be difficult considering moving to the much more
interesting question of address handle relationship.
P.S. Using SASL ANONYMOUS in XMPP is not safer than doing un-authenticated
SIP. That said, the so called security gurus should have said that even if
SIP provides authentication mechanisms, it is definitively easier to ensure
a good level of confidence with XMPP.
Date: Fri, 10 Feb 2006 11:27:26 -0700
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: Re: [Standards-JIG] Jingle vs. Zoep
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <43ECDB0E.2010106 at jabber.org>
Content-Type: text/plain; charset="iso-8859-1"
-----BEGIN PGP SIGNED MESSAGE-----
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
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
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
More information about the Standards