![](https://csdnimg.cn/release/download_crawler_static/88069531/bg7.jpg)
1 Introduction
1.1 Scope and Audience
The Trusted Network Connect Work Group (TNCWG) is defining an open solution architecture that
enables network operators to enforce policies regarding endpoint integrity when granting access to
a network infrastructure. Integrity measurements are carried between the TNC Client and TNC
Server on a protocol called IF-TNCCS (Trusted Network Connect Client-Server), as shown in figure
1 below.
AR PEP
Integrity Measurement
Verifiers
Integrity Measurement
Verifiers
Integrity Measurement
Collector
Integrity Measurement
Collector
Integrity Measurement
Collectors
Integrity Measurement
Verifiers
IF-IMC IF-IMV
TNC
Client
Network Access
Requestor
Policy Enforcement
Point
Network Access
Authority
TNC
Server
IF-TNCCS
PDP
Supplicant/
VPN Client, etc.
Switch/
Firewall/
VPN Gateway
IF-M
Integrity
Collection
Layer
Integrity
Evaluation
Layer
Network
Access
Layer
IF-T
IF-PEP
AAA Server
Figure 1 - TNC Architecture
This specification is integral to the Trusted Computing Group’s Trusted Network Connect (TNC)
reference architecture. Specifically, this specification defines the IF-TNCCS protocol, which is used
to communicate integrity measurements between a TNC Client and a TNC Server.
Architects, designers, developers, and technologists interested in the development, deployment,
and interoperation of trusted systems will find this document necessary in providing a specific
mechanism for communicating integrity information.
Before reading this document any further, the reader should review and understand the TNC
architecture as described in [1]. If the reader is building a TNC Client that supports IF-IMC, the
reader is encouraged to read [6] prior to reading this document. If the reader is building a TNC
Server that supports IF-IMV, the reader is encouraged to read [7] prior to reading this document.
1.2 Keywords
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in RFC 2119 [2]. This specification does not distinguish blocks of
informative comments and normative requirements. Therefore, for the sake of clarity, note that
lower case instances of must, should, etc. do not indicate normative requirements.