Subject: [AVTCORE] Questions regarding EKT (draft-ietf-avt-srtp-ekt-03)

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Feb 2012 10:34:31 +0100

Authors, WG,

I have reviewed the EKT draft and have a number of high level comments
and questions about this draft. Please consider this as individual
input, not as WG chair.

I have done this review from the perspective of checking if two
different use cases are possible to realize using EKT. The two use cases
are:

A) Centralized conferencing using a RTP transport translator. Example
would be 4 end-points establishing unicast traffic session to the
translator. On each of these DTLS-SRTP would be used for keying and all
nodes support EKT. The goal is that the transport translator should be
able to forward all RTP and RTCP packets from one participant to all the
other without any processing related to security (SRTP). I assume the
translator supports DTLS-SRTP and the signalling helps ensure that the
conference participants agree on a single KEK and SPI set.

B) A WEBRTC endpoint Alice (using DTLS-SRTP + EKT in this case) uses a
media gateway (MGW) (DTLS+SRTP and EKT support) to connect to a SDESC
keyed SRTP legacy end-point Bob. The goal is that the MGW should not
need to perform any SRTP or SRTCP operations beyond injecting Bob's key
using EKT to Alice. This is basically the use case described in Appendix
A in the draft.

>From my review I have the following issues with the current definition
of EKT or at least the description. I do not rule out that I have missed
something in the description.

1) It appears that use case B above is not functional with EKT as
currently defined. My understanding is that the MGW will have to modify
all RTP and RTCP packets as they pass the MGW. This as the presence of
the EKT authentication tag, in either form requires one to recalculate
the base authentication tag. This as it covers the keys and fields of
the EKT authentication tag, even in the abbreviated form where the
reserved and "0" abbreviated form indication bit is covered. Thus it is
impossible for the MGW to perform a packet transformation by simply
stripping away the extra byte in the abbreviated form in the Alice to
Bob direction, remember that Bob is legacy and wants no EKT
authentication tags as it doesn't understand them.

Also in the other direction where the MGW needs to include EKT
information in the RTP/RTCP packets where it would like to indicate
Bob's key to Alice it needs to recompute all RTP and RTCP packets to
ensure that the authentication tag changes from the regular 80 bit SHA-1
HMAC to either the full or abbreviated EKT authentication tag including
a different 80-bit SHA-1 HMAC tag.

This appears to be a design flaw. I think it is important that EKT can
be used with legacy and the MGW only needs to do basic insertion or
stripping operations of the packets to convert them between EKT and
regular SRTP versions of the authentication tag.

2) If I understand correctly there are in fact three ways of EKT
operation in regards how to use the KEK and EKT where of 2 I think are
intentional. This is focused on use case A above.

i) Use a single KEK+SPI over all session participants, having the
signaling and the central conference server force the participants to
agree on the servers decided KEK and SPI information

ii) Have each participant agree with the server on a different KEK+SPI,
then distribute each KEK and SPI to all the participants so that EKT
SRTP/SRTCP packets can go end-to-end between all participants.

iii) Have each participant agree with the server on a different KEK+SPI,
then have the central node to modify the EKT messages to match the KEK
that particular participant has. This last one is only practical if only
the SRTP/SRTCP messages that has a master key in them needs to be modified.

I assume iii) is not intentional to use as it is sub-optimal. ii) seems
to have one issue that is clearly insufficiently discussed in the draft.
That is how the system ensures that all participants agree on different
SPI values so that none is overlapping within the RTP session. For both
i) and ii) I am missing discussion in the negotiation sections on the
details how the SPI value is negotiated and can be changed by the party
representing the centralized conference to arrive at a set that are
unique. I also think this can result in some "clipping" cases as
somewhat discussed.

In addition the fact that one has two different modes of operation it is
unclear which should be used by an end-point in a given session and
there is no signaling for this. In worst case the conference server
assumes that each participant will generate a KEK and use different
ones, while a participants implementation assumes that a single one will
be used. So clarification of both implementation requirements of these
operation modes and the signaling necessary to agree on what is being used.

3) The draft discusses that one can use EKT authentication tags in RTCP
only, RTP only or both. However, it appears there is no signaling to
negotiate which should be used. Is the goal that one uses the EKT
authentication tag always in both RTP and RTCP independent if one
actually is sending full EKT authentication tag only in RTCP? If that is
not the intention I think the aspect of how one negotiates what
authentication format for RTP and RTCP needs to be clarified.

4) Section 2.2.2: I am a bit confused over the process when using ISN.
The first one has to do with that one uses ISN in the replay protection
part. That would mean that multiple SRTCP packets containing the same
EKT transported master key would be considered duplicates, despite the
actual RTCP information in it is not a duplicate. Why isn't the regular
RTCP packet index or RTP sequence number used in the replay protection?

Secondly, if I understand correctly in a SRTP packet that contains a
full EKT auth tag that has a RTP sequence number that is lower than the
ISN (when re-keying) will still use the new key that is included in the
KEK protected part for the packet protection (encryption and integrity).
I find this strange behavior to use the new key prior to the ISN. It
also appears to have the effect that if one uses different EKT SPI to
protect the new key compared to the old key in use by this end-point the
receivers that hasn't gotten this SPI+KEK can't decode this RTP/RTCP
packet despite this is prior to the rekeying point. That can't be the
intention as it creates an unclean key-change.

I do have more detailed comments but I will save those until I have
received answer on these to determine if they are worth writing up or
may become irrelevant due to changes.

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

---

From: David McGrew <[email-masked]>
Date: Wed, 22 Feb 2012 10:20:22 -0500

Many thanks for your review, Magnus.   I'll follow up with the thread that doesn't copy the list, then let's bring the conversation back to the list.

David