Re: [AVTCORE] EKT Problems with RTCP

John Mattsson <> Tue, 24 March 2015 16:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 61AE51A8F3D for <>; Tue, 24 Mar 2015 09:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eG7Jfpu_qk8x for <>; Tue, 24 Mar 2015 09:41:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 071351A90EE for <>; Tue, 24 Mar 2015 09:41:46 -0700 (PDT)
X-AuditID: c1b4fb3a-f79146d0000070a3-aa-551193c84e3d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 39.33.28835.8C391155; Tue, 24 Mar 2015 17:41:45 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Tue, 24 Mar 2015 17:41:44 +0100
From: John Mattsson <>
To: "Mo Zanaty (mzanaty)" <>
Thread-Topic: [AVTCORE] EKT Problems with RTCP
Date: Tue, 24 Mar 2015 16:41:44 +0000
Message-ID: <>
References: <> <emae6d6460-9744-4852-ba8b-91b0e0794a40@helsinki> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BFCB4F6D81CD4B779EB802BF6C16BD59ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM+Jvje7JyYKhBou281u87FnJbvHiwRwm i/MXNjA5MHtM+b2R1WPJkp9MHg37jrIHMEdx2aSk5mSWpRbp2yVwZfTd381Y0HiRseL/+5eM DYxztjB2MXJySAiYSFzs/ccOYYtJXLi3nq2LkYtDSOAIo8SblW/ZIZwljBKzl05iAaliEzCQ mLungQ3EFhHQlXj3+xnYJGYBb4mGj6vBaoSB4jMOz2HqYuQAqtGT2P1TDqLcSeJDVztYOYuA qsTq21vAxvAK2EssuTyPCWLXDEaJfTvOsYIkOAX0JebN/w92HSPQdd9PrWGC2CUucevJfCaI qwUkluw5zwxhi0q8fPyPFcJWklix/RLUbckScyZOZYFYJihxcuYTlgmMorOQjJqFpGwWkjKI uIHE+3PzmSFsbYllC19D2foSG7+cZYSwrSUmn5nPjqxmASPHKkbR4tTi4tx0IyO91KLM5OLi /Dy9vNSSTYzACD245bfVDsaDzx0PMQpwMCrx8BpcFggVYk0sK67MPcQozcGiJM5rZ3woREgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjyrMcLcM7Jv+umqz+ynjtW9nWyGdaTx68UGFz2N5t 4vuzUPzt3eRZPK68K/Oet014c+d/kqh1w5y4RbwrCt6x3fyye8fOyb5m1fPXTXW4oOPCnX43 +O7v5/0magWGltNjim586X7zdNriDzJll4KPr83uXS1rbJ1+NjXmn9P68qtisscWq/YHKrEU ZyQaajEXFScCAO8XBBCxAgAA
Archived-At: <>
Cc: IETF AVTCore WG <>
Subject: Re: [AVTCORE] EKT Problems with RTCP
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Mar 2015 16:41:53 -0000

> I think it could even be argued that ISN/ISI should be eliminated

Agree, Thinking more about the problem, there is no possibility at all to keep ISN, it definitely needs to be eliminated.

Not only is it causing the major problems it is also making EKT vulnerable to several types of practical replay attacks.

The question needing answer is "Do we really need several SRTP Master keys per SSRC and EKT SPI?”

If no we can just skip ISN. If yes we need MKI. If maybe we can make MKI optional.

The ISN problems and the scope of EKT will the two topics of my EKT presentation today.


On 24 Mar 2015, at 10:29, Mo Zanaty (mzanaty) <<>> wrote:

I agree with Paul, option 1 seems best. I think it could even be argued that ISN/ISI should be eliminated, and EKT must always be sent separately in SRTP/SRTCP coincident with the SN/index of the rekey point.

Some additional text may be useful to reflect operation in more complex RTP scenarios, such as multiple RTP streams bundled in the same session with sparse RTCP reporting (not full mesh).


On 3/23/15, 3:27 PM, Paul E. Jones <<>> wrote:


Option 1 strikes me as the simplest solution to the problem you describe with minimal changes in the text.  Option 2 would work, though I'm missing the point of the replay benefit that comes with MKI.  Given the endpoints are randomly generating SRTP master keys, isn't that sufficient?  Perhaps I'm missing something key.


------ Original Message ------
From: "John Mattsson" <<>>
To: "IETF AVTCore WG" <<>>
Sent: 3/23/2015 8:15:48 AM
Subject: [AVTCORE] EKT Problems with RTCP


While editing the EKT draft I realized that EKT has major problems with RTCP.

+---+ —------ SRTP ---------> +---+
| S | ------- SRTCP SR -----> | R |
+---+ <------ SRTCP RR ------ +---+

Take the above example. The sender S sends RTP and RTCP to the receiver R. R sends RTCP but not RTP to S.

S re-keying: Irrespectively if S sends EKT in SRTP or SRTCP the occurrence of the key change is signalled with ROC || ISN and R has no way to know when to exactly change key for SRTCP (i.e. how ISN maps to the SRTCP index). R is forced to guess and try authenticating with both the old and the new key.

R re-keying: Here ROC || ISN has no meaning at all and S will have to do trial and error with both the old and the new key.

This is not a robust solution and it needs to be fixed. Two suggestions:

- Option 1
One option is to add another field ISI (Initial SRTCP Index) to the EKT_Plaintext. This would then work similar to ISN. The Plaintext could contain both, or one of them. One alternative is that EKT contains both ISN and ISI. Another alternative is that ISN is used in EKT over SRTP and ISI in EKT over SRTCP, forcing EKT to be used in both SRTP and SRTCP.

- Option 2
The current EKT draft says

“MKI is no longer allowed with EKT (as MKI duplicates some of EKT's functions)”.

Its rather EKT that duplicates MKI (RFC 3711) and one simple option would be to simply remove the EKT parts that duplicates MKI and instead mandate use of MKI.

The EKT_Plaintext would then be:
EKT_Plaintext = SRTP_Master_Key || SSRC || ROC || MKI

And the SRT(C)P packets would look like:
| RTP Header | RTP Payload | MKI | TAG | EKT |
| RTCP Packet Types  | SRTCP INDEX | MKI | TAG | EKT |

This would allow full flexibility in the use of EKT. EKT could be sent in RTP and/or RTCP. Any number of keys could be distributed ahead of time.

If the MKIs are random, this would also make the EKT replay attack (in the case of SSRC collisions) much harder.

MKI could by default be one byte.

For AEAD algorithms MKI is the last field in the SRTP. If AEAD algorithms were mandated for EKT, MKIs with the last bit ‘0’ could be mandated and the short EKT tag would not be needed.

Comments welcome, I would strongly prefer option 2. The more I think about it, the ISN approach duplicates functionality in RFC3711, it is complex, not robust, and vulnerable to replay attacks.



MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

Ericsson AB
Ericsson Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone +46 10 71 43 501
SMS/MMS +46 76 11 53 501<>