Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16

[Gunnar Hellström <[e-mail]>]

Thanks.

I have added this sentence to section 3.19

" Further general security considerations are covered in
    Section 11."

Regards

Gunnar Hellstrom

-- 

Gunnar Hellström

GHAccess

[e-mail]  <mailto:[e-mail]>


Den 2021-05-07 kl. 18:13, skrev Salz, Rich:
>
> Thanks for the explanation and update. Your updated draft addresses my 
> concerns.  Perhaps 3.9 should have a forward link to Sec 11
>
> *From: *Gunnar Hellström <[e-mail]>
> *Date: *Friday, May 7, 2021 at 11:45 AM
> *To: *Rich Salz <[e-mail]>, "[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, 
> "[e-mail]" 
> <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Subject: *Re: [AVTCORE] Secdir last call review of 
> draft-ietf-avtcore-multi-party-rtt-mix-16
>
> 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
> [e-mail]  <mailto:[e-mail]>
>
> Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker:
>
>     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
>
>     [e-mail]  <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/avt  <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/avt__;!!GjvTz_vk!ChNP_4C8_-IG9lEq-LDl930w9i9b8GYIlpcFoBp1nUK7LGxO78Q0hXyqr7QT$>
>
> -- 
> Gunnar Hellström
> GHAccess
> [e-mail]  <mailto:[e-mail]>

-- 
Gunnar Hellström
GHAccess
[e-mail]