![](https://csdnimg.cn/release/download_crawler_static/88069523/bg6.jpg)
Clientless Endpoint Support Profile TCG Copyright
Specification Version 1.0
Revision 14 Published Page 6 of 31
TCG PUBLISHED
1 Introduction
1.1 Scope and Audience
The Trusted Network Communications Work Group (TNC) defines an open solution architecture
that enables network operators to enforce policies regarding endpoint integrity when granting
access to a network infrastructure. Today's networks contain many "clientless endpoints", legacy
devices that do not have a functional TNC client and therefore do not support integrity checking. In
the absence of standards addressing clientless endpoints, every vendor may handle them in a
different manner, negating the interoperability provided by TNC and causing situations where one
vendor's Policy Enforcement Point (PEP) only works with that vendor's Policy Decision Point (PDP)
because of different ways in which clientless endpoints are handled.
In addition to these compatibility problems, clientless endpoints represent a security risk in many
environments because of the lack of identity and integrity information provided by the client.
Mechanisms such as RADIUS-based MAC authentication and Link Layer Discovery Protocol
(LLDP) can help classify clientless endpoints by function for authorization purposes; IF-MAP
enables a standard way to achieve much greater security than previously available for clientless
endpoints by incorporating information such as behavior, provisioning, etc. to infer an endpoint's
integrity. The Clientless Endpoint Support Profile (CESP) specifies how PEPs, PDPs, and other
TNC entities should handle clientless endpoints to ensure interoperability and enforce compliance
in environments where endpoints lack a TNC client.
This specification is integral to the TCG Trusted Network Communications Work Group’s (TNC)
reference architecture. Specifically, this specification defines a Clientless Endpoint Support Profile,
which is used to perform assessment and make access control decisions in the absence of a TNC
client on the endpoint.
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 assessing endpoints without a TNC client. Before reading this document any further,
the reader should review and understand the TNC architecture as described in [1]. To understand
this specification, the reader should review and understand the TNC IF-MAP Binding for SOAP [4].
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.