Software Inventory Message and Attributes (SWIMA) for PA-TNC
draft-ietf-sacm-nea-swima-patnc-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-07-09
|
05 | (System) | IANA registries were updated to include RFC8412 |
2018-07-05
|
05 | (System) | Received changes through RFC Editor sync (created alias RFC 8412, changed abstract to 'This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with … Received changes through RFC Editor sync (created alias RFC 8412, changed abstract to 'This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).', changed pages to 101, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-07-05, changed IESG state to RFC Published) |
2018-07-05
|
05 | (System) | RFC published |
2018-07-02
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-06-11
|
05 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-06-04
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-06-04
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2018-06-04
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-06-01
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-06-01
|
05 | (System) | IANA Action state changed to In Progress from On Hold |
2018-05-07
|
05 | (System) | RFC Editor state changed to IANA from AUTH |
2018-04-16
|
05 | (System) | RFC Editor state changed to AUTH from EDIT |
2018-04-03
|
05 | Charles Schmidt | New version available: draft-ietf-sacm-nea-swima-patnc-05.txt |
2018-04-03
|
05 | (System) | New version approved |
2018-04-03
|
05 | (System) | Request for posting confirmation emailed to previous authors: David Waltermire , Chris Coffin , Charles Schmidt , Daniel Haynes , Jessica Fitzgerald-McKay |
2018-04-03
|
05 | Charles Schmidt | Uploaded new revision |
2018-04-02
|
04 | Benjamin Kaduk | Shepherding AD changed to Benjamin Kaduk |
2018-03-26
|
04 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'No Response' |
2018-03-13
|
04 | (System) | IANA Action state changed to On Hold from In Progress |
2018-03-09
|
04 | (System) | RFC Editor state changed to EDIT |
2018-03-09
|
04 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-03-09
|
04 | (System) | Announcement was received by RFC Editor |
2018-03-09
|
04 | (System) | IANA Action state changed to In Progress |
2018-03-09
|
04 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2018-03-09
|
04 | Cindy Morgan | IESG has approved the document |
2018-03-09
|
04 | Cindy Morgan | Closed "Approve" ballot |
2018-03-09
|
04 | Cindy Morgan | Ballot approval text was generated |
2018-03-08
|
04 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'No Response' |
2018-03-06
|
04 | Cindy Morgan | New version available: draft-ietf-sacm-nea-swima-patnc-04.txt |
2018-03-06
|
04 | (System) | Secretariat manually posting. Approvals already received |
2018-03-06
|
04 | Cindy Morgan | Uploaded new revision |
2018-03-01
|
03 | Ben Campbell | [Ballot comment] Thanks for addressing my DISCUSS points and comments! |
2018-03-01
|
03 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss |
2018-02-28
|
03 | Alexey Melnikov | [Ballot comment] Thank you for addressing my DISCUSS and many of my comments. Remaining comments listed below (plus see updated point #7) Minor: (Points not … [Ballot comment] Thank you for addressing my DISCUSS and many of my comments. Remaining comments listed below (plus see updated point #7) Minor: (Points not mentioned below were addressed). 2) When referencing RFC 5198 (Network Unicode format), I personally prefer a stricter version that disallows control characters (other than CR LF). In RFC 5198, use of control characters is only "SHOULD NOT". So you might want to make a stronger statement on this. 5) In Section 4.3. Required Exchanges All SWIMA-PVs and SWIMA-PCs MUST support both types of exchanges. I question the value in requiring SWIMA-PVs in supporting both types of exchanges. For example, if a SWIMA-PV never uses subscriptions, it doesn't seem to need to handle subscription responses. Similar text in 5.2: All SWIMA-PVs MUST be capable of sending SWIMA Request attributes and be capable of receiving and processing all SWIMA Response attributes as well as PA-TNC Error attributes. 6) Use of fields which can contain both human readable and possibly machine readable information - I think this is rather handwavy and I wish you would be more specific. Also consider issues raised in BCP 18 (RFC 2277), in particular language tagging of human readable text. 7) (downgraded from DISCUSS): SWID registry is using "http://invalid.unavailable" Tag Creator RegID value in Section 6.1.1. invalid.unavailable is not a valid domain name and "unavailable" is not registered in the special-use domain registry I am not entirely sure how big of a problem this is, but use of something which can be interpreted as a URI in a non existing non special-use domain seems like a bad idea. Note, if you can change the value to "http://unavailable.invalid", that would address my concern. |
2018-02-28
|
03 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2018-02-28
|
03 | Alexey Melnikov | [Ballot comment] Minor: (Points not mentioned below were addressed). 2) When referencing RFC 5198 (Network Unicode format), I personally prefer a stricter version that disallows … [Ballot comment] Minor: (Points not mentioned below were addressed). 2) When referencing RFC 5198 (Network Unicode format), I personally prefer a stricter version that disallows control characters (other than CR LF). In RFC 5198, use of control characters is only "SHOULD NOT". So you might want to make a stronger statement on this. 5) In Section 4.3. Required Exchanges All SWIMA-PVs and SWIMA-PCs MUST support both types of exchanges. I question the value in requiring SWIMA-PVs in supporting both types of exchanges. For example, if a SWIMA-PV never uses subscriptions, it doesn't seem to need to handle subscription responses. Similar text in 5.2: All SWIMA-PVs MUST be capable of sending SWIMA Request attributes and be capable of receiving and processing all SWIMA Response attributes as well as PA-TNC Error attributes. 6) Use of fields which can contain both human readable and possibly machine readable information - I think this is rather handwavy and I wish you would be more specific. Also consider issues raised in BCP 18 (RFC 2277), in particular language tagging of human readable text. 7) (downgraded from DISCUSS): SWID registry is using "http://invalid.unavailable" Tag Creator RegID value in Section 6.1.1. invalid.unavailable is not a valid domain name and "unavailable" is not registered in the special-use domain registry I am not entirely sure how big of a problem this is, but use of something which can be interpreted as a URI in a non existing non special-use domain seems like a bad idea. Note, if you can change the value to "http://unavailable.invalid", that would address my concern. |
2018-02-28
|
03 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2018-02-27
|
03 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-02-27
|
03 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2018-02-27
|
03 | Charles Schmidt | New version available: draft-ietf-sacm-nea-swima-patnc-03.txt |
2018-02-27
|
03 | (System) | New version approved |
2018-02-27
|
03 | (System) | Request for posting confirmation emailed to previous authors: David Waltermire , sacm-chairs@ietf.org, Chris Coffin , Charles Schmidt , Jessica Fitzgerald-McKay , Daniel Haynes |
2018-02-27
|
03 | Charles Schmidt | Uploaded new revision |
2018-02-22
|
02 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead |
2018-02-22
|
02 | Mirja Kühlewind | [Ballot comment] The shepherd write-up says: "This document is being requested for publication as an Internet Standard RFC." I issued my ballot position under the … [Ballot comment] The shepherd write-up says: "This document is being requested for publication as an Internet Standard RFC." I issued my ballot position under the assumption that document is published as Proposed Standard as indicated in the datatracker. |
2018-02-22
|
02 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-02-22
|
02 | Alexey Melnikov | [Ballot discuss] This is generally a well written document, despite certain repetition of text. It was a pleasure to read. I have a couple of … [Ballot discuss] This is generally a well written document, despite certain repetition of text. It was a pleasure to read. I have a couple of issues that I would like to discuss. I believe they would be easy to resolve: 1) In Section 5.8, in the table (I believe this is repeated at least 3 more times elsewhere in the document): Software Locator: A string containing the Software Locator value. This is expressed as a URI. This field value MUST be normalized to Network Unicode format as described in Section 3.4.4. At minimum this text is misleading (or can be misread) and at maximum it is wrong. I think what you are trying to say is that the location value is first normalized to Network Unicode format as described in Section 3.4.4, then it is converted in UTF-8 and then it is encoded as a URI. (As opposed to doing something else, e.g. convert to URI first and then trying to normalize it). If this is correct, I suggest: A string containing the Software Locator value. This is expressed as a URI [RFC3986]. This field value MUST be first normalized to Network Unicode format as described in Section 3.4.4, then converted to UTF-8 [RFC3629] (if not already in UTF-8), then encoded as a URI. 2) SWID registry is using "http://invalid.unavailable" Tag Creator RegID value. invalid.unavailable is not a valid domain name and "unavailable" is not registered in the special-use domain registry I am not entirely sure how big of a problem this is, but use of something which can be interpreted as a URI in a non existing non special-use domain seems like a bad idea. |
2018-02-22
|
02 | Alexey Melnikov | [Ballot comment] Minor: 1) Please add a Normative Reference to [RFC3629] when mentioning UTF-8. 2) When referencing RFC 5198 (Network Unicode format), I … [Ballot comment] Minor: 1) Please add a Normative Reference to [RFC3629] when mentioning UTF-8. 2) When referencing RFC 5198 (Network Unicode format), I personally prefer a stricter version that disallows control characters (other than CR LF). In RFC 5198, use of control characters is only "SHOULD NOT". So you might want to make a stronger statement on this. 3) In Section 3.4.4. Software Locators The location is expressed as a URI string consisting of a scheme and path. [RFC3986] The location URI does not include an authority part. The last sentence: is this just a fact for file: URIs or is it absolute prohibition for all other schemes that can be used here? 4) In Section 3.8.1. Establishing Subscriptions A SWIMA-PC MUST have the ability to record and support multiple simultaneous subscriptions from a single party and from multiple parties. A SWIMA-PV MUST have the ability to record and support multiple simultaneous subscriptions to a single party and subscriptions to multiple parties. In order to improve interoperability it might be useful to specify a minimal limit on the number of multiple subscriptions per PV. 5) In Section 4.3. Required Exchanges All SWIMA-PVs and SWIMA-PCs MUST support both types of exchanges. I question the value in requiring SWIMA-PVs in supporting both types of exchanges. For example, if a SWIMA-PV never uses subscriptions, it doesn't seem to need to handle subscription responses. Similar text in 5.2: All SWIMA-PVs MUST be capable of sending SWIMA Request attributes and be capable of receiving and processing all SWIMA Response attributes as well as PA-TNC Error attributes. 6) Use of fields which can contain both human readable and possibly machine readable information - I think this is rather handwavy and I wish you would be more specific. Also consider issues raised in BCP 18 (RFC 2277), in particular language tagging of human readable text. 7) IANA Considerations Sections 10.2 and 10.3 contain: Software Inventory Message and Attributes for PA-TNC as the reference. This is not actually useful, because these tables are going to be extracted and copied to the www.iana.org website. You should add "[RFCXXXX]" to them, so that RFC Editor knows to replace it with the RFC number of this document once it is published. Nit: 8) 3.4. Core Software Reporting Information Different parameters in the SWIMA Request can influence what information is returned in the SWIMA Response. However, while each SWIMA Response provides different additional information about this installed software, they all share a common set of fields that support reliable software identification on an endpoint. These fields include: Software Identifiers, the Data Model Type, Record Identifiers, Software Locators, and Source Identifiers. These fields are present for each reported piece of software in each type of SWIMA Response. The following sections examine these three types of five types as per the previous sentence? information in more detail. |
2018-02-22
|
02 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2018-02-21
|
02 | Adam Roach | [Ballot comment] Thanks for everyone's work on this document. I support Ben's DISCUSS, his concerns regarding the treatment of privacy in §8, and EKR's concerns … [Ballot comment] Thanks for everyone's work on this document. I support Ben's DISCUSS, his concerns regarding the treatment of privacy in §8, and EKR's concerns regarding the phrasing "not generally considered to be sensitive." I also have a few very important comments about this document's handling of URIs. §3.4.4: > The location is expressed as a URI string consisting of a scheme and > path. [RFC3986] The location URI does not include an authority part. > The URI schema describes the context of the described location. For > example, in most cases the location of the installed software product > will be expressed in terms of its path in the filesystem. For such > locations, the location URI scheme MUST be "file" or the URI MUST > appear without a scheme. (I.e., "file" is default scheme.) It is > possible that other schemes could be used to represent other location > contexts. Apart from reserving the "file" scheme, this specification > does not reserve schemes. When representing software products in > other location contexts, tools MUST be consistent in their use of > schemes, but the exact string used in those schemes is not > normatively defined here. Please cite RFC 8098 in this paragraph. Saying that a URI can appear without a scheme is at least confusing and probably ambiguous. For example, I can't tell which of the following syntaxes are expected and/or allowed: 1. :///Applications/TurnipTwaddler 2. ///Applications/TurnipTwaddler 3. /Applications/TurnipTwaddler Read literally, the quoted paragraph describes the first. It probably means to describe the second (maybe?), but I suspect some implementors will interpret it as the third. This becomes even more problematic for Windows, where it might be interpreted to mean any of *four* things (where the final one is clearly wrong due to potential confusion between drive letters and URI schemes -- but which I'm sure will be implemented if not clearly spelled out): 1. :///C:/Program%20Files/TurnipTwaddler 2. ///C:/Program%20Files/TurnipTwaddler 3. /C:/Program%20Files/TurnipTwaddler 4. C:/Program%20Files/TurnipTwaddler To be clear, whatever you define in this document cannot allow the omission of a scheme to result in Form #4 above, as this is syntactically ambiguous. It also probably bears reiterating that omitting the "file" scheme from a URI doesn't exempt it from encoding according to RFC 8089 section 4 (e.g., including an unescaped space, as in "Program Files", would be syntactically invalid). Finally, I question the assertion that "The location URI does not include an authority part." It's been a while since I used Windows on a regular basis, but my recollection is that files -- including applications -- can be accessed from a CIFS filesystem without associating a local mount point with them. It would be impossible to describe the location of such applications if the authority is required to be omitted. It is easy to anticipate that future iterations of, e.g., Linux may have similar properties. (Popular desktops already allow userland access of files on unmounted access using full URIs, which necessarily include authority components; it is not far-fetched to imagine that this functionality might be incorporated into the kernel at some point). --------------------------------------------------------------------------- The following appears in several places: > | Software | A string containing the Software Locator value. | > | Locator | This is expressed as a URI. This field value | > | | MUST be normalized to Network Unicode format as | > | | described in Section 3.4.4. This string MUST NOT | > | | be NULL terminated. | Section 3.4.4 doesn't describe the use of Network Unicode format, so this text is confusing. I'll note that file URIs are generally going to be percent encoded, so they shouldn't contain any non-ASCII characters. Section 4 of RFC 8089 deals with encoding considerations for file URIs. Other URIs have their own encoding considerations, and it would be somewhat ambitious for this document to take on any encoding specification above and beyond what is already defined for each scheme. |
2018-02-21
|
02 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-02-21
|
02 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from No Record |
2018-02-21
|
02 | Alissa Cooper | [Ballot comment] The Gen-ART review raises some questions to which I'd like to see responses. https://datatracker.ietf.org/doc/review-ietf-sacm-nea-swima-patnc-02-genart-telechat-romascanu-2018-02-18/ |
2018-02-21
|
02 | Alissa Cooper | Ballot comment text updated for Alissa Cooper |
2018-02-21
|
02 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2018-02-21
|
02 | Ben Campbell | [Ballot discuss] (This is related to one of Ekr's comments, but I don't think it's quite the same.) In the first paragraph of §7.2, the … [Ballot discuss] (This is related to one of Ekr's comments, but I don't think it's quite the same.) In the first paragraph of §7.2, the conclusions seem to be based on the following sentence: "This is generally not considered to be problematic, as those with access to the endpoint can usually learn of everything disclosed by that endpoint’s records simply by inspecting other parts of the endpoint." This doesn’t seem like a reasonable assumption. Multiuser endpoints may well have access controls that prevent a given user from seeing all software packages installed on the system. This leads to the conclusion that the records on the endpoint are not sensitive. I do not think this document should draw that conclusion. Even if this were provably true for all existing systems, such an assumption could be problematic for future systems. |
2018-02-21
|
02 | Ben Campbell | [Ballot comment] Substantive Comments: §2.4: This seems to assume there is never a need to hide information from intermediaries. Is that the intent? (Or maybe … [Ballot comment] Substantive Comments: §2.4: This seems to assume there is never a need to hide information from intermediaries. Is that the intent? (Or maybe there aren't any intermediaries?) §3.4.3, -- first paragraph: What is the expected scope of uniqueness for record identifiers? -- In the sentence "The Record Identifier SHOULD remain unchanged if that record is modified.", why is the SHOULD not a MUST? What would happen if the identifier did change? §3.4.4: -- "However, if that directory is shared by other software products, the "location" SHOULD be the location of the primary executable associated with the software product." I'm confused by the the condition, since sharing a directory with other products doesn't seem to introduce the ambiguity that the rest of the sentence assumes. Perhaps this was meant to be about situations where a software package is installed across multiple directories? -- "Even a probable location for a software product is preferable to using a zero-length locator." This could use elaboration; do you expect the collector to guess? §7.1: " Some tools might not be designed to update records in the Software Inventory Evidence Collection in real time,..." Wasn't there a normative requirement that they be capable of this? §8, -- 2nd paragraph: It’s worth mentioning that in some contexts this sort of information could expose the user to severe personal risk, including the risk of death. -- Last paragraph: "For this reason, privacy safeguards might be necessary for collected inventory information." Can this be stated more strongly than "might be necessary"? Editorial Comments and Nits: §3.8.5, first paragraph: "As noted in Section 3.6 SWIMA-PCs MUST ..." Please reserve 2119 keywords for the authoritative statement of a requirement; that is, please do not use them to refer to requirements defined elsewhere. (Note that this pattern occurs multiple times in the draft.) §9: Nit: is there are reasons to violate the convention that IANA, security, and privacy considerations are the last substantive sections in in the body of an RFC? |
2018-02-21
|
02 | Ben Campbell | [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell |
2018-02-21
|
02 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-02-21
|
02 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-02-21
|
02 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-02-21
|
02 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-02-21
|
02 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-02-21
|
02 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-02-21
|
02 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-02-20
|
02 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-02-20
|
02 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-sacm-nea-swima-patnc-01. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-sacm-nea-swima-patnc-01. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the PA Subtypes registry on the Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) Parameters regsitry page located at: https://www.iana.org/assignments/pb-tnc-parameters/ the following registration is to be added: PEN: 0 Integer: 9 Name: SWIMA Attributes Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the PA-TNC Attribute Types registry on the Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters registry page located at: https://www.iana.org/assignments/pa-tnc-parameters/ the following registrations will be added to the registry: +-----+---------+-------------------+-------------------------------+ | PEN | Integer | Name | Defining Specification | +-----+---------+-------------------+-------------------------------+ | 0 | 17 | SWIMA Request | [ RFC-to-be ] | | | | | | | 0 | 18 | Software | [ RFC-to-be ] | | | | Identifier | | | | | Inventory | | | | | | | | 0 | 19 | Software | [ RFC-to-be ] | | | | Identifier Events | | | | | | | | 0 | 20 | Software | [ RFC-to-be ] | | | | Inventory | | | | | | | | 0 | 21 | Software Events | [ RFC-to-be ] | | | | | | | 0 | 22 | Subscription | [ RFC-to-be ] | | | | Status Request | | | | | | | | 0 | 23 | Subscription | [ RFC-to-be ] | | | | Status Response | | | | | | | | 0 | 24 | Source Metadata | [ RFC-to-be ] | | | | Request | | | | | | | | 0 | 25 | Source Metadata | [ RFC-to-be ] | | | | Response | | | | | | | | 0 | 26 - 31 | Reserved for | [ RFC-to-be ] | | | | future use | | +-----+---------+-------------------+-------------------------------+ IANA Question --> are Integer values 13 - 16 defined in another document, or is there a reason these values are not used? As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, in the PA-TNC Error Codes registry on the Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters registry page located at: https://www.iana.org/assignments/pa-tnc-parameters/ the following registrations will be added to the registry: +-----+---------+--------------------------------------+---------------+ | PEN | Integer | Name | Reference | +-----+---------+--------------------------------------+---------------+ | 0 | 32 | SWIMA_ERROR | [ RFC-to-be ] | | 0 | 33 | SWIMA_SUBSCRIPTION_DENIED_ERROR | [ RFC-to-be ] | | 0 | 34 | SWIMA_RESPONSE_TOO_LARGE_ERROR | [ RFC-to-be ] | | 0 | 35 | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR | [ RFC-to-be ] | | 0 | 36 | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR | [ RFC-to-be ] | | 0 | 37-47 | Reserved for future use | [ RFC-to-be ] | +-----+---------+--------------------------------------+---------------+ IANA Question --> are Integer values 4 - 31 defined in another document, or is there a reason these values are not used? As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Fourth, a new registry is to be created called the Software Data Models registry. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? Is it to be on the Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters registry page located at: https://www.iana.org/assignments/pa-tnc-parameters/ ? The new registry is to be managed via Specification Required as defined in RFC 8126. There are initial registrations in the new registry as follows: +-----+---------+----------------------------+----------------------+ | PEN | Integer | Name | Reference | +-----+---------+----------------------------+----------------------+ | 0 | 1 | ISO 2015 SWID Tags using | [ RFC-to-be ] | | | | XML | | | 0 | 2 | ISO 2009 SWID Tags using | [ RFC-to-be ] | | | | XML | | | 0 | 192-255 | Reserved for local | N/A | | | | enterprise use | | +-----+---------+----------------------------+----------------------+ IANA Question --> Is PEN 0, Integer Value 0 reserved or unassigned? IANA Question --> Are PEN 0, Integer Values 3-191 unassigned? The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-02-19
|
02 | Eric Rescorla | [Ballot comment] More detail in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D3336 IMPORTANT I consider the following comment important, though I have chosen to make it a comment rather … [Ballot comment] More detail in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D3336 IMPORTANT I consider the following comment important, though I have chosen to make it a comment rather than a discuss. Software records on an endpoint are generally not considered to be sensitive, although there can be exceptions to this generalization as noted in the section on Privacy Considerations. In general, an I'm not sure where "generally" comes from. I consider it sensitive and we know that people have been jailed for running certain software. Even the rest of this section provides strong evidence that this is sensitive. So I think you should remove this claim and rewrite this paragraph to acknowledge that this is sensitive information MINOR The primary use of exchanging software inventory information over the PA-TNC interface is to enable a challenger (e.g. NEA Server) to obtain inventory evidence about some system in a way that conforms to Nit: e.g., endpoint is providing false information, either through malice or error, but instead focuses on correctly and reliably providing the reported Software Inventory Evidence Collection to the NEA Server. This seems like a pretty significant narrowing of the use cases. Can you explain what use cases this is useful for if the machine can lie? A Record Identifier is a 4-byte integer generated by the SWIMA-PC that is uniquely associated with a specific record within the In what byte order? Signed or unsigned? If it's actually an integer this is important. that SWIMA-PV), the SWIMA-PC MUST assign that source a Source Identification Number, which is an 8-bit unsigned integer. Each item reported includes the Source Identification Number that provided that What happens if you have 256 sources? Must these be sequential? record that is no longer available, the SWIMA-PC SHOULD return a 0-length record. Is this different from what happens if you are requested to send something that never existed? If so, is this a recipe for unlimited growth. An EID is a 4-byte unsigned integer that the SWIMA-PC assigns sequentially to each observed event (whether detected in real-time or What byte order? very first recorded event in a SWIMA-PC's records within an EID Epoch MUST be assigned a value of 1 or greater. Note that EID and EID Epoch values are assigned by the SWIMA-PC without regard to whether Why "or greater" this is the only place you allow a gap. event records MUST only contain events with EIDs that all come from the current Epoch. How does the SWIMA-PC garbage collect? It seems like the answer is it can just change epochs? records. This ensures that every partial list of event records is always complete within its indicated range. Is the point here that the list must be consecutive? | | (8) | PA-TNC specification [RFC5792]. | +--------------+------------+---------------------------------------+ It's up to you, but isn't this table largely duplicative of S 5.2? | Software Identifier Length | Software Identifier (var len) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OK, I think I see what's going on here: you can have an arbitrary number of instances of this block. Maybe you should show more than one in the diagram with an indication that it's controlled by SWID Count? Or a .... or something? This comment applies to the other PDUs in this document as well. | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | I would not put lines between these timestamp fields because they are actually one giant field |
2018-02-19
|
02 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-02-19
|
02 | Kathleen Moriarty | [Ballot comment] The authors have queued up some clarifying text from section 10.4 to make it more clear that this section is requesting the addition … [Ballot comment] The authors have queued up some clarifying text from section 10.4 to make it more clear that this section is requesting the addition of a new registry. My ballot also makes that point clear int he request to IANA. |
2018-02-19
|
02 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2018-02-19
|
02 | Kathleen Moriarty | [Ballot comment] The authors have queued up some clarifying text fro section 10.4 to make it more clear that this section is requesting the addition … [Ballot comment] The authors have queued up some clarifying text fro section 10.4 to make it more clear that this section is requesting the addition of a new registry. My ballot also makes that point clear int he request to IANA. |
2018-02-19
|
02 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2018-02-19
|
02 | Kathleen Moriarty | Ballot has been issued |
2018-02-19
|
02 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2018-02-19
|
02 | Kathleen Moriarty | Created "Approve" ballot |
2018-02-19
|
02 | Kathleen Moriarty | Ballot writeup was changed |
2018-02-19
|
02 | Kathleen Moriarty | Notification list changed to Karen O'Donoghue <odonoghue@isoc.org>, sacm@ietf.org from Karen O'Donoghue <odonoghue@isoc.org> |
2018-02-18
|
02 | Dan Romascanu | Request for Telechat review by GENART Completed: Almost Ready. Reviewer: Dan Romascanu. Sent review to list. |
2018-02-15
|
02 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2018-02-15
|
02 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2018-02-15
|
02 | Jean Mahoney | Assignment of request for Telechat review by GENART to Jouni Korhonen was rejected |
2018-02-08
|
02 | Jessica Fitzgerald-McKay | New version available: draft-ietf-sacm-nea-swima-patnc-02.txt |
2018-02-08
|
02 | (System) | New version approved |
2018-02-08
|
02 | (System) | Request for posting confirmation emailed to previous authors: David Waltermire , Chris Coffin , Charles Schmidt , Jessica Fitzgerald-McKay , Daniel Haynes |
2018-02-08
|
02 | Jessica Fitzgerald-McKay | Uploaded new revision |
2018-02-07
|
01 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-02-07
|
01 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-02-21): From: The IESG To: IETF-Announce CC: sacm-chairs@ietf.org, sacm@ietf.org, odonoghue@isoc.org, Karen O'Donoghue , … The following Last Call announcement was sent out (ends 2018-02-21): From: The IESG To: IETF-Announce CC: sacm-chairs@ietf.org, sacm@ietf.org, odonoghue@isoc.org, Karen O'Donoghue , Kathleen.Moriarty.ietf@gmail.com, draft-ietf-sacm-nea-swima-patnc@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Software Inventory Message and Attributes (SWIMA) for PA-TNC) to Proposed Standard The IESG has received a request from the Security Automation and Continuous Monitoring WG (sacm) to consider the following document: - 'Software Inventory Message and Attributes (SWIMA) for PA-TNC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document extends the PA-TNC specification [RFC5792] by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA server (as described in [RFC5209]). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5209: Network Endpoint Assessment (NEA): Overview and Requirements (Informational - IETF stream) |
2018-02-07
|
01 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-02-07
|
01 | Kathleen Moriarty | Last call was requested |
2018-02-07
|
01 | Kathleen Moriarty | Ballot approval text was generated |
2018-02-07
|
01 | Kathleen Moriarty | Ballot writeup was generated |
2018-02-07
|
01 | Kathleen Moriarty | IESG state changed to Last Call Requested from Publication Requested |
2018-02-07
|
01 | Kathleen Moriarty | Last call announcement was generated |
2018-01-26
|
01 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joel Jaeggli |
2018-01-26
|
01 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joel Jaeggli |
2018-01-25
|
01 | Tianran Zhou | Assignment of request for Telechat review by OPSDIR to Tianran Zhou was rejected |
2018-01-25
|
01 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Tobias Gondrom |
2018-01-25
|
01 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Tobias Gondrom |
2018-01-25
|
01 | Jean Mahoney | Request for Telechat review by GENART is assigned to Jouni Korhonen |
2018-01-25
|
01 | Jean Mahoney | Request for Telechat review by GENART is assigned to Jouni Korhonen |
2018-01-25
|
01 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tianran Zhou |
2018-01-25
|
01 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tianran Zhou |
2018-01-24
|
01 | Kathleen Moriarty | Placed on agenda for telechat - 2018-02-22 |
2018-01-24
|
01 | Karen O'Donoghue | draft-ietf-sacm-nea-swid-patnc shepherd write-up (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper … draft-ietf-sacm-nea-swid-patnc shepherd write-up (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is being requested for publication as an Internet Standard RFC. It provides normative requirements surrounding an extension to the IETF NEA specifications (RFC 5209) with the goal of using the NEA protocols to deliver endpoint software inventory information. The intended status is shown on the title page. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document defines normative requirements for an extension to IETF NEA (RFC 5209) for the collection and delivery of software inventory information from an endpoint to a NEA server. Working Group Summary: The document has working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item. Document Quality: This document has been reviewed and revised many times. It is well written and clear. There were no specific external expert reviews conducted. Personnel: Karen O'Donoghue is acting as the Document Shepherd. Kathleen is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has followed the working group process and reviewed the final document and feels this document is ready for IESG review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document shepherd does not have any concerns about the reviews that were performed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This document does not require any special reviews beyond those planned during the IESG review process. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd is comfortable with this document as a set of requirements to drive the SACM working group efforts in the future. The documents represent the consensus of the working group. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The authors have confirmed that they have dealt with all appropriate IPR disclosures. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed that reference this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Parts of the workgroup are interested in different subsections of the SACM architecture. Within the portion of SACM that is focusing on collecting data from endpoints, there is strong consensus behind this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. There have been no threats of anyone appealing the documents. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ###There are ID nits that need to be fixed, but we'll make sure they are done once Kathleen has done her review. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no formal review criteria for this document. (13) Have all references within this document been identified as either normative or informative? All references are tagged as normative or informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are to published documents. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No references are made to documents at a lower maturity level. There are normative references to ISO/IEC 19770-2-2009 and ISO/IEC 19770-2-2015, both of which are behind a paywall. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document will not change the status of any existing RFC. This document extends NEA along standard extension points built into that specification and requires no changes to any NEA specification. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). (###Need to finish in parallel with Kathleen's review) (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. A new entry is added to the existing “PA Subtype” registry defined in RFC 5792. This addition requires expert review as defined in section 7.1 in that specification. 10 new entries are added to the existing “PA-TNC Attribute Types” registry defined in RFC 5792. This addition requires expert review as defined in section 7.1 in that specification. 6 new entries are added to the existing “PA-TNC Error Codes” registry defined in RFC 5792. This addition requires expert review as defined in section 7.1 in that specification. The specification defines a new registry named “Software Data Model Types”. Addition of further entries to this registry will require expert review. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no formal language sections in this document. |
2018-01-24
|
01 | Karen O'Donoghue | Responsible AD changed to Kathleen Moriarty |
2018-01-24
|
01 | Karen O'Donoghue | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-01-24
|
01 | Karen O'Donoghue | IESG state changed to Publication Requested |
2018-01-24
|
01 | Karen O'Donoghue | IESG process started in state Publication Requested |
2018-01-24
|
01 | Karen O'Donoghue | Changed consensus to Yes from Unknown |
2018-01-24
|
01 | Karen O'Donoghue | Intended Status changed to Proposed Standard from None |
2018-01-24
|
01 | Karen O'Donoghue | Changed document writeup |
2018-01-24
|
01 | Karen O'Donoghue | Notification list changed to Karen O'Donoghue <odonoghue@isoc.org> |
2018-01-24
|
01 | Karen O'Donoghue | Document shepherd changed to Karen O'Donoghue |
2017-09-22
|
01 | Charles Schmidt | New version available: draft-ietf-sacm-nea-swima-patnc-01.txt |
2017-09-22
|
01 | (System) | New version approved |
2017-09-22
|
01 | (System) | Request for posting confirmation emailed to previous authors: David Waltermire , Chris Coffin , Charles Schmidt , Jessica Fitzgerald-McKay , Daniel Haynes |
2017-09-22
|
01 | Charles Schmidt | Uploaded new revision |
2017-06-28
|
00 | Adam Montville | This document now replaces draft-ietf-sacm-nea-swid-patnc instead of None |
2017-06-28
|
00 | Charles Schmidt | New version available: draft-ietf-sacm-nea-swima-patnc-00.txt |
2017-06-28
|
00 | (System) | WG -00 approved |
2017-06-28
|
00 | Charles Schmidt | Set submitter to "Charles Schmidt ", replaces to (none) and sent approval email to group chairs: sacm-chairs@ietf.org |
2017-06-28
|
00 | Charles Schmidt | Uploaded new revision |