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

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

Return-Path: <prvs=68353fe77e=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 4DABC21F8619 for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 23:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.136
X-Spam-Level:
X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 SrxpKfirrY0y for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 23:59:02 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B8CFC21F8675 for <mmusic@ietf.org>; Thu, 2 May 2013 23:59:00 -0700 (PDT)
X-AuditID: c1b4fb25-b7f396d000007d06-8a-518360339320
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 98.B3.32006.33063815; Fri, 3 May 2013 08:58:59 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Fri, 3 May 2013 08:58:59 +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///lJwCAAPmFoA==
Date: Fri, 3 May 2013 06:58:59 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36A026@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>
In-Reply-To: <5182A802.9020003@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.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvra5xQnOgwd075hYzW1tZLP60/mK0 mLr8MYvFig0HWB1YPFqf7WX1+Pv+A5PHzll32T2WLPnJFMASxW2TlFhSFpyZnqdvl8Cdce/M fJaCDu6KZ//EGxgvcnQxcnJICJhIbJq8lRXCFpO4cG89WxcjF4eQwGFGiaN90xghnMWMEmdW TAPKcHCwCVhIdP/TBjFFBDQkJm1VAylhFpjFKDH95GZGkEHCAnYSM+Z3MIHYIgL2Emc7FrFB 2FkSK+b0gNksAioSm251sIPYvAK+EpMvdUMt7mSR+N47E+wiTgEdiU9LVoANYgS67vupNWA2 s4C4xK0n85kgrhaQWLLnPDOELSrx8vE/qG8UJa5OXw5VryOxYPcnNghbW2LZwtfMEIsFJU7O fMIygVFsFpKxs5C0zELSMgtJywJGllWM7LmJmTnp5UabGIHRdHDLb9UdjHfOiRxilOZgURLn TeZqDBQSSE8sSc1OTS1ILYovKs1JLT7EyMTBCSK4pBoYWeaJt/5UuBYsnPlrGouT7Oav36ZY 3MzeajA5QN4yIzhi5SpzJ/XoY+wyMa+UpjztP32i9GiX7CmfjCTFeKnvgk9WpViLrWCoemLc tOG87+q7RwJmM5+Zv0BfiyXn1QKv/ZG81rO2flh4ND6U7eNUtlesIdOFD6nteffv2FaHGw+l fk73aOfmUGIpzkg01GIuKk4EAIRymeJ5AgAA
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 06:59:08 -0000

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