< draft-ietf-sacm-ecp-04.txt   draft-ietf-sacm-ecp-05.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: Best Current Practice J. Fitzgerald-McKay
Expires: August 19, 2019 Department of Defense Expires: December 23, 2019 Department of Defense
L. Lorenzin L. Lorenzin
Pulse Secure Pulse Secure
February 15, 2019 June 21, 2019
Endpoint Posture Collection Profile Endpoint Posture Collection Profile
draft-ietf-sacm-ecp-04 draft-ietf-sacm-ecp-05
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 best practices 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. This document is an extension of the Trusted Computing tools. This document is an extension of the Trusted Computing
Group's Endpoint Compliance Profile Version 1.0 specification [ECP]. Group's Endpoint Compliance Profile Version 1.0 specification [ECP].
skipping to change at page 1, line 39 skipping to change at page 1, line 38
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 August 19, 2019. This Internet-Draft will expire on December 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Endpoint Posture Collection Profile . . . . . . . . . . . . . 5 3. Endpoint Posture Collection Profile . . . . . . . . . . . . . 5
3.1. Components . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Components . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1.1. Posture Collection Engine . . . . . . . . . . . . 7 3.1.1.1. Posture Collection Engine . . . . . . . . . . . . 7
3.1.2. Posture Manager . . . . . . . . . . . . . . . . . . . 7 3.1.2. Posture Manager . . . . . . . . . . . . . . . . . . . 8
3.1.2.1. Posture Collection Manager . . . . . . . . . . . 7 3.1.2.1. Posture Collection Manager . . . . . . . . . . . 8
3.1.3. Repository . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Repository . . . . . . . . . . . . . . . . . . . . . 8
3.1.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . 8 3.1.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . 9
3.1.5. Orchestrator . . . . . . . . . . . . . . . . . . . . 8 3.1.5. Orchestrator . . . . . . . . . . . . . . . . . . . . 9
3.1.6. Administrative Interface and API . . . . . . . . . . 8 3.1.6. Administrative Interface and API . . . . . . . . . . 9
3.2. Transactions . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Transactions . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Discovery and Validation . . . . . . . . . . . . . . 9 3.2.2. Discovery and Validation . . . . . . . . . . . . . . 10
3.2.3. Event Driven Collection . . . . . . . . . . . . . . . 9 3.2.3. Event Driven Collection . . . . . . . . . . . . . . . 10
3.2.4. Querying . . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. Querying the Endpoint . . . . . . . . . . . . . . . . 10
3.2.5. Data Storage . . . . . . . . . . . . . . . . . . . . 10 3.2.5. Data Storage . . . . . . . . . . . . . . . . . . . . 10
3.2.6. Data Sharing . . . . . . . . . . . . . . . . . . . . 10 3.2.6. Data Sharing . . . . . . . . . . . . . . . . . . . . 11
4. IETF NEA EPCP Implementation for Traditional Endpoints . . . 10 4. IETF NEA EPCP Implementation for Traditional Endpoints . . . 11
4.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 12 4.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 13
4.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Posture Collector . . . . . . . . . . . . . . . . . . 13 4.2.1. Posture Collector . . . . . . . . . . . . . . . . . . 14
4.2.2. Posture Broker Client . . . . . . . . . . . . . . . . 13 4.2.2. Posture Broker Client . . . . . . . . . . . . . . . . 14
4.2.3. Posture Transport Client . . . . . . . . . . . . . . 13 4.2.3. Posture Transport Client . . . . . . . . . . . . . . 14
4.3. Posture Manager . . . . . . . . . . . . . . . . . . . . . 13 4.3. Posture Manager . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Posture Validator . . . . . . . . . . . . . . . . . . 13 4.3.1. Posture Validator . . . . . . . . . . . . . . . . . . 14
4.3.2. Posture Broker Server . . . . . . . . . . . . . . . . 13 4.3.2. Posture Broker Server . . . . . . . . . . . . . . . . 14
4.3.3. Posture Transport Server . . . . . . . . . . . . . . 13 4.3.3. Posture Transport Server . . . . . . . . . . . . . . 14
4.4. Repository . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Repository . . . . . . . . . . . . . . . . . . . . . . . 15
4.5. IETF SACM SWAM Extension to the IETF NEA EPCP 4.5. IETF SACM SWAM Extension to the IETF NEA EPCP
Implementation . . . . . . . . . . . . . . . . . . . . . 14 Implementation . . . . . . . . . . . . . . . . . . . . . 15
4.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 14 4.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 15
4.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . . . 14 4.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . . . 15
4.5.3. SWID Posture Collectors and Posture Validators . . . 14 4.5.3. SWID Posture Collectors and Posture Validators . . . 15
4.5.3.1. The SWID Posture Collector . . . . . . . . . . . 15 4.5.3.1. The SWID Posture Collector . . . . . . . . . . . 16
4.5.3.2. The SWID Posture Validator . . . . . . . . . . . 15 4.5.3.2. The SWID Posture Validator . . . . . . . . . . . 16
4.5.4. Repository . . . . . . . . . . . . . . . . . . . . . 16 4.5.4. Repository . . . . . . . . . . . . . . . . . . . . . 17
5. IETF NETCONF EPCP Implementation for Network Device Endpoints 16 5. IETF NETCONF EPCP Implementation for Network Device Endpoints 17
5.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 17 5.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 18
5.2. Posture Manager Provisioning . . . . . . . . . . . . . . 17 5.2. Posture Manager Provisioning . . . . . . . . . . . . . . 18
5.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.1. Datastore . . . . . . . . . . . . . . . . . . . . . . 17 5.3.1. Datastore . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Posture Manager . . . . . . . . . . . . . . . . . . . . . 18 5.4. Posture Manager . . . . . . . . . . . . . . . . . . . . . 19
5.5. Repository . . . . . . . . . . . . . . . . . . . . . . . 18 5.5. Repository . . . . . . . . . . . . . . . . . . . . . . . 19
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 22
9.1.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 21 9.1.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 23
9.1.2. Network Attacks . . . . . . . . . . . . . . . . . . . 22 9.1.2. Network Attacks . . . . . . . . . . . . . . . . . . . 23
9.1.3. Posture Manager Attacks . . . . . . . . . . . . . . . 22 9.1.3. Posture Manager Attacks . . . . . . . . . . . . . . . 23
9.1.4. Repository Attacks . . . . . . . . . . . . . . . . . 22 9.1.4. Repository Attacks . . . . . . . . . . . . . . . . . 24
9.2. Countermeasures . . . . . . . . . . . . . . . . . . . . . 23 9.2. Countermeasures . . . . . . . . . . . . . . . . . . . . . 25
9.2.1. Countermeasures for Endpoint Attacks . . . . . . . . 23 9.2.1. Countermeasures for Endpoint Attacks . . . . . . . . 25
9.2.2. Countermeasures for Network Attacks . . . . . . . . . 23 9.2.2. Countermeasures for Network Attacks . . . . . . . . . 25
9.2.3. Countermeasures for Posture Manager Attacks . . . . . 24 9.2.3. Countermeasures for Posture Manager Attacks . . . . . 26
9.2.4. Countermeasures for Repository Attacks . . . . . . . 25 9.2.4. Countermeasures for Repository Attacks . . . . . . . 26
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Informative References . . . . . . . . . . . . . . . . . 26 11.1. Informative References . . . . . . . . . . . . . . . . . 27
11.2. Normative References . . . . . . . . . . . . . . . . . . 26 11.2. Normative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Rationale for an EPCP Solution . . . . . . . . . . . 28 Appendix A. Rationale for an EPCP Solution . . . . . . . . . . . 30
A.1. Preventative Posture Assessments . . . . . . . . . . . . 28 A.1. Preventative Posture Assessments . . . . . . . . . . . . 30
A.2. All Network-Connected Endpoints are Endpoints . . . . . . 29 A.2. All Network-Connected Endpoints are Endpoints . . . . . . 31
A.3. All Endpoints on the Network Must be Uniquely Identified 29 A.3. All Endpoints on the Network Must be Uniquely Identified 31
A.4. Standardized Data Models . . . . . . . . . . . . . . . . 29 A.4. Standardized Data Models . . . . . . . . . . . . . . . . 31
A.5. Posture Information Must Be Stored . . . . . . . . . . . 30 A.5. Posture Information Must Be Stored . . . . . . . . . . . 32
A.6. Posture Information Can Be Shared . . . . . . . . . . . . 30 A.6. Posture Information Can Be Shared . . . . . . . . . . . . 32
A.7. Enterprise Asset Posture Information Belongs to the A.7. Enterprise Asset Posture Information Belongs to the
Enterprise . . . . . . . . . . . . . . . . . . . . . . . 30 Enterprise . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 31 Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 33
B.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 31 B.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 33
B.1.1. Hardware Asset Management . . . . . . . . . . . . . . 31 B.1.1. Hardware Asset Management . . . . . . . . . . . . . . 33
B.1.2. Software Asset Management . . . . . . . . . . . . . . 31 B.1.2. Software Asset Management . . . . . . . . . . . . . . 33
B.1.3. Vulnerability Management . . . . . . . . . . . . . . 32 B.1.3. Vulnerability Management . . . . . . . . . . . . . . 34
B.1.4. Threat Detection and Analysis . . . . . . . . . . . . 32 B.1.4. Threat Detection and Analysis . . . . . . . . . . . . 34
B.2. Non-Supported Use Cases . . . . . . . . . . . . . . . . . 32 B.2. Non-Supported Use Cases . . . . . . . . . . . . . . . . . 34
Appendix C. Endpoint Posture Collection Profile Examples . . . . 33 Appendix C. Endpoint Posture Collection Profile Examples . . . . 35
C.1. Continuous Posture Assessment of an Endpoint . . . . . . 33 C.1. Continuous Posture Assessment of an Endpoint . . . . . . 35
C.1.1. Change on Endpoint Triggers Posture Assessment . . . 33 C.1.1. Change on Endpoint Triggers Posture Assessment . . . 35
C.2. Administrator Searches for Vulnerable Endpoints . . . . . 36 C.2. Administrator Searches for Vulnerable Endpoints . . . . . 38
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 37 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 39
D.1. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 37 D.1. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 39
D.2. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 38 D.2. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 40
D.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 38 D.3. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 40
D.4. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 39 D.4. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 41
D.5. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 39 D.5. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41
D.6. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 39 D.6. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 41
D.7. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 39 D.7. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 D.8. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The Endpoint Posture Collection Profile (EPCP) builds on prior work The Endpoint Posture Collection Profile (EPCP) builds on prior work
from the IETF NEA WG, the IETF NETCONF WG, IETF NETMOD WG, the from the IETF NEA WG, the IETF NETCONF WG, IETF NETMOD WG, the
Trusted Computing Group (TCG) Trusted Network Communications [TNC] Trusted Computing Group (TCG) Trusted Network Communications [TNC]
WG, and the International Organization for Standardization/ WG, and the International Organization for Standardization/
International Electrotechnical Commission Joint Technical Committee International Electrotechnical Commission Joint Technical Committee
(JTC) 1, Subcommittee (SC) 7, WG 21 (ISO/IEC JTC 1, SC7, WG21) to (JTC) 1, Subcommittee (SC) 7, WG 21 (ISO/IEC JTC 1, SC7, WG21) to
describe the best practices for the collection and communication of describe the best practices for the collection and communication of
skipping to change at page 5, line 43 skipping to change at page 5, line 45
to its configuration; to its configuration;
5. enabling the posture manager to request information about the 5. enabling the posture manager to request information about the
configuration of the endpoint; and configuration of the endpoint; and
6. storing the posture information in a repository linked to the 6. storing the posture information in a repository linked to the
identifier for the endpoint. identifier for the endpoint.
Furthermore, the EPCP aims to support data storage and data sharing Furthermore, the EPCP aims to support data storage and data sharing
capabilities to make the collected posture information available to capabilities to make the collected posture information available to
authorized parties and components insupport of other processes authorized parties and components in support of other processes
(analytic, access control, remediation, reporting, etc.). (analytic, access control, remediation, reporting, etc.).
3.1. Components 3.1. Components
To perform posture assessment, data storage, and data sharing, the To perform posture assessment, data storage, and data sharing, the
EPCP defines several components. Some of these components reside on EPCP defines several components. Some of these components reside on
the target endpoint. Others reside on a posture manager that manages the target endpoint. Others reside on a posture manager that manages
communications with the target endpoint and stores the target communications with the target endpoint and stores the target
endpoint's posture information in a repository. endpoint's posture information in a repository.
It should be noted that the primary focus of this document is on the It should be noted that the primary focus of this document is on the
communication between the posture manager and endpoints. While the communication between the posture manager and endpoints. While the
orchestrator, evaluator, repository, and administrative interface and orchestrator, evaluator, repository, and administrative interface and
API will be discussed in the context of the broader EPCP API will be discussed in the context of the broader EPCP
architecture, these components are not strictly defined nor are best architecture, these components are not strictly defined nor are best
practices provided for them at this time. As a result, vendors are practices provided for them at this time. As a result, vendors are
free to implement these components and interfaces in a way that makes free to implement these components and interfaces in a way that makes
the most sense for their products. the most sense for their products.
************FUTURE WORK************* *********FUTURE WORK********** Posture Manager Endpoint
* * * Orchestrator * +----------------+ +----------------+
* * * +--------+ * | | | |
* * Posture Manager Endpoint * | |<------------>| | | |
* Orchestrator * +----------------+ +----------------+ * | | publish/ * | | | |
* +--------+ * | | | | * | | subscribe * | | | |
* | |<------*->| | | | * | | * | +------------+ | | +------------+ |
* | | pub/ * | | | | * +--------+ * | | | | | | | |
* | | sub * | | | | *********FUTURE WORK********** | | Posture | | report/ | | Posture | |
* | | * | +------------+ | | +------------+ | | | Collection | | publish | | Collection | |
* +--------+ * | | | | | | | | Evaluator Repository | | Manager | |<----------| | Engine | |
* * | | Posture | | | | Posture | | +------+ +--------+ | | | | | | | |
* Evaluator Repository * | | Collection | | | | Collection | | | | | | | | | | | | | |
* +------+ +--------+ * | | Manager | |<-------| | Engine | | | | | | | +------------+ | | +------------+ |
* | | | | * | | | | report | | | | | |<-------->| |<---------->| | query/ | |
* | | | | * | +------------+ | | +------------+ | | | request/ | | store | | subscribe | |
* | |<-----> | |<------*->| | query | | | | respond | | | |---------->| |
* | |request/| | store * | |------->| | | | | | | | | |
* | |respond | | * | | | | +------+ +--------+ +----------------+ +----------------+
* | | | | * | | | | | ^ ^
* +------+ +--------+ * +----------------+ +----------------+ | query | |
* | * ^ +----------------------------------------+ |
* | query * | |
* +-----------------------------*----------+ ***************************FUTURE WORK***********|*************
* * * | *
* ****************************
* *
* +--------------------------------+ * * +--------------------------------+ *
* | Administrative Interface | * * | Administrative Interface | *
* | and API | * * | and API | *
* +--------------------------------+ * * +--------------------------------+ *
* * * *
************FUTURE WORK**************************************** ***************************FUTURE WORK*************************
Figure 1: EPCP Components Figure 1: EPCP Components
3.1.1. Endpoint 3.1.1. Endpoint
An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is
monitored by the enterprise and is the target of posture assessments. monitored by the enterprise and is the target of posture assessments.
To support these posture assessments, posture information is To support these posture assessments, posture information is
collected via a posture collection engine. collected via a posture collection engine.
3.1.1.1. Posture Collection Engine 3.1.1.1. Posture Collection Engine
The posture collection engine is located on the target endpoint and The posture collection engine is located on the target endpoint and
receives queries from a posture collection manager. It also sends can either receive queries for data from the posture collection
collected posture information to the posture manager where it can be manager (see Section 3.2.4) or can push data to the posture
sanity checked and stored in the repository. The posture collection collection manager (see Section 3.2.3). The posture collection
engine also contains a capability that sets up exchanges between the engine sends collected posture information to the posture manager
target endpoint and posture manager. This capability makes the where it can be sanity checked and stored in the repository. The
posture collection engine responsible for performing the client-side posture collection engine also contains a capability that sets up
portion of encryption handshakes, and for locating authorized posture exchanges between the target endpoint and posture manager. This
managers with which to communicate. capability makes the posture collection engine responsible for
performing the client-side portion of encryption handshakes, and for
locating authorized posture managers with which to communicate.
3.1.2. Posture Manager 3.1.2. Posture Manager
The posture manager is an endpoint that collects, validates, and The posture manager is an endpoint that collects, validates, and
enriches posture information received about a target endpoint. It enriches posture information received about a target endpoint. It
also stores the posture information it receives in the repository also stores the posture information it receives in the repository
where it can be evaluated. The posture manager does not evaluate the where it can be evaluated. The posture manager does not evaluate the
posture information. posture information.
3.1.2.1. Posture Collection Manager 3.1.2.1. Posture Collection Manager
skipping to change at page 7, line 47 skipping to change at page 8, line 34
enterprise. The posture collection manager may query and retrieve enterprise. The posture collection manager may query and retrieve
guidance from the repository to guide the collection of posture guidance from the repository to guide the collection of posture
information from the target endpoint. information from the target endpoint.
The posture collection manager also contains a capability that sets The posture collection manager also contains a capability that sets
up exchanges between the target endpoint and the posture manager, and up exchanges between the target endpoint and the posture manager, and
manages data sent to and from posture collection engine. It is also manages data sent to and from posture collection engine. It is also
responsible for performing the server-side portion of encryption responsible for performing the server-side portion of encryption
handshakes. handshakes.
If the posture manager wants to register for continuous collection of
endpoint posture changes with the endpoint, then it must do so in a
scalable way. Specifically, it will need to create subscriptions
with endpoints in a way which allows the posture data to be securely
pushed. Effectively this means that the endpoint must be able to
establish secure transport connectivity to the posture collection
manager as needed, and the collection manager must be able to
periodically collect the current state of the endpoint to verify the
expected state of that endpoint.
3.1.3. Repository 3.1.3. Repository
The repository hosts guidance, endpoint identification information, The repository hosts guidance, endpoint identification information,
and posture information reported by target endpoints where it is made and posture information reported by target endpoints where it is made
available to authorized components and persisted over a period of available to authorized components and persisted over a period of
time set by the administrator. Information stored in the repository time set by the administrator. Information stored in the repository
will be accessible to authorized parties via a standard will be accessible to authorized parties via a standard
administrative interface as well as through a standardized API. The administrative interface as well as through a standardized API. The
repository may be a standalone component or may be located on the repository may be a standalone component or may be located on the
posture manager. Furthermore, an implementation is not restricted to posture manager. Furthermore, an implementation is not restricted to
skipping to change at page 8, line 47 skipping to change at page 9, line 45
The administrative interface allows administrators to query the The administrative interface allows administrators to query the
repository and manage the endpoints and software used in the EPCP via repository and manage the endpoints and software used in the EPCP via
the posture manager. Similarly, an API is necessary to allow the posture manager. Similarly, an API is necessary to allow
infrastructure endpoints and software access to the information infrastructure endpoints and software access to the information
stored in the repository and to manage the endpoints and software stored in the repository and to manage the endpoints and software
used in the EPCP. The administrative interface and API provide used in the EPCP. The administrative interface and API provide
authorized users, infrastructure endpoints, and software with the authorized users, infrastructure endpoints, and software with the
ability to query the repository for data, send commands to the ability to query the repository for data, send commands to the
posture collection managers requesting information from the posture collection managers requesting information from the
associated posture collection engines residing on endpoints, and associated posture collection engines residing on endpoints, and
establish and update the policy that resides on the posture manager establish and update the policy that resides on the posture manager.
3.2. Transactions 3.2. Transactions
The following sections describe the transactions associated with the The following sections describe the transactions associated with the
components of the EPCP architecture and may be provided in an components of the EPCP architecture and may be provided in an
implementation. implementation.
3.2.1. Provisioning 3.2.1. Provisioning
An endpoint is provisioned with one or more attributes that will An endpoint is provisioned with one or more attributes that will
skipping to change at page 9, line 39 skipping to change at page 10, line 33
exchanged. exchanged.
3.2.3. Event Driven Collection 3.2.3. Event Driven Collection
The posture assessment is initiated when the posture collector engine The posture assessment is initiated when the posture collector engine
on the target endpoint notices that relevant posture information on on the target endpoint notices that relevant posture information on
the endpoint has changed. Then, the posture collection engine the endpoint has changed. Then, the posture collection engine
initiates a posture assessment information exchange with the posture initiates a posture assessment information exchange with the posture
collection manager. collection manager.
3.2.4. Querying 3.2.4. Querying the Endpoint
The posture assessment is initiated by the posture collection The posture assessment is initiated by the posture collection
manager. This can occur because: manager. This can occur because:
1. policy states that a previous assessment has aged out or become 1. policy states that a previous assessment has aged out or become
invalid, or invalid, or
2. the posture collection manager is alerted by a sensor or an 2. the posture collection manager is alerted by a sensor or an
administrator (via the posture manager's administrative administrator (via the posture manager's administrative
interface) that an assessment must be completed interface) that an assessment must be completed.
3.2.5. Data Storage 3.2.5. Data Storage
Once posture information is received by the posture manager, it is Once posture information is received by the posture manager, it is
forwarded to the repository. The repository could be co-located with forwarded to the repository. The repository could be co-located with
the posture manager, or there could be direct or brokered the posture manager, or there could be direct or brokered
communication between the posture manager and the repository. The communication between the posture manager and the repository. The
posture information is stored in the repository along with past posture information is stored in the repository along with past
posture information collected about the target endpoint. posture information collected about the target endpoint.
skipping to change at page 15, line 9 skipping to change at page 16, line 9
The elements in the SWID tag MUST be populated as specified in The elements in the SWID tag MUST be populated as specified in
[SWID]. These tags, and the directory in which they are stored, MUST [SWID]. These tags, and the directory in which they are stored, MUST
be updated as software is added, removed, or updated. be updated as software is added, removed, or updated.
4.5.3. SWID Posture Collectors and Posture Validators 4.5.3. SWID Posture Collectors and Posture Validators
4.5.3.1. The SWID Posture Collector 4.5.3.1. The SWID Posture Collector
For the EPCP, the SWID posture collector MUST be conformant with For the EPCP, the SWID posture collector MUST be conformant with
[RFC8412], which includes requirements for: [RFC8412], which includes requirements for:
1. Collecting SWID tags from the SWID directory 1. Collecting SWID tags from the SWID directory;
2. Monitoring the SWID directory for changes 2. Monitoring the SWID directory for changes;
3. Initiating a session with the posture manager to report changes 3. Initiating a session with the posture manager to report changes
to the directory to the directory;
4. Maintaining a list of changes to the SWID directory when updates 4. Maintaining a list of changes to the SWID directory when updates
take place and no PT-TLS connection can be created with the take place and no PT-TLS connection can be created with the
posture manager posture manager;
5. Responding to a request for SWID tags from the SWID Posture 5. Responding to a request for SWID tags from the SWID Posture
Validator on the posture manager Validator on the posture manager; and
6. Responding to a query from the SWID posture validator as to 6. Responding to a query from the SWID posture validator as to
whether all updates have been sent whether all updates have been sent.
The SWID posture collector is not responsible for detecting that the The SWID posture collector is not responsible for detecting that the
SWID directory was not updated when an application was either SWID directory was not updated when an application was either
installed or uninstalled. installed or uninstalled.
4.5.3.2. The SWID Posture Validator 4.5.3.2. The SWID Posture Validator
Conformance to [RFC8412] enables the SWID posture validator to: Conformance to [RFC8412] enables the SWID posture validator to:
1. Send messages to the SWID posture collector (at the behest of the 1. Send messages to the SWID posture collector (at the behest of the
administrator at the posture manager console) requesting updates administrator at the posture manager console) requesting updates
for SWID tags located on endpoint for SWID tags located on endpoint;
2. Ask the SWID posture collector whether all updates to the SWID 2. Ask the SWID posture collector whether all updates to the SWID
directory located at the posture manager have been sent directory located at the posture manager have been sent; and
3. Perform any validation and processing on the collected SWID 3. Perform any validation and processing on the collected SWID
posture information prior to storage posture information prior to storage.
In addition to these requirements, a SWID posture validator used in In addition to these requirements, a SWID posture validator used in
conformance with this profile MUST be capable of passing this SWID conformance with this profile MUST be capable of passing this SWID
posture information as well as the associated endpoint identity to posture information as well as the associated endpoint identity to
the repository for storage. the repository for storage.
4.5.4. Repository 4.5.4. Repository
The administrative interface SHOULD enable an administrator to: The administrative interface SHOULD enable an administrator to:
1. Query which endpoints have reported SWID tags for a particular 1. Query which endpoints have reported SWID tags for a particular
application application
2. Query which SWID tags are installed on an endpoint 2. Query which SWID tags are installed on an endpoint; and
3. Query tags based on characteristics, such as vendor, publisher, 3. Query tags based on characteristics, such as vendor, publisher,
etc. etc.
5. IETF NETCONF EPCP Implementation for Network Device Endpoints 5. IETF NETCONF EPCP Implementation for Network Device Endpoints
When EPCP is used, a NETCONF client that implements the posture When EPCP is used, a NETCONF client that implements the posture
collection manager sends a query to target network device endpoint collection manager sends a query to target network device endpoint
requesting posture information over a secure channel. Once the requesting posture information over a secure channel. Once the
NETCONF server on the endpoint receives the request, it queries one NETCONF server on the endpoint receives the request, it queries one
skipping to change at page 18, line 41 skipping to change at page 19, line 41
posture collection manager stores this information in the repository posture collection manager stores this information in the repository
linked to the identity of the target endpoint from which it was linked to the identity of the target endpoint from which it was
collected. collected.
6. Future Work 6. Future Work
This section captures ideas for future work related to EPCP that This section captures ideas for future work related to EPCP that
might be of interest to the IETF SACM WG. These ideas are listed in might be of interest to the IETF SACM WG. These ideas are listed in
no particular order. no particular order.
o Integrate the IETF NETCONF Yang Push architecture. o The [I-D.ietf-netconf-subscribed-notifications] and
[I-D.ietf-netconf-yang-push] which have been submitted to IESG for
publication could be leveraged for an HTTP-based subscription for
EPCP. Specifically, it could be used for the posture collection
manager to continuously receive posture changes as they happen
from the posture collection engine. At this point, it seems like
[I-D.ietf-netconf-restconf-notif] would be a good match to these
requirements. However further investigation into the
applicability of supporting a RESTCONF server capability on to
handle subscription requests needs to be made. Specific questions
which should be examined include:
* Number of endpoints which can be continuously tracked by a
single posture collection manager. Scalability questions to be
considered include elements from the number of transport
connects maintained to the volume of volume and churn of
posture evidence which will be continuously pushed to the
posture collection manager manager.
* Ability of the posture collection manager to establish and
maintain a continuous state of endpoint posture during
failures. This includes failures/reboots on either side of the
interface.
* Ability to support for the full set of functions described for
NETCONF within Section 5.
o Add support endpoint types beyond workstations, servers, and o Add support endpoint types beyond workstations, servers, and
network infrastructure devices. network infrastructure devices.
o Examine the integration of [I-D.ietf-mile-xmpp-grid]. o Examine the integration of [I-D.ietf-mile-xmpp-grid].
o Define a standard interface and API for interacting with the o Define a standard interface and API for interacting with the
repository. Requirements to consider include: creating a secure repository. Requirements to consider include: creating a secure
channel between a publisher and the repository, creating a secure channel between a publisher and the repository, creating a secure
channel between a subscriber and the repository, and the types of channel between a subscriber and the repository, and the types of
skipping to change at page 19, line 18 skipping to change at page 20, line 43
broker client and posture transport client(s) as well as the broker client and posture transport client(s) as well as the
posture broker server and posture transport server(s). posture broker server and posture transport server(s).
o Retention of posture information on the target endpoint. o Retention of posture information on the target endpoint.
o Define an orchestrator component as well as publish/subscribe o Define an orchestrator component as well as publish/subscribe
interface for it. interface for it.
o Define an evaluator component as well as an interface for it. o Define an evaluator component as well as an interface for it.
o Reassess the use of MAC addresses, including market research to
determine if MAC addresses continue to be a widely implemented
device identifier among network tools.
7. Acknowledgements 7. Acknowledgements
The authors wish to thank all of those in the TCG TNC work group who The authors wish to thank all of those in the TCG TNC work group who
contributed to development of the TNC ECP specification upon which contributed to development of the TNC ECP specification upon which
this document is based. this document is based.
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Member | Organization | | Member | Organization |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Padma Krishnaswamy | Battelle Memorial Institute | | Padma Krishnaswamy | Battelle Memorial Institute |
skipping to change at page 20, line 42 skipping to change at page 22, line 22
| McKay | | | McKay | |
| | | | | |
| Mary Lessels | U.S. Government | | Mary Lessels | U.S. Government |
| | | | | |
| Chris Salter | U.S. Government | | Chris Salter | U.S. Government |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
Table 1: Members of the TNC Work Group that Contributed to the Table 1: Members of the TNC Work Group that Contributed to the
Document Document
Special thanks also to Dan Ehrlich, Kathleen Moriarty, David Oliva
and Eric Voit for their thoughtful comments and edits.
8. IANA Considerations 8. IANA Considerations
This document does not define any new IANA registries. However, this This document does not define any new IANA registries. However, this
document does reference other documents that do define IANA document does reference other documents that do define IANA
registries. As a result, the IANA Considerations section of the registries. As a result, the IANA Considerations section of the
referenced documents should be consulted. referenced documents should be consulted.
9. Security Considerations 9. Security Considerations
This Security Considerations section includes an analysis of the This Security Considerations section includes an analysis of the
skipping to change at page 21, line 49 skipping to change at page 23, line 30
be unreliable or even malicious. This software, potentially be unreliable or even malicious. This software, potentially
including the SWID generation or discovery tool, or malicious including the SWID generation or discovery tool, or malicious
software pretending to be a SWID generation or discovery tool, can software pretending to be a SWID generation or discovery tool, can
place incorrect or maliciously crafted information into the SWID place incorrect or maliciously crafted information into the SWID
directory. Endpoint users may even place such information in the directory. Endpoint users may even place such information in the
directory, whether motivated by curiosity or confusion or a desire directory, whether motivated by curiosity or confusion or a desire
to bypass restrictions on their use of the endpoint. to bypass restrictions on their use of the endpoint.
o Identity spoofing (impersonation): A compromised endpoint may o Identity spoofing (impersonation): A compromised endpoint may
attempt to impersonate another endpoint to gain its privileges or attempt to impersonate another endpoint to gain its privileges or
to besmirch the reputation of that other endpoint. to besmirch the reputation of that other endpoint. This is of
particular concern when using MAC addresses to identify endpoints,
which, while widely used in endpoint behavior monitoring and
threat assessment tools, are easy to spoof.
9.1.2. Network Attacks 9.1.2. Network Attacks
A variety of attacks can be mounted using the network. Generally, Generally, the network cannot be trusted. A variety of attacks can
the network cannot be trusted. be mounted using the network, including:
o Eavesdropping, modification, injection, replay, deletion o Eavesdropping, modification, injection, replay, deletion;
o Traffic analysis o Traffic analysis; and
o Denial of service and blocking traffic o Denial of service and blocking traffic.
9.1.3. Posture Manager Attacks 9.1.3. Posture Manager Attacks
The posture manager is a critical security element and therefore The posture manager is a critical security element and therefore
merits considerable scrutiny. merits considerable scrutiny. A variety of attacks can be leveraged
against the Posture Manager.
o Compromised trusted manager: A compromised posture manager or a o Compromised trusted manager: A compromised posture manager or a
malicious party that is able to impersonate a posture manager can malicious party that is able to impersonate a posture manager can
incorrectly grant or deny access to endpoints, place incorrect incorrectly grant or deny access to endpoints, place incorrect
information into the repository, or send malicious messages to information into the repository, or send malicious messages to
endpoints. endpoints.
o Misconfiguration of posture manager: Accidental or purposeful o Misconfiguration of posture manager: Accidental or purposeful
misconfiguration of a trusted posture manager can cause effects misconfiguration of a trusted posture manager can cause effects
that are similar to those listed for compromised trusted posture that are similar to those listed for compromised trusted posture
skipping to change at page 23, line 33 skipping to change at page 25, line 20
9.2.1. Countermeasures for Endpoint Attacks 9.2.1. Countermeasures for Endpoint Attacks
This profile is in and of itself a countermeasure for a compromised This profile is in and of itself a countermeasure for a compromised
endpoint. A primary defense for an endpoint is to run up to date endpoint. A primary defense for an endpoint is to run up to date
software configured to be run as safely as possible. software configured to be run as safely as possible.
Ensuring that anti-virus signatures are up to date and that a Ensuring that anti-virus signatures are up to date and that a
firewall is configured are also protections for an endpoint that are firewall is configured are also protections for an endpoint that are
supported by the current NEA specifications. supported by the current NEA specifications.
Endpoints that have hardware cryptographic modules that are For secure device identification and to correlate device identifiers
provisioned by the enterprise, in accordance with [IEEE-802-1ar], can if the MAC address is randomized, MAC addresses should be collected
protect the private keys used for authentication and help prevent along with other, more secure endpoint identifiers. Endpoints that
adversaries from stealing credentials that can be used for have hardware cryptographic modules that are provisioned by the
impersonation. Future versions of the EPCP may want to discuss in enterprise, in accordance with [IEEE-802-1ar], can protect the
greater detail how to use a hardware cryptographic module, in private keys used for authentication and help prevent adversaries
accordance with [IEEE-802-1ar], to protect credentials and to protect from stealing credentials that can be used for impersonation. Future
the integrity of the code that executes during the bootstrap process. versions of the EPCP may want to discuss in greater detail how to use
a hardware cryptographic module, in accordance with [IEEE-802-1ar],
to protect credentials and to protect the integrity of the code that
executes during the bootstrap process by hashing or recording
indicators of compromise.
9.2.2. Countermeasures for Network Attacks 9.2.2. Countermeasures for Network Attacks
To address network attacks, [RFC6876] includes required encryption, To address network attacks, [RFC6876] includes required encryption,
authentication, integrity protection, and replay protection. authentication, integrity protection, and replay protection.
[Server-Discovery] also includes authorization checks to ensure that [Server-Discovery] also includes authorization checks to ensure that
only authorized servers are trusted by endpoints. Any unspecified or only authorized servers are trusted by endpoints. Any unspecified or
not yet specified network protocols employed in the EPCP (e.g. the not yet specified network protocols employed in the EPCP (e.g. the
protocol used to interface with the repository) should include protocol used to interface with the repository) should include
similar protections. similar protections.
skipping to change at page 26, line 5 skipping to change at page 27, line 40
A possible exception may be the concerns a user may have when A possible exception may be the concerns a user may have when
attempting to connect a personal endpoint (such as a phone or mobile attempting to connect a personal endpoint (such as a phone or mobile
endpoint) to an enterprise network. The user may not want to share endpoint) to an enterprise network. The user may not want to share
certain details, such as an endpoint identifier or SWID tags, with certain details, such as an endpoint identifier or SWID tags, with
the enterprise. The user can configure their NEA client to reject the enterprise. The user can configure their NEA client to reject
requests for this information; however, it is possible that the requests for this information; however, it is possible that the
enterprise policy will not allow the user's endpoint to connect to enterprise policy will not allow the user's endpoint to connect to
the network without providing the requested data. the network without providing the requested data.
An enterprise network should limit access to endpoint posture and
identification information to authorized users.
11. References 11. References
11.1. Informative References 11.1. Informative References
[CIS] http://www.cisecurity.org/controls/, "CIS Critical [CIS] http://www.cisecurity.org/controls/, "CIS Critical
Security Controls". Security Controls".
[DSD] http://www.dsd.gov.au/publications/csocprotect/ [DSD] http://www.dsd.gov.au/publications/csocprotect/
top_4_mitigations.htm, "Top 4 Mitigation Strategies to top_4_mitigations.htm, "Top 4 Mitigation Strategies to
Protect Your ICT System", November 2012. Protect Your ICT System", November 2012.
skipping to change at page 26, line 39 skipping to change at page 28, line 32
Architecture for Interoperability, Version 1.5", February Architecture for Interoperability, Version 1.5", February
2012. 2012.
11.2. Normative References 11.2. Normative References
[I-D.ietf-mile-xmpp-grid] [I-D.ietf-mile-xmpp-grid]
Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre,
"Using XMPP for Security Information Exchange", draft- "Using XMPP for Security Information Exchange", draft-
ietf-mile-xmpp-grid-04 (work in progress), October 2017. ietf-mile-xmpp-grid-04 (work in progress), October 2017.
[I-D.ietf-netconf-restconf-notif]
Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and
A. Bierman, "Dynamic subscription to YANG Events and
Datastores over RESTCONF", draft-ietf-netconf-restconf-
notif-15 (work in progress), June 2019.
[I-D.ietf-netconf-subscribed-notifications] [I-D.ietf-netconf-subscribed-notifications]
Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and
A. Tripathy, "Customized Subscriptions to a Publisher's A. Tripathy, "Customized Subscriptions to a Publisher's
Event Streams", draft-ietf-netconf-subscribed- Event Streams", draft-ietf-netconf-subscribed-
notifications-13 (work in progress), June 2018. notifications-13 (work in progress), June 2018.
[I-D.ietf-netconf-yang-push] [I-D.ietf-netconf-yang-push]
Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen-
Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore
Subscription", draft-ietf-netconf-yang-push-12 (work in Subscription", draft-ietf-netconf-yang-push-12 (work in
skipping to change at page 37, line 41 skipping to change at page 39, line 41
Figure 8: Admin Searches for Vulnerable Endpoints Figure 8: Admin Searches for Vulnerable Endpoints
The repository returns a list of entries in the matching the The repository returns a list of entries in the matching the
administrator's search. The administrator can then address the administrator's search. The administrator can then address the
vulnerable endpoints by taking some follow-up action such as removing vulnerable endpoints by taking some follow-up action such as removing
it from the network, quarantining it, or updating the vulnerable it from the network, quarantining it, or updating the vulnerable
software. software.
Appendix D. Change Log Appendix D. Change Log
D.1. -03 to -04 D.1. -04 to -05
Updated the diagram so the Evaluator and Repository are "current
work".
Clarified how the Posture Collection Engine can push data, respond to
queries, and establish secure transport connectivity for fulfilling
subscriptions.
Expanded on the future work around leveraging NETCONF, RESTCONF, and
YANG Push for network devices.
Documented the need to reassess MAC addresses as a device identifier.
Made various typographical and editorial changes.
D.2. -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.2. -02 to -03 D.3. -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 38, line 36 skipping to change at page 41, line 5
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.3. -01 to -02 D.4. -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.4. -00 to -01 D.5. -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.5. -01 to -02 D.6. -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.6. -02 to -00 D.7. -02 to -00
Draft adopted by IETF SACM WG. Draft adopted by IETF SACM WG.
D.7. -00 to -01 D.8. -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
Danny Haynes Danny Haynes
The MITRE Corporation The MITRE Corporation
202 Burlington Road 202 Burlington Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: dhaynes@mitre.org Email: dhaynes@mitre.org
Jessica Fitzgerald-McKay Jessica Fitzgerald-McKay
Department of Defense Department of Defense
 End of changes. 49 change blocks. 
162 lines changed or deleted 236 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/