Re: [AVTCORE] changes planned for EKT

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 29 November 2013 12:21 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BD91AE002 for <avt@ietfa.amsl.com>; Fri, 29 Nov 2013 04:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 oC7nyheUkpuw for <avt@ietfa.amsl.com>; Fri, 29 Nov 2013 04:21:48 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 539A31ADBD5 for <avt@ietf.org>; Fri, 29 Nov 2013 04:21:48 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-0f-529886da9747
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D5.F5.03802.AD688925; Fri, 29 Nov 2013 13:21:46 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.328.9; Fri, 29 Nov 2013 13:21:45 +0100
Message-ID: <529886D9.6080209@ericsson.com>
Date: Fri, 29 Nov 2013 13:21:45 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>, "avt@ietf.org WG" <avt@ietf.org>
References: <91E00FEF-2D36-4D8E-8B9A-EBAE12A1A912@cisco.com>
In-Reply-To: <91E00FEF-2D36-4D8E-8B9A-EBAE12A1A912@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgluLIzCtJLcpLzFFi42KZGfG3VvdW24wgg76fEhYve1ayW1y89pDJ gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4MqY982wYKliRUfvWaYGxgtSXYwcHBICJhI7 ezm7GDmBTDGJC/fWs4HYQgKHGCXm99Z3MXIB2csZJf7sec0OkuAV0JZ483AFM4jNIqAqMX3+ U0YQm03AQuLmj0awZlGBYImrveuYIeoFJU7OfMICYosIOEhcWHwDLC4soCcxe387I8QyG4kH zQtYQe7hFLCVOLtEBOI0cYmexiCQCmag6ilXWxghbHmJ5q2zmSE6tSUamjpYJzAKzkKybBaS lllIWhYwMq9iZM9NzMxJLzfaxAgMxYNbfqvuYLxzTuQQozQHi5I474e3zkFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGC1cAqQWrd9T5+izzcE5Jvzv/9DKj3bMdau/Z3pNMGRYv+UBY1PL DOfoaJec61ErrRK/Mmwttkz709veyD5TOTHrs8CnNcZvlP2KlZYW/LWRmOS49RSDhuvbeTvU v1/ceXVxqWTr5yDJPT5Zix4tk3d1cU2RCXk0Xej5Djt3I32jQ2e+KIl2KrEUZyQaajEXFScC AADNYHATAgAA
Subject: Re: [AVTCORE] changes planned for EKT
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Nov 2013 12:21:50 -0000

On 2013-11-26 07:17, Dan Wing wrote:
> 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.

I wonder if this really works in reality. The issues I directly can see are:

1. In an RTP session where RTP is one way only, the receiver's RTCP
reports will be unable to change their key when they have over used any
initially generated key.

2. Still have synchronization issues with the keys. In this case rather
with RTCP, because of reorder or packet loss, an RTCP packet using a new
key can arrive prior to the key and thus fail to be decrypted.
This might be a minor issue, but still needs consideration.

I think 1) above is the real significant issue here.

2) I assume can be solved by procedures or possible using some type of
MKI field to point at which key is used.



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

I think this is fine.

> 
> 
> 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.
> 

Considering issue 2) for the above, I wonder if using the MKI might be a
better solution?

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

I think it is good to consider and be more explicit about how the normal
key-management keys functions in the presence of EKT.

I am uncertain what issues, if any, your proposal will result. I do
encourage additional persons to consider this and provide feedback.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------