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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 03 May 2013 17:42 UTC

Return-Path: <prvs=783586931d=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 7AA4621F96E9 for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 10:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.05
X-Spam-Level:
X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[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 TrIJg11RTHN7 for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 10:42:53 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CA70A21F9798 for <mmusic@ietf.org>; Fri, 3 May 2013 10:37:50 -0700 (PDT)
X-AuditID: c1b4fb25-b7f396d000007d06-30-5183f5edf15a
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0B.A0.32006.DE5F3815; Fri, 3 May 2013 19:37:49 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Fri, 3 May 2013 19:37:49 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation
Thread-Index: AQHORpmC/JMg42bB/EOYWhKkPbD8pZjwrh2AgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIAAKEfF///lJwCAAPmFoIAAftYAgAA20vU=
Date: Fri, 3 May 2013 17:37:48 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B693@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> <5182A802.9020003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36A026@ESESSMB209.ericsson.se>, <5183E3B8.6060401@alum.mit.edu>
In-Reply-To: <5183E3B8.6060401@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvre7br82BBteXGFvMbG1lsfjT+ovR YuryxywWKzYcYHVg8Wh9tpfV4+/7D0weO2fdZfdYsuQnUwBLFLdNUmJJWXBmep6+XQJ3xufJ s9gKvglWvL+6gbWB8QNvFyMHh4SAicS2h5ZdjJxAppjEhXvr2boYuTiEBA4zSux8fY0RwlnM KHF24xNWkAY2AQuJ7n/aIKaIgIbEpK1qICXMArMYJaaf3MwIMkhYwE5ixvwOJhBbRMBe4mzH IjYIu0xi3qGpzCC9LAIqEqumx4KEeQV8JTatfQu16i2LxKXee2C9nAI6Elu29oLZjEDHfT+1 BsxmFhCXuPVkPhPE0QISS/acZ4awRSVePv7HCmErSrQ/bWCEqNeRWLD7ExuErS2xbOFrZojF ghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAWDq45bfqDsY750QOMUpz sCiJ8yZzNQYKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFINjEsM4m71W5va3dF/djbvUifP n3mbgqUqJ6w+/Ezxo45me6951es9wbaxax2umD2bpnjdr0nC19aFz9FiZwRnT2/wY4nqq/pK nduemP3gOy9+avn7qwld8xaffNA5b++q9x+Vp7T/3blXRLUiobXUzfyth9ctO6HPr8teRPdk v1FYwhIXVWwQpcRSnJFoqMVcVJwIAFBMSA14AgAA
Cc: Alan Johnston <alan.b.johnston@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
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: Fri, 03 May 2013 17:42:58 -0000

Hi,

>After rereading this and checking 4583, I realize my comment was based
>on a misunderstanding of what BFCP was doing. I thought you were saying
>that BFCP didn't use a=setup, and that the active party for the TCP/TLS
>connection was always the offerer. I see that was wrong - that it uses
>a=setup for that and says that the answer is the TLS server.

Correct. BFCP does use a=setup for the TCP connection establishment. Sorry if I was unclear.

Regards,

Christer





BFCP seems to have arranged its authentication so either end is capable
of being the TLS server, and it is only necessary to have *some*
mechanism for deciding which one will be. As long as that is the case, I
don't have a particular problem with it.

        Thanks,
        Paul

On 5/3/13 2:58 AM, Christer Holmberg wrote:
> Hi Paul,
>
>>> 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.
>>
>> I think that approach has limitations. What does one do when doing a subsequent o/a, especially in the opposite direction?
>
> Well, I could ask you to look it up in the BFCP RFC, but I doubt you'll find an answer there :)
>
>> And how does one distinguish when in a subsequent o/a you do/don't want to reestablish the connection rather than retaining the existing one?
>
> I would need some more time to think about that, but a few questions that came to my mind:
>
> 1) If the TLS connection already exists, is there a reason to reestablish it to begin with?
>
> 2) Would you need an o/a to reestablish the TLS connection to begin with? Once the roles have been determined (in the initial o/a), can't everything be handled on the TLS layer?
>
> 3) If the TLS connection already exists, is there a reason to renegotiate the TLS roles?
>
> 4) If a subsequent o/a is needed in order to reestablish the connection, and/or renegotiate the TLS roles, could the TLS connection first be terminated on the TLS layer, before the subsequent of/a is sent?
>
> Regards,
>
> Christer
>
>