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. There are e.g. several sections mentioning "base authentication tag"...

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.

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.

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

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.

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.

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.

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

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

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

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

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

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

- [Section 2.2]
"inbound SRTCP traffic" Should probably be "inbound traffic" or inbound SRTP/SRTCP traffic
	
- [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."

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

- [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

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

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

[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?

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

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

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

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

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

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

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

- [Section 8]
"denail" -> "denial"    
   
- [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.
   
- [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." 

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


------------------------------------------------------------------------------------
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 +46 10 71 43 501
SMS/MMS +46 76 11 53 501
john.mattsson@ericsson.com
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