Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 02 May 2013 18:09 UTC

Return-Path: <prvs=7834fac474=christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F80421F8FA7 for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 11:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.874
X-Spam-Level:
X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlElZLhfMQeG for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 11:09:41 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D394021F8EB3 for <mmusic@ietf.org>; Thu, 2 May 2013 11:09:40 -0700 (PDT)
X-AuditID: c1b4fb30-b7f3a6d0000007a4-0f-5182abe3d90a
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A7.2A.01956.3EBA2815; Thu, 2 May 2013 20:09:39 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Thu, 2 May 2013 20:09:39 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Francois Audet <francois.audet@skype.net>, Alan Johnston <alan.b.johnston@gmail.com>, "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation
Thread-Index: AQHORpmC/JMg42bB/EOYWhKkPbD8pZjwrh2AgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIAAKEfF///k9QCAACTW+w==
Date: Thu, 02 May 2013 18:09:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369C11@ESESSMB209.ericsson.se>
References: <E888F149-12FE-4F23-A270-F861123BAC7B@tokbox.com> <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <CAOJ7v-2XUzVr3kL=emR_7w49th3mowa_WQG4wVVmD7__uA8APw@mail.gmail.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <CAKhHsXGEiNLod6fXbOSP3HvVYtFi4iBQEUBe2x-5YQdwz8LAOQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se>, <8d9d933dfa7f4b2182144018905e1514@DFM-DB3MBX15-06.exchange.corp.microsoft.com>
In-Reply-To: <8d9d933dfa7f4b2182144018905e1514@DFM-DB3MBX15-06.exchange.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvre7j1U2BBq8emljMbG1lsfjT+ovR omM1i8XU5Y9ZLFZsOMDqwOrR+mwvq8ff9x+YPHbOusvusWTJTyaPWw8msQWwRnHbJCWWlAVn pufp2yVwZyw+tZat4JRVxezlE1kaGCcbdDFyckgImEi8+HaECcIWk7hwbz1bFyMXh5DAYUaJ 02cfsoEkhAQWM0r0HrfoYuTgYBOwkOj+pw1SIyKwiFHi4vMTrCA1zAK+Eu9/TmcHsYUF7CRm zO8AGyoiYC9xtmMRG4SdJbG27yILyBwWARWJh8sLQMK8QK3LNs9hgti7k0Xi8tfLYPWcAtES 8x5cA7MZgY77fmoNE8QucYlbT+ZDHS0gsWTPeWYIW1Ti5eN/rCDzJQQUJZb3y0GU60ncmDqF DcLWlli28DUzxF5BiZMzn7BMYBSbhWTqLCQts5C0zELSsoCRZRUje25iZk56ufkmRmB0Hdzy 22AH46b7YocYpTlYlMR5k7kaA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwggguqQZGvkWfa+LO GlwIy9HpC2SXzDjtmfXZ2P7hVsYwxsq9jw5at+TkHL17vERvRdGkbR/8lVjOB2/gMCmdsHl7 W4eTu+zq/cyyjxZb3LjAXP2db2ZlTf1qyYbqt18UPG1zDh32vTj3GG+xjOX9ORybPjw5eqNo QcTGcwZTC3a0BOYJXD69L0N+p4WvEktxRqKhFnNRcSIAcPo3ZoECAAA=
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2013 18:09:46 -0000

Hi,

One good reason is if both clients are behind NATs, connected to SBCs. The SBCs will typically make the clients "active", in order to make the TCP connection traverse the NAT. Hence both clients will also become TLS clients. But, TLS does not define a mechanism to handle "collisions" when both endpoints act as TLS client, which means some intermediary needs to act as TLS server towards the clients.

Now, I realize that may not be a "valid" reason in IETF, and with ICE it may not be a long-term problem :) 

But, is there a reason why it is NOT be a good idea?

Regards,

Christer
________________________________________
From: Francois Audet [francois.audet@skype.net]
Sent: Thursday, 02 May 2013 8:52 PM
To: Christer Holmberg; Alan Johnston; Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation

You think a rule the binds TLS client role to offer/answer is *good*.... Really, why?

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 2 May, 2013 10:31
To: Alan Johnston; Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation


Hi,

RFC 4572 specifies that the "active" endpoint also takes the role as TLS client. At least MSRP refers to RFC 4572.

AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act as TLS client - ie it separates the TCP setup from TLS roles - which I think is very good.

Regards,

Christer



________________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Alan Johnston [alan.b.johnston@gmail.com]
Sent: Thursday, 02 May 2013 8:05 PM
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Interestingly, I have yet to see any browser use a=setup for DTLS-SRTP.  Is this attribute really needed?  How do things work if one or both browsers don't include it?

- Alan -


On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com<mailto:albrecht.schwarz@alcatel-lucent.com>> wrote:
The RFC situation is not really clear, even confusing concerning client/server role negotiations (in case of transport security sessions over connection-oriented IP transport protocols).


.         RFC 4145 is only about TCP, i.e., TCP client/server role assignments. Thus, the RFC 4145 introduced SDP attribute is TCP specific.

.         draft-ietf-mmusic-sctp-sdp: seems to profile the "a=setup:" attribute for SCTP path establishment directions . (?)

.         RFC 5763 uses the TCP SDP attribute for DTLS session establishment, i.e. DTLS client/server role assignments; that's actually a semantical change of this SDP element vs RFC 4145

. and DTLS is TLS based, leading to the question of role/assignments in case of TLS/TCP sessions?
I.e., the TCP client/server and also TLS client/server roles? Keeping in mind that the role assignments at IP transport layer and security session layer may principally be different!

The "a=setup" definition by RFC 4145 is unfortunate in my opinion.
Required seems to be a generic SDP specification (i.e., outside RFC 4145), which may be then tight to the concerned protocol. Sth like an explicit indication "a=setup:PROTOCOL:" or an implicit indication by adding an identifier.


The "m=" line <proto> element does not really help to reduce ambiguity (as Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "transport". The proto field identifies a whole stack of protocol layers.").

Albrecht
PS
I would see following parameter values for a SDP "a=setup:PROTOCOL:" attribute extension:
L4: TCP, SCTP, DCCP(?)
L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling .)



From: mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org> [mailto:mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the other leg will answer with active or passive but not actpass.

A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and alter SDP in complex ways to generate two answers from two offers, part of which is deciding which answer should become active and which should become passive.

The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unaltered by a B2BUA which delays offers on both legs. Generating two answers from two offers is much more complex than simply forwarding the offers as answers.

DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be actpass. TCP is harder since RFC 4145 allows offers to be active, passive, or actpass, causing more complex reinvites to resolve active/active or passive/passive conflicts.

Mo


On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com<mailto:juberti@google.com>> wrote:
I think Paul means the active/passive attributes in RFC 5763, but I'm still not sure about how 3rd party call control would be handled in this case, i.e. when both endpoints think they are offerers and set a=setup:actpass.

ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.11.

On Wed, May 1, 2013 at 2:10 PM, Gustavo García <ggb@tokbox.com<mailto:ggb@tokbox.com>> wrote:
I saw it, but that is all about TCP client/server role and not DTLS client/server role.   Are we supposed to use the same "setup" attribute for dtls role negotiation even if it is over UDP?

I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misunderstanding something.

On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> On 5/1/13 2:26 PM, Gustavo García wrote:
>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which side is the DTLS server must be established via some out-of-band mechanism such as SDP."
>>
>> What is the specification on how to signal that in SDP?
>>
>> Specifically in case of 3pcc where both endpoints are SDP offerers which one should take the client and server roles for DTLS?    Should we tie that role to ICE controlled/controlling roles or should we negotiate it in the SDP somehow?
>
> See RFC4145.
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org<mailto:mmusic@ietf.org>
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic