Re: [secdir] secdir review of draft-ietf-avt-rtp-h264-rcdo-07
Patrick Luthi <patrick.luthi@tandberg.com> Fri, 05 November 2010 18:29 UTC
Return-Path: <patrick.luthi@tandberg.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8CC3A691C; Fri, 5 Nov 2010 11:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEgeMcf-Nt56; Fri, 5 Nov 2010 11:29:47 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3E11E3A6919; Fri, 5 Nov 2010 11:29:47 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAOHp00ytJV2a/2dsb2JhbACGRpsncaBjmz6FSASNZg
X-IronPort-AV: E=Sophos;i="4.58,304,1286150400"; d="scan'208";a="179040381"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 05 Nov 2010 18:29:59 +0000
Received: from OSLEXCP11.eu.tandberg.int ([173.38.136.5]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oA5ITwJk030849; Fri, 5 Nov 2010 18:29:58 GMT
Received: from oslexcp2.eu.tandberg.int ([10.47.136.30]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Nov 2010 19:29:58 +0100
Received: from Suisse129.tandberg.com ([128.107.141.242]) by oslexcp2.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Nov 2010 19:29:56 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 05 Nov 2010 19:23:43 +0100
To: Tom Kristensen <tom.kristensen@tandberg.com>, "Scott G. Kelly" <scott@hyperthought.com>
From: Patrick Luthi <patrick.luthi@tandberg.com>
In-Reply-To: <4CD3FCA4.70401@tandberg.com>
References: <1288888292.35265529@192.168.2.228> <4CD3FCA4.70401@tandberg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID: <OSLEXCP2XvpFVjCRGry00000012@oslexcp2.eu.tandberg.int>
X-OriginalArrivalTime: 05 Nov 2010 18:29:56.0953 (UTC) FILETIME=[72899490:01CB7D17]
X-Mailman-Approved-At: Sat, 06 Nov 2010 17:57:25 -0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-avt-rtp-h264-rcdo.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-h264-rcdo-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 05 Nov 2010 18:29:48 -0000
Tom, Your proposed text sounds good to me! Regards, Patrick At 13:46 05/11/2010, Tom Kristensen wrote: >On 11/04/2010 05:31 PM, Scott G. Kelly 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 draft describes a new RTP payload format, extending existing >>RTP capabilities. Based on my limited understanding of RTP, this >>introduces no new security considerations. >> >>The security considerations section starts off by saying this, but >>then goes on to talk about various security properties that could >>be added by various means. I found the text to be a little >>confusing, especially when it makes recommendations without >>detailing any particular threats. > >I can understand this conclusion. A simplification makes sense as >the recommendations given here is described better within a security >context in the RTP RFC and associated specifications. However, I'd >like to keep the reference to the H.264 security considerations, >with its codec specific details. My proposed text for the security >considerations at bottom. > >>I would suggest simplifying the security considerations. Here is >>the current text: >> >> "RTP packets using the payload format defined in this specification >> are subject to the security considerations discussed in the RTP >> specification [6], and in any applicable RTP profile. The main >> security considerations for the RTP packet carrying the RTP payload >> format defined within this document are confidentiality, integrity >> and source authenticity. Confidentiality is achieved by encryption >> of the RTP payload. Integrity of the RTP packets through suitable >> cryptographic integrity protection mechanism. Cryptographic system >> may also allow the authentication of the source of the payload. A >> suitable security mechanism for this RTP payload format should >> provide confidentiality, integrity protection and at least source >> authentication capable of determining if an RTP packet is from a >> member of the RTP session or not. >> >> Note that the appropriate mechanism to provide security to RTP and >> payloads following this document may vary. It is dependent on the >> application, the transport, and the signalling protocol employed. >> Therefore a single mechanism is not sufficient. Usage of data origin >> authentication and data integrity protection of at least the RTP >> packet is RECOMMENDED, for example by use of the Secure Real-time >> Transport Protocol (SRTP) [12]. Other mechanisms that may be used >> are IPsec [13] and Transport Layer Security (TLS) [14] (RTP over >> TCP), but other alternatives may exist. >> >> Refer also to section 9 of RFC YYYY [3], as no reasons for separate >> considerations are introduced in this document." >> >> >>I would suggest the following simplified text: >> >> "RTP packets using the payload format defined in this specification >> are subject to the security considerations discussed in the RTP >> specification [6], and in any applicable RTP profile. No additional >> security considerations are introduced by this specification." >> >>(or something like this). > >I would like to keep the reference to the security considerations >section of RFC YYYY/RFC3984bis in, as specific H.264 threats and >recommendations are included there. Cf.: >http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-12#section-9 > >So, something like this should be fine: > > "RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification [6], and in any applicable RTP profile. Refer also > to section 9 of RFC YYYY [3]. No additional security > considerations are introduced by this specification." > >As a side note. One might consider altering the "template security >considerations" section in the "How to Write an RTP Payload Format" >draft according to the preferred security directorate/IESG policy >for the RTP payload format specifications later on. Cf.: >http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06#appendix-A.13 > >-- Tom
- [secdir] secdir review of draft-ietf-avt-rtp-h264… Scott G. Kelly
- Re: [secdir] secdir review of draft-ietf-avt-rtp-… Tom Kristensen
- Re: [secdir] secdir review of draft-ietf-avt-rtp-… Patrick Luthi