[secdir] Security review of draft-thornburgh-adobe-rtmfp-07
"Hilarie Orman" <hilarie@purplestreak.com> Fri, 21 June 2013 17:07 UTC
Return-Path: <hilarie@purplestreak.com>
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 EA6C621F9F1C; Fri, 21 Jun 2013 10:07:03 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFvco3dVEsbZ; Fri, 21 Jun 2013 10:06:51 -0700 (PDT)
Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id D010121F9F08; Fri, 21 Jun 2013 10:06:51 -0700 (PDT)
Received: from mx03.mta.xmission.com ([166.70.13.213]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1Uq4nS-0007jS-8V; Fri, 21 Jun 2013 11:06:50 -0600
Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx03.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1Uq4nO-0003cW-QT; Fri, 21 Jun 2013 11:06:50 -0600
Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id r5LH5R2R025410; Fri, 21 Jun 2013 11:05:27 -0600
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id r5LH5Qf2025408; Fri, 21 Jun 2013 11:05:26 -0600
Date: Fri, 21 Jun 2013 11:05:26 -0600
Message-Id: <201306211705.r5LH5Qf2025408@sylvester.rhmr.com>
From: Hilarie Orman <hilarie@purplestreak.com>
To: iesg@ietf.org, secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-SA-Exim-Connect-IP: 166.70.57.249
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: **;iesg@ietf.org, secdir@ietf.org
X-Spam-Relay-Country:
X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700)
X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com)
Cc: draft-thornburgh-adobe-rtmfp@tools.ietf.org
Subject: [secdir] Security review of draft-thornburgh-adobe-rtmfp-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
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: Fri, 21 Jun 2013 17:07:04 -0000
Security review of Adobe's Secure Real-Time Media Flow Protocol draft-thornburgh-adobe-rtmfp-07 Do not be alarmed. 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 is an informational RFC describing an existing Adobe protocol. It has the feature of allowing sessions to change their IP addresses and to use forwarders to help in NAT traversal. The draft does not specify the cryptographics requirements and processing in enough detail to facilitate interoperable implementations, and I don't recommend advancing it. The draft generically specifies the cryptographic features that would provide privacy and authentication. All specifics are left to the implementor. The cryptographic profiles could be trivial (rot13 and casting out nines, for example). How is the cryptographic profile specified? Is there only one, to be used by all implementations RTMFP? If not, how do two implementations agree on which profile they will use? How is the "default session key" selected? The text mentions the possibility of multiple default keys. In "Security Considerations": ... to allow for different applications of RTMFP using different Default Session Keys to (intentionally or not) share network transport addresses without interference. I don't see how this could work. What is the algorithm for encrypting with the default session key? Note that the crypto profile is supposed to determine the keys, but there is not necessarily an interface that accepts a default key and produces usable encryption and integrity/authentication keys. Is there any response for "endpoint discriminator unacceptable"? I did not see any "MUST" requirements for rejecting data that fails to pass cryptographic checks. How are message integrity and authentication achieved? Is it required? Section 2.2.3 says: "The packet encryption layer is responsible for data integrity and authenticity, for example by means of a checksum or cryptographic message authentication code." That does not seem to require that the message integrity be tied to the Endpoint Discriminator. Is there anti-replay prevention? I cannot tell. There are sequence numbers, but they could be spoofed under some definitions of the cryptographic profile. Section 2.2.2: "The 32-bit Scrambled Session ID is the 32-bit Session ID modified by performing a bitwise exclusive-or with the bitwise exclusive-or of the first two 32-bit words of the encrypted packet." This is security-by-obscurity and is not worth the trouble. The Security Considerations admit that the Default Session Key is such a weak measure that all messages that use it should be considered to be sent in the clear. It isn't worth the trouble of using it. There are robust IETF security protocols that could be layered over RTMFP. I recommend removing all references to cryptography from this document. Hilarie
- [secdir] Security review of draft-thornburgh-adob… Hilarie Orman
- Re: [secdir] Security review of draft-thornburgh-… Michael Thornburgh
- Re: [secdir] Security review of draft-thornburgh-… Uri Blumenthal
- Re: [secdir] Security review of draft-thornburgh-… Michael Thornburgh
- Re: [secdir] Security review of draft-thornburgh-… Michael Thornburgh