RFC 5792
PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
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 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 ensures 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.
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 namespace 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 namespace. 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 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 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 Integer 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. 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
Enabled 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 Posture Collectors proactively send
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 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 1-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.
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 namespace 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.
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-length fields in the PA-TNC Attribute Header and
the fixed-length 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.
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.
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 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.
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-length fields in the PA-TNC Attribute Header and
the fixed-length 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.
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
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 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
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.
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.
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 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 blocked and
non-blocked ports for a particular protocol. To be more 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.
(page 31 continued on part 3)
