Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc

"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Mon, 07 August 2017 04:54 UTC

Return-Path: <ncamwing@cisco.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AC4127601 for <sacm@ietfa.amsl.com>; Sun, 6 Aug 2017 21:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 fRe5qh77qwel for <sacm@ietfa.amsl.com>; Sun, 6 Aug 2017 21:54:42 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B161274A5 for <sacm@ietf.org>; Sun, 6 Aug 2017 21:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5830; q=dns/txt; s=iport; t=1502081682; x=1503291282; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=b1+ai1jiHr/c63/Wsa4gV3J5TPd02gbv/0lUN9wsezI=; b=RDEdz4rQdgsU6wqv+eUO0wFM6hIYkNGljIZnvwcLoCPw4T2YP71RoTgn aJaTf5whqyagEJSz3r38l6t6foGBocCYItbX+llUuomYqYwz1W6RziT/T wQjqUj7e7ezPYTx4g3nvuTSwRy84/L9YzYGft9Dm8sERnTe3AtFRs1AbI I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CcAgBZ8odZ/4gNJK1cHAEBBAEBCgEBgy0tZG0nB44IkAmBTJY3DoIELIFggzschDE/GAECAQEBAQEBAWsohRkGIxEzBx0BCBIIAhEVAgQwFQIQBAEJCYovEK0igiaLSAEBAQEBAQEDAQEBAQEBAQEBGgWBC4IZBIICgy8rC4JxhDAdEBY/glQwgjEFoA8Ch1GMYIIPhVqDeYUkgUaWBwEfOD9LdxUfKhIBhwd2hkMBJAeBBYEPAQEB
X-IronPort-AV: E=Sophos;i="5.41,336,1498521600"; d="scan'208";a="467691203"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2017 04:54:18 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v774sIsC004697 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Aug 2017 04:54:18 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Aug 2017 00:54:17 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 7 Aug 2017 00:54:17 -0400
From: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
To: Karen O'Donoghue <odonoghue@isoc.org>, "sacm@ietf.org" <sacm@ietf.org>
Thread-Topic: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc
Thread-Index: AQHTDzk5zaVaLou9b0eM0Yv7igddPw==
Date: Mon, 07 Aug 2017 04:54:17 +0000
Message-ID: <9F2CC6FD-105E-4467-BF68-D76809BA188B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.248.50]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D74A55895EB3F74F87BA5226F1FD61E7@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/Qi3zl6AkOUHUbt9RYs0CLitZ1ok>
Subject: Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Aug 2017 04:54:44 -0000

Hi,

Not being familiar with SWIDs and trying to get thru this draft,  I will provide initial comments though I’m still only on Section 3.

My general read of this was that it would be a SWIDs mapping to either a particular data model to adhere to SACM and/or that it would use the NEA data model and transfer using PA-TNC and PB-TNC.  Is that correct?  I do not get that impression from Section 3, so am somewhat confused.

Here are some comments thus far:
If indeed the draft is about extending the PA-TNC model to include SWIDs…This can limit the scalability and deployment use cases; per section 2.1.3 of RFC 7632, as it states there is desire to “collect a set of attribute values related to one or more endpoints”.

-	As there are no references to the TNC standards (and those have been absorbed in NEA),
I suggest to remove the last paragraph and Table 1 of Section 1.1

Section 1.1
“The attributes defined in this document are used to
   communicate software inventory evidence, collected from a range of
   possible sources, from the posture collector on the endpoint to the
   posture validator on a NEA Server using the PA-TNC interface, as
   shown in Figure 1 below.”
-	“Posture collector on the endpoint”,  
why does the collector need to be on an endpoint?  

Section 2, specifically 2.1.1 and 2.1.2 If the definition is to define a set of PA-TNC attributes; they are meant to be carried thru the NEA model; as such the recipient MUST be a NEA Server or at minimum a Posture Validator as that is the component that can accept NEA’s Posture Attributes.  I’m not sure these 2 sections are needed as they have to map to the NEA architecture which is described in 2.1.3

Section 2.2: is this section necessary?  There are many more use cases not supported, so would opt to remove this section.

Section 2.3: There must be normative language to make these requirements.  Also, it would be best suited to have this section also set in the context of the SACM requirements and reference the requirements enumerated in the soon to be published https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/ draft

Section 2.5: What does it mean to “provide reliable delivery”?  Does this imply TCP vs UDP? 

Section 3.2 The beginning of the draft and title infers that this draft is a mapping for NEA, which does define its own data model…so how can these map to “an open set of data models”?

Editorial

Section: Introduction
Awkward sentence: “When reported endpoint
   software installation inventory lists, shortened to "software
   inventories" for the remainder of this document, contain patch level
   data for identified software, further comparison to vulnerability or
   threat alerts can be used to determine an endpoint's exposure to
   attack. “

If I understand the intent, I suggest: “Endpoint software installation 
inventory lists (hereinafter “software inventories”) 
can further be used to determine an endpoint’s 
exposure to attack based on comparison to vulnerability or threat alerts against
identified software’s patch level data.”

Section 1.3 “Software Identifier” has a first reference to SWIMA that should be referenced first;
e.e. Software Inventory Message Attributes (SWIMA). 


More to come soon,
	Nancy

On 7/28/17, 7:40 AM, "sacm on behalf of Karen O'Donoghue" <sacm-bounces@ietf.org on behalf of odonoghue@isoc.org> wrote:

    Folks,
    
    This begins a 3 week working group last call (WGLC) for the following document: 
    
    Software Inventory Message and Attributes (SWIMA) for PA-TNC
    https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/
    
    We have chosen to do a 3 week WGLC to account for post IETF recovery and August vacations. 
    
    Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list will be used to determine WG consensus to proceed. 
    
    Please send all comments in by Friday 18 August 2017.  
    
    Thank you!
    Karen and Adam