Re: [AVTCORE] changes planned for EKT

[Dan Wing <[e-mail]>]

On Nov 29, 2013, at 4:21 AM, Magnus Westerlund <[e-mail]> wrote:

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

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

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

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.


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

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


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

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

-d


> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>