RFC 5792
PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
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 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-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.
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 protocol can support that many). If this number
is not sufficient, specialized patch management software should be
employed that can simply report compliance with a pre-established
patch policy.
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 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-length fields in the PA-TNC Attribute Header
and the fixed-length 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.
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 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:
Integer 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 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 | Copy of 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.
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.
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 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.
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 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 | Copy of 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
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.
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.
4.2.10. Remediation Instructions
This PA-TNC attribute sent by the Posture Validator to the Posture
Collector 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 than one
Remediation Instructions attribute 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 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 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:
Integer 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 Type
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.
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 Type 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
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 composed 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 SHOULD NOT send the
Forwarding Enabled attribute unless 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 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.
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 namespace collisions or misinterpretations. In order to avoid collisions, PA-TNC uses the well-established SMI Private Enterprise Numbers as vendor IDs to define separate namespaces 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 namespace 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 TNC architecture envisions some trust relationships between the processing elements of the PA-TNC protocol. The following subsections 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 service5.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 send malicious remediation instructions that do not fix or that cause damage to the endpoint5.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 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
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 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
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 Validators 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 launches 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.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.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 bidirectionally 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 the Posture Collector or Posture Validator, sending very large messages containing many attributes, and repeatedly asking for resource-intensive operations.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 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 that 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 a 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 namespace 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 to 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 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 (in section 4.1), 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.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 have been added to the PA Subtypes registry defined in the PB- TNC specification. Here is a list of these assignments: PEN Integer Name Defining Specification --- ------- ---- ---------------------- 0 0 Testing RFC 5792 0 1 Operating System RFC 5792 0 2 Anti-Virus RFC 5792 0 3 Anti-Spyware RFC 5792 0 4 Anti-Malware RFC 5792 0 5 Firewall RFC 5792 0 6 IDPS RFC 5792 0 7 VPN RFC 5792 0 8 NEA Client RFC 5792 These PA Subtypes have been added to the registry for PA Subtypes defined in the PB-TNC specification, with this RFC as the reference.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. They are 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. PEN Integer Name Defining Specification --- ------- ---- ---------------------- 0 0 Testing RFC 5792 0 1 Attribute Request RFC 5792 0 2 Product Information RFC 5792 0 3 Numeric Version RFC 5792 0 4 String Version RFC 5792 0 5 Operational Status RFC 5792 0 6 Port Filter RFC 5792 0 7 Installed Packages RFC 5792 0 8 PA-TNC Error RFC 5792 0 9 Assessment Result RFC 5792 0 10 Remediation Instructions RFC 5792 0 11 Forwarding Enabled RFC 5792 0 12 Factory Default Password RFC 5792 Enabled 0 0xffffffff Reserved RFC 57927.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. They are 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.
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 Invalid Parameter RFC 5792
0 2 Version Not Supported RFC 5792
0 3 Attribute Type Not Supported RFC 5792
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.
They are 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 Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 URI RFC 5792
0 2 Remediation String RFC 5792
8. Acknowledgments
Thanks to the Trusted Computing Group for contributing the initial
text [8] upon which this document was based. The authors 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.
(next page on part 4)
