[AVTCORE] changes planned for EKT

Dan Wing <dwing@cisco.com> Tue, 26 November 2013 06:17 UTC

From: Dan Wing <dwing@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <91E00FEF-2D36-4D8E-8B9A-EBAE12A1A912@cisco.com>
Date: Mon, 25 Nov 2013 22:17:17 -0800
To: "avt@ietf.org WG" <avt@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: [AVTCORE] changes planned for EKT
Precedence: list

We received detailed reviews from Michael Peck, John Mattsson, and Magnus Westerlund (URLs for their reviews below). I am replying in separate emails to each of Michael, John, and Magnus' reviews and CC'ing AVTCORE.

As a result of those reviews, we are considering some changes to EKT, as follows:

1. Only use EKT over SRTP, and remove the ability to send EKT over SRTCP. As you may recall, EKT originally worked only over SRTCP, then added support for both SRTP and SRTCP. Our desire to abandon SRTCP is because of several deficiencies with carrying EKT over SRTCP compared to carrying EKT over SRTP, specifically:
- SRTCP compound packet problem described in Magnus' review (his point "G2"). See URL to his review below.
- lack of fate sharing between SRTCP (signaling the new SRTP master key) and SRTP (using the new SRTP master key).
- RTCP rate limits for AVP and AVPF profiles, which prevent sending EKT in SRTCP as aggressively as one might like when rekeying or when joining a session as a new sender.
- unsure how we might handle ISN (initial sequence number) for the key protecting SRTCP (immediately or later), because RTCP does not have a sequence number.
- implementations would have to support EKT over RTP and RTCP.

2. require SRTP master keys to always be randomly generated and never shared between sessions, ever.

3. Remove MKI support from EKT, as they are duplicative functions. As a reminder, MKI (master key index) is defined in SRTP (RFC3711) and allows to pre-stage a key using call setup key signaling (e.g., Security Descriptions, MIKEY, DTLS-SRTP, etc.), whereas EKT has its own mechanism to perform a similar function (ISN, initial sequence number, which is when a pre-staged key will be used). Currently the EKT draft has a weak discussion of how these interact, and instead of improving this text and imposing the implementation burden for MKI support on EKT endpoints, we would like to declare MKI with EKT as unsupported and out of scope.

4. Require EKT to be negotiated during call setup, and require endpoints to wait until receiving the EKT Full Field packet (containing the decryption key) before attempting to authenticate packets (to avoid doubling authentication effort). This avoids new joiners attempting to authenticate two packets when they join an EKT session (the first attempt using the SRTP master key from normal key-management (MIKEY, SDESC, DTLS-SRTP, whatever) and if that fails the second attempt from the EKT-provided SRTP master key).

We would really like to hear WG feedback on the above proposed changes before we publish -02 of draft-ietf-avtcore-srtp-ekt. If you are adventurous, the work-in-progress -02 is at https://svn.tools.ietf.org/svn/wg/avtcore/draft-ietf-avtcore-srtp-ekt/draft-ietf-avtcore-srtp-ekt-02.txt, and side-by-side diffs are at http://tools.ietf.org/rfcdiff?url1=draft-ietf-avtcore-srtp-ekt-01.txt&url2=https://svn.tools.ietf.org/svn/wg/avtcore/draft-ietf-avtcore-srtp-ekt/draft-ietf-avtcore-srtp-ekt-02.txt -- but this is my work-in-progress version of -02, and does not yet have any of the proposed changes 1 through 4 (above) included in that text, until we receive feedback from the working group.

Review URLs:
Magnus Westerlund review, http://www.ietf.org/mail-archive/web/avt/current/msg16109.html
Michael Peck review, http://www.ietf.org/mail-archive/web/avt/current/msg16107.html
John Mattsson review, http://www.ietf.org/mail-archive/web/avt/current/msg16095.html

-d

[AVTCORE] changes planned for EKT Dan Wing
Re: [AVTCORE] changes planned for EKT Magnus Westerlund
Re: [AVTCORE] changes planned for EKT Dan Wing