[Perc] Review of draft-ietf-perc-srtp-ekt-diet-01

[Russ Housley <[e-mail]>]

In Berlin, I agreed to d a review of draft-ietf-perc-srtp-ekt-diet-01 by the end of August.  Here is my review.

I have sent a more complete review to the authors.  I have included editorial comments in the review sent to the authors.  I stick to technical comments in this posting.


Figure 1 is incomplete.  I think that the “2” in the right margin is supposed to represent the EKT_Msg_Type_Full.


Section 2.1 says:

   EKT_Ciphertext:  The data that is output from the EKT encryption
      operation, described in Section 2.3.  This field is included in
      SRTP packets when EKT is in use.  The length of this field is
      variable, and is equal to the ciphertext size N defined in
      Section 2.3.  Note that the length of the field is inferable from
      the SPI field, since the SPI will indicate the cipher being used
      and thus the size.

This is not correct!  Two things neet to be known to figure out the length.  First, the cipher being used to encrypt the EKT_Plaintext, and second the size of the SRTP master key. RFC 3771 says that the master key can be 128, 192, or 256 bits.  I think that the SPI only tells one of these.


Section 2.1 says:

   Time to Live (TTL):  The maximum amount of time that this key can be
      used.  A unsigned 16 bit integer representing duration in seconds.
      The SRTP Master key in this message MUST NOT be used for
      encrypting or decrypting information after this time.  Open Issue:
      does this need to be absolute time not duration?  TODO: discuss in
      security section.

If a new participant joins, do they need to know when the start time for the TTL.  This might not be a problem is the sender is the only party doing the enforcement.  If a recipient is expected to discard any traffic after the TTL expires, then the recipient will need to know the absolute time as well as the TTL.


Section 2.1 says:

   Security Parameter Index (SPI):  This field indicates the appropriate
      EKT Key and other parameters for the receiver to use when
      processing the packet.  Each time a different EKT Key is received,
      it will have a larger SPI than the previous key (after taking
      rollover into account).  The length of this field is 16 bits.  The
      parameters identified by this field are:

I am confused here.  I thought the SPI identified the cipher, key, and associated parameters needed to decrypt the EKT_Ciphertext. Two different SRTP sources can use the same SPI value, and the will identify two different keys.

Why does the SPI value monotonically increase?  Since it is assigned by the SRTP source, we have no idea when any given participant will see it for a long-lived conference.


Section 2.2 says:

   All SRTP master keys MUST NOT be re-used, MUST be randomly generated
   according to [RFC4086], and MUST NOT be equal to or derived from
   other SRTP master keys.

You do not really want people to write code to check that the randomly generated makter key does not match a previously generated master key.  I suggest:

   SRTP master keys MUST be randomly generated, and [RFC4086] offers
   some guidance about random number generation.
   SRTP master keys MUST NOT be re-used for any other purpose, and
   SRTP master keys MUST NOT be derived from other SRTP master keys.

That said, this text is out of place.  It does not belong in the discussion of packet processing and the state machine.


Section 2.2.2 says:

   Inbound EKT processing MUST take place prior to the usual SRTP or
   SRTCP processing.  The following steps show processing as packets are
   received in order.

Will an implementation ever be doing SRTP with EKT with some sessions and SRTP without EKT for other sessions at the same time? If so, how does the inbound processing determine whether an EKT is present or not?


Section 2.3.1 says:

   The default EKT Cipher is the Advanced Encryption Standard (AES) Key
   Wrap with Padding [RFC5649] algorithm.  It requires a plaintext
   length M that is at least one octet, and it returns a ciphertext with
   a length of N = M + 8 octets.  

This only true if len(M) is a multiple of 64 bits.  Both examples in Section 6 of RFC 5649 show cases where this equation is incorrect. Figure 4 also shows that this equation is incorrect.

The equation should be: N = M + (M mod 8) + 8


Section 2.1 does not agree with Figure 4.  Section 2.1 says that the length field and the following message type are counted.  The values in Figure 4 only accommodates the SPI of 2 octets.


Section 2.3.2 says:

   Other specifications may extend this one by defining other EKT
   ciphers per Section 7.  This section defines how those ciphers
   interact with this specification.

Section 7 does not tell how to register more EKT ciphers.


Section 2.6 says:

   Rekey: By sending EKT over SRTP, the rekeying event shares fate with
   the SRTP packets protected with that new SRTP master key.

Yes, but packet loss is possible here too.  Should the first three packets using the new key contain the EKT?


Figure 6 (Handshake Message Flow) goes beyond the handshake messages.


Section 5 says:

   An attacker could send packets containing a Full EKT Field, in an
   attempt to consume additional CPU resources of the receiving system
   by causing the receiving system will decrypt the EKT ciphertext and
   detect an authentication failure

Since you recommend sending the EKT on more than one consecutive packet, is there an easy way to avoid processing the same EKT on the subsequent packets without doing all of the work?


Section 5 says:

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

Yes. But, there is more to say.  If DTLS-SRTP is used, then there is another ciphersuite that must be at least this strong as well.


Section 6 asks:

   Do we need AES-192?

No.


Section 7 needs to cover two things: IANA registry for Message Type and IANA registry EKT ciphers.

Russ