draft-ietf-sacm-epcp-00.txt   draft-ietf-sacm-epcp-01.txt 
SACM D. Haynes SACM D. Haynes
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Best Current Practice J. Fitzgerald-McKay Intended status: Standards Track J. Fitzgerald-McKay
Expires: May 7, 2020 Department of Defense Expires: August 28, 2020 Department of Defense
November 4, 2019 February 25, 2020
Endpoint Posture Collection Profile Endpoint Posture Collection Profile
draft-ietf-sacm-epcp-00 draft-ietf-sacm-epcp-01
Abstract Abstract
This document specifies the Endpoint Posture Collection Profile, This document specifies the Endpoint Posture Collection Profile,
which describes the best practices for the application of IETF, TNC, which describes the requirements for the application of IETF, TNC,
and ISO/IEC data models, protocols, and interfaces to support the on- and ISO/IEC data models, protocols, and interfaces to support the on-
going collection and communication of endpoint posture to a going collection and communication of endpoint posture to a
centralized server where it can be stored and made available to other centralized server where it can be stored and made available to other
tools. tools.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020. This Internet-Draft will expire on August 28, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 46 skipping to change at page 3, line 46
B.1.1. Hardware Asset Management . . . . . . . . . . . . . . 31 B.1.1. Hardware Asset Management . . . . . . . . . . . . . . 31
B.1.2. Software Asset Management . . . . . . . . . . . . . . 32 B.1.2. Software Asset Management . . . . . . . . . . . . . . 32
B.1.3. Vulnerability Management . . . . . . . . . . . . . . 32 B.1.3. Vulnerability Management . . . . . . . . . . . . . . 32
B.1.4. Threat Detection and Analysis . . . . . . . . . . . . 32 B.1.4. Threat Detection and Analysis . . . . . . . . . . . . 32
B.2. Non-Supported Use Cases . . . . . . . . . . . . . . . . . 33 B.2. Non-Supported Use Cases . . . . . . . . . . . . . . . . . 33
Appendix C. Endpoint Posture Collection Profile Examples . . . . 33 Appendix C. Endpoint Posture Collection Profile Examples . . . . 33
C.1. Continuous Posture Assessment of an Endpoint . . . . . . 33 C.1. Continuous Posture Assessment of an Endpoint . . . . . . 33
C.1.1. Change on Endpoint Triggers Posture Assessment . . . 34 C.1.1. Change on Endpoint Triggers Posture Assessment . . . 34
C.2. Administrator Searches for Vulnerable Endpoints . . . . . 37 C.2. Administrator Searches for Vulnerable Endpoints . . . . . 37
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 38 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 38
D.1. -05 to -00 . . . . . . . . . . . . . . . . . . . . . . . 38 D.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 38
D.2. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 39 D.2. -05 to -00 . . . . . . . . . . . . . . . . . . . . . . . 38
D.3. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 39 D.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 39
D.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 39 D.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 39
D.5. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 40 D.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 40
D.6. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 40 D.6. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 40
D.7. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 40 D.7. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41
D.8. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 41 D.8. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 41
D.9. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41 D.9. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 41
D.10. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The Endpoint Posture Collection Profile (EPCP) describes the best The Endpoint Posture Collection Profile (EPCP) describes the
practices for the collection and communication of posture information requirements for the collection and communication of posture
from network-connected endpoints to a centralized server leveraging information from network-connected endpoints to a centralized server
prior work from the IETF NEA WG, the IETF NETCONF WG, IETF NETMOD WG, leveraging prior work from the IETF NEA WG, the IETF NETCONF WG, IETF
the Trusted Computing Group (TCG) Trusted Network Communications NETMOD WG, the Trusted Computing Group (TCG) Trusted Network
[TNC] Work Group, and the International Organization for Communications [TNC] Work Group, and the International Organization
Standardization/International Electrotechnical Commission Joint for Standardization/International Electrotechnical Commission Joint
Technical Committee (JTC) 1, Subcommittee (SC) 7, WG 21 (ISO/IEC JTC Technical Committee (JTC) 1, Subcommittee (SC) 7, WG 21 (ISO/IEC JTC
1, SC7, WG21). 1, SC7, WG21).
This document focuses on reducing the security exposure of a network This document focuses on reducing the security exposure of a network
by enabling: by enabling:
event-driven posture collection; o event-driven posture collection;
standardized querying of additional posture information as needed; o standardized querying of additional posture information as needed;
and the communication of that data to a centralized server where o and the communication of that data to a centralized server where
it can be made available to other components. it can be made available to other components.
Thus, eliminating the need for multiple collection tools on an Thus, eliminating the need for multiple collection tools on an
endpoint collecting the same data for different purposes. Future endpoint collecting the same data for different purposes. Future
revisions of this document may include support for the collection of revisions of this document may include support for the collection of
posture information from other endpoint types as well as a posture information from other endpoint types as well as a
standardized interface for storing and querying data in repositories standardized interface for storing and querying data in repositories
among other capabilities. Additional information about this future among other capabilities. Additional information about this future
work can be found in Section 5 of this document. work can be found in Section 5 of this document.
To support the collection of posture information from new endpoint To support the collection of posture information from new endpoint
types, this document is organized such that it first provides a high- types, this document is organized such that it first provides a high-
level overview of EPCP as well as the abstract components and level overview of EPCP as well as the abstract components and
transactions that will be realized by implementations (Section 2). transactions that will be realized by implementations (Section 2).
This is followed by individual sections that discuss the best This is followed by individual sections that discuss the requirements
practices for specific implementations of the EPCP for a given for specific implementations of the EPCP for a given endpoint type
endpoint type (e.g., traditional workstations and servers, network (e.g., traditional workstations and servers, network devices, mobile
devices, mobile devices, etc.) along with any extensions for devices, etc.) along with any extensions for supported use cases
supported use cases (software asset management, vulnerability (software asset management, vulnerability management, etc.). Over
management, etc.). Over time, the best practices may be expanded to time, the requirements may be expanded to address issues that arise,
address issues that arise, support new capabilities, or support new support new capabilities, or support new implementations beyond IETF
implementations beyond IETF NEA and IETF NETCONF. NEA and IETF NETCONF.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119][RFC8174] when, and only when, they appear in all BCP14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification does not distinguish blocks of informative This specification does not distinguish blocks of informative
skipping to change at page 5, line 28 skipping to change at page 5, line 28
1.2. Terminology 1.2. Terminology
This document uses terms as defined in [I-D.ietf-sacm-terminology] This document uses terms as defined in [I-D.ietf-sacm-terminology]
unless otherwise specified. unless otherwise specified.
2. Endpoint Posture Collection Profile 2. Endpoint Posture Collection Profile
The EPCP describes how IETF, TCG, and ISO/IEC data models, protocols, The EPCP describes how IETF, TCG, and ISO/IEC data models, protocols,
and interfaces can be used to support the posture assessment of and interfaces can be used to support the posture assessment of
endpoints on a network. This profile does not generate new data endpoints on a network. This profile does not generate new data
models, protocols, or interfaces; rather, it offers best practices models, protocols, or interfaces; rather, it offers requirements for
for a full end-to-end solution for posture assessment, as well as a a full end-to-end solution for posture assessment, as well as a fresh
fresh perspective on how existing standards can be leveraged against perspective on how existing standards can be leveraged against
vulnerabilities. Rationale for the EPCP solution as well as the vulnerabilities. Rationale for the EPCP solution as well as the
supported and non-supported use cases is available in Appendix A and supported and non-supported use cases is available in Appendix A and
Appendix B respectively. Appendix B respectively.
The EPCP defines the following best practices for posture assessments The EPCP makes it possible to perform posture assessments against all
against network-connected endpoints. network-connected endpoints by:
1. uniquely identifying the endpoint; 1. uniquely identifying the endpoint;
2. collecting and evaluating posture based on data from the endpoint 2. collecting and evaluating posture based on data from the endpoint
(asset management, software asset management, vulnerability (asset management, software asset management, vulnerability
management, and configuration management); management, and configuration management);
3. creating a secure, authenticated, confidential channel between 3. creating a secure, authenticated, confidential channel between
the endpoint and the posture manager; the endpoint and the posture manager;
skipping to change at page 6, line 26 skipping to change at page 6, line 26
capabilities, the EPCP defines several components. Some of these capabilities, the EPCP defines several components. Some of these
components reside on the target endpoint. Others reside on the components reside on the target endpoint. Others reside on the
posture manager that manages communications with the target endpoint posture manager that manages communications with the target endpoint
and stores the target endpoint's posture information in a repository. and stores the target endpoint's posture information in a repository.
The primary focus of this document is on the communication between The primary focus of this document is on the communication between
the posture manager and endpoints through the posture collection the posture manager and endpoints through the posture collection
manager and posture collection engine components. While the manager and posture collection engine components. While the
orchestrator, evaluator, repository, and API will be discussed in the orchestrator, evaluator, repository, and API will be discussed in the
context of the EPCP, these components are for illustrative purposes context of the EPCP, these components are for illustrative purposes
only and are not strictly defined nor are best practices provided for only and are not strictly defined nor are requirements provided for
them. As a result, vendors are free to implement these components them. As a result, vendors are free to implement these components
and interfaces in a way that makes the most sense for their products. and interfaces in a way that makes the most sense for their products.
Orchestrator Orchestrator
+--------+ +--------+
| | | |
| | | |
| |<---+ | |<---+
| | | | | |
| | | ************Posture Collection Profile************* | | | ************Posture Collection Profile*************
skipping to change at page 24, line 20 skipping to change at page 24, line 20
analysis and denial of service. Countermeasures for traffic analysis analysis and denial of service. Countermeasures for traffic analysis
(e.g., masking) are usually impractical but may be employed. (e.g., masking) are usually impractical but may be employed.
Countermeasures for denial of service (e.g., detecting and blocking Countermeasures for denial of service (e.g., detecting and blocking
particular sources) SHOULD be used when appropriate to detect and particular sources) SHOULD be used when appropriate to detect and
block denial of service attacks. These are routine practices in block denial of service attacks. These are routine practices in
network security. network security.
8.2.3. Countermeasures for Posture Manager Attacks 8.2.3. Countermeasures for Posture Manager Attacks
Because of the serious consequences of posture manager compromise, Because of the serious consequences of posture manager compromise,
posture managers SHOULD be especially well hardened against attack posture managers SHOULD be especially well-hardened against attack
and minimized to reduce their attack surface. They SHOULD be and minimized to reduce their attack surface. They SHOULD be
monitored using the NEA protocols to ensure the integrity of the monitored using the NEA protocols to ensure the integrity of the
behavior and analysis data stored on the posture manager and SHOULD behavior and analysis data stored on the posture manager and SHOULD
utilize an [IEEE-802-1ar]-compliant hardware cryptographic module for utilize an [IEEE-802-1ar]-compliant hardware cryptographic module for
identity and/or integrity measurements of the posture manager. They identity and/or integrity measurements of the posture manager. They
should be well managed to minimize vulnerabilities in the underlying should be well-managed to minimize vulnerabilities in the underlying
platform and in systems upon which the posture manager depends. platform and in systems upon which the posture manager depends.
Network security measures such as firewalls or intrusion detection Network security measures such as firewalls or intrusion detection
systems may be used to monitor and limit traffic to and from the systems may be used to monitor and limit traffic to and from the
posture manager. Personnel with administrative access to the posture posture manager. Personnel with administrative access to the posture
manager should be carefully screened and monitored to detect problems manager should be carefully screened and monitored to detect problems
as soon as possible. Posture manager administrators should not use as soon as possible. Posture manager administrators should not use
password-based authentication but should instead use non-reusable password-based authentication but should instead use non-reusable
credentials and multi-factor authentication (where available). credentials and multi-factor authentication (where available).
Physical security measures should be employed to prevent physical Physical security measures should be employed to prevent physical
attacks on posture managers. attacks on posture managers.
skipping to change at page 29, line 22 skipping to change at page 29, line 22
intrusions. Application whitelisting, patching applications and intrusions. Application whitelisting, patching applications and
operating systems, and using the latest versions of applications top operating systems, and using the latest versions of applications top
the Defense Signals Directorate's "Top 4 Mitigations to Protect Your the Defense Signals Directorate's "Top 4 Mitigations to Protect Your
ICT System". [DSD] "Inventory of Authorized and Unauthorized ICT System". [DSD] "Inventory of Authorized and Unauthorized
Endpoints", "Inventory of Authorized and Unauthorized Software", and Endpoints", "Inventory of Authorized and Unauthorized Software", and
"Continuous Vulnerability Assessment and Remediation" are Controls 1, "Continuous Vulnerability Assessment and Remediation" are Controls 1,
2, and 3, respectively, of the CIS Controls [CIS]. While there are 2, and 3, respectively, of the CIS Controls [CIS]. While there are
commercially available solutions that attempt to address these commercially available solutions that attempt to address these
security controls, these solutions do not: security controls, these solutions do not:
run on all types of endpoints; o run on all types of endpoints;
consistently interoperate with other tools that could make use of o consistently interoperate with other tools that could make use of
the data collected; the data collected;
collect posture information from all types of endpoints in a o collect posture information from all types of endpoints in a
consistent, standardized schema; consistent, standardized schema;
require vetted, standardized protocols that have been evaluated by o require vetted, standardized protocols that have been evaluated by
the international community for cryptographic soundness. the international community for cryptographic soundness.
As is true of most solutions offered today, the solution found in the As is true of most solutions offered today, the solution found in the
EPCP does not attempt to solve the lying endpoint problem, or detect EPCP does not attempt to solve the lying endpoint problem, or detect
infected endpoints; rather, it focuses on ensuring that healthy infected endpoints; rather, it focuses on ensuring that healthy
endpoints remain healthy by keeping software up-to-date and patched. endpoints remain healthy by keeping software up-to-date and patched.
A.2. All Network-Connected Endpoints are Endpoints A.2. All Network-Connected Endpoints are Endpoints
As defined by [I-D.ietf-sacm-terminology], an endpoint is any As defined by [I-D.ietf-sacm-terminology], an endpoint is any
skipping to change at page 30, line 21 skipping to change at page 30, line 21
[I-D.ietf-sacm-terminology], SACM defines this set of endpoints on [I-D.ietf-sacm-terminology], SACM defines this set of endpoints on
the network as the SACM domain. Unique endpoint identification also the network as the SACM domain. Unique endpoint identification also
enables the comparison of current and past endpoint posture enables the comparison of current and past endpoint posture
assessments, by allowing administrators to correlate assessments from assessments, by allowing administrators to correlate assessments from
the same endpoint. This makes it easier to flag suspicious changes the same endpoint. This makes it easier to flag suspicious changes
in endpoint posture for manual or automatic review, and helps to in endpoint posture for manual or automatic review, and helps to
swiftly identify malicious changes to endpoint applications. swiftly identify malicious changes to endpoint applications.
A.4. Standardized Data Models A.4. Standardized Data Models
Meeting EPCP best practices requires the use of standardized data EPCP requirements prescribe the use of standardized data models for
models for the exchange of posture information. This helps to ensure the exchange of posture information. This helps to ensure that the
that the posture information sent from endpoints to the repository posture information sent from endpoints to the repository can be
can be easily stored, due to their known format, and shared with easily stored, due to their known format, and shared with authorized
authorized endpoints and users. endpoints and users.
Posture information must be sent over standardized protocols to Posture information must be sent over standardized protocols to
ensure the confidentiality and authenticity of this data while in ensure the confidentiality and authenticity of this data while in
transit. Implementations of the EPCP include [RFC6876] and [RFC6241] transit. Implementations of the EPCP include [RFC6876] and [RFC6241]
for communication between the target endpoint and the posture for communication between the target endpoint and the posture
manager. These protocols allow networks that implement this solution manager. These protocols allow networks that implement this solution
to collect large amounts of posture information from an endpoint to to collect large amounts of posture information from an endpoint to
make decisions about that endpoint's compliance with some policy. make decisions about that endpoint's compliance with some policy.
The EPCP offers a solution for all endpoints already connected to the The EPCP offers a solution for all endpoints already connected to the
network. Periodic assessments and automated reporting of changes to network. Periodic assessments and automated reporting of changes to
skipping to change at page 37, line 7 skipping to change at page 37, line 7
Figure 6: Storing SWIDs in the Repository Figure 6: Storing SWIDs in the Repository
If the endpoint has fallen out of compliance with a policy, the If the endpoint has fallen out of compliance with a policy, the
posture manager can alert the administrator via the posture manager's posture manager can alert the administrator via the posture manager's
API. The administrator can then take steps to address the problem. API. The administrator can then take steps to address the problem.
If the administrator has already established a policy for If the administrator has already established a policy for
automatically addressing this problem, that policy will be followed. automatically addressing this problem, that policy will be followed.
(") (")
__|__ __|__
+-->| +--> |
Endpoint Posture Manager | / \ Endpoint Posture Manager | / \
+---------------+ +---------------+ | +---------------+ +---------------+ |
| | | | | | | | | |
| +-----------+ | | +-----------+ | | | +-----------+ | | +-----------+ | |
| | SWID | | | | SWID |-|-+ | | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | | | | Posture | | | | Posture | |
| | Collector | | | | Validator | | | | Collector | | | | Validator | |
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | | | | | Repository | | | | | | Repository
| | IF-IMC | | | IF-IMV | +--------+ | | IF-IMC | | | IF-IMV | +--------+
skipping to change at page 38, line 40 skipping to change at page 38, line 40
Figure 8: Admin Searches for Vulnerable Endpoints Figure 8: Admin Searches for Vulnerable Endpoints
The repository returns a list of entries matching the administrator's The repository returns a list of entries matching the administrator's
search. The administrator can then address the vulnerable endpoints search. The administrator can then address the vulnerable endpoints
by taking some follow-up action such as removing it from the network, by taking some follow-up action such as removing it from the network,
quarantining it, or updating the vulnerable software. quarantining it, or updating the vulnerable software.
Appendix D. Change Log Appendix D. Change Log
D.1. -05 to -00 D.1. -00 to -01
Changed the status of the draft from "Best Current Practices" to
"Standards Track".
D.2. -05 to -00
Changed the title of the draft to draft-ietf-sacm-epcp. Changed the title of the draft to draft-ietf-sacm-epcp.
Updated the diagram so the Endpoint and Posture Manager are the Updated the diagram so the Endpoint and Posture Manager are the
primary focus of EPCP. primary focus of EPCP.
Added a reference to CoSWID in the Software Asset Management Added a reference to CoSWID in the Software Asset Management
extension of the IETF NEA EPCP implementation. extension of the IETF NEA EPCP implementation.
Further clarified the use of MAC addresses in EPCP. Further clarified the use of MAC addresses in EPCP.
skipping to change at page 39, line 17 skipping to change at page 39, line 22
of certain data given privacy regulations. of certain data given privacy regulations.
Added a requirement around an endpoint being provisioned with a Added a requirement around an endpoint being provisioned with a
machine certificate. machine certificate.
Clarified that other protocols and interfaces may be supported beyond Clarified that other protocols and interfaces may be supported beyond
IETF NEA and NETCONF. IETF NEA and NETCONF.
Made various typographical and editorial changes. Made various typographical and editorial changes.
D.2. -04 to -05 D.3. -04 to -05
Updated the diagram so the Evaluator and Repository are "current Updated the diagram so the Evaluator and Repository are "current
work". work".
Clarified how the Posture Collection Engine can push data, respond to Clarified how the Posture Collection Engine can push data, respond to
queries, and establish secure transport connectivity for fulfilling queries, and establish secure transport connectivity for fulfilling
subscriptions. subscriptions.
Expanded on the future work around leveraging NETCONF, RESTCONF, and Expanded on the future work around leveraging NETCONF, RESTCONF, and
YANG Push for network devices. YANG Push for network devices.
Documented the need to reassess MAC addresses as a device identifier. Documented the need to reassess MAC addresses as a device identifier.
Made various typographical and editorial changes. Made various typographical and editorial changes.
D.3. -03 to -04 D.4. -03 to -04
Addressed various comments from the SACM WG. Addressed various comments from the SACM WG.
Refactored the document to better focus it on the communications Refactored the document to better focus it on the communications
between endpoints and the posture manager and the best practices for between endpoints and the posture manager and the best practices for
EPCP implementations. EPCP implementations.
Made other editorial changes and improved consistency throughout the Made other editorial changes and improved consistency throughout the
document. document.
D.4. -02 to -03 D.5. -02 to -03
Addressed various comments from the SACM WG. Addressed various comments from the SACM WG.
Added a reference to TCG ECP 1.0. Added a reference to TCG ECP 1.0.
Removed text in the "SWID Posture Validator" section that states it Removed text in the "SWID Posture Validator" section that states it
performs evaluation. This was removed because it contradicts the performs evaluation. This was removed because it contradicts the
posture manager not performing any evaluations. posture manager not performing any evaluations.
Expanded the "Provisioning" section of the "EPCP Transactions" Expanded the "Provisioning" section of the "EPCP Transactions"
skipping to change at page 40, line 26 skipping to change at page 40, line 36
Management". Management".
Changed I-D category to BCP. Changed I-D category to BCP.
Changed references to the NETMOD architecture to the NETCONF Changed references to the NETMOD architecture to the NETCONF
architecture because NETCONF represents the management protocol architecture because NETCONF represents the management protocol
whereas NETMOD is focused on the definition of data models. whereas NETMOD is focused on the definition of data models.
Addressed various editorial suggestions. Addressed various editorial suggestions.
D.5. -01 to -02 D.6. -01 to -02
Addressed various comments from the SACM WG. Addressed various comments from the SACM WG.
Added a section for the collection of posture information from Added a section for the collection of posture information from
network devices using standards from the NETMOD WG. network devices using standards from the NETMOD WG.
Updated EPCP component diagrams so they were not specific to a NEA- Updated EPCP component diagrams so they were not specific to a NEA-
based implementation. based implementation.
Updated EPCP NEA example diagrams to reflect all the components in Updated EPCP NEA example diagrams to reflect all the components in
the NEA architecture. the NEA architecture.
D.6. -00 to -01 D.7. -00 to -01
There are no textual changes associated with this revision. This There are no textual changes associated with this revision. This
revision simply reflects a resubmission of the document so that it revision simply reflects a resubmission of the document so that it
remains in active status. remains in active status.
D.7. -01 to -02 D.8. -01 to -02
Added references to the Software Inventory Message and Attributes Added references to the Software Inventory Message and Attributes
(SWIMA) for PA-TNC I-D. (SWIMA) for PA-TNC I-D.
Replaced references to PC-TNC with IF-IMC. Replaced references to PC-TNC with IF-IMC.
Removed erroneous hyphens from a couple of section titles. Removed erroneous hyphens from a couple of section titles.
Made a few minor editorial changes. Made a few minor editorial changes.
D.8. -02 to -00 D.9. -02 to -00
Draft adopted by IETF SACM WG. Draft adopted by IETF SACM WG.
D.9. -00 to -01 D.10. -00 to -01
Significant edits to up-level the draft to describe SACM collection Significant edits to up-level the draft to describe SACM collection
over multiple different protocols. over multiple different protocols.
Replaced references to SANS with CIS. Replaced references to SANS with CIS.
Made other minor editorial changes. Made other minor editorial changes.
Authors' Addresses Authors' Addresses
 End of changes. 31 change blocks. 
61 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/