One document matched: draft-sangster-nea-pa-tnc-security-00.txt
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@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@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]
| PAFTECH AB 2003-2026 | 2026-04-24 05:50:25 |