Re: [clue] Comments on CaptureID and security

[Paul Kyzivat <[e-mail]>]

I have a side question on this: if RTCP is being multiplexed with RTP, 
and the RTP is being encrypted, is the RTCP also implicitly encrypted, 
or is it still an independently negotiated feature?

(Yes, I realize that doesn't solve the general problem for CLUE.)

	Thanks,
	Paul

On 1/18/17 6:53 AM, Magnus Westerlund wrote:
> 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#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]
>>> ----------------------------------------------------------------------
>>
>>>