Re: [Perc] Review of needed information for inner security

[Cullen Jennings <[e-mail]>]

> On Oct 8, 2015, at 5:18 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi,
>  
> John, Mats and I have spent some time reviewing what information we see
> as needed for the RTP payload security, hence called inner security. We
> also in the end have a proposal for how to include that information.
>  
> So we have considered the three topologies that are relevant for PERC.
> These three as named in
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update/:
>  
> 1. Relay - Transport Translator (Section 3.5.1)
> 2. Media Switching Mixer (Section 3.6.2)
> 3. Selective Forwarding Middlebox (Section 3.7)
>  
> First we look how the SSRCs are handled by these middleboxes. This is
> important as it affects how one can track the media streams flowing
> through the system.
>  
> So the Relay (1) performs no manipulation on the RTP level. Thus, a
> packet being sent will arrive at the receiver except for transport
> losses. This results in constant SSRCs end to end between sender and
> receiver.
>  
>  
> The Media Switching Mixer (2) has some important properties. As the
> SSRCs used towards the receiver from the RTP mixer (MDD) is task/role
> based, rather than related to original source, the inner security
> context identification can't be made based on the SSRC, rather an
> additional field has to be used. It is important to note that the
> sequence of payloads for this stream is created by switching between the
> available incoming streams. At any given point in time one specific
> stream of inner payloads are forwarded for each task/role. Which it is can be changed at almost
> any point. The CSRC would be the normal method for identifying the
> original media contributor in a non PERC context. In a PERC context it
> seems reasonable to also use CSRC. Especially, as there can't be any
> media mixing due to the protected inner payloads, there can only be one
> CSRC for any payload. So in this case the SSRC has no relation to the
> media sources, and instead it is CSRC (or equivalent) that would have a
> relation with the media source.
>  
> The SFM (3) although selectively forwarding media, it does have a one to one
> handling of SSRCs, one SSRC arriving at a SFM will have its own SSRC
> going out. Note that remapping may occur so that incoming and outgoing
> SSRC is different.
>  
> The remapping of SSRC could occur also in the switching RTP mixer,
> although it is not a recommended behaviour.
>  
> What was discussed last design team meeting was the view that we want to
> enable the remapping of SSRC when needed. It is a simple way of dealing
> with SSRC collisions in SFMs for example. However, one need to be aware
> of the potential downside. First, by allowing re-mapping we don't have a
> global stable identifier towards the originating end-point and its
> identification of the media stream. This is something that at least on a
> higher layer is needed to prevent substitution attacks, where the MDD
> attempts to replace one endpoint's media streams with another endpoints
> stream.
>  
> We also note that if end-to-end protected RTCP messages are used, not
> having a global coordinated SSRC space within a conference, there will
> be identification issues, and likely some other id space would be needed.
>  
> The next RTP header field that we considered was the RTP sequence
> number. At the sender side, the RTP sequence number will be directly
> related to the inner payload. However, that relation is not retained
> across an MDD. An RTP switching mixer, will create an RTP sequence
> number solely related to the out going created stream. As that is a
> switched combined stream the corresponding inner sequence number will
> jump back and forth at each switch, and the relative offset will change
> with each switch.
>  
> For the SFM the outer RTP sequence number for an outgoing stream will be
> counting the inner payloads selected to be sent (forwarded). Thus, the
> offset changes at each time a decision to forward or not forward is made.
>  
> The Payload Type field is dependent on the signalling, and likely have
> local assignment only. Each joining endpoint will negotiate common sets
> of payload types with the signaling server representing the conference.
> However, the signalling server when using offer/answer not force an
> endpoint to use a particular PT field value to represent a commonly used
> codec configuration. Thus, PT rewriting will occur at the MDDs,
> independently of the topology.
>  
> The RTP marker bit is actually a field owned by the payload format, and
> thus are tightly connected to the inner payload. We see that this field
> is not possible to modify by the MDD, instead it should be included part
> of the payload's integrity protected data.
>  
> The padding flag is tightly connected to the inner payload and should 
> not be modified by the MDD, instead it should be included part
> of the payload's integrity protected data.
>  
> The Timestamp field also relates to the presentation timeline for the
> outgoing stream. Here there is a difference between the SFM, which
> maintains the original senders timeline, and the RTP switching mixer
> that needs to create its outgoing streams timeline in a consistent way.
> This requires rewriting the timestamp, but maintain the inter spacing
> between media frames within the inner payload.

I agree with above and let me summarize as requirements are the MDD can optionally modify

SSRC, Seq_no, PT, timestamp, CC, CSRC

But can not modify: (M) Marker, (P) Padding. 

I'm never clear on the many different meanings the M bit has been used for so bit harder for me to decide but we can figure that out and ditto for padding but what you are proposing sounds like it would work for me. 

We should probably make sure we know what we want for V, X,

I would propose V is that as a future extensibility we might allow V to modified by MDD but I don't really care. 

I think the X bit we need to be modified by MDD so that it can insert things like mixer to client levels. 


>  
>  
> Proposal for how to structure information
> -----------------------------------------
> Our proposal for how the above information should be handled and
> maintained are the following.
>  
> The inner payload's crypto context is looked up based on the CSRC if
> that field is present (for RTP switching mixers), else the SSRC.

I view this as for the E3E, we need to be able to find all the bits that are used in normal E2E crypto from some new place in the packet. I'm fine with finding the original SSRC in CSRC. 

>  
> The inner crypto context includes the necessary key (called transport
> key below) and other crypto
> information. To prevent attacks we also need a identifier for this
> particular inner media stream. For this we want to have two parts, one
> part identifying the endpoint, and another identifying the media stream.
> The endpoint identifier can either be globally unique and assigned by
> the master key server, thus enabling a compact field scaled to planned
> maximum participation in a conference. Alternatively if significant
> longer randomly picked. An endpoint id assigned by the master key server
> seems preferable as that enables mapping between the endpoint id and
> other identifiers meant for humans. The stream id is managed by the endpoint. We
> foresee that these two IDs are carried by EKT to establish this context.
> The field lengths can be configurable and the used values provided in
> the key-management protocol for the EKT master key. Thus enabling that
> most conference to use 1 + 1 byte enabling 256 endpoints which each can
> have 256 streams. Sufficient for most use cases, and for those use cases
> that requires more participants or streams one can use longer fields
> within the conference.
>  
> The Inner Payload gets an explicit sequence number. We propose 32 bits
> that counts the number of sent packets using a specific transport key
> used to protect this inner payload. It is part of the inner payload to
> keep these close, and minimize the overhead. Using an RTP header
> extension will in many case have more overhead.
>  
> We foresee that PERC systems will perform transport re-keying quite
> frequently, that is why 32-bits will be sufficient, and if that is on
> its way to wrap, the sending end-point will have to rekey its transport
> key for this media stream. We note that 32-bits are sufficient also for
> really high bit-rates. At 3 Gbps using 1200 bytes of payload one need to
> rekey approximately every 3 hours. Using 24 bits would result in
> rekeying every 53 seconds for this case.
>  
> To ensure that replay protection is present, and to prevent MDD reordering
> of packets, one will need to have a sequence number also for the used
> transport key. That way when one starts using a new transport key, one
> can reset the inner payload sequence number, thus enabling long lived
> sessions.
>  
> For the cases where one wants to prevent joining and leaving participant
> to decrypt media prior or after joining and leaving respectively then we
> forsee the need for master key rekeying. Also that needs to be tracked,
> to prevent replay attacks. Thus also on this level one needs to have a
> associated sequence number with the master key. When one
> starts using a new master transport key, the transport key sequence
> number is reset.
>  
> The inner payload identification will thus basically be
> "Master_Key_seq_nr : Transport_Key_Seq_nr : Inner_Payload_Seq_nr". The
> first two will determined through the key management protocol and EKT.
> Enabling the receiver to determine if a payload is less recent then the
> latest received one. This enables one to have a short window for
> accepting older packets to deal with re-order events thus preventing
> replays. We note that the MDD will be able to delay packets. Thus when
> switching back to a source select any point between the previous sent
> and the latest received by the MDD, as the point of continuing
> transmission. We likely need to discuss if that is a sufficient level of
> protection. We need to deal with expected levels of transport delay.
>  
>  
> To summarize our proposal:
>  
> As part of the inner RTP payload for a particular media stream:
> - Explicit 32-bit sequence number
> - Use CSRC/SSRC for context lookup on packet reception.
>  
> Use EKT for context population per media stream of the following
> information:
> -   Endpoint ID + Endpoint specific stream ID
> -   Transport key used to protect payload
> -   Transport key sequence number
>  
> Stream specific context also contain:
> Highest seen inner payload identifier "Master Sequence nr : Transport
> Sequence nr. : Packet Sequence nr" and replay window.
>  
> Key-management for EKT master key
> - EKT Master key
> - Master Key sequence number
> - Field lengths for Endpoint Id and Endpoint Stream ID
> - Endpoint ID
>  
> IV includes:
> - Endpoint ID + Endpoint specific stream ID
> - Master_Key_seq_nr : Transport_Key_Seq_nr : Inner_Payload_Seq_nr
> e2e integrity protected information
> - padding flag
> - marker bit
> - payload + padding + pad count (also encrypted)
> - IV (only Inner_Payload_Seq_nr sent in each packet)
>  
>  
> Looking forward to feedback on this.

This is inventing a new security scheme for the HBH. My questions is first can we just use SRTP for HBH? Any reason it would not work?  It seems to me that it will work and if it does, then I get a bit antsy about it inventing something new will have any significant advantages.