[secdir] Secdir review of draft-ietf-mmusic-sdp-miscellaneous-caps-05

Catherine Meadows <catherine.meadows@nrl.navy.mil> Thu, 30 May 2013 20:58 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
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 5F73F21F8EDF; Thu, 30 May 2013 13:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 iVL2UHn4cZiZ; Thu, 30 May 2013 13:58:36 -0700 (PDT)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id EA4FB21F8F0E; Thu, 30 May 2013 13:58:35 -0700 (PDT)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.14.4/8.13.6) with ESMTP id r4UKwYwN031450; Thu, 30 May 2013 16:58:34 -0400
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id r4UKwOoP027509; Thu, 30 May 2013 16:58:24 -0400 (EDT)
Received: from ashurbanipal.fw5540.net ([10.0.3.109]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2013053016582422316 ; Thu, 30 May 2013 16:58:24 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E29C7D43-7A2D-467E-99F4-D0F93BBD286A"
Date: Thu, 30 May 2013 16:58:24 -0400
Message-Id: <C809039F-341E-478C-BFD2-11FF553D58A6@nrl.navy.mil>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-mmusic-sdp-miscellaneous-caps.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Subject: [secdir] Secdir review of draft-ietf-mmusic-sdp-miscellaneous-caps-05
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: Thu, 30 May 2013 20:58:41 -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 ID defines three new capabilities that can be negotiated in the Session Description Protocols (SDP) using the SDP offer/answer
procedure.  These are bandwidth capability (proposed bandwidth to be used by session or media), connection capability (network type, address
type, and address), and title capability (human-readable textual information about the session).

None of these are directly security-related, although the authors point out that an attacker who
is able to modify traffic could modify the bandwidth value so that then network winds up being under-utilized
or over-utilized.  They recommend using on of the security mechanisms recommended in RFC5939 (which defines SDP capability negotiation
in general) in case
it is necessary to protect the bandwidth value.  

I think this is a very appropriate recommendation for this ID, but perhaps the authors should consider offering similar recommendations
for the other capabilities.  For example, in the connection capability it is possible to offer an address together with a number of alternatives.
What happens if an attacker removes some or most of the addresses?  Could this lead to overuse of the remaining addresses?  Likewise, one of the reasons the human-readable
title capability is provided is so that a human can make choices about which media configurations to choose.  If the attacker tampers with a label so that the human is caused to make wrong choices, this could again
cause problems.  I think it could be worthwhile to point out that there may be cases for both connection and title capabilities where adversarial tampering could have harmful effects,
and if this is the case the security mechanisms in RFC5939 should be applied as well. 


Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil