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

[John Mattsson <[e-mail]>]

Hi,

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.

Cheers
John


- 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
packet).

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
end-to-end.

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
sections.



- 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
states:

“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
SSRCs.

- 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
EKT SPI)

  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”,
etc.

-  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, "[e-mail]" <[e-mail]>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> 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
>
>Abstract:
>   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:
>https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-ekt/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-03
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-srtp-ekt-03
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>Audio/Video Transport Core Maintenance
>[e-mail]
>https://www.ietf.org/mailman/listinfo/avt