Subject: [clue] Fwd: [rtcweb] Consensus call regarding media security

From: Marshall Eubanks <[email-masked]>
Date: Mon, 16 Apr 2012 10:56:10 -0400

I thought that CLUE people might be interested in this.

Encryption has not (to my knowledge) been seriously discussed in CLUE.
It is not mentioned
in the Requirements, Framework or Use Cases documents.

Now, RTCWEB has just made it mandatory (against some opposition, but
the consensus call is below). Of course, RTCWEB is not the
videoconferencing industry, and we clearly cannot mandate encryption
(as the videoconferencing industry has not). However

Some might say that encryption is at a layer below CLUE, but I
actually think that is wrong and that we are going to have to deal
with it some.  CLUE will include metadata (such as, potentially, the
participants names) and configuration options that users will expect
to have encrypted. I would actually regard it as a security breach to
say, transport will be encrypted, but all of the host of CLUE data
will carried in the clear.

Worse, I think it is a reality that this means that encrypted RTCWEB
session will be run with unencrypted CLUE telepresence sessions, and
we need to think about the implications of that.  I also think we are
going to have to think more than we have (or, at least, than I have)
about the general security implications of the CLUE data, how to best
authenticate CLUE exchanges, and how to ensure that CLUE traffic is
protected. Questions I see arising from this include

- should CLUE traffic be protected by https / SSL ? Is that a MAY, a
SHOULD or a MUST ?
- what are the security information of the information shared by CLUE
? Does some of it (e.g., user names) require more protection than
other pieces.
- If a session is encrypted, is the CLUE information also required to
be encrypted ? Does that use the same security infrastructure, or a
separate one? For example, if there is encryption through a shared
secret distributed through a PKI or by some  other means, does CLUE
share that secret? If the CLUE exchange goes on _before_ the PKI
exchange, using some other PKI or SSL, does it change  once the shared
secret has been distributed?

I know that all of this might not be required for RTCWEB, but we might
as well start thinking about it anyway.

Regards
Marshall

---------- Forwarded message ----------
From: Magnus Westerlund <[email-masked]>
Date: Mon, Apr 16, 2012 at 4:36 AM
Subject: Re: [rtcweb] Consensus call regarding media security
To: [email-masked], EKR <[email-masked]>

WG, EKR

The deadline for this call of consensus has ended. I note that there has
been discussion of a number of details and additional views on the
actual consensus statement made. Some supporting the consensus from the
meeting room and some opposing it. In the end I determine that the two
consensus statements are confirmed:

 The first was that there was overwhelming consensus that all RTP
 packets SHALL be protected by SRTP.

 Secondly that no one objected against making DTLS-SRTP a mandatory to
 implement and the default keying mechanism. Additional mechanisms are
 not precluded.

>From the discussion in the thread I would note the following:

1) Null cipher for encryption is strongly desired but an actual proposal
is needed for how to express this.

2) Details of the SRTP and DTLS-SRTP usage in this WG needs to be
defined. This is for continued discussion. I hope our editor of the
security architecture can make a proposal to the WG to consider.

3) The discussion of additional keying mechanisms such as Security
Descriptions and Encrypted Key Transport will continue.

Cheers

Magnus

On 2012-03-28 16:50, Magnus Westerlund wrote:
> WG,
>
> In todays RTCWEB WG meeting there was discussion around media security
> mechanism. In this meeting there was some clear consensus in the
> meeting which we would like to confirm on the list.
>
> The first was that there was overwhelming consensus that all RTP
> packets SHALL be protected by SRTP.
>
> Secondly that no one objected against making DTLS-SRTP a mandatory to
> implement and the default keying mechanism. Additional mechanisms are
> not precluded.
>
> WG participants may state their position regarding these consensus calls
> until 12th of April when the chairs will declare the final consensus. If
> you where present in the meeting room and comment on this, please
> indicate that.
>
> Best Regards
>
> Magnus Westerlund
> For the WG chairs
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Roni Even" <[email-masked]>
Date: Mon, 16 Apr 2012 19:33:48 +0300

Hi Marshall,
I think that RTCweb discussed the media security and I believe that video
conferencing systems support SRTP. The question will be the keying mechanism
and currently I think that most support SDES (there was work done in IMTC to
recommend the security profile and the outcome was SDES) and later may
support DTLS-SRTP. 
Another issue will be the usage of ICE and I think it will be good for us to
look at the proposed profile in RTCweb.
As for the CLUE signaling I think it should be secure, I am sure that it
will not go through IESG without security. 
Roni 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Marshall Eubanks
> Sent: Monday, April 16, 2012 5:56 PM
> To: clue
> Subject: [clue] Fwd: [rtcweb] Consensus call regarding media security
> 
> Some might say that encryption is at a layer below CLUE, but I actually
> think that is wrong and that we are going to have to deal with it some.
> CLUE will include metadata (such as, potentially, the participants
> names) and configuration options that users will expect to have
> encrypted. I would actually regard it as a security breach to say,
> transport will be encrypted, but all of the host of CLUE data will
> carried in the clear.
> 
> session will be run with unencrypted CLUE telepresence sessions, and we
> need to think about the implications of that.  I also think we are
> - what are the security information of the information shared by CLUE ?
> Does some of it (e.g., user names) require more protection than other
> pieces.
> The deadline for this call of consensus has ended. I note that there
> has been discussion of a number of details and additional views on the
> 1) Null cipher for encryption is strongly desired but an actual
> proposal is needed for how to express this.
> 
> > WG participants may state their position regarding these consensus
> > calls until 12th of April when the chairs will declare the final
> > consensus. If you where present in the meeting room and comment on
> > this, please indicate that.
> >
> > Best Regards
> >
> > Magnus Westerlund
> > For the WG chairs
> >
> Ericsson AB                | Phone  +46 10 7148287 Färögatan 6
>        | Mobile +46 73 0949079
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue