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

From: "Peck, Michael A" <[email-masked]>
Date: Wed, 13 Nov 2013 19:09:14 +0000

Hi - I have a few minor comments:

There are several references to AES_128 throughout the document (I counted
6) including a statement that "AES_128 is the default value for the EKT
cipher."  It looks like these are leftovers from a previous draft and
should be removed, as AES_128 is no longer a defined EKT cipher.  Section
3.4.1 states that AESKW_128 is now the default cipher.

Section 2.1:
The ROC and ISN paragraphs both state "It is included in the EKT
plaintext, but does not appear on the wire."
The phrase "but does not appear on the wire" seems confusing to me - I'd
suggest removing it?
The EKT_Plaintext paragraph already states that the EKT plaintext doesn't
appear on the wire.
Besides, they sort-of do appear on the wire, but they're in ciphertext
form?

Section 2.2:
"for use in processing inbound SRTCP traffic"
Should this be "for use in processing inbound SRTCP and SRTP traffic"?

Section 2.2.2
typo: "containing and EKT" should be "containing an EKT"
typo: "Steps 2, 3, 4 5" should be "Steps 2, 3, 4, 5"

Section 3.4.1:
typo: "with in" should be "within"
Same sentence: should "SRTCP packets" be "SRTCP and SRTP packets"?

Section 3.4.2:
Should "SRTCP packets" be "SRTCP and SRTP packets"?

Section 3.5:
typo: "Section (newline) Section 3.4" should just be "Section 3.4"

Mike Peck

On 10/25/13 5:55 AM, "Magnus Westerlund" <[email-masked]>
wrote:

>WG,
>
>This starts a 3-week (due to the IETF meeting) WG last call of Encrypted
>Key Transport for Secure RTP with intended status Proposed Standard.
>Please provide any feedback by the 15th of November.
>
>The draft
>https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-ekt/
>
>Cheers
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------
>Ericsson AB                | Phone  +46 10 7148287
>Färögatan 6                | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden| mailto: [email-masked]
>----------------------------------------------------------------------
>
>_______________________________________________
>Audio/Video Transport Core Maintenance
>[email-masked]
>https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Nov 2013 17:23:54 +0100

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.

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?

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.

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.

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.

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.

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.

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-

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

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.

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

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?

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

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.

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?

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?

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.

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.

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.

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?

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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?

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?

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.

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?

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?

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

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?

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.

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.

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

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?

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?

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?

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?

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.

41. Section 4.1:

I fail to find the SDP attribute definition for dtls-srtp-ekt.

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?

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.

46. Section 9:

This section needs quite a lot more detail. The SDP attributes needs to
fill in the template. The Registries needs considerations for what a
registration requires. Probably the other registrations have several
formal requirements not fulfilled by this text.

47. Section 11:

I think the following references are in the wrong category:
RFC 3261, RFC 4771, RFC 6347?, RFC 3830, RFC 5649.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Nov 2013 13:59:18 +0100

WG,

The WG last call has concluded. I notice that there has been a number of
significant issues raised. I find it likely that we will have to do
another complete WG last call when these issues has been addressed.

If you have some feedback and haven't provided it yet, please do so.

Cheers

Magnus Westerlund
AVTCORE WG chair

-- 

Magnus Westerlund

---

From: Dan Wing <[email-masked]>
Date: Mon, 25 Nov 2013 21:58:38 -0800

Thanks for your comments, Michael.  I incorporated all those changes for -02.

-d

---

From: Dan Wing <[email-masked]>
Date: Mon, 25 Nov 2013 21:58:51 -0800

> number of issues that needs resolution.

Thanks for your detailed review.

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

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

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

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

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

> of packets correctly. Please review all references to packets to ensure

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.

> I think this might not be the best start, at least failing to discuss

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.

> SRTP Source (SSRC), using ..

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

> First, you have a order mismatch, secondly, I can't understand the

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

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

> equally strong on this as the SRTP. What about integrity and

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

> What is an "instance of EKT"?

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

>   single EKT parameter set.

Thanks, fixed.

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

> inbound SRTP/SRTCP traffic?

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

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

> The above uses KEK without defining it.

Fixed, thanks.

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

> What is only one SPI is defined, what is used then. Shouldn't the SPI be

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?

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

> from step 4 is to be used.

Thanks, fixed.

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

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

> further than 65535. I don't think this is a serious limitation, but it

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

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

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

> I think the end of the sentence needs to include ISN.

Added.

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

> support. As Section 2.3.1 doesn't identify a single one, and instead

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.

> coordinated in key-management.

Fixed, thanks.

> requires plaintext larger that 16 bytes, and the next to say it is 8

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.

> used for all the already defined SRTP crypto transforms.

Added a table (see a few lines below).

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

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

> Are the reference to EKT_Key, actually correct, or should it refer to

Should be to EKT Parameter set.  Fixed.  Thanks.

> What are the reasonable exceptions to doing this, why isn't the SHOULD a

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

> abstract this to say: buffer the packets and later discard them when

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

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

> Is really "new" appropriate to use here?

Fixed.

> Suggest using ":" after hanging text in bullet list

Fixed.

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

> Maybe further clarify that the concern really are between different

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.

> Considering that the SPI is 15 bits, this appears wrong. See also later

Thanks.  Fixed both to 2^15.

> 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

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

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

> agreements, and if you actually can use DTLS-SRTP to establish multiple

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

> remove it. Shouldn't this be a slightly more elaborate parameter that

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 ([email-masked]) 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?

> but you are not explicit about this in the sentence leading up to the def.

Thanks, fixed.

> I fail to find the SDP attribute definition for dtls-srtp-ekt.

Added, thanks.

>   of the host on the c/m lines).

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

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

> fill in the template.

Added, thanks.

> The Registries needs considerations for what a

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.

> 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