IETF Logo Mail Archive

[rtcweb] security-arch: RTP and RTCP Key Management (mux and non-mux)

Bernard Aboba <bernard.aboba@gmail.com> Tue, 22 July 2014 03:34 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB001A03D2 for <rtcweb@ietfa.amsl.com>; Mon, 21 Jul 2014 20:34:07 -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 9v3iHEEWzwB3 for <rtcweb@ietfa.amsl.com>; Mon, 21 Jul 2014 20:34:06 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7031A03BA for <rtcweb@ietf.org>; Mon, 21 Jul 2014 20:34:05 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id k48so7379406wev.12 for <rtcweb@ietf.org>; Mon, 21 Jul 2014 20:34:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=e5B5GNw6EsadRWFV1ZyOz5oTvQDwGBXrZos6LWhG/Gg=; b=pm/JTYmlRzhldKYF2wNsKTRZSSWXUofD6uID+lChn1hPmHeQ4AQKtzqtI3og6FsW6m cl+myRjK4qN+SS0B2C5BtmVICni57qWfB+HgKudKf6Hv9OYacipPfk1LK1k68p6jMy+Y f2sErsvSh6kG5BTMq31jos2XHDDs0oIewXKWGYR/pkLAeoUF/XA4ZkfPrPCVkQNG5rZV K225rb8tyZNDs8V4oN+9kBjsVO+/M3rQRIaCQkMytMIJrGHbEfS0STbf9UBVglVQ0nvj q3vta+hds6xDO9s4vEKxDbRnH8L4sPR/wr1LMRYy8JppIgk7D3p6Kaicwzg7t+Pc3s0F pc0w==
X-Received: by 10.194.123.105 with SMTP id lz9mr29630061wjb.122.1406000044721; Mon, 21 Jul 2014 20:34:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.122.65 with HTTP; Mon, 21 Jul 2014 20:33:44 -0700 (PDT)
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 21 Jul 2014 23:33:44 -0400
Message-ID: <CAOW+2dsAyiKxAVCHBv-Qi2_2G4xOBE_xFiniUvhAO=Ft78TkDw@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="089e01177699384b2904febfe5e2"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/k5cGySZk1zDXf9HgGni7s1VV4rc
Subject: [rtcweb] security-arch: RTP and RTCP Key Management (mux and non-mux)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jul 2014 03:34:08 -0000

I have had some questions about DTLS/SRTP key derivation in the multiplexed
and non-multiplexed cases.  The questions arise from the following sentence
in RFC 5764 Section 3:

   There MUST be a separate DTLS-SRTP session for each
   distinct pair of source and destination ports used by a media session
   (though the sessions can share a single DTLS session and hence
   amortize the initial public key handshake!).

[BA] My question is whether WebRTC permits DTLS-SRTP sessions to share a
single DTLS session or not.

The description in security-arch Section 4.3 seems to indicate that where
symmetric RTP and RTCP is not multiplexed it is expected to have two
separate DTLS sessions, and for RTP/RTCP multiplexed there will be a single
DTLS session:

   Specifically, Alice and Bob perform a DTLS
   handshake on every channel which has been established by ICE.  The
   total number of channels depends on the amount of muxing; in the most
   likely case we are using both RTP/RTCP mux and muxing multiple media
   streams on the same channel, in which case there is only one DTLS
   handshake.  Once the DTLS handshake has completed, the keys are
   exported [RFC5705 <http://tools.ietf.org/html/rfc5705>] and used to key
SRTP for the media channels.

[BA] However, I didn't see any normative language indicating that this is
the only permitted configuration (although my understanding is that every
existing implementations operates this way).

v2.23.0 | Report a Bug | By Email