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

Gonzalo Camarillo <> Tue, 07 May 2013 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23D2321F8E9A; Tue, 7 May 2013 04:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rFscTgM7X3RX; Tue, 7 May 2013 04:02:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3BCDA21F8733; Tue, 7 May 2013 04:02:38 -0700 (PDT)
X-AuditID: c1b4fb25-b7f396d000007d06-94-5188df4da9ac
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 36.67.32006.D4FD8815; Tue, 7 May 2013 13:02:37 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 7 May 2013 13:02:36 +0200
Message-ID: <>
Date: Tue, 07 May 2013 14:02:35 +0300
From: Gonzalo Camarillo <>
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 <>
References: <>
In-Reply-To: <>
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=
Subject: Re: [secdir] secdir review of draft-ietf-mmusic-sdp-cs-17
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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



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