From sumanth@cablelabs.com Tue Aug 21 09:31:53 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1163921F87B7; Tue, 21 Aug 2012 09:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWOaH6JEZL6m; Tue, 21 Aug 2012 09:31:52 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0521F87B6; Tue, 21 Aug 2012 09:31:49 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q7LGVlZG020740; Tue, 21 Aug 2012 10:31:48 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 21 Aug 2012 10:31:47 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 21 Aug 2012 10:31:48 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Tue, 21 Aug 2012 10:31:45 -0600 Thread-Topic: Security Directorate early review comments (from Paul Hoffman) Thread-Index: Ac1/unXInveEUfdeQQi+APx35OQepA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC59141111BB3sumanthcablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: Paul Hoffman , "secdir@ietf.org" Subject: [drinks] Security Directorate early review comments (from Paul Hoffman) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:31:53 -0000 --_000_CC59141111BB3sumanthcablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG Participants, As you know we requested an early review from the security directorate, the= apps area, and a couple of other external reviewers on the two I-Ds that a= re currently I last call. I am forwarding the comments from Paul Hoffman (on behalf of the security d= irectorate) since he is not on the mailing list. Please include him on your= responses. - S -- From Paul Hoffman Greetings. I have been requested to review draft-ietf-drinks-spp-framework = for the Security Directorate. This review is being done during WG Last Call= instead of IETF Last Call as a special request. I note that literally no o= ne has spoken up in the WG during WG Last Call since it began three weeks a= go. SPPF is a protocol for provisioning session establishment data into data re= gistries and SIP service providers. Well, actually it's not. It is a descri= ption of the data format and some handwaving about how to transport that da= ta. The mandatory-to-implement transport is listed in a different document,= draft-ietf-drinks-spp-protocol-over-soap (for which there is no reference = in this document...). The transport protocol requirements listed in section 4 of this document ar= e fairly generic, as are the security requirements. The descriptions of the= transport requirements are fine. The security requirements are not so grea= t: while servers MUST be able to authenticate clients, confidentiality and = integrity protection SHOULD be provided. Given that the mandatory-to implem= ent transport is SOAP, this approximately translates to "must do some sort = or minimal client authentication, should consider using TLS but lots of cli= ents and servers probably won't actually do it". I think that undershoots m= oderns security practices, which would have TLS be mandatory. Even though this is a security review, I cannot resist a non-security quest= ion: SOAP? In 2012? Really? -- --_000_CC59141111BB3sumanthcablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
WG Participants,

As you know we requested an early review fr= om the security directorate, the apps area, and a couple of other external = reviewers on the two I-Ds that are currently I last call. 

I am forwarding the comments f= rom Paul Hoffman (on behalf of the security directorate) since he is not on= the mailing list. Please include him on your responses.


- S


-- From Paul Hoffman

Greetings. I have been requested to review draft-ietf-drinks-spp= -framework for the Security Directorate. This review is being done during W= G Last Call instead of IETF Last Call as a special request. I note that lit= erally no one has spoken up in the WG during WG Last Call since it began th= ree weeks ago.
SPPF= is a protocol for provisioning session establishment data into data regist= ries and SIP service providers. Well, actually it's not. It is a descriptio= n of the data format and some handwaving about how to transport that data. = The mandatory-to-implement transport is listed in a different document, dra= ft-ietf-drinks-spp-protocol-over-soap (for which there is no reference in t= his document...).

T= he transport protocol requirements listed in section 4 of this document are= fairly generic, as are the security requirements. The descriptions of the = transport requirements are fine. The security requirements are not so great= : while servers MUST be able to authenticate clients, confidentiality and i= ntegrity protection SHOULD be provided. Given that the mandatory-to impleme= nt transport is SOAP, this approximately translates to "must do some sort o= r minimal client authentication, should consider using TLS but lots of clie= nts and servers probably won't actually do it". I think that undershoots mo= derns security practices, which would have TLS be mandatory.

Even though this is a security re= view, I cannot resist a non-security question: SOAP? In 2012? Really? <s= igh>

--
--_000_CC59141111BB3sumanthcablelabscom_-- From paul.hoffman@vpnc.org Sat Aug 18 18:18:59 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E5221F84CD; Sat, 18 Aug 2012 18:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMXbSEMge7Xw; Sat, 18 Aug 2012 18:18:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 39C3321F84CE; Sat, 18 Aug 2012 18:18:58 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7J1ItuG093132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Aug 2012 18:18:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Aug 2012 18:18:55 -0700 Message-Id: <14DB90CC-BF75-4EBC-8348-29E85D678DDE@vpnc.org> To: drinks@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) X-Mailman-Approved-At: Tue, 21 Aug 2012 23:29:20 -0700 Cc: secdir Subject: [drinks] Secdir review of draft-ietf-drinks-spp-framework X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 01:18:59 -0000 Greetings. I have been requested to review = draft-ietf-drinks-spp-framework for the Security Directorate. This = review is being done during WG Last Call instead of IETF Last Call as a = special request. I note that literally no one has spoken up in the WG = during WG Last Call since it began three weeks ago. SPPF is a protocol for provisioning session establishment data into data = registries and SIP service providers. Well, actually it's not. It is a = description of the data format and some handwaving about how to = transport that data. The mandatory-to-implement transport is listed in a = different document, draft-ietf-drinks-spp-protocol-over-soap (for which = there is no reference in this document...). The transport protocol requirements listed in section 4 of this document = are fairly generic, as are the security requirements. The descriptions = of the transport requirements are fine. The security requirements are = not so great: while servers MUST be able to authenticate clients, = confidentiality and integrity protection SHOULD be provided. Given that = the mandatory-to implement transport is SOAP, this approximately = translates to "must do some sort or minimal client authentication, = should consider using TLS but lots of clients and servers probably won't = actually do it". I think that undershoots moderns security practices, = which would have TLS be mandatory. Even though this is a security review, I cannot resist a non-security = question: SOAP? In 2012? Really? --Paul Hoffman From vbhatia@tnsi.com Thu Aug 23 09:36:26 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC01621F8582; Thu, 23 Aug 2012 09:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDRQLyDC99OE; Thu, 23 Aug 2012 09:36:24 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADA921F85A3; Thu, 23 Aug 2012 09:36:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJlbNlCsEQfn/2dsb2JhbABFu1SCIAEBAQQBAQEkEw0nCwwEAgEIEQQBAR8JBycLFAkIAQEEAQ0FCIgQqlaPO4sIGoYXYAOWaJF/gUU X-IronPort-AV: E=Sophos;i="4.80,301,1344207600"; d="scan'208";a="1485043" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 23 Aug 2012 17:36:26 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 23 Aug 2012 12:36:22 -0400 From: "Bhatia, Vikas" To: Paul Hoffman , "drinks@ietf.org" Date: Thu, 23 Aug 2012 12:36:21 -0400 Thread-Topic: [drinks] Secdir review of draft-ietf-drinks-spp-framework Thread-Index: Ac2AL4WpGgx7n2I7SJm66NwiqSSlmABEVq1w Message-ID: References: <14DB90CC-BF75-4EBC-8348-29E85D678DDE@vpnc.org> In-Reply-To: <14DB90CC-BF75-4EBC-8348-29E85D678DDE@vpnc.org> 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 Cc: secdir Subject: Re: [drinks] Secdir review of draft-ietf-drinks-spp-framework X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:36:26 -0000 Hello Paul, Thanks for the review. Below is a response to your comments: =3D=3DYour Comment=3D=3D SPPF is a protocol for provisioning session establishment data into data re= gistries and SIP service providers. Well, actually it's not. It is a descri= ption of the data format and some handwaving about how to transport that da= ta. The mandatory-to-implement transport is listed in a different document,= draft-ietf-drinks-spp-protocol-over-soap (for which there is no reference = in this document...). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Response -> Agree with your point, but the line "SPPF is a protocol..." is not present = in the current version of the framework draft (http://tools.ietf.org/html/d= raft-ietf-drinks-spp-framework-02) (assuming this line was taken from the d= ocument that was reviewed). Below is an excerpt from the "Abstract" that th= e framework document currently has to describe SPPF: This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). Let us know if you have a further comment on the above text. We will add a reference to the spp-protocol-over-soap document to the "Norm= ative References" section in the framework document. =3D=3DYour Comment=3D=3D The transport protocol requirements listed in section 4 of this document ar= e fairly generic, as are the security requirements. The descriptions of the= transport requirements are fine. The security requirements are not so grea= t: while servers MUST be able to authenticate clients, confidentiality and = integrity protection SHOULD be provided. Given that the mandatory-to implem= ent transport is SOAP, this approximately translates to "must do some sort = or minimal client authentication, should consider using TLS but lots of cli= ents and servers probably won't actually do it". I think that undershoots m= oderns security practices, which would have TLS be mandatory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Response -> Your point is valid. TLS is a MUST as mentioned in section 11.1 of the SOAP= document (http://tools.ietf.org/html/draft-ietf-drinks-spp-protocol-over-s= oap-02). It seems to be an oversight to not have this requirement as a MUST= in the framework. We shall replace existing text in the "Confidentiality a= nd Integrity" section of the framework document as below: "Any conforming transport protocol specification MUST provide means to prot= ect the confidentiality and integrity of any data transmitted between SPPF = client and server. " For easy reference, below is the existing text (which shall be replaced wit= h the above one liner): "4.6. Confidentiality and Integrity In some deployments, the SPPF objects that an SPPF registry manages can be private in nature. As a result it MAY NOT be appropriate to for transmission in plain text over a connection to the SPPF registry. Therefore, the transport protocol SHOULD provide means for end-to-end encryption between the SPPF client and server. For some SPPF implementations, it may be acceptable for the data to be transmitted in plain text, but the failure to detect a change in data after it leaves the SPPF client and before it is received at the server, either by accident or with a malicious intent, will adversely affect the stability and integrity of the registry. Therefore, the transport protocol SHOULD provide means for data integrity" protection." Thanks, Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Paul Hoffman Sent: Saturday, August 18, 2012 9:19 PM To: drinks@ietf.org Cc: secdir Subject: [drinks] Secdir review of draft-ietf-drinks-spp-framework Greetings. I have been requested to review draft-ietf-drinks-spp-framework = for the Security Directorate. This review is being done during WG Last Call= instead of IETF Last Call as a special request. I note that literally no o= ne has spoken up in the WG during WG Last Call since it began three weeks a= go. SPPF is a protocol for provisioning session establishment data into data re= gistries and SIP service providers. Well, actually it's not. It is a descri= ption of the data format and some handwaving about how to transport that da= ta. The mandatory-to-implement transport is listed in a different document,= draft-ietf-drinks-spp-protocol-over-soap (for which there is no reference = in this document...). The transport protocol requirements listed in section 4 of this document ar= e fairly generic, as are the security requirements. The descriptions of the= transport requirements are fine. The security requirements are not so grea= t: while servers MUST be able to authenticate clients, confidentiality and = integrity protection SHOULD be provided. Given that the mandatory-to implem= ent transport is SOAP, this approximately translates to "must do some sort = or minimal client authentication, should consider using TLS but lots of cli= ents and servers probably won't actually do it". I think that undershoots m= oderns security practices, which would have TLS be mandatory. Even though this is a security review, I cannot resist a non-security quest= ion: SOAP? In 2012? Really? --Paul Hoffman _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.