Re: [AVTCORE] EKT Problems with RTCP

"Paul E. Jones" <> Mon, 23 March 2015 19:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F191B1A0687 for <>; Mon, 23 Mar 2015 12:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G2AxULL8pVFP for <>; Mon, 23 Mar 2015 12:27:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 452C81A066C for <>; Mon, 23 Mar 2015 12:27:42 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.9/8.14.9) with ESMTP id t2NJRcHa020002 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 15:27:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1427138859; bh=eSeF4ExZcREnaiv8hDEHpi8Pzb1o8NU7FBkZol3f6xk=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=g0wMsWycNgFEJzsigrQj1eY59XuMUYOr1i+wMz6cp2ecGXIXti8FjBW6PzCYGF0W8 svEIBYmuBzb0n9nAWbPBUDFImttdJg370W8F0jc5c9Ls8JgT2OmA0GrZFBlPBo27eB vmZK2XRN/9sTOBOYqprcUgHTItEkzllwDpXd/CUQ=
From: "Paul E. Jones" <>
To: John Mattsson <>, IETF AVTCore WG <>
Date: Mon, 23 Mar 2015 19:27:39 +0000
Message-Id: <emae6d6460-9744-4852-ba8b-91b0e0794a40@helsinki>
In-Reply-To: <>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: multipart/related; boundary="------=_MB3213949E-0250-437E-9D5F-70BFF6008141"
Archived-At: <>
Subject: Re: [AVTCORE] EKT Problems with RTCP
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <>
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Mar 2015 19:27:46 -0000


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 
>+---+ —------ 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 
>- 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 
>- Option 2
>The current EKT draft says
>“MKI is no longer allowed with EKT (as MKI duplicates some of EKT's 
>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 
>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