Subject:	SecDir review of draft-ietf-sipcore-sip-websocket-08
Resent-Date:	Wed, 10 Apr 2013 16:19:04 -0500 (CDT)
Resent-From:	draft-alias-bounces@tools.ietf.org
Resent-To:	adam@nostrum.com, ibc@aliax.net, jmillan@aliax.net, pkyzivat@alum.mit.edu, rlb@ipv.sx, vpascual@acmepacket.com
Date:	Thu, 11 Apr 2013 00:18:46 +0300
From:	Yaron Sheffer <yaronf.ietf@gmail.com>
To:	IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-sipcore-sip-websocket.all@tools.ietf.org

Subject:

SecDir review of draft-ietf-sipcore-sip-websocket-08

Resent-Date:

Wed, 10 Apr 2013 16:19:04 -0500 (CDT)

Resent-From:

draft-alias-bounces@tools.ietf.org

Resent-To:

adam@nostrum.com, ibc@aliax.net, jmillan@aliax.net, pkyzivat@alum.mit.edu, rlb@ipv.sx, vpascual@acmepacket.com

Date:

Thu, 11 Apr 2013 00:18:46 +0300

From:

Yaron Sheffer <yaronf.ietf@gmail.com>

To:

IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-sipcore-sip-websocket.all@tools.ietf.org

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines how SIP can be layered on the WebSocket protocol. This is essentially a profile of SIP. Summary In my opinion, from a security perspective this document is not yet ready for publication. I expect this document to be widely implemented, and I would not want it implemented until it offers a solid security model, even if it is optional. Details RFC 3261 has 20 pages of security considerations, and defines several security mechanisms. The current document "only" defines a transport for SIP, but such transport needs to preserve the security of any SIP mechanisms being used. In particular, it should be clear how endpoint identities are determined at each layer and how identities at different layers relate to one another. In other words, what's known as "channel binding". The only security-related section (other than the Security Considerations) is Authentication (Sec. 7), and this section is marked non-normative. So the reader is left to wonder: how is the SIP client authenticated? How does this authentication relate to the WebSocket-level client authentication? And similarly for the server. Sec. 9.1 mentions (again, non-normatively) that SIP-level certificate checks are omitted, and replaced by transport-level checks only. I believe this significantly reduces the security properties of SIP. Moreover, it begs for a policy tying WebSocket certificates to identities of the endpoints of the SIP protocol. Nit/bug: Sec. 5.2.1 ends with a colon in the HTML version *only*, and is missing a paragraph. Thanks, Yaron

Dear Experts,

&= nbsp; I am having a following case, where the REGISTER request= To header URI and the Contact URI are same. Pls see the message below.

REG= ISTER sip:10.232.15.206:5070 SIP/2.0

= To: <sip:1001@10.232.15.206>

Vi= a: SIP/2.0/TCP 10.232.122.70;branch=3Dz9hG4bK-6928-1-0

From: <sip:1001@10.232.15.206>;tag=3D123451001

Call-ID: 1-6928@10.232.122.70

Max-Forwards: 70

supported: gru= u,path,outbound

require: gruu

Contact: = <sip:1001@10.232.15.206;deviceName=3Ddevice1>;+sip.instance=3D"<ur= n:uuid:f81d4fae-7dec-11d0-a765-00a0c9e6bf6>"

Content-Length: 0
=

RFC 5627 says,

The contact URI MUST NOT be equivalent, based on

the URI equality rules in RFC= 3261 [1], to the AOR in the To header

field. 3261 [1]) t= o the AOR, the registrar MUST reject the request with a

403, since this would cause a = routing loop.

From RFC 3261, URI equality rules say,

URI uri-parameter components are compared as follows:

-= Any uri-parameter appearing in both URIs must match.

&n= bsp; - A user, ttl, or method uri-paramete= r appearing in only one

URI never matches, eve= n if it contains the default value.

&n= bsp; - A URI that includes an maddr parameter will not m= atch a URI

&n= bsp; that contains no maddr parameter.

- All other u= ri-parameters appearing in only one URI are

= ; ignored when comparing the URIs.

URI = header components are never ignored. Any present header

= ; component MUST be present in both URIs and match for the URIs

&= nbsp;to match. The matching rules are defined for each header field

&nbs= p; in Section 20.

Now, while checking To and Contac= t URIs for equality, we can ignore the uncommon URI parameters in the Conta= ct URI(here it is deviceName). But do we need to consider the Contact "head= er" parameters(here in above message +sip.instance param) also while compar= ing the URIs in To and Contact to decide that they are equal and reject the= request with 403 as it would cause loop during lookup ? Getting this doubt= bcos RFC 3261 says "URI header components are never ignored". What is an U= RI header component ? Does it apply to Contact header parameter in this cas= e ?

In this = case, is the above REGISTER request to be rejected with 403 or not ?

<= div style=3D"color: rgb(0, 0, 0); font-family: 'times new roman', 'new york= ', times, serif; font-size: 16px; font-style: normal;">regards

+Santhana

--1466435115-244288905-1366891827=:70197-- From worley@shell01.TheWorld.com Thu Apr 25 10:26:08 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9E921F962B for ; Thu, 25 Apr 2013 10:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3THIXLSMgN2 for ; Thu, 25 Apr 2013 10:26:07 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7D27E21F95FB for ; Thu, 25 Apr 2013 10:26:04 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r3PHPaE9020445; Thu, 25 Apr 2013 13:25:39 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3PHPZqs3412338; Thu, 25 Apr 2013 13:25:35 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PHPZRi3425255; Thu, 25 Apr 2013 13:25:35 -0400 (EDT) Date: Thu, 25 Apr 2013 13:25:35 -0400 (EDT) Message-Id: <201304251725.r3PHPZRi3425255@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Santhana Krishnan In-reply-to: <1366891827.70197.YahooMailNeo@web160403.mail.bf1.yahoo.com> (yskrishnan@yahoo.com) References: <1366891827.70197.YahooMailNeo@web160403.mail.bf1.yahoo.com> Cc: sipcore@ietf.org Subject: Re: [sipcore] REGISTER AOR Loop Scenario. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 17:26:08 -0000 > From: Santhana Krishnan > To: > Contact: ;+sip.instance="" > Now, while checking To and Contact URIs for equality, we can ignore > the uncommon URI parameters in the Contact URI(here it is > deviceName). But do we need to consider the Contact "header" > parameters(here in above message +sip.instance param) also while > comparing the URIs in To and Contact to decide that they are equal > and reject the request with 403 as it would cause loop during lookup > ? Getting this doubt bcos RFC 3261 says "URI header components are > never ignored". What is an URI header component ? Does it apply to > Contact header parameter in this case ? The "URI" in the To header is "sip:1001@10.232.15.206". The "URI" in the Contact header is "sip:1001@10.232.15.206;deviceName=device1". The "+sip.instance=..." part is *not* part of the URI, it is a "contact-param" -- see the grammar rule "Contact" in section 25.1 of RFC 3261. These sort of parameters attached to URIs in the values of header fields are often called "field parameters" because they have the same syntax in many different header fields, although the grammar in 25.1 uses different non-terminal names depending on which header field they appear in. The "URI header components" referred to in section 19.1.4 refers to the nonterminal "headers" in section 25.1, that is, constructs like "?Subject=foo" in the URI "sip:user@host?Subject=foo". Dale From hammondjohnson@hushmail.com Sat Apr 27 14:06:57 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D1121F992F for ; Sat, 27 Apr 2013 14:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC78sVP4om9S for ; Sat, 27 Apr 2013 14:06:57 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBEE21F9916 for ; Sat, 27 Apr 2013 14:06:54 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 0F338580B2 for ; Sat, 27 Apr 2013 17:49:01 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:49:00 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id C72FBE6739; Sat, 27 Apr 2013 17:49:00 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:49:00 -0400 To: sipcore@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174900.C72FBE6739@smtp.hushmail.com> Subject: [sipcore] Biggest Fake Conference in Computer Science X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:06:57 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.