[Standards-JIG] Jingle vs. Zoep

dirk.griffioen@voipster.com dgriffioen at voipster.com
Mon Feb 13 23:25:29 UTC 2006


Peter Saint-Andre wrote:

>-----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.
>  
>
Sorry, I have been away for the weekend to friends in England - only to 
return today.

>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?
>  
>
I'd like to quote Max here:

I'm not very well understand reason why they are talking about
security. If it is a pure XMPP client to XMPP client connection then
it relies on XMPP security (we are not using any SIP servers there!).
If it is a connection that goes away from from XMPP network (to PSTN
for example), then it does not differs from jingle approach as it have
to use SIP anyway. Is that right? or I'm missing some very impotant
detail there (just because it is too late and my brains are off
already :)) )?


We tunnel SIP over XMPP - all authentication is done in the XMPP world 
and all it's rules apply. If connection setup passes to another realm, 
then of course it's rules hold. So I see no probleem here: XMPP is as 
secure as XMPP is, and the same, mutatis mutandis, is true for SIP.

>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?
>  
>
Validated in what sense - sorry, I think will need to read some of the 
Jeps out there to properly respond here. But once again, I think here 
too Max's remark applies.

I think that from jep-zoep it is not clear what we propose. This would 
be my concern here: we propose to use SIP in 2 cases:

- pc2pc: all issues are in the XMPP world, the SIP stack is 'dumb' and 
only used to maintain state and pass requested (and agreed) session 
options to the application. The SIP stack we have allowed for this: it 
had an abstraction for transport, so this is TCP in the pc2pstn case, 
but 'XMPP' (yes, xmml over tcp) in the pc2pc case. Another way to look 
at is is that SIP is tunneled over XMPP.

- pc2pstn: no XMPP is used (at the moment, since we do not use gateways, 
yet) and SIP is just 'SIP' - with all problems know and unknown.

The Zoep use of SIP in XMPP is on a functionality level and conceived in 
a pre-jingle era, it takes elements of both where needed to obtain a 
worable and interoperable solution for session negociation, and added to 
that not closing to certain solution or noew developments.

>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?).
>
>  
>
This is true: we took the addressing as 'sip:*' - meaning the line 
'sip:' followed by whatever. I don't know if this is valid SIP, but at 
least to me, this was not very important: for pc2pc routing is done by 
XMPP anyway, with pc2pstn we send the 'raw' SIP message to a service 
provider.

Your email analogy would be correct. As for the addressing, I know there 
is a relation because I put there - but seriously: with pc2pc we could 
have made all the usernames 'zoep' (since SIP demands a name; and XMPP 
was handling routing), but we felt more comfortable dong the same in 
alike cases, even if this lead to redundancy. In either case, the SIP 
message has the proper names, even if they are not used for routing (pc2pc).

However, with pc2pc the relation can be easily enforced. With pc2pstn, 
the very nature is that the 2 differ: the JID would be the gateways one 
wehere the SIP uri is the addressee in the SIP world.


>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.
>  
>
How about  other  'plain' payloads: jabber-xmlrpc could be conceived to 
carry malicious payloads, or are they validated too? The real issue then 
would be 'what do I trust'? Which for a general case is difficult to 
answer ...

>******
>
>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.)
>
>  
>
I will get you these - asap.

Dirk

>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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060214/da1aadc3/attachment.html>


More information about the Standards mailing list