[dispatch] Charter Proposal for OSRTP Working Group
Alan Johnston <alan.b.johnston@gmail.com> Fri, 25 September 2015 18:54 UTC
Return-Path: <alan.b.johnston@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F51A87D0 for <dispatch@ietfa.amsl.com>; Fri, 25 Sep 2015 11:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OU9AXHh1LxB for <dispatch@ietfa.amsl.com>; Fri, 25 Sep 2015 11:54:32 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92011A87CA for <dispatch@ietf.org>; Fri, 25 Sep 2015 11:54:27 -0700 (PDT)
Received: by ioiz6 with SMTP id z6so120038987ioi.2 for <dispatch@ietf.org>; Fri, 25 Sep 2015 11:54:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sOmCO1R6dV4Q2YtG8vbckC1lg5EkIltRoRJbj/HEtsU=; b=o+0t14ZcY93wvl4sZWPKbNuDExXut3GAecDVmiKTfBbhij8qi5DLAPOYnwFLWzt5v+ W8dYdLkSjkJ1hLKXeKYe9hmiJV3A/1QJc8+iRHmqvZe17FgunK/sXCOtBNIqCTKbhnba b4WWWQfnC/PZ7wNUCQsJjGG/w2iKaYeQZFOvA8+mP6EID4xSTZ5zTITI0em6WWchXiKY xm7nthppbVHH81c/st2uDpAdOpfepB3+s0CkNJPXwEpQAPGdtw4/5ROZ9d5VWF6Hh7OR IX3XkTJyaC1FaAclFlQ8Zvw+aLPZnfcrfonm9ElXUCHbSjUN+NU1aFoGdAPUUPNwt0nj SDOQ==
MIME-Version: 1.0
X-Received: by 10.107.40.12 with SMTP id o12mr8043064ioo.84.1443207267011; Fri, 25 Sep 2015 11:54:27 -0700 (PDT)
Received: by 10.79.32.86 with HTTP; Fri, 25 Sep 2015 11:54:26 -0700 (PDT)
Date: Fri, 25 Sep 2015 13:54:26 -0500
Message-ID: <CAKhHsXFFjy_q=AXRqrcw0Xvf49-6jq7=9xuSA6md=qx2pViyug@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141d1507cd092052096e0ef"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g>
Subject: [dispatch] Charter Proposal for OSRTP Working Group
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2015 18:54:34 -0000
All, Here is proposed text for an OSRTP Working Group which we would request to be dispatched. We are not sure that we really need to form a working group in order to publish what is effectively already industry best practices, but this text is for discussion of the topic and the determination of the path forward in here in dispatch. Comments most welcome! - Alan - - - - - - - - - Charter for Opportunistic Security for RTP Working Group (OSRTP) Real-time voice and video communication using RTP is widely used over the Internet today, and much of it is negotiated using SIP and SDP offer/answer. Secure media transport negotiated using SIP and SDP with the secure profile of RTP, SRTP, is unfortunately not widely deployed today for voice and video communication. One reason for this is the difficulty in negotiating the use of SRTP. SDP offer/answer was not originally designed to negotiate profiles of RTP, and extensions such as SDP Capability Negotiation, RFC 5939, have not achieved enough deployment to be useful for negotiating secure media. Without extensions, a caller needs to decide in advance that secure media is used, but if chosen in advance and the called party does not support it, the session will fail. This presents a serious barrier to incremental deployment of secure media. Opportunistic Security (OS), defined in RFC 7435, is an approach to security that defines a third mode for security between "cleartext" and "comprehensive protection" that allows encryption and authentication to be used if supported but will not result in failures if it is not supported. An opportunistic approach for secure media would allow SRTP to be used if the called party support the opportunistic approach, but will fall back to RTP if the called party does not. This will allow SRTP to be incrementally introduced in voice and video communication networks during the transition from no encryption to always-on encryption. WG Objectives This WG will work on a solution for Opportunistic SRTP (OSRTP) that does not require SDP Capability Negotiation, but instead will be based on currently deployed techniques in many voice and video systems that use SDP offers that do not specify a secure profile, but instead use AVP and the presence of SRTP keying SDP attributes in the SDP offer and answer to negotiate secure media. The approach will be general enough to work with a variety of SRTP key agreement protocols including, but not limited to SDP Security Descriptions, DTLS-SRTP, and ZRTP. It is important to note that OSRTP makes no changes, and has no effect on media sessions in which the offer contains a secure profile of RTP, such as SAVP. Also, approaches that always require secure media, such as RTCWEB, will never utilize OSRTP. As allowed by Opportunistic Security, some authentication requirements of SRTP key agreement approaches will be relaxed. However, confidentiality requirements will not be relaxed. The working group will perform the following work: 1. Define the goals and requirements of an Opportunistic Security approach for RTP 2. Define a specification for OSRTP. Non Goals This work will not define any new extensions to SIP or SDP, but it may make changes in some offer/answer procedures or authentication requirements of key agreement protocols. No changes to SRTP or RTP will be made. Collaboration The working group may coordinate with SIPCORE, MMUSIC, and AVTCORE as needed. Input to the WG https://tools.ietf.org/html/draft-johnston-dispatch-osrtp (a starting point for the goals and requirements and protocol) https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-00 (for historical reasons and background)
- [dispatch] Charter Proposal for OSRTP Working Gro… Alan Johnston