[secdir] secdir review of draft-ietf-avt-rtp-cnames-02
Tobias Gondrom <tobias.gondrom@gondrom.org> Tue, 14 December 2010 00:39 UTC
Return-Path: <tobias.gondrom@gondrom.org>
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 DA4BD3A6D5C for <secdir@core3.amsl.com>; Mon, 13 Dec 2010 16:39:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.143
X-Spam-Level:
X-Spam-Status: No, score=-95.143 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
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 D6pGRa-jmk+1 for <secdir@core3.amsl.com>; Mon, 13 Dec 2010 16:39:25 -0800 (PST)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 8617A3A6D4F for <secdir@ietf.org>; Mon, 13 Dec 2010 16:39:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=o/NE3GvV9iW+tpVYKK1N4yMpKNMILHY1odRes70SBK81PXN68aNUCeuHcSzdDHkSXBeThHIoXaCpuz/k/a7a8qLIgVvC1X8b/MZVcO83L/26pCLdt4rsF+6SU2slFkNt; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 26279 invoked from network); 14 Dec 2010 01:40:29 +0100
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Dec 2010 01:40:29 +0100
Message-ID: <4D06BD5F.5040807@gondrom.org>
Date: Tue, 14 Dec 2010 00:42:07 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-avt-rtp-cnames.all@tools.ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: keith.drage@alcatel-lucent.com, even.roni@huawei.com, abegen@cisco.com, dwing@cisco.com, csp@csperkins.org, rjsparks@nostrum.com
Subject: [secdir] secdir review of draft-ietf-avt-rtp-cnames-02
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: Tue, 14 Dec 2010 00:39:26 -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. The Security Considerations section is ok and the draft does not add further security aspects beyond it. However there are a number of issues with the draft, including use of rfc2119 language and hash agility: 1. section 4.2 first bullet point: spelling: s/"and endpoint MUST generate and store a Universally"/"an endpoint MUST generate and store a Universally" 2. COMMENTS/DISCUSS: section 4.2: the draft makes the distinction between 4 cases: a) long-term persistent b) short-term persistent with IPv6 c) short-term persistent with IPv4 d) per-session RTCP CNAME all use MUST to specify the generated CNAME with _different_ methods. This raises a number of potential issues: 2.1. The boundary between the definition of long-term and short-term with persistence across several related RTP sessions (see 4.1) is not well defined, thus different MUST clauses for how to treat these two cases seem problematic. As it can be hard for an application to determine the difference between across several sessions and long-term. 2.2. Though I understand why a system may not want to use UUID in all four cases, it is unclear to me why it should be forbidden to use UUID for scenarios b, c and d. (which is implied by using "MUST" with the defined method). 2.3. in section 4.2. next to last paragraph it states: (other methods) "beyond the three methods listed above, are not compliant with this specification and SHOULD NOT be used." If the document is std track and updates 3550 and uses "MUST" for the methods it would be inconsistent to frame it here as "SHOULD NOT". 2.4. Question: which leads to another question: are there upgrade issues with 3550-applications with this update or is there an upgrade path for RTP from 3550 to draft-ietf-avt-rtp-cnames? 2.5. case b (IPv6): I understand that one reason for different handling of IPv4 is NAT and private address spaces. And although NAT with IPv6 should not make sense, in theory this could still happen, so I am not sure whether these two cases (b and c) can be and need to be handled differently. Overall: a solution could be that UUID be allowed for all methods (e.g. frame it as "MUST use one of the here described methods") and maybe the unification of case b (short-term IPv6) and c (short-term IPv4) - either allowing both methods for both and indicating preferred approaches with "SHOULD" for each of them (e.g. SHOULD use MAC for scenarios of possible NAT) - unless the authors can explain why we really need to mandate these two different scenarios and why IPv6 has not at least in theory NAT issues? 3. hash agility: in section 4.2 last paragraph the draft mandates for case d (per-session RTCP CNAMEs ) to use SHA1-HMAC and truncate the value to 96bit 3.1. DISCUSS: The drafts should not be tied to SHA1 and actually allow use of other algorithms (e.g. SHA2/SHA-256/-512) as well. 3.2. Question: maybe obvious, but why do you need to truncate the output to 96bit? 3.3. Clarification: it also states at the end of this paragraph that the "user@" part of the CNAME "is omitted". Does this mean "MAY be omitted on single-user systems, and MAY be replaced by an opaque token on multiuser systems" like for cases a-c or is this intentionally different and mandatory in d? Kind regards, Tobias Tobias Gondrom email: tobias.gondrom@gondrom.org
- [secdir] secdir review of draft-ietf-avt-rtp-cnam… Tobias Gondrom
- Re: [secdir] secdir review of draft-ietf-avt-rtp-… Dan Wing
- Re: [secdir] secdir review of draft-ietf-avt-rtp-… DRAGE, Keith (Keith)
- Re: [secdir] secdir review of draft-ietf-avt-rtp-… Ali C. Begen (abegen)