Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-ekt-03.txt

John Mattsson <> Thu, 30 October 2014 10:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 417CB1AD0C0 for <>; Thu, 30 Oct 2014 03:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EErJN0sqojDC for <>; Thu, 30 Oct 2014 03:51:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 854321AD0B9 for <>; Thu, 30 Oct 2014 03:51:21 -0700 (PDT)
X-AuditID: c1b4fb2d-f79fc6d000001087-8a-5452182795e7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 67.FC.04231.72812545; Thu, 30 Oct 2014 11:51:19 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 11:51:19 +0100
From: John Mattsson <>
To: "" <>
Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-ekt-03.txt
Thread-Index: AQHP7iyVPs/rDYPpOEG/wuYRXYocBpxIgwmA
Date: Thu, 30 Oct 2014 10:51:18 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvja66RFCIwd8NmhYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoErY//DCcwF2yIrzv2axNTAOCG8i5GTQ0LAROLYhifsELaYxIV7 69m6GLk4hASOMEp83LWCCcJZwijxYHcfE0gVm4CBxNw9DWwgtoiAokTrtc+MXYwcHMICrhIH LuRBhN0kfq7YwgJhG0nMv74WrJxFQFXi8NaJYDavgLnEv+YeMFtIwFHi9MJOsHpOASeJb71d YHFGoIO+n1oDtpZZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B8riC0qoCfxbMNmdpBzJASUJKZt TQMxmQU0Jdbv0oeYYi2xqf8DC4StKDGl+yE7xDWCEidnPmGZwCg+C8myWQjds5B0z0LSPQtJ 9wJG1lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgVF1cMtv3R2Mq187HmIU4GBU4uH98DAw RIg1say4MvcQozQHi5I476Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MNZsvuNnpf9T bt4iAYZ/vNOZgy87OH0u79J1Pxb6smx6QuvBV3uE170p81LQuPxpqczz+csrY/zOv100+eV/ 9T6Tv9OMSy9YNZ9M+s/W78d5b7Lkk31//0QuXjW7rGvFYu10qcAb6ayHz+lKTI45+H/qu6ef Hqas+yzb/SvpSeWEnP8i2luus0grsRRnJBpqMRcVJwIAWlTf8osCAAA=
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-ekt-03.txt
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: Thu, 30 Oct 2014 10:51:28 -0000


I have now reviewed Section 1-2 in detail, and I see several things that
need fixing. Let’s discuss some of these issues in Honolulu, based on any
comments, I will make more concrete suggestions and mail of a draft -04 on
the list.


- SRTCP Compound packets
If I understand correctly, the solution outlined in Section 2.5 for
compound packages suggests end-to-end EKT with hob-by-hop SRTCP, this
seems strange. Futhermore the solution outlined for compound packages is
clearly not detailed enough for interworking implementations, and it goes
against things stated earlier in the draft (EKT placed last in SRTCP

The only benefits I see with such a solution would be to enable EKT in
SRTCP but not SRTP, in scenarios where SRTCP is hop-by-bop but SRTP is

Suggestion: Skip the suggested solution and require EKT in both SRTP and
SRTCP for these cases (SRTCP is hop-by-bop but SRTP is end-to-end).

- SRTP master salt length
“  The master salt length for the offered cipher suites MUST be the
   same.  In practice the easiest way to achieve this is by offering the
   same crypto suite.”

1. This text is strangely places in the middle of EKT Cipher discussion.
2. RFC3711 is completely unaware of cipher suites, this is SDESC only.
3. For RFC3711 I actually don’t see any problem. AES-CM is not mandating
any specific master salt lengths, neither does AES-GCM. The only fixed
lengths of SRTP master salt is in the SDESC ciphersuites and DTLS-SRTP
protection profiles. E.g. using 112 bit master salt for GCM and 96 bit for
AES-CM is fine according to both RFC3711 and
draft-ietf-avtcore-srtp-aes-gcm-14. The PRF is SRTP will then derive a
session salt of the needed length.

Suggestion: Any salt restrictions should be moved to the key management

- SRTP master key length
Table 4 gives the idea that the SRTP encryption transform determines the
length of the
SRTP master key, this is wrong. The SRTP encryption transform only
determines the
length of the SRTP session key. RFC3711 kan make use of SRTP master keys
of any length,
the PRF will derive the correct session key length. Section 9.2 of RFC3711

“users having concerns about this are RECOMMENDED to instead use a 192 bit
master key in the key derivation.”

Suggestion: Change the table to show EKT lengths for given example
combinations of SRTP master key lengths and EKT Ciphers.

- Default and mandatory EKT ciphers.
Section 2.3.1 mandates EKT Cipher per SRTP encryption transform, this is
not in line with
RFC3711 which allows e.g. a 192 bit master key to be used with AES-128. If
something should determine EKT Cipher its the SRTP master key length.

Suggestion: Simply state that the security is given by the weakest link,
or mandate EKT Key length based on SRTP master key length,

- Default and mandatory EKT ciphers.
“  The confidentiality, integrity, and authentication of the EKT cipher
   MUST be at least as strong as the SRTP cipher.”

This is clearly not possible as the EKT cipher uses a 8-bit authentication
tag, and what is the “SRTP cipher”

Given the complex combination of EKT Cipher, EKT Key, SRTP master key,
SRTP encryption session key, SRTP encryption transform, SRTP
authentication session key, SRTP SRTP authentication authentication
transform, and SRTP PRF, I will not even try to come up with
correct sentence capturing all of them.

Suggestion: Simply state that the security is given by the weakest link,
or mandate EKT Key length based on SRTP master key length.

- Replay attack 2:
>> If there is a SSRC collision or the same SSRC has previously been used,
>>an attacker
>> can replay a Full EKT Field with a high ROC. The receiver will update
>>the ROC and
>> will not recover from this until after up to 2^48 packets.

>Here is our understanding of Replay Attack 2:  There are two senders
>using the same SSRC, >let's call them Alice and Bob who happen to use the
>same SSRC.  Alice has been >transmitting for a while and her Full EKT
>Field indicates with SSRC=A with a high ROC and >her SRTP master key.
>Bob joins and sends his Full EKT Field with his same SSRC=A, ROC=0
>>(because new senders have a ROC=0) and his SRTP master key.  In a desire
>>to DoS traffic >from Bob, the attacker injects Alice's Full EKT Field.
>>This same sequence could happen >in the absence of an attacker if Alice
>>or Bob are ignorant of their SSRC collision and >they just happily send
>>their Full EKT Field.

>We disagree this attack is possible, because the first step of step 5 of
>Section 2.2.2:
> " 5.  If the ROC from the EKT_Plaintext is less than the ROC in the
>       SRTP context, then packet processing halts. "

I don’t see how this would stop anything, Your description of the attack
is correct, Alice
Full EKT Field is replayed meaning the the ROC from the EKT_Plaintext is
larger (not less)
than the ROC in the SRTP context.

So I continue to think the attack is possible (on the EKT level), unclear
how serious it is if combined with SSRC collision detection, and would
there be a difference if Alice has left the session?

- Section 1
“to replace an old SRTP source that has reached the packet-count limit”
I think this is wrong. According to RFC3711, keys have packet counts not

- Section 1
“EKT does not allow SRTP's ROC to rollover”
Should also mention the SRTCP index

- Section 2.1
As Ciphertext and SPI is only included in some packets. I suggest writing
that EKT Field is included.

- Section 2.1
“the SRTP master key associated with the indicated SSRC”
This is not true if ISN > SEQ.

- Section 2.1
I don’t think the EKT SPI can identify SSRC... (as there is several per

  Suggestion: State that the EKT parameter set consists of EKT Key, EKT
Cipher, and SRTP master key length, and master salt.

- Different capitalisation of words

  Suggestion:  For RFC3711 terms like “SRTP master key” the RFC3711
spelling should be used. For EKT terms I suggest: “EKT Key”, “EKT Cipher”,

-  The document should spell out the specific key i.e. “STRP master key”
or “EKT key”

- Removing “and other information”, e.g. I think EKT only provides secure
transport of SRTP master key and ROC.

On 22/10/14 21:14, "" <>

>A New Internet-Draft is available from the on-line Internet-Drafts
> This draft is a work item of the Audio/Video Transport Core Maintenance
>Working Group of the IETF.
>        Title           : Encrypted Key Transport for Secure RTP
>        Authors         : John Mattsson
>                          David A. McGrew
>                          Dan Wing
>	Filename        : draft-ietf-avtcore-srtp-ekt-03.txt
>	Pages           : 45
>	Date            : 2014-10-20
>   Encrypted Key Transport (EKT) is an extension to Secure Real-time
>   Transport Protocol (SRTP) that provides for the secure transport of
>   SRTP master keys, Rollover Counters, and other information.  This
>   facility enables SRTP to work for decentralized conferences with
>   minimal control.
>   This note defines EKT, and also describes how to use it with SDP
>   Security Descriptions, DTLS-SRTP, and MIKEY.  With EKT, these other
>   key management protocols provide an EKT key to everyone in a session,
>   and EKT coordinates the SRTP keys within the session.
>The IETF datatracker status page for this draft is:
>There's also a htmlized version available at:
>A diff from the previous version is available at:
>Please note that it may take a couple of minutes from the time of
>until the htmlized version and diff are available at
>Internet-Drafts are also available by anonymous FTP at:
>Audio/Video Transport Core Maintenance