Subject: Re: [clue] How is data channel secured?

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 2 Nov 2015 10:54:52 -0800

We could just add what Alissa  suggested to the framework: “This can be accomplished using SIP authentication [ref SIP doc] plus DTLS for the data channel [ref data channel doc]”.  And remove the part that says details are in the data channel doc.

Does this solve the problem?

Mark

From: Christer Holmberg [mailto:[email-masked]]
Sent: Saturday, October 31, 2015 5:54 AM
To: Alissa Cooper; Duckworth, Mark
Cc: [email-masked]
Subject: RE: [clue] How is data channel secured?

Hi Alissa,

Thanks for your input!

So, if I understand correctly, the issue is not how to secure the data channel, but how to secure the *signalling* that negotiates the data channel, i.e. SIP/SDP. THAT is currently not described in the CLUE data channel draft.

So, I agree that we should either add some text about that, or refer to another *CLUE* draft that talks about signalling security.

Regards,

Christer

From: Alissa Cooper [mailto:[email-masked]]
Sent: 31 October 2015 11:13
To: Duckworth, Mark <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; [email-masked]
Subject: Re: [clue] How is data channel secured?

Let me try to expand on this a bit so it’s more clear what the issue is.

The paragraph in question is:

"While other information in the CLUE protocol messages does not

   reveal specific identities, it can reveal characteristics and

   capabilities of the endpoints.  That information could possibly

   uniquely identify specific endpoints.  It might also be possible

   for an attacker to manipulate the information and disrupt the CLUE

   sessions.  It would also be possible to mount a DoS attack on the

   CLUE endpoints if a malicious agent has access to the data

   channel.  Thus, it MUST be possible for the endpoints to establish

   a channel which is secure against both message recovery and

   message modification. Further details on this are provided in the

   CLUE data channel solution document."

Thus there is a normative requirement here for endpoints to support a mechanism that secures the data channel against message recovery and modification. As noted, this is described for rtcweb in draft-ietf-rtcweb-security-arch, but clue is different in that it is relying on SIP/SDP to establish the session in the first place. So if the solution here is SIP authentication mechanisms to setup the session + DTLS for the data channel, then just say that. But you can’t say the details are provided in another document when that document provides no details, and you can’t fully rely on draft-ietf-rtcweb-security-arch which assumes a different framework for authenticating the other parties in the call.

Alissa

On Oct 22, 2015, at 3:44 AM, Duckworth, Mark <[email-masked]<mailto:[email-masked]>> wrote:

Hello Christer,

Alissa raised an issue about the data channel document, I copied it here:

======
There are no details about how the data channel is secured in draft-ietf-clue-datachannel (which should be cited here if it's going to be referenced). Nor are the details in draft-ietf-rtcweb-data-channel, but rather they are in draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security, where they are described for rtcweb which uses a different authentication model from clue. So how to do this actually needs to be explained either here or in the clue data channel document for clue specifically.
=====
Do you agree with her assessment?  Do we need to add something to the data channel document about how the data channel is secured?  I think it belongs there, not in the framework.

Mark

From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
Sent: Thursday, October 08, 2015 4:05 PM
To: Alissa Cooper
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [clue] New draft-ietf-clue-framework-23

Hi Alissa,
Thanks for the feedback.  Comments below, and questions for Roni.
Mark

From: Alissa Cooper [mailto:[email-masked]]
Sent: Saturday, October 03, 2015 8:45 AM
To: Duckworth, Mark
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [clue] New draft-ietf-clue-framework-23

Thanks for these updates. There are still a few points from my evaluation concerning Section 15 that are outstanding.

First, this text proposed by Roni did not make it into the draft:

As described in section 5, CLUE uses SIP/SDP to establish the
   session prior to exchanging any CLUE specific information. Thus
   the security mechanisms recommended for SIP [RFC3261], including
   user authentication and authorization, MUST be supported.

[Duckworth, Mark] Thanks for catching this, it was an oversight on my part.  It should be as you say, from Roni’s proposal. I will correct it.

Furthermore, if the position of the WG is that it isn’t even going to recommend the use of authentication, you at least need to explain why, under what conditions, and the threats associated with operating this way.

From my previous review:

"In
  addition, the media is based on RTP and thus existing RTP security
  mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported.
  Media security is also discussed in [I-D.ietf-clue-signaling] and
  [I-D.ietf-clue-rtp-mapping]."

I think it's worth pointing out in this document that DTLS/SRTP is required to use for CLUE-controlled m-lines.

[Duckworth, Mark] Roni, can you please clarify what the group’s final decision was on this? I thought we decided in April that DTLS/SRTP is mandatory to support, but not mandatory to use.  See this email topic https://mailarchive.ietf.org/arch/msg/clue/AC6H1QwQqTzSfdgOI8ZNT87OZOA . I counted six responses, with all six in favor of mandatory to support but not mandatory to use. I propose this alteration to the sentence about DTLS/SRTP in the framework document:

In addition, the media is based on RTP and thus existing RTP security mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported and SHOULD be used. If media is protected by other means, then DTLS/SRTP does not need to be used.

Also, I just did a quick skim of draft-ietf-clue-rtp-mapping and didn't see anything in there about media security.

[Duckworth, Mark] Roni, should I remove this reference to the RTP mapping document?  Or do you expect that document really will discuss media security?

"Thus, it MUST be possible for the endpoints to establish
  a channel which is secure against both message recovery and
  message modification. Further details on this are provided in the
  CLUE data channel solution document."

There are no details about how the data channel is secured in draft-ietf-clue-datachannel (which should be cited here if it's going to be referenced). Nor are the details in draft-ietf-rtcweb-data-channel, but rather they are in draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security, where they are described for rtcweb which uses a different authentication model from clue. So how to do this actually needs to be explained either here or in the clue data channel document for clue specifically.
[Duckworth, Mark] I think the data channel document is the right place to describe how the data channel is secured. I will add a proper reference to it in the framework.
Thanks,
Alissa

On Sep 24, 2015, at 3:04 PM, Duckworth, Mark <[email-masked]<mailto:[email-masked]>> wrote:

Changes from 22 to 23:
1.            Updates to Security Considerations section.
2.            Update version number of references to other CLUE documents in progress.
3.            Change some "MAY" to "may".
4.            Fix a few grammatical errors.

Mark
_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 3 Nov 2015 09:42:44 +0900

Something along these lines should work.

> On Nov 3, 2015, at 3:54 AM, Duckworth, Mark <[email-masked]> wrote:
> 
> From: Christer Holmberg [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: [email-masked] <mailto:[email-masked]>
>  <> 
> From: Alissa Cooper [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Duckworth, Mark <[email-masked] <mailto:[email-masked]>>
> Cc: Christer Holmberg <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Oct 22, 2015, at 3:44 AM, Duckworth, Mark <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hello Christer,
>  
> From: clue [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Duckworth, Mark
> Cc: [email-masked] <mailto:[email-masked]>
> From: Alissa Cooper [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: [email-masked] <mailto:[email-masked]>
> [Duckworth, Mark] Roni, can you please clarify what the group’s final decision was on this? I thought we decided in April that DTLS/SRTP is mandatory to support, but not mandatory to use.  See this email topic https://mailarchive.ietf.org/arch/msg/clue/AC6H1QwQqTzSfdgOI8ZNT87OZOA <https://mailarchive.ietf.org/arch/msg/clue/AC6H1QwQqTzSfdgOI8ZNT87OZOA> . I counted six responses, with all six in favor of mandatory to support but not mandatory to use. I propose this alteration to the sentence about DTLS/SRTP in the framework document:
>  
> On Sep 24, 2015, at 3:04 PM, Duckworth, Mark <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Changes from 22 to 23:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Nov 2015 01:14:45 +0000

Hi,

My question is whether the text should be in the data channel draft, or whether we will have some generic text on how to secure the CLUE signalling, which the data channel draft can then refer to.

Regards,

Christer

Sent: 03 November 2015 02:43

On Nov 3, 2015, at 3:54 AM, Duckworth, Mark <[email-masked]<mailto:[email-masked]>> wrote:

Mark

Hi Alissa,

Thanks for your input!

Regards,

Christer

From: Alissa Cooper [mailto:[email-masked]]
Sent: 31 October 2015 11:13
To: Duckworth, Mark <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [clue] How is data channel secured?

Alissa

Hello Christer,

======

Mark

Hi Alissa,

From my previous review:

"In

Changes from 22 to 23:

Mark

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 3 Nov 2015 11:09:29 +0900

> On Nov 3, 2015, at 10:14 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>  

I think the new text should go in the data channel draft. And the current generic text about signaling in the framework draft (4th para of section 15) should remain unchanged.

Alissa 

> On Nov 3, 2015, at 3:54 AM, Duckworth, Mark <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 3 Nov 2015 06:13:14 -0800

So if we add that new sentence (or similar) to the data channel draft, then this text can stay in the framework:

“Thus, it MUST be possible for the endpoints to establish a channel which is secure against both message recovery and message modification. Further details on this are provided in the CLUE data channel solution document.” [add proper reference to data channel draft]

Do you agree?

Mark

From: Alissa Cooper [mailto:[email-masked]]
Sent: Monday, November 02, 2015 9:09 PM
To: Christer Holmberg
Cc: Duckworth, Mark; [email-masked]
Subject: Re: [clue] How is data channel secured?

On Nov 3, 2015, at 10:14 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Alissa

Regards,

Christer

Mark

Hi Alissa,

Thanks for your input!

Regards,

Christer

Alissa

Hello Christer,

======

Mark

Hi Alissa,

From my previous review:

"In

Changes from 22 to 23:

Mark

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 4 Nov 2015 10:18:51 +0900

> On Nov 3, 2015, at 11:13 PM, Duckworth, Mark <[email-masked]> wrote:
> 

Yes. The changes to the data channel draft will probably require a bit more than just adding the sentence, given what is there now, but as far as the framework goes I think what you suggest above will work.

Alissa

> Cc: Duckworth, Mark; [email-masked] <mailto:[email-masked]>
> On Nov 3, 2015, at 10:14 AM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
>