From nobody Tue Jul 1 07:07:07 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E071A032D for ; Tue, 1 Jul 2014 07:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zbRRtTkJduwc for ; Tue, 1 Jul 2014 07:06:52 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91E21A032B for ; Tue, 1 Jul 2014 07:06:52 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so10641033pab.17 for ; Tue, 01 Jul 2014 07:06:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=WSUigw+DmNfVv+V3vN9nDVhBAOERm4WpvNXOpSZ86hs=; b=X7eUXdrjQr6B4uLMrqAO49pt/1xeKaYXNe141kSp7vnim+bPEYlSykV8b1qETDZK5Y vg1F3iYhP3TlsGmvFJgV0y7fNDOSa63fEPNZN1Bp6+jcQ78RxG3wfNBBnC3sD6PWDI2F GvdWcKajeqCE1Gq2tUa1O8hZW/hR0bs0gAyfc5Yao7xl5m1+PCpZq9hrpZkLDCv2Pxjm 3FXJHBhcpcjwguTZSlveMHYC04LHn1MX2FNf5VorIG/0Y39AHOz7GbMAsQ+x9lNppZXw yN3iJuF3740aUYBmUDnRCDftKBCIowJE1qJlJL+GOQHlfsMZEddASuNXHqo1DGO8GPWx WULw== X-Gm-Message-State: ALoCoQn5yuzNy6g40Z8SpCsPV5hrKJUBtzuXU/BPs1bJ3z8ub6+3421YOsT+bgtH+hsfUn0/BXsA X-Received: by 10.66.235.34 with SMTP id uj2mr60458461pac.28.1404223612487; Tue, 01 Jul 2014 07:06:52 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:6932:beff:76b3:233f? ([2602:306:3406:4f00:6932:beff:76b3:233f]) by mx.google.com with ESMTPSA id id10sm32915914pbc.35.2014.07.01.07.06.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 07:06:51 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_A45F1ECD-4EC9-47B6-8EE0-409CB6BC9B5D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Date: Tue, 1 Jul 2014 09:06:47 -0500 To: sacm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/UWplSHND0dAaC902JvwOFBU4q-A Subject: [sacm] Draft Agenda for IETF 90 Posted X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 14:06:57 -0000 --Apple-Mail=_A45F1ECD-4EC9-47B6-8EE0-409CB6BC9B5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All: We=92ve posted a draft agenda for IETF 90 here: = http://www.ietf.org/proceedings/90/agenda/agenda-90-sacm. If you have = any change proposals, let=92s start the discussion now. Thank you and regards, Dan and Adam --Apple-Mail=_A45F1ECD-4EC9-47B6-8EE0-409CB6BC9B5D 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 iQEcBAEBCgAGBQJTssB3AAoJELhc5c4zaVWHcxAH/0370GVMKfN+FleXT8EKFK9T zyxYVeXVfEXnn6aWFyUxBWnxGqJ721ah31NfQ9yRAXEqsWXfJLqdjsrWWnE8Fhu3 hgXXkEXs+rKtn6mRFuTlS6W7jqM56S7cH9KUfaAPlCVX+icSZllxjKJSObQ+LAPh H4MP0hjSMDIscChij75Zez9s6q9ovo9XRv3cYl6r93rSCpsQN4WMfZQPaiSk6kga eICvXkpcK9JEwqWJ6fF9NTjY50CaTl6GReiZe0RccE294tdeKEwsL2zEKDr+NOYj eDUhy7q4vBcdpg7KHPkql6DOb27C2zMPwnaqGxBh3LoPAW0/0IVggz5zyTTX42Y= =mhfc -----END PGP SIGNATURE----- --Apple-Mail=_A45F1ECD-4EC9-47B6-8EE0-409CB6BC9B5D-- From nobody Thu Jul 3 13:27:04 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC251B2B48 for ; Thu, 3 Jul 2014 13:26:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 K44T_eDyu3-v for ; Thu, 3 Jul 2014 13:26:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04F21B2B60 for ; Thu, 3 Jul 2014 13:26:45 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 3 Jul 2014 20:26:43 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0974.002; Thu, 3 Jul 2014 20:26:43 +0000 From: "Waltermire, David A." To: "sacm@ietf.org" Thread-Topic: New Version Notification for draft-wandw-sacm-information-model-00.txt Thread-Index: AQHPlvwjrAK+S4+MEEaAmcqTETTPxpuOy07w Date: Thu, 3 Jul 2014 20:26:42 +0000 Message-ID: References: <20140703201940.13572.79793.idtracker@ietfa.amsl.com> In-Reply-To: <20140703201940.13572.79793.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.225.82] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(13464003)(199002)(189002)(377424004)(107046002)(76576001)(54356999)(77982001)(86362001)(2351001)(79102001)(2656002)(92566001)(15202345003)(19580395003)(107886001)(95666004)(50986999)(76176999)(85852003)(80022001)(77096002)(99396002)(19580405001)(99286002)(74502001)(83072002)(66066001)(33646001)(21056001)(81542001)(74316001)(15975445006)(106356001)(106116001)(46102001)(85306003)(64706001)(105586002)(87936001)(83322001)(101416001)(31966008)(74662001)(76482001)(20776003)(81342001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0224; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/h2H746ClMBCfBLxNUSXhkdWViHo Subject: [sacm] FW: New Version Notification for draft-wandw-sacm-information-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:26:50 -0000 SSBqdXN0IHBvc3RlZCBhIHJlc3BvbnNlIGZvciB0aGUgQ2FsbCBmb3IgQ29udHJpYnV0aW9ucyBm b3IgdGhlIFNBQ00gSW5mb3JtYXRpb24gTW9kZWwgdGhhdCBJIGNvLWF1dGhvcmVkIHdpdGggS2lt IFdhdHNvbi4gQ29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KDQpGb3IgdGhvc2UgdGhhdCBhcmUg aW4gdGhlIFVTLCBoYXZlIGEgZ3JlYXQgNHRoIG9mIEp1bHkhIE90aGVyd2lzZSwgaGFwcHkgRnJp ZGF5IChhdCBsZWFzdCBmb3IgdG9tb3Jyb3cpIQ0KDQpTaW5jZXJlbHksDQpEYXZlDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEp1bHkgMDMs IDIwMTQgNDoyMCBQTQ0KVG86IFdhbHRlcm1pcmUsIERhdmlkIEEuOyBLaW0gV2F0c29uOyBXYWx0 ZXJtaXJlLCBEYXZpZCBBLjsgS2ltIFdhdHNvbg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC13YW5kdy1zYWNtLWluZm9ybWF0aW9uLW1vZGVsLTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YW5kdy1zYWNtLWluZm9ybWF0aW9uLW1vZGVs LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYXZpZCBXYWx0ZXJt aXJlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXdh bmR3LXNhY20taW5mb3JtYXRpb24tbW9kZWwNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlJbmZvcm1h dGlvbiBNb2RlbCBmb3IgRW5kcG9pbnQgQXNzZXNzbWVudA0KRG9jdW1lbnQgZGF0ZToJMjAxNC0w Ny0wMw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJNjkNClVSTDogICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13YW5kdy1z YWNtLWluZm9ybWF0aW9uLW1vZGVsLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmR3LXNhY20taW5mb3JtYXRpb24tbW9kZWwv DQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZHct c2FjbS1pbmZvcm1hdGlvbi1tb2RlbC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVu dCBwcm9wb3NlcyBhIGRyYWZ0IGluZm9ybWF0aW9uIG1vZGVsIGZvciBlbmRwb2ludCBwb3N0dXJl DQogICBhc3Nlc3NtZW50LiAgSXQgZGVzY3JpYmVzIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8g cGVyZm9ybSBjZXJ0YWluDQogICBhc3Nlc3NtZW50IGFjdGl2aXRpZXMuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Sun Jul 6 03:53:22 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347401A03B6 for ; Sun, 6 Jul 2014 03:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 GuRmbAjVeEyU for ; Sun, 6 Jul 2014 03:53:18 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02DB01A03AF for ; Sun, 6 Jul 2014 03:53:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMFADIpuVOHCzIm/2dsb2JhbABagmokUlqrSgEBAQEBAQaSeR6HPwGBBxZ1hAMBAQEBAwEBAQ8LHTQFBA4EAgEIDQQEAQELFAkHJwsUCQgCBAESCAEZiCABDKU0pB0XhXCJATgGgyeBFgWcPoVwhCSIMINDgjA X-IronPort-AV: E=Sophos;i="5.01,610,1400040000"; d="scan'208";a="74865664" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Jul 2014 06:53:15 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 06 Jul 2014 06:50:01 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Sun, 6 Jul 2014 06:53:14 -0400 From: "Romascanu, Dan (Dan)" To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: New Version Notification for draft-wandw-sacm-information-model-00.txt Thread-Index: AQHPlvwjrAK+S4+MEEaAmcqTETTPxpuOy07wgAQXQ/A= Date: Sun, 6 Jul 2014 10:53:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C832B55@AZ-FFEXMB04.global.avaya.com> References: <20140703201940.13572.79793.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/9Cu-X6Zw1vVNBca8oBsgaAZTkEg Subject: Re: [sacm] New Version Notification for draft-wandw-sacm-information-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 10:53:20 -0000 Dave and Kim,=20 Thanks for the submission. Will you need agenda time to discuss the contrib= ution and especially the comments received at IETF-90? How much?=20 Regards, Dan > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David > A. > Sent: Thursday, July 03, 2014 11:27 PM > To: sacm@ietf.org > Subject: [sacm] FW: New Version Notification for draft-wandw-sacm- > information-model-00.txt >=20 > I just posted a response for the Call for Contributions for the SACM > Information Model that I co-authored with Kim Watson. Comments are > appreciated. >=20 > For those that are in the US, have a great 4th of July! Otherwise, happy > Friday (at least for tomorrow)! >=20 > Sincerely, > Dave >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, July 03, 2014 4:20 PM > To: Waltermire, David A.; Kim Watson; Waltermire, David A.; Kim Watson > Subject: New Version Notification for draft-wandw-sacm-information- > model-00.txt >=20 >=20 > A new version of I-D, draft-wandw-sacm-information-model-00.txt > has been successfully submitted by David Waltermire and posted to the IET= F > repository. >=20 > Name: draft-wandw-sacm-information-model > Revision: 00 > Title: Information Model for Endpoint Assessment > Document date: 2014-07-03 > Group: Individual Submission > Pages: 69 > URL: http://www.ietf.org/internet-drafts/draft-wandw-sacm- > information-model-00.txt > Status: https://datatracker.ietf.org/doc/draft-wandw-sacm-informa= tion- > model/ > Htmlized: http://tools.ietf.org/html/draft-wandw-sacm-information- > model-00 >=20 >=20 > Abstract: > This document proposes a draft information model for endpoint posture > assessment. It describes the information needed to perform certain > assessment activities. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From nobody Sun Jul 6 16:41:56 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37E91A002F for ; Sun, 6 Jul 2014 16:41:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 pwCfWkqaMTXi for ; Sun, 6 Jul 2014 16:41:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660EF1A002E for ; Sun, 6 Jul 2014 16:41:52 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0221.namprd09.prod.outlook.com (25.160.92.143) with Microsoft SMTP Server (TLS) id 15.0.980.8; Sun, 6 Jul 2014 23:41:50 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0974.002; Sun, 6 Jul 2014 23:41:50 +0000 From: "Waltermire, David A." To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: New Version Notification for draft-wandw-sacm-information-model-00.txt Thread-Index: AQHPlvwjrAK+S4+MEEaAmcqTETTPxpuOy07wgAQXQ/CAANcqOQ== Date: Sun, 6 Jul 2014 23:41:49 +0000 Message-ID: References: <20140703201940.13572.79793.idtracker@ietfa.amsl.com> , <9904FB1B0159DA42B0B887B7FA8119CA5C832B55@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C832B55@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.16.52] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377424004)(189002)(199002)(51914003)(13464003)(164054003)(51704005)(377454003)(76576001)(76482001)(15975445006)(99396002)(54356999)(85306003)(106116001)(15202345003)(74316001)(19580405001)(21056001)(50986999)(19580395003)(76176999)(83322001)(105586002)(99286002)(95666004)(106356001)(107046002)(107886001)(80022001)(66066001)(20776003)(64706001)(101416001)(81542001)(81342001)(83072002)(85852003)(87936001)(79102001)(77096002)(77982001)(86362001)(4396001)(46102001)(2656002)(33646001)(74502001)(74662001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0221; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/m1QdAnr21mlR8MYZPs3U-e_mCFU Subject: Re: [sacm] New Version Notification for draft-wandw-sacm-information-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 23:41:55 -0000 30-45 minutes would do. Kim will likely need to present remotely if that ca= n be arranged. Thanks, Dave ________________________________________ From: Romascanu, Dan (Dan) Sent: Sunday, July 6, 2014 6:53:13 AM To: Waltermire, David A.; sacm@ietf.org Subject: RE: New Version Notification for draft-wandw-sacm-information-mode= l-00.txt Dave and Kim, Thanks for the submission. Will you need agenda time to discuss the contrib= ution and especially the comments received at IETF-90? How much? Regards, Dan > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David > A. > Sent: Thursday, July 03, 2014 11:27 PM > To: sacm@ietf.org > Subject: [sacm] FW: New Version Notification for draft-wandw-sacm- > information-model-00.txt > > I just posted a response for the Call for Contributions for the SACM > Information Model that I co-authored with Kim Watson. Comments are > appreciated. > > For those that are in the US, have a great 4th of July! Otherwise, happy > Friday (at least for tomorrow)! > > Sincerely, > Dave > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, July 03, 2014 4:20 PM > To: Waltermire, David A.; Kim Watson; Waltermire, David A.; Kim Watson > Subject: New Version Notification for draft-wandw-sacm-information- > model-00.txt > > > A new version of I-D, draft-wandw-sacm-information-model-00.txt > has been successfully submitted by David Waltermire and posted to the IET= F > repository. > > Name: draft-wandw-sacm-information-model > Revision: 00 > Title: Information Model for Endpoint Assessment > Document date: 2014-07-03 > Group: Individual Submission > Pages: 69 > URL: http://www.ietf.org/internet-drafts/draft-wandw-sacm- > information-model-00.txt > Status: https://datatracker.ietf.org/doc/draft-wandw-sacm-informa= tion- > model/ > Htmlized: http://tools.ietf.org/html/draft-wandw-sacm-information- > model-00 > > > Abstract: > This document proposes a draft information model for endpoint posture > assessment. It describes the information needed to perform certain > assessment activities. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From nobody Mon Jul 7 05:51:13 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3173A1A03FF for ; Mon, 7 Jul 2014 05:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 baIUXZ4J39oc for ; Mon, 7 Jul 2014 05:51:09 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9BE1A03FD for ; Mon, 7 Jul 2014 05:51:05 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wm4so4540451obc.34 for ; Mon, 07 Jul 2014 05:51:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=cESPfsROJLFhLSm3XlmFfUqYIamEBR+mgfemvtIMgnI=; b=YRbJxKJMYV/mDWiFjhIUTOqeW4st1nw4Y+N/HYYavMbc4LbuOm2j97mZRlugHb0HV7 kVTOUFKupePoVnWSb2xPsK/MnQnz36fQ091P72vGdE5A4oznLc1iqAF7kDJ/VGRYBXzU AsWO7LcmBIBYiqYUf/VaedSIolPWuBFbwh7OmqOR/yhe63TH+TfJuxaBEXkdA0QMFOeF 30V9Vdf/rtbegFeFoHYbueRsm7dEnUXeS4UmB35wIQ2/H01OuUYivl8xlJdHcixumKD+ Ge4MQur1vUMTg9Kn1dgIWnuFDL9hHokKIBjK1Ahmpeg1Es5V/hODii5Wqd03GkQIqbSZ uL6w== X-Gm-Message-State: ALoCoQl2x8M6JRpqIAiSRUl8d1IfTNts4Mt5SWLB38bCP/dMj5Ny8m5u0dIcA8tNvifjyr2o/EVs X-Received: by 10.182.214.98 with SMTP id nz2mr30876747obc.62.1404737465227; Mon, 07 Jul 2014 05:51:05 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:3429:90e6:4231:9e43? ([2602:306:3406:4f00:3429:90e6:4231:9e43]) by mx.google.com with ESMTPSA id ok5sm7254795obc.19.2014.07.07.05.51.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 05:51:04 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_672B7E05-5C5D-49BF-A6F5-65C34DEABD57"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <904FED9B-BF8E-4A52-954A-504FE2A43301@stoicsecurity.com> Date: Mon, 7 Jul 2014 07:49:45 -0500 To: sacm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/aNTStTI655GWzgmpB50G4SxQBnk Subject: [sacm] Updated Draft IETF 90 Agenda Posted X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 12:51:11 -0000 --Apple-Mail=_672B7E05-5C5D-49BF-A6F5-65C34DEABD57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All: Please find the updated draft agenda for our two sessions at IETF 90 = here: http://www.ietf.org/proceedings/90/agenda/agenda-90-sacm Comments welcome! Regards, Adam --Apple-Mail=_672B7E05-5C5D-49BF-A6F5-65C34DEABD57 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 iQEcBAEBCgAGBQJTupdpAAoJELhc5c4zaVWHyeIIALQJCLDnczuVObXayAGgtBLE Do7jym0LlKRm3Lo/CDp+dzsp3Ptb3+uA2VA7ODHt+sF7BVYrd4Aye4hwXRswhUQw K5wvG/kCIQf99WGQ/lmycKRGQa0+3fMleOLmYr7WEGUI8XC6PwcxmeJaP1ZUKAls XiR2uoGj2NUzdyCh/ryvAod6CX0Q5I2nkjk/WrWsdeGMd0ruP+zWBSkVStwt/YOg sjlHMRN/tRpoOY6AA4tvOsyRmPTZlh+ybgPEdbBqtq7mzr1MbNnkKycN1JSt1BQi AShbgejRIMVKfruC7uapeyAj9+CJzcfNjN/s3CkPEKh2rffVfg6RscWrFEbCmrM= =/aeR -----END PGP SIGNATURE----- --Apple-Mail=_672B7E05-5C5D-49BF-A6F5-65C34DEABD57-- From nobody Mon Jul 7 12:38:51 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD051B28A3 for ; Mon, 7 Jul 2014 12:38:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 UHDzhH8V1XlW for ; Mon, 7 Jul 2014 12:38:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D631B28A6 for ; Mon, 7 Jul 2014 12:38:46 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 7 Jul 2014 19:38:44 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0974.002; Mon, 7 Jul 2014 19:38:44 +0000 From: "Waltermire, David A." To: "sacm@ietf.org" Thread-Topic: Comments on draft-camwinget-sacm-architecture-00 Thread-Index: Ac+aGXDjl2+6g+v/RAG/k2QfnqleNQ== Date: Mon, 7 Jul 2014 19:38:44 +0000 Message-ID: <46b4400b80014af2a408ec9fe75e20f6@DM2PR09MB0224.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.225.82] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(164054003)(64706001)(87936001)(15202345003)(31966008)(83322001)(101416001)(92566001)(74662001)(2656002)(74316001)(15975445006)(85306003)(46102001)(76482001)(106356001)(110136001)(81342001)(105586002)(79102001)(19580395003)(20776003)(54356999)(16236675004)(77982001)(107046002)(76576001)(19300405004)(86362001)(2351001)(99396002)(83072002)(74502001)(99286002)(77096002)(21056001)(66066001)(81542001)(19625215002)(95666004)(229853001)(107886001)(85852003)(50986999)(4396001)(80022001)(33646001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0224; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_46b4400b80014af2a408ec9fe75e20f6DM2PR09MB0224namprd09pr_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/AkaQnQR6m9xXUE9SZv4bBxQwg9Y Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:38:50 -0000 --_000_46b4400b80014af2a408ec9fe75e20f6DM2PR09MB0224namprd09pr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After a light read, here are some quick thoughts on the draft-camwinget-sac= m-architecture-00: General: This draft is fairly light on defining the roles of repositories of differe= nt types of security automation data (e.g., guidance, attribute data, proce= ssing artifacts) which can be consumers and providers in their own right. I= don't believe these should be handled as part of the control plane, but sh= ould be considered first-class components in the architecture (perhaps as d= istinct classes of provider/consumer like collectors and evaluators.) What was the reasoning behind including these components in the control pla= ne? Section 2.1: The draft states "a Consumer may also desire to obtain the information with= out having to know the available providers." I would expect that the consumer, at minimum, should have some way of ident= ifying and authenticating the provider in addition to any authentication se= rvices provided by the control plane. To not do so would leave the system o= pen to a number of security concerns relating to potentially malicious prov= ider or middle box. Having anonymous providers would also prevent the consu= mer from knowing the provenance of the provided data, tracking history from= the same provider, or being able to go back to a given provider to query a= dditional information relative to the first exchange. I don't think this is= a workable solution. Also, an evaluator is notionally a consumer of collected posture data and a= provider of evaluation results. The notions of collectors and evaluators a= re associated with providers in section 2.2, but not with consumers in sect= ion 2.1. It should also be possible under this architecture to have aggrega= ting collectors and evaluators that request/subscribe and consume collecti= on and evaluation data respectively, and then provide the corresponding agg= regate data based on requests/subscriptions. Another case might be a collec= tor proxy such as an MDM which is a specialized type of provider/consumer. = Some discussion of this general flow should be included in the architectura= l overview (section 2). The generalization of providers and consumers is nice, but I am afraid this= will break down when we are considering mandatory to implement for data mo= dels and transports for collectors and evaluators. We may also find that th= ere are more specific requirements for specific types of provider/consumer = interfaces. More thought/discussion is needed here. I'll provide more comments once I am able to consider this architecture in = the context of the information model drafts. Thanks, Dave --_000_46b4400b80014af2a408ec9fe75e20f6DM2PR09MB0224namprd09pr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After a light read, here are some quick thoughts on = the draft-camwinget-sacm-architecture-00:

 

General:

 

This draft is fairly light on defining the roles of = repositories of different types of security automation data (e.g., guidance= , attribute data, processing artifacts) which can be consumers and provider= s in their own right. I don’t believe these should be handled as part of the control plane, but should be consid= ered first-class components in the architecture (perhaps as distinct classe= s of provider/consumer like collectors and evaluators.)

 

What was the reasoning behind including these compon= ents in the control plane?

 

Section 2.1:

 

The draft states “a Consumer may also desire t= o obtain the information without

   having to know the available providers.= ”

 

I would expect that the consumer, at minimum, should= have some way of identifying and authenticating the provider in addition t= o any authentication services provided by the control plane. To not do so w= ould leave the system open to a number of security concerns relating to potentially malicious provider or middle = box. Having anonymous providers would also prevent the consumer from knowin= g the provenance of the provided data, tracking history from the same provi= der, or being able to go back to a given provider to query additional information relative to the first exc= hange. I don’t think this is a workable solution.

 

Also, an evaluator is notionally a consumer of colle= cted posture data and a provider of evaluation results. The notions of coll= ectors and evaluators are associated with providers in section 2.2, but not= with consumers in section 2.1. It should also be possible under this architecture to have aggregating  = collectors and evaluators that request/subscribe and consume collection and= evaluation data respectively, and then provide the corresponding aggregate= data based on requests/subscriptions. Another case might be a collector proxy such as an MDM which is a speciali= zed type of provider/consumer. Some discussion of this general flow should = be included in the architectural overview (section 2).

 

The generalization of providers and consumers is nic= e, but I am afraid this will break down when we are considering mandatory t= o implement for data models and transports for collectors and evaluators. W= e may also find that there are more specific requirements for specific types of provider/consumer interfaces. = More thought/discussion is needed here.

 

I’ll provide more comments once I am able to c= onsider this architecture in the context of the information model drafts.

 

Thanks,

Dave

 

--_000_46b4400b80014af2a408ec9fe75e20f6DM2PR09MB0224namprd09pr_-- From nobody Mon Jul 7 14:23:02 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119A91B291D for ; Mon, 7 Jul 2014 14:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 k2Q_uNCItpzu for ; Mon, 7 Jul 2014 14:22:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398AB1B28E9 for ; Mon, 7 Jul 2014 14:22:56 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 7 Jul 2014 21:22:54 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0974.002; Mon, 7 Jul 2014 21:22:54 +0000 From: "Waltermire, David A." To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: Comments on draft-camwinget-sacm-architecture-00 Thread-Index: Ac+aGXDjl2+6g+v/RAG/k2QfnqleNQADMZXQ Date: Mon, 7 Jul 2014 21:22:53 +0000 Message-ID: <562088810c2148c3aadd474d359554da@DM2PR09MB0224.namprd09.prod.outlook.com> References: <46b4400b80014af2a408ec9fe75e20f6@DM2PR09MB0224.namprd09.prod.outlook.com> In-Reply-To: <46b4400b80014af2a408ec9fe75e20f6@DM2PR09MB0224.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.225.82] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(164054003)(199002)(189002)(77096002)(99286002)(19580405001)(99396002)(74502001)(83072002)(19300405004)(76576001)(77982001)(107046002)(86362001)(85852003)(107886001)(76176999)(80022001)(33646001)(4396001)(50986999)(66066001)(21056001)(95666004)(81542001)(19625215002)(15975445006)(74316001)(106356001)(76482001)(85306003)(46102001)(83322001)(31966008)(101416001)(64706001)(15202345003)(87936001)(74662001)(92566001)(2656002)(79102001)(19580395003)(54356999)(16236675004)(20776003)(81342001)(105586002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0224; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_562088810c2148c3aadd474d359554daDM2PR09MB0224namprd09pr_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/lAas46oYF3CdoyvKahPt5adurLo Subject: Re: [sacm] Comments on draft-camwinget-sacm-architecture-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:23:00 -0000 --_000_562088810c2148c3aadd474d359554daDM2PR09MB0224namprd09pr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few more questions. Is the use of a broker/proxy a required component of the architecture? If s= o, are there any concerns that this might restrict usage to only large-scal= e enterprise deployments? Is it possible for the providers/consumers to implement the broker/proxy in= terfaces directly? In other words, in the most simplistic implementation ca= se, can providers/consumers directly negotiate about tasking/formats withou= t an intermediary? If so, what functions are required for each "side" of th= e communication? Does this approach restrict the use of DNS SRV records [RFC2782] for basic= service discovery (e.g., identifying potential providers or consumers)? Can the providers/consumers work with an existing authorization provider wi= thin the enterprise or does this require a specialized SACM component? Also, one typo in section 2.3: "R's may request information independent of = knowing the identities of the P's and Providers (P's)" Is the first "P's" a consumer or is this intended to just read "identities = of the P's"? Thanks, Dave From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, July 07, 2014 3:39 PM To: sacm@ietf.org Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00 After a light read, here are some quick thoughts on the draft-camwinget-sac= m-architecture-00: General: This draft is fairly light on defining the roles of repositories of differe= nt types of security automation data (e.g., guidance, attribute data, proce= ssing artifacts) which can be consumers and providers in their own right. I= don't believe these should be handled as part of the control plane, but sh= ould be considered first-class components in the architecture (perhaps as d= istinct classes of provider/consumer like collectors and evaluators.) What was the reasoning behind including these components in the control pla= ne? Section 2.1: The draft states "a Consumer may also desire to obtain the information with= out having to know the available providers." I would expect that the consumer, at minimum, should have some way of ident= ifying and authenticating the provider in addition to any authentication se= rvices provided by the control plane. To not do so would leave the system o= pen to a number of security concerns relating to potentially malicious prov= ider or middle box. Having anonymous providers would also prevent the consu= mer from knowing the provenance of the provided data, tracking history from= the same provider, or being able to go back to a given provider to query a= dditional information relative to the first exchange. I don't think this is= a workable solution. Also, an evaluator is notionally a consumer of collected posture data and a= provider of evaluation results. The notions of collectors and evaluators a= re associated with providers in section 2.2, but not with consumers in sect= ion 2.1. It should also be possible under this architecture to have aggrega= ting collectors and evaluators that request/subscribe and consume collecti= on and evaluation data respectively, and then provide the corresponding agg= regate data based on requests/subscriptions. Another case might be a collec= tor proxy such as an MDM which is a specialized type of provider/consumer. = Some discussion of this general flow should be included in the architectura= l overview (section 2). The generalization of providers and consumers is nice, but I am afraid this= will break down when we are considering mandatory to implement for data mo= dels and transports for collectors and evaluators. We may also find that th= ere are more specific requirements for specific types of provider/consumer = interfaces. More thought/discussion is needed here. I'll provide more comments once I am able to consider this architecture in = the context of the information model drafts. Thanks, Dave --_000_562088810c2148c3aadd474d359554daDM2PR09MB0224namprd09pr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few more questions.<= o:p>

 

Is the use of a broker= /proxy a required component of the architecture? If so, are there any conce= rns that this might restrict usage to only large-scale enterprise deploymen= ts?

Is it possible for the= providers/consumers to implement the broker/proxy interfaces directly? In = other words, in the most simplistic implementation case, can providers/cons= umers directly negotiate about tasking/formats without an intermediary? If so, what functions are required for each ̶= 0;side” of the communication?

Does this approach res= trict the use of DNS SRV records  [RFC2782] for basic service discover= y (e.g., identifying potential providers or consumers)?

Can the providers/cons= umers work with an existing authorization provider within the enterprise or= does this require a specialized SACM component?

 

Also, one typo in sect= ion 2.3: “R's may request information independent of knowing the iden= tities of the P's and Providers (P's)”

 

Is the first “P&= #8217;s” a consumer or is this intended to just read “identitie= s of the P's”?

 

Thanks,

Dave=

 

From: sacm [mailto:sacm-bounces@ietf.org] = On Behalf Of Waltermire, David A.
Sent: Monday, July 07, 2014 3:39 PM
To: sacm@ietf.org
Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00

 

After a light read, here are some quick thoughts on = the draft-camwinget-sacm-architecture-00:

 

General:

 

This draft is fairly light on defining the roles of = repositories of different types of security automation data (e.g., guidance= , attribute data, processing artifacts) which can be consumers and provider= s in their own right. I don’t believe these should be handled as part of the control plane, but should be consid= ered first-class components in the architecture (perhaps as distinct classe= s of provider/consumer like collectors and evaluators.)

 

What was the reasoning behind including these compon= ents in the control plane?

 

Section 2.1:

 

The draft states “a Consumer may also desire t= o obtain the information without

   having to know the available providers.= ”

 

I would expect that the consumer, at minimum, should= have some way of identifying and authenticating the provider in addition t= o any authentication services provided by the control plane. To not do so w= ould leave the system open to a number of security concerns relating to potentially malicious provider or middle = box. Having anonymous providers would also prevent the consumer from knowin= g the provenance of the provided data, tracking history from the same provi= der, or being able to go back to a given provider to query additional information relative to the first exc= hange. I don’t think this is a workable solution.

 

Also, an evaluator is notionally a consumer of colle= cted posture data and a provider of evaluation results. The notions of coll= ectors and evaluators are associated with providers in section 2.2, but not= with consumers in section 2.1. It should also be possible under this architecture to have aggregating  = collectors and evaluators that request/subscribe and consume collection and= evaluation data respectively, and then provide the corresponding aggregate= data based on requests/subscriptions. Another case might be a collector proxy such as an MDM which is a speciali= zed type of provider/consumer. Some discussion of this general flow should = be included in the architectural overview (section 2).

 

The generalization of providers and consumers is nic= e, but I am afraid this will break down when we are considering mandatory t= o implement for data models and transports for collectors and evaluators. W= e may also find that there are more specific requirements for specific types of provider/consumer interfaces. = More thought/discussion is needed here.

 

I’ll provide more comments once I am able to c= onsider this architecture in the context of the information model drafts.

 

Thanks,

Dave

 

--_000_562088810c2148c3aadd474d359554daDM2PR09MB0224namprd09pr_-- From nobody Tue Jul 8 06:50:53 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE011B2847 for ; Tue, 8 Jul 2014 06:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 2niZ7_unjYRc for ; Tue, 8 Jul 2014 06:50:48 -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 638531B2838 for ; Tue, 8 Jul 2014 06:50:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT29401; Tue, 08 Jul 2014 13:50:45 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 14:50:44 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml705-chm.china.huawei.com ([169.254.7.240]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 06:50:33 -0700 From: Linda Dunbar To: "sacm@ietf.org" Thread-Topic: Any feedback on mechanisms of enabling enterprise (or applications) to request/verify virtual Security Function from network providers? Thread-Index: Ac+as5I8ny84HkBAR+ewAwo6IiWSUQ== Date: Tue, 8 Jul 2014 13:50:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D94D21@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.198.161] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D94D21dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/1M5yhY7ip0y88syaXIFswNxleC8 Cc: Andrew Malis , "Romascanu, Dan \(Dan\)" , Kathleen Moriarty , "Zarny, Myo" , Shaibal Chakrabarty Subject: [sacm] Any feedback on mechanisms of enabling enterprise (or applications) to request/verify virtual Security Function from network providers? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 13:50:50 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D94D21dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SACM participants: We have a draft on problem and use cases of enabling enterprise (or applic= ations) to request/verify security functions hosted by network providers: h= ttp://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf. We didn't know which IETF area or WG are good fit for the proposed work. Security Area Director Kathleen Moriaty suggests that the proposed work is = somewhat related to SACM. After reading through the SCAM charter, my initial feeling is that SCAM doe= sn't quite fit because SCAM is about the language and data format for "end= point posture assessment". What we proposed is about the mechanism to enab= le Network Security as a Service (NSaaS). I can see the mechanisms provided= by SCAM can be used for some attributes negotiation of NSaaS. But I could be wrong. We are seeking feedback from SACM group, in particular: - If what we propose fits with SACM? - Can the mechanism defined by SACM be used for NSaaS? - Any other thoughts? if it turns out that it is in the SCAM group scope, it is great. If it does= n't, we will see what else can be done. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645D94D21dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SACM participants:

 

We have a draft on pro= blem and use cases of enabling  enterprise (or applications) to reques= t/verify security functions hosted by network providers: http://tools.= ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf.

 

We didn’t know w= hich IETF area or WG are good fit for the proposed work.

Security Area Director= Kathleen Moriaty suggests that the proposed work is somewhat related to SA= CM.

After reading through = the SCAM charter, my initial feeling is that SCAM doesn’t quite fit b= ecause SCAM is about  the language and data format for “e= ndpoint posture assessment”.  What we proposed is about the mechanism to enable Network Security as a Service= (NSaaS). I can see the mechanisms provided by SCAM can be used for some at= tributes negotiation of NSaaS.

But I could be wrong. =

 

We are seeking feedbac= k from SACM group, in particular:

-&nb= sp;         If what we pro= pose fits with SACM?

-&nb= sp;         Can the mechan= ism defined by SACM be used for NSaaS?

-&nb= sp;         Any other thou= ghts?

 

if it turns out that i= t is in the SCAM group scope, it is great. If it doesn’t, we will see= what else can be done.

 

Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D94D21dfweml701chmchi_-- From nobody Fri Jul 11 12:18:36 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB79B1B2957 for ; Fri, 11 Jul 2014 12:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dLiNR3gXvgZp for ; Fri, 11 Jul 2014 12:18:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593AC1B2949 for ; Fri, 11 Jul 2014 12:18:32 -0700 (PDT) Received: from BY2PR05MB550.namprd05.prod.outlook.com (10.141.220.151) by BY2PR05MB551.namprd05.prod.outlook.com (10.141.220.152) with Microsoft SMTP Server (TLS) id 15.0.980.8; Fri, 11 Jul 2014 19:18:31 +0000 Received: from BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) by BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) with mapi id 15.00.0980.000; Fri, 11 Jul 2014 19:18:31 +0000 From: Lisa Lorenzin To: "sacm@ietf.org" Thread-Topic: New Version Notification for draft-lorenzin-sacm-tnc-information-model-00.txt Thread-Index: AQHPl3k2teiv460VB0Op+M6fvxK1DJubRoxQ Date: Fri, 11 Jul 2014 19:18:30 +0000 Message-ID: <63572899756242fea09a7dc00354122b@BY2PR05MB550.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(377424004)(199002)(189002)(377454003)(20776003)(85852003)(92566001)(19580395003)(74316001)(99286002)(85306003)(50986999)(105586002)(64706001)(76482001)(80022001)(81542001)(76576001)(83072002)(81342001)(79102001)(86362001)(77982001)(15975445006)(83322001)(4396001)(19580405001)(46102001)(21056001)(101416001)(2351001)(74662001)(107886001)(31966008)(15202345003)(107046002)(99396002)(2656002)(95666004)(66066001)(110136001)(54356999)(87936001)(106116001)(106356001)(33646001)(74502001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB551; H:BY2PR05MB550.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/1mjX0XgPMS-3BgxhPD8f8Y_Zofs Subject: [sacm] FW: New Version Notification for draft-lorenzin-sacm-tnc-information-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 19:18:34 -0000 R3JlZXRpbmdzIQ0KDQpJbiByZXNwb25zZSB0byB0aGUgU0FDTSBDYWxsIGZvciBDb250cmlidXRp b25zIGZvciBhbg0KaW5mb3JtYXRpb24gbW9kZWwsIHNldmVyYWwgY29sbGVhZ3VlcyBhbmQgSSBo YXZlIG91dGxpbmVkDQphIGRyYWZ0IGluZm9ybWF0aW9uIG1vZGVsIGZvciBTQUNNIC0gZGVzY3Jp YmVkIGluIHRoZSBiZWxvdw0KSW50ZXJuZXQtRHJhZnQgLSB0aGF0IGRyYXdzIHVwb24gb3VyIGV4 cGVyaWVuY2UgY3JlYXRpbmcsDQppbXBsZW1lbnRpbmcsIGFuZCBkZXBsb3lpbmcgVE5DIHN0YW5k YXJkcy1iYXNlZCBzb2x1dGlvbnMNCmZvciBlbmRwb2ludCBjb21wbGlhbmNlIGFuZCBzZWN1cml0 eSBhdXRvbWF0aW9uLg0KDQpUaGlzIGluZm9ybWF0aW9uIG1vZGVsIGlzIGJhc2VkIGxhcmdlbHkg b24gdGhlIFROQyBJRi1NQVANCnNwZWNpZmljYXRpb25zLiAgV2UgaGF2ZSBhdHRlbXB0ZWQgdG8g c2VwYXJhdGUgdGhlIElGLU1BUA0KZ3JhcGggbW9kZWwsIGNvbXBvbmVudHMsIGFuZCBvcGVyYXRp b25zIGZyb20gdGhlIHVuZGVybHlpbmcNCnRyYW5zcG9ydCBwcm90b2NvbDsgdG8gYXVnbWVudCB0 aGUgZXhpc3RpbmcgY29uY2VwdHMgd2l0aA0KbGVzc29ucyB3ZSd2ZSBsZWFybmVkIGZyb20gcHJv ZHVjdGlvbiBkZXBsb3ltZW50czsgYW5kIHRvDQppbGx1c3RyYXRlIGFwcGxpY2F0aW9uIG9mIHRo ZSByZXN1bHRpbmcgaW5mb3JtYXRpb24gbW9kZWwNCnRvIG9uZSBvZiB0aGUgdXNhZ2Ugc2NlbmFy aW9zIFNBQ00gc2Vla3MgdG8gYWRkcmVzcy4NCg0KV2UgbG9vayBmb3J3YXJkIHRvIGRpc2N1c3Np bmcgdGhpcyBJLUQgYW5kIGhlYXJpbmcgeW91cg0KZmVlZGJhY2sgYXQgSUVURiA5MCENCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWdh cmRzLA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTGlzYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XQ0KU2VudDogRnJpZGF5LCBKdWx5IDA0LCAyMDE0IDQ6MTUgQU0NClRvOiBMaXNhIExvcmVuemlu OyBDbGlmZm9yZCBLYWhuOyBTY290dCBQb3BlOyBTdGV2ZW4gVmVuZW1hOyBIZW5rIEJpcmtob2x6 OyBIZW5rIEJpcmtob2x6OyBTY290dCBQb3BlOyBMaXNhIExvcmVuemluOyBDbGlmZm9yZCBLYWhu OyBTdGV2ZW4gVmVuZW1hDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWxvcmVuemluLXNhY20tdG5jLWluZm9ybWF0aW9uLW1vZGVsLTAwLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sb3Jlbnppbi1zYWNtLXRuYy1pbmZvcm1hdGlvbi1tb2Rl bC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGlzYSBMb3Jlbnpp biBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAg ZHJhZnQtbG9yZW56aW4tc2FjbS10bmMtaW5mb3JtYXRpb24tbW9kZWwNClJldmlzaW9uOiAgICAg ICAwMA0KVGl0bGU6ICAgICAgICAgIFNBQ00gSW5mb3JtYXRpb24gTW9kZWwgQmFzZWQgT24gVE5D DQpEb2N1bWVudCBkYXRlOiAgMjAxNC0wNy0wMw0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDMwDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbG9yZW56aW4tc2FjbS10bmMtaW5mb3Jt YXRpb24tbW9kZWwtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbG9yZW56aW4tc2FjbS10bmMtaW5mb3JtYXRpb24tbW9kZWwvDQpI dG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9yZW56aW4t c2FjbS10bmMtaW5mb3JtYXRpb24tbW9kZWwtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhbiBpbmZvcm1hdGlvbiBtb2RlbCBmb3IgYWdncmVnYXRlZA0KICAgY29u ZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uYWwgZGF0YSwgc28gdGhhdCB0aGUgZGF0YSBjYW4gYmUg ZXZhbHVhdGVkDQogICB0byBkZXRlcm1pbmUgYW4gb3JnYW5pemF0aW9uJ3Mgc2VjdXJpdHkgcG9z dHVyZS4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Jul 15 08:40:59 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE09D1B2883 for ; Tue, 15 Jul 2014 08:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 B2IMcPEvMLDX for ; Tue, 15 Jul 2014 08:40:56 -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 421BF1B2875 for ; Tue, 15 Jul 2014 08:40:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB58079; Tue, 15 Jul 2014 15:40:53 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 16:40:52 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 08:40:49 -0700 From: Linda Dunbar To: "sacm@ietf.org" , "david.waltermire@nist.gov" , "ietfdbh@comcast.net" Thread-Topic: Questions to draft-ietf-sacm-use-cases-07 Thread-Index: Ac+gQyaskQTQ8FgYSw6H93oMds68Fw== Date: Tue, 15 Jul 2014 15:40:49 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.165] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D9CC52dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/j8j7GETInN5sHrWhWbTdWQ2J1eY Subject: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 15:40:58 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9CC52dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David W and David H: General question: - Is SACM about defining the standard "data set" or is more about = the "collection mechanism" of various data? - How is "Endpoint target" related to "endpoint"? Can you give som= e concrete examples? - Section 2.1.1: - Are there any examples for the "Data Definition" described in th= is section? or data model? - I can't figure out what "data" is SACM targeted for. - Section 2.2.1: - Can you give some examples of "specialized endpoint devices" ref= erred in the first sentence of the section? - The first paragraph talked about manufacture publishing guidelin= es on how to configure their devices. Is the objective of SACM for standard= ize those guidelines? - Section 2.2.3: - Does SACM standardize the protocols to detect "end points" attac= hment to the network? Thank you very much, Linda Dunbar Huawei USA IP Lab 5340 Legacy Drive, Plano, TX 75024 Tel: +1 469-277 - 5840 Fax: +1 469 -277 - 5900 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9CC52dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David W and David H:

 

 

General question:

-     &= nbsp;    Is SACM about defining the standard “data set= ” or is more about the “collection mechanism” of various = data?

-     &= nbsp;    How is “Endpoint target” related to = 220;endpoint”? Can you give some concrete examples?

-     &= nbsp;     

Section 2.1.1:

-     &= nbsp;    Are there any examples for the “Data Definiti= on” described in this section? or data model?

-     &= nbsp;    I can’t figure out what “data” is= SACM targeted for.

-     &= nbsp;     

Section 2.2.1:

-       = ;   Can you give some examples of “specialized en= dpoint devices” referred in the first sentence of the section?

-       = ;   The first paragraph talked about manufacture publis= hing guidelines on how to configure their devices. Is the objective of SACM= for standardize those guidelines?

-       = ;    

 

Section 2.2.3:

-       = ;   Does SACM standardize the pr= otocols to detect "end points" attachment to the network?<= o:p>

 

Thank you very much,

 

Linda Dunbar

Huawei USA IP La= b

5340 Legacy Driv= e,

Plano, TX 75024<= o:p>

Tel: +1 469-= 277 - 5840

Fax: +1 469 = -277 - 5900

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D9CC52dfweml701chmchi_-- From nobody Wed Jul 16 08:02:24 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4F01B2A22 for ; Wed, 16 Jul 2014 08:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 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, RP_MATCHES_RCVD=-0.651, 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 VoHqQtwYkNEV for ; Wed, 16 Jul 2014 08:01:54 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id EBCC01B2B88 for ; Wed, 16 Jul 2014 08:01:50 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta04.westchester.pa.mail.comcast.net with comcast id T1Ed1o0060Fqzac5431qTZ; Wed, 16 Jul 2014 15:01:50 +0000 Received: from [10.59.1.23] ([67.189.237.137]) by omta08.westchester.pa.mail.comcast.net with comcast id T31p1o00H2yZEBF3U31p5J; Wed, 16 Jul 2014 15:01:50 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_04DEE0B4-E713-4097-8AA3-09067DB2E13F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Harrington In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> Date: Wed, 16 Jul 2014 11:01:49 -0400 Message-Id: <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1878.2) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405522910; bh=cHDnFDviuNTCPvU4Ld1RcASOwWQuxrGn1QOVgTfscW4=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=efWjXmN7L+o9bCGn7+54XYJVNI13XzNDkQJs71hVIDHERlQ24eG2gKowJMq5XkbO7 EXjkPLCEuSG7hNhzxUTO0nU+oU5iu8OYkMzbG0bPs/eEz09THnyDBFN2X+iIALMxoh h7aGNzTR82rWIpeKp7P7v6OZyiaan/HBb4ze/XKwdNy2ysC6ziTGQvVtdAjMeECTRX DtTfUMQm61gPxa8ajaF4ybKEj1P3+5TuWLBU7G9jWcEkZj7aKAVy/xeSXcxZ32QLxN q/J4tZLK/eneuoZ/g92kQDN0deyKVictvmQRd9OkvlUzRs3TQW5l/fCnrxXewK3Js1 xHTX3HlVnqXXg== Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/gtKITWjdgqBoexjW2oWBhCVTBTk Cc: "sacm@ietf.org" , David Waltermire Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 15:02:05 -0000 --Apple-Mail=_04DEE0B4-E713-4097-8AA3-09067DB2E13F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Linda, I have drifted away from editing of this document, but I think I can = answer some of your questions. On Jul 15, 2014, at 11:40 AM, Linda Dunbar = wrote: > David W and David H: > =20 > =20 > General question: > - Is SACM about defining the standard =93data set=94 or is = more about the =93collection mechanism=94 of various data? Potentially, both. The charter spells out what the SACM WG is supposed = to do, and I recommend you read that to get a through answer. My thinking on this is: 1) SACM needs to define an architecture capable of supporting multiple = protocols for collecting data and making said data accessible to = processes that want to be consumers of that data. 2) SACM may need to define a generic information model for some core = information, or reuse IMs from other protocols that have already modeled = appropriate data sets. > - How is =93Endpoint target=94 related to =93endpoint=94? Can = you give some concrete examples? endpoints exist in a network. A SACM assessment process might only be interested in a subset of the = available endpoints. The members of that subset would be endpoint =93targets=94. For example, an assessment might, as part of an overall assessment = process, focus on assessing the current configuration of Huawei routers = in a heterogeneous network, based on administratively-defined rules = about how a Huawei router should be configured. Each of the selected Huawei routers in that subset would then be an = "endpoint target" for that assessment. Are you asking for concrete example so you understand the document = better, or are you asking us to add some concrete examples to the = document? (If you didn=92t understand this from the current text, then some = concrete examples in the document would seem a good idea=85.) > - =20 > Section 2.1.1: > - Are there any examples for the =93Data Definition=94 = described in this section? or data model? We have the non-unique problem that, because SACM is such a broad topic, = this WG draws people from multiple SDOs and multiple vendors with = products in the =93SACM space=94. We have avoided mentioning specific standards as examples because we = feared a rush of =93what about ?=94 requests. Do you feel that the text is too hard to understand without examples? > - I can=92t figure out what =93data=94 is SACM targeted for. Because we are currently working at such an abstract level, discussing = use cases and architectures, SACM scope includes many different = potential flows. In many cases, the =93data=94 depends on the flow involved. For example, a collector application might collect current values from a = managed switch using SNMP and MIB data models, and from a managed router = using Netconf and YANG data models. The collector might convert that data into database-specific format for = storage and fast retrieval; It might organize the data into its own = internal information models, organized to support its approach to = security assessment. When an assessment application asks the database for some data, it might = request a specific (database-record-defined) information model=92s worth = of data, or a mixed-model set of data, using an SQL request The assessment application might generate data into a report containing = the results of the assessment, possibly in, let=92s say, Excel format or = in a text message to an operator. Because SACM scope (security assessment) is very broad, it is hard to = nail down what the data is in any particular flow, without excluding = some data that somebody wants included (and is a legitimate type of data = for SACM purposes). That=92s why we=92re starting with a use cases document - to help = identify the types of data that might be needed to address certain types = of assessment. You=92re not alone. We have had lots of concern about the nebulous-ness = of the =93data=94 that SACM targets. We have been working to better differentiate the various flows of data = (data=3Dcorporate guidelines versus collected values of operational = state, for example). > - =20 > Section 2.2.1: > - Can you give some examples of =93specialized endpoint = devices=94 referred in the first sentence of the section? It can be any device that provides a specialized function, such as a = router, a switch, a firewall device, etc. > - The first paragraph talked about manufacture publishing = guidelines on how to configure their devices. Is the objective of SACM = for standardize those guidelines? No. I think these guidelines might be thought of as release notes. But part of the goal would be to encourage expressing the guidelines in = a machine-friendly format to promote automation, and possibly to = encourage vendors to use industry standard data formats. But even if the vendor doesn=92t provide the information in a = standardized format, such as a MIB module, they might explain how to use = proprietary interfaces (such as a CLI) to set and retrieve the current = values. Part of the guideline would be the vendor=92s recommendation for values = to use for the specific model of product, to achieve a specific = security-related configuration. As an example, a vendor that supports SNMPv3 in their product might = specify how to configure the View-based Access Control Model tables = (SNMP-VIEW-BASED-ACM-MIB from RFC3415). Appendix A of RFC 3415 contains an example guidelines, that could be = used by a SACM assessor to assess the security posture of an initial = configuration of an SNMPv3 deployment. As another example, the NSA provides guidelines about how to configure = routers for various security functionality. See http://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf > - =20 > =20 > Section 2.2.3: > - Does SACM standardize the protocols to detect "end points" = attachment to the network? I expect that SACM needs to be able to support multiple protocols for = this purpose. Network Management Systems often use multiple technologies to =93auto = discover=94 a network, such as ping, trace route, SNMP, etc., and they = use the information gathered to heuristically discover additional = endpoints, iteratively. SACM might use such mechanisms directly, but also might =93import=94 the = network topology from an NMS that already does auto discovery. > =20 > Thank you very much, > =20 > Linda Dunbar > Huawei USA IP Lab > 5340 Legacy Drive, > Plano, TX 75024 > Tel: +1 469-277 - 5840 > Fax: +1 469 -277 - 5900 David Harrington ietfdbh@comcast.net --Apple-Mail=_04DEE0B4-E713-4097-8AA3-09067DB2E13F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Linda,

I have drifted away from editing of this = document, but I think I can answer some of your = questions.

On Jul 15, 2014, at 11:40 AM, Linda = Dunbar <linda.dunbar@huawei.com> = wrote:

David W and David = H:
 
 
General question:
-          Is SACM about = defining the standard =93data set=94 or is more about the =93collection = mechanism=94 of various = data?

Potentially, both. = The charter spells out what the SACM WG is supposed to do, and I = recommend you read that to get a through answer.
My thinking = on this is:
1)  SACM needs to define an architecture = capable of supporting multiple protocols for collecting data and making = said data accessible to processes that want to be consumers of that = data.
2) SACM may need to define a generic information model = for some core information, or reuse IMs from other protocols that have = already modeled appropriate data = sets.


-          How is = =93Endpoint target=94 related to =93endpoint=94? Can you give some = concrete = examples?

endpoints exist = in a network.
A SACM assessment process might only be = interested in a subset of the available endpoints.
The members = of that subset would be endpoint =93targets=94.
For example, = an assessment might, as part of an overall assessment process, focus on = assessing the current configuration of Huawei routers in a heterogeneous = network, based on administratively-defined rules about how a Huawei = router should be configured.
Each of the selected Huawei = routers in that subset would then be an "endpoint target" for that = assessment.

Are you asking for concrete example = so you understand the document better, or are you asking us to add some = concrete examples to the document?
(If you didn=92t understand = this from the current text, then some concrete examples in the document = would seem a good idea=85.)


-           
Section 2.1.1:
-          Are there any = examples for the =93Data Definition=94 described in this section? or = data model?

We have the = non-unique problem that, because SACM is such a broad topic, this WG = draws people from multiple SDOs and multiple vendors with products in = the =93SACM space=94.
We have avoided mentioning specific = standards as examples because we feared a rush of =93what about <my = favorite protocol>?=94 requests.
Do you feel that the text = is too hard to understand without = examples?


-          I can=92t = figure out what =93data=94 is SACM targeted = for.


Because we are currently working at such an abstract level, discussing = use cases and architectures, SACM scope includes many different = potential flows.
In many cases, the =93data=94 depends on the = flow involved.
For example, a collector application might = collect current values from a managed switch using SNMP and MIB data = models, and from a managed router using Netconf and YANG data = models.
The collector might convert that data into = database-specific format for storage and fast retrieval; It might = organize the data into its own internal information models, organized to = support its approach to security assessment.
When an = assessment application asks the database for some data, it might request = a specific (database-record-defined) information model=92s worth of = data, or a mixed-model set of data, using an SQL request
The = assessment application might generate data into a report containing the = results of the assessment, possibly in, let=92s say, Excel format or in = a text message to an operator.

Because = SACM scope (security assessment) is very broad, it is hard to nail down = what the data is in any particular flow, without excluding some data = that somebody wants included (and is a legitimate type of data for SACM = purposes).
That=92s why we=92re starting with a use cases = document - to help identify the types of data that might be needed to = address certain types of assessment.
You=92re not alone. We = have had lots of concern about the nebulous-ness of the =93data=94 that = SACM targets.
We have been working to better differentiate the = various flows of data (data=3Dcorporate guidelines versus collected = values of operational state, for = example).


-           
Section 2.2.1:
-          Can you give = some examples of =93specialized endpoint devices=94 referred in the = first sentence of the = section?

It can be any = device that provides a specialized function, such as a router, a switch, = a firewall device, etc.

-          The first = paragraph talked about manufacture publishing guidelines on how to = configure their devices. Is the objective of SACM for standardize those = guidelines?

No. I think = these guidelines might be thought of as release notes.
But = part of the goal would be to encourage expressing the guidelines in a = machine-friendly format to promote automation, and possibly to encourage = vendors to use industry standard data formats.
But even if the = vendor doesn=92t provide the information in a standardized format, such = as a MIB module, they might explain how to use proprietary interfaces = (such as a CLI) to set and retrieve the current values.
Part = of the guideline would be the vendor=92s recommendation for values to = use for the specific model of product, to achieve a specific = security-related configuration.
As an example, a vendor that = supports SNMPv3 in their product might specify how to configure the = View-based Access Control Model tables (SNMP-VIEW-BASED-ACM-MIB from = RFC3415).
Appendix A of RFC 3415 contains an example guidelines, that could be = used by a SACM assessor to assess the security posture of an initial = configuration of an SNMPv3 deployment.

As another example, the NSA = provides guidelines about how to configure routers for various = security functionality.

-           
 
Section 2.2.3:
-          Does SACM = standardize the protocols to detect "end points" attachment to the = network?

I expect = that SACM needs to be able to support multiple protocols for this = purpose.
Network Management Systems often use multiple = technologies to =93auto discover=94 a network, such as ping, trace = route, SNMP, etc., and they use the information gathered to = heuristically discover additional endpoints, iteratively.
SACM = might use such mechanisms directly, but also might =93import=94 the = network topology from an NMS that already does auto = discovery.


 
Thank you = very much,
 
Linda = Dunbar
Huawei USA IP Lab
5340 Legacy = Drive,
Plano, TX = 75024
Tel: +1 469-277 - = 5840
Fax: +1 469 -277 - = 5900

David = Harrington

=
= --Apple-Mail=_04DEE0B4-E713-4097-8AA3-09067DB2E13F-- From nobody Wed Jul 16 09:09:17 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52C11B2BBA for ; Wed, 16 Jul 2014 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 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, RP_MATCHES_RCVD=-0.651, 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 fOMZiB2Rdgih for ; Wed, 16 Jul 2014 09:09:13 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id A15A51B2BCB for ; Wed, 16 Jul 2014 09:09:13 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta15.westchester.pa.mail.comcast.net with comcast id T32J1o0011uE5Es5F49DJJ; Wed, 16 Jul 2014 16:09:13 +0000 Received: from [10.59.1.23] ([67.189.237.137]) by omta16.westchester.pa.mail.comcast.net with comcast id T49B1o00C2yZEBF3c49CHM; Wed, 16 Jul 2014 16:09:13 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_CF0D4127-B992-4376-957D-FFA871EB0F3B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Harrington In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D94D21@dfweml701-chm.china.huawei.com> Date: Wed, 16 Jul 2014 12:09:11 -0400 Message-Id: <1D8E6F4F-2854-4FCF-BA3D-A1AF22666FBF@comcast.net> References: <4A95BA014132FF49AE685FAB4B9F17F645D94D21@dfweml701-chm.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1878.2) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405526953; bh=Qz4s+tz/VBrNbEg/acCO3p9tmwOSxBsjzQUZ6aqPqxk=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=pPo5UMakImjeJB7mBMMH1MXxGhe8vQthNaOU/RAkep/+HzsFsmgsSIi0mdgQ2PMkw zy8N06JSYxZ/HVoBuC9jk8yV7mSw8jfsEmWsZUEstxKAmUdj8fJIWYUTLG9CQ24/XP qijP1byrPiPLXaczeetM4grn4gfvPgqdh70yTm/+G6Ga+2EHpmHuc43Cx3YeVlZjRk uUMV8KWbESki5KJn0RE9hTq5XzdjR8IHY9HLzsOgoe0yVhk1z2oubS5jDEzvjEJPty 4n4vKPD6+dG4A9lL9AWGZTqcy3ED8FGm7CAG+wk6HtxEBBfMyNpHlC1yzff8mDGwfy 3hNwwQnWiSWyg== Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/mNWxIcY6Zt60a2FIOtmFyZ3vG88 Cc: "sacm@ietf.org" , Andrew Malis , "Zarny, Myo" , "Romascanu, Dan \(Dan\)" , Kathleen Moriarty , Shaibal Chakrabarty Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or applications) to request/verify virtual Security Function from network providers? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 16:09:16 -0000 --Apple-Mail=_CF0D4127-B992-4376-957D-FFA871EB0F3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Linda, I quickly scanned your draft. It appears to me, as a contributor, that your use cases seem to fit = within the scope of SACM. We are focused on endpoint assessment, but in your use cases, the = endpoint happens to be a virtual endpoint in a virtual network, but an = endpoint nonetheless. And your use cases discuss assessing the configuration of security = functionality on the virtual endpoint. Your use cases raise some concerns that might be out of scope. Inter-domain correlation would be part of the functionality of the = NMS/SMS/security manager application that is gathering reports of = assessments. I think SACM is focused mainly on creating infrastructure for assessing = individual endpoints, so those assessments can be used by applications. The infrastructure for collecting data, storing data, and making the = stored data accessible to applications would seem to be in scope. What the application does with the data would seem to be out of scope. Comparing this to an SNMP ecosystem, the IETF defines a data modeling = language, data models, and a protocol for transporting the data. It = assumes the data could be stored for later retrieval. But what an application does with the collected/retrieved MIB data is = not within the scope of the SNMP infrastructure. If the application tries to correlate MIB data across multiple = management domains, that is not part of the IETF scope. As far as I can see, almost everything in your use cases fits within = SACM. David harrington ietfdbh@comcast.net On Jul 8, 2014, at 9:50 AM, Linda Dunbar = wrote: > SACM participants: > =20 > We have a draft on problem and use cases of enabling enterprise (or = applications) to request/verify security functions hosted by network = providers: = http://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf. > =20 > We didn=92t know which IETF area or WG are good fit for the proposed = work. > Security Area Director Kathleen Moriaty suggests that the proposed = work is somewhat related to SACM. > After reading through the SCAM charter, my initial feeling is that = SCAM doesn=92t quite fit because SCAM is about the language and data = format for =93endpoint posture assessment=94. What we proposed is about = the mechanism to enable Network Security as a Service (NSaaS). I can see = the mechanisms provided by SCAM can be used for some attributes = negotiation of NSaaS. > But I could be wrong. > =20 > We are seeking feedback from SACM group, in particular: > - If what we propose fits with SACM? > - Can the mechanism defined by SACM be used for NSaaS? > - Any other thoughts? > =20 > if it turns out that it is in the SCAM group scope, it is great. If it = doesn=92t, we will see what else can be done. > =20 > Linda Dunbar > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_CF0D4127-B992-4376-957D-FFA871EB0F3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Linda,

I quickly scanned your draft.
It = appears to me, as a contributor, that your use cases seem to fit within = the scope of SACM.
We are focused on endpoint assessment, but = in your use cases, the endpoint happens to be a virtual endpoint in a = virtual network, but an endpoint nonetheless.
And your use = cases discuss assessing the configuration of security functionality on = the virtual endpoint.

Your use cases raise some = concerns that might be out of scope.
Inter-domain correlation = would be part of the functionality of the NMS/SMS/security manager = application that is gathering reports of assessments.
I think = SACM is focused mainly on creating infrastructure for assessing = individual endpoints, so those assessments can be used by = applications.
The infrastructure for collecting data, storing = data, and making the stored data accessible to applications would seem = to be in scope.
What the application does with the data would = seem to be out of scope.

Comparing this to an = SNMP ecosystem, the IETF defines a data modeling language, data models, = and a protocol for transporting the data. It assumes the data could be = stored for later retrieval.
But what an application does with = the collected/retrieved MIB data is not within the scope of the SNMP = infrastructure.
If the application tries to correlate MIB data = across multiple management domains, that is not part of the IETF = scope.
As far as I can see, almost everything in your use = cases fits within SACM.

David = harrington

=
On Jul 8, 2014, at 9:50 AM, Linda Dunbar <linda.dunbar@huawei.com> = wrote:

SACM = participants:
 
We have a draft on problem and use = cases of enabling  enterprise (or applications) to request/verify = security functions hosted by network providers: http://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement= -00.pdf.
 
We didn=92t know which IETF area or = WG are good fit for the proposed work.
Security = Area Director Kathleen Moriaty suggests that the proposed work is = somewhat related to SACM.
After reading = through the SCAM charter, my initial feeling is that SCAM doesn=92t = quite fit because SCAM is about  the language and data format for = =93endpoint posture assessment=94.  What we proposed is about the mechanism to enable = Network Security as a Service (NSaaS). I can see the mechanisms provided = by SCAM can be used for some attributes negotiation of = NSaaS.
But I could be wrong.
 
We are seeking feedback from SACM group, in = particular:
-          If what we propose fits with = SACM?
-          Can the mechanism defined by SACM be = used for NSaaS?
-          Any other = thoughts?
 
if it turns out that it is in the = SCAM group scope, it is great. If it doesn=92t, we will see what else = can be done.
 
Linda = Dunbar
 
________________________________= _______________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

= --Apple-Mail=_CF0D4127-B992-4376-957D-FFA871EB0F3B-- From nobody Wed Jul 16 14:48:44 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4653B1A034D for ; Wed, 16 Jul 2014 14:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 B0tXh28Ys5EO for ; Wed, 16 Jul 2014 14:48:39 -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 9EF071A008C for ; Wed, 16 Jul 2014 14:48:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHG62427; Wed, 16 Jul 2014 21:48:36 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 22:48:35 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 14:48:27 -0700 From: Linda Dunbar To: David Harrington Thread-Topic: [sacm] Any feedback on mechanisms of enabling enterprise (or applications) to request/verify virtual Security Function from network providers? Thread-Index: Ac+as5I8ny84HkBAR+ewAwo6IiWSUQGl2G+AAAL5c3A= Date: Wed, 16 Jul 2014 21:48:26 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9E63D@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D94D21@dfweml701-chm.china.huawei.com> <1D8E6F4F-2854-4FCF-BA3D-A1AF22666FBF@comcast.net> In-Reply-To: <1D8E6F4F-2854-4FCF-BA3D-A1AF22666FBF@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.213] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D9E63Ddfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/aYu5g_wOO9q2iaSSA-JFAouZIuA Cc: "sacm@ietf.org" , Andrew Malis , "Zarny, Myo" , "Romascanu, Dan \(Dan\)" , Kathleen Moriarty , Shaibal Chakrabarty Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or applications) to request/verify virtual Security Function from network providers? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 21:48:42 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9E63Ddfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, Thank you very much for the reply. What NSaaS intends to do is more along the line of BGP: distribute and nego= tiate relevant policies to security functions, and receives supported polic= ies for verification and coordination. So it is quite different from the Data Modeling language, like SNMP or Netc= onf. We can discuss more at Toronto. SACM chairs have allocated a slot for us at= Toronto meeting. Linda From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, July 16, 2014 11:09 AM To: Linda Dunbar Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan); Kathleen Moriarty; Z= arny, Myo; Shaibal Chakrabarty Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? Hi Linda, I quickly scanned your draft. It appears to me, as a contributor, that your use cases seem to fit within = the scope of SACM. We are focused on endpoint assessment, but in your use cases, the endpoint = happens to be a virtual endpoint in a virtual network, but an endpoint none= theless. And your use cases discuss assessing the configuration of security function= ality on the virtual endpoint. Your use cases raise some concerns that might be out of scope. Inter-domain correlation would be part of the functionality of the NMS/SMS/= security manager application that is gathering reports of assessments. I think SACM is focused mainly on creating infrastructure for assessing ind= ividual endpoints, so those assessments can be used by applications. The infrastructure for collecting data, storing data, and making the stored= data accessible to applications would seem to be in scope. What the application does with the data would seem to be out of scope. Comparing this to an SNMP ecosystem, the IETF defines a data modeling langu= age, data models, and a protocol for transporting the data. It assumes the = data could be stored for later retrieval. But what an application does with the collected/retrieved MIB data is not w= ithin the scope of the SNMP infrastructure. If the application tries to correlate MIB data across multiple management d= omains, that is not part of the IETF scope. As far as I can see, almost everything in your use cases fits within SACM. David harrington ietfdbh@comcast.net On Jul 8, 2014, at 9:50 AM, Linda Dunbar > wrote: SACM participants: We have a draft on problem and use cases of enabling enterprise (or applic= ations) to request/verify security functions hosted by network providers: h= ttp://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf. We didn't know which IETF area or WG are good fit for the proposed work. Security Area Director Kathleen Moriaty suggests that the proposed work is = somewhat related to SACM. After reading through the SCAM charter, my initial feeling is that SCAM doe= sn't quite fit because SCAM is about the language and data format for "end= point posture assessment". What we proposed is about the mechanism to enab= le Network Security as a Service (NSaaS). I can see the mechanisms provided= by SCAM can be used for some attributes negotiation of NSaaS. But I could be wrong. We are seeking feedback from SACM group, in particular: - If what we propose fits with SACM? - Can the mechanism defined by SACM be used for NSaaS? - Any other thoughts? if it turns out that it is in the SCAM group scope, it is great. If it does= n't, we will see what else can be done. Linda Dunbar _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_4A95BA014132FF49AE685FAB4B9F17F645D9E63Ddfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David,

 <= /p>

Thank you very much for t= he reply.

 <= /p>

 <= /p>

What NSaaS intends to do = is more along the line of BGP: distribute and negotiate relevant policies t= o security functions, and receives supported policies for verification and coordination.

 <= /p>

So it is quite different = from the Data Modeling language, like SNMP or Netconf.

 <= /p>

We can discuss more at To= ronto. SACM chairs have allocated a slot for us at Toronto meeting.

 <= /p>

Linda

 <= /p>

 <= /p>

From: David Ha= rrington [mailto:ietfdbh@comcast.net]
Sent: Wednesday, July 16, 2014 11:09 AM
To: Linda Dunbar
Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan); Kathleen Mori= arty; Zarny, Myo; Shaibal Chakrabarty
Subject: Re: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

Hi Linda,

 

I quickly scanned your draft.

It appears to me, as a contributor, that your use ca= ses seem to fit within the scope of SACM.

We are focused on endpoint assessment, but in your u= se cases, the endpoint happens to be a virtual endpoint in a virtual networ= k, but an endpoint nonetheless.

And your use cases discuss assessing the configurati= on of security functionality on the virtual endpoint.

 

Your use cases raise some concerns that might be out= of scope.

Inter-domain correlation would be part of the functi= onality of the NMS/SMS/security manager application that is gathering repor= ts of assessments.

I think SACM is focused mainly on creating infrastru= cture for assessing individual endpoints, so those assessments can be used = by applications.

The infrastructure for collecting data, storing data= , and making the stored data accessible to applications would seem to be in= scope.

What the application does with the data would seem t= o be out of scope.

 

Comparing this to an SNMP ecosystem, the IETF define= s a data modeling language, data models, and a protocol for transporting th= e data. It assumes the data could be stored for later retrieval.=

But what an application does with the collected/retr= ieved MIB data is not within the scope of the SNMP infrastructure.

If the application tries to correlate MIB data acros= s multiple management domains, that is not part of the IETF scope.

As far as I can see, almost everything in your use c= ases fits within SACM.

 

David harrington

 

On Jul 8, 2014, at 9:50 AM, Linda Dunbar <linda.dunbar@huawei.com> wrote:<= o:p>



SACM participants:

 

We have a draft on proble= m and use cases of enabling  enterprise (or applications) to request/v= erify security functions hosted by network providers: http://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.p= df.

 

We didn’t know whic= h IETF area or WG are good fit for the proposed work.

Security Area Director Ka= thleen Moriaty suggests that the proposed work is somewhat related to SACM.=

After reading through the= SCAM charter, my initial feeling is that SCAM doesn’t quite fit beca= use SCAM is about  the language and data format for “endpoint posture assessment”.  What we pro= posed is about the mechanism to enable Network Security as a Service (NSaaS= ). I can see the mechanisms provided by SCAM can be used for some attribute= s negotiation of NSaaS.

But I could be wrong.

 

We are seeking feedback f= rom SACM group, in particular:

-   = ;      =  If what we propose fits with SACM?

-   = ;      =  Can the mechanism defined by SACM be used for NSaaS?<= /o:p>

-   = ;      =  Any other thoughts?

 

if it turns out that it i= s in the SCAM group scope, it is great. If it doesn’t, we will see wh= at else can be done.

 

Linda Dunbar

 

______________________________________= _________
sacm mailing list
sacm@ietf.org=
https://www.ietf.org/mailman/listinfo/sacm

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D9E63Ddfweml701chmchi_-- From nobody Wed Jul 16 15:42:36 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF6B1A0384 for ; Wed, 16 Jul 2014 15:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 1oOkjuhmGFtu for ; Wed, 16 Jul 2014 15:42:30 -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 E4A751A0382 for ; Wed, 16 Jul 2014 15:42:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHG64588; Wed, 16 Jul 2014 22:42:27 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 23:42:26 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 15:42:22 -0700 From: Linda Dunbar To: David Harrington Thread-Topic: Questions to draft-ietf-sacm-use-cases-07 Thread-Index: Ac+gQyaskQTQ8FgYSw6H93oMds68FwA/mQWAAACntdA= Date: Wed, 16 Jul 2014 22:42:22 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> In-Reply-To: <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.213] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D9E6E3dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/C2IP43g-vz9ogF9OofNU6xnNgH8 Cc: "sacm@ietf.org" , David Waltermire Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:42:33 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9E6E3dfweml701chmchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, Reading through your explanation make me feel SACM is more like what NETCON= F wants to do, except SACM is the reverse direction, isn't it? NETCONF: Controller (or NMS) --> device; SACM: devices --> Controller (or NMS) More questions/comments are inserted below: From: David Harrington [mailto:ietfdbh@comcast.net] - How is "Endpoint target" related to "endpoint"? Can you give som= e concrete examples? endpoints exist in a network. A SACM assessment process might only be interested in a subset of the avail= able endpoints. The members of that subset would be endpoint "targets". For example, an assessment might, as part of an overall assessment process,= focus on assessing the current configuration of Huawei routers in a hetero= geneous network, based on administratively-defined rules about how a Huawei= router should be configured. Each of the selected Huawei routers in that subset would then be an "endpoi= nt target" for that assessment. [Linda] Does it mean SACM is like NETCONF, except the information is from D= evices to Controller (or NMS)? Are you asking for concrete example so you understand the document better, = or are you asking us to add some concrete examples to the document? (If you didn't understand this from the current text, then some concrete ex= amples in the document would seem a good idea....) [Linda] absolutely some examples will help a lot. Use cases are supposed to= be examples, examples of "end points", examples of actual "data" to be col= lected, examples of "data-definitions" used in the draft, etc. - Section 2.1.1: - Are there any examples for the "Data Definition" described in th= is section? or data model? We have the non-unique problem that, because SACM is such a broad topic, th= is WG draws people from multiple SDOs and multiple vendors with products in= the "SACM space". We have avoided mentioning specific standards as examples because we feared= a rush of "what about ?" requests. Do you feel that the text is too hard to understand without examples? [Linda] I thought that IETF doesn't do too broad problems WG. Are there exa= mples of "Data Definitions" in mind? - I can't figure out what "data" is SACM targeted for. Because we are currently working at such an abstract level, discussing use = cases and architectures, SACM scope includes many different potential flows= . In many cases, the "data" depends on the flow involved. For example, a collector application might collect current values from a ma= naged switch using SNMP and MIB data models, and from a managed router usin= g Netconf and YANG data models. The collector might convert that data into database-specific format for sto= rage and fast retrieval; It might organize the data into its own internal i= nformation models, organized to support its approach to security assessment= . When an assessment application asks the database for some data, it might re= quest a specific (database-record-defined) information model's worth of dat= a, or a mixed-model set of data, using an SQL request The assessment application might generate data into a report containing the= results of the assessment, possibly in, let's say, Excel format or in a te= xt message to an operator. [Linda] Does SACM target to have one proxy data models for "NETCONF, SNMP, = SQL, ..."? Because SACM scope (security assessment) is very broad, it is hard to nail = down what the data is in any particular flow, without excluding some data t= hat somebody wants included (and is a legitimate type of data for SACM purp= oses). That's why we're starting with a use cases document - to help identify the = types of data that might be needed to address certain types of assessment. [Linda] Then the Use Case document should have concrete examples. You're not alone. We have had lots of concern about the nebulous-ness of th= e "data" that SACM targets. We have been working to better differentiate the various flows of data (dat= a=3Dcorporate guidelines versus collected values of operational state, for = example). - Section 2.2.1: - Can you give some examples of "specialized endpoint devices" ref= erred in the first sentence of the section? It can be any device that provides a specialized function, such as a router= , a switch, a firewall device, etc. [Linda] Is SACM trying to get one model for "router/switch/firewall"? How i= s it different from SNMP? - The first paragraph talked about manufacture publishing guidelin= es on how to configure their devices. Is the objective of SACM for standard= ize those guidelines? No. I think these guidelines might be thought of as release notes. But part of the goal would be to encourage expressing the guidelines in a m= achine-friendly format to promote automation, and possibly to encourage ven= dors to use industry standard data formats. But even if the vendor doesn't provide the information in a standardized fo= rmat, such as a MIB module, they might explain how to use proprietary inter= faces (such as a CLI) to set and retrieve the current values. Part of the guideline would be the vendor's recommendation for values to us= e for the specific model of product, to achieve a specific security-related= configuration. As an example, a vendor that supports SNMPv3 in their product might specify= how to configure the View-based Access Control Model tables (SNMP-VIEW-BAS= ED-ACM-MIB from RFC3415). Appendix A of RFC 3415 contains an example guidelines, that could be used b= y a SACM assessor to assess the security posture of an initial configuratio= n of an SNMPv3 deployment. As another example, the NSA provides guidelines about how to configure rout= ers for various security functionality. See http://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf - Section 2.2.3: - Does SACM standardize the protocols to detect "end points" attac= hment to the network? I expect that SACM needs to be able to support multiple protocols for this = purpose. Network Management Systems often use multiple technologies to "auto discove= r" a network, such as ping, trace route, SNMP, etc., and they use the infor= mation gathered to heuristically discover additional endpoints, iteratively= . SACM might use such mechanisms directly, but also might "import" the networ= k topology from an NMS that already does auto discovery. Thank you very much, Linda Dunbar Huawei USA IP Lab 5340 Legacy Drive, Plano, TX 75024 Tel: +1 469-277 - 5840 Fax: +1 469 -277 - 5900 David Harrington ietfdbh@comcast.net --_000_4A95BA014132FF49AE685FAB4B9F17F645D9E6E3dfweml701chmchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

David,

 <= /p>

Reading through your expl= anation make me feel SACM is more like what NETCONF wants to do, except SAC= M is the reverse direction, isn’t it?  

NETCONF: Controller (or N= MS) =E0 device;

SACM: devices =E0 Controller (or NMS)

 <= /p>

More questions/comments a= re inserted below:

 <= /p>

 <= /p>

From: David Ha= rrington [mailto:ietfdbh@comcast.net]

 

 

 



-       &nb= sp;  How is “Endpoint target” related to “endpoint”? Can yo= u give some concrete examples?

 

endpoints exist in a network.

A SACM assessment process might only be interested i= n a subset of the available endpoints.

The members of that subset would be endpoint “= targets”.

For example, an assessment might, as part of an over= all assessment process, focus on assessing the current configuration of Hua= wei routers in a heterogeneous network, based on administratively-defined r= ules about how a Huawei router should be configured.

Each of the selected Huawei routers in that subset w= ould then be an "endpoint target" for that assessment.=

 

[Linda] Does it mean SACM= is like NETCONF, except the information is from Devices to Controller (or = NMS)?

 <= /p>

Are you asking for concrete example so you understan= d the document better, or are you asking us to add some concrete examples t= o the document?

(If you didn’t understand this from the curren= t text, then some concrete examples in the document would seem a good idea&= #8230;.)

 

[Linda] absolutely some e= xamples will help a lot. Use cases are supposed to be examples, examples of= “end points”, examples of actual “data” to be coll= ected, examples of “data-definitions” used in the draft, etc.

 <= /p>



-       &nb= sp;   

Section 2.1.1:

-       &nb= sp;  Are there any examples for the “Data Definition” described in this= section? or data model?

 

We have the non-unique problem that, because SACM is= such a broad topic, this WG draws people from multiple SDOs and multiple v= endors with products in the “SACM space”.

We have avoided mentioning specific standards as exa= mples because we feared a rush of “what about <my favorite protoco= l>?” requests.

Do you feel that the text is too hard to understand = without examples?

 <= /p>

[Linda] I thought that IE= TF doesn’t do too broad problems WG. Are there examples of “Dat= a Definitions” in mind?

 



-       &nb= sp;  I can’t figure out what “data” is SACM targeted for.<= /o:p>

 

 

Because we are currently working at such an abstract= level, discussing use cases and architectures, SACM scope includes many di= fferent potential flows.

In many cases, the “data” depends on the= flow involved.

For example, a collector application might collect c= urrent values from a managed switch using SNMP and MIB data models, and fro= m a managed router using Netconf and YANG data models.

The collector might convert that data into database-= specific format for storage and fast retrieval; It might organize the data = into its own internal information models, organized to support its approach= to security assessment.

When an assessment application asks the database for= some data, it might request a specific (database-record-defined) informati= on model’s worth of data, or a mixed-model set of data, using an SQL = request

The assessment application might generate data into = a report containing the results of the assessment, possibly in, let’s= say, Excel format or in a text message to an operator.

 <= /p>

[Linda] Does SACM target = to have one proxy data models for “NETCONF, SNMP, SQL, …”= ?

 

Because SACM scope (security assessment) is very bro= ad, it is hard to nail down what the data is in any particular flow, withou= t excluding some data that somebody wants included (and is a legitimate typ= e of data for SACM purposes).

That’s why we’re starting with a use cas= es document - to help identify the types of data that might be needed to ad= dress certain types of assessment.

 <= /p>

[Linda] Then the Use Case= document should have concrete examples.

 <= /p>

You’re not alone. We have had lots of concern = about the nebulous-ness of the “data” that SACM targets.

We have been working to better differentiate the var= ious flows of data (data=3Dcorporate guidelines versus collected values of = operational state, for example).

 



-       &nb= sp;   

Section 2.2.1:

-       &nb= sp;  Can you give some examples of “specialized endpoint devices” refer= red in the first sentence of the section?

 

It can be any device that provides a specialized fun= ction, such as a router, a switch, a firewall device, etc.

 

[Linda] Is SACM trying to= get one model for “router/switch/firewall”? How is it differen= t from SNMP?



-       &nb= sp;  The first paragraph talked about manufacture publishing guidelines on how to c= onfigure their devices. Is the objective of SACM for standardize those guid= elines?

 

No. I think these guidelines might be thought of as = release notes.

But part of the goal would be to encourage expressin= g the guidelines in a machine-friendly format to promote automation, and po= ssibly to encourage vendors to use industry standard data formats.

But even if the vendor doesn’t provide the inf= ormation in a standardized format, such as a MIB module, they might explain= how to use proprietary interfaces (such as a CLI) to set and retrieve the = current values.

Part of the guideline would be the vendor’s re= commendation for values to use for the specific model of product, to achiev= e a specific security-related configuration.

As an example, a vendor that supports SNMPv3 in thei= r product might specify how to configure the View-based Access Control Mode= l tables (SNMP-VIEW-BASED-ACM-MIB from RFC3= 415).

Appendix A of RFC 34= 15 contains an example guideli= nes, that could be used by a SACM assessor to assess the security posture o= f an initial configuration of an SNMPv3 deployment.

 

As another example,= the NSA provides guidelines about how to configure routers for variou= s security functionality.



-       &nb= sp;   

 

Section 2.2.3:

-       &nb= sp;  Does SACM standardize the protocols to detect "end points" attachment= to the network?

 

I expect that SACM needs to be able to support multi= ple protocols for this purpose.

Network Management Systems often use multiple techno= logies to “auto discover” a network, such as ping, trace route,= SNMP, etc., and they use the information gathered to heuristically discove= r additional endpoints, iteratively.

SACM might use such mechanisms directly, but also mi= ght “import” the network topology from an NMS that already does= auto discovery.

 



 

Thank you very much,<= /p>

 

Linda Dunbar

Huawei USA IP Lab

5340 Legacy Drive,

Plano, TX 75024

Tel: +1 469-277 - 5840

Fax: +1 469 -277 - 5900

 

David Harrington

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D9E6E3dfweml701chmchi_-- From nobody Thu Jul 17 08:55:02 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E651A0181 for ; Thu, 17 Jul 2014 08:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-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 lcODZq7VDCcE for ; Thu, 17 Jul 2014 08:54:57 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB491A0176 for ; Thu, 17 Jul 2014 08:54:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=Krrxvo/+FtWGpRDMivx+AMXPtgX56J2kkvCQKWP4kdanHPJtUPnEt1trueHrflxyutCvyOg3QF/x4LIzGSUfWMqQ+/poC5wFvcXZIfHeq7ePnFd29lRLQtvjn8nAaZJl; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 27274 invoked from network); 17 Jul 2014 09:08:02 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by server.threatguard.com with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 17 Jul 2014 09:08:02 -0700 Message-ID: <53C7F1CF.4070408@ThreatGuard.com> Date: Thu, 17 Jul 2014 11:54:55 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Dunbar , David Harrington References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/PSDACfEnQjImkq5rt_-P9cnizvI Cc: "sacm@ietf.org" , David Waltermire Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:55:01 -0000 Linda, Let me restate what David has said in a different way and see if that is of any help. SACM is about standards for automating the security assessments of endpoints. That starts with an expression of security policies in a form that a machine can apply, but also needs to include the abilities to determine applicability of each policy to an endpoint (and find all policies that apply to an endpoint), to generate a list of endpoints, and to request/receive data items for each endpoint necessary to complete analysis of the policy(ies). This working group is still in the process of defining requirements for all of this let alone determining what form any of these will take, but it looks like this will result in discrete components that can be used for other purposes. That could mean, for example, taking advantage of a SACM-compliant system to collect specific data times from certain classes of endpoints for your own analysis, or it could mean creating automated policies that use SACM to produce a set of results and then doing further analysis or aggregation on that result set. Given that any endpoint may or may not be owned by the interested party, as recognized in your proposal, there would be a spectrum along which security posture could be determined: 1) Direct query of endpoint attributes 2) Indirect query of endpoint attributes (SACM collection)* 3) Request for validation at the SACM policy level 4) Stating desired policy and validation via behavioral analysis 5) Stating desired policy with no external validation 6) Service Level Agreement contract 7) None. The lower the number the more reliable (and current) the results, but a 3rd party is certainly not going to make #1 available. However, given the direction SACM is going, I would think that #2 and #3 are very possible. Incidentally, this exact problem is something NIST started bringing under the SCAP umbrella about five years ago, so it's a happy confluence to see you bringing this up with SACM. --gun * A SACM query should be as reliable as a direct query, but a mechanism for guaranteeing this has not yet been worked out. On 7/16/2014 6:42 PM, Linda Dunbar wrote: > David, > > Reading through your explanation make me feel SACM is more like what > NETCONF wants to do, except SACM is the reverse direction, isn’t it? > > NETCONF: Controller (or NMS) àdevice; > > SACM: devices àController (or NMS) > > More questions/comments are inserted below: > > *From:*David Harrington [mailto:ietfdbh@comcast.net] > > > > -How is “Endpoint target” related to “endpoint”? Can you give some > concrete examples? > > endpoints exist in a network. > > A SACM assessment process might only be interested in a subset of the > available endpoints. > > The members of that subset would be endpoint “targets”. > > For example, an assessment might, as part of an overall assessment > process, focus on assessing the current configuration of Huawei routers > in a heterogeneous network, based on administratively-defined rules > about how a Huawei router should be configured. > > Each of the selected Huawei routers in that subset would then be an > "endpoint target" for that assessment. > > [Linda] Does it mean SACM is like NETCONF, except the information is > from Devices to Controller (or NMS)? > > Are you asking for concrete example so you understand the document > better, or are you asking us to add some concrete examples to the document? > > (If you didn’t understand this from the current text, then some concrete > examples in the document would seem a good idea….) > > [Linda] absolutely some examples will help a lot. Use cases are supposed > to be examples, examples of “end points”, examples of actual “data” to > be collected, examples of “data-definitions” used in the draft, etc. > > > > - > > Section 2.1.1: > > -Are there any examples for the “Data Definition” described in this > section? or data model? > > We have the non-unique problem that, because SACM is such a broad topic, > this WG draws people from multiple SDOs and multiple vendors with > products in the “SACM space”. > > We have avoided mentioning specific standards as examples because we > feared a rush of “what about ?” requests. > > Do you feel that the text is too hard to understand without examples? > > [Linda] I thought that IETF doesn’t do too broad problems WG. Are there > examples of “Data Definitions” in mind? > > > > -I can’t figure out what “data” is SACM targeted for. > > Because we are currently working at such an abstract level, discussing > use cases and architectures, SACM scope includes many different > potential flows. > > In many cases, the “data” depends on the flow involved. > > For example, a collector application might collect current values from a > managed switch using SNMP and MIB data models, and from a managed router > using Netconf and YANG data models. > > The collector might convert that data into database-specific format for > storage and fast retrieval; It might organize the data into its own > internal information models, organized to support its approach to > security assessment. > > When an assessment application asks the database for some data, it might > request a specific (database-record-defined) information model’s worth > of data, or a mixed-model set of data, using an SQL request > > The assessment application might generate data into a report containing > the results of the assessment, possibly in, let’s say, Excel format or > in a text message to an operator. > > [Linda] Does SACM target to have one proxy data models for “NETCONF, > SNMP, SQL, …”? > > Because SACM scope (security assessment) is very broad, it is hard to > nail down what the data is in any particular flow, without excluding > some data that somebody wants included (and is a legitimate type of data > for SACM purposes). > > That’s why we’re starting with a use cases document - to help identify > the types of data that might be needed to address certain types of > assessment. > > [Linda] Then the Use Case document should have concrete examples. > > You’re not alone. We have had lots of concern about the nebulous-ness of > the “data” that SACM targets. > > We have been working to better differentiate the various flows of data > (data=corporate guidelines versus collected values of operational state, > for example). > > > > - > > Section 2.2.1: > > -Can you give some examples of “specialized endpoint devices” referred > in the first sentence of the section? > > It can be any device that provides a specialized function, such as a > router, a switch, a firewall device, etc. > > [Linda] Is SACM trying to get one model for “router/switch/firewall”? > How is it different from SNMP? > > > > -The first paragraph talked about manufacture publishing guidelines on > how to configure their devices. Is the objective of SACM for standardize > those guidelines? > > No. I think these guidelines might be thought of as release notes. > > But part of the goal would be to encourage expressing the guidelines in > a machine-friendly format to promote automation, and possibly to > encourage vendors to use industry standard data formats. > > But even if the vendor doesn’t provide the information in a standardized > format, such as a MIB module, they might explain how to use proprietary > interfaces (such as a CLI) to set and retrieve the current values. > > Part of the guideline would be the vendor’s recommendation for values to > use for the specific model of product, to achieve a specific > security-related configuration. > > As an example, a vendor that supports SNMPv3 in their product might > specify how to configure the View-based Access Control Model tables > (SNMP-VIEW-BASED-ACM-MIB from RFC3415). > > Appendix A of RFC 3415 contains an example guidelines, that could be > used by a SACM assessor to assess the security posture of an initial > configuration of an SNMPv3 deployment. > > As another example, the NSA provides guidelines about how to configure > routers for various security functionality. > > See http://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf > > > > - > > Section 2.2.3: > > -Does SACM standardize the protocols to detect "end points" attachment > to the network? > > I expect that SACM needs to be able to support multiple protocols for > this purpose. > > Network Management Systems often use multiple technologies to “auto > discover” a network, such as ping, trace route, SNMP, etc., and they use > the information gathered to heuristically discover additional endpoints, > iteratively. > > SACM might use such mechanisms directly, but also might “import” the > network topology from an NMS that already does auto discovery. > > > > Thank you very much, > > Linda Dunbar > > *Huawei USA IP Lab* > > *5340 Legacy Drive,* > > *Plano, TX 75024* > > *Tel: +1 469-277 - 5840* > > *Fax: +1 469 -277 - 5900* > > David Harrington > > ietfdbh@comcast.net > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From nobody Thu Jul 17 09:56:00 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84471A0201 for ; Thu, 17 Jul 2014 09:55:30 -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, 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 J2syMUUv1LVt for ; Thu, 17 Jul 2014 09:55:28 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5171E1A016F for ; Thu, 17 Jul 2014 09:55:27 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id c11so1933679lbj.5 for ; Thu, 17 Jul 2014 09:55:25 -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=JlAZK3jfooh6j0n64yg/E/hMOG8ZztXfLZQruarKahU=; b=RS1BAUcUZ5CI4LmxJ6Dq/cuIKc+a2pdd9N0rbnrO6uSlWCiMohqsWhXXjhSaAuxN3u SiJLIVbW6lFUKz+9BsKrJrwpS+qi60Ce/oxV2bt8Kr7AGmtvxtY5IjWsg5pcKmyIJPbo nsR7Pc18YYHjnnaXyv70fuUGoanY/tgNVFJx7xzmMzuXfIxK5/RnEOXGQShPkv4wrF/H Xty98+fzHj2u0bNHrZRfua1rq9+YH2E7OXltEpEBZUsk+1y4B5JGpxK9ro5PSm1tZNgz kMZaQxrlRw+uBL6XdzNxn0E+u9GYVX74UFKTnnQHyqAxY02bMgewlIqfL7WMHeYCkd7I OPpw== MIME-Version: 1.0 X-Received: by 10.152.26.37 with SMTP id i5mr34166160lag.17.1405616125592; Thu, 17 Jul 2014 09:55:25 -0700 (PDT) Received: by 10.112.207.73 with HTTP; Thu, 17 Jul 2014 09:55:25 -0700 (PDT) In-Reply-To: <53C7F1CF.4070408@ThreatGuard.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> <53C7F1CF.4070408@ThreatGuard.com> Date: Thu, 17 Jul 2014 12:55:25 -0400 Message-ID: From: Kathleen Moriarty To: Gunnar Engelbach Content-Type: multipart/alternative; boundary=089e0160a476db47c404fe668193 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/50fAe6XTCz4fdUuEwYoR63yb_Qo Cc: David Waltermire , David Harrington , "sacm@ietf.org" , Linda Dunbar Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:55:30 -0000 --089e0160a476db47c404fe668193 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable SACM doesn't preclude the use of existing interfaces to access endpoint information, just to make sure that point is clear. The issued a wide call for proposals and are open to submissions to meet their use cases, etc. On Thu, Jul 17, 2014 at 11:54 AM, Gunnar Engelbach < Gunnar.Engelbach@threatguard.com> wrote: > > Linda, > > Let me restate what David has said in a different way and see if that is > of any help. > > SACM is about standards for automating the security assessments of > endpoints. That starts with an expression of security policies in a form > that a machine can apply, but also needs to include the abilities to > determine applicability of each policy to an endpoint (and find all > policies that apply to an endpoint), to generate a list of endpoints, and > to request/receive data items for each endpoint necessary to complete > analysis of the policy(ies). > > This working group is still in the process of defining requirements for > all of this let alone determining what form any of these will take, but i= t > looks like this will result in discrete components that can be used for > other purposes. > > That could mean, for example, taking advantage of a SACM-compliant system > to collect specific data times from certain classes of endpoints for your > own analysis, or it could mean creating automated policies that use SACM = to > produce a set of results and then doing further analysis or aggregation o= n > that result set. > > > Given that any endpoint may or may not be owned by the interested party, > as recognized in your proposal, there would be a spectrum along which > security posture could be determined: > > 1) Direct query of endpoint attributes > 2) Indirect query of endpoint attributes (SACM collection)* > 3) Request for validation at the SACM policy level > 4) Stating desired policy and validation via behavioral analysis > 5) Stating desired policy with no external validation > 6) Service Level Agreement contract > 7) None. > > The lower the number the more reliable (and current) the results, but a > 3rd party is certainly not going to make #1 available. However, given th= e > direction SACM is going, I would think that #2 and #3 are very possible. > > > Incidentally, this exact problem is something NIST started bringing under > the SCAP umbrella about five years ago, so it's a happy confluence to see > you bringing this up with SACM. > > > --gun > > > > * A SACM query should be as reliable as a direct query, but a mechanism > for guaranteeing this has not yet been worked out. > > > > On 7/16/2014 6:42 PM, Linda Dunbar wrote: > >> David, >> >> Reading through your explanation make me feel SACM is more like what >> NETCONF wants to do, except SACM is the reverse direction, isn=E2=80=99t= it? >> >> NETCONF: Controller (or NMS) =C3=A0device; >> >> SACM: devices =C3=A0Controller (or NMS) >> >> >> More questions/comments are inserted below: >> >> *From:*David Harrington [mailto:ietfdbh@comcast.net] >> >> >> >> -How is =E2=80=9CEndpoint target=E2=80=9D related to =E2=80=9Cendpoint= =E2=80=9D? Can you give some >> >> concrete examples? >> >> endpoints exist in a network. >> >> A SACM assessment process might only be interested in a subset of the >> available endpoints. >> >> The members of that subset would be endpoint =E2=80=9Ctargets=E2=80=9D. >> >> For example, an assessment might, as part of an overall assessment >> process, focus on assessing the current configuration of Huawei routers >> in a heterogeneous network, based on administratively-defined rules >> about how a Huawei router should be configured. >> >> Each of the selected Huawei routers in that subset would then be an >> "endpoint target" for that assessment. >> >> [Linda] Does it mean SACM is like NETCONF, except the information is >> from Devices to Controller (or NMS)? >> >> Are you asking for concrete example so you understand the document >> better, or are you asking us to add some concrete examples to the >> document? >> >> (If you didn=E2=80=99t understand this from the current text, then some = concrete >> examples in the document would seem a good idea=E2=80=A6.) >> >> [Linda] absolutely some examples will help a lot. Use cases are supposed >> to be examples, examples of =E2=80=9Cend points=E2=80=9D, examples of ac= tual =E2=80=9Cdata=E2=80=9D to >> be collected, examples of =E2=80=9Cdata-definitions=E2=80=9D used in the= draft, etc. >> >> >> >> - >> >> Section 2.1.1: >> >> -Are there any examples for the =E2=80=9CData Definition=E2=80=9D descri= bed in this >> >> section? or data model? >> >> We have the non-unique problem that, because SACM is such a broad topic, >> this WG draws people from multiple SDOs and multiple vendors with >> products in the =E2=80=9CSACM space=E2=80=9D. >> >> We have avoided mentioning specific standards as examples because we >> feared a rush of =E2=80=9Cwhat about ?=E2=80=9D re= quests. >> >> Do you feel that the text is too hard to understand without examples? >> >> [Linda] I thought that IETF doesn=E2=80=99t do too broad problems WG. Ar= e there >> examples of =E2=80=9CData Definitions=E2=80=9D in mind? >> >> >> >> -I can=E2=80=99t figure out what =E2=80=9Cdata=E2=80=9D is SACM targeted= for. >> >> >> Because we are currently working at such an abstract level, discussing >> use cases and architectures, SACM scope includes many different >> potential flows. >> >> In many cases, the =E2=80=9Cdata=E2=80=9D depends on the flow involved. >> >> For example, a collector application might collect current values from a >> managed switch using SNMP and MIB data models, and from a managed router >> using Netconf and YANG data models. >> >> The collector might convert that data into database-specific format for >> storage and fast retrieval; It might organize the data into its own >> internal information models, organized to support its approach to >> security assessment. >> >> When an assessment application asks the database for some data, it might >> request a specific (database-record-defined) information model=E2=80=99s= worth >> of data, or a mixed-model set of data, using an SQL request >> >> The assessment application might generate data into a report containing >> the results of the assessment, possibly in, let=E2=80=99s say, Excel for= mat or >> in a text message to an operator. >> >> [Linda] Does SACM target to have one proxy data models for =E2=80=9CNETC= ONF, >> SNMP, SQL, =E2=80=A6=E2=80=9D? >> >> Because SACM scope (security assessment) is very broad, it is hard to >> nail down what the data is in any particular flow, without excluding >> some data that somebody wants included (and is a legitimate type of data >> for SACM purposes). >> >> That=E2=80=99s why we=E2=80=99re starting with a use cases document - to= help identify >> the types of data that might be needed to address certain types of >> assessment. >> >> [Linda] Then the Use Case document should have concrete examples. >> >> You=E2=80=99re not alone. We have had lots of concern about the nebulous= -ness of >> the =E2=80=9Cdata=E2=80=9D that SACM targets. >> >> We have been working to better differentiate the various flows of data >> (data=3Dcorporate guidelines versus collected values of operational stat= e, >> for example). >> >> >> >> - >> >> Section 2.2.1: >> >> -Can you give some examples of =E2=80=9Cspecialized endpoint devices=E2= =80=9D referred >> >> in the first sentence of the section? >> >> It can be any device that provides a specialized function, such as a >> router, a switch, a firewall device, etc. >> >> [Linda] Is SACM trying to get one model for =E2=80=9Crouter/switch/firew= all=E2=80=9D? >> How is it different from SNMP? >> >> >> >> -The first paragraph talked about manufacture publishing guidelines on >> >> how to configure their devices. Is the objective of SACM for standardize >> those guidelines? >> >> No. I think these guidelines might be thought of as release notes. >> >> But part of the goal would be to encourage expressing the guidelines in >> a machine-friendly format to promote automation, and possibly to >> encourage vendors to use industry standard data formats. >> >> But even if the vendor doesn=E2=80=99t provide the information in a stan= dardized >> format, such as a MIB module, they might explain how to use proprietary >> interfaces (such as a CLI) to set and retrieve the current values. >> >> Part of the guideline would be the vendor=E2=80=99s recommendation for v= alues to >> use for the specific model of product, to achieve a specific >> security-related configuration. >> >> As an example, a vendor that supports SNMPv3 in their product might >> specify how to configure the View-based Access Control Model tables >> (SNMP-VIEW-BASED-ACM-MIB from RFC3415). >> >> Appendix A of RFC 3415 contains an example guidelines, that could be >> used by a SACM assessor to assess the security posture of an initial >> configuration of an SNMPv3 deployment. >> >> As another example, the NSA provides guidelines about how to configure >> routers for various security functionality. >> >> See http://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf >> >> >> >> - >> >> Section 2.2.3: >> >> -Does SACM standardize the protocols to detect "end points" attachment >> >> to the network? >> >> I expect that SACM needs to be able to support multiple protocols for >> this purpose. >> >> Network Management Systems often use multiple technologies to =E2=80=9Ca= uto >> discover=E2=80=9D a network, such as ping, trace route, SNMP, etc., and = they use >> the information gathered to heuristically discover additional endpoints, >> iteratively. >> >> SACM might use such mechanisms directly, but also might =E2=80=9Cimport= =E2=80=9D the >> network topology from an NMS that already does auto discovery. >> >> >> >> Thank you very much, >> >> Linda Dunbar >> >> *Huawei USA IP Lab* >> >> *5340 Legacy Drive,* >> >> *Plano, TX 75024* >> >> *Tel: +1 469-277 - 5840* >> >> *Fax: +1 469 -277 - 5900* >> >> David Harrington >> >> ietfdbh@comcast.net >> >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >> > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --=20 Best regards, Kathleen --089e0160a476db47c404fe668193 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SACM doesn't preclude the use of existing interfaces t= o access endpoint information, just to make sure that point is clear. =C2= =A0The issued a wide call for proposals and are open to submissions to meet= their use cases, etc.




On Thu, Jul 17, 2014 at 11:54 AM, Gunnar Engelbach <Gunnar.Engelbach@threatguard.com> wrote:

Linda,

Let me restate what David has said in a different way and see if that is of= any help.

SACM is about standards for automating the security assessments of endpoint= s. =C2=A0That starts with an expression of security policies in a form that= a machine can apply, but also needs to include the abilities to determine = applicability of each policy to an endpoint (and find all policies that app= ly to an endpoint), to generate a list of endpoints, and to request/receive= data items for each endpoint necessary to complete analysis of the policy(= ies).

This working group is still in the process of defining requirements for all= of this let alone determining what form any of these will take, but it loo= ks like this will result in discrete components that can be used for other = purposes.

That could mean, for example, taking advantage of a SACM-compliant system t= o collect specific data times from certain classes of endpoints for your ow= n analysis, or it could mean creating automated policies that use SACM to p= roduce a set of results and then doing further analysis or aggregation on t= hat result set.


Given that any endpoint may or may not be owned by the interested party, as= recognized in your proposal, there would be a spectrum along which securit= y posture could be determined:

1) Direct query of endpoint attributes
2) Indirect query of endpoint attributes (SACM collection)*
3) Request for validation at the SACM policy level
4) Stating desired policy and validation via behavioral analysis
5) Stating desired policy with no external validation
6) Service Level Agreement contract
7) None.

The lower the number the more reliable (and current) the results, but a 3rd= party is certainly not going to make #1 available. =C2=A0However, given th= e direction SACM is going, I would think that #2 and #3 are very possible.<= br>

Incidentally, this exact problem is something NIST started bringing under t= he SCAP umbrella about five years ago, so it's a happy confluence to se= e you bringing this up with SACM.


--gun



* A SACM query should be as reliable as a direct query, but a mechanism for= guaranteeing this has not yet been worked out.



On 7/16/2014 6:42 PM, Linda Dunbar wrote:
David,

Reading through your explanation make me feel SACM is more like what
NETCONF wants to do, except SACM is the reverse direction, isn=E2=80=99t it= ?

NETCONF: Controller (or NMS) =C3=A0device;

SACM: devices =C3=A0Controller (or NMS)


More questions/comments are inserted below:

*From:*David Harrington [mailto:ietfdbh@comcast.net]



-How is =E2=80=9CEndpoint target=E2=80=9D related to =E2=80=9Cendpoint=E2= =80=9D? Can you give some

concrete examples?

endpoints exist in a network.

A SACM assessment process might only be interested in a subset of the
available endpoints.

The members of that subset would be endpoint =E2=80=9Ctargets=E2=80=9D.

For example, an assessment might, as part of an overall assessment
process, focus on assessing the current configuration of Huawei routers
in a heterogeneous network, based on administratively-defined rules
about how a Huawei router should be configured.

Each of the selected Huawei routers in that subset would then be an
"endpoint target" for that assessment.

[Linda] Does it mean SACM is like NETCONF, except the information is
from Devices to Controller (or NMS)?

Are you asking for concrete example so you understand the document
better, or are you asking us to add some concrete examples to the document?=

(If you didn=E2=80=99t understand this from the current text, then some con= crete
examples in the document would seem a good idea=E2=80=A6.)

[Linda] absolutely some examples will help a lot. Use cases are supposed to be examples, examples of =E2=80=9Cend points=E2=80=9D, examples of actua= l =E2=80=9Cdata=E2=80=9D to
be collected, examples of =E2=80=9Cdata-definitions=E2=80=9D used in the dr= aft, etc.



-

Section 2.1.1:

-Are there any examples for the =E2=80=9CData Definition=E2=80=9D described= in this

section? or data model?

We have the non-unique problem that, because SACM is such a broad topic, this WG draws people from multiple SDOs and multiple vendors with
products in the =E2=80=9CSACM space=E2=80=9D.

We have avoided mentioning specific standards as examples because we
feared a rush of =E2=80=9Cwhat about <my favorite protocol>?=E2=80=9D= requests.

Do you feel that the text is too hard to understand without examples?

[Linda] I thought that IETF doesn=E2=80=99t do too broad problems WG. Are t= here
examples of =E2=80=9CData Definitions=E2=80=9D in mind?



-I can=E2=80=99t figure out what =E2=80=9Cdata=E2=80=9D is SACM targeted fo= r.


Because we are currently working at such an abstract level, discussing
use cases and architectures, SACM scope includes many different
potential flows.

In many cases, the =E2=80=9Cdata=E2=80=9D depends on the flow involved.

For example, a collector application might collect current values from a managed switch using SNMP and MIB data models, and from a managed router using Netconf and YANG data models.

The collector might convert that data into database-specific format for
storage and fast retrieval; It might organize the data into its own
internal information models, organized to support its approach to
security assessment.

When an assessment application asks the database for some data, it might request a specific (database-record-defined) information model=E2=80=99s wo= rth
of data, or a mixed-model set of data, using an SQL request

The assessment application might generate data into a report containing
the results of the assessment, possibly in, let=E2=80=99s say, Excel format= or
in a text message to an operator.

[Linda] Does SACM target to have one proxy data models for =E2=80=9CNETCONF= ,
SNMP, SQL, =E2=80=A6=E2=80=9D?

Because SACM scope (security assessment) is very broad, it is hard to
nail down what the data is in any particular flow, without excluding
some data that somebody wants included (and is a legitimate type of data for SACM purposes).

That=E2=80=99s why we=E2=80=99re starting with a use cases document - to he= lp identify
the types of data that might be needed to address certain types of
assessment.

[Linda] Then the Use Case document should have concrete examples.

You=E2=80=99re not alone. We have had lots of concern about the nebulous-ne= ss of
the =E2=80=9Cdata=E2=80=9D that SACM targets.

We have been working to better differentiate the various flows of data
(data=3Dcorporate guidelines versus collected values of operational state,<= br> for example).



-

Section 2.2.1:

-Can you give some examples of =E2=80=9Cspecialized endpoint devices=E2=80= =9D referred

in the first sentence of the section?

It can be any device that provides a specialized function, such as a
router, a switch, a firewall device, etc.

[Linda] Is SACM trying to get one model for =E2=80=9Crouter/switch/firewall= =E2=80=9D?
How is it different from SNMP?



-The first paragraph talked about manufacture publishing guidelines on

how to configure their devices. Is the objective of SACM for standardize those guidelines?

No. I think these guidelines might be thought of as release notes.

But part of the goal would be to encourage expressing the guidelines in
a machine-friendly format to promote automation, and possibly to
encourage vendors to use industry standard data formats.

But even if the vendor doesn=E2=80=99t provide the information in a standar= dized
format, such as a MIB module, they might explain how to use proprietary
interfaces (such as a CLI) to set and retrieve the current values.

Part of the guideline would be the vendor=E2=80=99s recommendation for valu= es to
use for the specific model of product, to achieve a specific
security-related configuration.

As an example, a vendor that supports SNMPv3 in their product might
specify how to configure the View-based Access Control Model tables
(SNMP-VIEW-BASED-ACM-MIB from RFC3415).

Appendix A of RFC 3415 contains an example guidelines, that could be
used by a SACM assessor to assess the security posture of an initial
configuration of an SNMPv3 deployment.

As another example, the NSA provides guidelines about how to configure
routers for various security functionality.

See http://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf<= br>


-

Section 2.2.3:

-Does SACM standardize the protocols to detect "end points" attac= hment

to the network?

I expect that SACM needs to be able to support multiple protocols for
this purpose.

Network Management Systems often use multiple technologies to =E2=80=9Cauto=
discover=E2=80=9D a network, such as ping, trace route, SNMP, etc., and the= y use
the information gathered to heuristically discover additional endpoints, iteratively.

SACM might use such mechanisms directly, but also might =E2=80=9Cimport=E2= =80=9D the
network topology from an NMS that already does auto discovery.



Thank you very much,

Linda Dunbar

*Huawei USA IP Lab*

*5340 Legacy Drive,*

*Plano, TX 75024*

*Tel: +1 469-277 - 5840*

*Fax: +1 469 -277 - 5900*

David Harrington

ietfdbh@comcast.ne= t <mailto:i= etfdbh@comcast.net>




_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm



--
=

Best regards,
Kathleen
--089e0160a476db47c404fe668193-- From nobody Thu Jul 17 10:18:23 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1483A1A0067 for ; Thu, 17 Jul 2014 10:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 fBGo9EdkM7qJ for ; Thu, 17 Jul 2014 10:17:39 -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 A3C251A000B for ; Thu, 17 Jul 2014 10:17:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKE78467; Thu, 17 Jul 2014 17:17:35 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Jul 2014 18:17:35 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Thu, 17 Jul 2014 10:17:24 -0700 From: Linda Dunbar To: Gunnar Engelbach , David Harrington Thread-Topic: [sacm] Questions to draft-ietf-sacm-use-cases-07 Thread-Index: Ac+gQyaskQTQ8FgYSw6H93oMds68FwA/mQWAAACntdAAM32mgAAL6JBQ Date: Thu, 17 Jul 2014 17:17:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9ED81@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> <53C7F1CF.4070408@ThreatGuard.com> In-Reply-To: <53C7F1CF.4070408@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.170] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/32Mws8ukviWXgmHpojlg3DBx--k Cc: "sacm@ietf.org" , David Waltermire Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 17:17:41 -0000 Gunnar,=20 Thank you very much for the further explanation.=20 David's reply indicates that the "end point" can be "routers, switches, or = other devices". Is it true? Your reply indicates that SACM is about the "Security Assessment of end poi= nt". Does it mean that SACM is about defining the security related metrics = for "routers, switches or other devices"?=20 Linda=20 -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Thursday, July 17, 2014 10:55 AM To: Linda Dunbar; David Harrington Cc: sacm@ietf.org; David Waltermire Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 Linda, Let me restate what David has said in a different way and see if that is of= any help. SACM is about standards for automating the security assessments of endpoint= s. That starts with an expression of security policies in a form that a ma= chine can apply, but also needs to include the abilities to determine appli= cability of each policy to an endpoint (and find all policies that apply to= an endpoint), to generate a list of endpoints, and to request/receive data= items for each endpoint necessary to complete analysis of the policy(ies). This working group is still in the process of defining requirements for all= of this let alone determining what form any of these will take, but it loo= ks like this will result in discrete components that can be used for other = purposes. That could mean, for example, taking advantage of a SACM-compliant system t= o collect specific data times from certain classes of endpoints for your ow= n analysis, or it could mean creating automated policies that use SACM to p= roduce a set of results and then doing further analysis or aggregation on t= hat result set. Given that any endpoint may or may not be owned by the interested party, as= recognized in your proposal, there would be a spectrum along which securit= y posture could be determined: 1) Direct query of endpoint attributes 2) Indirect query of endpoint attributes (SACM collection)* 3) Request for validation at the SACM policy level 4) Stating desired policy and validation via behavioral analysis 5) Stating desired policy with no external validation 6) Service Level Agreement contract 7) None. The lower the number the more reliable (and current) the results, but a 3rd= party is certainly not going to make #1 available. However, given the dir= ection SACM is going, I would think that #2 and #3 are very possible. Incidentally, this exact problem is something NIST started bringing under t= he SCAP umbrella about five years ago, so it's a happy confluence to see yo= u bringing this up with SACM. --gun * A SACM query should be as reliable as a direct query, but a mechanism for= guaranteeing this has not yet been worked out. On 7/16/2014 6:42 PM, Linda Dunbar wrote: > David, > > Reading through your explanation make me feel SACM is more like what > NETCONF wants to do, except SACM is the reverse direction, isn't it? > > NETCONF: Controller (or NMS) =E0device; > > SACM: devices =E0Controller (or NMS) > > More questions/comments are inserted below: > > *From:*David Harrington [mailto:ietfdbh@comcast.net] > > > > -How is "Endpoint target" related to "endpoint"? Can you give some > concrete examples? > > endpoints exist in a network. > > A SACM assessment process might only be interested in a subset of the > available endpoints. > > The members of that subset would be endpoint "targets". > > For example, an assessment might, as part of an overall assessment > process, focus on assessing the current configuration of Huawei routers > in a heterogeneous network, based on administratively-defined rules > about how a Huawei router should be configured. > > Each of the selected Huawei routers in that subset would then be an > "endpoint target" for that assessment. > > [Linda] Does it mean SACM is like NETCONF, except the information is > from Devices to Controller (or NMS)? > > Are you asking for concrete example so you understand the document > better, or are you asking us to add some concrete examples to the documen= t? > > (If you didn't understand this from the current text, then some concrete > examples in the document would seem a good idea..) > > [Linda] absolutely some examples will help a lot. Use cases are supposed > to be examples, examples of "end points", examples of actual "data" to > be collected, examples of "data-definitions" used in the draft, etc. > > > > - > > Section 2.1.1: > > -Are there any examples for the "Data Definition" described in this > section? or data model? > > We have the non-unique problem that, because SACM is such a broad topic, > this WG draws people from multiple SDOs and multiple vendors with > products in the "SACM space". > > We have avoided mentioning specific standards as examples because we > feared a rush of "what about ?" requests. > > Do you feel that the text is too hard to understand without examples? > > [Linda] I thought that IETF doesn't do too broad problems WG. Are there > examples of "Data Definitions" in mind? > > > > -I can't figure out what "data" is SACM targeted for. > > Because we are currently working at such an abstract level, discussing > use cases and architectures, SACM scope includes many different > potential flows. > > In many cases, the "data" depends on the flow involved. > > For example, a collector application might collect current values from a > managed switch using SNMP and MIB data models, and from a managed router > using Netconf and YANG data models. > > The collector might convert that data into database-specific format for > storage and fast retrieval; It might organize the data into its own > internal information models, organized to support its approach to > security assessment. > > When an assessment application asks the database for some data, it might > request a specific (database-record-defined) information model's worth > of data, or a mixed-model set of data, using an SQL request > > The assessment application might generate data into a report containing > the results of the assessment, possibly in, let's say, Excel format or > in a text message to an operator. > > [Linda] Does SACM target to have one proxy data models for "NETCONF, > SNMP, SQL, ."? > > Because SACM scope (security assessment) is very broad, it is hard to > nail down what the data is in any particular flow, without excluding > some data that somebody wants included (and is a legitimate type of data > for SACM purposes). > > That's why we're starting with a use cases document - to help identify > the types of data that might be needed to address certain types of > assessment. > > [Linda] Then the Use Case document should have concrete examples. > > You're not alone. We have had lots of concern about the nebulous-ness of > the "data" that SACM targets. > > We have been working to better differentiate the various flows of data > (data=3Dcorporate guidelines versus collected values of operational state= , > for example). > > > > - > > Section 2.2.1: > > -Can you give some examples of "specialized endpoint devices" referred > in the first sentence of the section? > > It can be any device that provides a specialized function, such as a > router, a switch, a firewall device, etc. > > [Linda] Is SACM trying to get one model for "router/switch/firewall"? > How is it different from SNMP? > > > > -The first paragraph talked about manufacture publishing guidelines on > how to configure their devices. Is the objective of SACM for standardize > those guidelines? > > No. I think these guidelines might be thought of as release notes. > > But part of the goal would be to encourage expressing the guidelines in > a machine-friendly format to promote automation, and possibly to > encourage vendors to use industry standard data formats. > > But even if the vendor doesn't provide the information in a standardized > format, such as a MIB module, they might explain how to use proprietary > interfaces (such as a CLI) to set and retrieve the current values. > > Part of the guideline would be the vendor's recommendation for values to > use for the specific model of product, to achieve a specific > security-related configuration. > > As an example, a vendor that supports SNMPv3 in their product might > specify how to configure the View-based Access Control Model tables > (SNMP-VIEW-BASED-ACM-MIB from RFC3415). > > Appendix A of RFC 3415 contains an example guidelines, that could be > used by a SACM assessor to assess the security posture of an initial > configuration of an SNMPv3 deployment. > > As another example, the NSA provides guidelines about how to configure > routers for various security functionality. > > See http://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf > > > > - > > Section 2.2.3: > > -Does SACM standardize the protocols to detect "end points" attachment > to the network? > > I expect that SACM needs to be able to support multiple protocols for > this purpose. > > Network Management Systems often use multiple technologies to "auto > discover" a network, such as ping, trace route, SNMP, etc., and they use > the information gathered to heuristically discover additional endpoints, > iteratively. > > SACM might use such mechanisms directly, but also might "import" the > network topology from an NMS that already does auto discovery. > > > > Thank you very much, > > Linda Dunbar > > *Huawei USA IP Lab* > > *5340 Legacy Drive,* > > *Plano, TX 75024* > > *Tel: +1 469-277 - 5840* > > *Fax: +1 469 -277 - 5900* > > David Harrington > > ietfdbh@comcast.net > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From nobody Thu Jul 17 11:02:54 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806511A0043 for ; Thu, 17 Jul 2014 11:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-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 z1UjhXJ6vPC6 for ; Thu, 17 Jul 2014 11:01:53 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1C61A0028 for ; Thu, 17 Jul 2014 11:01:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=caCnvNBRE4xcHuigXyk47dC/YTZyZIQYyx/1XTVumriQA75ll57QD0/W1QBhFwfMZ3UXcLTW+i3sL1LZEO5EUqIm72+rov6EMeCwqBOtLlLzXDJaDlB9oYZO894fI3RN; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 2620 invoked from network); 17 Jul 2014 11:14:57 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by server.threatguard.com with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 17 Jul 2014 11:14:56 -0700 Message-ID: <53C80F92.4020205@ThreatGuard.com> Date: Thu, 17 Jul 2014 14:01:54 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Dunbar , David Harrington References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> <53C7F1CF.4070408@ThreatGuard.com> <4A95BA014132FF49AE685FAB4B9F17F645D9ED81@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9ED81@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/ynBYUVVL3XbCdAzIxnmHsR_b-sM Cc: "sacm@ietf.org" , David Waltermire Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:01:56 -0000 On 7/17/2014 1:17 PM, Linda Dunbar wrote: > Gunnar, > > Thank you very much for the further explanation. > > David's reply indicates that the "end point" can be "routers, switches, or other devices". Is it true? Certainly, and other things as well, such as a clustered database or and installed piece of software. It's really any discrete item about which a policy can be expressed and the necessary data items collected. > > Your reply indicates that SACM is about the "Security Assessment of end point". Does it mean that SACM is about defining the security related metrics for "routers, switches or other devices"? Not really the metrics, but about how those metrics can be expressed in a way where the determination of policy compliance can be automated. For example, the DISA STIGs (Security Technical Information Guides) are documents that define a set of configuration items for a number of platforms that must be set at certain values in order to be compliant with DoD's security policies. These have traditionally been expressed as prose documents where each piece of ADPE must be manually verified before the equipment is allowed to connect to the network. So, for example, a Solaris 10 SPARC system used in a environment that requires adherence to a policy of Mission Critical Classified. SACM would be interested in how to encode that policy in a manner where assessment can be automated, but the actual metrics codified in that document would be defined by DISA. Similarly to ensure compliance with health care regulations (HIPAA), financial regulations (Sorbanes-Oxley), NATO, Automotive Network Exchange, etc. Anything where the policy can be expressed in the SACM format. SACM will also be defining the mechanism to query for and retrieve data items about endpoint(s), so evaluation of a policy is not the only entry point into a SACM system. --gun > > Linda > > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach > Sent: Thursday, July 17, 2014 10:55 AM > To: Linda Dunbar; David Harrington > Cc: sacm@ietf.org; David Waltermire > Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 > > > Linda, > > Let me restate what David has said in a different way and see if that is of any help. > > SACM is about standards for automating the security assessments of endpoints. That starts with an expression of security policies in a form that a machine can apply, but also needs to include the abilities to determine applicability of each policy to an endpoint (and find all policies that apply to an endpoint), to generate a list of endpoints, and to request/receive data items for each endpoint necessary to complete analysis of the policy(ies). > > This working group is still in the process of defining requirements for all of this let alone determining what form any of these will take, but it looks like this will result in discrete components that can be used for other purposes. > > That could mean, for example, taking advantage of a SACM-compliant system to collect specific data times from certain classes of endpoints for your own analysis, or it could mean creating automated policies that use SACM to produce a set of results and then doing further analysis or aggregation on that result set. > > > Given that any endpoint may or may not be owned by the interested party, as recognized in your proposal, there would be a spectrum along which security posture could be determined: > > 1) Direct query of endpoint attributes > 2) Indirect query of endpoint attributes (SACM collection)* > 3) Request for validation at the SACM policy level > 4) Stating desired policy and validation via behavioral analysis > 5) Stating desired policy with no external validation > 6) Service Level Agreement contract > 7) None. > > The lower the number the more reliable (and current) the results, but a 3rd party is certainly not going to make #1 available. However, given the direction SACM is going, I would think that #2 and #3 are very possible. > > > Incidentally, this exact problem is something NIST started bringing under the SCAP umbrella about five years ago, so it's a happy confluence to see you bringing this up with SACM. > > > --gun > > > > * A SACM query should be as reliable as a direct query, but a mechanism for guaranteeing this has not yet been worked out. > > > On 7/16/2014 6:42 PM, Linda Dunbar wrote: >> David, >> >> Reading through your explanation make me feel SACM is more like what >> NETCONF wants to do, except SACM is the reverse direction, isn't it? >> >> NETCONF: Controller (or NMS) àdevice; >> >> SACM: devices àController (or NMS) >> >> More questions/comments are inserted below: >> >> *From:*David Harrington [mailto:ietfdbh@comcast.net] >> >> >> >> -How is "Endpoint target" related to "endpoint"? Can you give some >> concrete examples? >> >> endpoints exist in a network. >> >> A SACM assessment process might only be interested in a subset of the >> available endpoints. >> >> The members of that subset would be endpoint "targets". >> >> For example, an assessment might, as part of an overall assessment >> process, focus on assessing the current configuration of Huawei routers >> in a heterogeneous network, based on administratively-defined rules >> about how a Huawei router should be configured. >> >> Each of the selected Huawei routers in that subset would then be an >> "endpoint target" for that assessment. >> >> [Linda] Does it mean SACM is like NETCONF, except the information is >> from Devices to Controller (or NMS)? >> >> Are you asking for concrete example so you understand the document >> better, or are you asking us to add some concrete examples to the document? >> >> (If you didn't understand this from the current text, then some concrete >> examples in the document would seem a good idea..) >> >> [Linda] absolutely some examples will help a lot. Use cases are supposed >> to be examples, examples of "end points", examples of actual "data" to >> be collected, examples of "data-definitions" used in the draft, etc. >> >> >> >> - >> >> Section 2.1.1: >> >> -Are there any examples for the "Data Definition" described in this >> section? or data model? >> >> We have the non-unique problem that, because SACM is such a broad topic, >> this WG draws people from multiple SDOs and multiple vendors with >> products in the "SACM space". >> >> We have avoided mentioning specific standards as examples because we >> feared a rush of "what about ?" requests. >> >> Do you feel that the text is too hard to understand without examples? >> >> [Linda] I thought that IETF doesn't do too broad problems WG. Are there >> examples of "Data Definitions" in mind? >> >> >> >> -I can't figure out what "data" is SACM targeted for. >> >> Because we are currently working at such an abstract level, discussing >> use cases and architectures, SACM scope includes many different >> potential flows. >> >> In many cases, the "data" depends on the flow involved. >> >> For example, a collector application might collect current values from a >> managed switch using SNMP and MIB data models, and from a managed router >> using Netconf and YANG data models. >> >> The collector might convert that data into database-specific format for >> storage and fast retrieval; It might organize the data into its own >> internal information models, organized to support its approach to >> security assessment. >> >> When an assessment application asks the database for some data, it might >> request a specific (database-record-defined) information model's worth >> of data, or a mixed-model set of data, using an SQL request >> >> The assessment application might generate data into a report containing >> the results of the assessment, possibly in, let's say, Excel format or >> in a text message to an operator. >> >> [Linda] Does SACM target to have one proxy data models for "NETCONF, >> SNMP, SQL, ."? >> >> Because SACM scope (security assessment) is very broad, it is hard to >> nail down what the data is in any particular flow, without excluding >> some data that somebody wants included (and is a legitimate type of data >> for SACM purposes). >> >> That's why we're starting with a use cases document - to help identify >> the types of data that might be needed to address certain types of >> assessment. >> >> [Linda] Then the Use Case document should have concrete examples. >> >> You're not alone. We have had lots of concern about the nebulous-ness of >> the "data" that SACM targets. >> >> We have been working to better differentiate the various flows of data >> (data=corporate guidelines versus collected values of operational state, >> for example). >> >> >> >> - >> >> Section 2.2.1: >> >> -Can you give some examples of "specialized endpoint devices" referred >> in the first sentence of the section? >> >> It can be any device that provides a specialized function, such as a >> router, a switch, a firewall device, etc. >> >> [Linda] Is SACM trying to get one model for "router/switch/firewall"? >> How is it different from SNMP? >> >> >> >> -The first paragraph talked about manufacture publishing guidelines on >> how to configure their devices. Is the objective of SACM for standardize >> those guidelines? >> >> No. I think these guidelines might be thought of as release notes. >> >> But part of the goal would be to encourage expressing the guidelines in >> a machine-friendly format to promote automation, and possibly to >> encourage vendors to use industry standard data formats. >> >> But even if the vendor doesn't provide the information in a standardized >> format, such as a MIB module, they might explain how to use proprietary >> interfaces (such as a CLI) to set and retrieve the current values. >> >> Part of the guideline would be the vendor's recommendation for values to >> use for the specific model of product, to achieve a specific >> security-related configuration. >> >> As an example, a vendor that supports SNMPv3 in their product might >> specify how to configure the View-based Access Control Model tables >> (SNMP-VIEW-BASED-ACM-MIB from RFC3415). >> >> Appendix A of RFC 3415 contains an example guidelines, that could be >> used by a SACM assessor to assess the security posture of an initial >> configuration of an SNMPv3 deployment. >> >> As another example, the NSA provides guidelines about how to configure >> routers for various security functionality. >> >> See http://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf >> >> >> >> - >> >> Section 2.2.3: >> >> -Does SACM standardize the protocols to detect "end points" attachment >> to the network? >> >> I expect that SACM needs to be able to support multiple protocols for >> this purpose. >> >> Network Management Systems often use multiple technologies to "auto >> discover" a network, such as ping, trace route, SNMP, etc., and they use >> the information gathered to heuristically discover additional endpoints, >> iteratively. >> >> SACM might use such mechanisms directly, but also might "import" the >> network topology from an NMS that already does auto discovery. >> >> >> >> Thank you very much, >> >> Linda Dunbar >> >> *Huawei USA IP Lab* >> >> *5340 Legacy Drive,* >> >> *Plano, TX 75024* >> >> *Tel: +1 469-277 - 5840* >> >> *Fax: +1 469 -277 - 5900* >> >> David Harrington >> >> ietfdbh@comcast.net >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From nobody Thu Jul 17 11:14:24 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979251A0043 for ; Thu, 17 Jul 2014 11:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-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 OhPZATW1oDDE for ; Thu, 17 Jul 2014 11:12:48 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFB21A0028 for ; Thu, 17 Jul 2014 11:12:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=oRyvpQJMnbdGBpd7rSOS7SBegvwwMXwXg0hmiWTsHwmCMSrg4fEXd7JtK+vyY6wbvee97mKiLWWi4xOpfATCLvZDyr0oj0izvq7q2uZyaprnZYKprRKuYKgkwWPY+YCa; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 2902 invoked from network); 17 Jul 2014 11:25:55 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by server.threatguard.com with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 17 Jul 2014 11:25:54 -0700 Message-ID: <53C81224.5090709@ThreatGuard.com> Date: Thu, 17 Jul 2014 14:12:52 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> <53C7F1CF.4070408@ThreatGuard.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/iQGTh09FzwNgGt32kgOZFaPFa7E Cc: David Waltermire , David Harrington , "sacm@ietf.org" , Linda Dunbar Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:12:56 -0000 Thanks, yes, I did not mean that a SACM endpoint data collection query would be a replacement for any other method. To be compliant an endpoint would need to implement the SACM collection query mechanism, but could also make 0 to many other interfaces available. Endpoints that do not implement the SACM interface could still participate by means of a proxy. On 7/17/2014 12:55 PM, Kathleen Moriarty wrote: > SACM doesn't preclude the use of existing interfaces to access endpoint > information, just to make sure that point is clear. The issued a wide > call for proposals and are open to submissions to meet their use cases, etc. > > > > > On Thu, Jul 17, 2014 at 11:54 AM, Gunnar Engelbach > > wrote: > > > Linda, > > Let me restate what David has said in a different way and see if > that is of any help. > > SACM is about standards for automating the security assessments of > endpoints. That starts with an expression of security policies in a > form that a machine can apply, but also needs to include the > abilities to determine applicability of each policy to an endpoint > (and find all policies that apply to an endpoint), to generate a > list of endpoints, and to request/receive data items for each > endpoint necessary to complete analysis of the policy(ies). > > This working group is still in the process of defining requirements > for all of this let alone determining what form any of these will > take, but it looks like this will result in discrete components that > can be used for other purposes. > > That could mean, for example, taking advantage of a SACM-compliant > system to collect specific data times from certain classes of > endpoints for your own analysis, or it could mean creating automated > policies that use SACM to produce a set of results and then doing > further analysis or aggregation on that result set. > > > Given that any endpoint may or may not be owned by the interested > party, as recognized in your proposal, there would be a spectrum > along which security posture could be determined: > > 1) Direct query of endpoint attributes > 2) Indirect query of endpoint attributes (SACM collection)* > 3) Request for validation at the SACM policy level > 4) Stating desired policy and validation via behavioral analysis > 5) Stating desired policy with no external validation > 6) Service Level Agreement contract > 7) None. > > The lower the number the more reliable (and current) the results, > but a 3rd party is certainly not going to make #1 available. > However, given the direction SACM is going, I would think that #2 > and #3 are very possible. > > > Incidentally, this exact problem is something NIST started bringing > under the SCAP umbrella about five years ago, so it's a happy > confluence to see you bringing this up with SACM. > > > --gun > > > > * A SACM query should be as reliable as a direct query, but a > mechanism for guaranteeing this has not yet been worked out. > > > > On 7/16/2014 6:42 PM, Linda Dunbar wrote: > > David, > > Reading through your explanation make me feel SACM is more like what > NETCONF wants to do, except SACM is the reverse direction, isn’t it? > > NETCONF: Controller (or NMS) àdevice; > > SACM: devices àController (or NMS) > > > More questions/comments are inserted below: > > *From:*David Harrington [mailto:ietfdbh@comcast.net > ] > > > > -How is “Endpoint target†related to “endpointâ€? Can you give some > > concrete examples? > > endpoints exist in a network. > > A SACM assessment process might only be interested in a subset > of the > available endpoints. > > The members of that subset would be endpoint “targetsâ€. > > For example, an assessment might, as part of an overall assessment > process, focus on assessing the current configuration of Huawei > routers > in a heterogeneous network, based on administratively-defined rules > about how a Huawei router should be configured. > > Each of the selected Huawei routers in that subset would then be an > "endpoint target" for that assessment. > > [Linda] Does it mean SACM is like NETCONF, except the information is > from Devices to Controller (or NMS)? > > Are you asking for concrete example so you understand the document > better, or are you asking us to add some concrete examples to > the document? > > (If you didn’t understand this from the current text, then some > concrete > examples in the document would seem a good idea….) > > [Linda] absolutely some examples will help a lot. Use cases are > supposed > to be examples, examples of “end pointsâ€, examples of actual > “data†to > be collected, examples of “data-definitions†used in the draft, etc. > > > > - > > Section 2.1.1: > > -Are there any examples for the “Data Definition†described in this > > section? or data model? > > We have the non-unique problem that, because SACM is such a > broad topic, > this WG draws people from multiple SDOs and multiple vendors with > products in the “SACM spaceâ€. > > We have avoided mentioning specific standards as examples because we > feared a rush of “what about ?†requests. > > Do you feel that the text is too hard to understand without > examples? > > [Linda] I thought that IETF doesn’t do too broad problems WG. > Are there > examples of “Data Definitions†in mind? > > > > -I can’t figure out what “data†is SACM targeted for. > > > Because we are currently working at such an abstract level, > discussing > use cases and architectures, SACM scope includes many different > potential flows. > > In many cases, the “data†depends on the flow involved. > > For example, a collector application might collect current > values from a > managed switch using SNMP and MIB data models, and from a > managed router > using Netconf and YANG data models. > > The collector might convert that data into database-specific > format for > storage and fast retrieval; It might organize the data into its own > internal information models, organized to support its approach to > security assessment. > > When an assessment application asks the database for some data, > it might > request a specific (database-record-defined) information model’s > worth > of data, or a mixed-model set of data, using an SQL request > > The assessment application might generate data into a report > containing > the results of the assessment, possibly in, let’s say, Excel > format or > in a text message to an operator. > > [Linda] Does SACM target to have one proxy data models for “NETCONF, > SNMP, SQL, …â€? > > Because SACM scope (security assessment) is very broad, it is > hard to > nail down what the data is in any particular flow, without excluding > some data that somebody wants included (and is a legitimate type > of data > for SACM purposes). > > That’s why we’re starting with a use cases document - to help > identify > the types of data that might be needed to address certain types of > assessment. > > [Linda] Then the Use Case document should have concrete examples. > > You’re not alone. We have had lots of concern about the > nebulous-ness of > the “data†that SACM targets. > > We have been working to better differentiate the various flows > of data > (data=corporate guidelines versus collected values of > operational state, > for example). > > > > - > > Section 2.2.1: > > -Can you give some examples of “specialized endpoint devices†> referred > > in the first sentence of the section? > > It can be any device that provides a specialized function, such as a > router, a switch, a firewall device, etc. > > [Linda] Is SACM trying to get one model for > “router/switch/firewallâ€? > How is it different from SNMP? > > > > -The first paragraph talked about manufacture publishing > guidelines on > > how to configure their devices. Is the objective of SACM for > standardize > those guidelines? > > No. I think these guidelines might be thought of as release notes. > > But part of the goal would be to encourage expressing the > guidelines in > a machine-friendly format to promote automation, and possibly to > encourage vendors to use industry standard data formats. > > But even if the vendor doesn’t provide the information in a > standardized > format, such as a MIB module, they might explain how to use > proprietary > interfaces (such as a CLI) to set and retrieve the current values. > > Part of the guideline would be the vendor’s recommendation for > values to > use for the specific model of product, to achieve a specific > security-related configuration. > > As an example, a vendor that supports SNMPv3 in their product might > specify how to configure the View-based Access Control Model tables > (SNMP-VIEW-BASED-ACM-MIB from RFC3415). > > Appendix A of RFC 3415 contains an example guidelines, that could be > used by a SACM assessor to assess the security posture of an initial > configuration of an SNMPv3 deployment. > > As another example, the NSA provides guidelines about how to > configure > routers for various security functionality. > > See http://www.nsa.gov/ia/_files/__routers/c4-040r-02.pdf > > > > > - > > Section 2.2.3: > > -Does SACM standardize the protocols to detect "end points" > attachment > > to the network? > > I expect that SACM needs to be able to support multiple > protocols for > this purpose. > > Network Management Systems often use multiple technologies to “auto > discover†a network, such as ping, trace route, SNMP, etc., and > they use > the information gathered to heuristically discover additional > endpoints, > iteratively. > > SACM might use such mechanisms directly, but also might “import†the > network topology from an NMS that already does auto discovery. > > > > Thank you very much, > > Linda Dunbar > > *Huawei USA IP Lab* > > *5340 Legacy Drive,* > > *Plano, TX 75024* > > *Tel: +1 469-277 - 5840 * > > *Fax: +1 469 -277 - 5900 * > > David Harrington > > ietfdbh@comcast.net > > > > > > > _________________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/__listinfo/sacm > > > > _________________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/__listinfo/sacm > > > > > > -- > > Best regards, > Kathleen From nobody Thu Jul 17 14:11:30 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8D1A0064 for ; Thu, 17 Jul 2014 14:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 MP6CX9U1Obfb for ; Thu, 17 Jul 2014 14:11:19 -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 723841B27EE for ; Thu, 17 Jul 2014 14:11:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKE89383; Thu, 17 Jul 2014 21:11:16 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Jul 2014 22:11:15 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Thu, 17 Jul 2014 14:11:10 -0700 From: Linda Dunbar To: Gunnar Engelbach , David Harrington Thread-Topic: [sacm] Questions to draft-ietf-sacm-use-cases-07 Thread-Index: Ac+gQyaskQTQ8FgYSw6H93oMds68FwA/mQWAAACntdAAM32mgAAL6JBQ///ENgCAAET14A== Date: Thu, 17 Jul 2014 21:11:10 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9F08E@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> <53C7F1CF.4070408@ThreatGuard.com> <4A95BA014132FF49AE685FAB4B9F17F645D9ED81@dfweml701-chm.china.huawei.com> <53C80F92.4020205@ThreatGuard.com> In-Reply-To: <53C80F92.4020205@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.170] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D9F08Edfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/nymQSZ1V6DyR3tTiCydf9XnsW5M Cc: "sacm@ietf.org" , David Waltermire Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 21:11:28 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9F08Edfweml701chmchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gunnar, What you provided is very helpful. A few more questions: -----Original Message----- From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] Not really the metrics, but about how those metrics can be expressed in a w= ay where the determination of policy compliance can be automated. For example, the DISA STIGs (Security Technical Information Guides) are doc= uments that define a set of configuration items for a number of platforms t= hat must be set at certain values in order to be compliant with DoD's secur= ity policies. [Linda] Can you give some examples of the "platforms" that you are talking = about? What does it mean by saying "configuration items to be set at certai= n values"? Does it mean that "secure login password" has to be X number of characters? These have traditionally been expressed as prose documents where each piece= of ADPE must be manually verified before the equipment is allowed to conne= ct to the network. So, for example, a Solaris 10 SPARC system used in a environment that requi= res adherence to a policy of Mission Critical Classified. [Linda] any examples of the "policies" for Mission Critical Classified? SACM would be interested in how to encode that policy in a manner where ass= essment can be automated, but the actual metrics codified in that document = would be defined by DISA. [Linda] Do you have some examples of the "policies" that are to be encoded = to enable the automation? Similarly to ensure compliance with health care regulations (HIPAA), financ= ial regulations (Sorbanes-Oxley), NATO, Automotive Network Exchange, etc. = Anything where the policy can be expressed in the SACM format. [Linda] Any examples of those "policies" used for HIPAA, financial regulati= ons? SACM will also be defining the mechanism to query for and retrieve data ite= ms about endpoint(s), [Linda] If the end point is a router, what kind of "data items about endpoi= nts (i.e. router)" are to be queried? Is it FIB/RIB? Or configuration of in= terfaces? so evaluation of a policy is not the only entry point into a SACM system. --gun > > Linda > > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > Engelbach > Sent: Thursday, July 17, 2014 10:55 AM > To: Linda Dunbar; David Harrington > Cc: sacm@ietf.org; David Waltermire > Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 > > > Linda, > > Let me restate what David has said in a different way and see if that is = of any help. > > SACM is about standards for automating the security assessments of endpoi= nts. That starts with an expression of security policies in a form that a = machine can apply, but also needs to include the abilities to determine app= licability of each policy to an endpoint (and find all policies that apply = to an endpoint), to generate a list of endpoints, and to request/receive da= ta items for each endpoint necessary to complete analysis of the policy(ies= ). > > This working group is still in the process of defining requirements for a= ll of this let alone determining what form any of these will take, but it l= ooks like this will result in discrete components that can be used for othe= r purposes. > > That could mean, for example, taking advantage of a SACM-compliant system= to collect specific data times from certain classes of endpoints for your = own analysis, or it could mean creating automated policies that use SACM to= produce a set of results and then doing further analysis or aggregation on= that result set. > > > Given that any endpoint may or may not be owned by the interested party, = as recognized in your proposal, there would be a spectrum along which secur= ity posture could be determined: > > 1) Direct query of endpoint attributes > 2) Indirect query of endpoint attributes (SACM collection)* > 3) Request for validation at the SACM policy level > 4) Stating desired policy and validation via behavioral analysis > 5) Stating desired policy with no external validation > 6) Service Level Agreement contract > 7) None. > > The lower the number the more reliable (and current) the results, but a 3= rd party is certainly not going to make #1 available. However, given the d= irection SACM is going, I would think that #2 and #3 are very possible. > > > Incidentally, this exact problem is something NIST started bringing under= the SCAP umbrella about five years ago, so it's a happy confluence to see = you bringing this up with SACM. > > > --gun > > > > * A SACM query should be as reliable as a direct query, but a mechanism f= or guaranteeing this has not yet been worked out. > > > On 7/16/2014 6:42 PM, Linda Dunbar wrote: >> David, >> >> Reading through your explanation make me feel SACM is more like what >> NETCONF wants to do, except SACM is the reverse direction, isn't it? >> >> NETCONF: Controller (or NMS) =E0device; >> >> SACM: devices =E0Controller (or NMS) >> >> More questions/comments are inserted below: >> >> *From:*David Harrington [mailto:ietfdbh@comcast.net] >> >> >> >> -How is "Endpoint target" related to "endpoint"? Can you give some >> concrete examples? >> >> endpoints exist in a network. >> >> A SACM assessment process might only be interested in a subset of the >> available endpoints. >> >> The members of that subset would be endpoint "targets". >> >> For example, an assessment might, as part of an overall assessment >> process, focus on assessing the current configuration of Huawei >> routers in a heterogeneous network, based on administratively-defined >> rules about how a Huawei router should be configured. >> >> Each of the selected Huawei routers in that subset would then be an >> "endpoint target" for that assessment. >> >> [Linda] Does it mean SACM is like NETCONF, except the information is >> from Devices to Controller (or NMS)? >> >> Are you asking for concrete example so you understand the document >> better, or are you asking us to add some concrete examples to the docume= nt? >> >> (If you didn't understand this from the current text, then some >> concrete examples in the document would seem a good idea..) >> >> [Linda] absolutely some examples will help a lot. Use cases are >> supposed to be examples, examples of "end points", examples of actual >> "data" to be collected, examples of "data-definitions" used in the draft= , etc. >> >> >> >> - >> >> Section 2.1.1: >> >> -Are there any examples for the "Data Definition" described in this >> section? or data model? >> >> We have the non-unique problem that, because SACM is such a broad >> topic, this WG draws people from multiple SDOs and multiple vendors >> with products in the "SACM space". >> >> We have avoided mentioning specific standards as examples because we >> feared a rush of "what about ?" requests. >> >> Do you feel that the text is too hard to understand without examples? >> >> [Linda] I thought that IETF doesn't do too broad problems WG. Are >> there examples of "Data Definitions" in mind? >> >> >> >> -I can't figure out what "data" is SACM targeted for. >> >> Because we are currently working at such an abstract level, >> discussing use cases and architectures, SACM scope includes many >> different potential flows. >> >> In many cases, the "data" depends on the flow involved. >> >> For example, a collector application might collect current values >> from a managed switch using SNMP and MIB data models, and from a >> managed router using Netconf and YANG data models. >> >> The collector might convert that data into database-specific format >> for storage and fast retrieval; It might organize the data into its >> own internal information models, organized to support its approach to >> security assessment. >> >> When an assessment application asks the database for some data, it >> might request a specific (database-record-defined) information >> model's worth of data, or a mixed-model set of data, using an SQL >> request >> >> The assessment application might generate data into a report >> containing the results of the assessment, possibly in, let's say, >> Excel format or in a text message to an operator. >> >> [Linda] Does SACM target to have one proxy data models for "NETCONF, >> SNMP, SQL, ."? >> >> Because SACM scope (security assessment) is very broad, it is hard to >> nail down what the data is in any particular flow, without excluding >> some data that somebody wants included (and is a legitimate type of >> data for SACM purposes). >> >> That's why we're starting with a use cases document - to help >> identify the types of data that might be needed to address certain >> types of assessment. >> >> [Linda] Then the Use Case document should have concrete examples. >> >> You're not alone. We have had lots of concern about the nebulous-ness >> of the "data" that SACM targets. >> >> We have been working to better differentiate the various flows of >> data (data=3Dcorporate guidelines versus collected values of >> operational state, for example). >> >> >> >> - >> >> Section 2.2.1: >> >> -Can you give some examples of "specialized endpoint devices" >> referred in the first sentence of the section? >> >> It can be any device that provides a specialized function, such as a >> router, a switch, a firewall device, etc. >> >> [Linda] Is SACM trying to get one model for "router/switch/firewall"? >> How is it different from SNMP? >> >> >> >> -The first paragraph talked about manufacture publishing guidelines >> on how to configure their devices. Is the objective of SACM for >> standardize those guidelines? >> >> No. I think these guidelines might be thought of as release notes. >> >> But part of the goal would be to encourage expressing the guidelines >> in a machine-friendly format to promote automation, and possibly to >> encourage vendors to use industry standard data formats. >> >> But even if the vendor doesn't provide the information in a >> standardized format, such as a MIB module, they might explain how to >> use proprietary interfaces (such as a CLI) to set and retrieve the curre= nt values. >> >> Part of the guideline would be the vendor's recommendation for values >> to use for the specific model of product, to achieve a specific >> security-related configuration. >> >> As an example, a vendor that supports SNMPv3 in their product might >> specify how to configure the View-based Access Control Model tables >> (SNMP-VIEW-BASED-ACM-MIB from RFC3415). >> >> Appendix A of RFC 3415 contains an example guidelines, that could be >> used by a SACM assessor to assess the security posture of an initial >> configuration of an SNMPv3 deployment. >> >> As another example, the NSA provides guidelines about how to >> configure routers for various security functionality. >> >> See http://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf >> >> >> >> - >> >> Section 2.2.3: >> >> -Does SACM standardize the protocols to detect "end points" >> attachment to the network? >> >> I expect that SACM needs to be able to support multiple protocols for >> this purpose. >> >> Network Management Systems often use multiple technologies to "auto >> discover" a network, such as ping, trace route, SNMP, etc., and they >> use the information gathered to heuristically discover additional >> endpoints, iteratively. >> >> SACM might use such mechanisms directly, but also might "import" the >> network topology from an NMS that already does auto discovery. >> >> >> >> Thank you very much, >> >> Linda Dunbar >> >> *Huawei USA IP Lab* >> >> *5340 Legacy Drive,* >> >> *Plano, TX 75024* >> >> *Tel: +1 469-277 - 5840* >> >> *Fax: +1 469 -277 - 5900* >> >> David Harrington >> >> ietfdbh@comcast.net >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --_000_4A95BA014132FF49AE685FAB4B9F17F645D9F08Edfweml701chmchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Gunnar,
 
What you provided is very helpful.
 
A few more questions:
 
-----Original Message-----
From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com]
Not really the metrics, but about how those metrics can be expressed i= n a way where the determination of policy compliance can be automated.
 
For example, the DISA STIGs (Security Technical Information Guides) ar= e documents that define a set of configuration items for a number of platfo= rms that must be set at certain values in order to be compliant with DoD's = security policies.
 
[Linda] Can you give some examples of the R= 20;platforms” that you are talking about? What does it mean by saying= “configuration items to be set at certain values”?
 
Does it mean that “secure login password= ” has to be X number of characters?
 
 
 
These have traditionally been expressed as prose documents where each = piece of ADPE must be manually verified before the equipment is allowed to = connect to the network.
 
 
So, for example, a Solaris 10 SPARC system used in a environment that = requires adherence to a policy of Mission Critical Classified. 
[Linda] any examples of the “policies= 221; for Mission Critical Classified?
 
SACM would be interested in how to encode that policy in a manner wher= e assessment can be automated, but the actual metrics codified in that docu= ment would be defined by DISA.
 
[Linda] Do you have some examples of the ̶= 0;policies” that are to be encoded to enable the automation? =
 
Similarly to ensure compliance with health care regulations (HIPAA), f= inancial regulations (Sorbanes-Oxley), NATO, Automotive Network Exchange, e= tc.  Anything where the policy can be expressed in the SACM format.
 
[Linda] Any examples of those “policies&= #8221; used for HIPAA, financial regulations?
 
 
SACM will also be defining the mechanism to query for and retrieve dat= a items about endpoint(s),
 
[Linda] If the end point is a router, what kin= d of “data items about endpoints (i.e. router)” are to be queri= ed? Is it FIB/RIB? Or configuration of interfaces?
 
 
so evaluation of a policy is not the only entry point into a SACM syst= em.
 
 
--gun
 
 
 
>
> Linda
>
> -----Original Message-----
> From: sacm [mailto:sacm-= bounces@ietf.org] On Behalf Of Gunnar
> Engelbach
> Sent: Thursday, July 17, 2014 10:55 AM
> To: Linda Dunbar; David Harrington
> Cc: sacm@ietf.org; David Wal= termire
> Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07
>
>
> Linda,
>
> Let me restate what David has said in a different way and see if = that is of any help.
>
> SACM is about standards for automating the security assessments o= f endpoints.  That starts with an expression of security policies in a= form that a machine can apply, but also needs to include the abilities to = determine applicability of each policy to an endpoint (and find all policies that apply to an endpoint), to generate = a list of endpoints, and to request/receive data items for each endpoint ne= cessary to complete analysis of the policy(ies).
>
> This working group is still in the process of defining requiremen= ts for all of this let alone determining what form any of these will take, = but it looks like this will result in discrete components that can be used = for other purposes.
>
> That could mean, for example, taking advantage of a SACM-complian= t system to collect specific data times from certain classes of endpoints f= or your own analysis, or it could mean creating automated policies that use= SACM to produce a set of results and then doing further analysis or aggregation on that result set.
>
>
> Given that any endpoint may or may not be owned by the interested= party, as recognized in your proposal, there would be a spectrum along whi= ch security posture could be determined:
>
> 1) Direct query of endpoint attributes
> 2) Indirect query of endpoint attributes (SACM collection)*
> 3) Request for validation at the SACM policy level
> 4) Stating desired policy and validation via behavioral analysis<= /div>
> 5) Stating desired policy with no external validation
> 6) Service Level Agreement contract
> 7) None.
>
> The lower the number the more reliable (and current) the results,= but a 3rd party is certainly not going to make #1 available.  However= , given the direction SACM is going, I would think that #2 and #3 are very = possible.
>
>
> Incidentally, this exact problem is something NIST started bringi= ng under the SCAP umbrella about five years ago, so it's a happy confluence= to see you bringing this up with SACM.
>
>
> --gun
>
>
>
> * A SACM query should be as reliable as a direct query, but a mec= hanism for guaranteeing this has not yet been worked out.
>
>
> On 7/16/2014 6:42 PM, Linda Dunbar wrote:
>> David,
>>
>> Reading through your explanation make me feel SACM is more li= ke what
>> NETCONF wants to do, except SACM is the reverse direction, is= n't it?
>>
>> NETCONF: Controller (or NMS) =E0device;
>>
>> SACM: devices =E0Controller (or NMS)
>>
>> More questions/comments are inserted below:
>>
>> *From:*David Harrington [mailto:ietfdbh@comcast.net]
>>
>>
>>
>> -How is "Endpoint target" related to "endpoint= "? Can you give some
>> concrete examples?
>>
>> endpoints exist in a network.
>>
>> A SACM assessment process might only be interested in a subse= t of the
>> available endpoints.
>>
>> The members of that subset would be endpoint "targets&qu= ot;.
>>
>> For example, an assessment might, as part of an overall asses= sment
>> process, focus on assessing the current configuration of Huaw= ei
>> routers in a heterogeneous network, based on administratively= -defined
>> rules about how a Huawei router should be configured.
>>
>> Each of the selected Huawei routers in that subset would then= be an
>> "endpoint target" for that assessment.
>>
>> [Linda] Does it mean SACM is like NETCONF, except the informa= tion is
>> from Devices to Controller (or NMS)?
>>
>> Are you asking for concrete example so you understand the doc= ument
>> better, or are you asking us to add some concrete examples to= the document?
>>
>> (If you didn't understand this from the current text, then so= me
>> concrete examples in the document would seem a good idea..)
>>
>> [Linda] absolutely some examples will help a lot. Use cases a= re
>> supposed to be examples, examples of "end points", = examples of actual
>> "data" to be collected, examples of "data-defi= nitions" used in the draft, etc.
>>
>>
>>
>> -
>>
>> Section 2.1.1:
>>
>> -Are there any examples for the "Data Definition" d= escribed in this
>> section? or data model?
>>
>> We have the non-unique problem that, because SACM is such a b= road
>> topic, this WG draws people from multiple SDOs and multiple v= endors
>> with products in the "SACM space".
>>
>> We have avoided mentioning specific standards as examples bec= ause we
>> feared a rush of "what about <my favorite protocol>= ;?" requests.
>>
>> Do you feel that the text is too hard to understand without e= xamples?
>>
>> [Linda] I thought that IETF doesn't do too broad problems WG.= Are
>> there examples of "Data Definitions" in mind?
>>
>>
>>
>> -I can't figure out what "data" is SACM targeted fo= r.
>>
>> Because we are currently working at such an abstract level, <= /div>
>> discussing use cases and architectures, SACM scope includes m= any
>> different potential flows.
>>
>> In many cases, the "data" depends on the flow invol= ved.
>>
>> For example, a collector application might collect current va= lues
>> from a managed switch using SNMP and MIB data models, and fro= m a
>> managed router using Netconf and YANG data models.
>>
>> The collector might convert that data into database-specific = format
>> for storage and fast retrieval; It might organize the data in= to its
>> own internal information models, organized to support its app= roach to
>> security assessment.
>>
>> When an assessment application asks the database for some dat= a, it
>> might request a specific (database-record-defined) informatio= n
>> model's worth of data, or a mixed-model set of data, using an= SQL
>> request
>>
>> The assessment application might generate data into a report =
>> containing the results of the assessment, possibly in, let's = say,
>> Excel format or in a text message to an operator.
>>
>> [Linda] Does SACM target to have one proxy data models for &q= uot;NETCONF,
>> SNMP, SQL, ."?
>>
>> Because SACM scope (security assessment) is very broad, it is= hard to
>> nail down what the data is in any particular flow, without ex= cluding
>> some data that somebody wants included (and is a legitimate t= ype of
>> data for SACM purposes).
>>
>> That's why we're starting with a use cases document - to help=
>> identify the types of data that might be needed to address ce= rtain
>> types of assessment.
>>
>> [Linda] Then the Use Case document should have concrete examp= les.
>>
>> You're not alone. We have had lots of concern about the nebul= ous-ness
>> of the "data" that SACM targets.
>>
>> We have been working to better differentiate the various flow= s of
>> data (data=3Dcorporate guidelines versus collected values of =
>> operational state, for example).
>>
>>
>>
>> -
>>
>> Section 2.2.1:
>>
>> -Can you give some examples of "specialized endpoint dev= ices"
>> referred in the first sentence of the section?
>>
>> It can be any device that provides a specialized function, su= ch as a
>> router, a switch, a firewall device, etc.
>>
>> [Linda] Is SACM trying to get one model for "router/swit= ch/firewall"?
>> How is it different from SNMP?
>>
>>
>>
>> -The first paragraph talked about manufacture publishing guid= elines
>> on how to configure their devices. Is the objective of SACM f= or
>> standardize those guidelines?
>>
>> No. I think these guidelines might be thought of as release n= otes.
>>
>> But part of the goal would be to encourage expressing the gui= delines
>> in a machine-friendly format to promote automation, and possi= bly to
>> encourage vendors to use industry standard data formats.
>>
>> But even if the vendor doesn't provide the information in a <= /div>
>> standardized format, such as a MIB module, they might explain= how to
>> use proprietary interfaces (such as a CLI) to set and retriev= e the current values.
>>
>> Part of the guideline would be the vendor's recommendation fo= r values
>> to use for the specific model of product, to achieve a specif= ic
>> security-related configuration.
>>
>> As an example, a vendor that supports SNMPv3 in their product= might
>> specify how to configure the View-based Access Control Model = tables
>> (SNMP-VIEW-BASED-ACM-MIB from RFC3415).
>>
>> Appendix A of RFC 3415 contains an example guidelines, that c= ould be
>> used by a SACM assessor to assess the security posture of an = initial
>> configuration of an SNMPv3 deployment.
>>
>> As another example, the NSA provides guidelines about how to =
>> configure routers for various security functionality.
>>
>>
>>
>>
>> -
>>
>> Section 2.2.3:
>>
>> -Does SACM standardize the protocols to detect "end poin= ts"
>> attachment to the network?
>>
>> I expect that SACM needs to be able to support multiple proto= cols for
>> this purpose.
>>
>> Network Management Systems often use multiple technologies to= "auto
>> discover" a network, such as ping, trace route, SNMP, et= c., and they
>> use the information gathered to heuristically discover additi= onal
>> endpoints, iteratively.
>>
>> SACM might use such mechanisms directly, but also might "= ;import" the
>> network topology from an NMS that already does auto discovery= .
>>
>>
>>
>> Thank you very much,
>>
>> Linda Dunbar
>>
>> *Huawei USA IP Lab*
>>
>> *5340 Legacy Drive,*
>>
>> *Plano, TX 75024*
>>
>> *Tel: +1 469-277 - 5840*
>>
>> *Fax: +1 469 -277 - 5900*
>>
>> David Harrington
>>
>>
>>
>>
>> _______________________________________________
>> sacm mailing list
>>
>
> _______________________________________________
> sacm mailing list
>
 
--_000_4A95BA014132FF49AE685FAB4B9F17F645D9F08Edfweml701chmchi_-- From nobody Thu Jul 17 15:19:14 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560481A0085 for ; Thu, 17 Jul 2014 15:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-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 uVRQtNM9Rp36 for ; Thu, 17 Jul 2014 15:19:08 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAA71A01C5 for ; Thu, 17 Jul 2014 15:19:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=Ht7QWOA7oqtVu9tG8lSKy5wEuraQ1p5mi+ufPh2ituA2kbCfJhTUs78PWsJUf6HKe98dDqryoAJtpTVsuWghk4kzmzVcYjluMODtRt5nXYkjA1+dj2hi9EUxyVdIaFQ6; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 12131 invoked from network); 17 Jul 2014 15:32:14 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by server.threatguard.com with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 17 Jul 2014 15:32:14 -0700 Message-ID: <53C84BDF.6080507@ThreatGuard.com> Date: Thu, 17 Jul 2014 18:19:11 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Dunbar , David Harrington References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> <53C7F1CF.4070408@ThreatGuard.com> <4A95BA014132FF49AE685FAB4B9F17F645D9ED81@dfweml701-chm.china.huawei.com> <53C80F92.4020205@ThreatGuard.com> <4A95BA014132FF49AE685FAB4B9F17F645D9F08E@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9F08E@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/P574kjFqqOE-zqB8tK19jWKs7kE Cc: "sacm@ietf.org" , David Waltermire Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 22:19:11 -0000 On 7/17/2014 5:11 PM, Linda Dunbar wrote: > Gunnar, > What you provided is very helpful. > A few more questions: > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Not really the metrics, but about how those metrics can be expressed in > a way where the determination of policy compliance can be automated. > For example, the DISA STIGs (Security Technical Information Guides) are > documents that define a set of configuration items for a number of > platforms that must be set at certain values in order to be compliant > with DoD's security policies. > [Linda] Can you give some examples of the “platforms” that you are > talking about? For the STIGs, a platform would be Solaris 9, Solaris 10, AIX 5.3, Windows 7, and so on. Some STIGs also address software components like the .Net framework, Internet Explorer, and so on. What does it mean by saying “configuration items to be > set at certain values”? > Does it mean that “secure login password” has to be X number of characters? Exactly. The STIGs will include rules like "The maximum password age must be 30 days" and "The minimum password age must be 1 day" In total, the Windows 7 STIG has nearly 300 of these rules. Collectively, that set of 272 rules is the STIG policy for Windows 7. Each Windows 7 machine must pass every rule in order to be compliant with the policy. Similarly, the USGCG policy for Windows 7 has about the same number of rules, most of which cover the same items, but might have different values. For example, under USGCB the maximum password age is allowed to be 60 days. > These have traditionally been expressed as prose documents where each > piece of ADPE must be manually verified before the equipment is allowed > to connect to the network. > So, for example, a Solaris 10 SPARC system used in a environment that > requires adherence to a policy of Mission Critical Classified. > [Linda] any examples of the “policies” for Mission Critical Classified? Mission Critical Classified (aka MAC-1 Classified) *is* the policy, as are other Windows 7 STIG policies, such as Administrative Public (MAC-III Public) or Mission Support Sensitive (MAC-II Sensitive). Each of these policies, for the most part cover the same rules (give or take a few here and there) but will have more or less stringent settings for many of these rules depending on the security level the target computer is running at. Which policy applies to which computer depends on the role and type of data being processed by that computer. Matching up the proper policy to the proper computer is part of the assessment process. This is a little less complicated in other areas, like USGCB or HIPAA, where there is a single policy that applies equally to all computers. So a policy is made up of one or more rules, and each rule requires one or more data items to be evaluated. > SACM would be interested in how to encode that policy in a manner where > assessment can be automated, but the actual metrics codified in that > document would be defined by DISA. > [Linda] Do you have some examples of the “policies” that are to be > encoded to enable the automation? > Similarly to ensure compliance with health care regulations (HIPAA), > financial regulations (Sorbanes-Oxley), NATO, Automotive Network > Exchange, etc. Anything where the policy can be expressed in the SACM > format. > [Linda] Any examples of those “policies” used for HIPAA, financial > regulations? > SACM will also be defining the mechanism to query for and retrieve data > items about endpoint(s), > [Linda] If the end point is a router, what kind of “data items about > endpoints (i.e. router)” are to be queried? Is it FIB/RIB? Or > configuration of interfaces? That depends on the policy. Like from the STIG password example where the minimum and password ages are part of the policy those two data items would need to be known about each endpoint to which the policy applies. Full evaluation of the policy would require all of the needed data items and nothing more, and the policy would need to specify what those data items are. Those data items would then be collected and the level of policy compliance could be computed. > so evaluation of a policy is not the only entry point into a SACM system. > --gun >> >> Linda >> >> -----Original Message----- >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar >> Engelbach >> Sent: Thursday, July 17, 2014 10:55 AM >> To: Linda Dunbar; David Harrington >> Cc:sacm@ietf.org ; David Waltermire >> Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 >> >> >> Linda, >> >> Let me restate what David has said in a different way and see if that is of any help. >> >> SACM is about standards for automating the security assessments of endpoints. That starts with an expression of security policies in a form that a machine can apply, but also needs to include the abilities to determine applicability of each policy to an endpoint (and find all policies that apply to an endpoint), to > generate a list of endpoints, and to request/receive data items for each > endpoint necessary to complete analysis of the policy(ies). >> >> This working group is still in the process of defining requirements for all of this let alone determining what form any of these will take, but it looks like this will result in discrete components that can be used for other purposes. >> >> That could mean, for example, taking advantage of a SACM-compliant system to collect specific data times from certain classes of endpoints for your own analysis, or it could mean creating automated policies that use SACM to produce a set of results and then doing further analysis or aggregation on that result set. >> >> >> Given that any endpoint may or may not be owned by the interested party, as recognized in your proposal, there would be a spectrum along which security posture could be determined: >> >> 1) Direct query of endpoint attributes >> 2) Indirect query of endpoint attributes (SACM collection)* >> 3) Request for validation at the SACM policy level >> 4) Stating desired policy and validation via behavioral analysis >> 5) Stating desired policy with no external validation >> 6) Service Level Agreement contract >> 7) None. >> >> The lower the number the more reliable (and current) the results, but a 3rd party is certainly not going to make #1 available. However, given the direction SACM is going, I would think that #2 and #3 are very possible. >> >> >> Incidentally, this exact problem is something NIST started bringing under the SCAP umbrella about five years ago, so it's a happy confluence to see you bringing this up with SACM. >> >> >> --gun >> >> >> >> * A SACM query should be as reliable as a direct query, but a mechanism for guaranteeing this has not yet been worked out. >> >> >> On 7/16/2014 6:42 PM, Linda Dunbar wrote: >>> David, >>> >>> Reading through your explanation make me feel SACM is more like what >>> NETCONF wants to do, except SACM is the reverse direction, isn't it? >>> >>> NETCONF: Controller (or NMS) àdevice; >>> >>> SACM: devices àController (or NMS) >>> >>> More questions/comments are inserted below: >>> >>> *From:*David Harrington [mailto:ietfdbh@comcast.net] >>> >>> >>> >>> -How is "Endpoint target" related to "endpoint"? Can you give some >>> concrete examples? >>> >>> endpoints exist in a network. >>> >>> A SACM assessment process might only be interested in a subset of the >>> available endpoints. >>> >>> The members of that subset would be endpoint "targets". >>> >>> For example, an assessment might, as part of an overall assessment >>> process, focus on assessing the current configuration of Huawei >>> routers in a heterogeneous network, based on administratively-defined >>> rules about how a Huawei router should be configured. >>> >>> Each of the selected Huawei routers in that subset would then be an >>> "endpoint target" for that assessment. >>> >>> [Linda] Does it mean SACM is like NETCONF, except the information is >>> from Devices to Controller (or NMS)? >>> >>> Are you asking for concrete example so you understand the document >>> better, or are you asking us to add some concrete examples to the document? >>> >>> (If you didn't understand this from the current text, then some >>> concrete examples in the document would seem a good idea..) >>> >>> [Linda] absolutely some examples will help a lot. Use cases are >>> supposed to be examples, examples of "end points", examples of actual >>> "data" to be collected, examples of "data-definitions" used in the draft, etc. >>> >>> >>> >>> - >>> >>> Section 2.1.1: >>> >>> -Are there any examples for the "Data Definition" described in this >>> section? or data model? >>> >>> We have the non-unique problem that, because SACM is such a broad >>> topic, this WG draws people from multiple SDOs and multiple vendors >>> with products in the "SACM space". >>> >>> We have avoided mentioning specific standards as examples because we >>> feared a rush of "what about ?" requests. >>> >>> Do you feel that the text is too hard to understand without examples? >>> >>> [Linda] I thought that IETF doesn't do too broad problems WG. Are >>> there examples of "Data Definitions" in mind? >>> >>> >>> >>> -I can't figure out what "data" is SACM targeted for. >>> >>> Because we are currently working at such an abstract level, >>> discussing use cases and architectures, SACM scope includes many >>> different potential flows. >>> >>> In many cases, the "data" depends on the flow involved. >>> >>> For example, a collector application might collect current values >>> from a managed switch using SNMP and MIB data models, and from a >>> managed router using Netconf and YANG data models. >>> >>> The collector might convert that data into database-specific format >>> for storage and fast retrieval; It might organize the data into its >>> own internal information models, organized to support its approach to >>> security assessment. >>> >>> When an assessment application asks the database for some data, it >>> might request a specific (database-record-defined) information >>> model's worth of data, or a mixed-model set of data, using an SQL >>> request >>> >>> The assessment application might generate data into a report >>> containing the results of the assessment, possibly in, let's say, >>> Excel format or in a text message to an operator. >>> >>> [Linda] Does SACM target to have one proxy data models for "NETCONF, >>> SNMP, SQL, ."? >>> >>> Because SACM scope (security assessment) is very broad, it is hard to >>> nail down what the data is in any particular flow, without excluding >>> some data that somebody wants included (and is a legitimate type of >>> data for SACM purposes). >>> >>> That's why we're starting with a use cases document - to help >>> identify the types of data that might be needed to address certain >>> types of assessment. >>> >>> [Linda] Then the Use Case document should have concrete examples. >>> >>> You're not alone. We have had lots of concern about the nebulous-ness >>> of the "data" that SACM targets. >>> >>> We have been working to better differentiate the various flows of >>> data (data=corporate guidelines versus collected values of >>> operational state, for example). >>> >>> >>> >>> - >>> >>> Section 2.2.1: >>> >>> -Can you give some examples of "specialized endpoint devices" >>> referred in the first sentence of the section? >>> >>> It can be any device that provides a specialized function, such as a >>> router, a switch, a firewall device, etc. >>> >>> [Linda] Is SACM trying to get one model for "router/switch/firewall"? >>> How is it different from SNMP? >>> >>> >>> >>> -The first paragraph talked about manufacture publishing guidelines >>> on how to configure their devices. Is the objective of SACM for >>> standardize those guidelines? >>> >>> No. I think these guidelines might be thought of as release notes. >>> >>> But part of the goal would be to encourage expressing the guidelines >>> in a machine-friendly format to promote automation, and possibly to >>> encourage vendors to use industry standard data formats. >>> >>> But even if the vendor doesn't provide the information in a >>> standardized format, such as a MIB module, they might explain how to >>> use proprietary interfaces (such as a CLI) to set and retrieve the current values. >>> >>> Part of the guideline would be the vendor's recommendation for values >>> to use for the specific model of product, to achieve a specific >>> security-related configuration. >>> >>> As an example, a vendor that supports SNMPv3 in their product might >>> specify how to configure the View-based Access Control Model tables >>> (SNMP-VIEW-BASED-ACM-MIB from RFC3415). >>> >>> Appendix A of RFC 3415 contains an example guidelines, that could be >>> used by a SACM assessor to assess the security posture of an initial >>> configuration of an SNMPv3 deployment. >>> >>> As another example, the NSA provides guidelines about how to >>> configure routers for various security functionality. >>> >>> Seehttp://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf >>> >>> >>> >>> - >>> >>> Section 2.2.3: >>> >>> -Does SACM standardize the protocols to detect "end points" >>> attachment to the network? >>> >>> I expect that SACM needs to be able to support multiple protocols for >>> this purpose. >>> >>> Network Management Systems often use multiple technologies to "auto >>> discover" a network, such as ping, trace route, SNMP, etc., and they >>> use the information gathered to heuristically discover additional >>> endpoints, iteratively. >>> >>> SACM might use such mechanisms directly, but also might "import" the >>> network topology from an NMS that already does auto discovery. >>> >>> >>> >>> Thank you very much, >>> >>> Linda Dunbar >>> >>> *Huawei USA IP Lab* >>> >>> *5340 Legacy Drive,* >>> >>> *Plano, TX 75024* >>> >>> *Tel: +1 469-277 - 5840* >>> >>> *Fax: +1 469 -277 - 5900* >>> >>> David Harrington >>> >>>ietfdbh@comcast.net > >>> >>> >>> >>> _______________________________________________ >>> sacm mailing list >>>sacm@ietf.org >>>https://www.ietf.org/mailman/listinfo/sacm >>> >> >> _______________________________________________ >> sacm mailing list >>sacm@ietf.org >>https://www.ietf.org/mailman/listinfo/sacm >> From nobody Thu Jul 17 15:53:16 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED6B1B2801 for ; Thu, 17 Jul 2014 15:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-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 oHdQ0fpDCXmq for ; Thu, 17 Jul 2014 15:53:11 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734121A0314 for ; Thu, 17 Jul 2014 15:53:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=odMtDKlReHiQ+TejRLl8+BE30IF1MDBR/ZVI9RMHqqd0OK/7Uipg5CCrWZ3rrR2n4noc2NGx3ChWyLDmnslQO9iusm/9c16hK+sSYJRiXPfLFoFjk5DibSYGCMBuleDA; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 12606 invoked from network); 17 Jul 2014 16:06:18 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by server.threatguard.com with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 17 Jul 2014 16:06:17 -0700 Message-ID: <53C853DB.5000006@ThreatGuard.com> Date: Thu, 17 Jul 2014 18:53:15 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Dunbar , David Harrington References: <4A95BA014132FF49AE685FAB4B9F17F645D9CC52@dfweml701-chm.china.huawei.com> <8D0A8B0B-7AF9-4F0D-A365-DB5DE94AFDA6@comcast.net> <4A95BA014132FF49AE685FAB4B9F17F645D9E6E3@dfweml701-chm.china.huawei.com> <53C7F1CF.4070408@ThreatGuard.com> <4A95BA014132FF49AE685FAB4B9F17F645D9ED81@dfweml701-chm.china.huawei.com> <53C80F92.4020205@ThreatGuard.com> <4A95BA014132FF49AE685FAB4B9F17F645D9F08E@dfweml701-chm.china.huawei.com> <53C84BDF.6080507@ThreatGuard.com> In-Reply-To: <53C84BDF.6080507@ThreatGuard.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/oVJp2tbGqfQzYMEeZg-yDbP2doc Cc: "sacm@ietf.org" , David Waltermire Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 22:53:14 -0000 It seemed like I was getting a little wordy there so I tried to restrain myself, but it occurs to me that maybe I should clarify something. When I refer to STIG, USGCG, HIPAA, etc, policies, those are all just one class of policy -- measuring conformity with security settings. There can be other kinds of policies. Such as determining susceptibility to known vulnerabilities, or if disallowed software is installed, or if there is evidence of malware, and so on. --gun On 7/17/2014 6:19 PM, Gunnar Engelbach wrote: > > > On 7/17/2014 5:11 PM, Linda Dunbar wrote: >> Gunnar, >> What you provided is very helpful. >> A few more questions: >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Not really the metrics, but about how those metrics can be expressed in >> a way where the determination of policy compliance can be automated. >> For example, the DISA STIGs (Security Technical Information Guides) are >> documents that define a set of configuration items for a number of >> platforms that must be set at certain values in order to be compliant >> with DoD's security policies. >> [Linda] Can you give some examples of the “platforms” that you are >> talking about? > > For the STIGs, a platform would be Solaris 9, Solaris 10, AIX 5.3, > Windows 7, and so on. Some STIGs also address software components like > the .Net framework, Internet Explorer, and so on. > > What does it mean by saying “configuration items to be >> set at certain values”? >> Does it mean that “secure login password” has to be X number of >> characters? > > Exactly. The STIGs will include rules like "The maximum password age > must be 30 days" and "The minimum password age must be 1 day" > > In total, the Windows 7 STIG has nearly 300 of these rules. > Collectively, that set of 272 rules is the STIG policy for Windows 7. > Each Windows 7 machine must pass every rule in order to be compliant > with the policy. > > Similarly, the USGCG policy for Windows 7 has about the same number of > rules, most of which cover the same items, but might have different > values. For example, under USGCB the maximum password age is allowed to > be 60 days. > > > >> These have traditionally been expressed as prose documents where each >> piece of ADPE must be manually verified before the equipment is allowed >> to connect to the network. >> So, for example, a Solaris 10 SPARC system used in a environment that >> requires adherence to a policy of Mission Critical Classified. >> [Linda] any examples of the “policies” for Mission Critical Classified? > > Mission Critical Classified (aka MAC-1 Classified) *is* the policy, as > are other Windows 7 STIG policies, such as Administrative Public > (MAC-III Public) or Mission Support Sensitive (MAC-II Sensitive). > > Each of these policies, for the most part cover the same rules (give or > take a few here and there) but will have more or less stringent settings > for many of these rules depending on the security level the target > computer is running at. > > Which policy applies to which computer depends on the role and type of > data being processed by that computer. Matching up the proper policy to > the proper computer is part of the assessment process. > > This is a little less complicated in other areas, like USGCB or HIPAA, > where there is a single policy that applies equally to all computers. > > > So a policy is made up of one or more rules, and each rule requires one > or more data items to be evaluated. > > > >> SACM would be interested in how to encode that policy in a manner where >> assessment can be automated, but the actual metrics codified in that >> document would be defined by DISA. >> [Linda] Do you have some examples of the “policies” that are to be >> encoded to enable the automation? >> Similarly to ensure compliance with health care regulations (HIPAA), >> financial regulations (Sorbanes-Oxley), NATO, Automotive Network >> Exchange, etc. Anything where the policy can be expressed in the SACM >> format. >> [Linda] Any examples of those “policies” used for HIPAA, financial >> regulations? >> SACM will also be defining the mechanism to query for and retrieve data >> items about endpoint(s), >> [Linda] If the end point is a router, what kind of “data items about >> endpoints (i.e. router)” are to be queried? Is it FIB/RIB? Or >> configuration of interfaces? > > > That depends on the policy. Like from the STIG password example where > the minimum and password ages are part of the policy those two data > items would need to be known about each endpoint to which the policy > applies. Full evaluation of the policy would require all of the needed > data items and nothing more, and the policy would need to specify what > those data items are. Those data items would then be collected and the > level of policy compliance could be computed. > > > > > >> so evaluation of a policy is not the only entry point into a SACM system. >> --gun >>> >>> Linda >>> >>> -----Original Message----- >>> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar >>> Engelbach >>> Sent: Thursday, July 17, 2014 10:55 AM >>> To: Linda Dunbar; David Harrington >>> Cc:sacm@ietf.org ; David Waltermire >>> Subject: Re: [sacm] Questions to draft-ietf-sacm-use-cases-07 >>> >>> >>> Linda, >>> >>> Let me restate what David has said in a different way and see if that >>> is of any help. >>> >>> SACM is about standards for automating the security assessments of >>> endpoints. That starts with an expression of security policies in a >>> form that a machine can apply, but also needs to include the >>> abilities to determine applicability of each policy to an endpoint >>> (and find all policies that apply to an endpoint), to >> generate a list of endpoints, and to request/receive data items for each >> endpoint necessary to complete analysis of the policy(ies). >>> >>> This working group is still in the process of defining requirements >>> for all of this let alone determining what form any of these will >>> take, but it looks like this will result in discrete components that >>> can be used for other purposes. >>> >>> That could mean, for example, taking advantage of a SACM-compliant >>> system to collect specific data times from certain classes of >>> endpoints for your own analysis, or it could mean creating automated >>> policies that use SACM to produce a set of results and then doing >>> further analysis or aggregation on that result set. >>> >>> >>> Given that any endpoint may or may not be owned by the interested >>> party, as recognized in your proposal, there would be a spectrum >>> along which security posture could be determined: >>> >>> 1) Direct query of endpoint attributes >>> 2) Indirect query of endpoint attributes (SACM collection)* >>> 3) Request for validation at the SACM policy level >>> 4) Stating desired policy and validation via behavioral analysis >>> 5) Stating desired policy with no external validation >>> 6) Service Level Agreement contract >>> 7) None. >>> >>> The lower the number the more reliable (and current) the results, but >>> a 3rd party is certainly not going to make #1 available. However, >>> given the direction SACM is going, I would think that #2 and #3 are >>> very possible. >>> >>> >>> Incidentally, this exact problem is something NIST started bringing >>> under the SCAP umbrella about five years ago, so it's a happy >>> confluence to see you bringing this up with SACM. >>> >>> >>> --gun >>> >>> >>> >>> * A SACM query should be as reliable as a direct query, but a >>> mechanism for guaranteeing this has not yet been worked out. >>> >>> >>> On 7/16/2014 6:42 PM, Linda Dunbar wrote: >>>> David, >>>> >>>> Reading through your explanation make me feel SACM is more like what >>>> NETCONF wants to do, except SACM is the reverse direction, isn't it? >>>> >>>> NETCONF: Controller (or NMS) àdevice; >>>> >>>> SACM: devices àController (or NMS) >>>> >>>> More questions/comments are inserted below: >>>> >>>> *From:*David Harrington [mailto:ietfdbh@comcast.net] >>>> >>>> >>>> >>>> -How is "Endpoint target" related to "endpoint"? Can you give some >>>> concrete examples? >>>> >>>> endpoints exist in a network. >>>> >>>> A SACM assessment process might only be interested in a subset of the >>>> available endpoints. >>>> >>>> The members of that subset would be endpoint "targets". >>>> >>>> For example, an assessment might, as part of an overall assessment >>>> process, focus on assessing the current configuration of Huawei >>>> routers in a heterogeneous network, based on administratively-defined >>>> rules about how a Huawei router should be configured. >>>> >>>> Each of the selected Huawei routers in that subset would then be an >>>> "endpoint target" for that assessment. >>>> >>>> [Linda] Does it mean SACM is like NETCONF, except the information is >>>> from Devices to Controller (or NMS)? >>>> >>>> Are you asking for concrete example so you understand the document >>>> better, or are you asking us to add some concrete examples to the >>>> document? >>>> >>>> (If you didn't understand this from the current text, then some >>>> concrete examples in the document would seem a good idea..) >>>> >>>> [Linda] absolutely some examples will help a lot. Use cases are >>>> supposed to be examples, examples of "end points", examples of actual >>>> "data" to be collected, examples of "data-definitions" used in the >>>> draft, etc. >>>> >>>> >>>> >>>> - >>>> >>>> Section 2.1.1: >>>> >>>> -Are there any examples for the "Data Definition" described in this >>>> section? or data model? >>>> >>>> We have the non-unique problem that, because SACM is such a broad >>>> topic, this WG draws people from multiple SDOs and multiple vendors >>>> with products in the "SACM space". >>>> >>>> We have avoided mentioning specific standards as examples because we >>>> feared a rush of "what about ?" requests. >>>> >>>> Do you feel that the text is too hard to understand without examples? >>>> >>>> [Linda] I thought that IETF doesn't do too broad problems WG. Are >>>> there examples of "Data Definitions" in mind? >>>> >>>> >>>> >>>> -I can't figure out what "data" is SACM targeted for. >>>> >>>> Because we are currently working at such an abstract level, >>>> discussing use cases and architectures, SACM scope includes many >>>> different potential flows. >>>> >>>> In many cases, the "data" depends on the flow involved. >>>> >>>> For example, a collector application might collect current values >>>> from a managed switch using SNMP and MIB data models, and from a >>>> managed router using Netconf and YANG data models. >>>> >>>> The collector might convert that data into database-specific format >>>> for storage and fast retrieval; It might organize the data into its >>>> own internal information models, organized to support its approach to >>>> security assessment. >>>> >>>> When an assessment application asks the database for some data, it >>>> might request a specific (database-record-defined) information >>>> model's worth of data, or a mixed-model set of data, using an SQL >>>> request >>>> >>>> The assessment application might generate data into a report >>>> containing the results of the assessment, possibly in, let's say, >>>> Excel format or in a text message to an operator. >>>> >>>> [Linda] Does SACM target to have one proxy data models for "NETCONF, >>>> SNMP, SQL, ."? >>>> >>>> Because SACM scope (security assessment) is very broad, it is hard to >>>> nail down what the data is in any particular flow, without excluding >>>> some data that somebody wants included (and is a legitimate type of >>>> data for SACM purposes). >>>> >>>> That's why we're starting with a use cases document - to help >>>> identify the types of data that might be needed to address certain >>>> types of assessment. >>>> >>>> [Linda] Then the Use Case document should have concrete examples. >>>> >>>> You're not alone. We have had lots of concern about the nebulous-ness >>>> of the "data" that SACM targets. >>>> >>>> We have been working to better differentiate the various flows of >>>> data (data=corporate guidelines versus collected values of >>>> operational state, for example). >>>> >>>> >>>> >>>> - >>>> >>>> Section 2.2.1: >>>> >>>> -Can you give some examples of "specialized endpoint devices" >>>> referred in the first sentence of the section? >>>> >>>> It can be any device that provides a specialized function, such as a >>>> router, a switch, a firewall device, etc. >>>> >>>> [Linda] Is SACM trying to get one model for "router/switch/firewall"? >>>> How is it different from SNMP? >>>> >>>> >>>> >>>> -The first paragraph talked about manufacture publishing guidelines >>>> on how to configure their devices. Is the objective of SACM for >>>> standardize those guidelines? >>>> >>>> No. I think these guidelines might be thought of as release notes. >>>> >>>> But part of the goal would be to encourage expressing the guidelines >>>> in a machine-friendly format to promote automation, and possibly to >>>> encourage vendors to use industry standard data formats. >>>> >>>> But even if the vendor doesn't provide the information in a >>>> standardized format, such as a MIB module, they might explain how to >>>> use proprietary interfaces (such as a CLI) to set and retrieve the >>>> current values. >>>> >>>> Part of the guideline would be the vendor's recommendation for values >>>> to use for the specific model of product, to achieve a specific >>>> security-related configuration. >>>> >>>> As an example, a vendor that supports SNMPv3 in their product might >>>> specify how to configure the View-based Access Control Model tables >>>> (SNMP-VIEW-BASED-ACM-MIB from RFC3415). >>>> >>>> Appendix A of RFC 3415 contains an example guidelines, that could be >>>> used by a SACM assessor to assess the security posture of an initial >>>> configuration of an SNMPv3 deployment. >>>> >>>> As another example, the NSA provides guidelines about how to >>>> configure routers for various security functionality. >>>> >>>> Seehttp://www.nsa.gov/ia/_files/routers/c4-040r-02.pdf >>>> >>>> >>>> >>>> - >>>> >>>> Section 2.2.3: >>>> >>>> -Does SACM standardize the protocols to detect "end points" >>>> attachment to the network? >>>> >>>> I expect that SACM needs to be able to support multiple protocols for >>>> this purpose. >>>> >>>> Network Management Systems often use multiple technologies to "auto >>>> discover" a network, such as ping, trace route, SNMP, etc., and they >>>> use the information gathered to heuristically discover additional >>>> endpoints, iteratively. >>>> >>>> SACM might use such mechanisms directly, but also might "import" the >>>> network topology from an NMS that already does auto discovery. >>>> >>>> >>>> >>>> Thank you very much, >>>> >>>> Linda Dunbar >>>> >>>> *Huawei USA IP Lab* >>>> >>>> *5340 Legacy Drive,* >>>> >>>> *Plano, TX 75024* >>>> >>>> *Tel: +1 469-277 - 5840* >>>> >>>> *Fax: +1 469 -277 - 5900* >>>> >>>> David Harrington >>>> >>>> ietfdbh@comcast.net >> >>>> >>>> >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>> >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From nobody Thu Jul 17 17:17:18 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5341A00E2 for ; Thu, 17 Jul 2014 17:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 UCl3oEj3Tifd for ; Thu, 17 Jul 2014 17:17:15 -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 2D53E1A00DF for ; Thu, 17 Jul 2014 17:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1854; q=dns/txt; s=iport; t=1405642635; x=1406852235; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5xf70eXputArWGKwKBUuxoM58XkqRwJz78zCcDLjw4I=; b=XYQV0O8XpDdDvERQlvrwB+2kNVwhqPIx1PmVCZIWd1neeeKfgruxTXkq q2sDkoM8cgw0KXlnDwYZ/oKXCX/O5aSuTpFnZT1Zl3Y1lBqT2yvIkiCIP 2qVGFmc/VsszWUYazwR0LD8xI2cFoTjLSRHu1ggGlbuoM7NaH0YFvWY1q Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFANdmyFOtJA2H/2dsb2JhbABZgw5SVwTEDYdBAYEJFnaEBAEBBB1aEgIBCBI0MhcEAQYDAgQTCRKIJw3FNxePUoRGBYoqkHWBTJJgg0RsAYFE X-IronPort-AV: E=Sophos;i="5.01,681,1400025600"; d="scan'208";a="340860178" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP; 18 Jul 2014 00:17:14 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6I0HEwI021314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Jul 2014 00:17:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 19:17:14 -0500 From: "Aaron Woland (aawoland)" To: "sacm@ietf.org" Thread-Topic: New Version Notification for draft-salowey-sacm-xmpp-grid-00.txt Thread-Index: AQHPlc/VWKMjRtfewEuMwMeeX/7w5ZulIDCA Date: Fri, 18 Jul 2014 00:17:13 +0000 Message-ID: References: <20140702083002.7597.96287.idtracker@ietfa.amsl.com> In-Reply-To: <20140702083002.7597.96287.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.117.118.214] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/riG2o4JzHVV8wnahcFSQkxExUsU Subject: [sacm] FW: New Version Notification for draft-salowey-sacm-xmpp-grid-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 00:17:17 -0000 Greetings and Salutations, In response to the SACM Call for Contributions for a transport model, several colleagues and I have outlined a draft transport model for SACM - described in the below linked Internet-Draft. This XMPP-Grid transport model is based largely on a =B3best of both worlds= =B2 approach with Cisco=B9s pxGrid and the TNC IF-MAP specifications, and stems from our collective experience creating, implementing, and deploying both pxGrid and TNC standards-based solutions for endpoint compliance and security automation. We are very much looking forward to discussing this Internet-Draft and hearing your feedback at IETF 90! -- Regards, Aaron T. Woland, CCIE #20113 Sr. Secure Access TME, SAMBU ciscoSystems, Inc. On 7/2/14, 4:30 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-salowey-sacm-xmpp-grid-00.txt >has been successfully submitted by Nancy Cam-Winget and posted to the >IETF repository. > >Name: draft-salowey-sacm-xmpp-grid >Revision: 00 >Title: XMPP Protocol Extensions for Use in SACM Information Transport >Document date: 2014-07-02 >Group: Individual Submission >Pages: 51 >URL: =20 >http://www.ietf.org/internet-drafts/draft-salowey-sacm-xmpp-grid-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-salowey-sacm-xmpp-grid/ >Htmlized: http://tools.ietf.org/html/draft-salowey-sacm-xmpp-grid-00 > > >Abstract: > This document defines a transport protocol for use with the Security > Automation and Continuous Monitoring (SACM) Architecture. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Fri Jul 18 15:16:13 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685131A0298 for ; Fri, 18 Jul 2014 15:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 js434H7hPiUS for ; Fri, 18 Jul 2014 15:15:53 -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 7EB091A028A for ; Fri, 18 Jul 2014 15:15:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHI52709; Fri, 18 Jul 2014 22:15:31 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 23:15:30 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml705-chm.china.huawei.com ([169.254.7.240]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 15:15:19 -0700 From: Linda Dunbar To: David Harrington Thread-Topic: Summerized differences between SACM and NSaaS Thread-Index: AQHPotXCSD/rh78U9EqZ4q6s0QcW5g== Date: Fri, 18 Jul 2014 22:15:19 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9FDDC@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D94D21@dfweml701-chm.china.huawei.com> <1D8E6F4F-2854-4FCF-BA3D-A1AF22666FBF@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.239] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D9FDDCdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/mE0nOnfNBD04KNLD04UqUg7Q3Cs Cc: "sacm@ietf.org" , Andrew Malis , "Zarny, Myo" , "Romascanu, Dan \(Dan\)" , Kathleen Moriarty , Shaibal Chakrabarty Subject: [sacm] Summerized differences between SACM and NSaaS X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 22:15:58 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9FDDCdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to David H explanation and especially many thanks to Gunnar Engelbac= h's extended examples for SACM, I summarized the major differences between = SACM and NSaaS: SACM: Security Assessment of End Points: * End points can be routers, switches, clustered DB, installed piece = of software * SACM is about "How to encode that policy in a manner where assessme= nt can be automated" * Examples: - a Solaris 10 SPARC or Window 7 system used in a environment that req= uires adherence to a policy of Mission Critical Classified. - rules like "The maximum password age must be 30 days" and "The minim= um password age must be 1 day" NSaaS: Network Security as a Function: * Protocols for edge devices (e.g. vCPE) or clients to request/query/= verify Security related functions from Network Providers * Firewall * DDOS/Anti-DOS * Access control/Authorization/Authentication * Remote identity management * Secure Key management * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) * Threat detection: Eavesdropping, Trojans, viruses and worms, Malwar= e, etc. * Examples: vCPE needs vFW that are hosted in the network. vCPE provides the "Group Policies" for the vFW, like A can talk to B & C, b= ut B can't talk to C. Please let me know if you have comments/suggestions. Thank you, Linda Dunbar From: Linda Dunbar Sent: Wednesday, July 16, 2014 4:48 PM To: 'David Harrington' Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan); Kathleen Moriarty; Z= arny, Myo; Shaibal Chakrabarty Subject: RE: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? David, Thank you very much for the reply. What NSaaS intends to do is more along the line of BGP: distribute and nego= tiate relevant policies to security functions, and receives supported polic= ies for verification and coordination. So it is quite different from the Data Modeling language, like SNMP or Netc= onf. We can discuss more at Toronto. SACM chairs have allocated a slot for us at= Toronto meeting. Linda From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, July 16, 2014 11:09 AM To: Linda Dunbar Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? Hi Linda, I quickly scanned your draft. It appears to me, as a contributor, that your use cases seem to fit within = the scope of SACM. We are focused on endpoint assessment, but in your use cases, the endpoint = happens to be a virtual endpoint in a virtual network, but an endpoint none= theless. And your use cases discuss assessing the configuration of security function= ality on the virtual endpoint. Your use cases raise some concerns that might be out of scope. Inter-domain correlation would be part of the functionality of the NMS/SMS/= security manager application that is gathering reports of assessments. I think SACM is focused mainly on creating infrastructure for assessing ind= ividual endpoints, so those assessments can be used by applications. The infrastructure for collecting data, storing data, and making the stored= data accessible to applications would seem to be in scope. What the application does with the data would seem to be out of scope. Comparing this to an SNMP ecosystem, the IETF defines a data modeling langu= age, data models, and a protocol for transporting the data. It assumes the = data could be stored for later retrieval. But what an application does with the collected/retrieved MIB data is not w= ithin the scope of the SNMP infrastructure. If the application tries to correlate MIB data across multiple management d= omains, that is not part of the IETF scope. As far as I can see, almost everything in your use cases fits within SACM. David harrington ietfdbh@comcast.net On Jul 8, 2014, at 9:50 AM, Linda Dunbar > wrote: SACM participants: We have a draft on problem and use cases of enabling enterprise (or applic= ations) to request/verify security functions hosted by network providers: h= ttp://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf. We didn't know which IETF area or WG are good fit for the proposed work. Security Area Director Kathleen Moriaty suggests that the proposed work is = somewhat related to SACM. After reading through the SCAM charter, my initial feeling is that SCAM doe= sn't quite fit because SCAM is about the language and data format for "end= point posture assessment". What we proposed is about the mechanism to enab= le Network Security as a Service (NSaaS). I can see the mechanisms provided= by SCAM can be used for some attributes negotiation of NSaaS. But I could be wrong. We are seeking feedback from SACM group, in particular: - If what we propose fits with SACM? - Can the mechanism defined by SACM be used for NSaaS? - Any other thoughts? if it turns out that it is in the SCAM group scope, it is great. If it does= n't, we will see what else can be done. Linda Dunbar _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_4A95BA014132FF49AE685FAB4B9F17F645D9FDDCdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to David H explana= tion and especially many thanks to Gunnar Engelbach’s extended exampl= es for SACM, I summarized the major differences between SACM and NSaaS:

 <= /p>

SACM: Security Assessment of End Points:

• &nbs= p;     End points can be= routers, switches, clustered DB, installed piece of software

• &nbs= p;     SACM is about = 220;How to encode that policy in a manner where assessment can be automated= ”

• &nbs= p;     Examples:

– &nbs= p;    a Solaris 10 SPAR= C or Window 7 system used in a environment that requires adherence to a pol= icy of Mission Critical Classified.

– &nbs= p;    rules like "= The maximum password age must be 30 days" and "The minimum passwo= rd age must be 1 day"

 <= /p>

NSaaS: Network Security as a Function:

• &nbs= p;     Protocols for edg= e devices (e.g. vCPE) or clients to request/query/verify Security related f= unctions from Network Providers

• &nbs= p;     Firewall

• &nbs= p;     DDOS/Anti-DOS

• &nbs= p;     Access control/Au= thorization/Authentication

• &nbs= p;     Remote identity m= anagement

• &nbs= p;     Secure Key manage= ment

• &nbs= p;     Intrusion Detecti= on System/ Intrusion Prevention System (IDS/IPS)

• &nbs= p;     Threat detection:= Eavesdropping, Trojans, viruses and worms, Malware, etc.

• &nbs= p;     Examples:

 <= /p>

Please let me know if you= have comments/suggestions.

 <= /p>

Thank you,

 <= /p>

Linda  Dunbar

 <= /p>

From: Linda Du= nbar
Sent: Wednesday, July 16, 2014 4:48 PM
To: 'David Harrington'
Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan); Kathleen Mori= arty; Zarny, Myo; Shaibal Chakrabarty
Subject: RE: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

David,

 <= /p>

Thank you very much for t= he reply.

 <= /p>

 <= /p>

What NSaaS intends to do = is more along the line of BGP: distribute and negotiate relevant policies t= o security functions, and receives supported policies for verification and coordination.

 <= /p>

So it is quite different = from the Data Modeling language, like SNMP or Netconf.

 <= /p>

We can discuss more at To= ronto. SACM chairs have allocated a slot for us at Toronto meeting.

 <= /p>

Linda

 <= /p>

 <= /p>

From: David Ha= rrington [mailto:ietfdbh@comcast.net= ]
Sent: Wednesday, July 16, 2014 11:09 AM
To: Linda Dunbar
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty<= br> Subject: Re: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

Hi Linda,

 

I quickly scanned your draft.

It appears to me, as a contributor, that your use ca= ses seem to fit within the scope of SACM.

We are focused on endpoint assessment, but in your u= se cases, the endpoint happens to be a virtual endpoint in a virtual networ= k, but an endpoint nonetheless.

And your use cases discuss assessing the configurati= on of security functionality on the virtual endpoint.

 

Your use cases raise some concerns that might be out= of scope.

Inter-domain correlation would be part of the functi= onality of the NMS/SMS/security manager application that is gathering repor= ts of assessments.

I think SACM is focused mainly on creating infrastru= cture for assessing individual endpoints, so those assessments can be used = by applications.

The infrastructure for collecting data, storing data= , and making the stored data accessible to applications would seem to be in= scope.

What the application does with the data would seem t= o be out of scope.

 

Comparing this to an SNMP ecosystem, the IETF define= s a data modeling language, data models, and a protocol for transporting th= e data. It assumes the data could be stored for later retrieval.=

But what an application does with the collected/retr= ieved MIB data is not within the scope of the SNMP infrastructure.

If the application tries to correlate MIB data acros= s multiple management domains, that is not part of the IETF scope.

As far as I can see, almost everything in your use c= ases fits within SACM.

 

David harrington

 

On Jul 8, 2014, at 9:50 AM, Linda Dunbar <linda.dunbar@huawei.com> wrote:<= o:p>

 

SACM participants:

 

We have a draft on proble= m and use cases of enabling  enterprise (or applications) to request/v= erify security functions hosted by network providers: http://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.p= df.

 

We didn’t know whic= h IETF area or WG are good fit for the proposed work.

Security Area Director Ka= thleen Moriaty suggests that the proposed work is somewhat related to SACM.=

After reading through the= SCAM charter, my initial feeling is that SCAM doesn’t quite fit beca= use SCAM is about  the language and data format for “endpoint posture assessment”.  What we pro= posed is about the mechanism to enable Network Security as a Service (NSaaS= ). I can see the mechanisms provided by SCAM can be used for some attribute= s negotiation of NSaaS.

But I could be wrong.

 

We are seeking feedback f= rom SACM group, in particular:

-   = ;      =  If what we propose fits with SACM?

-   = ;      =  Can the mechanism defined by SACM be used for NSaaS?<= /o:p>

-   = ;      =  Any other thoughts?

 

if it turns out that it i= s in the SCAM group scope, it is great. If it doesn’t, we will see wh= at else can be done.

 

Linda Dunbar

 

______________________________________= _________
sacm mailing list
sacm@ietf.org=
https://www.ietf.org/mailman/listinfo/sacm

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D9FDDCdfweml701chmchi_-- From nobody Sun Jul 20 06:14:34 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50F81B2C20 for ; Sun, 20 Jul 2014 06:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 k6t3B0C1GqUa for ; Sun, 20 Jul 2014 06:14:11 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AC11B2C23 for ; Sun, 20 Jul 2014 06:14:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwFADi/y1OHCzIm/2dsb2JhbABZgkcjJFJbrh4BAQEBAQYFnjEBgQUWdoQFAQEDEhteARUVViYBBBsaiCABmxOEXaFEF4V7iR+DZoEYBZcHi1yMcYNEgjE X-IronPort-AV: E=Sophos; i="5.01,695,1400040000"; d="scan'208,217"; a="74604338" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Jul 2014 09:14:10 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 20 Jul 2014 09:14:10 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Sun, 20 Jul 2014 09:14:09 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: important details for the IETF-90 meeting Thread-Index: Ac+kHH0ChbOMreq/RrSd91kmjkr4jQ== Date: Sun, 20 Jul 2014 13:14:09 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C849339@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C849339AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/GSNoN91iTRc_r0wgMqba95vrrr4 Subject: [sacm] important details for the IETF-90 meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 13:14:13 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C849339AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please read and help with these important details for a successful meeting = at IETF-90: 1. Send your presentations early if you own items on the agenda 2. Volunteer for taking notes and scribing on jabber. We need two not= e takers and one jabber scribe in order to start the meeting. Thanks and Regards, The Chairs --_000_9904FB1B0159DA42B0B887B7FA8119CA5C849339AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please read and help with these important details fo= r a successful meeting at IETF-90:

 

1.     &= nbsp; Send your presentations ea= rly if you own items on the agenda

2.     &= nbsp; Volunteer for taking notes= and scribing on jabber. We need two note takers and one jabber scribe in o= rder to start the meeting.

 

Thanks and Regards,

 

The Chairs

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C849339AZFFEXMB04globa_-- From nobody Sun Jul 20 19:45:48 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467011B2A5D for ; Sun, 20 Jul 2014 17:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 bd9UBeGojq5x for ; Sun, 20 Jul 2014 17:11:24 -0700 (PDT) Received: from mxecd07.gs.com (mxe7.gs.com [204.4.178.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3575E1B2A5B for ; Sun, 20 Jul 2014 17:11:22 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,697,1400040000"; d="scan'208,217"; a="54617877" Received: from unknown (HELO mxpcd01-public.ny.fw.gs.com) ([148.86.97.78]) by mxecd07.idz.gs.com with ESMTP; 20 Jul 2014 20:11:20 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshccdp04ex.firmwide.corp.gs.com ([10.135.172.74]) by cd01-mxp-vip-prod.ny.fw.gs.com with ESMTP; 20 Jul 2014 20:11:20 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp04ex.firmwide.corp.gs.com ([10.135.172.74]) with mapi; Sun, 20 Jul 2014 20:11:20 -0400 To: 'Linda Dunbar' , 'David Harrington' Date: Sun, 20 Jul 2014 20:11:18 -0400 Thread-Topic: Summerized differences between SACM and NSaaS Thread-Index: AQHPotXCSD/rh78U9EqZ4q6s0QcW5pupmTdw Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645D94D21@dfweml701-chm.china.huawei.com> <1D8E6F4F-2854-4FCF-BA3D-A1AF22666FBF@comcast.net> <4A95BA014132FF49AE685FAB4B9F17F645D9FDDC@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9FDDC@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23070BE51D1CGSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/YEzC5ZZGhyVnaoRY3-6N1hlej78 X-Mailman-Approved-At: Sun, 20 Jul 2014 19:45:46 -0700 Cc: "'sacm@ietf.org'" , 'Andrew Malis' , "'christian.jacquenet@orange.com'" , "'Romascanu, Dan \(Dan\)'" , 'Kathleen Moriarty' , 'Shaibal Chakrabarty' Subject: Re: [sacm] Summerized differences between SACM and NSaaS X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 00:11:28 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23070BE51D1CGSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I can see why some could consider NSaaS as part of "security automation". A= fter all, NSaaS seeks to define how endpoints can request *network* securit= y services over standard protocols (or APIs), which will facilitate automat= ion. >From what I see, the current SACM charter seems mainly concerned with asses= sing endpoint posture, and how (by what protocols) requisite policies could= be pushed down to the endpoints. I see potential synergies but we'll need to iron out a few differences: * Scope: Security vs. network security services * Goal: Automating endpoint posture assessment vs. defining how ne= twork security services are requested * Security policy enforcement location: Endpoint vs network (and e= ndpoint-network security services could exist on the endpoint itself.) I'd like to add that the need to standardize how services could be requeste= d from the "cloud" goes beyond network security services. We've intentional= ly narrowed down the scope to network security in order not to chew too muc= h at once. (Indeed, one could argue network security itself already is a br= oad field.) On the other hand, we don't want to be too narrow: each IETF WG= solving essentially the same problem over and over in (slightly) different= ways isn't most productive and will create market confusion. I hope we'll = get the right balance here. Regards, From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 18 July 2014 6:15 PM To: David Harrington Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan); Kathleen Moriarty; Z= arny, Myo [Tech]; Shaibal Chakrabarty Subject: Summerized differences between SACM and NSaaS Thanks to David H explanation and especially many thanks to Gunnar Engelbac= h's extended examples for SACM, I summarized the major differences between = SACM and NSaaS: SACM: Security Assessment of End Points: * End points can be routers, switches, clustered DB, installed piece = of software * SACM is about "How to encode that policy in a manner where assessme= nt can be automated" * Examples: - a Solaris 10 SPARC or Window 7 system used in a environment that req= uires adherence to a policy of Mission Critical Classified. - rules like "The maximum password age must be 30 days" and "The minim= um password age must be 1 day" NSaaS: Network Security as a Function: * Protocols for edge devices (e.g. vCPE) or clients to request/query/= verify Security related functions from Network Providers * Firewall * DDOS/Anti-DOS * Access control/Authorization/Authentication * Remote identity management * Secure Key management * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) * Threat detection: Eavesdropping, Trojans, viruses and worms, Malwar= e, etc. * Examples: vCPE needs vFW that are hosted in the network. vCPE provides the "Group Policies" for the vFW, like A can talk to B & C, b= ut B can't talk to C. Please let me know if you have comments/suggestions. Thank you, Linda Dunbar From: Linda Dunbar Sent: Wednesday, July 16, 2014 4:48 PM To: 'David Harrington' Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: RE: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? David, Thank you very much for the reply. What NSaaS intends to do is more along the line of BGP: distribute and nego= tiate relevant policies to security functions, and receives supported polic= ies for verification and coordination. So it is quite different from the Data Modeling language, like SNMP or Netc= onf. We can discuss more at Toronto. SACM chairs have allocated a slot for us at= Toronto meeting. Linda From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, July 16, 2014 11:09 AM To: Linda Dunbar Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? Hi Linda, I quickly scanned your draft. It appears to me, as a contributor, that your use cases seem to fit within = the scope of SACM. We are focused on endpoint assessment, but in your use cases, the endpoint = happens to be a virtual endpoint in a virtual network, but an endpoint none= theless. And your use cases discuss assessing the configuration of security function= ality on the virtual endpoint. Your use cases raise some concerns that might be out of scope. Inter-domain correlation would be part of the functionality of the NMS/SMS/= security manager application that is gathering reports of assessments. I think SACM is focused mainly on creating infrastructure for assessing ind= ividual endpoints, so those assessments can be used by applications. The infrastructure for collecting data, storing data, and making the stored= data accessible to applications would seem to be in scope. What the application does with the data would seem to be out of scope. Comparing this to an SNMP ecosystem, the IETF defines a data modeling langu= age, data models, and a protocol for transporting the data. It assumes the = data could be stored for later retrieval. But what an application does with the collected/retrieved MIB data is not w= ithin the scope of the SNMP infrastructure. If the application tries to correlate MIB data across multiple management d= omains, that is not part of the IETF scope. As far as I can see, almost everything in your use cases fits within SACM. David harrington ietfdbh@comcast.net On Jul 8, 2014, at 9:50 AM, Linda Dunbar > wrote: SACM participants: We have a draft on problem and use cases of enabling enterprise (or applic= ations) to request/verify security functions hosted by network providers: h= ttp://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf. We didn't know which IETF area or WG are good fit for the proposed work. Security Area Director Kathleen Moriaty suggests that the proposed work is = somewhat related to SACM. After reading through the SCAM charter, my initial feeling is that SCAM doe= sn't quite fit because SCAM is about the language and data format for "end= point posture assessment". What we proposed is about the mechanism to enab= le Network Security as a Service (NSaaS). I can see the mechanisms provided= by SCAM can be used for some attributes negotiation of NSaaS. But I could be wrong. We are seeking feedback from SACM group, in particular: - If what we propose fits with SACM? - Can the mechanism defined by SACM be used for NSaaS? - Any other thoughts? if it turns out that it is in the SCAM group scope, it is great. If it does= n't, we will see what else can be done. Linda Dunbar _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_A3233753A4B65F43BCA1B64DA99A9C23070BE51D1CGSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all= ,

 =

I can see why some could consider NSaaS as = part of “security automation”. After all, NSaaS seeks to define= how endpoints can request *network* security services over standard= protocols (or APIs), which will facilitate automation.

 

From what I see, the current SACM charter seems mainly concerned= with assessing endpoint posture, and how (by what protocols) requisite pol= icies could be pushed down to the endpoints.

 

I see potential synergies but we’ll need to iron out a few differenc= es:

= ·   &nbs= p;     Scope:&nbs= p; Security vs. network security services

·         Goal:  Automating endpoint posture assessm= ent vs. defining how network security services are requested

·      &nbs= p;  Security policy enforcement = location:  Endpoint vs network (and endpoint—network security se= rvices could exist on the endpoint itself.)

 

I’d like to add that the need to standardize how services could be r= equested from the “cloud” goes beyond network security services= . We’ve intentionally narrowed down the scope to network security in = order not to chew too much at once. (Indeed, one could argue network securi= ty itself already is a broad field.) On the other hand, we don’t want= to be too narrow: each IETF WG solving essentially the same problem over a= nd over in (slightly) different ways isn’t most productive and will c= reate market confusion. I hope we’ll get the right balance here.=

 

Regards,

 

From: Linda Dunbar [mailto:linda.dunbar@huawei.com] <= br>Sent: 18 July 2014 6:15 PM
To: David Harrington
C= c: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan); Kathleen Moriarty= ; Zarny, Myo [Tech]; Shaibal Chakrabarty
Subject: Summerized diff= erences between SACM and NSaaS

 

Thanks to David H explanation and esp= ecially many thanks to Gunnar Engelbach’s extended examples for SACM,= I summarized the major differences between SACM and NSaaS:

 

SACM= : Security Assessment of End Points:

•<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp; End points can be routers, swit= ches, clustered DB, installed piece of software

•= ;     = ;  SACM is about “How to e= ncode that policy in a manner where assessment can be automated”=

• =       Exam= ples:

–      a= Solaris 10 SPARC or Window 7 system used in a environment that requires ad= herence to a policy of Mission Critical Classified.

<= p class=3DMsoNormal style=3D'margin-left:1.5in;text-indent:-.25in;mso-list:= l1 level2 lfo2'>&= #8211;    =   rules like "The maximum p= assword age must be 30 days" and "The minimum password age must b= e 1 day"

 

NSaaS: Network Security as a Function:<= /o:p>

• &= nbsp;     Protoco= ls for edge devices (e.g. vCPE) or clients to request/query/verify Security= related functions from Network Providers

•     &nbs= p; Firewall

= 226;    &n= bsp;  DDOS/Anti-DOS <= /span>

•  =      Access contr= ol/Authorization/Authentication

•       = Remote identity management=

•   =     Secure Key managem= ent

•Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

• &= nbsp;     Threat = detection: Eavesdropping, Trojans, viruses and worms, Malware, etc.

• &n= bsp;     Examples= :

vCPE needs vFW that are hosted in the network.

vCPE provides the R= 20;Group Policies” for the vFW, like A can talk to B & C, but B c= an’t talk to C.

 

Please let me know if you have comments/sug= gestions.

 

Thank you,

 

Linda  Dunbar

 

From= : Linda Dunbar
Sent: Wednesday, July 16, 2014 4:48 PM
T= o: 'David Harrington'
Cc: sa= cm@ietf.org; Andrew Malis; Romascanu, Dan (Dan); Kathleen Moriarty; Zar= ny, Myo; Shaibal Chakrabarty
Subject: RE: [sacm] Any feedback on = mechanisms of enabling enterprise (or applications) to request/verify virtu= al Security Function from network providers?

 

David,

 

Than= k you very much for the reply.

 

 

What NSaaS intends to do i= s more along the line of BGP: distribute and negotiate relevant policies to= security functions, and receives supported policies for verification and c= oordination.

 

So it is quite different from the Data Modeling lang= uage, like SNMP or Netconf.

 

We can discuss more at Toronto. SACM = chairs have allocated a slot for us at Toronto meeting. <= /p>

 =

Linda

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

From: David Harrington [mailto:ietfdbh@comcast.net]
Sent: Wednesday, July 16= , 2014 11:09 AM
To: Linda Dunbar
Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan); Kathl= een Moriarty; Zarny, Myo; Shaibal Chakrabarty
Subject: Re: [sacm]= Any feedback on mechanisms of enabling enterprise (or applications) to req= uest/verify virtual Security Function from network providers?

&n= bsp;

Hi Linda,

 =

I quic= kly scanned your draft.

It appears to me, as a contributor, that your use cas= es seem to fit within the scope of SACM.

We are focused on endpoint assessme= nt, but in your use cases, the endpoint happens to be a virtual endpoint in= a virtual network, but an endpoint nonetheless.

<= p class=3DMsoNormal style=3D'margin-left:.5in'>And your use cases discuss a= ssessing the configuration of security functionality on the virtual endpoin= t.

 

Your use cases raise some concerns that might be out of scope.

Inter-do= main correlation would be part of the functionality of the NMS/SMS/security= manager application that is gathering reports of assessments.

I think SACM i= s focused mainly on creating infrastructure for assessing individual endpoi= nts, so those assessments can be used by applications.

=

The infrastructure for= collecting data, storing data, and making the stored data accessible to ap= plications would seem to be in scope.

What the application does with the data= would seem to be out of scope.

 

Comparing this to an SNMP ecosystem, the= IETF defines a data modeling language, data models, and a protocol for tra= nsporting the data. It assumes the data could be stored for later retrieval= .

= But what an application does with the collected/retrieved MIB data is not w= ithin the scope of the SNMP infrastructure.

If the application tries to corre= late MIB data across multiple management domains, that is not part of the I= ETF scope.

As far as I can see, almost everything in your use cases fits with= in SACM.

 

David harrington

 

On Jul 8, 2014, at 9:50 AM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

 

<= div>

SACM participants:<= /span>

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>We have a draft on problem and use cases of enabling  enterprise= (or applications) to request/verify security functions hosted by network p= roviders: http://tools.ietf.org/pdf/draft-dunbar= -nsaas-problem-statement-00.pdf.

 

= We didn’t know which IETF area or WG are good fit for the proposed wo= rk.

Security Area Director Kathleen Moriaty suggests that the p= roposed work is somewhat related to SACM.

<= p class=3DMsoNormal style=3D'margin-left:.5in'>After reading through= the SCAM charter, my initial feeling is that SCAM doesn’t quite fit = because SCAM is about  the language and data format for “= endpoin= t posture assessment”.  What we pr= oposed is about the mechanism to enable Network Security as a Service (NSaa= S). I can see the mechanisms provided by SCAM can be used for some attribut= es negotiation of NSaaS.

But I could be wrong.

 

We are seeking feedback from SACM group, in particula= r:

-      = ;    = If what we propose fits with SACM?

-          Can the mechanism defined by = SACM be used for NSaaS?

= -  &n= bsp;       Any other thoughts?

=

 

if it turns out that it is in the SCAM group scope, it is great. If it = doesn’t, we will see what else can be done.

 =

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Linda Dunbar

 

_______________________________________________
sacm m= ailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinf= o/sacm

 

= --_000_A3233753A4B65F43BCA1B64DA99A9C23070BE51D1CGSCMAMP19EXfi_-- From nobody Mon Jul 21 09:18:05 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA8B1A0059 for ; Mon, 21 Jul 2014 09:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 YaeMfUBsjE9K for ; Mon, 21 Jul 2014 09:18:00 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A82F1A002E for ; Mon, 21 Jul 2014 09:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17001; q=dns/txt; s=iport; t=1405959480; x=1407169080; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=n//xJlI3usDoTVE+LuUJEdsF/89PV1YOGX+L30bvZG8=; b=ii1txM3Saqt1QxcHq2KEQmRE33rWK9RidTmeJZ2YvudQVD/iCjSHBgvp 9zTBzpNbP878xJYtMGyPmRId7Zp2/Y/+Jt35m5b13SiZcitg7Y46TyQ0t YA+rKz74rSV2LRj6LWm+4zic737RmvJxjOiQZpA+aiq5dVu16FYrFxDLi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANA8zVOtJA2I/2dsb2JhbABQCYJHR1JbzREBgRoWdoQDAQIELV4BCBEBAgECDRs5FAMGCAIEARIbiCe+PReOcAM0ExgChEQFmyWUL4NEbIEDAh4GHA X-IronPort-AV: E=Sophos; i="5.01,702,1400025600"; d="scan'208,217"; a="62718117" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 21 Jul 2014 16:17:59 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6LGHwAE004829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 16:17:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 11:17:58 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] Comments on draft-camwinget-sacm-architecture-00 Thread-Index: AQHPpP9W7Sf2Yy3IuEi/6e1bilTt7w== Date: Mon, 21 Jul 2014 16:17:58 +0000 Message-ID: In-Reply-To: <46b4400b80014af2a408ec9fe75e20f6@DM2PR09MB0224.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.131] Content-Type: multipart/alternative; boundary="_000_CFF288A1C5584ncamwingciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/tLim2_4OcEGXDblEtPKV26Aansc Subject: Re: [sacm] Comments on draft-camwinget-sacm-architecture-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:18:03 -0000 --_000_CFF288A1C5584ncamwingciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Adam, Further comments below: From: , "David A." > Date: Monday, July 7, 2014 at 12:38 PM To: "sacm@ietf.org" > Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00 After a light read, here are some quick thoughts on the draft-camwinget-sac= m-architecture-00: General: This draft is fairly light on defining the roles of repositories of differe= nt types of security automation data (e.g., guidance, attribute data, proce= ssing artifacts) which can be consumers and providers in their own right. I= don=92t believe these should be handled as part of the control plane, but = should be considered first-class components in the architecture (perhaps as= distinct classes of provider/consumer like collectors and evaluators.) [NCW] Yes, my bad on not providing more details as I was pressed for time i= n putting more content into the draft but I can certainly work on providing= more color. What was the reasoning behind including these components in the control pla= ne? [NCW] The control plane is meant to be an abstraction that handles the secu= rity behind the =93sharing=94 of information as well as the discovery/regis= tration. That is, I believe the group will want to allow for different dat= a models and transports (albeit SACM will define at least one MUST). I bel= ieve the roles will be defined by each of the consumer and the provider, bu= t it is up to the control plane to manage (and =93trust=94 the information = provided by these components). Section 2.1: The draft states =93a Consumer may also desire to obtain the information wi= thout having to know the available providers.=94 I would expect that the consumer, at minimum, should have some way of ident= ifying and authenticating the provider in addition to any authentication se= rvices provided by the control plane. To not do so would leave the system o= pen to a number of security concerns relating to potentially malicious prov= ider or middle box. Having anonymous providers would also prevent the consu= mer from knowing the provenance of the provided data, tracking history from= the same provider, or being able to go back to a given provider to query a= dditional information relative to the first exchange. I don=92t think this = is a workable solution. [NCW] That is one possibility=85..but I think there are cases in which the= re may be several providers (in a very large enterprise, there may be for i= nstance, multiple AAA systems or Posture collector/validators)=85.each of w= hich (in a model where the control plane is distinct, like a broker) could = authenticate to the control plane . This is akin to a pub/sub mechanism. Also, an evaluator is notionally a consumer of collected posture data and a= provider of evaluation results. The notions of collectors and evaluators a= re associated with providers in section 2.2, but not with consumers in sect= ion 2.1. It should also be possible under this architecture to have aggrega= ting collectors and evaluators that request/subscribe and consume collecti= on and evaluation data respectively, and then provide the corresponding agg= regate data based on requests/subscriptions. Another case might be a collec= tor proxy such as an MDM which is a specialized type of provider/consumer. = Some discussion of this general flow should be included in the architectura= l overview (section 2). [NCW] So, this is where I will need to add more text once we get consensus= of the group. Perhaps there is a tier or operations (vs. roles) that an e= ntity can perform: - consume posture information: but within the consumption, there may be re= strictive ways in which the information could be consumed. That is, for so= me use cases, the information provided to the consumer may not include iden= tity information for privacy reasons. - produce posture information: like a consumer, there may be restrictions = in how it can produce the information both due to policy or due to its own = limited set of capabilities So, when an entity =93joins=94, as you state above, it can =93join=94 to c= onsume and produce (or some combination of)=85.but that has to be proven th= rough the authentication/authorization process (which we place in the contr= ol plane). To be able to have the example you describe above. I will need= to add more text around this to clarify, so thanks for raising this. The generalization of providers and consumers is nice, but I am afraid this= will break down when we are considering mandatory to implement for data mo= dels and transports for collectors and evaluators. We may also find that th= ere are more specific requirements for specific types of provider/consumer = interfaces. More thought/discussion is needed here. I=92ll provide more comments once I am able to consider this architecture i= n the context of the information model drafts. Thanks, Dave --_000_CFF288A1C5584ncamwingciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <16E1BEB47F2B6A4D831C2BCDA9CCFE1B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Adam,

Further comments below:

From: <Waltermire>, "Dav= id A." <david.waltermi= re@nist.gov>
Date: Monday, July 7, 2014 at 12:38= PM
To: "sacm@ietf.org" <sacm@i= etf.org>
Subject: [sacm] Comments on draft-c= amwinget-sacm-architecture-00

After a light read, here are some quick thoughts on = the draft-camwinget-sacm-architecture-00:

 

General:

 

This draft is fairly light on defining the roles of = repositories of different types of security automation data (e.g., guidance= , attribute data, processing artifacts) which can be consumers and provider= s in their own right. I don=92t believe these should be handled as part of the control plane, but should be consid= ered first-class components in the architecture (perhaps as distinct classe= s of provider/consumer like collectors and evaluators.)
[NCW] Yes, my bad on not providing more detail= s as I was pressed for time in putting more content into the draft but I ca= n certainly work on providing more color. 

 

What was the reasoning behind including these compon= ents in the control plane?
[N= CW] The control plane is meant to be an abstraction that handles the securi= ty behind the =93sharing=94 of information as well as the discovery/registr= ation.  That is, I believe the group will want to allow for different data models and transports (albeit SACM will d= efine at least one MUST).  I believe the roles will be defined by each= of the consumer and the provider, but it is up to the control plane to man= age (and =93trust=94 the information provided by these components).

 

Section 2.1:

 

The draft states =93a Consumer may also desire to ob= tain the information without

   having to know the available providers.= =94

 

I would expect that the consumer, at minimum, should= have some way of identifying and authenticating the provider in addition t= o any authentication services provided by the control plane. To not do so w= ould leave the system open to a number of security concerns relating to potentially malicious provider or middle = box. Having anonymous providers would also prevent the consumer from knowin= g the provenance of the provided data, tracking history from the same provi= der, or being able to go back to a given provider to query additional information relative to the first exc= hange. I don=92t think this is a workable solution.
[NCW]  That is one possibility=85.= .but I think there are cases in which there may be several providers (in a = very large enterprise, there may be for instance, multiple AAA systems or P= osture collector/validators)=85.each of which (in a model where the control plane is distinct, like a broker) could auth= enticate to the control plane .  This is akin to a pub/sub mechanism.<= /div>

 

Also, an evaluator is notionally a consumer of colle= cted posture data and a provider of evaluation results. The notions of coll= ectors and evaluators are associated with providers in section 2.2, but not= with consumers in section 2.1. It should also be possible under this architecture to have aggregating  = collectors and evaluators that request/subscribe and consume collection and= evaluation data respectively, and then provide the corresponding aggregate= data based on requests/subscriptions. Another case might be a collector proxy such as an MDM which is a speciali= zed type of provider/consumer. Some discussion of this general flow should = be included in the architectural overview (section 2).
[NCW]  So, this is where I will need to a= dd more text once we get consensus of the group.  Perhaps there is a t= ier or operations (vs. roles) that an entity can perform:
 - consume posture information: but withi= n the consumption, there may be restrictive ways in which the information c= ould be consumed.  That is, for some use cases, the information provid= ed to the consumer may not include identity information for privacy reasons.
 - produce posture information: like a co= nsumer, there may be restrictions in how it can produce the information bot= h due to policy or due to its own limited set of capabilities

So, when an entity =93joins=94,  as you s= tate above, it can =93join=94 to consume and produce (or some combination o= f)=85.but that has to be proven through the authentication/authorization pr= ocess (which we place in the control plane).  To be able to have the example you describe above.  I will need to add m= ore text around this to clarify, so thanks for raising this.

 

The generalization of providers and consumers is nic= e, but I am afraid this will break down when we are considering mandatory t= o implement for data models and transports for collectors and evaluators. W= e may also find that there are more specific requirements for specific types of provider/consumer interfaces. = More thought/discussion is needed here.

 

I=92ll provide more comments once I am able to consi= der this architecture in the context of the information model drafts.<= /o:p>

 

Thanks,

Dave

 

 --_000_CFF288A1C5584ncamwingciscocom_-- From nobody Mon Jul 21 09:26:41 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D81A02E3 for ; Mon, 21 Jul 2014 09:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 nEjx475Xa38C for ; Mon, 21 Jul 2014 09:26:35 -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 39D451A02DD for ; Mon, 21 Jul 2014 09:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19786; q=dns/txt; s=iport; t=1405959996; x=1407169596; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=DPLJpcg2VMdR8W6f5uQDW2aYwYBNhwGqCdvvltDUaMQ=; b=muDLRqRPG+BPZnHAuVuL0BOADmp51sri/djx341/DDTCKXU/D2msnwoo 8zNFtNB76zFkByyj5UtxZlP3Os/YPES7U0oX7OMsXU79LOWc9EpeqG39I mtGiFZ7zqbFQS3QIPhh8JruT/ZGWjqny/gQraZ+Gl4mPn9AM9/GToBLyt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHA+zVOtJA2E/2dsb2JhbABQCYJHR1JbzREBgRoWdoQDAQEBBAwhXgEIEQECAQEBDRs5FAMGCAIEARIbiCe+XBeOcDcTFwEChEQFjkOMYpQvg0RsgUU X-IronPort-AV: E=Sophos;i="5.01,702,1400025600"; d="scan'208,217";a="341707045" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jul 2014 16:26:35 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6LGQYTM029008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 16:26:34 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 11:26:33 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] Comments on draft-camwinget-sacm-architecture-00 Thread-Index: AQHPpQCIVVBf5+qTMkO7dFnjBSQ9pA== Date: Mon, 21 Jul 2014 16:26:33 +0000 Message-ID: In-Reply-To: <562088810c2148c3aadd474d359554da@DM2PR09MB0224.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.131] Content-Type: multipart/alternative; boundary="_000_CFF28B4FC55A0ncamwingciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/BHzezcu-YluXF6BH1sxBOPMPmZs Subject: Re: [sacm] Comments on draft-camwinget-sacm-architecture-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:26:37 -0000 --_000_CFF28B4FC55A0ncamwingciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Adam, More below: From: , "David A." > Date: Monday, July 7, 2014 at 2:22 PM To: "Waltermire, David A." >, "sacm@ietf.org" > Subject: Re: [sacm] Comments on draft-camwinget-sacm-architecture-00 A few more questions. Is the use of a broker/proxy a required component of the architecture? If s= o, are there any concerns that this might restrict usage to only large-scal= e enterprise deployments? [NCW] Actually, it was added to address large scale systems :-) But we=92= ll need consensus to determine what is MUST (mandatory to implement) Is it possible for the providers/consumers to implement the broker/proxy in= terfaces directly? In other words, in the most simplistic implementation ca= se, can providers/consumers directly negotiate about tasking/formats withou= t an intermediary? If so, what functions are required for each =93side=94 o= f the communication? [NCW] Yes, it is possible for each entity to provide their own control pla= ne interface. They will need to provide their own (effective AAA services)= , that is the means to authenticate, authorize and manage the consumption o= r production of information for all the subscribers or publishers respectiv= ely. More importantly, they would have to handle the identity and policy m= anagement. Does this approach restrict the use of DNS SRV records [RFC2782] for basic= service discovery (e.g., identifying potential providers or consumers)? [NCW] I do not believe so. Can the providers/consumers work with an existing authorization provider wi= thin the enterprise or does this require a specialized SACM component? [NCW] The intent, especially in defining the control plane is to allow for = SACM to leverage/piggyback the already existing authorization mechanisms (a= s well as authentication mechanisms too) Also, one typo in section 2.3: =93R's may request information independent o= f knowing the identities of the P's and Providers (P's)=94 Is the first =93P=92s=94 a consumer or is this intended to just read =93ide= ntities of the P's=94? [NCW] the P is a Provider. The intent is to state that a Requestor may jus= t want information from the enterprise knowing that the control plane is ha= ndling the authentication and authorization of all the Providers; similarly= an enterprise can set up all the Providers to authenticate directly to the= control plane to publish information without the Providers needing to auth= enticate all the Requestors. Thanks, Dave From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, July 07, 2014 3:39 PM To: sacm@ietf.org Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00 After a light read, here are some quick thoughts on the draft-camwinget-sac= m-architecture-00: General: This draft is fairly light on defining the roles of repositories of differe= nt types of security automation data (e.g., guidance, attribute data, proce= ssing artifacts) which can be consumers and providers in their own right. I= don=92t believe these should be handled as part of the control plane, but = should be considered first-class components in the architecture (perhaps as= distinct classes of provider/consumer like collectors and evaluators.) What was the reasoning behind including these components in the control pla= ne? Section 2.1: The draft states =93a Consumer may also desire to obtain the information wi= thout having to know the available providers.=94 I would expect that the consumer, at minimum, should have some way of ident= ifying and authenticating the provider in addition to any authentication se= rvices provided by the control plane. To not do so would leave the system o= pen to a number of security concerns relating to potentially malicious prov= ider or middle box. Having anonymous providers would also prevent the consu= mer from knowing the provenance of the provided data, tracking history from= the same provider, or being able to go back to a given provider to query a= dditional information relative to the first exchange. I don=92t think this = is a workable solution. Also, an evaluator is notionally a consumer of collected posture data and a= provider of evaluation results. The notions of collectors and evaluators a= re associated with providers in section 2.2, but not with consumers in sect= ion 2.1. It should also be possible under this architecture to have aggrega= ting collectors and evaluators that request/subscribe and consume collecti= on and evaluation data respectively, and then provide the corresponding agg= regate data based on requests/subscriptions. Another case might be a collec= tor proxy such as an MDM which is a specialized type of provider/consumer. = Some discussion of this general flow should be included in the architectura= l overview (section 2). The generalization of providers and consumers is nice, but I am afraid this= will break down when we are considering mandatory to implement for data mo= dels and transports for collectors and evaluators. We may also find that th= ere are more specific requirements for specific types of provider/consumer = interfaces. More thought/discussion is needed here. I=92ll provide more comments once I am able to consider this architecture i= n the context of the information model drafts. Thanks, Dave --_000_CFF28B4FC55A0ncamwingciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4D9D277017DAD146B1461BBB8CCBABA2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Adam,

More below:

From: <Waltermire>, "Dav= id A." <david.waltermi= re@nist.gov>
Date: Monday, July 7, 2014 at 2:22 = PM
To: "Waltermire, David A."= ; <david.waltermire@nist.go= v>, "sacm@ietf.org" &= lt;sacm@ietf.org>
Subject: Re: [sacm] Comments on dra= ft-camwinget-sacm-architecture-00

A few more questions.<= o:p>

 

Is the use of a broker= /proxy a required component of the architecture? If so, are there any conce= rns that this might restrict usage to only large-scale enterprise deploymen= ts?
[NCW]  Actually, it was added to address large scale systems :-) =  But we=92ll need consensus to determine what is MUST (mandatory to im= plement)

Is it possible for the= providers/consumers to implement the broker/proxy interfaces directly? In = other words, in the most simplistic implementation case, can providers/cons= umers directly negotiate about tasking/formats without an intermediary? If so, what functions are required for each =93si= de=94 of the communication?
[NCW]  Yes, it is possible for each entity to provide their own c= ontrol plane interface.  They will need to provide their own (effectiv= e AAA services), that is the means to authenticate, authorize and manage th= e consumption or production of information for all the subscribers or publishers respectively.  More importantly= , they would have to handle the identity and policy management.

Does this approach res= trict the use of DNS SRV records  [RFC2782] for basic service discover= y (e.g., identifying potential providers or consumers)?
[NCW] I do not believe so.

Can the providers/cons= umers work with an existing authorization provider within the enterprise or= does this require a specialized SACM component?
[NCW] The intent, especially in defining the control plane is to allow= for SACM to leverage/piggyback the already existing authorization mechanis= ms (as well as authentication mechanisms too)

 

Also, one typo in sect= ion 2.3: =93R's may request information independent of knowing the identiti= es of the P's and Providers (P's)=94

 

Is the first =93P=92s= =94 a consumer or is this intended to just read =93identities of the P's=94= ?
[NCW] the P is a Provider.  The intent is to state that a Request= or may just want information from the enterprise knowing that the control p= lane is handling the authentication and authorization of all the Providers;= similarly an enterprise can set up all the Providers to authenticate directly to the control plane to publish inf= ormation without the Providers needing to authenticate all the Requestors. =  

 

Thanks,

Dave=

 

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A.
Sent: Monday, July 07, 2014 3:39 PM
To: sacm@ietf.org
Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00

 

After a light read, here are some quick thoughts on = the draft-camwinget-sacm-architecture-00:

 

General:

 

This draft is fairly light on defining the roles of = repositories of different types of security automation data (e.g., guidance= , attribute data, processing artifacts) which can be consumers and provider= s in their own right. I don=92t believe these should be handled as part of the control plane, but should be consid= ered first-class components in the architecture (perhaps as distinct classe= s of provider/consumer like collectors and evaluators.)

 

What was the reasoning behind including these compon= ents in the control plane?

 

Section 2.1:

 

The draft states =93a Consumer may also desire to ob= tain the information without

   having to know the available providers.= =94

 

I would expect that the consumer, at minimum, should= have some way of identifying and authenticating the provider in addition t= o any authentication services provided by the control plane. To not do so w= ould leave the system open to a number of security concerns relating to potentially malicious provider or middle = box. Having anonymous providers would also prevent the consumer from knowin= g the provenance of the provided data, tracking history from the same provi= der, or being able to go back to a given provider to query additional information relative to the first exc= hange. I don=92t think this is a workable solution.

 

Also, an evaluator is notionally a consumer of colle= cted posture data and a provider of evaluation results. The notions of coll= ectors and evaluators are associated with providers in section 2.2, but not= with consumers in section 2.1. It should also be possible under this architecture to have aggregating  = collectors and evaluators that request/subscribe and consume collection and= evaluation data respectively, and then provide the corresponding aggregate= data based on requests/subscriptions. Another case might be a collector proxy such as an MDM which is a speciali= zed type of provider/consumer. Some discussion of this general flow should = be included in the architectural overview (section 2).

 

The generalization of providers and consumers is nic= e, but I am afraid this will break down when we are considering mandatory t= o implement for data models and transports for collectors and evaluators. W= e may also find that there are more specific requirements for specific types of provider/consumer interfaces. = More thought/discussion is needed here.

 

I=92ll provide more comments once I am able to consi= der this architecture in the context of the information model drafts.<= /o:p>

 

Thanks,

Dave

 

 --_000_CFF28B4FC55A0ncamwingciscocom_-- From nobody Mon Jul 21 09:34:42 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D721A031D; Mon, 21 Jul 2014 09:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Ut24-wnD_OtR; Mon, 21 Jul 2014 09:34:37 -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 CCE871A00FA; Mon, 21 Jul 2014 09:34:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKJ45581; Mon, 21 Jul 2014 16:34:34 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Jul 2014 17:34:32 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Mon, 21 Jul 2014 09:34:23 -0700 From: Linda Dunbar To: "sacm@ietf.org" , "saag@ietf.org" Thread-Topic: Informal Gathering to discuss NSaaS (a.k.a Bar BoF) Thread-Index: AQHPpQGhcbj+vFVvcEWI5kv4slmd9A== Date: Mon, 21 Jul 2014 16:34:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DA0DE9@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.168] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DA0DE9dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/kCZAmJb3Ca8jOsc1nJ9D2rcKipM Cc: "Zarny, Myo" , "'christian.jacquenet@orange.com'" , 'Shaibal Chakrabarty' Subject: [sacm] Informal Gathering to discuss NSaaS (a.k.a Bar BoF) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:34:41 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645DA0DE9dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We will have an informal gathering (a.k.a. Bar BOF) at New Brunswick room T= hurs at 8:30pm to discuss NSaaS. The purpose of this meeting is to collect comments and requirements from se= rvice providers to see there is justification for a full BOF at IETF 91. For this purpose I have invited Vodafone, DT, Cable Lab, Verizon, and Telef= onica to attend this informal gathering. Cheers, Linda From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Sent: Sunday, July 20, 2014 7:11 PM To: Linda Dunbar; 'David Harrington' Cc: 'sacm@ietf.org'; Andrew Malis; 'Romascanu, Dan (Dan)'; 'Kathleen Moriar= ty'; 'Shaibal Chakrabarty'; 'christian.jacquenet@orange.com' Subject: RE: Summerized differences between SACM and NSaaS Hello all, I can see why some could consider NSaaS as part of "security automation". A= fter all, NSaaS seeks to define how endpoints can request *network* securit= y services over standard protocols (or APIs), which will facilitate automat= ion. >From what I see, the current SACM charter seems mainly concerned with asses= sing endpoint posture, and how (by what protocols) requisite policies could= be pushed down to the endpoints. I see potential synergies but we'll need to iron out a few differences: * Scope: Security vs. network security services * Goal: Automating endpoint posture assessment vs. defining how netw= ork security services are requested * Security policy enforcement location: Endpoint vs network (and end= point-network security services could exist on the endpoint itself.) I'd like to add that the need to standardize how services could be requeste= d from the "cloud" goes beyond network security services. We've intentional= ly narrowed down the scope to network security in order not to chew too muc= h at once. (Indeed, one could argue network security itself already is a br= oad field.) On the other hand, we don't want to be too narrow: each IETF WG= solving essentially the same problem over and over in (slightly) different= ways isn't most productive and will create market confusion. I hope we'll = get the right balance here. Regards, From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 18 July 2014 6:15 PM To: David Harrington Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo [Tech]; Shaibal Chakrabarty Subject: Summerized differences between SACM and NSaaS Thanks to David H explanation and especially many thanks to Gunnar Engelbac= h's extended examples for SACM, I summarized the major differences between = SACM and NSaaS: SACM: Security Assessment of End Points: * End points can be routers, switches, clustered DB, installed piece = of software * SACM is about "How to encode that policy in a manner where assessme= nt can be automated" * Examples: - a Solaris 10 SPARC or Window 7 system used in a environment that req= uires adherence to a policy of Mission Critical Classified. - rules like "The maximum password age must be 30 days" and "The minim= um password age must be 1 day" NSaaS: Network Security as a Function: * Protocols for edge devices (e.g. vCPE) or clients to request/query/= verify Security related functions from Network Providers * Firewall * DDOS/Anti-DOS * Access control/Authorization/Authentication * Remote identity management * Secure Key management * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) * Threat detection: Eavesdropping, Trojans, viruses and worms, Malwar= e, etc. * Examples: vCPE needs vFW that are hosted in the network. vCPE provides the "Group Policies" for the vFW, like A can talk to B & C, b= ut B can't talk to C. Please let me know if you have comments/suggestions. Thank you, Linda Dunbar From: Linda Dunbar Sent: Wednesday, July 16, 2014 4:48 PM To: 'David Harrington' Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: RE: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? David, Thank you very much for the reply. What NSaaS intends to do is more along the line of BGP: distribute and nego= tiate relevant policies to security functions, and receives supported polic= ies for verification and coordination. So it is quite different from the Data Modeling language, like SNMP or Netc= onf. We can discuss more at Toronto. SACM chairs have allocated a slot for us at= Toronto meeting. Linda From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, July 16, 2014 11:09 AM To: Linda Dunbar Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? Hi Linda, I quickly scanned your draft. It appears to me, as a contributor, that your use cases seem to fit within = the scope of SACM. We are focused on endpoint assessment, but in your use cases, the endpoint = happens to be a virtual endpoint in a virtual network, but an endpoint none= theless. And your use cases discuss assessing the configuration of security function= ality on the virtual endpoint. Your use cases raise some concerns that might be out of scope. Inter-domain correlation would be part of the functionality of the NMS/SMS/= security manager application that is gathering reports of assessments. I think SACM is focused mainly on creating infrastructure for assessing ind= ividual endpoints, so those assessments can be used by applications. The infrastructure for collecting data, storing data, and making the stored= data accessible to applications would seem to be in scope. What the application does with the data would seem to be out of scope. Comparing this to an SNMP ecosystem, the IETF defines a data modeling langu= age, data models, and a protocol for transporting the data. It assumes the = data could be stored for later retrieval. But what an application does with the collected/retrieved MIB data is not w= ithin the scope of the SNMP infrastructure. If the application tries to correlate MIB data across multiple management d= omains, that is not part of the IETF scope. As far as I can see, almost everything in your use cases fits within SACM. David harrington ietfdbh@comcast.net On Jul 8, 2014, at 9:50 AM, Linda Dunbar > wrote: SACM participants: We have a draft on problem and use cases of enabling enterprise (or applic= ations) to request/verify security functions hosted by network providers: h= ttp://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf. We didn't know which IETF area or WG are good fit for the proposed work. Security Area Director Kathleen Moriaty suggests that the proposed work is = somewhat related to SACM. After reading through the SCAM charter, my initial feeling is that SCAM doe= sn't quite fit because SCAM is about the language and data format for "end= point posture assessment". What we proposed is about the mechanism to enab= le Network Security as a Service (NSaaS). I can see the mechanisms provided= by SCAM can be used for some attributes negotiation of NSaaS. But I could be wrong. We are seeking feedback from SACM group, in particular: - If what we propose fits with SACM? - Can the mechanism defined by SACM be used for NSaaS? - Any other thoughts? if it turns out that it is in the SCAM group scope, it is great. If it does= n't, we will see what else can be done. Linda Dunbar _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_4A95BA014132FF49AE685FAB4B9F17F645DA0DE9dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We will have an informal gathering (a.k.a. Bar BOF) = at New Brunswick room Thurs at 8:30pm to discuss NSaaS.

 

The purpose of this meeting is to collect comments a= nd requirements from service providers to see there is justification for a = full BOF at IETF 91.

For this purpose I have invited Vodafone, DT, Cable = Lab, Verizon, and Telefonica to attend this informal gathering.

 

Cheers,

 

Linda

 

 <= /p>

 <= /p>

From: Zarny, M= yo [mailto:Myo.Zarny@gs.com]
Sent: Sunday, July 20, 2014 7:11 PM
To: Linda Dunbar; 'David Harrington'
Cc: 'sacm@ietf.org'; Andrew Malis; 'Romascanu, Dan (Dan)'; 'Kathleen= Moriarty'; 'Shaibal Chakrabarty'; 'christian.jacquenet@orange.com'
Subject: RE: Summerized differences between SACM and NSaaS

 

Hello all,

 <= /p>

I can see why some could = consider NSaaS as part of “security automation”. After all, NSa= aS seeks to define how endpoints can request *network* security services over standard protocols (or APIs), which will facilitate automati= on.

 <= /p>

From what I see, the curr= ent SACM charter seems mainly concerned with assessing endpoint posture, an= d how (by what protocols) requisite policies could be pushed down to the endpoints.

 <= /p>

I see potential synergies= but we’ll need to iron out a few differences:

·      = ; Scope:  Secu= rity vs. network security services

·      = ; Goal:  Autom= ating endpoint posture assessment vs. defining how network security service= s are requested

·      = ; Security policy e= nforcement location:  Endpoint vs network (and endpoint—network = security services could exist on the endpoint itself.)

 <= /p>

I’d like to add tha= t the need to standardize how services could be requested from the “c= loud” goes beyond network security services. We’ve intentionall= y narrowed down the scope to network security in order not to chew too much at once. = (Indeed, one could argue network security itself already is a broad field.)= On the other hand, we don’t want to be too narrow: each IETF WG solv= ing essentially the same problem over and over in (slightly) different ways isn’t most productive and will= create market confusion. I hope we’ll get the right balance here.

 <= /p>

Regards,

 <= /p>

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: 18 July 2014 6:15 PM
To: David Harrington
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo [Tech]; Shaibal Chakr= abarty
Subject: Summerized differences between SACM and NSaaS

 

• &nbs= p;     End points can be= routers, switches, clustered DB, installed piece of software

• &nbs= p;     SACM is about = 220;How to encode that policy in a manner where assessment can be automated= ”

• &nbs= p;     Examples:

– &nbs= p;    a Solaris 10 SPAR= C or Window 7 system used in a environment that requires adherence to a pol= icy of Mission Critical Classified.

– &nbs= p;    rules like "= The maximum password age must be 30 days" and "The minimum passwo= rd age must be 1 day"

• &nbs= p;     Protocols for edg= e devices (e.g. vCPE) or clients to request/query/verify Security related f= unctions from Network Providers

• &nbs= p;     Firewall

• &nbs= p;     DDOS/Anti-DOS

• &nbs= p;     Access control/Au= thorization/Authentication

• &nbs= p;     Remote identity m= anagement

• &nbs= p;     Secure Key manage= ment

• &nbs= p;     Intrusion Detecti= on System/ Intrusion Prevention System (IDS/IPS)

• &nbs= p;     Threat detection:= Eavesdropping, Trojans, viruses and worms, Malware, etc.

• &nbs= p;     Examples:

vCPE needs vFW that are hosted in the network.

vCPE provides the “Group Policies” for the vFW, like A can t= alk to B & C, but B can’t talk to C.

From: Linda Dunbar
Sent: Wednesday, July 16, 2014 4:48 PM
To: 'David Harrington'
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty<= br> Subject: RE: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

From: David Harrington [mailto:ietfdbh@comcast.net]
Sent: Wednesday, July 16, 2014 11:09 AM
To: Linda Dunbar
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty<= br> Subject: Re: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

Hi Linda,

 

I quickly scanned your dr= aft.

It appears to me, as a co= ntributor, that your use cases seem to fit within the scope of SACM.

We are focused on endpoin= t assessment, but in your use cases, the endpoint happens to be a virtual e= ndpoint in a virtual network, but an endpoint nonetheless.

And your use cases discus= s assessing the configuration of security functionality on the virtual endp= oint.

 

Your use cases raise some= concerns that might be out of scope.

Inter-domain correlation = would be part of the functionality of the NMS/SMS/security manager applicat= ion that is gathering reports of assessments.

I think SACM is focused m= ainly on creating infrastructure for assessing individual endpoints, so tho= se assessments can be used by applications.

The infrastructure for co= llecting data, storing data, and making the stored data accessible to appli= cations would seem to be in scope.

What the application does= with the data would seem to be out of scope.

 

Comparing this to an SNMP= ecosystem, the IETF defines a data modeling language, data models, and a p= rotocol for transporting the data. It assumes the data could be stored for = later retrieval.

But what an application d= oes with the collected/retrieved MIB data is not within the scope of the SN= MP infrastructure.

If the application tries = to correlate MIB data across multiple management domains, that is not part = of the IETF scope.

As far as I can see, almo= st everything in your use cases fits within SACM.

 

David harrington

 

On Jul 8, 2014, at 9:50 A= M, Linda Dunbar <linda.dunbar= @huawei.com> wrote:

 

SACM partici= pants:

 <= /o:p>

endpoint posture assessment”. =  What we proposed is about the mechanism= to enable Network Security as a Service (NSaaS). I can see the mechanisms provided by SCAM can be used for some attributes negotiation of NSaaS.

-=           If what we propose fits with SACM?

-=           Can the mechanism defined by SACM be used for NSaaS?<= /o:p>

-=           Any other thoughts?

 <= /o:p>

___________= ____________________________________
sacm mailing list
sacm@ietf.org=
https://www.ietf.org/mailman/listinfo/sacm

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645DA0DE9dfweml701chmchi_-- From nobody Mon Jul 21 11:19:51 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ABB1A0354; Mon, 21 Jul 2014 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 weNY5gUT7CRz; Mon, 21 Jul 2014 11:19:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496BD1A0350; Mon, 21 Jul 2014 11:19:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkHAPFYzVOHCzIm/2dsb2JhbABQCYJHIyQfM1uuUgEBBpURgT8YAQmHRQGBHRZ2hAMBAQEBAQIBAQELBBs4CQQHEAIBCA0EBAEBCw4IAQYHJwsUCQgCBAENBQgaiAwDEQEMnRaaLwiHCReCYYMaiHUqLQQGARiCHw9EJIEYBY5DiESFa4VxjHGDRGwBgUQ X-IronPort-AV: E=Sophos; i="5.01,702,1400040000"; d="scan'208,217"; a="74746598" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Jul 2014 14:19:39 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 21 Jul 2014 14:19:38 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 21 Jul 2014 20:19:37 +0200 From: "Romascanu, Dan (Dan)" To: Linda Dunbar , "sacm@ietf.org" , "saag@ietf.org" Thread-Topic: Informal Gathering to discuss NSaaS (a.k.a Bar BoF) Thread-Index: AQHPpQGhcbj+vFVvcEWI5kv4slmd9Juq1hJg Date: Mon, 21 Jul 2014 18:19:37 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C84CF10@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA0DE9@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DA0DE9@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C84CF10AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/dGZCrapZ8cmyeljOGvXwAmhKIBw Cc: "Zarny, Myo" , 'Shaibal Chakrabarty' , "'christian.jacquenet@orange.com'" Subject: Re: [sacm] Informal Gathering to discuss NSaaS (a.k.a Bar BoF) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:19:47 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C84CF10AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the announcement, Linda. I encourage all interested SACM partici= pants to attend. We shall also make some room on the second SACM session on= Friday morning to discuss the outcome of the Bar BoF and relationship with= SACM. Regards, Dan From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, July 21, 2014 7:34 PM To: sacm@ietf.org; saag@ietf.org Cc: Zarny, Myo; 'christian.jacquenet@orange.com'; 'Shaibal Chakrabarty' Subject: [sacm] Informal Gathering to discuss NSaaS (a.k.a Bar BoF) We will have an informal gathering (a.k.a. Bar BOF) at New Brunswick room T= hurs at 8:30pm to discuss NSaaS. The purpose of this meeting is to collect comments and requirements from se= rvice providers to see there is justification for a full BOF at IETF 91. For this purpose I have invited Vodafone, DT, Cable Lab, Verizon, and Telef= onica to attend this informal gathering. Cheers, Linda From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Sent: Sunday, July 20, 2014 7:11 PM To: Linda Dunbar; 'David Harrington' Cc: 'sacm@ietf.org'; Andrew Malis; 'Romascanu, Dan (Dan)'; 'Kathleen Moriar= ty'; 'Shaibal Chakrabarty'; 'christian.jacquenet@orange.com' Subject: RE: Summerized differences between SACM and NSaaS Hello all, I can see why some could consider NSaaS as part of "security automation". A= fter all, NSaaS seeks to define how endpoints can request *network* securit= y services over standard protocols (or APIs), which will facilitate automat= ion. >From what I see, the current SACM charter seems mainly concerned with asses= sing endpoint posture, and how (by what protocols) requisite policies could= be pushed down to the endpoints. I see potential synergies but we'll need to iron out a few differences: * Scope: Security vs. network security services * Goal: Automating endpoint posture assessment vs. defining how ne= twork security services are requested * Security policy enforcement location: Endpoint vs network (and e= ndpoint-network security services could exist on the endpoint itself.) I'd like to add that the need to standardize how services could be requeste= d from the "cloud" goes beyond network security services. We've intentional= ly narrowed down the scope to network security in order not to chew too muc= h at once. (Indeed, one could argue network security itself already is a br= oad field.) On the other hand, we don't want to be too narrow: each IETF WG= solving essentially the same problem over and over in (slightly) different= ways isn't most productive and will create market confusion. I hope we'll = get the right balance here. Regards, From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 18 July 2014 6:15 PM To: David Harrington Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo [Tech]; Shaibal Chakrabarty Subject: Summerized differences between SACM and NSaaS Thanks to David H explanation and especially many thanks to Gunnar Engelbac= h's extended examples for SACM, I summarized the major differences between = SACM and NSaaS: SACM: Security Assessment of End Points: * End points can be routers, switches, clustered DB, installed piece = of software * SACM is about "How to encode that policy in a manner where assessme= nt can be automated" * Examples: - a Solaris 10 SPARC or Window 7 system used in a environment that req= uires adherence to a policy of Mission Critical Classified. - rules like "The maximum password age must be 30 days" and "The minim= um password age must be 1 day" NSaaS: Network Security as a Function: * Protocols for edge devices (e.g. vCPE) or clients to request/query/= verify Security related functions from Network Providers * Firewall * DDOS/Anti-DOS * Access control/Authorization/Authentication * Remote identity management * Secure Key management * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) * Threat detection: Eavesdropping, Trojans, viruses and worms, Malwar= e, etc. * Examples: vCPE needs vFW that are hosted in the network. vCPE provides the "Group Policies" for the vFW, like A can talk to B & C, b= ut B can't talk to C. Please let me know if you have comments/suggestions. Thank you, Linda Dunbar From: Linda Dunbar Sent: Wednesday, July 16, 2014 4:48 PM To: 'David Harrington' Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: RE: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? David, Thank you very much for the reply. What NSaaS intends to do is more along the line of BGP: distribute and nego= tiate relevant policies to security functions, and receives supported polic= ies for verification and coordination. So it is quite different from the Data Modeling language, like SNMP or Netc= onf. We can discuss more at Toronto. SACM chairs have allocated a slot for us at= Toronto meeting. Linda From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, July 16, 2014 11:09 AM To: Linda Dunbar Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? Hi Linda, I quickly scanned your draft. It appears to me, as a contributor, that your use cases seem to fit within = the scope of SACM. We are focused on endpoint assessment, but in your use cases, the endpoint = happens to be a virtual endpoint in a virtual network, but an endpoint none= theless. And your use cases discuss assessing the configuration of security function= ality on the virtual endpoint. Your use cases raise some concerns that might be out of scope. Inter-domain correlation would be part of the functionality of the NMS/SMS/= security manager application that is gathering reports of assessments. I think SACM is focused mainly on creating infrastructure for assessing ind= ividual endpoints, so those assessments can be used by applications. The infrastructure for collecting data, storing data, and making the stored= data accessible to applications would seem to be in scope. What the application does with the data would seem to be out of scope. Comparing this to an SNMP ecosystem, the IETF defines a data modeling langu= age, data models, and a protocol for transporting the data. It assumes the = data could be stored for later retrieval. But what an application does with the collected/retrieved MIB data is not w= ithin the scope of the SNMP infrastructure. If the application tries to correlate MIB data across multiple management d= omains, that is not part of the IETF scope. As far as I can see, almost everything in your use cases fits within SACM. David harrington ietfdbh@comcast.net On Jul 8, 2014, at 9:50 AM, Linda Dunbar > wrote: SACM participants: We have a draft on problem and use cases of enabling enterprise (or applic= ations) to request/verify security functions hosted by network providers: h= ttp://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf. We didn't know which IETF area or WG are good fit for the proposed work. Security Area Director Kathleen Moriaty suggests that the proposed work is = somewhat related to SACM. After reading through the SCAM charter, my initial feeling is that SCAM doe= sn't quite fit because SCAM is about the language and data format for "end= point posture assessment". What we proposed is about the mechanism to enab= le Network Security as a Service (NSaaS). I can see the mechanisms provided= by SCAM can be used for some attributes negotiation of NSaaS. But I could be wrong. We are seeking feedback from SACM group, in particular: - If what we propose fits with SACM? - Can the mechanism defined by SACM be used for NSaaS? - Any other thoughts? if it turns out that it is in the SCAM group scope, it is great. If it does= n't, we will see what else can be done. Linda Dunbar _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_9904FB1B0159DA42B0B887B7FA8119CA5C84CF10AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the announceme= nt, Linda. I encourage all interested SACM participants to attend. We shall= also make some room on the second SACM session on Friday morning to discuss the outcome of the Bar BoF and relationship with SACM. =

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, July 21, 2014 7:34 PM
To: sacm@ietf.org; saag@ietf.org
Cc: Zarny, Myo; 'christian.jacquenet@orange.com'; 'Shaibal Chakrabar= ty'
Subject: [sacm] Informal Gathering to discuss NSaaS (a.k.a Bar BoF)<= o:p>

 

We will have an informal gathering (a.k.a. Bar BOF) = at New Brunswick room Thurs at 8:30pm to discuss NSaaS.

 

The purpose of this meeting is to collect comments a= nd requirements from service providers to see there is justification for a = full BOF at IETF 91.

For this purpose I have invited Vodafone, DT, Cable = Lab, Verizon, and Telefonica to attend this informal gathering.

 

Cheers,

 

Linda

 

 <= /p>

 <= /p>

From: Zarny, M= yo [mailto:Myo.Zarny@gs.com]
Sent: Sunday, July 20, 2014 7:11 PM
To: Linda Dunbar; 'David Harrington'
Cc: 'sacm@ietf.org'; Andrew Malis; 'Romascanu, Dan (Dan)'; 'Kathleen= Moriarty'; 'Shaibal Chakrabarty'; 'christian.jacquenet@orange.com'
Subject: RE: Summerized differences between SACM and NSaaS

 

Hello all,

 <= /p>

I can see why some could = consider NSaaS as part of “security automation”. After all, NSa= aS seeks to define how endpoints can request *network* security services over standard protocols (or APIs), which will facilitate automati= on.

 <= /p>

From what I see, the curr= ent SACM charter seems mainly concerned with assessing endpoint posture, an= d how (by what protocols) requisite policies could be pushed down to the endpoints.

 <= /p>

I see potential synergies= but we’ll need to iron out a few differences:

·     &nbs= p;   Scope:  Security vs. network security services

·     &nbs= p;   Goal:  Automating endpoint posture assessment vs. defining how= network security services are requested

·     &nbs= p;   Security policy enforcement location:  Endpoint vs network (an= d endpoint—network security services could exist on the endpoint itself.)

 <= /p>

I’d like to add tha= t the need to standardize how services could be requested from the “c= loud” goes beyond network security services. We’ve intentionall= y narrowed down the scope to network security in order not to chew too much at once. = (Indeed, one could argue network security itself already is a broad field.)= On the other hand, we don’t want to be too narrow: each IETF WG solv= ing essentially the same problem over and over in (slightly) different ways isn’t most productive and will= create market confusion. I hope we’ll get the right balance here.

 <= /p>

Regards,

 <= /p>

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: 18 July 2014 6:15 PM
To: David Harrington
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo [Tech]; Shaibal Chakr= abarty
Subject: Summerized differences between SACM and NSaaS

 

Thanks to David H explanation and especially many thanks to Gunnar Enge= lbach’s extended examples for SACM, I summarized the major differences between SACM and NSaaS:

 

SACM: Security Assessment of End Points:

• &nbs= p;     End points can be routers, switches, clustered DB, installed piece = of software

• &nbs= p;     SACM is about “How to encode that policy in a manner where as= sessment can be automated”

• &nbs= p;     Examples:

– &nbs= p;    a Solaris 10 SPARC or Window 7 system used in a environment that re= quires adherence to a policy of Mission Critical Classified.

– &nbs= p;    rules like "The maximum password age must be 30 days" and= "The minimum password age must be 1 day"

 

NSaaS: Network Security as a Function:

• &nbs= p;     Protocols for edge devices (e.g. vCPE) or clients to request/query/= verify Security related functions from Network Providers<= /p>

• &nbs= p;     Firewall

• &nbs= p;     DDOS/Anti-DOS

• &nbs= p;     Access control/Authorization/Authentication

• &nbs= p;     Remote identity management

• &nbs= p;     Secure Key management

• &nbs= p;     Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

• &nbs= p;     Threat detection: Eavesdropping, Trojans, viruses and worms, Malwar= e, etc.

• &nbs= p;     Examples:

vCPE needs vFW that are hosted in the network.

vCPE provides the “Group Policies” for the vFW, like A can = talk to B & C, but B can’t talk to C.

 

Please let me know if you have comments/suggestions.

 

Thank you,

 

Linda  Dunbar

 

From: Linda Dunbar
Sent: Wednesday, July 16, 2014 4:48 PM
To: 'David Harrington'
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty<= br> Subject: RE: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

David,

 

Thank you very much for the reply.

 

 

What NSaaS intends to do is more along the line of BGP: distribute and = negotiate relevant policies to security functions, and receives supported policies for verification and coordination.

 

So it is quite different from the Data Modeling language, like SNMP or = Netconf.

 

We can discuss more at Toronto. SACM chairs have allocated a slot for u= s at Toronto meeting.

 

Linda

 

 

From: David Harrington [mailto:ietfdbh@comcast.net]
Sent: Wednesday, July 16, 2014 11:09 AM
To: Linda Dunbar
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty<= br> Subject: Re: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

Hi Linda,

 

I quickly scanned your = draft.

It appears to me, as a = contributor, that your use cases seem to fit within the scope of SACM.=

We are focused on endpo= int assessment, but in your use cases, the endpoint happens to be a virtual= endpoint in a virtual network, but an endpoint nonetheless.

And your use cases disc= uss assessing the configuration of security functionality on the virtual en= dpoint.

 

Your use cases raise so= me concerns that might be out of scope.

Inter-domain correlatio= n would be part of the functionality of the NMS/SMS/security manager applic= ation that is gathering reports of assessments.

I think SACM is focused= mainly on creating infrastructure for assessing individual endpoints, so t= hose assessments can be used by applications.

The infrastructure for = collecting data, storing data, and making the stored data accessible to app= lications would seem to be in scope.

What the application do= es with the data would seem to be out of scope.

 

Comparing this to an SN= MP ecosystem, the IETF defines a data modeling language, data models, and a= protocol for transporting the data. It assumes the data could be stored fo= r later retrieval.

But what an application= does with the collected/retrieved MIB data is not within the scope of the = SNMP infrastructure.

If the application trie= s to correlate MIB data across multiple management domains, that is not par= t of the IETF scope.

As far as I can see, al= most everything in your use cases fits within SACM.

 

David harrington

 

On Jul 8, 2014, at 9:50= AM, Linda Dunbar <linda.dunb= ar@huawei.com> wrote:

 

SACM parti= cipants:

 

We have a draft on problem and use cases of enabling  enterprise (= or applications) to request/verify security functions hosted by network providers: http://tools.ietf.org/pdf/= draft-dunbar-nsaas-problem-statement-00.pdf.

 

We didn’t know which IETF area or WG are good fit for the propose= d work.

Security Area Director Kathleen Moriaty suggests that the proposed work= is somewhat related to SACM.

After reading through the SCAM charter, my initial feeling is that SCAM= doesn’t quite fit because SCAM is about  the language and data format for “endpoint posture assessmentR= 21;.  What we proposed is about the mech= anism to enable Network Security as a Service (NSaaS). I can see the mechan= isms provided by SCAM can be used for some attributes negotiation of NSaaS.

But I could be wrong.

 

We are seeking feedback from SACM group, in particular:

-          If what we propose fits with SACM?

-          Can the mechanism defined by SACM be used for NSaaS?<= /o:p>

-          Any other thoughts?

 

if it turns out that it is in the SCAM group scope, it is great. If it = doesn’t, we will see what else can be done.<= /o:p>

 

Linda Dunbar

 

_________= ______________________________________
sacm mailing list
sacm@ietf.org=
https://www.ietf.org/mailman/listinfo/sacm

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C84CF10AZFFEXMB04globa_-- From nobody Tue Jul 22 08:45:10 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106711B285A for ; Tue, 22 Jul 2014 08:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 ixX7Qp_gwAqw for ; Tue, 22 Jul 2014 08:45:08 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59741A036E for ; Tue, 22 Jul 2014 08:45:07 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so9231646wes.24 for ; Tue, 22 Jul 2014 08:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=g9yTTHkBHu7bm1Wsebl27ckGyPvcB2vtK1FEkJvQWfw=; b=U9X1wX9Nk3+fn8gRTms97DBRkn/uE3oNObc+hE2KaVMK6MamVn5DAkIZnlrpTCIOMX cmXsbRE4sJcKlTrZXM0RFB0++tTn6VN05nLUQsBKMtRq2jdMMqQIydh9mpGw2Qau1Ivf 9es3zlExiEX4Qx1bSWmSTuL66Q2zqKUquQNe6uVdbl8B0jqJHluTYdDnkHmOzkr5krp3 0h/DQaHDMsxgp79lWljP5XO8ODFXVLxS4kRJcOV2MpoJq1eMYnGzpvs8Y6xjEDDU1+es c28pQr0RYhh07wyjGfBU6xptdRB+AiI4ilhcFFBf3uYFMS7an53WlBFyrsATMpmOqMRP Rtag== X-Received: by 10.180.104.42 with SMTP id gb10mr15879231wib.65.1406043905621; Tue, 22 Jul 2014 08:45:05 -0700 (PDT) Received: from [31.133.149.127] (dhcp-957f.meeting.ietf.org. [31.133.149.127]) by mx.google.com with ESMTPSA id di7sm1804439wjb.34.2014.07.22.08.43.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 08:45:04 -0700 (PDT) From: "Adam W. Montville" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <6B1A0A3D-9480-43F5-95C5-22399876DF87@gmail.com> Date: Tue, 22 Jul 2014 11:43:06 -0400 To: sacm@ietf.org X-Mailer: iPhone Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/Fht9CFRa3IBnGy2VVHMawgxVCKU Subject: [sacm] Architecture/information Model X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:45:09 -0000 We are planning to have working sessions today from 3-4:30 or so, tomorrow a= t 5pm, and again on Thursday morning.=20 We will then reconvene on Friday for another sacm session. Sent from my iPhone= From nobody Tue Jul 22 10:01:02 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654B81B29F9 for ; Tue, 22 Jul 2014 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 GMPrg6fuBHaI for ; Tue, 22 Jul 2014 10:01:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E98DD1B29BC for ; Tue, 22 Jul 2014 10:00:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 727471F16A3; Tue, 22 Jul 2014 13:00:59 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5BF191F169D; Tue, 22 Jul 2014 13:00:59 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.155]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:00:59 -0400 From: "Haynes, Dan" To: "Adam W. Montville" , "sacm@ietf.org" Thread-Topic: [sacm] Architecture/information Model Thread-Index: AQHPpcPuzFsSW4CuzUaHN0a0fqpgEJusUIPQ Date: Tue, 22 Jul 2014 17:00:58 +0000 Message-ID: <6A1F6FD3001BDD40A94503E2223CEBD50AF29344@IMCMBX03.MITRE.ORG> References: <6B1A0A3D-9480-43F5-95C5-22399876DF87@gmail.com> In-Reply-To: <6B1A0A3D-9480-43F5-95C5-22399876DF87@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/TjZjNEW75n9qs5uNqbKRpr8veUc Subject: Re: [sacm] Architecture/information Model X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:01:01 -0000 Hi Adam, Will these working sessions support remote participation? Thanks, Danny >-----Original Message----- >From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam W. Montville >Sent: Tuesday, July 22, 2014 11:43 AM >To: sacm@ietf.org >Subject: [sacm] Architecture/information Model > >We are planning to have working sessions today from 3-4:30 or so, tomorrow= at >5pm, and again on Thursday morning. > >We will then reconvene on Friday for another sacm session. > >Sent from my iPhone >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From nobody Tue Jul 22 10:16:54 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D88B1B2AAE for ; Tue, 22 Jul 2014 10:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 ItmVFzsXzzee for ; Tue, 22 Jul 2014 10:16:49 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FE01B2AAD for ; Tue, 22 Jul 2014 10:16:49 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so6380582wiv.5 for ; Tue, 22 Jul 2014 10:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=34DNXnUWI36arG2kZMH3RT7dOyQiKdhGZi2COs5agGg=; b=qGAvp/juwhJ+EFiOpRUSn6/8vnwZjFJ543XbSVmL32KnU2RJocHcBXeJs5GfgwjPoO lOX8RmzkVtojsmUQ6RTRZKEqhg9PMWEpmPGi8jjt+YcUJ4DjYgpTReNQ8F5rKW5NuwVo d+NlJ4+cFYuhE7n3XOMX3fkvh+3VTMZniCII5xrQFThNj0Db8LS60RFVz9aRxjTu9NUK VOWnyRAW/APKiEeNvWR/RJQpRmsCDBS5Ywm0Z45RvYVBN4/XQw2df0jjBEwzRDpCzcND 07qosqGb7uakSWDeW6X0SaritaG6J/s4g9U+NpAaHk+2eR/lus8SzTsU8uMboTwyeeii LyLg== X-Received: by 10.194.174.35 with SMTP id bp3mr34874432wjc.33.1406049406834; Tue, 22 Jul 2014 10:16:46 -0700 (PDT) Received: from hotel-wireless-v6.meeting.ietf.org ([2001:67c:370:144:d498:1795:e64c:d10]) by mx.google.com with ESMTPSA id dn3sm55893587wib.12.2014.07.22.10.16.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 10:16:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CE533136-1812-404F-94F8-3878B2E52480"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Adam W. Montville" In-Reply-To: <6A1F6FD3001BDD40A94503E2223CEBD50AF29344@IMCMBX03.MITRE.ORG> Date: Tue, 22 Jul 2014 13:16:39 -0400 Message-Id: <6719D233-121B-43F3-90D9-0F7A0FF3FF1B@gmail.com> References: <6B1A0A3D-9480-43F5-95C5-22399876DF87@gmail.com> <6A1F6FD3001BDD40A94503E2223CEBD50AF29344@IMCMBX03.MITRE.ORG> To: "Haynes, Dan" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/zbNL9n35lsf_pgCmMzadJNNNS70 Cc: "sacm@ietf.org" Subject: Re: [sacm] Architecture/information Model X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:16:53 -0000 --Apple-Mail=_CE533136-1812-404F-94F8-3878B2E52480 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I can send a WebEx to those who would like to participate remotely. The = best we=92ll be able to do for audio is likely a computer=92s microphone = and speakers, however. Still, might be worth a shot. We=92re trying to = get a location with whiteboard and/or flip chart. If you would like to participate remotely for any of these sessions, = please let me know. Adam On Jul 22, 2014, at 1:00 PM, Haynes, Dan wrote: > Hi Adam, >=20 > Will these working sessions support remote participation? >=20 > Thanks, >=20 > Danny >=20 >> -----Original Message----- >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam W. = Montville >> Sent: Tuesday, July 22, 2014 11:43 AM >> To: sacm@ietf.org >> Subject: [sacm] Architecture/information Model >>=20 >> We are planning to have working sessions today from 3-4:30 or so, = tomorrow at >> 5pm, and again on Thursday morning. >>=20 >> We will then reconvene on Friday for another sacm session. >>=20 >> Sent from my iPhone >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_CE533136-1812-404F-94F8-3878B2E52480 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 iQEcBAEBCgAGBQJTzpx3AAoJEILmIVe/2cgGsTIH/3EvZl5mhPJkNUlgCYeHgGai CB2TBR7vAhUJX5d70gyXmTdqCvm5O8liT74ibr5AjSdouUHjdpNhwnaYAE9DHUWL glxMG3JplNCiujAsbpjmFVSq9znfExju6NNFapj9hEsGD7sUvqvOjtrcrdDVmK1p +Lvb2EPK063JUC3EpXLuXk9MFmvrG4oR8bDQz5bNxN1OBfgts5QZG4WClH8uztXN t6skyY/R3NjovRSHzHC1nxrU+LpAIQ1E4zwdX9iGcheDWtT/gQUjZyrDMhaLlP2r mdLjHUBhRH1SEf7bcazVBp/vb9UDCcBYanOAXK6U9q/4+zc+ZK8mpmLkxyiN4sE= =UMcD -----END PGP SIGNATURE----- --Apple-Mail=_CE533136-1812-404F-94F8-3878B2E52480-- From nobody Tue Jul 22 10:18:58 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB41B29AD for ; Tue, 22 Jul 2014 10:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-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 qcL4W1JjYWWG for ; Tue, 22 Jul 2014 10:18:54 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D383E1A0180 for ; Tue, 22 Jul 2014 10:18:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=kukeq/blGoPIrjKNYI/d3I1hwPtcH72u6HI9JXXI7IO9RgFpQ9G8dpj3vem/fV8kkRTrTI8FcPx0b3ejO+s8ZtE9BXKqXBCU0VELn97y/y+NRba2jjnSWAIO6EvRqu5l; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 17685 invoked from network); 22 Jul 2014 10:32:13 -0700 Received: from h64-35-203-242.cntcnh.broadband.dynamic.tds.net (HELO ?172.16.1.22?) (64.35.203.242) by server.threatguard.com with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 22 Jul 2014 10:32:13 -0700 Message-ID: <53CE9CFF.2080003@ThreatGuard.com> Date: Tue, 22 Jul 2014 13:18:55 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Adam W. Montville" , "Haynes, Dan" References: <6B1A0A3D-9480-43F5-95C5-22399876DF87@gmail.com> <6A1F6FD3001BDD40A94503E2223CEBD50AF29344@IMCMBX03.MITRE.ORG> <6719D233-121B-43F3-90D9-0F7A0FF3FF1B@gmail.com> In-Reply-To: <6719D233-121B-43F3-90D9-0F7A0FF3FF1B@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/e32K6S_ggp8gNuth6czCtQYpV4Q Cc: "sacm@ietf.org" Subject: Re: [sacm] Architecture/information Model X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:18:56 -0000 Absolutely! --gun On 7/22/2014 1:16 PM, Adam W. Montville wrote: > > I can send a WebEx to those who would like to participate remotely. The best we’ll be able to do for audio is likely a computer’s microphone and speakers, however. Still, might be worth a shot. We’re trying to get a location with whiteboard and/or flip chart. > > If you would like to participate remotely for any of these sessions, please let me know. > > Adam > > On Jul 22, 2014, at 1:00 PM, Haynes, Dan wrote: > >> Hi Adam, >> >> Will these working sessions support remote participation? >> >> Thanks, >> >> Danny >> >>> -----Original Message----- >>> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam W. Montville >>> Sent: Tuesday, July 22, 2014 11:43 AM >>> To: sacm@ietf.org >>> Subject: [sacm] Architecture/information Model >>> >>> We are planning to have working sessions today from 3-4:30 or so, tomorrow at >>> 5pm, and again on Thursday morning. >>> >>> We will then reconvene on Friday for another sacm session. >>> >>> Sent from my iPhone >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From nobody Tue Jul 22 11:20:14 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9B1A0004 for ; Tue, 22 Jul 2014 11:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 VdGdlCZ8t9We for ; Tue, 22 Jul 2014 11:20:06 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FB81A0061 for ; Tue, 22 Jul 2014 11:20:05 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so910956wib.17 for ; Tue, 22 Jul 2014 11:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=CsqCr6pGTKpt9QuyXhAsmdITQSAfidNYBS2g6Q3AuJE=; b=pEIDQI2knzWSGnR/JJ1Q8haVTO8EqgkSwCR9raPWMgvPWtnXKtECXj9D0K4oregQuK fWumfuxr9alAPjxVC7h+4ZiYNWO5YuI5jQjoigolHwADLlht711I26WM4JGa+24h/3DM pX+NvjaTA9MbEQSaU81xkS4+Ygx7ealA6MY/WkCDNc7NzNDK8v75pn0/31gTYsKOAjgG pMOlY5yIW9S4vwO1lh2onkcUQfHD1O+HKAZEtsCi0d6K5Yg4nVEfAKWJJBzkPcIzGfdW lh3ZcfhTyUIzIJ5mV2IK9gyyA5bnhvH6YBQ4jDOaWxsoPVadLyezyGjDnjYxE2MLhn4J 6bLw== X-Received: by 10.180.36.18 with SMTP id m18mr16337180wij.74.1406053202785; Tue, 22 Jul 2014 11:20:02 -0700 (PDT) Received: from dhcp-b30f.meeting.ietf.org (dhcp-b30f.meeting.ietf.org. [31.133.179.15]) by mx.google.com with ESMTPSA id gd13sm56451235wic.6.2014.07.22.11.20.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 11:20:01 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_303D7268-9BAE-41E2-8A7C-0CD96AFDC238"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Date: Tue, 22 Jul 2014 14:19:59 -0400 To: sacm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/vtqa-IIFJ2H1_7QWPYCKxiVRezo Subject: [sacm] Architecture Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:20:08 -0000 --Apple-Mail=_303D7268-9BAE-41E2-8A7C-0CD96AFDC238 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All: If you=92re at IETF 90 and interested in participating, we=92ll be = discussing the SACM architecture today at 3pm. Until we are able to = secure a room, let=92s plan to meet in front of IETF registration on the = C level. Two additional informal sessions will be held: Tomorrow at 5pm = until approximately 7pm, and again Thursday morning at 9am until about = 11am. If you are remote and interested in attending via WebEx, please let me = know directly. Regards, Adam --Apple-Mail=_303D7268-9BAE-41E2-8A7C-0CD96AFDC238 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 iQEcBAEBCgAGBQJTzqtPAAoJEILmIVe/2cgGKxQIAMvCb1J+7elQBQynNuvDO/Ll m3jQ/1HCZ2IXKwwx4R47k0Gwehls7fnL9o2HE4I+DiOEEXeyD1Dzs3zJZlFnmnCu 60YTrFCpWKJEfvuaCuB3E4v39gdqadPmL3rwIjSeTIX3A1TUUIOFp5paexJcLJYx g8N/72nxMoC7Zw9t1Ef/l0UgvgkdvlOCb/nJsog+Ok65pyMlcXNNJqMECJdBpyQE 6G+7mTRVTobKGc7xHhSdIJl8BhgQCB3BGYhsHhX/VTnTqZyFu4m8ERJy9I4BJduV c0Z6U7IwsAoiQbd24BwuUgYhVYDebf1KSU6/aGu2uLrWf4ql0W//5a+0WnS6SJg= =ZBj7 -----END PGP SIGNATURE----- --Apple-Mail=_303D7268-9BAE-41E2-8A7C-0CD96AFDC238-- From nobody Tue Jul 22 12:05:09 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EDD1A0AFB for ; Tue, 22 Jul 2014 12:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Mfd1zws3sGS4 for ; Tue, 22 Jul 2014 12:05:06 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4851A0B06 for ; Tue, 22 Jul 2014 12:05:06 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 142so66816ykq.37 for ; Tue, 22 Jul 2014 12:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=TjPmBCTapgjZizKoyehtsMOonGG7YKb+0k0vFfTg3I8=; b=PZWT23dHYNNIHTwHWWeX5QDsqwsfnONhVKWBPFEnKZ4g6EWzpBHKstGWtnEygN25QW PxvRKqPZV2Bwz3oyp5510XqRsdSauisoyToXBkv3d3p7uKP6GPqjtbwBvYQYTvxFLBLF x7Ed/pIxD1dmbzul5aKiYr4QYjNupGJx+y1TFNTWbMYQkdpLmc4S7r0VFcSW93QzwFko iSEbttmjXg1n8AJ7zB+Zxma+eI4IeggygsHXpVA2MHQU0Cme3FAnP4qqr+crgHp54tWs YMohC0g84EwSD8y1s+XDH1LpYhW1NoFjbqrOY1T45SoAHRDZ1jFbiLQNA/e7Wb1aHAVO n/SQ== X-Received: by 10.236.202.68 with SMTP id c44mr54299475yho.0.1406055905675; Tue, 22 Jul 2014 12:05:05 -0700 (PDT) Received: from [10.127.228.154] ([166.170.57.240]) by mx.google.com with ESMTPSA id o50sm2435906yhm.0.2014.07.22.12.05.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 12:05:05 -0700 (PDT) From: "Adam W. Montville" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Tue, 22 Jul 2014 15:05:04 -0400 To: sacm@ietf.org X-Mailer: iPhone Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/uwz8pYSh8ulw1thdrTJJBU1_XKI Subject: [sacm] Architecture discussion on 18 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:05:07 -0000 In the IETF lounge. From nobody Tue Jul 22 14:11:37 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242C61B2831 for ; Tue, 22 Jul 2014 14:11:35 -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 vCGroxQ7eAXL for ; Tue, 22 Jul 2014 14:11:32 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026B81A03D3 for ; Tue, 22 Jul 2014 14:11:31 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so6581035wiw.3 for ; Tue, 22 Jul 2014 14:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=z/r0f+RJNfCk72y2uHPLT/tvItaH//XMleZpNt3NQwA=; b=LB9hruunq9DxY/RBA+Q7zP5dnBcbyl4UmXvLtefDiKxtUqqazr0LN/dZimJTesSZ7G OrJzHKj8dzDJ8O9YMJNmb12nhbRdvlgHtLPfngIlOy0qGKMI0rYWw0CJJgMkqptz+KuP Bp+9XkSv2iG9I3FZAJd+fgv7wfk8Ow9eWndlvPUUtL4nbfijwtgRIlTjmfW04QoKMhOp lJ7gpmviRVVUwWwxh3HNJhMiZ4A/wu4FZ/FvoVnSJuWx6DV/FzFNLfIfXt1vZaTbKaxh uLeEyaueWKikbymkbWlV5ea2ukgsY4lZBgbAeVJJHkHYGErxN4eebj3IUGB+qp0VdeX3 +DCA== X-Received: by 10.194.87.97 with SMTP id w1mr37918707wjz.42.1406063489418; Tue, 22 Jul 2014 14:11:29 -0700 (PDT) Received: from hotel-wireless-v6.meeting.ietf.org ([2001:67c:370:144:88bd:5ca8:eb08:3217]) by mx.google.com with ESMTPSA id fb8sm1131050wib.15.2014.07.22.14.11.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 14:11:27 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_D4B043AE-A14B-48AB-8B85-614BC9BBDE5E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 22 Jul 2014 17:11:23 -0400 To: sacm@ietf.org Message-Id: <3236F348-E98C-4A60-ABA3-BD3E8219A9EB@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/V_RXizs_a9_mjVas-QxHhPQtsHQ Subject: [sacm] From Today's Architecture Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:11:35 -0000 --Apple-Mail=_D4B043AE-A14B-48AB-8B85-614BC9BBDE5E Content-Type: multipart/alternative; boundary="Apple-Mail=_4ECAE545-E02D-4B4E-8023-FF97831EC6DD" --Apple-Mail=_4ECAE545-E02D-4B4E-8023-FF97831EC6DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Today several of us sat down to talk about the architecture draft - = specifically to identify improvements. I captured a list of things that = either require further discussion or that we know we want to address. = Hopefully, the categorization of these items are faithfully represented = below. We will be meeting again tomorrow from 5-7pm and on Thursday = from 9-11am (Eastern) on-site at IETF 90. If those who attended the = WebEx today thought it was useful, I can set up another - I know at = least Gunnar had an issue being heard via WebEx (apologies for that). =20= For those who were present during today=92s discussion, feel free to = bash what I=92ve written below for =93things we know we need to do=94 = and =93for further discussion=94. Next Steps: Wednesday: Walking through a usage scenario (preferably from the use = case draft), which will inform both architecture and information model. Thursday: Start folding together the two information model drafts. =20 Friday: Second SACM session =97=97=97=97=97=97=97=97 Things we know we need to do: Define and relate to each other the concepts of =93role=94, =93function=94= , and =93capability.=94 =20 Provide better segregation between control plane vs. data plane = operations (functions? capabilities?) Partition transport and what is transported Be more specific about how we integrate/interact/relate with other IETF = efforts (i.e. NEA, MILE, etc.) Might we consider referencing their architectures? For further discussion: How do we talk about =93repositories=94 and =93security automation data=94= in the architecture draft? Four repositories were mentioned (including = one from Gunnar): Guidance Attribute Evaluation results Classification/Taxonomy Collection providers as proxy (i.e. mediation between protocols; select = options as part of timing information) Control plane interfaces: Should the architecture document define these, = or should these be expressed elsewhere? What are the data flows required within the SACM ecosystem and how do = these flows inform information models? The subject of timing/time-stamping is probably better put in = requirements, but could be discussed in architecture Provider/Consumer chaining and/or delegation - we may want to include = something about this on an informative basis and certainly don=92t want = to preclude this ability Provisioning/registration There was some discussion about whether this is =93information model=94 = or =93architecture=94 material - or something else (i.e. ops spec?) =93Discovery=94 is as client, not as endpoint (i.e. active scanning for = previously unknown endpoints is not in scope here) Kind Regards, Adam --Apple-Mail=_4ECAE545-E02D-4B4E-8023-FF97831EC6DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Today = several of us sat down to talk about the architecture draft - = specifically to identify improvements.  I captured a list of things = that either require further discussion or that we know we want to = address.  Hopefully, the categorization of these items are = faithfully represented below.  We will be meeting again tomorrow = from 5-7pm and on Thursday from 9-11am (Eastern) on-site at IETF 90. =  If those who attended the WebEx today thought it was useful, I can = set up another - I know at least Gunnar had an issue being heard via = WebEx (apologies for that).  

For those who were = present during today=92s discussion, feel free to bash what I=92ve = written below for =93things we know we need to do=94 and =93for further = discussion=94.

Next = Steps:

  • Wednesday: = Walking through a usage scenario (preferably from the use case draft), = which will inform both architecture and information = model.
  • Thursday: Start folding together the two information = model drafts.  
  • Friday: Second SACM = session

=97=97=97=97=97=97=97=97
<= div>
Things we know we need to = do:
  • Define and relate to each other the concepts of = =93role=94, =93function=94, and =93capability.=94  
  • Provide = better segregation between control plane vs. data plane operations = (functions? capabilities?)
    • Partition transport and what is = transported
  • Be more specific about how we = integrate/interact/relate with other IETF efforts (i.e. NEA, MILE, = etc.)
    • Might we consider referencing their = architectures?

For further = discussion:
  • How do we talk about =93repositories=94 = and =93security automation data=94 in the architecture draft?  Four = repositories were mentioned (including one from = Gunnar):
    • Guidance
    • Attribute
    • Evaluation = results
    • Classification/Taxonomy
  • Collection = providers as proxy (i.e. mediation between protocols; select options as = part of timing information)
  • Control plane interfaces: Should the = architecture document define these, or should these be expressed = elsewhere?
  • What are the data flows required within the SACM = ecosystem and how do these flows inform information models?
  • The = subject of timing/time-stamping is probably better put in requirements, = but could be discussed in architecture
  • Provider/Consumer = chaining and/or delegation - we may want to include something about this = on an informative basis and certainly don=92t want to preclude this = ability
  • Provisioning/registration
    • There was some = discussion about whether this is =93information model=94 or = =93architecture=94 material - or something else (i.e. ops = spec?)
    • =93Discovery=94 is as client, not as endpoint (i.e. = active scanning for previously unknown endpoints is not in scope = here)

Kind = Regards,

Adam
= --Apple-Mail=_4ECAE545-E02D-4B4E-8023-FF97831EC6DD-- --Apple-Mail=_D4B043AE-A14B-48AB-8B85-614BC9BBDE5E 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 iQEcBAEBCgAGBQJTztN7AAoJEILmIVe/2cgGjuIH/2IYxQLJadthVLzQeVkc4lP+ 49ZConp8XfH36VynzB5WgUj4jB5AwVFgxLjsDRLRjPh6wdrCa25ahC5eRd1xJupG sP+XhUyxAhoqpxRx574Ai/9k3GKfNL2Y/YtRnrmTgXOLajyGAALjBtsKz+/HBV7Q iw8M2hjn9X9+mZ9amoo7zAz7VjF3NkGgwk9w2UyYrAoTd2Hh9/+vVWCcBM+QyNdI 4UThlrnYo1lzbd7DiRRELu6xJSelj29Ac49ZtBhIynNs+S3g0yQVFwdm1QLq1mrf +Hwf562TdTuNTbB5MUpn4+0nKCW+KGniH/HMleASSCBW2KTXkbmd6VKiuP2CmeE= =qPJ3 -----END PGP SIGNATURE----- --Apple-Mail=_D4B043AE-A14B-48AB-8B85-614BC9BBDE5E-- From nobody Wed Jul 23 09:36:33 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328CC1A0146 for ; Wed, 23 Jul 2014 09:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Ofw5DAG7QoQ7 for ; Wed, 23 Jul 2014 09:36:29 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECB71A00F0 for ; Wed, 23 Jul 2014 09:36:29 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so1705723qgf.21 for ; Wed, 23 Jul 2014 09:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=pUlnYBwEPfCYw2Pk/V81E2Lr2wwPxIK7NGbBqce+iUs=; b=xKJlEql9OjowN7pMohgvT4q/IBDN3QyNjQVzo/WZaZAEfImOzmU5ehHoW0zldu61yx NecB5RJNyTQth2YZDzJhiroOdDDZQo14qMqHicN7/luYmGyHzeQejbmkn3lXAZWwPb9K COVxrMlLSCSl9mt/HDspbHQqySXnBTL2J2VLqOMGrBx9ERYtOWk7dXceGTEi2r4S1b0T 2OgrYI7zLCImNK5rO227MpgUSbxZ4a6wzmi38o4DiE2sj+htkquzzM98h2O7ODCbNcwP UZQVuqhj0KGnR1jq0m0risK3JoyP6hli0f95QnPCDDWAOgquzlCc4dJ0Mj3KYXelBeO+ WoHQ== X-Received: by 10.224.51.74 with SMTP id c10mr3798635qag.81.1406133388679; Wed, 23 Jul 2014 09:36:28 -0700 (PDT) Received: from [172.16.53.32] ([206.47.221.210]) by mx.google.com with ESMTPSA id 98sm3882011qgh.5.2014.07.23.09.36.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 09:36:23 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_B9D70B47-07E1-4174-A0C2-A2EEE7465436"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 23 Jul 2014 12:36:21 -0400 To: sacm@ietf.org Message-Id: <3BE8B030-8E77-4D2A-8444-6D1338FFD21F@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/BnlbZzKM4WJDHYlDMmeHorLJz8s Subject: [sacm] Scheduled Discussions at IETF 90 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:36:31 -0000 --Apple-Mail=_B9D70B47-07E1-4174-A0C2-A2EEE7465436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We will be holding a usage scenario walkthrough discussion today from = 5-7pm in Confederation 3 (MM level). Tomorrow morning=92s meeting will = be held from 9-11am in Algonquin (also MM level). Regards, Adam --Apple-Mail=_B9D70B47-07E1-4174-A0C2-A2EEE7465436 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 iQEcBAEBCgAGBQJTz+SFAAoJEILmIVe/2cgGK40IAJawBqA4jxujXFCCELWUHP99 /cwCCUaHwR1T+C59LrwT4e9B9KP3vxnT4toxhZuGwQTJ6aA5G7CYxBP5OtrpyX5E C/jUzMfMx3iJkhMRmKlcT5LIuja1oGu/Kf7/bxKy2f24GESohTY73pmKXE96xo5z JeVsQ8hWp0lqwZOUDBTAIeq9Ks8Lce47K5IQa34rFeWcxKBFabchOdBry/W9vyFM IotzJ5n8KvUxiGrz+WHhaE1yR7FEuP/NodbftVoWlOvBMEbg3FZMiqBIeFgoB0DF rDJUWZwkAJAR+8hq+r8iL8WS+uGaoqG9/v16oZ88qp2fctpnaUIwC8ieigmMqcE= =f6aR -----END PGP SIGNATURE----- --Apple-Mail=_B9D70B47-07E1-4174-A0C2-A2EEE7465436-- From nobody Wed Jul 23 09:39:36 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12C71A0146 for ; Wed, 23 Jul 2014 09:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 qOuwjcXS4aj5 for ; Wed, 23 Jul 2014 09:39:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDF91B29A6 for ; Wed, 23 Jul 2014 09:39:30 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0221.namprd09.prod.outlook.com (25.160.92.143) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 16:39:28 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 16:39:28 +0000 From: "Waltermire, David A." To: Adam Montville , "sacm@ietf.org" Thread-Topic: [sacm] Scheduled Discussions at IETF 90 Thread-Index: AQHPppRG3jHEniyunkSXrOvd8OkDaput3C2O Date: Wed, 23 Jul 2014 16:39:27 +0000 Message-ID: References: <3BE8B030-8E77-4D2A-8444-6D1338FFD21F@gmail.com> In-Reply-To: <3BE8B030-8E77-4D2A-8444-6D1338FFD21F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:b876:c7c:8948:6f7b] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(199002)(87936001)(2656002)(101416001)(79102001)(77096002)(85306003)(83322001)(19580405001)(19580395003)(81542001)(81342001)(20776003)(64706001)(77982001)(80022001)(4396001)(83072002)(63666003)(105586002)(85852003)(21056001)(86362001)(33646002)(107886001)(31966008)(107046002)(95246002)(76482001)(74502001)(54356999)(46102001)(99286002)(99396002)(106356001)(74662001)(95666004)(92566001)(76176999)(92726001)(50986999)(106116001)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0221; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/w3H33zENhNx_Kd6cpD69hQgZbZQ Subject: Re: [sacm] Scheduled Discussions at IETF 90 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:39:35 -0000 We should have a conference phone in these rooms. Do we have webex info for= these meetings for remote participation? Dave "Adam W. Montville" wrote: We will be holding a usage scenario walkthrough discussion today from 5-7pm= in Confederation 3 (MM level). Tomorrow morning=92s meeting will be held = from 9-11am in Algonquin (also MM level). Regards, Adam From nobody Wed Jul 23 09:41:32 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBA81A0AC2 for ; Wed, 23 Jul 2014 09:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 pOKzyJnTYjsN for ; Wed, 23 Jul 2014 09:41:29 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B3B1B29F8 for ; Wed, 23 Jul 2014 09:41:28 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id cm18so1504510qab.4 for ; Wed, 23 Jul 2014 09:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Mv6rZZPPbX5OdIbmpBtAjPxBRNFRpg2dZRXjRnB9NAs=; b=dg4K1uOPMVxGgh/nzSl2Lsvu9TH94gs4hhQJLeuXJlRKXDrZBaHva57oVsPAkMZ/Xq GvtvMug49L4yP8U40J8BM7JHvwCRt49gdIx0jZxbQCogKviAkhQeKYiPX2MpdLWFhpxW Zrt4rspgw0TGj81F3jxEJbl18V72MtYxSCj01amrS+SUg2jJ2X9bYPH+eOuod36ITp8s OpqPkbADaUXUHS2O8KXqyjiSKzL0dKxRR8h6A8t8ulhxMQwQBtoP08lF+z1Yv5/L0TIw heXrSsot1NREqlkq4pBZaHnJFoYxBT4IGWUmcLCxkDdcMJD73G9VZmYyWaiY09Ny7p4v vt7w== X-Received: by 10.224.71.198 with SMTP id i6mr4162330qaj.76.1406133686589; Wed, 23 Jul 2014 09:41:26 -0700 (PDT) Received: from [172.16.53.32] ([206.47.221.210]) by mx.google.com with ESMTPSA id b6sm4762427qak.42.2014.07.23.09.41.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 09:41:24 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_75754166-21FD-4B91-AB22-60D645A5F7CA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Adam W. Montville" In-Reply-To: Date: Wed, 23 Jul 2014 12:41:23 -0400 Message-Id: <7E88344D-7ED9-4643-9870-2411961D2ABB@gmail.com> References: <3BE8B030-8E77-4D2A-8444-6D1338FFD21F@gmail.com> To: Dave Waltermier X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/oi-12jEzwSHiu7QcVurK6aoPBBc Cc: "sacm@ietf.org" Subject: Re: [sacm] Scheduled Discussions at IETF 90 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:41:31 -0000 --Apple-Mail=_75754166-21FD-4B91-AB22-60D645A5F7CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 23, 2014, at 12:39 PM, Waltermire, David A. = wrote: > We should have a conference phone in these rooms. Do we have webex = info for these meetings for remote participation? Yes, I have sent the WebEx information to those who=92ve indicated = they=92re interested in attending (for Thursday; Friday=92s WebEx is = forthcoming). >=20 > Dave >=20 > "Adam W. Montville" wrote: >=20 >=20 > We will be holding a usage scenario walkthrough discussion today from = 5-7pm in Confederation 3 (MM level). Tomorrow morning=92s meeting will = be held from 9-11am in Algonquin (also MM level). >=20 > Regards, >=20 > Adam --Apple-Mail=_75754166-21FD-4B91-AB22-60D645A5F7CA 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 iQEcBAEBCgAGBQJTz+WzAAoJEILmIVe/2cgGvBkH/R3xVUPoUUxiTL3Gxz3L05Or i4zTvfrvcnOMmssuUcVKFjIyMqT8BZ3ZIgWZ28eN80InZKbnhMNdJdHgH6AvTygf +sbVZhn02rid96yf+VhOSHvxKNxkPrbZGUE06bqA3yZs1Ma393ueh0T7C0EotbrV W8KpEs42FVDDySsUAVCKBFMW30v2gteWfdGmeK/zn4Vo0/kmClFaRJzAM9ry3Q3w wC9tKOkq0U9uCv+wxUt89qn+sILmEV0Ki6Y7mCazVDnB1jfeTnc7ZraHkJAPGw/6 grlCZLfVwwwmn+kZuCDuDmurA9vgj3XBEsVLSY7XSQVKvnjVl/y4g7myUOekeLU= =2vpf -----END PGP SIGNATURE----- --Apple-Mail=_75754166-21FD-4B91-AB22-60D645A5F7CA-- From nobody Wed Jul 23 09:46:52 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F18D1A0361 for ; Wed, 23 Jul 2014 09:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-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 xRAByzNr13wM for ; Wed, 23 Jul 2014 09:46:47 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348771B2931 for ; Wed, 23 Jul 2014 09:46:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=Mr3BphTXuUEzIIZb3waJW5a1ysKyDrnpV5toFquySYLwFDRj2vQ7UHFrzaBQwAs6jA7QQS3swicY4fmbmoLnCLWaPHP9H4FIGMqpSeHZ8dGddc9PGcPVj2gW0DLDWTMc; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 13406 invoked from network); 23 Jul 2014 10:00:07 -0700 Received: from h64-35-203-242.cntcnh.broadband.dynamic.tds.net (HELO ?172.16.1.22?) (64.35.203.242) by server.threatguard.com with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 23 Jul 2014 10:00:07 -0700 Message-ID: <53CFE6F9.3080803@ThreatGuard.com> Date: Wed, 23 Jul 2014 12:46:49 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Adam W. Montville" , Dave Waltermier References: <3BE8B030-8E77-4D2A-8444-6D1338FFD21F@gmail.com> <7E88344D-7ED9-4643-9870-2411961D2ABB@gmail.com> In-Reply-To: <7E88344D-7ED9-4643-9870-2411961D2ABB@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/XMRbpMRIFB0PMXEwkYN_rHD2mNE Cc: "sacm@ietf.org" Subject: Re: [sacm] Scheduled Discussions at IETF 90 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:46:49 -0000 Also, is there video available from Tuesday's session? I wanted to participate remotely but could not find any information for doing so -- I still have some fundamental questions about IF-MAP that I hope can be answered by viewing Lisa's presentation. --gun On 7/23/2014 12:41 PM, Adam W. Montville wrote: > > On Jul 23, 2014, at 12:39 PM, Waltermire, David A. wrote: > >> We should have a conference phone in these rooms. Do we have webex info for these meetings for remote participation? > > Yes, I have sent the WebEx information to those who’ve indicated they’re interested in attending (for Thursday; Friday’s WebEx is forthcoming). > >> >> Dave >> >> "Adam W. Montville" wrote: >> >> >> We will be holding a usage scenario walkthrough discussion today from 5-7pm in Confederation 3 (MM level). Tomorrow morning’s meeting will be held from 9-11am in Algonquin (also MM level). >> >> Regards, >> >> Adam > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From nobody Wed Jul 23 11:00:18 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825EA1B2C2B for ; Wed, 23 Jul 2014 11:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 jyzSChtFPNj4 for ; Wed, 23 Jul 2014 11:00:12 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474831B2C30 for ; Wed, 23 Jul 2014 10:59:11 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so8243443wib.8 for ; Wed, 23 Jul 2014 10:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=o0DOhqk3fzNv2vtrnRJs8Nor/7V9IqnuluBKpbgP4TU=; b=OcJSmYb9coCXkyWB6yJZ3GzdhkJEHiByrsF5yUUKlDO5zlWYle9j2RpxcA3Dp+MFux u46xduJYoFKEcBIL6TcPcvDn+7ealbf+C55NVduxBkpri7ztCKWr/vUdQJQwb8fmq004 08oJwdlzPEvY3fPMxb5AwFqnMqxDE8IxP+fYFzkuE5pt3tzOR0R8qkzFK6fBePEY5Xy4 MzK/k48noXcjVOqfXreXFOlOPrFS3vvf2ybYzncajOViQxV7pUxW1pUlFhp3cI2jEMKB GpO1TkI6Dh1/e4fJiO9NaNu8HtGb7ful4likr3bW/bIYF9fD90NWXKjzgH8DktrZ4QVK P+Kg== X-Received: by 10.194.134.70 with SMTP id pi6mr4245731wjb.1.1406138349218; Wed, 23 Jul 2014 10:59:09 -0700 (PDT) Received: from hotel-wireless-v6.meeting.ietf.org ([2001:67c:370:144:1490:f797:410:40f]) by mx.google.com with ESMTPSA id ub11sm12135662wib.1.2014.07.23.10.59.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 10:59:07 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_86C275E2-A683-4E7D-813E-71F0300479FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 23 Jul 2014 13:59:00 -0400 To: sacm@ietf.org Message-Id: <0AB40BC0-3595-4B95-8791-85D3A508A778@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/QWGV01O6vH_oGjAdBiCF2WTK8uo Subject: [sacm] SACM Session Notes Posted X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:00:15 -0000 --Apple-Mail=_86C275E2-A683-4E7D-813E-71F0300479FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All: Thanks to Chris Inacio and Mehmet Ersue for volunteering to take notes. I have summarized the notes from yesterday=92s session and posted them = for your review here: = http://www.ietf.org/proceedings/90/minutes/minutes-90-sacm Please let me know if you find any issues. Also, these notes will be = updated after Friday=92s session. Regards, Adam --Apple-Mail=_86C275E2-A683-4E7D-813E-71F0300479FD 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 iQEcBAEBCgAGBQJTz/fkAAoJEILmIVe/2cgGHTkH/3VdXsJt7Dg/r5v00AA2elWp iHLVQYRz08kyiouxXr+x2Yox12nvIPAKMXqRcxcNzdkltDMj4qsHgaCbNPv7nUZa HxxPJmmifMr7iGT4FNoz4SbAYFnA/POAIXIlbp6A9H68cdWH3dZQ+I+EidbEKPso gy4ZFknyceIT/dUGpSKy+syrssL4LyFmR6yZRqvXyCoLwYTZT6m4pAiaqanqADm8 CYxh4+OXP8M6bwKvriiE3qySlZK6AOu/cXRojlr8IM2BVTEurxfeNl9+S24JNCiE 3DbSkQgrGcMk64VaTJendhIeyhHFXHACslOKGwmFFGpqdUc1EQ7+jawKrbyNKsM= =y8NT -----END PGP SIGNATURE----- --Apple-Mail=_86C275E2-A683-4E7D-813E-71F0300479FD-- From nobody Thu Jul 24 12:59:14 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EEB1A037D for ; Thu, 24 Jul 2014 12:59:13 -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 3v9vCi68BtYS for ; Thu, 24 Jul 2014 12:59:11 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169AD1A02D6 for ; Thu, 24 Jul 2014 12:59:10 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so4553051wib.11 for ; Thu, 24 Jul 2014 12:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=p5WFeYyBLqKmJzMW0dUd9byDrbYXBHImBkiCCNPLjeY=; b=m/3wv5hSoAbXmBqyeVX8qsIHGL4dkG2YfCd/sv58fxuL3XNdUySrXMujDfmxQAcXSU fWcOFOPXYCeLqbp3OH+Gu+BVt8PXUHL8JoNN72nE1KjAsMlxMlf5y7Lo/BdOZNxdC1YU BDTer8PBb3eLKmSF9mAPTwtTKLqIZgN9yGe5atdFPBbBrplBDmmPT3r9EqtObNwZm0ax lZ/mmHtKF90AZmbv1Dbut/vySIVMAr7cnonMCrQL5gKgNjWENYzG7fhNVGG+oRzA3bq3 GNxz90yl08TZOBRFI+HeUyuC7DQVr2/Sem4quzTukOJ8aXDlluBrRmWtGn4BBaafSYWQ nwOg== X-Received: by 10.194.243.10 with SMTP id wu10mr15645860wjc.44.1406231947331; Thu, 24 Jul 2014 12:59:07 -0700 (PDT) Received: from hotel-wireless-v6.meeting.ietf.org ([2001:67c:370:144:95c5:bcb2:f8e4:4421]) by mx.google.com with ESMTPSA id u10sm583304wix.14.2014.07.24.12.59.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 12:59:06 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_C8017529-3EFB-4E31-BE95-5EDCA9C372EC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 24 Jul 2014 15:59:00 -0400 To: sacm@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/nkFArnR9NIhKoKQlrsjjdGBGrqo Subject: [sacm] Notes from Usage Scenario Walkthrough X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:59:13 -0000 --Apple-Mail=_C8017529-3EFB-4E31-BE95-5EDCA9C372EC Content-Type: multipart/alternative; boundary="Apple-Mail=_BFA226A0-714C-4ACE-A52C-72C918B79BC9" --Apple-Mail=_BFA226A0-714C-4ACE-A52C-72C918B79BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All: Several of us participated in a SACM usage scenario walkthrough = yesterday evening. During this time, we walked through each usage = scenario from draft-ietf-sacm-use-cases-07 (sections 2.2.1 - 2.2.7). = Generally, we started out slow and rather talking past one another as we = struggled with terms and understanding the domains for various ecosystem = actors (i.e. what belongs to the Control Plane). As the evening wore = on, walking through the flows became easier, and we collected items for = discussion with respect to the Architecture and the Information Model. If anyone who was present feels I left something out, let me know or = just make the correction on this thread. Some assumptions/observations we believe to be true: The =93grid=94 is always on There may be multiple grids for deployment (federated grids) There may exist proxies at several locations in deployment (i.e. = endpoint proxy, query proxy, etc.) We need to handle asynchronous communications in different deployment = scenarios (i.e. with/without proxy) Things we know we need to do: 2.2.4 needs some rework with respect to clarifying how queries happen = (i.e. query multiple data stores) Define =93baseline=94 in the terminology document Define =93guidance=94 in the terminology document Things we believe we need to do: Create an informational =93flows=94 I-D Things that need to be discussed: Terminology updates: Checklist verification is different from endpoint = verification We may want to consider changing the name of =93Automated Checklist = Verification=94 (2.2.2) Should there be two major sections in the Architecture draft? One for = operational and the other for data exchange? =20 Is observation of endpoint behavior in scope for this charter? There = was some discussion how this could go either way. The in-room-consensus = seemed to be that, while endpoint behavior may not be something we = tackle now, we certainly do not want to preclude it as evidence of = posture in the future. Is security of transport sufficient or should we have some additional = security functions for communications? In disconnected environments, how do we queue messages and then batch = them when the link is active? Should the Control Plane be aware of data exchanges (i.e. for = audit-ability, manageability)? Regards, Adam --Apple-Mail=_BFA226A0-714C-4ACE-A52C-72C918B79BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 All:

Several of us participated = in a SACM usage scenario walkthrough yesterday evening.  During = this time, we walked through each usage scenario from = draft-ietf-sacm-use-cases-07 (sections 2.2.1 - 2.2.7).  Generally, = we started out slow and rather talking past one another as we struggled = with terms and understanding the domains for various ecosystem actors = (i.e. what belongs to the Control Plane).  As the evening wore on, = walking through the flows became easier, and we collected items for = discussion with respect to the Architecture and the Information = Model.

If anyone who was present feels I left = something out, let me know or just make the correction on this = thread.

Some assumptions/observations we = believe to be true:

  • The =93grid=94 is always on
  • There may = be multiple grids for deployment (federated grids)
  • There may = exist proxies at several locations in deployment (i.e. endpoint proxy, = query proxy, etc.)
  • We need to handle asynchronous communications = in different deployment scenarios (i.e. with/without = proxy)

Things we know we need to = do:

  • 2.2.4 needs = some rework with respect to clarifying how queries happen (i.e. query = multiple data stores)
  • Define =93baseline=94 in the terminology = document
  • Define =93guidance=94 in the terminology = document

Things we believe we need to = do:

  • Create an = informational =93flows=94 I-D

Things = that need to be discussed:

  • Terminology updates: Checklist verification is = different from endpoint verification
  • We may want to consider = changing the name of =93Automated Checklist Verification=94 = (2.2.2)
  • Should there be two major sections in the Architecture = draft? One for operational and the other for data exchange? =  
  • Is observation of endpoint behavior in scope for this = charter?  There was some discussion how this could go either way. =  The in-room-consensus seemed to be that, while endpoint behavior = may not be something we tackle now, we certainly do not want to preclude = it as evidence of posture in the future.
  • Is security of = transport sufficient or should we have some additional security = functions for communications?
  • In disconnected environments, how = do we queue messages and then batch them when the link is = active?
  • Should the Control Plane be aware of data exchanges = (i.e. for audit-ability, = manageability)?


Regards,=

Adam
= --Apple-Mail=_BFA226A0-714C-4ACE-A52C-72C918B79BC9-- --Apple-Mail=_C8017529-3EFB-4E31-BE95-5EDCA9C372EC 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 iQEcBAEBCgAGBQJT0WWEAAoJEILmIVe/2cgGb6YIAMsWz4GRM+CCpYRj6CQKus2/ YrgC1bvWbtxRiWx7f12nA42Eo4hkGHiZWB///ErFXwr0gbiqv6vV5oKlS/jLxQvA K/OjPP9uE/pvD7skSqubFAZymF3pzyv0Efww4sUzNDxPGnDjYZjOcyDF6dK5x5L4 WcYbkLdR1YvXiqFnru9wZLYcuDAqIR+ORyFTzJNL3XEwt52enIZ/M+QgbaTX6WAY 6x7lcyk2S1+E52LD+94nZJrQYN5uM2tVUq/8kSNwbmDiLpGRAs2aN0ReLkUuc5Vz 1Red9iztl7Evqiw8DH7bqlYoOdKW4SokxSbiMJLOH7e/iCUmJ+1tHxQVDQ/zLyA= =blg1 -----END PGP SIGNATURE----- --Apple-Mail=_C8017529-3EFB-4E31-BE95-5EDCA9C372EC-- From nobody Thu Jul 24 13:31:35 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC671B2803 for ; Thu, 24 Jul 2014 13:31:30 -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 5H9KQ6iKRMb1 for ; Thu, 24 Jul 2014 13:31:26 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FEE1B27D7 for ; Thu, 24 Jul 2014 13:30:43 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so10368538wiv.7 for ; Thu, 24 Jul 2014 13:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=97wGsNbbS4JQPyH3LmbEG0i5mPYUu/fqLGmgfxCoCEE=; b=h7u0bvXpeZcSu+L7OrX1KNEIdgkqJqAtSZ5u81dZOuTze6akL7Fr5GHmxusvZrynx6 RmpNwII+Y3JsKboX5zDksFnvhyaLUSxdXOH5DM1XGL41fPjTDJNpFbTYJiRK0dBlJUGh kL9a/UVhgHSIErLx0JNRyUqZ80hU9Z50sMShrWVXSUEYQnbvlakDdrk67IecV/B9Wg/D nqTotGGfX1UKu7KBSF94ySHdGv/QboQG83MPQa70YIm2bAOSFHa59JjwNmKGCib1kiIu Fj7wGxt9H8o5KLZRAvlsxVpLSbhtHNwe4wXEFCZoJ3cxr/17oXCGOaJ7oiZuMPrzHrpE e1Mg== X-Received: by 10.180.9.38 with SMTP id w6mr5109039wia.61.1406233842772; Thu, 24 Jul 2014 13:30:42 -0700 (PDT) Received: from dhcp-92fd.meeting.ietf.org (dhcp-92fd.meeting.ietf.org. [31.133.146.253]) by mx.google.com with ESMTPSA id jv9sm18786108wjc.28.2014.07.24.13.30.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 13:30:40 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_1F74A5A8-2C16-4E88-B8A4-EE8F695AC3A6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 24 Jul 2014 16:30:34 -0400 To: sacm@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/1MVq9_0a4DZUTmne_edYqEmMr1A Subject: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:31:31 -0000 --Apple-Mail=_1F74A5A8-2C16-4E88-B8A4-EE8F695AC3A6 Content-Type: multipart/alternative; boundary="Apple-Mail=_7DD4E998-EE7D-436D-868D-B87C3C5EACAC" --Apple-Mail=_7DD4E998-EE7D-436D-868D-B87C3C5EACAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All: This morning a few of us attempted a deeper dive on the =93Ice Station = Zebra=94 usage scenario to gain better understanding of the data that = would be required between two SACM participants. =20 Before getting into that, toward the end of the meeting we found = ourselves asking what success looks like. We seemed to generally agreed = that success is getting the Control Plane, Data Plane, and essential = configuration assessment items in place. This would include information = models needed for Control Plane administration/configuration and = configuration assessment. The following =93things that we should do=94 and =93things we need to = discuss=94 are based on the =93Frame Of Reference=94 bit below (thanks = for sharing your notes Lisa!) and on notes I took. If others have = things to add or alter, please do so. Some things that we should do: Pick term, define it in terminology draft, use it - a comment was heard = that we tend to switch around on terminology, so let=92s try to pick = one, document it, and stick with it. We should work on security considerations for authentication and = delegation of authentication We should not preclude ecosystem possibilities, but we should be = explicit about what we intend to standardize and what we intend to = restrict (thus drawing a line between what we will do and what we will = leave to be possible in the future). Define taxonomy or functional taxonomy in the terminology document Things we need to discuss: We need to have a discussion about authorization. There is = authorization at the Control Plane level, but are there more granular = authorizations for which we need to provide? What provides that more = granular authorization (i.e. Control Plane, Provider, delegate, = something else)? How do we define that we need a service to provide a taxonomy of, for = example, enterprise-relevant tags? We believe this should go into the = architecture draft. How can queries be filtered? Concrete list, wildcard, metadata = characteristics=85 And, does the Provider do the filtering or the Proxy = or=85 One way to allow Providers to announce the availability of a functional = taxonomy is to use a registry with some standard entries, but with = extension guidance for unimagined functional taxonomies Prior to participation, registration must occur. Registration (station endpoint management system, university admin) Each client publishes its capabilities (=93I know this stuff=94) So far, no data about any assets has been exchanged Endpoints are provisioned into endpoint management database Device identity information that=92s important to SACM Not traveling over a SACM transport Administrator constructs a query I want to consume information you have about assets I=92m interested in Method of query is based on what the provider registered as capability Can ask me over the grid or by this direct RESTful API, etc. Control Plane: Does: Capture Capability announcements Provides auth capability (protocol TBD) Provides resource to find capability providers Capability Definition Provider and/or consumer data Ability to exchange taxonomy (language about schemas provided) Optional/MAY Data transfer protocol(s) Data model(s) Authentication protocol(s) - direct, indirect/SSO Regards, Adam --Apple-Mail=_7DD4E998-EE7D-436D-868D-B87C3C5EACAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 All:

This morning a few of us = attempted a deeper dive on the =93Ice Station Zebra=94 usage scenario to = gain better understanding of the data that would be required between two = SACM participants.  

Before getting into = that, toward the end of the meeting we found ourselves asking what = success looks like.  We seemed to generally agreed that success is = getting the Control Plane, Data Plane, and essential configuration = assessment items in place.  This would include information models = needed for Control Plane administration/configuration and configuration = assessment.

The following =93things that we = should do=94 and =93things we need to discuss=94 are based on the =93Frame= Of Reference=94 bit below (thanks for sharing your notes Lisa!) and on = notes I took.  If others have things to add or alter, please do = so.

Some things that we should = do:

  • Pick term, = define it in terminology draft, use it - a comment was heard that we = tend to switch around on terminology, so let=92s try to pick one, = document it, and stick with it.
  • We should work on security = considerations for authentication and delegation of = authentication
  • We should not preclude ecosystem possibilities, = but we should be explicit about what we intend to standardize and what = we intend to restrict (thus drawing a line between what we will do and = what we will leave to be possible in the future).
  • Define = taxonomy or functional taxonomy in the terminology = document


Things we = need to discuss:

  • We= need to have a discussion about authorization.  There is = authorization at the Control Plane level, but are there more granular = authorizations for which we need to provide?  What provides that = more granular authorization (i.e. Control Plane, Provider, delegate, = something else)?
  • How do we define that we need a service to = provide a taxonomy of, for example, enterprise-relevant tags?  We = believe this should go into the architecture draft.
  • How can = queries be filtered?  Concrete list, wildcard, metadata = characteristics=85  And, does the Provider do the filtering or the = Proxy or=85
  • One way to allow Providers to announce the = availability of a functional taxonomy is to use a registry with some = standard entries, but with extension guidance for unimagined functional = taxonomies


<Fra= meOfReference>
Prior to participation, registration must = occur.

  1. Registration= (station endpoint management system, university admin)
    1. Each = client publishes its capabilities (=93I know this stuff=94)
    2. So = far, no data about any assets has been exchanged
  2. Endpoints = are provisioned into endpoint management database
    1. Device = identity information that=92s important to SACM
    2. Not traveling = over a SACM transport
  3. Administrator constructs a = query
    1. I want to consume information you have about assets = I=92m interested in
    2. Method of query is based on what the = provider registered as capability
      1. Can ask me over the grid = or by this direct RESTful API, = etc.

Control = Plane:
= Does:
  • Capture = Capability announcements
  • Provides auth capability (protocol = TBD)
  • Provides resource to find capability = providers

Capability = Definition
  • Provider and/or = consumer data
    • Ability to exchange taxonomy (language about = schemas provided)
    • Optional/MAY
  • Data transfer = protocol(s)
  • Data model(s)
  • Authentication protocol(s) - = direct, = indirect/SSO
</FrameOfReference>

<= /div>

Regards,

Adam
=


= --Apple-Mail=_7DD4E998-EE7D-436D-868D-B87C3C5EACAC-- --Apple-Mail=_1F74A5A8-2C16-4E88-B8A4-EE8F695AC3A6 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 iQEcBAEBCgAGBQJT0WzqAAoJEILmIVe/2cgGYwwH/1AXMSsaDSep0a2DhmL4mcxG gGgFdnVFqCumKWvkIEhRuLDSX/rK9aCRjeEb6Ah2fJ9wO/tu8F/nW/dd0hjlSkVo obFPRM6NmSig32TUwScbrqb5qos9XqAYEJZisHWtE47dh+983z89Tg9/36QB8l2Q jj9FKKmw0T7Lkr4UPXkBC8/KVAb8dV8X9pu1mn2nF0yfGc1kJcq246zhPUv3YNls OYaFqBeXRS6dlBfazQerW5xfo/tzrAAJT/fFkKCEvjC2+jqwEUDgZ7eSUJsNs28J jsmFShiXXmyHw6vXovhqv5Sb3Bqjd1KZMsgh0p6PDjIkUdKLlTqz6vGBsj+HvtQ= =P6df -----END PGP SIGNATURE----- --Apple-Mail=_1F74A5A8-2C16-4E88-B8A4-EE8F695AC3A6-- From nobody Thu Jul 24 14:15:54 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BAB1B281E for ; Thu, 24 Jul 2014 14:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-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 bFvYnAWxYZ2J for ; Thu, 24 Jul 2014 14:15:51 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722521B280C for ; Thu, 24 Jul 2014 14:15:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=DkdPbq6gIDKsG5aoP+CpquA/kEaCNDTu4fXXMWAtfgm7UoNGfvSqDUGpwswHH5m7SXXrdJLqKd5w+z9VkAwEwCn3iynAQTm9x+oVbT09FwpBRf9J0roDfVpU821UeJL0; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 16832 invoked from network); 24 Jul 2014 14:29:14 -0700 Received: from h64-35-203-242.cntcnh.broadband.dynamic.tds.net (HELO ?172.16.1.22?) (64.35.203.242) by server.threatguard.com with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 24 Jul 2014 14:29:14 -0700 Message-ID: <53D1778B.6040608@ThreatGuard.com> Date: Thu, 24 Jul 2014 17:15:55 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Adam W. Montville" , sacm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/Ur2FAxEVztRqjYw3KcvrwdeKADg Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 21:15:54 -0000 On 7/24/2014 4:30 PM, Adam W. Montville wrote: > All: > > This morning a few of us attempted a deeper dive on the “Ice Station > Zebra” usage scenario to gain better understanding of the data that > would be required between two SACM participants. > > Before getting into that, toward the end of the meeting we found > ourselves asking what success looks like. We seemed to generally agreed > that success is getting the Control Plane, Data Plane, and essential > configuration assessment items in place. This would include information > models needed for Control Plane administration/configuration and > configuration assessment. > > The following “things that we should do” and “things we need to discuss” > are based on the “Frame Of Reference” bit below (thanks for sharing your > notes Lisa!) and on notes I took. If others have things to add or > alter, please do so. > > Some things that we should do: > > * Pick term, define it in terminology draft, use it - a comment was > heard that we tend to switch around on terminology, so let’s try to > pick one, document it, and stick with it. > * We should work on security considerations for authentication and > delegation of authentication > * We should not preclude ecosystem possibilities, but we should be > explicit about what we intend to standardize and what we intend to > restrict (thus drawing a line between what we will do and what we > will leave to be possible in the future). > * Define taxonomy or functional taxonomy in the terminology document > > > Things we need to discuss: > > * We need to have a discussion about authorization. There is > authorization at the Control Plane level, but are there more > granular authorizations for which we need to provide? What provides > that more granular authorization (i.e. Control Plane, Provider, > delegate, something else)? > * How do we define that we need a service to provide a taxonomy of, > for example, enterprise-relevant tags? We believe this should go > into the architecture draft. > * How can queries be filtered? Concrete list, wildcard, metadata > characteristics… And, does the Provider do the filtering or the > Proxy or… > * One way to allow Providers to announce the availability of a > functional taxonomy is to use a registry with some standard entries, > but with extension guidance for unimagined functional taxonomies > > > > > Prior to participation, registration must occur. Must it? An alternative would be to simply broadcast its existence, such as is done with an LMAnnounce. Some drawbacks: * Must periodically re-announce so newcomers get the message * Won't cross network boundaries unless rules are created at the network level * Doesn't scale Another alternative it to not announce, but to respond to broadcast queries that it matches -- such as is done with ARP. Much more scalable, but, again, won't inherently cross network boundaries. Although a possible response to such a query could be information that resolves the query conditions for a node on another network. And if there is registration, registration with what? An authoritative server? In that case the server must already be known, along with mutual authentication information. > > 1. Registration (station endpoint management system, university admin) > 1. Each client publishes its capabilities (“I know this stuff”) > 2. So far, no data about any assets has been exchanged > 2. Endpoints are provisioned into endpoint management database > 1. Device identity information that’s important to SACM > 2. Not traveling over a SACM transport > 3. Administrator constructs a query > 1. I want to consume information you have about assets I’m > interested in > 2. Method of query is based on what the provider registered as > capability > 1. Can ask me over the grid or by this direct RESTful API, etc. Is it anticipated that a SACM participant not be required to implement, at a minimum, a common query method and data model? If it is allowed that SACM participants can interact using a free choice of method, that then leads to two possibilities: 1) A consumer can only make queries of endpoints for which it has implemented the matching query method. Portions of the network will, therefore, be inaccessible to it. 2) Every consumer has to implement every possible query method. > > > Control Plane: > Does: > > * Capture Capability announcements > * Provides auth capability (protocol TBD) > * Provides resource to find capability providers > > > Capability Definition > > * Provider and/or consumer data > o Ability to exchange taxonomy (language about schemas provided) > o Optional/MAY > * Data transfer protocol(s) > * Data model(s) > * Authentication protocol(s) - direct, indirect/SSO > > > > > Regards, > > Adam > > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From nobody Thu Jul 24 15:08:17 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0C01A0111 for ; Thu, 24 Jul 2014 15:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RP_MATCHES_RCVD=-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 KNlq8QTMwW8C for ; Thu, 24 Jul 2014 15:08:12 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 73BA31A00DE for ; Thu, 24 Jul 2014 15:08:12 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta02.westchester.pa.mail.comcast.net with comcast id WJrW1o00A1GhbT851N8BA4; Thu, 24 Jul 2014 22:08:11 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta07.westchester.pa.mail.comcast.net with comcast id WN8B1o00M2yZEBF3TN8Bqe; Thu, 24 Jul 2014 22:08:11 +0000 From: "David Harrington" To: References: In-Reply-To: Date: Thu, 24 Jul 2014 18:08:09 -0400 Message-ID: <02cb01cfa78b$c1580e60$44082b20$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CC_01CFA76A.3A4C3AC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEnMYsIYCFNAvViO32qDF9t+jszHp0ApV6w Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406239691; bh=EZczExZnmTfsrywQzSKfdqm/A7V/0I82SPA5HbIRWK8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=DL521OqOyAt/rBaXzML3xQBKUy5jNWKVDh6AwK+1GSHJF2sRrpEawmPIb+rK6ML42 fIUWW3y5zl50cbqyN3C4vRLn1lMhimjyjIIVJRmGBvGtG539W+l9Bu/sNIBKPJ80Pd hZspv85YSkAL8Y2UfrVA3A3MTe4bLJcaAoKw6D9xmseXrjEANZZ0koo30egXU5bKf+ D0PmvaMQ7f0iUiPCVFa+8bce7uDg95gBqjlCA/cO7jX9dg2iAeOtSQYr0NF/6qpu0D N7YlNCOVA9AJTeH13c3R/4iOI0btQ2hvRPS/2TQ5kVLzbitOg936qXdrqJx12Zp/Vu j20mZPyuPZE5A== Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/fMC47UdYMEe7xRwirWB7d_AItIs Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 22:08:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CC_01CFA76A.3A4C3AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'm a bit concerned that this WG has chosen to use the term "Control Plane". SACM is about configuration (charter: Standardized protocols to collect, verify, and update system security configurations) and continuous monitoring, That would seem to put it into the management plane (which many consider a subset of the control plane). Defining part of the management plane as being the "control plane" seems a poor choice of terminology. I tried to find the definition in the terminology draft, but it's not there. I tried to find it in the use cases draft but it's not there. I finally found it in one of the architecture drafts. Since the IETF is all about the Internet, "control plane" seems a term of art related to routing and networking, such as OSPF and BGP. Recognizing that I might not know about non-router usages, I looked up "control plane" in Wikipedia, which redirects "control plane" to "routing control plane". I checked a few other web sites that discuss control plane versus management plane. http://blog.ipspace.net/2013/08/management-control-and-data-planes-in.html http://whatis.techtarget.com/definition/plane-in-networking http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/security/ configuration/guide/syssec_cg41crs_chapter7.html http://en.wikipedia.org/wiki/Telecommunications_network This group's use of control plane appears to be slightly different than the rest of the networking industry. It appears a SACM "control plane" is a broker for AAA services, so why not call it a AAA broker? David Harrington dbharrington@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam W. Montville Sent: Thursday, July 24, 2014 4:31 PM To: sacm@ietf.org Subject: [sacm] Notes from Information Model Discussion All: This morning a few of us attempted a deeper dive on the "Ice Station Zebra" usage scenario to gain better understanding of the data that would be required between two SACM participants. Before getting into that, toward the end of the meeting we found ourselves asking what success looks like. We seemed to generally agreed that success is getting the Control Plane, Data Plane, and essential configuration assessment items in place. This would include information models needed for Control Plane administration/configuration and configuration assessment. The following "things that we should do" and "things we need to discuss" are based on the "Frame Of Reference" bit below (thanks for sharing your notes Lisa!) and on notes I took. If others have things to add or alter, please do so. Some things that we should do: * Pick term, define it in terminology draft, use it - a comment was heard that we tend to switch around on terminology, so let's try to pick one, document it, and stick with it. * We should work on security considerations for authentication and delegation of authentication * We should not preclude ecosystem possibilities, but we should be explicit about what we intend to standardize and what we intend to restrict (thus drawing a line between what we will do and what we will leave to be possible in the future). * Define taxonomy or functional taxonomy in the terminology document Things we need to discuss: * We need to have a discussion about authorization. There is authorization at the Control Plane level, but are there more granular authorizations for which we need to provide? What provides that more granular authorization (i.e. Control Plane, Provider, delegate, something else)? * How do we define that we need a service to provide a taxonomy of, for example, enterprise-relevant tags? We believe this should go into the architecture draft. * How can queries be filtered? Concrete list, wildcard, metadata characteristics. And, does the Provider do the filtering or the Proxy or. * One way to allow Providers to announce the availability of a functional taxonomy is to use a registry with some standard entries, but with extension guidance for unimagined functional taxonomies Prior to participation, registration must occur. 1. Registration (station endpoint management system, university admin) 1. Each client publishes its capabilities ("I know this stuff") 2. So far, no data about any assets has been exchanged 2. Endpoints are provisioned into endpoint management database 1. Device identity information that's important to SACM 2. Not traveling over a SACM transport 3. Administrator constructs a query 1. I want to consume information you have about assets I'm interested in 2. Method of query is based on what the provider registered as capability 1. Can ask me over the grid or by this direct RESTful API, etc. Control Plane: Does: * Capture Capability announcements * Provides auth capability (protocol TBD) * Provides resource to find capability providers Capability Definition * Provider and/or consumer data * Ability to exchange taxonomy (language about schemas provided) * Optional/MAY * Data transfer protocol(s) * Data model(s) * Authentication protocol(s) - direct, indirect/SSO Regards, Adam ------=_NextPart_000_02CC_01CFA76A.3A4C3AC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’m a bit concerned that this WG has chosen to use the term = “Control Plane”.

SACM is about configuration (charter: Standardized = protocols to collect, verify, and update system security configurations) = and continuous monitoring,

That would = seem to put it into the management plane (which many consider a subset = of the control plane).

Defining = part of the management plane as being the “control plane” = seems a poor choice of terminology.

 

I tried to find the definition in the terminology draft, but = it’s not there.

I tried to find it in the use cases draft but it’s not = there.

I finally found it in one of the architecture = drafts.

 

Since the IETF is all about the Internet, “control plane” = seems a term of art related to routing and networking, such as OSPF and = BGP.

Recognizing that I might not know about non-router usages, I looked = up “control plane” in Wikipedia, which redirects = “control plane” to “routing control = plane”.

I checked a few other web sites that discuss control plane versus = management plane.

http://blog= .ipspace.net/2013/08/management-control-and-data-planes-in.html

http://what= is.techtarget.com/definition/plane-in-networking

http://www.= cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/security/configur= ation/guide/syssec_cg41crs_chapter7.html

http://en.w= ikipedia.org/wiki/Telecommunications_network

 

This group’s use of control plane appears to be slightly = different than the rest of the networking = industry.

It appears a SACM “control plane” is a broker for AAA = services, so why not call it a AAA broker?

 

+1-603-828-1401

From:= = sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam W. = Montville
Sent: Thursday, July 24, 2014 4:31 PM
To: = sacm@ietf.org
Subject: [sacm] Notes from Information Model = Discussion

 

All:

 

This morning a few of us attempted a deeper dive on = the “Ice Station Zebra” usage scenario to gain better = understanding of the data that would be required between two SACM = participants.  

 

Before getting into that, toward the end of the = meeting we found ourselves asking what success looks like.  We = seemed to generally agreed that success is getting the Control Plane, = Data Plane, and essential configuration assessment items in place. =  This would include information models needed for Control Plane = administration/configuration and configuration = assessment.

 

The following “things that we should do” = and “things we need to discuss” are based on the = “Frame Of Reference” bit below (thanks for sharing your = notes Lisa!) and on notes I took.  If others have things to add or = alter, please do so.

 

Some things that we should = do:

 

  • Pick term, define it in terminology draft, use it - a = comment was heard that we tend to switch around on terminology, so = let’s try to pick one, document it, and stick with = it.
  • We should work on security considerations for = authentication and delegation of authentication
  • We should not preclude ecosystem possibilities, but we = should be explicit about what we intend to standardize and what we = intend to restrict (thus drawing a line between what we will do and what = we will leave to be possible in the future).
  • Define taxonomy or functional taxonomy in the terminology = document

 

 

Things we need to discuss:

 

  • We need to have a discussion about authorization. =  There is authorization at the Control Plane level, but are there = more granular authorizations for which we need to provide?  What = provides that more granular authorization (i.e. Control Plane, Provider, = delegate, something else)?
  • How do we define that we need a service to provide a = taxonomy of, for example, enterprise-relevant tags?  We believe = this should go into the architecture draft.
  • How can queries be filtered?  Concrete list, wildcard, = metadata characteristics…  And, does the Provider do the = filtering or the Proxy or…
  • One way to allow Providers to announce the availability of = a functional taxonomy is to use a registry with some standard entries, = but with extension guidance for unimagined functional = taxonomies

 

 

<FrameOfReference>

Prior to participation, registration must = occur.

 

  1. Registration (station endpoint management system, = university admin)
    1. Each client publishes its capabilities (“I know this = stuff”)
    2. So far, no data about any assets has been = exchanged
  1. Endpoints are provisioned into endpoint management = database
    1. Device identity information that’s important to = SACM
    2. Not traveling over a SACM = transport
  1. Administrator constructs a query
    1. I want to consume information you have about assets = I’m interested in
    2. Method of query is based on what the provider registered as = capability
      1. Can ask me over the grid or by this direct RESTful API, = etc.

 

Control Plane:

        &n= bsp; Does:

  • Capture Capability announcements
  • Provides auth capability (protocol TBD)
  • Provides resource to find capability = providers

 

Capability Definition

  • Provider and/or consumer data
    • Ability to exchange taxonomy (language about schemas = provided)
    • Optional/MAY
  • Data transfer protocol(s)
  • Data model(s)
  • Authentication protocol(s) - direct, = indirect/SSO

</FrameOfReference>

 

 

Regards,

 

Adam

 

 

 

------=_NextPart_000_02CC_01CFA76A.3A4C3AC0-- From nobody Thu Jul 24 15:20:54 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEE51A0311 for ; Thu, 24 Jul 2014 15:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RP_MATCHES_RCVD=-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 wYUpbtmoPiCB for ; Thu, 24 Jul 2014 15:20:49 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id C08E61A03B8 for ; Thu, 24 Jul 2014 15:20:48 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id WFka1o0041c6gX855NLoHx; Thu, 24 Jul 2014 22:20:48 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta23.westchester.pa.mail.comcast.net with comcast id WNLn1o00q2yZEBF3jNLoix; Thu, 24 Jul 2014 22:20:48 +0000 From: "David Harrington" To: References: <53D1778B.6040608@ThreatGuard.com> In-Reply-To: <53D1778B.6040608@ThreatGuard.com> Date: Thu, 24 Jul 2014 18:20:46 -0400 Message-ID: <02d901cfa78d$8457fd20$8d07f760$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEnMYsIYCFNAvViO32qDF9t+jszHgFe1AmknPW/fBA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406240448; bh=p5c6vZ7ZWrjWrNWg6cHr5KBqd2fmYk1+c3JAruB1uW0=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=nWQJBIIByJxyx+zNPL6c54m4fWT+3Kn2PmQzagIDObeRTHtK1y/7Gp1ZEoBslvLUV PFkMXU7xRanQbX6nTP0WXJtkv2Eo7TqAX8+4KJDDhH5wQ1W1U2rm7gE2nSwNvaZ8lK jEG+Lc3X/cw2/8DrJruWrGs6MzyDOpUCSbNM1yxzI66erd+SYG7o05YWJX8phd4tMR lGfcOvoxJeYgRzdldg/JkvaDBzCykbkf0bsbQi8+DmB6iCbic1bIrKRKmMIHYvcJL7 x/gHzq8Cy9vt6t7TeSyFfV70Fn/D6fAS2xJCnV/EyaQqSY5hxgRtlf0s7gx6UckASr 7NwEjdRi9tzmQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/btl3aXP_T_5wr4Ecg8tShcCFAhc Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 22:20:51 -0000 > > > Is it anticipated that a SACM participant not be required to implement, > at a minimum, a common query method and data model? > > If it is allowed that SACM participants can interact using a free choice > of method, that then leads to two possibilities: > > 1) A consumer can only make queries of endpoints for which it has > implemented the matching query method. Portions of the network will, > therefore, be inaccessible to it. > > 2) Every consumer has to implement every possible query method. > > > If every participant can interact using a free choice of method, leading to non-interoperability, that raises the question: Why are we doing this in the IETF? David Harrington dbharrington@comcast.net +1-603-828-1401 From nobody Thu Jul 24 15:48:55 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00E01B28AA for ; Thu, 24 Jul 2014 15:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 cYvKv-5ndpAs for ; Thu, 24 Jul 2014 15:48:52 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54151B28A8 for ; Thu, 24 Jul 2014 15:48:51 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0221.namprd09.prod.outlook.com (25.160.92.143) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 22:48:49 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0990.007; Thu, 24 Jul 2014 22:48:49 +0000 From: "Waltermire, David A." To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Notes from Information Model Discussion Thread-Index: AQHPp35H3v41bPjSXEih5Cr54kkdv5uvueyAgAASHgCAAAfW1A== Date: Thu, 24 Jul 2014 22:48:48 +0000 Message-ID: References: <53D1778B.6040608@ThreatGuard.com>, <02d901cfa78d$8457fd20$8d07f760$@comcast.net> In-Reply-To: <02d901cfa78d$8457fd20$8d07f760$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.150.225] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(51704005)(189002)(199002)(79102001)(101416001)(77982001)(83072002)(86362001)(87936001)(81342001)(19580395003)(83322001)(81542001)(19580405001)(2656002)(64706001)(21056001)(66066001)(85852003)(63666003)(80022001)(4396001)(15975445006)(20776003)(105586002)(31966008)(107886001)(33646002)(95246002)(107046002)(74502001)(76482001)(99396002)(46102001)(54356999)(99286002)(106356001)(76176999)(95666004)(92566001)(74662001)(85306003)(77096002)(92726001)(106116001)(50986999); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0221; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/fnNiNC9RqPNMaRe6T_DwtaVTzZ8 Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 22:48:53 -0000 Or... 3) we define MTI transports and data formats to enable interop. Dave David Harrington wrote: > > > Is it anticipated that a SACM participant not be required to implement, > at a minimum, a common query method and data model? > > If it is allowed that SACM participants can interact using a free choice > of method, that then leads to two possibilities: > > 1) A consumer can only make queries of endpoints for which it has > implemented the matching query method. Portions of the network will, > therefore, be inaccessible to it. > > 2) Every consumer has to implement every possible query method. > > > If every participant can interact using a free choice of method, leading to non-interoperability, that raises the question: Why are we doing this in the IETF? David Harrington dbharrington@comcast.net +1-603-828-1401 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From nobody Thu Jul 24 16:02:19 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25C91A02E8 for ; Thu, 24 Jul 2014 16:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Twwk8WGD64Xc for ; Thu, 24 Jul 2014 16:02:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31CB1A0311 for ; Thu, 24 Jul 2014 16:02:13 -0700 (PDT) Received: from BY2PR05MB550.namprd05.prod.outlook.com (10.141.220.151) by BY2PR05MB552.namprd05.prod.outlook.com (10.141.220.156) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 23:02:12 +0000 Received: from BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) by BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) with mapi id 15.00.0990.007; Thu, 24 Jul 2014 23:02:12 +0000 From: Lisa Lorenzin To: "sacm@ietf.org" Thread-Topic: Update with new proposed requirements content for discussion tomorrow Thread-Index: Ac+nkudDaX6kpn82Qv6VtGyfYrAIzQ== Date: Thu, 24 Jul 2014 23:02:11 +0000 Message-ID: <8a8388169eae4492b8c2bc15de28d16d@BY2PR05MB550.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(43234003)(189002)(199002)(53754006)(54356999)(64706001)(19580405001)(85306003)(83072002)(50986999)(21056001)(229853001)(15975445006)(76482001)(80022001)(74316001)(110136001)(33646002)(106356001)(2351001)(66066001)(101416001)(74502001)(95666004)(83322001)(99936001)(92566001)(86362001)(79102001)(15202345003)(99396002)(4396001)(85852003)(19580395003)(77982001)(31966008)(74662001)(81542001)(76576001)(99286002)(87936001)(2656002)(20776003)(107886001)(81342001)(46102001)(107046002)(105586002)(108616002)(24736002)(18886065003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB552; H:BY2PR05MB550.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/mixed; boundary="_002_8a8388169eae4492b8c2bc15de28d16dBY2PR05MB550namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/Qj4U1-1z1xPA-CL8ZbSU9ixa5mE Subject: [sacm] Update with new proposed requirements content for discussion tomorrow X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:02:17 -0000 --_002_8a8388169eae4492b8c2bc15de28d16dBY2PR05MB550namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Attached is a change-tracked update to the -04.txt requirements draft with changes from the 4/28 interim meeting discussion, new proposed general requirements from our 5/28 interim meeting discussion, and some raw notes on information model requirements and other requirements that I don't know how to categorize. :) Hopefully we can review this in our requirements section of tomorrow's agenda. I spent part of the afternoon finishing my writeup of the new general requirements we agreed upon in our discussion during the 5/28 virtual interim meeting, and realized that we ran out of time during that session and only discussed my proposed general requirements, but didn't get to my proposed requirements on the information model. This jogged my memory that I'd seen other suggested requirements go by on the list, (hi Gunnar!) so I reviewed the meeting notes and email archives to look for additional proposed requirements to capture and dropped them into this working document as an unformatted infodump for tracking purposes. If you've suggested a requirement that is _not_ included in the draft already or captured in that infodump (sections 2.3 / 2.4, just for ease of reference) please let me know; if we can agree on information model requirements, I'll write them up, and I can add any missing / additional proposed requirements for tracking purposes at that point. Regards, Lisa -- Lisa Lorenzin / 919-384-7275 / llorenzin@juniper.net Principal Solutions Architect - Security & Mobility Juniper Networks / http://www.juniper.net/ --_002_8a8388169eae4492b8c2bc15de28d16dBY2PR05MB550namprd05pro_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-camwinget-sacm-requirements-04-LL.docx" Content-Description: draft-camwinget-sacm-requirements-04-LL.docx Content-Disposition: attachment; filename="draft-camwinget-sacm-requirements-04-LL.docx"; size=31850; creation-date="Thu, 24 Jul 2014 21:26:04 GMT"; modification-date="Thu, 24 Jul 2014 22:52:25 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDhD46/jQEAACkGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lEtPwkAUhfcm/odmtoYOuDDGUFj4WCqJmLgdprcwcV6Ze0H5994WaIyPEkU2TZrmfufcM6czHL85 m60goQm+EIO8LzLwOpTGzwvxNL3rXYoMSflS2eChEGtAMR6dngyn6wiY8bTHQiyI4pWUqBfgFOYh gucvVUhOEb+muYxKv6g5yPN+/0Lq4Ak89ahmiNHwgQ0kU0I2UYnulWMdqZdIwT07Kw2Bm6QQcZAz VGTXm+naQCFUjNZoRWxfrnz5SboXqspoKINeOhbMW2jNg0QG8KxmytHwBiq1tJTdvrG1TRoJLP5O brtlzpONJVyY2KXQvc/W2XfpvIZUynatbsz+WGpaTEEDIp+7s3lLdsr4XUI/+vBLN4PEkwefzxcj LXqvCaS1Bfx/BxtulzyH1dRTchcP1oe6fiWUPT6PTw39MX8EIk7/GMtvyV3rN1Uk/vFBNs/D/9IG s1ey4mtgqmYWDs78S+ta9F4TrzB7PFr6H+BdRtr+6ZD+EMbuzqqnv2mdbC760TsAAAD//wMAUEsD BBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9h yH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99r eG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1 jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDP JZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD/ /wMAUEsDBBQABgAIAAAAIQDX5gieIAEAAEQEAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwu cmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTT0vEMBDF74LfIczdpl11 Fdl0LyLsVSt4TdvpH2ySkkzVfnvDyna7uHQvuQTmhcz7ZV6y2f6ojn2hda3RApIoBoa6MGWrawHv 2cvNIzBHUpeyMxoFjOhgm15fbV6xk+QPuabtHfNdtBPQEPVPnLuiQSVdZHrUfqcyVknypa15L4tP WSNfxfGa23kPSE96sl0pwO7KW2DZ2Hvny71NVbUFPptiUKjpjAV3NHb+AiyTtkYS8FdHnhH4efuH kPbkx4JH933J92uyxLAKyaAHlaP18R45JmkJIgkJUQyOjPrwY5+iiCI+qbwlVIsjWYekqYymTObd LJpJWhrJfUiIb8zfkMgHM3ufM3EJ5C4kiPtHcVAOCPzk76e/AAAA//8DAFBLAwQUAAYACAAAACEA +euYQQxGAAAUwAMAEQAAAHdvcmQvZG9jdW1lbnQueG1s7H3bcttItuX7RMw/ZOjl2B2STFI3W+eY HbIuHe6oqtDY6umIrqgHEEySOAYBNC6i2E/zG/N78yWzdiZAIkFAJNjCzUx3RLtMUhTysm9r7732 f/35ZW6zZ+4Hlut8Puqf9o4Yd0x3bDnTz0d/e3o4+XjEgtBwxobtOvzz0ZIHR38e/s//8V+L67Fr RnPuhAxf4QTXz3h3Fobe9YcPgTnjcyM4dT3u4M2J68+NEP/0px/mhv8j8k5Md+4ZoTWybCtcfhj0 epdH8de4n48i37mOv+Jkbpm+G7iTkH7k2p1MLJPHfyU/4e/ye+VP3sWPLH7jB5/beAbXCWaWFyTf Nt/327DEWfIlz68t4nluJ59beLv8trFvLHAec1s+9sL1x57vmjwI8OqdfHP1jf3ea7873kD6itVP 7PII6u9MnmRuWM7qa+h2ZM5/dXinOLwP8nd/oK9aLwR7McRdGrnjJf3tscU17uL42+ejXvznKHnp EQfd613RyzerF+/4xIjskN457/X69w/JO4+pD4tvfvTFX9/Dpc3xlc+G/fno0cYKnvhLePSB3vTl Z/wH1wkDfMYITMv6fHTrRr7FffYbX9C3z26cYPNVM1A/iC/8EH8j/vbom+lvvUgcrj5JfV1bIpMQ 0Vz9UqE6WFyHw+83t7+y/f78dspujfnJ36H7eUg6JZSa5kD0S0MH9tUJue/w8AT2dhKWOrlbKzBd 9n0ZhHwe6ANLLHjFEkYH5oz5mLzXMAqu2VdH+qFw+Az79QP8a+Rw9vGYDXr9c31gNR3Y/Ytn+RwH dcdNPh/B3+r3DvUItKcINU9hQOc9xWbMFcXS14FnmIjJPAgV95/50ZCUnqLOmnm44XduRj5nN1Ho ImiGPmbAF9gtgi7LidwoYL+6jhW6Pjwc9o48pffsG/9nBO1AcIM2oasguFoTWnyJVOuZuVKAJtzJ vU9udbj0cAGnvjH/Hhp+EmQ34W8DQiEIyZgTkAIvLjDM+YmfulQnPdXSI1TPW8e9MyaoQOtnrZ/3 hoMoYrsZBaFvmAcYvx2E6DRjWAsV9tPMCtgKrh/zieXwgIUzzhCZelyY34CHzJ2wtE5kCJjoU4qC 1+dXDUgMrVB4fmUcJsDrP8hxmvpupBxcM3dy6J0y9qTv0Dpz0ZDTlrkLud5N015aWvns8ryxN9bM zS6QVgplYq2KGGdkBICgEOGQsjWmPse/Ig//jgLOTLwZnCoLPQjtehCLbOZSDiHCQDvJkguj/yuf u/qC/ZTZ5GYuWIHWIxsPHzOTJcErQTSaW2EItWc5bBLZNjNdCcQ7JtLwVjjTHma6rkF7B+tai1QJ BcXMcFmeLapTUhHA15GaVkkJtPKX20d29VFEXOI/P2n7/3MW+7Tq4rGMZg6YAec0CRUTZEC4DeSo Jmqc3Su+QzNLGjpTwBWcsgHK02gvsn4g4skIfrAH14fpfvf1/unhPYL739yQw4YbgI9wd3wBPHgB mxtLZtiBy8YWoE5rFIUaR2o6caPIT4HdbBoDiJXSLo/axvB/rUuNrDscSCSM2RAICtCQBPWpfDrR tifKmrV6q1+9KQfQUvkQ9WcBszrrBMNQxGXiYwNgBbJgP7h/avFwIhoERKY2+BALxwftHmv3+I3K 8F/LsKx0cCxe5B6Lm7hKmwUMHQPWuBUFNJSXM+BhvVjzaE6mJLBe2Bz1MzNVK2gbom2IKFPIICnI Uexi6troX1FYMeLIocB48PEx8tWejTI3/BdkYtuiAo/bdtMOrjsKXJvj4Xd62jaewWgZh3opZzcE pLVUVqSVj1Y+econtOYqElDgaDd684eI1b6G8LKRtjA8IM+eb0HhsNAVmdsNdyGAIppwhHOmujYt BFoI8oQAdc9ANA1b0ZhtFISCfB8VhrnMtAT0x+GDCugPKCBquQN2RCAOJfwgOKh5CILTI2WhByEV B7HIZlICBZcyPwm9sOysmDXR8lnwzFx0PVGF0Ebbk4Y+NPTxdtDH8Nb1lr41nYWUsQGLhtbIuizo bfgtXgPW1rfunfleNNQyShyyJz9CFoSKJSnh7IGABnUdzBojIWJNLJQLwY3AO4d3SVtmUZUDKHBQ m0ZUEhhil2dtNKos8AGMKJy5PqUHb1AfJ3Q0xZOia3OsvQDtBbydF1BwA2PPOREkwj1QuPnf3Awp zEvVrJGyXuvv/wjYL3yaiWJ13FM/5PG4Ko1EpzSRmqEBCAcnTiqjFZuIfYZ3Me+aTk81XQL0Ls69 h+R/cb7Ou9sICZyAn1iozn5P2A2fTEj+494VSrcg06hcJi3p9Uu6cgAt9ce8aITbJJgddnncNrpk yKmH6aZZ+GaPNke/FvyyZ4svKDbBPxKDqfVa03ptl4vWdJxioqqEWmDUPGmBEDcqFcPjOP5esjEP TJTvcrYEC2YSnFDcjgAFdb2mIFCVjTx4xYPJUI5C2whtI/ISYKHalthGISiIlbJ24dYdc5AXzdHV S+xEDGyyviICzSA6Q7CLAEab+O5cNWVsDs9PeUAto1pG82TUckw7GqsYbIcE9bs192wJJn/5fsd+ kQEOCyGgZN0SwyY6U8GwIYjIzk91lKPbUSXP9yuM3tSOms1OdEgyZPJFQHcsBR2RV0eFz6jaeEYm Ziy8OjcK2cLwfcMJ0dClAx0d6IC/b4torFSr4mZ0SEAAfxHSnW9BdEbm58zIHIQbrBeJcOynYBY+ iJNsKHZeD1hQqW5jjvJVrV7GvjWRWytAKRLudPX52e+PxpSz/h/Kg+ubVFX8P1qzIHvY+Jg6+FBG ATUivLYRhN84Jj/4fEyX/YvPjR/of6OQTW3bUEXjZjSi1A51lbEnK8SMqI0/YizEYc6EOAgVcRCL bEQow+GTMYJIIa1KNP+HyeKvr1dVZraYOblPfXxO6LvjSAK87LTk/xgbaGepnhFABa7sxtAS4JPq hIlW9HWr1yQH7BJP2WxaH9KQnqTCtsuCcvebsR0F10IVZC2mmXmnFc0yfa3XA2dw2s9cmA1ZbcM0 GIjBX7jD/Uzlco7M0tM2KrIFl1/Mj0zTpW+VZC0g7RCQrWaiJQKSthO7yHQbpWTFvv831GreEtv+ K2LC2LmyTu2u1++un0Ez35g/HHdh8/FUjnvbwUlJnSpjF/oUG3bXzynouvnthmJ9pFqU82jGhRzC 1stCVdVrfO1f+iY1bzAzV2fDmWxF4KcqnBwnsh2BnxgiZaGIR0plSYnQ0tC8NFyK8D2mmQrK2UWp 6fQpNn+KjF12Jkr+zfVpQu9zZ2uAvyWsbIXikjExTaTwQTaX/p8W0nYIaVci9a9yntLPLaaqgFwq Uqsj9fojdQxvB2cJCCBuxmNi+CvvjcAOHt4p6qta2VUdZnO9+nZpgrPqCc6e3LGxhB40Z4Ztc2cK jBlVLvzZtZ8FC8sM9WfoCqXeGvSjobOGuM0cw16Cgw8UZ2obrFYPlamHgkTa9uKCNuRjjFaAqMLQ K1o1B+xqa8Y0iEwaNSqlcQYeTFtwYRoMs+VAQugysLC5RMssOn8CjgE0JL+a8kZPLj/a3vE2AgF2 VyWDGJ8EzAOqp4SQM1iCHWpOFJwY1xSErs+PqS3UJE9ffAb9oAEG+5KwKOvWFkxbsHwugdUlU+5L Gy0IDX+gAhvp1flg6mcTENhR+QCJiAx4yTgE7lzUNAsyKGVZWgy0GOSJwTpKUK5LG6WgwGFGazR8 JhACuAvIRWC6HmcYCDRyI2csAx54UJnFNQKq06hacutifAriqzyVllAtobkSSmViyk3pkHAKdw1k 6qFBDAauCGU8NwgjsHoYARYWzGniLAEUzthzLfBVaTaDn5PNoJlCqwKjkeWXTrlTMVdIYjqUmmaa czkxTMu2MCgWn1DEUitwrcDzFHg2Iu2Q+uYv8A8BIZOCzlHbqUD9WEzXMnyAyJFt+McIUHwtHQ3X vSoHUHDtmuag7bB0wINnpijiB3sff+EJu19m25sINgrMHpyw37+eZJ6vnUWsd4IJfqdHbbTTY9iN 7QwMc96FzYRMnQiZ+uP0xg7cY0QMlhr9aDdLu1l5blZCfb/tlrc1HyjgXEC7c8txbXdKROcTy0Eq UCttMHQESHm93dQhrbTfdDNTt/YPDd9o+OYNBXUgWkz+GVm+bL5UtPtBuAIHschWg4PSENMExPU9 ZKtWbgSwIjnLVuHg4d3Rlh2fcgAtxT1i726XR200vtVIQl31ZtopfVOnNIUkxNke1FCKmRoyw5OR vCZQuuEIFTxZAFTbe41v5OEbae8jc3c3ENwWYxxjKs4RbFFUCyNKAEQBp4mBVTTrw0Q1pyWGe6ay S8p6tYBoAckTkDnmntkqVlzg+7XRoaIiZshx6JquTW04mHctq5kxAcecWSFsF4pmEA0/iUGfhdpA S4eWjjzp4C8etcUqmrRD4oE6BJ8GCPpWIPrUqBAHfWwQibgnwEhZjkSOGD4FU2Ioi9YCogUkT0CE +VBuSofEg0ZoMszENQ0v4TV3MS49s5xGYhzRtRaQr0dWDSPdqfZTtrPRADdH7STU0qmlM086URnM fZT2+8aIqi87MLFaJ8J0IuxNE2GayfptiwAKkO0NJmvFiB6EfTqIRbYsZ4Wwfp1B1LU/1U0L0GmW itIszPA8e0lO/txwVAdNKxTt1ed59WPu2e6SWgAVI9uhwDswOXqPLTcgZHYV3majlWP0JRt2HLro mNdvnk9zl/vWdGvMxOYvVkfC3QJnmprznSW1jyHNnQWfG4GjOHyrROkE1F7A0apm2+6CGj51VgVe 8cYwappVWp0/VnBzOsKD5mcx1s7k4pP2AuppBlPgOvi4VnTjQbhuB7HIlgW8f9naONcGosNer8/Y /QsmxAZdMcXDa2HVKPHJZE2EoEqLKwtWZGme64eqRdZSUH+UxhRlWxD4NO2IdrxWOSk4S5KkPBZn zH8GWAHb5y5QbeORQBBtAXNc5yQIISiGr5OTvYY5DDohINksdoEct7HubBIJMqZYJjAfTZaYsZAI NT2VDboZD2IIsVxV9AgZToSVG4FlHyDSeBCGWi8yLxZHG7QI0O/4xIjskIC0c/io9w9H8TuPGWzN kz6N9z1cwt4trp8N+/PRow0+tifI/NGHCoN7OsHYo0oe+7E26M82gvAbd8bc5+NHY8q/gGj7h1ht OLw15id/B97DQ6b8uX/x0GcasDtu8vkIbJL93jEb9PrnyqcY+52+kA3+UHy3g7ivjViAEQGF4dLj n488bDzdWWy2L/7fo/vrJdeL7r78k4jDN+XGJZ/T0rO4NoPPR7cuSOVxz3/ji2RXpcC+Jj1fqRTL 4eHJnW9MMhJ0Mxr5/NkCa/2YPVkhNM7Gn79GDmQHQnV40nMQKuIgFtmIHgwLofJuBElj4mNWpL5D cZLDF0zUn8qxzYuZBeU2hxtF1LaUOxoZ5o8FEANM3qFWtjCGCw+wDLRdwpG5cE0kHYvklmq+/hlx f8lssGxG5FSK+FZCUlPuoNzZBv8T0U5Y8EtRQr/gSNUYGrfVsBR5uK/6cOEw7vmyXCcjBJ1JUqJw AMPKTWtimQw6dSZ6SGS+/j+RrQ8hFghoqb4g+ZiyUu2L6IxGTnQTDot6yzvkkKwIiAwH0/1QQnec sg9iLgwcEQcs5ZEbBURXZAX/qUvPasOfOu6soy5K0aQdEoykzBK5vdhCoN9wZUQsYHtiIuZKBWTW 2YSDOHQdlIjGz6g8j7Zg2oLlWjATEF2HB8PAY1sJIF1+ZFA/IPVO5ZgwZUDh0RuMzxjPhoW6aVtV RlootFDkCkXqSilatI3Wi4b6EQCQemZZrhVjACZgJJRvJQNgMTbMEuxlegBsXYR8RbBNN0qTAVi2 XgYKdliULlLCT8x2JbsQmDM+B/xF/QQ5SCug2IkRzAB0HCDcqq1h/dawK8XLA8ZEurZTzBnXwi7G 9csZHdZIdEa8crqGWtZbxLKWVFIo5RUV1hKhAKTAWKDAIHNHctHtpmuoKbGzy3O2sUYUxFIxOIGy joUVzhCjudF0hlY6ZD9BV0hNBaiYDikjCrJCFHgAfJFUT8qatamq31R1QjqyDdPKrWln9KY84kFc 7INYZLuKF1hXHM0zxr6vKQ4U2Wil+Co+5uv+ncRjRhqC1DUXO9RcSKKPDGDdRhHId6cBSgoCNKXP BpCL7xpw8VAwD1B+TaCQ9S0aic7WFCyK2tHWqgFf8yZAJ6U5wzTokFkBzYxG2zTQuXBmhCK5E1j/ wjRpP2eatD483Wm5vaQtlS1RLkx3NCzxlLNnA0WfE9+dA84OUD0MEZGzMIgLS0oLxCeYEzGHpVbv ab3WgF57t8tlaxpi8rnpZjrWOyQWMAoE+RLpx3vIBMwENeezZ1ke7aM2Onmb7Ef6DeVstHg0IB7K CRTcuaalA87rLo/ZRvyVCmHEpCSyDhJtFf45cFmUBdBYDzU4bQbDGIrRTlTBIyKIpJwNnTBgFVC2 XsuoltHc+p2uEM0MdZmBJvd/O3L/fCgGic2uoL8gSLiZdmQuh0R+Dfm4acZPAixWacs1YkFep7Ze GpvYjk10Y4LUMFXJAv5bSfMEKkCRxLfwtzX3bE6epvTcMH8Q6X8MIxSDpUKVEUp7ctqTy/XkJlZn oy3UmI4tDE/zCYpL5Tokl6asdUmxvt8iurFAM6TjHJVrRxeDFZHrhEOwTCouRQFk0kYsguJ725rO wgWn/9+wFpQfXDPPCmlJ2RhLAwE6i75DFj0m4h+3Xkqoi+dvAQ3eRDPeMeMC9ULWZkmtCiQrz5FN NB5yjEMKxiPJUFanXSntSuW6UuEM1IWd9aYA6aEQGEA1hkNZZhxSxOLNQmsO0fHR2IbaMUz1JKEZ ueFMC4aOt7fH2+4o5t5SrkvHfKlUQUOavwPUHaqr1FBOJ5oTt9k7fjo9BQEPqGed6Xuya8qWa9Ol TVeu6drATtsonDqZY+lkjk7mgE8ZTXbDXu8CvAQJKqyo+TYKb0HqDPV1VhxzXbO7FZqXQiKSAop4 lgDXwZgGJnYAJjL5jw6JRFwplI9tUwOnDMbgd0JK0I9Hg0C+y6k4cPoURaD9Pe3v5fp7a/2q3Jcu SYlsU/jFWIIWf3DM5H+cEVrHZgC88WoKyQBvLz4X6Gog7UBqB3LlQGZkv5GmsMsOTm3EuEYeztyx GEKXcDcTszwQUaJXEAPphCaiCXXKLmuLrC1yrkVOro1yWzpkj9+tqpG4f5KUlL+XKWYjBP/3KApB EybHMRjPrrUxY0KLhhaNXNEwMfbdCjaaEzokHMHMjWx0XdBM+wlYd8YI2R7QHJVlUxE2IzBBAqao AS0ZWjJyJWPkRuRrqJM12ygXqGUl9vsXSi2j4zzhJ6D6o5RxAG/knJynbA69EcfUReNvBkTScqjl MFcOV76PorbbKIgFMPyGgRKWaOKaUQAmOddhj24gxg/frNobmfwZZcVaQLSA5ApIhpSpQ5Ix5gHq nkaQAupyFyPoafS8cu1zloMIyLab7qSO3cukqHGnZ25lKbPrauR2Z+T2jmNwdK/3pXf28eaMMmUd nEM9d5/5A1hXvmHcHhdihHVYY6yLFmREQN8wIOgXKzDYLy76P/5lOfQGXEfMHqaZtSe9q5PB+VP/ 6npwdd3r/YPedYw53qWvPvt09unjZf/yTI7VTn4bPkO/o7/v7xCdFPgSseEK4W78ono0DTVe/OUE CWT0gZqYrxMwdMWEvmuj2RLqTXIUwD03MW4YVZ6UTPF869kw1RADdj7ZsyFplb2GO6ubkWxbtyY+ J7sQ35zBz31zaE5ZqoUKTYmom183kaT6FcXNWSUZBTGjYn30BfKkp5i5QEJf76PeuqB6lBtQVCbb Jk2ZXHcmT8T6l6iKpxF9MiiC3gSkDb/QddBHIp3D5KObdUrJUWuNSZY91pjnP7nGpAYKHoSuL9u2 vWgEKBvFCeLaGNIEkxZNV5ePOJVyxz9Z+h596V2efbynba3M77McJHKEq3RR+vjOLoU79kEorAc4 H/RVb5STJ08kV61eln7MgfQau6BWQT+CgDS5WeONSGmL3im+L+o7jxRUXPXw5+aItiXeae97uAQp 4uIa430/Hz3aqEh74i+hdKx9eRrr+3JV+iDquC+5Hqy6+m8pv1R950325WP5fZEXtGI5Wp/cp/JP KCVdiJD4v8qwsWF5+p2KH0hEWHdZQpocnIhYFNeQS7VPVYD9fnVCPqVw71pFtSAVOH56pPUt6JeP v8/7QuGLpTWxvhulWMcJENnCuoqohfAxsfIdFl4eFDgf1LXw4cbMmtyzKx+dps8OKl44FGQGBg9X g8GZMAOxivff2JQXjxFCEl0JJHKXWj6Ouvi0Pq3alzrEJKRncJNs9DZsCmB5hzl9iE0I4CmmhIGx Ky6Z23525X3K+iQtX4VidQkPAkWDxPaZjMNl76xTfkqxoVA5JzNAajYpIAwN9VxH0IQqFP5W+P6Y oVaKSM4cN8x+scjH0XBFfKGgMkAlSe6WNu/T9Mt73Wc1ODUt2JjyXvD5eR1RU8rO7+2QVm/nMU87 /MYdMDnx8aMx5V/AuvBD+MFhGx3Bj4x1xBF89N2Qm8QCnKtRFD9wj3Dg49rANmGGMt5t+/HHrYcw KO+Mn6W8nCYO4SnpV0VayQ1dVHbCMcDAxXgGoXTLlYXjnKp9UPK98q595b8435fIt+Zp2RvsEYr0 mpU9qpiIIy5JZIkaQOWU85z4Qfl4pb7rPRwtcWdNf+mJWe+UKPXdEW6yQ0lVYwoYDLc6ueQnMmWA UkfD/KHSheSuvHz4ct7wCbN3NE6IiFF87kWhTJTg1An65ifYnhPcgYXhj6nekzbh/fbzLx/q1Hj+ GzDrRqg22COQafoUH1e6UPQ2CZnFQChMLlgFJAg+RIW6+IByiJVrzCHNK6j5V+5wzuXjnPOzZvWx 8EiFdpL+HsqulxS2iuiSlPWIOtniyg+Ry6dGtuTfxXPchAw0H2AN2hlg5W7M/eXVeS+3TCsnzRB/ mByivdIvg/Jh3YVEMWvLMwzKRxZxcCzcxIp9xbYlGvJ9yF7vUwEqlPYjz8qHD/FlEJucBklT97I6 PHj45Hqu7U43StFiywtny53c+z4eLFx6qPRTciv4EN6g8r6zsv4zAlcJv2ysu0kc/MHmL5ZkK1VM Yp5DeVbela5RqK63P/8eDnEq+1j7Vc0Xy+0hz1l5l/c8p1CBUjS1iGT+Or+Q8wDiddT/2RgPB5cf 0ZFyxinwpbZnHY556pkaf5z8rWPvPI7+6dA9ob/ft2DXUoVJbd0z/mIirYK5gxtUYUiO3KbuoQhn Vp9ufDlD7tCoDhUPaEI0Cu6iskG5ZmWPCDeFArdELSPooWHZBqXk5mh1E7cEQdCcJiEjm+dbY9yt 7ZuxRxiYQmNbshmhOwW1CciTVFkZcYwR4DRvA2M+sV/BMgj5HDzqG6o9956Uj8cuUkhIS7aGxgHb HOtHzonGmlp+GBkyrSthLjmKam1kZMmnO5nYmMmOf8Q5YCbLPo/FD+G7cjaxCSUwnBOZHFSSY6rs A008TIFGgjgaoFAYEz85/ArAUhjdYSK/fpe27Zm7G2vZHSR4j+g4VdzUkmsaUDMyddkvSasFMxBs JvVOiRT73AZA+8xRtB45Fqk6dXOaOPFhrFIUPdvEg+RfPSmkyQbKed9ONB9RJTdtc6IPG3/84Xqy RePPkr+VLbhrCyucZaa1t+eqQcXFk+bhunIfqCsM7tgl9fyfyUUTs+mjHQ44UUqyG7GWoHAYYsAk poLDXBo2ajPGyJSB3Uo2PozhpJPZpH6Zqc+hxCOUQTFH6KO063VMVFHIKMXIdAE9FoE9q6rEWla3 /51OHrXOowCUv+KmEDm5FTXXDnenYiw1P7NSEiSPzzzeW1GLn7oGe4HkZ+UR6DpA8uY35nwPwLjm urXzstju1XUa0674xncke9Dv7ZA9OC8LKTeMog/vSndjJAq76Yp3RVXnxdfn5eHxi1QGuiXr/Bq4 FJa4TqZSL3fFZYHyj9eDghzOw+3Fl/t+xb0MQ6ULxdt+ouWRtfSJVqzHDD/EJLAdykTPy2JihA6u SyNqv5hDCpXdyfbj2QPQSglctcdT4KEKQG8DId++1D1AkZSkNbFU8FIAJzIFnItVY3CdQluBGdmy Um3KXaSIPYQZ7AOwpGkE9UOsfx8YKGJ8MMajDEbwK1ro8iegc8KT8cEUnaD+nGIc158aTkINQNHK wsA4YjzBajaxRc+gbDSClmo3ZhgjFfX+1oKbl0ohxRAptg3VRoRNEZFCFBKpCKOR5u4CGLMIdcWG 5/0kmmLyI4d0bcN5WR++YftQsHPK8eXZwYuyLjnWeZGvYGuxg/nrvEFpBhAZQScTN1LRWPt1CaKy DxmkppbnhmGIW0WbfxSoN+Uhcu9F2Tiolfc/1Ta42WKn7EEjd8Jo/hHqazNU1ppcOfy9Sf2lQjJp 4gT1nTcBay7KhqEI+GvAJFqwMXvEhNIy1FbqeVE2iMPZpYxXxR5U28CaYa/fZ+xXdww3ldgaFIFs JbPEDnH8Rdk4t+kA8UbZ9kQPpl3Pi7IxL251qlax4lvtOAhpMgn+3FWUjXCbPhhyGLefzR7BbG1n k+8bizjI4VM3tF71N2opRR7usMXlI6+GIR+kH3eAfC7LRlqqWNcOZRXcpgmkn6A7w1aEpXJAouBx TMOT018BsWQfqC1btupsVB4wT2lelo26cEdIb/5Dos+1L3hIZJXQm1ROhTuxaleluj5BsZzAWoE5 43OOlyWI6I65jX+s+V2TPtfgePse7eGwF5RJ1qLyCi4uD83T7S2sIJjGocq93JGuuj5foGBl5SHi y7J+PMCGFBqevva1gDn5Cz9GPzcVqSADYGygtbU/Y26ra+1Pkb9Ta+4igrnnxg+iL/1nZPkCJwdm LkezpnU71cihKwR1xSneI3QSE/WpojIaAXLy2orbstfcdGVxobJNudanbCyleijVBh75N+lUPfxk Vfi7YVjpco8grgb0JHdjYjOYXNgUUWkFeNvl3nFhbbDS5R5B3kHDSgPG/jfqmOEBwvgpaqaVsBLy s1/AICLIRG7BogffVbbBbu8jvexYcJqvNfOVZhqDuiobrCIKKehkaNDJvonBKpELpPx7DIOIWAUO ReaqKrXAtTz2kJqhIDatDV2xSWgSD0JyahV3LD+mzThf9ezhKops/DgLpK1EcHtVFgCA3KVMT2LC my44VKL8ZJZzelCn7J9Q0ADl9BJHTtFJZQP/Vuqk1Hj3ZKg1jTVFJxopAhpsCmBEgAMtUE9xKK8c TRMyXiBYynPlXpmy8AmuTIp0u3ZxGgaR57k+WhM3StAm6HpBvdjUdxcodCFjNrde+PhkpZXRJJNE ekF+fVNJ518NC94k2X5VHuiJsf1Knf8WbEzZ0BsXVeaVKt0YRf2WjWjxiKlS3GrRgRby9vbPwNtr gekOPl6rcu3D7WHO1R5BekpvVnvWBcbgCUggGgAi4dwLwwW/izjxgcbOORF8WMFcVASmEERRZSvP CAW54GtQTErlSS1UBUqeCJj+en9zwSaiSm7NPF/vEw0N03eDjUiokbtEqPLKmirbkOtllMWLoBkL SJd69/3Lm6p7SQrOPh40kMxZIBZHpPUMEKZR9Cdc+vXdiKH31SYJj8QYQ9eFlnqGuTu2B4xC5iQn z1nLjom2Dmt77cLHPWCTFt4EaEXqeIjmQCe25yg/7hGz1mYshpJ3QTZbYF1Tl1JOoKihJnmPm9YE zRueBfYPyjCFZAKKdHLeRf64R0zawgMXor9Vz33cI5pqUmoL9By5Axj/PGZg4JYUAQYGpcBPEPw8 LjHDiLRios3QYZK6EjvIwx5BTgrDacLggUooJfJ1O0Fj1/l//+f/qtq1cter4HLMjGecvsvE3wYx GLu+xX447sLmO7F4fdw7khMHX+3pD7GyiQXsIG3IVx5oW1GDj3tEnjUEx7moQeyOJMhRKpeaA6ek fJe9iCY+lg/T+jVsTBo1+LiHb1xbwWzrUIN8pdTrn+/Ap/Cxaz7196VjznzkjDEVW/E9MghzLSVd w80I/HU6aCVZWMsj5l+OHXokPpWPSvoFflstCx1+U65Dnt/9aY+Yo2BJKSVcIfW4nOItomSkesBY RZyhHqggCa7aHjB/Kh9nNHqE+Xd1xa8bWigGDo25R4kOymWshk9v+J6JJaWUZj23L+XsK/ewCbX0 2j4i8yNSQrSZFLyKPZSF2Mpz58pP+VAu9hyEg5o+lHrkJ983TXsan/YIu5pUCQVHu/3oygcY/QLI oR55uhH9IqBmACcwABdR78LkPCskvFXTn3tXy7v/W+5qcn0lkV4tFzj/tCG5JwF3ApDhIOwUEOv2 89/D6S+45/Wc/7vtSyofJLTvhJG7l6wwoAP3GVBz1/lA/z+ZUGPA2HOVbcgYk1ruIHFQ7PAQrZEO AqEdOV/qw5gyqcm/4g3NLidXeZSPihrVlvl6AmQ3AKQARTHQh2cOMW/V/d4eLn8q7E6uADld8dVM XqpRZw63+8X9XvlAoFHHGPmI3Tq/+r09XP7WHWHBdVa0UP4F3sNBbdTLAROVIOhHJV/MLr/DIsu7 rO2zewVHDNcOGbYVxEM8zTRxW9AwUz6Zsm1wf7b79f1eeYe3hRRVTCFwHHMxMZhaBRH9YuIpiv5o V0QsR7YOL2GOAvXDJe2UcTXLOH/HIESbHU9Q3vhDHaSC4lqq7it67SZ58Y7bqcg6+WQKtj7v9fr3 D8nH/40qQLT84utpflq/V96jH8hSskqr3ZI9nKNk68F3599oJtA9zkc+du9I/HYv2SRhHGkz336H 4zOiWLtEYiC9w+WDhDp3uOwepjmgci7kftvlP7gOGAPRXh2YlvX56BajQCy47r/xBV332Q3iso1X zUB9CVcC10YAh3R9HkHLmFwjvUifRETVN/okVztSUrr1df03ZDIVbitWsOJ0+60xP/k77DrKjZQ/ 9y+ehTSAmDpEI2BYv3fMBiLPp3zu90caFXX2R9aV3MvUd0r0GjmwkQ+9L0e/eth4svek3A9EpTey 5bYRhN8Aj4ELeUyX/QvmvfwQflaYH1h8pZE2Dg9P7nxjEouVIh6NLKPgYRNhvhmNfP5MNM5j9mSF Nk/eWP/918jhQgUoi9G+BI4T5M7fFK2deOCvhynaK0Ro92hj6tMTfwll8FJRhjtxfZuRveHgdKBI TQHrwPcQcwfifUiukHKvKvYGMEz2G+oAYPmpIV0FNwseGdFncw+cr4DXqbu/oYbh1ggyxGtaZf0s KqsZaS64dYw9EZt3IPNByCQDI7NG8KGpVyfF+U4voIif5igYnocpcSh5LaroOIir2rJT7IKingt+ wl2etFH9jFySQrSw4pmgUosVKwY6+gKGNkiwNE4s+J/oeiCRQZZaWaCWBcLuICxvjAoioCzUaMoB FHgATTst5oaBL3jQRkWhYIvRpfj715Nt24w+MNtuep/vMk9JUMRm5FO1h2rxUB1elXPYYrsaPe1h N440MMx55lQ3asrbsJkwBaARgR//R5yNnACNAcf7ylbETpeyFm0vtL0QqbJUBgy2bhjPNFfuSo4S wdy0eaM6pMBiTJD3lRHEmPDFU2UdB3HnD2KRLQuKvt3/r60mjSSmaScFtSCM3SS8ZYpsdEjG7yw5 wcBfXrMVhgWQQMRFi5kLeB7VSd9jpEGFFrV01G/2sj1BG05UG0QjAaS6KhSECTgcPh/xvmC85krK QWKViAsA7L/TmEWiO/8PYHEmOtiU9Wrp0NIhC6gyXuHENRFljJXL0iGLgWLWRzcQ3XY3AQKlgBI4 x1m91EjITnJrJBYZHRO2HdstFJYq261lU8tmrmwa0ylmV4tGZOXCdEg+RY10TNmyAJiX1Jq7YPkB oy65cysZARjumHYUoONOWa6WDy0fufKRme3WIbGAbbB8sF2B+pI6LnwkfaiekEZROxraQFXRjiX8 unISyYhXKt9fy3F1B9rAFJOvhXSsuTFnGwFMzPfl9hrXYIPT/mk/Uy6RivO0CUwaFKpNrRXAzaj/ VE6gwLg0jful5IIGSKOTC1U1Y59IC9CVTdYENwzEcpm1NBIQgUvBdVTcvmBX2yi+7CYQ8ApRBnDj 2fVRz6QyB2g/VfupuX6qz7M1PR2694aNwv8xZlgk04aCEACG4Y/RoDezQKxBBX2SnFM4te7CEcVP isbRoqFFI1c0OlLQV+AkCNMqqzEsh+QCk9xFtzhg+lRpKxOrxOAYIIJUF6hFQ7t2W+O2YbdFgyi7 RxzGwQOVIDmlcWpqQyyQuvrOOfv928Pt2fn5+R+U5tICogVku4CoerRDLpXMSHtiHo7RitBszEBt AssVEwKOeLjgHDwxqhkjRhRtv9LcCRqaSFFzZDLLwn4pmryNIjpUAYmDCFQOYpG6kLA0Tw5VCfd6 NB0vG6S0UXILYrJfExT00XdDF2UXwgdFmu116F1RVFpANFyRC1dQfka5KR0SDNFum4AUNHtx3aIo 6+opZEO8RsEaIRUUsGHMjhQitSdey4eWj1z5yMbuHRIPLy4jTNJm6xkQLOGPXvH4Z1RAI9k01zlm /4wwwfaY0QjVqa6ZUvjbKuJTea2gohMJ45jfdGOqbWfKKAiEMBL6WjcKMCGQ+ufleI3N+eo/PyGb Nsb1G+Pu1E5hQBmqKTw3S8nfIct8l8xqz0Rwg7ziKV2TsWZ21ehkMTopxlZgKHbGleuMGUQVkhBq kMjAIMp6YtOdw4vNKbM6CBNxEIvUqOaeqObFT9AeLUdziaBvF1OYDca1gNTuKGasSxNAQQFM3olg FWYts4Odsc9pcNUFguTRIBGArkJ61wNG15ydmMki+uGUBWuRrV1ku1H3v26aVO5Lh6I6ZBkmhmnZ Vgjy7XR7NFpC00ViK/BV4rPKcrV4aPHIzUMYKy4A5b60UTzAFWo5NDvQ9ZfsHS7/OrKjqYJxmAcB QWzn4GPBe4r4lGVpMdBikCsGyGVNrGkkZ5krV6aNklDgqZozbv6wUZ54ynStlu6MfqOZYK8l8rqD 7l+mOqMz8t1ErDnsbloxha2wBVFpTSwb82w268bOlH3Wpleb3lzTm7DOqYVTHTK7VAK2oiOgf+Qj GvQO8ZgEgp4uC9ho8dDikSseqQhf0addEhCXGtxiXjfqcZv5bjSdrTC+Oae6LCuYo8PtIfIhGv7c 9fmxsl4tIFpAcgUkq0k7JBhZiDueAQQLkbhUzDQ8Y0TYH83RBhJo2La7YNkBB824sGpJgBZQLaC5 Auo69lJR5R2SUOSaolFMv5iyxCSJMGk+DzFu+5mPYbie4N5l5FlZtBYPLR654gFWGOWidEg6IAIQ kKVjwqFzqMKYDBgPQFYK/u2c1zUqqVFJjUrGDRfUQXqFWquUnHRVD6zafajVJvKAf8BZhQ6Q7TZE 6rPuO1DWqI2iNoq5RpGAZeWmdMgqroK3delhIDhMz47FX+eMCpGJ1PQiW1vWSByXALCil3Wjb1eL qBbRXBHNFs12SEIBGe0K0isVViLqU9SSlg4tHbnSIVyiYNZdEoR0/GYviXvOmlu24dtoo87Ijxhd ERfuaunQhHTbCek6jNmvU7hG1nvbKLlvxVTmGJPJcEXmWOvm5/gW1LXB7Lqj0MB0Qx1boq2NLC75 HbHlhbTVPWS74Jw6MglAtWyKwcqRipZO+YVB/sX6wbMqqJEAktyBTOpD+AgBjwVW2eODcJn1IvO0 UqKq7vjEiOyQRhedYx7v/cNR/M4jvXTVw5+bI+rJj3Wc9z1cYqLt4vrZsD8fPdowBU/8JTwCj2as D/HXA6Z4gGn/+o0A5kTDHsRJYvuSs3msjbXVNoLwG9o2uM/Hjxjq9QXjE36IIw2Ht8b85O8oKUWj n/Ln/sWzfIDLd9zk8xH3Wb8HUK3XB3mH8ud3+kJ2/sfhaZ5GjnJE1ydcevzzkYeNJ8GE3MR+ihDk 5HrpcWWmZX0+uk3xbWBr9mjVf016vmKeke/w8OTONyYZCboZjXz+jOkLKMR7skKo1Y0/f40cLoTq 8KTnILT9QSyyET0YdjsyUgjiFOHvTmCEikkxT4OKtiJPdqgYcUFlqoAS2WmqS6P6lWiUWWoDvlA4 xPMqj6GFVGcWcjML3Z3lmxDHrnvON7NrMdKHksrDkwYt8vWLfHc6WD92e9qAGHLCAtOwZT/DMlsd ky6LSUpS1J5ALR/1y0cWYN7IcRE+3vRs3w6nE3doHE3JDDXIEdfJizH3bN0gp4LFmsgceOhvfJGg b1JZhMMOS0cmqyQm6AL+Re4AniNiN9DSLhmKUoD1UrynuIzNAABD8BKtKcfQBaE8k7Zg2oLlyuiC 27ZyUzoEuBhgVk4JIQQgJIkM9YgBS7f7vFE29ucgIfpEE3w9o9ssY5DvW9e2uZiAyr7FHX/U0pB6 +Ua8e02Voopa0wZQG8BcA0icOcpN6ZABlNCGqIKWw4GnkRXMRJW0rBZFAWPSGYuuCVhLwRBkhXyO jISyai0fWj5y5QMTp+1orCrTDokIR3s4GH8yFAoAkzyOjgJmjcHXak2WQmYsNRHWUBwnZDMhLdIy mq7K00BLPtAyirI3NxctvXfGceViUhRVX81dUYEClfAmJsp0I3tM9CaB9FVB8gDnLhl7zya+C7OF zxtmGBlq1KrNlzZfueZrzsOZq3Jxd8h6wWeDJJs8CFgUEIEdGPkjG33ethCEWHB0xlrCHYOHq8Hg LCnp/pYq9lbf+TeKvS2waC6urfHno37vI/0mI8L9QuXyL1ZgsF9AHuj8y3LoDeKi+HxEFcInvauT wflT/+N17+y61/tHrIMrKhvH06We8dO+zygK3CuscgeuMhycnokwHoXVc6LNT/hJ2VcH0crcCC3X YWJYfNYNwhJlK9JGia960lvuQPxh8SVSf+5S8J/a336v/P6eJ3cANivTUpX+5v6+37w6uXD43eMm EaAIC7uxy2mfWESSH0R0KP6ztRs+2Hdb4spwOmZyFuRxpzdcKI5y4iyPcr3hRUWYf2J/cyyklBxS 5ICx3NF/A8US/+nzCdoQHJMfr2ZYJwMlgmP29bG1B3Fe2UFc7PvN2w+i/OQg+s5waIzHyP4FXE2q bXUk5A8fMx6aGza6NSrsct/t3ipRV/t+8y4H+Sf2a8LeS24Rjse1nzmRP4WuzYF0I06YjzBawwoR 5jv4gBA0SF1rRWoPh2JHY7KHG7CrbqMmjnfKlhaIRbpWRwoGP53u8oPrsFX+2CkLjDmHbmSxWErf GGccLjDHLYkd0YaycP0fwXvld0D3t0XyBpU5D4M3cB6Kbdn3eFIeIcq+66KTB1Yt4IaPMTAB+4DK d3tsGv549VprD6AyZ0JGIdU4E4z9id0IZmaglrjvyHnT1EJ5AEBMlgvQmHNSeYSVhD6HawF1iBdb q/kGlTkTg0qdiX3diRCs84pQFKjMjOYrEElDHH/i6tvcUEm6X9V4tzeD/r3YfUHl8HrI/G+HS4Py vsYAUbMMmV8NlwYV+hp/YnfIETLbmvDQguGZGw5aTSliZe9sF63Cz+RifEBxJFqEZdAKH59iqRKm p/gg1HcEdvHvH0RlrsagvKsRH/F2py8+iG2Ss0F+E3sb3gyH5hugtN/Ke5xhpBFfUCB97yQ1jKpb EdnLX/qcqUVK3ij4MtEHtyxxbeqFO84q81jOKvVYfnHdYBV8I8vg2ejwR6IhXHDuEMI6jkyYR8o2 YB5fEOGaKJfsVRVa8xFU5rOcVQiAZHyWVdZVAE4irwMHJrFgyXm09ggq81bOKvRWKF4ODbHh5Jxb jlCE7IQFkAWbn4DhJEKGAQqLzVHmbMUvtPYQyrsSvd2C5bNKXYnbZKzKEqO7pm4IPgRCuU/YYgY/ ThwP0VlQHBUgnppTjSu8+dYeQ2WOxFl5RyI+4O2OxL5+e0w1WYpbs0W247wy831eqfl+9F1MXzYA khN4LmTkROSK4nak67ZKx3llxvq8YmP9GI0wz5cwA2mrQ5CvmmB+CVZ8+iBa86OAILZwZlFi47i1 Suq8MoN9XqHBJmBVudgFIMEmripxJyuEaYHc4Gh2+ZoYa2iTuqrMxJ9XaOLJ1X1ANmKWJPtIXykH 0KYtrsx8n1dqvoUzi7oeNlrCcbLMmbQKC3hLU9x4yv6M2TvrlCNXwO3Jic896Ck+3pjs2JZcwEVl pvmiQtO8v4pKDkQRjAIFtxsKiptgTKc+nxqh6wPxls2a8BfQxYzhMJSCbS2uclHeTxh82gkXvajY T/jFNRXEUznPVxWdCmumC3XUd94G8Lwo7wIM+rvtcHkXID67HeIUIJ7cBvYsb3MmdZ1gicOSIGPo hoadfOXuB/Zwe/HlXiiTbKpAfeeNDqy88T/rJQeGnamsug7olDu5932U+EneyQwPRaqk6KK8mxFf utXVqK7iffj115Pen/+snP9OCri6RyoAxdfu1DVL4hKUhVNORrQ+0TDAIHBNSS1JA5xk5pNyNVRs 5VtToF0xzJKUB6D3Y1VPLrI6+KQYnRHrMyqtRcXcmPKofzkhnlcgZe4KHg4E29vcABH2GDV2ATAc ADUjNwrjwlybPycBK6VhxdOODKrhBdpjoQrFjHyq+4LVcsYfqDdrykvUCKk6snLtWd5NrEMYYV88 khSQ7UkmeuJ4Ld6Z3kPv7otwS0mBvZGaKu/m1rEzShHwZXnf8kKq0hrUUL7MD07P1dg3cSXUhZV3 bePNFwvLuTXi9co6KYa/WoGpVDwr2jd/jeVdwzPpuDSzxvzzZO+Esv1L5DgGnHOkOVHtClhblqpA QYKxf+qyJQ9L+OjFkq6+IyQ9fok2ZRdudyeaxxXC9rONiyL433uych/vfR0nr/Vj0pvVD8TmMeUG XJb3weMj3FZheVneq00LAG1GQV9WqqN+hzta3gVO31HxGKAhzeUnSISipK6v6AaI015cl74Beziz u0Ufl+VdzLOBcJMV9SD7AFMyUnAtnlLdetmGcuGLxd3CrFzbrdLyeszQzphub2LBzEDDEykNcvXg g81RgiOaocZw0cwQvhx/4WaEkl8HntTqRcNDoh8el8ihTZHVpx4TlMytvuJUDE/3Ih8EocJXBJQt Z0nHzRIM//R8a274Fn6JKDOmUgHxdJ4bUu8wQinQLhnmD3BCmYAegIPT88/wS8nxQ4mqRa4nPjYC MjWxMKN6oto2OC+JKdo4h9fI1o1REProhaRaBvpVSRslHYy5JspYubmp12RXHP2Uzwk4sW13QV8z RwMTm9j8xYoLDOH9ztxF+uuwIxZxwNFu5pClFgNqqkhucVlTV7F2db2HsytFaqu63sNZTNny3dQ1 pAO3Wdw59Zr9FJr0qrwvu2Pa/2oPZ1K28wlNKo3YTVpSEnmMecHlwVAAiJiUJC/nswF7J+HspcXR Ch1LLH5GVGcE70lhQQBXYe8IUxSglaAWUXwIkIjiSygeWFKhZkgrpKQ+eSDEsahAFToWam/VgSRj WnwXvoh6KfBVUg97roVaRzx26rsozKZod2Y8C/3jIlDG7AeoI8l8nlJI3C8R2JaqptpvYE/KNbsq 713X0cOZ6+zUvDPlndbGdobGNvWEYticR5dY1lRlc+snP204BKl7Xh36NjwDyeuN+cNxFzYfywJn NXOcey1/ts0/iEU2c8MKsAEmvHBZtIDuekECYtOIQVg26pT4wb4Y/gjkdQCCgaACP/irNWdf4Nkb omT3ZmzMs0HqJi74s93Tlh2hcgAFeYR0pUqilxtnoPkV0/ueQaiBuIf62dDMwUUoRBFmZlGZMK0e rfz/2bu2nraRKPxXRrxskQJKCBSC1GhTYLW0W4qAqg9VH5xkAlYTm7WdUPbX73dmHMdj7CYOtceJ p1LvXOyZcz/f+Q4A6YFnI6UMwyyRog5pvZYaVWWc+QLWs/0qYUx3caXrQwQHl72rHrg2HXRPCGJD PS9FQ2px/rV4yYo5F5n08gklmYKN0EehD7YalBo+UlRXSKZqDmtxTbV4ST2y2D2CwbtFUdmj4U5j 9FI67Sai/g3bVDMaLUBWCqM3dAeibwGUyYhQ9lGhX2Fzuu2dfaLkHTQM08FDA/gSNC7q55r1WIrM rFa5gIzwXHNK1EXZGF2rXANNlTplUcf2OdaxoMEmIWHukI/RhANOL3BRsAYsi3qFnuX4hAFX1aJS 7zKxnlHJV6TGOPjCMpqNVlvpDTaZ1tTjgtBUzn6PPW4NqYlv+6LMAU4bZ4ghZcwiSzfow0jRmCyo hQzvb1MzJbZioSrq1x7s+4cxfm4sLzYkXqYeREixqLfIxi15CgK3CEgKBX8sghaj76rcj/EgxoOk 7eYjtjbsAQGTuqcKTIZCL4awKlO5F4Fd5CqEQhDaC5AlkQ8tV4P3zfZJT/S5M/vGGL8hUHniI2PN ZPV/BNQ0/CdChKyCXQo7uohacbKCWfo4L6zz+HQxDoaQtrDZlzhyIi/mE894vAAeCsxMUZrZ90Ik VpdkQCDSnk4n4BC4c28s8HWJpCs67LzYzOhF8BUcEFG+26Ev3e60OydvW8D64nvPv1v0PfKiNKPv Ic4JX+algBZ6gtlVCUWrwHIek9q8uDm8pCR3y37J8M1VLSz0zfFCd/xnxvtjEKh5TCAJwciPomDg ueNT0SYMP09InKSYxr/Qk+K3SAzy4v9wQnLMs4In1L0DkFbSImPGOgxWKNUGXnZmDQTFWsahQCml NorTetmXVG3qjdIiTpWIuYIUbJdP8oIPo/sTNqE4uyxPcy5mJ3mRjIq1icnrSV50XPS+FZTXzHwf qMZ4hA1eE6AmF6WkzEqSQGGSOdw2Kc+L/ItuvVwpXyNIWgQgcSlfI5KprFVeLuUsZIf5T07ERokj PBm1F1zMpyKvFBMB0YfK+vC2yfkagV9EulBklJ2w5q+KHeNyvkZ8toFyHqICMIgj8kMx001EVnLy R0ZuZOHj20/6nMBV4Wf+TmEvIiCJJWEn+QPKcPqrVFPdWSNuSjXVnTUimw0UYeAQ52I7FKiW5ZZX mYvuvC5uKzS/ysisVKjlImuPCXsnf1wSH3ad5wgym4jVaIpD1Kc74yV506vC0eiT1fOEt9JxqRmR hlJCSL/q/LFdcqC4uFvtUr6QSRGtKmL+0DIusjru7IXgVEZvRlNHNgHnRQZ7zO85Ov2IWRWR0iTt qXGz+mTpwp4/DtUg7CpuIv1F8keqcWmvjKBR3FgFgVpFdvLH9CXKDiA4M1s9ynTBWSOMjRHUVEZw 1CQj4rP/RaZB68oWoV76hePIlpZIi80zDuRwpXTnK606PT5tl7zqFItWc26bwzPqFSKqoIPWmma4 R3w+UYHl1p6LfVqCgx80C/iIAMP8KM28IWyn4LIQH1E9CwW/q0EVu653bzm2LGcBBAiNuucuSPke wQvLwMhGSCKcn0ospClGiCpqsvgm5vitMebx0XLiSwfOSklauginYLEwaQl+bwEPYFyyfQjw8QR8 ujOKuubSOICAEvgSUTF1w7B6EbsLjHCG+3/6nvtDnIjsKBDtLbg5QEnIE4uB5o6xCtY+f/mgDGu/ yslUpVV40MxfrCgbwnHQXCPLTjCeFJdlp9dOLp2IUKmRsKVJk6PBFaU/s8P5UBSfQxsP+5oaGorp Y9+degAXMGtm2WMRGgDOROVq7sxsz3WIdYkmMZ2QQgbrF4YwxmqlxQczC9hjwOQSdXf6YJyByRZ7 p9kb+oLJ89JRbIhHxsnnqcz9RQ2FXdFQkLu7zRnChXlpwMKoi7IrStfBHBGjK+K6g6yHdGfRsgAx Q6/qDFiV5nRx+OMUwyKg9R0BT6i+RdJNy16dQJUBIQmZlQC+txIFphDTvn5cLhb/5QAWFgU7SfXH r3/JGKtCBV7yRU4Te7zinF/3LWz8jVxYDm+gmMZaHHstXlKbbLUUgcoAfOueTIQGXLneBInybGMB 6kaFIVzzQI5w9MY9FDoy/u1yb5lqI64Zj3Xr9vm+ndTpROmwHDcbqJvSUyyhOC6tsy/dzbhS3xqo JGwVPUxwlE5sxx2798/fFV0xIUdR4zhZkB/aHhb9+GqNxdV4vMHO9xssomVrsB7++rflecDoBS5W edF/Ewbgap+dWRNVPcwt6r1F3BEPGmznbqFmglcvYtLpgaPY96mMtdNggsZOvcAss6HbZdl8A52F 0Qat2qD4lxTBTmwO0xICkd/eiznFvebhKo+tNSRKr7ODOt31ftD4L3AnWATp+7twI5iUBzTg8EUV 7yWkYttyE6P85Sv/JiVgG+jPUmxoJfLZTUl+QLmzN1CXUWsqQiIINOmXbiKfKPliTE2/RHp1vq9k XTtw+XIRyDyWV+IE423K9zax+7t2fWJyAQXkPL3CvtIL2siCcXwsefmCn2cgz/dN1vWb2VGwQi9R ojOqoFUVFLOUEjFUJuuS3hg6udc8XuWhNyXn6sHkjE3WhcgKxG03pu01sO13xba9bv46O2i1Ot8Z e+9ZQ4dWxNyiSLzzkT9jnwwQcqIGCX2j6kBC1bRUXfDAAhJ46QxtLBxXm2HGf2j1Hzdy8zuVqNk/ YBYeU8z0/uyatQ4bDBfHSNSosgQGPdbqdI5NbWk7rVwt9NC8ZOin00YH4ktqzdbAdLwvtWC/irZf LB3FHy9+PmJHgc/O+YBP+vjcVrMhgkL1w9i3a+uesyNTDSqnGtSneCd4fgRt5SMOPtxeLxkLt78n oqXa+asd3pdUonF4sHdOG91U1ej1+7SODuHhkN3ZAWZBX/z4MHW4UColqDU2fVtsei1uUotSBsDY HyhaU9FSkZj2wmrKTUdCJ85aS9o94h53BmagwpSlTi2/lLJU+/DwEGWphPADoOKOLrxFKFaJLvY1 Zv5XelCtheguAUJFg/LDPrsdPLjcebL4eEhFv53Pclj23B6Fqo4h2OCJc0d5L+NVtRbYLp3QnWGh zyexrUv2m63ACv+OghsV2kh5sOzbcqaWJ/jEo2FSc4NabxCEQG1T9dzOqqeeaDwD0snYNxiCo4Mm 9XYUG17NaD39NW6xdMRHnt9g1+hKLXuNSsQCHx9c37Nm9koPqzUeSD9yTIzgqD+BGAq/bsqhX1me 9WypsUqKnFdgJq3BPuJQaQjng+oHUh6X8BahhBi3rdFtJ1RZRwKerqvLLXslTOIdFlK6iUNMT+S0 2sMu0qArJD00C4EHkZDNGCzwzdVFb/eUfcbK3JnNn0iJlZcyOqpRR4n149/pfLd3mAZR+IM0SJb6 myeqwa3FddXiJfUE3t3eNHhwvT981pPLvOpnDIx0lW/xrixn8CzGtyV2oH5Sp0fdsyIwdmb7A5fd PiNPnahVYKMe5atH++ioGV7JV8uUPsuBxmTzVKCAwz64PqgpznqMdY5abXVI2qhI+Sry5bZ+PsPI WflydjEBE+8pcwbW5Akwxz8H5Cj3B+7EiN9WzrbUQsfMSyL8pumsjUd9m5s0N8lH1nQc0KBh5YcU jLgacTXiGmM3rQDHudFJo5P10sn/AQAA///sWN1PwjAQ/1eaPWvo5gBDHAny4ZNmARMfjA9lO0bj ti5tceBf77UD2YKvJsa0D+vHffS6XnvXHw0p9ecLj9QjqXgaRx6lQ4pl4o3v6lEVS1ut9CEH5Plg eeTFOePlM+y11zNE2fDIhSi1Qh6mEs4jbyp2koMkT1Ab7dtJqS5HE9VlRIW9o0as7eymtjYcTVwa E5tysnoZy5bdJ74ZbNgu14biFul20rlr96i5M9m+odzF0wQAd7ua0OdCiEsGXMZjUz+X1rnctZXJ uzjp4uT5ieji5B+Nk+ikp73pvI1/8b1ej3Km9BLKFCSkMcvgXgJ7txCBHk9Zcf3Cyww06ZT5vuIS FJlBAsUa4QKfXpGA+mGHi5BXo5AM3gw8oBuQwH4voYHuW///QAMKEh1/7+olqvHjSlco1IJGLI6S rT7RN+rI84MgpCbX3WK7f4ttu1lV9sjMPFpUOB42LJJnW9Tk92lgJNZCa1GcyTlsGqpv9QFDJ4i8 YWDVb4TQrW6207Z7nC4RuUGNVMUSaESsFalIHiRPkZLzEmKuE7TyZmCF0Aeav2FdYC3Sg22gyK6A Uo+/AAAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUx LnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdht h2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlA k7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWM FbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT 2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60r WwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIG ZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4 GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJ X9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfV eFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+ FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxU WmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurY dZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4o HFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkv I7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxHal1Cq nQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2EO1l0u1wE9O2vuVt4kuwRCPP5 jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrIDWmaZAn7RNCHQb3OnA5JcWJK I3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2NhyZd2WNhUx8YbD2QWO3ywA6v 6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3DrVAZfDivGgwW1oQGBEHbAlZe hfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA2KnwkT7knWK1EreWJvsG3M7i pDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp2xvDmRYe4xS8LnXPh1kIF0O+Ejbs T01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQWAizRnKz8y00w60UpYCP9NaRYWYNg+Nek ADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV35 9srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+KSfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIj na9tjwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm +k4hVs/2LkuSZYRMRJXElakVe0QOCRvqGriq93YPRRDqpppkZcDgTsaf+55l0CjUTU4535waUuy9 Ngf+6c7HJjMo5dZh09Dk9i9ErNhV7XqzPN97y4roiVmb1cizApiVtoJWlvavKcI5t1pbseY0Xm7m woEX5zWGwaIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnT Zq2Ttlq+WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn91 4qN74OgtuN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQUAAYACAAAACEA6ro7gTUD AACVBwAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFXbbtswDH0fsH8w/Lw0snOt0bSI02QXtNtQrx8g 20oiVDdIStzs60fZVt1gXlEsL5HOIY8okqKvbp45C45EGyrFIowuUBgQUciSit0ifPy1GczDwFgs SsykIIvwREx4c/3xw1WVGGItmJkAJIRJ5CI8aJGYYk84NgNOCy2N3NpBIXkit1takPYvbD30Itxb q5LhsHW6kIoIUNtKzbE1F1Lvho3nrSwOnAg7jBGaDjVh2ELAZk+V8Wr8f9XgqL0XOb51iSNn3q6K 0FuW7XUrqcsXj/eE5xyUlgUxBjLLWXNdjqnwMoa9R6fJ5x3NNdanVyLXULbfUvKgShTRBSQUao5Q OHQEHCy3mcWWAG0UYaxugoIRDMdXyU5jzjEUrUFqH6tx8fRAjtT1j6mhkmzxgdlfOM+sVOB3xBDz LG5PKfYYfCzRmcIFHLCSwmrJvF0pv0u7klxpyEETF/SPwrbWhjYtjYvVLR6ktN4NodEy2qC48XBs x6B1NF1GvcwG3aaXfUy8mcXxqI/59zljhKL1ps9nhuC37GMu0wkaz3uZVTS9bHN2fp8UjebL3thS NB3N131q6RJN07SPWS3jaD3uY25X0WzSG8F6Ohuj3gg2q0m6rnM9bIoE1eKJe2E/tV9toOIBb9pi hXmuKQ7u3RuEEvMk108pFZ7PCcwC8prJDrknB4OGMBwztoGu8gQ8v4YpqVG3ZFsLs3usd51yfTGe 6F4Uevjbi5p7JkR/1vKgGtVKY/VVlAD7A6PxuNWjwt5R7nFzyDPvJeApvqIOovxx1E5w2CWoSixM T+IydIfFzvcwEYPHzJlWScF05iYsucdKwfMBk3wXLUJGd3sbuWdqYVdi/VRv8l3ccnHNwc5x9QYX 7mZg3S6cQbMEq3bRYSOPjTps7LFxh008NumwqcemDtufYPbAbHmCSeaXDt9KxmRFyi8eXIR/QU0S zB4rAnV1cwYaTCY10A4eExwT8gyDjZTUwsdL0ZLj50UYo6aZW2uGT/Jgz2ydkjNWZ2hQYothTNal OnOG0sGgPI+lSkpSUGjI7MTzbqxdNIEzamxGFExAKzVcuR6Nn2rl7nt6/QcAAP//AwBQSwMEFAAG AAgAAAAhABUysb2nDQAAQHcAAA8AAAB3b3JkL3N0eWxlcy54bWzcXdty2zgSfd+q/QeV3mdsS7Zk u0aZcpxkk6qMk4md2meKoi3GFKklqTier59G40LwArIhwM54d6vGEUjioG+nQRBN/vb7j00y+h7l RZyli/HRr4fjUZSG2SpO7xbjrzfvfjkdj4oySFdBkqXRYvwYFePfX/37X789nBflYxIVI+ggLc7z xXhdltvzg4MiXEeboPg120YpHLvN8k1Qws/87iC7vY3D6E0W7jZRWh5MDg9nB3mUBCWAF+t4W4xF bw+U3h6yfLXNszAqChjtJuH9bYI4Hb+C4a2y8E10G+ySsmA/88+5+Cl+4Z93WVoWo4fzoAjj+AYG DiJu4jTL31+kRTyGI1FQlBdFHHQeXLOzOo+ExWJ8E29AP1fRw+hLtgnS8QGDLP6CTr8HyWI8mciW SzaEWlsSpHeyLUp/+XqtD2UxVk3LeBXLn9D9Acop/2rybmvSwy8cyjYIQXOAE9yWEVgQDMJwkphZ ejKfyR9fdgk0BLsyYyMGEOyA/1Ug8LOhcjAsmPmauwkcjW4/ZuF9tLou4cBijFjQ+PXD5zzO8rh8 XIzPzhgmNF5Hm/h9vFpFzCtF29d0Ha+i/66j9GsRrar2P9+hj4kew2yXljD82RzdIClWb3+E0Zb5 GHSdBszEV+yChHVbaDg4oF1cjYY3NFCx8X8S8ojbsBNlHQUsjkY4/l4glHrnDDRhEukCYL9WY526 d3Hs3sWJexfovG66mLuPAtjT1SLcNzSvpBu1zELufLoepmc9LsuuaHnR4BUtpxm8ouUjg1e0XGLw ipYHDF7RMvjgFS37Dl7RMmfvFWGAxNX0oulJjw1v4jKJ2BW9lHPkSG6C90efgzy4y4PtesRyaXOg ffR4vVuWtKEige5Pj9dlnqV3gxqBfMyCdW8WfrvZroMihknMgOonjqq/CZZJNPpPHq8GoU64u7Vk wqlIZ9L6nARhtM6SVZSPbqIf3KIW119lo2s+rxgcnKNZP8Z363J0vcYkOwg2MyjdrAne/8e4QB30 BtPMIMpQ5yQbzgx+ae78j2gV7zZSNYT5x4wzuIWZGxA4xH4VHTMTtaNrUApmAIoIPEHYi4D9E8bP 04l9/8zGlPHz5LNn/4Tx81S1Z//oH/32tWaaN0F+PyKF19w6di+zJMtvd4mMgUF6mFtHsIKgiWAd xKp/EknMrSO4Rp+jizCEezWKn1rbouJRCxRrc3AUDDa6LNZGadDekYVE1gZqYE0ssNy41gLImnS/ RN9jttZkmwyQpdVcczCcpwYNQAoi3Q7/ucvK4Tn0xMB5VJQPKSyQFNGIhjY1RB4VTfgTz3cWNnZL fBZAbhnQAsgtFVoAGfzDPOdROZEO4p4cLbCsaVllMXQ7MjPPrZlZAdmlAE95kzD/MkSv2RfaeZOA Ym2gdt4koFhbp5HLVN4kYHnLmwQsQ9Yw20jnVBuhrPOmDqRmAgSJ/JA3AcgPeROA/JA3AcidvIdB /JE3AcuaGxSn6uRNAMJTbG71FZBO3gQga27gbCfWjGTew176b249kDcBxdpAbfImoFhbx0TeBCw8 xcYTGliK6ghYfsibAOSHvAlAfsibAOSHvAlAfsibAORO3sMg/sibgGXNDYpTdfImAFnTgwLSyZsA hKfYcEMneWPUPzl5E1CsDdQmbwKKtXUahKomqQQsawM1sBR5E7DwFBtnEFjo3DZC+SFvgkR+yJsA 5Ie8CUB+yJsA5E7ewyD+yJuAZc0NilN18iYAWdODAtLJmwBkzQ2d5I3B+OTkTUCxNlCbvAko1tZp EKriOQKWtYEaWIq8CVjoL87kTQDCU/YFspHID3kTJPJD3gQgP+RNAHIn72EQf+RNwLLmBsWpOnkT gKzpQQHp5E0AsuaGTvLGGHly8iagWBuoTd4EFGvrNAhVkTcBy9pADSxFdQQsP+RNAELHdCZvAhCe sgcQRpGNmfyQN0EiP+RNAHIn72EQf+RNwLLmBsWpOnkTgKzpQQHp5E0AsuYGts8W9ouSt6ceGZyA us9A7mogA04MRqICCgG/RLdRDsVL0fDuEEdAKaEFosE9qCK+zrL7EW1j99TgIGSoeJnEGW7pfsRd OlrpwXTet+/80+XoPS95aV2HLlXfeQP1QnqBEBYksVIhGGf5uIUina3cWc56g5IgVsolin6w9OwD lACJQh52MavsgROxjEo043NbgYr/hjK3lTzn8PDs8mh2dsglMpVE4YMfURB1rH50F0SJ4qtajdcx 7774S6vxwjYQH0rSsJoKpRmQX0ksNHyExU26zFW1EYq6DKBG6hMreWppJIVt3V3tIOa9bJcwl+sg 5yJUNSTyHFFIYqXg+yjaXgE+jrFQBWjLCOoEweYTrmNRjwZ7tvG8bFcyE3z8nkhoPMAL0JjiUJPw p7OcL/jWU87HDr4VJX7Mz2oVfdWVXKX8v5cF/r2PcqXdqSrlkwOsWirD8zZHw0+Mhhdj8GP4CcHw 1dwfFVKfcWHTz3ANLDn5ua4Ro/CxcBSt4vO0gw2wzdEppkanmHJEP04xfbFOgbHxc51Cc4NZhxtg m6MbHBvdQKQhP25w/GLdAKOh5QZLDNfl84XridFOoq7Pj51Ont9O+2d0OSkSEzGR0eumMfLqUwXU zGgogejHULOXZCh0UXoMqZlRNQ/iLz5w5Dpe3d81ARb3KH5MM39JppE5RL6eYZ8bi1Ojy4vJix+9 nr4kvaJHtVxeZyNHZz4zKl3cY/lR+tlLUrqcF9cTwhPf4mmTNAfiCuGmOQjhlSo9Kxeifl6VNGH1 fHMdw1Bkz2+31LqMvOcUxfZDt2XgqwZiKFlhec+YsfC8d8llhKfw6W3HgoHw5qERqiItFLRcJvx9 NfCPDylbv4HXA+FSDF8nWv0IOCAcv4yS5I8gZ3oss6351CS6ZUsg0NHRIS6uN7paZmWZbczX51h7 buwAVKwPhv/sX+1Jd5tllMPrYnr0f5WxRekWV0DJPbYb3ALeqYNHhrRu9ouaP4e7AlRzzZbqmqtx tUWjpi+Lg6OjUcVCDVrrjAkce9fSlNHL+AHzWt//12qRpXH4wo7JOBNPxhHk2UEBnb74z7KVnthr i7kOyzeWVuIrLSYrTT1ZSSwOvUwraana4fbP0i586cNkl2NPdhGrNUa7DIbLEknT74qGpab44oNJ UyeeNCXWS4yaauQ8S8UZieD5HI4vDZjUOPOkRiHPk6gRphUDD7osPYvfkptUMvekErGK4E0lGl2J 8N7nmaClqvhdtklVp55UJdKiN1UZw+75FMfvlE2KO/OkODEx96a4J705Ho7j2gN79cCa71poqpK3 8jTl9qQae7rseUwNb7pDHKuHkdSF7G8h3CTiE3b2/hy440eof/wD64maysrhuzywprJSZapOd3CN Ks2n2iElvWBwCvCkQfRwXp+a6ZsI/NqkOxjVOxebBlAHfISk7Kw3KsVq1Z5R2dghQg3Dn7A5YJg3 qeFTU6vJgK5BJEE4kXXEkbDbz46jJ5hPqZQlXhjaUjF/j2hXhJhXrtoalO/9pnl+x4NQS49SYqkN mU3B1AFn0axSbe86XO0l7LVdWdURPlz8rz5nHNZPNzleZfLNpU0FaS817VKRvt2wbW8rohM60e8N 3LaNsZVh9ZChtXSMm5yrw/bCwYvW8CKaM4tnOTGu4rM1+MV4Dm/DxR5CeH0wbAzcBYmwArSCJfd6 lslfqNa0Im8dkpGyOxJ76stu8GY4C7UIozMfHvZdaraoxtipB9c8oSmz7fJS/MEkwcPWD5d3B7XY q82H29SE3MitCdN4JKGHNsUzdLg+B4GX+Vk4iCFuYO6OD6JUFMl4UTtilwgitWy/BYPqbC2xezXt 6ns6Gldj2wWlggddsK4ieTs0QV6zjEaVadkkKolUWm0qgx+uKjLQSG0RoBDDwkc0Enk4D9n7b6Us Jxfs/+y5Ysm+cIKFJ4sxI1usg8DGm5h9NONCbu7BzkB6lIgNH//BesCt+TW3UFILsxjFFscbcjcC zmomtU9q7bM3e9qjBYnIbTupSPadGXhADkZxc4yqbsTgGdUJ6AAOKpruoyIKH8O7vP2pRXhGJXZT L9J1qjOcFSMeUdImLiK4uO+01eNRFazShy9kNHWg1QA5Cy+e/FkJ/ywLIzJVSd/iPNwVl8Mh2D0h uPl0KbYitGbDcEhVMHWpWO5v4LRsmg60iVx+4qPxNMq1YKK9yogJAxSz16QZvvwQp/jJh6bn4RH+ NYgutehzJH2jhuqwbyIkd6d0KKOeuueH8L8LrnoRjnWPXIwv4TNiWRIULNXhLWO9iX2TS52CgmiR LHiyxv/YNuxntWzYsz2mrg+zkl2nRwqHK6vtj1LnL0XB3YH8OkiSLOv2WHHM3me1TileOxzRdR2/ PpyeXgjyNTjxTbCGr8VpLlw14Efl+OGG+x51PJHmbf7ct6mapgPrOnd1YQ1ryIkbJnhh+laT58ts wz6KWE1wmuoN0jSDD+exz9jlqtK5i45tZtCSCRpKHCTjDj+uuNTFGbtDXSinMzlpemG3NNxdGjNm U4bS+n2maK+0JNe9ahkHVwX8hWxTvqZPieNIk64hq2H5Dlk/Sut1Lbgl/xaF7b21mncV4pSumGsJ r08OWwf1SZI4KPCfyQuXXAasePPubbooJocT55h9TtNZpROz3nx7XL+CQGXI28WrvwEAAP//AwBQ SwMEFAAGAAgAAAAhAHQ/OXrCAAAAKAEAAB4ACAFjdXN0b21YbWwvX3JlbHMvaXRlbTEueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEz8GKAjEMBuC74DuU3J3OeBCR 6XhZFryJuOC1dDIzxWlTmij69hZPKyzsMQn5/qTdP8Ks7pjZUzTQVDUojI56H0cDP+fv1RYUi429 nSmigScy7Lvloj3hbKUs8eQTq6JENjCJpJ3W7CYMlitKGMtkoByslDKPOll3tSPqdV1vdP5tQPdh qkNvIB/6BtT5mUry/zYNg3f4Re4WMMofEdrdWChcwnzMlLjINo8oBrxgeLeaqtwLumv1x3/dCwAA //8DAFBLAwQUAAYACAAAACEA/S092wEDAADADQAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbMxXSW7b MBTdF+gdDO0TDR4rRAni2EZTtEGBuuialuiYKAeBpOR4m8v0CD1WrtBPUVI8AIElp4A3lv1nPv73 9X1188RoJ8dSEcEjx7/0nA7msUgIf4ycn/PZxcjpKI14gqjgOHI2WDk31x8/XK1DnrEFlmDYgRhc hTmoV1qnoeuqeIUZUpcixRyUSyEZ0vBTProMyd9ZehELliJNFoQSvXEDzxs4ZRgROZnkYRnigpFY CiWW2riEYrkkMS4flYc8Jq/1nIg4Y5jrIqMrMYUaBFcrkqoqGmsbDY64qoLkbx0iZ7SyW6fHZEsk WgPOjNqy10ImqRQxVgqkE6usI/reW7lLAE2I2uOYEnZzVpUwRHgdxrTH3v3Xl3cJl+fa3K4J9XoQ wOIamgktlJYo1g8Z6+z8uk8ixytMuCIJ6HJEI2cwGk/9vhc4rnFmGdXkK84xnW9SXNmsNgtJkm9G R43O2mqW0spi7A2m08l4YDU0NwoCD5MRvuqUxsCJ2cQbB1NbA1BB6sp9aP2ABzNWCxcZpVjXEef4 qVa9PP+t5V/iKgrFy9I8/S7NaQg3xzTiyBkGRSUrxB8LRnYHngnhrsPSWFofORNcK3BDKiYkcn5s 2EJAl61DjJS+VQTNgZFwQYxwIT/fApZGuTJftq1jFTl3QAhBERACDAiHKhK8RABjmblICRUAUKbc bdj8V9i8nvfJ87xucXU7sPkWhKNhE01B83u9dqjdiUwSLDsPeL2Fzp7UQrRr2Ayl4AClfiGBuQTj yIxR/3TUXp7/NMUt8KG7zKU37bZf0JvmjWFbxvbUrqwZQN0DgGxjvTNAjdkYjEbtAHql4wHjGjKs dwCNBetdoWnMOBhL7YDZ41aJzp70dMZZfhXjvJxL58G4XrflfN9l1+mMg+2ret+VAJ0H4/pQTauR 9H6MGx5Acw6M6w9bzuo9bv0vxsHfhr2GOg/GDXotR/jpjIOVaWvLNasTrECAEnyaJde+87cs7s0a WGy71c4HlsXuB0/7z+v6HwAAAP//AwBQSwMEFAAGAAgAAAAhAOTkHdDhAAAAVQEAABgAKABjdXN0 b21YbWwvaXRlbVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAnJDBasMwDIbvg72D0d21m2ypW+KUpKHQ69hgV9dxEkNsB9spG2PvPoeduuNO4pOQvh+Vxw8z oZvyQTvLYbuhgJSVrtN24PD2esYMUIjCdmJyVnGwDo7V40PZhUMnogjReXWJyqDU0KleWg5fRcHq /LmhmLaswU85y3C92+eY1edtcaobtttn34CS2qYzgcMY43wgJMhRGRE2blY2DXvnjYgJ/UBc32up WicXo2wkGaUFkUvSm3czQbXm+d1+UX24xzXa4vV/LVd9nbQbvJjHTyBVSf6oVr57RfUDAAD//wMA UEsDBBQABgAIAAAAIQCMhuiDUgEAAIcCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMkl9PwyAUxd9N/A4N7y20m39C2i5Rs6ctMXFG4xuB u41YKAFcNz+9tN1qpz74SM+5P865NJ/tVRXtwDpZ6wKlCUERaF4LqTcFel7N41sUOc+0YFWtoUAH cGhWXl7k3FBeW3i0tQHrJbgokLSj3BRo672hGDu+BcVcEhw6iOvaKubD0W6wYfydbQBnhFxjBZ4J 5hlugbEZiOiIFHxAmg9bdQDBMVSgQHuH0yTF314PVrk/Bzpl5FTSH0zodIw7Zgvei4N77+RgbJom aSZdjJA/xa/LxVNXNZa63RUHVOaCU26B+dqWC+lYtAjd9KfUOR4p7RYr5vwyLHwtQdwdfpp/G9oZ CzvZvlg5yfH4GG7tSvZXg4hCbNqXPCkvk/uH1RyVGUmnMbmJs+kqS2l2TQl5a7Odzbc1+g/qmPCf xIxeZefEE6DsEp//OuUXAAAA//8DAFBLAwQUAAYACAAAACEAhdp+sJgAAADoAAAAEwAoAGN1c3Rv bVhtbC9pdGVtMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArI+9 CsIwFEZ3wXcIeYCmODiEtlBQJxEhi4NLkt40gfyU5Bbs2xtEfALH73xw4HSKi7RmDYUI8KARJoGb h54+x/vYPMSVkg+4yVBhZeTiDFpynhy6FCl5BR8LVz21iAtnrGgLQZYmLRDrZ1IOEuvMM0vGOA2n pNcAEdmhbY9MOeVdmrNc7PaV/UU1dOyXNux3bwAAAP//AwBQSwMEFAAGAAgAAAAhAAGt7W46AgAA OQkAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWy8lV2PojAUhu83mf9Aej9DQfArg5MZVy/3YtfNXlcs 0oS2pAdl/Pd7CojriJnBbJQo8bSctg/vec/zy7vMnD03ILSKiPdEicNVrDdCbSPye7V8HBMHCqY2 LNOKR+TAgbzMHr49l9NEqwIcfF7B1EQkLYp86roQp1wyeNI5VziWaCNZgX/N1tVJImL+Xcc7yVXh +pQOXcMzVuDakIocSJOt/Eq2UptNbnTMAXCzMqvzSSYUmTW7c8qpYhJ3/esg1zqr4jlTGriHQ3uW RYSGeHnUx++IDvEe0hFxbYI4ZQZ40U7063DCpMgOx6jRkql6IBdFnB7je2YEW2e8HgKxxYEdrCku 2HxIHfEQ+nnEv5gzOI/EVZ7xP09hBPO0mXH7bv16LkDMWSbWRnSS8OkST+9XV0AHeA+6SdAuElAK gF4kFvbg/nJ5IhFg4HXeRk4kJs2cThLVub1JlacHCdSczhhcQfGGYpjciELqDTddqkjEO99cSqIb xPJuIHZGcOP84OUVFiMUQ83CyiPoJYveLKwmXlsJoKznGBmNg0EjgV6iqPN8XRQrITlYEs7PqrBt /Xw0DFsgQyQSIgnLY9CLR3/DWFwj4t2DyB/0VtsMuuskrGrv7KfbMjrNk+0K3csxjgudHOO+3inR OtmVIrFiqEVhxdHPO28TxaV30qAtnFOZYEeves9/9M4VS7E8roCwzmnbh62PoCeI25qIv2iP3fjF kIZvH6vD/6yJeNT71C+avgqzvwAAAP//AwBQSwMEFAAGAAgAAAAhAF5rYnE5AQAApQIAABQAAAB3 b3JkL3dlYlNldHRpbmdzLnhtbJRSTW/CMAy9T9p/qHIfKQiNraJFQojTThv7ASFxaaQkjpLQDn79 TMs29nEYpzh+z86zX+aLN2uyFkLU6Eo2HuUsAydRabcr2etmfffAspiEU8Kgg5IdILJFdXsz74oO ti+QEjFjRl1cLELJmpR8wXmUDVgRR+jBEVZjsCLRNew41rWWsEK5t+ASn+T5PQ9gRCIFsdE+snO3 7j/dOgzKB5QQIwmxZuhnhXasIo1Kt/F8Zl2hFY04nU0exo+zybQnbFEdVrolsBWGUMZPdCvCE9Tp I5t/Zp/1rvkjvUH/m7vElND+yJOgpQqnN9JXjaPVMiLGY8nIAAq8kLTsPpZokBYr9gkHGeZC2XWV 22+KrqsNl5NfU8p7F/qhh7CaD2dvDPqkrT7CGsMyYBchkAGEX3yu6h0AAP//AwBQSwMEFAAGAAgA AAAhABik7nj9AQAA/AMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAnFNdb9owFH2ftP8Q5XnFBFoGyLiaqKZu2lok0vbZc27AamJb9iUr+/W7 Tkoatj2Np3M/dHw494Rfv9RV0oAP2ppVmo3GaQJG2UKb3Sp9yD9fzNMkoDSFrKyBVXqEkF6L9+/4 xlsHHjWEhChMWKV7RLdkLKg91DKMaGxoUlpfS6TS75gtS63gxqpDDQbZZDyeMXhBMAUUF64nTDvG ZYP/S1pYFfWFx/zoSLDgOdSukgjiLsqpRoXFmrO+y3OLssp1DWI2pn5f8Y3cQRDZJWcd4k/WF0FM 5osFZx3m6730UiGZKLLZ1eSKs0GHf3Ku0koiGSy+a+VtsCUm960VSWTgbLjCyZ4tqIPXeBSkZVjy b9pENdOPnHWQ9Hm589Ltg5jOo8i+5FslK1iTDaKUVQDO3hr8FmQ88UZqEs0bXDag0Pok6F905Ema /JABonmrtJFeS4NkYlzrihZXLqAXucaKuGnW1S0crg2xvhRZu0DgfDESdBpocK6ufSHcl/Tf8B9i s6HYVkMndSBnAPs3/mBd29pJcxRfD0ZTrpM7wJ/WP4cPyRejRnTR13k8wXN4cLm9iXF6dfa8OQjE k8b91kkVr7aYzmfDaAxmfEsRgoJufWJ8a/BbOoOv4rMUK7OD4rTz9yCG7bH7mEU2GY3p16br1KOA 9F+Z+A0AAP//AwBQSwECLQAUAAYACAAAACEA4Q+Ov40BAAApBgAAEwAAAAAAAAAAAAAAAAAAAAAA W0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAA AAAAAMYDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDX5gieIAEAAEQEAAAcAAAAAAAAAAAA AAAAAOoGAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAPnrmEEM RgAAFMADABEAAAAAAAAAAAAAAAAATAkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAh AJa1reKWBgAAUBsAABUAAAAAAAAAAAAAAAAAh08AAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQIt ABQABgAIAAAAIQDqujuBNQMAAJUHAAARAAAAAAAAAAAAAAAAAFBWAAB3b3JkL3NldHRpbmdzLnht bFBLAQItABQABgAIAAAAIQAVMrG9pw0AAEB3AAAPAAAAAAAAAAAAAAAAALRZAAB3b3JkL3N0eWxl cy54bWxQSwECLQAUAAYACAAAACEAdD85esIAAAAoAQAAHgAAAAAAAAAAAAAAAACIZwAAY3VzdG9t WG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAP0tPdsBAwAAwA0AABIAAAAA AAAAAAAAAAAAjmkAAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQDk5B3Q4QAAAFUB AAAYAAAAAAAAAAAAAAAAAL9sAABjdXN0b21YbWwvaXRlbVByb3BzMS54bWxQSwECLQAUAAYACAAA ACEAjIbog1IBAACHAgAAEQAAAAAAAAAAAAAAAAD+bQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAU AAYACAAAACEAhdp+sJgAAADoAAAAEwAAAAAAAAAAAAAAAACHcAAAY3VzdG9tWG1sL2l0ZW0xLnht bFBLAQItABQABgAIAAAAIQABre1uOgIAADkJAAASAAAAAAAAAAAAAAAAAHhxAAB3b3JkL2ZvbnRU YWJsZS54bWxQSwECLQAUAAYACAAAACEAXmticTkBAAClAgAAFAAAAAAAAAAAAAAAAADicwAAd29y ZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAGKTueP0BAAD8AwAAEAAAAAAAAAAAAAAA AABNdQAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADwAPANQDAACAeAAAAAA= --_002_8a8388169eae4492b8c2bc15de28d16dBY2PR05MB550namprd05pro_-- From nobody Thu Jul 24 16:02:24 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D175B1A03BC for ; Thu, 24 Jul 2014 16:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 K001XnVmvtsH for ; Thu, 24 Jul 2014 16:02:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614591A02E8 for ; Thu, 24 Jul 2014 16:02:17 -0700 (PDT) Received: from BY2PR05MB550.namprd05.prod.outlook.com (10.141.220.151) by BY2PR05MB549.namprd05.prod.outlook.com (10.141.220.147) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 23:02:15 +0000 Received: from BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) by BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) with mapi id 15.00.0990.007; Thu, 24 Jul 2014 23:02:15 +0000 From: Lisa Lorenzin To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Notes from Information Model Discussion Thread-Index: AQHPp35GLa3Dg1BdjE6CCzEmdg0x5ZuvueyAgAASHgCAAAcG8A== Date: Thu, 24 Jul 2014 23:02:14 +0000 Message-ID: References: <53D1778B.6040608@ThreatGuard.com> <02d901cfa78d$8457fd20$8d07f760$@comcast.net> In-Reply-To: <02d901cfa78d$8457fd20$8d07f760$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(377454003)(199002)(13464003)(189002)(54356999)(106116001)(50986999)(74316001)(2656002)(81542001)(20776003)(99396002)(21056001)(74662001)(83322001)(31966008)(86362001)(19580405001)(4396001)(77982001)(33646002)(87936001)(95666004)(105586002)(19580395003)(106356001)(107046002)(83072002)(46102001)(99286002)(64706001)(76482001)(80022001)(74502001)(85306003)(76576001)(81342001)(101416001)(92566001)(107886001)(66066001)(79102001)(76176999)(15975445006)(85852003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB549; H:BY2PR05MB550.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/gnUajvhHLloGOkXbBjoN-1Ai2WY Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:02:19 -0000 Hi David, I believe we've agreed in previous discussions that we will standardize and require data format(s) and transport protocol(s) that will be mandatory to implement, to ensure interoperability, but include extensibility points to accommodate participants choosing other data format(s) and transport protocol(s). If desired, I can dig through the notes so far and see if I can find a citation for that decision. :) Regards, Lisa -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington Sent: Thursday, July 24, 2014 6:21 PM To: sacm@ietf.org Subject: Re: [sacm] Notes from Information Model Discussion > > > Is it anticipated that a SACM participant not be required to implement, > at a minimum, a common query method and data model? > > If it is allowed that SACM participants can interact using a free choice > of method, that then leads to two possibilities: > > 1) A consumer can only make queries of endpoints for which it has > implemented the matching query method. Portions of the network will, > therefore, be inaccessible to it. > > 2) Every consumer has to implement every possible query method. > > > If every participant can interact using a free choice of method, leading to non-interoperability, that raises the question: Why are we doing this in the IETF? David Harrington dbharrington@comcast.net +1-603-828-1401 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From nobody Thu Jul 24 16:02:25 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2A41A041D for ; Thu, 24 Jul 2014 16:02:20 -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 MRoPQiCVp0u4 for ; Thu, 24 Jul 2014 16:02:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B351D1A0311 for ; Thu, 24 Jul 2014 16:02:17 -0700 (PDT) Received: from BY2PR05MB551.namprd05.prod.outlook.com (10.141.220.152) by BY2PR05MB646.namprd05.prod.outlook.com (10.141.217.149) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 23:02:16 +0000 Received: from BY2PR05MB550.namprd05.prod.outlook.com (10.141.220.151) by BY2PR05MB551.namprd05.prod.outlook.com (10.141.220.152) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 23:02:14 +0000 Received: from BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) by BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) with mapi id 15.00.0990.007; Thu, 24 Jul 2014 23:02:14 +0000 From: Lisa Lorenzin To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Notes from Information Model Discussion Thread-Index: AQHPp35GLa3Dg1BdjE6CCzEmdg0x5ZuvyISAgAAJcGA= Date: Thu, 24 Jul 2014 23:02:13 +0000 Message-ID: <38c9e1fcadc14482b61996eb889f72ba@BY2PR05MB550.namprd05.prod.outlook.com> References: <02cb01cfa78b$c1580e60$44082b20$@comcast.net> In-Reply-To: <02cb01cfa78b$c1580e60$44082b20$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(13464003)(377454003)(52604005)(86362001)(74662001)(87936001)(50986999)(64706001)(81342001)(19580405001)(80022001)(99396002)(92566001)(19625735002)(74502001)(105586002)(83322001)(15202345003)(74316001)(101416001)(31966008)(19580395003)(107886001)(21056001)(83072002)(95666004)(81542001)(66066001)(99286002)(2656002)(107046002)(76482001)(85852003)(77982001)(85306003)(106356001)(76176999)(54356999)(4396001)(20776003)(106116001)(15975445006)(46102001)(79102001)(33646002)(76576001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB551; H:BY2PR05MB550.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/qOpEv8jLfFe2QfXwoL0dbsQlU1s Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:02:20 -0000 Hi David, I agree with your concern about creating our own definition of a term that's already in wide use with a different meaning! However, in the architecture discussions, we've envisioned that the control plane could operate in one of several modes - so far we've identified: * broker - CP receives a request from a consumer and returns instructions to the consumer on how to obtain requested data from appropriate provider(s) * proxy - CP receives a request from a consumer, gathers the information from appropriate provider(s), and returns the information to the consumer itself * repository - providers publish information directly to the CP; CP receives a request from a consumer and returns information from its store of published data as the three primary modes. So we need to find a term that encompasses more than just the broker mode... Regards, Lisa -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington Sent: Thursday, July 24, 2014 6:08 PM To: sacm@ietf.org Subject: Re: [sacm] Notes from Information Model Discussion Hi, I'm a bit concerned that this WG has chosen to use the term "Control Plane"= . SACM is about configuration (charter: Standardized protocols to collect, ve= rify, and update system security configurations) and continuous monitoring, That would seem to put it into the management plane (which many consider a = subset of the control plane). Defining part of the management plane as being the "control plane" seems a = poor choice of terminology. I tried to find the definition in the terminology draft, but it's not there= . I tried to find it in the use cases draft but it's not there. I finally found it in one of the architecture drafts. Since the IETF is all about the Internet, "control plane" seems a term of a= rt related to routing and networking, such as OSPF and BGP. Recognizing that I might not know about non-router usages, I looked up "con= trol plane" in Wikipedia, which redirects "control plane" to "routing contr= ol plane". I checked a few other web sites that discuss control plane versus managemen= t plane. http://blog.ipspace.net/2013/08/management-control-and-data-planes-in.html = http://whatis.techtarget.com/definition/plane-in-networking http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/security= /configuration/guide/syssec_cg41crs_chapter7.html http://en.wikipedia.org/wiki/Telecommunications_network This group's use of control plane appears to be slightly different than the= rest of the networking industry. It appears a SACM "control plane" is a broker for AAA services, so why not = call it a AAA broker? David Harrington dbharrington@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam W. Montville Sent: Thursday, July 24, 2014 4:31 PM To: sacm@ietf.org Subject: [sacm] Notes from Information Model Discussion All: This morning a few of us attempted a deeper dive on the "Ice Station Zebra"= usage scenario to gain better understanding of the data that would be requ= ired between two SACM participants. Before getting into that, toward the end of the meeting we found ourselves = asking what success looks like. We seemed to generally agreed that success= is getting the Control Plane, Data Plane, and essential configuration asse= ssment items in place. This would include information models needed for Co= ntrol Plane administration/configuration and configuration assessment. The following "things that we should do" and "things we need to discuss" ar= e based on the "Frame Of Reference" bit below (thanks for sharing your note= s Lisa!) and on notes I took. If others have things to add or alter, pleas= e do so. Some things that we should do: * Pick term, define it in terminology draft, use it - a comment was h= eard that we tend to switch around on terminology, so let's try to pick one= , document it, and stick with it. * We should work on security considerations for authentication and de= legation of authentication * We should not preclude ecosystem possibilities, but we should be ex= plicit about what we intend to standardize and what we intend to restrict (= thus drawing a line between what we will do and what we will leave to be po= ssible in the future). * Define taxonomy or functional taxonomy in the terminology document Things we need to discuss: * We need to have a discussion about authorization. There is authori= zation at the Control Plane level, but are there more granular authorizatio= ns for which we need to provide? What provides that more granular authoriz= ation (i.e. Control Plane, Provider, delegate, something else)? * How do we define that we need a service to provide a taxonomy of, f= or example, enterprise-relevant tags? We believe this should go into the a= rchitecture draft. * How can queries be filtered? Concrete list, wildcard, metadata cha= racteristics... And, does the Provider do the filtering or the Proxy or... * One way to allow Providers to announce the availability of a functi= onal taxonomy is to use a registry with some standard entries, but with ext= ension guidance for unimagined functional taxonomies Prior to participation, registration must occur. 1. Registration (station endpoint management system, university admin) 1. Each client publishes its capabilities ("I know this stuff"= ) 2. So far, no data about any assets has been exchanged 2. Endpoints are provisioned into endpoint management database 1. Device identity information that's important to SACM 2. Not traveling over a SACM transport 3. Administrator constructs a query 1. I want to consume information you have about assets I'm int= erested in 2. Method of query is based on what the provider registered as= capability 1. Can ask me over the grid or by this direct RESTful = API, etc. Control Plane: Does: * Capture Capability announcements * Provides auth capability (protocol TBD) * Provides resource to find capability providers Capability Definition * Provider and/or consumer data * Ability to exchange taxonomy (language about schemas provid= ed) * Optional/MAY * Data transfer protocol(s) * Data model(s) * Authentication protocol(s) - direct, indirect/SSO Regards, Adam From nobody Thu Jul 24 16:37:52 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC59E1A0648 for ; Thu, 24 Jul 2014 16:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RP_MATCHES_RCVD=-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 XIpLM8TmHh0Y for ; Thu, 24 Jul 2014 16:37:49 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id C58E81A0AD1 for ; Thu, 24 Jul 2014 16:37:47 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id WNGp1o0020SCNGk59PdnHx; Thu, 24 Jul 2014 23:37:47 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta09.westchester.pa.mail.comcast.net with comcast id WPdm1o00l2yZEBF3VPdncc; Thu, 24 Jul 2014 23:37:47 +0000 From: "David Harrington" To: "'Waltermire, David A.'" , References: <53D1778B.6040608@ThreatGuard.com>, <02d901cfa78d$8457fd20$8d07f760$@comcast.net> In-Reply-To: Date: Thu, 24 Jul 2014 19:37:45 -0400 Message-ID: <02e901cfa798$45855fb0$d0901f10$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEnMYsIYCFNAvViO32qDF9t+jszHgFe1AmkANRzi+YB8ygtNJzflxzg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406245067; bh=w+g87JjMiDa5Ho1dZKwioQtsWnIRb6Ws80IbsnKfVPs=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=enFBPpV/4lhMi0alDJZezZ4qy8xzUmPeaHcozl+vdr+KfuIKH3yEeGPKMZbmtx1XB Lo9Bk+pL1nApFF43CtbXG450kXSicPindzuzwIe0x5A0Sm3XrxY1d4C8tVhCicL5Lc 8EYjKuEVGmcFfLWEFJm3Q5+x1rKdWK8BACQdyRsvjTvfxwLAGCTAG6NT/CLp/dNtPX 3QAeLNp0gfHr4Rq7aQi+Y3jxaBoTcOwrpG2G4y2QM1BMzFlNHeOvjNZNC2HmuuJS72 /aUPjr1szjDC4z0hu6u1LNLNm/6Mio88nPGfNQjmLNQrFrAnqj9/xK01ftfrMGHgVW wxMyDavZd7sbg== Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/GD4ye1LJGeBeunP7bTYSWmzNaMI Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:37:51 -0000 Hi, What's an MTI transport? MTI does not appear to be mentioned in any of the sacm documents. Assuming (thanks Wikipedia) you mean message type indicator, that would still imply 1) interoperability between nodes only with matching query mechanisms (i.e., not vendor-neutral interoperability), or 2) everybody has to implement everything. If you sent me a message in Russian, and had a language indicator that told me it was Russian, I still wouldn't be able to read the message. David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Thursday, July 24, 2014 6:49 PM > To: David Harrington; sacm@ietf.org > Subject: Re: [sacm] Notes from Information Model Discussion > > Or... > > 3) we define MTI transports and data formats to enable interop. > > Dave > > David Harrington wrote: > > > > > > > Is it anticipated that a SACM participant not be required to implement, > > at a minimum, a common query method and data model? > > > > If it is allowed that SACM participants can interact using a free choice > > of method, that then leads to two possibilities: > > > > 1) A consumer can only make queries of endpoints for which it has > > implemented the matching query method. Portions of the network will, > > therefore, be inaccessible to it. > > > > 2) Every consumer has to implement every possible query method. > > > > > > > If every participant can interact using a free choice of method, leading to > non-interoperability, that raises the question: > Why are we doing this in the IETF? > > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From nobody Thu Jul 24 17:15:51 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA7F1A04BA for ; Thu, 24 Jul 2014 17:15:47 -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, HTML_MESSAGE=0.001, 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 fvngGYUxkclt for ; Thu, 24 Jul 2014 17:15:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D231A028E for ; Thu, 24 Jul 2014 17:15:44 -0700 (PDT) Received: from BY2PR05MB550.namprd05.prod.outlook.com (10.141.220.151) by BY2PR05MB550.namprd05.prod.outlook.com (10.141.220.151) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 00:15:41 +0000 Received: from BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) by BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) with mapi id 15.00.0990.007; Fri, 25 Jul 2014 00:15:41 +0000 From: Lisa Lorenzin To: "dbharrington@comcast.net" , "david.waltermire@nist.gov" , "sacm@ietf.org" Thread-Topic: [sacm] Notes from Information Model Discussion Thread-Index: AQHPp35GLa3Dg1BdjE6CCzEmdg0x5ZuvueyAgAASHgCAAAfWAIAADa2AgAAKmdg= Date: Fri, 25 Jul 2014 00:15:40 +0000 Message-ID: <531F0F95-4510-42A7-B380-4973D7E283EA@juniper.net> References: <53D1778B.6040608@ThreatGuard.com>, <02d901cfa78d$8457fd20$8d07f760$@comcast.net> , <02e901cfa798$45855fb0$d0901f10$@comcast.net> In-Reply-To: <02e901cfa798$45855fb0$d0901f10$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [::] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(24454002)(377454003)(189002)(199002)(13464003)(92566001)(64706001)(106356001)(93886003)(83716003)(33656002)(87936001)(85852003)(92726001)(21056001)(20776003)(31966008)(86362001)(2201001)(76482001)(19625215002)(105586002)(74662001)(107886001)(81342001)(99286002)(2656002)(83322001)(80022001)(46102001)(19580405001)(16236675004)(99396002)(83072002)(4396001)(50986999)(81542001)(79102001)(106116001)(85306003)(107046002)(19580395003)(101416001)(77982001)(82746002)(36756003)(74502001)(15975445006)(54356999)(76176999)(95666004)(19617315012)(104396001)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB550; H:BY2PR05MB550.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_531F0F95451042A7B3804973D7E283EAjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/lF00it1y6SLPISNJmmVC8GoTYQo Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:15:47 -0000 --_000_531F0F95451042A7B3804973D7E283EAjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read it as Mandatory To Implement... Regards, Lisa Please pardon brevity - sent from my HTC EVO running Junos Pulse ----- Reply message ----- From: "David Harrington" Date: Thu, Jul 24, 2014 19:37 Subject: [sacm] Notes from Information Model Discussion To: "'Waltermire, David A.'" , "sacm@i= etf.org" Hi, What's an MTI transport? MTI does not appear to be mentioned in any of the sacm documents. Assuming (thanks Wikipedia) you mean message type indicator, that would still imply 1) interoperability between nodes only with matching query mechanisms (i.e., not vendor-neutral interoperability), or 2) everybody has to implement everything. If you sent me a message in Russian, and had a language indicator that told me it was Russian, I still wouldn't be able to read the message. David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Thursday, July 24, 2014 6:49 PM > To: David Harrington; sacm@ietf.org > Subject: Re: [sacm] Notes from Information Model Discussion > > Or... > > 3) we define MTI transports and data formats to enable interop. > > Dave > > David Harrington wrote: > > > > > > > Is it anticipated that a SACM participant not be required to implement, > > at a minimum, a common query method and data model? > > > > If it is allowed that SACM participants can interact using a free choic= e > > of method, that then leads to two possibilities: > > > > 1) A consumer can only make queries of endpoints for which it has > > implemented the matching query method. Portions of the network will, > > therefore, be inaccessible to it. > > > > 2) Every consumer has to implement every possible query method. > > > > > > > If every participant can interact using a free choice of method, leading to > non-interoperability, that raises the question: > Why are we doing this in the IETF? > > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_531F0F95451042A7B3804973D7E283EAjunipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I read it as Mandatory To Implement...

Regards,
Lisa

Please pardon brevity - sent from my HTC EVO running Junos Pulse

----- Reply message -----
From: "David Harrington" <dbharrington@comcast.net>
Date: Thu, Jul 24, 2014 19:37
Subject: [sacm] Notes from Information Model Discussion
To: "&apos;Waltermire, David A.&apos;" <david.waltermi= re@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>

Hi,

What's an MTI transport?
MTI does not appear to be mentioned in any of the sacm documents.

Assuming (thanks Wikipedia) you mean message type indicator, that would
still imply 1) interoperability between nodes only with matching query
mechanisms (i.e., not vendor-neutral interoperability), or 2) everybody has=
to implement everything.
If you sent me a message in Russian, and had a language indicator that told=
me it was Russian, I still wouldn't be able to read the message.

David Harrington
dbharrington@comcast.net
+1-603-828-1401

> -----Original Message-----
> From: Waltermire, David A. [mailto:david.waltermire@nist.gov]
> Sent: Thursday, July 24, 2014 6:49 PM
> To: David Harrington; sacm@ietf.org
> Subject: Re: [sacm] Notes from Information Model Discussion
>
> Or...
>
> 3) we define MTI transports and data formats to enable interop.
>
> Dave
>
> David Harrington <dbharrington@comcast.net> wrote:
>
>
> > > <FrameOfReference>
> > Is it anticipated that a SACM participant not be required to impl= ement,
> > at a minimum, a common query method and data model?
> >
> > If it is allowed that SACM participants can interact using a free= choice
> > of method, that then leads to two possibilities:
> >
> > 1) A consumer can only make queries of endpoints for which it has=
> > implemented the matching query method.  Portions of the netw= ork will,
> > therefore, be inaccessible to it.
> >
> > 2) Every consumer has to implement every possible query method. > >
> > > </FrameOfReference>
>
> If every participant can interact using a free choice of method, leadi= ng
to
> non-interoperability, that raises the question:
> Why are we doing this in the IETF?
>
>
> David Harrington
> dbharrington@comcast.net
> +1-603-828-1401
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.iet= f.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org= /mailman/listinfo/sacm
 --_000_531F0F95451042A7B3804973D7E283EAjunipernet_-- From nobody Thu Jul 24 17:28:53 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E8B1A055D for ; Thu, 24 Jul 2014 17:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 TjeXqnYHNNG9 for ; Thu, 24 Jul 2014 17:28:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752671A03C8 for ; Thu, 24 Jul 2014 17:28:45 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0221.namprd09.prod.outlook.com (25.160.92.143) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 00:28:43 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0990.007; Fri, 25 Jul 2014 00:28:44 +0000 From: "Waltermire, David A." To: Lisa Lorenzin , David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Notes from Information Model Discussion Thread-Index: AQHPp35H3v41bPjSXEih5Cr54kkdv5uvueyAgAASHgCAAAfW1IAADa2AgAAKmACAAAOmNA== Date: Fri, 25 Jul 2014 00:28:43 +0000 Message-ID: <9fg9n5u3ngtsu9kw1olqvg2w.1406248050858@email.android.com> References: <53D1778B.6040608@ThreatGuard.com>, <02d901cfa78d$8457fd20$8d07f760$@comcast.net> , <02e901cfa798$45855fb0$d0901f10$@comcast.net>, <531F0F95-4510-42A7-B380-4973D7E283EA@juniper.net> In-Reply-To: <531F0F95-4510-42A7-B380-4973D7E283EA@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:144:7452:6252:fe12:14b0] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(189002)(51704005)(199002)(164054003)(377454003)(24454002)(99286002)(54356999)(106356001)(46102001)(76176999)(107046002)(76482001)(74502001)(95246002)(99396002)(92726001)(16236675004)(50986999)(106116001)(74662001)(85306003)(77096002)(92566001)(95666004)(19625215002)(93886003)(81542001)(19580405001)(19580395003)(81342001)(83322001)(2656002)(101416001)(79102001)(86362001)(87936001)(77982001)(83072002)(15975445006)(19617315012)(107886001)(31966008)(33646002)(20776003)(105586002)(85852003)(63666003)(64706001)(21056001)(1941001)(80022001)(4396001)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0221; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9fg9n5u3ngtsu9kw1olqvg2w1406248050858emailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/uVTPRsDmFnylNZ96DPMr_F0pfP0 Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:28:52 -0000 --_000_9fg9n5u3ngtsu9kw1olqvg2w1406248050858emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mandatory to implement is what I intended. Thanks, Dave Lisa Lorenzin wrote: I read it as Mandatory To Implement... Regards, Lisa Please pardon brevity - sent from my HTC EVO running Junos Pulse ----- Reply message ----- From: "David Harrington" Date: Thu, Jul 24, 2014 19:37 Subject: [sacm] Notes from Information Model Discussion To: "'Waltermire, David A.'" , "sacm@i= etf.org" Hi, What's an MTI transport? MTI does not appear to be mentioned in any of the sacm documents. Assuming (thanks Wikipedia) you mean message type indicator, that would still imply 1) interoperability between nodes only with matching query mechanisms (i.e., not vendor-neutral interoperability), or 2) everybody has to implement everything. If you sent me a message in Russian, and had a language indicator that told me it was Russian, I still wouldn't be able to read the message. David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Thursday, July 24, 2014 6:49 PM > To: David Harrington; sacm@ietf.org > Subject: Re: [sacm] Notes from Information Model Discussion > > Or... > > 3) we define MTI transports and data formats to enable interop. > > Dave > > David Harrington wrote: > > > > > > > Is it anticipated that a SACM participant not be required to implement, > > at a minimum, a common query method and data model? > > > > If it is allowed that SACM participants can interact using a free choic= e > > of method, that then leads to two possibilities: > > > > 1) A consumer can only make queries of endpoints for which it has > > implemented the matching query method. Portions of the network will, > > therefore, be inaccessible to it. > > > > 2) Every consumer has to implement every possible query method. > > > > > > > If every participant can interact using a free choice of method, leading to > non-interoperability, that raises the question: > Why are we doing this in the IETF? > > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_9fg9n5u3ngtsu9kw1olqvg2w1406248050858emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Mandatory to implement is what I intended.=0A=
Thanks,=0A=
Dave=0A=
=0A=
Lisa Lorenzin <llorenzin@juniper.net> wrote:=0A=
=0A=
I read it as Mandatory To Implement...

Regards,
Lisa

Please pardon brevity - sent from my HTC EVO running Junos Pulse

----- Reply message -----
From: "David Harrington" <dbharrington@comcast.net>
Date: Thu, Jul 24, 2014 19:37
Subject: [sacm] Notes from Information Model Discussion
To: "&apos;Waltermire, David A.&apos;" <david.waltermi= re@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>

Hi,

What's an MTI transport?
MTI does not appear to be mentioned in any of the sacm documents.

Assuming (thanks Wikipedia) you mean message type indicator, that would
still imply 1) interoperability between nodes only with matching query
mechanisms (i.e., not vendor-neutral interoperability), or 2) everybody has=
to implement everything.
If you sent me a message in Russian, and had a language indicator that told=
me it was Russian, I still wouldn't be able to read the message.

David Harrington
dbharrington@comcast.net
+1-603-828-1401

> -----Original Message-----
> From: Waltermire, David A. [mailto:david.waltermire@nist.gov]
> Sent: Thursday, July 24, 2014 6:49 PM
> To: David Harrington; sacm@ietf.org
> Subject: Re: [sacm] Notes from Information Model Discussion
>
> Or...
>
> 3) we define MTI transports and data formats to enable interop.
>
> Dave
>
> David Harrington <dbharrington@comcast.net> wrote:
>
>
> > > <FrameOfReference>
> > Is it anticipated that a SACM participant not be required to impl= ement,
> > at a minimum, a common query method and data model?
> >
> > If it is allowed that SACM participants can interact using a free= choice
> > of method, that then leads to two possibilities:
> >
> > 1) A consumer can only make queries of endpoints for which it has=
> > implemented the matching query method.  Portions of the netw= ork will,
> > therefore, be inaccessible to it.
> >
> > 2) Every consumer has to implement every possible query method. > >
> > > </FrameOfReference>
>
> If every participant can interact using a free choice of method, leadi= ng
to
> non-interoperability, that raises the question:
> Why are we doing this in the IETF?
>
>
> David Harrington
> dbharrington@comcast.net
> +1-603-828-1401
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.iet= f.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org= /mailman/listinfo/sacm
--_000_9fg9n5u3ngtsu9kw1olqvg2w1406248050858emailandroidcom_-- From nobody Thu Jul 24 17:34:43 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB96A1A0AAA for ; Thu, 24 Jul 2014 17:34:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 XYhbGu_koG7q for ; Thu, 24 Jul 2014 17:34:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB79C1A0640 for ; Thu, 24 Jul 2014 17:34:38 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0223.namprd09.prod.outlook.com (25.160.92.145) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 00:34:35 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0990.007; Fri, 25 Jul 2014 00:34:35 +0000 From: "Waltermire, David A." To: Lisa Lorenzin , David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Notes from Information Model Discussion Thread-Index: AQHPp35H3v41bPjSXEih5Cr54kkdv5uvueyAgAASHgCAAAfW1IAADa2AgAAKmACAAAVIDA== Date: Fri, 25 Jul 2014 00:34:34 +0000 Message-ID: <9fg9n5u3ngtsu9kw1olqvg2w.1406248050858@email.android.com> References: <53D1778B.6040608@ThreatGuard.com>, <02d901cfa78d$8457fd20$8d07f760$@comcast.net> , <02e901cfa798$45855fb0$d0901f10$@comcast.net>, <531F0F95-4510-42A7-B380-4973D7E283EA@juniper.net> In-Reply-To: <531F0F95-4510-42A7-B380-4973D7E283EA@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.162.85] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(164054003)(199002)(51704005)(13464003)(24454002)(377454003)(95246002)(86362001)(19625215002)(64706001)(31966008)(74662001)(33646002)(79102001)(81342001)(87936001)(80022001)(2656002)(66066001)(101416001)(83072002)(99396002)(85306003)(85852003)(50986999)(21056001)(1941001)(76176999)(15975445006)(107886001)(74502001)(20776003)(105586002)(107046002)(93886003)(83322001)(81542001)(95666004)(19617315012)(92566001)(19580395003)(4396001)(77096002)(92726001)(99286002)(77982001)(76482001)(46102001)(54356999)(106356001)(106116001)(63666003)(16236675004)(19580405001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0223; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9fg9n5u3ngtsu9kw1olqvg2w1406248050858emailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/uVTPRsDmFnylNZ96DPMr_F0pfP0 Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:34:41 -0000 --_000_9fg9n5u3ngtsu9kw1olqvg2w1406248050858emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mandatory to implement is what I intended. Thanks, Dave Lisa Lorenzin wrote: I read it as Mandatory To Implement... Regards, Lisa Please pardon brevity - sent from my HTC EVO running Junos Pulse ----- Reply message ----- From: "David Harrington" Date: Thu, Jul 24, 2014 19:37 Subject: [sacm] Notes from Information Model Discussion To: "'Waltermire, David A.'" , "sacm@i= etf.org" Hi, What's an MTI transport? MTI does not appear to be mentioned in any of the sacm documents. Assuming (thanks Wikipedia) you mean message type indicator, that would still imply 1) interoperability between nodes only with matching query mechanisms (i.e., not vendor-neutral interoperability), or 2) everybody has to implement everything. If you sent me a message in Russian, and had a language indicator that told me it was Russian, I still wouldn't be able to read the message. David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Thursday, July 24, 2014 6:49 PM > To: David Harrington; sacm@ietf.org > Subject: Re: [sacm] Notes from Information Model Discussion > > Or... > > 3) we define MTI transports and data formats to enable interop. > > Dave > > David Harrington wrote: > > > > > > > Is it anticipated that a SACM participant not be required to implement, > > at a minimum, a common query method and data model? > > > > If it is allowed that SACM participants can interact using a free choic= e > > of method, that then leads to two possibilities: > > > > 1) A consumer can only make queries of endpoints for which it has > > implemented the matching query method. Portions of the network will, > > therefore, be inaccessible to it. > > > > 2) Every consumer has to implement every possible query method. > > > > > > > If every participant can interact using a free choice of method, leading to > non-interoperability, that raises the question: > Why are we doing this in the IETF? > > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_9fg9n5u3ngtsu9kw1olqvg2w1406248050858emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Mandatory to implement is what I intended.=0A=
Thanks,=0A=
Dave=0A=
=0A=
Lisa Lorenzin <llorenzin@juniper.net> wrote:=0A=
=0A=
I read it as Mandatory To Implement...

Regards,
Lisa

Please pardon brevity - sent from my HTC EVO running Junos Pulse

----- Reply message -----
From: "David Harrington" <dbharrington@comcast.net>
Date: Thu, Jul 24, 2014 19:37
Subject: [sacm] Notes from Information Model Discussion
To: "&apos;Waltermire, David A.&apos;" <david.waltermi= re@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>

Hi,

What's an MTI transport?
MTI does not appear to be mentioned in any of the sacm documents.

Assuming (thanks Wikipedia) you mean message type indicator, that would
still imply 1) interoperability between nodes only with matching query
mechanisms (i.e., not vendor-neutral interoperability), or 2) everybody has=
to implement everything.
If you sent me a message in Russian, and had a language indicator that told=
me it was Russian, I still wouldn't be able to read the message.

David Harrington
dbharrington@comcast.net
+1-603-828-1401

> -----Original Message-----
> From: Waltermire, David A. [mailto:david.waltermire@nist.gov]
> Sent: Thursday, July 24, 2014 6:49 PM
> To: David Harrington; sacm@ietf.org
> Subject: Re: [sacm] Notes from Information Model Discussion
>
> Or...
>
> 3) we define MTI transports and data formats to enable interop.
>
> Dave
>
> David Harrington <dbharrington@comcast.net> wrote:
>
>
> > > <FrameOfReference>
> > Is it anticipated that a SACM participant not be required to impl= ement,
> > at a minimum, a common query method and data model?
> >
> > If it is allowed that SACM participants can interact using a free= choice
> > of method, that then leads to two possibilities:
> >
> > 1) A consumer can only make queries of endpoints for which it has=
> > implemented the matching query method.  Portions of the netw= ork will,
> > therefore, be inaccessible to it.
> >
> > 2) Every consumer has to implement every possible query method. > >
> > > </FrameOfReference>
>
> If every participant can interact using a free choice of method, leadi= ng
to
> non-interoperability, that raises the question:
> Why are we doing this in the IETF?
>
>
> David Harrington
> dbharrington@comcast.net
> +1-603-828-1401
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.iet= f.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org= /mailman/listinfo/sacm
--_000_9fg9n5u3ngtsu9kw1olqvg2w1406248050858emailandroidcom_-- From nobody Thu Jul 24 18:48:28 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718161A0AB4 for ; Thu, 24 Jul 2014 18:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-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 ahD9fQMXjfsU for ; Thu, 24 Jul 2014 18:48:20 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140ED1A0AB3 for ; Thu, 24 Jul 2014 18:48:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=akw+BRiZ7a+NB0/Kp6NBgBlpm0B/lxjmYQPcooXqJkcLnpYdmFrWw0GphTWVjQKZIpoH6ZA9BYX3HUZxPqz+/WRko98ozf8iC5wmI9EvFS94xwCTpP++OZ1q7GTkcqTC; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 26470 invoked from network); 24 Jul 2014 19:01:44 -0700 Received: from h64-35-203-242.cntcnh.broadband.dynamic.tds.net (HELO ?172.16.1.22?) (64.35.203.242) by server.threatguard.com with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 24 Jul 2014 19:01:43 -0700 Message-ID: <53D1B768.3090206@ThreatGuard.com> Date: Thu, 24 Jul 2014 21:48:24 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lisa Lorenzin , David Harrington , "sacm@ietf.org" References: <53D1778B.6040608@ThreatGuard.com> <02d901cfa78d$8457fd20$8d07f760$@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/nrqu6zR4XcHLtEUmTKKqNOUL5fo Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:48:22 -0000 On 7/24/2014 7:02 PM, Lisa Lorenzin wrote: > Hi David, > > I believe we've agreed in previous discussions that we will > standardize and require data format(s) and transport protocol(s) > that will be mandatory to implement, to ensure interoperability, > but include extensibility points to accommodate participants > choosing other data format(s) and transport protocol(s). Yes, it would be nice of us if we describe an architecture that can also be used with other data formats and transport protocols. But as soon as a node starts using one of those other formats/protocols that data interchange is no longer a SACM conversation. Being able to act as a SACM node will require a software implementation on the endpoint, and that's not going to happen on all endpoints -- legacy equipment, for example, or closed devices that just chose to not implement. These endpoints will still be network denizens that need to be evaluated, it just won't happen directly as a SACM participant. So at some point, something will need to broker the SACM request/response into something that can interact with the non-SACM endpoints -- a proxy. And the closer that happens to the endpoint the better, since that minimizes the number of places that non-SACM formats/protocols need to be implemented. So, SACM itself should have no need to support other formats/protocols. If the SACM architecture is such that it can and this makes it useful for other purposes -- wonderful. Does anybody else read this differently? --gun > > If desired, I can dig through the notes so far and see if I > can find a citation for that decision. :) > > Regards, > > Lisa > > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > Sent: Thursday, July 24, 2014 6:21 PM > To: sacm@ietf.org > Subject: Re: [sacm] Notes from Information Model Discussion > > > >>> >> Is it anticipated that a SACM participant not be required to implement, >> at a minimum, a common query method and data model? >> >> If it is allowed that SACM participants can interact using a free choice >> of method, that then leads to two possibilities: >> >> 1) A consumer can only make queries of endpoints for which it has >> implemented the matching query method. Portions of the network will, >> therefore, be inaccessible to it. >> >> 2) Every consumer has to implement every possible query method. >> >>> > > If every participant can interact using a free choice of method, leading to > non-interoperability, that raises the question: > Why are we doing this in the IETF? > > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From nobody Fri Jul 25 04:13:16 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E461A01A8 for ; Fri, 25 Jul 2014 04:13:12 -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 XEgNc7H4c4To for ; Fri, 25 Jul 2014 04:13:06 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC65F1A017A for ; Fri, 25 Jul 2014 04:13:05 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so4015079wgg.31 for ; Fri, 25 Jul 2014 04:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=xdJD6gVPqmV83PjYTbS8Gk8ux8VbM+sTodI42TmBcVA=; b=urM9QoRepEIV9WiB8UOEqULLyWK7foCMvLOFseKvYb+IJDjPuOmzefuy3lNHaaGE9f OyjLLR80mFnhr7up/lTIo7/rCWhNJAXkW/y6Zy8ok/Qtzvr45mCSea1A34v/ZxDjjVkG badiOWJu3teZ811lwTgtQoSXnKxdTAX2fQPIpRyb1UwIgaD9TSm13Y+Sg1jUHlns7rLW 7RpbNMVICDwwa/4+habMCr3Nux8lUmfIIyJz5lUs4PBjlVsz9qVOiiy9ZC2PYh3V7sSz 83jnjJf6zw68Pn98n8N+1Pv+vIZ/dp/C4+OLBh8/z3Eeli6qQlHW+q29Fqg80bA5AaW3 Ighg== X-Received: by 10.180.211.197 with SMTP id ne5mr4119854wic.67.1406286783907; Fri, 25 Jul 2014 04:13:03 -0700 (PDT) Received: from dhcp-92fd.meeting.ietf.org (dhcp-92fd.meeting.ietf.org. [31.133.146.253]) by mx.google.com with ESMTPSA id eh10sm4748556wic.0.2014.07.25.04.13.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 04:13:02 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7474FC99-D9DD-4697-81CA-2012A9F379B8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Adam W. Montville" In-Reply-To: <53D1B768.3090206@ThreatGuard.com> Date: Fri, 25 Jul 2014 07:12:57 -0400 Message-Id: <9F0BB7BC-9E60-4778-B58E-D993E6520E6A@gmail.com> References: <53D1778B.6040608@ThreatGuard.com> <02d901cfa78d$8457fd20$8d07f760$@comcast.net> <53D1B768.3090206@ThreatGuard.com> To: Gunnar Engelbach X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/oHZ_D42Ge1w1E4uMk6sIoVikeB0 Cc: David Harrington , Lisa Lorenzin , "sacm@ietf.org" Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:13:12 -0000 --Apple-Mail=_7474FC99-D9DD-4697-81CA-2012A9F379B8 Content-Type: multipart/alternative; boundary="Apple-Mail=_320F4549-E77B-437A-AA5C-23F8C11DBF4A" --Apple-Mail=_320F4549-E77B-437A-AA5C-23F8C11DBF4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 24, 2014, at 9:48 PM, Gunnar Engelbach = wrote: >=20 >=20 > On 7/24/2014 7:02 PM, Lisa Lorenzin wrote: >> Hi David, >>=20 >> I believe we've agreed in previous discussions that we will >> standardize and require data format(s) and transport protocol(s) >> that will be mandatory to implement, to ensure interoperability, >> but include extensibility points to accommodate participants >> choosing other data format(s) and transport protocol(s). >=20 > Yes, it would be nice of us if we describe an architecture that can = also be used with other data formats and transport protocols. But as = soon as a node starts using one of those other formats/protocols that = data interchange is no longer a SACM conversation. >=20 > Being able to act as a SACM node will require a software = implementation on the endpoint, and that's not going to happen on all = endpoints -- legacy equipment, for example, or closed devices that just = chose to not implement. >=20 > These endpoints will still be network denizens that need to be = evaluated, it just won't happen directly as a SACM participant. So at = some point, something will need to broker the SACM request/response into = something that can interact with the non-SACM endpoints -- a proxy. >=20 > And the closer that happens to the endpoint the better, since that = minimizes the number of places that non-SACM formats/protocols need to = be implemented. >=20 > So, SACM itself should have no need to support other = formats/protocols. >=20 > If the SACM architecture is such that it can and this makes it useful = for other purposes -- wonderful. >=20 >=20 > Does anybody else read this differently? I=92m sure others on the list will chime in. Here are my thoughts. To = be successful, SACM needs to define its control plane (using that term = again until we figure it out), it=92s data plane, and some information = models to get through the pipes. We=92re going to start this with an = eye toward getting adoption in the field. Adoption from security tool = vendors who probably already have their own methods of doing these = things and collecting data from endpoints. In some cases, they use = broker networks, in others it=92s point to point. In some cases, they = use agents, in others they don=92t. We need to look at this not only as = an architecture for the future, but as an architecture that is flexible = enough to enable generalized interoperability between vendors=92 tools. =20= Put another way, SACM has a need to support the formats and protocols it = needs to support. We don=92t know exactly what that set is today, and = we should not preclude what we cannot envision. >=20 >=20 > --gun >=20 >=20 >>=20 >> If desired, I can dig through the notes so far and see if I >> can find a citation for that decision. :) >>=20 >> Regards, >>=20 >> Lisa >>=20 >> -----Original Message----- >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David = Harrington >> Sent: Thursday, July 24, 2014 6:21 PM >> To: sacm@ietf.org >> Subject: Re: [sacm] Notes from Information Model Discussion >>=20 >>=20 >>=20 >>>> >>> Is it anticipated that a SACM participant not be required to = implement, >>> at a minimum, a common query method and data model? >>>=20 >>> If it is allowed that SACM participants can interact using a free = choice >>> of method, that then leads to two possibilities: >>>=20 >>> 1) A consumer can only make queries of endpoints for which it has >>> implemented the matching query method. Portions of the network = will, >>> therefore, be inaccessible to it. >>>=20 >>> 2) Every consumer has to implement every possible query method. >>>=20 >>>> >>=20 >> If every participant can interact using a free choice of method, = leading to >> non-interoperability, that raises the question: >> Why are we doing this in the IETF? >>=20 >>=20 >> David Harrington >> dbharrington@comcast.net >> +1-603-828-1401 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >>=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_320F4549-E77B-437A-AA5C-23F8C11DBF4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 24, 2014, at 9:48 PM, Gunnar = Engelbach <Gunnar.Engelbach@ThreatGu= ard.com> wrote:



On 7/24/2014 7:02 PM, Lisa = Lorenzin wrote:
Hi David,

I believe = we've agreed in previous discussions that we will
standardize and = require data format(s) and transport protocol(s)
that will be = mandatory to implement, to ensure interoperability,
but include = extensibility points to accommodate participants
choosing other data = format(s) and transport protocol(s).

Yes, it would = be nice of us if we describe an architecture that can also be used with = other data formats and transport protocols.  But as soon as a node = starts using one of those other formats/protocols that data interchange = is no longer a SACM conversation.

Being able to act as a SACM = node will require a software implementation on the endpoint, and that's = not going to happen on all endpoints -- legacy equipment, for example, = or closed devices that just chose to not = implement.

These endpoints will still be = network denizens that need to be evaluated, it just won't happen = directly as a SACM participant.  So at some point, something will = need to broker the SACM request/response into something that can = interact with the non-SACM endpoints -- a proxy.

And the closer = that happens to the endpoint the better, since that minimizes the number = of places that non-SACM formats/protocols need to be = implemented.

So, SACM itself should have no need to support other = formats/protocols.

If the SACM architecture is such = that it can and this makes it useful for other purposes -- = wonderful.


Does anybody else read this = differently?

I=92m sure others = on the list will chime in.  Here are my thoughts.  To be = successful, SACM needs to define its control plane (using that term = again until we figure it out), it=92s data plane, and some information = models to get through the pipes.  We=92re going to start this with = an eye toward getting adoption in the field.  Adoption from = security tool vendors who probably already have their own methods of = doing these things and collecting data from endpoints.  In some = cases, they use broker networks, in others it=92s point to point. =  In some cases, they use agents, in others they don=92t.  We = need to look at this not only as an architecture for the future, but as = an architecture that is flexible enough to enable generalized = interoperability between vendors=92 tools. =  

Put another way, SACM has a need to = support the formats and protocols it needs to support.  We don=92t = know exactly what that set is today, and we should not preclude what we = cannot envision.




--gun



If desired, I can dig through the notes so far and see = if I
can find a citation for that decision. = :)

          &nbs= p;            =             &n= bsp;           &nbs= p;        Regards,

 &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =  Lisa

-----Original Message-----
From: sacm [mailto:sacm-bounces@ietf.org] = On Behalf Of David Harrington
Sent: Thursday, July 24, 2014 6:21 = PM
To: sacm@ietf.org
Subject: = Re: [sacm] Notes from Information Model = Discussion



<FrameOfReference>
Is it anticipated = that a SACM participant not be required to implement,
at a minimum, a = common query method and data model?

If it is allowed that SACM = participants can interact using a free choice
of method, that then = leads to two possibilities:

1) A consumer can only make queries = of endpoints for which it has
implemented the matching query method. =  Portions of the network will,
therefore, be inaccessible to = it.

2) Every consumer has to implement every possible query = method.

</FrameOfReference>

I= f every participant can interact using a free choice of method, leading = to
non-interoperability, that raises the question:
Why are we = doing this in the IETF?


David Harrington
dbharrington@comcast.net
+= 1-603-828-1401

_______________________________________________
s= acm mailing = list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing = list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
sacm = mailing list
sacm@ietf.org
https://www.ietf.org/m= ailman/listinfo/sacm

= --Apple-Mail=_320F4549-E77B-437A-AA5C-23F8C11DBF4A-- --Apple-Mail=_7474FC99-D9DD-4697-81CA-2012A9F379B8 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 iQEcBAEBCgAGBQJT0ju5AAoJEILmIVe/2cgGb0kIAM27cHqtAa6HzSh6YfUFz7xj SvYetAUOL6oOsXEuQHUOC4IoWFFTHPqO4KXFFEgJLG13oe6Hid54fa3r+4YEQggV OHXp29JL65cgO0YhCeyiD7d5uJ5+UY8f63mUlpUVWkspCBg6jHxTMJNuScsfKukX ncM8953z5+2a9kmYd4gn51Q40rnvuMsNC4VCcR3LxkTfQUsE5EsRoTRRbpaL9m/Y 5dpM9/1UKleG2oIkfQjK2XH8BBXRin76n1Kba5C1yofeBduKnZkdKEX6GKZA+va8 Sx71wUMOE8wglWp20aCenGQFsBYrg6yTSPOIM2pNBBfmhDqpOnR0eOfzxYfLbVU= =t5xn -----END PGP SIGNATURE----- --Apple-Mail=_7474FC99-D9DD-4697-81CA-2012A9F379B8-- From nobody Fri Jul 25 04:17:22 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DAA1A0126 for ; Fri, 25 Jul 2014 04:17:21 -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, 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 UjfcxduRCWCX for ; Fri, 25 Jul 2014 04:17:19 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E731A017A for ; Fri, 25 Jul 2014 04:17:18 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so4077507wgh.29 for ; Fri, 25 Jul 2014 04:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=77xmFdiWqRmZcnVcJzueiN1VmRWMgEV9HEmZVe5QZEM=; b=NEUcG7m2iDvEBrU8QTteUl+kjgZVA5FQDlhAzTCT8TFKE1TC04RMbpdGitEvZA74Bl X5XzXAHX7wyPp2aANN5Uw8MI7xnF75xF6DCDCQabtx0YChYjOKBGMNG6Tkk0nKtsimbh RKmaUm/A3sqC7rvySJan/oD8XDri1Mb5/5wIvTQACGcDg+UNS3AmI+5eDYT1yBglB9z9 lifpZW0B0hy1sdFPTVG51jKVPzY3UdLDzgahtil609O04uoVASmwoTGulPMnyOLWrf8P rJgzhGGIpIzdG8f16vj9RD8I/hzRNh+vNhRI8jkeNWhqrU7kAHYnhSohgKoGxbiopbU2 Tnrw== X-Received: by 10.180.189.107 with SMTP id gh11mr4371003wic.40.1406287037696; Fri, 25 Jul 2014 04:17:17 -0700 (PDT) Received: from dhcp-92fd.meeting.ietf.org (dhcp-92fd.meeting.ietf.org. [31.133.146.253]) by mx.google.com with ESMTPSA id v4sm4713898wiz.16.2014.07.25.04.17.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 04:17:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C737568A-AFE2-49A6-AC89-D34694DB9A32"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Adam W. Montville" In-Reply-To: <02cb01cfa78b$c1580e60$44082b20$@comcast.net> Date: Fri, 25 Jul 2014 07:17:12 -0400 Message-Id: <2B928A18-2206-456B-8AD8-0FFEE67D5F97@gmail.com> References: <02cb01cfa78b$c1580e60$44082b20$@comcast.net> To: David Harrington X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/HYVIzHKGjuLu_dmYno_Xy-FDOmg Cc: sacm@ietf.org Subject: Re: [sacm] Notes from Information Model Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:17:21 -0000 --Apple-Mail=_C737568A-AFE2-49A6-AC89-D34694DB9A32 Content-Type: multipart/alternative; boundary="Apple-Mail=_4332985E-B169-4126-8E67-7710C3A7C50A" --Apple-Mail=_4332985E-B169-4126-8E67-7710C3A7C50A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 24, 2014, at 6:08 PM, David Harrington = wrote: > Hi, > =20 > I=92m a bit concerned that this WG has chosen to use the term =93Control= Plane=94. > SACM is about configuration (charter: Standardized protocols to = collect, verify, and update system security configurations) and = continuous monitoring, > That would seem to put it into the management plane (which many = consider a subset of the control plane). > Defining part of the management plane as being the =93control plane=94 = seems a poor choice of terminology. > =20 > I tried to find the definition in the terminology draft, but it=92s = not there. > I tried to find it in the use cases draft but it=92s not there. > I finally found it in one of the architecture drafts. > =20 > Since the IETF is all about the Internet, =93control plane=94 seems a = term of art related to routing and networking, such as OSPF and BGP. > Recognizing that I might not know about non-router usages, I looked up = =93control plane=94 in Wikipedia, which redirects =93control plane=94 to = =93routing control plane=94. > I checked a few other web sites that discuss control plane versus = management plane. > = http://blog.ipspace.net/2013/08/management-control-and-data-planes-in.html= > http://whatis.techtarget.com/definition/plane-in-networking > = http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/securit= y/configuration/guide/syssec_cg41crs_chapter7.html > http://en.wikipedia.org/wiki/Telecommunications_network > =20 > This group=92s use of control plane appears to be slightly different = than the rest of the networking industry. > It appears a SACM =93control plane=94 is a broker for AAA services, so = why not call it a AAA broker? It=92s not just AAA services, but your point about management plane vs. = control plane is well taken. We=92ll have to work this one out, because = we do not intend to confuse other WGs or the public relying on these = specifications. To defend a bit about the term and it=92s lack of = presence in terminology, though, it=92s all a work in progress so, of = course things aren=92t as =93tight=94 as we would ultimately like them = to be. > =20 > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam W. = Montville > Sent: Thursday, July 24, 2014 4:31 PM > To: sacm@ietf.org > Subject: [sacm] Notes from Information Model Discussion > =20 > All: > =20 > This morning a few of us attempted a deeper dive on the =93Ice Station = Zebra=94 usage scenario to gain better understanding of the data that = would be required between two SACM participants. =20 > =20 > Before getting into that, toward the end of the meeting we found = ourselves asking what success looks like. We seemed to generally agreed = that success is getting the Control Plane, Data Plane, and essential = configuration assessment items in place. This would include information = models needed for Control Plane administration/configuration and = configuration assessment. > =20 > The following =93things that we should do=94 and =93things we need to = discuss=94 are based on the =93Frame Of Reference=94 bit below (thanks = for sharing your notes Lisa!) and on notes I took. If others have = things to add or alter, please do so. > =20 > Some things that we should do: > =20 > Pick term, define it in terminology draft, use it - a comment was = heard that we tend to switch around on terminology, so let=92s try to = pick one, document it, and stick with it. > We should work on security considerations for authentication and = delegation of authentication > We should not preclude ecosystem possibilities, but we should be = explicit about what we intend to standardize and what we intend to = restrict (thus drawing a line between what we will do and what we will = leave to be possible in the future). > Define taxonomy or functional taxonomy in the terminology document > =20 > =20 > Things we need to discuss: > =20 > We need to have a discussion about authorization. There is = authorization at the Control Plane level, but are there more granular = authorizations for which we need to provide? What provides that more = granular authorization (i.e. Control Plane, Provider, delegate, = something else)? > How do we define that we need a service to provide a taxonomy of, for = example, enterprise-relevant tags? We believe this should go into the = architecture draft. > How can queries be filtered? Concrete list, wildcard, metadata = characteristics=85 And, does the Provider do the filtering or the Proxy = or=85 > One way to allow Providers to announce the availability of a = functional taxonomy is to use a registry with some standard entries, but = with extension guidance for unimagined functional taxonomies > =20 > =20 > > Prior to participation, registration must occur. > =20 > Registration (station endpoint management system, university admin) > Each client publishes its capabilities (=93I know this stuff=94) > So far, no data about any assets has been exchanged > Endpoints are provisioned into endpoint management database > Device identity information that=92s important to SACM > Not traveling over a SACM transport > Administrator constructs a query > I want to consume information you have about assets I=92m interested = in > Method of query is based on what the provider registered as capability > Can ask me over the grid or by this direct RESTful API, etc. > =20 > Control Plane: > Does: > Capture Capability announcements > Provides auth capability (protocol TBD) > Provides resource to find capability providers > =20 > Capability Definition > Provider and/or consumer data > Ability to exchange taxonomy (language about schemas provided) > Optional/MAY > Data transfer protocol(s) > Data model(s) > Authentication protocol(s) - direct, indirect/SSO > > =20 > =20 > Regards, > =20 > Adam > =20 > =20 > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_4332985E-B169-4126-8E67-7710C3A7C50A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 24, 2014, at 6:08 PM, David = Harrington <dbharrington@comcast.net> = wrote:

 
I=92m a bit concerned that this WG has chosen to use = the term =93Control Plane=94.
SACM is about configuration = (charter: Standardized = protocols to collect, verify, and update system security configurations) = and continuous monitoring,
That would seem to put it into the management plane (which = many consider a subset of the control = plane).
Defining part = of the management plane as being the =93control plane=94 seems a poor = choice of terminology.
 
I tried to find the definition in the terminology = draft, but it=92s not there.
I tried to find it in the use = cases draft but it=92s not there.
I finally found it in one = of the architecture drafts.
 
Since the IETF is all = about the Internet, =93control plane=94 seems a term of art related to = routing and networking, such as OSPF and = BGP.
Recognizing that I might not know about non-router = usages, I looked up =93control plane=94 in Wikipedia, which redirects = =93control plane=94 to =93routing control = plane=94.
I checked a few other web sites that discuss control = plane versus management plane.
 
This group=92s use of = control plane appears to be slightly different than the rest of the = networking industry.
It appears a SACM =93control = plane=94 is a broker for AAA services, so why not call it a AAA = broker?

It=92s = not just AAA services, but your point about management plane vs. control = plane is well taken.  We=92ll have to work this one out, because we = do not intend to confuse other WGs or the public relying on these = specifications.  To defend a bit about the term and it=92s lack of = presence in terminology, though, it=92s all a work in progress so, of = course things aren=92t as =93tight=94 as we would ultimately like them = to be.

 
David Harrington
+1-603-828-1401
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam W. = Montville
Sent: Thursday, July 24, 2014 = 4:31 PM
To: sacm@ietf.org
Subject: [sacm] Notes from = Information Model Discussion
 
All:
 
This = morning a few of us attempted a deeper dive on the =93Ice Station Zebra=94= usage scenario to gain better understanding of the data that would be = required between two SACM participants. =  
 
Before getting into that, toward the end of the meeting we found = ourselves asking what success looks like.  We seemed to generally = agreed that success is getting the Control Plane, Data Plane, and = essential configuration assessment items in place.  This would = include information models needed for Control Plane = administration/configuration and configuration = assessment.
 
The = following =93things that we should do=94 and =93things we need to = discuss=94 are based on the =93Frame Of Reference=94 bit below (thanks = for sharing your notes Lisa!) and on notes I took.  If others have = things to add or alter, please do so.
 
Some things that we should = do:
 
  • Pick term, define it in terminology draft, use it - a comment = was heard that we tend to switch around on terminology, so let=92s try = to pick one, document it, and stick with it.
  • We should work on security = considerations for authentication and delegation of = authentication
  • We should not preclude ecosystem possibilities, but we should be = explicit about what we intend to standardize and what we intend to = restrict (thus drawing a line between what we will do and what we will = leave to be possible in the future).
  • Define taxonomy or functional = taxonomy in the terminology document
 
 
Things we need to = discuss:
 
  • We need to have a discussion about authorization.  There is = authorization at the Control Plane level, but are there more granular = authorizations for which we need to provide?  What provides that = more granular authorization (i.e. Control Plane, Provider, delegate, = something else)?
  • How do we define that we need a service to provide a taxonomy = of, for example, enterprise-relevant tags?  We believe this should = go into the architecture draft.
  • How can queries be filtered?  Concrete list, = wildcard, metadata characteristics=85  And, does the Provider do = the filtering or the Proxy or=85
  • One way to allow Providers to announce the = availability of a functional taxonomy is to use a registry with some = standard entries, but with extension guidance for unimagined functional = taxonomies
 
 
<FrameOfReference>
Prior to participation, registration must = occur.
 
  1. Registration (station endpoint management system, university = admin)
    1. Each client publishes its capabilities (=93I know this = stuff=94)
    2. So far, no data about any assets has been = exchanged
  1. Endpoints are provisioned into endpoint management = database
    1. Device identity information that=92s important to = SACM
    2. Not = traveling over a SACM transport
  1. Administrator constructs a = query
    1. I want to consume information you have about assets I=92m = interested in
    2. Method of query is based on what the provider registered as = capability
      1. Can ask me over the grid or by this direct RESTful API, = etc.
 
Control Plane:
        &= nbsp; Does:
=
  • Capture Capability = announcements
  • Provides auth capability (protocol TBD)
  • Provides resource to find = capability providers
 
Capability Definition
  • Provider and/or consumer data
    • Ability to exchange taxonomy (language about schemas = provided)
    • Optional/MAY
  • Data transfer protocol(s)
  • Data model(s)
  • Authentication protocol(s) - direct, = indirect/SSO
</FrameOfReference>
 
 
Regards,
 
Adam
 
 
 
___________________= ____________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

= --Apple-Mail=_4332985E-B169-4126-8E67-7710C3A7C50A-- --Apple-Mail=_C737568A-AFE2-49A6-AC89-D34694DB9A32 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 iQEcBAEBCgAGBQJT0jy4AAoJEILmIVe/2cgGk00IAMCE6jUV6KGQG9AVFDHrVFc4 4HICDBMTgZ5+u6WyJ++6xdNFnBqHVmK50qXoNMc/UhOqXNcpeOoeIG2uovmRtag2 /v+9l050E3hv2acvgqnCmEeu0JIE/v4AFAW88BLnw6eGFF1kxsonQzdxr/O21jnW +4gKIwkSN1amVd+PHGa856HhrteY311BVRIf4+wRpHv1vk9czBUYcQSuC+2+YbZ8 U5PRtBft1CZuETe6ycDNYIzNk8uHWOAL3vUvMjlhlJnPzcPbmuJS+WegZ+dfQTGH eLnHH6/zutdinjiP3JBiWcNwHmNg2pxT0jUuZYO79rTlIlY6MV2XocBA/5isJ4c= =JrsI -----END PGP SIGNATURE----- --Apple-Mail=_C737568A-AFE2-49A6-AC89-D34694DB9A32-- From nobody Fri Jul 25 08:21:46 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DCA1A0312 for ; Fri, 25 Jul 2014 08:21:43 -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 l-J7ewSf36E2 for ; Fri, 25 Jul 2014 08:21:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DBC1A0277 for ; Fri, 25 Jul 2014 08:21:40 -0700 (PDT) Received: from BY2PR05MB551.namprd05.prod.outlook.com (10.141.220.152) by BY2PR05MB048.namprd05.prod.outlook.com (10.242.34.156) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 15:21:37 +0000 Received: from BY2PR05MB550.namprd05.prod.outlook.com (10.141.220.151) by BY2PR05MB551.namprd05.prod.outlook.com (10.141.220.152) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 15:21:36 +0000 Received: from BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) by BY2PR05MB550.namprd05.prod.outlook.com ([10.141.220.151]) with mapi id 15.00.0990.007; Fri, 25 Jul 2014 15:21:36 +0000 From: Lisa Lorenzin To: "sacm@ietf.org" Thread-Topic: Potential additions to terminology draft Thread-Index: Ac+oGygviPtcXyL8QAK5JT8mnA8NAA== Date: Fri, 25 Jul 2014 15:21:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(54356999)(106356001)(229853001)(107046002)(77982001)(85306003)(85852003)(76482001)(15975445006)(33646002)(76576001)(79102001)(46102001)(20776003)(4396001)(99396002)(2351001)(110136001)(92566001)(80022001)(105586002)(74502001)(87936001)(74662001)(86362001)(19580405001)(81342001)(50986999)(64706001)(99286002)(81542001)(95666004)(66066001)(2656002)(74316001)(83322001)(15202345003)(101416001)(21056001)(83072002)(19580395003)(31966008)(107886001)(108616002)(24736002)(18886065003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB551; H:BY2PR05MB550.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/XQp5sdzFHkFnFSOwaScniqeBGUo Subject: [sacm] Potential additions to terminology draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:21:43 -0000 During today's meeting, we talked about updating the=20 terminology draft - from the recent architecture=20 conversations, here are some additional terms: Components -=20 Client/supplicant Provider (client role) Consumer (client role) Control Plane Data Plane Control plane modes of operation=20 Broker Proxy Repository (my email reply to David yesterday has a starting point for these definitions) Also, there are several terms I think we need to add to the terminology draft because we keep debating them while trying to have other conversations. :) Role (flavor of client) Examples: provider, consumer Capability (provider/consumer data) Examples: attributes, schemas Function (mechanism for doing something) Examples: authentication, authorization Regards, Lisa -- Lisa Lorenzin / 919-384-7275 / llorenzin@juniper.net=20 Principal Solutions Architect - Security & Mobility=20 Juniper Networks / http://www.juniper.net/=20 From nobody Fri Jul 25 09:01:14 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F191A0416 for ; Fri, 25 Jul 2014 09:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 8zBlY-28k8ul for ; Fri, 25 Jul 2014 09:01:08 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF451B2964 for ; Fri, 25 Jul 2014 09:01:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEHAKZ+0lOHCzIm/2dsb2JhbABZgkcjJB8zW7AZAQEBAQEBBplCGgEJh0UBgRAWd4QFAQEDEgsQXgEMCRVWJgEEGxqIIAEMmD+EYKFmEwSFe4kfLYJCD0QkgRsFow6NA4NIgjE X-IronPort-AV: E=Sophos; i="5.01,731,1400040000"; d="scan'208,217"; a="78292320" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 25 Jul 2014 12:01:06 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 25 Jul 2014 12:01:05 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 12:01:04 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: call for adoption - SACM Requirements document Thread-Index: Ac+oIaIASIPeBA+YRliV8UD+pd4sqA== Date: Fri, 25 Jul 2014 16:01:03 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C853D36@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C853D36AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/Kp6tyZgENpdXbtl7kpfnYruLFgE Subject: [sacm] call for adoption - SACM Requirements document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:01:12 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C853D36AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the SACM WG meeting today the people in the room and on jabber were in c= onsensus that the next version of https://datatracker.ietf.org/doc/draft-ca= mwinget-sacm-requirements/ should be published as WG Internet-Drafts. If th= ere are any concerns, comments or questions related to this decision please= express them before 7/31. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C853D36AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the SACM WG meeting today the people in the room = and on jabber were in consensus that the next version of https://datatracker.ietf.org/doc/draft-camwinget-sacm-requirements/ should be published as WG Internet-Drafts. If there are any concerns, com= ments or questions related to this decision please express them before 7/31.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C853D36AZFFEXMB04globa_-- From nobody Fri Jul 25 12:37:07 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119981A0418 for ; Fri, 25 Jul 2014 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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_SORBS_WEB=0.77, 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 GJx7cRZw5oi7 for ; Fri, 25 Jul 2014 12:37:04 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F251A03BE for ; Fri, 25 Jul 2014 12:37:03 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so5632042qgd.19 for ; Fri, 25 Jul 2014 12:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=DsfbSh69GoN6k8ACv4Aw2lk7KHzpi1kbG1bEbhvIZVU=; b=YE2yde4UuAbblC3Q7o9VYrUwX6GxsSVCozqYz24b3OkxU/nd0XmeRFtCPhUZ1YniFS e4jW635+cCEPW0fGxFN3xxNERULSHBeb4dJRd1HqLmh6q+SONcJfpp9ti0tBeTm5h4rN DxGIHE4OeoV7Hv2b+0ehEZ+vB3MkQ/z6Z0EKXTfExKqoVPFWpRXkNRyZ5f31fueFHP3r foP4drd3LYGKmW8omAT7gkl8mfaBAyMhVsNII5VE/aY5hx6BwJm9MPkUc9Qqw3r6Nm97 K2qqNNcmJdCumwYzZ/ssvSl73uwYxvDCXCBtyLvYQTveM9FCE58KyjD7URkJpGkFboss RKZg== X-Received: by 10.140.40.165 with SMTP id x34mr29501624qgx.23.1406317022260; Fri, 25 Jul 2014 12:37:02 -0700 (PDT) Received: from [10.205.141.218] ([209.226.201.241]) by mx.google.com with ESMTPSA id 80sm12264312qgr.38.2014.07.25.12.37.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 12:37:01 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_0D715354-9C99-44B7-B740-161A36F0DC19"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 25 Jul 2014 15:36:59 -0400 To: sacm@ietf.org Message-Id: <41E7D251-A871-4DB5-AD2B-0F6833DF6F7A@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/w84Mk6fHyszUFIIXK9LT4iVLG3A Subject: [sacm] SACM IETF 90 Minutes Available X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:37:05 -0000 --Apple-Mail=_0D715354-9C99-44B7-B740-161A36F0DC19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All: I=92ve updated the minutes to reflect this morning=92s session here: = http://www.ietf.org/proceedings/90/minutes/minutes-90-sacm. Special = thanks to Dave Waltermire and Chris Inacio for volunteering to take = notes. Please review the minutes at your leisure, but provide feedback where = you can. Regards, Adam --Apple-Mail=_0D715354-9C99-44B7-B740-161A36F0DC19 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 iQEcBAEBCgAGBQJT0rHbAAoJEILmIVe/2cgG4zwH/0K3nt51F2sN279KQmsToCvT XljsuxmGAHlIoYivFF6fhJ/3vC/GQHHB9txKBaBlGSXN9mhPEbxaMwCANRSWOF1n 3HF9+6tSXgRXRrijIwuHBjRRcSJo3wSr3R3KyB7gTXrVTCCecUN+OhjYpP5ZGN6Q QKBUx7kb2kS4thdmzOtpaGTAT4qXPqIXbRRzcUdmOS408SgJQTayzbfdBsAUuiYG 4Ay4kFO/7HALXxFEUGDfFvEXevvTLlydfMhP7qXAvDERul+iW/kQPPaeyF7LRBg9 nLJl2ZJdKFS5DmlODdiD3187UU7MLzrA1wfs6DERHgsrGFuYtxXFanyLrssuMX4= =JnJF -----END PGP SIGNATURE----- --Apple-Mail=_0D715354-9C99-44B7-B740-161A36F0DC19-- From nobody Sun Jul 27 14:38:50 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617EF1A0390 for ; Sun, 27 Jul 2014 14:38:47 -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 nCV6vYK2s2_9 for ; Sun, 27 Jul 2014 14:38:45 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A225A1A031A for ; Sun, 27 Jul 2014 14:38:45 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so9315701pab.29 for ; Sun, 27 Jul 2014 14:38:45 -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=09Aupfhw+4E9ICz3WjrQ1yCxlrGJBzJnrIFJC3VMcSo=; b=GYcvYHmHI8Yg8FHsls61MMDBxZwDNrvpSUzc0PlFKykaYxZ87Qi3y5rZeqEb6+Qsf7 F/5gqyiMzV2ClZl+X2KTAvr8YDTaencgNlHgHHd6gNm7i8QzWAsgDL56KZBRmGBrX9ik 9fQRxlW6NHGIXIE106ram67z0bJSecLAwea6zJv7TErmxHuZCMc2JjyXtALlZSo9+K/h dEA9jQ5GKkzVhfL67+aJd2LUHob64yxRC7/4GMhB03DZDex+JJEnf6KChUsRG2G2UWih hazUHOn8vQ32mJaIAFfEPSl6AdUfrlzHRgvdyeim2fm+gE+0kDU9d33n5Ha4v+W3OhYm xJkg== MIME-Version: 1.0 X-Received: by 10.69.26.134 with SMTP id iy6mr5724587pbd.115.1406497125225; Sun, 27 Jul 2014 14:38:45 -0700 (PDT) Received: by 10.70.60.162 with HTTP; Sun, 27 Jul 2014 14:38:45 -0700 (PDT) In-Reply-To: <41E7D251-A871-4DB5-AD2B-0F6833DF6F7A@gmail.com> References: <41E7D251-A871-4DB5-AD2B-0F6833DF6F7A@gmail.com> Date: Sun, 27 Jul 2014 23:38:45 +0200 Message-ID: From: Jerome Athias To: "Adam W. Montville" Content-Type: multipart/alternative; boundary=001a1134a71c86dad104ff33a1ed Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/DfqHCdhEN0nRFhHJkjAzSs3qrfk Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM IETF 90 Minutes Available X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 21:38:47 -0000 --001a1134a71c86dad104ff33a1ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi In case that could be helpful (with some kind of abstraction), let's say regarding the vision and architecture ( CAESARS vs SESAR) http://www.sesarju.eu/sesar-solutions/system-wide-information-management/bu= ilding-swim On Friday, July 25, 2014, Adam W. Montville wrote: > All: > > I=E2=80=99ve updated the minutes to reflect this morning=E2=80=99s sessio= n here: > http://www.ietf.org/proceedings/90/minutes/minutes-90-sacm. Special > thanks to Dave Waltermire and Chris Inacio for volunteering to take notes= . > > Please review the minutes at your leisure, but provide feedback where you > can. > > Regards, > > Adam > --001a1134a71c86dad104ff33a1ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi

In case that could be helpful (with some kind of abst= raction), let's say regarding the vision and architecture ( CAESARS vs = SESAR)=C2=A0http://www.sesarju.eu/sesa= r-solutions/system-wide-information-management/building-swim

On Friday, July 25, 2014, Adam W. Montville <adam.w.montville@gmail.com> wrote:
All:

I=E2=80=99ve updated the minutes to reflect this morning=E2=80=99s session = here: http://www.ietf.org/proceedings/90/minutes/minutes-90-s= acm. =C2=A0Special thanks to Dave Waltermire and Chris Inacio for volun= teering to take notes.

Please review the minutes at your leisure, but provide feedback where you c= an.

Regards,

Adam
--001a1134a71c86dad104ff33a1ed-- From nobody Wed Jul 30 10:54:56 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC441A01B0 for ; Wed, 30 Jul 2014 10:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 am0mlNNWtFh5 for ; Wed, 30 Jul 2014 10:54:45 -0700 (PDT) Received: from worker2.doodle.com (worker2.doodle.com [188.92.145.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756981A01C5 for ; Wed, 30 Jul 2014 10:54:45 -0700 (PDT) Received: from worker2.doodle.com (localhost [127.0.0.1]) by worker2.doodle.com (Postfix) with ESMTP id 519E39282DC for ; Wed, 30 Jul 2014 19:54:43 +0200 (CEST) Date: Wed, 30 Jul 2014 19:54:43 +0200 (CEST) From: "Dan Romascanu (via Doodle)" To: Message-ID: <1979548784.154072.1406742883331.POLL_INVITECONTACT_PARTICIPANT_INVITATION.doodle@worker2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_154071_850320446.1406742883331" Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/R8Ub3rWz7k0SY-47BZY6nHuQSrw Subject: [sacm] SACM Virtual Interim Meeting - September 2014 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Dan Romascanu List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 17:54:52 -0000 ------=_Part_154071_850320446.1406742883331 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi there, Dan Romascanu (dromasca@avaya.com) invites you to participate in the Doodle poll "SACM Virtual Interim Meeting - September 2014". Dan Romascanu says: As discussed at IETF-90 - this is the Doodle poll to find the best time for a 2 hours virtual interim meeting of the SACM WG to make progress on the items in the WG charter Participate now https://doodle.com/2tihcn6hmmg7chxy?tmail=3Dpoll_invitecontact_participant_= invitation&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/main.html?tlink=3DcheckOutLink&tmail=3Dpoll_inviteconta= ct_participant_invitation) ---------------------------------------------------------------------- You have received this e-mail because "Dan Romascanu" has invited you to participate in the Doodle poll "SACM Virtual Interim Meeting - September 2014." ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_154071_850320446.1406742883331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
=09
Dan Romascanu invites you t= o participate in the Doodle poll "SACM Virtual Interim Meeting - Septe= mber 2014."
=09
=09 =09 =09
=09 =09=09 =09=09 =09=09=09=09=09=09=09 =09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09
=09=09 =09=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09=09 =09=09 =09=09 =09=09 =09=09 =09 =09=09 =09=09
=09=09 =09 =09=09 =09 =09=09=09 =09 =09=09=09
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09 =09=09
=09=09=09=09=09=09
=09=09 =09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"SACM Virtual= Interim Meeting - September 2014". =09=09=09=09=09=09
=09=09=09=09=09
=09=09 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09Dan Romascanu says: =09=09=09=09=09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09As discussed at IETF-90 - this is the Doodle poll to f= ind the best time for a 2 hours virtual interim meeting of the SACM WG to m= ake progress on the items in the WG charter =09=09=09=09=09=09
=09=09=09=09=09
=20 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate now =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=20 =09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date= for meeting with a group of people. Learn more about how Doodle works.
=20 =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09 =20 =09=09
=09=09 =09You have received this e-mail because "Dan Romascanu&= quot; has invited you to participate in the Doodle poll "SACM Virtual = Interim Meeting - September 2014." =09=09
=09
=09 =09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09