Subject: [AVTCORE] EKT with removable tags [Was: Re: Questions regarding EKT (draft-ietf-avt-srtp-ekt-03)]

From: David McGrew <[email-masked]>
Date: Wed, 21 Mar 2012 14:00:48 -0400

Hi AVTCore,

here is the follow-up to the questions on EKT.   

The original EKT design used the SRTP authentication function to protect the authenticity of the EKT data, which allowed the design to make the size of the EKT data somewaht smaller.  However, this design requires a tight binding between EKT and SRTP, and this tight binding makes it impossible for the original design to be used in some new use cases, such as interoperability between EKT and non-EKT endpoints.  Attached is a short note that describes a new loose-binding approach to EKT, which retains EKT's current capabilities while allowing it to accomodate some use cases that were unanticipated when it was first designed. 

Comments welcome.  Apologies for the length of the note, but we wanted to be clear.  

David

On Feb 22, 2012, at 10:20 AM, David McGrew wrote:

> 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
> 
> On Feb 17, 2012, at 4:34 AM, Magnus Westerlund wrote:
> 
>> 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: "Dan Wing" <[email-masked]>
Date: Fri, 23 Mar 2012 07:35:19 -0700

AVTCORE,

I will summarize these EKT changes during my RTCWEB presentation at IETF83.

>From an RTCWEB perspective, this change to EKT means a media gateway can
provide interworking between DTLS-SRTP-EKT (on the RTCWEB leg) with Security
Descriptions (on the other leg), and the interworking involves no per-packet
cryptographic operations of the SRTP packets in either direction.

This change to EKT eliminates one of RTCWEB's barriers to adoption of
DTLS-SRTP.

-d

> -----Original Message-----
> From: David McGrew [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2012 11:01 AM
> To: Magnus Westerlund; IETF AVTCore WG; Roni Even
> Cc: Dan Wing; Flemming Andreasen
> Subject: EKT with removable tags [Was: Re: Questions regarding EKT
> (draft-ietf-avt-srtp-ekt-03)]
> 
> Hi AVTCore,
> 
> The original EKT design used the SRTP authentication function to
> protect the authenticity of the EKT data, which allowed the design to
> make the size of the EKT data somewaht smaller.  However, this design
> requires a tight binding between EKT and SRTP, and this tight binding
> makes it impossible for the original design to be used in some new use
> cases, such as interoperability between EKT and non-EKT endpoints.
> Attached is a short note that describes a new loose-binding approach to
> EKT, which retains EKT's current capabilities while allowing it to
> accomodate some use cases that were unanticipated when it was first
> designed.
>