Rich,
Thanks for the review.
I am composing a new version because of the Gen-ART review, and
want to propose changes to satisfy your comments.
You ask if it is common to have the mixers being trusted.
In the expected first implementation environments for this draft, it is. That is in emergency service networks. Also in personal communication services it is.
The first implementation environments are also expected to use
the SIP centralized conference model (RFC 4353 etc.) where all
media are expected to be mixed centrally. Thus the security
aspects would be similar for audio, video and real-time text.
I have tried to elaborate a bit more on this in a modified security considerations section, currently looking like this and being ready for submission together with the changes because of the Gen-ART review. Would this satisfy your concerns?
--------Proposed security concerns--------------------
11. Security Considerations The RTP-mixer model requires the mixer to be allowed to decrypt, pack, and encrypt secured text from the conference participants. Therefore the mixer needs to be trusted to achieve security in confidentiality and integrity. This situation is similar to the situation for handling audio and video media in centralized mixers. The requirement to transfer information about the user in RTCP reports in SDES, CNAME, and NAME fields, and in conference notifications, for creation of labels may have privacy concerns as already stated in RFC 3550 [RFC3550], and may be restricted for privacy reasons. The receiving user will then get a more symbolic label for the source. Participants with malicious intentions may appear and e.g., disturb the multiparty session by emitting a continuous flow of text. They may also send text that appears to originate from other participants. Counteractions should be to require secure signaling, media and authentication, and to provide higher level conference functions e.g., for blocking, muting, and expelling participants. Further security considerations specific for this application are specified in Section 3.19. ---------------------------------------------------------- Regards
Gunnar
-- Gunnar Hellström GHAccess gunnar.hellstrom@xxxxxxxxxxx
Reviewer: Rich Salz Review result: Ready This review is for the benefit of the Security AD's. Nobody else should read this. Or, if you read it, treat it as any other last call review :) I know very little about WebRTC, AVT, etc. I thought Section 1.2, summary of the alternatives, was great. I wish more documents did this kind of thing. And similar for all of section 2. The details in Section 3 about how to comply seem very clear. If I were implementing this, I could use easily use this as a checklist and test suite. Section 3.19 is the most important one for transport security. Not knowing the operating environments, it seems reasonable. The security considerations seems a little scant, given the opportunity for privacy concerns of participants and for intruders to disrupt calls. Is it common that the mixer is a trusted entity? A statement on that either way would be useful. _______________________________________________ Audio/Video Transport Core Maintenance avt@xxxxxxxx https://www.ietf.org/mailman/listinfo/avt
-- Gunnar Hellström GHAccess gunnar.hellstrom@xxxxxxxxxxx
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
