Network Working Group P. Sangster
Internet Draft Symantec Corporation
Intended status: Proposed Standard K. Narayan
Expires: April 2010 Cisco Systems
October 22, 2009
PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC
draft-ietf-nea-pa-tnc-06.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79. This document may
contain material from IETF Documents or IETF Contributions
published or made publicly available before November 10, 2008.
The person(s) controlling the copyright in some of this material
may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards
Process. Without obtaining an adequate license from the
person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process,
and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC
or to translate it into languages other than English.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 22, 2009.
Copyright Notice
Sangster & Narayan Expires April 22, 2010 [Page 1]
Internet-Draft PA-TNC October 2009
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-
info). Please review these documents carefully, as they describe
your rights and restrictions with respect to this document.
Abstract
This document specifies PA-TNC, a Posture Attribute Protocol
identical to the Trusted Computing Group's IF-M 1.0 protocol.
The document then evaluates PA-TNC against the requirements
defined in the NEA Requirements specification.
Table of Contents
1. Introduction...................................................5
1.1. Prerequisites.............................................5
1.2. Message Diagram Conventions...............................5
1.3. Conventions Used in this Document.........................5
2. Design Considerations..........................................5
2.1. Standard Attribute Namespace for Interoperability.........6
2.2. Vendor Defined Namespace for Differentiation and Agility..6
2.3. Use of TLV Based Encoding for Efficiency..................7
3. PA-TNC Message Protocol........................................8
3.1. PA-TNC Messaging Model....................................8
3.2. PA-TNC Relationship to PB-TNC.............................9
3.3. PB-PA Posture Collector and Posture Validator Identifiers11
3.4. PA-TNC Messages in PB-TNC................................12
3.5. IETF Standard PA Subtypes................................12
3.6. PA-TNC Message Header Format.............................14
4. PA-TNC Attributes.............................................15
4.1. PA-TNC Attribute Header..................................15
4.2. IETF Standard PA-TNC Attribute Types.....................19
4.2.1. Attribute Request...................................20
4.2.2. Product Information.................................23
4.2.3. Numeric Version.....................................25
4.2.4. String Version......................................27
4.2.5. Operational Status..................................29
4.2.6. Port Filter.........................................32
4.2.7. Installed Packages..................................34
4.2.8. PA-TNC Error........................................37
4.2.8.1. Invalid Parameter Error Code...................39
4.2.8.2. Version Not Supported Error Code...............41
4.2.8.3. Attribute Type Not Supported Error Code........42
Sangster & Narayan Expires April 22, 2010 [Page 2]
Internet-Draft PA-TNC October 2009
4.2.9. Assessment Result...................................44
4.2.10. Remediation Instructions...........................45
4.2.10.1. Remediation URI Parameters....................47
4.2.10.2. Remediation String Parameters Type............48
4.2.11. Forwarding Enabled.................................49
4.2.12. Factory Default Password Enabled...................50
4.3. Vendor-Defined Attributes................................52
5. Security Considerations.......................................52
5.1. Trust Relationships......................................52
5.1.1. Posture Collector...................................53
5.1.2. Posture Validator...................................53
5.1.3. Posture Broker Client, Posture Broker Server........53
5.2. Security Threats.........................................54
5.2.1. Attribute Theft.....................................54
5.2.2. Message Fabrication.................................55
5.2.3. Attribute Modification..............................56
5.2.4. Attribute Replay....................................56
5.2.5. Attribute Insertion.................................57
5.2.6. Denial of Service...................................57
6. Privacy Considerations........................................57
7. IANA Considerations...........................................59
7.1. Designated Expert Guidelines.............................60
7.2. PA Subtypes..............................................60
7.3. Registry for PA-TNC Attribute Types......................61
7.4. Registry for PA-TNC Error Codes..........................62
7.5. Registry for PA-TNC Remediation Parameters Types.........63
8. Acknowledgments...............................................63
9. References....................................................64
9.1. Normative References.....................................64
9.2. Informative References...................................64
Appendix A: Use Cases............................................64
A.1. Initial Client triggered assessment......................64
A.1.1. Message Contents....................................65
A.1.1.1. N/W Join.......................................66
A.1.1.2. Request Posture (Req Post.)....................66
A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)...66
A.1.1.4. OS Posture.....................................66
A.1.1.5. Posture Report.................................67
A.1.1.6. Verify Posture.................................67
A.1.1.7. OS Posture Result (OS Reslt)...................67
A.1.1.8. Vendor X Patch Result (VndrX Patch Result).....68
A.1.1.9. Assessment Result (Assess Result)..............68
A.1.1.10. Posture Result (OS PRslt & Vndr X Post
PResult)......................................68
A.2. Server initiated Assessment with Remediation.............68
A.2.1. Message Contents....................................70
A.2.1.1. N/W Join.......................................70
A.2.1.2. Create Posture Request (Create Posture Req.)...70
Sangster & Narayan Expires April 22, 2010 [Page 3]
Internet-Draft PA-TNC October 2009
A.2.1.3. Vendor Y AV Posture Request (Vndr Y AV Posture
Req)...........................................70
A.2.1.4. Vendor X AV Posture Request (Vndr X AV Post.
Req)...........................................71
A.2.1.5. Posture Request................................71
A.2.1.6. Posture Request (Vndr X AV Post Req & Vndr Y AV
Post Req)......................................71
A.2.1.7. Vendor Y AV Posture (Vndr Y AV Posture)........71
A.2.1.8. Vendor X AV Posture (Vndr X AV Posture)........72
A.2.1.9. Posture Response...............................73
A.2.1.10. Verify Posture................................73
A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post
Result).......................................73
A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post
Reslt)........................................73
A.2.1.13. Assessment Result (Assess Result).............74
A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y
AV Post Reslt)................................74
A.3. Client triggered re-assessment...........................74
A.3.1. Message Contents....................................75
A.3.1.1. Enable VPN Client (Enble)......................76
A.3.1.2. Notify Status Change (VPN Status Change).......76
A.3.1.3. Notify Posture Change (Posture Change).........76
A.3.1.4. Request Posture (Req. Post)....................76
A.3.1.5. Inspect/Request Info (Ins/Rq Info).............76
A.3.1.6. Vendor X VPN Posture (VPNX Post)...............76
A.3.1.7. Vendor Y VPN Posture (VPNY Post)...............77
A.3.1.8. Posture Report.................................78
A.3.1.9. Verify Posture (Vrfy Post.)....................78
A.3.1.10. VPN Posture Result (VPN PRslt)................78
A.3.1.11. Assessment Result (Assess Result).............78
A.3.1.12. Posture Result (VPN PRslt)....................78
B.1. Evaluation Against Requirements C-1......................79
B.2. Evaluation Against Requirements C-2......................79
B.3. Evaluation Against Requirements C-3......................79
B.4. Evaluation Against Requirements C-4......................80
B.5. Evaluation Against Requirements C-5......................80
B.6. Evaluation Against Requirements C-6......................80
B.7. Evaluation Against Requirements C-7......................81
B.8. Evaluation Against Requirements C-8......................81
B.9. Evaluation Against Requirements C-9......................81
B.10. Evaluation Against Requirements C-10....................82
B.11. Evaluation Against Requirements C-11....................82
B.12. Evaluation Against Requirements PA-1....................83
B.13. Evaluation Against Requirements PA-2....................83
B.14. Evaluation Against Requirements PA-3....................84
B.15. Evaluation Against Requirements PA-4....................84
B.16. Evaluation Against Requirements PA-5....................84
Sangster & Narayan Expires April 22, 2010 [Page 4]
Internet-Draft PA-TNC October 2009
B.17. Evaluation Against Requirements PA-6....................85
Authors' Addresses...............................................86
1. Introduction
This document specifies PA-TNC, a Posture Attribute Protocol
(PA) identical to the Trusted Computing Group's IF-M 1.0
protocol [8]. The document then evaluates PA-TNC against the
requirements defined in the NEA Requirements specification [9].
1.1. Prerequisites
This document does not define an architecture or reference
model. Instead, it defines a protocol that works within the
reference model described in the NEA Overview and Requirements
specification. The reader is assumed to be thoroughly familiar
with that document. No familiarity with TCG specifications is
assumed.
1.2. Message Diagram Conventions
This specification defines the syntax of PA-TNC messages using
diagrams. Each diagram depicts the format and size of each
field in bits. Implementations MUST send the bits in each
diagram as they are shown, traversing the diagram from top to
bottom and then from left to right within each line (which
represents a 32-bit quantity). Multi-byte fields representing
numeric values must be sent in network (big endian) byte order.
Descriptions of bit field (e.g. flag) values are described
referring to the position of the bit within the field. These
bit positions are numbered from the most significant bit through
the least significant bit so a one octet field with only bit 0
set has the value 0x80.
1.3. Conventions Used in this Document
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 [1].
2. Design Considerations
This section discusses some of the key design considerations for
the PA protocol.
Sangster & Narayan Expires April 22, 2010 [Page 5]
Internet-Draft PA-TNC October 2009
2.1. Standard Attribute Namespace for Interoperability
The PA protocol requires the use of two categories of
namespaces: component types (AKA PA Subtypes) and attributes.
Each of these namespace categories needs to contain well known,
interoperable names with defined syntax and semantics co-
existing with names for vendor defined private extensions.
Similarly, each namespace category needs to be readily
extensible without repeated coordination yet avoids naming
conflicts.
The PA-TNC and PB-TNC protocols provide for multiple orthogonal
namespaces for each category that exist without overlap by
including a SMI Private Enterprise Number (PEN) field to
identify the definer of namespace of the associated field. This
allows the IETF NEA WG to define a set of standard component
types and attribute types while allowing vendors to each create
additional names outside of the IETF standard namespace. Over
time, vendor defined names might be proposed for standardization
and thus migration into the IETF namespace.
The PB-TNC protocol defines an IETF standard namespace (using
vendor-id=0) that allows for definition of standard component
types (e.g. Operating System, Firewall, Anti-Virus) using the PA
Subtype field (see section 3.2). Similarly, PA-TNC defines a
set of standard attributes in section 4.2 that represent the
most common capabilities (attributes) of these types of
components across a variety of vendor implementations. The
standard namespace allows NEA deployments with both open source
and vendor provided NEA implementations to support a consistent
set of policies across their environment based on these standard
attributes. The standard attributes can be used with a variety
of endpoints (hosts, printers, mobile devices) that are running
applications and operating systems (defined by the PA Subtypes)
from a variety of vendors.
2.2. Vendor Defined Namespace for Differentiation and Agility
The endpoint is a very dynamic environment in terms of rate of
new features being deployed and attacks that are crafted against
existing and new applications such as: viruses, worms, malware,
and spyware. It is difficult to imagine the standard namespaces
to being able to keep pace with this rapidly changing
environment. Vendors typically differentiate themselves by
moving rapidly to provide unique mechanisms to address such
threats and their ability to deal with changes in an agile
manner. The PA-TNC and PB-TNC protocols allows for creation of
Sangster & Narayan Expires April 22, 2010 [Page 6]
Internet-Draft PA-TNC October 2009
vendor defined namespace(s) where each namespace allows use of
vendor defined PA Subtypes to identify non-standard applications
or operating system variants and vendor defined attributes
describing new aspects of each type of component. The vendor
namespaces will allow NEA deployments to craft compliance
policies using a mixture of attributes from both the IETF
standard namespace and vendor defined namespaces that may
include multiple vendors representing the various hardware and
software components present on the endpoints.
The PA-TNC protocol's use of vendor-id to identify the namespace
of each attribute allows Posture Collectors to support some or
all of the IETF standard attributes plus optionally a set of
vendor defined attributes (potentially from more then one
vendor-id namespace). For instance, an open source anti-virus
Posture Collector might be written that supports all of the IETF
standard attributes used to describe a local anti-virus
component and a subset of multiple anti-virus manufacturers'
vendor defined attributes. This Posture Collector might
therefore be able to interoperate with Posture Validators from
multiple vendors. Conversely, a simple Posture Collector might
be written to ignore any vendor defined attributes requested and
only return standard attributes that it supports. If the vendor
provided Posture Validator's policy allows for this subset to be
considered compliant, then these simple Posture Collectors can
be used to perform a successful assessment.
2.3. Use of TLV Based Encoding for Efficiency
The PA-TNC protocol has chosen to employ a binary encoding using
a type-length-value (TLV) structure. TLV encoding was preferred
over the use of a textual encoding format such as XML to provide
a more efficient utilization of the potentially constrained
bandwidth available between the NEA Client and NEA Server (see
NEA Overview and Architecture [9]). Efficiency was a primary
criterion for this choice with consideration given to both:
1. Optimization of the bits-on-the-wire to accommodate NEA
requirements for assessment over low bandwidth or high
latency links (C-8) and allow for the PT protocol to run
over existing network access protocols (PT-4, C-11) that
are constrained by packet size.
2. Optimization of CPU utilization on the endpoint to
accommodate for low power endpoints such as mobile devices.
Sangster & Narayan Expires April 22, 2010 [Page 7]
Internet-Draft PA-TNC October 2009
The choice of TLV encoding does not preclude the use of XML-
based attribute values within the vendor namespaces or future
standard attributes. It is conceivable that certain vendors may
utilize XML encoding for extensibility within their namespace
when the above considerations are less applicable to their
technologies. Attributes encoded within the vendor defined
namespace using alternate encoding such as XML will be opaque to
NEA software only supporting standard attributes and will be
processed primarily by the vendor defined components
(collector/validator).
3. PA-TNC Message Protocol
This section discusses the use of the PA-TNC message and its
attributes, and specifies the syntax and semantics for the PA-
TNC message header. The details of each attribute included
within the PA-TNC payload are specified in section 4.2.
3.1. PA-TNC Messaging Model
PA-TNC messages are carried by the PB-TNC protocol [5], which
provides a multi-roundtrip reliable transport and end-to-end
message delivery to subscribed (interested) parties using a
variety of underlying network protocols. PA-TNC is unaware of
these underlying PT transport protocols being used below PB-TNC.
The interested parties consist of Posture Collectors on the NEA
Client and Posture Validators associated with the NEA Server
that have registered to receive messages about particular types
of components (e.g. anti-virus) during an assessment. The PA-
TNC messaging protocol operates synchronously within an
assessment session, with Posture Collectors and Posture
Validators taking turns sending one or more messages to each
other. Each PA-TNC message may contain one or more attributes
associated with the functional component identified in the
component type (PA Subtype) of the PB protocol.
Posture Collectors may only send PA-TNC messages to Posture
Validators and vice versa. No Posture Collector to Posture
Collector or Posture Validator to Posture Validator messaging is
allowed to occur. Each Posture Collector or Posture Validator
may send several PA-TNC messages in succession before indicating
that it has completed its batch of messages to the Posture
Broker Client or Posture Broker Server respectively. As
necessary, the Posture Broker Client and Posture Broker Server
will batch these messages prior to sending them over the
network.
Sangster & Narayan Expires April 22, 2010 [Page 8]
Internet-Draft PA-TNC October 2009
PB-TNC provides a publish/subscribe model of message exchange.
This means that, at any given point in time, zero or more
subscribers for a particular type of message may be present on a
Posture Broker Client or Posture Broker Server. This is
beneficial, since it allows one Posture Collector or Posture
Validator to combine multiple functions (like anti-virus and
personal firewall) by subscribing to both TNC standard component
types. It also allows multiple Posture Collectors or Posture
Validators to support the same components, such as two anti-
virus Posture Validators that are each used to manage their own
respective anti-virus client software.
However, this publish/subscribe model has some possible negative
side effects. When a Posture Collector or Posture Validator
initially sends a PA-TNC message, it does not know whether it
will receive many, one, or no PA-TNC messages from the other
side. For many types of assessments, this is acceptable, but in
some cases a more direct channel binding between a particular
Posture Collector and Posture Validator pair is necessary. For
example, a Posture Validator may wish to provide remediation
instructions to a particular Posture Collector that it knows is
capable of remediating a non-compliant component. This can be
accomplished using the exclusive delivery PB-TNC capability to
limit distribution of a message to a single Posture Collector by
including the target Posture Collector Identifier in the PB-PA
header. For more information on the PB-PA header, see section
4.5 of the PB-TNC specification.
3.2. PA-TNC Relationship to PB-TNC
This section summarizes the major elements of a PA-TNC message
as they might appear inside of a PB-TNC message. The double
line (===) in the diagram below indicates the separation between
the PB-TNC and PA-TNC protocols. The PA-TNC portion of the
message is delivered to each Posture Collector or Posture
Validator registered to receive messages containing a particular
message type. Note that PB-TNC is capable of carrying multiple
PB-TNC and PA-TNC messages in a single PB-TNC batch. See the
PB-TNC specification [5] for more information on its
capabilities.
One important linkage between the PA-TNC and PB-TNC protocols is
the PA message type (PA Message Vendor ID and PA Subtype) that
is used by the Posture Broker Client and Posture Broker Server
to route messages to interested Posture Collectors and Posture
Validators. The message type indicates the software component
(component type) that is associated with the attributes included
Sangster & Narayan Expires April 22, 2010 [Page 9]
Internet-Draft PA-TNC October 2009
inside the PA-TNC message. Therefore, Posture Collectors and
Posture Validators written to support an assessment of a
particular component can register to receive messages about the
component and thus participate in its assessment. Each Posture
Collector and Posture Validator MUST only send PA-TNC messages
containing attributes that pertain to the software component
defined in the message type of the message. This ensures that
only the appropriate Posture Collectors and Posture Validators
that support a particular type of component will receive
attributes related to that component. If a PA-TNC message
contained a mix of attributes about different components and a
message type of only one of those components, the message would
only be delivered to parties interested in the component type
included in the message type, so other interested recipients
wouldn't see those attributes.
The message type is comprised of 2 fields: a PA Message Vendor
ID and a PA Subtype. The PA Message Vendor ID identifies the
vendor or other organization that defined this message type.
The PA Subtype identifies the message type more specifically
within the set of message types defined by that vendor. This
specification defines several IETF Standard PA Subtypes to be
used with a PA Message Vendor ID of zero (0). Within this
specification, the PA Subtype field is used to indicate the type
of component (e.g. firewall) involved with the message's
attributes. Therefore for clarity the PA subtype will be
referred to as the "component type" in this specification.
Vendor-defined name spaces may use other semantics for the PA
Subtype field as this is outside the scope of this
specification.
Sangster & Narayan Expires April 22, 2010 [Page 10]
Internet-Draft PA-TNC October 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message of type PB-PA-Message |
|(includes: PA Message Vendor ID, PA Subtype, and other fields|
| used by Posture Broker Client and Posture Broker Server for |
| routing) |
===============================================================
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g. Product Information) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g. Operational Status) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Overview of a PB-TNC batch that contains a PA-TNC
Message
For example, if a Posture Broker Client sent a PB-TNC batch that
contained a PA-TNC message with a message type indicating
firewall component, this message would be routed by the Posture
Broker Server to Posture Validators registered to assess
firewalls. Each registered Posture Validator would receive a
copy of the PA-TNC message including the PA-TNC header and set
of attributes. It is important that each of the attributes
included in the PA-TNC message be associated with the firewall
component because only the Posture Collector and Posture
Validator interested in firewalls will receive such messages.
If the above message contained both firewall and operating
system attributes inside a PA-TNC message with a component type
of firewall, then any Posture Collector and Posture Validator
registered to receive operating system messages would not
receive those attributes, as the messages would only be
delivered to those registered for firewall messages.
3.3. PB-PA Posture Collector and Posture Validator Identifiers
The PB-PA header contains several fields important to the
processing of a received PA message. The PA Vendor ID and
Subtype are described in the PB-TNC specification and above in
section 3.2. Also present in the PB-PA header is a pair of
fields that identify the Posture Collector and/or Posture
Validator involved in the exchange. These fields are used for
Sangster & Narayan Expires April 22, 2010 [Page 11]
Internet-Draft PA-TNC October 2009
performing exclusive delivery of messages as described in
section 3.1 and as an indicator for correlation of received
attributes.
Correlation of attributes is necessary when the sending Posture
Collector provides posture for multiple implementations of a
single type of component during an assessment, so the recipient
Posture Validators need to know which attributes are describing
the same implementation.
For example, a single Posture Collector might report attributes
on two installed VPN implementations on the endpoint. Because
the individual attributes do not include an indication of which
VPN product they are describing, the recipient needs something
to perform this correlation. Therefore, for this example, the
VPN Posture Collector would need to obtain two Posture Collector
Identifiers from the Posture Broker Client and consistently use
one with each of the implementations during an assessment. The
VPN Posture Collector would group all the attributes associated
with a particular VPN implementation into a single PB-PA message
and send the message using the Posture Collector Identifier it
designates as going with the particular implementation. This
approach allows the recipient to recognize when attributes in
future assessment messages also describe the same component
implementation.
3.4. PA-TNC Messages in PB-TNC
As depicted in section 3.2, a PA-TNC message consists of a PA-
TNC header followed by a sequence of one or more attributes.
The PA-TNC message header (described in section 3.6) and the
header for each of the PA-TNC attributes (specified in section
4.1) have a fixed type-length-value (TLV) format. Each PA-TNC
message MAY contain a mixture of standards-based and vendor-
defined attributes identifiable using the type portion of the
attribute header. All Posture Collectors and Posture Validators
compliant with this specification MUST be capable of processing
multiple attributes in a received PA-TNC message. A Posture
Collector or Posture Validator that receives a PA-TNC message
can use the attribute header's length field to skip any
attributes that it does not understand, unless the attribute is
marked as mandatory to process.
3.5. IETF Standard PA Subtypes
This section defines several IETF Standard PA Subtypes. Each PA
subtype defined here identifies a specific component relevant to
Sangster & Narayan Expires April 22, 2010 [Page 12]
Internet-Draft PA-TNC October 2009
the endpoint's posture. This allows a small set of generic PA-
TNC attributes (e.g. Product Information) to be used to describe
a large number of different components (e.g. operating system,
anti-virus, etc.). It also allows Posture Collectors and
Posture Validators to specialize in a particular component and
only receive PA-TNC messages relevant to that component.
Value Name Definition
----- ---- ----------
0 Testing Reserved for use in specification
examples, experimentation and
testing.
1 Operating System Operating system running on the
endpoint
2 Anti-Virus Host-based anti-virus software
3 Anti-Spyware Host-based anti-spyware software
4 Anti-Malware Host-based anti-malware (e.g. anti-
bot) software not included within
anti-virus or anti-spyware components
5 Firewall Host-based firewall
6 IDPS Host-based Intrusion Detection and/or
Prevention Software (IDPS)
7 VPN Host-based Virtual Private Networking
(VPN) software
8 NEA Client NEA client software
These PA subtypes must be used in a PB-PA message with a PA
Message Vendor ID of zero (0) indicating an IETF standard type
of component (as described in the PB-TNC specification [5]). If
these PA subtype values are used with a different PA Message
Vendor ID, they have a completely different meaning that is not
defined in this specification. Posture Collectors and Posture
Validators MUST NOT require support for particular vendor-
specific PA subtypes and MUST interoperate with other parties
despite any differences in the set of vendor-specific PA
subtypes supported (although they MAY permit administrators to
configure them to require support for specific PA subtypes).
Sangster & Narayan Expires April 22, 2010 [Page 13]
Internet-Draft PA-TNC October 2009
3.6. PA-TNC Message Header Format
This section describes the format and semantics of the PA-TNC
header. Every PA-TNC message MUST start with a PA-TNC header.
The PA-TNC header provides a common context applying to all of
the attributes contained within the PA-TNC payload. The payload
consists of a sequence of assessment attributes described in
section 4.2.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
This field indicates the version of the format for the PA-TNC
message. This version is intended to allow for evolution of
the PA-TNC message header and payload in a manner that can
easily be detected by message recipients.
PA-TNC message senders MUST set this field to 0x01 for all
PA-TNC messages that comply with this specification.
Implementations responding to a PA-TNC message containing a
supported version MUST use the same Version number to
minimize the risk of version incompatibility. Message
recipients MUST respond to a PA-TNC message containing an
unsupported version by sending a Version Not Supported error
in a PA-TNC Error attribute that is the only PA-TNC attribute
in a PA-TNC message with version number 1.
PA-TNC message initiators supporting multiple PA-TNC protocol
versions SHOULD be able to alter which version of PA-TNC
message they send based on prior message exchanges with a
particular peer Posture Collector or Posture Validator.
Reserved
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
Message Identifier
Sangster & Narayan Expires April 22, 2010 [Page 14]
Internet-Draft PA-TNC October 2009
This field contains a value that uniquely identifies this
message, differentiating it from others sent by a particular
PA-TNC message sender within this assessment. This value can
be included in the payload of a response message to indicate
which message was received and caused the response. This
value is included in the payload of PA-TNC error messages so
the party who receives the error message can determine which
of the messages they had sent caused the error.
PA-TNC message senders MUST NOT send the same message
identifier more than once during an assessment. Message
identifiers may be randomly generated or sequenced as long as
values are not repeated during an assessment message
exchange. PA-TNC message recipients are not required to
check for duplicate message identifiers.
4. PA-TNC Attributes
This section defines the PA-TNC attributes that can be carried
within a PA-TNC message. The initial section defines the
standard attribute header that appears at the start of each
attribute in a PA-TNC message. The second section defines each
of the IETF Standard PA-TNC attributes and the final section
discusses how vendor-defined PA-TNC attributes can be used
within a PA-TNC message. Vendor-defined PA-TNC attributes use
the vendor's SMI Private Enterprise Number in the Attribute Type
field.
A PA-TNC message MUST contain a PA-TNC header (defined in
section 3.6. followed by a sequence of zero or more PA-TNC
attributes. All PA-TNC attributes MUST begin with a standard
PA-TNC attribute header, as defined in section 4.1. The
contents of PA-TNC attributes vary widely, depending on their
attribute type. Section 4.2 defines the IETF Standard PA-TNC
Attributes. Section 4.3 discusses how vendor-specific PA-TNC
attributes can be defined.
4.1. PA-TNC Attribute Header
Following the PA-TNC message header is a sequence of zero or
more attributes. All PA-TNC attributes MUST begin with the
standard PA-TNC attribute header defined in this subsection.
Each attribute described in this specification is represented by
a TLV tuple. The TLV tuple includes an attribute identifier
comprised of the Vendor ID and Attribute Type (type), the TLV
tuple's overall length and finally the attribute's value. The
use of TLV representation was chosen due to its flexibility and
Sangster & Narayan Expires April 22, 2010 [Page 15]
Internet-Draft PA-TNC October 2009
extensibility and use in other standards. Recipients of an
attribute can use the attribute type fields to determine the
precise syntax and semantics of the attribute value field and
the length to skip over an unrecognized attribute. The length
field is also beneficial when a variable length attribute value
is provided.
The TLV format does not contain an explicit TLV format version
number, so every attribute included in a particular PA-TNC
message MUST use the same TLV format. Using the PA-TNC message
version number to indicate the format of all TLV attributes
within a PA-TNC message allows for future versioning of the TLV
format in a manner detectable by PA-TNC message recipients.
Similarly, requiring all TLV attribute formats to be the same
within a PA-TNC message also assures that recipients compliant
with a particular PA-TNC message version can at least parse
every attribute header and use the length to skip over
unrecognized attributes. Finally all attribute TLVs within a
PA-TNC message MUST pertain to the same implementation of the
component. This restriction is relevant when a single Posture
Collector is reporting on multiple implementations of a
component, so must send multiple PA-TNC messages each including
only the attributes describing a single implementation. For
more information on how Posture Collectors should handle
multiple implementations see section 3.3.
Every PA-TNC compliant TLV attribute MUST use the following TLV
format:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
This field defines flags impacting the processing of the
associated attribute.
Sangster & Narayan Expires April 22, 2010 [Page 16]
Internet-Draft PA-TNC October 2009
Bit 0 (0x80) is the NOSKIP flag. Any Posture Collector or
Posture Validator that receives an attribute with this flag
set to 1 but does not support this attribute MUST NOT process
any part of the PA-TNC message and SHOULD respond with an
Attribute Type Not Supported error in a PA-TNC error message.
In order to avoid taking action on a subset of the attributes
only to later find an unsupported attribute with the NOSKIP
flag set, recipients of a multi-attribute PA-TNC message
might need to scan all of the attributes prior to acting upon
any attribute.
When the NOSKIP flag is set to 0, recipients SHOULD skip any
unsupported attributes and continue processing the next
attribute.
Bit 1-7 are reserved for future use. These bits MUST be set
to 0 on transmission and ignored upon reception.
PA-TNC Attribute Vendor ID
This field indicates the owner of the name space associated
with the PA-TNC Attribute Type. This is accomplished by
specifying the 24 bit SMI Private Enterprise Number Vendor ID
of the party who owns the Attribute Type name space. IETF
Standard PA-TNC Attribute Types MUST use zero (0) in this
field.
The PA-TNC Attribute Vendor ID 0xffffff is reserved. Posture
Collectors and Posture Validators MUST NOT send PA-TNC
messages in which the PA-TNC Attribute Vendor ID has this
reserved value (0xffffff). If a Posture Collector or Posture
Validator receives a message in which the PA-TNC Attribute
Vendor ID has this reserved value (0xffffff), it SHOULD
respond with an Invalid Parameter error code in a PA-TNC
Error attribute.
PA-TNC Attribute Type
This field defines the type of the attribute included in the
Attribute Value field. This field is qualified by the PA-TNC
Attribute Vendor ID field so that a particular PA-TNC
Attribute Type value (e.g. 327) has a completely different
meaning depending on the value in the PA-TNC Attribute Vendor
ID field. Posture Collectors and Posture Validators MUST NOT
require support for particular vendor-specific PA-TNC
Attribute Types and MUST interoperate with other parties
Sangster & Narayan Expires April 22, 2010 [Page 17]
Internet-Draft PA-TNC October 2009
despite any differences in the set of vendor-specific PA-TNC
Attribute Types supported (although they MAY permit
administrators to configure them to require support for
specific PA-TNC attribute types).
If the PA-TNC Attribute Vendor ID field has the value zero
(0) then the PA-TNC Attribute Type field contains an IETF
Standard PA-TNC Attribute Type, as listed in the IANA
registry. IANA maintains a registry of PA-TNC Attribute
Types. Entries in this registry are added by Expert Review
with Specification Required, following the guidelines in
section 7. Section 4.2 of this specification defines the
initial set of IETF Standard PA-TNC Attribute Types.
The PA-TNC Attribute Type 0xffffffff is reserved. Posture
Collectors and Posture Validators MUST NOT send PA-TNC
messages in which the PA-TNC Attribute Type has this reserved
value (0xffffffff). If a Posture Collector or Posture
Validator receives a message in which the PA-TNC Attribute
Type has this reserved value (0xffffffff), it SHOULD respond
with an Invalid Parameter error code in a PA-TNC Error
attribute.
PA-TNC Attribute Length
This field contains the length in octets of the entire PA-TNC
Attribute including the PA-TNC Attribute Header (the fields
Flags, PA-TNC Attribute Vendor ID, PA-TNC Attribute Type, and
PA-TNC Attribute Length). Therefore, this value MUST always
be at least 12. Any Posture Collector or Posture Validator
that receives a message with a PA-TNC Attribute Length field
whose value is less than 12 SHOULD respond with an Invalid
Parameter PA-TNC error code. Similarly, if a Posture
Collector or Posture Validator receives a PA-TNC message for
an Attribute Type that has a well known Attribute Value
length (e.g. fixed length attribute value) and the Attribute
Length indicates a different value (greater or less than the
expected value), the recipient SHOULD respond with an Invalid
Parameter PA-TNC error code.
Implementations that do not support the specified PA-TNC
Attribute Type can use this length to skip over this
attribute to the next attribute. Note that while this field
is 4 octets the maximum usable attribute length is less than
2^32-1 due to limitations of the underlying protocol stack.
Specifically PB-TNC TLV header's Batch Length field is also
32 bits in length. Therefore the maximum batch that PB-TNC
Sangster & Narayan Expires April 22, 2010 [Page 18]
Internet-Draft PA-TNC October 2009
can carry is 2^32-1, so the largest PA-TNC message carried by
PB-TNC must be less than 2^32-1 - size of the PB-TNC header
(see section 4.1 of PB-TNC for more details).
Attribute Value
This field varies depending on the particular type of
attribute being expressed. The contents of this field for
each of the IETF Standard PA-TNC Attribute Types are defined
in section 4.2.
4.2. IETF Standard PA-TNC Attribute Types
This section defines an initial set of IETF Standard PA-TNC
Attribute Types. These Attribute Types MUST always be used with
a PA-TNC Vendor ID of zero (0). If these PA-TNC Attribute Type
values are used with a different PA-TNC Vendor ID, they have a
completely different meaning that is not defined in this
specification.
The following table briefly describes each attribute and defines
the numeric value to be used in the PA-TNC Attribute Type field
of the PA-TNC Attribute Header. Later subsections provide
detailed specifications for each PA-TNC Attribute Value.
Number Name Description
------ ---- -----------
0 Testing Reserved for use in
specification examples,
experimentation and testing.
1 Attribute Request Contains a list of attribute
type values defining the
attributes desired from the
Posture Collectors.
2 Product Information Manufacturer and product
information for the component.
3 Numeric Version Numeric version of the
component.
4 String Version String version of the
component.
5 Operational Status Describes whether the component
is running on the endpoint.
Sangster & Narayan Expires April 22, 2010 [Page 19]
Internet-Draft PA-TNC October 2009
6 Port Filter Lists the set of ports (e.g.
TCP port 80 for HTTP) that are
allowed or blocked on the
endpoint.
7 Installed Packages List of software packages
installed on endpoint that
provide the requested
component.
8 PA-TNC Error PA-TNC message or attribute
processing error.
9 Assessment Result Result of the assessment
performed by a Posture
Validator.
10 Remediation Instructions Instructions for remediation
generated by a Posture
Validator.
11 Forwarding Enabled Indicates whether packet
forwarding has been enabled
between different interfaces on
the endpoint.
12 Factory Default Password Indicates whether the endpoint
has a factory default password
enabled.
The following subsections discuss the usage, format and semantics
of the Attribute Value field for each IETF Standard PA-TNC
Attribute Type.
4.2.1. Attribute Request
This PA-TNC Attribute Type allows a Posture Validator to request
certain attributes from the registered set of Posture
Collectors.
All Posture Collectors that implement any of the IETF Standard
PA Subtypes defined in this specification SHOULD support
receiving and processing this attribute type for at least those
PA subtypes. This requirement is only a "should" because there
are deployment scenarios (e.g. see section A.1) where the
Sangster & Narayan Expires April 22, 2010 [Page 20]
Internet-Draft PA-TNC October 2009
Posture Collectors proactively sends a set of attributes at the
start of an assessment (e.g. based upon local policy), so does
not need to support Posture Validator requested attributes.
Posture Collectors that receive but do not support the Attribute
Request attribute MUST respond with an Attribute Type Not
Supported PA-TNC error code. Posture Collectors that receive
and process this attribute MAY choose to send all, a subset or
none of the requested attributes but MUST NOT send attributes
that were not requested (except error attributes). All Posture
Validators that implement any of the IETF Standard PA Subtypes
defined in this specification SHOULD support sending this
attribute type for at least those PA subtypes.
Posture Validators MUST NOT include this attribute type in an
Attribute Request attribute. It does not make sense for a
Posture Validator to request that a Posture Collector send an
Attribute Request attribute.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 1.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
Note that this diagram shows two attribute types. The actual
number of attribute types included in an Attribute Request
attribute can vary from one to a large number (limited only by
the maximum message and length supported by the underlying PT
transport protocol). However, each Attribute Request MUST
contain at least one attribute type. Because the length of a
PA-TNC Attribute Vendor ID paired with a PA-TNC Attribute Type
and a one octet Reserved field is always 8 octets, the number of
requested attributes can be easily computed using the PA-TNC
Attribute Length field by subtracting the number of octets in
the PA-TNC Attribute Header and dividing by 8. If the PA-TNC
Attribute Length field is invalid, Posture Collectors SHOULD
respond with an Invalid Parameter PA-TNC error code.
Sangster & Narayan Expires April 22, 2010 [Page 21]
Internet-Draft PA-TNC October 2009
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
PA-TNC Attribute Vendor ID
This field contains the SMI Private Enterprise Number of the
organization that controls the name space for the following
PA-TNC Attribute Type. This field enables IETF Standard PA-
TNC Attributes and vendor-defined PA-TNC Attributes to be
used without potential collisions.
Any IETF Standard PA-TNC Attribute Types defined in section
4.2 MUST use zero (0) in this field. Vendor-defined
attributes MUST use the SMI Private Enterprise Number of the
organization that defined the attribute.
PA-TNC Attribute Type
The PA-TNC Attribute Type field (together with the PA-TNC
Vendor ID field) indicates the specific attribute requested.
Some IETF Standard PA-TNC Attribute Types MUST NOT be
requested using this field (e.g. requesting a PA-TNC Error
attribute). This is explicitly indicated in the description
of those PA-TNC Attribute Types. Any Posture Collector or
Posture Validator that receives an Attribute Request
containing one of the prohibited Attribute Types SHOULD
respond with an Invalid Parameter error in a PA-TNC error
message.
Sangster & Narayan Expires April 22, 2010 [Page 22]
Internet-Draft PA-TNC October 2009
4.2.2. Product Information
This PA-TNC Attribute Type contains identifying information
about a product that implements the component specified in the
PA Subtype field, as described in section 3.5. For example, if
the PA Subtype is Anti-Virus, this attribute would contain
information identifying an anti-virus product installed on the
endpoint.
All Posture Collectors that implement any of the IETF Standard
PA Subtypes defined in this specification MUST support sending
this attribute type, at least for those PA subtypes. Whether a
particular Posture Collector actually sends this attribute type
SHOULD still be governed by local privacy and security policies.
All Posture Validators that implement any of the IETF Standard
PA Subtypes defined in this specification MUST support receiving
this attribute type, at least for those PA subtypes. Posture
Validators MUST NOT send this attribute type.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 2. The value in the PA-TNC Attribute Length field
will vary, depending on the length of the Product Name field.
However, the value in the PA-TNC Attribute Length field MUST be
at least 17 because this is the length of the fixed size fields
in the PA-TNC Attribute Header and the fixed size fields in this
attribute type. If the PA-TNC Attribute Length field is less
than the size of these fixed length fields, implementations
SHOULD respond with an Invalid Parameter PA-TNC error code.
This attribute type includes both numeric and textual
identifiers for the organization that created the product (the
"product creator") and for the product itself. For automated
processing, numeric identifiers are superior because they are
less ambiguous and more efficient. However, numeric identifiers
are only available if the product creator has assigned them.
Therefore, a textual identifier is also included. This textual
identifier has the additional benefit that it may be easier for
humans to read (although this benefit is minimal since the
primary purpose of this attribute is automated assessment).
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
Sangster & Narayan Expires April 22, 2010 [Page 23]
Internet-Draft PA-TNC October 2009
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product Vendor ID | Product ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product ID | Product Name (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Product Vendor ID
This field contains the SMI Private Enterprise Number for the
product creator. If the SMI PEN for the product creator is
unknown or if the product creator does not have an SMI PEN,
the Product Vendor ID field MUST be set to 0 and the identity
of the product creator SHOULD be included in the Product Name
along with the name of the product.
Product ID
This field identifies the product using a numeric identifier
assigned by the product creator. If this Product ID value is
unknown or if the product creator has not assigned such a
value, this field MUST be set to 0. If the Product Vendor ID
is 0, this field MUST be set to 0. In any case, the name of
the product SHOULD be included in the Product Name field.
Note that a particular Product ID value (e.g. 635) will have
completely different meanings depending on the Product Vendor
ID. Each Product Vendor ID defines a different space of
Product ID values. Product creators are encouraged to
publish lists of Product ID values for their products.
Product Name
This variable length field contains a UTF-8 [2] string
identifying the product (e.g. "Symantec Norton AntiVirus(TM)
2008") in enough detail to unambiguously distinguish it from
other products from the product creator. Products whose
creator is known, but does not have a registered SMI Private
Enterprise Number, SHOULD be represented using a combination
of the creator name and full product name (e.g. "Ubuntu(R)
IPtables" for the IPtables firewall in the Ubuntu
distribution of Linux). If the product creator's SMI Private
Enterprise Number is included in the Product Vendor ID field,
the product creator's name may be omitted from this field.
Sangster & Narayan Expires April 22, 2010 [Page 24]
Internet-Draft PA-TNC October 2009
The length of this field can be determined by starting with
the value in the PA-TNC Attribute Length field in the PA-TNC
Attribute Header and subtracting the size of the fixed length
fields in that header (12) and the size of the fixed length
fields in this attribute (5). If the PA-TNC Attribute Length
field is less than the size of these fixed length fields,
implementations SHOULD respond with an Invalid Parameter PA-
TNC error code.
4.2.3. Numeric Version
This PA-TNC Attribute Type contains numeric version information
for a product on the endpoint that implements the component
specified in the PA Subtype field, as described in section 3.5.
For example, if the PA Subtype is Operating System, this
attribute would contain numeric version information for the
operating system installed on the endpoint. The version
information in this attribute is associated with a particular
product, so Posture Validators are expected to also possess the
corresponding Product Information attribute when interpreting
this attribute.
All Posture Collectors that implement the IETF Standard PA
Subtype for Operating System SHOULD support sending this
attribute type, at least for the Operating System PA subtype.
Other Posture Collectors MAY support sending this attribute
type. Whether a particular Posture Collector actually sends
this attribute type SHOULD still be governed by local privacy
and security policies. All Posture Validators that implement
the IETF Standard PA Subtype for Operating System SHOULD support
receiving this attribute type, at least for the Operating System
PA subtype. Other Posture Validators MAY support receiving this
attribute type. A Posture Validator that does not support
receiving this attribute type SHOULD simply ignore attributes
with this type. Posture Validators MUST NOT send this attribute
type.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 3. The value in the PA-TNC Attribute Length field
MUST be 28. If the PA-TNC Attribute Length field is less than
the size of these fixed length fields, implementations SHOULD
respond with an Invalid Parameter PA-TNC error code.
This attribute type includes numeric values for the product
version information, enabling Posture Validators to do
comparative operations on the version. Some Posture Collectors
Sangster & Narayan Expires April 22, 2010 [Page 25]
Internet-Draft PA-TNC October 2009
may not be able to determine some or all of this information for
a product. However, this attribute can be especially useful for
describing the version of the operating system, where numeric
version numbers are generally available.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Major Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minor Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Pack Major | Service Pack Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Major Version Number
This field contains the major version number for the product,
if applicable. If unused or unknown, this field SHOULD be set
to 0.
Minor Version Number
This field contains the minor version number for the product,
if applicable. If unused or unknown, this field SHOULD be set
to 0.
Build Number
This field contains the build number for the product, if
applicable. This may provide more granularity than the minor
version number, as many builds may occur leading up to an
official release, and all these builds may share a single
major and minor version number. If unused or unknown, this
field SHOULD be set to 0.
Service Pack Major
This field contains the major version number of the service
pack for the product, if applicable. If unused or unknown,
this field SHOULD be set to 0.
Sangster & Narayan Expires April 22, 2010 [Page 26]
Internet-Draft PA-TNC October 2009
Service Pack Minor
This field contains the minor version number of the service
pack for the product, if applicable. If unused or unknown,
this field SHOULD be set to 0.
4.2.4. String Version
This PA-TNC Attribute Type contains string version information
for a product on the endpoint that implements the component
specified in the PA Subtype field, as described in section 3.5.
For example, if the PA Subtype is Firewall, this attribute would
contain string version information for a host-based firewall
product installed on the endpoint (if any). The version
information in this attribute is associated with a particular
product, so Posture Validators are expected to also possess the
corresponding Product Information attribute when interpreting
this attribute.
All Posture Collectors that implement any of the IETF Standard
PA Subtypes defined in this document MUST support sending this
attribute type, at least for those PA subtypes. Other Posture
Collectors MAY support sending this attribute type. Whether a
particular Posture Collector actually sends this attribute type
SHOULD still be governed by local privacy and security policies.
All Posture Validators that implement any of the IETF Standard
PA Subtypes defined in this document MUST support receiving this
attribute type, at least for those PA subtypes. Other Posture
Validators MAY support receiving this attribute type. Posture
Validators MUST NOT send this attribute type.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 4. The value in the PA-TNC Attribute Length field
will vary, depending on the length of the Component Version
Number, Internal Build Number, and Configuration Version Number
fields. However, the value in the PA-TNC Attribute Length field
MUST be at least 15 because this is the length of the fixed size
fields in the PA-TNC Attribute Header and the fixed size fields
in this attribute type. If the PA-TNC Attribute Length field is
less than the size of these fixed length fields or does not
match the length indicated by the sum of the fixed length and
variable length fields, implementations SHOULD respond with an
Invalid Parameter PA-TNC error code.
Sangster & Narayan Expires April 22, 2010 [Page 27]
Internet-Draft PA-TNC October 2009
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Len | Product Version Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Num Len | Internal Build Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config. Len | Configuration Version Number (Variable Length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Len
This field defines the number of octets in the Product
Version Number field. If the product version number is
unavailable or unknown, this field MUST be set to 0 and the
Product Version Number field will be zero length (effectively
not present).
Product Version Number
This field contains a UTF-8 string identifying the version of
the component (e.g. "1.12.23.114"). This field MUST be sized
to fit the version string and MUST NOT include extra octets
for padding or NUL character termination.
Various products use a wide range of different formats and
semantics for version strings. Some use alphabetic
characters, white space, and punctuation. Some consider
version "1.21" to be later than version "1.3" and some
earlier. Therefore, the syntax and semantics of this string
are not defined.
Build Num Len
This field defines the number of octets in the Internal Build
Number field. For products where the internal build number
is unavailable or unknown, this field MUST be set to 0 and
the Internal Build Number field will be zero length
(effectively not present).
Internal Build Number
Sangster & Narayan Expires April 22, 2010 [Page 28]
Internet-Draft PA-TNC October 2009
This field contains a UTF-8 string identifying the
engineering build number of the product. This field MUST be
sized to fit the build number string and MUST NOT include
extra octets for padding or NUL character termination. The
syntax and semantics of this string are not defined.
Config. Len
This field defines the number of octets in the Configuration
Version Number field. If the configuration version number is
unavailable or unknown, this field MUST be set to 0 and the
Configuration Version Number field will be zero length
(effectively not present).
Configuration Version Number
This field contains a UTF-8 string identifying the version of
the configuration used by the component. This version SHOULD
represent the overall configuration version even if several
configuration policy files or settings are used. Posture
Collectors MAY include multiple version numbers in this
single string if a single version is not practical. This
field MUST be sized to fit the version string and MUST NOT
include extra octets for padding or NUL character
termination.
Various products use a wide range of different formats for
version strings. Some use alphabetic characters, white
space, and punctuation. Some consider version "1.21" to be
later than version "1.3" and some earlier. In addition, some
Posture Collectors may place multiple configuration version
numbers in this single string. Therefore, the syntax and
semantics of this string are not defined.
4.2.5. Operational Status
This PA-TNC Attribute Type describes the operational status of a
product that can implement the component specified in the PA
Subtype field, as described in section 3.5. For example, if the
PA Subtype is Anti-Spyware, this attribute would contain
information about the operational status of a host-based anti-
spyware product that may or may not be installed on the
endpoint.
Posture Collectors that implement the IETF Standard PA Subtype
for Operating System or VPN MAY support sending this attribute
type for those PA subtypes. Posture Collectors that implement
Sangster & Narayan Expires April 22, 2010 [Page 29]
Internet-Draft PA-TNC October 2009
other IETF Standard PA Subtypes defined in this specification
SHOULD support sending this attribute type for those PA
subtypes. Other Posture Collectors MAY support sending this
attribute type. Whether a particular Posture Collector actually
sends this attribute type SHOULD still be governed by local
privacy and security policies. Posture Validators that
implement the IETF Standard PA Subtype for Operating System or
VPN MAY support receiving this attribute type, at least for
those PA subtypes. Posture Validators that implement other IETF
Standard PA Subtypes defined in this specification SHOULD
support receiving this attribute type, at least for those PA
subtypes. Other Posture Validators MAY support receiving this
attribute type. A Posture Validator that does not support
receiving this attribute type SHOULD simply ignore attributes
with this type. Posture Validators MUST NOT send this attribute
type.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 5. The value in the PA-TNC Attribute Length field
MUST be 36. If the PA-TNC Attribute Length field does not have
this value, implementations SHOULD respond with an Invalid
Parameter PA-TNC error code.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
Sangster & Narayan Expires April 22, 2010 [Page 30]
Internet-Draft PA-TNC October 2009
This field gives the operational status of the product. The
following table lists the values currently defined for this
field.
Value Description
----- -----------
0 Unknown or other
1 Not installed
2 Installed but not operational
3 Operational
If a Posture Validator receives a value for this field that
it does not recognize, it SHOULD treat this value as
equivalent to the value 0.
Result
This field contains the result of the last use of the
product. The following table lists the values currently
defined for this field.
Value Description
----- -----------
0 Unknown or other
1 Successful use with no errors detected
2 Successful use with one or more errors detected
3 Unsuccessful use (e.g. aborted)
Posture Collectors SHOULD set this field to 0 if the Status
field contains a value of 1 (Not installed) or 2 (Installed
but not operational). If a Posture Validator receives a
value for this field that it does not recognize, it SHOULD
treat this value as equivalent to the value 0.
Reserved
This field is reserved for future use. The field MUST be set
to 0 on transmission and ignored upon reception.
Last Use
This field contains the date and time of the last use of the
component. The Last Use date and time MUST be represented as
an RFC 3339 [4] compliant ASCII string in Coordinated
Universal Time (UTC) time with the additional restrictions
that the 't' delimiter and the 'z' suffix MUST be capitalized
and fractional seconds (time-secfrac) MUST NOT be included.
Sangster & Narayan Expires April 22, 2010 [Page 31]
Internet-Draft PA-TNC October 2009
This field conforms to the date-time ABNF production from
section 5.6 of RFC 3339 with the above restrictions. Leap
seconds are permitted and Posture Validators MUST support
them.
The last use string MUST NOT be NUL terminated or padded in
any way. If the last use time is not known, not applicable,
or cannot be represented in this format, the Posture
Collector MUST set this field to the value "0000-00-
00T00:00:00Z" (allowing this field to be fixed length). Note
that this particular reserved value is NOT a valid RFC 3339
date and time and MUST NOT be used for any other purpose in
this field.
This encoding produces a string that is easy to read, parse,
and interpret. The format (more precisely defined in RFC
3339) is YYYY-MM-DDTHH:MM:SSZ, resulting in one and only one
representation for each second in UTC time from year 0000 to
year 9999. For example, 9:05:00AM EST (GMT-0500) on January
19, 1995 can be represented as "1995-01-19T14:05:00Z". The
length of this field is always 20 octets.
4.2.6. Port Filter
This PA-TNC Attribute Type provides the list of port numbers and
associated protocols (e.g. TCP and UDP) that are currently
blocked or allowed by a host-based firewall on the endpoint.
Posture Collectors that implement the IETF Standard PA Subtype
for Firewall or VPN SHOULD support sending this attribute type
for those PA subtypes. Posture Collectors that implement other
IETF Standard PA Subtypes defined in this specification MUST NOT
support sending this attribute type for those PA subtypes.
Other Posture Collectors MAY support sending this attribute
type, if it is appropriate to their PA subtype. Whether a
particular Posture Collector actually sends this attribute type
SHOULD still be governed by local privacy and security policies.
Posture Validators that implement the IETF Standard PA Subtype
for Firewall or VPN SHOULD support receiving this attribute
type, at least for those PA subtypes. Posture Validators that
implement other IETF Standard PA Subtypes defined in this
specification MUST NOT support receiving this attribute type for
those PA subtypes. Other Posture Validators MAY support
receiving this attribute type. A Posture Validator that does
not support receiving this attribute type SHOULD simply ignore
attributes with this type. Posture Validators MUST NOT send
this attribute type.
Sangster & Narayan Expires April 22, 2010 [Page 32]
Internet-Draft PA-TNC October 2009
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 6.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
Note that this diagram shows two Protocol/Port Number pairs. The
actual number of Protocol/Port Number pairs included in a Port
Filter attribute can vary from one to a large number (limited
only by the maximum message and length supported by the
underlying PT transport protocol). However, each Port Filter
attribute MUST contain at least one Protocol/Port Number pair.
Because the length of a Protocol/Port Number pair with the
Reserved field and B flag is always 4 octets, the number of
Protocol/Port Number pairs can be easily computed using the PA-
TNC Attribute Length field by subtracting the number of octets
in the PA-TNC Attribute Header and dividing by 4. If the PA-TNC
Attribute Length field is invalid, Posture Validators SHOULD
respond with an Invalid Parameter PA-TNC error code.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved for future use. It MUST be set to 0
on transmission and ignored upon reception.
B Flag (Blocked or Allowed Port)
This single bit field indicates whether the following port is
blocked or allowed. This bit MUST be set to 1 if the
protocol and port combination is blocked. Otherwise this
field MUST be set to 0. This field was provided to allow for
more abbreviated reporting of the port filtering policy (e.g.
when all ports are blocked except a few, the Posture
Collector can just list the few that are allowed).
Posture Collectors MUST NOT provide a mixed list of block and
non-blocked ports for a particular protocol. To be more
Sangster & Narayan Expires April 22, 2010 [Page 33]
Internet-Draft PA-TNC October 2009
precise, a Posture Collector MUST NOT include two
Protocol/Port Number pairs in a single Port Filter attribute
where the protocol number is the same but the B flag is
different. Also, Posture Collectors MUST NOT list the same
Protocol and Port Number combination twice in a Port List
attribute.
Posture Collectors MAY list all blocked ports for one
protocol and all allowed ports for a different protocol in a
single Port List attribute, using the B flag to indicate
whether each entry is blocked. For example, a Posture
Collector might list all the blocked TCP ports but only list
the allowed UDP ports. However it MUST NOT list some blocked
TCP ports and some other allowed TCP ports.
Protocol
This field contains the transport protocol number (e.g. tcp
is 6) being blocked or allowed. The values used in this field
are the same ones used in the IPv4 Protocol and IPv6 Next
Header fields. The IANA already maintains the Assigned
Internet Protocol Numbers registry of these values for use in
this field.
Port Number
This field contains the transport protocol (e.g. tcp) port
number being blocked or allowed. The values used in this
field are specific to the protocol identified by the Protocol
field. The IANA maintains registries for well known and user
requested TCP and UDP port numbers for use in this field.
4.2.7. Installed Packages
This PA-TNC Attribute Type contains a list of the installed
packages that comprise a product on the endpoint that implements
the component specified in the PA Subtype field, as described in
section 3.5. This allows a Posture Validator to check which
packages are installed for a particular product and which
versions of those packages are installed.
Posture Collectors that implement any of the IETF Standard PA
Subtypes defined in this document SHOULD support sending this
attribute type for those PA subtypes. Other Posture Collectors
MAY support sending this attribute type, if it is appropriate to
their PA subtype. Whether a particular Posture Collector
actually sends this attribute type SHOULD still be governed by
Sangster & Narayan Expires April 22, 2010 [Page 34]
Internet-Draft PA-TNC October 2009
local privacy and security policies. Posture Validators that
implement any of the IETF Standard PA Subtypes defined in this
document SHOULD support receiving this attribute type, at least
for those PA subtypes. Other Posture Validators MAY support
receiving this attribute type. A Posture Validator that does
not support receiving this attribute type SHOULD simply ignore
attributes with this type. Posture Validators MUST NOT send
this attribute type.
This attribute type can be quite long, especially for the
Operating System PA subtype. This can cause problems, especially
with 802.1X and other limited transport protocols. Therefore,
Posture Collectors SHOULD NOT send this attribute unless
specifically requested to do so using the Attribute Request
attribute or otherwise configured to do so. Also, Posture
Validators SHOULD NOT request this attribute unless the
transport protocol in use can support the large amount of data
that may be sent in response.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 7. The value in the PA-TNC Attribute Length field
will vary, depending on the number of packages and the length of
the Package Name and Package Version Number fields for those
packages. However, the value in the PA-TNC Attribute Length
field MUST be at least 16 because this is the length of the
fixed size fields in the PA-TNC Attribute Header and the fixed
size fields in this attribute type. If the PA-TNC Attribute
Length field is less than the size of these fixed length fields
or does not match the length indicated by the sum of the fixed
length and variable length fields, implementations SHOULD
respond with an Invalid Parameter PA-TNC error code.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
Note that this diagram shows an attribute containing information
on one package. The actual number of package descriptions
included in an Installed Packages attribute is indicated by the
Package Count field. This value may vary from zero to a large
number (up to 65535, if the underlying PT transport protocol can
support that many). If this number is not sufficient,
specialized patch management software should be employed which
can simply report compliance with a pre-established patch
policy.
Sangster & Narayan Expires April 22, 2010 [Page 35]
Internet-Draft PA-TNC October 2009
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Package Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pkg Name Len | Package Name (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Len | Package Version Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved for future use. The field MUST be set
to 0 on transmission and ignored upon reception.
Package Count
This field is an unsigned 16-bit integer that indicates the
number of packages listed in this attribute. For each
package so indicated, a Pkg Name Len, Package Name, Version
Len, and Package Version Number field is included in the
attribute.
Pkg Name Len
This field is an unsigned 8-bit integer that indicates the
length of the Package Name field in octets. This field may be
zero if a Package Name is not available.
Package Name
This field contains the name of the package associated with
the product. This field is a UTF-8 encoded character string
whose octet length is given by the Pkg Name Len field. This
field MUST NOT include extra octets for padding or NUL
character termination. The syntax and semantics of this name
are not specified in this document, since they may vary
across products and/or operating systems. Posture Collectors
MAY list two packages with the same name in a single
Installed Packages attribute. The meaning of doing so is not
defined here.
Version Len
This field is an unsigned 8-bit integer that indicates the
length of the Package Version Number field in octets. This
Sangster & Narayan Expires April 22, 2010 [Page 36]
Internet-Draft PA-TNC October 2009
field may be zero if a Package Version Number is not
available.
Package Version Number
This field contains the version string for the package named
in the previous Package Name field. This field is a UTF-8
encoded character string whose octet length is given by the
Version Len field. This field MUST NOT include extra octets
for padding or NUL character termination. The syntax and
semantics of this version string are not specified in this
document, since they may vary across products and/or
operating systems. Posture Collectors MAY list two packages
with the same Package Version Number (and even the same
Package Name and Package Version Number) in a single
Installed Packages attribute. The meaning of doing so is not
defined here.
4.2.8. PA-TNC Error
This PA-TNC Attribute Type contains an error code and
supplemental information regarding an error pertaining to PA-
TNC.
All Posture Collectors and Posture Validators that implement any
of the IETF Standard PA Subtypes defined in this specification
MUST support sending and receiving this attribute type, at least
for those PA subtypes.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 8. The value in the PA-TNC Attribute Length field
will vary, depending on the length of the Error Information
field. However, the value in the PA-TNC Attribute Length field
MUST be at least 20 because this is the length of the fixed size
fields in the PA-TNC Attribute Header and the fixed size fields
in this attribute type.
A PA-TNC error code SHOULD be sent with the same PA Message
Vendor ID and PA Subtype used by the PA-TNC message that caused
the error so that the error code is sent to the party who sent
the offending PA-TNC message. Other measures (such as setting
PB-TNC's EXCL flag and Posture Collector Identifier or Posture
Validator Identifier fields) SHOULD also be taken to attempt to
ensure that only the party who sent the offending message
receives the error.
Sangster & Narayan Expires April 22, 2010 [Page 37]
Internet-Draft PA-TNC October 2009
When a PA-TNC error code is received, the recipient MUST NOT
respond with a PA-TNC error code because this could result in an
infinite loop of errors. Instead, the recipient MAY log the
error, modify its behavior to attempt to avoid the error
(attempting to avoid loops or long strings of errors), ignore
the error, terminate the assessment, or take other action as
appropriate (as long as it is consistent with the requirements
of this specification).
Posture Validators MUST NOT include this attribute type in an
Attribute Request attribute. It does not make sense for a
Posture Validator to request that a Posture Collector send a PA-
TNC Error attribute.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Information (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved for future use. This field MUST be
set to 0 on transmission and ignored upon reception.
PA-TNC Error Code Vendor ID
This field contains the SMI Private Enterprise Number for the
organization that defined the PA-TNC Error Code that is being
used in the attribute. For IETF Standard PA-TNC Error Code
values this field MUST be set to zero (0).
PA-TNC Error Code
This field contains the PA-TNC Error Code being reported in
this attribute. Note that a particular PA-TNC Error Code
value will have completely different meanings depending on
the PA-TNC Error Code Vendor ID. Each PA-TNC Error Code
Vendor ID defines a different space of PA-TNC Error Code
Sangster & Narayan Expires April 22, 2010 [Page 38]
Internet-Draft PA-TNC October 2009
values. Posture Collectors and Posture Validators MUST NOT
require support for particular vendor-specific PA-TNC Error
Codes and MUST interoperate with other parties despite any
differences in the set of vendor-specific PA-TNC Error Codes
supported (although they MAY permit administrators to
configure them to require support for specific PA-TNC error
codes).
When the PA-TNC Error Code Vendor ID is set to zero (0), the
PA-TNC Error Code is an IETF Standard PA-TNC Error Code. IANA
maintains a registry of PA-TNC Error Codes. Entries in this
registry are added by Expert Review with Specification
Required, following the guidelines in section 7.
The following table lists the IETF Standard PA-TNC Error
Codes defined in this specification:
Value Description
----- -----------
0 Reserved
1 Invalid Parameter
2 Version Not Supported
3 Attribute Type Not Supported
The next few subsections of this document provide detailed
definitions of these error codes.
Error Information
This field provides additional context for the error. The
contents of this field vary based on the PA-TNC Error Code
Vendor ID and PA-TNC Error Code. Therefore, whenever a PA-TNC
Error Code is defined, the format of this field for that
error code must also be defined. The definitions of IETF
Standard PA-TNC Error Codes on the next few pages provide
good examples of such definitions.
The length of this field can be determined by the recipient
using the PA-TNC Attribute Length field by subtracting the
length of the fixed-length fields in the PA-TNC Attribute
Header and the fixed-length fields in this attribute.
4.2.8.1. Invalid Parameter Error Code
The Invalid Parameter error code is an IETF Standard PA-TNC
Error Code (value 1) that indicates that the sender of this
error code has detected an invalid value in a PA-TNC message
Sangster & Narayan Expires April 22, 2010 [Page 39]
Internet-Draft PA-TNC October 2009
sent by the recipient of this error code in the current
assessment.
For this error code, the Error Information field contains the
first 8 octets of the PA-TNC message that contained the invalid
parameter and an offset indicating the position within that
message of the invalid parameter.
The following diagram illustrates the format and contents of the
Error Information field for this error code. The text after
this diagram describes the fields shown here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
This field MUST contain an exact copy of the Version field in
the PA-TNC Message Header of the PA-TNC message that caused
this error.
Reserved
This field MUST contain an exact copy of the Reserved field
in the PA-TNC Message Header of the PA-TNC message that
caused this error.
Message Identifier
This field MUST contain an exact copy of the Message
Identifier field in the PA-TNC Message Header of the PA-TNC
message that caused this error.
Offset
This field MUST contain an octet offset from the start of the
PA-TNC Message Header of the PA-TNC message that caused this
error to the start of the value that caused this error. For
instance, if the first PA-TNC attribute in the message had an
Sangster & Narayan Expires April 22, 2010 [Page 40]
Internet-Draft PA-TNC October 2009
invalid PA-TNC Attribute Length (e.g. 0), this value would be
16.
4.2.8.2. Version Not Supported Error Code
The Version Not Supported error code is an IETF Standard PA-TNC
Error Code (value 2) that indicates that the sender of this
error code does not support the PA-TNC version number included
in the PA-TNC Message Header of a PA-TNC message sent by the
recipient of this error code in the current assessment.
For this error code, the Error Information field contains the
first 8 octets of the PA-TNC message that contained the
unsupported version as well as Max Version and Min Version
fields that indicate which PA-TNC version numbers are supported
by the sender of the error code.
The sender MUST support all PA-TNC versions between the Min
Version and the Max Version, inclusive (i.e. including the Min
Version and the Max Version). When possible, recipients of this
error code SHOULD send future messages to the Posture Collector
or Posture Validator that originated this error message with a
PA-TNC version number within the stated range.
Any party that is sending the Version Not Supported error code
MUST include that error code as the only PA-TNC attribute in a
PA-TNC message with version number 1. All parties that send PA-
TNC messages MUST be able to properly process a message that
meets this description, even if they cannot process any other
aspect of PA-TNC version 1. This ensures that a PA-TNC version
exchange can proceed properly, no matter what versions of PA-TNC
the parties implement.
The following diagram illustrates the format and contents of the
Error Information field for this error code. The text after
this diagram describes the fields shown here.
Sangster & Narayan Expires April 22, 2010 [Page 41]
Internet-Draft PA-TNC October 2009
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Version | Min Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
This field MUST contain an exact copy of the Version field in
the PA-TNC Message Header of the PA-TNC message that caused
this error.
Copy of Reserved
This field MUST contain an exact copy of the Reserved field
in the PA-TNC Message Header of the PA-TNC message that
caused this error.
Message Identifier
This field MUST contain an exact copy of the Message
Identifier field in the PA-TNC Message Header of the PA-TNC
message that caused this error.
Max Version
This field MUST contain the maximum PA-TNC version supported
by the sender of this error code.
Min Version
This field MUST contain the minimum PA-TNC version supported
by the sender of this error code.
Reserved
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
4.2.8.3. Attribute Type Not Supported Error Code
The Attribute Type Not Supported error code is an IETF Standard
PA-TNC Error Code (value 3) that indicates that the sender of
Sangster & Narayan Expires April 22, 2010 [Page 42]
Internet-Draft PA-TNC October 2009
this error code does not support the PA-TNC Attribute Type
included in the Error Information field. This PA-TNC Attribute
Type was included in a PA-TNC message sent by the recipient of
this error code in the current assessment.
For this error code, the Error Information field contains the
first 8 octets of the PA-TNC message that contained the
unsupported attribute type as well as a copy of the attribute
type that caused the problem.
The following diagram illustrates the format and contents of the
Error Information field for this error code. The text after
this diagram describes the fields shown here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
This field MUST contain an exact copy of the Version field in
the PA-TNC Message Header of the PA-TNC message that caused
this error.
Copy of Reserved
This field MUST contain an exact copy of the Reserved field
in the PA-TNC Message Header of the PA-TNC message that
caused this error.
Message Identifier
This field MUST contain an exact copy of the Message
Identifier field in the PA-TNC Message Header of the PA-TNC
message that caused this error.
Flags
Sangster & Narayan Expires April 22, 2010 [Page 43]
Internet-Draft PA-TNC October 2009
This field MUST contain an exact copy of the Flags field in
the PA-TNC Attribute Header of the PA-TNC attribute that
caused this error.
PA-TNC Attribute Vendor ID
This field MUST contain an exact copy of the PA-TNC Attribute
Vendor ID field in the PA-TNC Attribute Header of the PA-TNC
attribute that caused this error.
PA-TNC Attribute Type
This field MUST contain an exact copy of the PA-TNC Attribute
Type field in the PA-TNC Attribute Header of the PA-TNC
attribute that caused this error.
4.2.9. Assessment Result
This PA-TNC attribute contains the final assessment result from
a particular Posture Validator. This attribute might be
returned to a Posture Collector for information purposes such
as when an endpoint is compliant. Similarly, the Assessment
Result attribute could be sent to indicate a non-compliant
result where specific actions are needed to bring an endpoint
into compliance with the network's policies. These actions
could be defined in other PA-TNC attributes such as Remediation
Instructions sent to the Posture Collector.
All Posture Collectors that support an IETF standard PA Subtype
defined in this specification SHOULD support receiving and
processing the Assessment Result attribute. All Posture
Validators that implement an IETF standard PA Subtype defined
in this specification SHOULD support sending the Assessment
Result attribute.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field
MUST be set to 9.
The following diagram illustrates the format and contents of
the Attribute Value field for this attribute type. The text
after this diagram describes the fields shown here.
Sangster & Narayan Expires April 22, 2010 [Page 44]
Internet-Draft PA-TNC October 2009
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assessment Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assessment Result
This 32-bit field MUST contain one of the following values
Value Description
----- -----------
0 Posture Validator assessed the endpoint component to
be compliant with policy
1 Posture Validator assessed the endpoint component to
be non-compliant with policy but the difference from
compliant was minor.
2 Posture Validator assessed the endpoint component to
be non-compliant with policy and the assessed
difference was very significant.
3 Posture Validator was unable to determine policy
compliance of an endpoint component due to an error.
4 Posture Validator was unable to determine whether the
assessed endpoint component was compliant with policy
based on the attributes provided by the Posture
Collector(s)
4.2.10. Remediation Instructions
This PA-TNC attribute sent by the Posture Validator to the
Posture Collector(s) contains remediation instructions for
updating a particular component to make the endpoint compliant
with the assessment policies. A Posture Validator might choose
to send more then one Remediation Instructions attributes in
some circumstances (e.g. both a URI and a human readable
message are necessary) to remediate one or more components.
This attribute supports the inclusion of either an IETF
Standard or vendor specific remediation instruction.
All Posture Collectors that implement an IETF standard PA
Subtype defined in this specification SHOULD support receiving
and processing the Remediation Instructions attribute. All
Sangster & Narayan Expires April 22, 2010 [Page 45]
Internet-Draft PA-TNC October 2009
Posture Validators that implement an IETF standard PA Subtype
defined in this specification SHOULD support sending this
attribute type. Posture Collectors and Posture Validators
supporting other non-IETF standard components MAY support this
attribute.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field
MUST be set to 10.
The following diagram illustrates the format and contents of
the Attribute Value field for this attribute type. The text
after this diagram describes the fields shown here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remediation Parameters Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (8 bits)
The Reserved bits MUST be set to 0 on transmission and
ignored on reception.
Remediation Parameters Vendor ID (24 bits)
The Remediation Parameters Vendor ID field identifies a
vendor by using the SMI Private Enterprise Number (PEN). Any
organization can receive its own unique PEN from IANA, the
Internet Assigned Numbers Authority. The Remediation
Parameters Vendor ID qualifies the Remediation Parameters
Type field so that each vendor has 2^32 separate Remediation
Parameters Types available for its use. Remediation
Parameters Types standardized by the IETF are always used
with the value zero (0) in this field.
Remediation Parameters Type (32 bits)
The Remediation Parameters Type field identifies the
different types of remediation instructions that can be
contained in the Remediation Parameters field. IANA
Sangster & Narayan Expires April 22, 2010 [Page 46]
Internet-Draft PA-TNC October 2009
maintains a registry of PA-TNC Remediation Parameters Types.
Entries in this registry are added by Expert Review with
Specification Required, following the guidelines in section
7. A list of IETF Standard PA-TNC Remediation Parameters
Types defined in this specification appears later in this
section.
New vendor-specific remediation instructions can be created
by adding new Remediation Parameters Types (those used with a
non-zero Remediation Parameters vendor ID) without IETF or
IANA involvement. Posture Collectors and Posture Validators
MUST NOT require support for particular vendor-specific PA-
TNC Remediation Parameters Types and MUST interoperate with
other parties despite any differences in the set of vendor-
specific PA-TNC Remediation Parameters Types supported
(although they MAY permit administrators to configure them to
require support for specific PA-TNC remediation parameter
types).
The following table lists the IETF Standard PA-TNC
Remediation Parameters Type values defined in this
specification:
Value Description
----- -----------
0 Reserved
1 Remediation URI
2 Remediation String
The next few subsections of this document provide detailed
definitions of the contents of the Remediation Parameters
field used with each Remediation Parameter Type.
Remediation Parameters (variable length)
The Remediation Parameters field contains the actual
remediation instructions for the Posture Collector.
4.2.10.1. Remediation URI Parameters
The Remediation URI parameters type is an IETF Standard
Remediation Parameters Type (value 1) that indicates that the
sending Posture Validator is providing a URI to instructions on
how to remediate the endpoint.
Sangster & Narayan Expires April 22, 2010 [Page 47]
Internet-Draft PA-TNC October 2009
The following diagram illustrates the format and contents of the
Remediation Parameters field when carrying a Remediation URI
parameter. The text after this diagram describes the fields shown
here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation URI (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Remediation URI
The Remediation URI field MUST contain a URI, as described in
RFC 3986 [7]. This URI SHOULD contain instructions to update
a particular component so that it might result in the
component being compliant with the policies in future
assessments. Posture Collectors should validate that the URI
and instructions come from a trustworthy source to avoid
being tricked into performing damaging actions (see security
considerations).
4.2.10.2. Remediation String Parameters Type
The Remediation String parameters is an IETF Standard
Remediation Parameters Type (value 2) that indicates that the
sending Posture Validator is providing a human readable string
containing instructions on how to remediate the endpoint.
The following diagram illustrates the format and contents of the
Remediation Parameters field when the carrying a Remediation String
parameter. The text after this diagram describes the fields shown
here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Remediation String Lang Code (Variable Len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Remediation String Length
Sangster & Narayan Expires April 22, 2010 [Page 48]
Internet-Draft PA-TNC October 2009
The Remediation String Length contains the length of the
Remediation String field in octets.
Remediation String
The Remediation String field MUST contain a UTF-8 encoded
string. This string contains human-readable instructions for
remediation that MAY be displayed to the user by the Posture
Collector. NUL termination MUST NOT be included. If a
Posture Collector receives a Remediation String that does
contain a NUL termination, it SHOULD send an Invalid
Parameter error code.
Lang Code Len (Remediation String Language Code Length)
The Lang Code Len field contains the length of the
Remediation String Language Code field in octets.
Remediation String Lang Code
The Remediation String Lang(uage) Code field contains a US-
ASCII string comprised of a well-formed RFC 4646 [6] language
tag that indicates the language(s) used in the Remediation
String in the Remediation Parameters field. A zero length
string MAY be sent for this field (essentially omitting this
field) to indicate that the language code for the remediation
string is not known.
4.2.11. Forwarding Enabled
This PA-TNC attribute indicates whether the endpoint is
forwarding traffic between interfaces. Endpoints that forward
traffic between networks connected to multiple network
interfaces may be considered non-compliant (and a security
risk) in some enterprise network deployments. For example, an
endpoint with multiple connected network interfaces might allow
traffic from an interface connected to a public network to be
forwarded through another interface carrying a VPN session to a
protected enterprise network. This attribute is currently
envisioned to be specific to reporting posture for the
operating system component, however could be useful for other
future types of components.
Posture Collectors that implement the IETF standard PA Subtype
for Operating System SHOULD support sending the Forwarding
Enabled attribute. Posture Collectors that do not implement
the Operating System PA Subtype defined in this specification
Sangster & Narayan Expires April 22, 2010 [Page 49]
Internet-Draft PA-TNC October 2009
SHOULD NOT send the Forwarding Enabled attribute unless if it
is appropriate to their PA Subtype. Whether a particular
Posture Collector actually sends this attribute type SHOULD
still be governed by local privacy and security policies.
Posture Validators that implement the IETF standard PA Subtype
for Operating System SHOULD support receiving the Forwarding
Enabled attribute type. Posture Validators supporting
components other than Operating System MAY support receiving
this attribute type if it is appropriate to their PA Subtype.
A Posture Validator that does not support receiving this
attribute type SHOULD simply ignore attributes with this type.
Posture Validators MUST NOT send this attribute type.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field
MUST be set to 11.
The following diagram illustrates the format and contents of
the Attribute Value field for this attribute type. The text
after this diagram describes the fields shown here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Forwarding Enabled
This 32-bit field MUST contain one of the following values
Value Description
----- -----------
0 Disabled - Endpoint is not forwarding traffic.
1 Enabled - Endpoint is forwarding traffic.
2 Unknown - Unable to determine whether endpoint is
forwarding traffic
4.2.12. Factory Default Password Enabled
This PA-TNC attribute indicates whether the endpoint has a
factory default password enabled for use. Some types of
endpoints include a default static password for used to gain
Sangster & Narayan Expires April 22, 2010 [Page 50]
Internet-Draft PA-TNC October 2009
privileged access to the endpoint. If this password is not
changed or disabled before the endpoint is accessible on the
network, it's often easy to compromise the endpoint.
Posture Collectors that implement the IETF standard PA Subtype
for Operating System SHOULD support sending the Factory Default
Password Enabled attribute. Posture Collectors that implement
other IETF Standard PA Subtypes defined in this specification
SHOULD NOT support sending this attribute type for those PA
subtypes. Other Posture Collectors MAY support sending this
attribute type, if it is appropriate to their PA subtype.
Whether a particular Posture Collector actually sends this
attribute type SHOULD still be governed by local privacy and
security policies. Posture Validators that implement the IETF
standard PA Subtype for Operating System SHOULD support
receiving the Factory Default Password Enabled attribute. Other
Posture Validators MAY support receiving this attribute type. A
Posture Validator that does not support receiving this attribute
type SHOULD simply ignore attributes with this type. Posture
Validators MUST NOT send this attribute type.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 12.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Factory Default Password Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Factory Default Password Enabled
This 32-bit field MUST contain one of the following values
Value Description
----- -----------
0 Endpoint does not have factory default password enabled.
1 Endpoint has a factory default password enabled.
Sangster & Narayan Expires April 22, 2010 [Page 51]
Internet-Draft PA-TNC October 2009
4.3. Vendor-Defined Attributes
This section discusses the use of vendor-defined attributes
within PA-TNC. The PA-TNC protocol was designed to allow for
vendor-defined attributes to be used as a replacement where a
standard attribute could be used. In some cases even the
standard attributes allow for vendor-defined information to be
included. It is envisioned that over time as particular vendor-
defined attributes become popular, an equivalent standard
attribute could be added allowing for broader interoperability.
This specification does not define vendor-defined attributes,
but rather highlights how such attributes can be used with PA-
TNC without the potential for name space collisions or
misinterpretations. In order to avoid collisions, PA-TNC uses
the well-established SMI Private Enterprise Numbers as Vendor
IDs to define separate name spaces for important fields within a
PA-TNC message. For example, to ensure the uniqueness of
attribute types while providing for vendor extensions, vendor-
defined attribute types include the vendor's unique Vendor ID,
to indicate the intended name space for the attribute type,
followed by the attribute type. IETF Standard PA-TNC Attribute
Types use a Vendor ID of zero (0).
SMI Private Enterprise Numbers are used to provide a separate
identifier space for each vendor. The IANA provides a registry
for SMI Private Enterprise Numbers. Any organization (including
non-profit organizations, governmental bodies, etc.) can obtain
one of these numbers at no charge and thousands of organizations
have done so. Within this document, SMI Private Enterprise
Numbers are known as "vendor IDs".
5. Security Considerations
This section discusses the major potential types of security
threats relevant to the PA-TNC message protocol. It is
envisioned that additional attribute types could be defined in
the future to facilitate the exchange of security capabilities,
keys, and security protected attributes if future use cases are
adopted that require such protections.
5.1. Trust Relationships
In order to understand where security countermeasures are
necessary, this section starts with a discussion of where the
Sangster & Narayan Expires April 22, 2010 [Page 52]
Internet-Draft PA-TNC October 2009
TNC architecture envisions some trust relationships between the
processing elements of the PA-TNC protocol. The following sub-
sections discuss the trust properties associated with each
portion of the NEA reference model directly involved with the
processing of the PA-TNC protocol.
5.1.1. Posture Collector
The Posture Collectors are trusted by Posture Validators to:
o Collect valid information about the component type associated
with the Posture Collector
o Report upon collected information consistent with local
security and privacy policies
o Accurately report information associated with the type of
component for the PA-TNC message
o Not act maliciously to the Posture Broker Server and Posture
Validators, including attacks such as Denial Of Service
5.1.2. Posture Validator
The Posture Validators are trusted by Posture Collectors to:
o Only request information necessary to assess the security
state of the endpoint
o Make assessment decisions based on deployer defined policies
o Discard collected information consistent with data retention
and privacy policies
o Not act maliciously to the Posture Broker Server and Posture
Collectors, including attacks such as Denial Of Service
o Not to send malicious remediation instructions that do not
fix or causes damage to the endpoint.
5.1.3. Posture Broker Client, Posture Broker Server
The Posture Broker Client and Posture Broker Server are trusted
by the Posture Collector and Posture Validator to:
o Provide a reliable transport for PA-TNC messages
Sangster & Narayan Expires April 22, 2010 [Page 53]
Internet-Draft PA-TNC October 2009
o Deliver messages for a particular PA Subtype only to those
Posture Collectors and Posture Validators that have
registered for them
o Not disclose any provided attributes to unauthorized parties
o Not act maliciously to drop messages, duplicate messages, or
flood the Posture Collectors and Posture Validators with
unnecessary messages
o Not observe, fabricate, or alter the contents of a PA-TNC
message
o Properly place Posture Collector and Posture Validator
identifiers into the PB-TNC protocol, deliver those
identifiers to Posture Collectors and Posture Validators as
needed, and manage exclusive delivery to a particular Posture
Collector or Posture Validator when requested
o Properly expose authentication information from PT security
so that Posture Collectors and Posture Validators can use the
peer's identity information to safely make policy decisions
5.2. Security Threats
Beyond the trusted relationships assumed in section 5.1 the PA-
TNC protocol faces a number of potential security attacks that
could require security countermeasures.
Generally the PA-TNC protocol relies upon the underlying PT
protocol's security to protect the messages from attack when
traveling over the network. Once the message resides on the
Posture Broker Client or Posture Broker Server, the posture
brokers are trusted to properly and safely deliver the messages
to the appropriate Posture Collectors and Posture Validators.
5.2.1. Attribute Theft
When PA-TNC messages are sent over unprotected network links or
spanning local software stacks that are not trusted, the
contents of the PA-TNC messages may be subject to information
theft by an intermediary party. This theft could result in
information being recorded for future use or analysis by the
adversary. Attributes observed by eavesdroppers could contain
information that exposes potential weaknesses in the security of
the endpoint, or system fingerprinting information easing the
ability of the attacker to employ attacks more likely to be
Sangster & Narayan Expires April 22, 2010 [Page 54]
Internet-Draft PA-TNC October 2009
successful against the endpoint. The eavesdropper might also
learn information about the endpoint or network policies that
either singularly or collectively is considered sensitive
information (e.g. certain endpoints are lacking patches, or
particular sub-networks have more lenient policies).
PA-TNC attributes are not intended to carry privacy-sensitive
information, but should some exist in a message, the adversary
could come into possession of the information which could be
used for other financial gain. Therefore it is important that
PT provide strong confidentiality protection to protect the
message from eavesdroppers when being sent between the Posture
Transport Client and Posture Transport Server.
5.2.2. Message Fabrication
Attackers on the network or present within the NEA system could
introduce fabricated PA-TNC messages intending to trick or
create a denial of service against aspects of an assessment. For
example, an adversary could attempt to send a falsified set of
remediation instructions using the Remediation URI support in
hopes of the Posture Collector automatically following the
instructions. Posture Collectors need to ensure that any
requests to take actions on the endpoint (such as remediation
instructions) received from Posture Validator(s) are authentic
and trustworthy using strong authentication and integrity
protections offered by PT. Posture Collectors should not
blindly follow remediation instructions received from a trusted
NEA Server. At least for patches and other potentially
dangerous actions, Posture Collectors should validate these
actions (e.g. via user confirmation) before proceeding.
Such an attack could occur if an active attacker could launch a
man-in-the-middle (MiTM) attack by proxying the PA-TNC messages
and was able to replace undesired messages with ones easing
future attack upon the endpoint. Consider a scenario where PT
security protection is not used and the Posture Broker Server
proxies all assessment traffic to a remote Posture Broker
Server. The proxy could eavesdrop and replace assessment
results attributes, tricking the endpoint into thinking it has
passed an assessment, when in fact it has not and requires
remediation. Because the Posture Collector has no way to verify
that attributes were actually created by an authentic Posture
Validator, it is unable to detect the falsified attribute or
message. Therefore, it is important that PT provides strong
authentication and integrity protection.
Sangster & Narayan Expires April 22, 2010 [Page 55]
Internet-Draft PA-TNC October 2009
5.2.3. Attribute Modification
This attack could allow an active attacker capable of
intercepting a message to modify a PA-TNC message attribute to a
desired value to ease the compromise of an endpoint. Without
the ability for message recipients to detect whether a received
message contains the same content as what was originally sent,
active attackers can stealthily modify the attribute exchange.
For example, an attacker might wish to change the contents of
the firewall component's version string attribute to disguise
the fact that the firewall is running an old, vulnerable
version. The attacker would change the version string sent by
the firewall Posture Collector to the current version number, so
the Posture Validator's assessment passes while leaving the
endpoint vulnerable to attack. Similarly, an attacker could
achieve widespread denial of service by altering large numbers
of assessments' version string attributes to an old value so
they repeatedly fail assessments even after a successful
remediation. Upon receiving the lower value, the Posture
Validator would continue to believe that the endpoint is running
old, potentially vulnerable versions of the firewall that does
not meet network compliance policy, so therefore the endpoint
would not be allowed to join the network. Use of a PT protocol
providing strong integrity protection and authentication is
essential as countermeasures to these attacks.
5.2.4. Attribute Replay
Another potential attack against an unprotected PA-TNC message
attribute exchange is to exploit the lack of a strong binding
between the attributes sent during an assessment to the specific
endpoint. Without a strong binding of the endpoint to the
posture information, an attacker could record the attributes
sent during an assessment of a compliant endpoint and later
replay those attributes so that a non-compliant endpoint can now
gain access to the network or protected resource. This attack
could be employed by a network MiTM that is able to eavesdrop
and proxy message exchanges, or by using local rogue agents on
the endpoints. Assessments lacking some form of freshness
exchange could be subject to replay of prior assessment data,
even if it no longer reflects the current state of the endpoint.
Use of a PT protocol providing strong integrity protection and
authentication including a freshness exchange is necessary
countermeasure to these attacks.
Sangster & Narayan Expires April 22, 2010 [Page 56]
Internet-Draft PA-TNC October 2009
5.2.5. Attribute Insertion
Similar to the attribute modification attacks, an adversary
wishing to include one or more attributes or PA-TNC messages
inside a valid assessment may be able to insert the attributes
or messages without detection by the recipient. For example, an
attacker could add attributes to the front of a PA-TNC message
to cause an assessment to succeed even for a non-compliant
endpoint, particularly if it knew that the recipient ignored
repeated attributes within a message. Similarly, if a Posture
Collector or Posture Validator always generated an error if it
saw unexpected attributes, the attacker could cause failures and
denial of service by adding attributes or messages to an
exchange. Use of a PT protocol providing strong authentication
and integrity protection could prevent the adversary from
inserting attributes into the assessment.
5.2.6. Denial of Service
A variety of types of denial of service attacks are possible
against the PA-TNC message exchange if left unprotected from
untrusted parties along the communication path between the
Posture Collector and Posture Validator. Normally, the PT
exchange is bi-directionally authenticated which helps to
prevent a MiTM on the network from becoming an active proxy, but
transparent message routing gateways may still exist on the
communication path and can modify the integrity of the message
exchange unless adequate integrity protection is provided. If
the MiTM or other entities on the network can send messages to
the Posture Broker Client or Posture Broker Server that appear
to be part of an assessment, these messages could confuse the
Posture Collector and Posture Validator or cause them to perform
unnecessary work or take incorrect action. Several example
denial of service situations are described in sections 5.2.3
and 5.2.5. Many potential denial of service examples exist,
including flooding messages to Posture Collector or Posture
Validator, sending very large messages containing many
attributes, and repeatedly asking for resource intensive
operations. As described in sections 5.1.1 and 5.1.2.
6. Privacy Considerations
The PA-TNC protocol is designed to allow for controlled
disclosure of security relevant information about an endpoint,
specifically for the purpose of enabling an assessment of the
endpoint's compliance with network policy. The purpose of this
protocol is to provide visibility into the state of the
Sangster & Narayan Expires April 22, 2010 [Page 57]
Internet-Draft PA-TNC October 2009
protective mechanisms on the endpoint, in order for the Posture
Validators and Posture Broker Server to determine whether the
endpoint is up to date and thus has the best chance of being
resilient in the face of malware threats. One risk associated
with providing visibility into the contents of an endpoint is
the increased chance for exposure of privacy sensitive
information without the consent of the user.
While this protocol does provide the Posture Validator the
ability to request specific information about the endpoint, the
protocol is not open ended, bounding the Posture Validator to
only query specific information (attributes) about specific
security features (component types) of the endpoint. Each PA-
TNC message is explicitly about a single component from the list
of components in section 3.5. These components include a list
of security-related aspects of the endpoint that affect the
ability of the endpoint to resist attacks and thus are of
interest during an assessment. Discretionary components used by
the user to create or view content are not on the list, as they
are more likely to have access to privacy sensitive information.
Similarly, PA-TNC messages contain a set of attributes which
describe the particular component. Each attribute contains
generic information (e.g. product information or versions) about
the component, so it is unlikely to include any user specific or
identifying information. This combination of limited set of
security related components with non-user specific attributes
greatly reduces the risk of exposure of privacy sensitive
information. Vendors that choose to define additional component
types and/or attributes within their name space are encouraged
to provide similar constraints.
Even with the bounding of standard attribute information to
specific components, it is possible that individuals might wish
to share less information with different networks they wish to
access. For example, a user may wish to share more information
when connecting or being reassessed by the user's employer
network than what would be made available to the local coffee
shop wireless network. While these situations do not impact the
protocol itself, they do suggest that Posture Collector
implementations should consider supporting a privacy filter
allowing the user and/or system owner to restrict access to
certain attributes based upon the target network.
The underlying PT protocol authenticates the network's Posture
Broker Server at the start of an assessment, so identity can be
made available to the Posture Collector and per-network privacy
Sangster & Narayan Expires April 22, 2010 [Page 58]
Internet-Draft PA-TNC October 2009
filtering is possible. Network owners should make available a
list of the attributes they require to perform an assessment and
any privacy policy they enforce when handling the data. Users
wishing to use a more restricted privacy filter on the endpoint
may risk not being able to pass an assessment and thus not gain
access to the requested network or resource.
7. IANA Considerations
This section defines the contents of three new IANA registries:
PA-TNC Attribute Types, PA-TNC Error Codes and PA-TNC
Remediation Parameters Types. This section explains how these
registries work. Also, this specification defines several new
PA Subtypes for use with PA-TNC.
All of the registries defined in this document support IETF
standard values and vendor-defined values. To explain this
phenomenon, we will use the PA-TNC Attribute Type as an example
but the other three registries work the same way. Whenever a PA-
TNC Attribute Type appears on a network, it is always
accompanied by an SMI Private Enterprise Number (PEN), also
known as a vendor ID. If this vendor ID is zero, the
accompanying PA-TNC Attribute Type is an IETF standard value
listed in the IANA registry for PA-TNC Attribute Types and its
meaning is defined in the specification listed for that PA-TNC
Attribute Type in that registry. If the vendor ID is not zero,
the meaning of the PA-TNC Attribute Type is defined by the
vendor identified by the vendor ID (as listed in the IANA
registry for SMI PENs). The identified vendor is encouraged but
not required to register with IANA some or all of the PA-TNC
Attribute Types used with their vendor ID and publish a
specification for each of these values.
This delegation of namespace is analogous to the technique used
for OIDs. It can result in interoperability problems if vendors
require support for particular vendor-specific values. However,
such behavior is explicitly prohibited by this specification,
which dictates that "Posture Collectors and Posture Validators
MUST NOT require support for particular vendor-specific PA-TNC
Attribute Types and MUST interoperate with other parties despite
any differences in the set of vendor-specific PA-TNC Attribute
Types supported (although they MAY permit administrators to
configure them to require support for specific PA-TNC Attribute
Types)." Similar requirements are included for PA Subtypes,
Remediation Parameters Types, and PA-TNC Error Codes.
Sangster & Narayan Expires April 22, 2010 [Page 59]
Internet-Draft PA-TNC October 2009
7.1. Designated Expert Guidelines
For all of the IANA registries defined by this specification,
new values are added to the registry by Expert Review with
Specification Required, using the Designated Expert process
defined in RFC 5226 [3].
This section provides guidance to designated experts so that
they may make decisions using a philosophy appropriate for these
registries.
The registries defined in this document have plenty of values.
In most cases, the IETF has approximately 2^32 values available
for it to define and each vendor the same number of values for
its use. Because there are so many values available, designated
experts should not be terribly concerned about exhausting the
set of values.
Instead, designated experts should focus on the following
requirements. All values in these IANA registries MUST be
documented in a specification that is permanently and publicly
available. IETF standard values MUST also be useful, not harmful
to the Internet, and defined in a manner that is clear and
likely to ensure interoperability.
Designated experts should encourage vendors to avoid defining
similar but incompatible values and instead agree on a single
IETF standard value. However, it is beneficial to document
existing practice.
There are several ways to ensure that a specification is
permanently and publicly available. It may be published as an
RFC. Alternatively, it may be published in another manner that
makes it freely available to anyone. However, in this latter
case, the vendor MUST supply a copy to the IANA and authorize
the IANA to archive this copy and make it freely available to
all if at some point the document becomes no longer freely
available to all through other channels.
Section 7.2 defines the new PA Subtypes. The following three
sections provide guidance to the IANA in creating and managing
the new IANA registries defined by this specification.
7.2. PA Subtypes
Section 3.5 of this specification defines several new PA
Subtypes that will be added to the PA Subtypes registry defined
Sangster & Narayan Expires April 22, 2010 [Page 60]
Internet-Draft PA-TNC October 2009
in the PB-TNC specification. Here is a list of these
assignments:
PEN Number Name Defining Specification
--- ------ ---- ----------------------
0 0 Testing RFC # Assigned to this I-D
0 1 Operating System RFC # Assigned to this I-D
0 2 Anti-Virus RFC # Assigned to this I-D
0 3 Anti-Spyware RFC # Assigned to this I-D
0 4 Anti-Malware RFC # Assigned to this I-D
0 5 Firewall RFC # Assigned to this I-D
0 6 IDPS RFC # Assigned to this I-D
0 7 VPN RFC # Assigned to this I-D
0 8 NEA Client RFC # Assigned to this I-D
Once this document becomes an RFC, these PA Subtypes should be
added to the registry for PA Subtypes defined in the PB-TNC
specification. The RFC number assigned to this document should
be associated with these assignments.
7.3. Registry for PA-TNC Attribute Types
The name for this registry is "PA-TNC Attribute Types". Each
entry in this registry should include a human-readable name, an
SMI Private Enterprise Number, a decimal integer value between 0
and 2^32-1, and a reference to the specification where the
contents of this attribute type are defined. This specification
must define the meaning of this PA-TNC attribute type and the
format and semantics of the PA-TNC Attribute Value field for PA-
TNC attributes that include the designated Private Enterprise
Number in the PA-TNC Attribute Vendor ID field and the
designated numeric value in the PA-TNC Attribute Type field.
The following entries for this registry are defined in this
document. Once this document becomes an RFC, they should become
the initial entries in the registry for PA-TNC Attribute Types.
Additional entries to this registry are added by Expert Review
with Specification Required, following the guidelines in section
7.1.
Sangster & Narayan Expires April 22, 2010 [Page 61]
Internet-Draft PA-TNC October 2009
PEN Value Name Defining Specification
--- ----- ---- ----------------------
0 0 Testing RFC # Assigned to this I-D
0 1 Attribute Request RFC # Assigned to this I-D
0 2 Product Information RFC # Assigned to this I-D
0 3 Numeric Version RFC # Assigned to this I-D
0 4 String Version RFC # Assigned to this I-D
0 5 Operational Status RFC # Assigned to this I-D
0 6 Port Filter RFC # Assigned to this I-D
0 7 Installed Packages RFC # Assigned to this I-D
0 8 PA-TNC Error RFC # Assigned to this I-D
0 9 Assessment Result RFC # Assigned to this I-D
0 10 Remediation Instructions RFC # Assigned to this I-D
0 11 Forwarding Enabled RFC # Assigned to this I-D
0 12 Factory Default Password RFC # Assigned to this I-D
0 0xffffffff Reserved RFC # Assigned to this I-D
7.4. Registry for PA-TNC Error Codes
The name for this registry is "PA-TNC Error Codes". Each entry
in this registry should include a human-readable name, an SMI
Private Enterprise Number, a decimal integer value between 0 and
2^32-1, and a reference to the specification where this error
code is defined. This specification must define the meaning of
this error code and the format and semantics of the Error
Information field for PA-TNC attributes that have a PA-TNC
Vendor ID of 0, a PA-TNC Attribute Type of PA-TNC Error, the
designated Private Enterprise Number in the PA-TNC Error Code
Vendor ID field, and the designated numeric value in the PA-TNC
Error Code field.
The following entries for this registry are defined in this
document. Once this document becomes an RFC, they should become
the initial entries in the registry for PA-TNC Error Codes.
Additional entries to this registry are added by Expert Review
with Specification Required, following the guidelines in section
7.1.
Sangster & Narayan Expires April 22, 2010 [Page 62]
Internet-Draft PA-TNC October 2009
PEN Value Name Defining Specification
--- ----- ---- ----------------------
0 0 Reserved RFC # Assigned to this I-D
0 1 Invalid Parameter RFC # Assigned to this I-D
0 2 Version Not Supported RFC # Assigned to this I-D
0 3 Attribute Type Not Supported RFC # Assigned to this I-D
7.5. Registry for PA-TNC Remediation Parameters Types
The name for this registry is "PA-TNC Remediation Parameters
Types". Each entry in this registry should include a human-
readable name, an SMI Private Enterprise Number, a decimal
integer value between 1 and 2^32-1, and a reference to the
specification where the contents of this remediation parameters
type are defined. This specification must define the meaning of
this PA-TNC Remediation Parameters Type and the format and
semantics of the Remediation Parameters field for PA-TNC
attributes that include the designated Private Enterprise Number
in the Remediation Parameters Vendor ID field and the designated
numeric value in the Remediation Parameters Type field.
The following entries for this registry are defined in this
document. Once this document becomes an RFC, they should become
the initial entries in the registry for PA-TNC Remediation
Parameters Types. Additional entries to this registry are added
by Expert Review with Specification Required, following the
guidelines in section 7.1.
PEN Value Name Defining Specification
--- ----- ---- ----------------------
0 0 Reserved RFC # Assigned to this I-D
0 1 URI RFC # Assigned to this I-D
0 2 Remediation String RFC # Assigned to this I-D
8. Acknowledgments
Thanks to the Trusted Computing Group for contributing the
initial text [8] upon which this document was based. The
authors of this draft would also like to acknowledge the
following people who have contributed to or provided substantial
input on the preparation of this document or predecessors to it:
Stuart Bailey, Roger Chickering, Lauren Giroux, Charles
Goldberg, Steve Hanna, Ryan Hurst, Meenakshi Kaushik, Greg
Kazmierczak, Scott Kelly, PJ Kirner, Houcheng Lee, Lisa
Lorenzin, Mahalingam Mani, Sung Lee, Ravi Sahita, Mauricio
Sanchez, Brad Upson, and Han Yin.
Sangster & Narayan Expires April 22, 2010 [Page 63]
Internet-Draft PA-TNC October 2009
This document was prepared using 2-Word-v2.0.template.dot.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008.
[4] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[5] Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture
Broker Protocol (PB) Compatible with TNC", draft-ietf-nea-
pb-tnc-06.txt, Work In Progress, October 2009.
[6] Phillips, A. and Davis, M., "Tags for the Identification
of Languages", RFC 4646, September 2006.
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986,
January 2005.
9.2. Informative References
[8] Trusted Computing Group, "IF-M: TLV Binding", February
2008.
[9] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
Appendix A: Use Cases
A.1. Initial Client triggered assessment
This scenario involves the assessment of an endpoint initiated
during network join. The assessment is triggered by the Posture
Broker Client (PBC) and involves collection of patch information
from both Standard Operating System (OS) Posture Collector and
vendor-specific Patch Posture Collector (PC). The assessment by
Sangster & Narayan Expires April 22, 2010 [Page 64]
Internet-Draft PA-TNC October 2009
both the vendor-specific Patch Posture Validator (PV) and
Standard OS Posture Validator result in a compliant assessment
decision which results in a compliant System Assessment Decision
to be returned by the Posture Broker Server (PBS).
+--------+ +-------+ +---------+ +--------+ +-------++--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
+--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+
| | N/W Join| | | |
| | ----->| | | |
| | Req Post. | | | |
| |<----------| | | |
| | Req Post. | | | |
|<--------------------| | | |
|Vndr X Patch Posture | | | |
|-------------------->| | | |
| |OS Posture | | | |
| |---------->| | | |
| | | Posture | | |
| | | Report | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |---------> |
| | | | | Verify |
| | | | | Posture |
| | | |------------------->|
| | | | OS Reslt | |
| | | |<---------| |
| | | | VndrX Patch Result |
| | | Assess |<-------------------|
| | | Result | |
| | |<--------| | |
| | OS Reslt | | | |
| |<----------| | | |
| VndrX Patch Result | | | |
|<--------------------| | | |
A.1.1. Message Contents
This section shows the contents of the key fields in each of the
PA messages exchanged in this use case. When necessary
additional commentary is provided to explain why certain fields
contain the shown values. Note that many of the flows shown are
Sangster & Narayan Expires April 22, 2010 [Page 65]
Internet-Draft PA-TNC October 2009
between components on the same system so no message contents are
shown.
A.1.1.1. N/W Join
This flow represents the event that causes the PBC to decide to
start an assessment of the endpoint in order to gain access to
the network. This is merely an event and does not include a
message being sent.
A.1.1.2. Request Posture (Req Post.)
This flow illustrates an invocation of the OS and patch posture
collectors requesting particular posture attributes to be sent.
Because this use case is triggered locally the contents of this
flow aren't specified by NEA.
A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)
This flow contains the PA message from the Patch Posture
Collector:
Vendor X Patch Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1 (vendor X)
type=1 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute1=123
}
}
Attribute 2 {
vendor-id=1 (vendor X)
type=2 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute2=456
}
}
}
A.1.1.4. OS Posture
This flow contains the PA message from the OS Posture Collector:
OS Posture PA Message {
Sangster & Narayan Expires April 22, 2010 [Page 66]
Internet-Draft PA-TNC October 2009
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
Product-vendor-id=311 -- Microsoft's PEN
Product-name="Windows Vista"
}
}
Attribute 2 {
vendor-id=0
type=3 (numeric version)
length
Value = {
major-version=6 -- Vista is version 6.0
minor-version=0
build-number=456789
service-pack-major=0 -- No service packs
service-pack-minor=0
}
}
}
A.1.1.5. Posture Report
This flow contains the PB message containing the PA messages
from the Patch and OS Posture Collectors; the message content is
described in the PB-TNC specification.
A.1.1.6. Verify Posture
This flow illustrates an invocation of the OS and patch Posture
Validators requesting verification of the posture attributes
received. Because this flow happens locally within the NEA
server, NEA does not specify the message contents.
A.1.1.7. OS Posture Result (OS Reslt)
This flow contains the PA message (Posture Assessment Result)
from the OS Posture Validator
OS Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
Sangster & Narayan Expires April 22, 2010 [Page 67]
Internet-Draft PA-TNC October 2009
length
Value = {
assessment-result=0 (compliant)
}
}
}
A.1.1.8. Vendor X Patch Result (VndrX Patch Result)
This flow contains the PA message (Posture Assessment Result)
from the Vendor X Patch Posture Validator
Patch Vendor X Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
A.1.1.9. Assessment Result (Assess Result)
This flow contains the PB message containing the system
assessment result computed by the Posture Broker Server and the
PA messages from the Patch and OS Posture Validators; the
message content is described in the PB-TNC specification.
A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)
These flows illustrate an invocation of the OS and Vendor X
Patch Posture Collectors to receive the posture assessment
results. Because this flow is triggered locally, NEA does not
specify the contents of this flow.
A.2. Server initiated Assessment with Remediation
This scenario involves the assessment of an endpoint initiated
by the NEA Server. The assessment is triggered by the Posture
Broker Server and involves collection of Anti-Virus attributes
for two Anti-Virus components running on the endpoint. The
endpoint is assessed to be compliant by one of the vendor
(Vendor X) anti-virus Posture Validators and non-complaint by
the other vendor (Vendor Y) anti-virus Posture Validator. Based
Sangster & Narayan Expires April 22, 2010 [Page 68]
Internet-Draft PA-TNC October 2009
upon the Posture Broker Server's policy, this results in a non-
compliant system assessment decision to be returned by the
Posture Broker Server. The Posture Broker Server also returns
remediation instructions for the endpoint as part of the
response.
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | ------->| | |
| | | | Create | |
| | | |Post. Req | |
| | | |--------->| |
| | | |Create Posture Req |
| | | |----------+--------->|
| | | | Vndr Y AV Post Req |
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post. Req | |
| | | Posture |<---------| |
| | | Request | | |
| | Vndr X AV |<--------| | |
| | Post. Req | | | |
| |<----------| | | |
| Vndr Y AV | | | |
| Posture Req | | | |
+<---------+-----------| | | |
| Vndr Y AV Posture | | | |
+----------+---------->| | | |
| | Vndr X AV | | | |
| | Posture | | | |
| |---------->| Posture | | |
| | |Response | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |--------->| |
| | | | Verify Posture |
| | | |----------+--------->|
| | | |Vndr Y AV Post Result|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post Reslt| |
| | | Assess |<---------| |
| | | Result | | |
Sangster & Narayan Expires April 22, 2010 [Page 69]
Internet-Draft PA-TNC October 2009
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
+<---------+-----------| | | |
A.2.1. Message Contents
This section shows the contents of the key fields in each of the
PA messages exchanged in this use case. When necessary
additional commentary is provided to explain why certain fields
contain the shown values. Note that many of the flows shown are
between components on the same system so no message contents are
shown.
A.2.1.1. N/W Join
This flow represents the event that causes the PBS to decide to
start an assessment of the endpoint in order to gain access to
the network. This is merely an event and does not include a
message being sent.
A.2.1.2. Create Posture Request (Create Posture Req.)
This flow illustrates an invocation of the Vendor X and Vendor Y
Anti-Virus Posture Validators enabling posture request
attributes to be created. Because this use case is triggered
locally, NEA does not specify the contents of this flow.
A.2.1.3. Vendor Y AV Posture Request (Vndr Y AV Posture Req)
This flow contains the PA message (Posture Request) from the
Vendor Y Anti-Virus Posture Validator
Vendor Y AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
Vendor-id=1 (Vendor Y)
Type=2 (Vendor Y attribute, Extended-Dat-Version)
}
Sangster & Narayan Expires April 22, 2010 [Page 70]
Internet-Draft PA-TNC October 2009
}
}
A.2.1.4. Vendor X AV Posture Request (Vndr X AV Post. Req)
This flow contains the PA message (Posture Request) from the
Vendor X Anti-Virus Posture Validator
Vendor X AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=1 (Vendor X)
Type=1 (Vendor X attribute, Scan-Engine-Version)
Vendor-id=0 (IETF Standard)
Type=5 (Standard, Operational-Status)
}
}
}
A.2.1.5. Posture Request
This flow contains the PB message containing the PA messages
from the Vendor X and Vendor Y Anti-Virus Posture Validators;
the message content is described in the PB-TNC specification.
A.2.1.6. Posture Request (Vndr X AV Post Req & Vndr Y AV Post Req)
These flows illustrate an invocation of the Vendor X and Vendor
Y Anti-Virus Posture Collectors to process the Posture Request
and return the particular posture attributes requested. Because
this flow is triggered locally, NEA does not specify the
contents of this flow.
A.2.1.7. Vendor Y AV Posture (Vndr Y AV Posture)
This flow contains the PA message (response to the Posture
Request) from the Vendor Y Anti-Virus Posture Collector.
Vendor Y AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
Sangster & Narayan Expires April 22, 2010 [Page 71]
Internet-Draft PA-TNC October 2009
length
Value = {
product-vendor-id=12345 (vendor Y)
product-id=987 (AV product id from vendor Y)
product-name="Vendor Y Anti-Virus"
}
}
Attribute 2 {
vendor-id=2 (vendor Y)
type=2 (vendor Y attribute, DAT-Version)
length
Value = {
DAT-version=5678
}
}
}
A.2.1.8. Vendor X AV Posture (Vndr X AV Posture)
This flow contains the PA message (response to the Posture
Request) from the Vendor X Anti-Virus Posture Collector.
Vendor X AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1
type=1 (vendor X attribute, Scan-Engine-Version)
length
Value = {
scan-engine-version=1234
}
}
Attribute 2 {
vendor-id=0 (IETF Standard)
type=5 (Standard, Operational-Status)
length
Value = {
status=2 (installed but non-operational)
result=0 (unknown)
last use="" (never used)
}
}
}
Sangster & Narayan Expires April 22, 2010 [Page 72]
Internet-Draft PA-TNC October 2009
A.2.1.9. Posture Response
This flow contains the PB message containing the PA messages
from the Vendor X and Vendor Y Anti-Virus Posture Collectors;
the message content is described in the PB-TNC specification.
A.2.1.10. Verify Posture
This flow illustrates an invocation of the Vendor X and Vendor Y
Anti-Virus Posture Validators requesting verification of the
posture attributes received. Because this flow happens locally
within the NEA server, NEA does not specify the message
contents.
A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post Result)
This flow contains the PA message (Posture Assessment Result)
from the Vendor Y Anti-Virus Posture Validator
Vendor Y AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post Reslt)
This flow contains the PA message (Posture Assessment Result)
from the Vendor X Anti-Virus Posture Validator
Vendor X AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}
Sangster & Narayan Expires April 22, 2010 [Page 73]
Internet-Draft PA-TNC October 2009
A.2.1.13. Assessment Result (Assess Result)
This flow contains the PB message containing the system
assessment result computed by the Posture Broker Server and the
PA messages from the Vendor X and Vendor Y Anti-Virus Posture
Validators; the message content is described in the PB-TNC
specification.
A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post
Reslt)
These flows illustrate an invocation of the Vendor X and Vendor
Y Anti-Virus Posture Collectors to receive the posture
assessment results. Because this flow is triggered locally, NEA
does not specify the contents of this flow.
A.3. Client triggered re-assessment
This scenario involves the re-assessment of an endpoint as a
result of enabling a software component on the endpoint. The
endpoint has two VPN client software components, one from vendor
X for the user's home network and other from vendor Y for the
network that the endpoint is currently accessing. The
assessment is triggered when the user tries to use the Vendor X
VPN client; this is a violation of the assessment policy. The
Posture Broker Client triggers the posture assessment when it
receives a notification from the VPN Posture Collector about the
change to the operational state of the VPN component on the
endpoint. Note that the VPN Posture Collector may support
standard attributes and some vendor defined attributes from
vendor X and vendor Y's namespaces. This use case does not
leverage vendor defined attributes. The assessment involves
verification of the standard VPN posture attributes by the
standard VPN Posture Validator that results in a non-compliant
assessment result.
This use case relies on the use of multiple Posture Collector
IDs for a single Posture Collector as described in section 3.3
of the PA-TNC specification. In this example, the Posture
Collector will obtain two Posture Collector IDs to a single
Posture Collector (Standard VPN PC) and the Posture Collector
will generate two separate PA messages each using a different ID
to report the posture for Vendor X and Vendor Y VPN Clients.
The Posture Broker Client will associate the assigned IDs in the
PB message sent to the NEA Server. This entire behavior will be
completely opaque to the NEA Server, which will handle the PB
Sangster & Narayan Expires April 22, 2010 [Page 74]
Internet-Draft PA-TNC October 2009
message as if there were two VPN Posture Collectors on the NEA
Client.
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standrd| |Standard|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
Enble| | | | | |
---->| | | | | |
| VPN Status Change | | | |
|--------------------->| Posture | | |
| | | Change | | |
| | |-------->| | |
| | |Req. Post| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |VPNY Post| | |
| | |-------->| | |
| | | | Posture | |
| | | | Report | |
| | | |--------->| |
| | | | |Vrfy Post.|
| | | | |--------->|
| | | | |VPN PRslt |
| | | | Assess |<---------|
| | | | Result | |
| | | |<---------| |
| | |VPN PRslt| | |
| | |<--------| | |
A.3.1. Message Contents
This section shows the contents of the key fields in each of the
PA messages exchanged in this use case. When necessary
additional commentary is provided to explain why certain fields
contain the shown values. Note that many of the flows shown are
between components on the same system so no message contents are
shown.
Sangster & Narayan Expires April 22, 2010 [Page 75]
Internet-Draft PA-TNC October 2009
A.3.1.1. Enable VPN Client (Enble)
This flow represents the end user triggered event of starting
the VPN Client software from Vendor X. This is merely an event
and does not include a message being sent.
A.3.1.2. Notify Status Change (VPN Status Change)
This flow represents the detection of the active state of the
Vendor X VPN Client software by the VPN Posture Collector. This
is merely an event and does not include a message being sent.
A.3.1.3. Notify Posture Change (Posture Change)
This flow represents the notification of the VPN posture change
sent from the VPN Posture Collector to the Standard Posture
Broker Client. This is merely an event and does not include a
message being sent.
A.3.1.4. Request Posture (Req. Post)
This flow illustrates an invocation of the VPN Posture Collector
requesting particular posture attributes to be sent. Because
this use case is triggered locally, NEA does not specify the
contents of this flow.
A.3.1.5. Inspect/Request Info (Ins/Rq Info)
This flow illustrates the acquisition of the posture information
by the VPN Posture Collector from the Vendor X and Vendor Y VPN
Client components. Because this flow is triggered locally, NEA
does not specify the message contents.
A.3.1.6. Vendor X VPN Posture (VPNX Post)
This flow contains the PA message from the VPN Posture Collector
describing the Vendor X VPN Client's posture:
Vendor X VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=9876 (vendor X)
product-id=567 (VPN client identifier for Vndr X)
Sangster & Narayan Expires April 22, 2010 [Page 76]
Internet-Draft PA-TNC October 2009
product-name="Vendor X VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T12:00:00Z"
}
}
A.3.1.7. Vendor Y VPN Posture (VPNY Post)
This flow contains the PA message from the VPN Posture Collector
including the Vendor Y VPN Client's posture:
Vendor Y VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=Vendor Y
product-id=234 (VPN client identifier for Vndr Y)
product-name="Vendor Y VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T14:05:00Z"
}
}
}
Sangster & Narayan Expires April 22, 2010 [Page 77]
Internet-Draft PA-TNC October 2009
A.3.1.8. Posture Report
This flow contains the PB message containing the PA message from
the VPN Posture Collector; the message content is described in
the PB-TNC specification.
A.3.1.9. Verify Posture (Vrfy Post.)
This flow illustrates an invocation of the VPN Posture Validator
requesting verification of the posture attributes received.
Because this flow happens locally within the NEA server, NEA
does not specify the message contents.
A.3.1.10. VPN Posture Result (VPN PRslt)
This flow contains the PA message (Posture Assessment Result)
from the VPN Posture Validator
VPN Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}
A.3.1.11. Assessment Result (Assess Result)
This flow contains the PB message containing the system
assessment result computed by the Posture Broker Server and the
PA messages from the VPN Posture Validator; the message content
is described in the PB-TNC specification.
A.3.1.12. Posture Result (VPN PRslt)
This flow illustrates an invocation of the VPN Posture Collector
to receive the posture assessment result. Because this flow is
triggered locally, NEA does not specify the contents of this
flow.
Appendix B: Evaluation Against NEA Requirements
Sangster & Narayan Expires April 22, 2010 [Page 78]
Internet-Draft PA-TNC October 2009
This section evaluates the PA-TNC protocol against the
requirements defined in the NEA Requirements document. Each
subsection considers a separate requirement from the NEA
Requirements document. Only common requirements (C-1 through C-
10) and PA requirements (PA-1 through PA-6) are considered,
since these are the only ones that apply to PA.
B.1. Evaluation Against Requirements C-1
Requirement C-1 says:
C-1 NEA protocols MUST support multiple round trips between
the NEA Client and NEA Server in a single assessment.
PA-TNC meets this requirement. It allows an unlimited number of
round trips between the NEA Client and NEA Server.
B.2. Evaluation Against Requirements C-2
Requirement C-2 says:
C-2 NEA protocols SHOULD provide a way for both the NEA Client
and the NEA Server to initiate a posture assessment or
reassessment as needed.
PA-TNC meets this requirement. PA-TNC is designed to work
whether the NEA Client or the NEA Server initiates a posture
assessment or reassessment.
B.3. Evaluation Against Requirements C-3
Requirement C-3 says:
C-3 NEA protocols including security capabilities MUST be
capable of protecting against active and passive attacks by
intermediaries and endpoints including prevention from replay
based attacks.
Security for PA-TNC messages being sent over the network is
provided through PT protocol security. Therefore, PA-TNC
does not include any security capabilities. Since this
requirement only applies to NEA protocols "including security
capabilities", this specification is not subject to this
requirement (see section 5.2).
Sangster & Narayan Expires April 22, 2010 [Page 79]
Internet-Draft PA-TNC October 2009
B.4. Evaluation Against Requirements C-4
Requirement C-4 says:
C-4 The PA and PB protocols MUST be capable of operating over
any PT protocol. For example, the PB protocol must provide a
transport independent interface allowing the PA protocol to
operate without change across a variety of network protocol
environments (e.g. EAP/802.1X, PANA, TLS and IKE/IPsec).
PA-TNC meets this requirement. PA-TNC can operate over any PT
protocol that meets the requirements for PT stated in the NEA
Requirements document. PA-TNC does not have any dependencies on
specific details of the underlying PT protocol.
B.5. Evaluation Against Requirements C-5
Requirement C-5 says:
C-5 The selection process for NEA protocols MUST evaluate and
prefer the reuse of existing open standards that meet the
requirements before defining new ones. The goal of NEA is not
to create additional alternative protocols where acceptable
solutions already exist.
Based on this requirement, PA-TNC should receive a strong
preference. PA-TNC is equivalent with IF-M 1.0, an open TCG
specification. Other specifications from TCG and other groups
are also under development based on the IF-M 1.0 specification.
Selecting PA-TNC as the basis for the PA protocol will ensure
compatibility with IF-M 1.0, with these other specifications,
and with their implementations.
B.6. Evaluation Against Requirements C-6
Requirement C-6 says:
C-6 NEA protocols MUST be highly scalable; the protocols MUST
support many Posture Collectors on a large number of NEA Clients
to be assessed by numerous Posture Validators residing on
multiple NEA Servers.
PA-TNC meets this requirement. PA-TNC supports an unlimited
number of Posture Collectors, Posture Validators, NEA Clients,
and NEA Servers. It also is quite scalable in many other
aspects as well. A PA-TNC message can contain up to 2^32-1
octets and about 2^28 PA-TNC attributes. Each organization with
Sangster & Narayan Expires April 22, 2010 [Page 80]
Internet-Draft PA-TNC October 2009
an SMI Private Enterprise Number is entitled to define up to
2^32 vendor-specific PA-TNC Attribute Types, 2^16 vendor-
specific PA-TNC Product IDs, and 2^32 vendor-specific PA-TNC
Error Codes. Each attribute can contain almost 2^32 octets. It
is generally not advisable or necessary to send this much data
in a NEA assessment, but still PA-TNC is highly scalable and
meets requirement C-6 easily.
B.7. Evaluation Against Requirements C-7
Requirement C-7 says:
C-7 The protocols MUST support efficient transport of a large
number of attribute messages between the NEA Client and the NEA
Server.
PA-TNC meets this requirement. Each PA-TNC message can contain
about 2^28 PA-TNC attributes. PA-TNC supports up to 2^32 round
trips in a session so the maximum number of attribute messages
that can be sent in a single session is actually about 2^50.
However, it is generally inadvisable and unnecessary to send a
large number of messages in a NEA assessment. As for
efficiency, PA-TNC adds only 12 octets of overhead per attribute
and 8 octets per message (which is negligible on a per-attribute
basis).
B.8. Evaluation Against Requirements C-8
Requirement C-8 says:
C-8 NEA protocols MUST operate efficiently over low bandwidth
or high latency links.
PA-TNC meets this requirement. A PA-TNC exchange is envisioned
(based on current deployment experience) to involve one or two
round trips with less than 500 octets of PA-TNC messages. Of
course, use of vendor-specific PA-TNC attribute types could
expand the assessment. However, PA-TNC itself imposes an
overhead of only 8 octets per PA-TNC message and 12 octets per
attribute.
B.9. Evaluation Against Requirements C-9
Requirement C-9 says:
Sangster & Narayan Expires April 22, 2010 [Page 81]
Internet-Draft PA-TNC October 2009
C-9 For any strings intended for display to a user, the
protocols MUST support adapting these strings to the user's
language preferences.
PA-TNC meets this requirement. The only field included in a PB-
TNC attribute for display to the user includes a language tag
that could be selected based upon the user's PB-TNC negotiated
preferred language for the assessment (see section 4.10 of the
PB-TNC specification). With this exception, all of the strings
in the standard PA-TNC attributes are intended for logging and
programmatic comparisons.
If any vendor-specific PA-TNC attribute types or future IETF
Standard PA-TNC Attribute Types include strings that are
intended for display to a user, they should be translated to the
user's preferred language. The Posture Broker Server will need
to expose the user's preferences to the Posture Validators
through whatever API or protocol is used to connect those
components. However, that is all out of scope for this
specification.
B.10. Evaluation Against Requirements C-10
Requirement C-10 says:
C-10 NEA protocols MUST support encoding of strings in UTF-8
format.
PA-TNC meets this requirement. All strings in the PA-TNC
protocol are encoded in UTF-8 format. This allows the protocol
to support a wide range of languages efficiently.
B.11. Evaluation Against Requirements C-11
Requirement C-11 says:
C-11 Due to the potentially different transport characteristics
provided by the underlying candidate PT protocols, the NEA
Client and NEA Server MUST be capable of becoming aware of and
adapting to the limitations of the available PT protocol. For
example, some PT protocol characteristics that might impact the
operation of PA and PB include restrictions on: which end can
initiate a NEA connection, maximum data size in a message or
full assessment, upper bound on number of roundtrips, and
ordering (duplex) of messages exchanged. The selection process
for the PT protocols MUST consider the limitations the candidate
PT protocol would impose upon the PA and PB protocols.
Sangster & Narayan Expires April 22, 2010 [Page 82]
Internet-Draft PA-TNC October 2009
PA-TNC meets this requirement. The design of the PA-TNC
protocol emphasizes efficient transport of information in order
to maximize its usability in constrained PT environments. Local
APIs could allow Posture Collectors and Posture Validators to
discover when they are operating in a less constrained
deployment and then make use of more verbose attributes.
Similarly, Posture Collectors could choose to not send or use
smaller attributes (including assertions from previous
assessments) when faced with a very constrained network
connection.
B.12. Evaluation Against Requirements PA-1
Requirement PA-1 says:
PA-1 The PA protocol MUST support communication of an
extensible set of NEA standards defined attributes. These
attributes will be uniquely identifiable from non-standard
attributes.
PA-TNC meets this requirement. Each attribute is identified
with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.
IETF Standard PA-TNC Attribute Types use a vendor ID of zero
(0), in contrast with vendor-specific PA-TNC Attribute Types,
which will use the vendor's SMI Private Enterprise Number as the
vendor ID. The IANA will maintain a registry of PA-TNC
Attribute Types with new values added by Expert Review with
Specification Required, as described in the IANA Considerations
section of this specification. Thus, the set of standard
attribute types is extensible, but all standard attribute types
are uniquely identifiable.
B.13. Evaluation Against Requirements PA-2
Requirement PA-2 says:
PA-2 The PA protocol MUST support communication of an
extensible set of vendor-specific attributes. These attributes
will be segmented into uniquely identifiable vendor specific
name spaces.
PA-TNC meets this requirement. Each attribute is identified
with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.
Vendor-defined PA-TNC Attribute Types use the vendor's SMI
Private Enterprise Number as the PA-TNC Attribute Vendor ID.
Each vendor can define up to 2^32 PA-TNC Attribute Types, using
its own internal processes to manage its set of attribute types.
Sangster & Narayan Expires April 22, 2010 [Page 83]
Internet-Draft PA-TNC October 2009
The IANA is not involved, other than the initial assignment of
the vendor's SMI Private Enterprise Number. Thus, the set of
vendor-specific attributes is segmented into uniquely
identifiable vendor-specific name spaces.
B.14. Evaluation Against Requirements PA-3
Requirement PA-3 says:
PA-3 The PA protocol MUST enable a Posture Validator to make
one or more requests for attributes from a Posture Collector
within a single assessment. This enables the Posture Validator
to reassess the posture of a particular endpoint feature or to
request additional posture including from other parts of the
endpoint.
PA-TNC meets this requirement. The Attribute Request attribute
type is an IETF Standard PA-TNC Attribute Type that permits a
Posture Validator to send to one or more Posture Collectors a
request for one or more attributes. This attribute may be sent
at any point in the posture assessment process and may in fact
be sent more than once if the Posture Validator needs to first
determine the type of operating system and then request certain
attributes specific to that operating system, for example.
B.15. Evaluation Against Requirements PA-4
Requirement PA-4 says:
PA-4 The PA protocol MUST be capable of returning attributes
from a Posture Validator to a Posture Collector. For example,
this might enable the Posture Collector to learn the specific
reason for a failed assessment and to aid in remediation and
notification of the system owner.
PA-TNC meets this requirement. A Posture Validator can easily
send attributes to one or more Posture Collectors.
B.16. Evaluation Against Requirements PA-5
Requirement PA-5 says:
PA-5 The PA protocol SHOULD provide authentication, integrity,
and confidentiality of attributes communicated between a Posture
Collector and Posture Validator. This enables end-to-end
security across a NEA deployment that might involve traversal of
several systems or trust boundaries.
Sangster & Narayan Expires April 22, 2010 [Page 84]
Internet-Draft PA-TNC October 2009
PA-TNC does not include an explicit PA-level security mechanism
but does lay a foundation allowing attribute level security
protections to be added later. As an existence proof, the NEA
working group considered an internet draft proposal capable of
encapsulating PA attributes within a CMS security wrapper in a
new attribute type. This proposal offered the protections
described in this requirement. However the NEA WG decided that
the use cases in scope for the working group did not require PA-
level security. The use cases involving PA message traversal of
multiple systems or trust boundaries were considered out of
scope, therefore a Posture Validator to Posture Collector end-
to-end security protection was considered to not be required.
Instead PA-TNC attributes are protected by the PT layer
authentication, integrity and confidentiality support. This
protects the attributes communicated between the Posture
Transport Client and Posture Transport Server. Because the
Posture Collector is in the same address space as the Posture
Broker Client and Posture Transport Client and the Posture
Validator is in the same address space as the Posture Broker
Server and Posture Transport Server, the underlying broker and
transport components are deemed trusted with respect to not
tampering with the PA messages (see trust model in section 5.1
for details.) Encrypting the PA-TNC messages would not prevent
a hostile broker or transport component from attacking the
messages.
B.17. Evaluation Against Requirements PA-6
Requirement PA-6 says:
PA-6 The PA protocol MUST be capable of carrying attributes
that contain non-binary and binary data including encrypted
content.
PA-TNC meets this requirement. PA-TNC attributes can contain
non-binary and binary data including encrypted content. For
examples, see the attribute type definitions contained in this
specification.
Sangster & Narayan Expires April 22, 2010 [Page 85]
Internet-Draft PA-TNC October 2009
Authors' Addresses
Paul Sangster
Symantec Corporation
6825 Citrine Drive
Carlsbad, CA 92009 USA
Email: Paul_Sangster@symantec.com
Kaushik Narayan
Cisco Systems Inc.
10 West Tasman Drive
San Jose, CA 95134
Email: kaushik@cisco.com
Sangster & Narayan Expires April 22, 2010 [Page 86]
