Re: [clue] Comments on CaptureID and security

[Roni Even <[e-mail]>]

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#section-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]
> ----------------------------------------------------------------------