[AVTCORE] EKT Problems with RTCP

John Mattsson <john.mattsson@ericsson.com> Mon, 23 March 2015 12:15 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D3A561A882C for <avt@ietfa.amsl.com>; Mon, 23 Mar 2015 05:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id S1fD3NB7TimI for <avt@ietfa.amsl.com>; Mon, 23 Mar 2015 05:15:52 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3211A87D5 for <avt@ietf.org>; Mon, 23 Mar 2015 05:15:51 -0700 (PDT)
X-AuditID: c1b4fb2d-f79a46d0000006b4-76-551003f53f0e
Received: from ESESSHC010.ericsson.se (Unknown_Domain []) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.EB.01716.5F300155; Mon, 23 Mar 2015 13:15:50 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([]) by ESESSHC010.ericsson.se ([]) with mapi id 14.03.0210.002; Mon, 23 Mar 2015 13:15:49 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: IETF AVTCore WG <avt@ietf.org>
Thread-Topic: EKT Problems with RTCP
Thread-Index: AQHQZWMYVJRe7hrOQ0ODT1ktOeprFA==
Date: Mon, 23 Mar 2015 12:15:48 +0000
Message-ID: <44464851-92EB-4B19-9A4F-559C0E1A4DE7@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_4446485192EB4B199A4F559C0E1A4DE7ericssoncom_"; type="multipart/alternative"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM+Jvje43ZoFQgwWXGC1e9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqt3H9kL/h9krOhb3MvUwHhkD2MXIyeHhICJRHf3dDYIW0zi wr31QDYXh5DAEUaJk4/mMEI4SxglHq+7DVbFJmAgMXdPA5gtIqAksWPSNmYQW1hAXuLgy2/s XYwcQHEViUtvhCBK9CR2ddwAK2cRUJV4dLOLFcTmFbCX+DrzKZjNCLT4+6k1TCA2s4C4xK0n 85kgDhKReHjxNNRxohIvH/9jhbCVJBqXPGGFqK+X2P1mEdRMQYmTM5+wTGAUmoVk1CwkZbOQ lEHEkyV6zrSyzwK6mllAU2L9Ln2IsKLElO6H7BC2hkTrnLlQtrXE1AlX2DHVaEuc2DiFFcJW kHi1/h7bLGDIMYNC7vam9YwQ810k5j8JQ9a7gJFvFaNocWpxcW66kbFealFmcnFxfp5eXmrJ JkZg9B7c8lt3B+Pq146HGAU4GJV4eDc08ocKsSaWFVfmHmKU5mBREue1Mz4UIiSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoHRVue8/dHb2W+nMpY1NGzX3W56TbeEP2ZxRj5L7EerPRd97jk1 uzpusteeckF0/R5bwWNq7/b8PD1vsYnlF7ctk/48XKp4UTVwcfN+xuxj3t+1X3GknN7ccCaw 8ae6xxcuQ7WX3651Zs7IOVS3NvLsxeW/3ZYEfTf8IvlcXVvn2sMDiTPv73u2QImlOCPRUIu5 qDgRAJ5iWZK/AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/4SYi4Itrc9lBnRaIoKhzqAdzKBI>
Subject: [AVTCORE] EKT Problems with RTCP
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 12:15:55 -0000


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