draft-coffin-sacm-nea-swid-patnc-00.txt   draft-coffin-sacm-nea-swid-patnc-01.txt 
SACM C. Coffin SACM C. Coffin
Internet-Draft D. Haynes Internet-Draft D. Haynes
Intended status: Standards Track C. Schmidt Intended status: Standards Track C. Schmidt
Expires: September 8, 2016 The MITRE Corporation Expires: December 10, 2016 The MITRE Corporation
J. Fitzgerald-McKay J. Fitzgerald-McKay
Department of Defense Department of Defense
March 7, 2016 June 8, 2016
SWID Message and Attributes for PA-TNC SWID Message and Attributes for PA-TNC
draft-coffin-sacm-nea-swid-patnc-00 draft-coffin-sacm-nea-swid-patnc-01
Abstract Abstract
This document specifies the SWID Message and Attributes for PA-TNC. This document specifies the SWID Message and Attributes for PA-TNC.
It extends the PA-TNC specification [RFC5792] by providing specific It extends the PA-TNC specification [RFC5792] by providing specific
attributes and message exchanges to allow endpoints to report their attributes and message exchanges to allow endpoints to report their
software inventory information to a NEA server (as described in software inventory information to a NEA server (as described in
[RFC5209]) using SWID tags [SWID]. [RFC5209]) using SWID tags [SWID].
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 8, 2016. This Internet-Draft will expire on December 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 14 skipping to change at page 2, line 14
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
1.1. Scope and Audience . . . . . . . . . . . . . . . . . . . 4 1.1. Scope and Audience . . . . . . . . . . . . . . . . . . . 4
1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Role of SWID Message and Attributes for PA-TNC . . . . . 8 2.1. Role of SWID Message and Attributes for PA-TNC . . . . . 8
2.2. Supported Use Cases . . . . . . . . . . . . . . . . . . . 9 2.2. Supported Use Cases . . . . . . . . . . . . . . . . . . . 9
2.2.1. Use Software Inventory as a Factor in Determining 2.2.1. Use Software Inventory as a Factor in Determining
Endpoint Access . . . . . . . . . . . . . . . . . . . 9 Endpoint Access . . . . . . . . . . . . . . . . . . . 9
2.2.2. Maintain a Central Repository Reflecting an 2.2.2. Maintain a Central Repository Reflecting an
Endpoint's Software Inventory . . . . . . . . . . . . 10 Endpoint's Software Inventory . . . . . . . . . . . . 9
2.2.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 10 2.2.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 10
2.3. Non-supported Use Cases . . . . . . . . . . . . . . . . . 11 2.3. Non-supported Use Cases . . . . . . . . . . . . . . . . . 10
2.4. Specification Requirements . . . . . . . . . . . . . . . 12 2.4. Specification Requirements . . . . . . . . . . . . . . . 11
2.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 13 2.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 13
2.6. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 13 2.6. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 13
2.7. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 14 2.7. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 13
2.8. Caveat Regarding Persistent Connections . . . . . . . . . 14 2.8. SWID Message and Attributes for PA-TNC Diagram
2.9. SWID Message and Attributes for PA-TNC Diagram Conventions . . . . . . . . . . . . . . . . . . . . . . . 14
Conventions . . . . . . . . . . . . . . . . . . . . . . . 15 3. SWID Message and Attributes for PA-TNC System Requirements . 14
3. SWID Message and Attributes for PA-TNC System Requirements . 15 3.1. SWID Tags as Inventory Evidence . . . . . . . . . . . . . 15
3.1. SWID Tags as Inventory Evidence . . . . . . . . . . . . . 16 3.2. Basic SWID Tag Inventory Exchange . . . . . . . . . . . . 15
3.2. Basic SWID Tag Inventory Exchange . . . . . . . . . . . . 16 3.3. SWID Tag Identifiers . . . . . . . . . . . . . . . . . . 16
3.3. SWID Tag Identifiers . . . . . . . . . . . . . . . . . . 17 3.3.1. Tag Identifier Data . . . . . . . . . . . . . . . . . 17
3.3.1. Tag Identifier Data . . . . . . . . . . . . . . . . . 18 3.3.2. Tag Identifier Instances . . . . . . . . . . . . . . 18
3.3.2. Tag Identifier Instances . . . . . . . . . . . . . . 19
3.3.3. Comparing Tag Identifiers and Tag Identifier 3.3.3. Comparing Tag Identifiers and Tag Identifier
Instances . . . . . . . . . . . . . . . . . . . . . . 20 Instances . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3.1. Matching Tag Identifiers Indicate the Same 3.3.3.1. Matching Tag Identifiers Indicate the Same
Software Product . . . . . . . . . . . . . . . . 21 Software Product . . . . . . . . . . . . . . . . 20
3.3.3.2. Matching Tag Identifiers DO NOT Necessarily 3.3.3.2. Matching Tag Identifiers DO NOT Necessarily
Indicate Identical Tag Files . . . . . . . . . . 21 Indicate Identical Tag Files . . . . . . . . . . 20
3.3.3.3. Matching Tag Identifier Instances MIGHT Indicate 3.3.3.3. Matching Tag Identifier Instances MIGHT Indicate
Identical Tag Files . . . . . . . . . . . . . . . 22 Identical Tag Files . . . . . . . . . . . . . . . 21
3.3.3.4. Differing Tag Identifiers DO NOT Necessarily 3.3.3.4. Differing Tag Identifiers DO NOT Necessarily
Indicate Different Software Products . . . . . . 22 Indicate Different Software Products . . . . . . 21
3.3.4. Using Tag Identifiers in SWID Attributes . . . . . . 23 3.3.4. Using Tag Identifiers in SWID Attributes . . . . . . 22
3.4. Targeted Requests . . . . . . . . . . . . . . . . . . . . 23 3.4. Targeted Requests . . . . . . . . . . . . . . . . . . . . 22
3.5. Monitoring Changes in an Endpoint's SWID Tag Collection . 24 3.5. Monitoring Changes in an Endpoint's SWID Tag Collection . 23
3.6. Reporting Change Events . . . . . . . . . . . . . . . . . 26 3.6. Reporting Change Events . . . . . . . . . . . . . . . . . 25
3.6.1. Change Event Records . . . . . . . . . . . . . . . . 27 3.6.1. Change Event Records . . . . . . . . . . . . . . . . 25
3.6.2. Updating Inventory Knowledge Based on Events . . . . 28 3.6.2. Updating Inventory Knowledge Based on Events . . . . 27
3.6.3. Using Event Records in SWID Attributes . . . . . . . 29 3.6.3. Using Event Records in SWID Attributes . . . . . . . 28
3.6.4. Partial and Complete Lists of Event Records in SWID 3.6.4. Partial and Complete Lists of Event Records in SWID
Attributes . . . . . . . . . . . . . . . . . . . . . 29 Attributes . . . . . . . . . . . . . . . . . . . . . 28
3.6.5. Synchronizing Event Identifiers and Epochs . . . . . 31 3.6.5. Synchronizing Event Identifiers and Epochs . . . . . 30
3.7. Supporting Multiple Instances of a Single Tag . . . . . . 33 3.7. Supporting Multiple Instances of a Single Tag . . . . . . 32
3.7.1. Inventory Reporting in the Presence of Multiply- 3.7.1. Inventory Reporting in the Presence of Multiply-
Instantiated Tags . . . . . . . . . . . . . . . . . . 33 Instantiated Tags . . . . . . . . . . . . . . . . . . 32
3.7.2. Event Reporting in the Presence of Multiply 3.7.2. Event Reporting in the Presence of Multiply
Instantiated Tags . . . . . . . . . . . . . . . . . . 33 Instantiated Tags . . . . . . . . . . . . . . . . . . 32
3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 34 3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 32
3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 34 3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 33
3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 35 3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 33
3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 35 3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 34
3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 36 3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 35
3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 37 3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 35
3.8.5.1. Subscriptions Reporting Inventories . . . . . . . 39 3.8.5.1. Subscriptions Reporting Inventories . . . . . . . 37
3.8.5.2. Subscriptions Reporting Events . . . . . . . . . 39 3.8.5.2. Subscriptions Reporting Events . . . . . . . . . 37
3.8.5.3. Targeted Subscriptions . . . . . . . . . . . . . 40 3.8.5.3. Targeted Subscriptions . . . . . . . . . . . . . 38
3.8.5.4. No Subscription Consolidation . . . . . . . . . . 41 3.8.5.4. No Subscription Consolidation . . . . . . . . . . 39
3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 41 3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 39
3.9. Multiple Sources of SWID Tags . . . . . . . . . . . . . . 42 3.9. Multiple Sources of SWID Tags . . . . . . . . . . . . . . 40
3.10. Error Handling . . . . . . . . . . . . . . . . . . . . . 43 3.10. Error Handling . . . . . . . . . . . . . . . . . . . . . 41
4. SWID Message and Attributes for PA-TNC Protocol . . . . . . . 45 4. SWID Message and Attributes for PA-TNC Protocol . . . . . . . 43
4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 45 4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 43
4.2. PB-TNC and PA-TNC Messages . . . . . . . . . . . . . . . 46 4.2. PB-TNC and PA-TNC Messages . . . . . . . . . . . . . . . 44
4.3. PA-TNC Attribute Header . . . . . . . . . . . . . . . . . 46 4.3. PA-TNC Attribute Header . . . . . . . . . . . . . . . . . 44
4.4. SWID Attribute Overview . . . . . . . . . . . . . . . . . 47 4.4. SWID Attribute Overview . . . . . . . . . . . . . . . . . 45
4.5. SWID Attribute Exchanges . . . . . . . . . . . . . . . . 49 4.5. SWID Attribute Exchanges . . . . . . . . . . . . . . . . 47
4.6. SWID Message and Attributes for PA-TNC Attribute 4.6. SWID Message and Attributes for PA-TNC Attribute
Enumeration . . . . . . . . . . . . . . . . . . . . . . . 51 Enumeration . . . . . . . . . . . . . . . . . . . . . . . 49
4.7. Normalization of Text Encoding . . . . . . . . . . . . . 52 4.7. Normalization of Text Encoding . . . . . . . . . . . . . 50
4.8. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 53 4.8. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 51
4.9. SWID Request . . . . . . . . . . . . . . . . . . . . . . 54 4.9. SWID Request . . . . . . . . . . . . . . . . . . . . . . 52
4.10. SWID Tag Identifier Inventory . . . . . . . . . . . . . . 58 4.10. SWID Tag Identifier Inventory . . . . . . . . . . . . . . 56
4.11. SWID Tag Identifier Events . . . . . . . . . . . . . . . 61 4.11. SWID Tag Identifier Events . . . . . . . . . . . . . . . 59
4.12. SWID Tag Inventory . . . . . . . . . . . . . . . . . . . 66 4.12. SWID Tag Inventory . . . . . . . . . . . . . . . . . . . 64
4.13. SWID Tag Events . . . . . . . . . . . . . . . . . . . . . 68 4.13. SWID Tag Events . . . . . . . . . . . . . . . . . . . . . 66
4.14. Subscription Status Request . . . . . . . . . . . . . . . 72 4.14. Subscription Status Request . . . . . . . . . . . . . . . 70
4.15. Subscription Status Response . . . . . . . . . . . . . . 72 4.15. Subscription Status Response . . . . . . . . . . . . . . 70
4.16. PA-TNC Error as Used by SWID Message and Attributes for 4.16. PA-TNC Error as Used by SWID Message and Attributes for
PA-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 74 PA-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.16.1. SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR 4.16.1. SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR
and SWID_SUBSCRIPTION_ID_REUSE_ERROR and SWID_SUBSCRIPTION_ID_REUSE_ERROR
Information . . . . . . . . . . . . . . . . . . . . 76 Information . . . . . . . . . . . . . . . . . . . . 74
4.16.2. SWID_RESPONSE_TOO_LARGE_ERROR Information . . . . . 77 4.16.2. SWID_RESPONSE_TOO_LARGE_ERROR Information . . . . . 75
4.16.3. SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information . . 79 4.16.3. SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information . . 77
5. Security Considerations . . . . . . . . . . . . . . . . . . . 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 78
5.1. Evidentiary Value of SWID Tags . . . . . . . . . . . . . 81 5.1. Evidentiary Value of SWID Tags . . . . . . . . . . . . . 79
5.2. Integrity of the SWID Tag Collection . . . . . . . . . . 81 5.2. Integrity of the SWID Tag Collection . . . . . . . . . . 79
5.3. Sensitivity of Collected Tags . . . . . . . . . . . . . . 82 5.3. Sensitivity of Collected Tags . . . . . . . . . . . . . . 80
5.4. Integrity of Endpoint Records . . . . . . . . . . . . . . 83 5.4. Integrity of Endpoint Records . . . . . . . . . . . . . . 81
5.5. SWID-PC Access Permissions . . . . . . . . . . . . . . . 84 5.5. SWID-PC Access Permissions . . . . . . . . . . . . . . . 82
5.6. Sanitization of Tag Fields . . . . . . . . . . . . . . . 84 5.6. Sanitization of Tag Fields . . . . . . . . . . . . . . . 82
5.7. Tag Library Poisoning . . . . . . . . . . . . . . . . . . 85 5.7. Tag Library Poisoning . . . . . . . . . . . . . . . . . . 83
5.8. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 85 5.8. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 83
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 85 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 83
7. Relationship to Other Specifications . . . . . . . . . . . . 86 7. Relationship to Other Specifications . . . . . . . . . . . . 84
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
8.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 87 8.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 85
8.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 87 8.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 85
8.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 88 8.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 86
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.1. Normative References . . . . . . . . . . . . . . . . . . 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 87
9.2. Informative References . . . . . . . . . . . . . . . . . 89 9.2. Informative References . . . . . . . . . . . . . . . . . 87
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 90 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 88
A.1. A Simple SWID Tag . . . . . . . . . . . . . . . . . . . . 90 A.1. A Simple SWID Tag . . . . . . . . . . . . . . . . . . . . 88
A.2. SWID Request Attributes . . . . . . . . . . . . . . . . . 92 A.2. SWID Request Attributes . . . . . . . . . . . . . . . . . 90
A.2.1. Simple Request . . . . . . . . . . . . . . . . . . . 92 A.2.1. Simple Request . . . . . . . . . . . . . . . . . . . 90
A.2.2. Subscription Request for Events . . . . . . . . . . . 93 A.2.2. Subscription Request for Events . . . . . . . . . . . 91
A.2.3. Targeted Request . . . . . . . . . . . . . . . . . . 93 A.2.3. Targeted Request . . . . . . . . . . . . . . . . . . 91
A.3. SWID Response Attributes . . . . . . . . . . . . . . . . 95 A.3. SWID Response Attributes . . . . . . . . . . . . . . . . 93
A.3.1. SWID Tag Identifier Events Attribute . . . . . . . . 95 A.3.1. SWID Tag Identifier Events Attribute . . . . . . . . 93
A.3.2. SWID Tag Inventory Attribute . . . . . . . . . . . . 97 A.3.2. SWID Tag Inventory Attribute . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
1.1. Scope and Audience 1.1. Scope and Audience
The Network Endpoint Assessment (NEA) Working Group defines an open The Network Endpoint Assessment (NEA) Working Group defines an open
solution architecture that enables network operators to collect and solution architecture that enables network operators to collect and
utilize information about endpoint configuration and state. This utilize information about endpoint configuration and state. This
information can be used to enforce policies, monitor endpoint health, information can be used to enforce policies, monitor endpoint health,
and for many other activities. Information about the software and for many other activities. Information about the software
skipping to change at page 5, line 20 skipping to change at page 5, line 19
communicate software inventory evidence, in the form of SWID tags, communicate software inventory evidence, in the form of SWID tags,
between the posture collector and posture validator using the PA-TNC between the posture collector and posture validator using the PA-TNC
interface, as shown in Figure 1 below. interface, as shown in Figure 1 below.
+-------------+ +--------------+ +-------------+ +--------------+
| Posture | <--------PA--------> | Posture | | Posture | <--------PA--------> | Posture |
| Collectors | | Validators | | Collectors | | Validators |
| (1 .. N) | | (1 .. N) | | (1 .. N) | | (1 .. N) |
+-------------+ +--------------+ +-------------+ +--------------+
| | | |
| IF-IMC | IF-IMV | |
| | | |
+-------------+ +--------------+ +-------------+ +--------------+
| Posture | | Posture | | Posture | | Posture |
| Broker | <--------PB--------> | Broker | | Broker | <--------PB--------> | Broker |
| Client | | Server | | Client | | Server |
+-------------+ +--------------+ +-------------+ +--------------+
| | | |
| | | |
+-------------+ +--------------+ +-------------+ +--------------+
| Posture | | Posture | | Posture | | Posture |
skipping to change at page 6, line 45 skipping to change at page 6, line 44
highly useful to NEA Servers and other enterprise security highly useful to NEA Servers and other enterprise security
applications. applications.
Before reading this specification any further, the reader should Before reading this specification any further, the reader should
review and understand the NEA reference architecture as described in review and understand the NEA reference architecture as described in
the Network Endpoint Assessment (NEA): Overview and Requirements the Network Endpoint Assessment (NEA): Overview and Requirements
[RFC5209]. The reader should also understand the capabilities and [RFC5209]. The reader should also understand the capabilities and
requirements common to PA-TNC interfaces as defined in RFC 5792 requirements common to PA-TNC interfaces as defined in RFC 5792
[RFC5792]. [RFC5792].
In addition, this document relies upon features in the Trusted This document is based on standards published by the Trusted
Computing Group's Trusted Network Communications (TNC) IF-IMC 1.3 Computing Group's Trusted Network Communications (TNC) workgroup.
[IF-IMC] and IF-IMV 1.4 [IF-IMV] specifications. These The TNC and NEA architectures are interoperable and the following
specifications describe standard interfaces and requirements for the components are equivalent:
interoperation between TNC IMCs and TNC Clients, and between TNC IMVs
and TNC Servers. The TNC and NEA architectures are interoperable and
the following components are equivalent:
+---------------------------------------+-----------------------+ +---------------------------------------+-----------------------+
| TNC Component | NEA Component | | TNC Component | NEA Component |
+---------------------------------------+-----------------------+ +---------------------------------------+-----------------------+
| Integrity Measurement Verifier (IMV) | Posture Validator | | Integrity Measurement Verifier (IMV) | Posture Validator |
| Integrity Measurement Collector (IMC) | Posture Collector | | Integrity Measurement Collector (IMC) | Posture Collector |
| TNC Server (TNCS) | Posture Broker Server | | TNC Server (TNCS) | Posture Broker Server |
| TNC Client (TNCC) | Posture Broker Client | | TNC Client (TNCC) | Posture Broker Client |
+---------------------------------------+-----------------------+ +---------------------------------------+-----------------------+
Table 1: Equivalent components in TNC and NEA architectures Table 1: Equivalent components in TNC and NEA architectures
As a result, the IF-IMC specification effectively standardizes an
interface between a Posture Collector and the Posture Broker Client,
while the IF-IMV specification effectively standardize an interface
between a Posture Validator and a Posture Broker Server. However, as
there is currently no NEA equivalent for IF-IMC or IF-IMV, the names
for these specifications as well as the names of functions and data
structures that appear in those specifications uses TNC rather than
NEA terminology. Readers should be aware of the functional
equivalence of the TNC and NEA terms.
If the reader is building a posture collector that supports PA-TNC,
the reader is encouraged to read the TNC IF-IMC Specification prior
to reading this specification. If the reader is building a posture
validator that supports IF-IMV, the reader is encouraged to read the
TNC IF-IMV Specification prior to reading this specification.
1.2. Keywords 1.2. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in RFC 2119 specification are to be interpreted as described in RFC 2119
[RFC2119]. This specification does not distinguish blocks of [RFC2119]. This specification does not distinguish blocks of
informative comments and normative requirements. Therefore, for the informative comments and normative requirements. Therefore, for the
sake of clarity, note that lower case instances of must, should, etc. sake of clarity, note that lower case instances of must, should, etc.
do not indicate normative requirements. do not indicate normative requirements.
skipping to change at page 14, line 31 skipping to change at page 14, line 18
endpoint. This specification does not attempt to detect when the endpoint. This specification does not attempt to detect when the
endpoint is providing false information, either through malice or endpoint is providing false information, either through malice or
error, but instead focuses on correctly and reliably providing the error, but instead focuses on correctly and reliably providing the
existing SWID tags to the NEA Server. Similarly, this specification existing SWID tags to the NEA Server. Similarly, this specification
makes no assumption with regard to the completeness of the SWID tag makes no assumption with regard to the completeness of the SWID tag
collection's coverage of the total set of software installed on the collection's coverage of the total set of software installed on the
endpoint. It is possible, and even likely, that some installed endpoint. It is possible, and even likely, that some installed
software is not represented by a tag in an endpoints SWID tag software is not represented by a tag in an endpoints SWID tag
collection. See Section 5 for more on this security consideration. collection. See Section 5 for more on this security consideration.
2.8. Caveat Regarding Persistent Connections 2.8. SWID Message and Attributes for PA-TNC Diagram Conventions
One of the features defined in this specification describes the
ability for SWID-PCs to monitor the state of their endpoint's SWID
tag collection and, when changes are detected, to push updates to the
SWID-PV without the SWID-PV sending a request. (This feature is
described in more detail in Section 3.8.) This capability is tied to
the SWID-PC's ability to initiate an Integrity Check Handshake (as
described in section 2.10.1 of the IF-IMC 1.3 specification
[IF-IMC]), which in turn is only possible if there is an active
connection with a valid connection ID (as described in section 2.10.2
of the IF-IMC 1.3 specification).
The other specifications of the NEA architecture do not require
endpoints to maintain active connections outside of an Integrity
Check Handshake. While implementers are allowed to maintain
connections outside of an Integrity Check Handshake (and there are
advantages to doing so), maintaining open connections also consumes
resources on both the endpoint and the NEA Server, so some
implementers may choose to close connections as soon as a handshake
completes. Moreover, for devices with intermittent connectivity
(such as mobile phones), maintaining an active, ongoing connection
may be impractical.
This specification requires that all SWID-PCs and SWID-PVs support
subscriptions. However, for the reasons noted above, subscriptions
may not be practical in all environments where SWID-PCs and SWID-PVs
are deployed. Parties deploying SWID-PCs and SWID-PVs as part of
their enterprise protection strategy are encouraged to understand the
limits of specific devices and their NEA architecture as a whole. In
some cases, while other features of the SWID Message and Attributes
for PA-TNC specification may be employed, the use of subscriptions
may be limited or impractical without additional infrastructure
changes.
2.9. SWID Message and Attributes for PA-TNC Diagram Conventions
This specification defines the syntax of the SWID Message and This specification defines the syntax of the SWID Message and
Attributes for PA-TNC using diagrams. Each diagram depicts the Attributes for PA-TNC using diagrams. Each diagram depicts the
format and size of each field in bits. Implementations MUST send the format and size of each field in bits. Implementations MUST send the
bits in each diagram as they are shown from left to right for each bits in each diagram as they are shown from left to right for each
32-bit quantity traversing the diagram from top to bottom. Multi- 32-bit quantity traversing the diagram from top to bottom. Multi-
octet fields representing numeric values MUST be sent in network (big octet fields representing numeric values MUST be sent in network (big
endian) byte order. endian) byte order.
Descriptions of bit fields (e.g. flags) values refer to the position Descriptions of bit fields (e.g. flags) values refer to the position
skipping to change at page 17, line 25 skipping to change at page 16, line 25
Note, however, that proprietary measures might allow a SWID-PV to Note, however, that proprietary measures might allow a SWID-PV to
discover the SWID Request parameters for a SWID Response even if that discover the SWID Request parameters for a SWID Response even if that
SWID-PV did not send the given SWID Request. As such, there is no SWID-PV did not send the given SWID Request. As such, there is no
blanket requirement for a SWID-PV to discard all SWID Responses to blanket requirement for a SWID-PV to discard all SWID Responses to
SWID Request the SWID-PV did not generate itself, only that SWID-PVs SWID Request the SWID-PV did not generate itself, only that SWID-PVs
are required to discard SWID Responses for which they cannot get the are required to discard SWID Responses for which they cannot get the
necessary context to interpret. necessary context to interpret.
In the case that it is possible to do so, the SWID-PC MAY send its In the case that it is possible to do so, the SWID-PC MAY send its
SWID Response attribute to the SWID-PV that requested it using SWID Response attribute to the SWID-PV that requested it using
exclusive delivery as described in section 3.3.2.2 of the IF-IMV r1.4 exclusive delivery as described in section 4.5 of RFC 5793 (PB-TNC)
specification. Exclusive delivery ensures that only the sender of [RFC5793]. Exclusive delivery ensures that only the sender of the
the SWID Request receives the resulting SWID Response. However, SWID Request receives the resulting SWID Response. However, SWID
exclusive delivery is not always possible (it requires the use of IF- Message and Attributes for PA-TNC does not require support for
IMC 1.3 or later and IF-IMV 1.3 or later, and not all products
currently do this) or necessarily desirable in all cases. As such,
SWID Message and Attributes for PA-TNC does not require support for
exclusive delivery of attributes. exclusive delivery of attributes.
3.3. SWID Tag Identifiers 3.3. SWID Tag Identifiers
SWID tags can contain a great deal of information about a software SWID tags can contain a great deal of information about a software
product. In addition to identifying name, manufacturer, and version product. In addition to identifying name, manufacturer, and version
of a software product, SWID tags might contain references to related of a software product, SWID tags might contain references to related
products, associated files and libraries, dependencies on other products, associated files and libraries, dependencies on other
software, and many other details. Moreover, SWID tags might be software, and many other details. Moreover, SWID tags might be
customized on the endpoint to indicate when the SWID tag was last customized on the endpoint to indicate when the SWID tag was last
skipping to change at page 35, line 9 skipping to change at page 33, line 48
A SWID-PC MUST have the ability to record and support multiple A SWID-PC MUST have the ability to record and support multiple
simultaneous subscriptions from a single party and subscriptions from simultaneous subscriptions from a single party and subscriptions from
multiple parties. A SWID-PV MUST have the ability to record and multiple parties. A SWID-PV MUST have the ability to record and
support multiple simultaneous subscriptions to a single party and support multiple simultaneous subscriptions to a single party and
subscriptions to multiple parties. subscriptions to multiple parties.
3.8.2. Managing Subscriptions 3.8.2. Managing Subscriptions
The SWID-PC MUST record each accepted subscription along with the The SWID-PC MUST record each accepted subscription along with the
identity of the party to whom attributes are to be pushed in identity of the party to whom attributes are to be pushed in
compliance with the subscription. If the attribute is received by compliance with the subscription. This identity includes both the
the SWID-PC using the TNC_IMC_ReceiveMessage (section 3.8.4 of IF-IMC NEA Server's connection ID and the Posture Validator Identifier from
1.3 [IF-IMC]) function, then only the connection ID of the SWID-PV's the PB-PA message that delivered the request.
NEA Server is available to the SWID-PC. If the attribute is received
by the SWID-PC using the TNC_IMC_ReceiveMessageLong function (section
3.8.6 of IF-IMC) then the SWID-PC has both the NEA Server's
connection ID and the Posture Validator ID of the sending SWID-PV.
SWID-PCs SHOULD support TNC_IMC_ReceiveMessageLong function calls.
SWID-PCs MUST record the connection ID of the SWID-PV's NEA Server
for each accepted subscription. SWID-PCs SHOULD record the SWID-PV's
Posture Validator ID for each accepted subscription if this
information is available.
Likewise, SWID-PVs MUST record each accepted subscription for which Likewise, SWID-PVs MUST record each accepted subscription for which
they are the subscribing party along with its Subscription ID and the they are the subscribing party along with the associated Subscription
identity of the SWID-PC that will be fulfilling the subscription. ID and the identity of the SWID-PC that will be fulfilling the
The SWID-PV needs to retain this information in order to correctly subscription. The SWID-PV needs to retain this information in order
interpret pushed SWID Response attributes sent in fulfillment of the to correctly interpret pushed SWID Response attributes sent in
subscription. As with the SWID-PC, the SWID-PV might only have fulfillment of the subscription. The identity of the SWID-PC is
access to the connection ID of the SWID-PC's endpoint, or might have given in the Posture Collector Identifier of the PB-PA message header
both this connection ID and the SWID-PC's Posture Collector ID in all messages from that SWID-PC.
depending on the supported IF-IMV functions [IF-IMV]. SWID-PVs
SHOULD support TNC_IMV_ReceiveMessageLong function calls so as to be
capable of receiving the SWID-PC's Posture Collector ID. SWID-PVs
MUST record the connection ID of the SWID-PC's endpoint for each
accepted subscription. The SWID-PV SHOULD record the SWID-PC's
Posture Collector ID for each accepted subscription if this
information is available.
3.8.3. Terminating Subscriptions 3.8.3. Terminating Subscriptions
Subscriptions MAY be terminated at any time by the subscribing SWID- Subscriptions MAY be terminated at any time by the subscribing SWID-
PV by setting the Clear Subscriptions flag in a SWID Request. (See PV by setting the Clear Subscriptions flag in a SWID Request. (See
Section 4.9 for more on using this flag.) In the case that the SWID- Section 4.9 for more on using this flag.) In the case that the SWID-
PC receives both the connection ID and the Posture Validator ID of PC receives both the connection ID and the Posture Validator ID of
the SWID-PV requesting that subscriptions be cleared (i.e., the clear the SWID-PV requesting that subscriptions be cleared (i.e., the clear
subscription request is received via a TNC_IMC_ReceiveMessageLong subscription request is received via a TNC_IMC_ReceiveMessageLong
function) and the SWID-PC has been recording PV IDs associated with function) and the SWID-PC has been recording PV IDs associated with
skipping to change at page 36, line 23 skipping to change at page 34, line 48
unilaterally terminate a subscription. However, if the SWID-PC unilaterally terminate a subscription. However, if the SWID-PC
experiences a fatal error fulfilling a subscription, resulting in experiences a fatal error fulfilling a subscription, resulting in
sending a PA-TNC Error attribute of type sending a PA-TNC Error attribute of type
SWID_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose SWID_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose
fulfillment led to the error MUST be treated as terminated by both fulfillment led to the error MUST be treated as terminated by both
the SWID-PC and the SWID-PV. Only the subscription experiencing the the SWID-PC and the SWID-PV. Only the subscription experiencing the
error is cancelled and other subscriptions are unaffected. See error is cancelled and other subscriptions are unaffected. See
Section 3.10 for more on this error condition. Section 3.10 for more on this error condition.
Finally, a subscription is terminated if the connection between the Finally, a subscription is terminated if the connection between the
SWID-PC and SWID-PV is deleted, as indicated by the connection state SWID-PC and SWID-PV is deleted. This occurs when the connection ID
changing to DELETE. (Described in section 3.5.2.2 of IF-IMC [IF-IMC] used in the messages between the SWID-PC and the SWID-PV becomes
and section 3.5.2.2 of IF-IMV [IF-IMV].) Doing this renders the unbound. Loss of this connection ID would prevent the SWID-PC from
SWID-PC incapable of pushing additional SWID Response attributes to sending messages in fulfillment of this subscription. As such, loss
the subscribing party. Both the SWID-PC and SWID-PV MUST delete all of the connection ID necessarily forces subscription termination
subscriptions for which the connection has been deleted. SWID-PCs between the affected parties.
MUST support the TNC_IMC_NotifyConnectionChange function, as defined
in IF-IMC 1.3 section 3.8.2, so that the SWID-PC can be informed when
a connection's state changes to DELETE. Likewise, a SWID-PV MUST
support the TNC_IMV_NotifyConnectionChange function, as defined in
IF-IMV 1.4 section 3.8.2, for the same reason.
3.8.4. Subscription Status 3.8.4. Subscription Status
A SWID-PV can request that a SWID-PC report the list of active A SWID-PV can request that a SWID-PC report the list of active
subscriptions where the SWID-PV is the subscriber. A SWID-PV can use subscriptions where the SWID-PV is the subscriber. A SWID-PV can use
this to recover lost information about active subscriptions. A SWID- this to recover lost information about active subscriptions. A SWID-
PV can also use this capability to verify that a SWID-PC has not PV can also use this capability to verify that a SWID-PC has not
forgotten any of its subscriptions. The latter is especially useful forgotten any of its subscriptions. The latter is especially useful
where a SWID-PC does not send any attributes in fulfillment of a where a SWID-PC does not send any attributes in fulfillment of a
given subscription for a long period of time. The SWID-PV can check given subscription for a long period of time. The SWID-PV can check
skipping to change at page 37, line 26 skipping to change at page 35, line 46
connection ID and that have no associated Posture Validator ID, and connection ID and that have no associated Posture Validator ID, and
MUST include all such records. MUST include all such records.
3.8.5. Fulfilling Subscriptions 3.8.5. Fulfilling Subscriptions
As noted in Section 3.5 SWID-PCs MUST have the ability to As noted in Section 3.5 SWID-PCs MUST have the ability to
automatically detect changes to an endpoint's SWID tag collection in automatically detect changes to an endpoint's SWID tag collection in
near real-time. For every active subscription, the SWID-PC MUST send near real-time. For every active subscription, the SWID-PC MUST send
an attribute to the subscribed SWID-PV whenever a change is detected an attribute to the subscribed SWID-PV whenever a change is detected
to relevant tags within the endpoint's SWID tag collection. The to relevant tags within the endpoint's SWID tag collection. The
SWID-PC MAY choose to exclusively deliver this attribute in the case SWID-PC MAY choose to exclusively deliver this attribute. (See
that the SWID-PV's Posture Validator ID is known. (See section section 4.5 of RFC 5793 (PB-TNC) [RFC5793] for more on exclusive
3.3.2.2 of IF-IMC 1.3 [IF-IMC] or section 3.3.2.2 of IF-IMV 1.4 delivery.) Such an attribute is said to be sent "in fulfillment of"
[IF-IMV] for more on exclusive delivery.) Such an attribute is said the given subscription and any such attribute MUST include that
to be sent "in fulfillment of" the given subscription and any such subscription's Subscription ID. If the establishing request for that
attribute include that subscription's Subscription ID. If the subscription was a targeted request, then only tags that match the
establishing request for that subscription was a targeted request, SWID tag identifiers provided in that establishing request are
then only tags that match the SWID tag identifiers provided in that considered relevant. Otherwise, (i.e., for non-targeted requests)
establishing request are considered relevant. Otherwise, (i.e., for any tag is considered relevant for this purpose. Figure 3 shows a
non-targeted requests) any tag is considered relevant for this sample message exchange where a subscription is established and then
purpose. Figure 3 shows a sample message exchange where a later messages are sent from the SWID-PC in fulfillment of the
subscription is established and then later messages are sent from the established subscription.
SWID-PC in fulfillment of the established subscription.
+-------------+ +--------------+ +-------------+ +--------------+
| SWID-PC | | SWID-PV | Time | SWID-PC | | SWID-PV | Time
+-------------+ +--------------+ | +-------------+ +--------------+ |
| | | | | |
|<----------SWID Request------------| | |<----------SWID Request------------| |
| | | | | |
|-----------SWID Response---------->| | |-----------SWID Response---------->| |
| | | | | |
. . . . . .
skipping to change at page 53, line 36 skipping to change at page 51, line 36
sections. sections.
4.8. Request IDs 4.8. Request IDs
All SWID Request attributes MUST include a Request ID value. The All SWID Request attributes MUST include a Request ID value. The
Request ID field provides a value that identifies a given request Request ID field provides a value that identifies a given request
relative to other requests between a SWID-PV and the receiving SWID- relative to other requests between a SWID-PV and the receiving SWID-
PC. Specifically, the SWID-PV assigns each SWID Request attribute a PC. Specifically, the SWID-PV assigns each SWID Request attribute a
Request ID value that is intended to be unique within the lifetime of Request ID value that is intended to be unique within the lifetime of
a given network connection ID as assigned by the SWID-PV's Posture a given network connection ID as assigned by the SWID-PV's Posture
Broker Server (as described in section 3.5.2.2 of the IF-IMV Broker Server. In the case where all possible Request ID values have
specification [IF-IMV]). In the case where all possible Request ID been exhausted within the lifetime of a single network connection ID,
values have been exhausted within the lifetime of a single network the sender MAY reuse previously used Request IDs within the same
connection ID, the sender MAY reuse previously used Request IDs network connection that are not being used as Subscription IDs. (See
within the same network connection that are not being used as below in this section for an explanation of Subscription ID
Subscription IDs. (See below in this section for an explanation of assignment.) In this case of Request ID reuse, Request IDs SHOULD be
Subscription ID assignment.) In this case of Request ID reuse, reused in the order of their original use. For example, if a Request
Request IDs SHOULD be reused in the order of their original use. For ID of X was the first Request ID used within a particular network
example, if a Request ID of X was the first Request ID used within a connection and if the Request IDs are exhausted, X will be the first
particular network connection and if the Request IDs are exhausted, X reused Request ID. In other words, a SWID-PC SHOULD NOT use a given
will be the first reused Request ID. In other words, a SWID-PC Request ID value more than once within a persistent connection
SHOULD NOT use a given Request ID value more than once within a between a given Posture Broker Client-Posture Broker Server pair,
persistent connection between a given Posture Broker Client-Posture but, in the case where reuse is necessary due to exhaustion of
Broker Server pair, but, in the case where reuse is necessary due to possible ID values, the SWID-PC SHOULD structure the reuse to
exhaustion of possible ID values, the SWID-PC SHOULD structure the maximize the time between original and subsequent use. The Request
reuse to maximize the time between original and subsequent use. The ID value is included in a response attribute directly responding to
Request ID value is included in a response attribute directly this SWID Request to indicate which SWID Request was received and
responding to this SWID Request to indicate which SWID Request was caused the response. Request IDs can be randomly generated or
received and caused the response. Request IDs can be randomly sequential, as long as values are not repeated per the rules in this
generated or sequential, as long as values are not repeated per the paragraph. SWID-PCs are not required to check for duplicate Request
rules in this paragraph. SWID-PCs are not required to check for IDs.
duplicate Request IDs.
In the case that a SWID Request requests the establishment of a In the case that a SWID Request requests the establishment of a
subscription and the receiving SWID-PC agrees to that subscription, subscription and the receiving SWID-PC agrees to that subscription,
the Request ID of that SWID Request (i.e., the establishing request the Request ID of that SWID Request (i.e., the establishing request
of the subscription) becomes that subscription's Subscription ID. of the subscription) becomes that subscription's Subscription ID.
All attributes sent in fulfillment of this subscription include a All attributes sent in fulfillment of this subscription include a
flag indicating that the attribute fulfills a subscription and the flag indicating that the attribute fulfills a subscription and the
subscription's Subscription ID. A SWID-PV MUST NOT reuse a Request subscription's Subscription ID. A SWID-PV MUST NOT reuse a Request
ID value in communicating to a given SWID-PC while that Request ID is ID value in communicating to a given SWID-PC while that Request ID is
also serving as a Subscription ID for an active subscription with also serving as a Subscription ID for an active subscription with
skipping to change at page 86, line 15 skipping to change at page 84, line 15
authorized to receive this information and that can be trusted to authorized to receive this information and that can be trusted to
safeguard this information after collection. safeguard this information after collection.
7. Relationship to Other Specifications 7. Relationship to Other Specifications
This specification makes frequent reference to and use of other This specification makes frequent reference to and use of other
specifications. This section describes these relationships. specifications. This section describes these relationships.
This specification is expected to participate in a standard NEA This specification is expected to participate in a standard NEA
architecture. As such, it is expected to be used in conjunction with architecture. As such, it is expected to be used in conjunction with
the other protocols used in a NEA exchange. In particular, the SWID- the other protocols used in a NEA exchange. In particular, SWID
PC communicates with the endpoint's Posture Broker Client using IF- Attributes are conveyed over PB-TNC [RFC5793], which is in turn
IMC [IF-IMC], while the SWID-PV communicates with the NEA Server's conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP
Posture Broker Server using IF-IMV [IF-IMV]. [RFC7171]). These protocols have an especially important role, as
they are responsible for ensuring that attributes defined under this
In addition, SWID Attributes are conveyed over PB-TNC [RFC5793], specification are delivered reliably, securely, and to the
which is in turn conveyed over some variant of PT (either PT-TLS appropriate party.
[RFC6876] or PT-EAP [RFC7171]). These protocols have an especially
important role, as they are responsible for ensuring that attributes
defined under this specification are delivered reliably, securely,
and to the appropriate party.
It is important to note that the Product Information, Numeric It is important to note that the Product Information, Numeric
Version, and String Version attributes defined in the PA-TNC Version, and String Version attributes defined in the PA-TNC
specification [RFC5792] are also meant to convey information about specification [RFC5792] are also meant to convey information about
installed applications and the versions thereof. As such, there is installed applications and the versions thereof. As such, there is
some conceptual overlap between those attributes and the intent of some conceptual overlap between those attributes and the intent of
this specification. However, PA-TNC was designed to respond to very this specification. However, PA-TNC was designed to respond to very
specific queries about specific classes of products, while the SWID specific queries about specific classes of products, while the SWID
Message and Attributes for PA-TNC specification is able to convey a Message and Attributes for PA-TNC specification is able to convey a
broader query, resulting in a more comprehensive set of evidence broader query, resulting in a more comprehensive set of evidence
skipping to change at page 89, line 36 skipping to change at page 87, line 36
(TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010,
<http://www.rfc-editor.org/info/rfc5792>. <http://www.rfc-editor.org/info/rfc5792>.
[SWID] The International Organization for Standardization/ [SWID] The International Organization for Standardization/
International Electrotechnical Commission, "Information International Electrotechnical Commission, "Information
Technology - Software Asset Management - Part 2: Software Technology - Software Asset Management - Part 2: Software
Identification Tag, ISO/IEC 19770-2", November 2009. Identification Tag, ISO/IEC 19770-2", November 2009.
9.2. Informative References 9.2. Informative References
[IF-IMC] Trusted Computing Group, "TNC IF-IMC version 1.3",
February 2013.
[IF-IMV] Trusted Computing Group, "TNC IF-IMV version 1.4", August
2013.
[NIST-SWID] [NIST-SWID]
The National Institute of Standards and Technology and The The National Institute of Standards and Technology and The
MITRE Corporation, "Guidelines for the Creation of MITRE Corporation, "Guidelines for the Creation of
Interoperable Software Identification (SWID) Tags", August Interoperable Software Identification (SWID) Tags", August
2013. 2013.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
A Posture Broker (PB) Protocol Compatible with Trusted A Posture Broker (PB) Protocol Compatible with Trusted
Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793,
March 2010, <http://www.rfc-editor.org/info/rfc5793>. March 2010, <http://www.rfc-editor.org/info/rfc5793>.
 End of changes. 31 change blocks. 
252 lines changed or deleted 161 lines changed or added

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