<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Saint-Andre wrote:
<blockquote cite="mid43ECDB0E.2010106@jabber.org" type="cite">
  <pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<a class="moz-txt-link-abbreviated"
 href="mailto:dirk.griffioen@voipster.com">dirk.griffioen@voipster.com</a> wrote:

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">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
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
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.
  </pre>
</blockquote>
Sorry, I have been away for the weekend to friends in England - only to
return today.<br>
<blockquote cite="mid43ECDB0E.2010106@jabber.org" type="cite">
  <pre wrap="">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?
  </pre>
</blockquote>
I'd like to quote Max here:<br>
<br>
<pre wrap="">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 :)) )?</pre>
<br>
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.<br>
<blockquote cite="mid43ECDB0E.2010106@jabber.org" type="cite">
  <pre wrap="">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?
  </pre>
</blockquote>
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. <br>
<br>
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:<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
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.<br>
<blockquote cite="mid43ECDB0E.2010106@jabber.org" type="cite">
  <pre wrap="">3. Mixing of XMPP and SIP identifiers. The Zoep spec right now has
things like <sip:user@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?).

  </pre>
</blockquote>
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.<br>
<br>
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).<br>
<br>
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. <br>
<br>
<br>
<blockquote cite="mid43ECDB0E.2010106@jabber.org" type="cite">
  <pre wrap="">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.
  </pre>
</blockquote>
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 ...<br>
<blockquote cite="mid43ECDB0E.2010106@jabber.org" type="cite">
  <pre wrap="">******

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.)

  </pre>
</blockquote>
I will get you these - asap.<br>
<br>
Dirk<br>
<blockquote cite="mid43ECDB0E.2010106@jabber.org" type="cite">
  <pre wrap="">Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext"
 href="http://enigmail.mozdev.org">http://enigmail.mozdev.org</a>

iD8DBQFD7NsONF1RSzyt3NURAql9AJ9Wzf0XO9WrwdZ7diWzytFzPpVOtACg0x0t
PX+0psVDIY6aJkjXzR+MKgQ=
=B593
-----END PGP SIGNATURE-----
  </pre>
</blockquote>
<br>
</body>
</html>