[Nea] NEA proposals received this morning
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Nea] NEA proposals received this morning
Here are the Internet Drafts that I have received in response
to the request for NEA protocol proposals. They were submitted
to the internet-drafts email address this morning but may take
some time to appear on the IETF web site.
Thanks,
Steve
Network Working Group P. Sangster
Internet Draft Symantec
Intended status: Proposed Standard
Expires: August 2008
February 18, 2008
PA-TNC Security: A Posture Attribute (PA) Security Protocol
Compatible with TNC
draft-sangster-nea-pa-tnc-security-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or
she becomes aware will be disclosed, in accordance with Section
6 of BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Sangster Expires August 7, 2008 [Page 1]
Internet-Draft PA-TNC Security February 2008
This document specifies PA-TNC security, a Posture Attribute
Security Protocol identical to the Trusted Computing Group's
IF-M Security Binding to CMS 1.0 protocol. PA Security offers
origin authentication, integrity and optional confidentiality
protection for one or more PA attributes. The document then
evaluates PA-TNC Security against the requirements defined in
the NEA Requirements specification [5].
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [1].
Table of Contents
1. Introduction.............................................. 3
1.1. Background on Trusted Computing Group................ 4
1.2. Background on Trusted Network Connect................ 4
1.3. Submission of This Document.......................... 4
1.4. Prerequisites........................................ 5
1.5. Terminology.......................................... 5
2. PA-TNC Security Description............................... 6
2.1. Rationale for Using CMS ............................. 6
2.2. PA-TNC Attributes Protected by CMS .................. 6
2.3. CMS Protected Content Attribute...................... 7
2.3.1. CMS Content Info and Content Types.............. 7
2.3.2. CMS Signed-Data................................. 8
2.3.2.1. CMS Signed-Data Example................... 11
2.3.2.2. Signed-Data Required Algorithms........... 13
2.3.3. CMS Enveloped-Data ............................ 14
2.3.3.1. CMS Enveloped-Data Example................ 16
2.3.3.2. Enveloped-Data Required Key Management.... 18
2.3.3.3. Enveloped-Data Required Algorithms........ 19
2.4. Security Capabilities Attribute..................... 21
2.4.1. paTncSecurityCapabilities Within Signed-Data... 22
2.4.2. paTncSecurityCapabilities ASN.1................ 23
2.5. CMS Error Code Attribute............................ 24
2.5.1. paTncErrorCode Within Signed-Data.............. 24
2.5.2. paTncErrorCode ASN.1........................... 25
2.5.3. IETF Standard paTncErrorCode Values ........... 26
2.6. Nonce CMS Attribute................................. 29
2.6.1. paTncNonce Within Signed-Data ................. 30
2.6.2. paTncNonce CMS Attribute ASN.1................. 30
2.6.3. paTncNonce CMS Attribute Example............... 32
3. Evaluation Against NEA Requirements...................... 33
Sangster Expires August 7, 2008 [Page 2]
Internet-Draft PA-TNC Security February 2008
3.1. Evaluation Against Requirement C-1 ................. 33
3.2. Evaluation Against Requirement C-2 ................. 34
3.3. Evaluation Against Requirement C-3 ................. 34
3.4. Evaluation Against Requirement C-4 ................. 34
3.5. Evaluation Against Requirement C-5 ................. 35
3.6. Evaluation Against Requirement C-6 ................. 35
3.7. Evaluation Against Requirement C-7 ................. 35
3.8. Evaluation Against Requirement C-8 ................. 36
3.9. Evaluation Against Requirement C-9 ................. 36
3.10. Evaluation Against Requirement C-10................ 36
3.11. Evaluation Against Requirement PA-1................ 37
3.12. Evaluation Against Requirement PA-2................ 37
3.13. Evaluation Against Requirement PA-3................ 37
3.14. Evaluation Against Requirement PA-4................ 38
3.15. Evaluation Against Requirement PA-5................ 38
3.16. Evaluation Against Requirement PA-6................ 38
4. Security Considerations.................................. 39
4.1. Countermeasures to PA-TNC Threats................... 39
4.1.1. Threats Addressed by Signed Attributes......... 40
4.1.2. Threats Addressed by Encrypted Attributes...... 41
4.2. Potential Threats Against PA-TNC use of CMS......... 41
4.2.1. Cryptography .................................. 41
4.2.2. Threats to Keys................................ 42
4.2.3. Denial of Service.............................. 43
5. IANA Considerations...................................... 44
5.1. Registry for IETF Standard PA-TNC Error Codes ...... 44
6. Acknowledgments.......................................... 45
7. References............................................... 46
7.1. Normative References................................ 46
7.2. Informative References.............................. 46
Author's Addresses.......................................... 47
Intellectual Property Statement ............................ 47
Disclaimer of Validity...................................... 48
1. Introduction
This document specifies PA-TNC security, a Posture Attribute
Security Protocol identical to the Trusted Computing Group's
IF-M Security Binding to CMS 1.0 protocol [7]. PA Security
offers origin authentication, integrity and optional
confidentiality protection for one or more PA attributes
defined in the PA-TNC specification [6]. The document then
evaluates PA-TNC Security capabilities against the requirements
defined in the NEA Requirements specification [5].
Sangster Expires August 7, 2008 [Page 3]
Internet-Draft PA-TNC Security February 2008
1.1. Background on Trusted Computing Group
The Trusted Computing Group (TCG) is a consortium that develops
specifications for trusted (secure) computing. Since its
formation in 2003, TCG has published specifications for a
variety of technologies such as: Trusted Platform Module (TPM),
TCG Software Stack (TSS), Mobile Trusted Module (MTM), and
Trusted Network Connect (TNC).
TCG members include more than 175 organizations that design,
build, sell, or use trusted computing technology. Membership
is open to any organization that signs the membership agreement
and pays the annual membership fee. Non-members are welcome to
implement the TCG specifications. Many open source
implementers have already done so.
1.2. Background on Trusted Network Connect
Starting in 2004, the TCG has defined and published the Trusted
Network Connect (TNC) architecture and standards for network
access control. These standards enable multi-vendor
interoperability at all points in the architecture and have
been widely adopted and deployed.
1.3. Submission of This Document
The IETF has recently chartered the Network Endpoint Assessment
(NEA) working group to develop several standards in the same
area as TNC. In order to avoid the development of multiple
incompatible standards, the TCG is offering several of its TNC
standards to the IETF as candidates for standardization in the
IETF also. This document is equivalent to TCG's IF-M Security:
Bindings to CMS 1.0.
Consistent with IETF's requirements for standards track
documents, the TCG has authorized the editors of this document
to offer the specification to the IETF without restriction. As
with other Internet-Drafts, the IETF Trust owns the copyright
to this document. The IETF may modify this document, ignore
it, publish it as an RFC, or take any other action. If the
IETF decides to adopt a later version of this document as an
RFC, the TCG plans to publish a specification for an equivalent
TNC protocol to ensure compatibility.
Sangster Expires August 7, 2008 [Page 4]
Internet-Draft PA-TNC Security February 2008
1.4. Prerequisites
This document does not define an architecture or reference
model. Instead, it defines a security protocol for protecting
PA-TNC attributes consistent with the reference model described
in the NEA Requirements specification. The reader is assumed
to be thoroughly familiar with the NEA Requirements document
particularly those aspects involving PA and its security model.
Similarly, the reader should have an understanding of the PA-
TNC protocol and its use of attributes. No familiarity with
TCG specifications is assumed.
This specification applies and frequently references the
Cryptographic Message Syntax (CMS) [3] to a set of one or more
PA-TNC attributes in order to protect the attributes from a
variety of threats. The readers needs to have a strong working
knowledge of CMS and would benefit from a reading of other
technologies that have applied CMS for similar purposes such as
S/MIME [8].
1.5. Terminology
This document reuses the terminology defined in the NEA
Requirements document, PA-TNC internet draft and the CMS
specification. No new terminology is introduced by PA-TNC
security.
One confusing area of terminology in this document is the
overloaded use of the term 'attribute'. The PA-TNC
specification defines a set of attributes as type-length-value
(TLV) tuples. This specification uses 'attribute' or 'PA-TNC
attribute' to refer to the TLV. When a portion of the TLV
mentioned it will be described as for example 'attribute type'
meaning the PA-TNC attribute's type field.
The other use of the term 'attribute' comes from the CMS
specification. A CMS attribute is additional information
associated with the CMS content but not included in the data
portion of the content field. This specification uses the
signedAttrs field in a signed-data to store CMS attributes.
Whenever this specification is referring to a CMS oriented
attribute (as opposed to a PA-TNC attribute) it will be
referred to as 'CMS attribute'.
Sangster Expires August 7, 2008 [Page 5]
Internet-Draft PA-TNC Security February 2008
2. PA-TNC Security Description
2.1. Rationale for Using CMS
CMS was selected to protect the PA-TNC attributes because of
its suitability to provide security protections for a messaging
oriented protocol. Messaging protocols may wish to avoid a
potentially lengthy set of roundtrip message exchanges to setup
a security association prior to being able to send protected
messages. PA-TNC message senders may only wish to protect one
of several attributes exchanged with another party. Such
additional roundtrips can cause latency issues that could
result in timeouts or other undesirable behavior in some
underlying protocols (e.g. 802.1X).
It is envisioned that during a PA-TNC message dialog, several
messages might be exchanged that do not need (or require
different) security protections. For example, a deployment may
not wish to protect messages requesting posture information,
but may wish to protect the resulting posture and/or any final
decision related attributes. In order to allow for each
message's attributes to be protected independently, a more
granular security mechanism was required. Note that the use of
a protected session oriented protocol, such as TLS, could be
provided by the PT protocol.
CMS has been used in the IETF to protect a number of messaging
oriented protocols (e.g. MIME messages, firmware upgrades [9])
so it was believed to be a good standards-based approach for
protecting PA-TNC message attributes. This specification
defines how CMS is applied to PA-TNC to provide origin
authentication, integrity and optional confidentiality of one
or more attributes. The use of other security protocols is
plausible in the future; consequently this protocol ensures
that PA-TNC attributes protected by CMS can be easily
recognized by Posture Collectors and Posture Validators.
2.2. PA-TNC Attributes Protected by CMS
This section discusses how CMS is used to protect PA-TNC
message attributes. The PA-TNC protocol specification defines
how Posture Collectors and Posture Validators can exchange
messages to perform an assessment. Each message is delivered
to interested Posture Collector(s) or Posture Validator(s)
based upon the component type (e.g. firewall) indicated in the
PB-TNC message type.
Sangster Expires August 7, 2008 [Page 6]
Internet-Draft PA-TNC Security February 2008
Within each PA-TNC message is a set of one or more attributes
expressed in TLV format. The attribute type indicates the
format and semantics of the attribute's value. PA-TNC defines
an extensible attribute type field allowing for both vendor
defined and standard attributes to be included and easily
identified by PA-TNC message recipients. For more information,
see the PA-TNC specification. This specification defines the
syntax and semantics of three new attribute types necessary to
support CMS protection of PA-TNC attributes. The following
subsections will focus on each of the new attributes.
2.3. CMS Protected Content Attribute
The CMS Protected Content attribute allows Posture Collector(s)
or Posture Validator(s) to send one or more PA-TNC message
attributes protected within a CMS encapsulated object. This
specification identifies the profile of CMS's capabilities that
are necessary to provide authentication and integrity
protection and optionally confidentiality protection for the
PA-TNC message attributes. Some aspects of CMS are not
required to achieve these security protections, and so for
simplicity these are explicitly excluded from the PA-TNC
security standard.
Because this specification describes a profile of CMS that
directly applies to the protection PA-TNC attributes, it does
not attempt to repeat all the encoding and processing rules
described by the CMS specification. Nonetheless these encoding
and processing rules are required unless explicitly modified or
excluded by this specification. The intention behind most of
the profiling of CMS in this specification is to exclude
portions of CMS or to alter (raise or remove) requirements for
particular fields within the CMS structures to reflect their
use in protecting PA-TNC attributes.
2.3.1. CMS Content Info and Content Types
Every CMS Protected Content attribute MUST begin with a
ContentInfo structure. The ContentInfo structure encapsulates
the top level ContentType identifier and the content itself.
CMS allows nesting of content types so that other levels of
content types may exist within the top level content field.
The ContentInfo structure is described in section 3 of the CMS
specification and is repeated below for the reader's
convenience:
Sangster Expires August 7, 2008 [Page 7]
Internet-Draft PA-TNC Security February 2008
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
Each contentType value is an OID that indicates the syntax and
semantics of the associated content field. The CMS
specification defines six different contentType values and
formats while allowing more to be defined in other
specifications. PA-TNC message security protection requires
the support of only two contentType values: signed-data and
enveloped-data. The signed-data contentType provides origin
authentication and integrity protection of the included set of
PA-TNC attributes. The signed-data protection MUST be present
in all CMS Protected Content attributes.
Optionally, a Posture Collector or Posture Validator may also
wish to protect the confidentiality of a signed set of
attributes. This can be accomplished by encapsulating the
signed-data content within an enveloped-data contentType. The
result is an encrypted version of the signed set of attributes
being included in the CMS Protected Content. Therefore, all
Posture Collectors or Posture Validators supporting the CMS
Protected Content attribute MUST be capable of supporting the
creation and/or processing of CMS Protected Content attributes
containing either:
o signed-data content (signed attributes)
o signed-data content encapsulated within enveloped-data
content (signed and encrypted attributes)
Other CMS contentType values MAY be supported but are outside
the scope of this specification so are unlikely to offer
interoperability. Implementations receiving a CMS Protected
Content containing an unrecognized contentType MUST discard the
attribute and SHOULD return a CMS Error Code attribute
containing an errorCode of badContentType.
2.3.2. CMS Signed-Data
PA-TNC attributes that require authentication and integrity
protection MUST use the signed-data CMS content type within a
CMS Protected Content PA-TNC message attribute. This section
defines the subset of the CMS signed-data features required for
protection of PA-TNC message attributes. Readers should refer
to section 5 of the CMS specification for background on the
Sangster Expires August 7, 2008 [Page 8]
Internet-Draft PA-TNC Security February 2008
required CMS processing rules that form the basis for the
profile discussed in this subsection.
The CMS signed-data content type has the following structure
present in the content field of ContentInfo:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
To simplify support and processing of signed CMS protected PA-
TNC message attributes, the following restrictions from full
CMS are imposed for the signed-data field:
CMSVersion
This field contains a value following the algorithm
described in section 5.1 of the CMS specification. This
profile does not support certificates and CRLs of type other
nor attribute certificates, therefore it is expected that
this value will normally be 3 or 1 (depending on the type of
SignerIdentity used).
digestAlgorithms
This field SHOULD be empty indicating that recipients need
to refer to the signerInfos field to determine the digest
algorithm used by the signer. This field MAY contain a
single DigestAlgorithmIdentifier OID corresponding to the
digest algorithm used during the single signature
computation included within the attribute. If present, this
field MUST match the signerInfos's digestAlgorithms field
described below.
Sangster Expires August 7, 2008 [Page 9]
Internet-Draft PA-TNC Security February 2008
encapContentInfo
This field contains another pair of content type and content
(see section 5.2 of the CMS specification for details). The
content type (referred to as eContentType) MUST be set to
the id-data ContentType OID and the content field MUST only
contain one or more PA-TNC message attribute(s) covered by
the signature. The content field MUST be present so it is
not optional as stated by CMS. The encoding of the PA-TNC
message attributes within the content field will match their
definition from the PA-TNC specification so does not require
DER or BER encoding.
certificates
This field MUST contain the signer's X.509 version 3
identity certificate and SHOULD also contain the set of
certificates leading from the signer's certificate to a
recipient trusted certificate authority as discussed in the
CMS specification. These certificate(s) enable the
recipient(s) to perform path validation of the signer's
certificate as part of its trust decision. It is expected
that the recipient(s) of the message will have other methods
for obtaining necessary certificates in the event that this
field does not contain a sufficient set of certificates to
complete validation. This field SHOULD NOT contain
attribute certificates although they are allowable under
standard CMS.
crls
No additional restrictions are placed on this field.
signerInfos
A single SignerInfo structure MUST be included in the
signerInfos field. Multiple signers MUST NOT be included.
PA-TNC security does not support multiple signers so only a
single SignerInfo can be present (not a set as described by
CMS). The included digestAlgorithm MUST match the value
included in the digestAlgorithms field above if one is
present.
PA-TNC recipients SHOULD return a CMS Error Code PA-TNC
message attribute containing a digestAlgorithmMismatch error
code if the signerInfos's digestAlgorithm does not match the
specified digestAlgorithm value.
Sangster Expires August 7, 2008 [Page 10]
Internet-Draft PA-TNC Security February 2008
The unsignedAttrs field MUST NOT be used as they are not
necessary to meet the requirements of PA-TNC security. The
Nonce CMS attribute MUST be included to provide replay
protection. Other signedAttrs field MAY be used to include
additional supporting information about the protection on
the CMS content such as SMIMEEncryptionKeyPreference and
SMIMEEncryptionKeyPreference.
2.3.2.1. CMS Signed-Data Example
This section provides a simple example of a PA-TNC message
attribute (Request Attribute) encapsulated within a CMS
Protected Content attribute. This simple example is intended
to help visualize the contents of this attribute and the
relationship between the nested CMS ASN.1 structure and the
values expected for use with PA-TNC. Due to the encapsulating
approach used by CMS, each level of encapsulation is
increasingly indented and both the ASN.1 and the encapsulated
content example are included.
Initially, each recipient of the example PA-TNC message would
receive a message containing a single attribute of type
Protected CMS Content. The value portion of the Protected CMS
Content TLV contains the following:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content[0] EXPLICIT ANY DEFINED BY contentType }
contentType
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
content
This field contains the signature metadata and encapsulates
the PA-TNC attribute. The ASN.1 for this field is as
follows:
Sangster Expires August 7, 2008 [Page 11]
Internet-Draft PA-TNC Security February 2008
ContentInfo ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
signerInfos SignerInfos }
version
Set to 1
digestAlgorithms
Empty (0 length field)
encapContentInfo
This field contains the encapsulated PA-TNC attribute
that was signed. The ASN.1 for this field is as follows:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content[0] EXPLICIT ANY DEFINED BY contentType }
contentType
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
content
This field contains the PA-TNC message attribute(s)
included in the signature. For this example, it
contains the Request Attribute TLV as defined by the
PA-TNC specification.
certificates
List of X.509 certificates including the sender's
certificate and any parent CA certificates leading to a
root trusted by the sender.
crls
Revocation information for signer's certificate
signerInfos
Sangster Expires August 7, 2008 [Page 12]
Internet-Draft PA-TNC Security February 2008
One set of signer information including signer's identity
and algorithms used in the signature. This field can
also carry a set of signed and unsigned CMS attributes.
For this example, the SignerInfo instance uses
issuerAndSerialNumber to denote the signer's certificate.
The Nonce signed CMS attribute is included for replay
protection. No unsigned attributes are included.
2.3.2.2. Signed-Data Required Algorithms
In order to enable interoperability between independent
implementations, this subsection defines the algorithms that
PA-TNC security compliant implementations are expected to
support. Additional algorithms and key lengths MAY be
supported.
Sangster Expires August 7, 2008 [Page 13]
Internet-Draft PA-TNC Security February 2008
+--------------+-----------+-------------+---------------------+
| Purpose | Algorithm | Requirement | Algorithm |
| | (Key Len.)| Level | Reference |
+--------------+-----------+-------------+---------------------+
| Digest | SHA-1 | MUST (Treat | RFC 3370, Sec. 2.1 |
| Algorithm | (160) | as MUST-) | FIPS 180-1 |
+--------------+-----------+-------------+---------------------+
| | SHA-256 | MUST | IETF I-D [4] |
| | (256) | | FIPS 180-2 |
+--------------+-----------+-------------+---------------------+
| Signature | RSA | MUST | RFC 3370, Sec. 3.2 |
| Algorithm | (2048) | | PKCS #1 v1.5 |
+--------------+-----------+-------------+---------------------+
| | ECDSA | SHOULD | RFC 5008, Sec. 3 |
| | (256) | | FIPS 186-2 |
+--------------+-----------+-------------+---------------------+
2.3.3. CMS Enveloped-Data
PA-TNC attributes that require confidentiality protection MUST
use the enveloped-data CMS content type to encapsulate and
encrypt the signed-data content. PA-TNC security does not try
to provide a confidentiality only security service, and
therefore enveloped-data is used only in conjunction with
signed-data (authentication and integrity protected) content.
This subsection defines the subset of the CMS enveloped-data
features required for the protection of PA-TNC message
attributes already protected within a signed-data object. When
a feature isn't specifically excluded or restricted by this
Sangster Expires August 7, 2008 [Page 14]
Internet-Draft PA-TNC Security February 2008
specification, implementations MUST follow the processing rules
defined in the CMS specification.
The CMS enveloped-data content type is defined in section 6.1
of the CMS specification as having the following structure:
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes
OPTIONAL }
To simplify support and processing of encrypted CMS protected
PA-TNC message attributes, the following restrictions from full
CMS are imposed on the encapsulated-data field:
CMSVersion
This field contains a value derived from the algorithm
described in section 5.1 of the CMS specification. Because
this profile does not use certificates and CRLs of type
other and unprotected attributes MUST NOT be used, it is
expected that this value will normally be 0.
originatorInfo
This field MUST contain the signer's X.509 version 3
identity certificate and SHOULD also contain the set of
certificates leading from the signer's certificate to a
recipient trusted certificate authority as discussed in the
CMS specification. These certificates enable the
recipient(s) to perform path validation of the signer's
identity certificate. It is expected that the recipient(s)
of the message will have other ways to obtain necessary
certificates in the event that this field does not contain a
sufficient set of certificates to complete validation. This
field SHOULD NOT contain attribute certificates despite
being allowable under standard CMS.
Optionally this field may also include CRL information used
to check the validity of the certificates presented by the
originator. This specification does not change the CMS
specification handling of CRLs.
Sangster Expires August 7, 2008 [Page 15]
Internet-Draft PA-TNC Security February 2008
recipientInfos
This field contains a set of per recipient information
necessary to process the encrypted content. This field
contains the encrypted key destined for each recipient to be
used to decrypt the encryptedContentInfo. This
specification does not change the CMS processing of this
field so readers should refer to section 6.2 of the CMS
specification for details and information about handling of
different key management techniques.
encryptedContentInfo
This field contains the encrypted version of the signed-data
content together with information about the encryption
algorithm used.
The use of the encryptedContentInfo field is the same as
specified in CMS except that this field MUST NOT be empty and
MUST contain the encrypted signed-data (in an id-data content
type). This field MUST NOT contain content that is not
signed as it could be subject to undetectable integrity based
attacks.
unprotectedAttrs
The CMS specification defines this field as optional. For
PA-TNC security, this field MUST NOT be used.
2.3.3.1. CMS Enveloped-Data Example
This section shows an example of an encrypted and signed set of
PA-TNC message attributes. Rather than duplicating the signed-
data example from section 2.3.2.1. the example focuses on the
encrypted-data content and highlights where the signed-data is
included.
Initially each recipient of the example PA-TNC message would
receive a message containing a single attribute of type
Protected CMS Content. The value portion of the Protected CMS
Content TLV would contain the following:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content[0] EXPLICIT ANY DEFINED BY contentType }
contentType
Sangster Expires August 7, 2008 [Page 16]
Internet-Draft PA-TNC Security February 2008
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
content
This field contains the encrypted content and information
required to decrypt it on a per recipient basis. The ASN.1
for this field is as follows:
ContentInfo ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes
OPTIONAL }
version
Set to 0
originatorInfo
This field includes a list of X.509 certificates
including the signer's certificate and potentially
several parent CA certificates enabling the recipient to
complete chain validation.
recipientInfos
This field contains encrypted versions of the keys
associated with each recipient that are used to decrypt
the encryptedContentInfo's content. Normally it is
expected that a single recipient will be involved with a
CMS protected message so this includes only one
recipientInfo.
encryptedContentInfo
This field contains the encapsulated PA-TNC attribute
that was encrypted. The ASN.1 for this field is as
follows:
Sangster Expires August 7, 2008 [Page 17]
Internet-Draft PA-TNC Security February 2008
ContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm
ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent }
contentType
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
contentEncryptionAlgorithm
joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3)_ nistAlgorithms(4)
aes(1) aes128(2)
encryptedContent
The content of this field is an encrypted version of
the signed-data example described in section 2.3.2.1.
While this field is optional in CMS, it is required
for PA-TNC security (external signatures are not
supported).
unprotectedAttrs
This field is empty.
2.3.3.2. Enveloped-Data Required Key Management
This subsection discusses the required key management schemes
as defined by the CMS specification. The key management scheme
is used to establish a key that is shared by the communicating
parties enabling them to perform cryptographic operations on
their communications. For this specification, the exchanged
content is signed-data containing one or more PA-TNC message
attributes protected by a signature. In order to allow the end
parties to use different types of credentials to protect this
key negotiation, several key management schemes are defined.
This specification follows the requirements from section 6.2 of
the CMS specification which states:
"Implementations MUST support key transport, key agreement,
and previously distributed symmetric key-encryption keys, as
represented by ktri, kari, and kekri, respectively.
Implementations MAY support the password-based key
management as represented by pwri. Implementations MAY
Sangster Expires August 7, 2008 [Page 18]
Internet-Draft PA-TNC Security February 2008
support any other key management technique as represented
by ori."
2.3.3.3. Enveloped-Data Required Algorithms
In order to enable interoperability between independent
implementations, this subsection defines the key management and
content protection algorithms that PA-TNC security compliant
implementations are expected to support. Additional
algorithms, key lengths and key management techniques MAY be
supported. The password-based key management scheme MAY be
supported while the key transport, key agreement and previously
distributed symmetric KEK schemes MUST be supported by
compliant implementations.
Sangster Expires August 7, 2008 [Page 19]
Internet-Draft PA-TNC Security February 2008
+------------------+----------------+-------+----------------+
| Key Management | Algorithm | Reqmt | Algorithm |
| Scheme | (Key Length) | Level | Reference |
+------------------+----------------+-------+----------------+
| Key | RSA wrap AES | MUST | RFC 3565, |
| Transport | CEK (2048) | | Sec. 2.2 |
+------------------+----------------+-------+----------------+
| Key | ESDH w/AES KEK | MUST | RFC 3565, |
| Agreement | (128 & 256) | | Sec. 2.3 |
+------------------+----------------+-------+----------------+
| Prev Distributed | AES Key Wrap | MUST | RFC 3565, |
| Symmetric KEK | (128 & 256) | | Sec. 2.4 |
+------------------+----------------+-------+----------------+
| Password Based | Passwd derived | MUST | RFC 3565, |
| | AES(128 & 256) | (*) | Sec. 2.5 |
+------------------+----------------+-------+----------------+
* - Optional to implement, so mandatory if supported
The above described key management schemes are used to
establish a symmetric content encryption key that protects the
signed PA-TNC attributes. PA-TNC security compliant
implementations MUST support the use of the following
algorithms for content encryption:
Sangster Expires August 7, 2008 [Page 20]
Internet-Draft PA-TNC Security February 2008
+------------------+----------------+-------+------------------+
| Purpose | Algorithm | Reqmt | Algorithm |
| | (Key Length) | Level | Reference |
+------------------+----------------+-------+------------------+
| Content | AES | MUST | RFC 3565, |
| Encryption | (128 & 256) | | Sec. 2.1 |
+------------------+----------------+-------+------------------+
2.4. Security Capabilities Attribute
The Security Capabilities attribute type allows a Posture
Collector or Posture Validator to determine the supported set
of cryptographic algorithms supported by the recipient(s) prior
to creating a protected message. This provides a simple
cryptographic algorithm discovery mechanism to assist the
sender's selection of an algorithm consistent with the sender's
policy and supported by the recipient. The algorithm list is
encapsulated within a signed CMS message that the recipient can
use to verify the authenticity and integrity of the algorithm
list. If confidentiality protection of the Security Capability
attribute is desired, the sender can encapsulate it within an
enveloped-data content type. Note however that the sender of
this attribute will not be aware of the cryptographic
algorithms supported by the recipient (since it is replying to
a cryptographic discovery request). For this reason,
implementations MAY support encryption of the security
capabilities content using the enveloped-data; however, one of
the mandatory encryption algorithms SHOULD be used to maximize
the possibility that the recipient supports the algorithm.
In order for a PA-TNC message sender to determine the security
capabilities supported by recipient(s), the Posture Collector
or Posture Validator would include the Security Capabilities
attribute type in a PA-TNC Attribute Request attribute (see the
PA-TNC specification for details). The Attribute Request may
include other PA-TNC attribute types in the list if
appropriate. The recipient(s) of the Attribute Request
attribute containing the Security Capabilities attribute type
respond with the Security Capabilities attribute described in
this section. NOTE that typically a Posture Collector does not
send an Attribute Request attribute to a Posture Validator
Sangster Expires August 7, 2008 [Page 21]
Internet-Draft PA-TNC Security February 2008
during an assessment as it normally is responding to requests
for attributes. However if an Posture Collector wishes to
determine the security algorithms supported by recipient
Posture Validator(s), it may send a Request Attribute
containing only the Security Capabilities attribute type.
The PA-TNC Security Capabilities attribute MUST consist of a
single CMS signed-data content containing a single signed
attribute in the signerInfo and an empty eContent (no other
data) within the encapContentInfo. The Security Capabilities
attribute SHOULD be signed with a mandatory signature algorithm
(specified in section 2.3.2.2. ) to ensure that the recipient
will be able to verify the signature. Note that CMS signature
also includes a field called signed attribute (signedAttrs)
that is information outside of the CMS content. This
specification does not use unsigned CMS attributes but does use
the signed CMS attribute to convey the supported security
algorithms. For PA-TNC security, the attributes described in
the PA-TNC specification are present in the data portion
(eContent in encapContentInfo) of the CMS content; whereas the
CMS defined attributes exist outside of the eContent section,
such as in the signerInfos field, and are represented by ASN.1
in this specification.
This specification defines a CMS attribute called
paTncSecurityCapabilities that contains a prioritized list of
the cryptographic algorithms supported for various purposes by
the sender. The purpose of each algorithm is reflected by the
OID definition and can include: signing, data encryption, key
wrapping and digesting. The prioritized algorithm list MUST be
grouped according to the algorithms' purpose to ease processing
by the recipient. The CMS paTncSecurityCapabilities attribute
is based on the SMIMECapabilities attribute defined in section
2.5.2 of the SMIME specification. The processing rules for the
SMIMECapabilities CMS attribute apply to the
paTncSecurityCapabilities CMS attribute unless stated otherwise
in this section.
2.4.1. paTncSecurityCapabilities Within Signed-Data
The paTncSecurityCapabilities CMS attribute exists within the
signed-data content type described in section 2.3.2. of this
specification. Rather than repeating all the detail of the
signed-data section, this section will focus on the differences
between a signed set of PA-TNC attributes and a
paTNCSecurityCapability CMS attribute encapsulated within
signed-data content.
Sangster Expires August 7, 2008 [Page 22]
Internet-Draft PA-TNC Security February 2008
The paTncSecurityCapabilities CMS attribute is present in the
signedAttrs field; consequently it is included in the CMS
signature. This enables recipients to detect modification of
the sender's claimed security capabilities and to authenticate
the sender's identity. Unlike normal signed-data content, the
paTncSecurityCapabilities CMS attribute MUST exist in all
Security Capabilities attributes and MUST be the only CMS
attribute present in the signedAttrs list besides the required
Nonce CMS (replay protection) attribute. This differs from
normal signed-data content that is allowed to include other CMS
attributes.
Another difference concerns the use of the encapContentInfo's
eContent field. In the case of signed-data content, this field
normally includes the PA-TNC message attributes being
protected. For a Security Capabilities attribute, the eContent
field MUST be empty. This is because the sole purpose of this
attribute is to indicate the security capabilities of the
sender and those capabilities are included in the signedAttrs
field. No other PA-TNC message attributes are allowed to be
encapsulated in this attribute. Note that a PA-TNC message can
contain several attributes so other attributes could be sent in
addition to the Security Capabilities attribute.
2.4.2. paTncSecurityCapabilities ASN.1
The paTncSecurityCapabilities content mirrors the
SMIMECapabilities attribute as described in section 2.5.2 of
the SMIME specification. The ASN.1 defined for the
paTncSecurityCapabilities attribute is as follows:
paTncSecurityCapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }
paTncSecurityCapabilities ::= SEQUENCE of
paTncSecurityCapability
The paTncSecurityCapabilities CMS attribute is simply a
prioritized (preference order) list of OIDs and associated
cryptographic parameters of the algorithms supported by the
sender. Ordering the list by preference provides another piece
of information to those wishing to send protected information
to the sender. This specification leverages the CMS Algorithms
specification defined set of ASN.1 for the OIDs and parameters
for the security algorithms represented in this list. For more
Sangster Expires August 7, 2008 [Page 23]
Internet-Draft PA-TNC Security February 2008
information see section 7 of the CMS Algorithm specification
and the AES algorithm specification. An in-depth discussion of
the SMIMECapabilities CMS attribute that parallels the
paTncSecurityCapabilities CMS attribute is included in the
SMIME specification in section 2.5.2
2.5. CMS Error Code Attribute
This PA-TNC attribute allows a recipient of an invalid security
protected PA-TNC message to send an integrity protected error
response indicating the reason for the failure. In order to
return protected error information related to the processing of
CMS Protected Content attributes, PA-TNC security encapsulates
the error code within of a signed attribute, itself
encapsulated within CMS signed-data content. Using a signed
attribute allows recipients to verify the integrity and origin
authentication of error status preventing spoofing and other
related attacks. In some uncommon situations, recipients may
not be able to verify the signature (e.g. the use of an
unsupported digest algorithm) or establish trust in the sender
(e.g. no common trust anchor) but at least the recipient can
view the returned error code and decide whether to trust it and
therefore how to act on it. Care should be taken when trusting
information whose integrity can not be verified as it could
leave the recipient open to various attacks.
All CMS processing errors MUST result in a response PA-TNC
message containing a CMS Error Code Attribute. The CMS Error
Code attribute MUST only contain a single CMS ContentInfo of
content type signed-data. The Signed-Data element MUST contain
an empty eContent and include only the Nonce CMS attribute and
the paTncErrorCode CMS attribute in the signerInfo.
The CMS Error Code attribute SHOULD be signed with one of the
mandatory signature algorithms (specified in section 2.3.2.2. )
to ensure that the recipient will be able to verify the
signature.
2.5.1. paTncErrorCode Within Signed-Data
The paTncErrorCode CMS attribute exists within the signed
attributes portion of the signed-data content type. Rather
than repeat all the detail of section 2.3.2. this section will
describe the differences between a signed set of PA-TNC
attributes and a paTNCSecurityErrorCode CMS attribute housed
within signed-data content. Note that the CMS Error Code
Sangster Expires August 7, 2008 [Page 24]
Internet-Draft PA-TNC Security February 2008
attribute and the Security Capabilities attribute both use the
same CMS fields.
The paTncErrorCode CMS attribute is an attribute that is
present in the signedAttrs field so it is included in the CMS
signature. This enables recipients to detect modification of
the error information and to authenticate the sender's
identity. Unlike normal signed-data content, the
paTncErrorCode CMS attribute MUST exist in all CMS Error Code
attributes and MUST be the only CMS attribute present in the
signedAttrs list besides the required Nonce CMS (replay
protection) attribute. This differs from normal signed-data
content that is allowed to include other CMS attributes.
The other difference is the use of the encapContentInfo's
eContent field. Normally in signed-data content, this field
must include the PA-TNC message attributes being protected.
For a CMS Error Code attribute, the eContent field MUST be
empty. This is because the sole purpose of this attribute is
to carry the error code related to an earlier PA-TNC message to
the recipient and the error information is included in the
signedAttrs field. No other PA-TNC message attributes (e.g.
Request Attribute) are allowed to be encapsulated in this
attribute. Note that a PA-TNC message can contain several
attributes so other attributes could be sent in addition to the
CMS Error Code attribute.
2.5.2. paTncErrorCode ASN.1
The paTncErrorCode CMS attribute is placed in the signerInfo's
signedAttrs field. The signedAttrs field is included in the
signature applied so that the recipient can verify the
authenticity and integrity of the information before taking
action. The following describes the syntax and semantics of
the paTncErrorCode CMS attribute.
paTncErrorCode ::= SEQUENCE {
vendorID OBJECT IDENTIFIER,
status errorCode,
ContentInfo originalContent OPTIONAL }
vendorID
Sangster Expires August 7, 2008 [Page 25]
Internet-Draft PA-TNC Security February 2008
This field indicates the Private Enterprise Number (PEN) OID
as a Vendor ID [10] of the party who owns the errorCode name
space that is being used in the errorCode field. For
example, this value for Symantec would be iso(1) org(3)
dod(6) internet(1) private(4) enterprise(1) symantec(393).
This allows vendors to have vendor-defined error codes
outside of the standard name space. For IETF standard PA-
TNC security errors, the vendorID field MUST be set to zero.
errorCode
This field MUST contain the error code reflecting the error
that occurred while processing the CMS message. The IETF
standard error codes are listed in section 2.5.3.
originalContent
This field SHOULD contain the contents of the CMS content
that cause the error. If the original content is large and
the deployment is bandwidth constrained this field MAY be
empty.
2.5.3. IETF Standard paTncErrorCode Values
This section defines an initial set of IETF standard PA-TNC
security error code values. IANA maintains a registry of IETF
PA-TNC standard error codes. Entries may only be added to this
registry by IETF Consensus. That is, they MUST be defined in
an RFC approved by the IESG.
The PA-TNC Security error codes MUST always be used with a
vendorID field value of zero. The following table briefly
describes the initial set of the IETF standard error codes used
in the errorCode field of a paTncErrorCode value. Values not
defined in this table MUST NOT be used with an IETF (zero)
vendorID unless approved and included in the IANA
paTNCSecurityErrorCode registry.
Posture Collectors and Posture Validators MUST NOT require
support for particular vendor-specific PA-TNC Error Code and
MUST interoperate with other parties despite any differences in
the set of vendor-specific PA-TNC errorCode values supported.
This ensures interoperability while allowing for vendor
experimentation and additional functionality outside of the
IETF standard name space.
Sangster Expires August 7, 2008 [Page 26]
Internet-Draft PA-TNC Security February 2008
Implementations MUST use their organization's assigned PEN OID
in the vendorID to include non-IETF standard error codes. The
following error codes were initially based on early work using
CMS for Trust Anchor Management Protocol (TAMP) [12].
Sangster Expires August 7, 2008 [Page 27]
Internet-Draft PA-TNC Security February 2008
Value Name Description
----- ---- -----------
0 Reserved This value MUST NOT be used
1 decodeFailure Unable to decode content, doesn't match
provided type
2 badContentInfo Unknown or invalid ContentInfo syntax
used in content
3 badSignedData Unknown, invalid or non-compliant
signed-data format
4 badEnvelopedData Unknown or non-compliant enveloped-data
format
5 badCertificate Invalid syntax used for included
certificate(s)
6 badSignerInfo Invalid or unsupported SignerInfo syntax
7 badSignedAttrs Invalid or unsupported use of signed
attributes
8 badUnsignedAttrs Non-compliant use of unsigned attributes
9 missingContent Non-compliant empty eContent field in
signed-data
10 noTrustAnchor Lack of trust anchor associated with the
signer's certificate
11 notAuthorized Requestor's not authorized to perform
operation
12 badDigestAlgorithm Digest algorithm used is unsupported or
unknown
13 badSignatureAlgorithm Signature algorithm used is unknown
or unsupported
14 unsupportedKeySize Key used is an unsupported length (too
short or long)
15 unsupportedParameters Algorithm parameters indicate
unsupported values
16 signatureFailure Recipient computed signature does not
match provided
17 decryptionFailure Unable to decrypt content using provided
content decryption key
18 keyManageFailure Unable to determine provided content
encryption key
19 badKeyManage Unknown or unsupported key management
technique used
20 nonceMissing Received signed content lacking required
nonce attribute
21 invalidNonce Unexpected or invalid nonce received
22 repeatedNonce Received nonce was recently used so
possible replay
23 nonceOrdering Received nonce was not one greater then
prior value
24 badContentType Invalid or unsupported contentType found
25 digestAlgMismatch Different algorithms in signerInfos &
digestAlgorithm
29 missingSignature Signed-data missing required signature
Sangster Expires August 7, 2008 [Page 28]
Internet-Draft PA-TNC Security February 2008
30 resourcesBusy Recipient lacks resources to process
received content
31 versionNumberMismatch Version in received message was
unsupported
33 revokedCertificate Certificate used was revoked by issuer
65535 other Unable to process message for reason
other than above
2.6. Nonce CMS Attribute
Unlike the above three PA-TNC attributes, this attribute is a
CMS attribute that is located in the signedAttrs field of the
signed-data content within other PA-TNC security protected
attributes. For example a CMS Protected Content attribute
would include a Nonce CMS attribute in its signedAttrs field to
detect replay attacks.
The Nonce CMS attribute allows the sender of a PA-TNC security
protected attribute to include a nonce that can be used by the
recipient to detect a replay attack. The Nonce CMS attribute
MUST be used in all PA-TNC security messages as defined within
this specification. The Nonce CMS attribute is a signed
attribute that MUST exist within any signed-data content type
including the Security Capabilities, CMS Error Code, and CMS
Protected Content PA-TNC attributes. The Nonce CMS attribute
MUST NOT be used in the enveloped-data content type to simplify
processing of such messages because the enveloped-data will
encapsulate signed-data content that must include the nonce
anyway.
The value of the nonce MUST be unpredictable to third parties
so MUST NOT be based on network observable information. Use of
good sources of entropy is highly desired, however
implementations may use persistently stored sequence numbers
that do not repeat (even across reboots and other disruptive
events). The Nonce CMS attribute contains two separate values
each under the control of a Posture Collector or Posture
Validator. This allows both sides of the message exchange to
provide entropy and receive replay protection.
The initial sender of a CMS message generates its nonce and
includes it in the Nonce CMS attribute with a zero value for
the other party. When initially responding to a CMS protected
message containing a zero value nonce, the responder generates
its nonce and includes it in the reply together with a copy of
the nonce sent by the other party. If the initial sender
wishes to send another signed-data message to the other party
it creates a Nonce CMS attribute by copying the other party's
nonce and by incrementing its own nonce by one. If the
resulting value is 2^32 then it should randomly generate a new
Sangster Expires August 7, 2008 [Page 29]
Internet-Draft PA-TNC Security February 2008
nonce. This process continues until the completion of an
assessment. Implementations unable to generate a good nonce
value MAY use persistent sequence numbers providing that it can
ensure that no repeated values are used in a predictable
manner.
When a CMS message recipient receives a message, it must check
the message's nonce attribute to ensure that its nonce matches
the value of the nonce that it sent or contains a zero.
Similarly it must also check that the nonce created by its peer
is one greater than the last received assessment message nonce
if it is not the first CMS protected message of the assessment.
2.6.1. paTncNonce Within Signed-Data
The Nonce CMS attribute MUST be present in the signedAttrs list
in all CMS signed-data content used by PA-TNC security.
Recipients of CMS signed-data protected attributes lacking a
Nonce CMS attribute MUST return an error to the sender and MUST
NOT process the CMS message. The Nonce CMS attribute is
defined as paTncNonce below.
As mentioned above, the Nonce CMS attribute (paTncNonce) only
exists within the CMS signed-data's list of signed attributes
(signedAttrs) and does not require changes to other fields
within the signed-data content. This allows paTncNonce to be
included in signed-data content that carries data (e.g. CMS
Protected Content) or is empty (e.g. Security Capabilities).
2.6.2. paTncNonce CMS Attribute ASN.1
The following ASN.1 shows the syntax of the paTncNonce CMS
attribute that is included in the signed-data content's
signedAttrs field.
NonceType ::= INTEGER (0 .. 4294967295)
paTncNonce ::= SEQUENCE {
pcNonce NonceType, -- Posture Collector's nonce
pvNonce NonceType } -- Posture Validator's nonce
pcNonce
This field contains an unpredictable 32 bit unsigned integer
of the Posture Collector's choosing. The selection of this
value MUST be consistent with the following rules:
Initial value during assessment:
Sangster Expires August 7, 2008 [Page 30]
Internet-Draft PA-TNC Security February 2008
o If a Posture Collector is sending an initial CMS
protected attribute during an assessment, the Posture
Collector MUST select an unpredictable, non-zero nonce
value for this field.
o If a Posture Validator is sending an initial CMS
protected attribute during an assessment, the Posture
Validator MUST set this field to zero. Zero indicates
that a Posture Collector has not yet had an opportunity
to establish an initial nonce value.
Non-initial value during assessment:
o Posture Collector MUST increment by one the prior pcNonce
value used during this assessment and if <2^32 include
this value in this field. If 2^32 is reached, a new
unpredictable, non-zero value MUST be selected. The
selected value SHOULD be compared against a list of those
recently used to avoid causing the recipients to consider
this a replay and sending an error. Use of the prior
pcNonce + one approach to new nonce selection was done to
ease nonce create and replay table maintenance.
o Posture Validator MUST copy pcNonce from most recent
valid CMS protected message from Posture Collector during
this assessment
o Recipients MUST verify appropriate nonce used in both
fields to detect replay attempts. Recipients SHOULD
maintain a table of recently used nonce ranges for each
peer.
pvNonce
This field contains an unpredictable 32 bit unsigned integer
of the Posture Validator's choosing. The selection of this
value MUST be consistent with the following rules:
Initial value during assessment:
o If Posture Validator is sending the initial CMS protected
attribute during an assessment, the Posture Validator
MUST create an unpredictable, non-zero nonce value for
this field.
o If Posture Collector is sending the initial CMS protected
attribute during an assessment, the Posture Collector
MUST set this field to zero. Zero indicates that the
Sangster Expires August 7, 2008 [Page 31]
Internet-Draft PA-TNC Security February 2008
Posture Validator has not yet had an opportunity to
establish an initial nonce value.
Non-initial value during assessment:
o Posture Validator MUST increment the prior pcNonce value
used during this assessment and if <2^32 include the
value in this field. If 2^32 reached, a new
unpredictable, non-zero value MUST be selected. The
selected value SHOULD be compared against a list of those
recently used to avoid causing the recipients for
considering this a replay and sending an error.
o Posture Collector MUST copy pcNonce from most recent
valid CMS protected message from the Posture Validator
during this assessment.
Recipients MUST verify appropriate nonce used in both fields to
detect replay attempts. Recipients SHOULD maintain a table of
recently used nonce ranges for each peer.
2.6.3. paTncNonce CMS Attribute Example
This section provides a simple example of a nonce value
exchange. In this example, a single Posture Collector and
Posture Validator will participate in a two roundtrip exchange
including three CMS protected attribute messages. The sub-
bullet in each step describes the contents of the pcNonce and
pvNonce fields.
1. Posture Validator sends an unprotected PA-TNC Request
Attribute containing the Security Capabilities attribute
type
o No nonces involved with this message (unprotected).
2. Posture Collector responds with a PA-TNC Security
Capabilities attribute
o pcNonce = initial value X; pvNonce = 0
3. Posture Validator sends a PA-TNC CMS Protected Content
attribute containing a PA-TNC Request Attribute requesting
Product Information about endpoint's operating system
o Verify X was not recently used by Posture Collector
o pcNonce = X; pvNonce = initial value Y
Sangster Expires August 7, 2008 [Page 32]
Internet-Draft PA-TNC Security February 2008
4. Posture Collector responds with a PA-TNC Product
Information attribute encapsulated within a CMS Protected
Content attribute
o Verify Y was not recently used by Posture Validator
o pcNonce = X+1; pvNonce = Y
5. Posture Validator sends an assessment result in a CMS
Protected Content attribute
o Verify pcNonce is last nonce + 1
o pcNonce = X+1; pvNonce = Y+1
Note that this example does not involve X or Y reaching 2^32 so
no new unpredictable values were required. If this was
required the recipient would need to verify that the last nonce
value was 2^32-1 and the new value had not been used recently.
Using this algorithm both parties can detect replayed messages
from the other party (or an attacking imposter). One further
benefit is that the loss of a message during a CMS exchange can
be detected by the recipient who can respond to this failure by
sending an error message (nonceOrdering) to the sender, who
could resend the prior message if appropriate.
3. Evaluation Against NEA Requirements
This section evaluated the PA-TNC security protocol against the
requirements defined in the NEA Requirements document. Each
subsection considers a separate requirement from the NEA
Requirements document. Only common requirements (C-1 through
C-10) and PA security oriented requirements are considered,
since these are the only ones that apply to PA security.
3.1. Evaluation Against Requirement C-1
Requirement C-1 says:
C-1 NEA protocols MUST support multiple round trips between
the NEA Client and NEA Server in a single assessment.
PA-TNC security meets this requirement fully. It allows an
unlimited number of round trips between the NEA Client and NEA
Server.
Sangster Expires August 7, 2008 [Page 33]
Internet-Draft PA-TNC Security February 2008
3.2. Evaluation Against Requirement C-2
Requirement C-2 says:
C-2 NEA protocols SHOULD provide a way for both the NEA
Client and the NEA Server to initiate a posture
assessment or reassessment as needed.
PA-TNC security meets this requirement. Either the NEA Client
or the NEA Server can initiate a posture assessment or
reassessment as PA security is independent of the assessment
initiation process and allows either party to send any of the
protected attributes.
3.3. Evaluation Against Requirement C-3
Requirement C-3 says:
C-3 NEA protocols including security capabilities MUST be
capable of protecting against active and passive attacks
by intermediaries and endpoints including prevention from
replay based attacks.
PA-TNC security provides cryptographic protection for one or
more PA-TNC attributes. This protection includes strong
authentication of attribute sender's identity, the integrity of
the attribute information sent and optionally the
confidentiality of the integrity protected attributes. PA-TNC
security also includes nonce-based detection of replayed
attributes so even active intermediaries are unable to inject,
modify or replay attributes observed on the network.
3.4. Evaluation Against Requirement C-4
Requirement C-4 says:
C-4 The PA and PB protocols MUST be capable of operating over
any PT protocol. For example, the PB protocol must
provide a transport independent interface allowing the PA
protocol to operate without change across a variety of
network protocol environments (e.g. EAP/802.1X, PANA, TLS
and IKE/IPsec).
PA-TNC security meets this requirement. PA-TNC security has no
dependencies or interactions with the underlying PB or PT
protocols. PA-TNC security protocol should be able to operate
over any protocol that PA-TNC can use.
Sangster Expires August 7, 2008 [Page 34]
Internet-Draft PA-TNC Security February 2008
3.5. Evaluation Against Requirement C-5
Requirement C-5 says:
C-5 The selection process for NEA protocols MUST evaluate and
prefer the reuse of existing open standards that meet the
requirements before defining new ones. The goal of NEA
is not to create additional alternative protocols where
acceptable solutions already exist.
Based on this requirement, PA-TNC security should receive a
strong preference. PA-TNC security is equivalent with IF-M
Security 1.0, an open TCG specification. IF-M is the attribute
exchange protocol for the existing TCG architecture that has
been implemented by a number of open source projects and
commercial vendors.
3.6. Evaluation Against Requirement C-6
Requirement C-6 says:
C-6 NEA protocols MUST be highly scalable; the protocols MUST
support many Posture Collectors on a large number of NEA
Clients to be assessed by numerous Posture Validators
residing on multiple NEA Servers.
PA-TNC security meets this requirement. PA-TNC security is
capable of include many PA-TNC attributes within a single CMS
content or can be repeatedly used to individually protect any
number of PA-TNC attributes within one or more PA-TNC messages.
PA-TNC security is independent of per Posture Collector or
Posture Validator information so scales very well to large
deployments. The one exception is that a sender of CMS
protected information may include per-recipient content
decryption keys using an extensible set of key management
techniques. The number of recipients can be extremely large
before the CMS limit is reached, but even in this unlikely
situation the sender could still send multiple separate copies
of the protected attribute in a PA-TNC message each to a
different set of recipients.
3.7. Evaluation Against Requirement C-7
Requirement C-7 says:
Sangster Expires August 7, 2008 [Page 35]
Internet-Draft PA-TNC Security February 2008
C-7 The protocols MUST support efficient transport of a large
number of attribute messages between the NEA Client and
the NEA Server.
PA-TNC security meets this requirement. The use of CMS allows
for an efficient encoding of many PA-TNC attributes and the
associated security meta-data (signatures, algorithms etc.)
inside a PA-TNC attribute. Many of the PA-TNC attributes can
be combined in a PA-TNC message and because the protocol
supports multiple round trips, several related PA-TNC messages
can be sent in one or more PB-TNC batches between the Posture
Collector(s) and Posture Validator(s).
3.8. Evaluation Against Requirement C-8
Requirement C-8 says:
C-8 NEA protocols MUST operate efficiently over low bandwidth
or high latency links.
PA-TNC security meets this requirement. A minimal CMS signed-
data content adds minimal overhead to the encapsulated
attributes so is efficient even over low bandwidth links. This
specification carefully profiled full CMS so we only include
those portions of CMS that are required to meet NEA's
functional requirements.
3.9. Evaluation Against Requirement C-9
Requirement C-9 says:
C-9 For any strings intended for display to a user, the
protocols MUST support adapting these strings to the
user's language preferences.
PA-TNC security meets this requirement. The PA-TNC security
protocol does not explicitly introduce strings destined for the
user.
3.10. Evaluation Against Requirement C-10
Requirement C-10 says:
C-10 NEA protocols MUST support encoding of strings in UTF-8
format.
Sangster Expires August 7, 2008 [Page 36]
Internet-Draft PA-TNC Security February 2008
PA-TNC security meets this requirement. The PA-TNC security
protocol does not use strings.
3.11. Evaluation Against Requirement PA-1
Requirement PA-1 says:
PA-1 The PA protocol MUST support communication of an
extensible set of NEA standards defined attributes.
These attributes will be uniquely identifiable from non-
standard attributes.
PA-TNC security meets this requirement. The PA-TNC security
protocol blindly encapsulates the PA-TNC attributes so is
unaware of which attributes are present. PA-TNC security uses
CMS ContentType identifiers to uniquely identify its internal
extensible set of attributes.
3.12. Evaluation Against Requirement PA-2
Requirement PA-2 says:
PA-2 The PA protocol MUST support communication of an
extensible set of vendor-specific attributes. These
attributes will be segmented into uniquely identifiable
vendor specific name spaces.
PA-TNC security meets this requirement. The PA-TNC security
protocol blindly encapsulates the PA-TNC attributes so is
unaware of which attributes are present. The PA-TNC security
protocol leverages OIDs to allow for vendor defined name spaces
and to allow extensibility for new types of CMS attribute,
algorithms and other types.
3.13. Evaluation Against Requirement PA-3
Requirement PA-3 says:
PA-3 The PA protocol MUST enable a Posture Validator to make
one or more requests for attributes from a Posture
Collector within a single assessment. This enables the
Posture Validator to reassess the posture of a particular
endpoint feature or to request additional posture
including from other parts of the endpoint.
PA-TNC security meets this requirement. The PA-TNC security
protocol allows for multiple roundtrips and does not get
Sangster Expires August 7, 2008 [Page 37]
Internet-Draft PA-TNC Security February 2008
involved in deciding when an assessment is complete. This
allows the Posture Validator and Posture Collector to decide
when sufficient information has been exchanged using the base
PA-TNC protocol.
3.14. Evaluation Against Requirement PA-4
Requirement PA-4 says:
PA-4 The PA protocol MUST be capable of returning attributes
from a Posture Validator to a Posture Collector. For
example, this might enable the Posture Collector to learn
the specific reason for a failed assessment and to aid in
remediation and notification of the system owner.
PA-TNC security meets this requirement. The PA-TNC security
protocol allows for multiple roundtrips and does not get
involved in deciding when an assessment is complete. Therefore
the PA-TNC security protocol does not constrain when Posture
Validators may send PA-TNC messages.
3.15. Evaluation Against Requirement PA-5
Requirement PA-5 says:
PA-5 The PA protocol SHOULD provide authentication, integrity,
and confidentiality of attributes communicated between a
Posture Collector and Posture Validator. This enables
end-to-end security across a NEA deployment that might
involve traversal of several systems or trust boundaries.
PA-TNC security meets this requirement. This requirement is
the primary reason a PA-TNC security protocol was defined. PA-
TNC security protocol provides cryptographic authentication of
the attribute sender, integrity protection of the attribute
contents and optional confidentiality of attributes between
Posture Collector(s) and Posture Validator(s). This protection
is provided end to end so even if the PT security protections
are terminated prior to reaching the Posture Validator, the PA-
TNC protections will remain. This allows for PA-TNC security
protected attributes to be transported over unprotected
communication channels spanning multiple trust boundaries.
3.16. Evaluation Against Requirement PA-6
Requirement PA-6 says:
Sangster Expires August 7, 2008 [Page 38]
Internet-Draft PA-TNC Security February 2008
PA-6 The PA protocol MUST be capable of carrying attributes
that contain non-binary and binary data including
encrypted content.
PA-TNC security meets this requirement fully. The PA-TNC
security protocol encapsulates PA-TNC attributes and is unaware
of their contents. The PA-TNC security protocol is able to
transport binary and non-binary attributes as it does not
impose any sort of PA-TNC attribute encoding or transport that
would alter the attributes original content.
4. Security Considerations
This section discusses how the security countermeasures
provided by the PA-TNC security protocol address the threats to
PA-TNC messages discussed in the security considerations
section of the PA-TNC specification. This section also
discusses some additional potential threats specific to the use
of CMS to protect the PA-TNC protocol.
4.1. Countermeasures to PA-TNC Threats
The PA-TNC specification discusses a range of potential threats
to the PA-TNC protocol and its attributes. Some deployment
environments may have mitigating controls already in place on
the network or have a threat model that accepts the identified
risks. For example, many deployments may deploy
cryptographically protected IF-T protocols and trust the NEA
Client and NEA Server not to compromise the attributes
exchanged. For deployments that require security protection of
the attributes sent between the Posture Collectors and Posture
Validators, the following sections discuss how the use of CMS
can provide the necessary protection.
The following subsections are organized along the capabilities
of CMS protected PA-TNC attributes. This allows a single
discussion of the cryptographic protection provided by the
countermeasure and a summary of the threats addressed by the
countermeasure. The PA-TNC security leverages the signed-data
and enveloped-data content types to provide different levels of
protection for one or more attributes. The following
subsections discuss how each content type's protections address
the PA-TNC threats.
Sangster Expires August 7, 2008 [Page 39]
Internet-Draft PA-TNC Security February 2008
4.1.1. Threats Addressed by Signed Attributes
The signed-data content type of CMS provides a cryptographic
signature around the set of one or more attributes. This
cryptographic protection enables the recipient of a PA-TNC
message to detect any changes to the content of the signed
attributes that occurred after the data was signed. This
protection includes both CMS signed attributes in the
signedAttrs field or PA-TNC level attributes included in the
content portion of CMS. Similarly the recipient can
authenticate the identity of the sender of the attributes, and
so is able to detect adversaries attempting to masquerade as a
trustworthy origin of the attribute contents.
Section 5.2.2 through 5.2.5 of the PA-TNC specification
discusses potential attacks against the integrity of the
attributes exchange by creating falsified attributes, modifying
legitimate attributes, inserting attributes within an exchange
or replaying prior attributes.
The use of a digital signature covering the attributes' content
allows each recipient to detect fabricated attributes that were
claiming to come from a party other than the authenticated
identity. The signer of a set of attributes must have the
appropriate credentials in order to create a valid signature
associated with a trusted sender. The digital signature
includes a cryptographic digest of the contents of the
attributes that enables the recipient to detect any
alterations, additions or deletions to the signed content.
Because the signature can cover multiple PA-TNC attributes, an
attack can not remove one of the attributes without
invalidating the hash value. The paTncNonce CMS attribute
included in the signedAttrs field is also included in the CMS
hash and signature. These CMS attribute also are protected
from modification. Because the paTncNonce CMS attribute is
mandated by this specification and includes freshness values
from each party, attempts to replay previously valid attributes
can be detected by the recipient using a replay cache. It is
critical that Posture Collectors and Posture Validators check
the nonce values prior to operating upon a received set of
attributes to avoid replay attacks. This check includes
validating that the nonce values are appropriate (incremented
from prior values) and checking a cache of previously used
initial nonce values. Finally, deployments could choose to
also use enveloped-data encapsulation of the signed-data
content. Enveloped-data provides encryption of the signed-data
Sangster Expires August 7, 2008 [Page 40]
Internet-Draft PA-TNC Security February 2008
using per-session encryption keys that would not be known (or
replayable) by network based intermediaries.
4.1.2. Threats Addressed by Encrypted Attributes
The CMS enveloped-data content type used by PA-TNC security
provides an encrypted envelope around the signed-data content
to protect the signed data from disclosure while traveling
between the Posture Collector and Posture Validator (even when
traveling through the NEA posture brokers). The encryption of
the signed set of attributes allows the attributes to pass
through untrustworthy intermediary devices and components while
maintaining the confidentiality and privacy of the information.
Section 5.2.1 of the PA-TNC specification discusses the threat
of information theft by adversaries capable of intercepting the
attributes while traversing the network and TNC architecture
components. Deployers wishing to protect the exchanged
attributes without trusting or using other countermeasures to
protect the attributes can use enveloped-data to establish
private attribute exchanges between Posture Collectors and
Posture Validators. Malicious intermediaries would require
knowledge of the encryption key (or indirectly via the key
encrypting key) to obtain the attribute information.
4.2. Potential Threats Against PA-TNC use of CMS
The use of CMS with PA-TNC provides security protections for
the exchanged PA-TNC attributes but CMS itself may be directly
attacked by adversaries. This section discusses some
potential threats to CMS.
4.2.1. Cryptography
CMS protections are based on the use of cryptographic digests,
signatures, and encryption (both content and key). Signing,
encryption and key management keys must be protected from a
variety of potential threats that would result in their
discovery by adversaries.
The encryption algorithms themselves become weaker over time
and eventually may become vulnerable to various forms of attack
including brute force. This risk is elevated as computing
performance increases and new mathematical weaknesses are
discovered allowing faster searching of the key space.
Implementations should be agile enough to support protected
dynamic negotiation and addition of new algorithms as
Sangster Expires August 7, 2008 [Page 41]
Internet-Draft PA-TNC Security February 2008
necessary. PA-TNC security offers dynamic discovery of
supported cryptographic capabilities; this allows senders to
use newer and stronger algorithms when recipients are also
deployed with those algorithms. PA-TNC message senders should
use care to not to send data using weak signature or encryption
algorithms that are no longer appropriate for the sensitivity
of the attributes being protected.
4.2.2. Threats to Keys
Signed-data content makes use of X.509 certificates for
communicating the signer's public key and associated metadata,
such as the holder's identity to recipients. These
certificates are protected from alteration as long as
recipients verify the content signature and properly inspect
the signing certificate for validity, authenticity and
trustworthiness prior to usage. Part of the validation process
normally involves consulting one or more trust anchors
typically manifested as a set of certificates associated with
trusted certificate authorities. Implementations need to
protect the trust anchor database from unauthorized
modification, addition or deletion in order to ensure that only
trusted certificate authorities are present. If an adversary
is able to alter the trust anchor database then falsified
certificates could pass validation and cause harm to the NEA
deployment.
Enveloped-data content can make use of data encryption keys,
initialization vectors and padding that are generated by the
sender and that must be unpredictable by third parties using
entropy that can not be influenced or predicted by untrusted
software [11]. The generated keys must be resilient to passive
eavesdropping and active attacks that attempt to steal them for
future use. Therefore, CMS encrypts these keys when sent
between the Posture Collector and Posture Validator using a
variety of types of key management algorithms discussed in the
CMS specification. Any non-public key used to encrypt the
content encryption keys must also be protected from prediction
or disclosure on the network, NEA Client or NEA Server system.
Key management schemes that make use of previously distributed
key encrypting key require those keys are protected from
unauthorized access while on persistent storage and in memory.
Failure to do so could lead to the exposure of the content
encryption keys and thus the protected attributes.
Sangster Expires August 7, 2008 [Page 42]
Internet-Draft PA-TNC Security February 2008
4.2.3. Denial of Service
PA-TNC security provides a protective CMS wrapper around a set
of one or more attributes allowing the recipient to detect
attacks on the PA-TNC message attributes. However, while
detection is possible, repair of the attribute is not, so
recipients are forced to drop protected contents that have been
altered. If an attacker can modify every protected attribute,
this would result in the protected attributes being dropped and
thus a denial of service (DoS) of the assessment.
Implementations should provide proper audit logging facilities
and alerting capabilities to enable deployers to become aware
of when such attacks are in progress. These facilities may
also be used to cause other DoS attacks, so the amount of
logging and alerting should be able to be throttled by deployer
controls (e.g. notify the admin at most once per hour). A
similar DoS attack can be achieved by a malicious intermediary
that just drops all TNC messages.
Another form of DoS against the CMS protected content involves
sending a high rate of PA-TNC messages containing large
falsified or replayed enveloped-data protected attributes.
This will cause the recipients to spend CPU cycles decrypting
the messages before finding out the content is falsified or
replayed when the attributes signatures is verified. This
threat may not be feasible when an authenticated PT protocol is
present.
Other forms of DoS attack target the CMS wrapper information
for enveloped-data. This information is outside of the CMS
signature so could be modified to cause problems for recipients
processing the message after significant CPU time has occurred.
For example an attacker might modify the recipientInfos
structure to break the key management schemes used to exchange
the content encryption keys. This could result in the
encrypted content no longer be able to decrypt and the message
would be discarded.
Finally, DoS attacks are possible by hostile intermediaries
modifying the paTncErrorCode, paTncSecurityCapabilities or
paTncNonce CMS attributes such that potential senders of
protected information are unable to find common algorithms with
their target recipients or pass the replay checks. Because the
CMS signed attributes are contained in signedAttrs field, these
modifications will be detected and thus the information
discarded
Sangster Expires August 7, 2008 [Page 43]
Internet-Draft PA-TNC Security February 2008
5. IANA Considerations
One new IANA registry is defined by this specification: IETF
Standard PA-TNC Error Code. This section explains how this
registry will work.
First, it is important to note that the PA-TNC Error Code name
space can support both IETF standard values listed in the IANA
registry while allowing for vendor specific attributes to be
used. The PA-TNC Error Codes are always accompanied by an SMI
Private Enterprise Number (PEN) based OID, also known as the
vendor ID. If this vendor ID is zero, the accompanying PA-TNC
Error Code is an IETF standard value listed in the IANA
registry and its meaning is defined in the RFC listed. If the
vendorID OID is not zero, the meaning of the PA-TNC Error Code
has a vendor-specific defined by the vendor identified by the
vendorID OID (as listed in the IANA registry for SMI PENs).
The following subsections provide guidance to the IANA in
creating and managing the new IANA registry defined by this
specification.
5.1. Registry for IETF Standard PA-TNC Error Codes
The name for this registry is "IETF Standard PA-TNC Error
Codes". Each entry in this registry should include a human-
readable name, a decimal integer value between 0 and 2^16-1,
and a reference to an RFC (long lived document) where this
error code is defined. This RFC must define the meaning of
this error code and a description of when it occurs. The RFC
can be any form of RFC including experimental and be an
individual submission.
Entries to this registry may only be added by IETF Consensus,
as defined in RFC 2434 [2]. That is, they can only be added in
an RFC approved by the IESG.
The following entries for this registry are defined in this
document. Once this document becomes an RFC, they should
become the initial entries in the registry for IETF Standard
PB-TNC Error Codes.
Sangster Expires August 7, 2008 [Page 44]
Internet-Draft PA-TNC Security February 2008
Value Name Defining RFC
----- ---- ------------
0 Reserved This value MUST NOT be used
1 decodeFailure RFC # Assigned to this I-D
2 badContentInfo RFC # Assigned to this I-D
3 badSignedData RFC # Assigned to this I-D
4 badEnvelopedData RFC # Assigned to this I-D
5 badCertificate RFC # Assigned to this I-D
6 badSignerInfo RFC # Assigned to this I-D
7 badSignedAttrs RFC # Assigned to this I-D
8 badUnsignedAttrs RFC # Assigned to this I-D
9 missingContent RFC # Assigned to this I-D
10 noTrustAnchor RFC # Assigned to this I-D
11 notAuthorized RFC # Assigned to this I-D
12 badDigestAlgorithm RFC # Assigned to this I-D
13 badSignatureAlgorithm RFC # Assigned to this I-D
14 unsupportedKeySize RFC # Assigned to this I-D
15 unsupportedParameters RFC # Assigned to this I-D
16 signatureFailure RFC # Assigned to this I-D
17 decryptionFailure RFC # Assigned to this I-D
18 keyManageFailure RFC # Assigned to this I-D
19 badKeyManage RFC # Assigned to this I-D
20 nonceMissing RFC # Assigned to this I-D
21 invalidNonce RFC # Assigned to this I-D
22 repeatedNonce RFC # Assigned to this I-D
23 nonceOrdering RFC # Assigned to this I-D
24 badContentType RFC # Assigned to this I-D
25 digestAlgMismatch RFC # Assigned to this I-D
29 missingSignature RFC # Assigned to this I-D
30 resourcesBusy RFC # Assigned to this I-D
31 versionNumberMismatch RFC # Assigned to this I-D
33 revokedCertificate RFC # Assigned to this I-D
65535 other RFC # Assigned to this I-D
6. Acknowledgments
The authors of this draft would like to acknowledge the
following people who have contributed to or provided
substantial input on the preparation of this document or
predecessors to it: Diana Arroyo, Stuart Bailey, Scott
Cochrane, Sandilya Garimella, Lauren Giroux, Steve Hanna,
Thomas Hardjono, Chris Hessing, Josh Howlett, John Jerrim,
Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, PJ Kirner,
Sung Lee, Lisa Lorenzin, Mahalingam Mani, Mauricio Sanchez,
Ravi Sahita, Curtis Simonson, Brad Upson, Han Yin.
This document was prepared using 2-Word-v2.0.template.dot.
Sangster Expires August 7, 2008 [Page 45]
Internet-Draft PA-TNC Security February 2008
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Alvestrand, H. and Narten T., "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October
1998.
[3] Housley R., "Cryptographic Message Syntax (CMS)
Algorithms", http://www.ietf.org/rfc/rfc3370.txt, IETF,
August 2002.
[4] Turner. S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", IETF, Internet Draft, Work in Progress.
7.2. Informative References
[5] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and
Tardo J., "Network Endpoint Assessment (NEA): Overview
and Requirements", draft-ietf-nea-requirements-05.txt,
Work In Progress, November 2007.
[6] Sangster, P., "PA-TNC: A Posture Attribute Protocol (PA)
Compatible with TNC", draft-sangster-nea-pa-tnc-00.txt,
February 2008.
[7] Sangster, P., "TNC IF-M Security: Bindings to CMS",
Trusted Computing Group, February 2008.
Sangster Expires August 7, 2008 [Page 46]
Internet-Draft PA-TNC Security February 2008
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
http://www.ietf.org/rfc/rfc3851.txt, IETF, July 2004.
[9] Housley R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages",
http://www.ietf.org/rfc/rfc4108.txt, IETF, August 2005.
[10] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
[11] Eastlake 3 , D., Crocker, S., and Schiller, J.,
"Randomness Recommendations for Security",
http://www.ietf.org/rfc/rfc1740.txt, IETF, December 1994.
[12] Housley R., Wallace C., "Trust Anchor Management
Protocol", draft-housley-tamp-00.txt, IETF, December 1994.
Author's Addresses
Paul Sangster
Symantec Corporation
6825 Citrine Dr
Carlsbad, CA 92009 USA
email: Paul_Sangster at symantec.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which
any license under such rights might or might not be available;
nor does it represent that it has made any independent effort
to identify any such rights. Information on the procedures
with respect to rights in RFC documents can be found in BCP 78
and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of
an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementers or users of
this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
Sangster Expires August 7, 2008 [Page 47]
Internet-Draft PA-TNC Security February 2008
required to implement this standard. Please address the
information to the IETF at ietf-ipr at ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by
the Internet Society.
Sangster Expires August 7, 2008 [Page 48]
Network Working Group R. Sahita
Internet Draft Intel
Intended status: Proposed Standard S. Hanna
Expires: August 2008 Juniper
R. Hurst
Microsoft
February 18, 2008
PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC
draft-sahita-nea-pb-tnc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document specifies PB-TNC, a Posture Broker Protocol identical
to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document
Sahita et al. Expires August 18, 2008 [Page 1]
Internet-Draft PB-TNC February 2008
then evaluates PB-TNC against the requirements defined in the NEA
Requirements specification.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Table of Contents
1. Introduction...................................................3
1.1. Background on Trusted Computing Group.....................3
1.2. Background on Trusted Network Connect.....................4
1.3. Submission of This Document...............................4
1.4. Prerequisites.............................................4
1.5. Message Diagram Conventions...............................4
1.6. Terminology...............................................5
2. PB-TNC Protocol Description....................................5
2.1. Protocol Overview.........................................5
2.2. PB-TNC State Machine......................................6
2.3. Layering on PT............................................8
2.4. Example of PB-TNC Encapsulation...........................8
3. PB-TNC Protocol Specification..................................9
3.1. PB-TNC Header.............................................9
3.2. PB-TNC Message...........................................10
3.3. IETF Standard PB-TNC Message Types.......................13
3.4. PB-Experimental..........................................13
3.5. PB-Batch-Type............................................14
3.6. PB-PA....................................................16
3.7. PB-Access-Recommendation.................................21
3.8. PB-Remediation-Parameters................................22
3.8.1. IETF Standard PB-TNC Remediation Parameters Types...25
3.9. PB-Error.................................................26
3.9.1. IETF Standard PB-TNC Error Codes....................28
3.9.2. Error Parameters Structures for IETF Standard PB-TNC
Error Codes................................................29
3.10. PB-Language-Preference..................................30
3.11. PB-Reason-String........................................32
4. Evaluation Against NEA Requirements...........................34
4.1. Evaluation Against Requirement C-1.......................34
4.2. Evaluation Against Requirement C-2.......................34
4.3. Evaluation Against Requirement C-3.......................35
4.4. Evaluation Against Requirement C-4.......................35
4.5. Evaluation Against Requirement C-5.......................35
4.6. Evaluation Against Requirement C-6.......................36
4.7. Evaluation Against Requirement C-7.......................36
Sahita et al. Expires August 18, 2008 [Page 2]
Internet-Draft PB-TNC February 2008
4.8. Evaluation Against Requirement C-8.......................37
4.9. Evaluation Against Requirement C-9.......................37
4.10. Evaluation Against Requirement C-10.....................37
4.11. Evaluation Against Requirement PB-1.....................37
4.12. Evaluation Against Requirement PB-2.....................38
4.13. Evaluation Against Requirement PB-3.....................38
4.14. Evaluation Against Requirement PB-4.....................38
4.15. Evaluation Against Requirement PB-5.....................39
4.16. Evaluation Against Requirement PB-6.....................39
5. Security Considerations.......................................39
5.1. Threat Model.............................................40
5.2. Countermeasures..........................................41
6. IANA Considerations...........................................42
6.1. Registry for IETF Standard PB-TNC Message Types..........43
6.2. Registry for IETF Standard PA Subtypes...................43
6.3. Registry for IETF Standard PB-TNC Remediation Parameters
Types.........................................................44
6.4. Registry for IETF Standard PB-TNC Error Codes............44
7. Acknowledgments...............................................45
8. References....................................................46
8.1. Normative References.....................................46
8.2. Informative References...................................46
Author's Addresses...............................................46
Intellectual Property Statement..................................47
Disclaimer of Validity...........................................47
1. Introduction
This document specifies PB-TNC, a Posture Broker Protocol (PB)
identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol [6].
The document then evaluates PB-TNC against the requirements defined
in the NEA Requirements specification [7].
1.1. Background on Trusted Computing Group
The Trusted Computing Group (TCG) is a consortium that develops
specifications for trusted (secure) computing. Since its formation
in 2003, TCG has published specifications for a variety of
technologies such as Trusted Platform Module (TPM), TCG Software
Stack (TSS), Mobile Trusted Module (MTM), and Trusted Network Connect
(TNC).
TCG members include more than 175 organizations that design, build,
sell, or use trusted computing technology. Membership is open to any
organization that signs the membership agreement and pays the annual
membership fee. Non-members are welcome to implement the TCG
specifications. Several open source implementers have done so.
Sahita et al. Expires August 18, 2008 [Page 3]
Internet-Draft PB-TNC February 2008
1.2. Background on Trusted Network Connect
Starting in 2004, the TCG has defined and published the Trusted
Network Connect (TNC) architecture and standards for network access
control. These standards enable multi-vendor interoperability
throughout the architecture and have been widely adopted and
deployed.
1.3. Submission of This Document
The IETF has recently chartered the Network Endpoint Assessment (NEA)
working group to develop several standards in the same area as TNC.
In order to avoid the development of multiple incompatible standards,
the TCG is offering several of its TNC standards to the IETF as
candidates for standardization in the IETF also. This document is
equivalent to TCG's IF-TNCCS 2.0 [6].
Consistent with IETF's requirements for standards track documents,
the TCG (the copyright holder for this text) has granted the licenses
described in section 3.3 of IETF RFC 3978 to the IETF Trust for the
text contained in this document. As with other Internet-Drafts, the
IETF may modify this document, ignore it, publish it as an RFC, or
take any other action. If the IETF decides to adopt a later version
of this document as an RFC, the TCG plans to publish a specification
for an equivalent TNC protocol to ensure compatibility.
1.4. Prerequisites
This document does not define an architecture or reference model.
Instead, it defines a protocol that works within the reference model
described in the NEA Requirements specification. The reader is
assumed to be thoroughly familiar with that document. No familiarity
with TCG specifications is assumed.
1.5. Message Diagram Conventions
This specification defines the syntax of PB-TNC messages using
diagrams. Each diagram depicts the format and size of each field in
bits. Implementations MUST send the bits in each diagram as they are
shown, traversing the diagram from top to bottom and then from left
to right within each line (which represents a 32-bit quantity).
Multi-byte fields representing numeric values must be sent in network
(big endian) byte order.
Descriptions of bit field (e.g. flag) values are described referring
to the position of the bit within the field. These bit positions are
Sahita et al. Expires August 18, 2008 [Page 4]
Internet-Draft PB-TNC February 2008
numbered from the most significant bit through the least significant
bit so a one octet field with only bit 0 set has the value 0x80.
1.6. Terminology
This document reuses the terminology defined in the NEA Requirements
document. One new term is defined in this section.
Batch - A group of PB-TNC messages sent over a PT protocol at one
time. Since the PB-TNC protocol needs to be able to work over a
half-duplex PT protocol, PB-TNC messages are grouped into batches.
The Posture Broker Client sends one batch to the Posture Broker
Server, which responds with a batch.
2. PB-TNC Protocol Description
2.1. Protocol Overview
The PB-TNC protocol carries batches of PB messages between a Posture
Broker Client and a Posture Broker Server. It encapsulates PA
messages and manages the NEA session. It runs over a PT transport
protocol.
In order to work well over half-duplex PT protocols (such as those
based on EAP [8]), PB-TNC is a half-duplex protocol. The Posture
Broker Client and Posture Broker Server take turns sending batches of
messages to each other. While the half-duplex nature of PB-TNC could
slow exchanges that require many round trips or bidirectional
multimedia exchanges, this is not a problem in practice because
endpoint assessments do not typically involve multimedia or a large
number of round trips. The benefit of working over half-duplex
transports outweighs any limitations imposed.
Each PB-TNC batch consists of a header followed by a sequence of PB-
TNC messages. Each PB-TNC message has a Type-Length-Value (TLV)
format with a few flags. The TLV format allows a recipient to skip
messages that it does not understand. The TLV format also provides a
standard way to mark messages as mandatory to ensure interoperability
between a Posture Broker Client and a Posture Broker Server.
This specification defines certain standard PB-TNC message types. It
also permits vendors to define their own vendor-specific message
types. One of the most important standard PB-TNC message types is
PB-PA. A message with this type contains a PA message and various
message routing information. A Posture Broker Client or Posture
Broker Server that receives such a message does not interpret the PA
message within. Instead, it delivers the PA message to the
Sahita et al. Expires August 18, 2008 [Page 5]
Internet-Draft PB-TNC February 2008
appropriate set of Posture Collectors or Posture Validators, as
determined using the message routing information contained in the PB-
PA message. Another important standard PB-TNC message type is PB-
Batch-Type, which contains a batch type that drives state machine
transitions.
A Posture Broker Server will often need to communicate with several
Posture Broker Clients at once. The reverse may also be true, as
when an endpoint has multiple network interfaces connected to
different networks. Each connection between a Posture Broker Server
and a Posture Broker Client is instantiated as a separate PB-TNC
session. There may be several simultaneous sessions between a single
Posture Broker Server and Posture Broker Client but this is unusual.
2.2. PB-TNC State Machine
Figure 1 illustrates the PB-TNC state machine, showing the set of
states that a PB-TNC session can have and the possible transitions
among these states. The following paragraphs describe this state
machine in more detail.
+---------+ CRETRY +---------+
CDATA | Server |<---------| Decided | CLOSE
+----------->| Working |--------->| |-------+
| +---------+ RESULT +---------+ |
| ^ | | v
| | | +---------------------->=======
======== | | CLOSE " End "
" Init " CDATA or| |SDATA or =======
======== CRETRY| |SRETRY ^ ^
| | | v | |
| | SDATA +---------+ CLOSE | |
| +-------->| Client |----------------------+ |
| | Working | |
| +---------+ |
| CLOSE |
+--------------------------------------------------+
Figure 1 PB-TNC State Machine
In this diagram, states are indicated by rectangular boxes. The
initial and terminal states have double outlines (with = and ").
State transitions are indicted by unidirectional arrows marked with
the cause of the transition.
Many transitions (CDATA, SDATA, CRETRY, SRETRY, and RESULT) are
triggered by the transmission or reception of a PB-TNC batch of a
Sahita et al. Expires August 18, 2008 [Page 6]
Internet-Draft PB-TNC February 2008
particular type. The type of a PB-TNC batch is indicated by the
contents of a PB-TNC message of type PB-Batch-Type within that batch.
For brevity, this document says "a FOO batch" instead of "a PB-TNC
batch containing a PB-TNC message of type PB-Batch-Type whose Batch
Type is FOO".
A PB-TNC session starts in the Init state when the underlying
transport protocol (PT) establishes a connection between a Posture
Broker Client and a Posture Broker Server. If the Posture Broker
Client initiated the underlying transport session, it starts by
sending a CDATA batch to the Posture Broker Server, thus causing a
transition to the Server Working state. If the Posture Broker Server
initiated the transport session, it starts by sending a PB-TNC batch
of type SDATA to the Posture Broker Client, thus causing a transition
to the Client Working state.
The Posture Broker Client and Posture Broker Server may now alternate
sending CDATA and SDATA batches to each other. Since PB-TNC is a
half-duplex protocol, only the Posture Broker Client can send a batch
when the session is in the Client Working state and only the Posture
Broker Server can send a batch when the session is in the Server
Working state.
The most common way to end an exchange is for the Posture Broker
Server to send a RESULT batch. This causes a transition into the
Decided state. This is not a terminal state. The PT session can
remain open and another exchange can be initiated by having the
Posture Broker Client send a CRETRY batch. This can be useful when
the Posture Broker Client (or more likely a Posture Collector)
discovers a suspicious condition on the endpoint, for example.
The Posture Broker Client can also initiate a new exchange by sending
a CRETRY batch when the session is in the Client Working state. The
Posture Broker Server can perform a similar operation by sending a
SRETRY batch when the session is in the Server Working state. This
can be useful if a suspicious condition arises on the endpoint or a
policy changes on the NEA Server while an exchange is underway.
The only terminal state is the End state. This state is reached if
the underlying PT connection closes. This can be caused by an action
of the Posture Broker Client or Posture Broker Server or it can be
caused by some external factor, such as pulling the network plug. No
PB-TNC batch is sent to indicate that the exchange has been closed.
The Posture Broker Client and Posture Broker Server will generally
receive some form of notification from the Posture Transport Client
and Posture Transport Server that the PT connection has been closed
but this interaction is not standardized since the vertical
Sahita et al. Expires August 18, 2008 [Page 7]
Internet-Draft PB-TNC February 2008
interfaces in the NEA Reference Model are not standardized. The
CLOSE notification causes the transition to the End state.
Note that a Posture Broker Client and Posture Broker Server may not
always have exactly the same state for a given PB-TNC session. For
example, say that a session is in the Client Working state and the
Posture Broker Client transmits a CDATA batch. While this batch is
in transit (transmitted by the Posture Broker Client but not yet
received by the Posture Broker Server), the Posture Broker Client
will think that the session is in Server Working state but the
Posture Broker Server will think that the session is in Client
Working state. However, this is a temporary condition and does not
cause problems in practice. The only possible issue is that a
Posture Broker Client or Posture Broker Server does not know whether
the other party has received its message until it receives a response
from the other party.
Note that the Posture Broker Server cannot send a SRETRY batch when
the session is in the Decided state because the Posture Broker Server
sent the most recent batch (the RESULT batch) and this would violate
the half-duplex nature of the PB-TNC protocol. Instead, a server
that wishes to initiate a new exchange in the Decided state should
close the PT connection and start a new PB-TNC session.
2.3. Layering on PT
PB-TNC batches are carried over protocol bindings of the PT protocol,
which provides the interaction between a Posture Transport Client and
a Posture Transport Server. PB-TNC counts on PT to provide a secure
transport. In particular, PT MUST support mutual authentication of
the Posture Transport Client and the Posture Transport Server,
confidentiality and integrity protection for PB-TNC batches, and
protection against replay attacks. PB-TNC is unaware of the
underlying transport protocols being used. PB-TNC operates directly
on PT; no further layer of PB-TNC is expected.
2.4. Example of PB-TNC Encapsulation
This section shows how PA messages can be carried inside a PB-TNC
batch which is inside a PT protocol.
Within the PT protocol, the PB-TNC header is packaged next, followed
by a PB-Batch-Type message and two PB-PA messages that contain PA
messages meant for the Posture Collectors and Posture Validators on
the platform.
Sahita et al. Expires August 18, 2008 [Page 8]
Internet-Draft PB-TNC February 2008
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-Batch-Type Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Example of PB-TNC message encapsulation
This figure is conceptual, of course, and not an exact byte-for-byte
replica.
3. PB-TNC Protocol Specification
3.1. PB-TNC Header
Every PB-TNC batch MUST start with the following header. A PB-TNC
batch MUST contain only one instance of this header followed by one
or more PB-TNC messages. The PB-TNC messages are defined in
subsequent sections of this specification.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (4 bits)
This field MUST be set to 2 when the batch conforms to this
specification. Later versions of PB-TNC may define other values
for this field. If a Posture Broker Client or Posture Broker
Server receives a Version value that it does not support, it
SHOULD respond with an Invalid Parameter error code.
Reserved (28 bits)
This field is reserved. For this version of this specification,
it MUST be set to 0 on transmission and ignored on reception.
Future versions of this specification may allow senders to set
some of these bits and recipients to interpret them.
Sahita et al. Expires August 18, 2008 [Page 9]
Internet-Draft PB-TNC February 2008
Batch Length (32 bits)
This length field contains the size of the full PB-TNC batch in
octets. This length includes the PB-TNC header and all the PB-TNC
messages in the batch. In other words, it includes the entire
contents of the batch.
3.2. PB-TNC Message
All PB-TNC messages have the same overall structure, which is
described in this section. Of course, the format and semantics of
the PB-TNC Message Value field will vary, depending on the values of
the PB-TNC Vendor ID and PB-TNC Message Type fields.
0 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 | PB-TNC Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
This field defines flags impacting the processing of this message.
Bit 0 of this flags field (the most significant bit) is known as
the NOSKIP flag. If this flag is cleared (value 0), then the
recipient (a Posture Broker Client or Posture Broker Server) may
skip (ignore) this message if the message type is not understood
or the recipient cannot or will not process the message as
required in the definition of that message. If this flag is set
(value 1), then recipients MUST NOT skip this attribute.
This flag does not mean that all recipients must support this
message. Instead, any recipient that receives a message with this
flag set to 1 but cannot or will not process it as required MUST
NOT act on any part of the PB-TNC batch. Instead, the recipient
SHOULD include an Unsupported Mandatory Message error code in the
next batch that it sends. In order to avoid taking action on some
messages in a batch only to later find an unsupported NOSKIP
flagged message, recipients of a PB-TNC batch might choose to scan
all of the messages in the batch prior to acting upon any of the
Sahita et al. Expires August 18, 2008 [Page 10]
Internet-Draft PB-TNC February 2008
messages, checking to determine whether one of them is an
unsupported message with the NOSKIP flag set.
The other bits in this Flags field are reserved. For this version
of PB-TNC, they MUST be set to 0 on transmission and ignored on
reception.
PB-TNC Vendor ID (24 bits)
The PB-TNC 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.
This Vendor ID qualifies the PB-TNC Message Type field so that
each vendor has 2^32-1 separate message types available for their
use.
Message types standardized by the IETF use zero (0) in this field.
The Vendor ID 0xffffff is reserved. Posture Broker Clients and
Posture Broker Servers MUST NOT send messages in which the Vendor
ID has this reserved value (0xffffff). If a Posture Broker Client
or Posture Broker Server receives a message in which the PB-TNC
Vendor ID has this reserved value (0xffffff), it SHOULD send an
Invalid Parameter error code in the next batch that it sends.
PB-TNC Message Type (32 bits)
The PB-TNC Message Type field identifies the type of the PB-TNC
message contained in the PB-TNC Message Value field. The PB-TNC
message type 0xffffffff is reserved. Posture Broker Clients and
Posture Broker Servers MUST NOT send messages in which the PB-TNC
Message Type field has this reserved value (0xffffffff). If a
Posture Broker Client or Posture Broker Server receives a message
in which the PB-TNC Message Type field has this reserved value
(0xffffffff), it SHOULD send an Invalid Parameter error code in
the next batch that it sends. Unless otherwise prohibited in the
definition of a particular PB-TNC Message Type (e.g. PB-Batch-
Type), a single PB-TNC batch may contain multiple messages with
the same message type and/or Vendor ID.
The IETF and any other organization with a PEN can define 2^32 - 1
unique PB-TNC message types, as long as the organization's PEN is
placed in the PB-TNC Vendor ID field of the message. Since the
PB-TNC message type is qualified by the Vendor ID, there is no
risk of conflicts as long as each organization uses its own PEN
for the Vendor ID and manages its own set of 2^32-1 message type
values.
Sahita et al. Expires August 18, 2008 [Page 11]
Internet-Draft PB-TNC February 2008
This document defines certain PB-TNC message types which, when
used with the IETF SMI PEN (0), have standard meanings. These are
known as IETF standard PB-TNC message types. Some of these PB-TNC
message types are mandatory and therefore MUST be implemented by
all Posture Broker Client and Posture Broker Server
implementations that claim compliance with this specification.
For details on which PB-TNC message types are mandatory, see the
description of these message types later in section 3.
IANA maintains a registry of IETF standard PB-TNC message types.
Entries may only be added to this registry by IETF Consensus.
That is, they must be defined in an RFC approved by the IESG.
New vendor-specific PB-TNC message types (those used with a non-
zero PB-TNC vendor ID) may be defined and employed by vendors
without IETF or IANA involvement. However, Posture Broker Clients
and Posture Broker Servers MUST NOT require support for particular
vendor-specific PB-TNC message types and MUST interoperate with
other parties despite any differences in the set of vendor-
specific PB-TNC message types supported (although they MAY permit
administrators to configure them to require support for specific
PB-TNC message types).
Note that the PB-TNC Message Type field is completely separate
from the PA Subtype field. The same value (e.g. 0) may have
different meanings as a PB-TNC message type and as a PA subtype.
PB-TNC Message Length (32 bits)
This field specifies the length of this PB-TNC message in octets.
It includes this header (the fields Flags, PB-TNC Vendor ID, PB-
TNC Message Type, and PB-TNC Message Length). Therefore, this
value MUST always be at least 12. Any Posture Broker Client or
Posture Broker Server that receives a message with a PB-TNC
Message Length field whose value is less than 12 SHOULD send an
Invalid Parameter error code in response.
PB-TNC Message Value (variable length)
The syntax and semantics of this field varies, depending on the
values in the PB-TNC Vendor ID and PB-TNC Message Type fields.
The syntax and semantics of several standard messages is defined
in subsequent sections of this specification.
Sahita et al. Expires August 18, 2008 [Page 12]
Internet-Draft PB-TNC February 2008
3.3. IETF Standard PB-TNC Message Types
This table provides a reference list with brief descriptions of the
IETF standard PB-TNC message types defined in this specification.
These PB-TNC message types must be used with a PB-TNC vendor ID of
zero (0). If these PB-TNC message type values are used with a
different PB-TNC vendor ID, they have a completely different meaning
that is not defined in this specification.
For more details on these message types, see the remainder of section
3. For IETF standard PA subtypes (which are completely different
from PB-TNC message types), please refer to the PA-TNC specification
[9].
Message Type Definition
------------ ----------
0 PB-Experimental - reserved for experimental use
1 PB-Batch-Type - indicates the type of the PB-TNC batch
that contains this message
2 PB-PA - contains a PA message
3 PB-Access-Recommendation - includes Posture Broker
Server access recommendation (also known as global
assessment decision)
4 PB-Remediation-Parameters - includes Posture Broker
Server remediation parameters
5 PB-Error - error indicator
6 PB-Language-Preference - sender's preferred
language(s) for human-readable strings
7 PB-Reason-String - string explaining reason for
Posture Broker Server access recommendation
3.4. PB-Experimental
The PB-Experimental PB-TNC message type is a PB-TNC message type
(value 0) that has been set aside for experimental purposes. It may
be used to test code or for other experimental purposes. It MUST NOT
be used in a production environment or in a product. This meaning
for this PB-TNC message type only applies if the PB-TNC Vendor ID
field in the PB-TNC Message Header contains the value zero (0). If a
different Vendor ID is contained in that field, the PB-TNC message
type 0 has a completely different meaning not defined in this
specification.
The contents of the PB-TNC Message Length and PB-TNC Message Value
fields for this PB-TNC message type are not specified. They may have
almost any value, depending on what experiments are being conducted.
Similarly, the Flags field for this message may have the NOSKIP bit
Sahita et al. Expires August 18, 2008 [Page 13]
Internet-Draft PB-TNC February 2008
set or cleared, depending on what experiments are being conducted.
However, note that the PB-TNC Message Length field must have a value
of at least 12 since that is the total of the length of the fixed-
length fields at the start of the PB-TNC message (the fields Flags,
PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length).
Any Posture Broker Client or Posture Broker Server that receives a
message with a PB-TNC Message Length field whose value is invalid
SHOULD send an Invalid Parameter error code in response.
A Posture Broker Client or Posture Broker Server implementation
intended for production use MUST NOT send a message with this Message
Type with the value zero (0) as the Vendor ID. If it receives a
message with this Message Type and with the value zero (0) as the
Vendor ID, it SHOULD ignore the message unless the NOSKIP bit is set,
in which case it SHOULD send an Unsupported Mandatory Message error
code in the next batch that it sends.
3.5. PB-Batch-Type
The PB-TNC message type named PB-Batch-Type (value 1) indicates the
type of the PB-TNC batch that contains it. This value is used to
drive the state machine described in section 2.2.
Each PB-TNC batch MUST contain one and only one message with type PB-
Batch-Type. Any Posture Broker Client or Posture Broker Server that
receives a PB-TNC batch that contains more than one message with type
PB-Batch-Type or contains no such message SHOULD ignore the entire
batch and send a fatal Invalid Parameter error code in response. All
Posture Broker Client and Posture Broker Server implementations MUST
implement support for this PB-TNC message type.
The NOSKIP flag in the PB-TNC Message Header MUST be set for this
message type and the PB-TNC Message Type field MUST contain 1. The
PB-TNC Vendor ID field MUST contain zero (0). If a different Vendor
ID is contained in that field, the Message Type 1 has a completely
different meaning not defined in this specification.
The PB-TNC Message Length field MUST contain the value 16 since that
is the total of the length of the fixed-length fields at the start of
the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC
Message Type, and PB-TNC Message Length) along with the fields
described below. Any Posture Broker Client or Posture Broker Server
that receives a PB-Batch-Type message with a PB-TNC Message Length
field that does not have a value of 16 SHOULD send an Invalid
Parameter error code in response.
Sahita et al. Expires August 18, 2008 [Page 14]
Internet-Draft PB-TNC February 2008
The following diagram illustrates the format and contents of the PB-
TNC Message Value field for this message type. The text after this
diagram describes the fields shown here.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| Reserved | Batch Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Directionality (D) (1 bit)
When a Posture Broker Client is sending this message, the
Directionality bit MUST be set to 0. When a Posture Broker Server
is sending this message, the Directionality bit MUST be set to 1.
This helps avoid any situation where two Posture Broker Clients or
two Posture Broker Servers engage in a dialog. It also helps with
debugging.
Reserved (15 bits)
These Reserved bits MUST be set to 0 on transmission and ignored
on reception.
Batch Type (16 bits)
The Batch Type field MUST have one of the values from the
following table. If any other value is received, the recipient
MUST send a Malformed Message error code in response. In
addition, if the value received is not permitted for the current
state, according to the state machine in section 2.2, the
recipient MUST send an Unexpected Batch Type error code in
response.
Number Name Definition
------ ---- ----------
1 CDATA The Posture Broker Client may send a batch with
this Batch Type to convey messages to the
Posture Broker Server. A Posture Broker Server
MUST NOT send this Batch Type. If a Posture
Broker Client receives a batch with this Batch
Type, it SHOULD ignore the batch and send a
fatal Unexpected Batch Type error code in
response. This message may be the only message
Sahita et al. Expires August 18, 2008 [Page 15]
Internet-Draft PB-TNC February 2008
in a batch, if the Posture Broker Client has
nothing else to send.
2 SDATA The Posture Broker Server may send a batch with
this Batch Type to convey messages to the
Posture Broker Client. A Posture Broker Client
MUST NOT send this Batch Type. If a Posture
Broker Server receives a batch with this Batch
Type, it SHOULD ignore the batch and send a
fatal Unexpected Batch Type error code in
response. This message may be the only message
in a batch, if the Posture Broker Server has
nothing else to send.
3 RESULT The Posture Broker Server may send a batch with
this Batch Type to indicate that it has
completed its evaluation. The batch SHOULD
include a PB-Access-Recommendation message.
4 CRETRY The Posture Broker Client may send a batch with
this Batch Type to indicate that it wishes to
restart an exchange. A Posture Broker Server
MUST NOT send this Batch Type. If a Posture
Broker Client receives a batch with this Batch
Type, it SHOULD ignore the batch and send a
fatal Unexpected Batch Type error code in
response. This message may be the only message
in a batch, if the Posture Broker Client has
nothing else to send.
5 SRETRY The Posture Broker Server may send a batch with
this Batch Type to indicate that it wishes to
restart the exchange. A Posture Broker Client
MUST NOT send this Batch Type. If a Posture
Broker Server receives a batch with this Batch
Type, it SHOULD ignore the batch and send a
fatal Unexpected Batch Type error code in
response. This message may be the only message
in a batch, if the Posture Broker Server has
nothing else to send.
3.6. PB-PA
The PB-TNC message type named PB-PA (value 2) contains one PA
message. Many batches will contain several PB-PA messages but some
batches may not contain any messages of this type.
Sahita et al. Expires August 18, 2008 [Page 16]
Internet-Draft PB-TNC February 2008
All Posture Broker Client and Posture Broker Server implementations
MUST implement support for this PB-TNC message type. Generally, this
support will consist of forwarding the enclosed PA message to the
appropriate Posture Collectors and Posture Validators. Specific
requirements are contained later in the description of this message
type.
The NOSKIP flag in the PB-TNC Message Header MUST be set for this
message type. Any Posture Broker Client or Posture Broker Server
that receives a PB-PA message with the NOSKIP flag not set SHOULD
ignore the message and send a fatal Invalid Parameter error code in
response. The PB-TNC Vendor ID field MUST contain the value zero (0)
and the PB-TNC Message Type field MUST contain 2. If a non-zero
value is contained in the PB-TNC Vendor ID field, message type 2 has
a completely different meaning not defined in this specification.
The PB-TNC Message Length field MUST contain the length of the entire
PB-TNC message, including the fixed-length fields at the start of the
PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message
Type, and PB-TNC Message Length), the fixed-length fields listed
below (Flags, PA Message Vendor ID, PA Subtype, Posture Collector
Identifier, and Posture Validator Identifier), and the PA Message
Body. Since the PA Message Body is variable length, the value in the
PB-TNC Message Length field will vary also. However, it MUST always
be at least 24 to cover the fixed-length fields listed in the
preceding sentences. Any Posture Broker Client or Posture Broker
Server that receives a PB-PA message with a PB-TNC Message Length
field that has an invalid value SHOULD send an Invalid Parameter
error code in response.
The following diagram illustrates the format and contents of the PB-
TNC Message Value field for this message type. The text after this
diagram describes the fields shown here.
0 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 Message Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Posture Collector Identifier | Posture Validator Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Message Body (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
Sahita et al. Expires August 18, 2008 [Page 17]
Internet-Draft PB-TNC February 2008
This field contains flags relating to the PA message.
Bit 0 of this flags field (the most significant bit) is known as
the EXCL flag (for exclusive). If the EXCL bit is cleared (value
0), the Posture Broker Client or Posture Broker Server that
receives this PB-TNC message SHOULD deliver the PA message
contained in this PB-TNC message to all Posture Collectors or
Posture Validators that have expressed an interest in PA messages
with this PA Message Vendor ID and PA subtype. If a Posture
Broker Client receives a message with the EXCL flag set (value 1),
the Posture Broker Client SHOULD deliver the PA message contained
in this PB-TNC message only to the Posture Collector identified by
the Posture Collector Identifier field. However, if the
identified Posture Collector has not expressed an interest in PA
messages with this PA Message Vendor ID and PA subtype, the PA
message should be silently discarded. Analogous requirements
apply to a Posture Broker Server that receives a message with the
EXCL flag set.
The EXCL bit allows, for example, a Posture Validator to handle
the circumstance where there are two Posture Collectors on the
endpoint that are interested in a particular kind of PA messages
and the Posture Validator has remediation instructions that only
apply to one of those Posture Collectors.
The other bits in this Flags field are reserved. For this version
of PB-TNC, they MUST be set to 0 on transmission and ignored on
reception.
PA Message Vendor ID (24 bits)
The PA Message 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 PA Message Vendor ID qualifies the PA Subtype
field so that each vendor has 2^32-1 separate PA subtypes
available for its use. PA subtypes standardized by the IETF are
always used with a PA Message Vendor ID of the value zero (0) in
this field. The PA Message Vendor ID 0xffffff is reserved. A
Posture Broker Client or Posture Broker Server MUST NOT send
messages in which the PA Message Vendor ID field has this reserved
value (0xffffff). If a Posture Broker Client or Posture Broker
Server receives a message in which the PA Message Vendor ID has
this reserved value (0xffffff), it SHOULD send an Invalid
Parameter error code in the next batch that it sends.
PA Subtype (32 bits)
Sahita et al. Expires August 18, 2008 [Page 18]
Internet-Draft PB-TNC February 2008
The PA Subtype field identifies the type of the PA message
contained in the PA Message Body field. The PA subtype 0xffffffff
is reserved. A Posture Broker Client or Posture Broker Server
MUST NOT send messages in which the PA Subtype field has this
reserved value (0xffffffff). If a Posture Broker Client or
Posture Broker Server receives a message in which the PA Subtype
has this reserved value (0xffffffff), it SHOULD send an Invalid
Parameter error code in the next batch that it sends. A Posture
Broker Client or Posture Broker Server MUST support having
multiple PA messages in a single PB-TNC batch that have the same
PA subtype and/or PA Message Vendor ID.
IANA maintains a registry of IETF standard PA subtypes. Entries
may only be added to this registry by IETF Consensus. That is,
they must be defined in an RFC approved by the IESG. No IETF
standard PA subtypes are defined in this specification.
Definitions of IETF standard PA subtypes will be contained in the
PA specification and other RFCs. IETF standard PA subtypes are
always used with a PA Message Vendor ID of zero (0).
New vendor-specific PA subtypes (those used with a non-zero PA
Message Vendor ID) may be defined and employed by vendors without
IETF or IANA involvement. However, Posture Broker Clients and
Posture Broker Servers MUST NOT require support for particular
vendor-specific PA subtypes and MUST interoperate with other
parties despite any differences in the set of vendor-specific PA
subtypes supported (although they MAY permit administrators to
configure them to require support for specific PA subtypes).
Note that the PB-TNC Message Type field is completely separate
from the PA Subtype field. The same value (e.g. 0) may have
different meanings as a PB-TNC message type and as a PA subtype.
Posture Collector Identifier (16 bits)
The Posture Collector Identifier field contains the identifier of
the Posture Collector associated with this PA message.
The Posture Broker Client MUST assign a unique Posture Collector
Identifier value (but not 0xffff) to each Posture Collector
involved in a message exchange and include this Posture Collector
identifier in this field for any PA messages sent by that Posture
Collector. The Posture Collector Identifier value assigned to a
Posture Collector by a Posture Broker Client MUST NOT change
during the course of a PT session. This identifier is used to
identify a unique Posture Collector communicating with the Posture
Broker Client on the endpoint during a NEA exchange, and is used
Sahita et al. Expires August 18, 2008 [Page 19]
Internet-Draft PB-TNC February 2008
by the Posture Validator to send response attributes to a specific
Posture Collector component if required.
When a Posture Broker Server sets the EXCL flag for a PA message,
the Posture Broker Server MUST set the Posture Collector
Identifier field to the identifier of the Posture Collector that
should receive the PA message. If the EXCL flag is not set, a
Posture Broker Server MAY still set the Posture Collector
Identifier value for PA messages that it sends to indicate that
the PA message is intended as a response to a message sent by the
Posture Collector associated with the specified Posture Collector
Identifier. If the Posture Broker Server does not wish to
indicate any Posture Collector in this manner, it SHOULD set this
field to the reserved value 0xffff.
Posture Validator Identifier (16 bits)
The Posture Validator Identifier field contains the identifier of
the Posture Validator associated with this PA message.
The Posture Broker Server MUST assign a unique Posture Validator
Identifier value (but not 0xffff) to each Posture Validator
involved in a message exchange and include this Posture Validator
identifier in this field for any PA messages sent by that Posture
Validator. The Posture Validator Identifier value assigned to a
Posture Validator by a Posture Broker Server MUST NOT change
during the course of a PT session. This identifier is used to
identify a unique Posture Validator communicating with the Posture
Broker Server endpoint during a NEA exchange, and is used by the
Posture Collector to send attributes to a specific Posture
Validator if required.
When a Posture Broker Client sets the EXCL flag for a PA message,
the Posture Broker Client MUST set the Posture Validator
Identifier field to the identifier of the Posture Validator that
should receive the PA message. If the EXCL flag is not set, a
Posture Broker Client MAY still set the Posture Validator
Identifier value for PA messages that it sends to indicate that
the PA message is intended as a response to a message sent by the
Posture Validator associated with the specified Posture Validator
Identifier. If the Posture Broker Server does not wish to
indicate any Posture Validator in this manner, it SHOULD set this
field to the reserved value 0xffff.
PA Message Body (variable length)
Sahita et al. Expires August 18, 2008 [Page 20]
Internet-Draft PB-TNC February 2008
The PA Message Body field contains the body of the PA message that
is being carried in this PB-TNC message. The length of this field
can be determined by subtracting the length of the fixed-length
fields at the start of the PB-TNC message (the fields Flags, PB-
TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and
the fixed-length fields at the start of the PB-PA message (Flags,
PA Message Vendor ID, PA Subtype, Posture Collector Identifier,
and Posture Validator Identifier) from the message length
contained in the PB-TNC Message Length field. The length of these
fixed-length fields is 24 octets. Therefore, any Posture Broker
Client or Posture Broker Server that receives a PB-PA message with
a PB-TNC Message Length field whose value is less than 24 SHOULD
send an Invalid Parameter error code in response.
3.7. PB-Access-Recommendation
The PB-TNC message type named PB-Access-Recommendation (value 3) is
used by the Posture Broker Server to provide an access recommendation
after the Posture Broker Server has completed some assessment of the
endpoint. The Posture Broker Server SHOULD include one message of
this type in any batch of type RESULT and SHOULD NOT include a
message of this type in any other type of batch. The Posture Broker
Client MUST NOT send a PB-TNC message with this message type. The
Posture Broker Client SHOULD implement and process this message and
SHOULD ignore any message with this message type that is not part of
a batch of type RESULT.
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this
message type. Any Posture Broker Client or Posture Broker Server
that receives a PB-Access-Recommendation message with the NOSKIP flag
set SHOULD ignore the message and send a fatal Invalid Parameter
error code in response. The PB-TNC Vendor ID field MUST contain the
value zero (0) and the PB-TNC Message Type field MUST contain 3. If
a non-zero value is contained in the PB-TNC Vendor ID field, message
type 3 has a completely different meaning not defined in this
specification. The PB-TNC Message Length field MUST contain the
value 16 since that is the total of the length of the fixed-length
fields at the start of the PB-TNC message (the fields Flags, PB-TNC
Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with
the Access Recommendation field described below. Any Posture Broker
Client or Posture Broker Server that receives a PB-Access-
Recommendation message with a PB-TNC Message Length field that does
not have a value of 16 SHOULD send an Invalid Parameter error code in
response.
Sahita et al. Expires August 18, 2008 [Page 21]
Internet-Draft PB-TNC February 2008
The following diagram illustrates the format and contents of the PB-
TNC Message Value field for this message type. The text after this
diagram describes the fields shown here.
0 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 | Access Recommendation Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (16 bits)
These Reserved bits MUST be set to 0 on transmission and ignored
on reception.
Access Recommendation Code (16 bits)
The Access Recommendation Code field identifies the Access
Recommendation that the Posture Broker Server has made for this
Posture Broker Client at this time. This field MUST have one of
these three values: 1 for Access Allowed (full access), 2 for
Access Denied (no access), or 3 for Quarantined (partial access).
If a Posture Broker Client receives an Access Recommendation Code
value other than these three values, it SHOULD respond with an
Invalid Parameter error code. Other values may be defined in
future versions of PB-TNC but only if the PB-TNC version number is
changed. Therefore, there is no need for an IANA registry for
Access Recommendation Codes.
3.8. PB-Remediation-Parameters
The PB-TNC message type named PB-Remediation-Parameters (value 4) is
used by the Posture Broker Server to provide global (not Posture
Validator-specific) remediation parameters after the Posture Broker
Server has completed some assessment of the endpoint. The Posture
Broker Server MAY include one or more messages of this type in any
batch of any type but this message type is most useful in batches of
type RESULT.
The Posture Broker Client MUST NOT send a PB-TNC message with this
message type. The Posture Broker Client may implement and process
this message but is not required to do so. It may skip this message.
Even if the Posture Broker Client implements this message type, it is
not obligated to act on it.
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this
message type. The PB-TNC Vendor ID field MUST contain the value zero
Sahita et al. Expires August 18, 2008 [Page 22]
Internet-Draft PB-TNC February 2008
(0) and the PB-TNC Message Type field MUST contain 4. If a non-zero
value is contained in the PB-TNC Vendor ID field, message type 4 has
a completely different meaning not defined in this specification.
The PB-TNC Message Length field MUST contain the length of the entire
PB-TNC message, including the fixed-length fields at the start of the
PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message
Type, and PB-TNC Message Length), the fixed-length fields listed
below (Reserved, Remediation Parameters Vendor ID, and Remediation
Parameters Type), and the Remediation Parameters. Since the
Remediation Parameters field is variable length, the value in the PB-
TNC Message Length field will vary also. However, it MUST always be
at least 20 to cover the fixed-length fields listed in the preceding
sentences. Any Posture Broker Client or Posture Broker Server that
receives a PB-Remediation-Parameters message with a PB-TNC Message
Length field that contains an invalid value (e.g. less than 20)
SHOULD send an Invalid Parameter error code in response.
The following diagram illustrates the format and contents of the PB-
TNC Message Value field for this message type. The text after this
diagram describes the fields shown here.
0 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)
These 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.
Sahita et al. Expires August 18, 2008 [Page 23]
Internet-Draft PB-TNC February 2008
Remediation Parameters Type (32 bits)
The Remediation Parameters Type field identifies the type of
remediation parameters contained in the Remediation Parameters
field. A Posture Broker Client or Posture Broker Server MUST
support having multiple Remediation Parameters messages contained
in a single PB-TNC batch that have the same Remediation Parameters
Type and/or Remediation Parameters Vendor ID.
IANA maintains a registry of IETF Standard PB-TNC Remediation
Parameters Types. Entries may only be added to this registry by
IETF Consensus. That is, they must be defined in an RFC approved
by the IESG. A list of IETF Standard PB-TNC Remediation
Parameters Types defined in this specification appears later in
this section.
New vendor-specific Remediation Parameters Types (those used with
a non-zero Remediation Parameters vendor ID) may be defined and
employed by vendors without IETF or IANA involvement. However,
Posture Broker Clients and Posture Broker Servers MUST NOT require
support for particular vendor-specific Remediation Parameters
Types and MUST interoperate with other parties despite any
differences in the set of vendor-specific Remediation Parameters
Types supported (although they MAY permit administrators to
configure them to require support for specific Remediation
Parameters Types).
Note that the Remediation Parameters Type is completely separate
from the PB-TNC Message Type and the PA Subtype fields. The same
value (e.g. 0) may have different meanings in each of these
fields.
Remediation Parameters (variable length)
The Remediation Parameters field contains the actual remediation
parameters carried in this PB-TNC message. The length of this
field can be determined by subtracting the length of the fixed-
length fields at the start of the PB-TNC message (the fields
Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message
Length) and the fixed-length fields at the start of the PB-
Remediation-Parameters message (Reserved, Remediation Parameters
Vendor ID, and Remediation Parameters Type) from the message
length contained in the PB-TNC Message Length field. The length
of these fixed-length fields is 20 octets. Therefore, any Posture
Broker Client that receives a PB-Remediation-Parameters message
with a PB-TNC Message Length field whose value is less than 20
SHOULD consider this a malformed message. The Posture Broker
Sahita et al. Expires August 18, 2008 [Page 24]
Internet-Draft PB-TNC February 2008
Client may send an Invalid Parameter error code in response, if
this is practical according to the PB-TNC state machine. In many
cases, it will not be practical since the PB-Remediation-
Parameters message often comes in a batch of type RESULT and
according to the PB-TNC state machine, a Posture Broker Client
cannot send a batch after this except a CRETRY batch, which would
restart the handshake. That is generally not desirable.
3.8.1. IETF Standard PB-TNC Remediation Parameters Types
This subsection defines several Remediation Parameters Types that
have been standardized by the IETF.
Remediation-URI
This Remediation Parameters Type is employed by creating a PB-
Remediation-Parameters message with a Remediation Parameters
Vendor ID equal to the value zero (0) and a Remediation Parameters
Type of 1. The Remediation Parameters field in the PB-
Remediation-Parameters message MUST contain a URI, as described in
RFC 3986 [2]. This URI contains instructions and resources for
remediation. The Posture Broker Client MAY load the URI and
display the resulting web page to the user. The Posture Broker
Client may also ignore the URI or take another action with it.
The Posture Broker Server and any other parties involved in
configuring this remediation URI should consider the likely
capabilities of the Posture Broker Client when creating the URI
and the content referenced by the URI. For example, they should
consider the Posture Broker Client's language preferences as
expressed in the PB-Language-Preference message.
Remediation-String
This Remediation Parameters Type is employed by creating a PB-
Remediation-Parameters message with a Remediation Parameters
Vendor ID equal to the value zero (0) and a Remediation Parameters
Type of 2. The Remediation Parameters field in the PB-
Remediation-Parameters message MUST contain a UTF-8 encoded
string. This string should contain human-readable instructions
for remediation. The Posture Broker Client MAY display the
instructions to the user. The Posture Broker Client may also
ignore the instructions or take another action with them. The
Posture Broker Server and any other parties involved in
configuring these instructions should consider the likely
capabilities of the Posture Broker Client when creating the
instructions. For example, they should consider the Posture
Sahita et al. Expires August 18, 2008 [Page 25]
Internet-Draft PB-TNC February 2008
Broker Client's language preferences as expressed in the PB-
Language-Preference message.
3.9. PB-Error
The PB-TNC message type named PB-Error (value 5) is used by the
Posture Broker Client or Posture Broker Server to indicate that an
error has occurred. The Posture Broker Client or Posture Broker
Server MAY include one or more messages of this type in any batch of
any type. Other messages may also be included in the same batch.
The party that receives a PB-Error message MAY log it or take other
action as deemed appropriate. If the FATAL flag is set (value 1),
the recipient MUST close the PB-TNC session after processing the
batch without sending any messages in response. Every Posture Broker
Client and Posture Broker Server MUST implement this message type.
The NOSKIP flag in the PB-TNC Message Header MUST be set for this
message type. The PB-TNC Vendor ID field MUST contain the value zero
(0) and the PB-TNC Message Type field MUST contain 5. If a non-zero
value is contained in the PB-TNC Vendor ID field, message type 5 has
a completely different meaning not defined in this specification.
The PB-TNC Message Length field MUST contain the length of the entire
PB-TNC message, including the fixed-length fields at the start of the
PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message
Type, and PB-TNC Message Length), the fixed-length fields listed
below (Flags, Error Code Vendor ID, Error Code, and Reserved), and
the Error Parameters. Since the Error Parameters field is variable
length, the value in the PB-TNC Message Length field will vary also.
However, it MUST always be at least 20 to cover the fixed-length
fields listed in the preceding sentences. Any Posture Broker Client
or Posture Broker Server that receives a PB-Remediation-Parameters
message with a PB-TNC Message Length field that contains an invalid
value (e.g. less than 20) SHOULD send an Invalid Parameter error code
in response.
The following diagram illustrates the format and contents of the PB-
TNC Message Value field for this message type. The text after this
diagram describes the fields shown here.
Sahita et al. Expires August 18, 2008 [Page 26]
Internet-Draft PB-TNC February 2008
0 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 | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
This field defines flags relating to the error.
Bit 0 of this flags field (the most significant bit) is known as
the FATAL flag. If the FATAL bit is cleared (value 0), the
Posture Broker Client or Posture Broker Server that receives this
PB-TNC message SHOULD process this error and then continue with
the exchange. If the FATAL flag is set (value 1), the Posture
Broker Client or Posture Broker Server that receives this PB-TNC
message MUST terminate the exchange after processing the error.
The FATAL bit allows a Posture Broker Client or Posture Broker
Server to signal a fatal error (like an invalid batch type) and/or
a non-fatal error (like an invalid language tag for a preferred
language).
The other bits in this Flags field are reserved. For this version
of PB-TNC, they MUST be set to 0 on transmission and ignored on
reception.
Error Code Vendor ID (24 bits)
The Error Code 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 Error Code Vendor ID qualifies the Error Code
field so that each vendor has 2^16 separate Error Codes available
for its use. Error codes standardized by the IETF are always used
with the value zero (0) in this field. For detailed descriptions
of those messages, see the next few subsections.
Error Code (16 bits)
The Error Code field identifies the type of error being signaled
with this message. The format of the Error Parameters field
depends on the value of the Error Code Vendor ID and the Error
Sahita et al. Expires August 18, 2008 [Page 27]
Internet-Draft PB-TNC February 2008
Code. However, any recipient that does not understand a
particular error code can process the error fairly well by using
the FATAL flag to determine whether the error is fatal and the PB-
TNC Message Length to skip over the Error Parameters field (or log
it).
IANA maintains a registry of IETF Standard PB-TNC Error Codes.
Entries may only be added to this registry by IETF Consensus.
That is, they must be defined in an RFC approved by the IESG. A
list of IETF Standard PB-TNC Wrror Codes defined in this
specification appears later in section 3.9.1.
New vendor-specific error codes (those used with a non-zero error
code vendor ID) may be defined and employed by vendors without
IETF or IANA involvement. Posture Broker Clients and Posture
Broker Servers that receive an unknown error code MUST process
this error code gracefully by ignoring or logging it if it is not
marked as fatal and terminating the exchange if it is marked as
fatal.
Reserved (16 bits)
The Reserved bits MUST be set to 0 on transmission and ignored on
reception.
3.9.1. IETF Standard PB-TNC Error Codes
The following error codes are IETF Standard PB-TNC Error Codes, hence
the Error Code Vendor ID MUST be the value zero (0). The following
table defines the 16 bit Error Code. Vendor-specific error codes may
be defined by setting the Error Code Vendor ID to the defining
vendor's SMI PEN and setting the Error Code field to whatever error
code(s) that vendor has defined. The format, length, and meaning of
the Error Parameters field varies, based on the Error Code Vendor ID
and Error Code. Subsequent sections of this document define the
format, length, and meaning of the Error Parameters for the IETF
Standard PB-TNC Error Codes defined in this section.
Sahita et al. Expires August 18, 2008 [Page 28]
Internet-Draft PB-TNC February 2008
Error Code Definition
---------- ----------
0 Unexpected Batch Type. Error Parameters has offset of
offending PB-Batch-Type message.
1 Invalid Parameter. Error Parameters has offset where
invalid value was found.
2 Local Error. Error Parameters are empty.
3 Unsupported Mandatory Message. Error Parameters has
offset of offending PB-TNC Message
3.9.2. Error Parameters Structures for IETF Standard PB-TNC Error Codes
This section defines the format, length, and meaning of the Error
Parameters field for the IETF Standard PB-TNC Error Codes defined in
this specification.
The Error Parameters field has the following structure for the IETF
Standard PB-TNC Error Code 0. The Offset field is the offset in
octets from the start of the PB-TNC batch to the PB-Batch-Type
message whose type was not recognized. The FATAL flag MUST be set
for this error code.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Parameters field has the following structure for the IETF
Standard PB-TNC Error Code 1. The Offset field is the offset in
octets from the start of the PB-TNC batch to the invalid value. The
FATAL flag may either be set or cleared for this error code.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Parameters field is zero length for the IETF Standard PB-
TNC Error Code 2. The FATAL flag MUST be set for this error code.
The Error Parameters field has the following structure for the IETF
Standard PB-TNC Error Code 3. The Offset field is the offset in
octets from the start of the PB-TNC batch to the PB-TNC message whose
message type was not recognized (and where the NOSKIP flag was set)
The FATAL flag MUST be set for this error code.
Sahita et al. Expires August 18, 2008 [Page 29]
Internet-Draft PB-TNC February 2008
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.10. PB-Language-Preference
The PB-TNC message type named PB-Language-Parameters (value 6) is
used by the Posture Broker Client to indicate which language or
languages it would prefer for any human-readable strings that might
be sent to it. This allows the Posture Broker Server and Posture
Validators to adapt any messages they may send to the Posture Broker
Client's preferences (probably determined by the language preferences
of the endpoint's users).
The Posture Broker Server may also send this message type to the
Posture Broker Client to indicate the Posture Broker Server's
language preferences but this is not very useful since the Posture
Broker Client rarely sends human-readable strings to the Posture
Broker Server and, if it does, rarely can adapt those strings to the
preferences of the Posture Broker Server.
No Posture Broker Client or Posture Broker Server is required to send
or implement this message type. However, a Posture Broker Server
SHOULD attempt to adapt to user language preferences by implementing
this message type, passing the language preference information to
Posture Validators, and allowing administrators to configure human-
readable languages in whatever languages are preferred by their
users.
A Posture Broker Client or Posture Broker Server may include a
message of this type in any batch of any type. However, it is
suggested that this message be included in the first batch sent by
the Posture Broker Client or Posture Broker Server in a PB-TNC
session so that the recipient can start adapting its human-readable
messages as soon as possible. If one PB-Language-Parameters message
is received and then another one is received in a later batch for the
same PB-TNC session, the value included in the later message should
be considered to replace the value in the earlier message.
A Posture Broker Client or Posture Broker Server MUST NOT include
more than one message of this type in a single batch. If a Posture
Broker Client or Posture Broker Server receives more than one message
of this type in a single batch, it should ignore all but the last
one.
Sahita et al. Expires August 18, 2008 [Page 30]
Internet-Draft PB-TNC February 2008
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this
message type. The PB-TNC Vendor ID field MUST contain the value zero
(0) and the PB-TNC Message Type field MUST contain 6. If a non-zero
value is contained in the PB-TNC Vendor ID field, message type 6 has
a completely different meaning not defined in this specification.
The PB-TNC Message Length field MUST contain the length of the entire
PB-TNC message, including the fixed-length fields at the start of the
PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message
Type, and PB-TNC Message Length) and the Language Preference field.
Since the Language Preference field is variable length, the value in
the PB-TNC Message Length field will vary also. However, it MUST
always be at least 12 to cover the fixed-length fields listed in the
preceding sentences.
The following diagram illustrates the format and contents of the PB-
TNC Message Value field for this message type. The text after this
diagram describes the fields shown here.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Preference (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Language Preference (variable length)
The Language Preference field contains an Accept-Language header,
as described in RFC 3282 [4] (US-ASCII only, no control characters
allowed, no NUL termination). Any Posture Broker Client or
Posture Broker Server that sends a PB-Language-Preference message
MUST ensure that the Language Preference field conforms to this
format.
A zero length Language Preference field indicates that no language
preference information is available. Generally, there's no need
to send a PB-Language-Preference message with a zero length
Language Preference field since this is equivalent to sending no
PB-Language-Preference message at all but it may be useful to send
a zero length Language Preference field if a PB-Language-
Preference message with a non-zero length Language Preference
field was sent in an earlier batch but these preferences no longer
apply.
Sahita et al. Expires August 18, 2008 [Page 31]
Internet-Draft PB-TNC February 2008
3.11. PB-Reason-String
The PB-TNC message type named PB-Reason-String (value 7) is used by
the Posture Broker Server to provide a human-readable explanation for
an access recommendation conveyed in a PB-Access-Recommendation
message. Therefore, a PB-Reason-String message SHOULD only be
included in the same batch as a PB-Access-Recommendation message.
The Posture Broker Client MUST NOT ever send a PB-Reason-String
message.
The Posture Broker Client is not required to implement this message
type and the Posture Broker Server is not required to send it.
However, there is some benefit to doing so since users are often
curious about why network access was denied (if that was the access
recommendation). The manner in which a Posture Broker Client uses
this field is up to the implementer and not specified here. The
Posture Broker Client MAY display the message to the user, log it,
ignore it, or take any other action that is not inconsistent with the
requirements of this specification. Since the strings contained in
this message are human-readable, the Posture Broker Server SHOULD
adapt them to the Posture Broker Client's language preferences as
expressed in any PB-Language-Preference message sent by the Posture
Broker Client in this PB-TNC session.
A Posture Broker Server MAY include more than one message of this
type in any batch of any type. However, it is suggested that this
message be included in the same batch as a PB-Access-Recommendation
message. If more than one PB-Reason-String message is included in a
single batch, the Posture Broker Client SHOULD consider the strings
included in these messages to be equivalent in meaning. This allows
the Posture Broker Server to return multiple equivalent reason
strings in different languages, which may help if the Posture Broker
Server is not able to accommodate the Posture Broker Client's
language preferences.
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this
message type. The PB-TNC Vendor ID field MUST contain the value zero
(0) and the PB-TNC Message Type field MUST contain 7. If a non-zero
value is contained in the PB-TNC Vendor ID field, message type 7 has
a completely different meaning not defined in this specification.
The PB-TNC Message Length field MUST contain the length of the entire
PB-TNC message, including the fixed-length fields at the start of the
PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message
Type, and PB-TNC Message Length), the fixed-length fields listed
below (Reason String Length and Reason String Language Code Length),
and the Reason String and Reason String Language Code fields. Since
Sahita et al. Expires August 18, 2008 [Page 32]
Internet-Draft PB-TNC February 2008
the Reason String and Reason String Language Code fields are variable
length, the value in the PB-TNC Message Length field will vary also.
However, it MUST always be at least 20 to cover the fixed-length
fields listed in the preceding sentences. In fact, the PB-TNC
Message Length field MUST be exactly the sum of 20 (for the fixed-
length fields) and the values of the Reason String Length and Reason
String Language Code Length fields. If this is not the case, the
recipient SHOULD send an Invalid Parameter error code in response, if
this is practical according to the PB-TNC state machine. In many
cases, it will not be practical since the PB-Reason-String message
often comes in a batch of type RESULT and according to the PB-TNC
state machine, a Posture Broker Client cannot send a batch after this
except a CRETRY batch, which would restart the handshake. That is
generally not desirable.
The following diagram illustrates the format and contents of the PB-
TNC Message Value field for this message type. The text after this
diagram describes the fields shown here.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String Language Code Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String Language Code (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason String Length (32 bits)
The Reason String Length field contains the length of the Reason
String field in octets.
Reason String (variable length)
The Reason String field contains a UTF-8 encoded string that
provides a human-readable reason for the Posture Broker Server's
access recommendation. NUL termination MUST NOT be included. If
a Posture Broker Client receives a Reason String that does contain
a NUL termination, it SHOULD send an Invalid Parameter error code
in the next batch that it sends. A zero length string SHOULD NOT
be sent since this is the same as sending no reason string at all,
leaving the reason unspecified.
Sahita et al. Expires August 18, 2008 [Page 33]
Internet-Draft PB-TNC February 2008
Reason String Language Code Length (32 bits)
The Reason String Language Code Length field contains the length
of the Reason String Language Code field in octets.
Reason String Language Code (variable length)
The Reason String Language Code field contains a US-ASCII string
containing a well-formed RFC 4646 [3] language tag that indicates
the language(s) used in the Reason String in this message. NUL
termination MUST NOT be included in this field. A zero length
string MAY be sent for this field (essentially omitting this
field) to indicate that the language code for the reason string is
not known.
4. Evaluation Against NEA Requirements
This section evaluates the PB-TNC protocol against the requirements
defined in the NEA Requirements document. Each subsection considers
a separate requirement from the NEA Requirements document. Only
common requirements (C-1 through C-10) and PB requirements (PB-1
through PB-6) are considered, since these are the only ones that
apply to PB.
4.1. Evaluation Against Requirement C-1
Requirement C-1 says:
C-1 NEA protocols MUST support multiple round trips between the NEA
Client and NEA Server in a single assessment.
PB-TNC meets this requirement. It allows an unlimited number of
round trips between the NEA Client and NEA Server.
4.2. Evaluation Against Requirement C-2
Requirement C-2 says:
C-2 NEA protocols SHOULD provide a way for both the NEA Client and
the NEA Server to initiate a posture assessment or reassessment
as needed.
PB-TNC meets this requirement. Either the NEA Client or the NEA
Server can initiate a posture assessment or reassessment.
There is one limitation on this support. If a NEA Server wishes to
initiate a reassessment after it has sent a RESULT batch, it must
Sahita et al. Expires August 18, 2008 [Page 34]
Internet-Draft PB-TNC February 2008
close the underlying transport session and initiate a new assessment.
For half duplex transports, this is unavoidable unless a constant
exchange of messages is maintained, which would be very wasteful.
For full duplex transports, it would be possible to allow the Posture
Broker Server to send an SRETRY batch even in the Decided state. If
the NEA working group reaches consensus that this change should be
made, it will be.
4.3. Evaluation Against Requirement C-3
Requirement C-3 says:
C-3 NEA protocols including security capabilities MUST be capable
of protecting against active and passive attacks by
intermediaries and endpoints including prevention from replay
based attacks.
PB-TNC does not include any security capabilities. It depends on PT
to supply a secure transport. This addresses all the necessary
threats without adding an extra layer of security. Since this
requirement only applies to NEA protocols that include security
capabilities, PB-TNC meets this requirement.
4.4. Evaluation Against Requirement C-4
Requirement C-4 says:
C-4 The PA and PB protocols MUST be capable of operating over any
PT protocol. For example, the PB protocol must provide a
transport independent interface allowing the PA protocol to
operate without change across a variety of network protocol
environments (e.g. EAP/802.1X, PANA, TLS and IKE/IPsec).
PB-TNC meets this requirement. PB-TNC can operate over any PT
protocol that meets the requirements for PT stated in the NEA
Requirements document. Also, PB-TNC insulates the PA protocol from
any specifics of the PT protocol. With PB-TNC, all PT protocols are
equivalent from the perspective of the PA protocol.
4.5. Evaluation Against Requirement C-5
Requirement C-5 says:
C-5 The selection process for NEA protocols MUST evaluate and
prefer the reuse of existing open standards that meet the
requirements before defining new ones. The goal of NEA is not
Sahita et al. Expires August 18, 2008 [Page 35]
Internet-Draft PB-TNC February 2008
to create additional alternative protocols where acceptable
solutions already exist.
Based on this requirement, PB-TNC should receive a strong preference.
PB-TNC is equivalent with IF-TNCCS 2.0, an open TCG specification.
IF-TNCCS 2.0 is an extension of the existing IF-TNCCS 1.X protocols,
which have been implemented by dozens of vendors and open source
projects.
4.6. Evaluation Against Requirement C-6
Requirement C-6 says:
C-6 NEA protocols MUST be highly scalable; the protocols MUST
support many Posture Collectors on a large number of NEA
Clients to be assessed by numerous Posture Validators residing
on multiple NEA Servers.
PB-TNC meets this requirement. PB-TNC supports up to 2^16-1 Posture
Collectors and an equal number of Posture Validators in a given PB-
TNC session. It also supports an unlimited number of NEA Clients and
NEA Servers.
The scalability of PB-TNC extends into other areas as well. For
example, PB-TNC supports an unlimited number of batches and each
batch can contain up to 2^32-1 octets and about 2^24 PA messages.
Each PA message can contain up to 2^32-1 octets. Of course, sending
this much data in a NEA assessment is not generally advisable but the
point is that PB-TNC is highly scalable.
4.7. Evaluation Against Requirement C-7
Requirement C-7 says:
C-7 The protocols MUST support efficient transport of a large
number of attribute messages between the NEA Client and the NEA
Server.
PB-TNC meets this requirement. Each PB-TNC batch can contain about
2^24 PA messages. Since PB-TNC supports an unlimited number of
batches in a session, this number is actually unlimited (except
perhaps by PT protocols, user patience, or other external factors).
As for efficiency, PB-TNC adds only 24 octets of overhead per PA
message. PA-TNC can include many attributes in a single PA message
so this overhead is diluted further.
Sahita et al. Expires August 18, 2008 [Page 36]
Internet-Draft PB-TNC February 2008
4.8. Evaluation Against Requirement C-8
Requirement C-8 says:
C-8 NEA protocols MUST operate efficiently over low bandwidth or
high latency links.
PB-TNC meets this requirement. A minimal PB-TNC exchange can be as
small as 72 octets and one round trip. Even if privacy policies or
other factors require multiple round trips, PB-TNC generally imposes
an overhead of only 8 octets per batch and 24 octets per PA message.
4.9. Evaluation Against Requirement C-9
Requirement C-9 says:
C-9 For any strings intended for display to a user, the protocols
MUST support adapting these strings to the user's language
preferences.
PB-TNC meets this requirement. It defines a standard way for the NEA
Client and NEA Server to send their language preferences to each
other, leveraging the widely implemented Accept-Language format
defined in RFC 3282.
4.10. Evaluation Against Requirement C-10
Requirement C-10 says:
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.
PB-TNC meets this requirement. All strings in the PB-TNC protocol
are encoded in UTF-8 format. This allows the protocol to support a
wide range of languages efficiently.
4.11. Evaluation Against Requirement PB-1
Requirement PB-1 says:
PB-1 The PB protocol MUST be capable of carrying attributes from the
Posture Broker Server to the Posture Broker Client. This
enables the Posture Broker Client to learn the posture
assessment decision and if appropriate to aid in remediation
and notification of the endpoint owner.
Sahita et al. Expires August 18, 2008 [Page 37]
Internet-Draft PB-TNC February 2008
PB-TNC meets this requirement. It can carry attributes from the
Posture Broker Client to the Posture Broker Server and back in an
unlimited number of round trips.
4.12. Evaluation Against Requirement PB-2
Requirement PB-2 says:
PB-2 The PB protocol MUST NOT interpret the contents of PA messages
being carried, i.e., the data it is carrying must be opaque to
it.
PB-TNC meets this requirement. It does not parse or interpret PA
messages in any way.
4.13. Evaluation Against Requirement PB-3
Requirement PB-3 says:
PB-3 The PB protocol MUST carry unique identifiers that are used by
the Posture Brokers to route (deliver) PA messages between
Posture Collectors and Posture Validators. Such message
routing should facilitate dynamic registration or
deregistration of Posture Collectors and Validators. For
example, a dynamically registered anti-virus Posture Validator
should be able to subscribe to receive messages from its
respective anti-virus Posture Collector on NEA Clients.
PB-TNC meets this requirement. PB-TNC tags each PA message with a PA
subtype that the Posture Brokers can use to deliver the PA messages
to the proper Posture Collectors and Posture Validators. By tagging
messages according to their content, PB-TNC allows Posture Collectors
and Posture Validators to be dynamically registered and deregistered,
ensuring that each one receives the proper data. PB-TNC also
supports exclusive delivery, which allows messages to be targeted at
a particular Posture Collector or Posture Validator.
4.14. Evaluation Against Requirement PB-4
Requirement PB-4 says:
PB-4 The PB protocol MUST be capable of supporting a half-duplex PT
protocol. However this does not preclude PB from operating
full-duplex when running over a full-duplex PT.
PB-TNC meets this requirement. In order to insulate PA from any
differences between half-duplex and full-duplex PT protocols, PB-TNC
Sahita et al. Expires August 18, 2008 [Page 38]
Internet-Draft PB-TNC February 2008
always operates in a half-duplex mode, regardless of the capabilities
of the PT protocol. While this could in theory slow assessments that
require many round trips or bidirectional multimedia exchanges, this
is not a problem in practice because endpoint assessments do not
typically involve multimedia or a large number of round trips.
4.15. Evaluation Against Requirement PB-5
Requirement PB-5 says:
PB-5 The PB protocol MAY support authentication, integrity and
confidentiality protection for the attribute messages it
carries between a Posture Broker Client and Posture Broker
Server. This provides security protection for a message dialog
of the groupings of attribute messages exchanged between the
Posture Broker Client and Posture Broker Server. Such
protection is orthogonal to PA protections (which are end to
end) and allows for simpler Posture Collector and Validators to
be implemented, and for consolidation of cryptographic
operations possibly improving scalability and manageability.
PB-TNC does not address this optional requirement. It leaves
security to PT (which is required to address it) and PA (which SHOULD
do so). There seems to be minimal benefit in adding a third layer of
security to the NEA protocol stack. However, if the NEA working
group determines that PB should include support for authentication,
integrity protection, and confidentiality protection, then this could
be added to PB in a similar manner to the way that the PA-TNC
security is done.
4.16. Evaluation Against Requirement PB-6
Requirement PB-6 says:
PB-6 The PB protocol MUST support grouping of attribute messages to
optimize transport of messages and minimize round trips.
PB-TNC meets this requirement. Multiple attribute messages can be
conveyed in a single PA message. In fact, that's how PA-TNC works.
5. Security Considerations
PT is required and assumed to provide reliable and secure transport
for the PB-TNC protocol (including authentication, confidentiality,
integrity protection, and replay protection). Still, it is useful to
describe the possible threats to PB-TNC and the countermeasures that
are or can be employed. This section does that.
Sahita et al. Expires August 18, 2008 [Page 39]
Internet-Draft PB-TNC February 2008
5.1. Threat Model
There are several possible threats to the PB-TNC protocol.
Untrusted intermediaries on the network between the NEA Client and
the NEA Server may attempt to observe data sent between the Posture
Broker Client and the Posture Broker Server via PB-TNC, modify this
data in transit, reorder it, or replay it. They may also attempt to
mount a denial of service attack against either party or truncate the
exchange prematurely. If successful, these attacks may result in
improper assessment decisions relating to the NEA Client, failure to
reassess these decisions in light of changed circumstances, improper
remediation instructions sent to the NEA Client (which could lead to
the compromise of the NEA Client), unauthorized access to
confidential information about the NEA Client's health and/or
identity, improper reason strings or other messages that might be
displayed to the user, access to reusable credentials such as posture
assertions, denial of service on the NEA Client, and even complete
denial of access to the network (if a denial of service attack
against the NEA Server was successful and the network required
permission from the NEA Server to grant network access).
Trusted intermediaries between the Posture Broker Client and the
Posture Broker Server include the Posture Transport Client and the
Posture Transport Server. These parties are considered trusted
because they are responsible for properly implementing the security
protections provided by PT. If they fail to do so properly, these
security protections may be diminished or eliminated altogether. The
possible attacks are the same as those listed in the previous
paragraph. To give one fairly likely example, if a Posture Transport
Client fails to properly authenticate and authorize the Posture
Transport Server (whether through implementation error or through
user configuration to "trust anyone"), the improperly authorized
Posture Transport Server may mount any of the previously described
attacks against the NEA Client.
Compromise of any of the trusted parties (the Posture Broker Client,
the Posture Transport Client, the Posture Broker Server, or the
Posture Transport Server) may result in failures that are equivalent
to those listed in the first paragraph. These failures may be even
more dangerous since they will not be detectable by observing network
traffic or by examining and comparing audit logs. Failure to
properly secure communications between the Posture Broker Client and
the Posture Transport Client or between the Posture Broker Server and
the Posture Transport Server is usually indistinguishable from
compromise of those parties. Compromise of the operating system or
other critical software, firmware, or hardware components on the NEA
Sahita et al. Expires August 18, 2008 [Page 40]
Internet-Draft PB-TNC February 2008
Client or NEA Server will typically result in an equivalent result.
And an attacker's ability to gain privileged access to the NEA Client
or NEA Server (even for a brief time, long enough to disable or
misconfigure security settings) is generally equivalent as well. If
the NEA Client or NEA Server are dependent on other services for
their proper operation (including Posture Collectors, Posture
Validators, directories, and patch management services), compromise
of those services may result in compromise or failure of the
dependent parties. Of course, compromise or failure of NEA Server
components is most serious since this would probably affect a large
number of NEA Clients while the effects of NEA Client compromise
might well be limited to a single machine.
5.2. Countermeasures
The primary countermeasure against attacks by untrusted network
intermediaries is the security provided by the PT protocol. Any
candidate PT protocols should be carefully examined to ensure that
all the threats described above are adequately addressed.
As noted above, compromise or erroneous operation of any of the
trusted parties is a serious matter with substantial security
implications. This includes the Posture Broker Client, the Posture
Broker Server, the Posture Transport Client, and the Posture
Transport Server. These are all security-sensitive components so
they should be built and managed in accordance with best practices
for security devices. This is especially important for the NEA
Server and its components since a compromise of this device would
affect the security and availability of the entire network (similar
to compromise of a AAA server). Communications between the trusted
parties must also be secured. For example, if the Posture Broker
Server and the Posture Transport Server are separate components,
their communications must be secured.
Since the NEA Client may be a mobile device with little physical
security (such as a laptop computer or even a public telephone), it
should generally be assumed that some proportion of Access NEA
Clients will be compromised and therefore hostile. The NEA Server
should be designed to be robust against hostile NEA Clients. Once a
compromised NEA Client is detected, it can be treated in a manner
equivalent to an untrusted party and should pose no greater threat
than any other untrusted party.
Countermeasures against a compromised NEA Server (or a component
thereof such as a Posture Broker Server or a Posture Transport
Server) include prevention of compromise, detection of compromise,
and mitigation of the effects of compromise. For prevention, the NEA
Sahita et al. Expires August 18, 2008 [Page 41]
Internet-Draft PB-TNC February 2008
Server and its components and dependencies should be implemented
using secure implementation techniques (e.g. secure coding and
minimization) and managed using secure practices (e.g. strong
authentication and separation of duty). For detection, the behavior
of the NEA Server should be monitored (e.g. via logging especially of
remediation instructions; intrusion detection systems; and probes
that impersonate a valid NEA Client and record NEA Server behavior)
and any anomalies analyzed. For mitigation, NEA Clients should not
blindly follow remediation instructions received from a trusted NEA
Server. At least for patches and other dangerous actions, they
should validate these actions (e.g. via user confirmation) before
proceeding. It should not be possible to configure a NEA Client to
trust all NEA Servers without proper authentication and
authorization.
6. IANA Considerations
Four new IANA registries are defined by this specification: IETF
Standard PB-TNC Message Types, IETF Standard PA Subtypes, IETF
Standard PB-TNC Remediation Parameters Types, and IETF Standard PB-
TNC Error Codes. This section explains how these registries work.
First, it is important to note that in all four of these cases the
IETF standard values listed in the IANA registry are only a small
part of the possible values. Whenever a PB-TNC Message 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 PB-TNC Message Type is an IETF standard value listed
in the IANA registry for PB-TNC Message Types and its meaning is
defined in the RFC listed for that PB-TNC Message Type in that
registry. If the vendor ID is not zero, the meaning of the PB-TNC
Message Type has a vendor-specific meaning defined by the vendor
identified by the vendor ID (as listed in the IANA registry for SMI
PENs).
This delegation of namespace is analogous to the technique used for
OIDs. It can result in interoperability problems if vendors require
support for particular vendor-specific values. However, such
behavior is explicitly prohibited by this specification, which
dictates that "Posture Broker Clients and Posture Broker Servers MUST
NOT require support for particular vendor-specific PB-TNC message
types and MUST interoperate with other parties despite any
differences in the set of vendor-specific PB-TNC message types
supported (although they MAY permit administrators to configure them
to require support for specific PB-TNC message types)." Similar
requirements are included for PA Subtypes, Remediation Parameters
Types, and PB-TNC Error Codes.
Sahita et al. Expires August 18, 2008 [Page 42]
Internet-Draft PB-TNC February 2008
The following subsections provide guidance to the IANA in creating
and managing the four new IANA registries defined by this
specification.
6.1. Registry for IETF Standard PB-TNC Message Types
The name for this registry is "IETF Standard PB-TNC Message Types".
Each entry in this registry should include a human-readable name, a
decimal integer value between 0 and 2^32-2, and a reference to an RFC
where the contents of this message type are defined. This RFC must
define the meaning of this PB-TNC message type and the format and
semantics of the PB-TNC Message Value field for PB-TNC messages that
include the designated numeric value in the PB-TNC Message Type field
and the value 0 in the PB-TNC Vendor ID field.
Entries to this registry may only be added by IETF Consensus, as
defined in RFC 2434 [5]. That is, they can only be added in an RFC
approved by the IESG.
The following entries for this registry are defined in this document.
Once this document becomes an RFC, they should become the initial
entries in the registry for IETF Standard PB-TNC Message Types.
Integer Value Name Defining RFC
------------- ---- ------------
0 PB-Experimental RFC # Assigned to this I-D
1 PB-Batch-Type RFC # Assigned to this I-D
2 PB-PA RFC # Assigned to this I-D
3 PB-Access-Recommendation RFC # Assigned to this I-D
4 PB-Remediation-Parameters RFC # Assigned to this I-D
5 PB-Error RFC # Assigned to this I-D
6 PB-Language-Preference RFC # Assigned to this I-D
7 PB-Reason-String RFC # Assigned to this I-D
6.2. Registry for IETF Standard PA Subtypes
The name for this registry is "IETF Standard PA Subtypes". Each
entry in this registry should include a human-readable name, a
decimal integer value between 0 and 2^32-2, and a reference to an RFC
where the contents of this PA subtype are defined. This RFC must
define the meaning of this PA subtype and the format and semantics of
the PA Message Body field for PB-TNC messages that have a PB-TNC
Vendor ID of 0, a PB-TNC Message Type of PB-PA, the designated
numeric value in the PA Subtype field, and the value 0 in the PA
Message Vendor ID field.
Sahita et al. Expires August 18, 2008 [Page 43]
Internet-Draft PB-TNC February 2008
Entries to this registry may only be added by IETF Consensus, as
defined in RFC 2434. That is, they can only be added in an RFC
approved by the IESG.
This document does not define any initial entries for this registry.
Therefore, this registry should initially be empty. Subsequent RFCs
(such as PA-TNC) will define entries in this registry.
6.3. Registry for IETF Standard PB-TNC Remediation Parameters Types
The name for this registry is "IETF Standard PB-TNC Remediation
Parameters Types". Each entry in this registry should include a
human-readable name, a decimal integer value between 0 and 2^32-1,
and a reference to an RFC where the contents of this remediation
parameters type are defined. This RFC must define the meaning of
this remediation parameters type value and the format and semantics
of the Remediation Parameters field for PB-TNC messages that have a
PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Remediation-
Parameters, the designated numeric value in the Remediation
Parameters Type field, and the value 0 in the Remediation Parameters
Vendor ID field.
Entries to this registry may only be added by IETF Consensus, as
defined in RFC 2434. That is, they can only be added in an RFC
approved by the IESG.
The following entries for this registry are defined in this document.
Once this document becomes an RFC, they should become the initial
entries in the registry for IETF Standard PB-TNC Remediation
Parameters Types.
Integer Value Name Defining RFC
------------- ---- ------------
1 Remediation-URI RFC # Assigned to this I-D
2 Remediation-String RFC # Assigned to this I-D
6.4. Registry for IETF Standard PB-TNC Error Codes
The name for this registry is "IETF Standard PB-TNC Error Codes".
Each entry in this registry should include a human-readable name, a
decimal integer value between 0 and 2^16-1, and a reference to an RFC
where this error code is defined. This RFC must define the meaning
of this error code and the format and semantics of the Error
Parameters field for PB-TNC messages that have a PB-TNC Vendor ID of
0, a PB-TNC Message Type of PB-Error, the designated numeric value in
the Error Code field, and the value 0 in the Error Code Vendor ID
field.
Sahita et al. Expires August 18, 2008 [Page 44]
Internet-Draft PB-TNC February 2008
Entries to this registry may only be added by IETF Consensus, as
defined in RFC 2434. That is, they can only be added in an RFC
approved by the IESG.
The following entries for this registry are defined in this document.
Once this document becomes an RFC, they should become the initial
entries in the registry for IETF Standard PB-TNC Error Codes.
Integer Value Name Defining RFC
------------- ---- ------------
0 Unexpected Batch Type RFC # Assigned to this I-D
1 Invalid Parameter RFC # Assigned to this I-D
2 Local Error RFC # Assigned to this I-D
3 Unsupported Mandatory Message RFC # Assigned to this I-D
7. Acknowledgments
The authors of this draft would like to acknowledge the following
people who have contributed to or provided substantial input on the
preparation of this document or predecessors to it: Bernard Aboba,
Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris
Balacheff, Gene Chang, Roger Chickering, Scott Cochrane, Pasi Eronen,
Aman Garg, Sandilya Garimella, Lauren Giroux, Mudit Goel, Charles
Goldberg, Thomas Hardjono, Chris Hessing, Hidenobu Ito, John Jerrim,
Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Tom Kelnar, Bryan
Kingsford, PJ Kirner, Houcheng Lee, Sung Lee, Lisa Lorenzin,
Mahalingam Mani, Paul Mayfield, Michael McDaniels, Bipin Mistry, Rod
Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn,
Alex Romanyuk, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean
Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad,
Joseph Tardo, Lee Terrell, Chris Trytten, Brad Upson, Ram Vadali,
Guha Prasad Venataraman, John Vollbrecht, Jun Wang, Han Yin.
This document was prepared using 2-Word-v2.0.template.dot.
Sahita et al. Expires August 18, 2008 [Page 45]
Internet-Draft PB-TNC February 2008
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, January
2005.
[3] Phillips, A. and M. Davis, "Tags for the Identification of
Languages", RFC 4646, September 2006.
[4] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[5] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
8.2. Informative References
[6] Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV
Binding", Trusted Computing Group, February 2008.
[7] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, " Network Endpoint Assessment (NEA): Overview and
Requirements", draft-ietf-nea-requirements-05.txt, Work In
Progress, November 2007.
[8] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[9] Sangster, P., "PA-TNC: A Posture Attribute Protocol (PA)
Compatible with TNC", draft-sangster-nea-pa-tnc-00.txt,
February 2008.
Author's Addresses
Ravi Sahita
Intel Corporation
2200 Mission College Blvd.
Santa Clara, CA 95054 USA
email: ravi.sahita at intel.com
Sahita et al. Expires August 18, 2008 [Page 46]
Internet-Draft PB-TNC February 2008
Steve Hanna
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
email: shanna at juniper.net
Ryan Hurst
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA
email: Ryan.Hurst at microsoft.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr at ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Sahita et al. Expires August 18, 2008 [Page 47]
Internet-Draft PB-TNC February 2008
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sahita et al. Expires August 18, 2008 [Page 48]
Network Working Group P. Sangster
Internet Draft Symantec Corporation
Intended status: Proposed Standard
Expires: August 2008
February 18, 2008
PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC
draft-sangster-nea-pa-tnc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document specifies PA-TNC, a Posture Attribute Protocol
identical to the Trusted Computing Group's IF-M 1.0 protocol.
The document then evaluates PA-TNC against the requirements
defined in the NEA Requirements specification.
Sangster Expires August 7, 2008 [Page 1]
Internet-Draft PA-TNC February 2008
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [1].
Table of Contents
1. Introduction...............................................3
1.1. Background on Trusted Computing Group.................3
1.2. Background on Trusted Network Connect.................4
1.3. Submission of This Document...........................4
1.4. Prerequisites.........................................4
1.5. Message Diagram Conventions...........................5
2. PA-TNC Message Protocol....................................5
2.1. PA-TNC Messaging Model................................5
2.2. PA-TNC Relationship to PB-TNC.........................6
2.3. PA-TNC Messages in PB-TNC.............................9
2.4. IETF Standard PA Subtypes.............................9
2.5. PA-TNC Message Header Format.........................10
3. PA-TNC Attributes.........................................12
3.1. PA-TNC Attribute Header..............................12
3.2. IETF Standard PA-TNC Attribute Types.................16
3.2.1. Attribute Request...............................18
3.2.2. Product Information.............................20
3.2.3. Numeric Version.................................22
3.2.4. String Version..................................24
3.2.5. Operational Status..............................27
3.2.6. Port Filter.....................................30
3.2.7. Installed Packages..............................32
3.2.8. PA-TNC Error....................................35
3.2.8.1. Definition of Invalid Parameter Error Code.38
3.2.8.2. Definition of Version Not Supported Error
Code.......................................39
3.2.8.3. Definition of Attribute Type Not Supported
Error Code.................................41
3.3. Vendor-Defined Attributes............................43
4. Evaluation Against NEA Requirements.......................43
4.1. Evaluation Against Requirement C-1...................44
4.2. Evaluation Against Requirement C-2...................44
4.3. Evaluation Against Requirement C-3...................44
4.4. Evaluation Against Requirement C-4...................44
4.5. Evaluation Against Requirement C-5...................45
4.6. Evaluation Against Requirement C-6...................45
4.7. Evaluation Against Requirement C-7...................46
4.8. Evaluation Against Requirement C-8...................46
4.9. Evaluation Against Requirement C-9...................46
Sangster Expires August 7, 2008 [Page 2]
Internet-Draft PA-TNC February 2008
4.10. Evaluation Against Requirement C-10.................47
4.11. Evaluation Against Requirement PA-1.................47
4.12. Evaluation Against Requirement PA-2.................48
4.13. Evaluation Against Requirement PA-3.................48
4.14. Evaluation Against Requirement PA-4.................48
4.15. Evaluation Against Requirement PA-5.................49
4.16. Evaluation Against Requirement PA-6.................49
5. Security Considerations...................................50
5.1. Trust Relationships..................................50
5.1.1. Posture Collector...............................50
5.1.2. Posture Validator...............................51
5.1.3. Posture Broker Client, Posture Broker Server,
and PB-TNC......................................51
5.2. Security Threats.....................................52
5.2.1. Attribute Theft.................................52
5.2.2. Message Fabrication.............................53
5.2.3. Attribute Modification..........................53
5.2.4. Attribute Replay................................53
5.2.5. Attribute Insertion.............................54
5.2.6. Denial of Service...............................54
6. Privacy Considerations....................................55
7. IANA Considerations.......................................56
7.1. New IETF Standard PA Subtypes........................56
7.2. Registry for IETF Standard PA-TNC Attribute Types....57
7.3. Registry for IETF Standard PA-TNC Error Codes........58
8. Acknowledgments...........................................59
9. References................................................59
9.1. Normative References.................................59
9.2. Informative References...............................59
Author's Address.............................................60
Intellectual Property Statement..............................60
Disclaimer of Validity.......................................61
1. Introduction
This document specifies PA-TNC, a Posture Attribute Protocol
(PA) identical to the Trusted Computing Group's IF-M 1.0
protocol [6]. The document then evaluates PA-TNC against the
requirements defined in the NEA Requirements specification [7].
1.1. Background on Trusted Computing Group
The Trusted Computing Group (TCG) is a consortium that develops
specifications for trusted (secure) computing. Since its
formation in 2003, TCG has published specifications for a
variety of technologies such as Trusted Platform Module (TPM),
Sangster Expires August 7, 2008 [Page 3]
Internet-Draft PA-TNC February 2008
TCG Software Stack (TSS), Mobile Trusted Module (MTM), and
Trusted Network Connect (TNC).
TCG members include more than 175 organizations that design,
build, sell, or use trusted computing technology. Membership is
open to any organization that signs the membership agreement and
pays the annual membership fee. Non-members are welcome to
implement the TCG specifications. Several open source
implementers have done so.
1.2. Background on Trusted Network Connect
Starting in 2004, the TCG has defined and published the Trusted
Network Connect (TNC) architecture and standards for network
access control. These standards enable multi-vendor
interoperability at all points in the architecture and have been
widely adopted and deployed.
1.3. Submission of This Document
The IETF has recently chartered the Network Endpoint Assessment
(NEA) working group to develop several standards in the same
area as TNC. In order to avoid the development of multiple
incompatible standards, the TCG is offering several of its TNC
standards to the IETF as candidates for standardization in the
IETF also. This document is equivalent to TCG's IF-M 1.0.
Consistent with IETF's requirements for standards track
documents, the TCG has authorized the editors of this document
to offer the specification to the IETF without restriction. As
with other Internet-Drafts, the IETF Trust owns the copyright to
this document. The IETF may modify this document, ignore it,
publish it as an RFC, or take any other action. If the IETF
decides to adopt a later version of this document as an RFC, the
TCG plans to publish a specification for an equivalent TNC
protocol to ensure compatibility.
1.4. Prerequisites
This document does not define an architecture or reference
model. Instead, it defines a protocol that works within the
reference model described in the NEA Requirements specification.
The reader is assumed to be thoroughly familiar with that
document. No familiarity with TCG specifications is assumed.
Sangster Expires August 7, 2008 [Page 4]
Internet-Draft PA-TNC February 2008
1.5. Message Diagram Conventions
This specification defines the syntax of PA-TNC messages using
diagrams. Each diagram depicts the format and size of each
field in bits. Implementations MUST send the bits in each
diagram as they are shown, traversing the diagram from top to
bottom and then from left to right within each line (which
represents a 32-bit quantity). Multi-byte fields representing
numeric values must be sent in network (big endian) byte order.
Descriptions of bit field (e.g. flag) values are described
referring to the position of the bit within the field. These
bit positions are numbered from the most significant bit through
the least significant bit so a one octet field with only bit 0
set has the value 0x80.
2. PA-TNC Message Protocol
This section discusses the use of the PA-TNC message and its
attributes, and specifies the syntax and semantics for the PA-
TNC message header. The details of each attribute included
within the PA-TNC payload are specified in section 3.2.
2.1. PA-TNC Messaging Model
PA-TNC messages are carried by the PB-TNC protocol [5], which
provides a multi-roundtrip reliable transport and end-to-end
message delivery to subscribed (interested) parties using a
variety of underlying network protocols. PA-TNC is unaware of
these underlying PT transport protocols being used below PB-TNC.
The interested parties consist of Posture Collectors on the NEA
Client and Posture Validators associated with the NEA Server
that have registered to receive messages about particular types
of components (e.g. anti-virus) during an assessment. The PA-
TNC messaging protocol operates synchronously within an
assessment session, with Posture Collectors and Posture
Validators taking turns sending one or more messages to each
other. Each PA-TNC message may contain one or more attributes
associated with the functional component defined in the PB
protocol. Posture Collectors may only send PA-TNC messages to
Posture Validators and vice versa. No Posture Collector to
Posture Collector or Posture Validator to Posture Validator
messaging is allowed to occur. Each Posture Collector or
Posture Validator may send several PA-TNC messages in succession
before indicating that it has completed its response to the
Posture Broker Client or Posture Broker Server respectively. As
necessary, the Posture Broker Client and Posture Broker Server
Sangster Expires August 7, 2008 [Page 5]
Internet-Draft PA-TNC February 2008
will batch these messages prior to sending them over the
network.
PB-TNC provides a publish/subscribe model of message exchange.
This means that, at any given point in time, zero or more
subscribers for a particular type of message may be present on a
Posture Broker Client or Posture Broker Server. This is
beneficial, since it allows one Posture Collector or Posture
Validator to combine multiple functions (like anti-virus and
personal firewall) by subscribing to both TNC standard component
types. It also allows multiple Posture Collectors or Posture
Validators to support the same components, such as two anti-
virus Posture Validators that are each used to manage their own
respective anti-virus client software. However, this
publish/subscribe model has some possible negative side effects.
When a Posture Collector or Posture Validator initially sends a
PA-TNC message, it does not know whether it will receive many,
one, or no PA-TNC messages from the other side. For many types
of assessments, this is acceptable, but in some cases a more
direct channel binding between a particular Posture Collector
and Posture Validator pair is necessary. For example, a Posture
Validator may wish to provide remediation instructions to a
particular Posture Collector that it knows is capable of
remediating a non-compliant component. This can be accomplished
using the PB-TNC capability to limit distribution of a message
to a single Posture Collector.
2.2. PA-TNC Relationship to PB-TNC
This section summarizes the major elements of a PA-TNC message
as they might appear inside of a PB-TNC message. The double
line (===) in the diagram below indicates the separation between
the PB-TNC and PA-TNC protocols. The PA-TNC portion of the
message is delivered to each Posture Collector or Posture
Validator registered to receive messages containing a particular
message type. Note that PB-TNC is capable of carrying multiple
PB-TNC and PA-TNC messages in a single PB-TNC batch. See the
PB-TNC specification [5] for more information on its
capabilities.
One important linkage between the PA-TNC and PB-TNC protocols is
the PA message type (PA Message Vendor ID and PA subtype) that
is used by the Posture Broker Client and Posture Broker Server
to route messages to interested Posture Collectors and Posture
Validators. The message type indicates the software component
(component type) that is associated with the attributes included
inside the PA-TNC message. Therefore, Posture Collectors and
Sangster Expires August 7, 2008 [Page 6]
Internet-Draft PA-TNC February 2008
Posture Validators written to support an assessment of a
particular component can register to receive messages about the
component and thus participate in its assessment. Each Posture
Collector and Posture Validator MUST only send PA-TNC messages
containing attributes that pertain to the software component
defined in the message type of the message. This assures that
only the appropriate Posture Collectors and Posture Validators
that support a particular type of component will receive
attributes related to that component. If a PA-TNC message
contained a mix of attributes about different components and a
message type of only one of those components, the message would
only be delivered to parties interested in the component type
included in the message type, so other interested recipients
wouldn't see those attributes.
The message type is comprised of 2 fields: a PA Message Vendor
ID and a PA Subtype. The PA Message Vendor ID identifies the
vendor or other organization that defined this message type. The
PA Subtype identifies the message type more particularly within
the set of message types defined by that vendor. This
specification defines several IETF Standard PA Subtypes to be
used with a PA Message Vendor ID of zero (0). Within this
specification, the PA Subtype field is used to indicate the type
of component (e.g. firewall) involved with the message's
attributes. Therefore for clarity the PA subtype will be
referred to as the "component type" in this specification.
Vendor-defined name spaces may use other semantics for the PA
Subtype field as this is outside the scope of this
specification.
Sangster Expires August 7, 2008 [Page 7]
Internet-Draft PA-TNC February 2008
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message of type PB-PA-Message |
| (includes PA Message Vendor ID, PA Subtype, and other fields |
| used by Posture Broker Client and Posture Broker Server for |
| routing) |
=================================================================
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g. Product Information) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g. Operational Status) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Overview of a PB-TNC batch that contains a PA-TNC
Message
For example, if a Posture Broker Client sent a PB-TNC batch that
contained a PA-TNC message with a message type indicating
firewall component, this message would be routed by the Posture
Broker Server to Posture Validators registered to assess
firewalls. Each registered Posture Validator would receive a
copy of the PA-TNC message including the PA-TNC header and set
of attributes. It is important that each of the attributes
included in the PA-TNC message be associated with the firewall
component because only the Posture Collector and Posture
Sangster Expires August 7, 2008 [Page 8]
Internet-Draft PA-TNC February 2008
Validator interested in firewalls will receive such messages.
For example, if the above message contained both firewall and
operating system attributes (inside a PA-TNC message with a
component type of firewall), then any Posture Collector and
Posture Validator registered to receive operating system
messages would not receive those attributes, as the messages
would only be delivered to those registered for firewall
messages.
2.3. PA-TNC Messages in PB-TNC
As depicted in section 2.2, a PA-TNC message consists of a PA-
TNC header followed by a sequence of one or more attributes. The
PA-TNC message header (described in section 2.5) and the header
for each of the PA-TNC attributes (specified in section 3.1)
have a fixed type-length-value (TLV) format. Each PA-TNC
message MAY contain a mixture of standards-based and vendor-
defined attributes identifiable using the type portion of the
attribute header. All Posture Collectors and Posture Validators
compliant with this specification MUST be capable of processing
multiple attributes in a received PA-TNC message. A Posture
Collector or Posture Validator that receives a PA-TNC message
can use the attribute header's length field to skip any
attributes that it does not understand, unless the attribute is
marked as mandatory to process.
2.4. IETF Standard PA Subtypes
This section defines several IETF Standard PA Subtypes. Each PA
subtype defined here identifies a specific component relevant to
the endpoint's posture. This allows a small set of generic PA-
TNC attributes (e.g. Product Information) to be used to describe
a large number of different components (e.g. OS, anti-virus
software, etc.). It also allows Posture Collectors and Posture
Validators to specialize in a particular component (e.g.
operating system) and only receive PA-TNC messages relevant to
that component.
Number Name Definition
------ ---- ----------
0 Testing Reserved for use in specification
examples, experimentation and
testing.
1 Operating System Operating system running on the
endpoint
Sangster Expires August 7, 2008 [Page 9]
Internet-Draft PA-TNC February 2008
2 Anti-Virus Host-based anti-virus software
3 Anti-Spyware Host-based anti-spyware software
4 Anti-Malware Host-based anti-malware (e.g. anti-
bot) software not included within
anti-virus or anti-spyware components
5 Firewall Host-based firewall
6 IDPS Host-based Intrusion Detection and/or
Prevention Software (IDPS)
7 VPN Host-based Virtual Private Networking
(VPN) software
These PA subtypes must be used in a PB-PA message with a PA
Message Vendor ID of zero (0) (as described in the PB-TNC
specification [5]). If these PA subtype values are used with a
different PA Message Vendor ID, they have a completely different
meaning that is not defined in this specification.
2.5. PA-TNC Message Header Format
This section describes the format and semantics of the PA-TNC
header. Every PA-TNC message MUST start with a PA-TNC header.
The PA-TNC header provides a common context applying to all of
the attributes contained within the PA-TNC payload. The payload
consists of a sequence of assessment attributes described in
section 3.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
Sangster Expires August 7, 2008 [Page 10]
Internet-Draft PA-TNC February 2008
This field indicates the version of the format for the PA-TNC
message. This version is intended to allow for evolution of
the PA-TNC message header and payload in a manner that can
easily be detected by message recipients.
PA-TNC message senders MUST set this field to 0x01 for all
PA-TNC messages that comply with formats and requirements
described in version 1.0 of this specification.
Implementations responding to a PA-TNC message containing a
supported version SHOULD use the same Version number to
minimize the risk of version incompatibility.
Message senders MAY send an empty PA-TNC message with the
Version value set to 0 in order to discover the PA-TNC
protocol versions supported by peer recipients (see PA-TNC
Error Code information in section 3.2.8). Message recipients
MUST NOT support version 0 and MUST NOT interpret the
contents (after the Version field) of a PA-TNC message
containing a version number that the recipient does not
support. Message recipients MUST respond to a PA-TNC message
with an unsupported version by sending a Version Not
Supported error code in a PA-TNC Error attribute.
PA-TNC message initiators supporting multiple PA-TNC protocol
versions SHOULD be able to alter which version of PA-TNC
message they send based on prior message exchanges with a
particular peer Posture Collector or Posture Validator.
Reserved
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
Message Identifier
This field contains a value that uniquely identifies this
message, differentiating it from others sent by a particular
PA-TNC message sender within this assessment. This value can
be included in a response message to indicate which message
was received and caused the response. For example, this
field is included in the PA-TNC error messages so the party
who receives the error message can determine which of the
messages they had sent caused the error.
PA-TNC message senders MUST NOT send the same message
identifier more than once during an assessment. Message
identifiers may be randomly generated or sequenced as long as
Sangster Expires August 7, 2008 [Page 11]
Internet-Draft PA-TNC February 2008
values are not repeated during an assessment message
exchange. PA-TNC message recipients are not required to
check for duplicate message identifiers.
3. 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 2.5) 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 3.1. The contents
of PA-TNC attributes vary widely, depending on their attribute
type. Section 3.2 defines the IETF Standard PA-TNC Attributes.
Section 3.3 discusses how vendor-specific PA-TNC attributes can
be defined.
3.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
Sangster Expires August 7, 2008 [Page 12]
Internet-Draft PA-TNC February 2008
format in a manner detectable by PA-TNC message recipients.
Similarly, requiring all TLV attribute formats to be the same
within a PA-TNC message also assures that recipients compliant
with a particular PA-TNC message version can at least parse
every attribute header and use the length to skip over
unrecognized attributes. Every PA-TNC 1.0 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Sangster Expires August 7, 2008 [Page 13]
Internet-Draft PA-TNC February 2008
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 (0x40) is the Correlation ID (COR) flag. This flag
indicates whether the optional Correlation ID value is
included in the header. When set to 1, a 32 bit Correlation
ID field is present. Otherwise when set to 0, no Correlation
ID is included.
Bit 2-7 are reserved for future use. These bits MUST be set
to 0 on transmission and ignored upon reception.
PA-TNC Attribute Vendor ID
This field indicates the owner of the name space associated
with the PA-TNC Attribute Type. This is accomplished by
specifying the 24 bit SMI Private Enterprise Number Vendor ID
of the party who owns the Attribute Type name space. IETF
Standard PA-TNC Attribute Types MUST use zero (0) in this
field.
The PA-TNC Attribute Vendor ID 0xffffff is reserved. Posture
Collectors and Posture Verifiers 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
Verifier 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.
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
Sangster Expires August 7, 2008 [Page 14]
Internet-Draft PA-TNC February 2008
registry. Section 3.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 Verifiers MUST NOT send PA-TNC
messages in which the PA-TNC Attribute Type has this reserved
value (0xffffffff). If a Posture Collector or Posture
Verifier 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 (16 if the Correlation ID is present). Any
Posture Collector or Posture Verifier that receives a message
with a PA-TNC Attribute Length field whose value is less than
12 (16 if the Correlation ID is present) 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 likely to
be less than 2^32-1 due to limitations of the underlying
protocol stack.
Correlation ID
This optional field MUST be present when the COR flag is set
to 1 and MUST NOT be present when the COR flag is set to 0.
Normally, this field will not be present. However, there are
times when this field is necessary.
Some Posture Collectors may wish to report on several
products with the same component ID on an endpoint (e.g. two
anti-malware software packages). In this case, the Posture
Collector and Posture Validator need a way to identify the
different products. For example, if a Posture Validator
requests Product Information and Numeric Version attributes
for the anti-malware component, this Posture Collector would
produce two Product Information and two Numeric Version
attributes, each attribute having a Correlation ID specific
Sangster Expires August 7, 2008 [Page 15]
Internet-Draft PA-TNC February 2008
to the product being described. The Product Information and
Numeric Version attributes describing the same product would
have the same Correlation ID. This allows the Posture
Validator to associate the Product Information and Numeric
Version attributes that apply to a single product. Because
the Product Information and Numeric Version attribute
requests might be requested at different times, it is
important that the Posture Collector use a consistent value
for each product upon which it is able to report. A Posture
Collector might create a persistent table of locally unique
IDs (e.g. counters) for each product upon which it reports,
for situations where a Correlation ID is necessary.
Note that many Posture Collectors will not need to worry
about Correlation IDs because they will only support
reporting on one product per endpoint. If an endpoint has two
anti-malware Posture Collectors installed that each support
only one product and those Posture Collectors are reporting
on two separate anti-malware products, the Correlation ID is
not required. This is because the Posture Validator can use
the Posture Collector ID reported in the PB-TNC protocol to
associate the attributes sent by each Posture Collector.
When a single Posture Collector needs to send several
attributes in a single assessment that pertain to separate
products but have the same PA Message Vendor ID and PA
Subtype, the Posture Collector MUST use the Correlation ID
field. The Correlation ID value MUST be constant per product
for an entire PB-TNC session so that the Posture Validator
can correlate attributes requested earlier about the same
product. The Posture Validator MAY send attributes with a
Correlation ID to identify the product to which they pertain.
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 is defined
in section 3.2.
3.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
Sangster Expires August 7, 2008 [Page 16]
Internet-Draft PA-TNC February 2008
completely different meaning that is not defined in this
specification.
The following table briefly describes each attribute and defines
the numeric value to be used in the PA-TNC Attribute Type field
of the PA-TNC Attribute Header. Later subsections provide
detailed specifications for each PA-TNC Attribute Value.
Number Name Description
------ ---- -----------
0 Testing Reserved for use in
specification examples,
experimentation and testing.
1 Attribute Request Contains a list of attribute
type values defining the
attributes desired from the
Posture Collectors.
2 Product Information Manufacturer and product
information for the component.
3 Numeric Version Numeric version of the
component.
4 String Version String version of the
component.
5 Operational Status Describes whether the component
is running on the endpoint.
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.
The following subsections discuss the usage, format and
semantics of the Attribute Value field for each IETF Standard
PA-TNC Attribute Type.
Sangster Expires August 7, 2008 [Page 17]
Internet-Draft PA-TNC February 2008
3.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. 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 Verifiers MUST NOT include this attribute type in an
Attribute Request attribute. It does not make sense for a
Posture Verifier to request that a Posture Collector send an
Attribute Request attribute.
For this attribute type, the PA-TNC Attribute Vendor ID field
MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
be set to 1.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
Note that this diagram shows two attribute types. The actual
number of attribute types included in an Attribute Request
attribute can vary from one to a large number (limited only by
the maximum message and length supported by the underlying PT
transport protocol). However, each Attribute Request MUST
contain at least one attribute type. Because the length of a
PA-TNC Attribute Vendor ID paired with a PA-TNC Attribute Type
and a one octet Reserved field is always 8 octets, the number of
requested attributes can be easily computed using the PA-TNC
Attribute Length field by subtracting the number of octets in
the PA-TNC Attribute Header and dividing by 8. If the PA-TNC
Attribute Length field is invalid, Posture Collectors SHOULD
respond with an Invalid Parameter PA-TNC error code.
Sangster Expires August 7, 2008 [Page 18]
Internet-Draft PA-TNC February 2008
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
PA-TNC Attribute Vendor ID
This field contains the SMI Private Enterprise Number of the
organization that controls the name space for the following
PA-TNC Attribute Type. This field enables IETF Standard PA-
TNC Attributes and vendor-defined PA-TNC Attributes to be
used without potential collisions.
Any IETF Standard PA-TNC Attribute Types defined in section
3.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
Sangster Expires August 7, 2008 [Page 19]
Internet-Draft PA-TNC February 2008
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.
3.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 2.4. 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 (21 if the Correlation ID field is present) because
this is the length of the fixed size fields in the PA-TNC
Attribute Header and the fixed size fields in this attribute
type. If the PA-TNC Attribute Length field is less than the
size of these fixed length fields, implementations SHOULD
respond with an Invalid Parameter PA-TNC error code.
This attribute type includes both numeric and textual
identifiers for the organization that created the product (the
"product creator") and for the product itself. For automated
processing, numeric identifiers are superior because they are
less ambiguous and more efficient. However, numeric identifiers
are only available if the product creator has assigned them.
Therefore, a textual identifier is also included. This textual
identifier has the additional benefit that it may be easier for
humans to read (although this benefit is minimal since the
primary purpose of this attribute is automated assessment).
Sangster Expires August 7, 2008 [Page 20]
Internet-Draft PA-TNC February 2008
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
Sangster Expires August 7, 2008 [Page 21]
Internet-Draft PA-TNC February 2008
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 or 16, depending on whether the
Correlation ID is present) 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.
3.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 2.4.
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.
Sangster Expires August 7, 2008 [Page 22]
Internet-Draft PA-TNC February 2008
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 Correlation ID field is not present and 32 if
it is present. 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.
Sangster Expires August 7, 2008 [Page 23]
Internet-Draft PA-TNC February 2008
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.
3.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 2.4.
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
Sangster Expires August 7, 2008 [Page 24]
Internet-Draft PA-TNC February 2008
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 (19 if the Correlation ID field is present)
because this is the length of the fixed size fields in the PA-
TNC Attribute Header and the fixed size fields in this attribute
type. If the PA-TNC Attribute Length field is less than the
size of these fixed length fields or does not match the length
indicated by the sum of the fixed length and variable length
fields, implementations SHOULD respond with an Invalid Parameter
PA-TNC error code.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
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
Sangster Expires August 7, 2008 [Page 25]
Internet-Draft PA-TNC February 2008
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 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).
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
Sangster Expires August 7, 2008 [Page 26]
Internet-Draft PA-TNC February 2008
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.
3.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 2.4. 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
Sangster Expires August 7, 2008 [Page 27]
Internet-Draft PA-TNC February 2008
MUST be 36 if the Correlation ID field is not present and 40 if
it is present. 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. As described in section 7, the IANA maintains a
registry of valid values for this field so that new values
can be defined.
Sangster Expires August 7, 2008 [Page 28]
Internet-Draft PA-TNC February 2008
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. As described in section 7, the IANA
maintains a registry of valid values for this field so that
new values can be defined.
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.
Leap seconds are permitted and Posture Validators MUST
support them. The last use string MUST NOT be NUL terminated
Sangster Expires August 7, 2008 [Page 29]
Internet-Draft PA-TNC February 2008
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). Not
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.
3.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.
Sangster Expires August 7, 2008 [Page 30]
Internet-Draft PA-TNC February 2008
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
Note that this diagram shows two Protocol/Port Number pairs. The
actual number of Protocol/Port Number pairs included in a Port
Filter attribute can vary from one to a large number (limited
only by the maximum message and length supported by the
underlying PT transport protocol). However, each Port Filter
attribute MUST contain at least one Protocol/Port Number pair.
Because the length of a Protocol/Port Number pair with the
Reserved field and B flag is always 4 octets, the number of
Protocol/Port Number pairs can be easily computed using the PA-
TNC Attribute Length field by subtracting the number of octets
in the PA-TNC Attribute Header and dividing by 4. If the PA-TNC
Attribute Length field is invalid, Posture Validators SHOULD
respond with an Invalid Parameter PA-TNC error code.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved for future use. It MUST be set to 0
on transmission and ignored upon reception.
B Flag (Blocked or Allowed Port)
This single bit field indicates whether the following port is
blocked or allowed. This bit MUST be set to 1 if the
protocol and port combination is blocked. Otherwise this
field MUST be set to 0. This field was provided to allow for
more abbreviated reporting of the port filtering policy (e.g.
when all ports are blocked except a few, the Posture
Collector can just list the few that are allowed).
Sangster Expires August 7, 2008 [Page 31]
Internet-Draft PA-TNC February 2008
Posture Collectors MUST NOT provide a mixed list of block 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 List 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 protocol number 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 a registry of these values.
Port Number
This field contains the 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 TCP and UDP port numbers.
3.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 2.4. 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
Sangster Expires August 7, 2008 [Page 32]
Internet-Draft PA-TNC February 2008
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 (20 if the Correlation ID field is
present) because this is the length of the fixed size fields in
the PA-TNC Attribute Header and the fixed size fields in this
attribute type. If the PA-TNC Attribute Length field is less
than the size of these fixed length fields or does not match the
length indicated by the sum of the fixed length and variable
length fields, implementations SHOULD respond with an Invalid
Parameter PA-TNC error code.
The following diagram illustrates the format and contents of the
Attribute Value field for this attribute type. The text after
this diagram describes the fields shown here.
Note that this diagram shows an attribute containing information
on one package. The actual number of package descriptions
included in an Installed Packages attribute is indicated by the
Package Count field. This value may vary from zero to a large
number (up to 65535, if the underlying PT transport protocol can
support that many). If this number is not sufficient,
specialized patch management software should be employed which
can simply report compliance with a pre-established patch
policy.
Sangster Expires August 7, 2008 [Page 33]
Internet-Draft PA-TNC February 2008
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
Sangster Expires August 7, 2008 [Page 34]
Internet-Draft PA-TNC February 2008
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.
3.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 (24 if the Correlation ID field is present)
because this is the length of the fixed size fields in the PA-
TNC Attribute Header and the fixed size fields in this attribute
type.
Sangster Expires August 7, 2008 [Page 35]
Internet-Draft PA-TNC February 2008
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 Verifiers MUST NOT include this attribute type in an
Attribute Request attribute. It does not make sense for a
Posture Verifier 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
Sangster Expires August 7, 2008 [Page 36]
Internet-Draft PA-TNC February 2008
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.
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. The
IANA maintains a registry for these values. The following
table lists the IETF Standard PA-TNC Error Codes defined in
this specification:
Value Description
----- -----------
0 Reserved
1 Invalid Parameter
2 Version Not Supported
3 Attribute Type Not Supported
The next few subsections of this document provide detailed
definitions of these error codes.
Error Information
This field provides additional context for the error. The
contents of this field vary based on the PA-TNC Error Code
Vendor ID and PA-TNC Error Code. Therefore, whenever a PA-TNC
Error Code is defined, the format of this field for that
error code must also be defined. The definitions of IETF
Standard PA-TNC Error Codes on the next few pages provide
good examples of such definitions.
The length of this field can be determined by the recipient
using the PA-TNC Attribute Length field by subtracting the
Sangster Expires August 7, 2008 [Page 37]
Internet-Draft PA-TNC February 2008
length of the fixed-length fields in the PA-TNC Attribute
Header and the fixed-length fields in this attribute.
3.2.8.1. Definition of 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
Sangster Expires August 7, 2008 [Page 38]
Internet-Draft PA-TNC February 2008
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.
3.2.8.2. Definition of 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
SHOULD 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 SHOULD 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
Sangster Expires August 7, 2008 [Page 39]
Internet-Draft PA-TNC February 2008
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.
Sangster Expires August 7, 2008 [Page 40]
Internet-Draft PA-TNC February 2008
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.
3.2.8.3. Definition of 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.
Sangster Expires August 7, 2008 [Page 41]
Internet-Draft PA-TNC February 2008
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
This field MUST contain an exact copy of the Version field in
the PA-TNC Message Header of the PA-TNC message that caused
this error.
Copy of Reserved
This field MUST contain an exact copy of the Reserved field
in the PA-TNC Message Header of the PA-TNC message that
caused this error.
Message Identifier
This field MUST contain an exact copy of the Message
Identifier field in the PA-TNC Message Header of the PA-TNC
message that caused this error.
Flags
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
Sangster Expires August 7, 2008 [Page 42]
Internet-Draft PA-TNC February 2008
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.
3.3. Vendor-Defined Attributes
This section discusses the use of vendor-defined attributes
within PA-TNC. The PA-TNC protocol was designed to allow for
vendor-defined attributes to be used as a replacement where a
standard attribute could be used. In some cases even the
standard attributes allow for vendor-defined information to be
included. It is envisioned that over time as particular vendor-
defined attributes become popular, an equivalent standard
attribute could be added allowing for broader interoperability.
This specification does not define vendor-defined attributes,
but rather highlights how such attributes can be used with PA-
TNC without the potential for name space collisions or
misinterpretations. In order to avoid collisions, PA-TNC uses
the well-established SMI Private Enterprise Numbers as Vendor
IDs to define separate name spaces for important fields within a
PA-TNC message. For example, to ensure the uniqueness of
attribute types while providing for vendor extensions, vendor-
defined attribute types include the vendor's unique Vendor ID,
to indicate the intended name space for the attribute type,
followed by the attribute type. IETF Standard PA-TNC Attribute
Types use a Vendor ID of zero (0).
SMI Private Enterprise Numbers are used to provide a separate
identifier space for each vendor. The IANA provides a registry
for SMI Private Enterprise Numbers. Any organization (including
non-profit organizations, governmental bodies, etc.) can obtain
one of these numbers at no charge and thousands of organizations
have done so. Within this document, SMI Private Enterprise
Numbers are known as "vendor IDs".
4. Evaluation Against NEA Requirements
This section evaluates the PA-TNC protocol against the
requirements defined in the NEA Requirements document. Each
subsection considers a separate requirement from the NEA
Sangster Expires August 7, 2008 [Page 43]
Internet-Draft PA-TNC February 2008
Requirements document. Only common requirements (C-1 through C-
10) and PA requirements (PA-1 through PA-6) are considered,
since these are the only ones that apply to PA.
4.1. Evaluation Against Requirement C-1
Requirement C-1 says:
C-1 NEA protocols MUST support multiple round trips between
the NEA Client and NEA Server in a single assessment.
PA-TNC meets this requirement. It allows an unlimited number of
round trips between the NEA Client and NEA Server.
4.2. Evaluation Against Requirement C-2
Requirement C-2 says:
C-2 NEA protocols SHOULD provide a way for both the NEA Client
and the NEA Server to initiate a posture assessment or
reassessment as needed.
PA-TNC meets this requirement. PA-TNC is designed to work
whether the NEA Client or the NEA Server initiates a posture
assessment or reassessment.
4.3. Evaluation Against Requirement C-3
Requirement C-3 says:
C-3 NEA protocols including security capabilities MUST be
capable of protecting against active and passive attacks
by intermediaries and endpoints including prevention from
replay based attacks.
Security for PA-TNC can be provided through PT security or
through the use of PA-TNC security, which is defined in a
separate specification: PA-TNC Security [8]. Therefore, this
base specification for PA-TNC does not include any security
capabilities. Since this requirement only applies to NEA
protocols that include security capabilities, this base
specification for PA-TNC meets this requirement.
4.4. Evaluation Against Requirement C-4
Requirement C-4 says:
Sangster Expires August 7, 2008 [Page 44]
Internet-Draft PA-TNC February 2008
C-4 The PA and PB protocols MUST be capable of operating over
any PT protocol. For example, the PB protocol must
provide a transport independent interface allowing the PA
protocol to operate without change across a variety of
network protocol environments (e.g. EAP/802.1X, PANA, TLS
and IKE/IPsec).
PA-TNC meets this requirement. PA-TNC can operate over any PT
protocol that meets the requirements for PT stated in the NEA
Requirements document. PA-TNC does not have any dependencies on
specific details of the underlying PT protocol.
4.5. Evaluation Against Requirement C-5
Requirement C-5 says:
C-5 The selection process for NEA protocols MUST evaluate and
prefer the reuse of existing open standards that meet the
requirements before defining new ones. The goal of NEA is
not to create additional alternative protocols where
acceptable solutions already exist.
Based on this requirement, PA-TNC should receive a strong
preference. PA-TNC is equivalent with IF-M 1.0, an open TCG
specification. Other specifications from TCG and other groups
are also under development based on the IF-M 1.0 specification.
Selecting PA-TNC as the basis for the PA protocol will ensure
compatibility with IF-M 1.0, with these other specifications,
and with their implementations.
4.6. Evaluation Against Requirement C-6
Requirement C-6 says:
C-6 NEA protocols MUST be highly scalable; the protocols MUST
support many Posture Collectors on a large number of NEA
Clients to be assessed by numerous Posture Validators
residing on multiple NEA Servers.
PA-TNC meets this requirement. PA-TNC supports an unlimited
number of Posture Collectors, Posture Validators, NEA Clients,
and NEA Servers. It also is quite scalable in many other
aspects as well. A PA-TNC message can contain up to 2^32-1
octets and about 2^28 PA-TNC attributes. Each organization with
an SMI Private Enterprise Number is entitled to define up to
2^32 vendor-specific PA-TNC Attribute Types, 2^16 vendor-
specific PA-TNC Product IDs, and 2^32 vendor-specific PA-TNC
Sangster Expires August 7, 2008 [Page 45]
Internet-Draft PA-TNC February 2008
Error Codes. Each attribute can contain almost 2^32 octets. It
is generally not advisable or necessary to send this much data
in a NEA assessment, but still PA-TNC is highly scalable and
meets requirement C-6 easily.
4.7. Evaluation Against Requirement C-7
Requirement C-7 says:
C-7 The protocols MUST support efficient transport of a large
number of attribute messages between the NEA Client and
the NEA Server.
PA-TNC meets this requirement. Each PA-TNC message can contain
about 2^28 PA-TNC attributes. PA-TNC supports up to 2^32 round
trips in a session so the maximum number of attribute messages
that can be sent in a single session is actually about 2^50.
However, it is generally inadvisable and unnecessary to send a
large number of messages in a NEA assessment. As for
efficiency, PA-TNC adds only 12 octets of overhead per attribute
and 8 octets per message (which is negligible on a per-attribute
basis).
4.8. Evaluation Against Requirement C-8
Requirement C-8 says:
C-8 NEA protocols MUST operate efficiently over low bandwidth
or high latency links.
PA-TNC meets this requirement. A typical PA-TNC exchange will
involve one or two round trips with less than 500 octets of PA-
TNC messages. Of course, use of PA-TNC security or vendor-
specific PA-TNC attribute types could expand the assessment.
However, PA-TNC itself imposes an overhead of only 8 octets per
PA-TNC message and 12 octets per attribute.
4.9. Evaluation Against Requirement C-9
Requirement C-9 says:
C-9 For any strings intended for display to a user, the
protocols MUST support adapting these strings to the
user's language preferences.
Sangster Expires August 7, 2008 [Page 46]
Internet-Draft PA-TNC February 2008
PA-TNC meets this requirement. The fields defined here do not
include any strings intended for display to a user. They are
intended for logging and programmatic comparisons.
If any vendor-specific PA-TNC attribute types or future IETF
Standard PA-TNC Attribute Types include strings that are
intended for display to a user, they can be adapted to the
user's language preferences using the PB-TNC protocol's ability
to exchange information about those preferences in a standard
manner. The Posture Broker Server will need to expose the
user's preferences to the Posture Validators through whatever
API or protocol is used to connect those components. However,
that is all out of scope for this specification.
4.10. Evaluation Against Requirement C-10
Requirement C-10 says:
C-10 NEA protocols MUST support encoding of strings in UTF-8
format.
PA-TNC meets this requirement. All strings in the PA-TNC
protocol are encoded in UTF-8 format. This allows the protocol
to support a wide range of languages efficiently.
4.11. Evaluation Against Requirement PA-1
Requirement PA-1 says:
PA-1 The PA protocol MUST support communication of an
extensible set of NEA standards defined attributes. These
attributes will be uniquely identifiable from non-standard
attributes.
PA-TNC meets this requirement. Each attribute is identified
with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.
IETF Standard PA-TNC Attribute Types use a vendor ID of zero
(0), in contrast with vendor-specific PA-TNC Attribute Types,
which will use the vendor's SMI Private Enterprise Number as the
vendor ID. The IANA will maintain a registry of IETF Standard
PA-TNC Attribute Types with new values added by IETF Consensus,
as described in the IANA Considerations section of this
specification. Thus, the set of standard attribute types is
extensible, but all standard attribute types are uniquely
identifiable.
Sangster Expires August 7, 2008 [Page 47]
Internet-Draft PA-TNC February 2008
4.12. Evaluation Against Requirement PA-2
Requirement PA-2 says:
PA-2 The PA protocol MUST support communication of an
extensible set of vendor-specific attributes. These
attributes will be segmented into uniquely identifiable
vendor specific name spaces.
PA-TNC meets this requirement. Each attribute is identified
with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.
Vendor-defined PA-TNC Attribute Types use the vendor's SMI
Private Enterprise Number as the PA-TNC Attribute Vendor ID.
Each vendor can define up to 2^32 PA-TNC Attribute Types, using
its own internal processes to manage its set of attribute types.
The IANA is not involved, other than the initial assignment of
the vendor's SMI Private Enterprise Number. Thus, the set of
vendor-specific attributes is segmented into uniquely
identifiable vendor-specific name spaces.
4.13. Evaluation Against Requirement PA-3
Requirement PA-3 says:
PA-3 The PA protocol MUST enable a Posture Validator to make
one or more requests for attributes from a Posture
Collector within a single assessment. This enables the
Posture Validator to reassess the posture of a particular
endpoint feature or to request additional posture
including from other parts of the endpoint.
PA-TNC meets this requirement. The Attribute Request attribute
type is an IETF Standard PA-TNC Attribute Type that permits a
Posture Validator to send to one or more Posture Collectors a
request for one or more attributes. This attribute may be sent
at any point in the posture assessment process and may in fact
be sent more than once if the Posture Validator needs to first
determine the type of operating system and then request certain
attributes specific to that operating system, for example.
4.14. Evaluation Against Requirement PA-4
Requirement PA-4 says:
PA-4 The PA protocol MUST be capable of returning attributes
from a Posture Validator to a Posture Collector. For
example, this might enable the Posture Collector to learn
Sangster Expires August 7, 2008 [Page 48]
Internet-Draft PA-TNC February 2008
the specific reason for a failed assessment and to aid in
remediation and notification of the system owner.
PA-TNC meets this requirement. A Posture Validator can easily
send attributes to one or more Posture Collectors.
4.15. Evaluation Against Requirement PA-5
Requirement PA-5 says:
PA-5 The PA protocol SHOULD provide authentication, integrity,
and confidentiality of attributes communicated between a
Posture Collector and Posture Validator. This enables
end-to-end security across a NEA deployment that might
involve traversal of several systems or trust boundaries.
PA-TNC meets this requirement when a PA-TNC Security mechanism
is used, such as PA-TNC Security with CMS. The specifications
for those mechanisms should be consulted for a complete analysis
of their security properties.
PA-TNC Security is an optional addition to PA-TNC because
different products and deployments may require different
security mechanisms. For example, one product might integrate
Posture Validators, the Posture Broker Server, and the Posture
Transport Server into a single entity. In that case, PA-TNC
security may not be needed. PT security may be enough. Another
deployment may employ remote Posture Validators in the same
trust domain as the Posture Broker Server. In that case, a TLS
session between the Posture Broker Server and the Posture
Validators may suffice. A third deployment may include a Posture
Broker Server that is not trusted to see PA-TNC messages, at
least for some Posture Validators. In that case, PA-TNC security
may be desirable. Even there, some deployments may wish to use
PKI (Public Key Infrastructure) for security, while others may
wish to use Kerberos or another mechanism.
4.16. Evaluation Against Requirement PA-6
Requirement PA-6 says:
PA-6 The PA protocol MUST be capable of carrying attributes
that contain non-binary and binary data including
encrypted content.
PA-TNC meets this requirement. PA-TNC attributes can contain
non-binary and binary data including encrypted content. For
Sangster Expires August 7, 2008 [Page 49]
Internet-Draft PA-TNC February 2008
examples, see the attribute type definitions contained in this
specification and in the PA-TNC Security with CMS specification.
5. Security Considerations
This section discusses the major types of potential security
threats relevant to the PA-TNC message protocol and summarizes
the expected security protections that should be offered by PA-
TNC security protocols. PA-TNC security protocols are described
in separate specifications which layer upon the base PA-TNC
protocol described in this specification. It is envisioned that
additional attribute types will be defined to facilitate the
exchange of security capabilities, keys, and security protected
attributes. Ultimately, the NEA deployer decides which security
protection is most appropriate for a particular deployment
environment. The security protections discussed in this section
highlight the need for PA-TNC security protocol implementations
to be capable of offering the feature.
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. Some deployments
may wish to reduce the amount of assumed trust by using a PA-TNC
security protocol to protect the PA-TNC messages. The following
sub-sections discuss the trust properties associated with each
portion of the NEA reference model directly involved with the
processing of the PA-TNC protocol.
5.1.1. Posture Collector
The Posture Collectors are trusted by Posture Validators to:
o Collect valid information about the component type associated
with the Posture Collector
o Report upon collected information consistent with local
security and privacy policies
o Accurately report information associated with the type of
component for the PA-TNC message
o Not act maliciously to the Posture Broker Server and Posture
Validators, including attacks such as Denial Of Service
Sangster Expires August 7, 2008 [Page 50]
Internet-Draft PA-TNC February 2008
5.1.2. Posture Validator
The Posture Validators are trusted by Posture Collectors to:
o Only request information necessary to assess the security
state of the endpoint
o Make assessment decisions based on deployer defined policies
o Discard collected information consistent with data retention
and privacy policies
o Not act maliciously to the Posture Broker Server and Posture
Collectors, including attacks such as Denial Of Service
5.1.3. Posture Broker Client, Posture Broker Server, and PB-TNC
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 the Posture Collectors and Posture Validators with
unnecessary messages
o Not observe, fabricate, or alter the contents of a PA-TNC
message (this trust can be minimized with a PA-TNC security
protocol)
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
o Properly expose authentication information from PT security
so that Posture Collectors and Posture Validators can use
this to make policy decisions
Sangster Expires August 7, 2008 [Page 51]
Internet-Draft PA-TNC February 2008
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 targeted security countermeasures. PA-TNC
security protocol specifications MUST state if and how the
security protocol will safeguard against these types of attack.
Generally the PA-TNC protocol, without the presence of security
countermeasures, relies upon the underlying PT protocol to
protect the messages from attack when traveling over the
network. Once the message resides on the Posture Broker Client
or Posture Broker Server, it is trusted to be properly and
safely delivered to the appropriate Posture Collectors and
Posture Validators. However, in some deployments the PA-TNC
messages need to travel over network hops that are not protected
by PT or require more assurance that only the appropriate
Posture Collector or Posture Validator has received the message.
In these cases, end to end PA-TNC message protection might be
required. The following sub-sections focus on the potential
threats where end to end protection might be desired and thus
when the use of the PA-TNC security protocol becomes beneficial.
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 other financial gain.
Sangster Expires August 7, 2008 [Page 52]
Internet-Draft PA-TNC February 2008
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.
This could occur if an active attacker could launch a man-in-
the-middle (MiTM) attack by proxying the PA-TNC messages and was
able to replace undesired messages with ones easing future
attack upon the endpoint. Consider a scenario where PT security
protection is not used, and the Posture Broker Server proxies
all assessment traffic to a remote Posture Broker Server. The
proxy could eavesdrop and replace assessment results attributes,
tricking the endpoint into thinking it has passed an assessment,
when in fact it has not and requires remediation. Because the
Posture Collector has no way to verify that attributes were
actually created by an authentic Posture Validator, it is unable
to detect the falsified attribute or message.
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.
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
Sangster Expires August 7, 2008 [Page 53]
Internet-Draft PA-TNC February 2008
endpoint. Without a strong binding of the endpoint to the
measurement 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.
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 is possible by the recipient.
Even if authentication of the parties is present during a PA-TNC
exchange, if no per-message and per-session integrity protection
is present, an attacker can add information to the assessment,
possibly causing incorrect assessment results. 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.
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 to
untrusted parties along the communication path between the
Posture Collector and Posture Validator. Normally, the PT
exchange is bi-directionally authenticated which helps to
prevent a MiTM on the network from becoming an active proxy, but
transparent message routing gateways may still exist on the
communication path and can modify the integrity of the message
exchange unless adequate integrity protection is provided. If
the MiTM or other entities on the network can send messages to
the Posture Broker Client or Posture Broker Server that appear
to be part of an assessment, these messages could confuse the
Posture Collector and Posture Validator or cause them to perform
unnecessary work or take incorrect action. Several example
denial of service situations are described in section 5.2.3 and
Sangster Expires August 7, 2008 [Page 54]
Internet-Draft PA-TNC February 2008
5.2.5. Many potential denial of service examples exist,
including flooding messages to Posture Collector or Posture
Validator, sending very large messages containing many
attributes, and repeatedly asking for resource intensive
operations.
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 2.4. These components include a list
of security-related aspects of the endpoint that affect the
ability of the endpoint to resist attacks and thus are of
interest during an assessment. Discretionary components used by
the user to create or view content are not on the list, as they
are more likely to have access to privacy sensitive information.
Similarly, PA-TNC messages contain a set of attributes which
describe the particular component. Each attribute contains
generic information (e.g. product information or versions) about
the component, so it is unlikely to include any user specific or
identifying information. This combination of limited set of
security related components with non-user specific attributes
greatly reduces the risk of exposure of privacy sensitive
information. Vendors that choose to define additional component
types and/or attributes within their name space are encouraged
to provide similar constraints.
Even with the bounding of standard attribute information to
specific components, it is possible that individuals might wish
to share less information with different networks they wish to
Sangster Expires August 7, 2008 [Page 55]
Internet-Draft PA-TNC February 2008
access. For example, a user may wish to share more information
when connecting or being reassessed by the user's employer
network than what would be made available to the local coffee
shop wireless network. While these situations do not impact the
protocol itself, they do suggest that Posture Collector
implementations should consider supporting a privacy filter
allowing the user and/or system owner to restrict access to
certain attributes based upon the target network. The
underlying PT protocol authenticates the network's Posture
Broker Server at the start of an assessment, so identity can be
made available to the Posture Collector and per-network privacy
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
Two new IANA registries are defined by this specification: IETF
Standard PA-TNC Attribute Types and IETF Standard PA-TNC Error
Codes. This section explains how these registries work. Also,
this specification defines nine new IETF Standard PA Subtypes.
These assignments will be added to the registry for IETF
Standard PA Subtypes when this document is approved by the IESG
as an RFC.
Section 7.1 defines the new IETF Standard PA Subtypes. Sections
7.2 and 7.3 provide guidance to the IANA in creating and
managing the two new IANA registries defined by this
specification.
7.1. New IETF Standard PA Subtypes
Section 2.4 of this specification defines several new IETF
Standard PA Subtypes. Here is a list of these assignments:
Number Name
------ ----
0 Testing
1 Operating System
2 Anti-Virus
3 Anti-Spyware
4 Anti-Malware
5 Firewall
6 IDPS
Sangster Expires August 7, 2008 [Page 56]
Internet-Draft PA-TNC February 2008
7 VPN
Once this document becomes an RFC, these IETF Standard PA
Subtypes should be added to the registry for IETF Standard PA
Subtypes defined in the PB-TNC specification. The RFC number
assigned to this document should be associated with these
assignments.
7.2. Registry for IETF Standard PA-TNC Attribute Types
The name for this registry is "IETF Standard PA-TNC Attribute
Types". Each entry in this registry should include a human-
readable name, a decimal integer value between 0 and 2^32-1, and
a reference to an RFC where the contents of this attribute type
are defined. This RFC 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 numeric value in the PA-TNC Attribute Type field and
the value 0 in the PA-TNC Attribute Vendor ID field.
Entries to this registry may only be added by IETF Consensus, as
defined in RFC 2434 [3]. That is, they can only be added in an
RFC approved by the IESG.
The following entries for this registry are defined in this
document. Once this document becomes an RFC, they should become
the initial entries in the registry for IETF Standard PA-TNC
Attribute Types.
Sangster Expires August 7, 2008 [Page 57]
Internet-Draft PA-TNC February 2008
Integer Value Name Defining RFC
------------- ---- ------------
0 Testing RFC # Assigned to this I-D
1 Attribute Request RFC # Assigned to this I-D
2 Product Information RFC # Assigned to this I-D
3 Numeric Version RFC # Assigned to this I-D
4 String Version RFC # Assigned to this I-D
5 Operational Status RFC # Assigned to this I-D
6 Port Filter RFC # Assigned to this I-D
7 Installed Packages RFC # Assigned to this I-D
8 PA-TNC Error RFC # Assigned to this I-D
7.3. Registry for IETF Standard PA-TNC Error Codes
The name for this registry is "IETF Standard PA-TNC Error
Codes". Each entry in this registry should include a human-
readable name, a decimal integer value between 0 and 2^32-1, and
a reference to an RFC where this error code is defined. This
RFC 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 numeric value in the PA-TNC
Error Code field, and the value 0 in the PA-TNC Error Code
Vendor ID field.
Entries to this registry may only be added by IETF Consensus, as
defined in RFC 2434. That is, they can only be added in an RFC
approved by the IESG.
The following entries for this registry are defined in this
document. Once this document becomes an RFC, they should become
the initial entries in the registry for IETF Standard PA-TNC
Error Codes.
Sangster Expires August 7, 2008 [Page 58]
Internet-Draft PA-TNC February 2008
Integer Value Name Defining RFC
------------- ---- ------------
1 Invalid Parameter RFC # Assigned to this I-D
2 Version Not Supported RFC # Assigned to this I-D
3 Attribute Type Not Supported RFC # For this I-D
8. Acknowledgments
The authors of this draft would 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.
This document was prepared using 2-Word-v2.0.template.dot.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
[3] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October
1998.
[4] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[5] Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture
Broker Protocol (PB) Compatible with TNC", draft-sahita-
nea-pb-00.txt, Work In Progress, February 2008.
9.2. Informative References
[6] Trusted Computing Group, "IF-M: TLV Binding", February
2008.
Sangster Expires August 7, 2008 [Page 59]
Internet-Draft PA-TNC February 2008
[7] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", draft-ietf-nea-requirements-05.txt, Work In
Progress, November 2007.
[8] Sangster, P., "PA-TNC Security: A Posture Attribute (PA)
Security Protocol Compatible with TNC", draft-sangster-
nea-pa-tnc-security-00.txt, Work In Progress, February
2008.
Author's Address
Paul Sangster
Symantec Corporation
6825 Citrine Drive
Carlsbad, CA 92009 USA
Phone: +1.760.438.5656
Email: Paul_Sangster at symantec.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any
license under such rights might or might not be available; nor
does it represent that it has made any independent effort to
identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and
BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr at ietf.org.
Sangster Expires August 7, 2008 [Page 60]
Internet-Draft PA-TNC February 2008
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sangster Expires August 7, 2008 [Page 61]
_______________________________________________
Nea mailing list
Nea at ietf.org
http://www.ietf.org/mailman/listinfo/nea
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
