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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 03 May 2013 17:33 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 3A6BF21F8FF0 for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 10:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.762
X-Spam-Level: **
X-Spam-Status: No, score=2.762 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1]
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 ZnISGLhHpyjb for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 10:33:00 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 6436921F99E1 for <mmusic@ietf.org>; Fri, 3 May 2013 09:20:09 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta15.westchester.pa.mail.comcast.net with comcast id XQti1l0081HzFnQ5FUL97U; Fri, 03 May 2013 16:20:09 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id XUL81l01C3ZTu2S3aUL9YC; Fri, 03 May 2013 16:20:09 +0000
Message-ID: <5183E3B8.6060401@alum.mit.edu>
Date: Fri, 03 May 2013 12:20:08 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.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>, <CAKhHsXGEiNLod6fXbOSP3HvVYtFi4iBQEUBe2x-5YQdwz8LAOQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> <5182A802.9020003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36A026@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36A026@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367598009; bh=y3g+oeCckohRnbNZIB8u5wYqwKF3y7Rgb4seSsFOlLg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gyvmn2cLGhokPIdzd8ZizByNlUXnTfV5aSgIA8/OzAmZY9KsDbzRWPIPB5XdYXEaL STJ7h54VGsOIoq1TIvmd36NFLUhbtVOw7Xtw9w3dq2/feHXAheBKbVP2RNy0B5ms9K LeHgS47eTccNaVun2Jmyx0XzwM9p/7GXAAfcCf214vi2LTxhcNT92OvXiGGUv2XBlW O+a2bOgiWPXEX3ECli661H2aWBl37y80pGSHpm0u8wCzJxBM/psWE+3eakOmHojCKm jbu84uIiup5Q27V1L4Da6o9TEWOSeH6mgwH83LsHsAywVmYsE3xglpQN9tYXkeVR+D eIXYkptvFF7sQ==
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:33:06 -0000

Christer,

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.

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