Re: [AVTCORE] WG last call for draft-ietf-avtcore-srtp-ekt-01

[Dan Wing <[e-mail]>]

On Nov 15, 2013, at 8:23 AM, Magnus Westerlund <[e-mail]> wrote:

> Hi,
> 
> This is my personal review of EKT in its WG last call.
> 
> I have to say that this is clearly not ready yet. There are a large
> number of issues that needs resolution.

Thanks for your detailed review.


> First the ones that doesn't have clear section references.
> 
> G1: The documents section where the connection with signalling and the
> key-exchange mechanisms are specified implies that one can start an SRTP
> session without EKT and later upgrade it to use EKT. I however fails to
> see how this can work reliable. Especially not the alluding to that you
> can wait doing this until you actually have a new master key to use.
> 
> A. Lets start with the signalled upgrade. When upgrading to EKT from
> plain SRTP then you start sending SRTP and SRTCP packets that allways
> have a EKT trailer, which is either a full header or the 1-byte short
> header. Thus when turning on EKT this header will be added to the end of
> the packet by the sender. When the receiver gets this packet it will
> fail SRTP authentication, as the EKT header now displaced the
> Authentication header. Thus there are failure modes for this upgrade
> that isn't discussed. To my understanding given that one have received
> the signalling that EKT will be used, then one can run regular mode
> until an authentication failure, then try processing the failed packets
> as EKT. If that works, one go to EKT mode for that SSRC. Risk, twice the
> amount of authentication work for SSRC not yet switched, but for a
> limited time
> 
> B. If this is EKT switch can occur at any time, then each time there is
> an authentication failure one have to check if this is EKT. Thus,
> bit-errors, packet mangling, all of these results in twice the amount of
> authentication work before dropping the packet.
> 
> Authors please clarify what the intention is hear. Is this to be
> supported, if it is, then can we please have a section defining the
> procedure for how to handle it so that its cost can be appropriately judged?

We expect EKT to be negotiated, and I added the following to Section 2.4, "Synchronizing Operation",

OLD:
       When joining an SRTP session, SRTP packets may be received before
        any EKT over SRTCP packets, which implies the crypto context has not
        been established, unless other external signaling mechanism has done
        so. Rather than automatically discarding such SRTP packets, the
        receiver MAY want to provisionally place them in a jitter buffer and
        delay discarding them until playout time.
NEW:
       The use of EKT MUST be negotiated during call setup (e.g.,
using DTLS-SRTP, Security Descriptions, MIKEY, or similar).  When
joining a session it is likely that SRTP or SRTCP packets might be
received before the EKT Full Field is received.  Thus, to avoid
doubling the authentication effort, an implementation joining an EKT
session SHOULD queue received SRTP and SRTCP packets until it receives
the Full EKT Field packet and use the information in that packet to authenticate
and decrypt the received SRTP/SRTCP packet.


> 
> G2. SRTCP compound packets and the SSRC field in the EKT. So the
> processing in Section 2.2.2, bullet 4 says that the EKT SSRC field must
> match the SRTP headers SSRC. This fails to discuss SRTCP, and I think
> you might have a major head-ache here. An SRTCP compound packet may
> actaully contain SR/RR packets from multiple SSRCs from an end-point.
> See RFC3550 Section 6.1 that says:
> 
> It is RECOMMENDED that translators and mixers combine individual
>      RTCP packets from the multiple sources they are forwarding into
>      one compound packet whenever feasible in order to amortize the
>      packet overhead (see Section 7).
> 
> This is further discussed in draft-ietf-avtcore-rtp-multi-stream.
> 
> Thus I think you have an issue of how to get all these SSRCs EKT
> payloads sent in SRTCP. If one takes the easy way out, and say that the
> SSRC in EKT must match the first RTCP packet part of the compound, and
> then round-robin among them you might have significant delay until all
> the SSRCs from an end-point have sent their EKT payload even once.
> 
> This maybe, but I am uncertain be handled with above said round robin,
> and instead rely on SRTP distribution of the relevant EKT. But the issue
> clearly needs to be discussed.

We will propose changing EKT to only work over SRTP, and remove text for EKT over SRTCP.  See the other email "changes planned for EKT" where this major change is called out.


> G3. The common master salt. I realized this when reading the security
> description section, that the master salt to use is actually defined by
> the cipher suit. And in case of mixing GCM or CCM cipher suits with any
> of the regular AES ones you actually have Master Salt mismatch between
> them. GCM and CCM uses 96 bits Master Salts, why the others use 112
> bits. Thus, an assumption EKT is built on can easily be made untrue by
> including cipher suites in the same invite from these two sets.

We can resolve this by requiring the same crypto suite to be in an offer -- which makes sense because we can't have half the participants successfully using AES and another half successfully using GCM.

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


> G4. In general I am missing a clear explanation of how the "default"
> master key produced by the key-managements are being used when combined
> with EKT. This applies to all the key-management mechanism where I don't
> get if or not they being used, or need to be included at all.

I believe by "default master key" you are referring to the SRTP key established by MIKEY, DTLS-SRTP, Security Descriptions, etc., which differs from the SRTP key established by EKT.  If so, this is similar to your G2 comment, above, and I believe the change described for G2 answers this.  If this comment is for something else, let us know.


> G5. This document totally fails to discuss the issue of MTU and the fact
> that having a varying sized tag could cause issues. I would recommend
> that one always assumes a full EKT header will be present and deduct
> appropriately from the MTU.

Added:

        "The Full EKT Field is appended to the SRTP (or SRTCP)
payload and is 42, 50, or 58 octets long for AES-128, AES-192, or
AES-192, respectively.  When EKT is sent over SRTP, this length
impacts the maximum payload size of the SRTP packet itself.  To remain
below the network path MTU, senders SHOULD constain the SRTP payload
size by this length of the Full EKT Field."


> G6. The document is very sloppy in referencing SRTP, SRTCP or both types
> of packets correctly. Please review all references to packets to ensure
> that this is correct.

Thanks.  We will review that pending a resolution on keeping or discarding EKT-over-SRTCP, considering the problem you highlighted earlier about SRTCP compound packets.  Abandoning EKT-over-SRTCP is discussed in the thread I started on major EKT changes.


> Now comments more associated with particular sections:
> 
> 1. Section 1:
>   For example, if a participant joins a session that is already in
>   progress, the SRTP rollover counter (ROC) of each SRTP source in the
>   session needs to be provided to that participant.
> 
> I think this might not be the best start, at least failing to discuss
> RFC 4771-

Reworded to:

      For example, if a participant joins a session that is
      already in progress, that participant needs to be told the SRTP
      keys (and SSRC, ROC and other details) of the other SRTP
      sources.



> 2. Section 1:
> EKT
>   securely distributes the SRTP master key and other information for
>   each SRTP source, using SRTCP or SRTP to transport that information.
> 
> I think you should be more explicit when you refer to what is identifed
> by a SSRC, like this:
> 
> SRTP Source (SSRC), using ..

Ok.  I made several edits to improve that clarity there and elsewhere throughout the document.


> 3. Section 1:
> Section 3, Section 4, and Section 5
>   define the use of EKT with SDP Security Descriptions, DTLS-SRTP, and
>   MIKEY, respectively.  Section 7 provides a design rationale.
>   Section 6 explains how EKT can interwork with keying in call
>   signaling.
> 
> First, you have a order mismatch, secondly, I can't understand the
> second sentence.

I removed that paragraph; the table of contents seems sufficient.


> 4. Section 2.1:
> What is the definition of the SSRC field part of the EKT_PLAINTEXT?

Added SSRC (and also SRTP_Master_Key which was also missing):

   SRTP_Master_Key:  On the sender side, the SRTP
   Master Key associated with the indicated SSRC.  The length
   of this field depends on the cipher suite negotiated during
   call setup for SRTP or SRTCP.

   SSRC: On the sender side, this field is	the
   SSRC for this SRTP source.  The length of this field is
   fixed at 32 bits.



> 5. Section 2.1:
> Definition of EKT_Ciphertext:
> I am missing what the requirements are on the production of this from
> the plain text. What is given is that confidenitiality needs to be
> equally strong on this as the SRTP. What about integrity and
> authentication?

Security Considerations currently says:
   The EKT Cipher MUST be at least as strong as the encryption and
   authentication operations used in SRTP.
which I combined with John Mattsson's suggestion to now read:
   "The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher."


> 6. Section 2.1:
> Together, these data elements assoicated with an instance of EKT
>      are called an EKT parameter set.
> 
> What is an "instance of EKT"?

Now reads:
"Together, these data elements are called an EKT parameter set. "


> 7. Section 2.2:
> At any given time, each SRTP/SRTCP source has associated with it a
>   single EKT parameter set.
> 
> Make clear that SSRC is the identifying factor:
> 
> At any given time, each SRTP/SRTCP source (SSRC) is associated with it a
>   single EKT parameter set.

Thanks, fixed.


> 8. Section 2.2:
> 
> There
>   may be other EKT parameter sets that are used by other SRTP/SRTCP
>   sources in the same session.
> 
> Does the above apply also within a end-point? So when having multiple
> SSRCs one can have multiple different EKT parameter sets in use?

Yes.  Edited to read:

        There may be other EKT parameter sets
        that are used by other SRTP/SRTCP sources in the same session,
        including other SRTP/SRTCP sources on the same endpoint (e.g.,
        one endpoint with voice and video might have two EKT parameter
        sets, or there might be multiple video sources on an endpoint
        each with their own EKT parameter set). 


> 9. Section 2.2:
> All of these EKT parameter sets SHOULD
>   be stored by all of the participants in an SRTP session, for use in
>   processing inbound SRTCP traffic.
> 
> inbound SRTP/SRTCP traffic?

Fixed to read "inbound SRTP or SRTCP traffic", thanks.


> 10. Section 2.2.1:
>   First, the sender decides whether to use the Full or Short format.
>   When sending EKT with SRTP, the Full format SHOULD be used on the
>   initial SRTP packet in a session and after each rekeying event.  When
>   sending EKT with SRTCP, the Full format MUST be used.  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.
> 
> Why isn't this mostly a pointer on Section 2.6? I think you should
> gather the discussion of when and why to send full format in one
> section. The reason I think is that Section 2.6 do need to be expanded
> to both discuss when and how to make delivery of the keys reliable.
> 
> I think one can start with analyzing the cases when one knows the
> receiver(s) will not have the keys. Which I think comes down to two
> major cases:
> 
> 1. The SSRC one transmit is new joiner of the session
> 2. There is new receiving endpoint in the session
> 
> A sender can easily determine 1), it can in some cases determine 2) and
> act on it.
> 
> The next is how to assure reliability, and that do depend on the
> receiver population and session properties. I would also note that there
> are cases where one can determine that the EKT has been received. For
> example RTCP reports on Extended Sequence number or explicit ACK
> messages for a sequence number that one has sent with the new key, thus
> determining that the reporting SSRC has been capable of setting the
> right SRTP key state.
> 
> Next is the classical, put the EKT full header on key-frames,
> periodically or on all until determined that reception has happened.
> 
> I think 2.6 can be structured to say this better. With concrete and good
> recommendations for how to act. Probably the new receiver is the hardest
> as the reasonable action will depend on group size.
> 
> In the end the text in section 2.2 can be significantly shortened to
> basically say. The use of Full or Short headers SHOULD follow the
> recommendation in Section 2.6.

I reworked section 2.6.  It now reads:

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



> 11. Section 2.2.1
>   The EKT_Ciphertext field is set to the ciphertext created by
>   encrypting the EKT_Plaintext with the EKT cipher, using the KEK as
>   the encryption key.
> 
> The above uses KEK without defining it.

Fixed, thanks.


> 12. Section 2.2.1:
> 
> I am missing a clear statement that each SSRC an endpoint have must
> individually ensure that their Master Key, ROC and SPI is distributed in
> the RTP session, even if shared with other SSRCs from the same endpoint.

This should be resolved by the addition of this text to Section 2.2, "Packet Processing and State Machine",
  "All SRTP master keys MUST be fresh and randomly generated;
          they MUST NOT be shared in any way."


> 13. Section 2.2.2, Bullet 2:
> 
> If multiple parameter sets have been defined for the
>       SRTP session, then the one that is associated with the value of
>       the SPI field in the packet is used.
> 
> What is only one SPI is defined, what is used then. Shouldn't the SPI be
> matched independently?

Section 2.2.2 is for inbound processing, so the SPI of that incoming packet is used.  Is your question perhaps about how the SPI is chosen for outbound processing?



> 14. Section 2.2.2, Bullet 3:
> The EKT_Ciphertext is decrypted using the EKT_Key and EKT_Cipher
>       in the matching parameter set,
> 
> Here the key is called EKT_Key, previously KEK?

KEK was used only once in the entire document; I have removed it from the work-in-progress -02 version.  EKT Key is the right term.


> 15. Section 2.2.2, bullet 5:
> If the ROC from the EKT_Plaintext is less than the ROC in the
>       SRTP context, then packet processing halts.
> 
> Probably should be explicit that the SRTP context related to the SSRC
> from step 4 is to be used.

Thanks, fixed.


> 
> 16. Section 2.2.2, bullet 5:
> Otherwise, the ROC
>       in the SRTP context is set to the value of the ROC from the
>       EKT_Plaintext, and the SRTP Master Key from the EKT_Plaintext is
>       accepted as the SRTP master key corresponding to the SRTP source
>       that sent the packet.
> 
> And
> If there is no SRTP crypto context corresponding to
>       the SSRC in the packet, then a new crypto context is created.  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.
> 
> Appears to be in the wrong order in this bullet.

Thanks.  Bullet 5 in Section 2.2.2 now reads:
                If an SRTP context already exists and the ROC from the
                EKT_Plaintext is less than the ROC in the SRTP
                context, then EKT processing halts (as this is a
                replay).  Otherwise, the ROC in the SRTP context is
                set to the value of the ROC from the EKT_Plaintext,
                and the SRTP Master Key from the EKT_Plaintext is
                accepted as the SRTP master key corresponding to the
                SSRC indicated in the EKT_Plaintext.  If an MKI is
                present in the packet, then the master key corresponds
                to the particular SSRC and MKI combination. </t>


> 
> 17. Section 2.2.2, bullet 5:
> Otherwise, the ROC
>       in the SRTP context is set to the value of the ROC from the
>       EKT_Plaintext, and the SRTP Master Key from the EKT_Plaintext is
>       accepted as the SRTP master key corresponding to the SRTP source
>       that sent the packet.
> 
> I think this is missing discussion of ISN. As the new key is not valid
> for use until ISN to my understanding.

Ok, I added a forward pointer to the ROC processing,
  "beginning at the sequence number indicated by the ISN (see next step)."


> 18. Section 2.2.2: Usage limiations of ISN and ROC
> 
> Due to the rules for the ROC, that any lower ROC gets update to the ROC
> included in the EKT, then one can't project the key-change further into
> the future, than the current ROC. So if one are at RTP Seq 65501 and
> would like to put a new key into use in 100 packets, then that isn't
> possible as the ISN can only point within the current ROC, i.e. no
> further than 65535. I don't think this is a serious limitation, but it
> should be discussed.

Added a sentence to the discussion to Outbound Processing which alluded to that limitation but was not terribly clear.  It now reads: 

          "... The
          rekeying event MUST NOT change the value of ROC (otherwise,
          the current value of the ROC would not be known to late
          joiners of existing sessions).  This means rekeying near
          the end of sequence number space (e.g., 100 packets past
          sequence number 65501) is not possible because
          ROC needs to roll over)."


> 19. Section 2.2.2: Use of ISN and the playback issues. If one wasn't
> allowed the pre-place an Master Key, ROC, SPI set, then one could accept
> a EKT full header provisionally, then try to use it on the current
> SRT(C)P packet and see if authenticates correctly. If it does, then one
> moves the EKT from provisional to verified status. However, with the ISN
> usage, and the possibility to project EKT parameters into the future,
> then one can't do the immediate verification, but maybe one should also
> have similar provisional status of parameter set. That way at least one
> don't use a replayed EKT to overwrite a valid entry.

David and I discussed this, and I think we have this covered.  The ROC cannot roll over and ekt-01 already had text saying the ROC had to be same or higher of existing crypto context, and we added the following text to the ISN processing based on John Mattsson's review:

   6.  If the ISN from the EKT_Plaintext is less than the RTP sequence
       number of an authenticated received SRTP packet, then EKT
       processing halts (as this is a replay). 

With that change, do you feel doing a provisional/verified step is still necessary?  (I expect you may want to see all of -02 before answering that particular question.)



> 20. Section 2.2.2, Bullet 6:
> This contain overlap procedures with bullet 5. Can you separate or merge
> them to make them correct and sequential in processing.

Bullet 5 discusses the ROC field processing and Bullet 6 discusses the ISN field processing.  I am reluctant to combine them.  In my work-in-progress version of -02, they currently read like this:

   5.  If an SRTP context associated with the SSRC in the previous step
       already exists and the ROC from the EKT_Plaintext is less than
       the ROC in the SRTP context, then EKT processing halts (as this
       is a replay).  Otherwise, the ROC in the SRTP context is set to
       the value of the ROC from the EKT_Plaintext, and the SRTP Master
       Key from the EKT_Plaintext is accepted as the SRTP master key
       corresponding to the SSRC indicated in the EKT_Plaintext,
       beginning at the sequence number indicated by the ISN (see next
       step).  If an MKI is present in the packet, then the master key
       corresponds to the particular SSRC and MKI combination.

   6.  If the ISN from the EKT_Plaintext is less than the RTP sequence
       number of an authenticated received SRTP packet, then EKT
       processing halts (as this is a replay).  If the Initial Sequence
       Number field is nonzero, then the initial sequence number for the
       SRTP master key is set to the packet index created by appending
       that field to the current rollover counter and treating the
       result as a 48-bit unsigned integer.  The initial sequence number
       for the master key is equivalent to the "From" value of the
       <From, To> pair of indices (Section 8.1.1 of [RFC3711]) that can
       be associated with a master key.


> 
> 21. Section 2.2.2,
>          Implementation note: the value of the EKT Ciphertext field is
>          identical in successive packets protected by the same EKT
>          parameter set and the same SRTP master key and ROC.
> 
> I think the end of the sentence needs to include ISN.

Added.


> I would note that the format of the EKT do require one to generate a new
> EKT cipher text at minimum each time the ROC changes, i.e. every 65536
> packets. I don't know if this is worth pointing out.

ROC changes every 2^32 packets (not every 65536).

Added the following to Outbound processing:
        Implementation note:	Because of the format of the Full EKT Field, a
packet containing the Full EKT Field MUST be sent when the ROC changes
(i.e., every 2^32 packets).


> 22. Section 2.3:
> This cipher
>   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., call signaling).
> 
> I think the above formulation, without using name of the cipher is
> unclear. In fact I am uncertain which EKT cipher I am required to
> support. As Section 2.3.1 doesn't identify a single one, and instead
> references three labels.

Adjusted to read:
  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).

and 2.3.1 now says that AESKW_128 is MUST because AES-128 is the must-implement AES length in SRTP itself (RFC3711).  The others (192 and 256 bit) remain with their existing text.


> I also think the "call signaling" is the wrong reference. It needs to be
> coordinated in key-management.

Fixed, thanks.


> 23. Section 2.3.1
>   The default EKT Cipher is the Advanced Encryption Standard (AES)
>   [FIPS197] Key Wrap with Padding [RFC5649] algorithm, which can be
>   used with plaintexts larger than 16 bytes in length, and is thus
>   suitable for keys of any size.  It requires a plaintext length M that
>   is at least eight bytes, and it returns a ciphertext with a length of
>   N = M + 8 bytes.
> 
> I find it very confusing to have one sentence saying that the KEY wrap
> requires plaintext larger that 16 bytes, and the next to say it is 8
> bytes required.

I reviewed RFC5649, and revised the text to now read:

            The default EKT Cipher is the Advanced Encryption Standard
            (AES) [FIPS197] 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.


> 24. Section 2.3.1:
> 
>   When AES-128 is used in SRTP and/or SRTCP, AESKW_128 SHOULD be used
>   in EKT.  In this case, the EKT Plaintext is 26 bytes long, the EKT
>   Ciphertext is 40 bytes long, and the Full EKT field is 42 bytes long.
> 
>   When AES-192 is used in SRTP and/or SRTCP, AESKW_192 SHOULD be used
>   in EKT.  In this case, the EKT Plaintext is 34 bytes long, the EKT
>   Ciphertext is 48 bytes long, and the Full EKT field is 50 bytes long.
> 
>   When AES-256 is used in SRTP and/or SRTCP, AESKW_256 SHOULD be used
>   in EKT.  In this case, the EKT Plaintext is 42 bytes long, the EKT
>   Ciphertext is 56 bytes long, and the Full EKT field is 58 bytes long.
> 
> I think you should build a table to make clear which key-wrap should be
> used for all the already defined SRTP crypto transforms.

Added a table (see a few lines below).


> I also think it is unclear to use SHOULD in the above. I think they are
> MUST unless overwritten by a key-management function.

I believe they should all be MUST, because elsewhere we point out that EKT protection needs to be at least as strong as SRTP's protection. 

I went with this:


                                length of  length of
         SRTP         EKT          EKT        EKT        length of
       transform   transform    plaintext  ciphertext  Full EKT Field
       ---------  ------------  ---------  ----------  --------------
       AES-128    AESKW_128 (m)    26          40            42
       AES-192    AESKW_192        34          48            50
       AES-256    AESKW_256        42          56            58
       F8-128     AESKW_128        26          40            42
       SEED-128   AESKW_128        26          40            42

                           Figure 4: AESKW Table

   The mandatory to implement transform is AESKW_128, indicated by (m).

   As AES-128 is the mandatory to implement transform in SRTP [RFC3711],
   AESKW_128 MUST be implemented for EKT.

   For all the SRTP transforms listed in the table, the corresponding
   EKT transform MUST be used, unless a stronger EKT transform is
   negotiated by key management.


> 
> 25.  Section 2.3.2:
> 
> In reference to the above. I believe it is reasonable that you propose
> default EKT ciphers for all existing SRTP transforms. They are not
> thousands of them, just a few different algorithms and key-lengths in use.

Ok, I guess you wanted F8 and SEED added.  I put those in the table, using AESKW for both because I don't have RFC5649 equivalencies for F8 or SEED to my knowledge.


> 26. Section 2.4:
> A participant in a session MAY opt to use a particular EKT key to
>   protect outbound packets after it accepts that EKT key for protecting
>   inbound traffic.
> 
> Are the reference to EKT_Key, actually correct, or should it refer to
> EKT Parameter set?

Should be to EKT Parameter set.  Fixed.  Thanks.


> 27. Section 2.4:
> An SRTP/SRTCP source SHOULD change its SRTP master key after its EKT
>   key has been changed.
> 
> What are the reasonable exceptions to doing this, why isn't the SHOULD a
> MAY or a MUST?

The full paragraph has two sentences,

   An SRTP/SRTCP source SHOULD change its SRTP master key after its EKT
   key has been changed.  This will ensure that the set of participants
   able to decrypt the traffic will be limited to those who know the
   current EKT key.

I will rephrase to:

	"If a source has its EKT key changed (by key management), it
MUST also change its SRTP master key, which will cause it to send out
a new Full EKT Field.  This ensures that if key	management thought the
EKT key	needs changing (due to a participant leaving or	joining) and
communicated that in key management to a source, the source will also
change its SRTP	master key, so that traffic can	be decrypted only by
those who know the current EKT key."


> 
> 28. Section 2.4:
> Rather than automatically discarding such SRTP packets, the receiver
>   MAY want to provisionally place them in a jitter buffer and delay
>   discarding them until playout time.
> 
> I think referring to Jitter buffer here is maybe to specific. I would
> abstract this to say: buffer the packets and later discard them when
> they become unusable.

Ok.  This has been consolidated into 2.6, "Timing and Reliability".


> 29. Section 2.4:
> As RTCP packets doesn't have sequence numbers, If one include a new
> Master Key in an EKT packet with an ISN in the future attached to the
> RTCP packet, does this key applies immediately for RTCP, or first when
> the SRTP packets has been sent?

Good question.  We haven't figured out a reasonable resolution to this question.  I think SRTP's <From,to> suffers the same problem.  But because we are considering removing EKT-over-SRTCP (see other email with subject "changes planned for EKT"), I'd like to table this question for the moment.

(thinking out loud:  It can't apply immediately, because we need to send the SRTCP packet a few times (to accommodate packet loss) and if we change to use the new key after that first transmission, but that first transmission is lost in the network, the receiver can't authenticate the 2nd and 3rd transmissions of the new key.  This feels all very awkward.  Perhaps we could apply the new key when an SRTCP Receiver Report is generated with the 'extended highest sequence number received' of that ISN, but that gets yuckie because we need to generate an SRTCP RR at an awkward interval (when the key changes, instead of using normal RTCP processing rules for generating RTCP packet).  That awkward feeling is not improving.)


> 30.  Section 3:
>   The SDP Security Descriptions (SDESC) [RFC4568] specification defines
>   a generic framework for negotiating security parameters for media
>   streams negotiated via the Session Description Protocol by use of a
>   new SDP "crypto" attribute and the Offer/Answer procedures defined in
>   [RFC3264].
> 
> Is really "new" appropriate to use here?

Fixed.


> 31. Section 3.1:
> Suggest using ":" after hanging text in bullet list

Fixed.


> 32. Section 3.5.1:
> 
> However if it operates as
>      an RTP translator, synchronized negotiation of the EKT parameter
>      sets on *all* the involved SIP dialogs will be needed.
> 
> I assume the issue you are referring to is a transport translator
> (relay), rather than a media translator, or?

Yes.  Now reads:

  However, if it operates as a transport translator (relay)
  then synchronized negotiation of the EKT parameter sets on *all* the
  involved SIP dialogs will be needed. 



> 33. Section 3.5.3:
> In this case, there will be multiple EKT parameter sets;
>   one for each SRTP session.
> 
> I agree this occurs between one end-point and its different peers. What
> is unclear in this topology is if this truly are different RTP sessions,
> or just one RTP session. It depends on the implementation.
> 
> Maybe further clarify that the concern really are between different
> pairs of end-points.

On this comment #33, can you suggest text?  We aren't sure what to do here.  I am not even confident on my mind's definition of "RTP session", so I worry my changes would be pretty lousy.


> 34. Section 3.7:
> Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI
>   value to a different EKT parameter set until 2^32 other mappings have
>   been used within the SRTP session.
> 
> Considering that the SPI is 15 bits, this appears wrong. See also later
> sentence in paragraph.

Thanks.  Fixed both to 2^15.


> 35. Section 3.9:
>       a=crypto:2 F8_128_HMAC_SHA1_80
>          inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
>          inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
>          FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0
> 
> The EKT key appears very short (24 bits).

Fixed, now reads like this, and I removed all the text about adjusting the base64 padding.  A 128 bit EKT key 

a=crypto:1 AES_CM_128_HMAC_SHA1_80
  inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
  FEC_ORDER=FEC_SRTP EKT=AESKW_128|WWVzQUxvdmVseUVLVGtleQ==|AAE0
a=crypto:2 F8_128_HMAC_SHA1_80
  inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
  inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
  FEC_ORDER=FEC_SRTP EKT=AESKW_128|VHdvTG92ZWx5RUtUa2V5cw==|AAE0



> 36. Section 4.1:
>                   enum {
>                    AES_128(0),
>                    AESKW_128(1),
>                    AESKW_192(2),
>                    AESKW_256(3),
>                   } ektcipher;
> 
> I don't understand why AEA_128 is listed here, can you please clarify?

It was a holdover from earlier version of EKT, sorry.  It is now changed in my work-in-progress document to RESERVED, so that we don't encounter conflicts with pre-RFC implementations.


> 
> 37. Section 4.1:
> 
> This appears to point to an open issue not dealt with:
> 
>      Editor's note: do we need reliability for the ekt_key messages?

Fixed by adding text

   4.2.4.  Sending DTLS EKT Key Reliably
   In the absence of a round trip time estimate, the DTLS ekt_key
   message is sent using an exponential backoff of 250ms, so that if the
   first message is sent at time 0, the next transmissions are at 250ms,
   500ms, 1000ms, and so on.  If a recent round trip time estimate is
   available, the DTLS ekt_key message should be re-transmitted at 1.5
   times the round trip time estimate.  In either case, re-transmission
   stops when ekt_key_ack or ekt_key_error message is received for the
   matching message_seq.




> 38. Section 4.1:
> 
> I don't understand how the SPI are bound to DTLS-SRTP parameter
> agreements, and if you actually can use DTLS-SRTP to establish multiple
> SPIs?

Yes, DTLS-SRTP could establish multiple SPI, such as for changing the EKT key itself (same as we could do with Security Descriptions or MIKEY by sending an updated offer with a new EKT key).



> 39. Section 4.1.1:
> 
> The dtls-srtp-host SDP attribute appears a bit strange. First of all, a
> includer in an O/A exchange gets no confirmation that the peer received
> or understands it. The second you could ensure by being explicit about
> mandating support for it. However, I don't know how you plan to ensure
> that it isn't removed in middlebox that doesn't understand it and thus
> remove it. Shouldn't this be a slightly more elaborate parameter that
> allows negotiation?

This functionality is intended to help with large groups where the sender cannot deal with the quantity of incoming DTLS-SRTP traffic and DTLS ekt_key messages for large groups.  I was considering pulling it several years ago but was encouraged to leave it in based on Romain Biehlmann's ([e-mail]) post in May 2010, http://www.ietf.org/mail-archive/web/avt/current/msg13044.html.  I emailed him last Friday to see if he still needs or uses that attribute, but have not yet heard back.  I am happy to remove it, or improve it.  However, improving it may be difficult as I don't have good technical solutions to accomplish your concerns in #39 -- as you know we can't force implementations to support the a=dtls-srtp-host attribute and we can't force B2BUAs or SBCs or other middleboxes to preserve the a=dtls-srtp-host attribute.  If it isn't supported or is removed, the DTLS-SRTP handshake and ekt_key messages are sent to the host on the m/c lines or what ICE decided (as with normal DTLS-SRTP handshake).  Perhaps if it is deemed important but difficult it can be moved to a separate specification so the rest of EKT can be published?


> 40. Section 4.1.1: ABNF:
> 
> I am missing references to all the used definitions, space, nettype,
> addrtype, connection-address. I personally know they are from RFC 4566,
> but you are not explicit about this in the sentence leading up to the def.

Thanks, fixed.


> 41. Section 4.1:
> 
> I fail to find the SDP attribute definition for dtls-srtp-ekt.

Added, thanks.


> 
> 42. Section 4.2.2:
> The presence of the dtls-srtp-host attribute
>   indicates an alternate host to send the DTLS-SRTP handshake (instead
>   of the host on the c/m lines).
> 
> Or what ICE indicates?

Right.  Related to your comment #39, above.  Let's see if we keep dtls-srtp-host attribute at all.



> 
> 43. Section 5:
> I am missing the RSA-R mode (RFC 4738) in this discussion. I don't know
> if it seriously effects anything, but that mode do allow the Responder
> to provide the TGK or TEK.
> 
> 44. Section 5:
> 
> I missing a discussion on the multicast and broadcast usages of MIKEY.
> 
> 45. Section 5.2:
> I think most of what is defined here is actually not O/A specific, and
> applies indpedenent of how MIKEY messages are transported. Could this be
> factored out, so that it get more general applicability? After all the
> usages I hear for MIKEY are not in a O/A context.

The MIKEY section was written by Kai Fischer (Siemens), who has asked to be removed from the authors list and is no longer active in AVTCORE (or EKT, as far as I know).  The remaining authors have insufficient background to improve the MIKEY section.  We welcome suggestions from you, others, or the WG chairs how to best proceed with your 3 comments.


> 46. Section 9:
> 
> This section needs quite a lot more detail. The SDP attributes needs to
> fill in the template.

Added, thanks.


> The Registries needs considerations for what a
> registration requires. Probably the other registrations have several
> formal requirements not fulfilled by this text.

MIKEY seems okay, from my review of RFC6309 (which relaxed to allow IESG approval) and RFC3830 (which has no IANA template registration requirements that I could find).

We also meet requirements for SDP Security Descriptions's Session Parameter registration (http://tools.ietf.org/html/rfc4568#section-10.3.2.2).

I think it's good for IANA stuff now.



> 47. Section 11:
> 
> I think the following references are in the wrong category:
> RFC 3261, RFC 4771,

Agreed those should be moved to Informative references.

> RFC 6347?, RFC 3830, 

RFC6347 is DTLS, RFC3830 is MIKEY -- we are extending both of those, so I believe they need to remain Normative references.

> RFC 5649.


Needs to remain normative, because it defines AES Key Wrap (AESKW) which we are using as the basis for EKT.


Thanks again for your detailed review!

-d