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

"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Mon, 06 May 2013 12:42 UTC

Return-Path: <albrecht.schwarz@alcatel-lucent.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 07F6F21F8972 for <mmusic@ietfa.amsl.com>; Mon, 6 May 2013 05:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 xyWmccPku1Vu for <mmusic@ietfa.amsl.com>; Mon, 6 May 2013 05:42:03 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6AF21F901D for <mmusic@ietf.org>; Mon, 6 May 2013 05:40:55 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r46CekJ4024267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 May 2013 07:40:47 -0500 (CDT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r46Cee9x014209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 May 2013 08:40:46 -0400
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 6 May 2013 08:40:45 -0400
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 6 May 2013 14:40:22 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Justin Uberti <juberti@google.com>
Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation
Thread-Index: AQHORpl/XH1yp96NPUWvLDnzWSG5+pjwrh2AgAAD2gCAABUxgIAAXkyAgABRLxCAALuJAIABTZkAgAAPHYCABID4oA==
Date: Mon, 6 May 2013 12:40:21 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1AC033489@FR711WXCHMBA03.zeu.alcatel-lucent.com>
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> <3879D71E758A7E4AA99A35DD8D41D3D91D45A655@xmb-aln-x14.cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0329D7@FR711WXCHMBA03.zeu.alcatel-lucent.com> <3879D71E758A7E4AA99A35DD8D41D3D91D462E4B@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D462E4B@xmb-rcd-x14.cisco.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC033489FR711WXCHMBA03zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
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: Mon, 06 May 2013 12:42:09 -0000

Mo

the root cause in your argumentation seems to be related to the term "client/server".
Looks like that you are equating "TLS client" equal to "TCP client" etc, right?

However (in our discussion), "client/server" is a protocol, - and thus a protocol layer -, specific concept.
RFC 793 is about TCP client/server entities.
RFC 5246 is about TLS client/server entities (and NOT TCP client/server).

RFC 4975 defines MSRP client and servers (such as a MSRP conference server) as an example of application protocol related client/server concepts (e.g., MSRP/TLS/TCP).

RFC 4582 defines BFCP floor control client/server entities as an example of application protocol related client/server concepts (e.g., BFCP/TLS/TCP).


Second: RFCs for user plane (protocols) (above list) and control plane (here SIP and SDP) are different items. An SDP RFC can't "redefine" above RFCs.
Right, there might be gaps, hidden assumptions, not documented requirements in some of the referred SDP RFCs, but we shouldn't mix both areas.

Regards,
Albrecht


From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: Freitag, 3. Mai 2013 18:54
To: Schwarz, Albrecht (Albrecht); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation

TLS RFC 5246 section 7.4.1.2:
When a client first connects to a server, it is required to send the ClientHello as its first message.

TCP RFC 793 section 2.7:
The OPEN call also specifies whether the connection establishment is to be actively pursued, or to be passively waited for.

You are correct that TLS does not specify any tight coupling to TCP, but how can you interpret the above to mean anything other than "clients actively connect to passive servers"?

Since TLS and DTLS do not support negotiating client/server roles, but rather derive them from the connection (and DTLS-SRTP specifies how to negotiate the connection as active/passive/actpass in SDP O/A), how would you support the role inversion you propose? How would a TCP listener know whether it can invert roles from server to client and send TLS ClientHello?

Perhaps EKR can chime in, but I just don't see the flexibility you describe being supported in TLS, so I don't see why SDP would need extensions to signal such flexibility.

Mo


From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Sent: Friday, May 03, 2013 10:13 AM
To: Mo Zanaty (mzanaty); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation

Mo

> If you mean TCP and TLS client/server roles can differ, I don't see that flexibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense for SDP to describe flexibility which is not supported in the underlying protocol.

I disagree with your refered justification, primarily because

1.  RFC 5246, sec. 7.4 does not provide such info explicitly ("can't find any TCP related info")

2.  TLS itself (RFC 5246) is designed to be transport protocol independent (see section 1: "At the lowest level, layered on top of some reliable transport protocol ...")

3.  TLS-over-SCTP (RFC 3436): there is not any client/server concept in SCTP (RFC 2960)! SCTP associations are established between two SCTP endpoints ... (rather a peer-to-peer concept than client/server)

4.  TLS-over-TCP: the establishment of a TLS session could be principally delayed wrt the TCP connection establishment; the TCP client/server role is ONLY relevant during the state transitioning from CLOSED to ESTAB (RFC 793); ie the TCP roles "dissolve" with a successfully established TCP connection state.

I fail to see any tight coupling between TLS and TCP.

Regards,
Albrecht

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: Donnerstag, 2. Mai 2013 22:06
To: Schwarz, Albrecht (Albrecht); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation

> role assignments at IP transport layer and security session layer may principally be different!

If you mean TCP and TLS client/server roles can differ, I don't see that flexibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense for SDP to describe flexibility which is not supported in the underlying protocol.

I agree it is somewhat confusing for DTLS-SRTP to use an attribute originally defined for TCP, but I don't see any practical problem or deficiency that would be solved by the proposed "a=setup:PROTOCOL:" attribute extension.

Mo


From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Sent: Thursday, May 02, 2013 3:15 AM
To: Mo Zanaty (mzanaty); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation

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