[AVTCORE] EKT update, draft-ietf-avtcore-srtp-ekt-02

[Dan Wing <[e-mail]>]

We just posted draft-ietf-avtcore-srtp-ekt-02, http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-02.

It contains a brief summary of changes, http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-02#section-1.1,
  In draft-ietf-avtcore-srtp-ekt-02 (this document), SRTP master keys
  have to be always generated randomly and never shared, MKI is no
  longer allowed with EKT (as MKI duplicates some of EKT's functions),
  and text clarifies that EKT must be negotiated during call setup.
  Some text was consolidated and re-written, notably Section 2.6
  ("Timing and Reliability").

Additionally, -02 removed the ability to re-direct DTLS-SRTP handshake to another host ("Scaling to Large Groups" which introduced the SDP attribute dtls-srtp-host).  This was removed because the only interested person never responded to my emails, and because proper support really needs ICE- or ICE-like handling for NAT traversal.  If interest grows, this can be done in a separate draft, and may have value even without EKT.


As you may recall, there were a bunch of great comments from Magnus, Michael, and John.  Almost all of those were integrated into -02, with the exception of those I was hoping to get feedback from the working group, which I had discussed in [1], "changes planned for EKT" where I summarized some planned changes.  In that post, I had written:

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


Due to unidirectional audio (recvonly, sendonly), limiting EKT to only RTP means we need to send an RTP packet.  While my confidence was high that we would never need or want to change the SRTCP key when using EKT (and hence not need to ever send an RTP packet with EKT), I admit this does not seem to be consensus.  

The authors were unable to resolve the SRTCP compound packet issue noticed by Magnus.  Details of the issue are in Magnus' review, see URL below.  I believe the best we can do is document this problem in the specification, and provide an additional encouragement to use EKT-over-SRTP.  Comments or feedback or better ideas?  I have some candidate text pointing out the problem and providing further encouragement to use EKT-over-SRTP (rather than EKT-over-SRTCP), but I am not yet happy with the text (see [2], below).

The other points in the bulleted list (fate sharing, RTCP rate limits, ISN) were added to draft-ietf-avtcore-srtp-ekt-02.


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

New text in draft-ietf-avtcore-srtp-ekt-02,

  All SRTP master keys MUST NOT be re-used, MUST be randomly generated
  according to [RFC4086], [and] MUST NOT be equal to or derived from other
  SRTP master keys.


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

MKI is now prohibited with EKT in draft-ietf-avtcore-srtp-ekt-02.


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

EKT is now required to be negotiated during call set-up in draft-ietf-avtcore-srtp-ekt-02.


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


[1] http://www.ietf.org/mail-archive/web/avt/current/msg16129.html

[2] candidate text providing further incentive for EKT-over-SRTCP:

  2.5.  Transport

  EKT SHOULD be used over SRTP, and MAY be used over SRTCP.  SRTP is
  preferred because it shares fate with transmitted media, because SRTP
  rekeying can occur without concern for RTCP transmission limits, and
|  because of SRTCP compound packets with RTP translators and mixers.
|  This specification requires the EKT SSRC match the SSRC in the RTCP
|  header, but Section 6.1 of [RFC3550] encourages creating SRTCP
|  compound packets:
|
|     It is RECOMMENDED that translators and mixers combine individual
|     RTCP packets from the multiple sources they are forwarding into
|     one compound packet whenever feasible in order to amortize the
|     packet overhead (see Section 7).
|
|  These compound SRTCP packets might have an SSRC that does not match
|  the EKT SSRC.  There is no good solution to handling these SRTCP
|  compound packets, except hoping the mixer or translator round robin
|  between the SSRCs, but this would require several SRTCP packets,
|  further delaying receipt of EKT over RTCP.  This impact of RTP
|  translators and mixers, and the inability to realibly determine an
|  RTP translator or mixer might be involved in an RTP session, provides
|  further incentive to send EKT over RTP.

-d