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

From: [email-masked]
Date: Wed, 22 Oct 2014 12:14:05 -0700

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/

---

From: John Mattsson <[email-masked]>
Date: Thu, 23 Oct 2014 08:43:19 +0000

Hi,

I have submitted a new version of draft-ietf-avtcore-srtp-ekt. Some
updated were made by Dan Wing and the rest by me. The changes in the new
version are implementations of the suggestions posted on the list:

- The SRTCP compound packet problem is discussed
- Updated section titles to make them more consistent and somewhat shorter
- Editorials in Section 1 pointed out by Yi Cheng
- Several “key” clarified -> “SRTP master key” or “EKT key”
- In Section 3 the editorial pointed out by me is fixed.
- Section 3, clarified that there is only one new session parameter “EKT”,
which consists of three fields. This leads to several changes in the
section.
- The changes to MIKEY suggested by Yi Cheng has been implemented. This
allows for fewer changes and better backward compatibility.
- The MIKEY section has also been aligned with the SDP section making
EKT_Cipher optional.

I suggest that we have a new WGLC. And maybe Roni could get some people to
promise to review the draft.

Cheers,
John

On 22/10/14 21:14, "[email-masked]" <[email-masked]>
wrote:

>_______________________________________________
>Audio/Video Transport Core Maintenance
>[email-masked]
>https://www.ietf.org/mailman/listinfo/avt

---

From: John Mattsson <[email-masked]>
Date: Thu, 30 Oct 2014 10:51:18 +0000

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.

---

From: John Mattsson <[email-masked]>
Date: Thu, 30 Oct 2014 14:13:39 +0000

Here is a concrete proposal for a -04 version of Section 8 - Security
Considerations. Motivations are provided further down.

Cheers
John

New suggested text:

8.  Security Considerations

   EKT inherits the security properties of the SRTP keying mechanism it
   uses: SDP Security Descriptions, DTLS-SRTP, or MIKEY.

   With EKT, RTP senders and receivers MUST generate distinct SRTP
   master keys for each SRTP source (SSRC).  This property avoids any
   security concern over the re-use of keys, by empowering the SRTP
   layer to create keys on demand.  Note that the inputs of EKT are the
   same as for SRTP with key-sharing: a single key is provided to
   protect an entire SRTP session.  However, SRTP with EKT remains
   secure even in the absence of out-of-band coordination of SSRCs, and
   even when SSRC values collide.

   The EKT Cipher includes its own authentication/integrity check.  For
   an attacker to successfully forge a SRTP packet with a Full EKT
   Field, the attacker would need to defeat the authentication

   mechanisms of both the EKT Cipher and the SRTP authentication
   mechanism.

   The presence of the SSRC in the EKT Plaintext ensures that an
   attacker cannot substitute an EKT Ciphertext from one SRTP stream
   into another SRTP stream with a different SSRC.

   An attacker who strips a Full EKT Field from an SRTP packet may
   prevent the intended receiver of that packet from being able to
   decrypt it.  This is a minor denial of service vulnerability.
   Similarly, an attacker who modifies a SRTP packet in any way can
   disrupt service.

   An attacker could send packets containing either Short EKT Field or a
   falsified Full EKT Field, in an attempt to consume additional CPU
   resources of the receiving system.  In the case of the Short EKT
   Field, this field is stripped and normal SRTP or SRTCP processing is
   performed.  In the case of the Full EKT Field: If an invalid SPI is
   provided by the attacker, processing stops.  If a valid SPI is
   provided by the attacker, the receiving system will decrypt the EKT
   Ciphertext and with a probability of at least 2^-8 return an
   authentication failure (Step 3 of Section 2.2.2).  In the case the
   EKT Cipher does not return an authentication failure, the SSRC, ROC,
   and ISN checks of Section 2.2.2 will fail with a high probability
   causing EKT processing to stop.

   EKT can rekey an SRTP stream until the SRTP rollover counter (ROC) or
   SRTCP index needs to roll over.  Thus, new EKT Keys need to be
   established after 2^48 SRTP packets or 2^31 SRTCP packets are
   transmitted in a single SRTP stream.  Due to the relatively low
   packet rates of typical RTP sessions, this is not expected to be a
   burden.

   The EKT Key length MUST be at least as long as the SRTP master key
   length.

   An EKT Cipher MUST resist attacks in which both ciphertexts and
   plaintexts can be adaptively chosen and adversaries that can query
   both the encryption and decryption functions adaptively.

Old text:

8.  Security Considerations

   EKT inherits the security properties of the SRTP keying it uses:
   Security Descriptions, DTLS-SRTP, or MIKEY.

   With EKT, each SRTP sender and receiver MUST generate distinct SRTP
   master keys.  This property avoids any security concern over the re-
   use of keys, by empowering the SRTP layer to create keys on demand.
   Note that the inputs of EKT are the same as for SRTP with key-
   sharing: a single key is provided to protect an entire SRTP session.
   However, EKT remains secure even in the absence of out-of-band
   coordination of SSRCs, and even when SSRC values collide.

   The EKT Cipher includes its own authentication/integrity check.  For
   an attacker to successfully forge a full EKT packet, it would need to
   defeat the authentication mechanisms of both the EKT Cipher and the
   SRTP authentication mechanism.

   The presence of the SSRC in the EKT_Plaintext ensures that an
   attacker cannot substitute an EKT_Ciphertext from one SRTP stream
   into another SRTP stream.

   An attacker who strips a Full_EKT_Field from an SRTP packet may
   prevent the intended receiver of that packet from being able to
   decrypt it.  This is a minor denial of service vulnerability.
   Similarly, an attacker who adds a Full_EKT_Field can disrupt service.

   An attacker could send packets containing either Short EKT Field or
   Full EKT Field, in an attempt to consume additional CPU resources of
   the receiving system.  In the case of the Short EKT Field, this field
   is stripped and normal SRTP or SRTCP processing is performed.  In the
   case of the Full EKT Field, the attacker would have to have guessed
   or otherwise determined the SPI being used by the receiving system.
   If an invalid SPI is provided by the attacker, processing stops.  If
   a valid SPI is provided by the attacker, the receiving system will
   decrypt the EKT ciphertext and return an authentication failure (Step
   3 of Section 2.2.2).

   EKT can rekey an SRTP stream until the SRTP rollover counter (ROC)
   needs to roll over.  EKT does not extend SRTP's rollover counter
   (ROC), and like SRTP itself EKT cannot properly handle a ROC
   rollover.  Thus even if using EKT, new (master or session) keys need
   to be established after 2^48 packets are transmitted in a single SRTP
   stream as described in Section 3.3.1 of [RFC3711].  Due to the
   relatively low packet rates of typical RTP sessions, this is not
   expected to be a burden.

   The confidentiality, integrity, and authentication of the EKT cipher
   MUST be at least as strong as the SRTP cipher.

   Part of the EKT_Plaintext is known, or easily guessable to an
   attacker.  Thus, the EKT Cipher MUST resist known plaintext attacks.
   In practice, this requirement does not impose any restrictions on our
   choices, since the ciphers in use provide high security even when
   much plaintext is known.

   An EKT cipher MUST resist attacks in which both ciphertexts and
   plaintexts can be adaptively chosen.  An EKT cipher MUST resist
   attacks in which both ciphertexts and plaintexts can be adaptively
   chosen and adversaries that can query both the encryption and
   decryption functions adaptively.

Motivation:

- “each SRTP sender and receiver MUST generate distinct SRTP
master keys”

->

"RTP senders and receivers MUST generate distinct SRTP
master keys for each SRTP source (SSRC)."

A SRTP receiver should not generate a SRTP key, a RTP receiver
that sends SRTCP should. An RTP Receiver may be an SRTP sender.

- “Full EKT packet”
This term is not defined. Suggest change to “SRTP packet with Full EKT
Field”

- "cannot substitute an EKT_Ciphertext from one SRTP stream
   Into another SRTP stream”

Suggest adding “with a different SSRC”.

- Similarly, an attacker who adds a Full_EKT_Field can disrupt service.

Suggest adding “Similarly, an attacker who modifies a SRTP packet in any
way can
disrupt service.” to illustrate that this is the way all security
protocols behave
And not specific to EKT.

- I suggest removing “the attacker would have to have guessed
or otherwise determined the SPI being used by the receiving system.”

As SPI is sent in cleartext, it is obviously known to a non-stupid
attacker.

- “If a valid SPI is provided by the attacker, the receiving system will
decrypt the EKT ciphertext and return an authentication failure (Step
3 of Section 2.2.2).”

This will not happened all the time as the EKT Cipher uses a very short
Authentication tag. But I donut think this is not a problem as later steps
will fail.
Suggest replacing with:

“and with a probability of at least 2^-8 return an
authentication failure (Step 3 of Section 2.2.2). In the case the
EKT Cipher does not return an authentication failure, the SSRC, ROC,
and ISN checks of Section 2.2.2 will fail with a high probability
causing EKT processing to stop.”

- "new (master or session) keys need to be established after 2^48 packets”

This should not be SRTP keys, the key that need to be established is
a new EKT Key and this is needed also after 2^31 SRTCP packets.

Suggested new text:

"EKT can rekey an SRTP stream until the SRTP rollover counter (ROC) or
SRTCP index needs to roll over. Thus, new EKT Keys need to be
established after 2^48 SRTP packets or 2^31 SRTCP packets are
transmitted in a single SRTP stream. Due to the relatively low
packet rates of typical RTP sessions, this is not expected to be a
burden.”

- “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 meant by the “SRTP cipher”

I suggest simplifying the requirement. Suggested new text:

“The EKT Key length MUST be at least as long as the SRTP master key
length."

- “Part of the EKT_Plaintext is known, or easily guessable to an
attacker. Thus, the EKT Cipher MUST resist known plaintext attacks.
In practice, this requirement does not impose any restrictions on our
choices, since the ciphers in use provide high security even when
much plaintext is known.

An EKT cipher MUST resist attacks in which both ciphertexts and
plaintexts can be adaptively chosen. An EKT cipher MUST resist
attacks in which both ciphertexts and plaintexts can be adaptively
chosen and adversaries that can query both the encryption and
decryption functions adaptively.”

This part contains a lot of redundant text. The EKT Cipher
should resist known plaintext attacks even if the plaintext is not
easily guessable. The second paragraph contains more strict requirements.

Suggestion:

“An EKT Cipher MUST resist attacks in which both ciphertexts and
plaintexts can be adaptively chosen and adversaries that can query
both the encryption and decryption functions adaptively."