From nobody Mon May 4 07:17:53 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE741A0126 for ; Mon, 4 May 2015 07:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flD5JHk3L5kB for ; Mon, 4 May 2015 07:17:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6435E1A0143 for ; Mon, 4 May 2015 07:17:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t44EHhFT013712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 4 May 2015 17:17:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t44EHhqH029917; Mon, 4 May 2015 17:17:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21831.32647.271750.284687@fireball.kivinen.iki.fi> Date: Mon, 4 May 2015 17:17:43 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 14:17:52 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Paul Hoffman is next in the rotation. For telechat 2015-05-14 Reviewer LC end Draft Shaun Cooley T 2015-05-05 draft-ietf-appsawg-rfc7001bis-07 Shawn Emery T 2015-05-01 draft-ietf-manet-tlv-naming-01 Daniel Kahn Gillmor T 2015-04-30 draft-ietf-rtgwg-mofrr-06 David Waltermire T 2015-04-20 draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 Sam Weiler T 2015-04-20 draft-ietf-scim-api-17 Brian Weis T 2015-04-20 draft-ietf-scim-core-schema-18 For telechat 2015-05-28 Phillip Hallam-Baker T 2015-05-15 draft-ietf-manet-olsrv2-multitopology-05 Sean Turner T 2015-04-20 draft-ietf-bmwg-traffic-management-04 Last calls and special requests: John Bradley 2015-05-13 draft-jimenez-p2psip-coap-reload-08 Dave Cridland 2015-05-06 draft-ietf-dhc-dynamic-shared-v4allocation-06 Alan DeKok 2015-05-01 draft-ietf-dprive-problem-statement-04 Donald Eastlake 2015-05-04 draft-ietf-ipsecme-ikev2-null-auth-06 Tobias Gondrom 2015-05-07 draft-ietf-dane-smtp-with-dane-16 Olafur Gudmundsson 2015-05-14 draft-ietf-kitten-sasl-oauth-22 Steve Hanna 2015-05-15 draft-ietf-rtcweb-stun-consent-freshness-11 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-15 Dan Harkins 2015-05-15 draft-ietf-siprec-protocol-16 Sam Hartman 2015-05-13 draft-ietf-straw-b2bua-stun-05 Eric Osterweil 2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01 Vincent Roca 2015-04-24 draft-hansen-scram-sha256-02 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Tina TSOU 2015-05-05 draft-hallambaker-tlsfeature-09 Klaas Wierenga 2015-04-17 draft-ietf-tls-negotiated-ff-dhe-08 Dacheng Zhang 2015-04-28 draft-ietf-lisp-eid-block-mgmnt-04 -- kivinen@iki.fi From nobody Mon May 4 10:39:52 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CC81A1BB4; Mon, 4 May 2015 10:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJq1GrITYYli; Mon, 4 May 2015 10:39:49 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5871A870E; Mon, 4 May 2015 10:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2368; q=dns/txt; s=iport; t=1430761189; x=1431970789; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=n8t9APKPorvc1yb6WhNQRkw80ySJ5FBbthbumSuVLAc=; b=HS+G5VFytcUDOHiTcJYGSeuBcb5lKFGfj8wsi9/b2Klgvy2mkm97t/I6 vXRHrOCagc1lnDndw5A+r4MKpSJTg93Tcc4tE21i+ta3RAFM9uebBOOXx avQYZpTTU5lzlTa9BdxxWe2BftXs6qO81bYxpbgldRycWwXk0LDstkeDG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BLBADdrUdV/4oNJK1TCYMMgTTFYAmHW4EwOBQBAQEBAQEBgQqEIwR5EgE4SCcEAQ2IMMV5AQEBAQEBAQEBAQEBAQEBAQEbj2JcH4J/gRYFkg2KUpYeI4N0gjOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,366,1427760000"; d="scan'208";a="146864981" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 04 May 2015 17:39:48 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t44Hdmsf030539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 May 2015 17:39:48 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.236]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 4 May 2015 12:39:48 -0500 From: "Brian Weis (bew)" To: The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-scim-core-schema-18 Thread-Index: AQHQhpFRcajFEh9bqUu5ZrnFZSPoLw== Date: Mon, 4 May 2015 17:39:48 +0000 Message-ID: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.211] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3C599E7071641A4EA0DC662A7139F9B5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-scim-core-schema.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-scim-core-schema-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 17:39:51 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. For the security area directions, I consider this document to be "Ready wit= h nits=94. This document documents resources a JSON scheme for Cross-Domain Identity M= anagement, a standard definition of attributes representing users and group= s, and a set of named schemas incorporating these attributes. The goal of t= he document is to make identity management in cloud based applications and= services easier. This is used when identity information needs to be shared= between services. The Security Considerations (Section 9) in version 18 is reasonably clear i= n the first two sub-sections that there are risks to sensitive information = defined in the schema, these sub-sections point to helpful text in draft-ie= tf-scim. It is much improved over version 17. I have a couple of comments s= uggesting clarification be added to the document. Section 9.3 begins by stating the schema =93defines attributes that MAY con= tain personally identifiable information as well as other sensitive data=94= . I don=92t understand the =93MAY=94. Just about every attribute described = in this document is arguably personally identifiable information (PII), sin= ce transporting PII between services seems to be the actual need for develo= pment of the schema. It seems more accurate to say =93defines attributes th= at contain personally identifiable information as well as other sensitive d= ata=94. (Also =93MAY=94 is intended to declare a part of the standard that = is optional for an implementation, and I don=92t see how that could apply h= ere.) Section 4.1.1 defines the =93password=94 attribute as a =93clear text passw= ord=94. It is much safer to store and pass a salted and hashed password. Do= none of the services using this schema support a method of hashing a user = password to see if it matches a given hashed value ? Or could this be an op= tion in the scheme definition? If so, it would be worth describing that her= e and in the Security Considerations section. Brian From nobody Mon May 4 12:27:01 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07AD1ACE92; Mon, 4 May 2015 12:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkJIL6ixTCi8; Mon, 4 May 2015 12:26:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF98B1ACE91; Mon, 4 May 2015 12:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4685; q=dns/txt; s=iport; t=1430767618; x=1431977218; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QX4zk6aEeB5K9MSLhlXyHRic80Jz4RqjyqDFbmbxLqU=; b=J2FO5MAc+iBkK8A9EMNaGkiJfuCvxJEg5WFgHhZ0ITO197c98P+01DRo z+jHelzzk0OQLLmdhGY6btNZ63Caj0CfCTTcfe40G+oBU/RjiWH5QQ1H7 2k7+hYaD05x6txnZIKnLTLGxMDXtAgf+uX2WXLKPnPX4OUBV3uYruXzXI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALBQAOx0dV/5BdJa1TBgODDIEvBbcTljYCgTFMAQEBAQEBgQuEIAEBAQMBeQULAgEIGBgWMhMSAgQOBYgXAwkIxg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXizmCTYFVBwoBHiMQBxEHgn+BFgEEhTwKjEeJA4FPgSSOGoMOg1IjgWUhHYFRb4ELOYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,367,1427760000"; d="scan'208";a="416963010" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 04 May 2015 19:26:57 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t44JQtaN006474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 May 2015 19:26:55 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.236]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 4 May 2015 14:26:55 -0500 From: "Brian Weis (bew)" To: Phil Hunt Thread-Topic: Secdir review of draft-ietf-scim-core-schema-18 Thread-Index: AQHQhpFRcajFEh9bqUu5ZrnFZSPoL51se4mAgAALtAA= Date: Mon, 4 May 2015 19:26:55 +0000 Message-ID: <5D457571-55CA-45D4-A9F4-9F1B8C96E6B4@cisco.com> References: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> <53991217-3DC8-4A97-9FCC-93B632D3C878@yahoo.com> In-Reply-To: <53991217-3DC8-4A97-9FCC-93B632D3C878@yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.211] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-scim-core-schema.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-scim-core-schema-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 19:26:58 -0000 Hi Phil, On May 4, 2015, at 11:45 AM, Phil Hunt wrote: > Brian, >=20 > Thanks for taking time to review both the recent documents. My proposed c= orrections inline=85 >=20 > Phil >=20 > phil.hunt@yahoo.com >=20 >> On May 4, 2015, at 10:39 AM, Brian Weis (bew) wrote: >>=20 >> I have reviewed this document as part of the security directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like a= ny other last call comments. >>=20 >> For the security area directions, I consider this document to be "Ready = with nits=94. >>=20 >> This document documents resources a JSON scheme for Cross-Domain Identit= y Management, a standard definition of attributes representing users and gr= oups, and a set of named schemas incorporating these attributes. The goal o= f the document is to make identity management in cloud based applications = and services easier. This is used when identity information needs to be sha= red between services. >>=20 >> The Security Considerations (Section 9) in version 18 is reasonably clea= r in the first two sub-sections that there are risks to sensitive informati= on defined in the schema, these sub-sections point to helpful text in draft= -ietf-scim. It is much improved over version 17. I have a couple of comment= s suggesting clarification be added to the document. >>=20 >> Section 9.3 begins by stating the schema =93defines attributes that MAY = contain personally identifiable information as well as other sensitive data= =94. I don=92t understand the =93MAY=94. Just about every attribute describ= ed in this document is arguably personally identifiable information (PII), = since transporting PII between services seems to be the actual need for dev= elopment of the schema. It seems more accurate to say =93defines attributes= that contain personally identifiable information as well as other sensitiv= e data=94. (Also =93MAY=94 is intended to declare a part of the standard th= at is optional for an implementation, and I don=92t see how that could appl= y here.) > You are right. The 2119 MAY is probably not appropriate. How about=20 > =93defines attributes that are sensitive and may be considered personally= identifiable information(PII).=94 >=20 > I think that inverts the emphasis getting people to realize that almost a= ll data is likely at least sensitive.=20 That=92s a fine way to state it, thanks. >>=20 >> Section 4.1.1 defines the =93password=94 attribute as a =93clear text pa= ssword=94. It is much safer to store and pass a salted and hashed password.= Do none of the services using this schema support a method of hashing a us= er password to see if it matches a given hashed value ? Or could this be an= option in the scheme definition? If so, it would be worth describing that = here and in the Security Considerations section. >=20 > This may be a question of document structure. We could copy/move the sal= ting/hashing requirements to the schema definition. However, my thinking wa= s the salting/hashing is not part of the protocol - thus should not be in t= he core spec sections. My thinking was that salting/hashing is really a sec= urity consideration for the implementer since it is a practical considerati= on of =93using" the protocol. >=20 > I=92m not sure what you mean by =93pass a salted and hashed password=94 (= may be I am mis-reading your intent). That would seem to be something to sa= y must not be done since it implies multiple servers having a common salt/h= ash. In LDAP, even replication passes the clear text but the servers only = store replica unique salted hashes. The distinction I=92m making is the difference between a clear text passwo= rd (e.g., "t1meMa$heen=94) and a hashed version of the password, which alth= ough still sensitive is considered to be safer. My hope would be for the sc= hema to represent both forms of passwords, because it would be a significa= nt improvement in security. If this is the case, then it would be good to d= escribe the use of the hashed password wherever you feel makes the most sen= se. If this is not the case, it would be worth mentioning in Security Consi= derations that hashed passwords are not supported, because the omission is = likely to be surprising to some readers. Thanks, Brian=20 >=20 >>=20 >> Brian --=20 Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Mon May 4 23:57:11 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A211B2EAB; Mon, 4 May 2015 23:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hjze4vvGMtqb; Mon, 4 May 2015 23:57:07 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B65F1B2EAA; Mon, 4 May 2015 23:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6239; q=dns/txt; s=iport; t=1430809027; x=1432018627; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DUhjz2XCap5wPnbM4MuUzbwG3SWdrUv357rTCOtZpI4=; b=WRuv2/Sf/DvOuUSXbGJ8QY7cWlY5MsvoALAzKVs8hOcV5fDgIsAER6a2 23NUDJ3iFwnvDFDXy7xj5ha5ny6tf2zDxX3TrP9dNHKb2TO9lWnBYApo7 rap2ko/E6lPq0m/0ZAVuI523svbpdqMCVYJuujNXbln6Ph/GyRJLZjkSQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BOBAChaEhV/4kNJK1TBgODDIEvBbcijlIJh1sCgTA4FAEBAQEBAQGBCoQgAQEBAwF5BQsCAQgYGBYyExICBA4FiBcDCQjFJQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOYJNgVUHCgEIFiMQBxEHgn+BFgEEhTwKjEeJA4FPgSSOGoMOg1IjgWUhHYFRb4EDCBcigQEBAQE X-IronPort-AV: E=Sophos;i="5.13,371,1427760000"; d="scan'208";a="147162585" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 05 May 2015 06:57:06 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t456v6WG002813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 06:57:06 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.236]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 5 May 2015 01:57:06 -0500 From: "Brian Weis (bew)" To: Phil Hunt Thread-Topic: Secdir review of draft-ietf-scim-core-schema-18 Thread-Index: AQHQhpFRcajFEh9bqUu5ZrnFZSPoL51se4mAgAALtACAALrqAIAABemA Date: Tue, 5 May 2015 06:57:05 +0000 Message-ID: References: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> <53991217-3DC8-4A97-9FCC-93B632D3C878@yahoo.com> <5D457571-55CA-45D4-A9F4-9F1B8C96E6B4@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.211] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8A29A9985F0EAD43AA6BC59CA91523A7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-scim-core-schema.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-scim-core-schema-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 06:57:09 -0000 Hi Phil, On May 4, 2015, at 11:35 PM, Phil Hunt wrote: > Brian, >=20 > I think we may be talking about different things. Maybe there is some con= fusion on the role of provisioning vs. authentication or maybe protocol vs.= storage? >=20 > If a client were to pre salt/hash a password (supposedly to protect it in= transit) then the service provider and client would have to agree on a sal= t and hash. This decreases security dramatically since multiple domain now= have the same hashed values. =20 >=20 > The intent is that every service provider endpoint that gets a clear-text= password, generates its own unique salted hash and stores that value. Ah. I actually wasn=92t suggesting doing a salt/hash just for protecting it= in transit =97 I was expecting that the endpoints would use the same metho= d and so could send the salted hash. So this explanation of each provider g= enerating their own unique salted hash is a key point. It would definitely = be helpful to add this rationale to the security considerations section, as= it explains why the password attribute needs to be clear text. Thanks, Brian >=20 > Phil >=20 > phil.hunt@yahoo.com >=20 >> On May 4, 2015, at 12:26 PM, Brian Weis (bew) wrote: >>=20 >> Hi Phil, >>=20 >> On May 4, 2015, at 11:45 AM, Phil Hunt wrote: >>=20 >>> Brian, >>>=20 >>> Thanks for taking time to review both the recent documents. My proposed= corrections inline=85 >>>=20 >>> Phil >>>=20 >>> phil.hunt@yahoo.com >>>=20 >>>> On May 4, 2015, at 10:39 AM, Brian Weis (bew) wrote: >>>>=20 >>>> I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. Thes= e comments were written primarily for the benefit of the security area dire= ctors. Document editors and WG chairs should treat these comments just like= any other last call comments. >>>>=20 >>>> For the security area directions, I consider this document to be "Read= y with nits=94. >>>>=20 >>>> This document documents resources a JSON scheme for Cross-Domain Ident= ity Management, a standard definition of attributes representing users and = groups, and a set of named schemas incorporating these attributes. The goal= of the document is to make identity management in cloud based application= s and services easier. This is used when identity information needs to be s= hared between services. >>>>=20 >>>> The Security Considerations (Section 9) in version 18 is reasonably cl= ear in the first two sub-sections that there are risks to sensitive informa= tion defined in the schema, these sub-sections point to helpful text in dra= ft-ietf-scim. It is much improved over version 17. I have a couple of comme= nts suggesting clarification be added to the document. >>>>=20 >>>> Section 9.3 begins by stating the schema =93defines attributes that MA= Y contain personally identifiable information as well as other sensitive da= ta=94. I don=92t understand the =93MAY=94. Just about every attribute descr= ibed in this document is arguably personally identifiable information (PII)= , since transporting PII between services seems to be the actual need for d= evelopment of the schema. It seems more accurate to say =93defines attribut= es that contain personally identifiable information as well as other sensit= ive data=94. (Also =93MAY=94 is intended to declare a part of the standard = that is optional for an implementation, and I don=92t see how that could ap= ply here.) >>> You are right. The 2119 MAY is probably not appropriate. How about=20 >>> =93defines attributes that are sensitive and may be considered personal= ly identifiable information(PII).=94 >>>=20 >>> I think that inverts the emphasis getting people to realize that almost= all data is likely at least sensitive.=20 >>=20 >> That=92s a fine way to state it, thanks. >>=20 >>>>=20 >>>> Section 4.1.1 defines the =93password=94 attribute as a =93clear text = password=94. It is much safer to store and pass a salted and hashed passwor= d. Do none of the services using this schema support a method of hashing a = user password to see if it matches a given hashed value ? Or could this be = an option in the scheme definition? If so, it would be worth describing tha= t here and in the Security Considerations section. >>>=20 >>> This may be a question of document structure. We could copy/move the s= alting/hashing requirements to the schema definition. However, my thinking = was the salting/hashing is not part of the protocol - thus should not be in= the core spec sections. My thinking was that salting/hashing is really a s= ecurity consideration for the implementer since it is a practical considera= tion of =93using" the protocol. >>>=20 >>> I=92m not sure what you mean by =93pass a salted and hashed password=94= (may be I am mis-reading your intent). That would seem to be something to = say must not be done since it implies multiple servers having a common salt= /hash. In LDAP, even replication passes the clear text but the servers onl= y store replica unique salted hashes. >>=20 >> The distinction I=92m making is the difference between a clear text pas= sword (e.g., "t1meMa$heen=94) and a hashed version of the password, which a= lthough still sensitive is considered to be safer. My hope would be for the= schema to represent both forms of passwords, because it would be a signif= icant improvement in security. If this is the case, then it would be good t= o describe the use of the hashed password wherever you feel makes the most = sense. If this is not the case, it would be worth mentioning in Security Co= nsiderations that hashed passwords are not supported, because the omission = is likely to be surprising to some readers. >>=20 >> Thanks, >> Brian=20 >>=20 >>>=20 >>>>=20 >>>> Brian >>=20 >> --=20 >> Brian Weis >> Security, CSG, Cisco Systems >> Telephone: +1 408 526 4796 >> Email: bew@cisco.com >>=20 >=20 --=20 Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Tue May 5 00:21:42 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2451C1B2EBD; Tue, 5 May 2015 00:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scoPDqOjryVd; Tue, 5 May 2015 00:21:37 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BEC1B2EC0; Tue, 5 May 2015 00:21:37 -0700 (PDT) Received: by widdi4 with SMTP id di4so134633393wid.0; Tue, 05 May 2015 00:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q688npnWghBNS8lZazUtGyieTKeUp6xZwjsBqEGPW8Y=; b=GHS8liafJBRsMb0cJ9qQuVuhuZTZ0q+lG54BeRZhsuaegrk4vbSmS728cI++v2K1Uv OoesqCep6HpluTp6c3GfpKTsa6Jr7S4Jh0ZwqV4eTTMNcwKatjlYv0+xDxT5rshD2Mhd glHXM7tR8r55zgvzYl4y+MBq/q3ngJjumb2m+ReXXYcfoMjleHEYbW3ZRXuPq0+HXvse wCQHLuquiJOKxk7uW3wYo1I3lAcpt/jknm/4+YI3u04k+yllfewr8s9zqlWiEQQdmLgn QB5nEXm0EJU7oicTBlwWR1/vnRc4sSRZiCEdzka+pK9T8As2i8B+X+lJDzSHXn7cQogQ hogA== X-Received: by 10.194.205.101 with SMTP id lf5mr8075116wjc.42.1430810495982; Tue, 05 May 2015 00:21:35 -0700 (PDT) Received: from [10.67.44.90] (host86-187-25-174.range86-187.btcentralplus.com. [86.187.25.174]) by mx.google.com with ESMTPSA id kc4sm24116314wjc.2.2015.05.05.00.21.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 May 2015 00:21:35 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <5D457571-55CA-45D4-A9F4-9F1B8C96E6B4@cisco.com> Date: Tue, 5 May 2015 08:21:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F34F5D3-8567-45DD-AB08-1AC173992B88@gmail.com> References: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> <53991217-3DC8-4A97-9FCC-93B632D3C878@yahoo.com> <5D457571-55CA-45D4-A9F4-9F1B8C96E6B4@cisco.com> To: "Brian Weis (bew)" Archived-At: Cc: Phil Hunt , "draft-ietf-scim-core-schema.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-scim-core-schema-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 07:21:39 -0000 Thanks for your review, Brian. Inline. Sent from my iPhone > On May 4, 2015, at 8:26 PM, "Brian Weis (bew)" wrote: >=20 > Hi Phil, >=20 >> On May 4, 2015, at 11:45 AM, Phil Hunt wrote: >>=20 >> Brian, >>=20 >> Thanks for taking time to review both the recent documents. My proposed c= orrections inline=E2=80=A6 >>=20 >> Phil >>=20 >> phil.hunt@yahoo.com >>=20 >>> On May 4, 2015, at 10:39 AM, Brian Weis (bew) wrote: >>>=20 >>> I have reviewed this document as part of the security directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These c= omments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like any o= ther last call comments. >>>=20 >>> For the security area directions, I consider this document to be "Ready w= ith nits=E2=80=9D. >>>=20 >>> This document documents resources a JSON scheme for Cross-Domain Identit= y Management, a standard definition of attributes representing users and gro= ups, and a set of named schemas incorporating these attributes. The goal of t= he document is to make identity management in cloud based applications and s= ervices easier. This is used when identity information needs to be shared be= tween services. >>>=20 >>> The Security Considerations (Section 9) in version 18 is reasonably clea= r in the first two sub-sections that there are risks to sensitive informatio= n defined in the schema, these sub-sections point to helpful text in draft-i= etf-scim. It is much improved over version 17. I have a couple of comments s= uggesting clarification be added to the document. >>>=20 >>> Section 9.3 begins by stating the schema =E2=80=9Cdefines attributes tha= t MAY contain personally identifiable information as well as other sensitive= data=E2=80=9D. I don=E2=80=99t understand the =E2=80=9CMAY=E2=80=9D. Just a= bout every attribute described in this document is arguably personally ident= ifiable information (PII), since transporting PII between services seems to b= e the actual need for development of the schema. It seems more accurate to s= ay =E2=80=9Cdefines attributes that contain personally identifiable informat= ion as well as other sensitive data=E2=80=9D. (Also =E2=80=9CMAY=E2=80=9D is= intended to declare a part of the standard that is optional for an implemen= tation, and I don=E2=80=99t see how that could apply here.) >> You are right. The 2119 MAY is probably not appropriate. How about=20 >> =E2=80=9Cdefines attributes that are sensitive and may be considered pers= onally identifiable information(PII).=E2=80=9D >>=20 >> I think that inverts the emphasis getting people to realize that almost a= ll data is likely at least sensitive. >=20 > That=E2=80=99s a fine way to state it, thanks. Thanks for this change. I haven't gotten to this draft yet and agree this w= as needed. >=20 >>>=20 >>> Section 4.1.1 defines the =E2=80=9Cpassword=E2=80=9D attribute as a =E2=80= =9Cclear text password=E2=80=9D. It is much safer to store and pass a salted= and hashed password. Do none of the services using this schema support a me= thod of hashing a user password to see if it matches a given hashed value ? O= r could this be an option in the scheme definition? If so, it would be worth= describing that here and in the Security Considerations section. >>=20 >> This may be a question of document structure. We could copy/move the sal= ting/hashing requirements to the schema definition. However, my thinking was= the salting/hashing is not part of the protocol - thus should not be in the= core spec sections. My thinking was that salting/hashing is really a securi= ty consideration for the implementer since it is a practical consideration o= f =E2=80=9Cusing" the protocol. >>=20 >> I=E2=80=99m not sure what you mean by =E2=80=9Cpass a salted and hashed p= assword=E2=80=9D (may be I am mis-reading your intent). That would seem to b= e something to say must not be done since it implies multiple servers having= a common salt/hash. In LDAP, even replication passes the clear text but th= e servers only store replica unique salted hashes. >=20 > The distinction I=E2=80=99m making is the difference between a clear text= password (e.g., "t1meMa$heen=E2=80=9D) and a hashed version of the password= , which although still sensitive is considered to be safer. My hope would be= for the schema to represent both forms of passwords, because it would be a= significant improvement in security. If this is the case, then it would be g= ood to describe the use of the hashed password wherever you feel makes the m= ost sense. If this is not the case, it would be worth mentioning in Security= Considerations that hashed passwords are not supported, because the omissio= n is likely to be surprising to some readers. Yes, please do update this in this draft or include the warning. Thanks, Kathleen >=20 > Thanks, > Brian=20 >=20 >>=20 >>>=20 >>> Brian >=20 > --=20 > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 From nobody Thu May 7 04:01:20 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2861B1A1BB1 for ; Thu, 7 May 2015 04:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq75aPh0fRax for ; Thu, 7 May 2015 04:01:17 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9901A1EED for ; Thu, 7 May 2015 04:01:12 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t47B19YL010592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 May 2015 14:01:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t47B19hN029252; Thu, 7 May 2015 14:01:09 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21835.17909.792856.453646@fireball.kivinen.iki.fi> Date: Thu, 7 May 2015 14:01:09 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 11:01:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Jeffrey Hutzelman is next in the rotation. For telechat 2015-05-14 Reviewer LC end Draft John Bradley T 2015-05-13 draft-jimenez-p2psip-coap-reload-08 Shaun Cooley T 2015-05-05 draft-ietf-appsawg-rfc7001bis-08 Shawn Emery T 2015-05-01 draft-ietf-manet-tlv-naming-01 Daniel Kahn Gillmor T 2015-04-30 draft-ietf-rtgwg-mofrr-06 Sam Hartman T 2015-05-13 draft-ietf-straw-b2bua-stun-05 Radia Perlman TR2015-04-13 draft-ietf-tls-session-hash-05 Tina TSOU T 2015-05-05 draft-hallambaker-tlsfeature-09 David Waltermire T 2015-04-20 draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 Sam Weiler T 2015-04-20 draft-ietf-scim-api-17 For telechat 2015-05-28 Dave Cridland T 2015-05-06 draft-ietf-dhc-dynamic-shared-v4allocation-06 Phillip Hallam-Baker T 2015-05-15 draft-ietf-manet-olsrv2-multitopology-05 Sean Turner T 2015-04-20 draft-ietf-bmwg-traffic-management-04 Last calls and special requests: Alan DeKok 2015-05-01 draft-ietf-dprive-problem-statement-04 Donald Eastlake 2015-05-04 draft-ietf-ipsecme-ikev2-null-auth-06 Tobias Gondrom 2015-05-07 draft-ietf-dane-smtp-with-dane-16 Olafur Gudmundsson 2015-05-14 draft-ietf-kitten-sasl-oauth-22 Steve Hanna 2015-05-15 draft-ietf-rtcweb-stun-consent-freshness-12 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-15 Dan Harkins 2015-05-15 draft-ietf-siprec-protocol-16 Paul Hoffman 2015-05-18 draft-ietf-avtext-rtp-grouping-taxonomy-06 Christian Huitema 2015-05-18 draft-ietf-opsawg-vmm-mib-02 Eric Osterweil 2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01 Vincent Roca 2015-04-24 draft-hansen-scram-sha256-02 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Klaas Wierenga 2015-04-17 draft-ietf-tls-negotiated-ff-dhe-08 Dacheng Zhang 2015-04-28 draft-ietf-lisp-eid-block-mgmnt-04 -- kivinen@iki.fi From nobody Thu May 7 06:17:43 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21EE1A8AD1; Thu, 7 May 2015 06:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNsm8N3bexKS; Thu, 7 May 2015 06:17:38 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C8C1A6EDA; Thu, 7 May 2015 06:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1064; q=dns/txt; s=iport; t=1431004659; x=1432214259; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2GxEvgWJLil0HQRAkRGxHrrTjR1R67bUm5ven1hFR2A=; b=Wu1H08kfHjlbnj21ztxMDUltHNYB55/8SDWNm1O3MFyiYj2QdEe6sMNg 5ZoycXZZpqRZYr9bje4bjPgH+sgXa6tAL2lidElopA0fQ2H96/C8qPvWB peO1x8JHkncyGB/uCOOtAUoiau3Z5VTMJyHHkxSz3CT43N1zIKNxGI3ss k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEBgB/ZUtV/40NJK1TCYMMgTiDGMFZiGiBE0wBAQEBAQGBC4QnIxFXASICJgIEMBUSBAGIPrJukywBAQEBAQEBAwEBAQEBARyBIYoYhCmDSy+BFgWSKIpYljkjg3aCM4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,384,1427760000"; d="scan'208";a="417778614" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP; 07 May 2015 13:17:38 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t47DHbN6013649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 13:17:37 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.13]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 7 May 2015 08:17:37 -0500 From: "Klaas Wierenga (kwiereng)" To: "draft-ietf-tls-negotiated-ff-dhe.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: review of draft-ietf-tls-negotiated-ff-dhe-08 Thread-Index: AQHQiMgvmSULQh6VmEaMnu41Pd07zA== Date: Thu, 7 May 2015 13:17:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.97.85] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [secdir] review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 13:17:39 -0000 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3MgDQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgDQpJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIA0Kc2VjdXJpdHkgYXJl YSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 IA0KdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMu DQoNClRoaXMgZG9jdW1lbnQgbW9kaWZpZXMgVExTIHRvIHVzZSBhIHNlY3Rpb24gb2YgdGhlIOKA nEVDIE5hbWVkIEN1cnZlc+KAnSByZWdpc3RyeSB0byBhZHZlcnRpc2Ugc3VwcG9ydCBmb3IgY29t bW9uIEZpbml0ZSBGaWVsZCBEaWZmaWUgSGVsbG1hbiBncm91cCBwYXJhbWV0ZXJzLg0KDQpJIGJl bGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4NCg0KVGhlIGRvY3Vt ZW50IGlzIGNsZWFyIGFuZCBJIGJlbGlldmUgdGhlIGFwcHJvYWNoIG1ha2VzIHNlbnNlIGFuZCBp cyBwb3RlbnRpYWxseSB2ZXJ5IGhlbHBmdWwgaW4gZXN0YWJsaXNoaW5nIHNlbnNpYmxlIGdyb3Vw IHBhcmFtZXRlcnMuDQoNCg0KLS0NCktsYWFzIFdpZXJlbmdhDQpJZGVudGl0eSBBcmNoaXRlY3QN CkNpc2NvIENsb3VkIFNlcnZpY2VzDQoNCg0KDQoNCg0KDQo= From nobody Thu May 7 12:21:06 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966DB1A87CE for ; Thu, 7 May 2015 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4g_30qnsu-5 for ; Thu, 7 May 2015 12:21:05 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDEA1A8825 for ; Thu, 7 May 2015 12:21:04 -0700 (PDT) Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t47JL3n9039365 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 May 2015 12:21:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <00643634-4707-4952-8879-BBF3AAFABFF2@vpnc.org> Date: Thu, 7 May 2015 12:21:03 -0700 To: secdir Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [secdir] Secdir review of draft-ietf-avtext-rtp-grouping-taxonomy X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 19:21:05 -0000 Summary: great document, no new security issues introduced. The title of the document is "A Taxonomy of Grouping Semantics and = Mechanisms for Real-Time Transport Protocol (RTP) Sources", and that = covers the content exactly. The Security Considerations section says: 5. Security Considerations This document simply tries to clarify the confusion prevalent in RTP taxonomy because of inconsistent usage by multiple technologies and protocols making use of the RTP protocol. It does not introduce any new security considerations beyond those already well documented in the RTP protocol [RFC3550] and each of the many respective specifications of the various protocols making use of it. Hopefully having a well-defined common terminology and understanding of the complexities of the RTP architecture will help lead us to better standards, avoiding security problems. That covers it completely. Unrelated: if you ever wanted a high-level overview of RTP, this = document is a great place to start. Instead of introducing RTP as a = technology, it introduces it in an "who says what to whom" fashion, = which is enough to get a pretty clear picture. --Paul Hoffman= From nobody Fri May 8 05:24:17 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1707F1B2ABC for ; Fri, 8 May 2015 05:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIbbiP8LOLEe for ; Fri, 8 May 2015 05:24:14 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4741B2AB9 for ; Fri, 8 May 2015 05:24:13 -0700 (PDT) Received: from [95.209.27.162] (95.209.27.162.bredband.tre.se [95.209.27.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1AF8A1800A76; Fri, 8 May 2015 14:24:12 +0200 (CEST) Message-ID: <554CAAE8.9090800@pi.nu> Date: Fri, 08 May 2015 14:24:08 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: secdir , "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 12:24:16 -0000 Security Directorate, Apologies if I'm sending this too wide! The MPLS wg has a review team. The task of the review team is to support the wg chair, in particular when we are considering a wg adoption poll. Before starting a wg adoption poll we run all documents through the MPLS-RT review (you can find a typical invite to such a review below). Just now we have draft-farrelll-mpls-opportunistic-encrypt in MPLS-RT review. We have enough reviewers accepting to do the review, but all of them have flagged that they are not entirely comfortable reviwing the document from a security perspective. Stephen have very graciously offered to help if there are question. I still would like to ask if it possible to find an expert reviewer in the security directorate. Questions asked are the same as you find in the invite below. Please contact me if you are willing to review the document for us. /Loa mpls wg co-chair -----------example of mpls-rt review invite ----------------------- Dave, Mach, Lizhong and Kamran, You have be selected as MPLS-RT reviewers for draft-farrelll-mpls-opportunistic-encrypt. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Note to the reviewers: I understand that this document is very much on the "security side of the house", however I will also reach out to the Sec-Dir for a more security biased review. This should not stop you from commenting on security aspects of the draft, but if you feel like it I'm comfortable with a "normal MPLS-RT review", responding to questions below. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control. Are you able to review this draft by May 17, 2015? Please respond in a timely fashion. Thanks, Loa (as MPLS WG chair) /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun May 10 16:15:57 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69A11AC438 for ; Sun, 10 May 2015 16:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIKmLieq0Tqg for ; Sun, 10 May 2015 16:15:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6E51AC432 for ; Sun, 10 May 2015 16:15:54 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4ANFq4Y018160 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 May 2015 23:15:53 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4ANFqhK010306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 May 2015 23:15:52 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4ANFpvA014186; Sun, 10 May 2015 23:15:52 GMT Received: from [10.159.114.29] (/10.159.114.29) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 10 May 2015 16:15:51 -0700 Message-ID: <554FE6F0.7000908@oracle.com> Date: Sun, 10 May 2015 17:17:04 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20150418 Thunderbird/17.0.11 MIME-Version: 1.0 To: secdir@ietf.org References: <54EAD095.2000200@oracle.com> In-Reply-To: <54EAD095.2000200@oracle.com> X-Forwarded-Message-Id: <54EAD095.2000200@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: draft-ietf-manet-tlv-naming.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-manet-tlv-naming-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 23:15:56 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft provides nomenclature of types and type extensions used by Mobile Ad hoc Networking's (MANET) Packet, Message, and Address Blocks. The draft also specifies a corresponding IANA registry for these types. The security considerations section does exist and discloses that the draft does not impose any security considerations in itself. I agree with this assertion. General comments: None. Editorial comments: s/consisteng/consistent/ Shawn. -- From nobody Mon May 11 13:42:37 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258BE1A9031; Mon, 11 May 2015 13:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4yz69rgfZJW; Mon, 11 May 2015 13:42:32 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8121A7035; Mon, 11 May 2015 13:42:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id CF85C206F9; Mon, 11 May 2015 16:41:03 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iXT1Tf_8uhk; Mon, 11 May 2015 16:41:03 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [62.232.113.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 11 May 2015 16:41:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AA0C887E77; Mon, 11 May 2015 16:42:21 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org,ietf@ietf.org Date: Mon, 11 May 2015 16:42:21 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [secdir] secdir review of draft-ietf-straw-b2bua-stun-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 20:42:34 -0000 I've been selected as the secdir reviewer for this draft. These comments are intended for the security ADs (and other ADs); authors please treat them as any other last call comments. I have one major issue. This draft is sufficiently unclear in its introductory material that I found it very challenging to review. What it's trying to do is to specify behavior for handling of ICE by B2BUAs. However, the introduction never says that; the introduction talks a lot about the background for B2BUAS, ICE, STUN and related parts of the SIP infrastructure. Coming back to reading SIP documents after a number of years, the bibliography provided in the introduction was useful, but the introduction needs to describe what this document does. The abstract sort of tries to describe what the document does. However, our process requires that the document and abstract stand independent of each other. The reader cannot be expected to read the abstract before reading the document. Also, the abstract claims that this document specifies the handling of STUN messages inside ICE. Section 3 and 4 actually provide requirements for handilg of SDP attributes, ICE processing and other things far beyond handling of STUN messages. My recommendation for addressing this issue is: 1) Update the abstract to make it clear that this is overall requirements for B2BUAs interacting with ICE, not just requirements for handling STUN messages. 2) Make sure everything the abstract says is near the front of the introduction. After introducing what STUN, ICE, and B2BUAs are, it's important to explain the role of this document. Once I understood what this document was trying to do I was able to think about the security implications. There really don't seem to be any new security implications with this document. The security considerations section is fairly lite, but the introduction does point to the existing discussions of security of ICE and B2BUAs and various latching techniques. I don't think this protocol introduces or even really changes the security landscape. It gives guidance which if followed will mean that good actors don't break the security mechansisms. That is valuable because if the frequency of good actors breaking security mechanisms is low enough, we can actually rely on the security mechanisms. So, I think the security considerations section is fine as-is, although the security ADs may wish to ask for a couple of references to be copied from the introduction. From nobody Tue May 12 19:13:38 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F6E1A9039; Tue, 12 May 2015 19:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-omHnmZkLcj; Tue, 12 May 2015 19:13:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A47B1A9006; Tue, 12 May 2015 19:13:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVY95700; Wed, 13 May 2015 02:13:27 +0000 (GMT) Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 03:13:26 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0158.001; Wed, 13 May 2015 10:13:19 +0800 From: Tina TSOU To: The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-hallambaker-tlsfeature-09 Thread-Index: AQHQjSJgcDug1ZCtTEeq/KRqufv8Kg== Date: Wed, 13 May 2015 02:13:18 +0000 Message-ID: References: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> In-Reply-To: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.87.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-hallambaker-tlsfeature.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-hallambaker-tlsfeature-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 02:13:35 -0000 Dear all, =20 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. In the intro, you refer to a number of attacks against TLS. Please provide = references. Section 1 and 2: > In order to avoid the confusion that would occur in attempting to=20 > describe an X.509 extension describing the use of TLS extensions, in=20 > this document the term 'extension' is reserved to refer to X.509v3=20 > extensions and the term 'feature' is used to refer to a TLS=20 > extension. >=20 > 2. Purpose >=20 > The purpose of the TLS feature extension is to prevent downgrade=20 > attacks that are not otherwise prevented by the TLS protocol. You should probably clarify in the terminology section what you mean by "TL= S feature extension". Section 3.3.1: > A CA SHOULD NOT issue certs with a TLS feature extension unless there > is an affirma Please expand the acronym. Thank you, Tina From nobody Wed May 13 03:32:47 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F82C1B2AB5; Wed, 13 May 2015 03:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RQZ9jZAnr8s; Wed, 13 May 2015 03:32:44 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89551B2AB6; Wed, 13 May 2015 03:32:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,420,1427752800"; d="asc'?scan'208,217";a="118493947" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2015 12:32:41 +0200 From: Vincent Roca X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_4A281209-FCE8-4E59-A4DE-6B37F134C1C1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 13 May 2015 12:32:40 +0200 Message-Id: <8B34786B-0A64-4566-BC35-12813DECE910@inria.fr> To: IESG , secdir@ietf.org, draft-hansen-scram-sha256@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [secdir] Secdir review of draft-hansen-scram-sha256-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 10:32:46 -0000 --Apple-Mail=_4A281209-FCE8-4E59-A4DE-6B37F134C1C1 Content-Type: multipart/alternative; boundary="Apple-Mail=_B061B991-D13A-4877-A5B4-C4C01056A9B0" --Apple-Mail=_B061B991-D13A-4877-A5B4-C4C01056A9B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have reviewed this document as part of the security directorate=E2=80=99= s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments = just like any other last call comments. Summary: ready with minor issues This document records the SHA-256 variants of SCRAM SASL mechanisms. As it complements RFC 5802, the authors refer to its security section: "The security considerations from [RFC5802] still apply." I have no objection as RFC 5802 security section seems well documented (I'm not an expert of the domain however). That being said, I have two comments: - there is no mention of the motivation for moving from SHA-1 to = SHA-256. I think the security section is a nice place for that, and the authors = can easily refer to RFC 4270 and RFC 6194 (there may be other references too that I=E2=80=99m not aware of). - RFC 2119 is missing from the Normative References. Please add it. [R2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. I also think that RFC 4422 should be moved to the Normative References as it is a mandatory to read reference for the present document. Cheers, Vincent --Apple-Mail=_B061B991-D13A-4877-A5B4-C4C01056A9B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I have reviewed this = document as part of the security directorate=E2=80=99s ongoing
effort to review all IETF documents being processed by the = IESG. These
comments were written primarily for the = benefit of the security area
directors.  Document = editors and WG chairs should treat these comments just
like = any other last call comments.


Summary: ready with minor issues


This document records = the SHA-256 variants of SCRAM SASL mechanisms.
As it complements RFC = 5802, the authors refer to its security section:
   "The = security considerations from [RFC5802] still apply."

I have no = objection as RFC 5802 security section seems well documented
(I'm not an expert of = the domain however).

That being said, I have two comments:

- there is no = mention of the motivation for moving from SHA-1 to SHA-256.
  I think the = security section is a nice place for that, and the authors can = easily
  refer = to RFC 4270 and RFC 6194 (there may be other references too = that
  I=E2=80=99m = not aware of).

- RFC 2119 is missing from the Normative References. Please = add it.
  =  [R2119]  Bradner, S., "Key words for use in RFCs to = Indicate
    =         Requirement Levels", BCP 14, RFC 2119, March = 1997.
  I also = think that RFC 4422 should be moved to the Normative = References
  as it = is a mandatory to read reference for the present document.


Cheers,

  = Vincent
= --Apple-Mail=_B061B991-D13A-4877-A5B4-C4C01056A9B0-- --Apple-Mail=_4A281209-FCE8-4E59-A4DE-6B37F134C1C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIbBAEBCgAGBQJVUyhIAAoJEHBYw8t72N4rM7EP9Rr6Cdkr3zg+9lRKNNNO1bnX xSKW6dDGn/+IduRbkegm+M9t+7soqgVxYDHCjFMB/HEo86X/tl7sjUXMG/Rkk7Xw 5k6Y+To54igkTGZsUUWUzbza/Pmf/iP8V+YGWqFsfTQqGyDOQ7ghCjiKouJnrxJA pVB0RQXKjkGh/9fhwZhrtMm8fzzvmFAhZTUp6zDke9uRg6tBb8hFXjxjjLcHqqcM 3XTFndRC7MXIiSCPPcUtmNSAjfbkaJ6X96vF73ODTd/+K5Mwuvp0nJzpy2JGlFw4 cPnv1jBeDt0fvynQOHHumL8Pki9WFOL/59m91COUylDeqfP8Z9oP+Jf642On2n6d BPYkdFReRQulYndFQ6K00QF9K875CFuzhtGctE4y4jofm+3UXldbIVoNVOAYQfOK md8QCZBsTX69ABheaHK/UOM12XMk9FeObn660IPxPWuD9gJPNKzFq1e/oJiFMcTQ HjTugiTnIXtc6X7Gd1XPyTYa9duHWb8UvfHpwT0MpWVLu/XE3vy+n99gQojpst0I tf49XUbpUEDux27SGVwtEjKoDsIktqBjufFL/EfMMdsvRzsNU3goTsleDZdaC4u5 5mlS+AOo9vjF7FfoTL613nq314YfGDOYtKKbFkBthrYaGbAE16VouIGUOUhCILVr 6l2B0VK39HNlmpOPm9c= =vERq -----END PGP SIGNATURE----- --Apple-Mail=_4A281209-FCE8-4E59-A4DE-6B37F134C1C1-- From nobody Wed May 13 19:49:18 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB8B1A90A9 for ; Wed, 13 May 2015 19:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoBAdVC8xvrH for ; Wed, 13 May 2015 19:49:14 -0700 (PDT) Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2D01ACF1A for ; Wed, 13 May 2015 19:49:13 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1YsjCx-0005Qx-6y for secdir@ietf.org; Wed, 13 May 2015 22:49:11 -0400 Received: (qmail 28329 invoked from network); 14 May 2015 02:49:10 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[72.235.170.243]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 May 2015 02:49:09 -0000 From: "Christian Huitema" To: "'The IESG'" , Date: Wed, 13 May 2015 19:49:05 -0700 Message-ID: <00bb01d08df0$8d92f3f0$a8b8dbd0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdCN7doYjrDBgdzuTDO0+ECXL1vNSA== Content-Language: en-us Archived-At: Cc: draft-ietf-opsawg-vmm-mib.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 02:49:15 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments = just like any other last call comments. For the security area directions, I consider this document to be "Ready = with nits=94. This document specifies objects (MIB) for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor) using SNMP. The security section is thoroughly written, points out the operational = risk if some management variables can be SET, and the privacy or other = security risks if hostile parties can read some of the objects. The essential recommendation is to use SNMPv3 strong security, or when that strong security is not available, to disable the "SET" capabilities.=20 There is an aggravating factor not mentioned in the security section. In many large data centers, some virtual machines will not be under the = direct control of the data center manager. They may have been rented to third parties, or they may have been subverted. These potentially hostile = virtual machines will have direct network connectivity with the hypervisor, and potentially with other hypervisors in the same subnet. Attackers in = control of these machines can gain advantage of even read-only access to = hypervisor state variables. One wonders whether even GET access should be allowed = in the absence of authentication through SNMPv3. Attempting to support even = GET operations with prior versions of SNMP appears risky. -- Christian Huitema From nobody Thu May 14 23:08:56 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91501A9134 for ; Thu, 14 May 2015 23:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nLSOuyz7dMn for ; Thu, 14 May 2015 23:08:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C961A9133 for ; Thu, 14 May 2015 23:08:52 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t4F68nsw015756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 May 2015 09:08:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t4F68nLI015463; Fri, 15 May 2015 09:08:49 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21845.36209.140088.843373@fireball.kivinen.iki.fi> Date: Fri, 15 May 2015 09:08:49 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 06:08:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Scott Kelly is next in the rotation. For telechat 2015-05-28 Reviewer LC end Draft Dave Cridland T 2015-05-06 draft-ietf-dhc-dynamic-shared-v4allocation-07 Donald Eastlake T 2015-05-04 draft-ietf-ipsecme-ikev2-null-auth-06 Phillip Hallam-Baker T 2015-05-15 draft-ietf-manet-olsrv2-multitopology-05 Steve Hanna T 2015-05-15 draft-ietf-rtcweb-stun-consent-freshness-13 Dan Harkins T 2015-05-15 draft-ietf-siprec-protocol-16 Jeffrey Hutzelman T 2015-05-28 draft-ietf-rtcweb-video-05 Chris Inacio T 2015-05-28 draft-ietf-rtcweb-rtp-usage-23 Simon Josefsson T 2015-05-25 draft-ietf-sfc-architecture-08 Sean Turner T 2015-04-20 draft-ietf-bmwg-traffic-management-04 Last calls and special requests: Alan DeKok 2015-05-01 draft-ietf-dprive-problem-statement-04 Tobias Gondrom 2015-05-07 draft-ietf-dane-smtp-with-dane-16 Olafur Gudmundsson 2015-05-14 draft-ietf-kitten-sasl-oauth-22 Leif Johansson 2015-05-25 draft-ietf-mip4-multiple-tunnel-support-12 Benjamin Kaduk 2015-05-22 draft-ietf-tcpm-newcwv-10 Charlie Kaufman E None draft-farrelll-mpls-opportunistic-encrypt-04 Eric Osterweil 2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Dacheng Zhang 2015-04-28 draft-ietf-lisp-eid-block-mgmnt-04 -- kivinen@iki.fi From nobody Sat May 16 08:37:46 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE18C1ACD6A for ; Mon, 4 May 2015 11:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7Wq7JLeVFEn for ; Mon, 4 May 2015 11:45:04 -0700 (PDT) Received: from nm27-vm3.bullet.mail.ne1.yahoo.com (nm27-vm3.bullet.mail.ne1.yahoo.com [98.138.91.157]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9530A1ACD63 for ; Mon, 4 May 2015 11:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430765103; bh=oiufstf85ZhNIyDhVhFBDvxh8D40CMtrAcCGbhayhPc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=U2B3uj2r55tqLgbSyLZ5JLB/zGvuVL1CfRQ9tjykTw8bBxCyUGC0NU+tCAM5FsjzNlKSpem7H4F5JzMQZpvSbXVSXd3ttaGPMTz7KSSm6Wj/RLdv1TntxFm4h3SQ73rS5a11nJZRYyxQ3eYyG1bxtSucyBm2UM1O1uK01GusedeacJqHkvkHkCYwh10qmgxu7jqjN4rUNj09XU6OSYZF6I2KGShrkuQINuhW9huRuCRp856QhdMYTulclITBOz33lUJ++KQacj5OzxWKiehwtbLY9srghXcIQo5FTxrIJij73N+HN1nNlnZe3ASwlzs1b0FgzRytXFCWhrrgDxap3w== Received: from [98.138.100.103] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 04 May 2015 18:45:03 -0000 Received: from [98.138.84.41] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 04 May 2015 18:45:03 -0000 Received: from [127.0.0.1] by smtp109.mail.ne1.yahoo.com with NNFMP; 04 May 2015 18:45:03 -0000 X-Yahoo-Newman-Id: 604768.92249.bm@smtp109.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: yqnfmEAVM1lcQLc5YDpEeDjUNdU45kp6wO23ms6S45EJBF0 8cltBkC6j4Vb6ZLPbmipnfbQhIsx0qU01C_nfmt75j.MI5eBHz1XjfpcI6TF O9L5osGvweh4N6F3grgxnzF4Mf5u8lcudwQJ.FtQTLqUH97H7tI_83AzTZxN nIbkTrAlsJL3PoiDxgWq7AGF_7NKil4nRpS0ijUsIfzkaFkFmJQ2G4C0Tohi agHTfOWg7a4H8LtihnM_t40URlok8bkO36UzWWwMTlblKfmjGKpFD9lDeHdW vt6_Id6Hmh_GCJ4bVGUGOryINVEEngx9RGcXn.440Svf6vHDKjHjp_13BC_L Cd2OEgf0GObLgyHsly8g1_34L8bf4gSYZlff8tjKepNBSowvYR6ew_he5pXg pnBgPWG0k1Qw_HNHyWyeQ56.JfJj9YAYzdtg0Ieq5_Z0Ki.vlR4XdibYEOLg I6sWojkbMQzMzXeHERhJ6xxpGvIBQbLaSvfT_r9oJk3NgX6yCmjzOLmUr52O lCq1__.A6k3nPLVBQzelEaw-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> Date: Mon, 4 May 2015 11:45:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <53991217-3DC8-4A97-9FCC-93B632D3C878@yahoo.com> References: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> To: "Brian Weis (bew)" X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Sat, 16 May 2015 08:37:45 -0700 Cc: "draft-ietf-scim-core-schema.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-scim-core-schema-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 18:45:05 -0000 Brian, Thanks for taking time to review both the recent documents. My proposed = corrections inline=85 Phil phil.hunt@yahoo.com > On May 4, 2015, at 10:39 AM, Brian Weis (bew) wrote: >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > For the security area directions, I consider this document to be = "Ready with nits=94. >=20 > This document documents resources a JSON scheme for Cross-Domain = Identity Management, a standard definition of attributes representing = users and groups, and a set of named schemas incorporating these = attributes. The goal of the document is to make identity management in = cloud based applications and services easier. This is used when identity = information needs to be shared between services. >=20 > The Security Considerations (Section 9) in version 18 is reasonably = clear in the first two sub-sections that there are risks to sensitive = information defined in the schema, these sub-sections point to helpful = text in draft-ietf-scim. It is much improved over version 17. I have a = couple of comments suggesting clarification be added to the document. >=20 > Section 9.3 begins by stating the schema =93defines attributes that = MAY contain personally identifiable information as well as other = sensitive data=94. I don=92t understand the =93MAY=94. Just about every = attribute described in this document is arguably personally identifiable = information (PII), since transporting PII between services seems to be = the actual need for development of the schema. It seems more accurate to = say =93defines attributes that contain personally identifiable = information as well as other sensitive data=94. (Also =93MAY=94 is = intended to declare a part of the standard that is optional for an = implementation, and I don=92t see how that could apply here.) You are right. The 2119 MAY is probably not appropriate. How about=20 =93defines attributes that are sensitive and may be considered = personally identifiable information(PII).=94 I think that inverts the emphasis getting people to realize that almost = all data is likely at least sensitive.=20 >=20 > Section 4.1.1 defines the =93password=94 attribute as a =93clear text = password=94. It is much safer to store and pass a salted and hashed = password. Do none of the services using this schema support a method of = hashing a user password to see if it matches a given hashed value ? Or = could this be an option in the scheme definition? If so, it would be = worth describing that here and in the Security Considerations section. This may be a question of document structure. We could copy/move the = salting/hashing requirements to the schema definition. However, my = thinking was the salting/hashing is not part of the protocol - thus = should not be in the core spec sections. My thinking was that = salting/hashing is really a security consideration for the implementer = since it is a practical consideration of =93using" the protocol. I=92m not sure what you mean by =93pass a salted and hashed password=94 = (may be I am mis-reading your intent). That would seem to be something = to say must not be done since it implies multiple servers having a = common salt/hash. In LDAP, even replication passes the clear text but = the servers only store replica unique salted hashes. >=20 > Brian >=20 >=20 From nobody Sat May 16 08:37:49 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3EE1B2E88 for ; Mon, 4 May 2015 23:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1OF0B4GzIhB for ; Mon, 4 May 2015 23:35:58 -0700 (PDT) Received: from nm23-vm0.bullet.mail.ne1.yahoo.com (nm23-vm0.bullet.mail.ne1.yahoo.com [98.138.91.57]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110691B2E85 for ; Mon, 4 May 2015 23:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430807757; bh=Ot9MGkI7lBqPoncHM4jKXr458WEHDD9MKwlvMIsZmMo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=IOg1+lx0KSrg7DiomzXU4Keyjdkec2RMJ6SHKE7eaDCEVEMC4IwX7e5iS0ULqbPhMmO6ew0jyaj/wk5QuJDT74D2bCh2yt7uWAK5xedTKcnlIxEkLFHAahUqlhsUp/hdHjU11KEqjTXk26PldWTYBMxHvtbmYfg7q6d7d7Bsqkwlzvge3WO1o6tCMg90qcAbue+FM+aWs20uXBCHOMB7Dgw3v6sce8jFdzQ06W42VRt4oeb3RgV68n5MR8f7qXhJMal6vbhTOkvvZXXJ5zv0uw0XO1ANiQiKXUdrfr+VwfoId4aGRUFdIhNFPhf0AOYb1IbpxWoy8AAU9Vo+bUZ47w== Received: from [98.138.100.111] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 05 May 2015 06:35:57 -0000 Received: from [98.138.84.41] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 05 May 2015 06:35:57 -0000 Received: from [127.0.0.1] by smtp109.mail.ne1.yahoo.com with NNFMP; 05 May 2015 06:35:57 -0000 X-Yahoo-Newman-Id: 219295.75728.bm@smtp109.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6Rq62V8VM1mlmA.uGKs4CsrJsj8eerdBSj9UBEuFFngq_J1 8dzNFkedXmyPjVLrpydI7eFQK3uZMRVQwi.7IPCXC9wK6kliWJfvPVFCNU12 8bkmDv1GnnCXmPAmVqXh52W.igSpznB1V9ovtbWqbuMjTtNW_ri6zUpIY9eO qp17upwFCM2kBhsmMxju4VQiIs.C6KvHmgPBrFpeXKrTWENpGii8z0IRpDv_ ev1Ey88Grl8psiDjPnQZGptgD2mpGR9bcEFw4BVzIC4811iES5MieJpj8qVV x3er8feyRgnYsFlFUJAcsQO3lHm9o7DCMvFWenBhj6W2LozEup1D_LBqtDCp hkLKDjrgUCwViMCYJ4slp.ZOS_UNyINJYprleuhPpv80KGFdLwjHsGIJmxy2 WR8l0HpPIxNjsZyWC06O5GJzPbp7iItqvlV.nxMuMTSP.HdZWiSzMqOMFNQr O3K0_wrWh2GPVik7r2UCR5XNgH5.RnWxf7VTHnWdPC96FBLb5hWR4yGHOR2s IPxS0w4CcY3hImXW1WRIr9A-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <5D457571-55CA-45D4-A9F4-9F1B8C96E6B4@cisco.com> Date: Mon, 4 May 2015 23:35:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> <53991217-3DC8-4A97-9FCC-93B632D3C878@yahoo.com> <5D457571-55CA-45D4-A9F4-9F1B8C96E6B4@cisco.com> To: "Brian Weis (bew)" X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Sat, 16 May 2015 08:37:45 -0700 Cc: "draft-ietf-scim-core-schema.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-scim-core-schema-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 06:35:59 -0000 Brian, I think we may be talking about different things. Maybe there is some = confusion on the role of provisioning vs. authentication or maybe = protocol vs. storage? If a client were to pre salt/hash a password (supposedly to protect it = in transit) then the service provider and client would have to agree on = a salt and hash. This decreases security dramatically since multiple = domain now have the same hashed values. =20 The intent is that every service provider endpoint that gets a = clear-text password, generates its own unique salted hash and stores = that value. Phil phil.hunt@yahoo.com > On May 4, 2015, at 12:26 PM, Brian Weis (bew) wrote: >=20 > Hi Phil, >=20 > On May 4, 2015, at 11:45 AM, Phil Hunt wrote: >=20 >> Brian, >>=20 >> Thanks for taking time to review both the recent documents. My = proposed corrections inline=85 >>=20 >> Phil >>=20 >> phil.hunt@yahoo.com >>=20 >>> On May 4, 2015, at 10:39 AM, Brian Weis (bew) wrote: >>>=20 >>> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>>=20 >>> For the security area directions, I consider this document to be = "Ready with nits=94. >>>=20 >>> This document documents resources a JSON scheme for Cross-Domain = Identity Management, a standard definition of attributes representing = users and groups, and a set of named schemas incorporating these = attributes. The goal of the document is to make identity management in = cloud based applications and services easier. This is used when identity = information needs to be shared between services. >>>=20 >>> The Security Considerations (Section 9) in version 18 is reasonably = clear in the first two sub-sections that there are risks to sensitive = information defined in the schema, these sub-sections point to helpful = text in draft-ietf-scim. It is much improved over version 17. I have a = couple of comments suggesting clarification be added to the document. >>>=20 >>> Section 9.3 begins by stating the schema =93defines attributes that = MAY contain personally identifiable information as well as other = sensitive data=94. I don=92t understand the =93MAY=94. Just about every = attribute described in this document is arguably personally identifiable = information (PII), since transporting PII between services seems to be = the actual need for development of the schema. It seems more accurate to = say =93defines attributes that contain personally identifiable = information as well as other sensitive data=94. (Also =93MAY=94 is = intended to declare a part of the standard that is optional for an = implementation, and I don=92t see how that could apply here.) >> You are right. The 2119 MAY is probably not appropriate. How about=20 >> =93defines attributes that are sensitive and may be considered = personally identifiable information(PII).=94 >>=20 >> I think that inverts the emphasis getting people to realize that = almost all data is likely at least sensitive.=20 >=20 > That=92s a fine way to state it, thanks. >=20 >>>=20 >>> Section 4.1.1 defines the =93password=94 attribute as a =93clear = text password=94. It is much safer to store and pass a salted and hashed = password. Do none of the services using this schema support a method of = hashing a user password to see if it matches a given hashed value ? Or = could this be an option in the scheme definition? If so, it would be = worth describing that here and in the Security Considerations section. >>=20 >> This may be a question of document structure. We could copy/move the = salting/hashing requirements to the schema definition. However, my = thinking was the salting/hashing is not part of the protocol - thus = should not be in the core spec sections. My thinking was that = salting/hashing is really a security consideration for the implementer = since it is a practical consideration of =93using" the protocol. >>=20 >> I=92m not sure what you mean by =93pass a salted and hashed password=94= (may be I am mis-reading your intent). That would seem to be something = to say must not be done since it implies multiple servers having a = common salt/hash. In LDAP, even replication passes the clear text but = the servers only store replica unique salted hashes. >=20 > The distinction I=92m making is the difference between a clear text = password (e.g., "t1meMa$heen=94) and a hashed version of the password, = which although still sensitive is considered to be safer. My hope would = be for the schema to represent both forms of passwords, because it = would be a significant improvement in security. If this is the case, = then it would be good to describe the use of the hashed password = wherever you feel makes the most sense. If this is not the case, it = would be worth mentioning in Security Considerations that hashed = passwords are not supported, because the omission is likely to be = surprising to some readers. >=20 > Thanks, > Brian=20 >=20 >>=20 >>>=20 >>> Brian >=20 > --=20 > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 From nobody Sat May 16 08:37:50 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E171A883B; Fri, 15 May 2015 10:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1431710893; bh=cCz9YmtzbwPXtyYmFdfoAN6mC2NH94KKDKMCMOO2Bhg=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Ld7htVp9xaeBNrCyGg3NU2ohmdnJSfdXqG3hj8nMPd0tt77r4KhHG1myt5UuZ2mPl ibbugmnpOO+E5Kf6GzVpNnmaoem/b80LTnAZ3ZtEvWyOX+ZT5qxwrxtu+vTqhWc8/X bV/cezbEPz4R32cj9Otb+hpKVFi+l9qaeh4uG8Pg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70501A883B; Fri, 15 May 2015 10:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To7T0HQhZMbB; Fri, 15 May 2015 10:28:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBDF1A8838; Fri, 15 May 2015 10:28:11 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150515172811.30535.7332.idtracker@ietfa.amsl.com> Date: Fri, 15 May 2015 10:28:11 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 16 May 2015 08:37:45 -0700 Subject: [secdir] [new-work] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 17:28:13 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-05-25. CBOR Object Signing and Encryption (cose) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Kathleen Moriarty Mailing list Address: cose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cose Archive: http://www.ietf.org/mail-archive/web/cose/ Charter: Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary format for the serialization of data structured to an extended version of the JSON data model. COSE seeks to create CBOR-based object signing and encryption formats. One motivation for COSE was to reuse functionality from the JOSE working group using the CBOR data representation as it is more amenable to constrained nodes and constrained node networks (RFC 7228). The JOSE working group recently completed producing representations for cryptographic keys, message authentication (MACs), encryption, and digital signatures, using JSON representation. The resulting formats will not be cryptographically convertible from or to JOSE formats. This lack of a need for bit-for-bit compatibility will enable some simplification in the adaptation process. Criteria that should be considered in the decision making process, changing from JSON to CBOR encoding include: o Maintain the current JOSE paradigms and formatting where feasible. o Minimize message size, code size, and computational complexity to suit constrained environments, where this is expected to be used. o Improve security o Provide new functionality for additional use cases that were not required for JOSE. Key management and binding of keys to identities are out of scope for the working group. The COSE WG will not innovate in terms of cryptography. The specification of algorithms in COSE is limited to those in RFCs or active IETF WG documents. The working group will coordinate its progress with the ACE, DICE and CORE working groups to ensure that we are fulfilling the needs of these constituencies to the extent relevant to their work. Other groups may be added to this list as the set of use cases is expanded. The WG will have two deliverables: 1. A standards-track specification covering the same cryptographic formats from JOSE, with optimizations for constrained device processing, expressed in CBOR; 2. Registration for algorithms (such as AES-CCM-8) that are appropriate for constrained environments. The Working Group will use a wiki to track desired use cases for its work, but does not intend to publish this as an RFC. Milestones: Jun 2015 - Submit COSE specification as a WG item Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item Jan 2016 - Submit COSE specification to the IESG, for publication as a Proposed Standard Jan 2016 - Submit COSE constrained-appropriate algorithms to the IESG, for publication as a Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon May 18 19:16:01 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD5C1B2D30; Mon, 18 May 2015 19:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxDic55N6FwT; Mon, 18 May 2015 19:15:56 -0700 (PDT) Received: from BLU004-OMC4S6.hotmail.com (blu004-omc4s6.hotmail.com [65.55.111.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05971B2D3B; Mon, 18 May 2015 19:15:44 -0700 (PDT) Received: from BLU436-SMTP193 ([65.55.111.137]) by BLU004-OMC4S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 18 May 2015 19:15:44 -0700 X-TMN: [P8BTHNXHztQz0W+1whEGo1B8KxJrtxm4] X-Originating-Email: [zhang_dacheng@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_5BB0B193-0224-403B-A991-C5AF9C61D6E2" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dacheng In-Reply-To: <8B34786B-0A64-4566-BC35-12813DECE910@inria.fr> Date: Tue, 19 May 2015 10:15:26 +0800 References: <8B34786B-0A64-4566-BC35-12813DECE910@inria.fr> To: draft-ietf-lisp-eid-block-mgmnt@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) X-OriginalArrivalTime: 19 May 2015 02:15:42.0597 (UTC) FILETIME=[B518B350:01D091D9] Archived-At: Cc: IESG , secdir@ietf.org Subject: [secdir] Secdir review of draft-ietf-lisp-eid-block-mgmnt-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 02:15:57 -0000 --Apple-Mail=_5BB0B193-0224-403B-A991-C5AF9C61D6E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="GB2312" Hello, I have reviewed this document as part of the security directorate=A1=AFs = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document is informational and proposes a framework for the = management of the LISP EID Prefix. I didn=A1=AFt find any additional security related issues of this work. = I think it is ready for publication. Cheers Dacheng --Apple-Mail=_5BB0B193-0224-403B-A991-C5AF9C61D6E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="GB2312"
Hello,

I have reviewed this document = as part of the security directorate=A1=AFs ongoing effort to review = all IETF documents being processed by the IESG. These comments were = written primarily for the benefit of the security area directors. =  Document editors and WG chairs should treat these comments = just like any other last call comments.

This document is informational =
and proposes a framework for the management of the LISP EID =
Prefix.

I didn=A1=AFt find any additional security = related issues of this work. I think it is ready for = publication.

Cheers

Dacheng




= --Apple-Mail=_5BB0B193-0224-403B-A991-C5AF9C61D6E2-- From nobody Wed May 20 12:13:10 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299961A8A60; Wed, 20 May 2015 12:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sinpD3Any7VN; Wed, 20 May 2015 12:13:04 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5A51A8A9C; Wed, 20 May 2015 12:13:02 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-85-555cdcbd3c8f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id D2.67.03359.DBCDC555; Wed, 20 May 2015 15:13:01 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t4KJD0E0021514; Wed, 20 May 2015 15:13:01 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4KJCwFx009768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 May 2015 15:13:00 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4KJCwqb028138; Wed, 20 May 2015 15:12:58 -0400 (EDT) Date: Wed, 20 May 2015 15:12:58 -0400 (EDT) From: Benjamin Kaduk To: draft-ietf-tcpm-newcwv-all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUixG6nrrv3TkyowZzZZharD69ks5jxZyKz xYeFD1kcmD2WLPnJ5PHl8me2AKYoLpuU1JzMstQifbsErozlS06xF8zSrmi80MjewNin3MXI ySEhYCKxa+JLRghbTOLCvfVsXYxcHEICi5kknnXMYoFwNjJKzJvdDJU5xCTx6fNbqEwDo8TC FR1sIP0sAtoSMxZ+BrPZBFQkGrovM3cxcnCICPhKvFrHCxIWFjCW+DXpAguIzSvgKLHh9wN2 EFtUQEdi9f4pUHFBiZMzn4DZzAJaEsunb2OZwMg3C0lqFpLUAkamVYyyKblVurmJmTnFqcm6 xcmJeXmpRbqGermZJXqpKaWbGEHBxinJs4PxzUGlQ4wCHIxKPLwFB6JDhVgTy4orcw8xSnIw KYnyNt+OCRXiS8pPqcxILM6ILyrNSS0+xCjBwawkwntuPVCONyWxsiq1KB8mJc3BoiTOu+kH X4iQQHpiSWp2ampBahFMVoaDQ0mCtxhkqGBRanpqRVpmTglCmomDE2Q4D9BwfpAa3uKCxNzi zHSI/ClGRSlx3haQhABIIqM0D64XlgxeMYoDvSLMmwVSxQNMJHDdr4AGMwENNtkWCTK4JBEh JdXAyLDWt2HnrASJyEt3VP8JSKouy+RkVLwXnSn5fcGJiibrzF9rmsXLs1z8Ey81H7ypO2fm kfsnZnkYJJ1Z25Ax63/FDr+DZq4HDBeLVi3t4ZmccW6OA+PHjhztH5/MXYWvvjM1Tp7AdkJc /sqeIMPNBavnee/Z8TKPt1gi847ttsNJipVdzsFvlFiKMxINtZiLihMB800rWOECAAA= Archived-At: Subject: [secdir] secdir review of draft-ietf-tcpm-newcwv-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:13:07 -0000 Hi all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document is ready with nits. The security considerations defer to those of RFC 5681 with the claim that this document just describes an algorithm for one aspect of the congestion control procedures and thus that the generic security considerations apply; this claim seems true. The security considerations section of RFC 5681 feels a little bit short, but it does seem to cover the relevant risks, namely that an attacker could make the sender send more slowly or more quickly, with the latter possibly driving the network into congestion collapse. These are issues that protocol designers and implementors must be aware of (and avoiding congestion collapse is more important). The authors seem to have taken sufficient care to avoid this algorithm contributing to congestion collapse, and the concern about an attacker being able to slow down a sender is not really feasible to mitigate at this level, so the security considerations of RFC 5681, short as they are, seem adequate here. One would hope that implementors know that failing to follow the specification could lead to congestion collapse, so an explicit warning is not needed. The nits are basically all grammatical; I'll include them below and expect people other than the document authors/shepherd to stop reading here. -Ben My apologies in advance if I am applying too much of an American English perspective to this document written in British English. In the abstract, "TCP is used to support traffic that [...]", is "support" the best verb to use (as opposed to "transmit", "carry", "transport", etc.)? The first paragraph of the Introduction might have a little more text to clarify how the cwnd differs from the FlightSize, for non-experts such as myself. (The cwnd is how much the sender is permitted to have outstanding/unack'd and the FlightSize is how much the sender actually has outstanding/unack'd?) Just another sentence after the second one, "The FlightSize is how many unacknowledged packets/bytes that are currently outstanding, and the cwnd is the maximum value the sender will allow FlightSize to take on" would be plenty. Introduction, third paragraph, """[CWV] introduced the terminology of "application limited periods". This document describes [...]""" Usually, in an RFC, "this document" refers to the RFC itself, but in this case, "this document" seems to be being used to refer to the other document, RFC 2861. So, the references and text could be made more clear. A couple sentences later, "or by changing the rate the application sends", maybe put an "at which" in there somewhere? Absent context, I would expect "the rate the application sends" to mean that an application protocol was conveying a number which is interpreted as a rate in some fashion. Still in the Introduction, in the summary of the document, paragraph for section 4, maybe s/does this in a way/does so in a way/ ? Also, in the parenthetical at the end of that sentence, I think it reads better as "including both application-limited and idle senders". Still in the introduction, in the "goals of this update" list, first item, do bulk transfers consume the cwnd or fill it? I'm not sure that the fifth item is fully grammatical. Maybe add in an "to send extra traffic" somewhere? In the sixth item, there's a singular/plural mismatch between flows and network (unless it's supposed to be "the network"). Section 2, first paragraph, "the behaviour where a sender transmitted at a rate less than allowed by cwnd", is "where" or "when" better? Section 2, second paragraph, third sentence: I think it should start "While this" instead of just "This". The first comma in this sentence could also be removed, if desired. In section 3 (Terminology), it might be nice to clarify that the listed terms are new to this document, or in addition to the RFC 5681 terms, or something like that. (I.e., "Additionally, the following terminology ...".) Section 4.2, last paragraph, a space is missing after the [RFC6675] citation. In section 4.4: if I understand correctly, the sliding window for pipeAck calculation is smaller than the NVP, so it is not the absolute amount of data which the sender transmits which can push pipeAck over (1/2)*cwnd, but rather the rate at which the data is transmitted. Also in section 4.4, there is some superficial inconsistency between "a sender that enters the non-validated phase SHOULD preserve the cwnd" and the text telling the sender how to reduce cwnd if it encounters congestion and the (outer) bullet point wherein "a sender determines whether to increase the cwnd based on ...". The last paragraph of the section helps clarify the situation, but it might help readability to clarify the exceptions to the SHOULD (and the rationale for them) right after the claim is made. In section 4.4.1, there is a missing space after "recovery" and before the internal reference to Section 4.2. Section 4.5.1, comma after "e.g.". From nobody Wed May 20 12:15:53 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4461A8AC9; Wed, 20 May 2015 12:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa7v6gSqj-D2; Wed, 20 May 2015 12:15:49 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3179F1A8A65; Wed, 20 May 2015 12:15:49 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-10-555cdd63c1db Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 24.FD.03355.46DDC555; Wed, 20 May 2015 15:15:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t4KJFlJg021633; Wed, 20 May 2015 15:15:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4KJFjGM011365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 May 2015 15:15:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4KJFiQI028579; Wed, 20 May 2015 15:15:44 -0400 (EDT) Date: Wed, 20 May 2015 15:15:44 -0400 (EDT) From: Benjamin Kaduk To: draft-ietf-tcpm-newcwv.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUixCmqrJtyNybU4NNcLov3yy8yWsz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8akb91MBU06FS9ebmduYHyo3MXI ySEhYCLRNf8oM4QtJnHh3nq2LkYuDiGBxUwS6141MEM4GxkllsxYzQLhHGKS6OnvZodwGhgl ZrZeBSrj4GAR0JZ4ezkKZBSbgIrEzDcb2UBsEQFfiRt3ulhBbGEBY4lfky6wgNi8Ao4STz9d YgKxRQV0JFbvnwIVF5Q4OfMJmM0soCWxfPo2lgmMfLOQpGYhSS1gZFrFKJuSW6Wbm5iZU5ya rFucnJiXl1qka6yXm1mil5pSuokRHGySfDsYvx5UOsQowMGoxMNbcCA6VIg1say4MvcQoyQH k5Io78HbMaFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjPrQfK8aYkVlalFuXDpKQ5WJTEeTf9 4AsREkhPLEnNTk0tSC2CycpwcChJ8L4BGSpYlJqeWpGWmVOCkGbi4AQZzgM0/D9IDW9xQWJu cWY6RP4Uo6KUOO8/kIQASCKjNA+uF5YMXjGKA70izCtzB6iKB5hI4LpfAQ1mAhpssi0SZHBJ IkJKqoFxemDX9rzEh86z3x+fNF1B6NitNuYQd1H3D0WL+R/e2rt/u5TC+udRK769jupcOeP9 xyquGY7833eKzHu09dNxBcZJsprc+T0dVwtq4/99enc/0+mV7rVzoqLK64UObexm/sWhum+3 gHC+zYLLZr+t6157c72zSNKK2OJwc/IEZiOG2zvdlKdnK7EUZyQaajEXFScCALLIvJDhAgAA Archived-At: Subject: [secdir] secdir review of draft-ietf-tcpm-newcwv-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:15:51 -0000 [resending with the correct spelling of the draft alias. Sorry for the extra copy, everyone else.] Hi all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document is ready with nits. The security considerations defer to those of RFC 5681 with the claim that this document just describes an algorithm for one aspect of the congestion control procedures and thus that the generic security considerations apply; this claim seems true. The security considerations section of RFC 5681 feels a little bit short, but it does seem to cover the relevant risks, namely that an attacker could make the sender send more slowly or more quickly, with the latter possibly driving the network into congestion collapse. These are issues that protocol designers and implementors must be aware of (and avoiding congestion collapse is more important). The authors seem to have taken sufficient care to avoid this algorithm contributing to congestion collapse, and the concern about an attacker being able to slow down a sender is not really feasible to mitigate at this level, so the security considerations of RFC 5681, short as they are, seem adequate here. One would hope that implementors know that failing to follow the specification could lead to congestion collapse, so an explicit warning is not needed. The nits are basically all grammatical; I'll include them below and expect people other than the document authors/shepherd to stop reading here. -Ben My apologies in advance if I am applying too much of an American English perspective to this document written in British English. In the abstract, "TCP is used to support traffic that [...]", is "support" the best verb to use (as opposed to "transmit", "carry", "transport", etc.)? The first paragraph of the Introduction might have a little more text to clarify how the cwnd differs from the FlightSize, for non-experts such as myself. (The cwnd is how much the sender is permitted to have outstanding/unack'd and the FlightSize is how much the sender actually has outstanding/unack'd?) Just another sentence after the second one, "The FlightSize is how many unacknowledged packets/bytes that are currently outstanding, and the cwnd is the maximum value the sender will allow FlightSize to take on" would be plenty. Introduction, third paragraph, """[CWV] introduced the terminology of "application limited periods". This document describes [...]""" Usually, in an RFC, "this document" refers to the RFC itself, but in this case, "this document" seems to be being used to refer to the other document, RFC 2861. So, the references and text could be made more clear. A couple sentences later, "or by changing the rate the application sends", maybe put an "at which" in there somewhere? Absent context, I would expect "the rate the application sends" to mean that an application protocol was conveying a number which is interpreted as a rate in some fashion. Still in the Introduction, in the summary of the document, paragraph for section 4, maybe s/does this in a way/does so in a way/ ? Also, in the parenthetical at the end of that sentence, I think it reads better as "including both application-limited and idle senders". Still in the introduction, in the "goals of this update" list, first item, do bulk transfers consume the cwnd or fill it? I'm not sure that the fifth item is fully grammatical. Maybe add in an "to send extra traffic" somewhere? In the sixth item, there's a singular/plural mismatch between flows and network (unless it's supposed to be "the network"). Section 2, first paragraph, "the behaviour where a sender transmitted at a rate less than allowed by cwnd", is "where" or "when" better? Section 2, second paragraph, third sentence: I think it should start "While this" instead of just "This". The first comma in this sentence could also be removed, if desired. In section 3 (Terminology), it might be nice to clarify that the listed terms are new to this document, or in addition to the RFC 5681 terms, or something like that. (I.e., "Additionally, the following terminology ...".) Section 4.2, last paragraph, a space is missing after the [RFC6675] citation. In section 4.4: if I understand correctly, the sliding window for pipeAck calculation is smaller than the NVP, so it is not the absolute amount of data which the sender transmits which can push pipeAck over (1/2)*cwnd, but rather the rate at which the data is transmitted. Also in section 4.4, there is some superficial inconsistency between "a sender that enters the non-validated phase SHOULD preserve the cwnd" and the text telling the sender how to reduce cwnd if it encounters congestion and the (outer) bullet point wherein "a sender determines whether to increase the cwnd based on ...". The last paragraph of the section helps clarify the situation, but it might help readability to clarify the exceptions to the SHOULD (and the rationale for them) right after the claim is made. In section 4.4.1, there is a missing space after "recovery" and before the internal reference to Section 4.2. Section 4.5.1, comma after "e.g.". From nobody Thu May 21 15:16:11 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC05A1A90DD for ; Thu, 21 May 2015 15:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.269 X-Spam-Level: X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u20x0Y69GKn6 for ; Thu, 21 May 2015 15:16:08 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EE31A90DC for ; Thu, 21 May 2015 15:16:07 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t4LMG5m7018986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 22 May 2015 01:16:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t4LMG5fw025882; Fri, 22 May 2015 01:16:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21854.22821.190504.503869@fireball.kivinen.iki.fi> Date: Fri, 22 May 2015 01:16:05 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:16:09 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Chris Lonvick is next in the rotation. For telechat 2015-05-28 Reviewer LC end Draft Dave Cridland T 2015-05-06 draft-ietf-dhc-dynamic-shared-v4allocation-07 Donald Eastlake T 2015-05-04 draft-ietf-ipsecme-ikev2-null-auth-06 Tobias Gondrom T 2015-05-07 draft-ietf-dane-smtp-with-dane-17 Olafur Gudmundsson T 2015-05-14 draft-ietf-kitten-sasl-oauth-22 Phillip Hallam-Baker T 2015-05-15 draft-ietf-manet-olsrv2-multitopology-05 Steve Hanna T 2015-05-15 draft-ietf-rtcweb-stun-consent-freshness-13 Dan Harkins T 2015-05-15 draft-ietf-siprec-protocol-16 Jeffrey Hutzelman T 2015-06-03 draft-ietf-rtcweb-video-05 Chris Inacio T 2015-05-28 draft-ietf-rtcweb-rtp-usage-23 Simon Josefsson T 2015-05-25 draft-ietf-sfc-architecture-08 Sean Turner T 2015-04-20 draft-ietf-bmwg-traffic-management-04 For telechat 2015-06-11 Scott Kelly T 2015-06-03 draft-ietf-httpbis-tunnel-protocol-04 Last calls and special requests: Alan DeKok 2015-05-01 draft-ietf-dprive-problem-statement-04 Leif Johansson 2015-05-25 draft-ietf-mip4-multiple-tunnel-support-12 Charlie Kaufman E 2015-05-31 draft-farrelll-mpls-opportunistic-encrypt-04 Stephen Kent 2015-06-01 draft-ietf-oauth-introspection-08 Tero Kivinen 2015-06-01 draft-ietf-dime-congestion-flow-attributes-01 Ben Laurie 2015-06-01 draft-ietf-oauth-spop-11 Matt Lepinski 2015-06-03 draft-ietf-xmpp-6122bis-22 Eric Osterweil 2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 -- kivinen@iki.fi From nobody Fri May 22 18:11:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7071A8991; Fri, 22 May 2015 17:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGgcvrFgR1lb; Fri, 22 May 2015 17:01:27 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4641A8848; Fri, 22 May 2015 17:01:26 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 653cf555.0.3299794.00-2242.8842642.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 23 May 2015 00:01:26 +0000 (UTC) X-MXL-Hash: 555fc3561f9e5c9c-48120237f0e6dfbf951bb426afebd543c8d7638b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N00NQ2016960; Fri, 22 May 2015 20:00:24 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N00GFR016901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 May 2015 20:00:17 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Sat, 23 May 2015 00:00:00 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N00073027970; Fri, 22 May 2015 20:00:00 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4MNxt3n027854; Fri, 22 May 2015 19:59:55 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.240.65](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150522235953gw1000cebue>; Fri, 22 May 2015 23:59:54 +0000 X-Originating-IP: [135.110.240.65] Message-ID: <555FC2F6.5070106@att.com> Date: Fri, 22 May 2015 19:59:50 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Vincent Roca , IESG , secdir@ietf.org, draft-hansen-scram-sha256@tools.ietf.org References: <8B34786B-0A64-4566-BC35-12813DECE910@inria.fr> In-Reply-To: <8B34786B-0A64-4566-BC35-12813DECE910@inria.fr> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e2XcTVDATc53SWCm9OdaEwIk4G32fuO7J" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=b/AFFK6x c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=5hWoPXNsKEoA:10 a=ZXRAoOSSXYMA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=h1PgugrvaO0A:10 a=gcibvM-JMz0v0nNIYKMA:9 a=Q] X-AnalysisOut: [EXdDO2ut3YA:10 a=u2wq3K9QzYlkO4H3ShsA:9 a=_W_S_7VecoQA:10 ] X-AnalysisOut: [a=j4nzMFrpAAAA:8 a=eOac07LCoXfVKgWTNaYA:9] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: X-Mailman-Approved-At: Fri, 22 May 2015 18:11:01 -0700 Subject: Re: [secdir] Secdir review of draft-hansen-scram-sha256-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 00:01:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e2XcTVDATc53SWCm9OdaEwIk4G32fuO7J Content-Type: multipart/alternative; boundary="------------040709040306030804050307" This is a multi-part message in MIME format. --------------040709040306030804050307 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/13/15 6:32 AM, Vincent Roca wrote: > Hello, > > I have reviewed this document as part of the security directorate=E2=80= =99s > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just > like any other last call comments. > > > *Summary: ready with minor issues > * > > > This document records the SHA-256 variants of SCRAM SASL mechanisms. > As it complements RFC 5802, the authors refer to its security section: > "The security considerations from [RFC5802] still apply." > > I have no objection as RFC 5802 security section seems well documented > (I'm not an expert of the domain however). > > That being said, I have two comments: > > - there is no mention of the motivation for moving from SHA-1 to SHA-25= 6. > I think the security section is a nice place for that, and the > authors can easily > refer to RFC 4270 and RFC 6194 (there may be other references too tha= t > I=E2=80=99m not aware of). > > - RFC 2119 is missing from the Normative References. Please add it. > [R2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > I also think that RFC 4422 should be moved to the Normative Reference= s > as it is a mandatory to read reference for the present document. > Vincent, thank you for your review. I've added the RFC2119 reference and moved 4422 to Normative. I've added a reference to RFCs 4270 and 6194 in the security section. Tony --------------040709040306030804050307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/13/15 6:32 AM, Vincent Roca wrote:
Hello,

I have reviewed this document as part of the security directorate=E2=80=99s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. =C2=A0Document editors and WG chairs should treat these comments just
like any other last call comments.
=
=
= Summary: ready with minor issues
=
=
This document records the SHA-256 variants of SCRAM SASL mechanisms.
As it complement= s RFC 5802, the authors refer to its security section:
=C2=A0 =C2=A0"Th= e security considerations from [RFC5802] still apply."

I have no objection as RFC 5802 security section seems well documented
(I'm not an expert of the domain however).

That being said,= I have two comments:

- there is no mention of the motivation for moving from SHA-1 to SHA-256.
=C2=A0 I think t= he security section is a nice place for that, and the authors can easily
=C2=A0 refer to = RFC 4270 and RFC 6194 (there may be other references too that
=C2=A0 I=E2=80=99= m not aware of).

- RFC 2119 is missing from the Normative References. Please add it.
=C2=A0 =C2=A0[R2= 119] =C2=A0Bradner, S., "Key words for use in RFCs t= o Indicate
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Requirement Levels", BCP 14, RFC 2119, March 1997.
=C2=A0 I also th= ink that RFC 4422 should be moved to the Normative References
=C2=A0 as it is = a mandatory to read reference for the present document.


Vincent, thank you for your review.

I've added the RFC2119 reference and moved 4422 to Normative.

I've added a reference to RFCs 4270 and 6194 in the security section.

=C2=A0=C2=A0=C2=A0 Tony
--------------040709040306030804050307-- --e2XcTVDATc53SWCm9OdaEwIk4G32fuO7J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVX8L4AAoJEKd93u989/UtxrYQAJ2wNal/ERsLVRsez5qZuZkQ bu1LEXe4pUriFAH5HlqzLRH8C6Vkcv3FS8vmiPFzX825wdZZ23tmeo5YeXvqI4k9 1EsBrjb8MfUyAISiyzIKi4jy453Penh6jvV8GV0rUk6RNIjP2sdG5Ukhwhf3zvIf Mq6DG/HPhuh920kMtScKJeWwjzdZP/PI94AXoHSmCqjbElGBBa9/bvrngKkBPuzZ dog/7XWLq7arULoWx9i4vxs1q0gnpUy/PPs2WUB1V2gA2di1RtzG6qMdw/JKm/GQ mXkfGlgr40hlppk+RGL7SgoAAIQQ1XOAAA4hNuhUO7Qvqv0pjY5Lg8YJec8yy0nP OG0t5it7B2QamucgD15E7sExpPWqlyCpKJoBUqEbeAQoeGfpwCVfK6mWGP85lo9E 8vr1XZNsdMZJva0nm0cPHNisdVbq+dn/FPLobhsRLayUjo+DTyVO/NLXJGW7RY+y 9NiKsv67kPfZfNDZKrdcRsOfYvUTNSjNDLOf4U7KSb5axlfI+HYEm/KSriPm6J+b 84t/9Iyo4H8l9RcV15vnP4eUDVWkbu1SCSm2YJ4I5ExjZd2du2uGDQ27Pmf0NFo4 SCkKP169cgwxurI6AQkQn3dCRMQYMzaANjE5XkqYKgTfOuDRK2cdyKvSKislXwvt tQzr6b67mC0nGG6OLmeB =+cno -----END PGP SIGNATURE----- --e2XcTVDATc53SWCm9OdaEwIk4G32fuO7J-- From nobody Fri May 22 23:13:54 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6051A90E8; Fri, 22 May 2015 23:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKRWJHwWkBBO; Fri, 22 May 2015 23:13:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FCF1A90D7; Fri, 22 May 2015 23:13:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7E26B158D; Sat, 23 May 2015 08:13:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id eKiAy3PDVbV7; Sat, 23 May 2015 08:13:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 23 May 2015 08:13:41 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BC592002B; Sat, 23 May 2015 08:13:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9Kwva2Xy9W3k; Sat, 23 May 2015 08:13:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7C5120013; Sat, 23 May 2015 08:13:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7354933554BC; Sat, 23 May 2015 08:13:35 +0200 (CEST) Date: Sat, 23 May 2015 08:13:35 +0200 From: Juergen Schoenwaelder To: Christian Huitema Message-ID: <20150523061335.GA58453@elstar.local> Mail-Followup-To: Christian Huitema , 'The IESG' , secdir@ietf.org, draft-ietf-opsawg-vmm-mib.all@tools.ietf.org References: <00bb01d08df0$8d92f3f0$a8b8dbd0$@huitema.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00bb01d08df0$8d92f3f0$a8b8dbd0$@huitema.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-ietf-opsawg-vmm-mib.all@tools.ietf.org, 'The IESG' , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 06:13:49 -0000 Christian, thanks for the review. I am not sure if anything needs changes. The draft largely follows the security considerations template for MIB modules. And there is explicit text about GET access: [...] Moreover, the objects in the vmTable, vmCpuTable, vmCpuAffinityTable, vmStorageTable and vmNetworkTable list information about the virtual machines and their virtual resource allocation. Some may wish not to disclose to others how many and what virtual machines they are operating. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. Is this text not already covering your concerns? Below the quoted text, there is the general boilerplate recommendation to avoid SNMPv1 and to use SNMPv3 instead. /js On Wed, May 13, 2015 at 07:49:05PM -0700, Christian Huitema wrote: > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > For the security area directions, I consider this document to be "Ready with > nits". > > This document specifies objects (MIB) for managing virtual machines > controlled by a hypervisor (a.k.a. virtual machine monitor) using SNMP. > > The security section is thoroughly written, points out the operational risk > if some management variables can be SET, and the privacy or other security > risks if hostile parties can read some of the objects. The essential > recommendation is to use SNMPv3 strong security, or when that strong > security is not available, to disable the "SET" capabilities. > > There is an aggravating factor not mentioned in the security section. In > many large data centers, some virtual machines will not be under the direct > control of the data center manager. They may have been rented to third > parties, or they may have been subverted. These potentially hostile virtual > machines will have direct network connectivity with the hypervisor, and > potentially with other hypervisors in the same subnet. Attackers in control > of these machines can gain advantage of even read-only access to hypervisor > state variables. One wonders whether even GET access should be allowed in > the absence of authentication through SNMPv3. Attempting to support even GET > operations with prior versions of SNMP appears risky. > > -- Christian Huitema > > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun May 24 12:10:49 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1681ACE15; Sun, 24 May 2015 12:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpi-FND8am4G; Sun, 24 May 2015 12:10:47 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C68F1A6F38; Sun, 24 May 2015 12:10:46 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4OJAgWa021246 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 24 May 2015 21:10:43 +0200 Date: Sun, 24 May 2015 21:10:41 +0200 From: Simon Josefsson To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sfc-architecture.all@tools.ietf.org Message-ID: <20150524211041.52cde768@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/ptW5nbJ5JQUN/MqNhDLne=9"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 19:10:49 -0000 --Sig_/ptW5nbJ5JQUN/MqNhDLne=9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is an architectural document, so it doesn't have the usual security impact that you can easily review. The Security Considerations section gently refer any security considerations to the future documents that will actually realize the archicture. The security considerations that you would expect to be discussed in an architecural document are those on an architectural level. The archicture proposed here is to change how network services are delivered. The document doesn't give many examples, but my understanding is that the intended services would include firewalls, NAT, proxies, packet filtering, anti-spam measures, anti-DDOS measure, QoS, and so on. The traditional model is static services coupled to network topology and physical resource. The new model introduced by this document, as far as I understand, is a dynamic model where delivery of these services can be moved around more dynamically, by tunneling traffic to the service and back. I may have missed it, but I feel that the security consequences of moving to this new architecture is not discussed in the document. Some obvious security considerations that are introduced with an architecture like this are: 1) When delivery of a service is moved from an on-network-path machine to a machine sitting somewhere else, there ought to be some consideration to authenticating the involved entities and encrypting the traffic between them. 2) Auditing who has powers over a communication channel will be different -- before you evaluated the wires and who had access to the machines connected to the wires. Now you have to review the policies configured in the machines and what external entities are involved, together with the operational aspects of this boxes that perform the service delivery. 3) Moving traffic around raises the challenge how to achieve that without negatively affecting privacy of the traffic. 4) Protecting the SFC configuration and policies is critical for secure operations. Anyone who gains access may be able to modify traffic. If the above is a bit handwavy, allow me to be more concrete. Adding something like the following to the security considerations would at least acknowledge that there are inherent security considerations with this architecture: The architecture described here is different from the current model, and moving to the new model will lead to different security arrangements and modeling. For example, when service functions are moved from on-path static machines to dynamic remote machines, this introduce security and privacy aspects that needs to be addressed. All this said, I still would classify this document as Ready. It mostly just disappoint me that a new architecture can be introduced without containing a significant discussion of security properties. /Simon --Sig_/ptW5nbJ5JQUN/MqNhDLne=9 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVYiIxAAoJEIYLf7sy+BGdYLUH/08kvR0a9InA/cDMypIdwcOK 0ZAu5E7RkPqSeTRKFKxPZKvOJCmB37u6AOtOYVbnRDCmYNNzifqNuD15ajLwi7OQ LVCRg4TSpkVKQCRDvxhNcpliSBhpyjxhD0trSR5B/cPfnu2QfwvH2xyOl8p3Q1Xn KjWMCRyos1HNch8l9hnaGSB6WJWL9NwVlpOjTTjQG3W4tbRZeBm/EYQXWuJ0yZ7b wa7Wv+lN2IW1VIQxiMiLjCkbqZsS9XRnpSGhalf9Fpt4WbNzgcBudMXW3LlLBmKL Bx0FUDY1Z1AgIGKlsXzJGeb+aOAyK8iq3SyXelUlp32TcPYWPnoCT1L1BHvPlcQ= =iEkc -----END PGP SIGNATURE----- --Sig_/ptW5nbJ5JQUN/MqNhDLne=9-- From nobody Sun May 24 13:07:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333F91ACED1; Sun, 24 May 2015 13:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDXraaMKwIlo; Sun, 24 May 2015 13:06:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B02D1ACECD; Sun, 24 May 2015 13:06:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0F49A240C18; Sun, 24 May 2015 13:06:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 59AF7240719; Sun, 24 May 2015 13:06:47 -0700 (PDT) Message-ID: <55622F53.5090201@joelhalpern.com> Date: Sun, 24 May 2015 16:06:43 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Josefsson , iesg@ietf.org, secdir@ietf.org, draft-ietf-sfc-architecture.all@tools.ietf.org References: <20150524211041.52cde768@latte.josefsson.org> In-Reply-To: <20150524211041.52cde768@latte.josefsson.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 20:06:57 -0000 While the paragraph you suggest looks reasonable, I am somewhat concerned if readers draw the conclusion that we expect to include data plane authentication and / or encryption mechanisms as a mandatory part of the solution. There is no such expectation. While there is reason to be concerned about exposure of information across the Internet, the document begins by specifically noting that this architecture is for use with a single administrative domain. I am thus concerned that adding the suggested text may give rise to unreasonable expectations on solutions which comply with this architecture. Yours, Joel On 5/24/15 3:10 PM, Simon Josefsson wrote: > Hello. > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This is an architectural document, so it doesn't have the usual > security impact that you can easily review. The Security > Considerations section gently refer any security considerations to > the future documents that will actually realize the archicture. > > The security considerations that you would expect to be discussed in an > architecural document are those on an architectural level. The > archicture proposed here is to change how network services are > delivered. The document doesn't give many examples, but my > understanding is that the intended services would include firewalls, > NAT, proxies, packet filtering, anti-spam measures, anti-DDOS measure, > QoS, and so on. > > The traditional model is static services coupled to network topology > and physical resource. The new model introduced by this document, as > far as I understand, is a dynamic model where delivery of these services > can be moved around more dynamically, by tunneling traffic to the > service and back. > > I may have missed it, but I feel that the security consequences of > moving to this new architecture is not discussed in the document. > > Some obvious security considerations that are introduced with an > architecture like this are: > > 1) When delivery of a service is moved from an on-network-path > machine to a machine sitting somewhere else, there ought to be some > consideration to authenticating the involved entities and encrypting > the traffic between them. > > 2) Auditing who has powers over a communication channel will be > different -- before you evaluated the wires and who had access to the > machines connected to the wires. Now you have to review the policies > configured in the machines and what external entities are involved, > together with the operational aspects of this boxes that perform the > service delivery. > > 3) Moving traffic around raises the challenge how to achieve that > without negatively affecting privacy of the traffic. > > 4) Protecting the SFC configuration and policies is critical for > secure operations. Anyone who gains access may be able to modify > traffic. > > If the above is a bit handwavy, allow me to be more concrete. Adding > something like the following to the security considerations would at > least acknowledge that there are inherent security considerations with > this architecture: > > The architecture described here is different from the current model, > and moving to the new model will lead to different security > arrangements and modeling. For example, when service functions are > moved from on-path static machines to dynamic remote machines, this > introduce security and privacy aspects that needs to be addressed. > > All this said, I still would classify this document as Ready. It > mostly just disappoint me that a new architecture can be introduced > without containing a significant discussion of security properties. > > /Simon > From nobody Sun May 24 17:35:36 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777841A1BEE for ; Sun, 24 May 2015 17:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8qYHBpZoWKr for ; Sun, 24 May 2015 17:35:30 -0700 (PDT) Received: from xsmtp03.mail2web.com (xsmtp03.mail2web.com [168.144.250.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556BD1A1BE9 for ; Sun, 24 May 2015 17:35:30 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1YwgMX-00010U-3P for secdir@ietf.org; Sun, 24 May 2015 20:35:29 -0400 Received: (qmail 20091 invoked from network); 25 May 2015 00:35:24 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 May 2015 00:35:23 -0000 From: "Christian Huitema" To: "'Juergen Schoenwaelder'" References: <00bb01d08df0$8d92f3f0$a8b8dbd0$@huitema.net> <20150523061335.GA58453@elstar.local> In-Reply-To: <20150523061335.GA58453@elstar.local> Date: Sun, 24 May 2015 17:35:22 -0700 Message-ID: <019f01d09682$b04a7950$10df6bf0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIE6d1Hpq9LKtM8ftWnX5M6Ol/RpAGIZb20nRbqdEA= Content-Language: en-us Archived-At: Cc: draft-ietf-opsawg-vmm-mib.all@tools.ietf.org, 'The IESG' , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 00:35:34 -0000 Yes, your security section does mention the need to control GET as well. > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, May 22, 2015 11:14 PM > To: Christian Huitema > Cc: 'The IESG'; secdir@ietf.org; draft-ietf-opsawg-vmm-mib.all@tools.ietf.org > Subject: Re: Secdir review of draft-ietf-opsawg-vmm-mib-02 > > Christian, > > thanks for the review. I am not sure if anything needs changes. The > draft largely follows the security considerations template for MIB > modules. And there is explicit text about GET access: > > [...] Moreover, the objects in the vmTable, > vmCpuTable, vmCpuAffinityTable, vmStorageTable and vmNetworkTable > list information about the virtual machines and their virtual > resource allocation. Some may wish not to disclose to others how > many and what virtual machines they are operating. > > It is thus important to control even GET access to these objects and > possibly to even encrypt the values of these object when sending them > over the network via SNMP. Not all versions of SNMP provide features > for such a secure environment. > > Is this text not already covering your concerns? Below the quoted > text, there is the general boilerplate recommendation to avoid SNMPv1 > and to use SNMPv3 instead. The "GET" paragraph feels a bit generic. I would personally be a bit stronger. Something like, "It is NOT RECOMMENDED" to provide access to these variables without using the strong security features of SNMPv3. Of course, this is a generic problem with SNMP, and I understand your desire to use the generic text. But is there a good reason to not recommend v3? I would also mention the specific problem of software running in a virtual machine and accessing the hypervisor's variables. This is an attack vector that is somewhat specific to this MIB. It cannot be mitigated by network firewalls. -- Christian Huitema From nobody Sun May 24 18:26:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59311A8844; Sun, 24 May 2015 18:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP097iyRHiC5; Sun, 24 May 2015 18:25:58 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF9E1A8845; Sun, 24 May 2015 18:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4753; q=dns/txt; s=iport; t=1432517158; x=1433726758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0I/uWtwMby1UxzE35WjSCQ8zfXWaVTxPeO89hTzD7JE=; b=ae7JyT1KlNv37LVg9+7xsbSt2vrQ7iHTslN3LSE2c0+zqwzJAMWHgI5C GdYw+lEdz5T0upgOKrEOMYI6SDlepoZ5lkNsLHR5NyDZIV5LIc+t8jrr8 kma5jnFnsFNHQG3k06iKq1jTKw8jx6aONP4k5ylDBG5K1WUbE5TPnPsf1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A4BAAIeWJV/4MNJK1cgxCBMsJKZgmHUAKBKTgUAQEBAQEBAYEKhCIBAQEDAToyDQULAgEIEgYeEDIXDgIEDgUbiAkI0m8BAQEBAQEBAQEBAQEBAQEBAQEBARiLOoRSMweDF4EWAQSQTII8iw+BKZItg1kjggocgVJvgkcBAQE X-IronPort-AV: E=Sophos;i="5.13,488,1427760000"; d="scan'208";a="1489945" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 25 May 2015 01:25:57 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4P1PvJp013359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 May 2015 01:25:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Sun, 24 May 2015 20:25:57 -0500 From: "Carlos Pignataro (cpignata)" To: Simon Josefsson Thread-Topic: Review of draft-ietf-sfc-architecture-08 Thread-Index: AQHQllVoiI0EciI2k0ypB2MTIDGLzJ2L5tT3 Date: Mon, 25 May 2015 01:25:56 +0000 Message-ID: <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> References: <20150524211041.52cde768@latte.josefsson.org> In-Reply-To: <20150524211041.52cde768@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 01:26:02 -0000 Simon, Many thanks for your detailed review, and in particular your conclusion: "I still would classify this document as Ready." It is true that this new architecture introduces a model in which there is = a more dynamic service application, decoupling it from network topology pat= h; however, there is no administrative domain changes or admin fragmentatio= n. In other words, taking it very concrete, there is no change in expectati= ons regarding for example encryption. The service is potentially applied in= another part of the network and a chain can be created dynamically, but al= l within the same admin domain as before.=20 I am happy to add some text strengthening the security considerations -- ho= wever, I am concerned with any text that could be interpreted as a specific= strong requirement of encryption on solutions.=20 Your proposal ends too definitively as "this introduce security and privacy aspects that needs to be addressed", while = I see it more as "potentially" or "may in some cases".=20 Further, I believe that the main concern you raise is already covered in th= e "SFC Encapsulation" section of the Security Considerations.=20 Thanks! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On May 24, 2015, at 15:11, Simon Josefsson wrote: >=20 > Hello. >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This is an architectural document, so it doesn't have the usual > security impact that you can easily review. The Security > Considerations section gently refer any security considerations to > the future documents that will actually realize the archicture. >=20 > The security considerations that you would expect to be discussed in an > architecural document are those on an architectural level. The > archicture proposed here is to change how network services are > delivered. The document doesn't give many examples, but my > understanding is that the intended services would include firewalls, > NAT, proxies, packet filtering, anti-spam measures, anti-DDOS measure, > QoS, and so on. >=20 > The traditional model is static services coupled to network topology > and physical resource. The new model introduced by this document, as > far as I understand, is a dynamic model where delivery of these services > can be moved around more dynamically, by tunneling traffic to the > service and back. >=20 > I may have missed it, but I feel that the security consequences of > moving to this new architecture is not discussed in the document. >=20 > Some obvious security considerations that are introduced with an > architecture like this are: >=20 > 1) When delivery of a service is moved from an on-network-path > machine to a machine sitting somewhere else, there ought to be some > consideration to authenticating the involved entities and encrypting > the traffic between them. >=20 > 2) Auditing who has powers over a communication channel will be > different -- before you evaluated the wires and who had access to the > machines connected to the wires. Now you have to review the policies > configured in the machines and what external entities are involved, > together with the operational aspects of this boxes that perform the > service delivery. >=20 > 3) Moving traffic around raises the challenge how to achieve that > without negatively affecting privacy of the traffic. >=20 > 4) Protecting the SFC configuration and policies is critical for > secure operations. Anyone who gains access may be able to modify > traffic. >=20 > If the above is a bit handwavy, allow me to be more concrete. Adding > something like the following to the security considerations would at > least acknowledge that there are inherent security considerations with > this architecture: >=20 > The architecture described here is different from the current model, > and moving to the new model will lead to different security > arrangements and modeling. For example, when service functions are > moved from on-path static machines to dynamic remote machines, this > introduce security and privacy aspects that needs to be addressed. >=20 > All this said, I still would classify this document as Ready. It > mostly just disappoint me that a new architecture can be introduced > without containing a significant discussion of security properties. >=20 > /Simon From nobody Mon May 25 08:03:00 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF77B1A9053; Mon, 25 May 2015 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjS5o2TgtfzG; Mon, 25 May 2015 08:02:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789F71A904F; Mon, 25 May 2015 08:02:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 295F31015; Mon, 25 May 2015 17:02:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AwTJot_xAVgu; Mon, 25 May 2015 17:02:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 May 2015 17:02:50 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87AB22002B; Mon, 25 May 2015 17:02:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dG6XPd2tvo5v; Mon, 25 May 2015 17:02:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E894720013; Mon, 25 May 2015 17:02:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D69D933564BF; Mon, 25 May 2015 17:02:46 +0200 (CEST) Date: Mon, 25 May 2015 17:02:46 +0200 From: Juergen Schoenwaelder To: Christian Huitema Message-ID: <20150525150245.GA62786@elstar.local> Mail-Followup-To: Christian Huitema , 'The IESG' , secdir@ietf.org, draft-ietf-opsawg-vmm-mib.all@tools.ietf.org References: <00bb01d08df0$8d92f3f0$a8b8dbd0$@huitema.net> <20150523061335.GA58453@elstar.local> <019f01d09682$b04a7950$10df6bf0$@huitema.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019f01d09682$b04a7950$10df6bf0$@huitema.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-ietf-opsawg-vmm-mib.all@tools.ietf.org, 'The IESG' , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 15:02:59 -0000 On Sun, May 24, 2015 at 05:35:22PM -0700, Christian Huitema wrote: > Yes, your security section does mention the need to control GET as well. > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, May 22, 2015 11:14 PM > > To: Christian Huitema > > Cc: 'The IESG'; secdir@ietf.org; > draft-ietf-opsawg-vmm-mib.all@tools.ietf.org > > Subject: Re: Secdir review of draft-ietf-opsawg-vmm-mib-02 > > > > Christian, > > > > thanks for the review. I am not sure if anything needs changes. The > > draft largely follows the security considerations template for MIB > > modules. And there is explicit text about GET access: > > > > [...] Moreover, the objects in the vmTable, > > vmCpuTable, vmCpuAffinityTable, vmStorageTable and vmNetworkTable > > list information about the virtual machines and their virtual > > resource allocation. Some may wish not to disclose to others how > > many and what virtual machines they are operating. > > > > It is thus important to control even GET access to these objects and > > possibly to even encrypt the values of these object when sending them > > over the network via SNMP. Not all versions of SNMP provide features > > for such a secure environment. > > > > Is this text not already covering your concerns? Below the quoted > > text, there is the general boilerplate recommendation to avoid SNMPv1 > > and to use SNMPv3 instead. > > The "GET" paragraph feels a bit generic. I would personally be a bit > stronger. Something like, "It is NOT RECOMMENDED" to provide access to these > variables without using the strong security features of SNMPv3. Of course, > this is a generic problem with SNMP, and I understand your desire to use the > generic text. It seems on every second I-D that contains a MIB module we receive suggestions to change the boilerplate. The boilerplate was settled between security ADs and ops ADs and as a mere user of it I prefer to stick to whatever these folks have worked out. > But is there a good reason to not recommend v3? It is there (page 50): It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [RFC3414] and the View-based Access Control Model [RFC3415] is recommended. > I would also mention the specific problem of software running in a virtual > machine and accessing the hypervisor's variables. This is an attack vector > that is somewhat specific to this MIB. It cannot be mitigated by network > firewalls. This MIB module is typically implemented on the hypervisor not inside a virtual machine. I guess I do not follow what your concern is. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon May 25 08:09:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7A1A905B; Mon, 25 May 2015 08:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rUgfpAXaLOS; Mon, 25 May 2015 08:07:08 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4771A9061; Mon, 25 May 2015 08:07:07 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id DD08728175; Mon, 25 May 2015 08:07:06 -0700 (PDT) Received: from EX13-CAS-009.vmware.com (EX13-CAS-009.vmware.com [10.113.191.61]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id D7D2418245; Mon, 25 May 2015 08:07:06 -0700 (PDT) Received: from EX13-MBX-020.vmware.com (10.113.191.40) by EX13-MBX-010.vmware.com (10.113.191.30) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 25 May 2015 08:07:06 -0700 Received: from EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7]) by EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7%15]) with mapi id 15.00.0913.011; Mon, 25 May 2015 08:06:48 -0700 From: Michael MacFaden To: Christian Huitema , 'Juergen Schoenwaelder' Thread-Topic: Secdir review of draft-ietf-opsawg-vmm-mib-02 Thread-Index: AdCN7doYjrDBgdzuTDO0+ECXL1vNSAHbGwKAAFjFUAAAD7fNgQ== Date: Mon, 25 May 2015 15:06:48 +0000 Message-ID: References: <00bb01d08df0$8d92f3f0$a8b8dbd0$@huitema.net> <20150523061335.GA58453@elstar.local>, <019f01d09682$b04a7950$10df6bf0$@huitema.net> In-Reply-To: <019f01d09682$b04a7950$10df6bf0$@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.113.160.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 25 May 2015 08:09:44 -0700 Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , 'The IESG' , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 15:07:13 -0000 Christian writes:=0A= >I would also mention the specific problem of software running in a virtual= =0A= >machine and accessing the hypervisor's variable=0A= =0A= Yes we could describe this configuration and point out SNMPv3 would be requ= ired=0A= to mitigate it. And in regards to this issue:=0A= =0A= >There is an aggravating factor not mentioned in the security section. In= =0A= >many large data centers, some virtual machines will not be under the direc= t=0A= >control of the data center manager. They may have been rented to third=0A= >parties, or they may have been subverted. These potentially hostile virtua= l=0A= >machines will have direct network connectivity with the hypervisor, and=0A= >potentially with other hypervisors in the same subnet. Attackers in contro= l=0A= >of these machines can gain advantage of even read-only access to hyperviso= r=0A= >state variables. One wonders whether even GET access should be allowed in= =0A= >the absence of authentication through SNMPv3. Attempting to support even G= ET=0A= >operations with prior versions of SNMP appears risky.=0A= =0A= I note it is not just SNMP service that could be vulnerable in such a netwo= rk configuration.=0A= But direct network connectivity is not typical for commercial systems howev= er.=0A= What normally done in industry at least with VMware products, is to isolate= these=0A= VMs networking into separate layer 2 networks. The snmp service is in a sep= arate management=0A= network using either different virtual switches at layer 2 or separate IP s= tack. =0A= =0A= Mike=0A= From nobody Mon May 25 16:34:11 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEF81A010E for ; Mon, 25 May 2015 16:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JHPs1ZLqoau for ; Mon, 25 May 2015 16:34:07 -0700 (PDT) Received: from BAY004-OMC4S16.hotmail.com (bay004-omc4s16.hotmail.com [65.54.190.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD6F1ACDEA for ; Mon, 25 May 2015 16:34:07 -0700 (PDT) Received: from BAY405-EAS367 ([65.54.190.200]) by BAY004-OMC4S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 25 May 2015 16:34:07 -0700 X-TMN: [FnuB3Qoll817kfHs9xFdBqhJkFwnKPOC] X-Originating-Email: [charliekaufman@outlook.com] Message-ID: From: Charlie Kaufman To: "'Loa Andersson'" , "'secdir'" , , References: <554CAAE8.9090800@pi.nu> In-Reply-To: <554CAAE8.9090800@pi.nu> Date: Mon, 25 May 2015 16:34:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQABAgMEKPaEyBwqUlD2BgAu291FcaEsZ9Fw Content-Language: en-us X-OriginalArrivalTime: 25 May 2015 23:34:07.0628 (UTC) FILETIME=[4B5614C0:01D09743] Archived-At: Subject: Re: [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 23:34:10 -0000 Loa-- I hope this is an appropriate distribution list. If not please forward as necessary. All-- Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a protocol for doing opportunistic encryption of MPLS connections. It permits encryption at any of two scopes: between adjacent Label Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an LSP. Opportunistic encryption in this case means that there is no mechanism specified for authenticating the endpoints of the encrypted channel. The two endpoints do an anonymous Diffie-Hellman exchange and use the resulting key to encrypt the connection. The protocol is not protected from a man-in-the-middle attack (though some mechanisms for detecting such an attack after the fact are suggested and a keying infrastructure could be added later). The encryption aspects of the protocol seem well thought out and appropriate. The question at hand is whether to adopt this document as a working group document and it easily meets that bar (at least from a security standpoint). I have a number of questions about operational aspects of the protocol (perhaps due to my limited understanding of MPLS) and I have some suggestions for enhancements that will probably be necessary eventually and might be easier to make before there is widespread deployment: There is an issue that came up in the design of IKEv2 that may be an issue here as well. I don't know whether MPLS connections are bi-directional or whether separate connections need to be established in the two directions. If they are bi-directional, then there are race conditions that can occur if both ends attempt to initialize a connection simultaneously and there must be some tie-breaking mechanism to assure that exactly one of the connection attempts succeeds. If they are uni-directional, and if the connection is always initialized by the sending end, then this is not a problem (though it is replaced with the problem that messages of this protocol sent in the reverse direction cannot be tunneled over the MPLS connection). (This document seems to imply that MPLS connections can be either uni-directional or bi-directional, but I don't understand MPLS well enough to have understood it). Even if the connections are bi-directional, it will make your life simpler if you use different symmetric keys in the two directions. This can be done easily by getting two independent keys from the key expansion process. A second issue relates to algorithm negotiation. While the protocol allows for any of the crypto algorithms to be replaced, and the algorithms are indicated on the wire, it does not appear to allow for a smooth upgrade where the two ends are updated independently and everything must continue to work when only one end has been updated. To accomplish that, there should be an algorithm negotiation (as takes place in IKE and TLS) where one end presents a list of algorithms is can support and the other end chooses the algorithms it prefers. A simpler variation would be for a responder to be able to reject the algorithms assumed by the initiator and send back a list of algorithms it will accept. Note: it's possible that MPLS already operates with the restriction that the two ends of a connection must be consistent and operations will halt if the two ends are updated non-simultaneously. If that's true, then adding crypto doesn't make the situation any worse and it would be acceptable to continue to operate that way. A possible problem with Key Identifiers: the Key Identifier is only 4 bits long, which should be sufficient because at most two keys should be active at any given time. The Key Identifier, however, is chosen effectively randomly, which means that one time in 16 it will be the same as the Key Identifier it is replacing. While the protocol could be modified to do something special in that last (like adding one to the Key Identifier if it matches the previous value or redoing the key negotiation in that case), it would probably be better to get the Key-ID from the key expansion when there is no previous connection and add one (mod 16) when rekeying. There is mention of the possibility of reusing g^i and g^r between connections. Some crypto purists would object to that, but I wouldn't. If you want to allow implementations that option, however, you should also include in the exchange nonce values Ni and Nr that are not reused between connections rather than depending on unique values for the other parameters to prevent reuse of keys. In section 3.5 (MTU considerations), I suspect you may be underestimating the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad bytes to make the encrypted payload size a multiple of 16 bytes. There are algorithm variants that do not add any padding, but they are somewhat controversial and difficult to implement in hardware. Further, the total overhead will be dependent of the crypto algorithm chosen, and the text should indicate that so that readers don't assume that there is some maximum number of bytes that can be wired into protocols that run above this. I would suggest that most or all of sections 5 and 7 should be moved to Security Considerations. Failing that, the Security Considerations section should reference them. Typos: P4: "and if may be advisable" -> "and it may be advisable" P4: "an alternative key derivation functions" -> "alternative key derivation functions" P5: "key definition function" -> "key derivation function" P5: "attck vecotrs" -> "attack vectors" P5: "descirption" -> "description" P19: "opostie" -> "opposite" --Charlie -----Original Message----- From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Friday, May 08, 2015 5:24 AM To: secdir; draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt Security Directorate, Apologies if I'm sending this too wide! The MPLS wg has a review team. The task of the review team is to support the wg chair, in particular when we are considering a wg adoption poll. Before starting a wg adoption poll we run all documents through the MPLS-RT review (you can find a typical invite to such a review below). Just now we have draft-farrelll-mpls-opportunistic-encrypt in MPLS-RT review. We have enough reviewers accepting to do the review, but all of them have flagged that they are not entirely comfortable reviwing the document from a security perspective. Stephen have very graciously offered to help if there are question. I still would like to ask if it possible to find an expert reviewer in the security directorate. Questions asked are the same as you find in the invite below. Please contact me if you are willing to review the document for us. /Loa mpls wg co-chair -----------example of mpls-rt review invite ----------------------- Dave, Mach, Lizhong and Kamran, You have be selected as MPLS-RT reviewers for draft-farrelll-mpls-opportunistic-encrypt. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Note to the reviewers: I understand that this document is very much on the "security side of the house", however I will also reach out to the Sec-Dir for a more security biased review. This should not stop you from commenting on security aspects of the draft, but if you feel like it I'm comfortable with a "normal MPLS-RT review", responding to questions below. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control. Are you able to review this draft by May 17, 2015? Please respond in a timely fashion. Thanks, Loa (as MPLS WG chair) /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Mon May 25 20:02:16 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F12C1AD2F2; Mon, 25 May 2015 20:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V8zSDm73_KO; Mon, 25 May 2015 20:02:04 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C939F1AD2EE; Mon, 25 May 2015 20:02:03 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-8c-5563e22aefd8 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 9A.62.03359.A22E3655; Mon, 25 May 2015 23:02:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t4Q321nJ019832; Mon, 25 May 2015 23:02:01 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4Q31wmc019916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 May 2015 23:02:00 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4Q31v6L006861; Mon, 25 May 2015 23:01:57 -0400 (EDT) Date: Mon, 25 May 2015 23:01:57 -0400 (EDT) From: Benjamin Kaduk To: "Carlos Pignataro (cpignata)" In-Reply-To: <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> Message-ID: References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT19V6lBxqsOikssWndztYLG58us1s MePPRGaLDwsfsljc23KJ3YHVY8rvjaweS5b8ZPKYeeYiu8eXy5/ZAliiuGxSUnMyy1KL9O0S uDKeL9jNWHCZu2LBzf0sDYwnOLsYOTkkBEwktsw+ygZhi0lcuLceyObiEBJYzCRxruEgI0hC SGAjo0TDcSGIxCEmiWvvV7FDJBoYJU6cEwSxWQS0JV7OPwLWwCagIjHzzUawqSICZhKNjycx gTQzCzxhlDjdB1LEwSEsYCfxfYIKSA2ngK3E2mWrmUFsXgFHiW2t/1gh5mdJzO+eAhYXFdCR WL1/CgtEjaDEyZlPwGxmAS2J5dO3sUxgFJyFJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8 vNQiXUO93MwSvdSU0k2MoNDmlOTZwfjmoNIhRgEORiUeXovDyaFCrIllxZW5hxglOZiURHlZ rwGF+JLyUyozEosz4otKc1KLDzFKcDArifDOvQuU401JrKxKLcqHSUlzsCiJ8276wRciJJCe WJKanZpakFoEk5Xh4FCS4N3wAKhRsCg1PbUiLTOnBCHNxMEJMpwHaPhqkBre4oLE3OLMdIj8 KUZFKXHeRSAJAZBERmkeXC8s9bxiFAd6RZh3JUgVDzBtwXW/AhrMBDT4SnMiyOCSRISUVANj lqP3/or/E/8kufKzHuRZt+qzVJXXitcsJfWrJ9dsnL7647HAp+enfVp4bI/GyyUfUoMDBFR3 Msg4T+laf2DDzxSX0997JsccXRX3wz5wz5QAZybhMONE9v6sxNM266aFves7+fX++fvtqzed XREarcp2IJ79sOvcCYe/lGpLctXOfhwq+uKUgxJLcUaioRZzUXEiAMbqa08YAwAA Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 03:02:09 -0000 On Sun, 24 May 2015, Carlos Pignataro (cpignata) wrote: > It is true that this new architecture introduces a model in which there > is a more dynamic service application, decoupling it from network > topology path; however, there is no administrative domain changes or > admin fragmentation. In other words, taking it very concrete, there is > no change in expectations regarding for example encryption. The service > is potentially applied in another part of the network and a chain can be > created dynamically, but all within the same admin domain as before. As I attemted to say in my secdir review of the sfc-problem-statement document (http://www.ietf.org/mail-archive/web/secdir/current/msg05351.html), it is not clear that being within the same administrative domain excuses one from considering whether encryption is necessary. I seem to recall that, e.g., Google is encrypting all inter-datacenter traffic (I don't remember about intra-datacenter traffic, though). I do not think it is realistic to think that one can protect a network at the boundary -- there are always ways for sufficiently advanced attackers to get in, and some form of defense in depth is needed. Now, I grant that encryption may not always be needed, and it is not the place of SFC to insist that encryption always be used, but please do not claim that being in a single administrative domain excuses the operator from considering whether encryption is necessary. -Ben Kaduk From nobody Mon May 25 20:15:33 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091B01AD353; Mon, 25 May 2015 20:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kfh9e9b8R2J1; Mon, 25 May 2015 20:15:26 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0961AD352; Mon, 25 May 2015 20:15:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BC8E22464B7; Mon, 25 May 2015 20:15:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id DF258240E3A; Mon, 25 May 2015 20:15:25 -0700 (PDT) Message-ID: <5563E54C.60800@joelhalpern.com> Date: Mon, 25 May 2015 23:15:24 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Benjamin Kaduk , "Carlos Pignataro (cpignata)" References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 03:15:28 -0000 I have no problem if someone wants to add link protection because they use someone elses resources as part of their domain. But that is not SFC's problem, and not something, as far as I can tell, for the SFC architecture to address. We have already had to make clear multiple times to folks that we do not expect to require the kind of encryption that you are agreeing we don't need to require. Given that, I am very concerned that we not add words which will lead readers to think we are making such a requirement. Yours, Joel On 5/25/15 11:01 PM, Benjamin Kaduk wrote: > On Sun, 24 May 2015, Carlos Pignataro (cpignata) wrote: > >> It is true that this new architecture introduces a model in which there >> is a more dynamic service application, decoupling it from network >> topology path; however, there is no administrative domain changes or >> admin fragmentation. In other words, taking it very concrete, there is >> no change in expectations regarding for example encryption. The service >> is potentially applied in another part of the network and a chain can be >> created dynamically, but all within the same admin domain as before. > > As I attemted to say in my secdir review of the sfc-problem-statement > document > (http://www.ietf.org/mail-archive/web/secdir/current/msg05351.html), it is > not clear that being within the same administrative domain excuses one > from considering whether encryption is necessary. I seem to recall that, > e.g., Google is encrypting all inter-datacenter traffic (I don't remember > about intra-datacenter traffic, though). > > I do not think it is realistic to think that one can protect a network at > the boundary -- there are always ways for sufficiently advanced attackers > to get in, and some form of defense in depth is needed. Now, I grant that > encryption may not always be needed, and it is not the place of SFC to > insist that encryption always be used, but please do not claim that being > in a single administrative domain excuses the operator from considering > whether encryption is necessary. > > -Ben Kaduk > From nobody Tue May 26 02:05:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5CF1A1F16; Tue, 26 May 2015 02:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Yb-hh2U8e2j; Tue, 26 May 2015 02:05:41 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8C61A1EF2; Tue, 26 May 2015 02:05:40 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9C4A3180133E; Tue, 26 May 2015 11:05:38 +0200 (CEST) Message-ID: <5564375E.9060306@pi.nu> Date: Tue, 26 May 2015 11:05:34 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <554CAAE8.9090800@pi.nu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls-chairs@tools.ietf.org, 'secdir' Subject: [secdir] FYI - Early review of draft-farrelll-mpls-opportunistic-encrypt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 09:05:44 -0000 Charlie, We normally send this type of reviews to the working group also, so I do that now. Working Group, When we started the MPLS-RT review of draft-farrelll-mpls-opportunistic- encrypt we also asked the sec-dir for an early review of the document. Please find the review from Charlie included. /Loa mpls wg co-chair On 2015-05-26 01:34, Charlie Kaufman wrote: > Loa-- > I hope this is an appropriate distribution list. If not please > forward as necessary. > > All-- > Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a > protocol for doing opportunistic encryption of MPLS connections. It permits > encryption at any of two scopes: between adjacent Label Switching Routers > (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an > LSP. Opportunistic encryption in this case means that there is no mechanism > specified for authenticating the endpoints of the encrypted channel. The two > endpoints do an anonymous Diffie-Hellman exchange and use the resulting key > to encrypt the connection. The protocol is not protected from a > man-in-the-middle attack (though some mechanisms for detecting such an > attack after the fact are suggested and a keying infrastructure could be > added later). > > The encryption aspects of the protocol seem well thought out and > appropriate. The question at hand is whether to adopt this document as a > working group document and it easily meets that bar (at least from a > security standpoint). I have a number of questions about operational aspects > of the protocol (perhaps due to my limited understanding of MPLS) and I have > some suggestions for enhancements that will probably be necessary eventually > and might be easier to make before there is widespread deployment: > > There is an issue that came up in the design of IKEv2 that may be an issue > here as well. I don't know whether MPLS connections are bi-directional or > whether separate connections need to be established in the two directions. > If they are bi-directional, then there are race conditions that can occur if > both ends attempt to initialize a connection simultaneously and there must > be some tie-breaking mechanism to assure that exactly one of the connection > attempts succeeds. If they are uni-directional, and if the connection is > always initialized by the sending end, then this is not a problem (though it > is replaced with the problem that messages of this protocol sent in the > reverse direction cannot be tunneled over the MPLS connection). (This > document seems to imply that MPLS connections can be either uni-directional > or bi-directional, but I don't understand MPLS well enough to have > understood it). Even if the connections are bi-directional, it will make > your life simpler if you use different symmetric keys in the two directions. > This can be done easily by getting two independent keys from the key > expansion process. > > A second issue relates to algorithm negotiation. While the protocol allows > for any of the crypto algorithms to be replaced, and the algorithms are > indicated on the wire, it does not appear to allow for a smooth upgrade > where the two ends are updated independently and everything must continue to > work when only one end has been updated. To accomplish that, there should be > an algorithm negotiation (as takes place in IKE and TLS) where one end > presents a list of algorithms is can support and the other end chooses the > algorithms it prefers. A simpler variation would be for a responder to be > able to reject the algorithms assumed by the initiator and send back a list > of algorithms it will accept. Note: it's possible that MPLS already operates > with the restriction that the two ends of a connection must be consistent > and operations will halt if the two ends are updated non-simultaneously. If > that's true, then adding crypto doesn't make the situation any worse and it > would be acceptable to continue to operate that way. > > A possible problem with Key Identifiers: the Key Identifier is only 4 bits > long, which should be sufficient because at most two keys should be active > at any given time. The Key Identifier, however, is chosen effectively > randomly, which means that one time in 16 it will be the same as the Key > Identifier it is replacing. While the protocol could be modified to do > something special in that last (like adding one to the Key Identifier if it > matches the previous value or redoing the key negotiation in that case), it > would probably be better to get the Key-ID from the key expansion when there > is no previous connection and add one (mod 16) when rekeying. > > There is mention of the possibility of reusing g^i and g^r between > connections. Some crypto purists would object to that, but I wouldn't. If > you want to allow implementations that option, however, you should also > include in the exchange nonce values Ni and Nr that are not reused between > connections rather than depending on unique values for the other parameters > to prevent reuse of keys. > > In section 3.5 (MTU considerations), I suspect you may be underestimating > the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad > bytes to make the encrypted payload size a multiple of 16 bytes. There are > algorithm variants that do not add any padding, but they are somewhat > controversial and difficult to implement in hardware. Further, the total > overhead will be dependent of the crypto algorithm chosen, and the text > should indicate that so that readers don't assume that there is some maximum > number of bytes that can be wired into protocols that run above this. > > I would suggest that most or all of sections 5 and 7 should be moved to > Security Considerations. Failing that, the Security Considerations section > should reference them. > > Typos: > > P4: "and if may be advisable" -> "and it may be advisable" > P4: "an alternative key derivation functions" -> "alternative key derivation > functions" > P5: "key definition function" -> "key derivation function" > P5: "attck vecotrs" -> "attack vectors" > P5: "descirption" -> "description" > P19: "opostie" -> "opposite" > > > > > --Charlie > > -----Original Message----- > From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, May 08, 2015 5:24 AM > To: secdir; draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt > > Security Directorate, > > Apologies if I'm sending this too wide! > > The MPLS wg has a review team. The task of the review team is to support the > wg chair, in particular when we are considering a wg adoption poll. > > Before starting a wg adoption poll we run all documents through the MPLS-RT > review (you can find a typical invite to such a review below). > > Just now we have draft-farrelll-mpls-opportunistic-encrypt in MPLS-RT > review. We have enough reviewers accepting to do the review, but all of them > have flagged that they are not entirely comfortable reviwing the document > from a security perspective. Stephen have very graciously offered to help if > there are question. > > I still would like to ask if it possible to find an expert reviewer in the > security directorate. Questions asked are the same as you find in the invite > below. > > Please contact me if you are willing to review the document for us. > > /Loa > mpls wg co-chair > > -----------example of mpls-rt review invite ----------------------- > > Dave, Mach, Lizhong and Kamran, > > > You have be selected as MPLS-RT reviewers for > draft-farrelll-mpls-opportunistic-encrypt. > > Note to authors: You have been CC'd on this email so that you can know that > this review is going on. However, please do not review your own document. > > Note to the reviewers: I understand that this document is very much on the > "security side of the house", however I will also reach out to the Sec-Dir > for a more security biased review. > This should not stop you from commenting on security aspects of the draft, > but if you feel like it I'm comfortable with a "normal MPLS-RT review", > responding to questions below. > > Reviews should comment on whether the document is coherent, is it useful > (ie, is it likely to be actually useful in operational networks), and is the > document technically sound? We are interested in knowing whether the > document is ready to be considered for WG adoption (ie, it doesn't have to > be perfect at this point, but should be a good start). > > Reviews should be sent to the document authors, WG co-chairs and WG > secretary, and CC'd to the MPLS WG email list. If necessary, comments may be > sent privately to only the WG chairs. > > If you have technical comments you should try to be explicit about what > *really* need to be resolved before adopting it as a working group document, > and what can wait until the document is a working group document and the > working group has the revision control. > > Are you able to review this draft by May 17, 2015? Please respond in a > timely fashion. > > > Thanks, Loa > (as MPLS WG chair) > > > /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue May 26 04:57:52 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA631A875D; Tue, 26 May 2015 04:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-M-XoISDpUZ; Tue, 26 May 2015 04:57:48 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FA41A86EC; Tue, 26 May 2015 04:57:48 -0700 (PDT) Received: by oifu123 with SMTP id u123so36046448oif.1; Tue, 26 May 2015 04:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=jJhpo4T6rHSXf6+Thq3vI/VMejuOtqoP5odIredXaNo=; b=tUGk7S+h3HG16Q1oY+AxZmYxTC1vg5UmxR9boLvV2/9Op+L+2F6a+sjGtK90s1S/lo oD1Oey8qvJ0d+9llBvlFtw62m3X+Tu1SId1OtRzInVJBCN3a9Q/VkPYNOmesQbDEwiWt fi4LX7ZG1/rXLOSomrnTyLKPKFtwmLAfdjthoVZKUyuNgH39uZB2xBZZuhn0Q9DKlfCM m9r2hazLGPDA5iTNhMOYnaLevFZhx82o26X/r2KMwgSOVyCp99gkgmPs+KQHi4Hx1mtC to5YsKMe+eyT1Ei2NQ4j8EQeRth8bYPK0LTuz0jSxS7oBOTmmyaCobvMmSz0lVddQWRx yGAQ== X-Received: by 10.202.83.83 with SMTP id h80mr3058956oib.56.1432641467922; Tue, 26 May 2015 04:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.86.193 with HTTP; Tue, 26 May 2015 04:57:32 -0700 (PDT) From: Donald Eastlake Date: Tue, 26 May 2015 07:57:32 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-ipsecme-ikev2-null-auth.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a113b0a08c93d940516fad56c Archived-At: Cc: "secdir@ietf.org" Subject: [secdir] draft-ietf-ipsecme-ikev2-null-auth-06 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 11:57:49 -0000 --001a113b0a08c93d940516fad56c Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments should be treated like other last call comments. This draft provides a null authentication method and a null identity for use in IPsec, specifically the Internet Key Exchange Protocol version 2 (IKEv2). Overall this is an excellent draft and useful in countering pervasive surveillance in IKEv2. The Security Considerations section is quite thorough. I did notice one small thing: Section 3.1 is labeled "Audit trail and peer identification". But the content of that Security Considerations section is about not trusting identification when null authentication is used. It seems to me that a few words to the effect that some clear indication should be present in audit/log trails when a purported identity has not been authentication should be included, as I expected them to be from the section heading. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a113b0a08c93d940516fad56c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG. These comments should be treated like other last call comments.=

This draft provides a null authentication method and a = null identity for use in IPsec, specifically the Internet Key Exchange Prot= ocol version 2 (IKEv2).

Overall this is an excelle= nt draft and useful in countering pervasive surveillance in IKEv2.

The Security Considerations section is quite thorough. I d= id notice one small thing: Section 3.1 is labeled "Audit trail and pee= r identification". But the content of that Security Considerations sec= tion is about not trusting identification when null authentication is used.= It seems to me that a few words to the effect that some clear indication s= hould be present in audit/log trails when a purported identity has not been= authentication should =C2=A0be included, as I expected them to be from the= section heading.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd= =C2=A0=C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street,=C2=A0Milfor= d, MA 01757 USA
=C2=A0d3e3e3@gmail.com
--001a113b0a08c93d940516fad56c-- From nobody Tue May 26 05:09:59 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341BC1A88C6; Tue, 26 May 2015 05:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUVHLtZZWBRp; Tue, 26 May 2015 05:09:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3871A88C2; Tue, 26 May 2015 05:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4100; q=dns/txt; s=iport; t=1432642193; x=1433851793; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=E86AHYBsY7IzYQMGIDFf35EugiRoY4M7cIccdWNIcQI=; b=Sg1J5gBqfOXAr+Ms0+ikG9atRB5WqTAYlWya88/tP9sTv0ynN+9ekCRr aOQtOrdEdkXMuj02AFOa5tkXW6Wtq69iPnFq+yEveXYX9F4EpXYVampZ8 iIVffOkj3F/lFylpo4+nnjuIJmzUwnJv+wdnOzMhq0JAKNjnmLLowlJ4H w=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BXBQD/YWRV/5pdJa1cDoMCVF4Ggxm/FYJIhS1KAoFHTAEBAQEBAYELhCIBAQEDASNWBQsCAQgSBioCAjIXDgIEDgUJBQ2ICQgNr0OjVAEBAQEBAQEBAQEBAQEBAQEBAQEZizqEMwEBUAIFgmgvgRYFkwiCEoFDhzqBKYNxgn+PFiOCChyBFD5vAYELOoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,498,1427760000"; d="asc'?scan'208";a="422585998" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 26 May 2015 12:09:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4QC9px1005956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 May 2015 12:09:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 26 May 2015 07:09:51 -0500 From: "Carlos Pignataro (cpignata)" To: Benjamin Kaduk Thread-Topic: [secdir] Review of draft-ietf-sfc-architecture-08 Thread-Index: AQHQllVoiI0EciI2k0ypB2MTIDGLzJ2L5tT3gAIA+oCAAJkTAA== Date: Tue, 26 May 2015 12:09:50 +0000 Message-ID: <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.72] Content-Type: multipart/signed; boundary="Apple-Mail=_1A9EA452-D03F-46CB-99A3-96E95133F6DB"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 12:09:54 -0000 --Apple-Mail=_1A9EA452-D03F-46CB-99A3-96E95133F6DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben, > On May 25, 2015, at 11:01 PM, Benjamin Kaduk wrote: >=20 > On Sun, 24 May 2015, Carlos Pignataro (cpignata) wrote: >=20 >> It is true that this new architecture introduces a model in which = there >> is a more dynamic service application, decoupling it from network >> topology path; however, there is no administrative domain changes or >> admin fragmentation. In other words, taking it very concrete, there = is >> no change in expectations regarding for example encryption. The = service >> is potentially applied in another part of the network and a chain can = be >> created dynamically, but all within the same admin domain as before. >=20 > As I attemted to say in my secdir review of the sfc-problem-statement > document > (http://www.ietf.org/mail-archive/web/secdir/current/msg05351.html), = it is > not clear that being within the same administrative domain excuses one > from considering whether encryption is necessary. I seem to recall = that, > e.g., Google is encrypting all inter-datacenter traffic (I don't = remember > about intra-datacenter traffic, though). >=20 > I do not think it is realistic to think that one can protect a network = at > the boundary -- there are always ways for sufficiently advanced = attackers > to get in, and some form of defense in depth is needed. Now, I grant = that > encryption may not always be needed, and it is not the place of SFC to > insist that encryption always be used, but please do not claim that = being > in a single administrative domain excuses the operator from = considering > whether encryption is necessary. >=20 My point was a different one: that SFC does not change these = requirements. I may have misunderstood, but what I read in Simon's review (admittedly = oversimplified) was: in SFC you move services from on-network-path = (which, as an aside, is really the other way around; it is moving from = creating an on-network-path steering of network topology through the = service) to a machine =E2=80=98elsewhere' =E2=80=94 and thus, = consequently, you have to encrypt. My point is that the logic above (which, again, I may have = misunderstood) does not follow. There may be additional security and privacy considerations needed in = the DC, in mobile networks, etc. However, the SFC architecture does not = change that, and mandating encryption on SFCs might not be the right = answer. As we wrote, the solution realizing the architecture need to = perform part of that analysis. As I had said, I am more than happy adding text strengthening the = security considerations =E2=80=94 as long as we do not mandate a = solution at a specific layer. Best, =E2=80=94 Carlos. > -Ben Kaduk --Apple-Mail=_1A9EA452-D03F-46CB-99A3-96E95133F6DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZGKOAAoJEIXgpQGOZny9e9gP/2W9B5oKK33aHh0PsHnkddee rEByBv4cnk5e1oB4nYAofPbWRg/oxcLgqjnwhHrZ4zBZVtl+OoZ1gmluCaqY1jSP PU/WOmBuSe/U3vVEG4ry6Rv7uZZsQldj6Z830C5sOLroL5zy0av2SSO8prYXxhPR ETyaRay6IJpJvvqQJX+FpNAFRcqeYza3ngRIt4w/KlpxKus6N3Rjn4SrFlCW9DOw Jw/5RRxfTvqmreYKnOa4h/gtIq819aZj65rHSVNYp6IixLfeAN5IWtitT2MnlUWg 44JIhdWTBO65SFB1Vf+0GwrY2qnwps82ixuhgYwbIMXnSlWXraNcTJbFV8+Y561h lyYa5b74umbvywvBYCwy0WomKsadZlOBDLjufhkKJbDdnLg8fD6gmeGqsyjDZWVD 5HSU/6yIONJZtzHuTcsVBs5pbEWv/SWnCPJeWtjCvvCc8RvJ5cgrw7XI3fwXmSMJ VLOx5dgomRTN7IkQafq2YAlwDS6uGOOL3WTmvIQEaXCt6BXsD4ex0hRah4Q+XHVk YuW0hjaVWu+xy1ZwOI8NvanAPf7BiKqly91JyL10fuOWA+FgYiZscTrONz/j4x/V At+lVCc+L/HI5Xq+UJfLBbj/2r3TD5fUETnDJLQf0bxB11RjmQyZOLlesN1Hcyo+ I7RU787TWRMHAq5S8hi8 =AQzO -----END PGP SIGNATURE----- --Apple-Mail=_1A9EA452-D03F-46CB-99A3-96E95133F6DB-- From nobody Tue May 26 07:21:26 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77331B2F14; Tue, 26 May 2015 07:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25jYK9-eUZl4; Tue, 26 May 2015 07:21:03 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F21E1B2EEE; Tue, 26 May 2015 07:20:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lwyBJ0H9qzpQ; Tue, 26 May 2015 16:20:40 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=IxUiAxrA X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 6dXZCEGlofDk; Tue, 26 May 2015 16:20:38 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 26 May 2015 16:20:38 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DCC968003D; Tue, 26 May 2015 10:20:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1432650032; bh=nVXMdo3Ko3jBMcL+3rlXHk0uW/x9Y0HbWyDwfhV1bik=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=IxUiAxrAknvO4hSivPp2yt7ljNWMTO/teavprc1nRklmwPglk7wdD2tb1WAOkwuLN ucyBFr1YUSknjwZJf0ZvV8pP/K3w1cMFCunIotH/sb75AdQmxr43vahmIDsMdzzilk J6CFd7XK3db6Izul7rNPEjhkFYkKPu9XGqzjy2Jg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t4QEKVGI014313; Tue, 26 May 2015 10:20:31 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 26 May 2015 10:20:31 -0400 (EDT) From: Paul Wouters To: Donald Eastlake In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org WG" , draft-ietf-ipsecme-ikev2-null-auth.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-ipsecme-ikev2-null-auth-06 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 14:21:11 -0000 On Tue, 26 May 2015, Donald Eastlake wrote: Thanks for the review Donald, > The Security Considerations section is quite thorough. I did notice one small thing: Section 3.1 is labeled > "Audit trail and peer identification". But the content of that Security Considerations section is about not > trusting identification when null authentication is used. It seems to me that a few words to the effect that > some clear indication should be present in audit/log trails when a purported identity has not been > authentication should  be included, as I expected them to be from the section heading. The bulk of that section was moved into section 2.2i and 3.2. How about: OLD: With NULL Authentication an established IKE session is no longer guaranteed to provide a verifiable (authenticated) entity known to the system or network. Implementers that implement NULL Authentication should ensure their implementation does not make any assumptions that depend on IKE peers being "friendly", "trusted" or "identifiable". NEW: With NULL Authentication an established IKE session is no longer guaranteed to provide a verifiable (authenticated) entity known to the system or network. Any logging of unproven ID payloads that were not authenticated should be clearly marked and treated as "untrusted", possibly accompanied by logging the remote IP address of the IKE session. Rate limiting of logging might be required to prevent excessive logging causing system damage. then move this bit: Implementers that implement NULL Authentication should ensure their implementation does not make any assumptions that depend on IKE peers being "friendly", "trusted" or "identifiable". To just above the "While implementations should..." in section 3.2 Paul From nobody Tue May 26 08:47:04 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626911A9028; Tue, 26 May 2015 08:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aBRwSlkSPo3; Tue, 26 May 2015 08:46:55 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F871A9026; Tue, 26 May 2015 08:46:55 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so73483584lbb.3; Tue, 26 May 2015 08:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fxdx4znIlchHN88g+c3q5KtxtVh3mY2oUht8OFR2Fco=; b=O0LtpVd/qSmjMa0zIcexauV9/k/KCTc2JnkZhYD/RuE2PuySnbZhU/07vtfsC/29z1 mGRubqrqZJ+6gyf7e2mmATOFp+6YNlTWnQojtCUt9nbdtejF6h0wAckJeGmI+KnkOImr OLpT0/kxWJY+M7aTo26MrVgN2h0sDuc/BYQivoYQJxUEB/2Y+tAU+PZ4gvtlv+WLPxVe KRSknWXgJOrakNWgaoVGqWwpl2wEDQhSTt5RbqKksOqhobns9elGbf6naB1lTS9EPMZn u/sw2BWprU96rpJqEz1dEEJZX3aHoCUbNx/nIDhr7VSGlEHhams25ZVHuA7ekKbX07f1 cI8Q== MIME-Version: 1.0 X-Received: by 10.112.50.74 with SMTP id a10mr23253204lbo.4.1432655213975; Tue, 26 May 2015 08:46:53 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 26 May 2015 08:46:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 May 2015 11:46:53 -0400 Message-ID: From: Kathleen Moriarty To: Paul Wouters Content-Type: multipart/alternative; boundary=001a1133bb461d5ede0516fe09db Archived-At: Cc: "ipsec@ietf.org WG" , draft-ietf-ipsecme-ikev2-null-auth.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-ipsecme-ikev2-null-auth-06 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 15:46:58 -0000 --001a1133bb461d5ede0516fe09db Content-Type: text/plain; charset=UTF-8 I'm okay with that change. I thought that we discussed this last, there was an emphasis on the possibility to avoid logging unauthenticated sessions though? I see there is wiggle room to allow for that still. Does the new text meet your needs and still allow for logging of authenticated sessions (my previous concern that was addressed). Thanks, Kathleen On Tue, May 26, 2015 at 10:20 AM, Paul Wouters wrote: > On Tue, 26 May 2015, Donald Eastlake wrote: > > Thanks for the review Donald, > > The Security Considerations section is quite thorough. I did notice one >> small thing: Section 3.1 is labeled >> "Audit trail and peer identification". But the content of that Security >> Considerations section is about not >> trusting identification when null authentication is used. It seems to me >> that a few words to the effect that >> some clear indication should be present in audit/log trails when a >> purported identity has not been >> authentication should be included, as I expected them to be from the >> section heading. >> > > The bulk of that section was moved into section 2.2i and 3.2. > > How about: > > OLD: > > With NULL Authentication an established IKE session is no longer > guaranteed to provide a verifiable (authenticated) entity known to > the system or network. Implementers that implement NULL > Authentication should ensure their implementation does not make any > assumptions that depend on IKE peers being "friendly", "trusted" or > "identifiable". > > NEW: > > With NULL Authentication an established IKE session is no longer > guaranteed to provide a verifiable (authenticated) entity known to > the system or network. Any logging of unproven ID payloads that > were not authenticated should be clearly marked and treated as > "untrusted", possibly accompanied by logging the remote IP address > of the IKE session. Rate limiting of logging might be required to > prevent excessive logging causing system damage. > > then move this bit: > > Implementers that implement NULL > Authentication should ensure their implementation does not make any > assumptions that depend on IKE peers being "friendly", "trusted" or > "identifiable". > > To just above the "While implementations should..." in section 3.2 > > Paul > -- Best regards, Kathleen --001a1133bb461d5ede0516fe09db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm okay with that change.=C2=A0 I thought that we dis= cussed this last, there was an emphasis on the possibility to avoid logging= unauthenticated sessions though?=C2=A0 I see there is wiggle room to allow= for that still.=C2=A0 Does the new text meet your needs and still allow fo= r logging of authenticated sessions (my previous concern that was addressed= ).

Thanks,
Kathleen

On Tue, May 26, 2015 at 10:20 AM= , Paul Wouters <paul@nohats.ca> wrote:
On Tue, 26 May 2015, Donald Eastlake wrote:

Thanks for the review Donald,

The Security Considerations section is quite thorough. I did notice one sma= ll thing: Section 3.1 is labeled
"Audit trail and peer identification". But the content of that Se= curity Considerations section is about not
trusting identification when null authentication is used. It seems to me th= at a few words to the effect that
some clear indication should be present in audit/log trails when a purporte= d identity has not been
authentication should =C2=A0be included, as I expected them to be from the = section heading.

 The bulk of that section was moved into section 2.2i and 3.2.

How about:

OLD:

=C2=A0 =C2=A0With NULL Authentication an established IKE session is no long= er
=C2=A0 =C2=A0guaranteed to provide a verifiable (authenticated) entity know= n to
=C2=A0 =C2=A0the system or network.=C2=A0 Implementers that implement NULL<= br> =C2=A0 =C2=A0Authentication should ensure their implementation does not mak= e any
=C2=A0 =C2=A0assumptions that depend on IKE peers being "friendly"= ;, "trusted" or
=C2=A0 =C2=A0"identifiable".

NEW:

=C2=A0 =C2=A0With NULL Authentication an established IKE session is no long= er
=C2=A0 =C2=A0guaranteed to provide a verifiable (authenticated) entity know= n to
=C2=A0 =C2=A0the system or network. Any logging of unproven ID payloads tha= t
=C2=A0 =C2=A0were not authenticated should be clearly marked and treated as=
=C2=A0 =C2=A0"untrusted", possibly accompanied by logging the rem= ote IP address
=C2=A0 =C2=A0of the IKE session. Rate limiting of logging might be required= to
=C2=A0 =C2=A0prevent excessive logging causing system damage.

then move this bit:

=C2=A0 =C2=A0Implementers that implement NULL
=C2=A0 =C2=A0Authentication should ensure their implementation does not mak= e any
=C2=A0 =C2=A0assumptions that depend on IKE peers being "friendly"= ;, "trusted" or
=C2=A0 =C2=A0"identifiable".

To just above the "While implementations should..." in section 3.= 2

Paul



--

Best regards,
Kathleen
--001a1133bb461d5ede0516fe09db-- From nobody Tue May 26 09:06:29 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297951A9115; Tue, 26 May 2015 09:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EE5ZNygZBY6; Tue, 26 May 2015 09:06:24 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2B81A90E9; Tue, 26 May 2015 09:06:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lx0X85Fzjz7WC; Tue, 26 May 2015 18:06:16 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=iVS0msRp X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id YhmcOxPC0QZC; Tue, 26 May 2015 18:06:14 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 26 May 2015 18:06:14 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 57D868004A; Tue, 26 May 2015 12:06:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1432656372; bh=ztIWOlIZWE7wyYDPXi4uW6RJbakgnSbklNK5R1XVBug=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iVS0msRpHqmkj614l9+lC/3wI3NJML0OqLLy+Gr9sjhxZ5gysFHt2MSKqzBESv5dO O9EAP4drQ+dj3KrIweDhRE+zGaaEl8yj5Za2tstaV4AbL56bQ9Ay6CKrkv7gDaoIEA 1E0IS9CdWzIIETOPAEqZAU5SLoj5So5sMGGdqPgc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t4QG6B44030839; Tue, 26 May 2015 12:06:11 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 26 May 2015 12:06:11 -0400 (EDT) From: Paul Wouters To: Kathleen Moriarty In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org WG" , draft-ietf-ipsecme-ikev2-null-auth.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-ipsecme-ikev2-null-auth-06 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 16:06:26 -0000 On Tue, 26 May 2015, Kathleen Moriarty wrote: > I'm okay with that change.  I thought that we discussed this last, there was an emphasis on the possibility to > avoid logging unauthenticated sessions though? We mostly talked about not using unauthenticated IDs and only use them for logging. Then Tero wanted it for additional debug and we loosened up to allow ID's other than ID_NULL for AUTH_NULL. We added text to ensure no security decisions are based on unauthenticated IDs in section 2.2. We never talked about completely not logging unauthenticated sessions. I'm sure everyone would like at least some logging of that. What we noticed in our deployment though is that logging failures is what really kills you - in our Opportunistic IPsec we clearly enounter 99.99 percent of "no IKE daemon, so incoming ICMP message", followed by a 0.01% chance we found an IKE server that was never meant to talk IKE to us, returning a NO_PROPOSAL_CHOSEN. On an open DNS resolver (yes we like real hammer tests) this filled up on 4GB log disk in 15 minutes. So we are making changes to minimize logging in the Opportunistic case. But these considerations are not specific to AUTH_NULL and should go into the (to be created) Opportunistic IPsec document. >  I see there is wiggle room to allow for that still.  Does the > new text meet your needs and still allow for logging of authenticated sessions (my previous concern that was > addressed). As I read the new text, it makes no statement about authenticted IKE, only about things to do or not do when using unauthenticated IKE Paul > Thanks, > Kathleen > > On Tue, May 26, 2015 at 10:20 AM, Paul Wouters wrote: > On Tue, 26 May 2015, Donald Eastlake wrote: > > Thanks for the review Donald, > > The Security Considerations section is quite thorough. I did notice one small thing: > Section 3.1 is labeled > "Audit trail and peer identification". But the content of that Security Considerations > section is about not > trusting identification when null authentication is used. It seems to me that a few > words to the effect that > some clear indication should be present in audit/log trails when a purported identity > has not been > authentication should  be included, as I expected them to be from the section heading. > > > The bulk of that section was moved into section 2.2i and 3.2. > > How about: > > OLD: > >    With NULL Authentication an established IKE session is no longer >    guaranteed to provide a verifiable (authenticated) entity known to >    the system or network.  Implementers that implement NULL >    Authentication should ensure their implementation does not make any >    assumptions that depend on IKE peers being "friendly", "trusted" or >    "identifiable". > > NEW: > >    With NULL Authentication an established IKE session is no longer >    guaranteed to provide a verifiable (authenticated) entity known to >    the system or network. Any logging of unproven ID payloads that >    were not authenticated should be clearly marked and treated as >    "untrusted", possibly accompanied by logging the remote IP address >    of the IKE session. Rate limiting of logging might be required to >    prevent excessive logging causing system damage. > > then move this bit: > >    Implementers that implement NULL >    Authentication should ensure their implementation does not make any >    assumptions that depend on IKE peers being "friendly", "trusted" or >    "identifiable". > > To just above the "While implementations should..." in section 3.2 > > Paul > > > > > -- > > Best regards, > Kathleen > > From nobody Tue May 26 13:17:41 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651EA1B3111; Tue, 26 May 2015 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX6ZcFOlwnJk; Tue, 26 May 2015 13:17:34 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B081B30FD; Tue, 26 May 2015 13:17:34 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4QKHTqK013128 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 26 May 2015 22:17:31 +0200 Date: Tue, 26 May 2015 22:17:28 +0200 From: Simon Josefsson To: "Joel M. Halpern" Message-ID: <20150526221728.02605b82@latte.josefsson.org> In-Reply-To: <55622F53.5090201@joelhalpern.com> References: <20150524211041.52cde768@latte.josefsson.org> <55622F53.5090201@joelhalpern.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/3+AAuvPRCbctybzxI48G6Ry"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: draft-ietf-sfc-architecture.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:17:36 -0000 --Sig_/3+AAuvPRCbctybzxI48G6Ry Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable If it is unreasonable to expect that encryption/authentication will be part of the architecture, I believe there is a significant problem with this architecture. The argument that security is not necessary within a single administrative domain is one that I complete disagree with. I am hoping that I am missing some context here. /Simon > While the paragraph you suggest looks reasonable, I am somewhat=20 > concerned if readers draw the conclusion that we expect to include > data plane authentication and / or encryption mechanisms as a > mandatory part of the solution. There is no such expectation. While > there is reason to be concerned about exposure of information across > the Internet, the document begins by specifically noting that this > architecture is for use with a single administrative domain. >=20 > I am thus concerned that adding the suggested text may give rise to=20 > unreasonable expectations on solutions which comply with this > architecture. >=20 > Yours, > Joel >=20 > On 5/24/15 3:10 PM, Simon Josefsson wrote: > > Hello. > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should > > treat these comments just like any other last call comments. > > > > This is an architectural document, so it doesn't have the usual > > security impact that you can easily review. The Security > > Considerations section gently refer any security considerations to > > the future documents that will actually realize the archicture. > > > > The security considerations that you would expect to be discussed > > in an architecural document are those on an architectural level. > > The archicture proposed here is to change how network services are > > delivered. The document doesn't give many examples, but my > > understanding is that the intended services would include firewalls, > > NAT, proxies, packet filtering, anti-spam measures, anti-DDOS > > measure, QoS, and so on. > > > > The traditional model is static services coupled to network topology > > and physical resource. The new model introduced by this document, as > > far as I understand, is a dynamic model where delivery of these > > services can be moved around more dynamically, by tunneling traffic > > to the service and back. > > > > I may have missed it, but I feel that the security consequences of > > moving to this new architecture is not discussed in the document. > > > > Some obvious security considerations that are introduced with an > > architecture like this are: > > > > 1) When delivery of a service is moved from an on-network-path > > machine to a machine sitting somewhere else, there ought to be > > some consideration to authenticating the involved entities and > > encrypting the traffic between them. > > > > 2) Auditing who has powers over a communication channel will be > > different -- before you evaluated the wires and who had access > > to the machines connected to the wires. Now you have to review the > > policies configured in the machines and what external entities are > > involved, together with the operational aspects of this boxes that > > perform the service delivery. > > > > 3) Moving traffic around raises the challenge how to achieve that > > without negatively affecting privacy of the traffic. > > > > 4) Protecting the SFC configuration and policies is critical for > > secure operations. Anyone who gains access may be able to modify > > traffic. > > > > If the above is a bit handwavy, allow me to be more concrete. > > Adding something like the following to the security considerations > > would at least acknowledge that there are inherent security > > considerations with this architecture: > > > > The architecture described here is different from the current > > model, and moving to the new model will lead to different security > > arrangements and modeling. For example, when service functions > > are moved from on-path static machines to dynamic remote machines, > > this introduce security and privacy aspects that needs to be > > addressed. > > > > All this said, I still would classify this document as Ready. It > > mostly just disappoint me that a new architecture can be introduced > > without containing a significant discussion of security properties. > > > > /Simon > > --Sig_/3+AAuvPRCbctybzxI48G6Ry Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZNTYAAoJEIYLf7sy+BGdOs8H/R0jNEs6d41m1ijnxedT5Bx1 nvbNvkokG1i89esVVjpCBxRXkPMj11sYlWlN0Pz6JnaVaEd0MW1cD5e0+666kxni VMDdytJzBfrWYBMHaW35V180YDbEFP5/jJ1VBNe32zX4eDVSKDH7NiL/zrVUrNMf fz9H9LMkKxkvniGli4hR1kkCBnqnZclay79q6yUj1FgKXU23LZOddYVpwO3cjTCo 5PbOcoYL1AMCF6/ftBfQZc8RTBb63rM/U3jhms0NZMYeUyrsAh4tmooCKaBtRMpL chiztsAlpwSRjhFTSzggh2gZu5RGTm4Fo3M1CdHYixIL+lsSTgaL6QIgzsK/oSg= =yVpy -----END PGP SIGNATURE----- --Sig_/3+AAuvPRCbctybzxI48G6Ry-- From nobody Tue May 26 14:23:12 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2F1B31C3; Tue, 26 May 2015 14:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.798 X-Spam-Level: * X-Spam-Status: No, score=1.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_BACKHAIR_32=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpHZAFYobzxo; Tue, 26 May 2015 14:23:06 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6E61B31EA; Tue, 26 May 2015 14:23:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4ED4C251087; Tue, 26 May 2015 14:23:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 841F4251040; Tue, 26 May 2015 14:23:00 -0700 (PDT) Message-ID: <5564E432.9000207@joelhalpern.com> Date: Tue, 26 May 2015 17:22:58 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Josefsson References: <20150524211041.52cde768@latte.josefsson.org> <55622F53.5090201@joelhalpern.com> <20150526221728.02605b82@latte.josefsson.org> In-Reply-To: <20150526221728.02605b82@latte.josefsson.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-sfc-architecture.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:23:07 -0000 Given the expected construction and usage for this, if we rite into the archtiecture that encryption and authentication of data plane messages are mandatory, then presumably we will also write such "mandatory" mechanisms into the data plane mechanism we specify. At which point we are writing a specification which will be widely ignored. Given that we are talking about passing packets through a series of service functions, requiring encryption between them causes a drastic increase in complexity and latency. As far as I can tell from the way customers expect to use this, it is simply unacceptable. For inter-DC (or POP<->DC) operators who wish to protect that traffic wil likely want to do so whether or not they are using service chaining. As such, the protection is not a service chaining issue. So, sorry, but I have to respectfully disagree with you Simon. Yours, Joel On 5/26/15 4:17 PM, Simon Josefsson wrote: > If it is unreasonable to expect that encryption/authentication will be > part of the architecture, I believe there is a significant problem with > this architecture. The argument that security is not necessary within > a single administrative domain is one that I complete disagree with. I > am hoping that I am missing some context here. > > /Simon > >> While the paragraph you suggest looks reasonable, I am somewhat >> concerned if readers draw the conclusion that we expect to include >> data plane authentication and / or encryption mechanisms as a >> mandatory part of the solution. There is no such expectation. While >> there is reason to be concerned about exposure of information across >> the Internet, the document begins by specifically noting that this >> architecture is for use with a single administrative domain. >> >> I am thus concerned that adding the suggested text may give rise to >> unreasonable expectations on solutions which comply with this >> architecture. >> >> Yours, >> Joel >> >> On 5/24/15 3:10 PM, Simon Josefsson wrote: >>> Hello. >>> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should >>> treat these comments just like any other last call comments. >>> >>> This is an architectural document, so it doesn't have the usual >>> security impact that you can easily review. The Security >>> Considerations section gently refer any security considerations to >>> the future documents that will actually realize the archicture. >>> >>> The security considerations that you would expect to be discussed >>> in an architecural document are those on an architectural level. >>> The archicture proposed here is to change how network services are >>> delivered. The document doesn't give many examples, but my >>> understanding is that the intended services would include firewalls, >>> NAT, proxies, packet filtering, anti-spam measures, anti-DDOS >>> measure, QoS, and so on. >>> >>> The traditional model is static services coupled to network topology >>> and physical resource. The new model introduced by this document, as >>> far as I understand, is a dynamic model where delivery of these >>> services can be moved around more dynamically, by tunneling traffic >>> to the service and back. >>> >>> I may have missed it, but I feel that the security consequences of >>> moving to this new architecture is not discussed in the document. >>> >>> Some obvious security considerations that are introduced with an >>> architecture like this are: >>> >>> 1) When delivery of a service is moved from an on-network-path >>> machine to a machine sitting somewhere else, there ought to be >>> some consideration to authenticating the involved entities and >>> encrypting the traffic between them. >>> >>> 2) Auditing who has powers over a communication channel will be >>> different -- before you evaluated the wires and who had access >>> to the machines connected to the wires. Now you have to review the >>> policies configured in the machines and what external entities are >>> involved, together with the operational aspects of this boxes that >>> perform the service delivery. >>> >>> 3) Moving traffic around raises the challenge how to achieve that >>> without negatively affecting privacy of the traffic. >>> >>> 4) Protecting the SFC configuration and policies is critical for >>> secure operations. Anyone who gains access may be able to modify >>> traffic. >>> >>> If the above is a bit handwavy, allow me to be more concrete. >>> Adding something like the following to the security considerations >>> would at least acknowledge that there are inherent security >>> considerations with this architecture: >>> >>> The architecture described here is different from the current >>> model, and moving to the new model will lead to different security >>> arrangements and modeling. For example, when service functions >>> are moved from on-path static machines to dynamic remote machines, >>> this introduce security and privacy aspects that needs to be >>> addressed. >>> >>> All this said, I still would classify this document as Ready. It >>> mostly just disappoint me that a new architecture can be introduced >>> without containing a significant discussion of security properties. >>> >>> /Simon >>> > From nobody Tue May 26 14:34:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314FE1B3202; Tue, 26 May 2015 14:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_BACKHAIR_32=1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG5K-hAACH8e; Tue, 26 May 2015 14:34:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8001B3200; Tue, 26 May 2015 14:34:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 53B85BECF; Tue, 26 May 2015 22:33:59 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-Q0PPDIiXAV; Tue, 26 May 2015 22:33:57 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1CEF2BECC; Tue, 26 May 2015 22:33:57 +0100 (IST) Message-ID: <5564E6C4.4000302@cs.tcd.ie> Date: Tue, 26 May 2015 22:33:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , Simon Josefsson References: <20150524211041.52cde768@latte.josefsson.org> <55622F53.5090201@joelhalpern.com> <20150526221728.02605b82@latte.josefsson.org> <5564E432.9000207@joelhalpern.com> In-Reply-To: <5564E432.9000207@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: secdir@ietf.org, draft-ietf-sfc-architecture.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:34:05 -0000 I've yet to read this one so could be plain wrong but I don't see that our choices here are an architecture that defines (or re-uses) no security mechanisms/services at all or one that encrypts everything, but fwiw your response below Joel and earlier ones read as if those are the only choices and I find that hard to believe. S. On 26/05/15 22:22, Joel M. Halpern wrote: > Given the expected construction and usage for this, if we rite into the > archtiecture that encryption and authentication of data plane messages > are mandatory, then > presumably we will also write such "mandatory" mechanisms into the data > plane mechanism we specify. > > At which point we are writing a specification which will be widely ignored. > > Given that we are talking about passing packets through a series of > service functions, requiring encryption between them causes a drastic > increase in complexity and latency. As far as I can tell from the way > customers expect to use this, it is simply unacceptable. For inter-DC > (or POP<->DC) operators who wish to protect that traffic wil likely want > to do so whether or not they are using service chaining. As such, the > protection is not a service chaining issue. > > So, sorry, but I have to respectfully disagree with you Simon. > > Yours, > Joel > > On 5/26/15 4:17 PM, Simon Josefsson wrote: >> If it is unreasonable to expect that encryption/authentication will be >> part of the architecture, I believe there is a significant problem with >> this architecture. The argument that security is not necessary within >> a single administrative domain is one that I complete disagree with. I >> am hoping that I am missing some context here. >> >> /Simon >> >>> While the paragraph you suggest looks reasonable, I am somewhat >>> concerned if readers draw the conclusion that we expect to include >>> data plane authentication and / or encryption mechanisms as a >>> mandatory part of the solution. There is no such expectation. While >>> there is reason to be concerned about exposure of information across >>> the Internet, the document begins by specifically noting that this >>> architecture is for use with a single administrative domain. >>> >>> I am thus concerned that adding the suggested text may give rise to >>> unreasonable expectations on solutions which comply with this >>> architecture. >>> >>> Yours, >>> Joel >>> >>> On 5/24/15 3:10 PM, Simon Josefsson wrote: >>>> Hello. >>>> >>>> I have reviewed this document as part of the security directorate's >>>> ongoing effort to review all IETF documents being processed by the >>>> IESG. These comments were written primarily for the benefit of the >>>> security area directors. Document editors and WG chairs should >>>> treat these comments just like any other last call comments. >>>> >>>> This is an architectural document, so it doesn't have the usual >>>> security impact that you can easily review. The Security >>>> Considerations section gently refer any security considerations to >>>> the future documents that will actually realize the archicture. >>>> >>>> The security considerations that you would expect to be discussed >>>> in an architecural document are those on an architectural level. >>>> The archicture proposed here is to change how network services are >>>> delivered. The document doesn't give many examples, but my >>>> understanding is that the intended services would include firewalls, >>>> NAT, proxies, packet filtering, anti-spam measures, anti-DDOS >>>> measure, QoS, and so on. >>>> >>>> The traditional model is static services coupled to network topology >>>> and physical resource. The new model introduced by this document, as >>>> far as I understand, is a dynamic model where delivery of these >>>> services can be moved around more dynamically, by tunneling traffic >>>> to the service and back. >>>> >>>> I may have missed it, but I feel that the security consequences of >>>> moving to this new architecture is not discussed in the document. >>>> >>>> Some obvious security considerations that are introduced with an >>>> architecture like this are: >>>> >>>> 1) When delivery of a service is moved from an on-network-path >>>> machine to a machine sitting somewhere else, there ought to be >>>> some consideration to authenticating the involved entities and >>>> encrypting the traffic between them. >>>> >>>> 2) Auditing who has powers over a communication channel will be >>>> different -- before you evaluated the wires and who had access >>>> to the machines connected to the wires. Now you have to review the >>>> policies configured in the machines and what external entities are >>>> involved, together with the operational aspects of this boxes that >>>> perform the service delivery. >>>> >>>> 3) Moving traffic around raises the challenge how to achieve that >>>> without negatively affecting privacy of the traffic. >>>> >>>> 4) Protecting the SFC configuration and policies is critical for >>>> secure operations. Anyone who gains access may be able to modify >>>> traffic. >>>> >>>> If the above is a bit handwavy, allow me to be more concrete. >>>> Adding something like the following to the security considerations >>>> would at least acknowledge that there are inherent security >>>> considerations with this architecture: >>>> >>>> The architecture described here is different from the current >>>> model, and moving to the new model will lead to different security >>>> arrangements and modeling. For example, when service functions >>>> are moved from on-path static machines to dynamic remote machines, >>>> this introduce security and privacy aspects that needs to be >>>> addressed. >>>> >>>> All this said, I still would classify this document as Ready. It >>>> mostly just disappoint me that a new architecture can be introduced >>>> without containing a significant discussion of security properties. >>>> >>>> /Simon >>>> >> > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue May 26 16:07:40 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5865C1B32FB; Tue, 26 May 2015 16:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_32=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqBkKxLmbL21; Tue, 26 May 2015 16:07:33 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576FB1B32F5; Tue, 26 May 2015 16:07:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 35882240443; Tue, 26 May 2015 16:07:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 577132464B7; Tue, 26 May 2015 16:07:32 -0700 (PDT) Message-ID: <5564FCB1.80207@joelhalpern.com> Date: Tue, 26 May 2015 19:07:29 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , Simon Josefsson References: <20150524211041.52cde768@latte.josefsson.org> <55622F53.5090201@joelhalpern.com> <20150526221728.02605b82@latte.josefsson.org> <5564E432.9000207@joelhalpern.com> <5564E6C4.4000302@cs.tcd.ie> In-Reply-To: <5564E6C4.4000302@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: secdir@ietf.org, draft-ietf-sfc-architecture.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:07:35 -0000 There may well be something that can be said in the architecture that would be helpful. My concern is that given teh current IETF environment, adding the suggested wording to the architecture could easily lead the IESG to expect mandatory-to-implement data plane packet authentication and / or encryption. There are proposals to add optional mechanisms to the dataplane protocol. The proposals I have seen have no impact on the architecture. Yours, Joel On 5/26/15 5:33 PM, Stephen Farrell wrote: > > I've yet to read this one so could be plain wrong but I don't > see that our choices here are an architecture that defines (or > re-uses) no security mechanisms/services at all or one that > encrypts everything, but fwiw your response below Joel and earlier > ones read as if those are the only choices and I find that hard > to believe. > > S. > > On 26/05/15 22:22, Joel M. Halpern wrote: >> Given the expected construction and usage for this, if we rite into the >> archtiecture that encryption and authentication of data plane messages >> are mandatory, then >> presumably we will also write such "mandatory" mechanisms into the data >> plane mechanism we specify. >> >> At which point we are writing a specification which will be widely ignored. >> >> Given that we are talking about passing packets through a series of >> service functions, requiring encryption between them causes a drastic >> increase in complexity and latency. As far as I can tell from the way >> customers expect to use this, it is simply unacceptable. For inter-DC >> (or POP<->DC) operators who wish to protect that traffic wil likely want >> to do so whether or not they are using service chaining. As such, the >> protection is not a service chaining issue. >> >> So, sorry, but I have to respectfully disagree with you Simon. >> >> Yours, >> Joel >> >> On 5/26/15 4:17 PM, Simon Josefsson wrote: >>> If it is unreasonable to expect that encryption/authentication will be >>> part of the architecture, I believe there is a significant problem with >>> this architecture. The argument that security is not necessary within >>> a single administrative domain is one that I complete disagree with. I >>> am hoping that I am missing some context here. >>> >>> /Simon >>> >>>> While the paragraph you suggest looks reasonable, I am somewhat >>>> concerned if readers draw the conclusion that we expect to include >>>> data plane authentication and / or encryption mechanisms as a >>>> mandatory part of the solution. There is no such expectation. While >>>> there is reason to be concerned about exposure of information across >>>> the Internet, the document begins by specifically noting that this >>>> architecture is for use with a single administrative domain. >>>> >>>> I am thus concerned that adding the suggested text may give rise to >>>> unreasonable expectations on solutions which comply with this >>>> architecture. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/24/15 3:10 PM, Simon Josefsson wrote: >>>>> Hello. >>>>> >>>>> I have reviewed this document as part of the security directorate's >>>>> ongoing effort to review all IETF documents being processed by the >>>>> IESG. These comments were written primarily for the benefit of the >>>>> security area directors. Document editors and WG chairs should >>>>> treat these comments just like any other last call comments. >>>>> >>>>> This is an architectural document, so it doesn't have the usual >>>>> security impact that you can easily review. The Security >>>>> Considerations section gently refer any security considerations to >>>>> the future documents that will actually realize the archicture. >>>>> >>>>> The security considerations that you would expect to be discussed >>>>> in an architecural document are those on an architectural level. >>>>> The archicture proposed here is to change how network services are >>>>> delivered. The document doesn't give many examples, but my >>>>> understanding is that the intended services would include firewalls, >>>>> NAT, proxies, packet filtering, anti-spam measures, anti-DDOS >>>>> measure, QoS, and so on. >>>>> >>>>> The traditional model is static services coupled to network topology >>>>> and physical resource. The new model introduced by this document, as >>>>> far as I understand, is a dynamic model where delivery of these >>>>> services can be moved around more dynamically, by tunneling traffic >>>>> to the service and back. >>>>> >>>>> I may have missed it, but I feel that the security consequences of >>>>> moving to this new architecture is not discussed in the document. >>>>> >>>>> Some obvious security considerations that are introduced with an >>>>> architecture like this are: >>>>> >>>>> 1) When delivery of a service is moved from an on-network-path >>>>> machine to a machine sitting somewhere else, there ought to be >>>>> some consideration to authenticating the involved entities and >>>>> encrypting the traffic between them. >>>>> >>>>> 2) Auditing who has powers over a communication channel will be >>>>> different -- before you evaluated the wires and who had access >>>>> to the machines connected to the wires. Now you have to review the >>>>> policies configured in the machines and what external entities are >>>>> involved, together with the operational aspects of this boxes that >>>>> perform the service delivery. >>>>> >>>>> 3) Moving traffic around raises the challenge how to achieve that >>>>> without negatively affecting privacy of the traffic. >>>>> >>>>> 4) Protecting the SFC configuration and policies is critical for >>>>> secure operations. Anyone who gains access may be able to modify >>>>> traffic. >>>>> >>>>> If the above is a bit handwavy, allow me to be more concrete. >>>>> Adding something like the following to the security considerations >>>>> would at least acknowledge that there are inherent security >>>>> considerations with this architecture: >>>>> >>>>> The architecture described here is different from the current >>>>> model, and moving to the new model will lead to different security >>>>> arrangements and modeling. For example, when service functions >>>>> are moved from on-path static machines to dynamic remote machines, >>>>> this introduce security and privacy aspects that needs to be >>>>> addressed. >>>>> >>>>> All this said, I still would classify this document as Ready. It >>>>> mostly just disappoint me that a new architecture can be introduced >>>>> without containing a significant discussion of security properties. >>>>> >>>>> /Simon >>>>> >>> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Tue May 26 16:28:48 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FE81B330F; Tue, 26 May 2015 16:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_32=1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6VVflhKcsZv; Tue, 26 May 2015 16:28:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64A61B3314; Tue, 26 May 2015 16:28:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 386C2BED9; Wed, 27 May 2015 00:28:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKVVL8zIJqXV; Wed, 27 May 2015 00:28:36 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB4ABBEC6; Wed, 27 May 2015 00:28:35 +0100 (IST) Message-ID: <556501A3.2080604@cs.tcd.ie> Date: Wed, 27 May 2015 00:28:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , Simon Josefsson References: <20150524211041.52cde768@latte.josefsson.org> <55622F53.5090201@joelhalpern.com> <20150526221728.02605b82@latte.josefsson.org> <5564E432.9000207@joelhalpern.com> <5564E6C4.4000302@cs.tcd.ie> <5564FCB1.80207@joelhalpern.com> In-Reply-To: <5564FCB1.80207@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: secdir@ietf.org, draft-ietf-sfc-architecture.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:28:43 -0000 On 27/05/15 00:07, Joel M. Halpern wrote: > There may well be something that can be said in the architecture that > would be helpful. My concern is that given teh current IETF > environment, adding the suggested wording to the architecture could > easily lead the IESG to expect mandatory-to-implement data plane packet > authentication and / or encryption. Perhaps it would be more useful to respond to the actual review and not a presumption of what might happen 10 steps down the road in response to what is a really innocuous statement that changing the network changes its security and privacy characteristics. Again though I've yet to read the draft so I'm not saying that text is or is not appropriate. S. > > There are proposals to add optional mechanisms to the dataplane > protocol. The proposals I have seen have no impact on the architecture. > > Yours, > Joel > > On 5/26/15 5:33 PM, Stephen Farrell wrote: >> >> I've yet to read this one so could be plain wrong but I don't >> see that our choices here are an architecture that defines (or >> re-uses) no security mechanisms/services at all or one that >> encrypts everything, but fwiw your response below Joel and earlier >> ones read as if those are the only choices and I find that hard >> to believe. >> >> S. >> >> On 26/05/15 22:22, Joel M. Halpern wrote: >>> Given the expected construction and usage for this, if we rite into the >>> archtiecture that encryption and authentication of data plane messages >>> are mandatory, then >>> presumably we will also write such "mandatory" mechanisms into the data >>> plane mechanism we specify. >>> >>> At which point we are writing a specification which will be widely >>> ignored. >>> >>> Given that we are talking about passing packets through a series of >>> service functions, requiring encryption between them causes a drastic >>> increase in complexity and latency. As far as I can tell from the way >>> customers expect to use this, it is simply unacceptable. For inter-DC >>> (or POP<->DC) operators who wish to protect that traffic wil likely want >>> to do so whether or not they are using service chaining. As such, the >>> protection is not a service chaining issue. >>> >>> So, sorry, but I have to respectfully disagree with you Simon. >>> >>> Yours, >>> Joel >>> >>> On 5/26/15 4:17 PM, Simon Josefsson wrote: >>>> If it is unreasonable to expect that encryption/authentication will be >>>> part of the architecture, I believe there is a significant problem with >>>> this architecture. The argument that security is not necessary within >>>> a single administrative domain is one that I complete disagree with. I >>>> am hoping that I am missing some context here. >>>> >>>> /Simon >>>> >>>>> While the paragraph you suggest looks reasonable, I am somewhat >>>>> concerned if readers draw the conclusion that we expect to include >>>>> data plane authentication and / or encryption mechanisms as a >>>>> mandatory part of the solution. There is no such expectation. While >>>>> there is reason to be concerned about exposure of information across >>>>> the Internet, the document begins by specifically noting that this >>>>> architecture is for use with a single administrative domain. >>>>> >>>>> I am thus concerned that adding the suggested text may give rise to >>>>> unreasonable expectations on solutions which comply with this >>>>> architecture. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 5/24/15 3:10 PM, Simon Josefsson wrote: >>>>>> Hello. >>>>>> >>>>>> I have reviewed this document as part of the security directorate's >>>>>> ongoing effort to review all IETF documents being processed by the >>>>>> IESG. These comments were written primarily for the benefit of the >>>>>> security area directors. Document editors and WG chairs should >>>>>> treat these comments just like any other last call comments. >>>>>> >>>>>> This is an architectural document, so it doesn't have the usual >>>>>> security impact that you can easily review. The Security >>>>>> Considerations section gently refer any security considerations to >>>>>> the future documents that will actually realize the archicture. >>>>>> >>>>>> The security considerations that you would expect to be discussed >>>>>> in an architecural document are those on an architectural level. >>>>>> The archicture proposed here is to change how network services are >>>>>> delivered. The document doesn't give many examples, but my >>>>>> understanding is that the intended services would include firewalls, >>>>>> NAT, proxies, packet filtering, anti-spam measures, anti-DDOS >>>>>> measure, QoS, and so on. >>>>>> >>>>>> The traditional model is static services coupled to network topology >>>>>> and physical resource. The new model introduced by this document, as >>>>>> far as I understand, is a dynamic model where delivery of these >>>>>> services can be moved around more dynamically, by tunneling traffic >>>>>> to the service and back. >>>>>> >>>>>> I may have missed it, but I feel that the security consequences of >>>>>> moving to this new architecture is not discussed in the document. >>>>>> >>>>>> Some obvious security considerations that are introduced with an >>>>>> architecture like this are: >>>>>> >>>>>> 1) When delivery of a service is moved from an on-network-path >>>>>> machine to a machine sitting somewhere else, there ought to be >>>>>> some consideration to authenticating the involved entities and >>>>>> encrypting the traffic between them. >>>>>> >>>>>> 2) Auditing who has powers over a communication channel will be >>>>>> different -- before you evaluated the wires and who had access >>>>>> to the machines connected to the wires. Now you have to review the >>>>>> policies configured in the machines and what external entities are >>>>>> involved, together with the operational aspects of this boxes that >>>>>> perform the service delivery. >>>>>> >>>>>> 3) Moving traffic around raises the challenge how to achieve >>>>>> that >>>>>> without negatively affecting privacy of the traffic. >>>>>> >>>>>> 4) Protecting the SFC configuration and policies is critical for >>>>>> secure operations. Anyone who gains access may be able to >>>>>> modify >>>>>> traffic. >>>>>> >>>>>> If the above is a bit handwavy, allow me to be more concrete. >>>>>> Adding something like the following to the security considerations >>>>>> would at least acknowledge that there are inherent security >>>>>> considerations with this architecture: >>>>>> >>>>>> The architecture described here is different from the current >>>>>> model, and moving to the new model will lead to different security >>>>>> arrangements and modeling. For example, when service functions >>>>>> are moved from on-path static machines to dynamic remote machines, >>>>>> this introduce security and privacy aspects that needs to be >>>>>> addressed. >>>>>> >>>>>> All this said, I still would classify this document as Ready. It >>>>>> mostly just disappoint me that a new architecture can be introduced >>>>>> without containing a significant discussion of security properties. >>>>>> >>>>>> /Simon >>>>>> >>>> >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> From nobody Tue May 26 16:41:54 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4A01B3326; Tue, 26 May 2015 16:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptgZEnoki0zc; Tue, 26 May 2015 16:41:48 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7F91B3323; Tue, 26 May 2015 16:41:48 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-cf-556504bbcb54 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id CA.0A.03451.BB405655; Tue, 26 May 2015 19:41:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t4QNfklB009172; Tue, 26 May 2015 19:41:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4QNfhvc024537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 May 2015 19:41:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4QNfhNG026076; Tue, 26 May 2015 19:41:43 -0400 (EDT) Date: Tue, 26 May 2015 19:41:42 -0400 (EDT) From: Benjamin Kaduk To: "Carlos Pignataro (cpignata)" In-Reply-To: <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> Message-ID: References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1165714292-1432682669=:22210" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA02SX0hTURzHO/febdfhtetV8/gv8KYo/i1QWWQrqYc9iUJ7KIq8bSc33Kbt TvMftIj2YGEWmm0WOJQeHGETKaPAmvngn9RlgiYtNCMQE1np1ITa3Zr69j18Pr8v53B+JM4M ieJJrcGEjAZOx4qlBCORp2W/JpDy6Ox2nsy7OkDIZr3zuOzRzn1ctmZfIGSe/o+S0yJF6x+n SNHdvYUprONuieL39C9xCXFBWqhGOm0NMubKy6SaT3YfUdWbWuueWcTNYO5wEwgjIZ0HbfNu PJgPwSlPr7gJSEmG7sLg0/UuEDw4AbRMfQeCxdAuDK7+KAkCM4D9Y2siARB0JvSMTwaymE6B 1hWnWMjRdAG8+e0BJgzg9BKAY83v/U0kGUXLoa8lRXDC6JPQNdkX8Cm6CE60T/y/hhtA++Nn gdIYOgs6BluJoBQJR6xLgYzTpXDDZhEFcxEc+NuDtwDGtk+z7dNs+7RgToNvvW4QzJnw65xF HHIcd7ygE4h7QJJaX5+t57Q6HqmyeRVnMCBjdn6OXmvKQerqPhD4q7PsANh6x7oATQI2nJIN qZSMiKvh6/QuEEdibAzFbqmVTMSVSnWdhuM1l43VOsS7ACRxNpq6vuNnlJqrq0fGyhBKIAk2 lurbjDjH0OWcCVUgVIWMIZpIkiykUnGkZCKNqBzVXtXqTHsYI8OE8nB/uQ/zOxRfxel5bXmQ j4Lk+FgqThimBaCpNuzOhnZvGcT6nxJFpQtWuH8zd6eX/cWYv7hgWLg1b+L2ULwZWBo6h9/M GU5JThTXr146jsYat8uiM6RLi6qfK3QiUNwlC8/XHGhGyQdnyusdn7F8ec+Z2zcGt4s3ZOnK e0kLHcnXGnITPI6mUckXe9uHpbJbbUf6nXlRpR3Nm0+szxM2H7oHfMuWjJFG684LuzTL9Spt OrHfXDCFvaxoF69fZAlewx3LwI089w8L+TVvVgMAAA== Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:41:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1165714292-1432682669=:22210 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Carlos, On Tue, 26 May 2015, Carlos Pignataro (cpignata) wrote: > > On May 25, 2015, at 11:01 PM, Benjamin Kaduk wrote: > > > > insist that encryption always be used, but please do not claim that bei= ng > > in a single administrative domain excuses the operator from considering > > whether encryption is necessary. > > > > My point was a different one: that SFC does not change these > requirements. > > I may have misunderstood, but what I read in Simon's review (admittedly > oversimplified) was: in SFC you move services from on-network-path > (which, as an aside, is really the other way around; it is moving from > creating an on-network-path steering of network topology through the > service) to a machine =E2=80=98elsewhere' =E2=80=94 and thus, consequentl= y, you have to > encrypt. I do not think anyone is saying "you must encrypt". My take of the key point is that SFC is (potentially) going to be making the actual physical flow of data very different from how it currently is, and potentially also divorced from the conceptual topology of the service function chain (if the service functions are laid out "strangely" compared to the physical topology). This has the potential to drastically change the security issues an operator deploying things has to consider, and an architecture document should point out that both protocol designers implementing the architecture and operators using such protocols should be aware of the new security environment. Thus, we are proposing that it is mandatory for protocol designers and operators to consider whether they should be encrypting, but not mandatory for them to encrypt (if they are satisfied with their topology). > My point is that the logic above (which, again, I may have > misunderstood) does not follow. > > There may be additional security and privacy considerations needed in > the DC, in mobile networks, etc. However, the SFC architecture does not > change that, and mandating encryption on SFCs might not be the right > answer. As we wrote, the solution realizing the architecture need to > perform part of that analysis. I think that the SFC architecture does have the potential to change where additional security and privacy considerations are needed. There can definitely be security and privacy considerations within a single administrative domain, and I do not think the current document has sufficient acknowledgement of the potential for the new architecture to require drastically different security and privacy measures in some (not all!) cases. (Yes, I did read through it before composing this mail.) I see some text in each of the three areas listed which sort-of addresses my concerns, ("Used transport mechanisms should satisfy the security requirements of the specific SFC deployment", "These include [...] potential confidentiality issues of that policy", "solutions should consider whether there is a risk of sensitive information slipping out of the operators control. Issues of information exposure should also consider flow analysis"), but they could easily be missed by the reader, and do not convey a single central sense that adopting SFC will involve a full reevaluation of network security policy. That reevaluation will include security/privacy issues for the original payload as well as the classification and encapsulation data added by the SFC protocol(s). > As I had said, I am more than happy adding text strengthening the > security considerations =E2=80=94 as long as we do not mandate a solution= at a > specific layer. To partially crib from Simon's proposal, how about The architecture described here is different from the current model, and moving to the new model could lead to different security arrangements and modeling. For example, when service functions are moved from on-path static machines to dynamic remote machines, this can change the flow of data through the network, and the security and privacy considerations of the protocol and deployment will need to be reevaluated in light of the new topology. The word "reevaluated" is intended to indicate that a new analysis should be performed, but not that a different conclustion must necessarily be reached. -Ben P.S. "consdierations" in the second paragraph of section 6 is a typo ---559023410-1165714292-1432682669=:22210-- From nobody Tue May 26 22:13:27 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938531A87AF; Tue, 26 May 2015 22:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbEAiQezbTbi; Tue, 26 May 2015 22:13:25 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CF11A87AC; Tue, 26 May 2015 22:13:24 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4R5DGsa001435 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 27 May 2015 07:13:17 +0200 Date: Wed, 27 May 2015 07:13:15 +0200 From: Simon Josefsson To: Benjamin Kaduk Message-ID: <20150527071315.17b3b5f5@latte.josefsson.org> In-Reply-To: References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/d/M_BP8axIxo1jANMHAl5vU"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 05:13:26 -0000 --Sig_/d/M_BP8axIxo1jANMHAl5vU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Den Tue, 26 May 2015 19:41:42 -0400 (EDT) skrev Re: [secdir] Review of draft-ietf-sfc-architecture-08: > Hi Carlos, >=20 > On Tue, 26 May 2015, Carlos Pignataro (cpignata) wrote: >=20 > > > On May 25, 2015, at 11:01 PM, Benjamin Kaduk > > > wrote: > > > > > > insist that encryption always be used, but please do not claim > > > that being in a single administrative domain excuses the operator > > > from considering whether encryption is necessary. > > > > > > > My point was a different one: that SFC does not change these > > requirements. > > > > I may have misunderstood, but what I read in Simon's review > > (admittedly oversimplified) was: in SFC you move services from > > on-network-path (which, as an aside, is really the other way > > around; it is moving from creating an on-network-path steering of > > network topology through the service) to a machine =E2=80=98elsewhere' = =E2=80=94 > > and thus, consequently, you have to encrypt. >=20 > I do not think anyone is saying "you must encrypt". Agreed. > To partially crib from Simon's proposal, how about >=20 > The architecture described here is different from the current model, > and moving to the new model could lead to different security > arrangements and modeling. For example, when service functions are > moved from on-path static machines to dynamic remote machines, this > can change the flow of data through the network, and the security and > privacy considerations of the protocol and deployment will need to be > reevaluated in light of the new topology. >=20 > The word "reevaluated" is intended to indicate that a new analysis > should be performed, but not that a different conclustion must > necessarily be reached. That's better, thank you. I believe it would have been better to include a discussion of security concerns in the architecture document itself -- doing security right sometimes requires architectural changes, so if it is done later you might realize serious issues -- but barring that, adding a statement to acknowledge that no security analysis has been done, and that it has to be done, seems appropriate. /Simon --Sig_/d/M_BP8axIxo1jANMHAl5vU Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZVJrAAoJEIYLf7sy+BGdRegH/1gN8u+rcnqHo3Tmo0tAgFrm 0JMMXZrNXAHVm3DJ1BXdeOkVLjlAWnbNllDqNFrYjgYzOehZ/Gx5p9VriRUMADej MNGzgNwB0/MHuAFP9JPIAfXFkFcvVzknWYzVWX95wM/slyLUuU16POd0ElEjU/Fn gquWTAJHL6MS3h+GIvCs3CISo7rr5pblOWTvsx+TZg5C5kpa15+10gh9KzTbqNwR 8xEx8huFqeg3RpXHV3DPYI8frHYxGUi0xn4azC4oIOsD8xGGmCTa0Q0mvdFDScZE dUT2XwYHdDRuV4uMtkbEGYjY5N9xYQ1MqfCw/VsvF3/KwMHB+AApmEUPrZ+QweY= =LoTv -----END PGP SIGNATURE----- --Sig_/d/M_BP8axIxo1jANMHAl5vU-- From nobody Wed May 27 09:50:46 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A694F1A871E; Wed, 27 May 2015 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpY9G2UWXKl3; Wed, 27 May 2015 09:50:40 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F9B1A8720; Wed, 27 May 2015 09:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8098; q=dns/txt; s=iport; t=1432745437; x=1433955037; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1bRsErfCkxDfEqjsZh4qDmwjCF57MEeve2YsBmFKGvY=; b=ALRyqwZlukV1T09eg1nDrfIm6HVFG/gGu05ys6rDgVMYCPUSFDX0/hPN U/xUf2VI0kQQJ5cgVR2BRvJ8TY5GXQjHrWgJ1Ce067Bat8RJVlOuTxUSg kxXandUh6cwcaDfkMbnrIep6wxpcLVJzs09w6o+ljREkYo+QEk59oEMi9 A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArBACL9WVV/4QNJK1cDoMCgTIGgxm9XmYJh1ACgT44FAEBAQEBAQGBCoQiAQEBAwEjVgULAgEIEgYqAgIyFw4CBA4FDg2ICgitVaQmAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s6hDMBAVAHgmgvgRYFkwiCEoFDhzqBKYNxgn+LPYNZI4FmJByBFD5vgQw6gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="asc'?scan'208";a="153831452" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP; 27 May 2015 16:50:36 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4RGoawL007351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 16:50:36 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Wed, 27 May 2015 11:50:36 -0500 From: "Carlos Pignataro (cpignata)" To: Benjamin Kaduk Thread-Topic: [secdir] Review of draft-ietf-sfc-architecture-08 Thread-Index: AQHQllVoiI0EciI2k0ypB2MTIDGLzJ2L5tT3gAIA+oCAAJkTAIAAwU8AgAEfd4A= Date: Wed, 27 May 2015 16:50:35 +0000 Message-ID: <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.90] Content-Type: multipart/signed; boundary="Apple-Mail=_EA4AF42B-E3FD-4B1B-94A9-9035CBEF67F2"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:50:45 -0000 --Apple-Mail=_EA4AF42B-E3FD-4B1B-94A9-9035CBEF67F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Ben, Thanks for the follow-up, please see inline. > On May 26, 2015, at 7:41 PM, Benjamin Kaduk wrote: >=20 > Hi Carlos, >=20 > On Tue, 26 May 2015, Carlos Pignataro (cpignata) wrote: >=20 >>> On May 25, 2015, at 11:01 PM, Benjamin Kaduk wrote: >>>=20 >>> insist that encryption always be used, but please do not claim that = being >>> in a single administrative domain excuses the operator from = considering >>> whether encryption is necessary. >>>=20 >>=20 >> My point was a different one: that SFC does not change these >> requirements. >>=20 >> I may have misunderstood, but what I read in Simon's review = (admittedly >> oversimplified) was: in SFC you move services from on-network-path >> (which, as an aside, is really the other way around; it is moving = from >> creating an on-network-path steering of network topology through the >> service) to a machine =E2=80=98elsewhere' =E2=80=94 and thus, = consequently, you have to >> encrypt. >=20 > I do not think anyone is saying "you must encrypt". >=20 > My take of the key point is that SFC is (potentially) going to be = making > the actual physical flow of data very different from how it currently = is, > and potentially also divorced from the conceptual topology of the = service > function chain (if the service functions are laid out "strangely" = compared > to the physical topology). This has the potential to drastically = change > the security issues an operator deploying things has to consider, and = an > architecture document should point out that both protocol designers > implementing the architecture and operators using such protocols = should be > aware of the new security environment. Fully agree =E2=80=94 and I believe this is what the current Security = Considerations section achieves. In particular, Section 6 highlights the areas of the new architecture = (Overlay, Classification, Encapsulation) of which designers and = operators ought to be aware. > Thus, we are proposing that it is > mandatory for protocol designers and operators to consider whether = they > should be encrypting, but not mandatory for them to encrypt (if they = are > satisfied with their topology). Further specifically, the "SFC Encapsulation=E2=80=9D seems to cover = this. But as I said, I would not oppose strengthening this section even more. >=20 >> My point is that the logic above (which, again, I may have >> misunderstood) does not follow. >>=20 >> There may be additional security and privacy considerations needed in >> the DC, in mobile networks, etc. However, the SFC architecture does = not >> change that, and mandating encryption on SFCs might not be the right >> answer. As we wrote, the solution realizing the architecture need to >> perform part of that analysis. >=20 > I think that the SFC architecture does have the potential to change = where > additional security and privacy considerations are needed. There can > definitely be security and privacy considerations within a single > administrative domain, and I do not think the current document has > sufficient acknowledgement of the potential for the new architecture = to > require drastically different security and privacy measures in some = (not > all!) cases. (Yes, I did read through it before composing this mail.) I do not disagree. Are there areas beyond what=E2=80=99s already in the = Security considerations that require specific focus? >=20 > I see some text in each of the three areas listed which sort-of = addresses > my concerns, ("Used transport mechanisms should satisfy the security > requirements of the specific SFC deployment", "These include [...] > potential confidentiality issues of that policy", "solutions should > consider whether there is a risk of sensitive information slipping out = of > the operators control. Issues of information exposure should also > consider flow analysis"), but they could easily be missed by the = reader, > and do not convey a single central sense that adopting SFC will = involve a > full reevaluation of network security policy. This is the key of the review, IMHO. On one hand, you seem to = acknowledge that your security concerns are already addressed with the = existing text. On the other hand, you seem to want to child-proof the = text in case a reader misses what is already there already addressing = the concern. I support your view of elevating the message with a central sense of = =E2=80=98this is an architecture and re-evaluate security=E2=80=99. = However, that is not (in my read) what the text proposed by Simon = achieved. I=E2=80=99ll be happy to add a short preamble sentence/paragraph to = Section 6 with this, if the WG agrees. > That reevaluation will > include security/privacy issues for the original payload as well as = the > classification and encapsulation data added by the SFC protocol(s). >=20 >=20 Yes =E2=80=94 which is what the doc already says. >> As I had said, I am more than happy adding text strengthening the >> security considerations =E2=80=94 as long as we do not mandate a = solution at a >> specific layer. >=20 > To partially crib from Simon's proposal, how about >=20 > The architecture described here is different from the current model, = and > moving to the new model could lead to different security arrangements = and > modeling. For example, when service functions are moved from on-path > static machines to dynamic remote machines, this can change the flow = of > data through the network, and the security and privacy considerations = of > the protocol and deployment will need to be reevaluated in light of = the > new topology. >=20 =E2=80=9CReevaluated=E2=80=9D is significantly better, of course. = Here=E2=80=99s another proposal: "The architecture described here is different from the current model, = and moving to the new model could lead to different security arrangements = and modeling. In the SFC architecture, a relatively static = topologically-dependent deployment model is replaced with the chaining of sets of service = functions. This can change the flow of data through the network, and the security = and privacy considerations of the protocol and deployment will need to be reevaluated in light of the model.=E2=80=9D Simon, Ben, Joel, Jim, Thomas, Alia, WG, Thoughs? =E2=80=94 Carlos. > The word "reevaluated" is intended to indicate that a new analysis = should > be performed, but not that a different conclustion must necessarily be > reached. >=20 > -Ben >=20 > P.S. "consdierations" in the second paragraph of section 6 is a typo --Apple-Mail=_EA4AF42B-E3FD-4B1B-94A9-9035CBEF67F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZfXbAAoJEIXgpQGOZny9gg4QAIO+uBCqSjUrEgpsc/oCdT0o RQaKTxl8sca4N/nFJYUgD3wDNsOjgIADldl0oiG6kbS2gRmnCiZSkcv0eFXA8Avn b4SiE7cUs1jQzz1TrVHxU7Fy+HJXEijl+hm2QvfcnOfxNtTw9cqdZHPc8fpt9yCB CgplCaIE8JbApXdnCnhlqFp0H5ZTW2i0CTslmZeYXROtEaOKJ9PUR2VppwIQeuLu ZqqM1Nv28M5Q8LsGdvOXE/yh+Map9o5ARr7pKwU9y4x8bYG2sHnot+WyLY4LHxGm 1DSq8l1HqlrLM6fx22jFt5IYxmgDUcpHsaufBHryldcRaxVUMmO9i7FTDLl8jjgX bLFbgRbgEiSYGc/l09rzWI9143NYq4AFpX/Pt04hlmKyavZFtIFjql769i8WQYwr zr+5q5lvvEOuoZphbiiN1rwa5t4tkJxTqmj5mhINlDRjig8SGdvbihg4LcmMjCrn 7yuN5+cNEbms6CbiG0XI99JnZLc6/3DE9WRWb4eabJNBG0DC0K+xP0sPxzckDhGb eWZ9rf3s/kVELapfFfwyP+IVhQoNJIxV54yztc5aaEF4E7FHV0tc3rrzIUEB/i/9 D5WjSCldfCwPJ/GY6/dLDnatQ366Ip5qUyXHW8e43N3BSYbyANdetANrskmyPv5O h85UfLsV9p8fpJ8aDMdJ =Sd4/ -----END PGP SIGNATURE----- --Apple-Mail=_EA4AF42B-E3FD-4B1B-94A9-9035CBEF67F2-- From nobody Wed May 27 09:54:17 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352561A871E; Wed, 27 May 2015 09:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfiSZg-KH7q6; Wed, 27 May 2015 09:54:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE041A8710; Wed, 27 May 2015 09:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4339; q=dns/txt; s=iport; t=1432745651; x=1433955251; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WSMRJFBM98GFXZaaHAfxyFUObxVhUppBFG8oI8gpNWQ=; b=PMexTBAge8FQR8zUqaE0sXgoDWM1HDgouh89XQgD0QNKyTT5W93G9Knb qBuuBGnJZLOCxLgDUobcge2uVE0nntuMpNV01mpK/KPJphm+LEMUJnETc grh1UwY8dkqkK5Ir3LMkOBFne1uvZA+9HnQEo3PuaQyY4wGBu8pYwg0jm o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BHBQCh9WVV/4oNJK1cgxCBMgaDGb1eiD8CgT5MAQEBAQEBgQuEIgEBAQMBI1YFCwIBCBIGFRUCAjIXDgIEDgUODYgKCK1VpCYBAQEBAQEBAQEBAQEBAQEBAQEBGYo4gQKFBQcKgl4vgRYFkwiCEoFDhzqBKYNxgn+PFiODeG+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="asc'?scan'208";a="15209458" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 27 May 2015 16:54:10 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4RGs9lU030679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 16:54:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Wed, 27 May 2015 11:54:09 -0500 From: "Carlos Pignataro (cpignata)" To: Simon Josefsson Thread-Topic: [secdir] Review of draft-ietf-sfc-architecture-08 Thread-Index: AQHQllVoiI0EciI2k0ypB2MTIDGLzJ2L5tT3gAIA+oCAAJkTAIAAwU8AgABcooCAAMPTAA== Date: Wed, 27 May 2015 16:54:08 +0000 Message-ID: <83F188A4-8E60-479E-A676-EB910E3EC900@cisco.com> References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <20150527071315.17b3b5f5@latte.josefsson.org> In-Reply-To: <20150527071315.17b3b5f5@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.90] Content-Type: multipart/signed; boundary="Apple-Mail=_1A903881-ADAF-48D0-9FC8-D29E7A5F223E"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:54:12 -0000 --Apple-Mail=_1A903881-ADAF-48D0-9FC8-D29E7A5F223E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Simon, > On May 27, 2015, at 1:13 AM, Simon Josefsson = wrote: >=20 > Den Tue, 26 May 2015 19:41:42 -0400 (EDT) > skrev Re: [secdir] Review of draft-ietf-sfc-architecture-08: >=20 >> Hi Carlos, >>=20 >> On Tue, 26 May 2015, Carlos Pignataro (cpignata) wrote: >>=20 >>>> On May 25, 2015, at 11:01 PM, Benjamin Kaduk >>>> wrote: >>>>=20 >>>> insist that encryption always be used, but please do not claim >>>> that being in a single administrative domain excuses the operator >>>> from considering whether encryption is necessary. >>>>=20 >>>=20 >>> My point was a different one: that SFC does not change these >>> requirements. >>>=20 >>> I may have misunderstood, but what I read in Simon's review >>> (admittedly oversimplified) was: in SFC you move services from >>> on-network-path (which, as an aside, is really the other way >>> around; it is moving from creating an on-network-path steering of >>> network topology through the service) to a machine =E2=80=98elsewhere'= =E2=80=94 >>> and thus, consequently, you have to encrypt. >>=20 >> I do not think anyone is saying "you must encrypt". >=20 > Agreed. >=20 >> To partially crib from Simon's proposal, how about >>=20 >> The architecture described here is different from the current model, >> and moving to the new model could lead to different security >> arrangements and modeling. For example, when service functions are >> moved from on-path static machines to dynamic remote machines, this >> can change the flow of data through the network, and the security and >> privacy considerations of the protocol and deployment will need to be >> reevaluated in light of the new topology. >>=20 >> The word "reevaluated" is intended to indicate that a new analysis >> should be performed, but not that a different conclustion must >> necessarily be reached. >=20 > That's better, thank you. I believe it would have been better to > include a discussion of security concerns in the architecture document > itself -- doing security right sometimes requires architectural > changes, so if it is done later you might realize serious issues -- = but > barring that, adding a statement to acknowledge that no security > analysis has been done, and that it has to be done, seems appropriate. A security analysis has been done, resulting in the identification of = key areas of security considerations to be taken into account during = protocol design and solution deployment. At an architectural level, Section 6 identifies the architectural = building blocks and their specific security considerations, to be = addressed by the realization of the architecture. This statement is not = an acknowledgement that no security analysis has been done. >=20 > /Simon > -Ben >=20 > P.S. "consdierations" in the second paragraph of section 6 is a typo Thank you, Ben. This is already corrected in our working copy. Best, =E2=80=94 Carlos. --Apple-Mail=_1A903881-ADAF-48D0-9FC8-D29E7A5F223E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZfavAAoJEIXgpQGOZny9NwsP/1erh0tnVXDAXT9t/kIL2rQu Ep1I//3Zo6zxiQYQ0/Yi7ymJ0pAb67v9FbAKzYVUTjgu2Tr5UqODDn/pHkS3sWPv fSTRtMxwLwXVbeBjSWpZhe83mNx0gQzfno4l/dNoLyuJdACMvMRV87i27TdqPXeL CJFlNB/inX0CEl0TYTZ3d/4M8ENY30y6F0abTiE+jm+EtnaG7GKNl/7x+EpH1X/6 eFJensSwuUUANxFtv29rtfvuMza3IRxcThR4JtReH/bl+feLGb6r4t6SNxQm0lHC zkrIuWEfcrV8a552jEhdWpYBrVn3yXoGQjdDTiOJ9CnKBelk/z94EdBbcDvJyWzj Qj2CRWifH+A8D5eRPXr2Mn+/YoQt3nxRrQLFun/veRf9bVTJ7A9KQMRR2jcJe7DQ 7IhRlhn2DOh9oDGT2UlE2lKWDcxeEKQ3wuCQnxlm41LkbsVzaY+TV+xbdmd+p/At EcGrjxCH/KVi9+U6wKlutIQCx9ymc0e0aToubkfk1lmzNJfDwJ58oRPepKCbIwcw sPaq0V9cUbn0E/GN2Aq5dxDuLOgHE8haFib5pG2/fSXQPSUKrMrbez7aC1zl7X0v /P3GKMX+CTW7SM31J3qEWnTSgM4nPdjSu5+uP7I1Z4Cwd6xRlGI3+GRtGRzjFRvR ZTVNipVMyQeOA751NY40 =M1O8 -----END PGP SIGNATURE----- --Apple-Mail=_1A903881-ADAF-48D0-9FC8-D29E7A5F223E-- From nobody Wed May 27 10:00:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A131A8740; Wed, 27 May 2015 10:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RTg6zd1u4Y6; Wed, 27 May 2015 10:00:04 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F461A8713; Wed, 27 May 2015 10:00:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5F1672510AB; Wed, 27 May 2015 10:00:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8F437251087; Wed, 27 May 2015 10:00:03 -0700 (PDT) Message-ID: <5565F812.2080301@joelhalpern.com> Date: Wed, 27 May 2015 13:00:02 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , Benjamin Kaduk References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> In-Reply-To: <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 17:00:06 -0000 While I can live with the change you propose, I do not think it improves the document in any way. Yours, Joel On 5/27/15 12:50 PM, Carlos Pignataro (cpignata) wrote: > Hi, Ben, > ... > > “Reevaluated” is significantly better, of course. Here’s another proposal: > > "The architecture described here is different from the current model, and > moving to the new model could lead to different security arrangements and > modeling. In the SFC architecture, a relatively static topologically-dependent > deployment model is replaced with the chaining of sets of service functions. > This can change the flow of data through the network, and the security and > privacy considerations of the protocol and deployment will need to be > reevaluated in light of the model.” > > Simon, Ben, Joel, Jim, Thomas, Alia, WG, > > Thoughs? > > — Carlos. > >> The word "reevaluated" is intended to indicate that a new analysis should >> be performed, but not that a different conclustion must necessarily be >> reached. >> >> -Ben >> >> P.S. "consdierations" in the second paragraph of section 6 is a typo > From nobody Wed May 27 10:52:24 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D759A1A894E for ; Wed, 27 May 2015 10:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogkaBxpQ_YXQ for ; Wed, 27 May 2015 10:52:23 -0700 (PDT) Received: from gateway30.websitewelcome.com (gateway30.websitewelcome.com [192.185.148.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021C91A8938 for ; Wed, 27 May 2015 10:52:23 -0700 (PDT) Received: by gateway30.websitewelcome.com (Postfix, from userid 500) id 51158279FF992; Wed, 27 May 2015 12:52:22 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway30.websitewelcome.com (Postfix) with ESMTP id 41E55279FF8B7 for ; Wed, 27 May 2015 12:52:22 -0500 (CDT) Received: from [173.73.121.66] (port=60713 helo=[192.168.1.6]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YxfV2-00021D-8l; Wed, 27 May 2015 12:52:16 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2015 13:52:14 -0400 Message-Id: <42245B4F-030A-485B-A218-3BF0357219AC@ieca.com> To: draft-ietf-bmwg-traffic-management@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.66 X-Exim-ID: 1YxfV2-00021D-8l X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.6]) [173.73.121.66]:60713 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: The IESG , secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-bmwg-traffic-management-4 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 17:52:24 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. Summary: Ready with a minor concern/question. Major Concerns: none Minor Concerns: Was there any thought to how the tcpinc efforts might = affect the ability to gather measurements? From nobody Wed May 27 11:16:25 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE811A89F9; Wed, 27 May 2015 11:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8nYGYAzcBcT; Wed, 27 May 2015 11:16:17 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403431A89FC; Wed, 27 May 2015 11:16:09 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-6d-556609e72423 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id BC.1F.03389.7E906655; Wed, 27 May 2015 14:16:08 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t4RIG6v5000719; Wed, 27 May 2015 14:16:07 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4RIG4Uq032042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 May 2015 14:16:05 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4RIG39i015702; Wed, 27 May 2015 14:16:03 -0400 (EDT) Date: Wed, 27 May 2015 14:16:03 -0400 (EDT) From: Benjamin Kaduk To: "Carlos Pignataro (cpignata)" In-Reply-To: <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> Message-ID: References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1818982703-1432749639=:22210" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsUixG6novuCMy3U4GuJxad3O1gsbny6zWwx 489EZosPCx+yWNzbcondgdVjyu+NrB5Llvxk8ph55iK7x5fLn9kCWKK4bFJSczLLUov07RK4 Mo7dOchWcNWoYvLC6ywNjL81uhg5OSQETCTOzfvOAmGLSVy4t54NxBYSWMwkceacdxcjF5C9 kVHi/JJDrBDOISaJfauXskM4DYwSa++vZgJpYRHQlri64iI7iM0moCIx881GsFEiAmYSjY8n MYE0MAs8YZQ43XeEsYuRg0NYwE7i+wQVEJNTwFai/1kmSDmvgKNE28wHTBDzdzFJLNrzCew8 UQEdidX7p7BAFAlKnJz5BMxmFgiUePjoKhuE7Shx699tpgmMQrOQlM1CUjYLSRmErS5x4NNF RghbW+L+zTa4miWzV7AsYGRbxSibklulm5uYmVOcmqxbnJyYl5dapGuil5tZopeaUrqJERRT nJL8Oxi/HVQ6xCjAwajEw3tAOjVUiDWxrLgy9xCjJAeTkijvT4a0UCG+pPyUyozE4oz4otKc 1OJDjBIczEoivG4fgcp5UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4 13IADRUsSk1PrUjLzClBSDNxcIIM5wEafh6khre4IDG3ODMdIn+KUVFKnPcGSEIAJJFRmgfX C0t5rxjFgV4R5mUGJkAhHmC6hOt+BTSYCWiw2dEUkMEliQgpqQbGxJzTte7/ate0vjA+XPAl PeVerqRaomB6c3KDto/k3kDh8qnf5uqEFk03mzUnrGJy46S0/DXccSE8jw5PNXv+w4Rv4gWu a1vcvt6smfOQZdMD7jOCLW6pyj+nmH9ZkDf90P4vQmGn20+t5PX7sO5PX7rx7ZVTK2cxPqnO O1M1de0aryOb/M+zKrEUZyQaajEXFScCALppJd9UAwAA Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 18:16:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1818982703-1432749639=:22210 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Wed, 27 May 2015, Carlos Pignataro (cpignata) wrote: > > > On May 26, 2015, at 7:41 PM, Benjamin Kaduk wrote: > > > > > > My take of the key point is that SFC is (potentially) going to be makin= g > > the actual physical flow of data very different from how it currently i= s, > > and potentially also divorced from the conceptual topology of the servi= ce > > function chain (if the service functions are laid out "strangely" compa= red > > to the physical topology). This has the potential to drastically chang= e > > the security issues an operator deploying things has to consider, and a= n > > architecture document should point out that both protocol designers > > implementing the architecture and operators using such protocols should= be > > aware of the new security environment. > > Fully agree =E2=80=94 and I believe this is what the current Security > Considerations section achieves. I think we disagree on what the current Security Considerations section achieves. > In particular, Section 6 highlights the areas of the new architecture > (Overlay, Classification, Encapsulation) of which designers and > operators ought to be aware. > > > Thus, we are proposing that it is > > mandatory for protocol designers and operators to consider whether they > > should be encrypting, but not mandatory for them to encrypt (if they ar= e > > satisfied with their topology). > > Further specifically, the "SFC Encapsulation=E2=80=9D seems to cover this= =2E So, you believe that the SFC Encapsulation section is intended to cover the potential need for confidentiality protection of the plaintext payload which is being encapsulated by SFC? I think that given the way the current text flows from "an operator may consider the SFC Metadata as sensitive" straight into "from a privacy perspective, a user may be concerned about the operator revealing data about [...] the customer", it causes me to read that privacy concern as applying only to the SFC Metadata (i.e., not to the original payload). Likewise for the "risk of sensitive information slipping out of the operators [sic] control"; since the paragraph started with the SFC Metadata, it seems like this paragraph may apply only to the metadata. > But as I said, I would not oppose strengthening this section even more. But more generally, I think the rhetoric is better (stronger) if it is of the form "you should do this thing (general concept); here are some concrete examples", rather than "you should do this list of things" without giving the overarching motivation. This is a lot of why I am pushing for added (summary) text. > > I think that the SFC architecture does have the potential to change whe= re > > additional security and privacy considerations are needed. There can > > definitely be security and privacy considerations within a single > > administrative domain, and I do not think the current document has > > sufficient acknowledgement of the potential for the new architecture to > > require drastically different security and privacy measures in some (no= t > > all!) cases. (Yes, I did read through it before composing this mail.) > > I do not disagree. Are there areas beyond what=E2=80=99s already in the S= ecurity > considerations that require specific focus? I think I only have the points I mentioned above (lack of clarity regarding protecting the original payload, and clear rhetoric). But let's see if Simon has anything else to add, as well. > > I see some text in each of the three areas listed which sort-of address= es > > my concerns, ("Used transport mechanisms should satisfy the security > > requirements of the specific SFC deployment", "These include [...] > > potential confidentiality issues of that policy", "solutions should > > consider whether there is a risk of sensitive information slipping out = of > > the operators control. Issues of information exposure should also > > consider flow analysis"), but they could easily be missed by the reader= , > > and do not convey a single central sense that adopting SFC will involve= a > > full reevaluation of network security policy. > > This is the key of the review, IMHO. On one hand, you seem to > acknowledge that your security concerns are already addressed with the > existing text. On the other hand, you seem to want to child-proof the > text in case a reader misses what is already there already addressing > the concern. I'm sorry that my message was unclear; I was not intending to "acknowledge that [my concerns] are already addressed", but rather to say that the existing text gets some of the way there, but there were still things missing. (Hopefully this email is helping clarify already.) > > That reevaluation will > > include security/privacy issues for the original payload as well as the > > classification and encapsulation data added by the SFC protocol(s). > > > > > > Yes =E2=80=94 which is what the doc already says. Just to ensure we're getting through to each other, do you mind pointing to the specific text that you have in mind that is supposed to already say this? > =E2=80=9CReevaluated=E2=80=9D is significantly better, of course. Here=E2= =80=99s another proposal: > > "The architecture described here is different from the current model, and > moving to the new model could lead to different security arrangements and > modeling. In the SFC architecture, a relatively static topologically-depe= ndent > deployment model is replaced with the chaining of sets of service functio= ns. > This can change the flow of data through the network, and the security an= d > privacy considerations of the protocol and deployment will need to be > reevaluated in light of the model.=E2=80=9D I might add in "new" or "chained" before the very last "model", but this seems to catch the sentiment I was going for. The idea would be to insert this as a new paragraph after the first paragraph of section 6? Thank you, Ben ---559023410-1818982703-1432749639=:22210-- From nobody Wed May 27 11:53:35 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D481A8737; Wed, 27 May 2015 11:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcD8tpE_QByM; Wed, 27 May 2015 11:53:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837111A8734; Wed, 27 May 2015 11:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16793; q=dns/txt; s=iport; t=1432752812; x=1433962412; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kolSzwAE8QfYlbj+OFYBi/3/06LfDM9MdWeJ2C1SYhE=; b=kj8DtOQWIa4FZOsgYFnGoDclbbbbcN7M1gwZS4Cd2zRRNgYqmR8PCFD8 6LZVjB0RDb2GuLjk4kxH8oj3Sxu8Kdnzd+tlwrCAnZ4etJRuNv+kdMpV4 5NoODuQNm2zd41WZA5HpeqE3/ptUZX6NT/lt5EfG2TCJE9UGtx57R71nR 0=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJBQDtEWZV/5NdJa1cDoI3S4EyBoMZvV+IPwKBQEwBAQEBAQGBC4QiAQEBAwEjVgULAgEGAhIGKgICMhcOAgQOBQ6IFwiREp0RpBoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqFBQeCaC+BFgEEkEyCPIISgUOHOpcvI4M6Pm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,507,1427760000"; d="asc'?scan'208,217";a="423096635" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 27 May 2015 18:53:20 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4RIrKlQ016943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 18:53:20 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Wed, 27 May 2015 13:53:20 -0500 From: "Carlos Pignataro (cpignata)" To: Benjamin Kaduk Thread-Topic: [secdir] Review of draft-ietf-sfc-architecture-08 Thread-Index: AQHQllVoiI0EciI2k0ypB2MTIDGLzJ2L5tT3gAIA+oCAAJkTAIAAwU8AgAEfd4CAABfhgIAACmqA Date: Wed, 27 May 2015 18:53:19 +0000 Message-ID: References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.90] Content-Type: multipart/signed; boundary="Apple-Mail=_50254197-7287-45DF-B9C7-57DF5C86C7F9"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 18:53:34 -0000 --Apple-Mail=_50254197-7287-45DF-B9C7-57DF5C86C7F9 Content-Type: multipart/alternative; boundary="Apple-Mail=_F82BB1D5-8B5C-492F-88A9-49A0F78B0838" --Apple-Mail=_F82BB1D5-8B5C-492F-88A9-49A0F78B0838 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben, > On May 27, 2015, at 2:16 PM, Benjamin Kaduk wrote: >> I do not disagree. Are there areas beyond what=E2=80=99s already in = the Security >> considerations that require specific focus? >=20 > I think I only have the points I mentioned above (lack of clarity > regarding protecting the original payload, and clear rhetoric). OK, let=E2=80=99s make sure we have a way forward for both of them. >>> That reevaluation will >>> include security/privacy issues for the original payload as well as = the >>> classification and encapsulation data added by the SFC protocol(s). >>>=20 >>>=20 >>=20 >> Yes =E2=80=94 which is what the doc already says. >=20 > Just to ensure we're getting through to each other, do you mind = pointing > to the specific text that you have in mind that is supposed to already > say this? >=20 What changes the flow of data in the network (i.e., direct user traffic = to the =E2=80=98remote machine=E2=80=99 (as you called it) is the = overlay =E2=80=94 that is why in the =E2=80=9CService Overlay=E2=80=9D = section of the Security Considerations we have: and can also include authenticity and integrity checking, and/or confidentiality provisions. The use of the SFC Encapsulation is for SFP encapsulation and metadata = sharing. >> =E2=80=9CReevaluated=E2=80=9D is significantly better, of course. = Here=E2=80=99s another proposal: >>=20 >> "The architecture described here is different from the current model, = and >> moving to the new model could lead to different security arrangements = and >> modeling. In the SFC architecture, a relatively static = topologically-dependent >> deployment model is replaced with the chaining of sets of service = functions. >> This can change the flow of data through the network, and the = security and >> privacy considerations of the protocol and deployment will need to be >> reevaluated in light of the model.=E2=80=9D >=20 > I might add in "new" or "chained" before the very last "model", but = this > seems to catch the sentiment I was going for. Either =E2=80=98chain=E2=80=99 or =E2=80=98new=E2=80=99 univocally = disambiguates =E2=80=98model=E2=80=99 =E2=80=94 sure. > The idea would be to insert > this as a new paragraph after the first paragraph of section 6? >=20 Yes, or as the first paragraph of Section 6, as a preamble to the = section. Either. Thank you, =E2=80=94 Carlos. > Thank you, >=20 > Ben --Apple-Mail=_F82BB1D5-8B5C-492F-88A9-49A0F78B0838 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ben,

On May 27, 2015, at 2:16 PM, = Benjamin Kaduk <kaduk@MIT.EDU> wrote:
I do not disagree. Are there areas beyond what=E2=80=99s = already in the Security
considerations that = require specific focus?

I = think I only have the points I mentioned above (lack of clarity
regarding protecting the original payload, and clear = rhetoric). 

OK, let=E2=80=99s make sure we have a way forward = for both of them.

That reevaluation will
include security/privacy = issues for the original payload as well as the
classification and encapsulation data added by the SFC = protocol(s).



Yes =E2=80=94 which is what the doc already says.

Just to ensure we're = getting through to each other, do you mind pointing
to the specific text that you have in mind that = is supposed to already
say this?


What changes the flow of data in the network = (i.e., direct user traffic to the =E2=80=98remote machine=E2=80=99 (as = you called it) is the overlay =E2=80=94 that is why in the =E2=80=9CServic= e Overlay=E2=80=9D section of the Security Considerations we = have:

    =     and can also include authenticity and integrity checking, = and/or
        confidentiality = provisions.

The use of the SFC = Encapsulation is for SFP encapsulation and metadata sharing.

=E2=80=9CReevaluated=E2=80=9D is significantly better, = of course. Here=E2=80=99s another proposal:

"The architecture described here is different from the = current model, and
moving to the new model could lead to = different security arrangements and
modeling. In the SFC = architecture, a relatively static topologically-dependent
deployment model is replaced with the chaining of sets of = service functions.
This can change the flow of data = through the network, and the security and
privacy = considerations of the protocol and deployment will need to be
reevaluated in light of the model.=E2=80=9D

I might add in "new" or = "chained" before the very last "model", but this
seems to catch the sentiment I was going for. =  

Either = =E2=80=98chain=E2=80=99 or =E2=80=98new=E2=80=99 univocally = disambiguates =E2=80=98model=E2=80=99 =E2=80=94 sure.

The idea would be to insert
this as a new paragraph after the first = paragraph of section 6?


Yes, or as = the first paragraph of Section 6, as a preamble to the section. = Either.

Thank you,

=E2=80=94 Carlos.

Thank you,

Ben

= --Apple-Mail=_F82BB1D5-8B5C-492F-88A9-49A0F78B0838-- --Apple-Mail=_50254197-7287-45DF-B9C7-57DF5C86C7F9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZhKfAAoJEIXgpQGOZny9K9QP/j51NtoLRNjVsXtU9rli0rmH zFvgnSY/wqUMeIdNKB2HteEaTM8FTRQkCUN2daiNuXnovC2rK41WU2V7Rb1rt2f7 0hT5ZWjFEvD7fnSkGCj3Ee8zIiI6MbnRKBbUcnH0GPhGG0quDxCvkgdbXOtdQ/Tl 7yXRKX90fXW0dc5rD4nep8Qe6iZ0ZXXq3Jf2af6GGc9lG5QHSYYXpcDb/fe824Lc pTBcePjwOjVqcSLIf8oRpNr2exnWesSYUApicrrWFbQlUmsYCdKgUGqqYJPCgVzz LkO+Nmoy8MtTOaY7bLYf/H/93N1OXwLxnjyY3eN/dxhaFPENHWVp4UovbmQLcogc 02ItT1sF905aXJUSxBAy6wc5S59YcyiZiWX+xPMybLIK0u8tjuxL8BV73LCOVb8S ir+c9qLxxykEdXoxBQ9Q+aVpP9SstVbpqD7BZeQVLht15JzpeAYZZEBj33sLYxC+ g/S6CHyxaAmOpgLTwFyR90pN/XgbNW/kyChhIF5kIw4OycyI8fo0O8MQYz+evUJ1 7/AohibRB7ckNkrPmx2GtCe51S2bS260exim2Omt/kZKomLcNjK80XYUIpHIxD0+ r7f+gALWJBrDntryb7C/zGp7yhRvOVtHER/ZnuKs3Vtz4mEdBs2vXOZ+lItwfHDL 344XybndqqkyqLP7KWxX =lijx -----END PGP SIGNATURE----- --Apple-Mail=_50254197-7287-45DF-B9C7-57DF5C86C7F9-- From nobody Wed May 27 12:08:29 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66721A8986; Wed, 27 May 2015 12:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ak4oyC3va0M; Wed, 27 May 2015 12:08:25 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E1F1A8A74; Wed, 27 May 2015 12:08:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6F506240556; Wed, 27 May 2015 12:08:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 72CD42402EA; Wed, 27 May 2015 12:08:24 -0700 (PDT) Message-ID: <55661626.5010300@joelhalpern.com> Date: Wed, 27 May 2015 15:08:22 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Benjamin Kaduk , "Carlos Pignataro (cpignata)" References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 19:08:28 -0000 The "plain text payload" is an IP packet. Customer IP packet protection needs are, in almost all cases I can think of, independent of the routing path through the network that the packet takes. As such, I do not see why SFC adding yet another means to direct traffic flows changes the protection needs for customer IP packets. Note that many of the results SFC is trying to simplify are achieved today, albeit with more complexity. So I am having trouble seeing what requirement you want the SFC architecture to call out. Yorus, Joel On 5/27/15 2:16 PM, Benjamin Kaduk wrote: > On Wed, 27 May 2015, Carlos Pignataro (cpignata) wrote: > >> >>> On May 26, 2015, at 7:41 PM, Benjamin Kaduk wrote: >>> >>> >>> My take of the key point is that SFC is (potentially) going to be making >>> the actual physical flow of data very different from how it currently is, >>> and potentially also divorced from the conceptual topology of the service >>> function chain (if the service functions are laid out "strangely" compared >>> to the physical topology). This has the potential to drastically change >>> the security issues an operator deploying things has to consider, and an >>> architecture document should point out that both protocol designers >>> implementing the architecture and operators using such protocols should be >>> aware of the new security environment. >> >> Fully agree — and I believe this is what the current Security >> Considerations section achieves. > > I think we disagree on what the current Security Considerations section > achieves. > >> In particular, Section 6 highlights the areas of the new architecture >> (Overlay, Classification, Encapsulation) of which designers and >> operators ought to be aware. >> >>> Thus, we are proposing that it is >>> mandatory for protocol designers and operators to consider whether they >>> should be encrypting, but not mandatory for them to encrypt (if they are >>> satisfied with their topology). >> >> Further specifically, the "SFC Encapsulation” seems to cover this. > > So, you believe that the SFC Encapsulation section is intended to cover > the potential need for confidentiality protection of the plaintext payload > which is being encapsulated by SFC? > > I think that given the way the current text flows from "an operator may > consider the SFC Metadata as sensitive" straight into "from a privacy > perspective, a user may be concerned about the operator revealing data > about [...] the customer", it causes me to read that privacy concern as > applying only to the SFC Metadata (i.e., not to the original payload). > Likewise for the "risk of sensitive information slipping out of the > operators [sic] control"; since the paragraph started with the SFC > Metadata, it seems like this paragraph may apply only to the metadata. > >> But as I said, I would not oppose strengthening this section even more. > > But more generally, I think the rhetoric is better (stronger) if it is of > the form "you should do this thing (general concept); here are some > concrete examples", rather than "you should do this list of things" > without giving the overarching motivation. This is a lot of why I am > pushing for added (summary) text. > >>> I think that the SFC architecture does have the potential to change where >>> additional security and privacy considerations are needed. There can >>> definitely be security and privacy considerations within a single >>> administrative domain, and I do not think the current document has >>> sufficient acknowledgement of the potential for the new architecture to >>> require drastically different security and privacy measures in some (not >>> all!) cases. (Yes, I did read through it before composing this mail.) >> >> I do not disagree. Are there areas beyond what’s already in the Security >> considerations that require specific focus? > > I think I only have the points I mentioned above (lack of clarity > regarding protecting the original payload, and clear rhetoric). But let's > see if Simon has anything else to add, as well. > >>> I see some text in each of the three areas listed which sort-of addresses >>> my concerns, ("Used transport mechanisms should satisfy the security >>> requirements of the specific SFC deployment", "These include [...] >>> potential confidentiality issues of that policy", "solutions should >>> consider whether there is a risk of sensitive information slipping out of >>> the operators control. Issues of information exposure should also >>> consider flow analysis"), but they could easily be missed by the reader, >>> and do not convey a single central sense that adopting SFC will involve a >>> full reevaluation of network security policy. >> >> This is the key of the review, IMHO. On one hand, you seem to >> acknowledge that your security concerns are already addressed with the >> existing text. On the other hand, you seem to want to child-proof the >> text in case a reader misses what is already there already addressing >> the concern. > > I'm sorry that my message was unclear; I was not intending to "acknowledge > that [my concerns] are already addressed", but rather to say that the > existing text gets some of the way there, but there were still things > missing. (Hopefully this email is helping clarify already.) > >>> That reevaluation will >>> include security/privacy issues for the original payload as well as the >>> classification and encapsulation data added by the SFC protocol(s). >>> >>> >> >> Yes — which is what the doc already says. > > Just to ensure we're getting through to each other, do you mind pointing > to the specific text that you have in mind that is supposed to already > say this? > >> “Reevaluated” is significantly better, of course. Here’s another proposal: >> >> "The architecture described here is different from the current model, and >> moving to the new model could lead to different security arrangements and >> modeling. In the SFC architecture, a relatively static topologically-dependent >> deployment model is replaced with the chaining of sets of service functions. >> This can change the flow of data through the network, and the security and >> privacy considerations of the protocol and deployment will need to be >> reevaluated in light of the model.” > > I might add in "new" or "chained" before the very last "model", but this > seems to catch the sentiment I was going for. The idea would be to insert > this as a new paragraph after the first paragraph of section 6? > > Thank you, > > Ben > From nobody Wed May 27 19:01:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2201B2BB1; Wed, 27 May 2015 19:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdmascZzrd7N; Wed, 27 May 2015 19:01:41 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A611B2BB0; Wed, 27 May 2015 19:01:41 -0700 (PDT) Received: by lbcue7 with SMTP id ue7so18984212lbc.0; Wed, 27 May 2015 19:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Jbu5BKvbUp+nyx9k853WmDL07og2WUM070oiW48fmbQ=; b=iG9W2BqTDufvvvfZxxt9XiBLcZOBWZdk2Ow97aLMfxDhanB7WYBkSPi2e3J3yfYxie aSvymjggM8EMaAAEOlddUFRpThD+iQnb8Vx9JJYS5l17mCYb3ygApJJY+lakOrACyCOv l9p6Q8LOm/KghJFuYPWr8b8K697Wr3GfgIFVWCcNNWT5taCUPXgPfpsyiTsbaImgp9d2 BPpRwbCrS4rGN2q490aEqqmzNxlV+WBaJqAJfZ14CW63bSwhXG0NpHq5OJ/WyQQYwxi3 lKrUAoJlwHz1maY63X/fhSpCVgXEbgERAjjMTbv5hFeic7ydsBOxcPuj1xyMhJgq0p6H ixmQ== MIME-Version: 1.0 X-Received: by 10.112.185.100 with SMTP id fb4mr306502lbc.79.1432778499663; Wed, 27 May 2015 19:01:39 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 27 May 2015 19:01:39 -0700 (PDT) Date: Wed, 27 May 2015 22:01:39 -0400 X-Google-Sender-Auth: MYNT_fMNuuPdwdVc_GPHZuqbXzQ Message-ID: From: Phillip Hallam-Baker To: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org, "secdir@ietf.org" , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3ca2283af4c05171abdc7 Archived-At: Subject: [secdir] SECDIR Review of draft-ietf-manet-olsrv2-multitopology-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 02:01:42 -0000 --001a11c3ca2283af4c05171abdc7 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready Major Concerns: none The draft has a reference to a security considerations in an RFC that was published recently. The claim that the draft does not change the security model in ways that would require re-evaluation seems to be well founded. --001a11c3ca2283af4c05171abdc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have r= eviewed this document as part of the security directorate's ongoing eff= ort to review all IETF documents being processed by the IESG. These comment= s were written primarily for the benefit of the security area directors. Do= cument editors and WG chairs should treat these comments just like any othe= r last call comments.

Summary:=C2=A0 Ready

Major Concerns: = none

The draft has a re= ference to a security considerations in an RFC that was published recently.= The claim that the draft does not change the security model in ways that w= ould require re-evaluation seems to be well founded.
--001a11c3ca2283af4c05171abdc7-- From nobody Wed May 27 21:02:34 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F4F1A6F22; Wed, 27 May 2015 21:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdtIrw58FZoG; Wed, 27 May 2015 21:02:28 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5181A6F15; Wed, 27 May 2015 21:02:28 -0700 (PDT) X-AuditID: 12074424-f79b06d000000cfd-44-55669353ccd4 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id BB.25.03325.35396655; Thu, 28 May 2015 00:02:27 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t4S42QDn021562; Thu, 28 May 2015 00:02:26 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4S42MII004301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 May 2015 00:02:23 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4S42Ln8029597; Thu, 28 May 2015 00:02:21 -0400 (EDT) Date: Thu, 28 May 2015 00:02:21 -0400 (EDT) From: Benjamin Kaduk To: "Joel M. Halpern" In-Reply-To: <55661626.5010300@joelhalpern.com> Message-ID: References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> <55661626.5010300@joelhalpern.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixCmqrRs8OS3U4MkXFYtP73awWNz4dJvZ YsaficwWH0+9YbL4sPAhi8W9LZfYHdg8pvzeyOqxZMlPJo9zU74zesw8c5Hd48vlz2wBrFFc NimpOZllqUX6dglcGZeW72cp+MhbcfjmPcYGxl7uLkZODgkBE4kTrT8YIWwxiQv31rN1MXJx CAksZpK4+fQBK4SzkVGi51orVOYQk8SZK5OZIJwGRomfS5azg/SzCGhLvJ3ygwnEZhNQkZj5 ZiMbiC0CFN+/5ANYA7PAQiaJKzOnsHQxcnAIC9hJfJ+gAlLDKaAvsWfRYbA5vAKOEqtnX2GG WDCZWeLK3n6whKiAjsTq/SC9IEWCEidnPgGzmQW0JJZP38YygVFwFpLULCSpBYxMqxhlU3Kr dHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RSU0o3MYKCnt1FZQdj8yGlQ4wCHIxKPLwv5NNChVgT y4orcw8xSnIwKYny2vUBhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwfvEEyvGmJFZWpRblw6Sk OViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfA+nAjUKFiUmp5akZaZU4KQZuLgBBnOAzT8 K0gNb3FBYm5xZjpE/hSjopQ472mQhABIIqM0D64XlpReMYoDvSLM6zsJqIoHmNDgul8BDWYC Gmx2NAVkcEkiQkqqgbEvX2zxzTssWtfmTQ2bzrx78gvRGdbLCsVP1Z3p1tobXjaVh81u64vn b4Nm+4dFzhIu4C7d9O2Sts06q6Yfi3cUK5ekHDtysZE51cFrhkt/D79pkoXeLcP51c/S9h30 vbB+5zUN48D7N++0JP96zFQkeeVwVuWTxUkOmzrMOdPM1Y42P9kRc16JpTgj0VCLuag4EQB4 BseVJQMAAA== Archived-At: Cc: "iesg@ietf.org" , "Carlos Pignataro \(cpignata\)" , "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 04:02:30 -0000 On Wed, 27 May 2015, Joel M. Halpern wrote: > The "plain text payload" is an IP packet. Customer IP packet protection needs > are, in almost all cases I can think of, independent of the routing path > through the network that the packet takes. As such, I do not see why SFC > adding yet another means to direct traffic flows changes the protection needs > for customer IP packets. > > Note that many of the results SFC is trying to simplify are achieved today, > albeit with more complexity. > > So I am having trouble seeing what requirement you want the SFC architecture > to call out. I believe that the main motivating factor is the case where the NSA or some other "three-letter agency" is sniffing traffic within a network. There was a bunch of news about "ssl added and removed here" a while back, motivating some companies to increase the use of encryption within their networks. If the attacker only has access to a small number of nodes or links within the network, then changing the paths over which data passes can potentially expose it to surveillance when it was not before. You are correct that SFC itself may not be adding new real requirements on what data (paths) should be protected, but it is, in some sense, the first "new thing" now that we are aware of the extent to which networks come under attack. As such, we are inclined to take the opportunity to remind readers of the potential for these attacks and that they may want to consider countermeasures as appropriate. So, it is not exactly an additional requirement in practice, but rather an additional requirement in terms of what we document in IETF protocols, an addition made to reflect our changed understanding of the world in which we operate. -Ben From nobody Wed May 27 21:24:59 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897321A89FB; Wed, 27 May 2015 21:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8XXohmZAN7V; Wed, 27 May 2015 21:24:51 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F191A8A10; Wed, 27 May 2015 21:24:51 -0700 (PDT) X-AuditID: 1209190f-f79936d000000d16-6b-556698922f8d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 50.0A.03350.29896655; Thu, 28 May 2015 00:24:50 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t4S4OnHv008177; Thu, 28 May 2015 00:24:49 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4S4Ok9r008805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 May 2015 00:24:48 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4S4OkaN002442; Thu, 28 May 2015 00:24:46 -0400 (EDT) Date: Thu, 28 May 2015 00:24:45 -0400 (EDT) From: Benjamin Kaduk To: "Carlos Pignataro (cpignata)" In-Reply-To: Message-ID: References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1657708531-1432785906=:22210" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEKsWRmVeSWpSXmKPExsUixCmqrDtpRlqoweX3Qhaf3u1gsbjx6Taz xYw/E5ktPix8yGJxb8sldgdWjym/N7J6LFnyk8lj5pmL7B5fLn9mC2CJ4rJJSc3JLEst0rdL 4MrY+nI6S8FR+YquTw/YGhhXSnYxcnJICJhIPLy+ig3CFpO4cG89kM3FISSwmEnixtLPrBDO RkaJ/rVLoJxDTBIfG1vZIZwGRolNW6Yyg/SzCGhLfH66kRHEZhNQkZj5ZiPYXBEBM4nGx5OY QBqYBZ4wSpzuOwJUxMEhLGAn8X2CCkgNp4CtxJo7L9hBbF4BR4kfV7dBbVvILDFzyRmwoaIC OhKr909hgSgSlDg58wmYzSwQKHFt1VwWkJnMQM2t2/InMArNQlI1C0nVLIQqiLC6xIFPFxkh bG2J+zfb2CBsR4k5Ky6xLmBkW8Uom5JbpZubmJlTnJqsW5ycmJeXWqRropebWaKXmlK6iREc VZL8Oxi/HVQ6xCjAwajEw2sgkhYqxJpYVlyZe4hRkoNJSZRXYgpQiC8pP6UyI7E4I76oNCe1 +BCjBAezkgjvF0+gHG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBO+E 6UCNgkWp6akVaZk5JQhpJg5OkOE8QMMngdTwFhck5hZnpkPkTzEqSonzmoIkBEASGaV5cL2w pPeKURzoFWHe3SBVPMCECdf9CmgwE9Bgs6MpIINLEhFSUg2MKg+40tQDPqd0t9idT/x9oKDH uTT5rdti//DVkxe3/f1vXGdzacmJ90tulm+7kLDUeIPX/KrCVzamu1dO+FJw4OlJq9RTOj/0 M3femu3Qetto86vkuXu6ZOWfahQbWEXqfXgV9aehIvye4lN+pzvqXfue58/i1vHWMj4bKfM0 rfBs2Yb5LdvWKrEUZyQaajEXFScCAAihoE9VAwAA Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 04:24:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1657708531-1432785906=:22210 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Wed, 27 May 2015, Carlos Pignataro (cpignata) wrote: > Ben, > > > On May 27, 2015, at 2:16 PM, Benjamin Kaduk wrote: > >> I do not disagree. Are there areas beyond what=E2=80=99s already in th= e Security > >> considerations that require specific focus? > > > > I think I only have the points I mentioned above (lack of clarity > > regarding protecting the original payload, and clear rhetoric). > > OK, let=E2=80=99s make sure we have a way forward for both of them. > > >>> That reevaluation will > >>> include security/privacy issues for the original payload as well as t= he > >>> classification and encapsulation data added by the SFC protocol(s). > >>> > >>> > >> > >> Yes =E2=80=94 which is what the doc already says. > > > > Just to ensure we're getting through to each other, do you mind pointin= g > > to the specific text that you have in mind that is supposed to already > > say this? > > > > What changes the flow of data in the network (i.e., direct user traffic > to the =E2=80=98remote machine=E2=80=99 (as you called it) is the overlay= =E2=80=94 that is why > in the =E2=80=9CService Overlay=E2=80=9D section of the Security Consider= ations we have: > > and can also include authenticity and integrity checking, and/or > confidentiality provisions. > > The use of the SFC Encapsulation is for SFP encapsulation and metadata sh= aring. Now that you have pointed me at it, I do see how you feel that the issue is already covered. Let me see if I have any suggestions for new text that would not have required you to point me at it in order for me to see it. One thing that comes to mind would be to add a clause at the end of the sentence to reiterate what data is being protected. It is late here, so I have confused myself as to whether that should be "for both the traffic being forwarded and its encapsulation" or just "for the traffic being forwarded". It seems like it would also be helpful to spend another clause or sentence expounding how the security requirements of the specific SFC deployment are determined -- perhaps, "These security requirements will depend both on the structure of the network where SFC is being deployed and the details of the protocol implementing the SFC architecture; the security assessment should consider potential threats from both inside and outside the network." That's probably overkill, but is perhaps illustrative. > >> =E2=80=9CReevaluated=E2=80=9D is significantly better, of course. Here= =E2=80=99s another proposal: > >> > >> "The architecture described here is different from the current model, = and > >> moving to the new model could lead to different security arrangements = and > >> modeling. In the SFC architecture, a relatively static topologically-d= ependent > >> deployment model is replaced with the chaining of sets of service func= tions. > >> This can change the flow of data through the network, and the security= and > >> privacy considerations of the protocol and deployment will need to be > >> reevaluated in light of the model.=E2=80=9D > > > > I might add in "new" or "chained" before the very last "model", but thi= s > > seems to catch the sentiment I was going for. > > Either =E2=80=98chain=E2=80=99 or =E2=80=98new=E2=80=99 univocally disamb= iguates =E2=80=98model=E2=80=99 =E2=80=94 sure. > > > The idea would be to insert > > this as a new paragraph after the first paragraph of section 6? > > > > Yes, or as the first paragraph of Section 6, as a preamble to the section= =2E Either. Sounds good. -Ben ---559023410-1657708531-1432785906=:22210-- From nobody Wed May 27 23:44:24 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C951A1B66; Wed, 27 May 2015 23:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeRcXdItn5RW; Wed, 27 May 2015 23:44:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541211A1B5B; Wed, 27 May 2015 23:44:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t4S6iExd002978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 May 2015 09:44:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t4S6iDK5025913; Thu, 28 May 2015 09:44:13 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21862.47421.550340.776868@fireball.kivinen.iki.fi> Date: Thu, 28 May 2015 09:44:13 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dime-congestion-flow-attributes.all@tools.ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-dime-congestion-flow-attributes-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 06:44:20 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document optional ECN and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. The security considerations section says this does not raise any new security concerns, and I agree with that. I think this document is Ready. -- kivinen@iki.fi From nobody Wed May 27 23:55:13 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBFB1A1B81 for ; Wed, 27 May 2015 23:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqtiD2GOuYr9 for ; Wed, 27 May 2015 23:55:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7479F1A1B7A for ; Wed, 27 May 2015 23:55:06 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t4S6t49B014008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 May 2015 09:55:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t4S6t4UE015779; Thu, 28 May 2015 09:55:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21862.48072.543533.839844@fireball.kivinen.iki.fi> Date: Thu, 28 May 2015 09:55:04 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 06:55:08 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Alexey Melnikov is next in the rotation. For telechat 2015-05-28 Reviewer LC end Draft Dave Cridland T 2015-05-06 draft-ietf-dhc-dynamic-shared-v4allocation-07 Tobias Gondrom T 2015-05-07 draft-ietf-dane-smtp-with-dane-18 Olafur Gudmundsson T 2015-05-14 draft-ietf-kitten-sasl-oauth-22 Dan Harkins T 2015-05-15 draft-ietf-siprec-protocol-16 For telechat 2015-06-11 Alan DeKok T 2015-05-01 draft-ietf-dprive-problem-statement-05 Steve Hanna T 2015-05-15 draft-ietf-rtcweb-stun-consent-freshness-13 Jeffrey Hutzelman T 2015-06-03 draft-ietf-rtcweb-video-05 Chris Inacio T 2015-05-28 draft-ietf-rtcweb-rtp-usage-23 Scott Kelly T 2015-06-03 draft-ietf-httpbis-tunnel-protocol-04 Eric Osterweil T 2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01 Last calls and special requests: Leif Johansson 2015-05-25 draft-ietf-mip4-multiple-tunnel-support-12 Stephen Kent 2015-06-01 draft-ietf-oauth-introspection-08 Ben Laurie 2015-06-01 draft-ietf-oauth-spop-11 Matt Lepinski 2015-06-03 draft-ietf-xmpp-6122bis-22 Chris Lonvick 2015-06-09 draft-ietf-6lo-btle-13 Catherine Meadows 2015-06-09 draft-ietf-dhc-access-network-identifier-08 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 -- kivinen@iki.fi From nobody Thu May 28 10:30:20 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A6D1B2C76; Thu, 28 May 2015 10:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su9BMWRZA3m9; Thu, 28 May 2015 10:30:13 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF161B2C65; Thu, 28 May 2015 10:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4143; q=dns/txt; s=iport; t=1432834205; x=1434043805; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FNAxnDj4AG/l58YqiUiY/dcqglLMZiEijaZHGCAaw3M=; b=cSmmNUoiPyPb2+gwn6pRnLNhC152R4AcmADQ8jN2iv9/4tnsb5aC8eKm Lp/VowXzsV5NUa76Aqh00JlNbZ4USu/Jj+3IpXBN/D1sL1Ia/ZsEw5Bty 5ju5z+GEHV4A9Pe6aJ+az1z5toctwJfU2W/nMhyFFU61pq6BP8FgxPt8a 8=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AwAAUGdV/5JdJa1cDoMCgTIGgxi5bWYJh1ECgUw4FAEBAQEBAQGBCoQiAQEBAwEjVgULAgEIEgYqAgIyFw4CBA4FDgyICwixLqQQAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tDhQYHgmgvgRYFkwiCEoFDhzqBKZItg1kjgWaBVD5vgUaBAQEBAQ X-IronPort-AV: E=Sophos; i="5.13,513,1427760000"; d="asc'?scan'208"; a="2593212" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 28 May 2015 17:30:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4SHU4Oe032697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 17:30:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 28 May 2015 12:30:04 -0500 From: "Carlos Pignataro (cpignata)" To: Benjamin Kaduk Thread-Topic: [secdir] Review of draft-ietf-sfc-architecture-08 Thread-Index: AQHQllVoiI0EciI2k0ypB2MTIDGLzJ2L5tT3gAIA+oCAAJkTAIAAwU8AgAEfd4CAABfhgIAADp4AgACVMYCAAOGtAA== Date: Thu, 28 May 2015 17:30:03 +0000 Message-ID: References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> <55661626.5010300@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_D424051D-628E-4F96-AE65-F8065BCB8B25"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "secdir@ietf.org" , "Joel M. Halpern" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 17:30:15 -0000 --Apple-Mail=_D424051D-628E-4F96-AE65-F8065BCB8B25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Ben, > On May 28, 2015, at 12:02 AM, Benjamin Kaduk wrote: >=20 > On Wed, 27 May 2015, Joel M. Halpern wrote: >=20 >> The "plain text payload" is an IP packet. Customer IP packet = protection needs >> are, in almost all cases I can think of, independent of the routing = path >> through the network that the packet takes. As such, I do not see why = SFC >> adding yet another means to direct traffic flows changes the = protection needs >> for customer IP packets. >>=20 >> Note that many of the results SFC is trying to simplify are achieved = today, >> albeit with more complexity. >>=20 >> So I am having trouble seeing what requirement you want the SFC = architecture >> to call out. >=20 > I believe that the main motivating factor is the case where the NSA or > some other "three-letter agency" is sniffing traffic within a network. > There was a bunch of news about "ssl added and removed here" a while = back, > motivating some companies to increase the use of encryption within = their > networks. This is a very noble goal, but let=E2=80=99s not DoS-attack this draft = to solve that higher-level objective. :-) I look forward to satisfactorily addressing the security concerns, and = strengthening the SFC architecture. I believe we have convergence points = in your other response. I will reply with the specifics there, but a = couple additional thoughts below. >=20 > If the attacker only has access to a small number of nodes or links = within > the network, then changing the paths over which data passes can > potentially expose it to surveillance when it was not before. =E2=80=9CChanging the path" can potentially remove traffic from = surveillance points also, net-improving the situation. My point is that = it is conjecture. > You are > correct that SFC itself may not be adding new real requirements on = what > data (paths) should be protected, but it is, in some sense, the first = "new > thing" now that we are aware of the extent to which networks come = under > attack. As such, we are inclined to take the opportunity to remind > readers of the potential for these attacks and that they may want to > consider countermeasures as appropriate. Given this objective, and the fact you acknowledge that SFC may not be = adding new real requirements, I=E2=80=99d recommend a more holistic = approach instead of reminding only SFC readers in a corner of the = security considerations. Best, =E2=80=94 Carlos. >=20 > So, it is not exactly an additional requirement in practice, but = rather an > additional requirement in terms of what we document in IETF protocols, = an > addition made to reflect our changed understanding of the world in = which > we operate. >=20 > -Ben --Apple-Mail=_D424051D-628E-4F96-AE65-F8065BCB8B25 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZ1CcAAoJEIXgpQGOZny995IP/1DhihVFOOUERDKcXEb73lwi Nem9Yz1k8PrqA9cYUbgkFo/JkUVX0/BKYNY+fdX9nAKwkAD7KI9woQ5iD77hwrpo nhZEK5z6W1LyMFwv1ucyrK+r7IRjcIuBN4EaWllpIPZQ/1QDZ3QEkF+5m9acrdxa A2Qg5VfU2lpDDRGyRDMCiBS8ch29IehzqufjboKNZjQ5m7mgerAPlxw+gxf19h+V jlbPOHUKtB3vB3hlnmGHtdvBMeBbcr9n6SJwEYUyJKemmnPJpHb5WDPgdrpxFBBj 1ZG9w4JxWyYVarQ8kQ5U4QQ0rHeawL0sT7Jmu84YrM2foVKjBddnA2IPPO0doWCl gA9geuRrkxzWAvCDKAeZpnHQEA1qEyNG2yUBGfmpGW0XUWcp0YCj901URLwNekOL sR8ex3YthBuCdEg+csFhUSWWV3mUgZHxjuKpvOA4Fv229BNj3sM5V02/7iJ+M8mU PS0kq8qjYpsugpyHL9Ij/ymgyVVRZ1XI7pa9+mPoOV31ID4LVJ9mV1WMOE1+Foj4 1mf2VcXnsOKYowu4g8q2JGXvf/OCv37aLyGlxN/iQCUAWxRoDKz0J/AuRI5CEUc5 YSqM0I8hOe7NwGGgkxg8TTeKMePbm8zWVE7O81EWpBkRlAq2NOjfyKIchrwXqdJP ri5POT6BgQ0Vr/2Wit6v =9VL2 -----END PGP SIGNATURE----- --Apple-Mail=_D424051D-628E-4F96-AE65-F8065BCB8B25-- From nobody Thu May 28 10:31:31 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFAF1B2BD0; Thu, 28 May 2015 10:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHzhGDhT1dJH; Thu, 28 May 2015 10:31:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768061A872A; Thu, 28 May 2015 10:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5691; q=dns/txt; s=iport; t=1432834288; x=1434043888; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jk36JCQanM0uwIJijSP9eABBVWFki6G+3SBtEAXVx/o=; b=S804bCaK5lY9CRvEpZWsNd8MbpJ9wOSISYfqwAe+9pdFB9p01o1hJZLG RrZpL4/BxAlezeUZMgrsCiL7RuXOndIdnvOMYUWnTrUGMg7Wc/Tdj89gn fWoBnxv/HYhCupM4GXbJrf3b8WN/Dkj9hGL/lMhRuEM5u5XEXjpbRiyv7 w=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQAAUGdV/5BdJa1cDoMCgTIGgxi5bYhAAoFMTAEBAQEBAYELhCIBAQEDASNWBQsCAQYCEgYqAgIyFw4CBA4FDogXCJQdnRGkEAEBAQEBAQEBAQEBAQEBAQEBAQEBGItDhQYHgmgvgRYFkwiCEoFDgy+EC5cvI4M6Pm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="asc'?scan'208";a="423397329" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 28 May 2015 17:31:12 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t4SHVCCv018336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 17:31:12 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 28 May 2015 12:31:12 -0500 From: "Carlos Pignataro (cpignata)" To: Benjamin Kaduk Thread-Topic: [secdir] Review of draft-ietf-sfc-architecture-08 Thread-Index: AQHQllVoiI0EciI2k0ypB2MTIDGLzJ2L5tT3gAIA+oCAAJkTAIAAwU8AgAEfd4CAABfhgIAACmqAgACfqICAANu8gA== Date: Thu, 28 May 2015 17:31:11 +0000 Message-ID: <5C38EDAD-2CAC-485B-B488-51819FAAFC81@cisco.com> References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_9E8C6884-E25F-4471-B7FC-EFC15150EE5A"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 17:31:30 -0000 --Apple-Mail=_9E8C6884-E25F-4471-B7FC-EFC15150EE5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben, > On May 28, 2015, at 12:24 AM, Benjamin Kaduk wrote: >=20 > On Wed, 27 May 2015, Carlos Pignataro (cpignata) wrote: >=20 >> Ben, >>=20 >>> On May 27, 2015, at 2:16 PM, Benjamin Kaduk wrote: >>>> I do not disagree. Are there areas beyond what=E2=80=99s already in = the Security >>>> considerations that require specific focus? >>>=20 >>> I think I only have the points I mentioned above (lack of clarity >>> regarding protecting the original payload, and clear rhetoric). >>=20 >> OK, let=E2=80=99s make sure we have a way forward for both of them. >>=20 >>>>> That reevaluation will >>>>> include security/privacy issues for the original payload as well = as the >>>>> classification and encapsulation data added by the SFC = protocol(s). >>>>>=20 >>>>>=20 >>>>=20 >>>> Yes =E2=80=94 which is what the doc already says. >>>=20 >>> Just to ensure we're getting through to each other, do you mind = pointing >>> to the specific text that you have in mind that is supposed to = already >>> say this? >>>=20 >>=20 >> What changes the flow of data in the network (i.e., direct user = traffic >> to the =E2=80=98remote machine=E2=80=99 (as you called it) is the = overlay =E2=80=94 that is why >> in the =E2=80=9CService Overlay=E2=80=9D section of the Security = Considerations we have: >>=20 >> and can also include authenticity and integrity checking, = and/or >> confidentiality provisions. >>=20 >> The use of the SFC Encapsulation is for SFP encapsulation and = metadata sharing. >=20 > Now that you have pointed me at it, I do see how you feel that the = issue > is already covered. Let me see if I have any suggestions for new text > that would not have required you to point me at it in order for me to = see > it. >=20 OK. > One thing that comes to mind would be to add a clause at the end of = the > sentence to reiterate what data is being protected. It is late here, = so I > have confused myself as to whether that should be "for both the = traffic > being forwarded and its encapsulation" or just "for the traffic being > forwarded=E2=80=9D. I can add =E2=80=9C, for both the network overlay transport and traffic = it encapsulates=E2=80=9D at the end of that sentence? Or "for both the = traffic being forwarded and its encapsulation=E2=80=9D as well. I = thought this was understood, however. >=20 > It seems like it would also be helpful to spend another clause or = sentence > expounding how the security requirements of the specific SFC = deployment > are determined -- perhaps, "These security requirements will depend = both > on the structure of the network where SFC is being deployed and the > details of the protocol implementing the SFC architecture; the = security > assessment should consider potential threats from both inside and = outside > the network." That's probably overkill, but is perhaps illustrative. To me, it is closer to overkill, but I would not oppose if you very = strongly feel it adds value, even if merely illustrative. >=20 >>>> =E2=80=9CReevaluated=E2=80=9D is significantly better, of course. = Here=E2=80=99s another proposal: >>>>=20 >>>> "The architecture described here is different from the current = model, and >>>> moving to the new model could lead to different security = arrangements and >>>> modeling. In the SFC architecture, a relatively static = topologically-dependent >>>> deployment model is replaced with the chaining of sets of service = functions. >>>> This can change the flow of data through the network, and the = security and >>>> privacy considerations of the protocol and deployment will need to = be >>>> reevaluated in light of the model.=E2=80=9D >>>=20 >>> I might add in "new" or "chained" before the very last "model", but = this >>> seems to catch the sentiment I was going for. >>=20 >> Either =E2=80=98chain=E2=80=99 or =E2=80=98new=E2=80=99 univocally = disambiguates =E2=80=98model=E2=80=99 =E2=80=94 sure. >>=20 >>> The idea would be to insert >>> this as a new paragraph after the first paragraph of section 6? >>>=20 >>=20 >> Yes, or as the first paragraph of Section 6, as a preamble to the = section. Either. >=20 > Sounds good. Done. Thanks. =E2=80=94 Carlos. >=20 > -Ben --Apple-Mail=_9E8C6884-E25F-4471-B7FC-EFC15150EE5A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZ1DgAAoJEIXgpQGOZny9LfcP/1W7vn/pKQQ/wfO1IYJVpd4y gYyTYtaLmuKU4SMh0z0d9BJR4aSSuBzNAKlXZtEQ3CPAMnrMmSktnYtIG2n5iB0W FkQD6AE2dBZ7PI1gI6x93cS98wTCh6IOtcv2PmKUR22GJu1dR51lbfoH2PthG7TT v4K38wyQdYwL490hOII/0NuEXrPj/Uj6GlPg3TcQW7XH8dgSTdZJZntqo/kipkT6 r/CN515a0EFT4tleA7EKpbWNHMCljLmrYLcRYmgZqNs/QHVJRchpSt72Y/sEe5fl 9F8luLt2JRnJUzEVubKGFjCHcLM72xEVLIQ1PiUdeA4gUzDVD5dbtXr8MZuDIG4m IPbMnak6CdIOCoFFIWrfYuAkUkDEaqFglbeK2Qi22tvfwcUGmFED9Pl/fwStIPoo DWjteVPmZyX8FGiJRvCuNqz8Jme+3rQROp3QVkEqY0txaRG5D6fdvYfa5d+3Ms6S fV6aJCezsMQxetEEVnVZmowSbk8U4UMG1PPan1m+WVrdZvDM8bU9JDdI+9B3I+zL McjTk09xttRYLOEQj+2THXXdxpjoTMnZ8KdytY4QaTAqVSLZeTckCLJhhJytFUF6 odRdZeBpbseRS/8GBIkCRQ7apD4HqvfPuh1590fbUcLH2T92mHyDklRcsW5yT5tV GXFPvpXefCw9eC6a5/DW =065X -----END PGP SIGNATURE----- --Apple-Mail=_9E8C6884-E25F-4471-B7FC-EFC15150EE5A-- From nobody Fri May 29 11:57:54 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D870F1B2C30; Fri, 29 May 2015 11:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUTrfj8pGCjO; Fri, 29 May 2015 11:57:50 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B671B2C1B; Fri, 29 May 2015 11:57:49 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4TIvjqE031264; Fri, 29 May 2015 19:57:45 +0100 Received: from 950129200 (jplon-nat12.juniper.net [193.110.55.12]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4TIvfO6031231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 29 May 2015 19:57:44 +0100 From: "Adrian Farrel" To: "'Charlie Kaufman'" References: <554CAAE8.9090800@pi.nu> <5564375E.9060306@pi.nu> In-Reply-To: <5564375E.9060306@pi.nu> Date: Fri, 29 May 2015 19:57:40 +0100 Message-ID: <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF5eSexDRNWQp3PbXquwiAO8nDK8AG1NIBxAwpgEWKeGt5TUA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21578.002 X-TM-AS-Result: No--19.096-10.0-31-10 X-imss-scan-details: No--19.096-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wtcjCbPZgQnFQrO4XR6BRQPwZxaFJX+r1Q9W gBEShsusNJRL3ObC9T403lLuu4Ngvwr0iJbTVMrQVUIE0/jxA/0pWss5kPUFdFpbYq2f4jz+tNM q9uo9SGSdUQQhPyoTsFFO3CvbVp5Y3kon++iVNT3Rc75iroKqApSlv/9klkDi0mAM2eipqlpxQ9 CNI5RA3XndTfZ2f9trubF1G61WsDK2jsN8aguKvIhaKK0I26FpeJ1OirYwzAPqLnOUXH9QdN/LI yZs19OqD4fkXZtjSA5IGIywrjubdcaZnhgjGx375cQFbdjxan6imsR6hkcJAhZ50KsQddqXnUqX H4EzL8J2zheu5Rrnt1Jf31s+j+06/zkYJHv4a2FgP1dNF1ow7QkN8Uvsy+nt2oLGTNKlb9eGXWN Bqn1KYugqahDxmMqz/2Km2iZ9UFITtP2F86umWBD3+0w1DhqKviRliDV2nyxb6PBUqmq+UjtjAP WAT9k7mfH8FreQYWD5uD6QwNqXa/PnSD6On2CewCZxkTHxcclWjiXAsVR2K0iO8DX9hL7R4d2Na uEDjqzpw6f4ioqa6Z0K9Xn3Ln5CDL2trK/H+w4pa6LJktEjgOEpCHUsKYYGobx/SIoF+OYy5PBt qoQlk1/wODk/m7aHNDDF3FEnVHCWHmpvkeKJB1Pjo7D4SFg4YM9jZ5ImeaeA+ITQt7D1AHfDoi9 9VAHrkO2RcZLzfFxIKOYV2FoClO+Qm7Tg9jG3oxWB033D5MKBA/jzcz3nAVVgGGTe6VdACwgUPj ccZ/Dqumt0gZE/iphzqJ5nm6DdwwTYGyiIokyeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtpkzYWdbnR1BaewVHaiHXFPxXrdqkuzUuSUHWbFS8puGgJwEy2zguUIAjJblo AwAwShAy7Ao/AUv4OkKftdT/BMkjQlxoxv9QJeJ1WMCERkGtftyYo2KwDjKpoRvzNKOP9DB8M7t iaMCEN0PsxMBbpmcjFnImzvyS Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls@ietf.org, mpls-chairs@tools.ietf.org, 'secdir' Subject: Re: [secdir] [mpls] FYI - Early review of draft-farrelll-mpls-opportunistic-encrypt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 18:57:53 -0000 Charlie, Thanks for this. Forgive me for stumbling through the security aspects: I'm sure Stephen will pick me up on whatever I get wrong. > All-- > Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a > protocol for doing opportunistic encryption of MPLS connections. It permits > encryption at any of two scopes: between adjacent Label Switching Routers > (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an > LSP. Opportunistic encryption in this case means that there is no mechanism > specified for authenticating the endpoints of the encrypted channel. The two > endpoints do an anonymous Diffie-Hellman exchange and use the resulting key > to encrypt the connection. The protocol is not protected from a > man-in-the-middle attack (though some mechanisms for detecting such an > attack after the fact are suggested and a keying infrastructure could be > added later). > > The encryption aspects of the protocol seem well thought out and > appropriate. The question at hand is whether to adopt this document as a > working group document and it easily meets that bar (at least from a > security standpoint). I have a number of questions about operational aspects > of the protocol (perhaps due to my limited understanding of MPLS) and I have > some suggestions for enhancements that will probably be necessary eventually > and might be easier to make before there is widespread deployment: > > There is an issue that came up in the design of IKEv2 that may be an issue > here as well. I don't know whether MPLS connections are bi-directional or > whether separate connections need to be established in the two directions. > > If they are bi-directional, then there are race conditions that can occur if > both ends attempt to initialize a connection simultaneously and there must > be some tie-breaking mechanism to assure that exactly one of the connection > attempts succeeds. If they are uni-directional, and if the connection is > always initialized by the sending end, then this is not a problem (though it > is replaced with the problem that messages of this protocol sent in the > reverse direction cannot be tunneled over the MPLS connection). (This > document seems to imply that MPLS connections can be either uni-directional > or bi-directional, but I don't understand MPLS well enough to have > understood it). Even if the connections are bi-directional, it will make > your life simpler if you use different symmetric keys in the two directions. > This can be done easily by getting two independent keys from the key > expansion process. Right. LSPs may be unidirectional or bidirectional. Section 4 and particularly 4.3 describe how the return path is selected for the case of a unidirectional LSP. So we have four questions: 1. Is the return path secure? 2. Who initiates the use of OS? 3. How do we handle race conditions? 4. Should we have different keys in different directions? In fact, the key exchange does not itself need to be secure, but it would be better if it was. 4.2.1 and 4.4 say how to do this if possible, but notes it will likely not be possible in the case of OS. So that's Q1. In the case of a unidirectional LSP, only the source node (i.e. upstream from the perspective of data flow) can be the initiator for the key exchange because the key exchange requires the use of a message flowing on the LSP itself. So, for Q2 we only have to worry about bidirectional LSPs, and that takes us to Q3. But, in fact, a bidirectional LSP is in fact (from the point of view of the forwarding plane) the association of two unidirectional LSPs. The association may be so tight (in the control plane or the management plane, and with fate sharing) that the LSP is referred to as *a* single bidirectional LSP, but that doesn't change the forwarding plane behavior. And, indeed, in the bidirectional case, there is no reason to not have encryption in one direction and not in the other direction (except, of course, that more is better :-). So that means that each direction of the bidirectional LSP is responsible for initiating its own OS. Hence Q3 is not a problem, and Q4 takes care of itself. We should definitely clarify this in the draft (and thank you for making me describe it here), but I'd like some more discussion with the WG to check I am right about this. > A second issue relates to algorithm negotiation. While the protocol allows > for any of the crypto algorithms to be replaced, and the algorithms are > indicated on the wire, it does not appear to allow for a smooth upgrade > where the two ends are updated independently and everything must continue > to work when only one end has been updated. To accomplish that, there > should be an algorithm negotiation (as takes place in IKE and TLS) where one > end presents a list of algorithms is can support and the other end chooses the > algorithms it prefers. A simpler variation would be for a responder to be > able to reject the algorithms assumed by the initiator and send back a list > of algorithms it will accept. Note: it's possible that MPLS already operates > with the restriction that the two ends of a connection must be consistent > and operations will halt if the two ends are updated non-simultaneously. If > that's true, then adding crypto doesn't make the situation any worse and it > would be acceptable to continue to operate that way. I'm so far from being an expert in this matter that I am probably making a fool of myself (again), but is algorithm replacement actually any different from key change? That is, the key negotiation protocol negotiates the key and algorithm to use and so can also negotiate changes in both key and algorithm. Section 4.2.3 mentions this, but is exceptionally week. I'll add some text (assuming what I just wrote is not complete lunacy). The key ID identifies the key and the algorithm in one field, so being able to change the key ID was intended to also allow changing the algorithm. > A possible problem with Key Identifiers: the Key Identifier is only 4 bits > long, which should be sufficient because at most two keys should be active > at any given time. The Key Identifier, however, is chosen effectively > randomly, which means that one time in 16 it will be the same as the Key > Identifier it is replacing. While the protocol could be modified to do > something special in that last (like adding one to the Key Identifier if it > matches the previous value or redoing the key negotiation in that case), it > would probably be better to get the Key-ID from the key expansion when > there is no previous connection and add one (mod 16) when rekeying. Yes, I had assumed that if the key ID was reselected then some form of secondary choice would be made. Not sure that the predictability of simply adding one is good idea (not that I can think of specific associated risk). > There is mention of the possibility of reusing g^i and g^r between > connections. Some crypto purists would object to that, but I wouldn't. If > you want to allow implementations that option, however, you should also > include in the exchange nonce values Ni and Nr that are not reused between > connections rather than depending on unique values for the other parameters > to prevent reuse of keys. Ah, hmm, OK. Stephen? Help! > In section 3.5 (MTU considerations), I suspect you may be underestimating > the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad > bytes to make the encrypted payload size a multiple of 16 bytes. There are > algorithm variants that do not add any padding, but they are somewhat > controversial and difficult to implement in hardware. Further, the total > overhead will be dependent of the crypto algorithm chosen, and the text > should indicate that so that readers don't assume that there is some maximum > number of bytes that can be wired into protocols that run above this. That's helpful. Stephen, I need you to help with this. > I would suggest that most or all of sections 5 and 7 should be moved to > Security Considerations. Failing that, the Security Considerations section > should reference them. Thanks. Since 5 is growing, I've put back pointer from 6. 7.1 is already referenced from 6.2 and 6.3 > Typos: > > P4: "and if may be advisable" -> "and it may be advisable" > P4: "an alternative key derivation functions" -> "alternative key derivation > functions" > P5: "key definition function" -> "key derivation function" > P5: "attck vecotrs" -> "attack vectors" > P5: "descirption" -> "description" > P19: "opostie" -> "opposite" Good. vmt Adrian From nobody Fri May 29 14:03:06 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0211B2D63; Fri, 29 May 2015 14:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqNt4TI6ZdIv; Fri, 29 May 2015 14:03:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C138A1B2D5C; Fri, 29 May 2015 14:03:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8C37CBF19; Fri, 29 May 2015 22:02:59 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCAEZhbZ1rgD; Fri, 29 May 2015 22:02:57 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 54AEBBF03; Fri, 29 May 2015 22:02:57 +0100 (IST) Message-ID: <5568D401.3040004@cs.tcd.ie> Date: Fri, 29 May 2015 22:02:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Charlie Kaufman' References: <554CAAE8.9090800@pi.nu> <5564375E.9060306@pi.nu> <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk> In-Reply-To: <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls@ietf.org, mpls-chairs@tools.ietf.org, 'secdir' Subject: Re: [secdir] [mpls] FYI - Early review of draft-farrelll-mpls-opportunistic-encrypt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 21:03:03 -0000 Hiya, On 29/05/15 19:57, Adrian Farrel wrote: > Charlie, > > Thanks for this. Forgive me for stumbling through the security aspects: I'm sure > Stephen will pick me up on whatever I get wrong. I'll get to this in a day or so, thanks Charlie for the review and Adrian for processing it. S. > >> All-- >> Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a >> protocol for doing opportunistic encryption of MPLS connections. It permits >> encryption at any of two scopes: between adjacent Label Switching Routers >> (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an >> LSP. Opportunistic encryption in this case means that there is no mechanism >> specified for authenticating the endpoints of the encrypted channel. The two >> endpoints do an anonymous Diffie-Hellman exchange and use the resulting key >> to encrypt the connection. The protocol is not protected from a >> man-in-the-middle attack (though some mechanisms for detecting such an >> attack after the fact are suggested and a keying infrastructure could be >> added later). >> >> The encryption aspects of the protocol seem well thought out and >> appropriate. The question at hand is whether to adopt this document as a >> working group document and it easily meets that bar (at least from a >> security standpoint). I have a number of questions about operational aspects >> of the protocol (perhaps due to my limited understanding of MPLS) and I have >> some suggestions for enhancements that will probably be necessary eventually >> and might be easier to make before there is widespread deployment: >> >> There is an issue that came up in the design of IKEv2 that may be an issue >> here as well. I don't know whether MPLS connections are bi-directional or >> whether separate connections need to be established in the two directions. >> >> If they are bi-directional, then there are race conditions that can occur if >> both ends attempt to initialize a connection simultaneously and there must >> be some tie-breaking mechanism to assure that exactly one of the connection >> attempts succeeds. If they are uni-directional, and if the connection is >> always initialized by the sending end, then this is not a problem (though it >> is replaced with the problem that messages of this protocol sent in the >> reverse direction cannot be tunneled over the MPLS connection). (This >> document seems to imply that MPLS connections can be either uni-directional >> or bi-directional, but I don't understand MPLS well enough to have >> understood it). Even if the connections are bi-directional, it will make >> your life simpler if you use different symmetric keys in the two directions. >> This can be done easily by getting two independent keys from the key >> expansion process. > > Right. LSPs may be unidirectional or bidirectional. > > Section 4 and particularly 4.3 describe how the return path is selected for the > case of a unidirectional LSP. > > So we have four questions: > > 1. Is the return path secure? > 2. Who initiates the use of OS? > 3. How do we handle race conditions? > 4. Should we have different keys in different directions? > > In fact, the key exchange does not itself need to be secure, but it would be > better if it was. 4.2.1 and 4.4 say how to do this if possible, but notes it > will likely not be possible in the case of OS. So that's Q1. > > In the case of a unidirectional LSP, only the source node (i.e. upstream from > the perspective of data flow) can be the initiator for the key exchange because > the key exchange requires the use of a message flowing on the LSP itself. So, > for Q2 we only have to worry about bidirectional LSPs, and that takes us to Q3. > > But, in fact, a bidirectional LSP is in fact (from the point of view of the > forwarding plane) the association of two unidirectional LSPs. The association > may be so tight (in the control plane or the management plane, and with fate > sharing) that the LSP is referred to as *a* single bidirectional LSP, but that > doesn't change the forwarding plane behavior. And, indeed, in the bidirectional > case, there is no reason to not have encryption in one direction and not in the > other direction (except, of course, that more is better :-). So that means that > each direction of the bidirectional LSP is responsible for initiating its own > OS. > > Hence Q3 is not a problem, and Q4 takes care of itself. > > We should definitely clarify this in the draft (and thank you for making me > describe it here), but I'd like some more discussion with the WG to check I am > right about this. > >> A second issue relates to algorithm negotiation. While the protocol allows >> for any of the crypto algorithms to be replaced, and the algorithms are >> indicated on the wire, it does not appear to allow for a smooth upgrade >> where the two ends are updated independently and everything must continue >> to work when only one end has been updated. To accomplish that, there >> should be an algorithm negotiation (as takes place in IKE and TLS) where one >> end presents a list of algorithms is can support and the other end chooses the >> algorithms it prefers. A simpler variation would be for a responder to be >> able to reject the algorithms assumed by the initiator and send back a list >> of algorithms it will accept. Note: it's possible that MPLS already operates >> with the restriction that the two ends of a connection must be consistent >> and operations will halt if the two ends are updated non-simultaneously. If >> that's true, then adding crypto doesn't make the situation any worse and it >> would be acceptable to continue to operate that way. > > I'm so far from being an expert in this matter that I am probably making a fool > of myself (again), but is algorithm replacement actually any different from key > change? That is, the key negotiation protocol negotiates the key and algorithm > to use and so can also negotiate changes in both key and algorithm. > > Section 4.2.3 mentions this, but is exceptionally week. I'll add some text > (assuming what I just wrote is not complete lunacy). > The key ID identifies the key and the algorithm in one field, so being able to > change the key ID was intended to also allow changing the algorithm. > >> A possible problem with Key Identifiers: the Key Identifier is only 4 bits >> long, which should be sufficient because at most two keys should be active >> at any given time. The Key Identifier, however, is chosen effectively >> randomly, which means that one time in 16 it will be the same as the Key >> Identifier it is replacing. While the protocol could be modified to do >> something special in that last (like adding one to the Key Identifier if it >> matches the previous value or redoing the key negotiation in that case), it >> would probably be better to get the Key-ID from the key expansion when >> there is no previous connection and add one (mod 16) when rekeying. > > Yes, I had assumed that if the key ID was reselected then some form of secondary > choice would be made. Not sure that the predictability of simply adding one is > good idea (not that I can think of specific associated risk). > >> There is mention of the possibility of reusing g^i and g^r between >> connections. Some crypto purists would object to that, but I wouldn't. If >> you want to allow implementations that option, however, you should also >> include in the exchange nonce values Ni and Nr that are not reused between >> connections rather than depending on unique values for the other parameters >> to prevent reuse of keys. > > Ah, hmm, OK. > Stephen? > Help! > >> In section 3.5 (MTU considerations), I suspect you may be underestimating >> the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad >> bytes to make the encrypted payload size a multiple of 16 bytes. There are >> algorithm variants that do not add any padding, but they are somewhat >> controversial and difficult to implement in hardware. Further, the total >> overhead will be dependent of the crypto algorithm chosen, and the text >> should indicate that so that readers don't assume that there is some maximum >> number of bytes that can be wired into protocols that run above this. > > That's helpful. > Stephen, I need you to help with this. > >> I would suggest that most or all of sections 5 and 7 should be moved to >> Security Considerations. Failing that, the Security Considerations section >> should reference them. > > Thanks. Since 5 is growing, I've put back pointer from 6. > 7.1 is already referenced from 6.2 and 6.3 > >> Typos: >> >> P4: "and if may be advisable" -> "and it may be advisable" >> P4: "an alternative key derivation functions" -> "alternative key derivation >> functions" >> P5: "key definition function" -> "key derivation function" >> P5: "attck vecotrs" -> "attack vectors" >> P5: "descirption" -> "description" >> P19: "opostie" -> "opposite" > > Good. > > vmt > Adrian > >