Subject: [clue] Comments on CaptureID and security

From: Roni Even <[email-masked]>
Date: Wed, 18 Jan 2017 08:33:26 +0000

Hi,
We got the following comments from Magnus when he reviewed the registration, he also had similar comments during IETF LC

"This registration is fine with the exception that it isn't clear on the security consideration for the CaptureID field as SDES item. I fail to find any limitations or even recommendations for how the value is created by the implementation. Nor does the security considerations discuss the potential risk that the capture ID is privacy sensetive, like "Adrian's Mic" rather than AC0 as in the example in the data model document. The data model document is fairly clear on the need for confidentiality and authorization for the whole data model document.

However, this thinking has not been raised and clarified in this specific move of the information into the RTP protocol.

So, I would recommend a discussion in general that the field should have anonymous labels, that do not contain privacy information. Then one should be clear on what requirements one put on transporting these fields in RTP. And that depends on how certain one can be that it is anonymous or that it may contain sensitive information and therefore should be confidentiality protected. In all cases this field needs integrity and source authentication. The clue mapping require implementation of SRTP with DTLS-SRTP keying, however, it fails to be specific on which protection profiles that are to be supported, both for the SRTP as well as the crypto functions for the key handshakes in DTLS-SRTP.

I recommended that registration is hold off for the RTP header extension parts (IANA review request #944570), where this gets even worse by the fact that even if RTP and RTCP is confidentiality protected, the RTP header extension is not per default confidentiality protected, and there is a additional protection mechanism that needs to be implemented."

The major point are:

1.       We need to specify the considerations for creating CaptureID, the data model talks in general about securing the CLUE message, the CLUE protocol and framework are silent about this parameter. Any suggestions? Also should this be specified in the RTP mapping or in the CLUE protocol?

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.

"

Thanks
Roni

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Jan 2017 09:44:56 +0100

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
>
>    [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>].
>
>
>
>    [FIPS186
> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#ref-FIPS186>].
> The DTLS-SRTP protection profile
>
> “

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roni Even <[email-masked]>
Date: Wed, 18 Jan 2017 09:44:18 +0000

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:[email-masked]]
> Sent: יום ד 18 ינואר 2017 10:45
> To: Roni Even; [email-masked]
> 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.
> 
> 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
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Jan 2017 12:53:05 +0100

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:[email-masked]] Sent: יום ד 18 ינואר 2017
>> 10:45 To: Roni Even; [email-masked] Cc: Jonathan Lennox Subject: Re:
>> Comments on CaptureID and security
>>
>> Hi,
>>
>> 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
>>
>>> 2.       What do we want to say about supported security profile?
>>> For example does the following directive from
looks good for CLUE?
>>> implement DTLS [RFC4347 <https://tools.ietf.org/html/rfc4347>]
>>> and DTLS-SRTP [RFC5763
>>> <https://tools.ietf.org/html/rfc5763>][RFC5764] for
>> SRTP
>>>
>>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#ref-I-
>>
>>>
D.ietf-tsvwg-sctp-dtls-encaps>].
>>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#ref-
>>
>>>
FIPS186>].
>> Färögatan 6                 | Mobile +46 73 0949079 SE-164 80
>> Stockholm, Sweden | mailto: [email-masked]
-- 

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Wed, 18 Jan 2017 12:20:39 +0000

Hi Magnus,
I want to see if others involved in  CLUE  work are OK with RTCP and RTP header encryption of the CaptureID or define how to create CaptureID we can say for example:

" The construction of the CaptureID value is implementation dependent. Therefore there exist a risk that the CaptureID contains privacy sensitive information or otherwise revealing information about the communication session to third parties. Since the CaptureID does not need to be human readable an arbitrary value that is not related to the CLUE session MUST be used, e.g. use AC0 and not Bob's microphone. Confidentiality protection should be applied to avoid this risk. "

Or

" The construction of the CaptureID value is implementation dependent. Therefore there exist a risk that the CaptureID contains privacy sensitive information or otherwise revealing information about the communication session to third parties. Since the CaptureID does not need to be human readable an arbitrary value that is not related to the CLUE session MUST be used, e.g. use AC0 and not Bob's microphone. Therefore confidentiality protection is always applied to avoid this risk. "

Looking for feedback from the WG about the SRTP profiles to implemented/support

I suggested the following text based on RTCWEB security architecture:

"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]. 
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."

Roni Even

> Sent: יום ד 18 ינואר 2017 13:53
> 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
> 
> > 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."
> >
> > So we can reference the rtcweb security architecture or use the text I
> > copied from there to define a security profile
> >
> > 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
> >
> >> as it fails to specify if RTCP encryption is mandatory to use or not.
> >> There are protection profiles that only have confidentiality
> >> 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
> >>
> >>> I-

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jan 2017 11:25:49 -0500

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 20 Jan 2017 17:28:09 +1100

Do we need to consider PERC when making that recommendation? An MDF 
would need access to the CaptureID in order to making switching 
decisions in CLUE is used.

Regards, Christian

On 18/01/2017 10:53 PM, Magnus Westerlund wrote:
> bad construction can have that I can think of. Thus, I support going 
> in that direction.
>
> 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.
>
> 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.
>
> 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
>

---

From: Roni Even <[email-masked]>
Date: Sun, 22 Jan 2017 05:10:10 +0000

Hi Christian,
I am not sure if it is needed for switching but if it does this is something for PERC to say that it needs to be secured using the hop by hop key
Roni

> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: יום ו 20 ינואר 2017 08:28
> To: [email-masked]
> Subject: Re: [clue] Comments on CaptureID and security
> 
> would need access to the CaptureID in order to making switching decisions in
> CLUE is used.
> 
> Regards, Christian
> 
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue