Re: [rtcweb] BUNDLE: Attempting to resolve security consideration
Magnus Westerlund <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <[email protected]> |
Hi,
EKR, I think I understood your issue with the SDP MID usage. I
restructured the section to move the issues with moving the MID into RTP
layer as the second paragraph and made it clear that this is a new
security consideration compared to before in the introduction.
Regarding the integrity and authenticity I have made some small changes.
I don't see how removing the requirements help, even if they are
normally resolved when using an existing mechanism. I guess this is is a
matter of view. I am not comfortable with simple assuming that people
will use a security mechanism and therefore this is not an issue. And it
makes future work to analyses potential mechanism a bit harder as one
have to redo more analysis, such as in PERC.
Anyway here is an updated text. I have sent the XML of this one to
Christer and he has told me he will update the PR he already have.
16. Security Considerations
The security considerations defined in [RFC3264] and [RFC5888] apply
to the BUNDLE extension. Bundle does not change which information,
e.g. RTP streams, that flows over the network, with the exception of
the usage of the MID SDES item as discussed below. Primarily it
changes which addresses and ports, and thus in which (RTP) sessions
that the information is flowing in. This affects the security
contexts being used and can cause previously separated information
flows to share security context. This has very little impact on the
performance of the security mechanism of the RTP sessions. In cases
where one would have applied different security policies on the
different RTP streams being bundled, or where the parties having
access to the security contexts would have differed between the RTP
stream additional analysis of the implications are needed before
selecting to apply BUNDLE.
The identification-tag, independent of transport, RTCP SDES packet or
RTP header extension, can expose the value to parties beyond the
signaling chain. Therefore, the identification-tag values MUST be
generated in a fashion that does not leak user information, e.g.,
randomly or using a per-bundle group counter, and SHOULD be 3 bytes
or less, to allow them to efficiently fit into the MID RTP header
extension. Note that if implementations use different methods for
generating identification-tags this could enable fingerprinting of
the implementation making it vulnerable to targeted attacks. The
identification-tag is exposed on the RTP stream level when included
in the RTP header extensions, however what it reveals of the RTP
media stream structure of the endpoint and application was already
possible to deduce from the RTP streams without the MID SDES header
extensions. As the identification-tag is also used to route the
media stream to the right application functionality it is also
important that the value received is the one intended by the sender,
thus integrity and the authenticity of the source are important to
prevent denial of service on the application. Existing SRTP
configurations and other security mechanisms protecting the whole
RTP/RTCP packets will provide the necessary protection.
When the BUNDLE extension is used, a single set of security
credentials over the bundled media descriptions will need to be used,
at least per direction or endpoint. When using SRTP this will be the
case, at least for the IETF defined key-management solutions due to
their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their
classification in [I-D.ietf-mmusic-sdp-mux-attributes].
"RTP Header Extension for the RTP Control Protocol (RTCP) Source
Description Items" [RFC7941] security consideration requires that
when RTCP is confidentiality protected that any SDES RTP header
extension carrying an SDES item, like the MID RTP header extension,
is also protected using commensurate strength algorithms. However,
assuming the above requirements and recommendations are followed
there are no known significant security risks with leaving the MID
RTP header extension without confidentiality protection. Thus, the
requirements in RFC 7941 MAY be ignored for the MID RTP header
extension. Security mechanisms for RTP/RTCP are discussed in Options
for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can
provide the necessary security functions of ensuring the integrity
and source authenticity.
Den 2017-03-07 kl. 18:47, skrev Eric Rescorla:
>
>
> On Tue, Mar 7, 2017 at 1:45 AM, Magnus Westerlund
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Hi,
>
> Please see inline.
>
> Den 2017-03-06 kl. 14:36, skrev Eric Rescorla:
>
>
> I think you are correct assuming that one is using SRTP. All the
> IETF key-management scheme follows this, although a=mikey is
> IDENTICAL. If one uses other security mechanisms, then this
> is still
> relevant to capture.
>
>
> Which security mechanisms are you thinking of here?
>
>
> I didn't have any specific security mechanism in mind. I simply want
> to make clear the requirements that arises due to the new mechanisms
> that BUNDLE creates. As you commented I can only think of mechanism
> that protects the whole packet.
>
>
> Yeah, this seems more confusing than illuminating. There are lots of
> theoretical
> risks that might happen if we had some new security mechanism with unknown
> properties.
>
>
>
> Is this precisely true? Do you ever use the MID extension w/o
> BUNDLE?
> It certainly changes which ICE checks you do.
>
>
> So lets start with the question of MID without using BUNDLE. As MID
> is used in grouping of media lines use cases, i.e. RFC 5888 there
> are certainly uses. However, there exist no need to signal MIDs on
> RTP session level in those cases as there already exist a one to one
> mapping between the MID and the transport addresses used for that
> RTP session. Only with BUNDLE do the RTP streams from the different
> m= lines start sharing transport context.
>
>
> That's what I meant by "MID extension". Sorry for the confusion.
>
>
>
> So strictly the above is incorrect. What was multiple security
> context due to different RTP sessions, or other sessions are now
> moved into a single context. I think we could reformulate this to say:
>
> The security considerations defined in [RFC3264] and [RFC5888] apply
> to the BUNDLE extension. Bundle does not change which information,
> e.g. RTP streams, that flows over the network. Primarily it changes
> which addresses and ports, and thus in which (RTP) sessions that the
> information is flowing in. This affects the security contexts being
> used and can cause previously separated information flows to share
> security context. This has very little impact on the performance of
> the security mechanism of the RTP sessions, however which actors that
> are present in a particular security context may require additional
> thoughts when applying Bundle.
>
> Is this better?
>
>
> But it still seems to be false because of the MID signaling in SDP.
>
> I also don't understand the last line.
>
> -Ekr
>
>
> The identication-tag is
>
>
> Still misspelled.
>
>
> Yes, there was actually two misspelled instances left, and I had
> corrected one.
>
> Full section text after corrections:
>
> 16. Security Considerations
>
> The security considerations defined in [RFC3264] and [RFC5888] apply
> to the BUNDLE extension. Bundle does not change which information,
> e.g. RTP streams, that flows over the network. Primarily it changes
> which addresses and ports, and thus in which (RTP) sessions that the
> information is flowing in. This affects the security contexts being
> used and can cause previously separated information flows to share
> security context. This has very little impact on the performance of
> the security mechanism of the RTP sessions, however which actors that
> are present in a particular security context may require additional
> thoughts when applying Bundle.
>
> When the BUNDLE extension is used, a single set of security
> credentials might be used for all media streams specified by a BUNDLE
> group. When using SRTP this is further required at least for the
> IETF defined key-management solutions due to their SDP attributes
> (a=crypto, a=fingerprint, a=mikey) classification in
> [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security
> solutions, this may require further consideration.
>
> The identification-tag, independent of transport, RTCP SDES packet or
> RTP header extension, can expose the value to parties beyond the
> signaling chain. Therefore, the identification-tag values MUST be
> generated in a fashion that does not leak user information, e.g.,
> randomly or using a per-bundle group counter, and SHOULD be 3 bytes
> or less, to allow them to efficiently fit into the MID RTP header
> extension. Note that if implementations use different methods for
> generating identification-tags this could enable fingerprinting of
> the implementation making it vulnerable to targeted attacks. The
> identification-tag is exposed on the RTP stream level when included
> in the RTP header extensions, however what it reveals of the RTP
> media stream structure of the endpoint and application was already
> possible to deduce from the RTP streams without the MID SDES header
> extensions. As the identification-tag is also used to route the
> media stream to the right application functionality it is also
> important that the value received is the one intended by the sender,
> thus integrity and the authenticity of the source are important to
> prevent denial of service on the application. Existing SRTP
> configurations requires integrity protection of both RTCP and RTP
> header extensions.
>
> "RTP Header Extension for the RTP Control Protocol (RTCP) Source
> Description Items" [RFC7941] security consideration requires that
> when RTCP is confidentiality protected that any SDES RTP header
> extension carrying an SDES item, like the MID RTP header extension,
> is also protected using commensurate strength algorithms. However,
> assuming the above requirements and recommendations are followed
> there are no known significant security risks with leaving the MID
> RTP header extension without confidentiality protection. Thus, the
> requirements in RFC 7941 MAY be ignored for the MID RTP header
> extension. Security mechanisms for RTP/RTCP are discussed in Options
> for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can
> provide the necessary security functions of ensuring the integrity
> and source authenticity.
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB | Phone +46 10 7148287
> <tel:%2B46%2010%207148287>
> Färögatan 6 | Mobile +46 73 0949079
> <tel:%2B46%2073%200949079>
> SE-164 80 Stockholm, Sweden | mailto: [email protected]
> <mailto:[email protected]>
> ----------------------------------------------------------------------
>
>
--
Magnus Westerlund
----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic