Subject: [AVTCORE] changes planned for EKT

From: Dan Wing <[email-masked]>
Date: Mon, 25 Nov 2013 22:17:17 -0800

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Nov 2013 13:21:45 +0100

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

> 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: [email-masked]
----------------------------------------------------------------------

---

From: Dan Wing <[email-masked]>
Date: Fri, 29 Nov 2013 08:28:05 -0800

> reports will be unable to change their key when they have over used any

I don't envision a key exhaustion problem with SRTCP.

> MKI field to point at which key is used.

Are you thinking of adding an MKI field to the SRTCP packet?  As you had pointed out previously, we don't have an RTCP sequence number and there  isn't much else to work from in the SRTCP payload format.

A variation on existing wording might be all that is necessary if we add:

   Due to packet loss and reordering, an SRTCP packet can be received
   using a new key before the EKT packet has been received.  SRTCP 
   receivers MAY want to delay discarding SRTCP packets from known 
   SSRCs that fail authentication in anticipation of receiving 
   a rekeying event via EKT shortly.

> key-management keys functions in the presence of EKT.

Some history:  Initially, when EKT was only spec'd to work over SRTCP, our product teams had a lot of concern with call setup delay to wait for the EKT packets for the common 'new sender' case.  Honoring the AVP/AVPF profiles for RTCP transmission made this even worse so the product ignored the RTCP profile rules (which is not good).  For that reason and to share fate with the SRTP packet itself, we added support for EKT over SRTP.  With those changes, EKT does not harm call setup delay (because the SRTP packet contains the EKT key). 

When a new receiver joins an existing session, the receiver has to necessarily wait for EKT (to understand received packets) and there is no value or benefit for the new receiver to send SRTCP packets into that existing session using its key-management key (because all the other receivers don't know [or care] about that particular receiver's unique key-management key).

> encourage additional persons to consider this and provide feedback.

Yes, I am hoping to hear from more people before making changes.

-d