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]