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

["Paul E. Jones" <[e-mail]>]

Magnus,

Thanks for that. I'd like to go through this point by point in the meeting.

For now, I'll just thought out a few thoughts and questions.

Given the focus of perc to provide E2E confidentiality of media, do we even need to authenticate anything in the RTP header E2E? Changes to that information doesn't weaken media confidentiality.

If we assume that, I think work for RTP is very simple.  We merely encrypt the media content using an E2E key.  We then follow normal SRTP procedures to provide HBH integrity (even double-encrypting if we wanted).  That yields a solution following the SRTP spec pretty closely, modulo the inner encryption.

The only to pieces of information that we need to not create a lot of new machinery is the SSRC and SEQ fields.  We could easily put those in either a header extension or payload.  If we insert them always, that inflates each packet by 64 bits.  Periodically, we would need to convey the ROC, but the frequency of that could be limited.  The MDD could modify anything in the header. We retain all properties of SRTP for each hop.

The only special treatment at the receiver is to decrypt the inner media content.  By preserving the SSRC, SEQ and ROC, we can largely reuse what's defined in AES-GCM for RTP. We can also detect replay of packets where a compromised MDD sends data it sent previously since we have the SSRC, SEQ, and ROC.

I think defining the steps following SRTP very closely will help address security concerns.  My only concern is inflating each packet by 64 bits.

In terms of implementation, I would use SRTP to authenticate that packet as usual, then locate contextual information for the inner part in relation to that outer part. That is, the outer SSRC might be associated with many crypto contexts (one for each sender).  A concern, though, is that some complex topologies where, say, A(SSRC=1) and B(SSRC=1) sends media to different MDDs, each of which rewrites the SSRC to 3 and 4, respectively.  Those flows then go to a next hop MDD that rewrites those SSRCs to a new value 5. The receiver might use 5 to process the outer part, but then uses SSRC 1 for the inner part. Problem is, both senders use the same inner SSRC value of 1.

I'm worried that we'll have the same issue with using the CSRC field as you've described it for the same reason.  Or, do you think this can be avoided somehow?  (Given even more hops, I'm feeling skeptical.)

The positive aspect is we have similar thinking on inner/outer.  We just have to be careful to ensure that inner crypto context will not be confused with another and that, to the extent possible, we minimize changes to SRTP.

Inner "uniqueness" is one motivation for our current proposal, though I appreciate folks want to change the SSRCs.  That nonetheless complicates things a lot.

Anyway, I'd love to go through some slides on the call.  I think that's going to be more helpful in exchanging ideas on this.

Paul


-------- Original Message --------
From: Magnus Westerlund <[e-mail]>
Sent: October 8, 2015 6:18:09 AM CDT
To: "[e-mail]" <[e-mail]>
Cc: "Mats Näslund" <[e-mail]>, John Mattsson <[e-mail]>
Subject: [Perc] Review of needed information for inner security

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.


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.

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.

Cheers

Magnus Westerlund
John Mattson
Mats Näslund


------------------------------------------------------------------------

_______________________________________________
Perc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/perc