Re: [clue] Comments on CaptureID and security

[Roni Even <[e-mail]>]

Hi Magnus,
About the requirement to encrypt the RTCP (do not use NULL security profile) I was wondering why it is not mention also on RTCPweb, is it because RTP/RTCP multiplexing? I think that it should be mentioned also there since there is option to support non multiplex RTP/RTCP
Roni 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: יום ד 18 ינואר 2017 13:53
> To: Roni Even; [e-mail]
> Cc: Jonathan Lennox
> Subject: Re: Comments on CaptureID and security
> 
> Hi,
> 
> Yes, I think encrypting the CaptureID avoids the negative impacts that bad
> construction can have that I can think of. Thus, I support going in that
> direction.
> 
> When it comes to the security solution I would recommend copying the text
> and then make the edits. There is at least two additions, the MUST encrypt
> RTCP, and the MUST implement RFC 6904 and use it to encrypt the CaptureID
> header extension. Please be explicit and clear in the CLUE level document on
> what security solutions that needs to be implemented and use.
> 
> Reasons for copying the text, is that there are differences between RTCWeb
> and CLUE, and in addition I think the implementation considerations and
> potential needs to later revise the specification are different. I am not certain
> CLUE will want to be required to follow any changes that RTCWeb does in the
> future.
> 
> I would also note that I think you need at least to put in a short paragraph
> about the CaptureID value. Something like this.
> 
> The construction of the CaptureID value is implementation dependent and is
> not tightly restricted. Therefore there exist a risk that the CaptureID contains
> privacy sensitive information or otherwise revealing information about the
> communication session to third parties. Therefore confidentiality protection
> is always applied to avoid this risk.
> 
> Cheers
> 
> Magnus
> 
> Den 2017-01-18 kl. 10:44, skrev Roni Even:
> > Hi, The text I added to the -11 version "The CaptureID is created as
> > part of the CLUE protocol.  The CaptId SDES item is used to convey the
> > same CaptureID value in the SDES item.  When sending the SDES item the
> > security considertion specied in the security section of [RFC7941] are
> > applicable and this SDES item MUST use similar security as the CLUE
> > protocol messages carried in the CLUE data channel."
> >
> > Say that  " this SDES item MUST use similar security as the CLUE
> > protocol messages carried in the CLUE data channel." The CLUE data
> > channel document
> > https://tools.ietf.org/html/draft-ietf-clue-datachannel-14#section-4
> > point at
> > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-
> > 7
> > pointing to
> > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10
> >
> > So we can reference the rtcweb security architecture or use the text I
> > copied from there to define a security profile
> >
> > As for the second item I agree that if we encrypt the content in the
> > CLUE data channel that includes the captureID, we need also to encrypt
> > RTCP with the captureID SDES item and it does not matter how we create
> > the captureID value, so maybe if we mandate encrypting the SDES item
> > there is no strong need for specifying how to create CaptureID . Note
> > that the CaptureID is not use to provide human-readable textual
> > information which is in the description attribute.
> >
> > Roni
> >
> >> -----Original Message----- From: Magnus Westerlund
> >> [mailto:[e-mail]] Sent: יום ד 18 ינואר 2017
> >> 10:45 To: Roni Even; [e-mail] Cc: Jonathan Lennox Subject: Re:
> >> Comments on CaptureID and security
> >>
> >> Hi,
> >>
> >> A comment about the below. I have an issue raised against the below
> >> quoted text from the rtcweb-security-architecture in the RTCWeb WG,
> >> as it fails to specify if RTCP encryption is mandatory to use or not.
> >> There are protection profiles that only have confidentiality
> >> protection for RTP, and not for RTCP. I would recommend requiring
> >> confidentiality protection also of RTCP.
> >>
> >> The second note on the below is that depending on the outcome of the
> >> security requirements for the CaptureID RTP header extension, you
> >> might in addition have to require RFC 6904, implementation and usage
> >> for the CaptureId header extension field. Or rather if you write
> >> nothing it will by default be required if you encrypt RTCP, due to
> >> RFC 7941. But, I really recommend that you are explicit on this
> >> matter. It comes down to what security risks the field entails. What
> >> information will it leak to a third party viewer of the RTP/RTCP
> >> stream they can capture.
> >>
> >> Cheers
> >>
> >> Magnus
> >>
> >> Den 2017-01-18 kl. 09:33, skrev Roni Even:
> >>> 2.       What do we want to say about supported security profile?
> >>> For example does the following directive from
> >>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#secti
> >>> on-5.5
> >>>
> >>>
> looks good for CLUE?
> >>>
> >>>
> >>>
> >>> “Implementations MUST implement SRTP [RFC3711
> >>> <https://tools.ietf.org/html/rfc3711>].  Implementations MUST
> >>>
> >>> implement DTLS [RFC4347 <https://tools.ietf.org/html/rfc4347>]
> >>> and DTLS-SRTP [RFC5763
> >>> <https://tools.ietf.org/html/rfc5763>][RFC5764] for
> >> SRTP
> >>>
> >>> keying.  Implementations MUST implement
> >>>
> >>> [I-D.ietf-tsvwg-sctp-dtls-encaps
> >>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#ref-
> >>> I-
> >>
> >>>
> D.ietf-tsvwg-sctp-dtls-encaps>].
> >>>
> >>>
> >>>
> >>> All media channels MUST be secured via SRTP.  Media traffic MUST NOT
> >>>
> >>> be sent over plain (unencrypted) RTP; that is, implementations MUST
> >>>
> >>> NOT negotiate cipher suites with NULL encryption modes.
> >>> DTLS-SRTP
> >>>
> >>> MUST be offered for every media channel.
> >>>
> >>>
> >>>
> >>> All data channels MUST be secured via DTLS.
> >>>
> >>>
> >>>
> >>> All implementations MUST implement DTLS 1.0, with the cipher suite
> >>>
> >>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve
> >>>
> >>> [FIPS186
> >>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#ref-
> >>
> >>>
> FIPS186>].
> >>> The DTLS-SRTP protection profile
> >>>
> >>> SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
> >>>
> >>> Implementations SHOULD implement DTLS 1.2 with the
> >>>
> >>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
> >>>
> >>> Implementations MUST favor cipher suites which support PFS over
> >>> non-
> >>>
> >>> PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.
> >>>
> >>> “
> >>
> >>
> >> --
> >>
> >> Magnus Westerlund
> >>
> >> ---------------------------------------------------------------------
> >> -
> >>
> >>
> Services, Media and Network features, Ericsson Research EAB/TXM
> >> ---------------------------------------------------------------------
> >> -
> >>
> >>
> Ericsson AB                 | Phone  [phone]
> >> Färögatan 6                 | Mobile [phone] SE-164 80
> >> Stockholm, Sweden | mailto: [e-mail]
> >> ---------------------------------------------------------------------
> >> -
> >
> >>
> --
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------