Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347101A88EF for ; Tue, 24 Mar 2015 08:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uftcWres4-ac for ; Tue, 24 Mar 2015 08:29:44 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AA21A88ED for ; Tue, 24 Mar 2015 08:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21067; q=dns/txt; s=iport; t=1427210984; x=1428420584; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=YHJFmkR6bXzOz6n8WBDB5qFWxO24Scd7q5CeUxN12o4=; b=SWJFiTzYTIVP78uWHx2IJsdb7Qajetk9QktSg3yZhH+OKhbS32ZNJ++a S78x/luUdDyNq2P8GYZWxSAwwTDL2BJBUaLUqmHWt1eWIm7h7IQBnkuiS +kevVlm1s2Rduf5a1FUX+16I9z0o3xiev0wS4/wz8+mWfH7XX739ctHMl E=; X-Files: unknown.png : 2991 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APBQDcgRFV/4sNJK1cgkNDUloExkiFeQKBOUwBAQEBAQF9hBQBAQEEBQcbBlgCAgIBCAcKBAEBBgEBAR8HAhUBAwsMFAkIAgQBEQEGCA2IFMkKAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLHYRbIQEGhCcBBIYYiW9JgWmBMgGGU5QsIoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,458,1422921600"; d="png'150?scan'150,208,217,150";a="134954334" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP; 24 Mar 2015 15:29:43 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2OFThl2003716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 15:29:43 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.61]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 10:29:43 -0500 From: "Mo Zanaty (mzanaty)" To: "Paul E. Jones" , John Mattsson , IETF AVTCore WG Thread-Topic: [AVTCORE] EKT Problems with RTCP Thread-Index: AQHQZkdZSYfsosNBuk+5RipnnggZrA== Date: Tue, 24 Mar 2015 15:29:42 +0000 Message-ID: References: <44464851-92EB-4B19-9A4F-559C0E1A4DE7@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [64.100.32.216] Content-Type: multipart/mixed; boundary="_004_D136F8364A4CBmzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:29:47 -0000 --_004_D136F8364A4CBmzanatyciscocom_ Content-Type: multipart/alternative; boundary="_000_D136F8364A4CBmzanatyciscocom_" --_000_D136F8364A4CBmzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with Paul, option 1 seems best. I think it could even be argued tha= t ISN/ISI should be eliminated, and EKT must always be sent separately in S= RTP/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 s= parse RTCP reporting (not full mesh). Mo On 3/23/15, 3:27 PM, Paul E. Jones > wrote: John, Option 1 strikes me as the simplest solution to the problem you describe wi= th minimal changes in the text. Option 2 would work, though I'm missing th= e 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. Paul ------ Original Message ------ From: "John Mattsson" > To: "IETF AVTCore WG" > Sent: 3/23/2015 8:15:48 AM Subject: [AVTCORE] EKT Problems with RTCP Hi, While editing the EKT draft I realized that EKT has major problems with RTC= P. +---+ =97------ 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 whe= n 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 ke= y. R re-keying: Here ROC || ISN has no meaning at all and S will have to do tr= ial 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_Pla= intext. This would then work similar to ISN. The Plaintext could contain bo= th, 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 ove= r SRTCP, forcing EKT to be used in both SRTP and SRTCP. - Option 2 The current EKT draft says =93MKI is no longer allowed with EKT (as MKI duplicates some of EKT's funct= ions)=94. Its rather EKT that duplicates MKI (RFC 3711) and one simple option would b= e to simply remove the EKT parts that duplicates MKI and instead mandate us= e of MKI. The EKT_Plaintext would then be: EKT_Plaintext =3D 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 R= TP 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 w= ere mandated for EKT, MKIs with the last bit =910=92 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, no= t robust, and vulnerable to replay attacks. Cheers, John JOHN MATTSSON MSc Engineering Physics, MSc Business Administration and Economics Ericsson IETF Security Coordinator Senior Researcher, Security Ericsson AB Ericsson Research F=E4r=F6gatan 6 SE-164 80 Stockholm, Sweden Phone +46 10 71 43 501 SMS/MMS +46 76 11 53 501 john.mattsson@ericsson.com http://www.ericsson.com/ --_000_D136F8364A4CBmzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3DFC71EC9F06184483659977B48E2D0B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I agree with Paul, option 1 seems best. I think it could even be argue= d 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 comple= x RTP scenarios, such as multiple RTP streams bundled in the same session w= ith sparse RTCP reporting (not full mesh).

Mo

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

John,
 
Option 1 strikes me as the simplest solution to the problem you descri= be 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 th= e endpoints are randomly generating SRTP master keys, isn't that sufficient?  Perhaps I'm missing something key.
 
Paul
 
------ Original Message ------
From: "John Mattsson" <john.mattsson@ericsson.com>
To: "IETF AVTCore WG" <av= t@ietf.org>
Sent: 3/23/2015 8:15:48 AM
Subject: [AVTCORE] EKT Problems with RTCP
 
Hi,

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

+---+ =97------ SRTP ---------> = +---+
| S | ------- SRTCP SR -----> | R |
+---+ <------ SRTCP RR ------ &#= 43;---+

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 
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 (Ini= tial SRTCP Index) t= o the EKT_Plaintext. This would then work similar to ISN. The <= span style=3D"font-family: 'Courier New';">Plaintext could contain both, or one of them. One alternative is that EKT contains b= oth ISN and ISI. Another alternative is that ISN is used in EKT over SRTP a= nd ISI in EKT over SRTCP, forcing EKT to be used in both SRTP and SRTCP.

- Option 2
The current EKT draft says

=93MKI is no longer allowed with EKT (as MK= I duplicates some of EKT's functions)=94. 

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

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

And the SRT(C)P packets would look like:
+------------+-------------+---= --+-----+-----+
| RTP Header | RTP Payload | MKI | TAG | EK= T |
+------------+-------------+---= --+-----+-----+
+--------------------+-------------= +-----+-----+-----+
| RTCP Packet Types  | SRTCP INDEX | M= KI | TAG | EKT |
+--------------------+-------------= +-----+-----+-----+

This would allow full flexibility in the us= e 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 mak= e 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 i= n the SRTP. If AEAD algorithms were mandated for EKT, MKIs with the last bi= t =910=92 could be mandated and the short EKT tag would not be needed.


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


Cheers,
John
JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and E= conomics
Ericsson IETF Security Coordinator 
Senior Researcher, Security

Ericsson AB
Ericsson Research
F=E4r=F6gatan 6
SE-164 80 Stockholm, Sweden
Phone +46 10 71 43 501
SMS/MMS +46 76 11 53 501
john.mattsson@ericsson.com

--_000_D136F8364A4CBmzanatyciscocom_-- --_004_D136F8364A4CBmzanatyciscocom_ Content-Type: image/png; name="unknown.png" Content-Description: unknown.png Content-Disposition: attachment; filename="unknown.png"; size=2991; creation-date="Tue, 24 Mar 2015 15:29:42 GMT"; modification-date="Tue, 24 Mar 2015 15:29:42 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAP8AAAADCAIAAADTOk7/AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAABKUlEQVRI De1TMU4DQQycu5yokNKglEhIfIEf8JEoHSU/gAfkATQ8gMcgGigR0CYSDVRhzdheL7sogT6602o1 6xmPvb67TkQAvKzu7l+v1x9PSbovWwm9A+4R1EhCFhjbB2UapUwTJqHPwU1lpYlhZSaRWAU3stOf KYIeXNLpnjFBOXaQiHswH02guChbk8bzT5NGSZNdnqViCEonohMBX4HepwIW/J/6lV5nbaWsEMs1 zp61lSqNJUCSZQEpWavoRSa2BkCB7wEG0UsyPoCySmBHshPOS1CxJoMoRf1Plh4ps3KuL7VUVumb uLdkrH7hB2qrAj7HNxfTxTkBO9Tn4e3q/fPR8biPE9jjCfAfeL689Qvmr/90Nj86PNvjO49XGydQ JnCynDv+BsiTWPQxCGmXAAAAAElFTkSuQmCC --_004_D136F8364A4CBmzanatyciscocom_--