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

[Russ Housley <[e-mail]>]

In Seoul, I agreed to d a review of draft-ietf-perc-srtp-ekt-diet-02.  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.


Section 2 says:

   EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
   Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP
   features duplicate some of the functions of EKT.

>>> Do you expect implementations to check for this MUST NOT?
>>> If so, what should the recipient do if the sender does use EKT
>>> in conjunction with SRTP's MKI or with SRTP's <From, To> ?

Section 2.1 says:

   EKTMsgLength  All EKT message other that ShortEKTField must have a
      length as second from the last element.  This is the length in
      octets of either the FullEKTField/ExtensionEKTField including this
      length field and the following message type.

>>> This "must" statement is really a requirement on the person that
>>> will specify other EKT messages.  Is there a better place to state
>>> This requirement?

Section 2.2.1, step 4 says:

   4.  Then the FullEKTField is formed using the EKTCiphertext and the
       SPI associated with the EKTKey used above.  Also appended are the
       Length and EKTMEsgTypeFull elements.

>>> s/EKTMEsgTypeFull/EKTMsgTypeFull/

          Note: the value of the EKT Ciphertext field is identical in

>>> To match text in step 4: s/EKT Ciphertext/EKTCiphertext/

          successive packets protected by the same EKTKey and SRTP
          master key.  This value MAY be cached by an SRTP sender to
          minimize computational effort.

Section 2.2.2 says:

   When receiving a packet on a RTP stream where EKT was negotiated, the
   following steps are applied for each received packet.

>>> 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?  Is an additional step needed to perform
>>> "normal SRTP or SRTCP processing" on packets without EKT?

Section 2.3 says:

   EKT uses an authenticated cipher to encrypt and authenticate the
   EKTPlaintext.  We first specify the interface to the cipher, in order
   to abstract the interface away from the details of that function.  We
   then define the cipher that is used in EKT by default.  The default
   cipher described in Section 2.3.1 MUST be implemented, but another
   cipher that conforms to this interface MAY be used, in which case its
   use MUST be coordinated by external means (e.g., key management).

>>> The SPI tells which cipher is being used, so I do not understand the
>>> second MUST in the sentence.  Key management needs to put the key in
>>> place regardless of the algorithm in play.

And, later it says:

   The decryption function returns a plaintext value P that is at least
   M bytes long, or returns an indication that the decryption operation
   failed because the ciphertext was invalid (i.e. it was not generated
   by the encryption of plaintext with the key K).

>>> It seems that E can pad P.  That is fine.  Why not have D strip
>>> any padding that was put on by E?

And, then it says:

   These functions have the property that D(K, E(K, P)) = ( P
   concatenated with optional padding) for all values of K and P.  Each
   cipher also has a limit T on the number of times that it can be used
   with any fixed key value.  The EKTKey MUST NOT be used more that T
   times.

>>> Where is the counter kept to enforce T?  It does not seem to be
>>> one of the parameters associated with the SPI for outbound
>>> processing.  Also, what does an implementation do if it reaches
>>> the limit imposed by T?

Section 3.2 says:

                 struct {
                   EKTCipherType ekt_ciphers<0..254>;
                 } SupportedEKTCiphers;

>>> There must be at least one, right?  Otherwise, just don't include
>>> the extension.
>>> s/<0..254>/<1..254>/

And, later it says:

   If a DTLS client includes "srtp_ekt_key_transport" in its
   ClientHello, then a DTLS server that supports this extensions will
   includes "srtp_ekt_key_transport" in its ServerHello message.  If a
   DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but
   does not receive "srtp_ekt_key_transport" in the ServerHello, the
   DTLS client MUST NOT send DTLS EKTMessage messages.

>>> Also, the "srtp_ekt_key_transport" in the ServerHello MUST select
>>> one and only one EKTCipherType from the list provided by the client
>>> in the "srtp_ekt_key_transport" in the ClientHello.

And, then it says:

   ekt_ttl:  The maximum amount of time, in seconds, that this
      ekt_key_value can be used.  The ekt_key_value in this message MUST
      NOT be used for encrypting or decrypting information after the TTL
      expires.

>>> There is a mismatch between TTL and T.  TTL says that the key
>>> cannot be used after a number of seconds, but T says that the key
>>> cannot be used after a number of encrypt operations.  The data
>>> to enforce these is very different.  This should be discussed in
>>> implementation guidance.

Section 4 says:

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

>>> I do not see a step in Section 2.2.2 that performs this check.  I
>>> expected to see a comparison of the decrypted SSRC to the one that
>>> is in the packet.  Without such a check, we cannot expect every
>>> implementation to prevent this substitution attack.

And, later it says:

   Each EKT cipher specifies a value T that is the maximum number of
   times a given key can be used.  An endpoint MUST NOT send more than T
   Full EKT Field using the same EKTKey.  In addition, the EKTKey MUST
   NOT be used beyond the lifetime provided by the TTL described in
   Section 3.2.

>>> This document tells the sender to put the same EKT into 3 SRTP
>>> packets.  This does not count as 3 encryptions.  This is 1
>>> encryption, even though the ciphertext is transmitted multiple
>>> times.

Russ