From internet-drafts@ietf.org Thu May 3 05:55:37 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B1E21F85B1; Thu, 3 May 2012 05:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 xzM2veLX4677; Thu, 3 May 2012 05:55:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE50C21F85A8; Thu, 3 May 2012 05:55:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120503125536.25955.93055.idtracker@ietfa.amsl.com> Date: Thu, 03 May 2012 05:55:36 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-msrp-cema-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 12:55:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Connection Establishment for Media Anchoring (CEMA) for = the Message Session Relay Protocol (MSRP) Author(s) : Christer Holmberg Staffan Blau Eric Burger Filename : draft-ietf-simple-msrp-cema-05.txt Pages : 21 Date : 2012-05-03 This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is optional. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages, and thus also enables a secure end-to-end MSRP communication in networks where such middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-cema/ From ben@nostrum.com Thu May 3 14:52:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747AB21F86F7 for ; Thu, 3 May 2012 14:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ZjJIOpZGU8ZH for ; Thu, 3 May 2012 14:52:52 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF221F86E2 for ; Thu, 3 May 2012 14:52:51 -0700 (PDT) Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q43LqmVL046764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 May 2012 16:52:48 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 3 May 2012 16:52:50 -0500 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "simple-chairs@tools.ietf.org Chairs" , draft-ietf-simple-msrp-cema.all@tools.ietf.org Subject: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 21:52:52 -0000 This is a working group last call for draft-ietf-simple-msrp-cema-05. We performed a previous WGLC on this draft last fall, and requested = publication of revision 03. Since then, the IESG review resulted in a = significant rewrite of the security considerations section, as well as a = few other changes. We want to confirm that the current text still = reflects work group consensus. Since this is a repeat last call, we will attempt a shortened review = cycle. Please focus your review on the changes since revision 03, and = send your comments to the list and the draft authors by the end of = Friday, 11 May 2012.=20 The current version is available at the following URL: http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-05 And here's a diff between 05 and 03: = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Ddraft-ietf-simple= -msrp-cema-03.txt&url2=3Ddraft-ietf-simple-msrp-cema-05.txt Thanks! Ben.= From R.Jesske@telekom.de Thu May 3 23:20:30 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB2121F8713 for ; Thu, 3 May 2012 23:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-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 VQMat9PkoN65 for ; Thu, 3 May 2012 23:20:30 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 28BE521F8711 for ; Thu, 3 May 2012 23:20:29 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 04 May 2012 08:20:27 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Fri, 4 May 2012 08:20:27 +0200 From: To: , Date: Fri, 4 May 2012 08:20:26 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 Thread-Index: Ac0pdxwG2c8+GBKGTMefnoFdDEAXPgARrHaA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DF15C4E9@HE111648.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: simple-chairs@tools.ietf.org, draft-ietf-simple-msrp-cema.all@tools.ietf.org Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 06:20:31 -0000 Dear all, I'm happy with the changes. No additional comments. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im Auftrag vo= n Ben Campbell Gesendet: Donnerstag, 3. Mai 2012 23:53 An: Simple WG Cc: simple-chairs@tools.ietf.org Chairs; draft-ietf-simple-msrp-cema.all@to= ols.ietf.org Betreff: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 This is a working group last call for draft-ietf-simple-msrp-cema-05. We performed a previous WGLC on this draft last fall, and requested publica= tion of revision 03. Since then, the IESG review resulted in a significant= rewrite of the security considerations section, as well as a few other cha= nges. We want to confirm that the current text still reflects work group co= nsensus. Since this is a repeat last call, we will attempt a shortened review cycle.= Please focus your review on the changes since revision 03, and send your c= omments to the list and the draft authors by the end of Friday, 11 May 2012= . The current version is available at the following URL: http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-05 And here's a diff between 05 and 03: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Ddraft-ietf-simple-= msrp-cema-03.txt&url2=3Ddraft-ietf-simple-msrp-cema-05.txt Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From pkyzivat@alum.mit.edu Fri May 4 07:06:59 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9720221F8716 for ; Fri, 4 May 2012 07:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] 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 sj4YEY5YOcbJ for ; Fri, 4 May 2012 07:06:59 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id D057C21F86EF for ; Fri, 4 May 2012 07:06:58 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id 5pSk1j0071vXlb855q6qQ4; Fri, 04 May 2012 14:06:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id 5q6y1j01V07duvL3dq6yv1; Fri, 04 May 2012 14:06:58 +0000 Message-ID: <4FA3E281.2060500@alum.mit.edu> Date: Fri, 04 May 2012 10:06:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:06:59 -0000 Ben, This generally looks good, but I found some editorial errors: Something has gone wrong in the editing of section 6.4. The following paragraph now says the same thing twice: This document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media, and that they are able to modify the SDP address information associated with the MSRP media. This is evolved from a paragraph that had two sentences saying complementary things, and the point made in that 2nd sentence has been lost. In section 7.3: s/is use without/is used without/ In section 7.5: However, this relies on that the SDP signaling is integrity protected, which may not always be the case. This isn't proper English. I suggest: However, this relies on SDP signaling being integrity protected, which may not always be the case. Also in that section the following has English problems: Therefore, it addition to the authentication mechanisms defined in RFC 4975, it is RECOMMENDED that a CEMA-enabled MSRP endpoint also supports self-signed certificates together Certificate Management Service [RFC6072], to which it publishes its self-signed certificate and from which it fetches on demand the self-signed certificates of other endpoints. I suggest: s/it addition/in addition/ s/together/together with the/ In section 7.6: - MSRPS: Security Mechanisms that does not rely on trusted signaling such as name based authentication s/that does not/that do not/ Thanks, Paul On 5/3/12 5:52 PM, Ben Campbell wrote: > This is a working group last call for draft-ietf-simple-msrp-cema-05. > > We performed a previous WGLC on this draft last fall, and requested publication of revision 03. Since then, the IESG review resulted in a significant rewrite of the security considerations section, as well as a few other changes. We want to confirm that the current text still reflects work group consensus. > > Since this is a repeat last call, we will attempt a shortened review cycle. Please focus your review on the changes since revision 03, and send your comments to the list and the draft authors by the end of Friday, 11 May 2012. > > The current version is available at the following URL: > > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-05 > > And here's a diff between 05 and 03: > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-simple-msrp-cema-03.txt&url2=draft-ietf-simple-msrp-cema-05.txt > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From christer.holmberg@ericsson.com Fri May 4 12:27:03 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF2221F8613 for ; Fri, 4 May 2012 12:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.101, 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 hcRBflj4ZHVP for ; Fri, 4 May 2012 12:27:02 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEA121F8598 for ; Fri, 4 May 2012 12:27:02 -0700 (PDT) X-AuditID: c1b4fb30-b7c78ae000006de5-a7-4fa42d84e31d Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 08.97.28133.48D24AF4; Fri, 4 May 2012 21:27:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 4 May 2012 21:27:00 +0200 From: Christer Holmberg To: Paul Kyzivat , "simple@ietf.org" Date: Fri, 4 May 2012 21:26:59 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 Thread-Index: Ac0p/y1jvUZVdTGuQxORu46maMplCgAK2d4u Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4400133B@ESESSCMS0356.eemea.ericsson.se> References: , <4FA3E281.2060500@alum.mit.edu> In-Reply-To: <4FA3E281.2060500@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:27:03 -0000 Hi Paul, > This generally looks good, but I found some editorial errors: > > Something has gone wrong in the editing of section 6.4. The following > paragraph now says the same thing twice: > > This document assumes that Middleboxes are able to modify the SDP > address information associated with the MSRP media, and that they are > able to modify the SDP address information associated with the MSRP > media. > > This is evolved from a paragraph that had two sentences saying > complementary things, and the point made in that 2nd sentence has been lo= st. The 2nd sentence was removed based on IESG comments, but it seems like some= copy/paste error has occured. So, I suggest remvoing the text after comma. ------------ > In section 7.3: s/is use without/is used without/ I'll fix as suggested. ------------ > In section 7.5: > > However, this relies on that the SDP signaling is > integrity protected, which may not always be the case. > > This isn't proper English. I suggest: > > However, this relies on SDP signaling being > integrity protected, which may not always be the case. I'll fix as suggested. ------------ > Also in that section the following has English problems: > > Therefore, it addition to the authentication mechanisms defined in > RFC 4975, it is RECOMMENDED that a CEMA-enabled MSRP endpoint also > supports self-signed certificates together Certificate Management > Service [RFC6072], to which it publishes its self-signed certificate > and from which it fetches on demand the self-signed certificates of > other endpoints. > > I suggest: > > s/it addition/in addition/ > s/together/together with the/ I'll fix as suggested. ------------ > In section 7.6: > > - MSRPS: Security Mechanisms that does not rely on trusted signaling > such as name based authentication > > s/that does not/that do not/ I'll fix as suggested. ------------ Thanks for the comments! Regards, Christer On 5/3/12 5:52 PM, Ben Campbell wrote: > This is a working group last call for draft-ietf-simple-msrp-cema-05. > > We performed a previous WGLC on this draft last fall, and requested publi= cation of revision 03. Since then, the IESG review resulted in a significa= nt rewrite of the security considerations section, as well as a few other c= hanges. We want to confirm that the current text still reflects work group = consensus. > > Since this is a repeat last call, we will attempt a shortened review cycl= e. Please focus your review on the changes since revision 03, and send your= comments to the list and the draft authors by the end of Friday, 11 May 20= 12. > > The current version is available at the following URL: > > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-05 > > And here's a diff between 05 and 03: > > http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Ddraft-ietf-simpl= e-msrp-cema-03.txt&url2=3Ddraft-ietf-simple-msrp-cema-05.txt > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From nancy.greene@ericsson.com Mon May 7 08:34:21 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0898421F861E for ; Mon, 7 May 2012 08:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 EF6GicxDdQLf for ; Mon, 7 May 2012 08:34:18 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 716CD21F85FD for ; Mon, 7 May 2012 08:34:18 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q47FY7Bm009106 for ; Mon, 7 May 2012 10:34:17 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 7 May 2012 11:34:13 -0400 From: Nancy Greene To: "simple@ietf.org" Date: Mon, 7 May 2012 11:34:12 -0400 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 Thread-Index: Ac0p/y5tVewlVxjtREGDXdzyefJ+owCZ3ZqQ Message-ID: References: <4FA3E281.2060500@alum.mit.edu> In-Reply-To: <4FA3E281.2060500@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 15:34:21 -0000 I also agree that this version is fine. I have just one typo on top of the ones mentioned below: In section 7.4. TLS Usage with Middleboxes This is the main use case for the CEMA extension; the endpoints expect one or more Middlebox. In the above, s/Middlebox/Middleboxes/=20 www.ericsson.com - This Communication is Confidential. We only send and re= ceive email on the basis of the term set out at www.ericsson.com/email_disc= laimer =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: May-04-12 10:07 AM To: simple@ietf.org Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 Ben, This generally looks good, but I found some editorial errors: Something has gone wrong in the editing of section 6.4. The following parag= raph now says the same thing twice: This document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media, and that they are able to modify the SDP address information associated with the MSRP media. This is evolved from a paragraph that had two sentences saying complementar= y things, and the point made in that 2nd sentence has been lost. In section 7.3: s/is use without/is used without/ In section 7.5: However, this relies on that the SDP signaling is integrity protected, which may not always be the case. This isn't proper English. I suggest: However, this relies on SDP signaling being integrity protected, which may not always be the case. Also in that section the following has English problems: Therefore, it addition to the authentication mechanisms defined in RFC 4975, it is RECOMMENDED that a CEMA-enabled MSRP endpoint also supports self-signed certificates together Certificate Management Service [RFC6072], to which it publishes its self-signed certificate and from which it fetches on demand the self-signed certificates of other endpoints. I suggest: s/it addition/in addition/ s/together/together with the/ In section 7.6: - MSRPS: Security Mechanisms that does not rely on trusted signaling such as name based authentication s/that does not/that do not/ Thanks, Paul On 5/3/12 5:52 PM, Ben Campbell wrote: > This is a working group last call for draft-ietf-simple-msrp-cema-05. > > We performed a previous WGLC on this draft last fall, and requested publi= cation of revision 03. Since then, the IESG review resulted in a significa= nt rewrite of the security considerations section, as well as a few other c= hanges. We want to confirm that the current text still reflects work group = consensus. > > Since this is a repeat last call, we will attempt a shortened review cycl= e. Please focus your review on the changes since revision 03, and send your= comments to the list and the draft authors by the end of Friday, 11 May 20= 12. > > The current version is available at the following URL: > > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-05 > > And here's a diff between 05 and 03: > > http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Ddraft-ietf-simpl= e > -msrp-cema-03.txt&url2=3Ddraft-ietf-simple-msrp-cema-05.txt > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Mon May 7 10:30:10 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1267021F865D for ; Mon, 7 May 2012 10:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.101, 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 UB37ZBcUKrgK for ; Mon, 7 May 2012 10:30:09 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1F50921F8650 for ; Mon, 7 May 2012 10:30:05 -0700 (PDT) X-AuditID: c1b4fb25-b7b09ae000007d0f-46-4fa8069cfb1f Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 12.3D.32015.C9608AF4; Mon, 7 May 2012 19:30:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 7 May 2012 19:30:04 +0200 From: Christer Holmberg To: Nancy Greene , "simple@ietf.org" Date: Mon, 7 May 2012 19:29:03 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 Thread-Index: Ac0p/y5tVewlVxjtREGDXdzyefJ+owCZ3ZqQAAQQHec= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C44001343@ESESSCMS0356.eemea.ericsson.se> References: <4FA3E281.2060500@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 17:30:10 -0000 Hi Nancy, > I also agree that this version is fine. > > I have just one typo on top of the ones mentioned below: > > In section 7.4. TLS Usage with Middleboxes > > This is the main use case for the CEMA extension; the endpoints > expect one or more Middlebox. > > In the above, s/Middlebox/Middleboxes/ I'll fix as suggested. Thank You! Regards, Christer -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: May-04-12 10:07 AM To: simple@ietf.org Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 Ben, This generally looks good, but I found some editorial errors: Something has gone wrong in the editing of section 6.4. The following parag= raph now says the same thing twice: This document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media, and that they are able to modify the SDP address information associated with the MSRP media. This is evolved from a paragraph that had two sentences saying complementar= y things, and the point made in that 2nd sentence has been lost. In section 7.3: s/is use without/is used without/ In section 7.5: However, this relies on that the SDP signaling is integrity protected, which may not always be the case. This isn't proper English. I suggest: However, this relies on SDP signaling being integrity protected, which may not always be the case. Also in that section the following has English problems: Therefore, it addition to the authentication mechanisms defined in RFC 4975, it is RECOMMENDED that a CEMA-enabled MSRP endpoint also supports self-signed certificates together Certificate Management Service [RFC6072], to which it publishes its self-signed certificate and from which it fetches on demand the self-signed certificates of other endpoints. I suggest: s/it addition/in addition/ s/together/together with the/ In section 7.6: - MSRPS: Security Mechanisms that does not rely on trusted signaling such as name based authentication s/that does not/that do not/ Thanks, Paul On 5/3/12 5:52 PM, Ben Campbell wrote: > This is a working group last call for draft-ietf-simple-msrp-cema-05. > > We performed a previous WGLC on this draft last fall, and requested publi= cation of revision 03. Since then, the IESG review resulted in a significa= nt rewrite of the security considerations section, as well as a few other c= hanges. We want to confirm that the current text still reflects work group = consensus. > > Since this is a repeat last call, we will attempt a shortened review cycl= e. Please focus your review on the changes since revision 03, and send your= comments to the list and the draft authors by the end of Friday, 11 May 20= 12. > > The current version is available at the following URL: > > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-05 > > And here's a diff between 05 and 03: > > http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Ddraft-ietf-simpl= e > -msrp-cema-03.txt&url2=3Ddraft-ietf-simple-msrp-cema-05.txt > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From saul@ag-projects.com Wed May 9 01:47:20 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCE721F8478 for ; Wed, 9 May 2012 01:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 DRU8vI6pTsGp for ; Wed, 9 May 2012 01:47:19 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 91FD521F846F for ; Wed, 9 May 2012 01:47:19 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 70157B01B2; Wed, 9 May 2012 10:47:16 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 9A35FB01A3; Wed, 9 May 2012 10:47:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 9 May 2012 10:09:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: "simple-chairs@tools.ietf.org Chairs" , draft-ietf-simple-msrp-cema.all@tools.ietf.org, Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 08:47:20 -0000 I'm ok with the final version (I did discover some editorial glitches = but they were all reported previously by Paul), no further comments. Regards, On May 3, 2012, at 11:52 PM, Ben Campbell wrote: > This is a working group last call for draft-ietf-simple-msrp-cema-05. >=20 > We performed a previous WGLC on this draft last fall, and requested = publication of revision 03. Since then, the IESG review resulted in a = significant rewrite of the security considerations section, as well as a = few other changes. We want to confirm that the current text still = reflects work group consensus. >=20 > Since this is a repeat last call, we will attempt a shortened review = cycle. Please focus your review on the changes since revision 03, and = send your comments to the list and the draft authors by the end of = Friday, 11 May 2012.=20 >=20 > The current version is available at the following URL: >=20 > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-05 >=20 > And here's a diff between 05 and 03: >=20 > = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Ddraft-ietf-simple= -msrp-cema-03.txt&url2=3Ddraft-ietf-simple-msrp-cema-05.txt >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple -- Sa=FAl Ibarra Corretg=E9 AG Projects From ben@nostrum.com Thu May 10 14:12:50 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF25F11E8085 for ; Thu, 10 May 2012 14:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 djaeGaNxQDJy for ; Thu, 10 May 2012 14:12:49 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 55DE621F85A5 for ; Thu, 10 May 2012 14:12:49 -0700 (PDT) Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4ALCmIQ006407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 May 2012 16:12:48 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 10 May 2012 16:12:48 -0500 Message-Id: <04C7EE0B-DAB1-45E3-A6C7-06DE5777534A@nostrum.com> To: Simple WG , draft-ietf-simple-msrp-cema.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Subject: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 21:12:50 -0000 (as individual) Hi, Here's my WGLC comments on draft-iet-msrp-cema-05. I will focus first on = the new security language, but I still have a few comments on the rest = of the document. I also have some general editorial comments for the = whole document. Substantive Security Considerations Comments: -- 7.1, and general: I'm still uncomfortable with the language that says (or implies) that = CEMA enables e2e security in general. In fact, it enables it in a some = very specific use cases, namely when you have middleboxes that behave = exactly as described in this document--in particular, when they = transparently forward TLS, _and_ where direct e2e TLS connections are = prevented by some aspect of the provider's architecture (e.g. the = middlebox use is required by policy, e2e connections are prevented by = NATs, etc.) But even then, the fact that the endpoints have no way of telling = whether the middlebox actually tunnels TLS vs acting as a TLS b2bua = makes me very skeptical of any claim of enabling e2e protection. I think that, if the endpoints can't _prove_ the protection is e2e, then it has = to assume that it is _not_ e2e. -- 7.1, last sentence "If the key management depends on trust in the = signaling plane, the Middlebox is by definition trusted, but the = security is still increased as the cleartext is not available in the = Middlebox." The first half of that sentence needs elaboration, particular in light = of the other assertions that fingerprint based authentication implies = trust in the signaling plane. Are you talking about trust that the = signaling plane authentication of endpoints is in fact true, or trust in = whether the offer/answer has not been tampered with? It seems to me that = something like RFC4474 can use fingerprint authentication of the media = session with at least minimal trust in middleboxes. I think it would help to open the security considerations section with a = subsection that explains the trust assumptions for CEMA in more detail -- 7.2: "For backward compatibility, a CEMA-enabled MSRP endpoint MUST = implement TLS." Why is this for "backwards compatibility"? Seems like you want it = whether or not you care about backwards compatibility. -- 7.4, 2nd paragraph: "This can e.g. be hop-by-hop cryptographic = protection or cryptographic access protection combined with physical = trust in other parts of the signaling plane." I'm not sure what you intend by this sentence. Should I infer that a = hard shell soft center model of protection is good enough? What are the = trust implications for hop by hop? What do you mean by access = protection? It seems like the real point is you _can't_ use end to end integrity = protection for signaling across middleboxes, with or without CEMA. -- 7.4, 3rd and 4th paragraphs: How can a user determine which case (e2e TLS vs TLS b2bua) is in effect, = and decide whether to allow it? -- 7.4, last paragraph: "But this is not an issue as the signaling = network is considered trusted by the endpoint (a requirement to use = fingerprint based authentication)." I don't think I accept that statement in general. (see previous comment = for 7.1 about trust in middleboxes) I think the way this is being presented involves some dog-wagging. It's = not so much that the end user wants to trust the middleboxes as much as = it is an operator that won't let calls complete if they don't anchor on = a middlebox. This is a fairly coercive definition of trust. -- 7.5, 2nd to last paragraph: "Alternate key distribution = mechanisms...may become ubiquitous enough to solve the key distribution = problem in the future." Do we believe RFC 6072 is that ubiquitous _now_? This seems like a dodge = to avoid a normative downref. If so, lets not hide it behind "ubiquity". = Perhaps the text should read "may become sufficiently standardized..." -- 7.5, last paragraph: "Some of these options require trusting the = service provider, but those issues are beyond the scope of this = document." Isn't this entire document predicated on the idea of endpoints trusting = the provider? -- 7.7, 3rd paragraph: "Signaling over a local or closed network MAY be = trusted." That's a broad statement to make without a considerably longer and more = nuanced discussion. As it stands, it seems to encourage a = hard-shell-gooey-center approach to security. -- 7.7, 4th paragraph: "It should however be noted that using = fingerprint based authentication over an insecure network increases the = security compared to unencrypted MSRP as this makes it harder to perform = an man-in-the-middle attack." You don't even need a MiTM attack if MSRP is used without protection *** Other substantive comments: -- 4.2, 4.3, and 4.4: I'm still afraid that sections 4.2, 4.3 are not = going to result in interoperable implementations. The various efforts to = decide you can still use CEMA even when the peer does not advertise it = remind me of the rules of Fizzbin ( = http://en.wikipedia.org/wiki/Fizbin#Fizzbin ). Adding in the need to = resolve names to IP addresses for comparison purposes in 4.4, I have to = ask if we really think the benefit is worth the complexity? Can it be = streamlined somehow? -- 4.2: Step 2: Doesn't the offerer insert a setup attribute whether or not it uses a = relay?. The value changes, but it uses the setup attribute either way. -- 4.2, step 3 on receipt of answer: If I read steps 1 and 3 right, the first covers the case of c/m not = matching path where the offerer is passive, and the 2nd covers the case = of c/m not matching path and the offerer is active. That's basically = all cases where c/m don't match path, isn't it? *** Editorial Comments: --1, 2nd paragraph" "middleboxes must read the message" Just read? Or parse, or modify? -- "address:port" (recurs throughout document) address and port.=20 -- "c/m- line" (recurs throughout document) c and m-lines, or c-line and m-line. (i.e. don't use "/" as a = conjunction) -- 1, 3rd paragraph: "...that normally result in negative performance = impact" _which_ normally _results_... -- 2, "Fingerprint Based TLS Authentication: An MSRP endpoint..." I don't think Fingerprint based TLS authn _is_ an endpoint--it's an = action. (repeats for name-based..) --2, "Name-Based..." Definition is hard to parse. I think the point is two-fold. The endpoint = uses a trusted CA to establish the validity of the peer certificate, = then compares the SAN of the peer certificate has a match for the peer's = MSRP URI. --2, "MSRP B2BUA" "... terminates an MSRP connection from one MSRP = endpoint and reoriginates that connection..." s/connection/session -- "...SIP B2BUA terminates a SIP session... s/session/dialog (or transaction). -- 4.2, step one on receipt of an answer: I have trouble parsing this -- 4.2, step 3 on receipt of an answer -- 4.4, paragraph 6 (Note) : "... MSRP URI must always contain a port." ... when used in an SDP path attribute. -- 6.2, 1st paragraph: "... where the offerer does not support the CEMA = extension." Doesn't that preempt some of the endpoint workarounds for when the peer = does not advertise CEMA? -- 7.7, 2nd paragraph" "...may be hard for the endpoint to decide." Decide what? From christer.holmberg@ericsson.com Tue May 15 02:12:36 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55621F85B6 for ; Tue, 15 May 2012 02:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.091, 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 pcLEJDBKgGK0 for ; Tue, 15 May 2012 02:12:35 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 92B3A21F85C7 for ; Tue, 15 May 2012 02:12:34 -0700 (PDT) X-AuditID: c1b4fb25-b7c5aae000007a47-71-4fb21e00f207 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3A.99.31303.00E12BF4; Tue, 15 May 2012 11:12:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 15 May 2012 11:12:33 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG , "draft-ietf-simple-msrp-cema.all@tools.ietf.org" Date: Tue, 15 May 2012 11:12:31 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) Thread-Index: Ac0yereOoQw8oyBSQVO58NkMDJMmNg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 09:12:36 -0000 Hi, Reply to Ben's comments on section 7 (Security Considerations). > -- 7.1, and general: >=20 > I'm still uncomfortable with the language that says (or > implies) that CEMA enables e2e security in general. In fact, it=20 > enables it in a some very specific use cases, namely when you have=20 > middleboxes that behave exactly as described in this document--in=20 > particular, when they transparently forward TLS, _and_ where direct=20 > e2e TLS connections are prevented by some aspect of the provider's=20 > architecture (e.g. the middlebox use is required by policy, e2e=20 > connections are prevented by NATs, etc.) In my opinion, the text in section 7.1 is quite clear on this:=20 "In deployments where Middleboxes are always used, which is the main use case for the CEMA extension, the CEMA extension increases the security by enabling the use of end-to-end TLS between the two endpoints." ------------- =20 > But even then, the fact that the endpoints have no way of telling=20 > whether the middlebox actually tunnels TLS vs acting as a TLS b2bua=20 > makes me very skeptical of any claim of enabling e2e protection. I=20 > think that, if the endpoints can't _prove_ the protection is e2e,=20 > then it has to assume that it is _not_ e2e. True end-to-end security requires a key management protocol that does not d= epend on secure signalling, e.g. name based certificates.=20 Whether such a protocol (together with the necessary infrastructure) is ava= ilable or not is a deployment issue, and is independent of CEMA. The statement that CEMA enables end-to-end security is true under following= conditions: (1) The deployment is such that it requires the use of Middleboxes; and (2) A key management protocol is available that does not depend on=20 secure signalling. In my opinion the text is quite clear on the above. ------------- =20 > -- 7.1, last sentence "If the key management depends on trust in the=20 > signaling plane, the Middlebox is by definition trusted, but the=20 > security is still increased as the cleartext is not available in the=20 > Middlebox." >=20 > The first half of that sentence needs elaboration, particular in light=20 > of the other assertions that fingerprint based authentication implies=20 > trust in the signaling plane. Are you talking about trust that the=20 > signaling plane authentication of endpoints is in fact true, or trust=20 > in whether the offer/answer has not been tampered with? It seems to me=20 > that something like RFC4474 can use fingerprint authentication of the=20 > media session with at least minimal trust in middleboxes. >=20 > I think it would help to open the security considerations section with=20 > a subsection that explains the trust assumptions for CEMA in more=20 > detail It's actually both. If self-signed certificates is to be considered secure = then both endpoints and the intermediate nodes must be authenticated and th= e fingerprint attribute cannot be tampered with by the intermediaries. I do agree that, if RFC 4474 is used, then it is not necessary to trust all= the intermediate nodes. However, RFC 4474 would not work well together wit= h media anchoring since the entire SIP body is signed, which means that the= c/m lines can't be modified.=20 AFAIK, it is not possible to sign certain parts of the SIP body (e.g. only = the fingerprint attribute). ------------- > -- 7.2: "For backward compatibility, a CEMA-enabled MSRP endpoint MUST=20 > implement TLS." >=20 > Why is this for "backwards compatibility"? Seems like you want it=20 > whether or not you care about backwards compatibility. Section 14.2 in RFC 4975 (MSRP) states that "MSRP elements MUST implement T= LS". Having said that, I agree with you that the text could be modified. I suggest: "According to RFC 4975, MSRP endpoints are required to support TLS. This a= lso apply to CEMA-enabled endpoints."=20 ------------- > -- 7.4, 2nd paragraph: "This can e.g. be hop-by-hop cryptographic=20 > protection or cryptographic access protection combined with physical=20 > trust in other parts of the signaling plane." >=20 > I'm not sure what you intend by this sentence. Should I infer that a=20 > hard shell soft center model of protection is good enough? What are=20 > the trust implications for hop by hop? What do you mean by access=20 > protection? >=20 > It seems like the real point is you _can't_ use end to end integrity=20 > protection for signaling across middleboxes, with or without CEMA. If you want to use fingerprint based authentication then you have to someho= w ensure yourself that the fingerprint attributes won't be manipulated by i= ntermediate nodes.=20 That can be accomplished in many different ways, but it is completely indep= endent of the use of CEMA. I therefore think the current level of detail is= sufficient. Access protection means that the signalling from the user to the first SIP = Proxy is protected by TLS (i.e. SIPS), IPsec, or by some other means (e.g.,= encryption and integrity protection of the air interface in 3G/4G).=20 The trust implications of using hop-by-hop security and fingerprint based a= uthentication are as explained in RFC 5763 (see especially Section 8.2). ------------- > -- 7.4, 3rd and 4th paragraphs: >=20 > How can a user determine which case (e2e TLS vs TLS b2bua) is in=20 > effect, and decide whether to allow it? If fingerprint based authentication is used, then it is not possible for th= e user to determine whether the TLS connection is end-to-end or terminated = by a B2BUA. If this is required by the user then he has to use some other key managemen= t protocol. Whether this is possible or not is an implementation/deployment issue. ------------- > -- 7.4, last paragraph: "But this is not an issue as the signaling=20 > network is considered trusted by the endpoint (a requirement to use=20 > fingerprint based authentication)." >=20 > I don't think I accept that statement in general. (see previous=20 > comment for 7.1 about trust in middleboxes) See my reply on your comment on section 7.1.=20 The statement is true for fingerprint based authentication without RFC 4474= . If RFC 4474 is used then you only need to trust parts of the signaling ne= twork, but you won't be able to do media anchoring (the main purpose of CEM= A).=20 ------------- > I think the way this is being presented involves some=20 > dog-wagging. It's not so much that the end user wants to=20 > trust the middleboxes as much as it is an operator that won't=20 > let calls complete if they don't anchor on a middlebox. This=20 > is a fairly coercive definition of trust. I don't think you ever *want* to trust anyone.=20 The user has to make a decision whether he thinks the benefits=20 of using the service outweighs the associated risk. If the=20 answer is yes, then he trusts the service provider. In some cases it is not possible to setup a call without inserting a=20 Middlebox (e.g. IPv4 user to IPv6 user). One could try to determine when=20 an end-to-end TCP connection can be established but that is often complex. ------------- > -- 7.5, 2nd to last paragraph: "Alternate key distribution=20 > mechanisms...may become ubiquitous enough to solve the key=20 > distribution problem in the future." >=20 > Do we believe RFC 6072 is that ubiquitous _now_? This seems=20 > like a dodge to avoid a normative downref. If so, lets not=20 > hide it behind "ubiquity". Perhaps the text should read "may=20 > become sufficiently standardized..." The lack of standards is not always the problem. It's also about deployment= . So, we could say: "sufficiently standardized and deployed" ------------- =20 > -- 7.5, last paragraph: "Some of these options require=20 > trusting the service provider, but those issues are beyond=20 > the scope of this document." >=20 > Isn't this entire document predicated on the idea of=20 > endpoints trusting the provider? Whether the service provider needs to be trusted or not depends on the=20 chosen key management, and this is entirely independent of CEMA. ------------- =20 > -- 7.7, 3rd paragraph: "Signaling over a local or closed=20 > network MAY be trusted." >=20 > That's a broad statement to make without a considerably=20 > longer and more nuanced discussion. As it stands, it seems to=20 > encourage a hard-shell-gooey-center approach to security. Yes, you're right that this is an imprecise statement.=20 But I don't understand why we should describe it further in=20 this document. Again, the selection of key management protocol=20 and the restrictions it imposes is independent of CEMA. ------------- > -- 7.7, 4th paragraph: "It should however be noted that using=20 > fingerprint based authentication over an insecure network=20 > increases the security compared to unencrypted MSRP as this=20 > makes it harder to perform an man-in-the-middle attack." >=20 > You don't even need a MiTM attack if MSRP is used without protection I disagree.=20 Even if unencrypted MSRP is used, the attacker still=20 need to intercept the traffic somehow. This means that you have some level = of security (the=20 level depends on the network you're on). ------------- Regards, Christer From christer.holmberg@ericsson.com Tue May 15 02:17:42 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A7021F84F0 for ; Tue, 15 May 2012 02:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.089, 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 RPeRoJt1HE+n for ; Tue, 15 May 2012 02:17:41 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DEF4921F84BF for ; Tue, 15 May 2012 02:17:40 -0700 (PDT) X-AuditID: c1b4fb2d-b7bc5ae00000796a-65-4fb21f336601 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D8.9A.31082.33F12BF4; Tue, 15 May 2012 11:17:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 15 May 2012 11:17:38 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG , "draft-ietf-simple-msrp-cema.all@tools.ietf.org" Date: Tue, 15 May 2012 11:17:38 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) Thread-Index: Ac0yewZjFrY+cAhiSLmKf25Y4VZYcw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 09:17:42 -0000 Hi, > -- 4.2, 4.3, and 4.4: I'm still afraid that sections 4.2, 4.3 are not goi= ng to result in interoperable implementations. The various efforts to decid= e you can still use CEMA even when the peer does not advertise it remind me= of the rules of Fizzbin (=20 > http://en.wikipedia.org/wiki/Fizbin#Fizzbin ). Adding in the need to reso= lve names to IP addresses for comparison purposes in 4.4, I have to ask if = we really think the benefit is worth the complexity? Can it be streamlined = somehow? In the past, we spent lots of time in order to clarify these sections, base= d on input from e.g. Eric Burger and yourself. And, there aren't any major= changes compared to version -03. I really don't know how it can be further streamlined, and suggest to keep = it as it is. ----------------------- --1, 2nd paragraph" "middleboxes must read the message" Just read? Or parse, or modify? > -- "address:port" (recurs throughout document) > > address and port.=20 Ok. ----------------------- > -- "c/m- line" (recurs throughout document) > > c and m-lines, or c-line and m-line. (i.e. don't use "/" as a conjunction= ) Ok. ----------------------- > -- 1, 3rd paragraph: "...that normally result in negative performance imp= act" > > _which_ normally _results_... Ok. ----------------------- > -- 2, "Fingerprint Based TLS Authentication: An MSRP endpoint..." > > I don't think Fingerprint based TLS authn _is_ an endpoint--it's an actio= n. (repeats for name-based..) Ok. ----------------------- --2, "Name-Based..." Definition is hard to parse. I think the point is two-fold. The endpoint us= es a trusted CA to establish the validity of the peer certificate, then com= pares the SAN of the peer certificate has a match for the peer's MSRP URI. I am not sure I understand. Do you have a suggestion for modified text? ----------------------- > --2, "MSRP B2BUA" "... terminates an MSRP connection from one MSRP endpoi= nt and reoriginates that connection..." > > s/connection/session Ok. ----------------------- > -- "...SIP B2BUA terminates a SIP session... > > s/session/dialog (or transaction). Ok. ----------------------- > -- 4.2, step one on receipt of an answer: > > I have trouble parsing this I think the text is clear. It says that the c/m does not match path, and th= at the endpoint will become passive. But, if you think the text can be improved, feel free to suggest text. ----------------------- > -- 4.2, step 3 on receipt of an answer > > -- 4.4, paragraph 6 (Note) : "... MSRP URI must always contain a port." > > ... when used in an SDP path attribute. Ok. ----------------------- > -- 6.2, 1st paragraph: "... where the offerer does not support the CEMA e= xtension." > > Doesn't that preempt some of the endpoint workarounds for when the peer d= oes not advertise CEMA? Yes, and the Middlebox doesn't need to enable MSRP B2BUA functionality in c= ases where the workarounds can be used. ----------------------- > -- 7.7, 2nd paragraph" "...may be hard for the endpoint to decide." > > Decide what? I suggest to remove that sentence, and re-write the subsequent sentence in = the following way: "In the end it is up to the endpoint to decide whether the signaling path= is trusted or not, and unless unless cryptographic end-to-end SDP integrity protection or encryption is = used it may be hard for the endpoint to make that decision." ----------------------- Regards, Christer From ben@nostrum.com Tue May 15 07:11:17 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4387C21F8714 for ; Tue, 15 May 2012 07:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 dElKnmt0YpTE for ; Tue, 15 May 2012 07:11:16 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B93521F871A for ; Tue, 15 May 2012 07:11:16 -0700 (PDT) Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4FEBCjh052086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 May 2012 09:11:13 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 15 May 2012 09:11:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:11:17 -0000 (Quick response on the "4.2, 4.2, and 4.4" comments--I will follow up = on the rest shortly.) On May 15, 2012, at 4:17 AM, Christer Holmberg wrote: > Hi, >=20 >=20 >> -- 4.2, 4.3, and 4.4: I'm still afraid that sections 4.2, 4.3 are not = going to result in interoperable implementations. The various efforts to = decide you can still use CEMA even when the peer does not advertise it = remind me of the rules of Fizzbin (=20 >> http://en.wikipedia.org/wiki/Fizbin#Fizzbin ). Adding in the need to = resolve names to IP addresses for comparison purposes in 4.4, I have to = ask if we really think the benefit is worth the complexity? Can it be = streamlined somehow? >=20 > In the past, we spent lots of time in order to clarify these sections, = based on input from e.g. Eric Burger and yourself. And, there aren't = any major changes compared to version -03. >=20 > I really don't know how it can be further streamlined, and suggest to = keep it as it is. >=20 I agree there have no substantial change since the work group pubreq'd = this before. Since I'm the only one who is complaining about it at this = point, I suspect the _chair_ will agree to let it go as is ;-) From pkyzivat@alum.mit.edu Tue May 15 07:54:09 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1178E21F88BF for ; Tue, 15 May 2012 07:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] 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 2+cP9vjSHTuL for ; Tue, 15 May 2012 07:54:08 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0D89921F88BB for ; Tue, 15 May 2012 07:54:07 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id AEmK1j00816LCl051Eu8tA; Tue, 15 May 2012 14:54:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta06.westchester.pa.mail.comcast.net with comcast id AEu81j00e07duvL3SEu84b; Tue, 15 May 2012 14:54:08 +0000 Message-ID: <4FB26E0E.4060101@alum.mit.edu> Date: Tue, 15 May 2012 10:54:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:54:09 -0000 On 5/15/12 5:12 AM, Christer Holmberg wrote: >> I think the way this is being presented involves some >> dog-wagging. It's not so much that the end user wants to >> trust the middleboxes as much as it is an operator that won't >> let calls complete if they don't anchor on a middlebox. This >> is a fairly coercive definition of trust. > > I don't think you ever *want* to trust anyone. > > The user has to make a decision whether he thinks the benefits > of using the service outweighs the associated risk. If the > answer is yes, then he trusts the service provider. > > In some cases it is not possible to setup a call without inserting a > Middlebox (e.g. IPv4 user to IPv6 user). One could try to determine when > an end-to-end TCP connection can be established but that is often complex. You say there is need to anchor the media, perhaps because of v4/v6 conversion, and then there is a need for a middle box to manipulate the SDP to accomplish that, and then 4474 can't be used because of the SDP manipulation. But this can be short circuited as long as the UA participates in the media anchoring. If TURN is used by the UA to establish the media anchor, then it can make the SDP correct, which then allows 4474 to be used. Thanks, Paul From ben@nostrum.com Tue May 15 13:57:42 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497B221F8655 for ; Tue, 15 May 2012 13:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 8rAGyrkMX3gO for ; Tue, 15 May 2012 13:57:40 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7FABD21F8653 for ; Tue, 15 May 2012 13:57:40 -0700 (PDT) Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4FKvanb015313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 May 2012 15:57:36 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 15 May 2012 15:57:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7B321302-CDFC-4966-9928-CCB202E33AAC@nostrum.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:57:42 -0000 On May 15, 2012, at 4:12 AM, Christer Holmberg wrote: > Hi, >=20 > Reply to Ben's comments on section 7 (Security Considerations). >=20 >> -- 7.1, and general: >>=20 >> I'm still uncomfortable with the language that says (or >> implies) that CEMA enables e2e security in general. In fact, it=20 >> enables it in a some very specific use cases, namely when you have=20 >> middleboxes that behave exactly as described in this document--in=20 >> particular, when they transparently forward TLS, _and_ where direct=20= >> e2e TLS connections are prevented by some aspect of the provider's=20 >> architecture (e.g. the middlebox use is required by policy, e2e=20 >> connections are prevented by NATs, etc.) >=20 > In my opinion, the text in section 7.1 is quite clear on this:=20 >=20 > "In deployments where Middleboxes are always used, which is the = main > use case for the CEMA extension, the CEMA extension increases = the > security by enabling the use of end-to-end TLS between the two > endpoints." Okay, I see that you constrained the benefit to the case where = "Middleboxes are always used". The problem I still have is, these = middleboxes may or may not choose to allow an e2e security association. = And as far as I can tell, without adding some other layer of e2e = security, the endpoints have no way of knowing if the SA is e2e or = hop-by-hop (and that's really only for the first hop, as the endpoint = can't know what a middlebox does for downstream hops.) Since the = middleboxes are not standardized devices, we can't even point to = normative language indicating that they SHOULD tunnel TLS. I 'd argue that if an endpoint can't be reasonably sure it has an e2e = SA, then it doesn't. And I suspect that, in practice, a lot of these = middleboxes are going to be there for reasons other than just firewall = and NAT traversal. If any of those reasons require access to cleartext = (and they almost certainly will), then the middlebox is never going to = just tunnel TLS.=20 Keep in mind this draft is about _endpoint_ behavior, and the security = considerations are from the endpoint's perspective. I think, from the = endpoint's perspective, the assertion that CEMA enables e2e TLS is = overstated, unless we are very explicit about what sort of assumptions = the endpoint might make. So I'd like to see this change to something to = the effect of the following: "CEMA enables middleboxes to allow end-to-end TLS security = considerations in some cases. MIddleboxes may or may not allow = end-to-send SAs, as a matter of local policy. Therefore a CEMA endpoint = MUST NOT assume that it has an end-to-end SA with it's peer unless it = can confirm this using some other mechanism", perhaps with a reference = to the section(s) discussing some potential methods for that.=20 I think I mentioned that it would be nice to see the security = considerations opening with a discussion of trust implications and what = assumptions an endpoint might make. This sort of thing might go there. >=20 >=20 > ------------- >=20 >=20 >> But even then, the fact that the endpoints have no way of telling=20 >> whether the middlebox actually tunnels TLS vs acting as a TLS b2bua=20= >> makes me very skeptical of any claim of enabling e2e protection. I=20 >> think that, if the endpoints can't _prove_ the protection is e2e,=20 >> then it has to assume that it is _not_ e2e. >=20 > True end-to-end security requires a key management protocol that does = not depend on secure signalling, e.g. name based certificates.=20 I do not understand that assertion. Why would a key management protocol = that requires trusted signaling not be end to end, assuming you have = trusted signaling? I understand that you pretty much can't have trusted = signaling over the sorts of middleboxes CEMA contemplates, but that's = not the same thing. >=20 > Whether such a protocol (together with the necessary infrastructure) = is available or not is a deployment issue, and is independent of CEMA. >=20 > The statement that CEMA enables end-to-end security is true under = following conditions: >=20 > (1) The deployment is such that it requires the use of Middleboxes; = and >=20 > (2) A key management protocol is available that does not depend on=20 > secure signalling. >=20 > In my opinion the text is quite clear on the above. I don't think it is unclear per se, I just don't think it provides = enough discussion for (potentially naive) implementers to fully = understand the implications of their choices. So, here's some suggested = text: "The purpose of CEMA is to enable communication over middleboxes. These = middleboxes are commonly deployed by SIP network operators, who also = commonly deploy firewall and routing policies that prevent media = sessions from working unless they traverse the middleboxes. Endpoints = that are not willing to trust such middleboxes SHOULD NOT enable CEMA.=20= CEMA makes it possible for middleboxes to tunnel TLS to allow end-to-end = security associations between endpoints. This is an improvement over the = status quo, since without CEMA, the middleboxes would be forced to both = read and modify the cleartext MSRP messages, which would make end-to-end = confidentiality and integrity protection impossible. However, = middleboxes may still choose to act as TLS B2BUAs, which would be = undetected by endpoints unless they use some additional mechanism to = authenticate that the TLS SA is in fact end-to-end. Endpoints enabling = CEMA MUST NOT assume end-to-end TLS protection of an MSRP without such a = mechanism.=20 Since the middleboxes described in this draft operate by modifying the = contents of SDP offers and answers, mechanisms that depend on end-to-end = integrity or confidentiality protection of the SIP message payloads will = fail. Therefore, endpoints using CEMA need to use a key management or = authentication mechanisms that does not require end-to-end trust in the = SIP signaling channel. Section [xxx] discusses some such mechanisms.=20 These are issues are not specific to CEMA, as the same issues occur = when using middleboxes without CEMA. Security mechanisms that provide = end-to-end protection of SIP message payloads, such as RFC 4744 = [informational reference], will detect the fact that an intermediary = modified the payloads. Such mechanisms cannot distinguish between an = authorized middlebox and a man-in-the-middle attacker. But since CEMA is = specifically intended for use with middleboxes, CEMA implementors should = carefully consider the trust implications. " =20 >=20 >=20 > ------------- >=20 >=20 >> -- 7.1, last sentence "If the key management depends on trust in the=20= >> signaling plane, the Middlebox is by definition trusted, but the=20 >> security is still increased as the cleartext is not available in the=20= >> Middlebox." >>=20 >> The first half of that sentence needs elaboration, particular in = light=20 >> of the other assertions that fingerprint based authentication implies=20= >> trust in the signaling plane. Are you talking about trust that the=20 >> signaling plane authentication of endpoints is in fact true, or trust=20= >> in whether the offer/answer has not been tampered with? It seems to = me=20 >> that something like RFC4474 can use fingerprint authentication of the=20= >> media session with at least minimal trust in middleboxes. >>=20 >> I think it would help to open the security considerations section = with=20 >> a subsection that explains the trust assumptions for CEMA in more=20 >> detail >=20 > It's actually both. If self-signed certificates is to be considered = secure then both endpoints and the intermediate nodes must be = authenticated and the fingerprint attribute cannot be tampered with by = the intermediaries. The sentence in question starts with "If key management depends on trust = in the signaling plane...". But aren't we saying that the key management = mechanism used with CEMA _cannot_ depend on trust in the signaling = plane? Or by "trust in the signaling plane" do we mean trusting that the = middleboxes will only use their powers for good? There's probably a place for a level of trust that means something like = "I trust that only the phone company and maybe the government can see my = cleartext messages", for which just using SIPS may be good enough. = That's not that different from the current status with SMS/MMS. But it's = _very_ different than an assumption of end-to-end message = confidentiality.=20 >=20 > I do agree that, if RFC 4474 is used, then it is not necessary to = trust all the intermediate nodes. However, RFC 4474 would not work well = together with media anchoring since the entire SIP body is signed, which = means that the c/m lines can't be modified.=20 Right. I guess the point is (and I hope my proposed text above covers = it), is that, in order to assume e2e TLS protection of the MSRP channel = in the presence of middleboxes, you have to use an = authentication/key-binding mechanism that doesn't break when the = middleboxes tamper with the SDP. >=20 > AFAIK, it is not possible to sign certain parts of the SIP body (e.g. = only the fingerprint attribute). AFAIK, you are correct. That is, we don't have a standardized mechanisms = for it. > ------------- >=20 >=20 >> -- 7.2: "For backward compatibility, a CEMA-enabled MSRP endpoint = MUST=20 >> implement TLS." >>=20 >> Why is this for "backwards compatibility"? Seems like you want it=20 >> whether or not you care about backwards compatibility. >=20 > Section 14.2 in RFC 4975 (MSRP) states that "MSRP elements MUST = implement TLS". >=20 > Having said that, I agree with you that the text could be modified. >=20 > I suggest: >=20 > "According to RFC 4975, MSRP endpoints are required to support = TLS. This also apply to CEMA-enabled endpoints."=20 >=20 WFM. >=20 > ------------- >=20 >=20 >> -- 7.4, 2nd paragraph: "This can e.g. be hop-by-hop cryptographic=20 >> protection or cryptographic access protection combined with physical=20= >> trust in other parts of the signaling plane." >>=20 >> I'm not sure what you intend by this sentence. Should I infer that a=20= >> hard shell soft center model of protection is good enough? What are=20= >> the trust implications for hop by hop? What do you mean by access=20 >> protection? >>=20 >> It seems like the real point is you _can't_ use end to end integrity=20= >> protection for signaling across middleboxes, with or without CEMA. >=20 > If you want to use fingerprint based authentication then you have to = somehow ensure yourself that the fingerprint attributes won't be = manipulated by intermediate nodes.=20 >=20 > That can be accomplished in many different ways, but it is completely = independent of the use of CEMA. I therefore think the current level of = detail is sufficient. >=20 > Access protection means that the signalling from the user to the first = SIP Proxy is protected by TLS (i.e. SIPS), IPsec, or by some other means = (e.g., encryption and integrity protection of the air interface in = 3G/4G).=20 >=20 > The trust implications of using hop-by-hop security and fingerprint = based authentication are as explained in RFC 5763 (see especially = Section 8.2). My objection was specifically to the idea of "physical trust". If that = means something like IPSec, then great. If it means I trust that that = the network is in a locked room, then any such assertion needs lots of = disclaimers that this is not the general case. >=20 >=20 > ------------- >=20 >=20 >> -- 7.4, 3rd and 4th paragraphs: >>=20 >> How can a user determine which case (e2e TLS vs TLS b2bua) is in=20 >> effect, and decide whether to allow it? >=20 > If fingerprint based authentication is used, then it is not possible = for the user to determine whether the TLS connection is end-to-end or = terminated by a B2BUA. >=20 > If this is required by the user then he has to use some other key = management protocol. >=20 > Whether this is possible or not is an implementation/deployment issue. I hope my comment here will become moot based on the larger discussion = of the first two items. >=20 >=20 > ------------- >=20 >=20 >> -- 7.4, last paragraph: "But this is not an issue as the signaling=20 >> network is considered trusted by the endpoint (a requirement to use=20= >> fingerprint based authentication)." >>=20 >> I don't think I accept that statement in general. (see previous=20 >> comment for 7.1 about trust in middleboxes) >=20 > See my reply on your comment on section 7.1.=20 >=20 > The statement is true for fingerprint based authentication without RFC = 4474. If RFC 4474 is used then you only need to trust parts of the = signaling network, but you won't be able to do media anchoring (the main = purpose of CEMA).=20 For a fingerprint based mechanism without integrity protection, I agree = with you. But the sentence states it as if were true in general. In any = case, it seems like this section says something like "You can't do = fingerprint based key management unless you trust the network, since you = can't integrity protect the SDP across middleboxes. But that's not a = problem, because you if you wanted to do fingerprints, you must already = trust the network." If that's what you mean, then it's a circular = argument. I _think_ the point is really along the lines of "Even though you can't = integrity-protect your fingerprints across middleboxes, the fingerprint = across may be better than nothing. If you are willing to trust the = (possibly both) service providers, you can reasonably be sure no = malicious third parties can mess with your fingerprints by using SIPS." But that's still very different from e2e media protection. (Your previous mention of RFC5763 might be relevant here, as I think = we're trying to say the same thing it did). >=20 >=20 > ------------- >=20 >=20 >> I think the way this is being presented involves some=20 >> dog-wagging. It's not so much that the end user wants to=20 >> trust the middleboxes as much as it is an operator that won't=20 >> let calls complete if they don't anchor on a middlebox. This=20 >> is a fairly coercive definition of trust. >=20 > I don't think you ever *want* to trust anyone.=20 >=20 > The user has to make a decision whether he thinks the benefits=20 > of using the service outweighs the associated risk. If the=20 > answer is yes, then he trusts the service provider. I doubt the average user is aware he needs to make such a decision, much = less competent to make it. And in many cases, the user may have no = choice in the matter, other than to carefully watch what they say over = the media channel. (But I hope this concern is covered in my proposed = text early in this email.) The bigger issue is that the user may not have enough information to = make informed trust decisions. The user does not know if middleboxes are = going to be used or not, or what policies the middleboxes might have. If = he cares, he needs to take the aforementioned steps to ensure (or at = least detect the lack of) e2e media protection. That all being said, I would be okay with this section if it clarified = what it means to trust the network. I think in this case, it means the = user understands that the service provider has access to and can modify = the cleartext of his messages, and trusts the provider not to do = anything inappropriate. This may be sufficient for normal, day-to-day = communication, but might not be sufficient for banking, medical = information, trade secrets, etc. >=20 > In some cases it is not possible to setup a call without inserting a=20= > Middlebox (e.g. IPv4 user to IPv6 user). One could try to determine = when=20 > an end-to-end TCP connection can be established but that is often = complex. >=20 There are a number of approaches to that other than using middleboxes. = If a session can't be set up without a middlebox, it's because the = service provider chose to make it so. The real problem with middleboxes = is that they are, or at least try to be, invisible to endpoints.=20 >=20 > ------------- >=20 >=20 >> -- 7.5, 2nd to last paragraph: "Alternate key distribution=20 >> mechanisms...may become ubiquitous enough to solve the key=20 >> distribution problem in the future." >>=20 >> Do we believe RFC 6072 is that ubiquitous _now_? This seems=20 >> like a dodge to avoid a normative downref. If so, lets not=20 >> hide it behind "ubiquity". Perhaps the text should read "may=20 >> become sufficiently standardized..." >=20 > The lack of standards is not always the problem. It's also about = deployment. >=20 > So, we could say: "sufficiently standardized and deployed" I'm not sure you get my point. Do you believe RFC 6072 is sufficiently = deployed? More deployed than the other choices? >=20 >=20 > ------------- >=20 >=20 >> -- 7.5, last paragraph: "Some of these options require=20 >> trusting the service provider, but those issues are beyond=20 >> the scope of this document." >>=20 >> Isn't this entire document predicated on the idea of=20 >> endpoints trusting the provider? >=20 > Whether the service provider needs to be trusted or not depends on the=20= > chosen key management, and this is entirely independent of CEMA. Not really, since you use CEMA because you expect middleboxes, and the = presence of middleboxes constrains our key-management mechanisms to = things that don't use e2e integrity protection of the SDP. A lot of this = discussion so far has been about that very point. >=20 >=20 > ------------- >=20 >=20 >> -- 7.7, 3rd paragraph: "Signaling over a local or closed=20 >> network MAY be trusted." >>=20 >> That's a broad statement to make without a considerably=20 >> longer and more nuanced discussion. As it stands, it seems to=20 >> encourage a hard-shell-gooey-center approach to security. >=20 > Yes, you're right that this is an imprecise statement.=20 >=20 > But I don't understand why we should describe it further in=20 > this document. Again, the selection of key management protocol=20 > and the restrictions it imposes is independent of CEMA. A normative "MAY" implies some degree of approval. Assuming a network is = secure because it's somehow locked away from the rest of the world is = dangerous. Disgruntled employees with "secure" network access are the = source of a great many security failures. We may recognize that many = carriers and SDOs choose to depend on physical security alone. That = doesn't mean we should suggest it. >=20 >=20 > ------------- >=20 >=20 >> -- 7.7, 4th paragraph: "It should however be noted that using=20 >> fingerprint based authentication over an insecure network=20 >> increases the security compared to unencrypted MSRP as this=20 >> makes it harder to perform an man-in-the-middle attack." >>=20 >> You don't even need a MiTM attack if MSRP is used without protection >=20 > I disagree.=20 >=20 > Even if unencrypted MSRP is used, the attacker still=20 > need to intercept the traffic somehow. This means that you have some = level of security (the=20 > level depends on the network you're on). That's not necessarily MiTM. With unprotected MSRP, you are vulnerable = to passive attacks as well. >=20 > ------------- >=20 > Regards, >=20 > Christer From ben@nostrum.com Tue May 15 14:45:13 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008F811E8093 for ; Tue, 15 May 2012 14:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 DlQZFBUcG0Um for ; Tue, 15 May 2012 14:45:12 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1028911E8074 for ; Tue, 15 May 2012 14:45:08 -0700 (PDT) Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4FLj0QM022339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 May 2012 16:45:01 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 15 May 2012 16:45:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2CDCC2EF-B5AF-4101-857C-0B9E42F381A8@nostrum.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 21:45:13 -0000 Hi, I replied to the first section (4.2, 4.3, 4.4) separately. This is = in response to the rest. I removed sections where I think no further = comment is needed. On May 15, 2012, at 4:17 AM, Christer Holmberg wrote: [...] >=20 >=20 > --1, 2nd paragraph" "middleboxes must read the message" >=20 > Just read? Or parse, or modify? I don't see a reply to this one [...] > ----------------------- >=20 > --2, "Name-Based..." >=20 > Definition is hard to parse. I think the point is two-fold. The = endpoint uses a trusted CA to establish the validity of the peer = certificate, then compares the SAN of the peer certificate has a match = for the peer's MSRP URI. >=20 > I am not sure I understand. Do you have a suggestion for modified = text? >=20 How about the following: "Name Based Authentication: An authentication method in which an = endpoint receives an X.509 certificate from its peer as part of the TLS = authentication. The endpoint validates that a chain of issuers exists = from the certificate to a trusted certification authority, and that the = certificate contains the domain name of the peer." We could specify the SubjectAltName part, but I don't think that really = adds to the definition. [By the way, this brings up a question. Have we been assuming that = name-based authentication survives an untrusted middlebox? It seems like = if the middlebox acts as an MSRP B2BUA, it can just substitute an MSRP = URI with its own domain name during the offer/answer.] =20 [...] >=20 > ----------------------- >=20 >=20 >> -- 4.2, step one on receipt of an answer: >>=20 >> I have trouble parsing this >=20 > I think the text is clear. It says that the c/m does not match path, = and that the endpoint will become passive. >=20 > But, if you think the text can be improved, feel free to suggest text. >=20 >=20 Quoting the text here for convenience: > =20 > 1. The SDP c/m-line address information associated with the MSRP > media description does not match Section 4.4 the information in the > MSRP URI of the =92path=92 attribute(s) (in which case is assumed = that > the SDP c/m-line contains the address to a Middlebox), and the MSRP > endpoint will become "passive" (if the MSRP media description of = the > SDP answer contains an SDP =92setup:active=92 attribute). what do you mean by "... does not match Section 4.4..." Suggested text: "The SDP c-line and m-line do not match the address and port from the = MSRP URI in the "path" attribute, and the offerer is forced to become = "passive" by an a "setup:active" attribute in the SDP answer. This = indicates that the m-line and c-line in the answer probably refer to a = middlebox." [...] >=20 >=20 >> -- 6.2, 1st paragraph: "... where the offerer does not support the = CEMA extension." >>=20 >> Doesn't that preempt some of the endpoint workarounds for when the = peer does not advertise CEMA? >=20 > Yes, and the Middlebox doesn't need to enable MSRP B2BUA functionality = in cases where the workarounds can be used. >=20 >=20 So the middlebox is also assumed to check for the cases in 4.2 and 4.3? [...] >=20 >> -- 7.7, 2nd paragraph" "...may be hard for the endpoint to decide." >>=20 >> Decide what? >=20 > I suggest to remove that sentence, and re-write the subsequent = sentence in the following way: >=20 > "In the end it is up to the endpoint to decide whether the = signaling path is trusted or not, and unless > unless cryptographic end-to-end SDP integrity protection or = encryption is used it may be hard for the > endpoint to make that decision." >=20 I guess my confusion is that I don't think the fact that the SDP is = integrity protected or not changes whether the user trusts the signaling = channel. If the SDP is integrity protected end to end, he doesn't _have_ = to trust the signaling channel. If it's not, then he must decide if he = trusts the network.=20 I assume the text resulted from Robert's objection to the previous = revision's assertion that an endpoint might decide it was okay to = continue to communicate if authentication failed. I'm not sure just = stepping back and saying "deciding is hard" is the right approach here. = That may need further discussion with Robert and/or the security ADs. OTOH, should a CEMA endpoint even try to use an end-to-end SDP integrity = protection mechanism?= From eburger@standardstrack.com Sun May 20 17:58:00 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D902821F85DD for ; Sun, 20 May 2012 17:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] 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 3lJaZtcXKNXM for ; Sun, 20 May 2012 17:58:00 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 4332021F84E6 for ; Sun, 20 May 2012 17:58:00 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:57177 helo=[192.168.15.135]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SWGwZ-0005v2-Tr; Sun, 20 May 2012 17:57:52 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-29-624905966; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: Date: Sun, 20 May 2012 20:57:54 -0400 Message-Id: <94AA2AF8-0D3B-418A-AA43-74215B0E1A64@standardstrack.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> To: Ben Campbell X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 00:58:01 -0000 --Apple-Mail-29-624905966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm not complaining... On May 15, 2012, at 10:11 AM, Ben Campbell wrote: > (Quick response on the "4.2, 4.2, and 4.4" comments--I will follow up = on the rest shortly.) >=20 > On May 15, 2012, at 4:17 AM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >>=20 >>> -- 4.2, 4.3, and 4.4: I'm still afraid that sections 4.2, 4.3 are = not going to result in interoperable implementations. The various = efforts to decide you can still use CEMA even when the peer does not = advertise it remind me of the rules of Fizzbin (=20 >>> http://en.wikipedia.org/wiki/Fizbin#Fizzbin ). Adding in the need to = resolve names to IP addresses for comparison purposes in 4.4, I have to = ask if we really think the benefit is worth the complexity? Can it be = streamlined somehow? >>=20 >> In the past, we spent lots of time in order to clarify these = sections, based on input from e.g. Eric Burger and yourself. And, there = aren't any major changes compared to version -03. >>=20 >> I really don't know how it can be further streamlined, and suggest to = keep it as it is. >>=20 >=20 > I agree there have no substantial change since the work group pubreq'd = this before. Since I'm the only one who is complaining about it at this = point, I suspect the _chair_ will agree to let it go as is ;-) >=20 >=20 --Apple-Mail-29-624905966 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNTIxMDA1NzU1WjAjBgkqhkiG9w0BCQQxFgQU f45SbSeFEJHXi7F413kefpRUH2QwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAH2dsBKKhh2poFyF5ZVz5YOKAk9qlnphanl4Qm9Omt8QcKM5zYU2M sS/DVTStJnwCU7lDZAKW7Wq9D6tPMb0RU/dNcgQq7R/HlS7sJqs68+pMfrjgkKq14n11efxcRg8R Q9Hh1RWydFraghQwR59WF9gRo/0sgyKpKU5x51C55Y4KNR+Kp5xXkldjZmcumrUxjddQJRxjXfoi 6XABtRgRVu7lLX57rYomJhIJ+w9hDtvf3Xnrl1Nr8XCMrEwoWbcNpK8KN/yfhHYFwQkiJJiwrcw8 LX8XTjrC4FHMFKER9NhBinEh7IyHqhpwGgj+yf1S1kTbMlTP/gdsAzo6QAVRewAAAAAAAA== --Apple-Mail-29-624905966-- From christer.holmberg@ericsson.com Mon May 28 00:19:46 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D9621F8597 for ; Mon, 28 May 2012 00:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 ET+2z02JNAIK for ; Mon, 28 May 2012 00:19:45 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E661721F8501 for ; Mon, 28 May 2012 00:19:44 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-bf-4fc3270fdfc3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 44.0A.11869.F0723CF4; Mon, 28 May 2012 09:19:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 28 May 2012 09:19:43 +0200 From: Christer Holmberg To: Ben Campbell Date: Mon, 28 May 2012 09:19:41 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) Thread-Index: Ac0y4/8u3lQzojKARYabA4SvZlZaywHYpscg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C459128EF@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> <2CDCC2EF-B5AF-4101-857C-0B9E42F381A8@nostrum.com> In-Reply-To: <2CDCC2EF-B5AF-4101-857C-0B9E42F381A8@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrS6/+mF/gxlvNSzmd55mt9h7uIvF YuHEf6wOzB5Llvxk8pi18wmLx5fLn9kCmKO4bFJSczLLUov07RK4Mt59dC9YYVrx5WUPUwPj Uq0uRk4OCQETie13zzNC2GISF+6tZ+ti5OIQEjjFKHFn2nx2CGcho8Ta6U+Zuxg5ONgELCS6 /2mDNIgIKEk8b97KAlLDLNDGKDGr7wMLSIJFQFXi8JrrzCC2sECqxKytW1ggGtIkuhetY4aw jSTaz/0Es3kFwiX6b91ggljWwyix++M/JpAEp4C9RO+/K2DNjEDnfT+1BizOLCAucevJfCaI swUkluw5zwxhi0q8fPyPFaJeVOJO+3pGiHodiQW7P7FB2NoSyxa+hlosKHFy5hOWCYxis5CM nYWkZRaSlllIWhYwsqxiFM5NzMxJLzfSSy3KTC4uzs/TK07dxAiMqINbfqvuYLxzTuQQozQH i5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFcGM4Qs/fn+XeKbjeUrDr5kXvVI ZasAu8iJPXx9Sr5rzVutb+boyShKLFuc8UTV/dmE6ceDdu7+t91wx8948VWsrpfEg7U0vkz9 dvXrlQMV0a4dX7R25U4L8agP3fvhzsmbV9x5wxQWmHBMvD09J3r2zRurzv9dzjvHu47vc21d 7fe1L2UlT5gqsRRnJBpqMRcVJwIARDV4gnYCAAA= Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 07:19:46 -0000 Hi, >> --1, 2nd paragraph" "middleboxes must read the message" >>=20 >> Just read? Or parse, or modify? > > I don't see a reply to this one I guess it should be "parse and modify". ----------------------- >> --2, "Name-Based..." >>=20 >> Definition is hard to parse. I think the point is two-fold. The endpoint= uses a trusted CA to establish the validity of the peer certificate, then = compares the SAN of the peer certificate has a match for the peer's MSRP U= RI. >>=20 >> I am not sure I understand. Do you have a suggestion for modified text? >>=20 > > How about the following: > > "Name Based Authentication: An authentication method in which an endpoint= receives an X.509 certificate from its peer as part of the=20 > TLS authentication. The endpoint validates that a chain of issuers exists= from the certificate to a trusted certification authority, and that=20 > the certificate contains the domain name of the peer." > > We could specify the SubjectAltName part, but I don't think that really a= dds to the definition. > > [By the way, this brings up a question. Have we been assuming that name-b= ased authentication survives an untrusted middlebox? It seems like=20 > if the middlebox acts as an MSRP B2BUA, it can just substitute an MSRP UR= I with its own domain name during the offer/answer.] The definitions looks good, except that matching the identity against the d= omain name of the peer wouldn't work in the peer-to-peer case (see RFC 4975= , Section 14.2, 3rd paragraph).=20 A better idea is probably to match the identity against the SIP address-of-= record in the to/from header field of the SIP INVITE, i.e. similar to how S= /MIME certificates are being=20 used (see RFC 3261, Section 23.1). This method is not described by MSRP tho= ugh, and using domain names is probably the only option right now. But, I w= ould still like to change the last sentence in the definition to "contains the domain name or SIP add= ress-of-record of the peer." Whether name-based authentication can be used together with B2B middleboxes= depends on the client behavior, but typically the answer would be no. =20 The user expects that the certificate used by the other endpoint of the TLS= connection matches the identity of the peer (the user corresponding to the= =20 SIP address-of-record in the from/to header field). Both peers would theref= ore notice if a middlebox acts as an MSRP B2BUA and can decide if the sessi= on=20 should be aborted.=20 ----------------------- >>> -- 4.2, step one on receipt of an answer: >>>=20 >>> I have trouble parsing this >>=20 >> I think the text is clear. It says that the c/m does not match path, and= that the endpoint will become passive. >>=20 >> But, if you think the text can be improved, feel free to suggest text. >>=20 >>=20 > Quoting the text here for convenience: > > =20 > 1. The SDP c/m-line address information associated with the MSRP > media description does not match Section 4.4 the information in the > MSRP URI of the 'path' attribute(s) (in which case is assumed that > the SDP c/m-line contains the address to a Middlebox), and the MSRP > endpoint will become "passive" (if the MSRP media description of the > SDP answer contains an SDP 'setup:active' attribute). > > what do you mean by "... does not match Section 4.4..." That is an editorial nit, and should be removed. > Suggested text: > > "The SDP c-line and m-line do not match the address and port from the MS= RP URI in the "path" attribute, and the offerer is forced > to become "passive" by an a "setup:active" attribute in the SDP answer. = This indicates that the m-line and c-line in the answer probably > refer to a middlebox." In order to be consistent with terminology uses elsewhere, I would like to = say "the offerer will beomce "passive", instead of using "forced". ----------------------- >>> -- 6.2, 1st paragraph: "... where the offerer does not support the CEMA= extension." >>>=20 >>> Doesn't that preempt some of the endpoint workarounds for when the peer= does not advertise CEMA? >>=20 >> Yes, and the Middlebox doesn't need to enable MSRP B2BUA functionality i= n cases where the workarounds can be used. >>=20 >>=20 > > So the middlebox is also assumed to check for the cases in 4.2 and 4.3? I still have some problems to understand the comment. The assumption is that, when the offerer indicates support of CEMA, the Mid= dlebox can modify the c/m line. If the offerer does not indicate support of CEMA (e.g. due to the procedure= s in section 4), the Middlebox will enable MSRP B2BUA. ----------------------- >>> -- 7.7, 2nd paragraph" "...may be hard for the endpoint to decide." >>>=20 >>> Decide what? >>=20 >> I suggest to remove that sentence, and re-write the subsequent sentence = in the following way: >>=20 >> "In the end it is up to the endpoint to decide whether the signaling pa= th is trusted or not, and unless >> unless cryptographic end-to-end SDP integrity protection or encryption = is used it may be hard for the >> endpoint to make that decision." >>=20 > > I guess my confusion is that I don't think the fact that the SDP is inte= grity protected or not changes whether the user trusts the signaling channe= l.=20 > If the SDP is integrity protected end to end, he doesn't _have_ to trust = the signaling channel. If it's not, then he must decide if he trusts the ne= twork.=20 > > I assume the text resulted from Robert's objection to the previous revisi= on's assertion that an endpoint might decide it was okay to continue to=20 > communicate if authentication failed. I'm not sure just stepping back and= saying "deciding is hard" is the right approach here. That may need furthe= r=20 > discussion with Robert and/or the security ADs. > > OTOH, should a CEMA endpoint even try to use an end-to-end SDP integrity = protection mechanism? Just because the SDP is integrity protected "end-to-end" does not necessari= ly mean that you don't have to trust the signalling path.=20 If the entity signing the SDP is part of the signalling path as in SIP Ide= ntity (RFC 4474), then the users are in effect trusting the signalling path= (or at least parts of it).=20 If you're using some out-of-band mechanism such as S/MIME with user certifi= cates then I agree with your statement (in my eyes this is true end-to-end = integrity=20 protection). Integrity protecting the entire SDP would not work since signalling nodes n= eed to be able modify the c/m lines. Some new mechanism would need to speci= fied=20 that lets you sign only the fingerprints. ----------------------- Regards, Christer From christer.holmberg@ericsson.com Mon May 28 00:19:48 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A259521F845D for ; Mon, 28 May 2012 00:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 d2hJwyE+4d4Q for ; Mon, 28 May 2012 00:19:46 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D23AD21F8594 for ; Mon, 28 May 2012 00:19:44 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-9d-4fc3270f15e4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F4.53.00702.F0723CF4; Mon, 28 May 2012 09:19:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Mon, 28 May 2012 09:19:43 +0200 From: Christer Holmberg To: Ben Campbell Date: Mon, 28 May 2012 09:19:12 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) Thread-Index: Ac0y3V2hreXbfdV1TlSess96NkPurQHc+KLg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C459128EE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> <7B321302-CDFC-4966-9928-CCB202E33AAC@nostrum.com> In-Reply-To: <7B321302-CDFC-4966-9928-CCB202E33AAC@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+JvrS6/+mF/g5m7JS3md55mt9h7uIvF YuHEf6wOzB5Llvxk8pi18wmLx5fLn9kCmKO4bFJSczLLUov07RK4Mg5MW8xeMGE3Y8W+/+uZ Ghh3T2XsYuTkkBAwkXg5+zYzhC0mceHeerYuRi4OIYFTjBJ7J3xhhXAWMkocbj8OlOHgYBOw kOj+pw3SICKgJPG8eSsLSA2zQBujxKy+DywgCRYBVYnPfVOZQGxhgTCJM+8PsUA0hEu03N7N DGEbSZxc9R6shhcofnNiKwvEsh5Gia1vHoM1cArYS/w7v5IVxGYEOu/7qTVgDcwC4hK3nsxn gjhbQGLJnvNQL4hKvHz8D6peVOJO+3pGiHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMYrOQ jJ2FpGUWkpZZSFoWMLKsYhTOTczMSS8310stykwuLs7P0ytO3cQIjKuDW34b7GDcdF/sEKM0 B4uSOK+e6n5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxbL9+rWF+/ZM6niEKxiXc+fNu0 WS6P65PiNnGxNOe72msO9X1TZhW7s+yobJjStLueD4SkTLyUfy9kiwxivsChztfC+ueG1I9O m8hzgqnnC1nrupO3TmXJ0S4Lftj0+7j098uX3v579PXT39OFk/2EL5o0CD/3+94i9p33xpE/ Ap3x1yReXxRTYinOSDTUYi4qTgQAkBhxhXkCAAA= Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 07:19:48 -0000 Hi, >>> -- 7.1, and general: >>> >>> I'm still uncomfortable with the language that says (or >>> implies) that CEMA enables e2e security in general. In fact, it >>> enables it in a some very specific use cases, namely when you have >>> middleboxes that behave exactly as described in this document--in >>> particular, when they transparently forward TLS, _and_ where direct >>> e2e TLS connections are prevented by some aspect of the provider's >>> architecture (e.g. the middlebox use is required by policy, e2e >>> connections are prevented by NATs, etc.) >> >> In my opinion, the text in section 7.1 is quite clear on this: >> >> "In deployments where Middleboxes are always used, >> which is the main use case for the CEMA extension, the CEMA ex= tension >> increases the security by enabling the use of end-to-end TLS b= etween the two >> endpoints." > > Okay, I see that you constrained the benefit to the case where > "Middleboxes are always used". The problem I still have is, these > middleboxes may or may not choose to allow an e2e security > association. And as far as I can tell, without adding some other layer > of e2e security, the endpoints have no way of knowing if the SA is e2e > or hop-by-hop (and that's really only for the first hop, as the > endpoint can't know what a middlebox does for downstream hops.) Since > the middleboxes are not standardized devices, we can't even point to > normative language indicating that they SHOULD tunnel TLS. > > I 'd argue that if an endpoint can't be reasonably sure it has an e2e > SA, then it doesn't. And I suspect that, in practice, a lot of these > middleboxes are going to be there for reasons other than just firewall > and NAT traversal. If any of those reasons require access to cleartext > (and they almost certainly will), then the middlebox is never going to > just tunnel TLS. > > Keep in mind this draft is about _endpoint_ behavior, and the security > considerations are from the endpoint's perspective. > I think, from the endpoint's perspective, the assertion that CEMA > enables e2e TLS is overstated, unless we are very explicit about what > sort of assumptions the endpoint might make. So I'd like to see this > change to something to the effect of the following: > > "CEMA enables middleboxes to allow end-to-end TLS security > considerations in some cases. MIddleboxes may or may not allow > end-to-send SAs, as a matter of local policy. Therefore a CEMA > endpoint MUST NOT assume that it has an end-to-end SA with it's peer > unless it can confirm this using some other mechanism", perhaps with a > reference to the section(s) discussing some potential methods for > that. I am happy to add text, as long as it doesn't give the impression that CEMA= somehow lowers security. An MSRP endpoint - CEMA enabled or not - should never assume that= it has an end-to-end SA with it's peer unless it can confirm this using some other mechanism. > I think I mentioned that it would be nice to see the security > considerations opening with a discussion of trust implications and > what assumptions an endpoint might make. > This sort of thing might go there. How would it be any different from legacy, non-CEMA, MSRP? A signalling proxy will always be able to insert a covert middlebox and int= ercept the traffic as long as the key management technique used depends on = trusted signalling. ------------- >>> But even then, the fact that the endpoints have no way of telling >>> whether the middlebox actually tunnels TLS vs acting as a >>> TLS b2bua makes me very skeptical of any claim of enabling e2e protecti= on. I >>> think that, if the endpoints can't _prove_ the protection is e2e, >>> then it has to assume that it is _not_ e2e. >> >> True end-to-end security requires a key management protocol >> that does not depend on secure signalling, e.g. name based >> certificates. > > I do not understand that assertion. Why would a key management > protocol that requires trusted signaling not be end to end, assuming > you have trusted signaling? I understand that you pretty much can't > have trusted signaling over the sorts of middleboxes CEMA > contemplates, but that's not the same thing. Assume fingeprint based key managment. If the signalling is trusted then by= definition the fingerprints won't be modified along the signalling path. Regardless of whether CEMA is used and middlebo= xes are inserted, the TLS tunnel has to be end-to-end or else there will be a certificate mismatch. OTOH, if the signalling is not trusted and the fingerprints and the rest of= the SDP can be modified, then a covert middlebox that terminates the TLS tunnel can be inserted regardless of whether CEMA i= s used or not. The only difference between the CEMA and the non-CEMA case is that in the latter case the middlebox has to = modify the URLs in the MSRP messages. I don't understand what it meant by "proving" that the protection is end-to= -end. As long as you rely on secure signalling you (as an end-user) can nev= er verify that the TLS tunnel is end-to-end. ------------- >> Whether such a protocol (together with the necessary >> infrastructure) is available or not is a deployment issue, and is >> independent of CEMA. >> >> The statement that CEMA enables end-to-end security is true >> under following conditions: >> >> (1) The deployment is such that it requires the use of Middleboxes; >> and >> >> (2) A key management protocol is available that does not depend on >> secure signalling. >> >> In my opinion the text is quite clear on the above. > > I don't think it is unclear per se, I just don't think it provides > enough discussion for (potentially naive) implementers to fully > understand the implications of their choices. So, here's some > suggested text: > > "The purpose of CEMA is to enable communication over middleboxes. > These middleboxes are commonly deployed by SIP network operators, who > also commonly deploy firewall and routing policies that prevent media > sessions from working unless they traverse the middleboxes. Endpoints > that are not willing to trust such middleboxes SHOULD NOT enable CEMA. > > CEMA makes it possible for middleboxes to tunnel TLS to allow > end-to-end security associations between endpoints. This is an > improvement over the status quo, since without CEMA, the middleboxes > would be forced to both read and modify the cleartext MSRP messages, > which would make end-to-end confidentiality and integrity protection > impossible. However, middleboxes may still choose to act as TLS > B2BUAs, which would be undetected by endpoints unless they use some > additional mechanism to authenticate that the TLS SA is in fact > end-to-end. Endpoints enabling CEMA MUST NOT assume end-to-end TLS > protection of an MSRP without such a mechanism. > > Since the middleboxes described in this draft operate by modifying the > contents of SDP offers and answers, mechanisms that depend on > end-to-end integrity or confidentiality protection of the SIP message > payloads will fail. Therefore, endpoints using CEMA need to use a key > management or authentication mechanisms that does not require > end-to-end trust in the SIP signaling channel. Section [xxx] discusses > some such mechanisms. > > > These are issues are not specific to CEMA, as the same issues occur > when using middleboxes without CEMA. Security mechanisms that provide > end-to-end protection of SIP message payloads, such as RFC 4744 > [informational reference], will detect the fact that an intermediary > modified the payloads. > Such mechanisms cannot distinguish between an authorized middlebox and > a man-in-the-middle attacker. But since CEMA is specifically intended > for use with middleboxes, CEMA implementors should carefully consider > the trust implications. > " As you do mention in the last paragraph, these issues are not specific to C= EMA-enabled MSRP endpoints. Again, as long as the key exchange depends on secure signalling (such as fingerprint based certificate verific= ation) it is always possible to insert a middlebox and terminate the TLS tunnel, regardless of whether the endpoints support CEMA or not. I don't entirely agree with the final paragraph since I find the usefulness= of RFC 4744 slighlty exagerrated. Assume that an MSRP session is being established from A to B and that AS_A and AS_B are the RFC 4744 Authe= ntication Service for user A and user B, respectively. AS_* and P are SIP p= roxies. A <--> P <--> P <--> AS_A <--> P <--> P <--> AS_B <--> P <--> P <--> B There is no way for user A to know whether the TLS tunnel is really end-to-= end since it cannot be certain that any of the proxies in the start/end of = the path hasn't modified the fingerprint and the c and m lines in the offer/ans= wer SDP. Even if RFC 4744 was extended to allow for signing parts of the SDP I don't= think it would greatly improve security. The user would still be required to trust some of the signalling nodes. ------------- >>> -- 7.1, last sentence "If the key management depends on >>> trust in the >>> signaling plane, the Middlebox is by definition trusted, but the >>> security is still increased as the cleartext is not >>> available in the Middlebox." >>> >>> The first half of that sentence needs elaboration, particular in >>> light of the other assertions that fingerprint based >>> authentication implies trust in the signaling plane. Are you talking ab= out trust >>> that the signaling plane authentication of endpoints is in >>> fact true, or trust in whether the offer/answer has not been tampered >>> with? It seems to me that something like RFC4474 can use fingerprint >>> authentication of the media session with at least minimal trust in midd= leboxes. >>> >>> I think it would help to open the security considerations section >>> with a subsection that explains the trust assumptions for CEMA in >>> more detail >> >> It's actually both. If self-signed certificates is to be >> considered secure then both endpoints and the intermediate >> nodes must be authenticated and the fingerprint attribute >> cannot be tampered with by the intermediaries. > > The sentence in question starts with "If key management > depends on trust in the signaling plane...". But aren't we > saying that the key management mechanism used with CEMA > _cannot_ depend on trust in the signaling plane? Or by "trust > in the signaling plane" do we mean trusting that the > middleboxes will only use their powers for good? In my opinion, "trust in the signalling plane" means that the service provi= der can access the media if it wants to (but no one else) and the user accepts this. I don't see why this definition would change when CEMA i= s introduced. > There's probably a place for a level of trust that means > something like "I trust that only the phone company and maybe > the government can see my cleartext messages", for which just > using SIPS may be good enough. That's not that different from > the current status with SMS/MMS. But it's _very_ different > than an assumption of end-to-end message confidentiality. I don't see how this is related to CEMA. >> I do agree that, if RFC 4474 is used, then it is not >> necessary to trust all the intermediate nodes. However, RFC >> 4474 would not work well together with media anchoring since >> the entire SIP body is signed, which means that the c/m lines >> can't be modified. > > Right. I guess the point is (and I hope my proposed text > above covers it), is that, in order to assume e2e TLS > protection of the MSRP channel in the presence of > middleboxes, you have to use an authentication/key-binding > mechanism that doesn't break when the middleboxes tamper with the SDP. Yes. ------------- >>> -- 7.4, 2nd paragraph: "This can e.g. be hop-by-hop cryptographic >>> protection or cryptographic access protection combined >>> with physical trust in other parts of the signaling plane." >>> >>> I'm not sure what you intend by this sentence. Should I >>> infer that a hard shell soft center model of protection is good enough= ? >>> What are the trust implications for hop by hop? What do you mean by acc= ess >>> protection? >>> >>> It seems like the real point is you _can't_ use end to end >>> integrity protection for signaling across middleboxes, with or without = CEMA. >> >> If you want to use fingerprint based authentication then >> you have to somehow ensure yourself that the fingerprint >> attributes won't be manipulated by intermediate nodes. >> >> That can be accomplished in many different ways, but it is >> completely independent of the use of CEMA. I therefore think >> the current level of detail is sufficient. >> >> Access protection means that the signalling from the user >> to the first SIP Proxy is protected by TLS (i.e. SIPS), >> IPsec, or by some other means (e.g., encryption and integrity >> protection of the air interface in 3G/4G). >> >> The trust implications of using hop-by-hop security and >> fingerprint based authentication are as explained in RFC 5763 >> (see especially Section 8.2). > > My objection was specifically to the idea of "physical > trust". If that means something like IPSec, then great. If it > means I trust that that the network is in a locked room, then > any such assertion needs lots of disclaimers that this is not > the general case. It is up to the service provider to make sure the core network is sufficien= tly protected. This involves securing the physical nodes as well as the links between them. How this is accomplished is a deployment issue.= You could put the all the nodes in a single locked room or you have the nodes in separate locked rooms and use IPSec or TLS in between= . Physical security is always an issue but it is often not mentioned. ------------- >>> -- 7.4, 3rd and 4th paragraphs: >>> >>> How can a user determine which case (e2e TLS vs TLS b2bua) is in >>> effect, and decide whether to allow it? >> >> If fingerprint based authentication is used, then it is not >> possible for the user to determine whether the TLS connection >> is end-to-end or terminated by a B2BUA. >> >> If this is required by the user then he has to use some >> other key management protocol. >> >> Whether this is possible or not is an >> implementation/deployment issue. > > I hope my comment here will become moot based on the larger > discussion of the first two items. I think my answer still holds. The only restriction in the choice of key ma= nagement protocol is that it must be possible for an intermediate signallin= g proxy to modify the c/m lines. ------------- >>> -- 7.4, last paragraph: "But this is not an issue as the signaling >>> network is considered trusted by the endpoint (a >>> requirement to use fingerprint based authentication)." >>> >>> I don't think I accept that statement in general. (see previous >>> comment for 7.1 about trust in middleboxes) >> >> See my reply on your comment on section 7.1. >> >> The statement is true for fingerprint based authentication >> without RFC 4474. If RFC 4474 is used then you only need to >> trust parts of the signaling network, but you won't be able >> to do media anchoring (the main purpose of CEMA). > > For a fingerprint based mechanism without integrity > protection, I agree with you. But the sentence states it as > if were true in general. In any case, it seems like this > section says something like "You can't do fingerprint based > key management unless you trust the network, since you can't > integrity protect the SDP across middleboxes. But that's not > a problem, because you if you wanted to do fingerprints, you > must already trust the network." If that's what you mean, > then it's a circular argument. > > I _think_ the point is really along the lines of "Even though > you can't integrity-protect your fingerprints across > middleboxes, the fingerprint across may be better than > nothing. If you are willing to trust the (possibly both) > service providers, you can reasonably be sure no malicious > third parties can mess with your fingerprints by using SIPS." > > But that's still very different from e2e media protection. > > (Your previous mention of RFC5763 might be relevant here, as > I think we're trying to say the same thing it did). But, isn't the sentence true in general? Currently the only way of integrit= y protecting fingerprint is via SIPS, RFC 4474, or S/MIME. Both SIPS and RF= C 4474 requires that the signalling network is trusted (at least parts of it). End= -to-end S/MIME requires client certificates and if you have that you wouldn't use fingerprints to begin with (or they are still used but they ha= ve no purpose). To me at least, "fingerprint based authentication" without any further prec= ision implies that the signalling network is trusted. ------------- >>> I think the way this is being presented involves some dog-wagging. >>> It's not so much that the end user wants to trust the >>> middleboxes as much as it is an operator that won't let calls complete = if >>> they don't anchor on a middlebox. This is a fairly coercive >>> definition of trust. >> >> I don't think you ever *want* to trust anyone. >> >> The user has to make a decision whether he thinks the benefits of >> using the service outweighs the associated risk. If the >> answer is yes, then he trusts the service provider. > > I doubt the average user is aware he needs to make such a > decision, much less competent to make it. And in many cases, > the user may have no choice in the matter, other than to > carefully watch what they say over the media channel. (But I > hope this concern is covered in my proposed text early in this email.) > > The bigger issue is that the user may not have enough > information to make informed trust decisions. The user does > not know if middleboxes are going to be used or not, or what > policies the middleboxes might have. If he cares, he needs to > take the aforementioned steps to ensure (or at least detect > the lack of) e2e media protection. > > That all being said, I would be okay with this section if it > clarified what it means to trust the network. I think in this > case, it means the user understands that the service provider > has access to and can modify the cleartext of his messages, > and trusts the provider not to do anything inappropriate. > This may be sufficient for normal, day-to-day communication, > but might not be sufficient for banking, medical information, > trade secrets, etc. In some cases the user would be able to control this via his UA. He could c= onfigure the UA to only use a specific key management protocol and reject all others. But of course the service provider could ch= oose to reject such clients. I think your definition of "trust in the signalling network" sounds good an= d is reasonable. >> In some cases it is not possible to setup a call without >> inserting a Middlebox (e.g. IPv4 user to IPv6 user). One could try to d= etermine >> when an end-to-end TCP connection can be established but >> that is often complex. > > There are a number of approaches to that other than using > middleboxes. If a session can't be set up without a > middlebox, it's because the service provider chose to make it > so. The real problem with middleboxes is that they are, or at > least try to be, invisible to endpoints. If the other choices were easier/cheaper than I would assume that the servi= ce provider would implement them. If all the service provider wants is to be able to interecept the traffic, then there are other ways of= doing that as well. ------------- >>> -- 7.5, 2nd to last paragraph: "Alternate key distribution >>> mechanisms...may become ubiquitous enough to solve the key >>> distribution problem in the future." >>> >>> Do we believe RFC 6072 is that ubiquitous _now_? This seems like a >>> dodge to avoid a normative downref. If so, lets not hide it behind >>> "ubiquity". Perhaps the text should read "may become sufficiently >>> standardized..." >> >> The lack of standards is not always the problem. It's also >> about deployment. >> >> So, we could say: "sufficiently standardized and deployed" > > I'm not sure you get my point. Do you believe RFC 6072 is > sufficiently deployed? More deployed than the other choices? I have no idea of how widely deployed RFC 6072, I don't even know who could= provide such information. The current text is based on feedback and discussions with the security area ADs. ------------- >>> -- 7.5, last paragraph: "Some of these options require >>> trusting the service provider, but those issues are beyond the scope of= this >>> document." >>> >>> Isn't this entire document predicated on the idea of endpoints >>> trusting the provider? >> >> Whether the service provider needs to be trusted or not depends on the >> chosen key management, and this is entirely independent of CEMA. > > Not really, since you use CEMA because you expect > middleboxes, and the presence of middleboxes constrains our > key-management mechanisms to things that don't use e2e > integrity protection of the SDP. A lot of this discussion so > far has been about that very point. The only way of integrity protecting the SDP end-to-end that I know of is S= /MIME which requires client certificates. But if you have client certificates then you might as well use them directly in the TLS han= dshake. See my earlier comments regarding RFC 4474. ------------- >>> -- 7.7, 3rd paragraph: "Signaling over a local or closed >>> network MAY be trusted." >>> >>> That's a broad statement to make without a considerably longer and >>> more nuanced discussion. As it stands, it seems to encourage a >>> hard-shell-gooey-center approach to security. >> >> Yes, you're right that this is an imprecise statement. >> >> But I don't understand why we should describe it further in this >> document. Again, the selection of key management protocol and the >> restrictions it imposes is independent of CEMA. > > A normative "MAY" implies some degree of approval. Assuming a > network is secure because it's somehow locked away from the > rest of the world is dangerous. Disgruntled employees with > "secure" network access are the source of a great many > security failures. We may recognize that many carriers and > SDOs choose to depend on physical security alone. That > doesn't mean we should suggest it. Perhaps we should change the "MAY" to a non-normative "may". ------------- >>> -- 7.7, 4th paragraph: "It should however be noted that using >>> fingerprint based authentication over an insecure network >>> increases the security compared to unencrypted MSRP as this makes it >>> harder to perform an man-in-the-middle attack." >>> >>> You don't even need a MiTM attack if MSRP is used without >>> protection >> >> I disagree. >> >> Even if unencrypted MSRP is used, the attacker still need >> to intercept the traffic somehow. This means that you have some level of >> security (the level depends on the network you're on). > > That's not necessarily MiTM. With unprotected MSRP, you are > vulnerable to passive attacks as well. That's a matter of definition. AFAIK a MitM attack can be both passive and = active. What passive really means can also be debated since basically all attacks requires some sort of conscious act. ------------- Regards, Christer From ben@nostrum.com Tue May 29 15:17:55 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A5111E8155 for ; Tue, 29 May 2012 15:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 fHnGCYPPomr8 for ; Tue, 29 May 2012 15:17:53 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C35C11E815E for ; Tue, 29 May 2012 15:17:52 -0700 (PDT) Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4TMHmYn039839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 May 2012 17:17:48 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C459128EE@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 29 May 2012 17:17:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8B33C1AA-3B30-413B-834C-2BFFF152E79D@nostrum.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> <7B321302-CDFC-4966-9928-CCB202E33AAC@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EE@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 22:17:55 -0000 (Apologies for the heavy quoting) On May 28, 2012, at 2:19 AM, Christer Holmberg wrote: > Hi, >=20 >>>> -- 7.1, and general: >>>>=20 >>>> I'm still uncomfortable with the language that says (or >>>> implies) that CEMA enables e2e security in general. In fact, it >>>> enables it in a some very specific use cases, namely when you have >>>> middleboxes that behave exactly as described in this document--in >>>> particular, when they transparently forward TLS, _and_ where direct >>>> e2e TLS connections are prevented by some aspect of the provider's >>>> architecture (e.g. the middlebox use is required by policy, e2e >>>> connections are prevented by NATs, etc.) >>>=20 >>> In my opinion, the text in section 7.1 is quite clear on this: >>>=20 >>> "In deployments where Middleboxes are always used, >>> which is the main use case for the CEMA extension, the CEMA = extension >>> increases the security by enabling the use of end-to-end = TLS between the two >>> endpoints." >>=20 >> Okay, I see that you constrained the benefit to the case where >> "Middleboxes are always used". The problem I still have is, these >> middleboxes may or may not choose to allow an e2e security >> association. And as far as I can tell, without adding some other = layer >> of e2e security, the endpoints have no way of knowing if the SA is = e2e >> or hop-by-hop (and that's really only for the first hop, as the >> endpoint can't know what a middlebox does for downstream hops.) Since >> the middleboxes are not standardized devices, we can't even point to >> normative language indicating that they SHOULD tunnel TLS. >>=20 >> I 'd argue that if an endpoint can't be reasonably sure it has an e2e >> SA, then it doesn't. And I suspect that, in practice, a lot of these >> middleboxes are going to be there for reasons other than just = firewall >> and NAT traversal. If any of those reasons require access to = cleartext >> (and they almost certainly will), then the middlebox is never going = to >> just tunnel TLS. >>=20 >> Keep in mind this draft is about _endpoint_ behavior, and the = security >> considerations are from the endpoint's perspective. >> I think, from the endpoint's perspective, the assertion that CEMA >> enables e2e TLS is overstated, unless we are very explicit about what >> sort of assumptions the endpoint might make. So I'd like to see this >> change to something to the effect of the following: >>=20 >> "CEMA enables middleboxes to allow end-to-end TLS security >> considerations in some cases. MIddleboxes may or may not allow >> end-to-send SAs, as a matter of local policy. Therefore a CEMA >> endpoint MUST NOT assume that it has an end-to-end SA with it's peer >> unless it can confirm this using some other mechanism", perhaps with = a >> reference to the section(s) discussing some potential methods for >> that. >=20 > I am happy to add text, as long as it doesn't give the impression that = CEMA somehow lowers > security. An MSRP endpoint - CEMA enabled or not - should never assume = that it has an end-to-end SA > with it's peer unless it can confirm this using some other mechanism. I agree, and don't mean to say that CEMA lowers security compared to the = _same_topology_ without CEMA. But I do think the use of middleboxes is = likely to lower security compared to true e2e usage. That's why I have = trouble with text suggesting CEMA improves security in _general_. It = _may_ improve security in some very specific cases. Arguably, there are issues with RFC4976 relays as well, since they don't = support e2e crypto at all. But at least they are visible to the = endpoints, at least one of which must choose to use them. Other = techniques such as TURN-TCP could be even better. >=20 >> I think I mentioned that it would be nice to see the security >> considerations opening with a discussion of trust implications and >> what assumptions an endpoint might make. >> This sort of thing might go there. >=20 > How would it be any different from legacy, non-CEMA, MSRP? >=20 > A signalling proxy will always be able to insert a covert middlebox = and intercept the traffic as long as the key management technique used = depends on trusted signalling. It's explicitly incompatible with e2e protection. I think this points out a potential point of language confusion, around = the idea of trusting the signaling channel. When I say I trust the = signaling channel, I mean that there are mechanisms in place to prevent = an intermediary from changing the SDP without my knowing about it. When = you say it, I think you mean that you are allowing middleboxes to change = the SDP, but you trust them to use their powers only for good. And that = goes for the other guy's middleboxes as well. hen you enable CEMA, you are assuming the second case. That by itself = has security implications that should be discussed. It's mentioned in = several places in the draft, but I think it would useful to have a few = paragraphs at the beginning of the security considerations that discuss = it from an explicit security perspective. >=20 >=20 > ------------- >=20 >=20 >>>> But even then, the fact that the endpoints have no way of telling >>>> whether the middlebox actually tunnels TLS vs acting as a >>>> TLS b2bua makes me very skeptical of any claim of enabling e2e = protection. I >>>> think that, if the endpoints can't _prove_ the protection is e2e, >>>> then it has to assume that it is _not_ e2e. >>>=20 >>> True end-to-end security requires a key management protocol >>> that does not depend on secure signalling, e.g. name based >>> certificates. >>=20 >> I do not understand that assertion. Why would a key management >> protocol that requires trusted signaling not be end to end, assuming >> you have trusted signaling? I understand that you pretty much can't >> have trusted signaling over the sorts of middleboxes CEMA >> contemplates, but that's not the same thing. >=20 > Assume fingeprint based key managment. If the signalling is trusted = then by definition the fingerprints won't be modified > along the signalling path. Regardless of whether CEMA is used and = middleboxes are inserted, the TLS tunnel has to be > end-to-end or else there will be a certificate mismatch. >=20 > OTOH, if the signalling is not trusted and the fingerprints and the = rest of the SDP can be modified, then a covert middlebox > that terminates the TLS tunnel can be inserted regardless of whether = CEMA is used or not. The only difference between the > CEMA and the non-CEMA case is that in the latter case the middlebox = has to modify the URLs in the MSRP messages. >=20 > I don't understand what it meant by "proving" that the protection is = end-to-end. As long as you rely on secure signalling you (as an = end-user) can never verify that the TLS tunnel is end-to-end. I think we are talking past each other somewhere, because in my mind = CEMA does not perform its purpose, in the sense that it adds no value, = unless the middleboxes can modify the SDP. That's where the fingerprints = live, right? See my previous comment about "trusted signaling", because I think we = are interpreting it in contradictory ways. >=20 >=20 > ------------- >=20 >=20 >>> Whether such a protocol (together with the necessary >>> infrastructure) is available or not is a deployment issue, and is >>> independent of CEMA. >>>=20 >>> The statement that CEMA enables end-to-end security is true >>> under following conditions: >>>=20 >>> (1) The deployment is such that it requires the use of Middleboxes; >>> and >>>=20 >>> (2) A key management protocol is available that does not depend on >>> secure signalling. >>>=20 >>> In my opinion the text is quite clear on the above. >>=20 >> I don't think it is unclear per se, I just don't think it provides >> enough discussion for (potentially naive) implementers to fully >> understand the implications of their choices. So, here's some >> suggested text: >>=20 >> "The purpose of CEMA is to enable communication over middleboxes. >> These middleboxes are commonly deployed by SIP network operators, who >> also commonly deploy firewall and routing policies that prevent media >> sessions from working unless they traverse the middleboxes. Endpoints >> that are not willing to trust such middleboxes SHOULD NOT enable = CEMA. >>=20 >> CEMA makes it possible for middleboxes to tunnel TLS to allow >> end-to-end security associations between endpoints. This is an >> improvement over the status quo, since without CEMA, the middleboxes >> would be forced to both read and modify the cleartext MSRP messages, >> which would make end-to-end confidentiality and integrity protection >> impossible. However, middleboxes may still choose to act as TLS >> B2BUAs, which would be undetected by endpoints unless they use some >> additional mechanism to authenticate that the TLS SA is in fact >> end-to-end. Endpoints enabling CEMA MUST NOT assume end-to-end TLS >> protection of an MSRP without such a mechanism. >>=20 >> Since the middleboxes described in this draft operate by modifying = the >> contents of SDP offers and answers, mechanisms that depend on >> end-to-end integrity or confidentiality protection of the SIP message >> payloads will fail. Therefore, endpoints using CEMA need to use a key >> management or authentication mechanisms that does not require >> end-to-end trust in the SIP signaling channel. Section [xxx] = discusses >> some such mechanisms. >>=20 >> >> These are issues are not specific to CEMA, as the same issues occur >> when using middleboxes without CEMA. Security mechanisms that provide >> end-to-end protection of SIP message payloads, such as RFC 4744 >> [informational reference], will detect the fact that an intermediary >> modified the payloads. >> Such mechanisms cannot distinguish between an authorized middlebox = and >> a man-in-the-middle attacker. But since CEMA is specifically intended >> for use with middleboxes, CEMA implementors should carefully consider >> the trust implications. >> " >=20 > As you do mention in the last paragraph, these issues are not specific = to CEMA-enabled MSRP endpoints. Again, as long as the key exchange > depends on secure signalling (such as fingerprint based certificate = verification) it is always possible to insert a middlebox and terminate = the > TLS tunnel, regardless of whether the endpoints support CEMA or not. I agree that those things are true, but I think they are things an = implementer (and a user) of CEMA needs to think about. Maybe = implementers of SIP and MSRP in general should think about them too, but = the security considerations of those specs are not under discussion here = :-) >=20 > I don't entirely agree with the final paragraph since I find the = usefulness of RFC 4744 slighlty exagerrated. Assume that an MSRP session = is > being established from A to B and that AS_A and AS_B are the RFC 4744 = Authentication Service for user A and user B, respectively. AS_* and P = are SIP proxies. >=20 > A <--> P <--> P <--> AS_A <--> P <--> P <--> AS_B <--> P <--> P <--> B >=20 > There is no way for user A to know whether the TLS tunnel is really = end-to-end since it cannot be certain that any of the proxies in the = start/end of the > path hasn't modified the fingerprint and the c and m lines in the = offer/answer SDP. >=20 > Even if RFC 4744 was extended to allow for signing parts of the SDP I = don't think it would greatly improve security. The user would still be > required to trust some of the signalling nodes. I accept that RFC4744 can be used in insecure ways. That's true of most = security mechanisms. I think it can also be used in reasonably secure = ways. But in any case, I listed it as an example, and would be happy to = have it removed, or replaced with some other similar example. >=20 >=20 > ------------- >=20 >=20 >>>> -- 7.1, last sentence "If the key management depends on >>>> trust in the >>>> signaling plane, the Middlebox is by definition trusted, but the >>>> security is still increased as the cleartext is not >>>> available in the Middlebox." >>>>=20 >>>> The first half of that sentence needs elaboration, particular in >>>> light of the other assertions that fingerprint based >>>> authentication implies trust in the signaling plane. Are you = talking about trust >>>> that the signaling plane authentication of endpoints is in >>>> fact true, or trust in whether the offer/answer has not been = tampered >>>> with? It seems to me that something like RFC4474 can use = fingerprint >>>> authentication of the media session with at least minimal trust in = middleboxes. >>>>=20 >>>> I think it would help to open the security considerations section >>>> with a subsection that explains the trust assumptions for CEMA in >>>> more detail >>>=20 >>> It's actually both. If self-signed certificates is to be >>> considered secure then both endpoints and the intermediate >>> nodes must be authenticated and the fingerprint attribute >>> cannot be tampered with by the intermediaries. >>=20 >> The sentence in question starts with "If key management >> depends on trust in the signaling plane...". But aren't we >> saying that the key management mechanism used with CEMA >> _cannot_ depend on trust in the signaling plane? Or by "trust >> in the signaling plane" do we mean trusting that the >> middleboxes will only use their powers for good? >=20 > In my opinion, "trust in the signalling plane" means that the service = provider can access the media if it wants to (but no one else) and the > user accepts this. I don't see why this definition would change when = CEMA is introduced. See my previous comment on the subject. I guess it's a question of = trusting the _channel_ vs the _network_. >=20 >> There's probably a place for a level of trust that means >> something like "I trust that only the phone company and maybe >> the government can see my cleartext messages", for which just >> using SIPS may be good enough. That's not that different from >> the current status with SMS/MMS. But it's _very_ different >> than an assumption of end-to-end message confidentiality. >=20 > I don't see how this is related to CEMA. Again, while it may apply to non CEMA cases, it's important for CEMA = implementers to understand it. >=20 >>> I do agree that, if RFC 4474 is used, then it is not >>> necessary to trust all the intermediate nodes. However, RFC >>> 4474 would not work well together with media anchoring since >>> the entire SIP body is signed, which means that the c/m lines >>> can't be modified. >>=20 >> Right. I guess the point is (and I hope my proposed text >> above covers it), is that, in order to assume e2e TLS >> protection of the MSRP channel in the presence of >> middleboxes, you have to use an authentication/key-binding >> mechanism that doesn't break when the middleboxes tamper with the = SDP. >=20 > Yes. >=20 >=20 > ------------- >=20 >=20 >>>> -- 7.4, 2nd paragraph: "This can e.g. be hop-by-hop cryptographic >>>> protection or cryptographic access protection combined >>>> with physical trust in other parts of the signaling plane." >>>>=20 >>>> I'm not sure what you intend by this sentence. Should I >>>> infer that a hard shell soft center model of protection is good = enough? >>>> What are the trust implications for hop by hop? What do you mean by = access >>>> protection? >>>>=20 >>>> It seems like the real point is you _can't_ use end to end >>>> integrity protection for signaling across middleboxes, with or = without CEMA. >>>=20 >>> If you want to use fingerprint based authentication then >>> you have to somehow ensure yourself that the fingerprint >>> attributes won't be manipulated by intermediate nodes. >>>=20 >>> That can be accomplished in many different ways, but it is >>> completely independent of the use of CEMA. I therefore think >>> the current level of detail is sufficient. >>>=20 >>> Access protection means that the signalling from the user >>> to the first SIP Proxy is protected by TLS (i.e. SIPS), >>> IPsec, or by some other means (e.g., encryption and integrity >>> protection of the air interface in 3G/4G). >>>=20 >>> The trust implications of using hop-by-hop security and >>> fingerprint based authentication are as explained in RFC 5763 >>> (see especially Section 8.2). >>=20 >> My objection was specifically to the idea of "physical >> trust". If that means something like IPSec, then great. If it >> means I trust that that the network is in a locked room, then >> any such assertion needs lots of disclaimers that this is not >> the general case. >=20 > It is up to the service provider to make sure the core network is = sufficiently protected. This involves securing the physical nodes as = well > as the links between them. How this is accomplished is a deployment = issue. You could put the all the nodes in a single locked room or > you have the nodes in separate locked rooms and use IPSec or TLS in = between. Physical security is always an issue but it is often not > mentioned. I think this is a definition issue. I think of "physical security" to = mean doors and locks. IPSec and TLS are not physical security by that = definition. I'm not sure if that's the _correct_ definition, but if = there is one that includes crypto techniques, it would be good to = reference it or define it. >=20 >=20 > ------------- >=20 >=20 >>>> -- 7.4, 3rd and 4th paragraphs: >>>>=20 >>>> How can a user determine which case (e2e TLS vs TLS b2bua) is in >>>> effect, and decide whether to allow it? >>>=20 >>> If fingerprint based authentication is used, then it is not >>> possible for the user to determine whether the TLS connection >>> is end-to-end or terminated by a B2BUA. >>>=20 >>> If this is required by the user then he has to use some >>> other key management protocol. >>>=20 >>> Whether this is possible or not is an >>> implementation/deployment issue. >>=20 >> I hope my comment here will become moot based on the larger >> discussion of the first two items. >=20 >=20 > I think my answer still holds. The only restriction in the choice of = key management protocol is that it must be possible for an intermediate = signalling proxy to modify the c/m lines. Again, I see this as a detail of the larger arguments above--let's see = how those shake out. >=20 >=20 > ------------- >=20 >=20 >>>> -- 7.4, last paragraph: "But this is not an issue as the signaling >>>> network is considered trusted by the endpoint (a >>>> requirement to use fingerprint based authentication)." >>>>=20 >>>> I don't think I accept that statement in general. (see previous >>>> comment for 7.1 about trust in middleboxes) >>>=20 >>> See my reply on your comment on section 7.1. >>>=20 >>> The statement is true for fingerprint based authentication >>> without RFC 4474. If RFC 4474 is used then you only need to >>> trust parts of the signaling network, but you won't be able >>> to do media anchoring (the main purpose of CEMA). >>=20 >> For a fingerprint based mechanism without integrity >> protection, I agree with you. But the sentence states it as >> if were true in general. In any case, it seems like this >> section says something like "You can't do fingerprint based >> key management unless you trust the network, since you can't >> integrity protect the SDP across middleboxes. But that's not >> a problem, because you if you wanted to do fingerprints, you >> must already trust the network." If that's what you mean, >> then it's a circular argument. >>=20 >> I _think_ the point is really along the lines of "Even though >> you can't integrity-protect your fingerprints across >> middleboxes, the fingerprint across may be better than >> nothing. If you are willing to trust the (possibly both) >> service providers, you can reasonably be sure no malicious >> third parties can mess with your fingerprints by using SIPS." >>=20 >> But that's still very different from e2e media protection. >>=20 >> (Your previous mention of RFC5763 might be relevant here, as >> I think we're trying to say the same thing it did). >=20 > But, isn't the sentence true in general? Currently the only way of = integrity protecting fingerprint is via SIPS, RFC 4474, or S/MIME. Both = SIPS and RFC 4474 > requires that the signalling network is trusted (at least parts of = it). End-to-end S/MIME requires client certificates and if you have that = you > wouldn't use fingerprints to begin with (or they are still used but = they have no purpose). >=20 > To me at least, "fingerprint based authentication" without any further = precision implies that the signalling network is trusted. Trust of the "network" is not an all or nothing thing, and I think that = is the crux of our disagreements. Trusting an identity service is a very = different thing than trusting a middlebox. There may be cases where one = or both are reasonable, but they are still different animals. This is = partly the basis of my request for a more detailed discussion about = trust assumptions. Rather than say you must "trust the signaling" plane, = let's talk about what elements you trust for what purposes. >=20 >=20 > ------------- >=20 >=20 >>>> I think the way this is being presented involves some dog-wagging. >>>> It's not so much that the end user wants to trust the >>>> middleboxes as much as it is an operator that won't let calls = complete if >>>> they don't anchor on a middlebox. This is a fairly coercive >>>> definition of trust. >>>=20 >>> I don't think you ever *want* to trust anyone. >>>=20 >>> The user has to make a decision whether he thinks the benefits of >>> using the service outweighs the associated risk. If the >>> answer is yes, then he trusts the service provider. >>=20 >> I doubt the average user is aware he needs to make such a >> decision, much less competent to make it. And in many cases, >> the user may have no choice in the matter, other than to >> carefully watch what they say over the media channel. (But I >> hope this concern is covered in my proposed text early in this = email.) >>=20 >> The bigger issue is that the user may not have enough >> information to make informed trust decisions. The user does >> not know if middleboxes are going to be used or not, or what >> policies the middleboxes might have. If he cares, he needs to >> take the aforementioned steps to ensure (or at least detect >> the lack of) e2e media protection. >>=20 >> That all being said, I would be okay with this section if it >> clarified what it means to trust the network. I think in this >> case, it means the user understands that the service provider >> has access to and can modify the cleartext of his messages, >> and trusts the provider not to do anything inappropriate. >> This may be sufficient for normal, day-to-day communication, >> but might not be sufficient for banking, medical information, >> trade secrets, etc. >=20 > In some cases the user would be able to control this via his UA. He = could configure the UA to only use a specific key management > protocol and reject all others. But of course the service provider = could choose to reject such clients. >=20 > I think your definition of "trust in the signalling network" sounds = good and is reasonable. >=20 >>> In some cases it is not possible to setup a call without >>> inserting a Middlebox (e.g. IPv4 user to IPv6 user). One could try = to determine >>> when an end-to-end TCP connection can be established but >>> that is often complex. >>=20 >> There are a number of approaches to that other than using >> middleboxes. If a session can't be set up without a >> middlebox, it's because the service provider chose to make it >> so. The real problem with middleboxes is that they are, or at >> least try to be, invisible to endpoints. >=20 > If the other choices were easier/cheaper than I would assume that the = service provider would implement them. If all the service provider > wants is to be able to interecept the traffic, then there are other = ways of doing that as well. >=20 >=20 Okay, I guess. I think the real answer is that the operator often has = requirements that go well beyond NAT/Firewall traversal. > ------------- >=20 >=20 >>>> -- 7.5, 2nd to last paragraph: "Alternate key distribution >>>> mechanisms...may become ubiquitous enough to solve the key >>>> distribution problem in the future." >>>>=20 >>>> Do we believe RFC 6072 is that ubiquitous _now_? This seems like a >>>> dodge to avoid a normative downref. If so, lets not hide it behind >>>> "ubiquity". Perhaps the text should read "may become sufficiently >>>> standardized..." >>>=20 >>> The lack of standards is not always the problem. It's also >>> about deployment. >>>=20 >>> So, we could say: "sufficiently standardized and deployed" >>=20 >> I'm not sure you get my point. Do you believe RFC 6072 is >> sufficiently deployed? More deployed than the other choices? >=20 > I have no idea of how widely deployed RFC 6072, I don't even know who = could provide such information. The current text is based > on feedback and discussions with the security area ADs. Hopefully one or more of them will read this, and comment on this = specific point. Again, my concern is that we don't use sleight-of-hand = to avoid a normative downref. We we need one, we should go through the = process to get one. If we really don't, then I'm fine with it. >=20 >=20 >=20 > ------------- >=20 >=20 >>>> -- 7.5, last paragraph: "Some of these options require >>>> trusting the service provider, but those issues are beyond the = scope of this >>>> document." >>>>=20 >>>> Isn't this entire document predicated on the idea of endpoints >>>> trusting the provider? >>>=20 >>> Whether the service provider needs to be trusted or not depends on = the >>> chosen key management, and this is entirely independent of CEMA. >>=20 >> Not really, since you use CEMA because you expect >> middleboxes, and the presence of middleboxes constrains our >> key-management mechanisms to things that don't use e2e >> integrity protection of the SDP. A lot of this discussion so >> far has been about that very point. >=20 > The only way of integrity protecting the SDP end-to-end that I know of = is S/MIME which requires client certificates. But if you have > client certificates then you might as well use them directly in the = TLS handshake. See my earlier comments regarding RFC 4474. I think this is another detail of the larger arguments above. >=20 >=20 > ------------- >=20 >=20 >>>> -- 7.7, 3rd paragraph: "Signaling over a local or closed >>>> network MAY be trusted." >>>>=20 >>>> That's a broad statement to make without a considerably longer and >>>> more nuanced discussion. As it stands, it seems to encourage a >>>> hard-shell-gooey-center approach to security. >>>=20 >>> Yes, you're right that this is an imprecise statement. >>>=20 >>> But I don't understand why we should describe it further in this >>> document. Again, the selection of key management protocol and the >>> restrictions it imposes is independent of CEMA. >>=20 >> A normative "MAY" implies some degree of approval. Assuming a >> network is secure because it's somehow locked away from the >> rest of the world is dangerous. Disgruntled employees with >> "secure" network access are the source of a great many >> security failures. We may recognize that many carriers and >> SDOs choose to depend on physical security alone. That >> doesn't mean we should suggest it. >=20 > Perhaps we should change the "MAY" to a non-normative "may". I'm okay with it, although it might be better to avoid the confusion of = a non-normative "may". Perhaps something along the lines of "might?" >=20 >=20 > ------------- >=20 >=20 >>>> -- 7.7, 4th paragraph: "It should however be noted that using >>>> fingerprint based authentication over an insecure network >>>> increases the security compared to unencrypted MSRP as this makes = it >>>> harder to perform an man-in-the-middle attack." >>>>=20 >>>> You don't even need a MiTM attack if MSRP is used without >>>> protection >>>=20 >>> I disagree. >>>=20 >>> Even if unencrypted MSRP is used, the attacker still need >>> to intercept the traffic somehow. This means that you have some = level of >>> security (the level depends on the network you're on). >>=20 >> That's not necessarily MiTM. With unprotected MSRP, you are >> vulnerable to passive attacks as well. >=20 > That's a matter of definition. AFAIK a MitM attack can be both passive = and active. What passive really means can also be > debated since basically all attacks requires some sort of conscious = act. A MiTM attack by definition requires the ability to inject messages into = the network. As far as I know, that's the usual distinguishing factor in = "active" vs "passive" attacks. From ben@nostrum.com Tue May 29 15:35:07 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BECB11E812E for ; Tue, 29 May 2012 15:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 l6TPL5hL8UXx for ; Tue, 29 May 2012 15:35:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 447DC21F8670 for ; Tue, 29 May 2012 15:35:06 -0700 (PDT) Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4TMZ2Vv040704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 May 2012 17:35:03 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C459128EF@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 29 May 2012 17:35:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> <2CDCC2EF-B5AF-4101-857C-0B9E42F381A8@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EF@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 22:35:07 -0000 On May 28, 2012, at 2:19 AM, Christer Holmberg wrote: > Hi, >=20 >>> --1, 2nd paragraph" "middleboxes must read the message" >>>=20 >>> Just read? Or parse, or modify? >>=20 >> I don't see a reply to this one >=20 > I guess it should be "parse and modify". Okay >=20 >=20 > ----------------------- >=20 >=20 >>> --2, "Name-Based..." >>>=20 >>> Definition is hard to parse. I think the point is two-fold. The = endpoint uses a trusted CA to establish the validity of the peer = certificate, then compares the SAN of the peer certificate has a match = for the peer's MSRP URI. >>>=20 >>> I am not sure I understand. Do you have a suggestion for modified = text? >>>=20 >>=20 >> How about the following: >>=20 >> "Name Based Authentication: An authentication method in which an = endpoint receives an X.509 certificate from its peer as part of the=20 >> TLS authentication. The endpoint validates that a chain of issuers = exists from the certificate to a trusted certification authority, and = that=20 >> the certificate contains the domain name of the peer." >>=20 >> We could specify the SubjectAltName part, but I don't think that = really adds to the definition. >>=20 >> [By the way, this brings up a question. Have we been assuming that = name-based authentication survives an untrusted middlebox? It seems like=20= >> if the middlebox acts as an MSRP B2BUA, it can just substitute an = MSRP URI with its own domain name during the offer/answer.] >=20 > The definitions looks good, except that matching the identity against = the domain name of the peer wouldn't work in the peer-to-peer case (see = RFC 4975, Section 14.2, 3rd paragraph).=20 Sure, but we're not talking about the peer to peer case. I can't imagine = why a b2bua would insert a different domain name unless it also intended = to redirect the media. >=20 > A better idea is probably to match the identity against the SIP = address-of-record in the to/from header field of the SIP INVITE, i.e. = similar to how S/MIME certificates are being=20 > used (see RFC 3261, Section 23.1). This method is not described by = MSRP though, and using domain names is probably the only option right = now. But, I would still like to change > the last sentence in the definition to "contains the domain name or = SIP address-of-record of the peer." Right now there is no requirement that the endpoint use the same name = for signaling and for MSRP. The expectation is that a name in the cert = matches the MSRP URI supplied by the peer. Maybe there should be some = tighter coupling between the MSRP name and the SIP AoR, I think that's = out of scope for this draft. I don't think the definition needs to describe the entire process. could = we just say "name of the peer", perhaps with a disclaimer that that the = meaning of "name" is as described by the protocol? >=20 > Whether name-based authentication can be used together with B2B = middleboxes depends on the client behavior, but typically the answer = would be no. =20 > The user expects that the certificate used by the other endpoint of = the TLS connection matches the identity of the peer (the user = corresponding to the=20 > SIP address-of-record in the from/to header field). Both peers would = therefore notice if a middlebox acts as an MSRP B2BUA and can decide if = the session=20 > should be aborted.=20 See my comment above. Right now, MSRP as defined in RFC4975 has no such = expectation. >=20 >=20 > ----------------------- >=20 >=20 >>>> -- 4.2, step one on receipt of an answer: >>>>=20 >>>> I have trouble parsing this >>>=20 >>> I think the text is clear. It says that the c/m does not match path, = and that the endpoint will become passive. >>>=20 >>> But, if you think the text can be improved, feel free to suggest = text. >>>=20 >>>=20 >>=20 > Quoting the text here for convenience: >>=20 >>=20 >> 1. The SDP c/m-line address information associated with the MSRP >> media description does not match Section 4.4 the information in the >> MSRP URI of the 'path' attribute(s) (in which case is assumed that >> the SDP c/m-line contains the address to a Middlebox), and the MSRP >> endpoint will become "passive" (if the MSRP media description of = the >> SDP answer contains an SDP 'setup:active' attribute). >>=20 >> what do you mean by "... does not match Section 4.4..." >=20 > That is an editorial nit, and should be removed. >=20 >> Suggested text: >>=20 >> "The SDP c-line and m-line do not match the address and port = from the MSRP URI in the "path" attribute, and the offerer is forced >> to become "passive" by an a "setup:active" attribute in the SDP = answer. This indicates that the m-line and c-line in the answer probably >> refer to a middlebox." >=20 > In order to be consistent with terminology uses elsewhere, I would = like to say "the offerer will beomce "passive", instead of using = "forced". Works for me. >=20 >=20 > ----------------------- >=20 >=20 >>>> -- 6.2, 1st paragraph: "... where the offerer does not support the = CEMA extension." >>>>=20 >>>> Doesn't that preempt some of the endpoint workarounds for when the = peer does not advertise CEMA? >>>=20 >>> Yes, and the Middlebox doesn't need to enable MSRP B2BUA = functionality in cases where the workarounds can be used. >>>=20 >>>=20 >>=20 >> So the middlebox is also assumed to check for the cases in 4.2 and = 4.3? >=20 > I still have some problems to understand the comment. >=20 > The assumption is that, when the offerer indicates support of CEMA, = the Middlebox can modify the c/m line. >=20 > If the offerer does not indicate support of CEMA (e.g. due to the = procedures in section 4), the Middlebox will enable MSRP B2BUA. There are situations described in section 4 where an endpoint can = attempt to use CEMA even if the other party did not indicate support. Do = we assume the middlebox is also going to try to figure out those cases, = or is it purely going to look for the CEMA tag? If the second, does it = require both parties to include it? >=20 >=20 > ----------------------- >=20 >=20 >>>> -- 7.7, 2nd paragraph" "...may be hard for the endpoint to decide." >>>>=20 >>>> Decide what? >>>=20 >>> I suggest to remove that sentence, and re-write the subsequent = sentence in the following way: >>>=20 >>> "In the end it is up to the endpoint to decide whether the = signaling path is trusted or not, and unless >>> unless cryptographic end-to-end SDP integrity protection or = encryption is used it may be hard for the >>> endpoint to make that decision." >>>=20 >>=20 >> I guess my confusion is that I don't think the fact that the SDP is = integrity protected or not changes whether the user trusts the signaling = channel.=20 >> If the SDP is integrity protected end to end, he doesn't _have_ to = trust the signaling channel. If it's not, then he must decide if he = trusts the network And of course the definition of trusting the channel I gave in the = separate email a couple of minutes ago is completely inconsistent with = that :-) But here I think we are talking about trust in operator = middleboxes, right? >> .=20 >>=20 >> I assume the text resulted from Robert's objection to the previous = revision's assertion that an endpoint might decide it was okay to = continue to=20 >> communicate if authentication failed. I'm not sure just stepping back = and saying "deciding is hard" is the right approach here. That may need = further=20 >> discussion with Robert and/or the security ADs. >>=20 >> OTOH, should a CEMA endpoint even try to use an end-to-end SDP = integrity protection mechanism? >=20 > Just because the SDP is integrity protected "end-to-end" does not = necessarily mean that you don't have to trust the signalling path.=20 >=20 > If the entity signing the SDP is part of the signalling path as in = SIP Identity (RFC 4474), then the users are in effect trusting the = signalling path (or at least parts of it).=20 > If you're using some out-of-band mechanism such as S/MIME with user = certificates then I agree with your statement (in my eyes this is true = end-to-end integrity=20 > protection). >=20 > Integrity protecting the entire SDP would not work since signalling = nodes need to be able modify the c/m lines. Some new mechanism would = need to specified=20 > that lets you sign only the fingerprints. Again, I think breaking down "trust the network" assertions to talk = about what elements you trust for what purposes would help a lot here. From christer.holmberg@ericsson.com Thu May 31 02:46:41 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DC921F8675 for ; Thu, 31 May 2012 02:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 BZbupxabQBpo for ; Thu, 31 May 2012 02:46:40 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EA26021F8692 for ; Thu, 31 May 2012 02:46:36 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-e3-4fc73dfbaa9d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 55.51.11869.BFD37CF4; Thu, 31 May 2012 11:46:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 31 May 2012 11:46:35 +0200 From: Christer Holmberg To: Ben Campbell Date: Thu, 31 May 2012 11:46:34 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) Thread-Index: Ac0960usOIrdjw7oQiSdYEQTIqtwIgAZ3ZIQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C459A338F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> <2CDCC2EF-B5AF-4101-857C-0B9E42F381A8@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EF@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvre5v2+P+Bgs7ZC3md55mt9h7uIvF YuHEf6wOzB5Llvxk8pi18wmLx5fLn9kCmKO4bFJSczLLUov07RK4Mp7vXMVc8ESl4n3rVtYG xmWyXYycHBICJhJLTixnhrDFJC7cW8/WxcjFISRwilHi+939UM5CRom1/68wdTFycLAJWEh0 /9MGaRARUJJ43ryVBaSGWaCNUWJW3wcWkASLgKrEo7fNYFOFBVIlZm3dwgLRkCbRvWgdM4Rt JLHm2C4wm1cgXOLfohcsEMv6mSTO9+9kB1nGKWAvcbPFCaSGEei676fWMIHYzALiEreezGeC uFpAYsme81AfiEq8fPyPFaJeVOJO+3pGiHodiQW7P7FB2NoSyxa+htorKHFy5hOWCYxis5CM nYWkZRaSlllIWhYwsqxiFM5NzMxJLzfSSy3KTC4uzs/TK07dxAiMqINbfqvuYLxzTuQQozQH i5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGMN5BOb9/NDLw6hipnsuSvbtppWn +u+52h7ObPA0ULuqcrR0pVPuZXuvi6kPG7n2n3Z53NX1f4eStsPaE72Lsn9LWqtpnXc4p8pq JH5QIWeK+2pbqyO6QfEZP972Nrz8NOvTzyKLipj+9r7ab49l1h487Gwv3vBd6Vqmdd4P8/Ru z//Vx3b9U2Ipzkg01GIuKk4EAP+osul2AgAA Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 09:46:41 -0000 Hi Ben, I will move the issue on section 7.7 to the other e-mail, where the other s= ection 7 issues are discussed. ----------------------- >>>> --2, "Name-Based..." >>>>=20 >>>> Definition is hard to parse. I think the point is two-fold. The endpoi= nt uses a trusted CA to establish the validity of the peer certificate, the= n compares the SAN of the peer certificate has a match for the peer's MSRP= URI. >>>>=20 >>>> I am not sure I understand. Do you have a suggestion for modified text= ? >>>>=20 >>>=20 >>> How about the following: >>>=20 >>> "Name Based Authentication: An authentication method in which an=20 >>> endpoint receives an X.509 certificate from its peer as part of the=20 >>> TLS authentication. The endpoint validates that a chain of issuers exis= ts from the certificate to a trusted certification authority, and that the = certificate contains the domain name of the peer." >>>=20 >>> We could specify the SubjectAltName part, but I don't think that really= adds to the definition. >>>=20 >>> [By the way, this brings up a question. Have we been assuming that=20 >>> name-based authentication survives an untrusted middlebox? It seems=20 >>> like if the middlebox acts as an MSRP B2BUA, it can just substitute=20 >>> an MSRP URI with its own domain name during the offer/answer.] >>=20 >> The definitions looks good, except that matching the identity against th= e domain name of the peer wouldn't work in the peer-to-peer case (see RFC 4= 975, Section 14.2, 3rd paragraph).=20 > > Sure, but we're not talking about the peer to peer case. I can't imagine = why a b2bua would insert a different domain name unless it also intended to= redirect the media. >=20 >> A better idea is probably to match the identity against the SIP=20 >> address-of-record in the to/from header field of the SIP INVITE, i.e.=20 >> similar to how S/MIME certificates are being used (see RFC 3261, Section= 23.1).=20 >> This method is not described by MSRP though, and using domain names is p= robably=20 >> the only option right now. But, I would still like to change the last se= ntence in the=20 >> definition to "contains the domain name or SIP address-of-record of the = peer." >> >> Right now there is no requirement that the endpoint use the same name fo= r signaling and for MSRP.=20 >> The expectation is that a name in the cert matches the MSRP URI supplied= by the peer. Maybe there should=20 >> be some tighter coupling between the MSRP name and the SIP AoR, I think = that's out of scope for this draft. > > I don't think the definition needs to describe the entire process. could = we just say "name of the peer", perhaps with a disclaimer that that the mea= ning of "name" is as described by the protocol? So, something like: "Name Based Authentication: An authentication method in which an=20 endpoint receives an X.509 certificate from its peer as part of the=20 TLS authentication. The endpoint validates that a chain of issuers exists= =20 from the certificate to a trusted certification authority, and that the=20 certificate contains the name (as indicated in SIP/SDP) of the=20 peer." =20 ----------------------- >>>>> -- 6.2, 1st paragraph: "... where the offerer does not support the CE= MA extension." >>>>>=20 >>>>> Doesn't that preempt some of the endpoint workarounds for when the pe= er does not advertise CEMA? >>>>=20 >>>> Yes, and the Middlebox doesn't need to enable MSRP B2BUA functionality= in cases where the workarounds can be used. >>>>=20 >>> So the middlebox is also assumed to check for the cases in 4.2 and 4.3? >>=20 >> I still have some problems to understand the comment. >>=20 >> The assumption is that, when the offerer indicates support of CEMA, the = Middlebox can modify the c/m line. >>=20 >> If the offerer does not indicate support of CEMA (e.g. due to the proced= ures in section 4), the Middlebox will enable MSRP B2BUA. > > There are situations described in section 4 where an endpoint can attempt= to use CEMA even if the other party did not=20 > indicate support. Do we assume the middlebox is also going to try to figu= re out those cases, or is it purely going to look for the > CEMA tag? If the second, does it require both parties to include it? Ok, now I understand :) The Middlebox does not need to be aware of different cases. It only looks f= or the CEMA tag in the offer. Then, if the answerer does not support CEMA, and CEMA cannot be used (based= on the criteria in section 4.2), the offerer will send a new offer, withou= t the CEMA tag. ----------------------- Regards, Christer From ben@nostrum.com Thu May 31 11:47:56 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BCF11E8086 for ; Thu, 31 May 2012 11:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 vOir-OmDQa65 for ; Thu, 31 May 2012 11:47:55 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A155711E8081 for ; Thu, 31 May 2012 11:47:55 -0700 (PDT) Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4VIlm5h093575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 13:47:49 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C459A338F@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 31 May 2012 13:47:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5F1730E7-0C2D-49F1-8C8E-B5B065BABF90@nostrum.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> <2CDCC2EF-B5AF-4101-857C-0B9E42F381A8@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C459A338F@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 18:47:56 -0000 On May 31, 2012, at 4:46 AM, Christer Holmberg wrote: [...] >>=20 >> I don't think the definition needs to describe the entire process. = could we just say "name of the peer", perhaps with a disclaimer that = that the meaning of "name" is as described by the protocol? >=20 > So, something like: >=20 >=20 > "Name Based Authentication: An authentication method in which an=20= > endpoint receives an X.509 certificate from its peer as part of = the=20 > TLS authentication. The endpoint validates that a chain of = issuers exists=20 > from the certificate to a trusted certification authority, and = that the=20 > certificate contains the name (as indicated in SIP/SDP) of the=20= > peer." >=20 >=20 Works for me. > --------------------- [...] >> There are situations described in section 4 where an endpoint can = attempt to use CEMA even if the other party did not=20 >> indicate support. Do we assume the middlebox is also going to try to = figure out those cases, or is it purely going to look for the >> CEMA tag? If the second, does it require both parties to include it? >=20 > Ok, now I understand :) >=20 > The Middlebox does not need to be aware of different cases. It only = looks for the CEMA tag in the offer. >=20 > Then, if the answerer does not support CEMA, and CEMA cannot be used = (based on the criteria in section 4.2), the offerer will send a new = offer, without the CEMA tag. Okay.