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

Samuel Weiler <weiler@watson.org> Mon, 04 February 2013 19:08 UTC

Return-Path: <weiler@watson.org>
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 B364F21F86E3; Mon, 4 Feb 2013 11:08:20 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTGH+Hv+6IiZ; Mon, 4 Feb 2013 11:08:20 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC1421F86D6; Mon, 4 Feb 2013 11:08:19 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id r14J8JaK079199; Mon, 4 Feb 2013 14:08:19 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id r14J8ICg079194; Mon, 4 Feb 2013 14:08:18 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Mon, 4 Feb 2013 14:08:18 -0500 (EST)
From: Samuel Weiler <weiler@watson.org>
To: secdir@ietf.org, iesg@ietf.org, ietf@ietf.org, draft-ietf-mmusic-sdp-cs-17.all@tools.ietf.org
Message-ID: <alpine.BSF.2.00.1302011241020.47827@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 04 Feb 2013 14:08:19 -0500 (EST)
Subject: [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: Mon, 04 Feb 2013 19:08:20 -0000

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