[Perc] FW: Review of needed information for inner security
John Mattsson <john.mattsson@ericsson.com> Sat, 10 October 2015 12:05 UTC
Return-Path: <john.mattsson@ericsson.com>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575671B35A9 for <perc@ietfa.amsl.com>; Sat, 10 Oct 2015 05:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9VyUWbdER1R for <perc@ietfa.amsl.com>; Sat, 10 Oct 2015 05:04:55 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68CD1B35A7 for <perc@ietf.org>; Sat, 10 Oct 2015 05:04:53 -0700 (PDT)
X-AuditID: c1b4fb25-f79a26d00000149a-ae-5618fee30965
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E0.93.05274.4EEF8165; Sat, 10 Oct 2015 14:04:52 +0200 (CEST)
Received: from ESESSMB307.ericsson.se ([169.254.7.184]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Sat, 10 Oct 2015 14:04:51 +0200
From: John Mattsson <john.mattsson@ericsson.com>
To: "perc@ietf.org" <perc@ietf.org>
Thread-Topic: [Perc] Review of needed information for inner security
Thread-Index: AdEBuoOigsVGsWtmR3iAEDjUPDtuQgALPaWAAFW06wAABWRLgA==
Date: Sat, 10 Oct 2015 12:04:51 +0000
Message-ID: <D23ECB11.3D7A9%john.mattsson@ericsson.com>
References: <52E4A8FC978E0241AE652516E24CAF00DADF30@ESESSMB309.ericsson.se> <AB452416-B1A0-4EC1-9FB1-272D19E9E5F5@packetizer.com> <D23E9EBA.3D753%john.mattsson@ericsson.com>
In-Reply-To: <D23E9EBA.3D753%john.mattsson@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.4.150722
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_D23ECB113D7A9johnmattssonericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3RvfJP4kwg5Y1vBarF05ndGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqynxxgLHjSyVTRPuMzewPjyLWsXIyeHhICJxP8XH9ggbDGJ C/fWA9lcHEICRxkldnUdYQRJCAksYZT4uV4axGYTMJCYu6cBrEFEQFni2/Y9YIOEBZwl2jq2 skLEXSS2rNnKAmE7SRza9QLMZhFQlVjSspsJxOYVMJe4NWkxC8SyjYwSk2/NZu5i5ODgFLCQ WH6LG6SGEeig76fWgNUzC4hL3HoynwniUAGJJXvOM0PYohIvH/9jBWkVFdCT2LNcEiKsJLFi +yVGiNYYiR3njrBArBWUODnzCcsERtFZSKbOQlI2C0nZLKCpzAKaEut36UOUKEpM6X7IDmFr SLTOmQtlWwO1TmVCVrOAkWMVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmDMHdzyW3UH4+U3 jocYBTgYlXh4FQolwoRYE8uKK3MPMUpzsCiJ8zYzPQgVEkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwOj1pu2D4sTVP2ZaKeatUvtwaN2Nk5LfV6UpLvhlKZ/P4mx5b97BlCaVZVMu/JrxqDSn 4K/CkjYLX2l9vphXVx/l/nva6a2b2MKlq7v37mP/6B/+3yVm9dhxFqUtYNpwj1cy7+G/Jzt3 5kjekK7tbTmtG/r+RNyMh7ZXOhv62k/aMB9nzFRft0uJpTgj0VCLuag4EQAl8nXomgIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/perc/5uZ5GIV1ilQU-jAbw_4gaDRAqXU>
X-Mailman-Approved-At: Tue, 13 Oct 2015 14:01:47 -0700
Subject: [Perc] FW: Review of needed information for inner security
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Oct 2015 12:05:01 -0000
>Thanks for that. I'd like to go through this point by point in the meeting. Good, lets discuss on the next PERC Design Meeting on Monday. >The only to pieces of information that we need to not create a lot of new machinery is the SSRC and SEQ fields. Totally agree on an RTP level, these are RTP fields and PERC should not do any changes to RTP. But changes will be needed to SRTP, EKT, and DTLS/DTLS-SRTP (if used for e2e key management). Here we need to discuss how to to achieve the best overall solution with regards to security, performance, features, and complexity. >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. Yes “inner ID uniqueness” is a must, even if ID collisions do not lead to two time pads (EKT and random SRTP master keys fixes this). Just as your analysis above shows, random 32-bit SSRCs are in many scenarios to short to give uniqueness. As stated, we therefore suggest that the Key Management Function assigns an “Endpoint ID” when endpoint requests the "e2e key”. This is something the KMF would do internally anyway. In our proposal, SSRC/CSRC would not be used for e2e protection, they would only be used as an context identifier for the receiver. This leads to the requirement that SSRC/CSRC must be unique for the receiver and that several senders using the same SSRC/CSRC is fine (as in your example). Our current understanding is that this would give a e2e ID solution with no changes to RTP SSRC handling, no packet overhead (except when CSRC is used), Inner ID uniqueness, and the possibility to map e2e identities to more human readable names. John From: "Paul E. Jones" <paulej@packetizer.com<mailto:paulej@packetizer.com>> Date: Thursday 8 October 2015 20:36 To: Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>>, "perc@ietf.org<mailto:perc@ietf.org>" <perc@ietf.org<mailto:perc@ietf.org>> Cc: Mats Näslund <mats.naslund@ericsson.com<mailto:mats.naslund@ericsson.com>>, John Mattsson2 <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>> Subject: Re: [Perc] Review of needed information for inner security 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 ________________________________ From: Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>> Sent: October 8, 2015 6:18:09 AM CDT To: "perc@ietf.org<mailto:perc@ietf.org>" <perc@ietf.org<mailto:perc@ietf.org>> Cc: "Mats Näslund" <mats.naslund@ericsson.com<mailto:mats.naslund@ericsson.com>>, John Mattsson <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>> 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 Perc@ietf.org<mailto:Perc@ietf.org> https://www.ietf.org/mailman/listinfo/perc
- [Perc] Review of needed information for inner sec… Magnus Westerlund
- Re: [Perc] Review of needed information for inner… Jonathan Lennox
- Re: [Perc] Review of needed information for inner… Magnus Westerlund
- Re: [Perc] Review of needed information for inner… Paul E. Jones
- [Perc] Deisgn team Re: Review of needed informati… Christian Groves
- Re: [Perc] Deisgn team Re: Review of needed infor… Suhas Nandakumar
- Re: [Perc] Review of needed information for inner… Paul E. Jones
- Re: [Perc] Review of needed information for inner… Cullen Jennings
- Re: [Perc] Review of needed information for inner… Cullen Jennings
- Re: [Perc] Review of needed information for inner… Roni Even
- Re: [Perc] Review of needed information for inner… Jonathan Lennox
- [Perc] FW: Review of needed information for inner… John Mattsson
- Re: [Perc] Review of needed information for inner… Magnus Westerlund
- Re: [Perc] Review of needed information for inner… Magnus Westerlund