[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)