Re: [secdir] secdir review of draft-ietf-mmusic-sdp-cs-17

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Tue, 07 May 2013 11:02 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D2321F8E9A; Tue, 7 May 2013 04:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 rFscTgM7X3RX; Tue, 7 May 2013 04:02:39 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCDA21F8733; Tue, 7 May 2013 04:02:38 -0700 (PDT)
X-AuditID: c1b4fb25-b7f396d000007d06-94-5188df4da9ac
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 36.67.32006.D4FD8815; Tue, 7 May 2013 13:02:37 +0200 (CEST)
Received: from [131.160.126.23] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 7 May 2013 13:02:36 +0200
Message-ID: <5188DF4B.1030402@ericsson.com>
Date: Tue, 7 May 2013 14:02:35 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Samuel Weiler <weiler@watson.org>
References: <alpine.BSF.2.00.1302011241020.47827@fledge.watson.org>
In-Reply-To: <alpine.BSF.2.00.1302011241020.47827@fledge.watson.org>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvra7v/Y5Ag53nBCw2rv3MZDHjz0Rm i2cb57NYfFj4kMWi/etzNgdWjyVLfjJ5fLn8mc1jacNu9gDmKC6blNSczLLUIn27BK6MU68e MRZMEat4PWMjewPjA8EuRk4OCQETif4JLxkhbDGJC/fWs3UxcnEICZxilPh4tZ8JwlnNKLH/ 5SMWkCpeAW2JZQ9mAdkcHCwCKhJP2t1BwmwCFhJbbt0HKxEViJL493Y3I0S5oMTJmU/A4iIC qhIX/n9nBbGZBWIldkz/zwRiCwtYSjyYeA5spJCAs8SV+wkgJqeAi0TPMn2I0yQlFk3rZIHo 1JOYcrWFEcKWl9j+dg4ziC0EdNjyZy0sExiFZiFZPAtJyywkLQsYmVcxsucmZuaklxttYgSG 88Etv1V3MN45J3KIUZqDRUmcN5mrMVBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo1d8r4+r 09PI9Rf0pR43bLUpjW8otpj+O1be5sQW7Y3brabu5IxM6v9uq1DJaB2ls9cy422fji2PyLTm HxuYVnq5v745Sbdbp7pMb/bv2M+JBlON/swXcwjVkv7p+t/ud2iuNneYs9mZEM5SHuE7W9Iz Zt7LL2prmWfz/+68Kbpb/9lFykUpsRRnJBpqMRcVJwIAahmkXTUCAAA=
Cc: ietf@ietf.org, iesg@ietf.org, draft-ietf-mmusic-sdp-cs@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-mmusic-sdp-cs-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2013 11:02:44 -0000

Hi Samuel,

the authors of this draft have reviewed it in order to address your
comments:

http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-18

Could you please have a look at this revision and let them know whether
you are happy with it?

Thanks,

Gonzalo


On 04/02/2013 9:08 PM, Samuel Weiler wrote:
> 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 allows SIP endpoints to negotiate the use of a
> circuit-switched (e.g. PSTN) channel.  It presents a mechanism for
> correlating an incoming circuit-switched connection with a given SDP/SIP
> session by sending a nonce or a static string.
> 
> Summary: I would like to see a stronger authentication mechanism
> defined to replace the static string or "plaintext password" nonce.
> 
> I am content with the analysis of security weaknesses: an attacker
> could trick someone into initiating a potentially expensive PSTN call,
> and the correlation mechanism is weak.
> 
> I am not content with the use of a mere nonce or static string for
> correlation.  That is the equivalent of sending plaintext passwords, and
> I suspect we have better mechanisms available that could allow for
> mutual endpoint authentication, making it statistically unlikely for a
> man-in-the-middle to participate successfully in the correlation
> exchange.  The document makes a case for using short strings/nonces
> (e.g. a caller-ID string or 10 DTFM digits).  I suspect both that those
> lengths could be extended without great pain and that some stronger
> authentication mechanisms could work with such short strings, especially
> given the ability to send longer keying material in the packet-switched
> SDP session.
> 
> Non-security observation: I'm worried that the architecture of the
> current correlation mechanism will have some unintended consequences.
>> From section 5.2.3:
> 
>    The endpoints should be able to correlate the circuit-switched bearer
>    with the session negotiated with SDP in order to avoid ringing for an
>    incoming circuit-switched bearer that is related to the session
>    controlled with SDP (and SIP).
> 
> As I understand it, some of the defined variants of the correlation
> scheme require answering the call (e.g. the DTMF scheme) before
> knowing whether or not the channel corresponds to a SIP session.  If
> it does not, then what?  The call is already answered, which gives a
> surprising user experience.  Feel free to tell me I'm off base with
> this one.
> 
> -- Sam
> 
>