HCD Health Assessment TNC Binding (HCD-TNC)

PWG 5110.4-2015 – HCD Health Assessment TNC Binding (HCD-TNC) 4 December 2015

Hardcopy Device Health Assessment

Trusted Network Connect Binding
(HCD-TNC)

Status: Approved

Abstract: This document defines a concrete protocol binding over TCG TNC / IETF NEA (technically equivalent) of the abstract PWG Hardcopy Device Health Assessment Attributes (PWG5110.1) for initial network endpoint health assessment (at time of network attachment) and periodic network endpoint health assessment (at runtime) of Imaging Devices.

This document is a PWG Candidate Standard. For a definition of a "PWG Candidate Standard", see:

http://ftp.pwg.org/pub/pwg/general/pwg-process30.pdf

This document is available electronically at:

http://ftp.pwg.org/pub/pwg/candidates/cs-idstnc10-20151204-5110.4.docx

http://ftp.pwg.org/pub/pwg/candidates/cs-idstnc10-20151204-5110.4.pdf

This document may be copied and furnished to others, and derivative works that comment on, or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice, this paragraph and the title of the Document as referenced below are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO.

Title: Hardcopy Device Health Assessment Trusted Network Connect Binding (HCD-TNC)

The IEEE-ISTO and the Printer Working Group DISCLAIM ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED INCLUDING (WITHOUT LIMITATION) ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The Printer Working Group, a program of the IEEE-ISTO, reserves the right to make changes to the document without further notice. The document may be updated, replaced or made obsolete by other documents at any time.

The IEEE-ISTO takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.

The IEEE-ISTO invites any interested party to bring to its attention any copyrights, patents, or patent applications, or other proprietary rights which may cover technology that may be required to implement the contents of this document. The IEEE-ISTO and its programs shall not be responsible for identifying patents for which a license may be required by a document and/or IEEE-ISTO Industry Group Standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Inquiries may be submitted to the IEEE-ISTO by e-mail at: .

The Printer Working Group acknowledges that the IEEE-ISTO (acting itself or through its designees) is, and shall at all times, be the sole entity that may authorize the use of certification marks, trademarks, or other special designations to indicate compliance with these materials.

Use of this document is wholly voluntary. The existence of this document does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to its scope.

About the IEEE-ISTO

The IEEE-ISTO is a not-for-profit corporation offering industry groups an innovative and flexible operational forum and support services. The IEEE-ISTO provides a forum not only to develop standards, but also to facilitate activities that support the implementation and acceptance of standards in the marketplace. The organization is affiliated with the IEEE (http://www.ieee.org/) and the IEEE Standards Association (http://standards.ieee.org/).

For additional information regarding the IEEE-ISTO and its industry programs visit:

http://www.ieee-isto.org

About the IEEE-ISTO PWG

The Printer Working Group (or PWG) is a Program of the IEEE Industry Standards and Technology Organization (ISTO) with member organizations including printer manufacturers, print server developers, operating system providers, network operating systems providers, network connectivity vendors, and print management application developers. The group is chartered to make printers and the applications and operating systems supporting them work together better. All references to the PWG in this document implicitly mean “The Printer Working Group, a Program of the IEEE ISTO.” In order to meet this objective, the PWG will document the results of their work as open standards that define print related protocols, interfaces, procedures and conventions. Printer manufacturers and vendors of printer related software will benefit from the interoperability provided by voluntary conformance to these standards.

In general, a PWG standard is a specification that is stable, well understood, and is technically competent, has multiple, independent and interoperable implementations with substantial operational experience, and enjoys significant public support.

For additional information regarding the Printer Working Group visit:

http://www.pwg.org

Contact information:

The Printer Working Group

c/o The IEEE Industry Standards and Technology Organization

445 Hoes Lane

Piscataway, NJ 08854

USA

About the Imaging Device Security Working Group

The goal of the Imaging Device Security Working Group is to provide the metrics and mechanisms that allow Imaging Devices to fully participate in assessment-protected networks and provide secure, controlled access to Jobs, Documents, and Imaging Services.

For additional information regarding IDS visit:

http://www.pwg.org/ids

Implementers of this specification are encouraged to join the IDS mailing list in order to participate in any discussions of the specification. Suggested additions, changes, or clarification to this specification, should be sent to the IDS mailing list for consideration.

Table of Contents

1. Introduction 7

1.1 Rationale for HCD-Specific TNC PA Subtypes 7

2. Terminology 7

2.1 Conformance Terminology 7

2.2 Imaging and Security Terminology 7

2.3 TCG TNC Terminology 8

2.4 Acronyms and Organizations 10

3. Requirements 10

3.1 Rationale for HCD-TNC 10

3.2 Use Cases for HCD-TNC 10

3.3 Out of Scope for HCD-TNC 11

3.4 Design Requirements for HCD-TNC 11

4. TNC Protocol Overview 12

4.1 TCG TNC Architecture 12

4.2 IETF PT-EAP – TNC Layer 2 Transport Protocol 12

4.2.1 IETF PT-EAP Message Format 12

4.3 IETF PT-TLS – TNC Layer 4 Transport Protocol 13

4.3.1 IETF PT-TLS Message Format 13

4.3.2 IETF PT-TLS Message Types 14

4.4 IETF PB-TNC – TNC Posture Broker Protocol 14

4.4.1 IETF PB-TNC Message Encapsulation 14

4.4.2 IETF PB-TNC Message Header Format 15

4.4.3 IETF PB-TNC Message Body Format 15

4.4.4 IETF PB-PA Message Type Format 16

4.5 IETF PA-TNC – TNC Posture Attribute Protocol 18

4.5.1 Overview of IETF PA-TNC Message within IETF PB-TNC Message 18

4.5.2 IETF PA-TNC Message Header Format 18

4.5.3 IETF PA-TNC Attribute Format 19

5. HCD Statement of Health for TNC Protocol 20

5.1 Mandatory Attributes 21

5.1.1 AttributesNaturalLanguage 21

5.1.2 MachineTypeModel 21

5.1.3 VendorName 22

5.1.4 VendorSMICode 22

5.1.5 DefaultPasswordEnabled 22

5.1.6 FirewallSetting 23

5.1.7 ForwardingEnabled 24

5.1.8 FirmwareName 24

5.1.9 FirmwarePatches 25

5.1.10 FirmwareStringVersion 25

5.1.11 FirmwareVersion 25

5.1.12 UserApplicationEnabled 26

5.1.13 UserApplicationPersistenceEnabled 26

5.1.14 PSTNFaxEnabled 26

5.1.15 TimeSource 27

5.2 Conditionally Mandatory Attributes 27

5.2.1 UserApplicationName 28

5.2.2 UserApplicationPatches 28

5.2.3 UserApplicationStringVersion 28

5.2.4 UserApplicationVersion 29

5.2.5 ResidentApplicationName 29

5.2.6 ResidentApplicationPatches 30

5.2.7 ResidentApplicationStringVersion 30

5.2.8 ResidentApplicationVersion 30

5.3 OptionalAttributes 31

5.3.1 CertificationState 31

5.3.2 ConfigurationState 31

5.4 Correlated Attributes 32

6. Conformance Requirements 33

6.1 HCD TNC Binding Conformance 33

6.2 HCD TNC Attribute Conformance 33

6.2.1 Mandatory Attributes 33

6.2.2 Conditionally Mandatory Attributes 34

6.2.3 Optional Attributes 34

7. Internationalization Considerations 35

8. Security Considerations 35

9. IANA and PWG Considerations 36

9.1 PWG Standard PA Subtypes 36

10. References 37

10.1 Normative References 37

10.2 Informative References 38

11. Editor's Address 39

List of Tables

Table 1 – PWG Standard PA Subtypes for HCD Components 36

List of Figures

Figure 1 – IETF PT-EAP Message Format 12

Figure 2 – IETF PT-TLS Message Format 13

Figure 3 – IETF PB-TNC Message Format 14

Figure 4 – IETF PB-TNC Message Header Format 15

Figure 5 – IETF PB-TNC Message Body Format 15

Figure 6 – IETF PB-PA Message Type Format 16

Figure 7 – IETF PA-TNC Message within IETF PB-TNC Message Format 18

Figure 8 – IETF PA-TNC Message Header Format 18

Figure 9 – IETF PA-TNC Attribute Format 19

Figure 10 – IETF PA-TNC FirewallSetting Format 23

1. Introduction

This document defines a concrete protocol binding over TCG TNC / IETF NEA (technically equivalent) of the abstract PWG Hardcopy Device Health Assessment Attributes [PWG5110.1] for initial network endpoint health assessment (at time of network attachment) and periodic network endpoint health assessment (at runtime) of Imaging Devices.

1.1 Rationale for HCD-Specific TNC PA Subtypes

TNC Posture Attribute (PA) subtypes are used to distinguish major components of network endpoints to allow dispatch of the appropriate TNC Integrity Measurement Validator (IMV) to process a given TNC posture attribute received from a network endpoint. IETF PA-TNC [RFC5792] assigns standard PA subtypes under the IETF SMI arc to identify generic major components that are common to most network endpoints. To support the dispatch of an appropriate HCD-specific IMV, this document assigns HCD-specific PA subtypes (see sections 9 and 9.1) and mandates their use for standard HCD-specific posture attributes (see sections 5, 5.1, 5.2, and 5.3).

2. Terminology

2.1 Conformance Terminology

Capitalized terms, such as MUST, MUST NOT, RECOMMENDED, REQUIRED, SHOULD, SHOULD NOT, MAY, and OPTIONAL, have special meaning relating to conformance as defined in Key words for use in RFCs to Indicate Requirement Levels [RFC2119]. The term CONDITIONALLY REQUIRED is additionally defined for a conformance requirement that applies to a particular capability or feature.

2.2 Imaging and Security Terminology

Normative definitions and semantics of printing terms are imported from the Printer MIB v2 [RFC3805], Printer Finishings MIB [RFC3806], and Internet Printing Protocol/1.1: Model and Semantics [RFC2911].

In addition, the following terms are imported or generalized from [IEEE2600]:

Administrator: A user who has been specifically granted the authority to manage some portion or all of the HCD and whose actions may affect the security policy. Administrators may possess special privileges that provide capabilities to override portions of the security policy. [IEEE2600]

Application: Persistent computer instructions and data placed on the HCD, via download or additional hardware (e.g., daughter card), that are separate from, and not a part of, the base Firmware. Applications are an addition to the base Firmware that provide additional function beyond that provided by the base Firmware.

Correlated Attributes: An ordered set of related attributes that describe an instance of firmware or software. The purpose of these Correlated Attributes is to allow ease-of-access and verification for each code instance.

Device Administrator: A user who controls administrative operations of the HCD other than its network configuration (e.g., management of users and resources of the HCD). [IEEE2600]

Firmware: Persistent computer instructions and data embedded in the HCD that provides the basic functions of that device. Firmware is only replaced during a specialized update process. [IEEE2600]

Hardcopy Device (HCD): A system producing or utilizing a physical embodiment of an electronic document or image. These systems include printers, scanners, fax machines, digital copiers, multifunction peripherals (MFPs), multifunction devices (MFDs), all-in-ones, and other similar products. [IEEE2600]

Network Administrator: A user who manages the network configuration of the HCD. [IEEE2600]

Resident Application: Resident applications are those applications that are downloaded via an offline administrative or maintenance update procedure and persist after a power cycle of the HCD. These types of applications augment the normal operation of the HCD and provide additional functions that are available to all users of the HCD.

User: An entity (human user or IT entity) outside the HCD that interacts with the HCD. [IEEE2600]

User Application: User applications are applications that are downloaded and executed as part of normal operation of the HCD and may be dynamically installed and executed by users. These applications do not include applications that are added via an offline administrative or maintenance update procedure. Examples of these types of applications include Java or Flash applications. User applications may or may not persist after a power cycle of the HCD.

2.3 TCG TNC Terminology

Normative definitions and semantics of health assessment terms are imported from section 11 “TNC Glossary” of TCG Trusted Network Connect Architecture for Interoperability [TNC-ARCH]:

Access Requestor (AR): An entity that is seeking connectivity to a network or access to a network resource (i.e., service, data, etc.).

Endpoint Integrity Information: The set of information provided by Integrity Measurement Collectors (IMCs) that describes the status and configuration of the Access Requestor (AR).

Integrity Information: The set of platform specific information that makes up a Trusted Platform. This ranges from information about a platform’s hardware components, TPM information (e.g. versions), PCRs, peripherals, Trusted Building Blocks, OS/Kernel, drivers, Applications, Anti-Virus information and others. Each specific use-case determines which information set will be of interest. As such, it is expected that for a given situation these will be pre-determined or pre-configured by an authorized entity (e.g. IT administrator).

Integrity Measurement Collector (IMC): The component of an Access Requestor (AR) that measures certain aspects of the AR's integrity, including software versions, patches, Anti-Virus and others.

Integrity Measurement Verifier (IMV): The component of a Policy Decision Point (PDP) that verifies a particular aspect of the AR’s integrity, based on measurements received from Integrity Measurement Collectors (IMCs) and/or other data. Note that multiple IMVs may reside on a single PDP.

Isolation: The action of separating an Access Requestor (AR) onto a separate network – virtual or physical – possibly, though not necessarily, for the purposes of performing Remediation on that AR.

Platform Authentication: The action of verifying both the proof-of-identity and integrity-status of a given platform.

Policy Decision Point (PDP): The component in the TCG TNC Architecture that evaluates the status of a TNC Client (seeking network connectivity) and decides upon some network-related action to be enforced by the Policy Enforcement Point (PEP). The PDP embodies the security and integrity related policies governing the network.

Policy Enforcement Point (PEP): The component in the TCG TNC Architecture that controls access to a protected network, whose policies are implemented through a Policy Decision Point (PDP). The PEP enforces the decisions of the PDP.