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

"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Mon, 14 August 2017 20:48 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 8BD18132425 for <sacm@ietfa.amsl.com>; Mon, 14 Aug 2017 13:48:39 -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 pDGjxtwXUlKt for <sacm@ietfa.amsl.com>; Mon, 14 Aug 2017 13:48:36 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B37132422 for <sacm@ietf.org>; Mon, 14 Aug 2017 13:48:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16738; q=dns/txt; s=iport; t=1502743716; x=1503953316; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cTDMLYd76nvsdW8lC2J8v8RC5zybxfVQVd4Sc7ry4Ro=; b=US8gqk+8kvn2CUY7BQ7xpQ2xzxfdklGznCkC5FeYsTLWYT2/QmKqbJmI G7Rk3Sy2OaTHly2CvR0IaS6HqMILQfv5ry4kqAlT+0RzPyHltHoUgvX43 aX7fzix2asSKvofIvlI9xfEnvTO/2pqrq2AjiTjbkJpvn5hTexcy1meWq g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DNAAB/C5JZ/5BdJa1TChoBAQEBAgEBAQEIAQEBAYNaZIEUB44KkBGBbneVIYISLIFggzsCGoRfPxgBAgEBAQEBAQFrKIUZAQQBIxEzIgIBCBIIAiYCAgIwFQIOAgQBCQkbigwIEK0CgiaLbAEBAQEBAQEBAQEBAQEBAQEBAQEBGQWBC4IZBIICgy4BK4FwWDSESAUQgykwgjEFoDECh1GMaYIPhV2DeoZvlhQBHziBCncVHyoSAYUEHIFndodVASQHgQWBDwEBAQ
X-IronPort-AV: E=Sophos;i="5.41,374,1498521600"; d="scan'208";a="282629519"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2017 20:48:35 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v7EKmZnJ024242 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Aug 2017 20:48:35 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Aug 2017 16:48:34 -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, 14 Aug 2017 16:48:34 -0400
From: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
To: "Schmidt, Charles M." <cmschmidt@mitre.org>, 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: AQHTDzk5zaVaLou9b0eM0Yv7igddP6J5YbQAgArK54A=
Date: Mon, 14 Aug 2017 20:48:34 +0000
Message-ID: <982B6BB4-9D8C-4C19-BBF3-096BBFE6D94C@cisco.com>
References: <9F2CC6FD-105E-4467-BF68-D76809BA188B@cisco.com> <BN6PR09MB11866327B7470AFEBC92345FABB50@BN6PR09MB1186.namprd09.prod.outlook.com>
In-Reply-To: <BN6PR09MB11866327B7470AFEBC92345FABB50@BN6PR09MB1186.namprd09.prod.outlook.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.155.86.135]
Content-Type: text/plain; charset="utf-8"
Content-ID: <173661ED360C174880DE9B1228A2FE29@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/9KKWasUcFLjVdfQndA6lFUIkxWE>
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, 14 Aug 2017 20:48:39 -0000

Hi Charles,

Apologies as I ran out of time, so didn’t get to fully read the spec, but below are my responses and a couple more comments.

Please see below:

On 8/7/17, 9:59 AM, "sacm on behalf of Schmidt, Charles M." <sacm-bounces@ietf.org on behalf of cmschmidt@mitre.org> wrote:

    Hi Nancy,
    
    Thanks a bunch for the comments. Responses inline:
    
    > 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.
    
    A few points: SWIMA is not SWID-specific. (The first drafts were, but it has since changed to support an extensible list of software inventory records, of which SWIDs are one possible record type.) 
[NCW] Got it, that helps.
    
    Also, NEA does not have a single data model. Instead, the PA protocol is a "lightweight wrapper" for a set of attributes to be exchanged. These attributes are intended to be extensible to allow a growing set of bindings to be defined, each of which define their own conditions for Collectors and Validators, and each of which support their own network attributes and data model. 
    
    So what you describe is not, in fact, the goal of SWIMA. SWIMA defines a NEA PA extension that defines new attributes and Collector/Validator behaviors to manage the collection and delivery of software inventory information.
[NCW]  What wasn’t clear is that I think the draft is defining new “message types” as PA-TNC extensions to enable the request/response for sw inventory information….but I had to read well down into section 5 to grok it.  May be useful to actually state that in the Introduction too.


    > 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”.
    
    I'm confused by what you mean here. SWIMA is not intended it single-handedly fulfill this requirement. It does, however, move towards fulfillment of this requirement by enabling appropriate collection of software inventory information. Thus there is no limiting of the SACM use cases.
[NCW] As this is PA-TNC and based on NEA, the intent of NEA was to only have the “target endpoint” do such reporting.  That is, Section 5.1.1 of RFC 5209 leads me to believe that the reporting is to be of “that” specific endpoint device (e.g. to what SACM refers to as the “target” endpoint).  So, my point was that in SACM, we’d like to have collectors that may have repositories of sw inventories of more than 1 target endpoint. 
    
    > -	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
    
    I agree the table is unnecessary. I do believe it is appropriate to retain the final paragraph to recognize that SWIMA came from TCG work and that this derivation is not a bifurcation.
[NCW] That’s fine.
    
    > 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?
    
    The NEA specification (RFC 5209) states that Posture Collectors are on NEA Clients, which is a type of endpoint. Is there anything that is not an endpoint on which you think there should be a posture collector?
[NCW] Per my previous comment, there are repositories that can keep inventory of more than 1 target 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
    
    2.1.1 and 2.1.2 are intended to outline the specific purpose of the extension of the PA-TNC specification that creates SWIMA. In other words, they identify why SWIMA was created. The three use cases identified in PA TNC are: 
    - Initial Client-Triggered Assessment - Client sends information when requesting to join a network
    - Server-Initiated Assessment with Remediation - Verifier requests information from the client.
    - Client-Triggered Reassessment - Client detects a situation where it needs to push updated information to the server.
    
    All of these represent cases under which PA-TNC can operate. SWIMA supports these cases as well. They don't talk about the same thing as 2.1.1 or 2.1.2, though. 2.1.1 and 2.1.2 identify the uses of software inventory information supported by SWIMA; the PA-TNC use cases identify the cases under which information might be exchanged in general. These are non-overlapping and complementary.

    > Section 2.2: is this section necessary?  There are many more use cases not
    > supported, so would opt to remove this section.
    
    I believe this is helpful because these address likely areas of confusion. Yes, this is not an exhaustive list of unsupported use cases. However, a reasonable reader might initially assume that SWIMA includes guidance for converting software inventory into a single data model (for example). This section would make it clear that conversion of information is outside the scope of SWIMA.
[NCW] While I can see them as use cases, it is meant to be for SACM….I am not sure why such elaboration is needed and question why these are not brought back to map how this draft helps address the SACM adopted use case (e.g.RFC7632).  Which I know it does….but again, I question why it is standalone vs. its relevance to other SACM documents (e.g. the Use case, terminology and requirements).
    
    > Section 2.3: There must be normative language to make these requirements.
    
    These are not requirements to implementers. These are design requirements for the specification itself. This is why these are not normative.
    
    > 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
    
    I'll have to think about that, but my gut response is that the SWIMA requirements and the SACM requirements are not the same thing. SWIMA certainly must conform to SACM requirements, but it does not need to completely fulfill them - SWIMA is one part of a larger solution. The SWIMA requirements, in turn, are intended to focus just on SWIMA itself, and thus go beyond SCAP requirements. Even when they align (e.g., requirement for interoperability) they are not talking about the same thing. SWIMA interoperability just means that the protocols allow SWIMA-PV and SWIMA-PCs from different vendors to talk to each other, not that the information collected by SWIMA be useable across the entire SACM architecture. The bottom line is that, despite the common use of the term "requirements", my initial feeling is that these are not alike enough for a mapping to be usefully instructive. Do you have specific mappings that you feel would be appropriate?
[NCW] This draft is about defining 2 new message types within NEA, what I read in this section are general implementation and considerations about NEA that imho do fall as being relevant to the sacm-requirements draft.
    
    > Section 2.5: What does it mean to “provide reliable delivery”?  Does this
    > imply TCP vs UDP?
    
    This is intended to mean that, if one party sends a message, the other party will either receive it or the sender will know it was not received. I'll add a clarification to that effect since, upon a quick search, it looks like there is no formal definition of the term. 
    
    It does not require any particular way of accomplishing reliable delivery (e.g., TCP) - just that reliable delivery is required.
[NCW]  A clarification will be good.
    
    > 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”?
    
    NEA does not define a single data model. It defines a framework which can be used to support an extensible list of attributes, each of which can support their own data model.
    
    In 3.2, the term "data model" refers not to the attributes, but to the way that a software inventory record is expressed. I should probably clarify that. "Open" set is probably the wrong word; I should probably say "Extensible" set. This reflects that SWIMA can convey records using any inventory record structure and imposes no limits on those structures.
[NCW] Perhaps this section could be moved to “after” the explanation of the PA-TNC messages.  I get it now, but consistency to the use of the terms message and record should be made (or clarified).
    
    > 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.”
    
    Yeah - my sentence is overly convoluted. Your suggestion is a big improvement. Thank you.
    
    > Section 1.3 “Software Identifier” has a first reference to SWIMA that should
    > be referenced first;
    > e.e. Software Inventory Message Attributes (SWIMA).
    
    Per Adam's suggestion, I'll be using "SWIMA" to label a lot more things. I'll add a definition of this term to the introduction so we are covered for the document.
[NCW] Sounds good.
    
    > More to come soon,
    > 	Nancy
[NCW] and here are a few more comments:
Section 1 state: “This specification is designed to only report software that is
   installed on an endpoint.”
  Suggest to: “a target endpoint”  (same for the following sentence)

Section 3.3 or somewhere in Section 3: it would be good to actually see the flow within the NEA architecture and encapsulations

Section 3.3 “SW-PVs MUST discard without error any SW Response attributes that
   they receive for which they do not know the SW Request parameters
   that led to this SW Response.”
- Why is this a MUST?  This can be done by policy as an implementation can choose to discard or send an error if the entire response if it only gets attributes it doesn’t understand.  
- What about a SW-PC getting a request it can not honor (e.g. it doesn’t understand any of the attributes or due to its own policy)?
- Are these messages to be protected?  It seems that unless there is a guard against replays and request matching, it could be an attack vector?

Section 5.4
- Why is there only a SW Request and not a SW [inventory] response?

    Great! Thanks a bunch for the feedback.
    
    Charles