Re: [AVTCORE] draft-ietf-avtcore-srtp-ekt-01 review

[Dan Wing <[e-mail]>]

On Nov 4, 2013, at 7:23 AM, John Mattsson <[e-mail]> wrote:

> Hi, 
> 
> I reviewed draft-ietf-avtcore-srtp-ekt-01 focusing on security aspects. I have only reviewed Sections 1,2,8 yet, but these should be consistent and complete without having to read the sections on specific key management protocols (3,4,5).
> 
> In general I think the draft is well written and useful, but I get the feeling that when parts of the draft have changed in the past, the rest of the document has not always been changed to reflect these changes.

Thanks for your detailed review and for summarizing the major points at the top.  I believe our edits will resolve your points, and will respond to each below.  There is a separate email on some of the major points (subject="changes planned for EKT") you should see shortly.


> There are e.g. several sections mentioning "base authentication tag"...

Fixed.

> I also think the draft misses to analyze the various replay attacks that can be done on the EKT layer. The draft writes that SSRC sync on the key management layer is no longer needed, but then EKT uses SSRC for replay protection. This makes replay attacks of the Full EKT fields possible and I think this need to be addressed in one way or another.

Your review described replay attacks in more detail below so I will comment on them below.

> Furthermore I think the draft must control how either SSRCs or SRTP master keys are generated, and the MKI handling needs to be described in more detail.

One thing we plan to change based on your review (details below) is that SRTP master keys cannot be re-used at all.  This is discussed in more detail, below.


> 
> /John
> 
> 
> - [General]
> The specified replay protection relies on encoding the SSRC in the Full EKT Field and not allowing the ROC to decrease. But without SSRC sync on the key management level, there will be SSRC collisions and the document seems to miss the fact that the ROC also rolls over, RFC3711 states "the sender side MUST increment ROC by one, modulo 2^32".

David McGrew found RFC3711 is unclear what should happen after 2^48 packets are sent and the ROC needs to roll over.  RFC3711 says:

   As the rollover counter is 32 bits long and the sequence number is 16
   bits long, the maximum number of packets belonging to a given SRTP
   stream that can be secured with the same key is 2^48 using the pre-
   defined transforms.  After that number of SRTP packets have been sent
   with a given (master or session) key, the sender MUST NOT send any
   more packets with that key.  (There exists a similar limit for SRTCP,
   which in practice may be more restrictive, see Section 9.2.)  This
   limitation enforces a security benefit by providing an upper bound on
   the amount of traffic that can pass before cryptographic keys are
   changed.  Re-keying (see Section 8.1) MUST be triggered, before this
   amount of traffic, and MAY be triggered earlier, e.g., for increased
   security and access control to media.  Recurring key derivation by
   means of a non-zero key_derivation_rate (see Section 4.3), also gives
   stronger security but does not change the above absolute maximum
   value.

Our interpretation is that when ROC rolls over, new keys need to be established using DTLS-SRTP, MIKEY, Security Descriptions -- not by EKT.  EKT does not provide for ROC rollover, just as RFC3711 does not provide for ROC rollover.  We aren't worried about ROC rollover because the ROC space is large.  Assuming my math is correct, 100,000 packets per second (which is well in excess of what I have heard any RTP system utilize), the ROC space is consumed in 89 years (2^48/100000/86400/365=89 years).

Added to the Security Considerations section:
   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 retransmitted 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.



> I think the following replay attacks are possible:
> 
> Replay attack 1:
> If the SRTP master key has changed, for example by sending a Full EKT field with (SRTP master key=2, ROC=X, ISN=Y) an attacker can replay an old Full EKT field with (SRTP master key=1, ROC=X, ISN=0) causing the receiver to update to the old key. The receiver will not recover until a Full EKT field arrives from the sender.

David and I discussed a few mitigations, but the existing ISN and ROC communicated in the Full EKT Field can prevent such an attack if we add text to require a receiver to ignore a Full EKT Field if the receiver has authenticated an SRTP packet with an RTP sequence number and ROC greater than the Full EKT Field.  With that in mind, I added the following to Inbound processing:

                If the ISN from the EKT_Plaintext is less than the RTP
                sequence number of an authenticated received SRTP packet,
                then EKT processing halts.

with that change, an attacker would only be successful at replaying an old Full EKT Field if the receiver had not received SRTP packets since the earlier legitimate transmission of that Full EKT Field.  Is that sufficient mitigation?


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



> Replay attack 3:
> For extremely long sessions (over 2^48 SRTP packets), the ROC will roll over. An attacker can then replay a Full EKT Field with a high ROC (e.g. 2^32-1). The receiver will update the ROC and will not recover from this until after up to 2^48 packets.

We do not intend for EKT to extend SRTP's rollover counter.


> While replay attacks that lead to short term disturbances may be tolerable, replay attacks leading to long term denial of service with a single packet is in my view not acceptable.
> 
> Suggestions:
> The only solution approach I see directly (except using time stamps and synchronized clocks) is to require SRTP master keys to be fresh and randomly generated, and then somehow bind the EKT layer to the current SRTP master key. But this needs further thought.

For another attack you described below, we agree fresh SRTP master keys are useful.  See below.

If we follow SRTP's lead and don't allow ROC to roll over, we believe binding EKT layer to the SRTP master key won't be necessary to thwart the above three replay attacks.



> 
> - [General]
> "With this method, SRTP entities are free to choose SSRC values as they see fit, and to start up new SRTP sources with new SRTP master keys (see Section 2.2) within a session without coordinating with other entities via signaling or other external means.  This fact allows to reinstate the RTP collision detection and repair mechanism"
> 
> "EKT does not control the manner in which the SSRC and master key are generated; it is only concerned with their secure transport."
> 
> "even if those two streams are using the same SRTP master key"
> 
> It is not possible to do both these things at the same time. This leads to IV reuse and the potential loss of confidentiality and integrity. Furthermore the SSRC collision and repair mechanism in RFC3550 only handles SSRC collisions happening at the same time, SRTP needs protection also against SSRC collisions happening at different times.
> 
> I think the draft must set strict requirements on the use of shared and reused keys:
> "All SRTP master keys MUST be fresh and randomly generated; they MUST NOT be shared or reused in any way."

Agreed, added to Section 2.2, Packet Processing and State Machine.


> - [General]
> I think the draft should give recommendations or default values for how often the Full EKT Field should be sent.

Magnus had a similar observation in his review.  I re-worked Section 2.6 to now read:

   2.6.  Timing and Reliability Consideration

   A system using EKT has the SRTP keys distributed with EKT, rather
   than with call signaling.  This means a receiver cannot authenticate
   or decrypt the SRTP or SRTCP packets without the EKT key, which has
   direct harm on the user-visible delay to session establishment.  This
   section describes how to reliably and expediently deliver EKT keys to
   receivers.

   There are three cases to consider.  The first case is a new sender
   joining a session which needs to communicate its key to all the
   receivers.  The second case is a sender changing its key which needs
   to be communicated to all the receivers.  The third case is a new
   receiver joining a session already in progress which needs to know
   the sender's key.

   New sender: A new sender SHOULD send a packet containing the Full EKT
   Field as soon as possible, always before or coincident with sending
   its initial SRTP packet.  It is RECOMMENDED that a packet containing
   the Full EKT Field be transmitted 3 times (to accomodate packet
   loss).  The sender can determine a receiver has received the new EKT
   key by receipt of RTCP receiver report or explicit ACK for a sequence
   number with the new key, and this MAY be used to cease re-
   transmitting the Full EKT Field if all receivers have received the
   EKT key.

   Rekey: When an SRTP source using EKT over SRTCP performs a rekeying
   operation, there is a race between the actual rekeying signaled via
   SRTCP and the SRTP packets secured by the new keying material.  If
   the SRTP packets are received first, they will fail authentication;
   alternatively, if authentication is not being used, they will decrypt
   to unintelligible random-looking plaintext.  (Note, however, that
   [RFC3711] says that SRTP "SHOULD NOT be used without message
   authentication".)  In order to address this problem, the rekeying
   event can be sent before packets using the new SRTP master key are
   sent (by use of the ISN field).  As with the new sender case, above,
   the sender can determine a receiver has received the new EKT key by
   receipt of an RTCP receiver report or explicit ACK for a sequence
   number with the new key, and this MAY be used to cease re-
   transmitting the Full EKT Field if all receivers have received the
   EKT key.  Another solution involves using an MKI at the expense of
   added overhead in each SRTP packet.  Alternatively, receivers MAY
   want to delay discarding packets from known SSRCs that fail
   authentication in anticipation of receiving a rekeying event via EKT
   (SRTCP) shortly.  Another approach is to send the Full EKT Field over
   SRTP, to share fate with the SRTP packet itself.

   New receiver: When a new receiver joins a session it does not need to
   communicate its sending key (because it is a receiver).  If it
   anticipates becoming a sender, it SHOULD communicate its key as soon
   as practical.  When a new receiver joins a session the sender is
   generally unaware of the receiver joining the session.  Thus, senders
   SHOULD periodically transmit the Full EKT Field.  That interval
   depends on how frequently new receivers join the session, the
   acceptable delay before those receivers can start processing SRTP
   packets, and the acceptable overhead of sending the Full EKT Field.
   The RECOMMENDED frequency is with every key frame if sending video
   and using EKT over SRTP, or as often as allowed by the RTCP profile
   timing rules, or every 5 seconds otherwise.

   For all three cases above, if SRTCP is used to send EKT, the timing
   rules associated with the negotiated profile MUST be obeyed (e.g.,
   RTP/SAVP or RTP/SAVPF).  Note that per Section 6.2 of [RFC3550], it
   is permissible to send a compound RTCP packet immediately after
   joining a unicast session (but not a multicast session).

   EKT can be transported over SRTCP, but some of the information that
   it conveys is used for SRTP processing; some elements of the EKT
   parameter set apply to both SRTP and SRTCP.  Furthermore, SRTCP
   packets can be lost and both SRTP and SRTCP packets may be delivered
   out of order.  This can lead to various race conditions if EKT is
   transported over SRTCP but not SRTP, which we review below.

   The ROC signaled via EKT over SRTCP may be off by one when it is
   received by the other party(ies) in the session.  In order to deal
   with this, receivers should simply follow the SRTP packet index
   estimation procedures defined in Section 3.3.1 [RFC3711].



> Not only to ease implementation, but also as this has effects on what an passive attacker can learn from just looking at the packets, and the effects of an active attacker replaying Full EKT Fields.

> - [Section 1]
> The term "SRTP source" seems to sometimes mean "SRTP endpoint"/"SRTP participant" and sometimes SSRC. I suggest replacing all occurrences of "SRTP source" with one of these terms. 

Magnus had suggested using "SRTP source (SSRC)" to be clearer that it is per-SSRC; I'll try that edit and see how it works.

> 
> - [Section 1]
> "An SRTP endpoint using EKT can generate new keys whenever an existing SRTP master key has been overused, or start up a new SRTP source to replace an old SRTP source that has reached the packet-count limit."
> 
> This seems to imply that both the key and the SRTP source have limits, but according to RFC3711 it is only the key that has a packet counter and a limit. The ROC rolls over modulo 2^32 and the same SSRC can be used for infinity many packets as long as the key is refreshed at least every 2^48 packet.

When the ROC needs to roll over we intend the key to be refreshed outside of EKT (using SDescriptions, MIKEY, DTLS-SRTP etc.).  I added some text in the introduction to hopefully cover that.


> - [Section 1]
> "EKT provides a way for an SRTP session participant, either a sender or a receiver, to securely transport its SRTP master key and current SRTP rollover counter to the other participants in the session.
> 
> Should this really be "or a receiver"? The handling for a receiver sending EKT does not seem to be defined.

When using EKT over SRTCP, an endpoint might be receive-only (while listening to a group session) and notice an SSRC collision and change its SSRC and signal its new SSRC by sending an Full EKT Field packet over RTCP.

(However, based on Magnus' review, we are considering pulling support for EKT over RTCP.  That is discussed in a different email.)



> - [Section 1]
> "using the KEK as the encryption key"
> I think it would be best to use "EKT Key" throughout the document and then maybe add "using the EKT key as KEK" in Section 2.3.1.

I removed that sole use of "KEK", but I was not sure of the addition you are proposing for Section 2.3.1.



> - [Section 2.1]
> "Reserved:  MUST be all zeros on transmission, and MUST be ignored on reception."
> 
> Length of Reserved field is missing in the text. Suggestion:
> "Reserved:  The length of this field is fixed at 7 bits. MUST be all zeros on transmission, and MUST be ignored on reception."

Done.

> - [Section 2.1]
> The figures are not really showing "examples", they seem to show the general format. I suggest removing "Example of" and "An example of".

Done.

> - [Section 2.2]
> "inbound SRTCP traffic" Should probably be "inbound traffic" or inbound SRTP/SRTCP traffic

Done.

> 	
> - [Section 2.2.1]
> "The creation of the EKT field MUST precede the normal SRTP or SRTCP   packet processing, so that the ROC used in EKT is the same as the one   used in the SRTP or SRTCP processing."
> 
> ROC is not used in SRTCP processing and I think it is better to move the "MUST" and write: "The ROC used in EKT MUST be the same as the one used in the SRTP processing."

Added.  I left the "... MUST precede..." sentence, because EKT process does need to precede both normal SRTP and normal SRTCP packet processing.


> - [Section 2.2.1]
> - "Not all SRTP or SRTCP packets need to include the EKT key, but it SHOULD be included with some regularity, e.g., every second or every ten seconds, though it need not be sent on a regular schedule. "
> 
> Is this left from some old version? EKT key is not sent anywhere...

Should have been Full EKT Field, and I changed it accordingly in the upcoming version.


> - [Section 2.2.1]
> "If the Short format is used, an all-zero Reserved octet"
> Maybe just "all-zero octet" as only 7 bits are reserved

Thanks, fixed.


> - [Section 2.2.2]
> I suggest changing "tag" to "field" to be consistent.

Thanks, fixed.  I found some other occurrences which of "Short EKT Tag" or "Full EKT Tag" which I also changed to "[Short|Full] EKT Field" for consistency.


> - [Section 2.2.2]
> I think the handling when MKI is used needs to be more well-defined.
>  * Is the old or new SRTP master key used for outbound processing of the packet containing the Full EKT field?
>  * If the old key is used, then is should be mentioned that the normal processing for that packet may fail.
>  * Is ISN and ROC ignored when MKI is used?
> 
> The current processing does also seem to open up for attacks. Assume that SRTP Master Key=1 and MKI=1 is in use. As I understand it, to prepare for future key update, the sender sends a Full EKT field containing SRTP Master Key=2 in a packet with MKI=2. If an attacker just changes that MKI from 2 to 1, the receiver will begin associating SRTP Master Key=2 with MKI=1 and all incoming packet processing will fail at least until the sender switches to MKI=2.

David and I discussed the interaction of ISN and MKI at length.  We would like to pull MKI from EKT entirely.  See a separate email, subject="changes considered for draft-ietf-avtcore-srtp-ekt-02" for details.

> 
> [Section 2.2.2]
> "If the crypto context is not new, then the rollover counter in the context MUST NOT be set to a value lower than its current value."
> 
> How does this work when the ROC rolls over and starts at 0 again?

It can't; if ROC rolls over fresh MIKEY/SDESC/DTLS-SRTP keying needs to occur.


> 
> - [Section 2.3]
> "EKT uses an authenticated cipher to encrypt the SRTP master keys, ROC, and ISN."
> Also SSRC, I suggest "EKT uses an authenticated cipher to encrypt the EKT Plaintext."
> 
> - [Section 2.3]
> " EKT uses an authenticated cipher"
> "where N is at least M"

> If the cipher is authenticated then N is larger than M. I suggest either
> "EKT by default uses an authenticated cipher" or "N is larger than M". 

We are updating this section of text, but I neglected to understand part of the edits from David McGrew.  A few more cycles and I'll have it, and will include that change in -02 and I will reply to this thread with that change.



> - [Section 2.3.1]
> "which can be used with plaintexts larger than 16 bytes in length" 
> Not wrong, but why mention it, RFC5649 can be used with plaintexts as short as one octet. I suggest just writing: "Key Wrap with Padding [RFC5649] algorithm, which is suitable for keys of any size."
> 
> - [Section 2.3.1]
> "It requires a plaintext length M that is at least eight bytes"
> True for RFC3394 but not RFC5649, which can be used with plaintexts as short as one octet. 
> 
> - [Section 2.3.1]
> "it returns a ciphertext with a length of N = M + 8 bytes"
> 
> This is true for RFC3394 but not RFC5649 (unless M is a multiple of 8). For RFC5649, I think it should be "N = 8 * (ceil(M / 8) + 1) bytes".

Similarly as above, I am having David McGrew help with these changes to ensure everything is aligned properly.




> - [Section 2.6]
> Quite much discussion about "Base Authentication Tag", which is not defined (I assume it was in an earlier version). Should be rewritten without "Base Authentication Tag".

Fixed, thanks.  Is now Full EKT Field.


> 
> - [Section 8]
> "With EKT, each SRTP sender and receiver can generate distinct SRTP master keys"
> 
> As you seem to recommend no SSRC sync at the key management level, I would say "MUST generate distinct SRTP master keys"

Done.


> - [Section 8]
> "EKT provides complete security, even in the absence of further out-of-band coordination of SSRCs, and even when SSRC values collide."
> 
> I do not understand what is meant with "complete security"? E.g. EKT does not provide complete security against replay attacks. I would recommend removing the vague "complete security" and instead describe explicitly what EKT provides.

Done.


> - [Section 8]
> "In order to avoid potential security issues, the SRTP authentication tag length used by the base authentication method MUST be at least ten octets."
> 
> There is no base authentication method defined. I assume there was in an earlier draft, and that there is no longer any need to put restrictions on the SRTP tag length.

Yes, thanks.  Removed.


> - [Section 8]
> "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, even if those two streams are using the same SRTP master key.  This is important because some applications may use the same master key for multiple streams."
> 
> This is not really true as you recommend to not have strict SSRC synchronization. And if you do not then "even if those two streams are using the same SRTP master key" may lead to loss of confidential and integrity.

Thanks.   Removed.


> - [Section 8]
> "denail" -> "denial"    

Thanks, fixed.


> - [Section 8]   
> "An attacker learns from EKT when SRTP Master Keys change."
> 
> Maybe change to "roughly when" or something similar. And if you send the Full EKT field with regular intervals, I think an attacker learns nothing. Otherwise the attacker learns approximately when. Maybe:
> 
> "If the full EKT field is sent with regular intervals, and MKI is not used, an attacker cannot learn when SRTP Master Keys change."
> 
> But I do not see this as an attack or important to mention. I would also be fine with just removing the text.

Agreed.  Removed.


> 
> - [Section 8]   
> "The EKT Cipher MUST be at least as strong as the encryption and authentication operations used in SRTP."
> 
> The authentication (64-bit tag) in the default EKT Cipher is not as strong as the default SRTP authentication (80-bit tag). As not even RFC3711 requires that the encryption and authentication operations used in SRTP are as strong as the SRTP master key, I do not think EKT should either. 
> 
> I suggest: "The confidentiality of the EKT Cipher MUST be at least as strong as the SRTP Master Key." 

Combined with Magnus' suggestion to read:
  "The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher."


> - [Section 8]   
> "For each randomly chosen key, the encryption and decryption functions cannot be distinguished from a random permutation and its inverse with non-negligible advantage."
> "The advantage is defined as the difference between the probability that the adversary will identify the cipher as such and the probability that the adversary will identify the random permutation as the cipher, when each case is equally likely.
> 
> Even the current EKT cipher fails this as it expands the plaintext ;) For the encryption function you could write "the encryption function cannot be distinguished from a random function", but not for the default decryption function as it can be distinguished even from a random function (it only accepts 1 of 2^-64 bitstrings of a given length). 
> 
> Maybe it's easiest to just remove the cryptographic details, leaving only:
> 
> "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."  

Adopted your text, thank you.


Thanks again for your detailed review!

-d


> 
> 
> ------------------------------------------------------------------------------------
> JOHN MATTSSON
> MSc Engineering Physics, MSc Business Administration and Economics 
> Senior Researcher, Security 
> 
> Ericsson AB
> Security Research
> Färögatan 6
> SE-164 80 Stockholm, Sweden
> Phone [phone]
> SMS/MMS [phone]
> [e-mail]
> www.ericsson.com
> 
> 
> 
> 
> This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt