[要約] RFC 5792は、Trusted Network Connect（TNC）と互換性のあるポスチャ属性（PA）プロトコルであり、ネットワークデバイスのセキュリティポリシーの評価と適用を可能にする。目的は、ネットワーク上のデバイスのセキュリティ状態を確認し、適切なアクセス制御を実施するための標準化と統合を提供すること。
Internet Engineering Task Force (IETF) P. Sangster
Request for Comments: 5792 Symantec Corporation
Category: Standards Track K. Narayan
ISSN: 2070-1721 Cisco Systems
March 2010
PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
PA-TNC：姿勢属性（PA）プロトコルと信頼できるネットワーク接続（TNC）と互換性のある
Abstract
概要
This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification.
このドキュメントは、信頼できるコンピューティンググループのIF-M 1.0プロトコルと同一の姿勢属性プロトコルであるPA-TNCを指定します。次に、このドキュメントは、NEA要件仕様で定義されている要件に対してPA-TNCを評価します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5792.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5792で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Conventions Used in This Document ..........................4
2. Design Considerations ...........................................4
2.1. Standard Attribute Namespace for Interoperability ..........4
2.2. Vendor-Defined Namespace for Differentiation and Agility ...5
2.3. Use of TLV-Based Encoding for Efficiency ...................6
3. PA-TNC Message Protocol .........................................7
3.1. PA-TNC Messaging Model .....................................7
3.2. PA-TNC Relationship to PB-TNC ..............................8
3.3. PB-PA Posture Collector and Posture Validator
Identifiers ...............................................10
3.4. PA-TNC Messages in PB-TNC .................................10
3.5. IETF Standard PA Subtypes .................................11
3.6. PA-TNC Message Header Format ..............................12
4. PA-TNC Attributes ..............................................13
4.1. PA-TNC Attribute Header ..................................13
4.2. IETF Standard PA-TNC Attribute Types .....................17
4.2.1. Attribute Request ..................................18
4.2.2. Product Information ................................20
4.2.3. Numeric Version ....................................22
4.2.4. String Version .....................................24
4.2.5. Operational Status .................................26
4.2.6. Port Filter ........................................29
4.2.7. Installed Packages .................................31
4.2.8. PA-TNC Error .......................................34
4.2.9. Assessment Result ..................................41
4.2.10. Remediation Instructions ..........................42
4.2.11. Forwarding Enabled ................................45
4.2.12. Factory Default Password Enabled ..................47
4.3. Vendor-Defined Attributes ................................48
5. Security Considerations ........................................48
5.1. Trust Relationships .......................................48
5.1.1. Posture Collector ..................................49
5.1.2. Posture Validator ..................................49
5.1.3. Posture Broker Client, Posture Broker Server .......49
5.2. Security Threats ..........................................50
5.2.1. Attribute Theft ....................................50
5.2.2. Message Fabrication ................................51
5.2.3. Attribute Modification .............................51
5.2.4. Attribute Replay ...................................52
5.2.5. Attribute Insertion ................................52
5.2.6. Denial of Service ..................................53
6. Privacy Considerations .........................................53
7. IANA Considerations ............................................54
7.1. Designated Expert Guidelines ..............................55
7.2. PA Subtypes ...............................................56
7.3. Registry for PA-TNC Attribute Types .......................56
7.4. Registry for PA-TNC Error Codes ...........................57
7.5. Registry for PA-TNC Remediation Parameters Types ..........58
8. Acknowledgments ................................................58
9. References .....................................................59
9.1. Normative References ......................................59
9.2. Informative References ....................................59
Appendix A. Use Cases .............................................60
A.1. Initial Client-Triggered Assessment .......................60
A.2. Server-Initiated Assessment with Remediation ..............64
A.3. Client-Triggered Reassessment .............................71
Appendix B. Evaluation against NEA Requirements ...................77
B.1. Evaluation against Requirements C-1 .......................77
B.2. Evaluation against Requirements C-2 .......................77
B.3. Evaluation against Requirements C-3 .......................77
B.4. Evaluation against Requirements C-4 .......................78
B.5. Evaluation against Requirements C-5 .......................78
B.6. Evaluation against Requirements C-6 .......................78
B.7. Evaluation against Requirements C-7 .......................79
B.8. Evaluation against Requirements C-8 .......................79
B.9. Evaluation against Requirements C-9 .......................79
B.10. Evaluation against Requirements C-10 .....................80
B.11. Evaluation against Requirements C-11 .....................80
B.12. Evaluation against Requirements PA-1 .....................81
B.13. Evaluation against Requirements PA-2 .....................81
B.14. Evaluation against Requirements PA-3 .....................81
B.15. Evaluation against Requirements PA-4 .....................82
B.16. Evaluation against Requirements PA-5 .....................82
B.17. Evaluation against Requirements PA-6 .....................83
This document specifies PA-TNC, a Posture Attribute (PA) Protocol identical to the Trusted Computing Group's IF-M 1.0 protocol [8]. The document then evaluates PA-TNC against the requirements defined in the Network Endpoint Assessment (NEA) Requirements specification [9].
このドキュメントは、信頼できるコンピューティンググループのIF-M 1.0プロトコル[8]と同一の姿勢属性（PA）プロトコルであるPA-TNCを指定します。次に、このドキュメントは、ネットワークエンドポイント評価（NEA）要件仕様で定義されている要件に対してPA-TNCを評価します[9]。
This document does not define an architecture or reference model. Instead, it defines a protocol that works within the reference model described in the NEA Overview and Requirements specification. The reader is assumed to be thoroughly familiar with that document. No familiarity with TCG specifications is assumed.
このドキュメントは、アーキテクチャまたは参照モデルを定義しません。代わりに、NEAの概要と要件仕様で説明されている参照モデル内で機能するプロトコルを定義します。読者は、その文書に完全に精通していると想定されています。TCG仕様に精通していることは想定されていません。
This specification defines the syntax of PA-TNC messages using diagrams. Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits in each diagram as they are shown, traversing the diagram from top to bottom and then from left to right within each line (which represents a 32-bit quantity). Multi-byte fields representing numeric values must be sent in network (big endian) byte order.
この仕様は、図を使用してPA-TNCメッセージの構文を定義します。各図は、ビットの各フィールドの形式とサイズを示しています。実装は、表示されているときに各図にビットを送信する必要があり、上から下への図を通過し、次に各行内で左から右に通過します（32ビット量を表します）。数値を表すマルチバイトフィールドは、ネットワーク（ビッグエンディアン）バイト順序で送信する必要があります。
Descriptions of bit field (e.g., flag) values are described referring to the position of the bit within the field. These bit positions are numbered from the most significant bit through the least significant bit, so a 1-octet field with only bit 0 set has the value 0x80.
ビットフィールド（フラグ）値の説明は、フィールド内のビットの位置を参照しています。これらのビット位置は、最も重要なビットから最も重要なビットから番号が付けられているため、ビット0セットのみを持つ1オクテットのフィールドには値0x80があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
This section discusses some of the key design considerations for the PA protocol.
このセクションでは、PAプロトコルの主要な設計上の考慮事項のいくつかについて説明します。
The PA protocol requires the use of two categories of namespaces: component types (AKA PA subtypes) and attributes. Each of these namespace categories needs to contain well-known, interoperable names with defined syntax and semantics co-existing with names for vendor- defined private extensions. Similarly, each namespace category needs to be readily extensible without repeated coordination yet avoids naming conflicts.
PAプロトコルでは、2つのカテゴリの名前空間を使用する必要があります：コンポーネントタイプ（別名PAサブタイプ）と属性が必要です。これらの各名前空間カテゴリは、ベンダー定義されたプライベートエクステンションの名前と共存する定義された構文とセマンティクスを備えたよく知られた相互運用可能な名前を含める必要があります。同様に、各名前空間カテゴリは、繰り返し調整せずに容易に拡張可能である必要がありますが、競合の命名を避けます。
The PA-TNC and PB-TNC protocols provide for multiple orthogonal namespaces for each category that exist without overlap by including a Structure of Management Information (SMI) Private Enterprise Number (PEN) field to identify the definer of namespace of the associated field. This allows the IETF NEA WG to define a set of standard component types and attribute types while allowing vendors to each create additional names outside of the IETF standard namespace. Over time, vendor-defined names might be proposed for standardization and thus migration into the IETF namespace.
PA-TNCおよびPB-TNCプロトコルは、管理情報の構造（SMI）プライベートエンタープライズ番号（PEN）フィールドを含めることにより、重複することなく存在する各カテゴリの複数の直交名空間を提供し、関連するフィールドの名前空間の定義者を識別します。これにより、IETF NEA WGは、標準コンポーネントタイプと属性タイプのセットを定義でき、それぞれがIETF標準名空間の外側に追加の名前を作成できるようにすることができます。時間が経つにつれて、ベンダー定義の名前が標準化のために提案され、したがってIETF名空間への移行が提案される場合があります。
The PB-TNC protocol defines an IETF standard namespace (using vendor-id=0) that allows for definition of standard component types (e.g., Operating System, Firewall, Anti-Virus) using the PA Subtype field (see section 3.2). Similarly, PA-TNC defines a set of standard attributes in section 4.2 that represent the most common capabilities (attributes) of these types of components across a variety of vendor implementations. The standard namespace allows NEA deployments with both open source and vendor-provided NEA implementations to support a consistent set of policies across their environment based on these standard attributes. The standard attributes can be used with a variety of endpoints (hosts, printers, mobile devices) that are running applications and operating systems (defined by the PA subtypes) from a variety of vendors.
PB-TNCプロトコルは、PAサブタイプフィールドを使用して標準コンポーネントタイプ（オペレーティングシステム、ファイアウォール、アンチウイルスなど）の定義を可能にするIETF標準名空間（ベンダー-ID = 0を使用）を定義します（セクション3.2を参照）。同様に、PA-TNCは、さまざまなベンダーの実装にわたるこれらのタイプのコンポーネントの最も一般的な機能（属性）を表すセクション4.2の標準属性のセットを定義します。標準の名前空間では、オープンソースとベンダーが提供するNEA実装の両方を備えたNEAの展開を可能にし、これらの標準属性に基づいて環境全体で一貫したポリシーセットをサポートします。標準属性は、さまざまなベンダーからアプリケーションとオペレーティングシステム（PAサブタイプで定義）を実行しているさまざまなエンドポイント（ホスト、プリンター、モバイルデバイス）で使用できます。
The endpoint is a very dynamic environment in terms of rate of new features being deployed and attacks that are crafted against existing and new applications such as viruses, worms, malware, and spyware. It is difficult to imagine the standard namespaces being able to keep pace with this rapidly changing environment. Vendors typically differentiate themselves by moving rapidly to provide unique mechanisms to address such threats and their ability to deal with changes in an agile manner. The PA-TNC and PB-TNC protocols allow for creation of vendor-defined namespace(s) where each namespace allows use of vendor-defined PA subtypes to identify non-standard applications or operating system variants and vendor-defined attributes describing new aspects of each type of component. The vendor namespaces will allow NEA deployments to craft compliance policies using a mixture of attributes from both the IETF standard namespace and vendor-defined namespaces that may include multiple vendors representing the various hardware and software components present on the endpoints.
エンドポイントは、展開されている新機能のレートと、ウイルス、ワーム、マルウェア、スパイウェアなどの既存のアプリケーションや新しいアプリケーションに対して作成される攻撃の点で非常に動的な環境です。標準的な名前空間がこの急速に変化する環境に対応できると想像することは困難です。ベンダーは通常、迅速に移動して、そのような脅威に対処するためのユニークなメカニズムと、アジャイルな方法で変化に対処する能力を提供することで自分自身を区別します。PA-TNCおよびPB-TNCプロトコルにより、ベンダー定義の名前空間を作成できます。各名前空間により、ベンダー定義のPAサブタイプを使用して、非標準アプリケーションまたはオペレーティングシステムのバリエーション、およびベンダー定義の属性を識別し、各タイプのコンポーネント。ベンダーの名前空間では、NEAの展開が、エンドポイントに存在するさまざまなハードウェアとソフトウェアコンポーネントを表す複数のベンダーを含む可能性のあるIETF標準名空間とベンダー定義の両方の名前からの属性の混合を使用して、コンプライアンスポリシーを作成することができます。
The PA-TNC protocol's use of vendor-id to identify the namespace of each attribute allows Posture Collectors to support some or all of the IETF standard attributes plus optionally a set of vendor-defined attributes (potentially from more than one vendor-id namespace). For instance, an open source anti-virus Posture Collector might be written that supports all of the IETF standard attributes used to describe a local anti-virus component and a subset of multiple anti-virus manufacturers' vendor-defined attributes. This Posture Collector might therefore be able to interoperate with Posture Validators from multiple vendors. Conversely, a simple Posture Collector might be written to ignore any vendor-defined attributes requested and only return standard attributes that it supports. If the vendor-provided Posture Validator's policy allows for this subset to be considered compliant, then these simple Posture Collectors can be used to perform a successful assessment.
PA-TNCプロトコルが各属性の名前空間を識別するためにベンダー-IDを使用することにより、姿勢コレクターはIETF標準属性の一部またはすべてに加えて、オプションでベンダー定義の属性のセットをサポートできます（潜在的には複数のベンダーIDネームスペースから）。たとえば、ローカルウイルス剤コンポーネントと複数のアンチウイルスメーカーのベンダー定義属性のサブセットを記述するために使用されるすべてのIETF標準属性をサポートするオープンソース姿勢コレクターが書かれている場合があります。したがって、この姿勢コレクターは、複数のベンダーからの姿勢バリデーターと相互運用できる可能性があります。逆に、単純な姿勢コレクターは、要求されたベンダー定義の属性を無視し、サポートする標準属性のみを返すために書かれている可能性があります。ベンダーが提供するPosure Validatorのポリシーがこのサブセットを準拠していると見なすことができる場合、これらの単純な姿勢コレクターを使用して評価を成功させることができます。
The PA-TNC protocol has chosen to employ a binary encoding using a type-length-value (TLV) structure. TLV encoding was preferred over the use of a textual encoding format such as XML to provide a more efficient utilization of the potentially constrained bandwidth available between the NEA Client and NEA Server (see NEA Overview and Architecture [9]). Efficiency was a primary criterion for this choice with consideration given to both:
PA-TNCプロトコルは、型長値（TLV）構造を使用してバイナリエンコードを使用することを選択しました。TLVエンコーディングは、XMLなどのテキストエンコード形式の使用よりも好まれ、NEAクライアントとNEAサーバーの間で利用可能な潜在的に制約された帯域幅をより効率的に利用することができました（NEAの概要とアーキテクチャ[9]を参照）。効率は、両方に与えられたこの選択の主要な基準でした。
1. Optimization of the bits-on-the-wire to accommodate NEA requirements for assessment over low bandwidth or high latency links (C-8) and allow for the Posture Transport (PT) protocol to run over existing network access protocols (PT-4, C-11) that are constrained by packet size.
1. 低帯域幅または高レイテンシリンク（C-8）での評価のNEA要件に対応し、姿勢輸送（PT）プロトコルが既存のネットワークアクセスプロトコルを実行できるようにするためのワイヤーのビットの最適化（PT-4、C-11）パケットサイズによって制約されています。
2. Optimization of CPU utilization on the endpoint to accommodate for low power endpoints such as mobile devices.
2. モバイルデバイスなどの低電力エンドポイントに対応するためのエンドポイントでのCPU使用率の最適化。
The choice of TLV encoding does not preclude the use of XML-based attribute values within the vendor namespaces or future standard attributes. It is conceivable that certain vendors may utilize XML encoding for extensibility within their namespace when the above considerations are less applicable to their technologies. Attributes encoded within the vendor-defined namespace using alternate encoding such as XML will be opaque to NEA software only supporting standard attributes and will be processed primarily by the vendor-defined components (collector/validator).
TLVエンコーディングの選択は、ベンダーネームスペースまたは将来の標準属性内のXMLベースの属性値の使用を排除するものではありません。上記の考慮事項がテクノロジーにあまり適していない場合、特定のベンダーが名前空間内で拡張性のためにXMLエンコードを利用できると考えられます。XMLなどの代替エンコードを使用してベンダー定義の名前空間内でエンコードされた属性は、標準属性のみをサポートするNEAソフトウェアに不透明であり、主にベンダー定義コンポーネント（コレクター/バリデーター）によって処理されます。
This section discusses the use of the PA-TNC message and its attributes, and specifies the syntax and semantics for the PA-TNC message header. The details of each attribute included within the PA-TNC payload are specified in section 4.2.
このセクションでは、PA-TNCメッセージとその属性の使用について説明し、PA-TNCメッセージヘッダーの構文とセマンティクスを指定します。PA-TNCペイロードに含まれる各属性の詳細は、セクション4.2に指定されています。
PA-TNC messages are carried by the PB-TNC protocol [5], which provides a multi-roundtrip reliable transport and end-to-end message delivery to subscribed (interested) parties using a variety of underlying network protocols. PA-TNC is unaware of these underlying PT protocols being used below PB-TNC.
PA-TNCメッセージは、PB-TNCプロトコル[5]によって伝達されます。これは、さまざまな基礎となるネットワークプロトコルを使用して、サブスクライブ（関心のある）当事者へのマルチラウンドトリップの信頼性の高いトランスポートとエンドツーエンドのメッセージ配信を提供します。PA-TNCは、これらの基礎となるPTプロトコルがPB-TNC以下で使用されていることを認識していません。
The interested parties consist of Posture Collectors on the NEA Client and Posture Validators associated with the NEA Server that have registered to receive messages about particular types of components (e.g., anti-virus) during an assessment. The PA-TNC messaging protocol operates synchronously within an assessment session, with Posture Collectors and Posture Validators taking turns sending one or more messages to each other. Each PA-TNC message may contain one or more attributes associated with the functional component identified in the component type (PA Subtype) of the Posture Broker (PB) protocol.
利害関係者は、評価中に特定のタイプのコンポーネント（アンチウイルスなど）に関するメッセージを受信するために登録したNEAサーバーに関連付けられたNEAクライアントの姿勢コレクターと姿勢バリーターで構成されています。PA-TNCメッセージングプロトコルは、評価セッション内で同期的に動作し、姿勢コレクターと姿勢バリーターが互いに1つ以上のメッセージを送信します。各PA-TNCメッセージには、姿勢ブローカー（PB）プロトコルのコンポーネントタイプ（PAサブタイプ）で識別された機能コンポーネントに関連付けられた1つ以上の属性が含まれている場合があります。
Posture Collectors may only send PA-TNC messages to Posture Validators and vice versa. No Posture Collector-to-Posture Collector or Posture Validator-to-Posture Validator messaging is allowed to occur. Each Posture Collector or Posture Validator may send several PA-TNC messages in succession before indicating that it has completed its batch of messages to the Posture Broker Client or Posture Broker Server respectively. As necessary, the Posture Broker Client and Posture Broker Server will batch these messages prior to sending them over the network.
姿勢コレクターは、PA-TNCメッセージを姿勢バリデーターにのみ送信することができ、その逆も同様です。姿勢コレクターからポスチャーへのコレクターまたは姿勢の検証装置の検証装置メッセージは、発生することはできません。各姿勢コレクターまたは姿勢検証装置は、それぞれ姿勢ブローカークライアントまたは姿勢ブローカーサーバーへのメッセージのバッチを完成させたことを示す前に、いくつかのPA-TNCメッセージを連続して送信する場合があります。必要に応じて、姿勢ブローカーのクライアントと姿勢ブローカーサーバーは、ネットワーク上に送信する前にこれらのメッセージをバッチします。
PB-TNC provides a publish/subscribe model of message exchange. This means that, at any given point in time, zero or more subscribers for a particular type of message may be present on a Posture Broker Client or Posture Broker Server. This is beneficial, since it allows one Posture Collector or Posture Validator to combine multiple functions (like anti-virus and personal firewall) by subscribing to both TNC standard component types. It also allows multiple Posture Collectors or Posture Validators to support the same components, such as two anti-virus Posture Validators that are each used to manage their own respective anti-virus client software.
PB-TNCは、メッセージ交換の公開/購読モデルを提供します。これは、特定のタイプのメッセージのゼロ以上のサブスクライバーが姿勢ブローカークライアントまたは姿勢ブローカーサーバーに存在する可能性があることを意味します。これは、1つの姿勢コレクターまたは姿勢検証装置が、両方のTNC標準コンポーネントタイプを購読することにより、複数の関数（アンチウイルスやパーソナルファイアウォールなど）を組み合わせることができるため、有益です。また、複数の姿勢コレクターまたは姿勢バリデーターが、それぞれ独自のアンチウイルスクライアントソフトウェアを管理するために使用される2つのウイルス型姿勢バリデーターなど、同じコンポーネントをサポートすることができます。
However, this publish/subscribe model has some possible negative side effects. When a Posture Collector or Posture Validator initially sends a PA-TNC message, it does not know whether it will receive many, one, or no PA-TNC messages from the other side. For many types of assessments, this is acceptable, but in some cases a more direct channel binding between a particular Posture Collector and Posture Validator pair is necessary. For example, a Posture Validator may wish to provide remediation instructions to a particular Posture Collector that it knows is capable of remediating a non-compliant component. This can be accomplished using the exclusive delivery PB-TNC capability to limit distribution of a message to a single Posture Collector by including the target Posture Collector Identifier in the PB-PA header. For more information on the PB-PA header, see section 4.5 of the PB-TNC specification.
ただし、この公開/購読モデルには、いくつかのマイナスの副作用があります。姿勢コレクターまたは姿勢検証装置が最初にPA-TNCメッセージを送信する場合、反対側からPA-TNCメッセージが多いかどうかはわかりません。多くのタイプの評価では、これは許容されますが、場合によっては、特定の姿勢コレクターと姿勢検証ターペアの間により直接的なチャネル結合が必要です。たとえば、姿勢バリーターは、非準拠コンポーネントを修復できることがわかっている特定の姿勢コレクターに修復指示を提供したい場合があります。これは、PB-PAヘッダーにターゲット姿勢コレクター識別子を含めることにより、排他的配信PB-TNC機能を使用して単一の姿勢コレクターへのメッセージの分布を制限することを実現できます。PB-PAヘッダーの詳細については、PB-TNC仕様のセクション4.5を参照してください。
This section summarizes the major elements of a PA-TNC message as they might appear inside of a PB-TNC message. The double line (===) in the diagram below indicates the separation between the PB-TNC and PA-TNC protocols. The PA-TNC portion of the message is delivered to each Posture Collector or Posture Validator registered to receive messages containing a particular message type. Note that PB-TNC is capable of carrying multiple PB-TNC and PA-TNC messages in a single PB-TNC batch. See the PB-TNC specification [5] for more information on its capabilities.
このセクションでは、PB-TNCメッセージの内部に表示される可能性のあるPA-TNCメッセージの主要な要素をまとめます。以下の図の二重線（===）は、PB-TNCとPA-TNCプロトコルの分離を示しています。メッセージのPA-TNC部分は、特定のメッセージタイプを含むメッセージを受信するために登録された各姿勢コレクターまたは姿勢バリデーターに配信されます。PB-TNCは、単一のPB-TNCバッチに複数のPB-TNCおよびPA-TNCメッセージを運ぶことができることに注意してください。その機能の詳細については、PB-TNC仕様[5]を参照してください。
One important linkage between the PA-TNC and PB-TNC protocols is the PA message type (PA Message Vendor ID and PA Subtype) that is used by the Posture Broker Client and Posture Broker Server to route messages to interested Posture Collectors and Posture Validators. The message type indicates the software component (component type) that is associated with the attributes included inside the PA-TNC message. Therefore, Posture Collectors and Posture Validators written to support an assessment of a particular component can register to receive messages about the component and thus participate in its assessment. Each Posture Collector and Posture Validator MUST only send PA-TNC messages containing attributes that pertain to the software component defined in the message type of the message. This ensures that only the appropriate Posture Collectors and Posture Validators that support a particular type of component will receive attributes related to that component. If a PA-TNC message contained a mix of attributes about different components and a message type of only one of those components, the message would only be delivered to parties interested in the component type included in the message type, so other interested recipients wouldn't see those attributes.
PA-TNCとPB-TNCプロトコルの間の重要なリンケージの1つは、Pasure BrokerクライアントとPossure Broker Serverが使用するPAメッセージタイプ（PAメッセージベンダーIDおよびPAサブタイプ）です。メッセージタイプは、PA-TNCメッセージ内に含まれる属性に関連付けられているソフトウェアコンポーネント（コンポーネントタイプ）を示します。したがって、特定のコンポーネントの評価をサポートするために書かれた姿勢コレクターと姿勢バリーターは、コンポーネントに関するメッセージを受信してその評価に参加できます。各姿勢コレクターと姿勢バリーターは、メッセージのメッセージタイプで定義されているソフトウェアコンポーネントに関連する属性を含むPA-TNCメッセージのみを送信する必要があります。これにより、特定のタイプのコンポーネントをサポートする適切な姿勢コレクターと姿勢バリエーターのみが、そのコンポーネントに関連する属性を受け取ることが保証されます。PA-TNCメッセージに、さまざまなコンポーネントに関する属性の組み合わせと、それらのコンポーネントの1つのみのメッセージタイプが含まれている場合、メッセージはメッセージタイプに含まれるコンポーネントタイプに関心のあるパーティーにのみ配信されるため、他の関心のある受信者はそうしません。tこれらの属性を参照してください。
The message type is composed of two fields: a PA Message Vendor ID and a PA Subtype. The PA Message Vendor ID identifies the vendor or other organization that defined this message type. The PA Subtype identifies the message type more specifically within the set of message types defined by that vendor. This specification defines several IETF Standard PA Subtypes to be used with a PA Message Vendor ID of zero (0). Within this specification, the PA Subtype field is used to indicate the type of component (e.g., firewall) involved with the message's attributes. Therefore, for clarity, the PA subtype will be referred to as the "component type" in this specification. Vendor-defined namespaces may use other semantics for the PA Subtype field as this is outside the scope of this specification.
メッセージタイプは、PAメッセージベンダーIDとPAサブタイプの2つのフィールドで構成されています。PAメッセージベンダーIDは、このメッセージタイプを定義したベンダーまたは他の組織を識別します。PAサブタイプは、そのベンダーによって定義されたメッセージタイプのセット内で、メッセージタイプをより具体的に識別します。この仕様では、ゼロ（0）のPAメッセージベンダーIDで使用するいくつかのIETF標準PAサブタイプを定義します。この仕様内では、PAサブタイプフィールドを使用して、メッセージの属性に関与するコンポーネントのタイプ（ファイアウォールなど）を示します。したがって、明確にするために、PAサブタイプは、この仕様の「コンポーネントタイプ」と呼ばれます。ベンダー定義の名前空間は、この仕様の範囲外であるため、PAサブタイプフィールドに他のセマンティクスを使用する場合があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message of type PB-PA-Message |
|(includes PA Message Vendor ID, PA Subtype, and other fields |
| used by Posture Broker Client and Posture Broker Server for |
| routing) |
===============================================================
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g., Product Information) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g., Operational Status) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Overview of a PB-TNC batch that contains a PA-TNC message
図1. PA-TNCメッセージを含むPB-TNCバッチの概要
For example, if a Posture Broker Client sent a PB-TNC batch that contained a PA-TNC message with a message type indicating firewall component, this message would be routed by the Posture Broker Server to Posture Validators registered to assess firewalls. Each registered Posture Validator would receive a copy of the PA-TNC message including the PA-TNC header and set of attributes. It is important that each of the attributes included in the PA-TNC message be associated with the firewall component because only the Posture Collector and Posture Validator interested in firewalls will receive such messages.
たとえば、姿勢ブローカーのクライアントがファイアウォールコンポーネントを示すメッセージタイプを含むPA-TNCメッセージを含むPB-TNCバッチを送信した場合、このメッセージは姿勢ブローカーサーバーによってルーティングされ、ファイアウォールを評価するために登録された姿勢バリエーターが登録されます。登録された各姿勢バリーターは、PA-TNCヘッダーと一連の属性を含むPA-TNCメッセージのコピーを受け取ります。PA-TNCメッセージに含まれる各属性をファイアウォールコンポーネントに関連付けることが重要です。なぜなら、ファイアウォールに関心のある姿勢コレクターと姿勢検証装置のみがそのようなメッセージを受信するからです。
If the above message contained both firewall and operating system attributes inside a PA-TNC message with a component type of firewall, then any Posture Collector and Posture Validator registered to receive operating system messages would not receive those attributes, as the messages would only be delivered to those registered for firewall messages.
上記のメッセージにファイアウォールとオペレーティングシステムの両方がコンポーネントタイプのファイアウォールを使用してPA-TNCメッセージ内に属性を含んでいた場合、メッセージが配信されるため、オペレーティングシステムメッセージを受信するために登録された姿勢コレクターと姿勢検証装置はそれらの属性を受信しません。ファイアウォールメッセージに登録されている人に。
The PB-PA header contains several fields important to the processing of a received PA message. The PA Vendor ID and Subtype are described in the PB-TNC specification and above in section 3.2. Also present in the PB-PA header is a pair of fields that identify the Posture Collector and/or Posture Validator involved in the exchange. These fields are used for performing exclusive delivery of messages as described in section 3.1 and as an indicator for correlation of received attributes.
PB-PAヘッダーには、受信したPAメッセージの処理に重要ないくつかのフィールドが含まれています。PAベンダーIDとサブタイプは、PB-TNC仕様および上記のセクション3.2で説明されています。また、PB-PAヘッダーに存在するのは、交換に関与する姿勢コレクターおよび/または姿勢バリーターを識別するフィールドのペアです。これらのフィールドは、セクション3.1で説明されているように、メッセージの排他的配信を実行するために使用され、受信属性の相関のインジケーターとして使用されます。
Correlation of attributes is necessary when the sending Posture Collector provides posture for multiple implementations of a single type of component during an assessment, so the recipient Posture Validators need to know which attributes are describing the same implementation.
送信姿勢コレクターが評価中に単一のタイプのコンポーネントの複数の実装に姿勢を提供する場合、属性の相関が必要であるため、受信者姿勢バリエーターは、同じ実装を記述している属性を知る必要があります。
For example, a single Posture Collector might report attributes on two installed VPN implementations on the endpoint. Because the individual attributes do not include an indication of which VPN product they are describing, the recipient needs something to perform this correlation. Therefore, for this example, the VPN Posture Collector would need to obtain two Posture Collector Identifiers from the Posture Broker Client and consistently use one with each of the implementations during an assessment. The VPN Posture Collector would group all the attributes associated with a particular VPN implementation into a single PB-PA message and send the message using the Posture Collector Identifier it designates as going with the particular implementation. This approach allows the recipient to recognize when attributes in future assessment messages also describe the same component implementation.
たとえば、単一の姿勢コレクターは、エンドポイントにインストールされている2つのVPN実装で属性を報告する場合があります。個々の属性には、説明しているVPN製品の表示は含まれていないため、受信者はこの相関を実行するために何かを必要とします。したがって、この例では、VPN姿勢コレクターは、姿勢ブローカークライアントから2つの姿勢コレクター識別子を取得し、評価中にそれぞれの実装で一貫して使用する必要があります。VPN Posture Collectorは、特定のVPN実装に関連付けられたすべての属性を単一のPB-PAメッセージにグループ化し、特定の実装を使用して指定するPositure Collector Identifierを使用してメッセージを送信します。このアプローチにより、受信者は、将来の評価メッセージの属性も同じコンポーネントの実装を記述するかを認識できます。
As depicted in section 3.2, a PA-TNC message consists of a PA-TNC header followed by a sequence of one or more attributes. The PA-TNC message header (described in section 3.6) and the header for each of the PA-TNC attributes (specified in section 4.1) have a fixed type-length-value (TLV) format. Each PA-TNC message MAY contain a mixture of standards-based and vendor-defined attributes identifiable using the type portion of the attribute header. All Posture Collectors and Posture Validators compliant with this specification MUST be capable of processing multiple attributes in a received PA-TNC message. A Posture Collector or Posture Validator that receives a PA-TNC message can use the attribute header's length field to skip any attributes that it does not understand, unless the attribute is marked as mandatory to process.
セクション3.2に示されているように、PA-TNCメッセージはPA-TNCヘッダーと1つ以上の属性のシーケンスで構成されています。PA-TNCメッセージヘッダー（セクション3.6で説明）と各PA-TNC属性のヘッダー（セクション4.1で指定）には、固定されたタイプ長値（TLV）形式があります。各PA-TNCメッセージには、属性ヘッダーの型部分を使用して識別可能な標準ベースとベンダー定義の属性の混合が含まれる場合があります。この仕様に準拠したすべての姿勢コレクターと姿勢バリデーターは、受信したPA-TNCメッセージで複数の属性を処理できる必要があります。PA-TNCメッセージを受信する姿勢コレクターまたは姿勢バリーターは、属性ヘッダーの長さフィールドを使用して、属性がプロセスに必須とマークされていない限り、理解していない属性をスキップできます。
This section defines several IETF Standard PA Subtypes. Each PA subtype defined here identifies a specific component relevant to the endpoint's posture. This allows a small set of generic PA-TNC attributes (e.g., Product Information) to be used to describe a large number of different components (e.g., operating system, anti-virus, etc.). It also allows Posture Collectors and Posture Validators to specialize in a particular component and only receive PA-TNC messages relevant to that component.
このセクションでは、いくつかのIETF標準PAサブタイプを定義します。ここで定義されている各PAサブタイプは、エンドポイントの姿勢に関連する特定のコンポーネントを識別します。これにより、少数の一般的なPA-TNC属性（製品情報など）を使用して、多数の異なるコンポーネント（オペレーティングシステム、アンチウイルスなど）を記述するために使用できます。また、姿勢コレクターと姿勢バリレーターが特定のコンポーネントに特化し、そのコンポーネントに関連するPA-TNCメッセージのみを受信することができます。
Value Integer Definition
----- ------- ----------
0 Testing Reserved for use in specification
examples, experimentation and
testing.
1 Operating System Operating system running on the endpoint
1エンドポイントで実行されているオペレーティングシステムオペレーティングシステム
2 Anti-Virus Host-based anti-virus software
2ウイルス対策ホストベースのウイルス対策ソフトウェア
3 Anti-Spyware Host-based anti-spyware software
3スパイウェアアンチスパイウェアベースのスパイウェアアンチスパイウェアソフトウェア
4 Anti-Malware Host-based anti-malware (e.g., anti-bot) software not included within anti-virus or anti-spyware components
4つのアンチマルウェアベースのアンチマルウェア（例：アリボット）ソフトウェアは、ウイルス対策またはスパイウェアコンポーネントに含まれていません
5 Firewall Host-based firewall
5ファイアウォールホストベースのファイアウォール
6 IDPS Host-based Intrusion Detection and/or Prevention Software (IDPS)
6 IDPSホストベースの侵入検知および/または予防ソフトウェア（IDP）
7 VPN Host-based Virtual Private Network (VPN) software
7 VPNホストベースの仮想プライベートネットワーク（VPN）ソフトウェア
8 NEA Client NEA client software
8 NEAクライアントNEAクライアントソフトウェア
These PA subtypes must be used in a PB-PA message with a PA Message Vendor ID of zero (0) indicating an IETF standard type of component (as described in the PB-TNC specification [5]). If these PA subtype values are used with a different PA Message Vendor ID, they have a completely different meaning that is not defined in this specification. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA subtypes and MUST interoperate with other parties despite any differences in the set of vendor-specific PA subtypes supported (although they MAY permit administrators to configure them to require support for specific PA subtypes).
これらのPAサブタイプは、ゼロ（0）のPAメッセージベンダーIDのPB-PAメッセージで、IETF標準タイプのコンポーネント（PB-TNC仕様[5]で説明されている）を示すPB-PAメッセージで使用する必要があります。これらのPAサブタイプの値が異なるPAメッセージベンダーIDで使用される場合、この仕様では定義されていないまったく異なる意味があります。姿勢コレクターと姿勢バリデーターは、特定のベンダー固有のPAサブタイプのサポートを必要としない必要があり、サポートされているベンダー固有のPAサブタイプのセットの違いにもかかわらず、他の関係者と相互運用する必要があります（ただし、管理者は特定のPAのサポートを必要とすることを許可する場合がありますがサブタイプ）。
This section describes the format and semantics of the PA-TNC header.
Every PA-TNC message MUST start with a PA-TNC header. The PA-TNC
header provides a common context applying to all of the attributes
contained within the PA-TNC payload. The payload consists of a
sequence of assessment attributes described in section 4.2.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
バージョン
This field indicates the version of the format for the PA-TNC message. This version is intended to allow for evolution of the PA-TNC message header and payload in a manner that can easily be detected by message recipients.
このフィールドは、PA-TNCメッセージの形式のバージョンを示します。このバージョンは、メッセージ受信者が簡単に検出できる方法でPA-TNCメッセージヘッダーとペイロードの進化を可能にすることを目的としています。
PA-TNC message senders MUST set this field to 0x01 for all PA-TNC messages that comply with this specification. Implementations responding to a PA-TNC message containing a supported version MUST use the same version number to minimize the risk of version incompatibility. Message recipients MUST respond to a PA-TNC message containing an unsupported version by sending a Version Not Supported error in a PA-TNC Error attribute that is the only PA-TNC attribute in a PA-TNC message with version number 1.
PA-TNCメッセージ送信者は、この仕様に準拠するすべてのPA-TNCメッセージに対して、このフィールドを0x01に設定する必要があります。サポートされているバージョンを含むPA-TNCメッセージに応答する実装は、同じバージョン番号を使用して、バージョンの非互換性のリスクを最小限に抑える必要があります。メッセージ受信者は、バージョン番号1のPA-TNCメッセージの唯一のPA-TNC属性であるPA-TNCエラー属性のサポートされていないエラーを送信することにより、サポートされていないバージョンを含むPA-TNCメッセージに応答する必要があります。
PA-TNC message initiators supporting multiple PA-TNC protocol versions SHOULD be able to alter which version of PA-TNC message they send based on prior message exchanges with a particular peer Posture Collector or Posture Validator.
複数のPA-TNCプロトコルバージョンをサポートするPA-TNCメッセージイニシエーターは、特定のピアポスチャーコレクターまたは姿勢検証装置との以前のメッセージ交換に基づいて送信するPA-TNCメッセージのバージョンを変更できるはずです。
Reserved
予約済み
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
将来の使用のために予約されています。このフィールドは、送信時に0に設定し、受信時に無視する必要があります。
Message Identifier
メッセージ識別子
This field contains a value that uniquely identifies this message, differentiating it from others sent by a particular PA-TNC message sender within this assessment. This value can be included in the payload of a response message to indicate which message was received and caused the response. This value is included in the payload of PA-TNC error messages so the party who receives the error message can determine which of the messages they had sent caused the error.
このフィールドには、このメッセージを一意に識別する値が含まれており、この評価内で特定のPA-TNCメッセージ送信者によって送信された他のメッセージと区別します。この値は、どのメッセージが受信され、応答が発生したかを示すために、応答メッセージのペイロードに含めることができます。この値は、PA-TNCエラーメッセージのペイロードに含まれるため、エラーメッセージを受信したパーティは、送信したメッセージのどれがエラーを引き起こしたかを決定できます。
PA-TNC message senders MUST NOT send the same message identifier more than once during an assessment. Message identifiers may be randomly generated or sequenced as long as values are not repeated during an assessment message exchange. PA-TNC message recipients are not required to check for duplicate message identifiers.
PA-TNCメッセージ送信者は、評価中に同じメッセージ識別子を複数回送信してはなりません。評価メッセージ交換中に値が繰り返されない限り、メッセージ識別子はランダムに生成またはシーケンスされる場合があります。PA-TNCメッセージ受信者は、複製メッセージ識別子を確認する必要はありません。
This section defines the PA-TNC attributes that can be carried within a PA-TNC message. The initial section defines the standard attribute header that appears at the start of each attribute in a PA-TNC message. The second section defines each of the IETF Standard PA-TNC Attributes and the final section discusses how vendor-defined PA-TNC attributes can be used within a PA-TNC message. Vendor-defined PA-TNC attributes use the vendor's SMI Private Enterprise Number in the Attribute Type field.
このセクションでは、PA-TNCメッセージ内で実行できるPA-TNC属性を定義します。初期セクションでは、PA-TNCメッセージの各属性の開始時に表示される標準属性ヘッダーを定義します。2番目のセクションでは、IETF標準PA-TNC属性のそれぞれを定義し、最後のセクションでは、ベンダー定義のPA-TNC属性をPA-TNCメッセージ内でどのように使用できるかについて説明します。ベンダー定義のPA-TNC属性属性タイプフィールドでベンダーのSMIプライベートエンタープライズ番号を使用します。
A PA-TNC message MUST contain a PA-TNC header (defined in section 3.6. followed by a sequence of zero or more PA-TNC attributes. All PA-TNC attributes MUST begin with a standard PA-TNC attribute header, as defined in section 4.1. The contents of PA-TNC attributes vary widely, depending on their attribute type. Section 4.2 defines the IETF Standard PA-TNC Attributes. Section 4.3 discusses how vendor-specific PA-TNC attributes can be defined.
PA-TNCメッセージには、PA-TNCヘッダー（セクション3.6で定義されています。その後のゼロ以上のPA-TNC属性のシーケンスが含まれている必要があります。セクション4.1。PA-TNC属性の内容は、属性タイプによって大きく異なります。セクション4.2は、IETF標準PA-TNC属性を定義します。セクション4.3では、ベンダー固有のPA-TNC属性を定義する方法について説明します。
Following the PA-TNC message header is a sequence of zero or more attributes. All PA-TNC attributes MUST begin with the standard PA-TNC attribute header defined in this subsection. Each attribute described in this specification is represented by a TLV tuple. The TLV tuple includes an attribute identifier comprised of the Vendor ID and Attribute Type (type), the TLV tuple's overall length, and finally the attribute's value. The use of TLV representation was chosen due to its flexibility and extensibility and use in other standards. Recipients of an attribute can use the attribute type fields to determine the precise syntax and semantics of the attribute value field and the length to skip over an unrecognized attribute. The length field is also beneficial when a variable-length attribute value is provided.
PA-TNCメッセージヘッダーに従うことは、ゼロ以上の属性のシーケンスです。すべてのPA-TNC属性は、このサブセクションで定義されている標準のPA-TNC属性ヘッダーから開始する必要があります。この仕様で説明されている各属性は、TLVタプルで表されます。TLVタプルには、ベンダーIDおよび属性タイプ（タイプ）、TLVタプルの全長、最後に属性の値で構成される属性識別子が含まれます。TLV表現の使用は、その柔軟性と拡張性と他の基準での使用により選択されました。属性の受信者は、属性タイプフィールドを使用して、属性値フィールドの正確な構文とセマンティクス、および認識されていない属性をスキップする長さを決定できます。長さのフィールドは、可変長属性値が提供される場合にも有益です。
The TLV format does not contain an explicit TLV format version number, so every attribute included in a particular PA-TNC message MUST use the same TLV format. Using the PA-TNC message version number to indicate the format of all TLV attributes within a PA-TNC message allows for future versioning of the TLV format in a manner detectable by PA-TNC message recipients. Similarly, requiring all TLV attribute formats to be the same within a PA-TNC message also ensures that recipients compliant with a particular PA-TNC message version can at least parse every attribute header and use the length to skip over unrecognized attributes. Finally, all attribute TLVs within a PA-TNC message MUST pertain to the same implementation of the component. This restriction is relevant when a single Posture Collector is reporting on multiple implementations of a component, so must send multiple PA-TNC messages each including only the attributes describing a single implementation. For more information on how Posture Collectors should handle multiple implementations, see section 3.3.
TLV形式には明示的なTLV形式バージョン番号が含まれていないため、特定のPA-TNCメッセージに含まれるすべての属性は同じTLV形式を使用する必要があります。PA-TNCメッセージバージョン番号を使用して、PA-TNCメッセージ内のすべてのTLV属性の形式を示し、PA-TNCメッセージ受信者が検出可能な方法でTLV形式の将来のバージョンを可能にします。同様に、すべてのTLV属性形式がPA-TNCメッセージ内で同じであることを要求すると、特定のPA-TNCメッセージバージョンに準拠した受信者が少なくともすべての属性ヘッダーを解析し、長さを使用して認識されていない属性をスキップできることも保証します。最後に、PA-TNCメッセージ内のすべての属性TLVは、コンポーネントの同じ実装に関係する必要があります。この制限は、単一の姿勢コレクターがコンポーネントの複数の実装について報告している場合に関連するため、単一の実装を記述する属性のみを含む複数のPA-TNCメッセージをそれぞれ送信する必要があります。姿勢コレクターが複数の実装を処理する方法の詳細については、セクション3.3を参照してください。
Every PA-TNC-compliant TLV attribute MUST use the following TLV
format:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
フラグ
This field defines flags impacting the processing of the associated attribute.
このフィールドは、関連する属性の処理に影響を与えるフラグを定義します。
Bit 0 (0x80) is the NOSKIP flag. Any Posture Collector or Posture Validator that receives an attribute with this flag set to 1 but does not support this attribute MUST NOT process any part of the PA-TNC message and SHOULD respond with an Attribute Type Not Supported error in a PA-TNC error message.
ビット0（0x80）はノスキップフラグです。このフラグが1に設定されているがこの属性をサポートしていない属性を受信する姿勢コレクターまたは姿勢バリデーターは、PA-TNCメッセージの一部を処理してはならず、PA-TNCエラーメッセージでサポートされていないエラーのない属性タイプで応答する必要があります。
In order to avoid taking action on a subset of the attributes only to later find an unsupported attribute with the NOSKIP flag set, recipients of a multi-attribute PA-TNC message might need to scan all of the attributes prior to acting upon any attribute.
属性のサブセットでのアクションを避けるためには、NosKipフラグセットでサポートされていない属性を後で見つけるためだけに、マルチアトリビングPA-TNCメッセージの受信者は、属性に作用する前にすべての属性をスキャンする必要がある場合があります。
When the NOSKIP flag is set to 0, recipients SHOULD skip any unsupported attributes and continue processing the next attribute.
Noskipフラグが0に設定されている場合、受信者はサポートされていない属性をスキップし、次の属性の処理を続ける必要があります。
Bit 1-7 are reserved for future use. These bits MUST be set to 0 on transmission and ignored upon reception.
ビット1-7は、将来の使用のために予約されています。これらのビットは、送信時に0に設定し、受信時に無視する必要があります。
PA-TNC Attribute Vendor ID
PA-TNC属性ベンダーID
This field indicates the owner of the namespace associated with the PA-TNC Attribute Type. This is accomplished by specifying the 24-bit SMI Private Enterprise Number Vendor ID of the party who owns the Attribute Type namespace. IETF Standard PA-TNC Attribute Types MUST use zero (0) in this field.
このフィールドは、PA-TNC属性タイプに関連付けられた名前空間の所有者を示しています。これは、属性タイプの名前空間を所有する当事者の24ビットSMIプライベートエンタープライズ番号ベンダーIDを指定することによって達成されます。IETF標準PA-TNC属性タイプは、このフィールドでゼロ（0）を使用する必要があります。
The PA-TNC Attribute Vendor ID 0xffffff is reserved. Posture Collectors and Posture Validators MUST NOT send PA-TNC messages in which the PA-TNC Attribute Vendor ID has this reserved value (0xffffff). If a Posture Collector or Posture Validator receives a message in which the PA-TNC Attribute Vendor ID has this reserved value (0xffffff), it SHOULD respond with an Invalid Parameter error code in a PA-TNC Error attribute.
PA-TNC属性ベンダーID 0xffffffは予約されています。Posure CollectorsおよびPossure Validatorsは、PA-TNC属性ベンダーIDにこの予約値（0xFFFFFF）があるPA-TNCメッセージを送信してはなりません。姿勢コレクターまたは姿勢バリーターが、PA-TNC属性ベンダーIDにこの予約値（0xFFFFFF）があるメッセージを受信する場合、PA-TNCエラー属性の無効なパラメーターエラーコードで応答する必要があります。
PA-TNC Attribute Type
PA-TNC属性タイプ
This field defines the type of the attribute included in the Attribute Value field. This field is qualified by the PA-TNC Attribute Vendor ID field so that a particular PA-TNC Attribute Type value (e.g., 327) has a completely different meaning depending on the value in the PA-TNC Attribute Vendor ID field. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Attribute Types and MUST interoperate with other parties despite any differences in the set of vendor-specific PA-TNC Attribute Types supported (although they MAY permit administrators to configure them to require support for specific PA-TNC attribute types).
このフィールドは、属性値フィールドに含まれる属性のタイプを定義します。このフィールドは、PA-TNC属性ベンダーIDフィールドによって適格であるため、特定のPA-TNC属性値（327）は、PA-TNC属性ベンダーIDフィールドの値に応じてまったく異なる意味を持ちます。姿勢コレクターと姿勢バリデーターは、特定のベンダー固有のPA-TNC属性タイプのサポートを必要としてはならず、ベンダー固有のPA-TNC属性タイプのセットがサポートされるにもかかわらず、他の関係者と相互運用する必要があります（管理者はそれらを構成することができますが特定のPA-TNC属性タイプのサポートが必要です）。
If the PA-TNC Attribute Vendor ID field has the value zero (0), then the PA-TNC Attribute Type field contains an IETF Standard PA-TNC Attribute Type, as listed in the IANA registry. IANA maintains a registry of PA-TNC Attribute Types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 7. Section 4.2 of this specification defines the initial set of IETF Standard PA-TNC Attribute Types.
PA-TNC属性ベンダーIDフィールドに値ゼロ（0）がある場合、PA-TNC属性タイプフィールドには、IANAレジストリにリストされているIETF標準PA-TNC属性タイプが含まれます。IANAは、PA-TNC属性タイプのレジストリを維持しています。このレジストリのエントリは、この仕様のセクション7のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。この仕様のセクション4.2は、IETF標準PA-TNC属性タイプの初期セットを定義します。
The PA-TNC Attribute Type 0xffffffff is reserved. Posture Collectors and Posture Validators MUST NOT send PA-TNC messages in which the PA-TNC Attribute Type has this reserved value (0xffffffff). If a Posture Collector or Posture Validator receives a message in which the PA-TNC Attribute Type has this reserved value (0xffffffff), it SHOULD respond with an Invalid Parameter error code in a PA-TNC Error attribute.
PA-TNC属性タイプ0xffffffffは予約されています。Posure CollectorsおよびPossure Validatorは、PA-TNC属性タイプにこの予約値（0xFFFFFFFF）のPA-TNCメッセージを送信してはなりません。姿勢コレクターまたは姿勢検証装置が、PA-TNC属性タイプにこの予約値（0xFFFFFFFF）があるメッセージを受信する場合、PA-TNCエラー属性の無効なパラメーターエラーコードで応答する必要があります。
PA-TNC Attribute Length
PA-TNC属性の長さ
This field contains the length in octets of the entire PA-TNC attribute including the PA-TNC Attribute Header (the fields Flags, PA-TNC Attribute Vendor ID, PA-TNC Attribute Type, and PA-TNC Attribute Length). Therefore, this value MUST always be at least 12. Any Posture Collector or Posture Validator that receives a message with a PA-TNC Attribute Length field whose value is less than 12 SHOULD respond with an Invalid Parameter PA-TNC error code. Similarly, if a Posture Collector or Posture Validator receives a PA-TNC message for an Attribute Type that has a well-known Attribute Value length (e.g., fixed-length attribute value) and the Attribute Length indicates a different value (greater or less than the expected value), the recipient SHOULD respond with an Invalid Parameter PA-TNC error code.
このフィールドには、PA-TNC属性ヘッダー（PA-TNC属性ベンダーID、PA-TNC属性タイプ、PA-TNC属性の長さ）を含むPA-TNC属性全体のオクテットの長さが含まれています。したがって、この値は常に少なくとも12でなければなりません。値が12未満のPA-TNC属性の長さフィールドを使用してメッセージを受信する姿勢コレクターまたは姿勢検証装置は、無効なパラメーターPA-TNCエラーコードで応答する必要があります。同様に、姿勢コレクターまたは姿勢検証装置が、よく知られている属性値の長さを持つ属性タイプのPA-TNCメッセージを受信し、属性の長さは異なる値を示します（期待値）、受信者は、無効なパラメーターPA-TNCエラーコードで応答する必要があります。
Implementations that do not support the specified PA-TNC Attribute Type can use this length to skip over this attribute to the next attribute. Note that while this field is 4 octets the maximum usable attribute length is less than 2^32-1 due to limitations of the underlying protocol stack. Specifically, PB-TNC TLV header's Batch Length field is also 32 bits in length. Therefore, the maximum batch that PB-TNC can carry is 2^32-1, so the largest PA-TNC message carried by PB-TNC must be less than 2^32-1 - size of the PB-TNC header (see section 4.1 of PB-TNC for more details).
指定されたPA-TNC属性タイプをサポートしていない実装は、この属性を次の属性にスキップするためにこの長さを使用できます。このフィールドは4オクテットですが、基礎となるプロトコルスタックの制限により、最大使用可能な属性の長さは2^32-1未満であることに注意してください。具体的には、PB-TNC TLVヘッダーのバッチ長さフィールドの長さは32ビットです。したがって、PB-TNCが運ぶことができる最大バッチは2^32-1であるため、PB-TNCによって運ばれる最大のPA-TNCメッセージは2^32-1未満でなければなりません - PB-TNCヘッダーのサイズ（セクションを参照詳細については、PB-TNCの4.1）。
Attribute Value
属性値
This field varies depending on the particular type of attribute being expressed. The contents of this field for each of the IETF Standard PA-TNC Attribute Types are defined in section 4.2.
このフィールドは、表現される特定のタイプの属性によって異なります。各IETF標準PA-TNC属性タイプの各フィールドの内容は、セクション4.2で定義されています。
This section defines an initial set of IETF Standard PA-TNC Attribute Types. These Attribute Types MUST always be used with a PA-TNC Vendor ID of zero (0). If these PA-TNC Attribute Type values are used with a different PA-TNC Vendor ID, they have a completely different meaning that is not defined in this specification.
このセクションでは、IETF標準PA-TNC属性タイプの初期セットを定義します。これらの属性タイプは、ゼロ（0）のPA-TNCベンダーIDで常に使用する必要があります。これらのPA-TNC属性タイプの値が異なるPA-TNCベンダーIDで使用される場合、この仕様では定義されていない完全に異なる意味があります。
The following table briefly describes each attribute and defines the numeric value to be used in the PA-TNC Attribute Type field of the PA-TNC Attribute Header. Later subsections provide detailed specifications for each PA-TNC Attribute Value.
次の表は、各属性を簡単に説明し、PA-TNC属性ヘッダーのPA-TNC属性タイプフィールドで使用する数値を定義します。後のサブセクションは、各PA-TNC属性値の詳細な仕様を提供します。
Number Integer Description
------ ------- -----------
0 Testing Reserved for use in
specification examples,
experimentation, and testing.
1 Attribute Request Contains a list of attribute type values defining the attributes desired from the Posture Collectors.
1属性要求には、姿勢コレクターから必要な属性を定義する属性タイプ値のリストが含まれています。
2 Product Information Manufacturer and product information for the component.
2コンポーネントの製品情報メーカーと製品情報。
3 Numeric Version Numeric version of the component.
3コンポーネントの数値バージョン数値バージョン。
4 String Version String version of the component.
コンポーネントの4文字列バージョン文字列バージョン。
5 Operational Status Describes whether the component is running on the endpoint.
5操作ステータスは、コンポーネントがエンドポイントで実行されているかどうかを説明します。
6 Port Filter Lists the set of ports (e.g., TCP port 80 for HTTP) that are allowed or blocked on the endpoint.
6ポートフィルターには、エンドポイントで許可またはブロックされているポートのセット（HTTPのTCPポート80など）がリストされています。
7 Installed Packages List of software packages installed on endpoint that provide the requested component.
7インストールされたパッケージ要求されたコンポーネントを提供するエンドポイントにインストールされたソフトウェアパッケージのリスト。
8 PA-TNC Error PA-TNC message or attribute processing error.
8 PA-TNCエラーPA-TNCメッセージまたは属性処理エラー。
9 Assessment Result Result of the assessment performed by a Posture Validator.
9評価姿勢バリーターによって実行された評価の結果結果。
10 Remediation Instructions Instructions for remediation generated by a Posture Validator.
10姿勢検証装置によって生成された修復のための修復指示指示。
11 Forwarding Enabled Indicates whether packet forwarding has been enabled between different interfaces on the endpoint.
11転送が有効になっていることは、エンドポイント上の異なるインターフェイス間でパケット転送が有効になっているかどうかを示します。
12 Factory Default Password Indicates whether the endpoint Enabled has a factory default password enabled.
12工場出荷時のデフォルトパスワードエンドポイントの有効化にファクトリーのデフォルトパスワードが有効になっているかどうかを示します。
The following subsections discuss the usage, format, and semantics of the Attribute Value field for each IETF Standard PA-TNC Attribute Type.
次のサブセクションでは、各IETF標準PA-TNC属性タイプの属性値フィールドの使用、形式、およびセマンティクスについて説明します。
This PA-TNC Attribute Type allows a Posture Validator to request certain attributes from the registered set of Posture Collectors.
このPA-TNC属性タイプにより、Posure Validatorは登録された姿勢コレクターのセットから特定の属性を要求できます。
All Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this specification SHOULD support receiving and processing this attribute type for at least those PA subtypes. This requirement is only a "should" because there are deployment scenarios (e.g., see section A.1) where the Posture Collectors proactively send a set of attributes at the start of an assessment (e.g., based upon local policy), so does not need to support Posture Validator requested attributes. Posture Collectors that receive but do not support the Attribute Request attribute MUST respond with an Attribute Type Not Supported PA-TNC error code. Posture Collectors that receive and process this attribute MAY choose to send all, a subset, or none of the requested attributes but MUST NOT send attributes that were not requested (except Error attributes). All Posture Validators that implement any of the IETF Standard PA Subtypes defined in this specification SHOULD support sending this attribute type for at least those PA subtypes.
この仕様で定義されているIETF標準PAサブタイプのいずれかを実装するすべての姿勢コレクターは、少なくともこれらのPAサブタイプのこの属性タイプの受信と処理をサポートする必要があります。この要件は、姿勢のシナリオ（セクションA.1を参照）があるため、「必要な」のみです。Posure Validator要求された属性をサポートする必要があります。属性要求属性を受け取るがサポートしていない姿勢コレクターは、サポートされていないPA-TNCエラーコードではない属性タイプで応答する必要があります。この属性を受け取って処理する姿勢コレクターは、すべて、サブセット、または要求された属性を送信することを選択できますが、要求されていない属性を送信してはなりません（エラー属性を除く）。この仕様で定義されているIETF標準PAサブタイプのいずれかを実装するすべての姿勢バリエーターは、少なくともこれらのPAサブタイプのこの属性タイプの送信をサポートする必要があります。
Posture Validators MUST NOT include this attribute type in an Attribute Request attribute. It does not make sense for a Posture Validator to request that a Posture Collector send an Attribute Request attribute.
Posture Validatorsは、この属性タイプを属性要求属性に含めてはなりません。Positure Validatorが姿勢コレクターが属性要求属性を送信するように要求することは意味がありません。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 1.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドをゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドを1に設定する必要があります。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
Note that this diagram shows two attribute types. The actual number of attribute types included in an Attribute Request attribute can vary from one to a large number (limited only by the maximum message and length supported by the underlying PT protocol). However, each Attribute Request MUST contain at least one attribute type. Because the length of a PA-TNC Attribute Vendor ID paired with a PA-TNC Attribute Type and a 1-octet Reserved field is always 8 octets, the number of requested attributes can be easily computed using the PA-TNC Attribute Length field by subtracting the number of octets in the PA-TNC Attribute Header and dividing by 8. If the PA-TNC Attribute Length field is invalid, Posture Collectors SHOULD respond with an Invalid Parameter PA-TNC error code.
この図は、2つの属性タイプを示していることに注意してください。属性要求属性に含まれる属性タイプの実際の数は、1つまで異なります（基礎となるPTプロトコルによってサポートされる最大メッセージと長さによってのみ制限されます）。ただし、各属性要求には、少なくとも1つの属性タイプを含める必要があります。PA-TNC属性タイプと1-OCTET予約フィールドとペアになったPA-TNC属性ベンダーIDの長さは常に8オクテットであるため、要求された属性の数は、PA-TNC属性の長さフィールドを使用して簡単に計算できます。PA-TNC属性ヘッダーのオクテットの数と8で割る。PA-TNC属性の長さフィールドが無効である場合、姿勢コレクターは無効なパラメーターPA-TNCエラーコードで応答する必要があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約済み
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
将来の使用のために予約されています。このフィールドは、送信時に0に設定し、受信時に無視する必要があります。
PA-TNC Attribute Vendor ID
PA-TNC属性ベンダーID
This field contains the SMI Private Enterprise Number of the organization that controls the namespace for the following PA-TNC Attribute Type. This field enables IETF Standard PA-TNC Attributes and vendor-defined PA-TNC attributes to be used without potential collisions.
このフィールドには、次のPA-TNC属性タイプの名前空間を制御する組織のSMIプライベートエンタープライズ番号が含まれています。このフィールドは、IETF標準PA-TNC属性とベンダー定義のPA-TNC属性を潜在的な衝突なしに使用できるようにします。
Any IETF Standard PA-TNC Attribute Types defined in section 4.2 MUST use zero (0) in this field. Vendor-defined attributes MUST use the SMI Private Enterprise Number of the organization that defined the attribute.
セクション4.2で定義されているIETF標準PA-TNC属性タイプは、このフィールドでゼロ（0）を使用する必要があります。ベンダー定義の属性は、属性を定義した組織のSMIプライベートエンタープライズ番号を使用する必要があります。
PA-TNC Attribute Type
PA-TNC属性タイプ
The PA-TNC Attribute Type field (together with the PA-TNC Vendor ID field) indicates the specific attribute requested. Some IETF Standard PA-TNC Attribute Types MUST NOT be requested using this field (e.g., requesting a PA-TNC Error attribute). This is explicitly indicated in the description of those PA-TNC Attribute Types. Any Posture Collector or Posture Validator that receives an Attribute Request containing one of the prohibited Attribute Types SHOULD respond with an Invalid Parameter error in a PA-TNC error message.
PA-TNC属性タイプフィールド（PA-TNCベンダーIDフィールドとともに）は、要求された特定の属性を示します。一部のIETF標準PA-TNC属性タイプは、このフィールドを使用して要求してはなりません（たとえば、PA-TNCエラー属性の要求）。これは、これらのPA-TNC属性タイプの説明で明示的に示されています。禁止された属性タイプのいずれかを含む属性要求を受信する姿勢コレクターまたは姿勢バリーターは、PA-TNCエラーメッセージに無効なパラメーターエラーで応答する必要があります。
This PA-TNC Attribute Type contains identifying information about a product that implements the component specified in the PA Subtype field, as described in section 3.5. For example, if the PA Subtype is Anti-Virus, this attribute would contain information identifying an anti-virus product installed on the endpoint.
このPA-TNC属性タイプには、セクション3.5で説明されているように、PAサブタイプフィールドで指定されたコンポーネントを実装する製品に関する識別情報が含まれています。たとえば、PAサブタイプがウイルス対策である場合、この属性には、エンドポイントにインストールされたウイルス対策製品を識別する情報が含まれます。
All Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this specification MUST support sending this attribute type, at least for those PA subtypes. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. All Posture Validators that implement any of the IETF Standard PA Subtypes defined in this specification MUST support receiving this attribute type, at least for those PA subtypes. Posture Validators MUST NOT send this attribute type.
この仕様で定義されているIETF標準PAサブタイプのいずれかを実装するすべての姿勢コレクターは、少なくともこれらのPAサブタイプについて、この属性タイプの送信をサポートする必要があります。特定の姿勢コレクターが実際にこの属性タイプを送信するかどうかは、現地のプライバシーとセキュリティポリシーによって依然として管理されるべきです。この仕様で定義されているIETF標準PAサブタイプのいずれかを実装するすべての姿勢バリエーターは、少なくともこれらのPAサブタイプに対して、この属性タイプの受信をサポートする必要があります。姿勢バリデーターは、この属性タイプを送信してはなりません。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 2. The value in the PA-TNC Attribute Length field will vary, depending on the length of the Product Name field. However, the value in the PA-TNC Attribute Length field MUST be at least 17 because this is the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute type. If the PA-TNC Attribute Length field is less than the size of these fixed-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドはゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドは2に設定する必要があります。製品名フィールドの長さ。ただし、PA-TNC属性の長さフィールドの値は、PA-TNC属性ヘッダーの固定長フィールドとこの属性タイプの固定長フィールドの長さであるため、少なくとも17でなければなりません。PA-TNC属性の長さフィールドがこれらの固定長フィールドのサイズよりも少ない場合、実装は無効なパラメーターPA-TNCエラーコードで応答する必要があります。
This attribute type includes both numeric and textual identifiers for the organization that created the product (the "product creator") and for the product itself. For automated processing, numeric identifiers are superior because they are less ambiguous and more efficient. However, numeric identifiers are only available if the product creator has assigned them. Therefore, a textual identifier is also included. This textual identifier has the additional benefit that it may be easier for humans to read (although this benefit is minimal since the primary purpose of this attribute is automated assessment).
この属性タイプには、製品（「製品作成者」）と製品自体を作成した組織の数値とテキストの両方の識別子が含まれます。自動処理の場合、数値識別子はあいまいで効率的であるため、優れています。ただし、数値識別子は、製品作成者がそれらを割り当てた場合にのみ使用できます。したがって、テキスト識別子も含まれています。このテキスト識別子には、人間が読みやすいかもしれないという追加の利点があります（ただし、この属性の主な目的は自動評価であるため、この利点は最小限です）。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product Vendor ID | Product ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product ID | Product Name (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Product Vendor ID
製品ベンダーID
This field contains the SMI Private Enterprise Number for the product creator. If the SMI PEN for the product creator is unknown or if the product creator does not have an SMI PEN, the Product Vendor ID field MUST be set to 0 and the identity of the product creator SHOULD be included in the Product Name along with the name of the product.
このフィールドには、製品作成者向けのSMIプライベートエンタープライズ番号が含まれています。製品作成者のSMIペンが不明の場合、または製品作成者にSMIペンがない場合、製品ベンダーIDフィールドを0に設定する必要があり、製品作成者のIDを名前とともに製品名に含める必要があります。製品の。
Product ID
製品番号
This field identifies the product using a numeric identifier assigned by the product creator. If this Product ID value is unknown or if the product creator has not assigned such a value, this field MUST be set to 0. If the Product Vendor ID is 0, this field MUST be set to 0. In any case, the name of the product SHOULD be included in the Product Name field.
このフィールドは、製品作成者によって割り当てられた数値識別子を使用して製品を識別します。この製品ID値が不明の場合、または製品作成者がそのような値を割り当てていない場合、このフィールドは0に設定する必要があります。製品ベンダーIDが0の場合、このフィールドは0に設定する必要があります。製品は、製品名フィールドに含める必要があります。
Note that a particular Product ID value (e.g., 635) will have completely different meanings depending on the Product Vendor ID. Each Product Vendor ID defines a different space of Product ID values. Product creators are encouraged to publish lists of Product ID values for their products.
特定の製品ID値（例：635）は、製品ベンダーIDに応じてまったく異なる意味を持つことに注意してください。各製品ベンダーIDは、製品ID値の異なるスペースを定義します。製品クリエーターは、製品の製品ID値のリストを公開することをお勧めします。
Product Name
商品名
This variable-length field contains a UTF-8 [2] string identifying the product (e.g., "Symantec Norton AntiVirus(TM) 2008") in enough detail to unambiguously distinguish it from other products from the product creator. Products whose creator is known, but does not have a registered SMI Private Enterprise Number, SHOULD be represented using a combination of the creator name and full product name (e.g., "Ubuntu(R) IPtables" for the IPtables firewall in the Ubuntu distribution of Linux). If the product creator's SMI Private Enterprise Number is included in the Product Vendor ID field, the product creator's name may be omitted from this field.
この可変長さフィールドには、製品を識別するUTF-8 [2]文字列が含まれています（たとえば、「Symantec Norton Antivirus（TM）2008」）。作成者が知られているが、登録されたSMIプライベートエンタープライズ番号を持っていない製品は、作成者名と完全な製品名の組み合わせを使用して表現する必要があります（例：Ubuntuの分布のiPtablesファイアウォールの「ubuntu（r）iptables」Linux）。製品作成者のSMIプライベートエンタープライズ番号が製品ベンダーIDフィールドに含まれている場合、製品作成者の名前はこのフィールドから省略できます。
The length of this field can be determined by starting with the value in the PA-TNC Attribute Length field in the PA-TNC Attribute Header and subtracting the size of the fixed-length fields in that header (12) and the size of the fixed-length fields in this attribute (5). If the PA-TNC Attribute Length field is less than the size of these fixed-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
このフィールドの長さは、PA-TNC属性ヘッダーのPA-TNC属性長フィールドの値から開始し、そのヘッダー（12）の固定長フィールドのサイズと固定のサイズを差し引くことで決定できます。 - この属性（5）の長さのフィールド。PA-TNC属性の長さフィールドがこれらの固定長フィールドのサイズよりも少ない場合、実装は無効なパラメーターPA-TNCエラーコードで応答する必要があります。
This PA-TNC Attribute Type contains numeric version information for a product on the endpoint that implements the component specified in the PA Subtype field, as described in section 3.5. For example, if the PA Subtype is Operating System, this attribute would contain numeric version information for the operating system installed on the endpoint. The version information in this attribute is associated with a particular product, so Posture Validators are expected to also possess the corresponding Product Information attribute when interpreting this attribute.
このPA-TNC属性タイプには、セクション3.5で説明されているように、PAサブタイプフィールドで指定されたコンポーネントを実装するエンドポイント上の製品の数値バージョン情報が含まれています。たとえば、PAサブタイプがオペレーティングシステムの場合、この属性には、エンドポイントにインストールされているオペレーティングシステムの数値バージョン情報が含まれます。この属性のバージョン情報は特定の製品に関連付けられているため、姿勢バリレーターは、この属性を解釈する際に対応する製品情報属性も所有することが期待されます。
All Posture Collectors that implement the IETF Standard PA Subtype for Operating System SHOULD support sending this attribute type, at least for the Operating System PA subtype. Other Posture Collectors MAY support sending this attribute type. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. All Posture Validators that implement the IETF Standard PA Subtype for Operating System SHOULD support receiving this attribute type, at least for the Operating System PA subtype. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
オペレーティングシステムにIETF標準PAサブタイプを実装するすべての姿勢コレクターは、少なくともオペレーティングシステムのPAサブタイプでは、この属性タイプの送信をサポートする必要があります。他の姿勢コレクターは、この属性タイプの送信をサポートする場合があります。特定の姿勢コレクターが実際にこの属性タイプを送信するかどうかは、現地のプライバシーとセキュリティポリシーによって依然として管理されるべきです。オペレーティングシステムにIETF標準PAサブタイプを実装するすべての姿勢バリエーターは、少なくともオペレーティングシステムのPAサブタイプで、この属性タイプの受信をサポートする必要があります。他の姿勢バリエーターは、この属性タイプの受信をサポートする場合があります。この属性タイプの受信をサポートしていないPosure Validatorは、このタイプで属性を単純に無視する必要があります。姿勢バリデーターは、この属性タイプを送信してはなりません。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 3. The value in the PA-TNC Attribute Length field MUST be 28. If the PA-TNC Attribute Length field is less than the size of these fixed-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドはゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドは3に設定する必要があります。PA-TNC属性の長さフィールドは、これらの固定長フィールドのサイズよりも小さいため、実装は無効なパラメーターPA-TNCエラーコードで応答する必要があります。
This attribute type includes numeric values for the product version information, enabling Posture Validators to do comparative operations on the version. Some Posture Collectors may not be able to determine some or all of this information for a product. However, this attribute can be especially useful for describing the version of the operating system, where numeric version numbers are generally available.
この属性タイプには、製品バージョン情報の数値値が含まれており、姿勢バリーターがバージョンで比較操作を行うことができます。一部の姿勢コレクターは、製品のこの情報の一部またはすべてを決定できない場合があります。ただし、この属性は、数値バージョン番号が一般的に利用可能なオペレーティングシステムのバージョンを説明するのに特に役立ちます。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Major Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minor Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Pack Major | Service Pack Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Major Version Number
メジャーバージョン番号
This field contains the major version number for the product, if applicable. If unused or unknown, this field SHOULD be set to 0.
このフィールドには、該当する場合、製品のメジャーバージョン番号が含まれています。未使用または不明の場合、このフィールドは0に設定する必要があります。
Minor Version Number
マイナーバージョン番号
This field contains the minor version number for the product, if applicable. If unused or unknown, this field SHOULD be set to 0.
このフィールドには、該当する場合、製品のマイナーバージョン番号が含まれています。未使用または不明の場合、このフィールドは0に設定する必要があります。
Build Number
ビルド番号
This field contains the build number for the product, if applicable. This may provide more granularity than the minor version number, as many builds may occur leading up to an official release, and all these builds may share a single major and minor version number. If unused or unknown, this field SHOULD be set to 0.
このフィールドには、該当する場合、製品のビルド番号が含まれています。これは、マイナーバージョン数よりも多くの粒度を提供する可能性があります。これは、公式リリースに至るまで多くのビルドが発生する可能性があり、これらのビルドはすべて、単一の主要なバージョン数とマイナーバージョン番号を共有する可能性があります。未使用または不明の場合、このフィールドは0に設定する必要があります。
Service Pack Major
サービスパックメジャー
This field contains the major version number of the service pack for the product, if applicable. If unused or unknown, this field SHOULD be set to 0.
このフィールドには、該当する場合、製品のサービスパックのメジャーバージョン番号が含まれています。未使用または不明の場合、このフィールドは0に設定する必要があります。
Service Pack Minor
サービスパックマイナー
This field contains the minor version number of the service pack for the product, if applicable. If unused or unknown, this field SHOULD be set to 0.
このフィールドには、該当する場合、製品のサービスパックのマイナーバージョン番号が含まれています。未使用または不明の場合、このフィールドは0に設定する必要があります。
This PA-TNC Attribute Type contains string version information for a product on the endpoint that implements the component specified in the PA Subtype field, as described in section 3.5. For example, if the PA Subtype is Firewall, this attribute would contain string version information for a host-based firewall product installed on the endpoint (if any). The version information in this attribute is associated with a particular product, so Posture Validators are expected to also possess the corresponding Product Information attribute when interpreting this attribute.
このPA-TNC属性タイプには、セクション3.5で説明されているように、PAサブタイプフィールドで指定されたコンポーネントを実装するエンドポイント上の製品の文字列バージョン情報が含まれています。たとえば、PAサブタイプがファイアウォールの場合、この属性には、エンドポイントにインストールされているホストベースのファイアウォール製品の文字列バージョン情報が含まれます（存在する場合）。この属性のバージョン情報は特定の製品に関連付けられているため、姿勢バリレーターは、この属性を解釈する際に対応する製品情報属性も所有することが期待されます。
All Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this document MUST support sending this attribute type, at least for those PA subtypes. Other Posture Collectors MAY support sending this attribute type. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. All Posture Validators that implement any of the IETF Standard PA Subtypes defined in this document MUST support receiving this attribute type, at least for those PA subtypes. Other Posture Validators MAY support receiving this attribute type. Posture Validators MUST NOT send this attribute type.
このドキュメントで定義されているIETF標準PAサブタイプのいずれかを実装するすべての姿勢コレクターは、少なくともこれらのPAサブタイプについて、この属性タイプの送信をサポートする必要があります。他の姿勢コレクターは、この属性タイプの送信をサポートする場合があります。特定の姿勢コレクターが実際にこの属性タイプを送信するかどうかは、現地のプライバシーとセキュリティポリシーによって依然として管理されるべきです。このドキュメントで定義されているIETF標準PAサブタイプのいずれかを実装するすべての姿勢バリエーターは、少なくともこれらのPAサブタイプについて、この属性タイプの受信をサポートする必要があります。他の姿勢バリエーターは、この属性タイプの受信をサポートする場合があります。姿勢バリデーターは、この属性タイプを送信してはなりません。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 4. The value in the PA-TNC Attribute Length field will vary, depending on the length of the Component Version Number, Internal Build Number, and Configuration Version Number fields. However, the value in the PA-TNC Attribute Length field MUST be at least 15 because this is the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute type. If the PA-TNC Attribute Length field is less than the size of these fixed-length fields or does not match the length indicated by the sum of the fixed-length and variable-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドはゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドは4に設定する必要があります。コンポーネントバージョン番号、内部ビルド番号、および構成バージョン番号フィールドの長さ。ただし、PA-TNC属性の長さフィールドの値は、PA-TNC属性ヘッダーの固定長フィールドとこの属性タイプの固定長フィールドの長さであるため、少なくとも15でなければなりません。PA-TNC属性の長さフィールドがこれらの固定長フィールドのサイズよりも小さい場合、または固定長と可変長フィールドの合計で示される長さと一致しない場合、実装は無効なパラメーターPA-TNCで応答する必要がありますエラーコード。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Len | Product Version Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Num Len | Internal Build Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config. Len | Configuration Version Number (Variable Length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Len
バージョンレン
This field defines the number of octets in the Product Version Number field. If the product version number is unavailable or unknown, this field MUST be set to 0 and the Product Version Number field will be zero length (effectively not present).
このフィールドは、製品バージョン番号フィールドのオクテットの数を定義します。製品バージョン番号が利用できないか不明の場合、このフィールドは0に設定する必要があり、製品バージョン番号フィールドは長さがゼロになります（事実上存在しません）。
Product Version Number
製品バージョン番号
This field contains a UTF-8 string identifying the version of the component (e.g., "1.12.23.114"). This field MUST be sized to fit the version string and MUST NOT include extra octets for padding or NUL character termination.
このフィールドには、コンポーネントのバージョンを識別するUTF-8文字列が含まれています（例： "1.12.23.114"）。このフィールドは、バージョンの文字列に合わせてサイズにしている必要があり、パディングまたはNUL文字終了のための追加のオクテットを含めてはなりません。
Various products use a wide range of different formats and semantics for version strings. Some use alphabetic characters, white space, and punctuation. Some consider version "1.21" to be later than version "1.3" and some earlier. Therefore, the syntax and semantics of this string are not defined.
さまざまな製品は、バージョン文字列に幅広い異なる形式とセマンティクスを使用しています。いくつかは、アルファベットのある文字、空白、句読点を使用しています。バージョン「1.21」がバージョン「1.3」よりも遅いと考える人もいれば、以前にはあるものもあります。したがって、この文字列の構文とセマンティクスは定義されていません。
Build Num Len
num lenを構築します
This field defines the number of octets in the Internal Build Number field. For products where the internal build number is unavailable or unknown, this field MUST be set to 0 and the Internal Build Number field will be zero length (effectively not present).
このフィールドは、内部ビルド番号フィールドのオクテットの数を定義します。内部ビルド番号が利用できないか不明な製品の場合、このフィールドは0に設定し、内部ビルド番号フィールドはゼロの長さになります（事実上存在しません）。
Internal Build Number
内部ビルド番号
This field contains a UTF-8 string identifying the engineering build number of the product. This field MUST be sized to fit the build number string and MUST NOT include extra octets for padding or NUL character termination. The syntax and semantics of this string are not defined.
このフィールドには、製品のエンジニアリングビルド番号を識別するUTF-8文字列が含まれています。このフィールドは、ビルド番号の文字列に合わせてサイズにする必要があり、パディングまたはNUL文字終了のための追加のオクテットを含めてはなりません。この文字列の構文とセマンティクスは定義されていません。
Config. Len
config。レン
This field defines the number of octets in the Configuration Version Number field. If the configuration version number is unavailable or unknown, this field MUST be set to 0 and the Configuration Version Number field will be zero length (effectively not present).
このフィールドは、構成バージョン番号フィールドのオクテットの数を定義します。構成バージョン番号が利用できないか不明の場合、このフィールドは0に設定する必要があり、構成バージョン番号フィールドは長さがゼロになります（事実上存在しません）。
Configuration Version Number
構成バージョン番号
This field contains a UTF-8 string identifying the version of the configuration used by the component. This version SHOULD represent the overall configuration version even if several configuration policy files or settings are used. Posture Collectors MAY include multiple version numbers in this single string if a single version is not practical. This field MUST be sized to fit the version string and MUST NOT include extra octets for padding or NUL character termination.
このフィールドには、コンポーネントが使用する構成のバージョンを識別するUTF-8文字列が含まれています。このバージョンは、複数の構成ポリシーファイルまたは設定が使用されている場合でも、全体的な構成バージョンを表す必要があります。姿勢コレクターには、単一のバージョンが実用的でない場合、この単一の文字列に複数のバージョン番号を含めることができます。このフィールドは、バージョンの文字列に合わせてサイズにしている必要があり、パディングまたはNUL文字終了のための追加のオクテットを含めてはなりません。
Various products use a wide range of different formats for version strings. Some use alphabetic characters, white space, and punctuation. Some consider version "1.21" to be later than version "1.3" and some earlier. In addition, some Posture Collectors may place multiple configuration version numbers in this single string. Therefore, the syntax and semantics of this string are not defined.
さまざまな製品は、バージョン文字列に幅広い異なる形式を使用しています。いくつかは、アルファベットのある文字、空白、句読点を使用しています。バージョン「1.21」がバージョン「1.3」よりも遅いと考える人もいれば、以前にはあるものもあります。さらに、一部の姿勢コレクターは、この単一の文字列に複数の構成バージョン番号を配置する場合があります。したがって、この文字列の構文とセマンティクスは定義されていません。
This PA-TNC Attribute Type describes the operational status of a product that can implement the component specified in the PA Subtype field, as described in section 3.5. For example, if the PA Subtype is Anti-Spyware, this attribute would contain information about the operational status of a host-based anti-spyware product that may or may not be installed on the endpoint.
このPA-TNC属性タイプは、セクション3.5で説明されているように、PAサブタイプフィールドで指定されたコンポーネントを実装できる製品の動作ステータスを記述します。たとえば、PAサブタイプがアンチスパイウェアである場合、この属性には、エンドポイントにインストールされている場合とまったくインストールされていない場合があるホストベースのアンチスパイウェア製品の運用ステータスに関する情報が含まれます。
Posture Collectors that implement the IETF Standard PA Subtype for Operating System or VPN MAY support sending this attribute type for those PA subtypes. Posture Collectors that implement other IETF Standard PA Subtypes defined in this specification SHOULD support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending this attribute type. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement the IETF Standard PA Subtype for Operating System or VPN MAY support receiving this attribute type, at least for those PA subtypes. Posture Validators that implement other IETF Standard PA Subtypes defined in this specification SHOULD support receiving this attribute type, at least for those PA subtypes. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
オペレーティングシステムまたはVPNにIETF標準PAサブタイプを実装する姿勢コレクターは、これらのPAサブタイプのこの属性タイプの送信をサポートする場合があります。この仕様で定義されている他のIETF標準PAサブタイプを実装する姿勢コレクターは、これらのPAサブタイプのこの属性タイプの送信をサポートする必要があります。他の姿勢コレクターは、この属性タイプの送信をサポートする場合があります。特定の姿勢コレクターが実際にこの属性タイプを送信するかどうかは、現地のプライバシーとセキュリティポリシーによって依然として管理されるべきです。オペレーティングシステムまたはVPNにIETF標準PAサブタイプを実装する姿勢バリエーターは、少なくともこれらのPAサブタイプでこの属性タイプの受信をサポートする場合があります。この仕様で定義されている他のIETF標準PAサブタイプを実装するPosure Validatorは、少なくともこれらのPAサブタイプでこの属性タイプの受信をサポートする必要があります。他の姿勢バリエーターは、この属性タイプの受信をサポートする場合があります。この属性タイプの受信をサポートしていないPosure Validatorは、このタイプで属性を単純に無視する必要があります。姿勢バリデーターは、この属性タイプを送信してはなりません。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 5. The value in the PA-TNC Attribute Length field MUST be 36. If the PA-TNC Attribute Length field does not have this value, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドはゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドは5に設定する必要があります。PA-TNC属性の長さフィールドにはこの値がありません。実装は、無効なパラメーターPA-TNCエラーコードで応答する必要があります。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
This field gives the operational status of the product. The following table lists the values currently defined for this field.
このフィールドは、製品の運用ステータスを提供します。次の表には、このフィールドで現在定義されている値を示します。
Value Description
----- -----------
0 Unknown or other
1 Not installed
2 Installed but not operational
3 Operational
If a Posture Validator receives a value for this field that it does not recognize, it SHOULD treat this value as equivalent to the value 0.
姿勢バリーターがこのフィールドの値を認識しない値を受信した場合、この値を値0に相当するものとして扱う必要があります。
Result
結果
This field contains the result of the last use of the product. The following table lists the values currently defined for this field.
このフィールドには、製品の最後の使用の結果が含まれています。次の表には、このフィールドで現在定義されている値を示します。
Value Description
----- -----------
0 Unknown or other
1 Successful use with no errors detected
2 Successful use with one or more errors detected
3 Unsuccessful use (e.g., aborted)
Posture Collectors SHOULD set this field to 0 if the Status field contains a value of 1 (Not installed) or 2 (Installed but not operational). If a Posture Validator receives a value for this field that it does not recognize, it SHOULD treat this value as equivalent to the value 0.
姿勢コレクターは、ステータスフィールドに1（インストールされていない）または2（インストールされていないが動作しない）の値が含まれている場合、このフィールドを0に設定する必要があります。姿勢バリーターがこのフィールドの値を認識しない値を受信した場合、この値を値0に相当するものとして扱う必要があります。
Reserved
予約済み
This field is reserved for future use. The field MUST be set to 0 on transmission and ignored upon reception.
このフィールドは、将来の使用のために予約されています。フィールドは、送信時に0に設定し、受信時に無視する必要があります。
Last Use
最後の使用
This field contains the date and time of the last use of the component. The Last Use date and time MUST be represented as an RFC 3339 [4] compliant ASCII string in Coordinated Universal Time (UTC) time with the additional restrictions that the 't' delimiter and the 'z' suffix MUST be capitalized and fractional seconds (time-secfrac) MUST NOT be included.
このフィールドには、コンポーネントの最後の使用の日付と時刻が含まれています。最後の使用日と時刻は、「T」デリミッターと「Z」の接尾辞を大文字と分数秒にする必要があるという追加の制限を伴う、調整されたユニバーサル時間（UTC）時間において、RFC 3339 [4]準拠のASCII文字列として表現する必要があります（UTC）Time-secfrac）は含めてはいけません。
This field conforms to the date-time ABNF production from section 5.6 of RFC 3339 with the above restrictions. Leap seconds are permitted and Posture Validators MUST support them.
このフィールドは、上記の制限を伴うRFC 3339のセクション5.6からの日付時間ABNF生産に準拠しています。跳躍秒は許可されており、姿勢バリデーターはそれらをサポートする必要があります。
The last use string MUST NOT be NUL terminated or padded in any way. If the last use time is not known, not applicable, or cannot be represented in this format, the Posture Collector MUST set this field to the value "0000-00-00T00:00:00Z" (allowing this field to be fixed length). Note that this particular reserved value is NOT a valid RFC 3339 date and time and MUST NOT be used for any other purpose in this field.
最後の使用文字列は、いかなる方法でも終了したりパッドにしたりしてはなりません。最後の使用時間が不明、該当なし、またはこの形式で表現できない場合、姿勢コレクターはこのフィールドを値「0000-00-00T00：00：00Z」に設定する必要があります（このフィールドを固定することを可能にします）。この特定の予約価値は有効なRFC 3339日付と時刻ではなく、この分野の他の目的に使用してはならないことに注意してください。
This encoding produces a string that is easy to read, parse, and interpret. The format (more precisely defined in RFC 3339) is YYYY-MM-DDTHH:MM:SSZ, resulting in one and only one representation for each second in UTC time from year 0000 to year 9999. For example, 9:05:00AM EST (GMT-0500) on January 19, 1995 can be represented as "1995-01-19T14:05:00Z". The length of this field is always 20 octets.
このエンコードは、読み取り、解析、解釈が簡単な文字列を生成します。形式（より正確にRFC 3339で定義されている）はYyyy-Mm-Ddthh：mm：SSZであり、0000年から9999年までのUTC時間の各秒の1つの表現のみが1つずつ1つずつ1つずつ1つの表現を実現します。（GMT-0500）1995年1月19日、「1995-01-19T14：05：00Z」として表すことができます。このフィールドの長さは常に20オクテットです。
This PA-TNC Attribute Type provides the list of port numbers and associated protocols (e.g., TCP and UDP) that are currently blocked or allowed by a host-based firewall on the endpoint.
このPA-TNC属性タイプは、エンドポイントのホストベースのファイアウォールによって現在ブロックまたは許可されているポート番号と関連するプロトコル（TCPやUDPなど）のリストを提供します。
Posture Collectors that implement the IETF Standard PA Subtype for Firewall or VPN SHOULD support sending this attribute type for those PA subtypes. Posture Collectors that implement other IETF Standard PA Subtypes defined in this specification MUST NOT support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending this attribute type, if it is appropriate to their PA subtype. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement the IETF Standard PA Subtype for Firewall or VPN SHOULD support receiving this attribute type, at least for those PA subtypes. Posture Validators that implement other IETF Standard PA Subtypes defined in this specification MUST NOT support receiving this attribute type for those PA subtypes. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
ファイアウォールまたはVPNにIETF標準PAサブタイプを実装する姿勢コレクターは、これらのPAサブタイプのこの属性タイプの送信をサポートする必要があります。この仕様で定義されている他のIETF標準PAサブタイプを実装する姿勢コレクターは、これらのPAサブタイプのこの属性タイプの送信をサポートしてはなりません。他の姿勢コレクターは、PAサブタイプに適している場合、この属性タイプの送信をサポートする場合があります。特定の姿勢コレクターが実際にこの属性タイプを送信するかどうかは、現地のプライバシーとセキュリティポリシーによって依然として管理されるべきです。FirewallまたはVPNにIETF標準PAサブタイプを実装するPosure Validatorsは、少なくともそれらのPAサブタイプでこの属性タイプの受信をサポートする必要があります。この仕様で定義されている他のIETF標準PAサブタイプを実装するPosure Validatorsは、これらのPAサブタイプのこの属性タイプの受信をサポートしてはなりません。他の姿勢バリエーターは、この属性タイプの受信をサポートする場合があります。この属性タイプの受信をサポートしていないPosure Validatorは、このタイプで属性を単純に無視する必要があります。姿勢バリデーターは、この属性タイプを送信してはなりません。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 6.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドをゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドは6に設定する必要があります。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
Note that this diagram shows two Protocol/Port Number pairs. The actual number of Protocol/Port Number pairs included in a Port Filter attribute can vary from one to a large number (limited only by the maximum message and length supported by the underlying PT protocol). However, each Port Filter attribute MUST contain at least one Protocol/Port Number pair. Because the length of a Protocol/Port Number pair with the Reserved field and B flag is always 4 octets, the number of Protocol/Port Number pairs can be easily computed using the PA-TNC Attribute Length field by subtracting the number of octets in the PA-TNC Attribute Header and dividing by 4. If the PA-TNC Attribute Length field is invalid, Posture Validators SHOULD respond with an Invalid Parameter PA-TNC error code.
この図は、2つのプロトコル/ポート番号のペアを示していることに注意してください。ポートフィルター属性に含まれるプロトコル/ポート番号ペアの実際の数は、1つまで異なります（基礎となるPTプロトコルによってサポートされる最大メッセージと長さによってのみ制限されます）。ただし、各ポートフィルター属性には、少なくとも1つのプロトコル/ポート番号ペアが含まれている必要があります。予約済みフィールドとBフラグを持つプロトコル/ポート番号ペアの長さは常に4オクテットであるため、プロトコル/ポート番号ペアの数は、PA-TNC属性長のフィールドを使用して簡単に計算できます。PA-TNC属性ヘッダーと4で割る4。PA-TNC属性の長さフィールドが無効である場合、姿勢バリーターは無効なパラメーターPA-TNCエラーコードで応答する必要があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約済み
This field is reserved for future use. It MUST be set to 0 on transmission and ignored upon reception.
このフィールドは、将来の使用のために予約されています。送信時に0に設定し、受信時に無視する必要があります。
B Flag (Blocked or Allowed Port)
Bフラグ（ブロックまたは許可ポート）
This single-bit field indicates whether the following port is blocked or allowed. This bit MUST be set to 1 if the protocol and port combination is blocked. Otherwise, this field MUST be set to 0. This field was provided to allow for more abbreviated reporting of the port filtering policy (e.g., when all ports are blocked except a few, the Posture Collector can just list the few that are allowed).
この単一ビットフィールドは、次のポートがブロックされているか許可されているかを示します。プロトコルとポートの組み合わせがブロックされている場合、このビットは1に設定する必要があります。それ以外の場合、このフィールドは0に設定する必要があります。このフィールドは、ポートフィルタリングポリシーのより省略された報告を可能にするために提供されました（たとえば、すべてのポートが少数を除くブロックされている場合、姿勢コレクターは許可されている少数をリストすることができます）。
Posture Collectors MUST NOT provide a mixed list of blocked and non-blocked ports for a particular protocol. To be more precise, a Posture Collector MUST NOT include two Protocol/Port Number pairs in a single Port Filter attribute where the protocol number is the same but the B flag is different. Also, Posture Collectors MUST NOT list the same Protocol and Port Number combination twice in a Port List attribute.
姿勢コレクターは、特定のプロトコルのためにブロックされたブロックされていないポートの混合リストを提供してはなりません。より正確には、姿勢コレクターは、プロトコル番号が同じであるがBフラグが異なる単一のポートフィルター属性に2つのプロトコル/ポート番号ペアを含めてはなりません。また、姿勢コレクターは、ポートリスト属性に同じプロトコルとポート番号の組み合わせを2回リストしてはなりません。
Posture Collectors MAY list all blocked ports for one protocol and all allowed ports for a different protocol in a single Port List attribute, using the B flag to indicate whether each entry is blocked. For example, a Posture Collector might list all the blocked TCP ports but only list the allowed UDP ports. However, it MUST NOT list some blocked TCP ports and some other allowed TCP ports.
姿勢コレクターは、1つのプロトコルのすべてのブロックされたポートをリストし、すべてのポートを単一のポートリスト属性の異なるプロトコルのポートを許可することができます。Bフラグを使用して、各エントリがブロックされているかどうかを示します。たとえば、姿勢コレクターはすべてのブロックされたTCPポートをリストする場合がありますが、許可されたUDPポートのみをリストします。ただし、ブロックされたTCPポートや他の許可されたTCPポートをリストしてはなりません。
Protocol
プロトコル
This field contains the transport protocol number (e.g., tcp is 6) being blocked or allowed. The values used in this field are the same ones used in the IPv4 Protocol and IPv6 Next Header fields. The IANA already maintains the Assigned Internet Protocol Numbers registry of these values for use in this field.
このフィールドには、輸送プロトコル番号（たとえば、TCPは6）が含まれています。このフィールドで使用される値は、IPv4プロトコルとIPv6次のヘッダーフィールドで使用されている値と同じです。IANAはすでに、このフィールドで使用するためにこれらの値の割り当てられたインターネットプロトコル番号レジストリを維持しています。
Port Number
ポート番号
This field contains the transport protocol (e.g., tcp) port number being blocked or allowed. The values used in this field are specific to the protocol identified by the Protocol field. The IANA maintains registries for well-known and user-requested TCP and UDP port numbers for use in this field.
このフィールドには、ブロックまたは許可されている輸送プロトコル（TCPなど）ポート番号が含まれています。このフィールドで使用される値は、プロトコルフィールドによって識別されるプロトコルに固有です。IANAは、この分野で使用するために、よく知られており、ユーザー要求されたTCPおよびUDPポート番号のレジストリを維持しています。
This PA-TNC Attribute Type contains a list of the installed packages that comprise a product on the endpoint that implements the component specified in the PA Subtype field, as described in section 3.5. This allows a Posture Validator to check which packages are installed for a particular product and which versions of those packages are installed.
このPA-TNC属性タイプには、セクション3.5で説明されているように、PAサブタイプフィールドで指定されたコンポーネントを実装するエンドポイント上の製品を構成するインストールされたパッケージのリストが含まれています。これにより、姿勢検証装置は、特定の製品用にインストールされているパッケージと、それらのパッケージのどのバージョンがインストールされているかを確認できます。
Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this document SHOULD support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending this attribute type, if it is appropriate to their PA subtype. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement any of the IETF Standard PA Subtypes defined in this document SHOULD support receiving this attribute type, at least for those PA subtypes. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
このドキュメントで定義されているIETF標準PAサブタイプのいずれかを実装する姿勢コレクターは、これらのPAサブタイプのこの属性タイプの送信をサポートする必要があります。他の姿勢コレクターは、PAサブタイプに適している場合、この属性タイプの送信をサポートする場合があります。特定の姿勢コレクターが実際にこの属性タイプを送信するかどうかは、現地のプライバシーとセキュリティポリシーによって依然として管理されるべきです。このドキュメントで定義されているIETF標準PAサブタイプのいずれかを実装するPosure Validatorsは、少なくともこれらのPAサブタイプについて、この属性タイプの受信をサポートする必要があります。他の姿勢バリエーターは、この属性タイプの受信をサポートする場合があります。この属性タイプの受信をサポートしていないPosure Validatorは、このタイプで属性を単純に無視する必要があります。姿勢バリデーターは、この属性タイプを送信してはなりません。
This attribute type can be quite long, especially for the Operating System PA subtype. This can cause problems, especially with 802.1X and other limited transport protocols. Therefore, Posture Collectors SHOULD NOT send this attribute unless specifically requested to do so using the Attribute Request attribute or otherwise configured to do so. Also, Posture Validators SHOULD NOT request this attribute unless the transport protocol in use can support the large amount of data that may be sent in response.
この属性タイプは、特にオペレーティングシステムのPAサブタイプでは非常に長い場合があります。これにより、特に802.1xおよびその他の限られた輸送プロトコルが問題を引き起こす可能性があります。したがって、姿勢コレクターは、属性要求属性を使用して具体的に要求されない限り、またはそうするように構成されている場合を除き、この属性を送信しないでください。また、使用中のトランスポートプロトコルがそれに応じて送信される可能性のある大量のデータをサポートできない限り、Posure Validatorsはこの属性を要求してはなりません。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 7. The value in the PA-TNC Attribute Length field will vary, depending on the number of packages and the length of the Package Name and Package Version Number fields for those packages. However, the value in the PA-TNC Attribute Length field MUST be at least 16 because this is the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute type. If the PA-TNC Attribute Length field is less than the size of these fixed-length fields or does not match the length indicated by the sum of the fixed-length and variable-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドはゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドは7に設定する必要があります。これらのパッケージのパッケージの数とパッケージ名とパッケージバージョン番号フィールドの長さ。ただし、PA-TNC属性の長さフィールドの値は、PA-TNC属性ヘッダーの固定長フィールドとこの属性タイプの固定長フィールドの長さであるため、少なくとも16でなければなりません。PA-TNC属性の長さフィールドがこれらの固定長フィールドのサイズよりも小さい場合、または固定長と可変長フィールドの合計で示される長さと一致しない場合、実装は無効なパラメーターPA-TNCで応答する必要がありますエラーコード。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
Note that this diagram shows an attribute containing information on one package. The actual number of package descriptions included in an Installed Packages attribute is indicated by the Package Count field. This value may vary from zero to a large number (up to 65535, if the underlying PT protocol can support that many). If this number is not sufficient, specialized patch management software should be employed that can simply report compliance with a pre-established patch policy.
この図は、1つのパッケージに情報を含む属性を示していることに注意してください。インストールされたパッケージ属性に含まれるパッケージの説明の実際の数は、パッケージカウントフィールドで示されています。この値は、基礎となるPTプロトコルがそれほど多くをサポートできる場合、ゼロから大量まで異なる場合があります（65535まで）。この数字が十分でない場合は、事前に確立されたパッチポリシーへのコンプライアンスを単純に報告できる専門的なパッチ管理ソフトウェアを使用する必要があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Package Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pkg Name Len | Package Name (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Len | Package Version Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved for future use. The field MUST be set to 0 on transmission and ignored upon reception.
このフィールドは、将来の使用のために予約されています。フィールドは、送信時に0に設定し、受信時に無視する必要があります。
Package Count
パッケージ数
This field is an unsigned 16-bit integer that indicates the number of packages listed in this attribute. For each package so indicated, a Pkg Name Len, Package Name, Version Len, and Package Version Number field is included in the attribute.
このフィールドは、この属性にリストされているパッケージの数を示す署名されていない16ビット整数です。そのように示されている各パッケージについて、PKG名LEN、パッケージ名、バージョンLEN、およびパッケージバージョン番号フィールドが属性に含まれています。
Pkg Name Len
PKG名レン
This field is an unsigned 8-bit integer that indicates the length of the Package Name field in octets. This field may be zero if a Package Name is not available.
このフィールドは、オクテットのパッケージ名フィールドの長さを示す署名されていない8ビット整数です。パッケージ名が利用できない場合、このフィールドはゼロになる場合があります。
Package Name
パッケージ名
This field contains the name of the package associated with the product. This field is a UTF-8 encoded character string whose octet length is given by the Pkg Name Len field. This field MUST NOT include extra octets for padding or NUL character termination. The syntax and semantics of this name are not specified in this document, since they may vary across products and/or operating systems. Posture Collectors MAY list two packages with the same name in a single Installed Packages attribute. The meaning of doing so is not defined here.
このフィールドには、製品に関連付けられたパッケージの名前が含まれています。このフィールドは、Octetの長さがPKG名Len Fieldによって与えられるUTF-8エンコード文字列です。このフィールドには、パディングまたはnul文字終了のための余分なオクテットを含めてはなりません。この名前の構文とセマンティクスは、製品やオペレーティングシステム間で異なる場合があるため、このドキュメントでは指定されていません。姿勢コレクターは、単一のインストールされたパッケージ属性に同じ名前の2つのパッケージをリストすることができます。そうすることの意味は、ここでは定義されていません。
Version Len
バージョンレン
This field is an unsigned 8-bit integer that indicates the length of the Package Version Number field in octets. This field may be zero if a Package Version Number is not available.
このフィールドは、オクテットのパッケージバージョン番号フィールドの長さを示す署名されていない8ビット整数です。パッケージバージョン番号が利用できない場合、このフィールドはゼロになる場合があります。
Package Version Number
パッケージバージョン番号
This field contains the version string for the package named in the previous Package Name field. This field is a UTF-8 encoded character string whose octet length is given by the Version Len field. This field MUST NOT include extra octets for padding or NUL character termination. The syntax and semantics of this version string are not specified in this document, since they may vary across products and/or operating systems. Posture Collectors MAY list two packages with the same Package Version Number (and even the same Package Name and Package Version Number) in a single Installed Packages attribute. The meaning of doing so is not defined here.
このフィールドには、前のパッケージ名フィールドに名前が付けられたパッケージのバージョン文字列が含まれています。このフィールドは、バージョンのLen Fieldによってオクテットの長さが与えられるUTF-8エンコード文字列です。このフィールドには、パディングまたはnul文字終了のための余分なオクテットを含めてはなりません。このバージョン文字列の構文とセマンティクスは、製品やオペレーティングシステム間で異なる場合があるため、このドキュメントでは指定されていません。姿勢コレクターは、単一のインストールされたパッケージ属性に、同じパッケージバージョン番号（および同じパッケージ名とパッケージバージョン番号）を持つ2つのパッケージをリストすることができます。そうすることの意味は、ここでは定義されていません。
This PA-TNC Attribute Type contains an error code and supplemental information regarding an error pertaining to PA-TNC.
このPA-TNC属性タイプには、エラーコードとPA-TNCに関連するエラーに関する補足情報が含まれています。
All Posture Collectors and Posture Validators that implement any of the IETF Standard PA Subtypes defined in this specification MUST support sending and receiving this attribute type, at least for those PA subtypes.
この仕様で定義されているIETF標準PAサブタイプのいずれかを実装するすべての姿勢コレクターと姿勢バリエーターは、少なくともこれらのPAサブタイプについて、この属性タイプの送信と受信をサポートする必要があります。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 8. The value in the PA-TNC Attribute Length field will vary, depending on the length of the Error Information field. However, the value in the PA-TNC Attribute Length field MUST be at least 20 because this is the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute type.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドはゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドは8に設定する必要があります。エラー情報フィールドの長さ。ただし、PA-TNC属性の長さフィールドの値は、PA-TNC属性ヘッダーの固定長フィールドとこの属性タイプの固定長フィールドの長さであるため、少なくとも20でなければなりません。
A PA-TNC error code SHOULD be sent with the same PA Message Vendor ID and PA Subtype used by the PA-TNC message that caused the error so that the error code is sent to the party who sent the offending PA-TNC message. Other measures (such as setting PB-TNC's EXCL flag and Posture Collector Identifier or Posture Validator Identifier fields) SHOULD also be taken to attempt to ensure that only the party who sent the offending message receives the error.
PA-TNCエラーコードは、エラーコードが違反のPA-TNCメッセージを送信したパーティに送信されるように、エラーを引き起こすPA-TNCメッセージで使用される同じPAメッセージベンダーIDとPAサブタイプで送信する必要があります。その他の測定（PB-TNCの除外フラグおよび姿勢コレクター識別子または姿勢バリデーター識別子フィールドの設定など）も、問題のあるメッセージを送信した当事者のみがエラーを受信するようにするために取得する必要があります。
When a PA-TNC error code is received, the recipient MUST NOT respond with a PA-TNC error code because this could result in an infinite loop of errors. Instead, the recipient MAY log the error, modify its behavior to attempt to avoid the error (attempting to avoid loops or long strings of errors), ignore the error, terminate the assessment, or take other action as appropriate (as long as it is consistent with the requirements of this specification).
PA-TNCエラーコードを受信した場合、受信者はPA-TNCエラーコードで応答してはなりません。これにより、エラーが無限にループする可能性があるためです。代わりに、受信者はエラーを記録し、動作を変更してエラーを回避しようとします（ループやエラーの長い文字列を避けようとします）、エラーを無視したり、評価を終了したり、適切に他のアクションを実行したりします（この仕様の要件と一致しています）。
Posture Validators MUST NOT include this attribute type in an Attribute Request attribute. It does not make sense for a Posture Validator to request that a Posture Collector send a PA-TNC Error attribute.
Posture Validatorsは、この属性タイプを属性要求属性に含めてはなりません。Positure ValidatorがPosure CollectorがPA-TNCエラー属性を送信するように要求することは意味がありません。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Information (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約済み
This field is reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
このフィールドは、将来の使用のために予約されています。このフィールドは、送信時に0に設定し、受信時に無視する必要があります。
PA-TNC Error Code Vendor ID
PA-TNCエラーコードベンダーID
This field contains the SMI Private Enterprise Number for the organization that defined the PA-TNC Error Code that is being used in the attribute. For IETF Standard PA-TNC Error Code values this field MUST be set to zero (0).
このフィールドには、属性で使用されているPA-TNCエラーコードを定義した組織のSMIプライベートエンタープライズ番号が含まれています。IETF標準PA-TNCエラーコード値の場合、このフィールドはゼロ（0）に設定する必要があります。
PA-TNC Error Code
PA-TNCエラーコード
This field contains the PA-TNC Error Code being reported in this attribute. Note that a particular PA-TNC Error Code value will have completely different meanings depending on the PA-TNC Error Code Vendor ID. Each PA-TNC Error Code Vendor ID defines a different space of PA-TNC Error Code values. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Error Codes and MUST interoperate with other parties despite any differences in the set of vendor-specific PA-TNC Error Codes supported (although they MAY permit administrators to configure them to require support for specific PA-TNC Error Codes).
このフィールドには、この属性で報告されているPA-TNCエラーコードが含まれています。特定のPA-TNCエラーコード値は、PA-TNCエラーコードベンダーIDに応じて、まったく異なる意味を持つことに注意してください。各PA-TNCエラーコードベンダーIDは、PA-TNCエラーコード値の異なるスペースを定義します。姿勢コレクターと姿勢バリデーターは、特定のベンダー固有のPA-TNCエラーコードのサポートを必要としない必要があり、ベンダー固有のPA-TNCエラーコードのセットに違いがサポートされているにもかかわらず、他の関係者と相互運用する必要があります（管理者はそれらを構成することができますが特定のPA-TNCエラーコードのサポートが必要です）。
When the PA-TNC Error Code Vendor ID is set to zero (0), the PA-TNC Error Code is an IETF Standard PA-TNC Error Code. IANA maintains a registry of PA-TNC Error Codes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 7.
PA-TNCエラーコードベンダーIDがゼロ（0）に設定されている場合、PA-TNCエラーコードはIETF標準PA-TNCエラーコードです。IANAは、PA-TNCエラーコードのレジストリを維持しています。このレジストリのエントリは、セクション7のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。
The following table lists the IETF Standard PA-TNC Error Codes defined in this specification:
次の表に、この仕様で定義されているIETF標準PA-TNCエラーコードを示します。
Integer Description
------- -----------
0 Reserved
1 Invalid Parameter
2 Version Not Supported
3 Attribute Type Not Supported
The next few subsections of this document provide detailed definitions of these error codes.
このドキュメントの次のいくつかのサブセクションは、これらのエラーコードの詳細な定義を提供します。
Error Information
エラー情報
This field provides additional context for the error. The contents of this field vary based on the PA-TNC Error Code Vendor ID and PA-TNC Error Code. Therefore, whenever a PA-TNC Error Code is defined, the format of this field for that error code must also be defined. The definitions of IETF Standard PA-TNC Error Codes on the next few pages provide good examples of such definitions.
このフィールドは、エラーの追加コンテキストを提供します。このフィールドの内容は、PA-TNCエラーコードベンダーIDおよびPA-TNCエラーコードに基づいて異なります。したがって、PA-TNCエラーコードが定義されている場合は、そのエラーコードのこのフィールドの形式も定義する必要があります。次の数ページのIETF標準PA-TNCエラーコードの定義は、そのような定義の良い例を提供します。
The length of this field can be determined by the recipient using the PA-TNC Attribute Length field by subtracting the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute.
このフィールドの長さは、PA-TNC属性ヘッダーの固定長フィールドの長さとこの属性の固定長フィールドを差し引くことにより、PA-TNC属性長のフィールドを使用して受信者によって決定できます。
The Invalid Parameter error code is an IETF Standard PA-TNC Error Code (value 1) that indicates that the sender of this error code has detected an invalid value in a PA-TNC message sent by the recipient of this error code in the current assessment.
無効なパラメーターエラーコードは、このエラーコードの送信者が現在の評価でこのエラーコードの受信者によって送信されたPA-TNCメッセージで無効な値を検出したことを示すIETF標準PA-TNCエラーコード（値1）です。。
For this error code, the Error Information field contains the first 8 octets of the PA-TNC message that contained the invalid parameter and an offset indicating the position within that message of the invalid parameter.
このエラーコードの場合、エラー情報フィールドには、無効なパラメーターを含むPA-TNCメッセージの最初の8オクテットと無効なパラメーターのメッセージ内の位置を示すオフセットが含まれています。
The following diagram illustrates the format and contents of the Error Information field for this error code. The text after this diagram describes the fields shown here.
次の図は、このエラーコードのエラー情報フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
バージョン
This field MUST contain an exact copy of the Version field in the PA-TNC Message Header of the PA-TNC message that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーにバージョンフィールドの正確なコピーを含める必要があります。
Copy of Reserved
予約済みのコピー
This field MUST contain an exact copy of the Reserved field in the PA-TNC Message Header of the PA-TNC message that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーに予約済みフィールドの正確なコピーを含める必要があります。
Message Identifier
メッセージ識別子
This field MUST contain an exact copy of the Message Identifier field in the PA-TNC Message Header of the PA-TNC message that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーのメッセージ識別子フィールドの正確なコピーを含める必要があります。
Offset
オフセット
This field MUST contain an octet offset from the start of the PA-TNC Message Header of the PA-TNC message that caused this error to the start of the value that caused this error. For instance, if the first PA-TNC attribute in the message had an invalid PA-TNC Attribute Length (e.g., 0), this value would be 16.
このフィールドには、このエラーがこのエラーを引き起こした値の開始までこのエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーの開始からのオクテットオフセットを含める必要があります。たとえば、メッセージ内の最初のPA-TNC属性が無効なPA-TNC属性の長さを持っていた場合（例：0）、この値は16になります。
The Version Not Supported error code is an IETF Standard PA-TNC Error Code (value 2) that indicates that the sender of this error code does not support the PA-TNC version number included in the PA-TNC Message Header of a PA-TNC message sent by the recipient of this error code in the current assessment.
サポートされていないエラーコードがサポートされていないバージョンは、このエラーコードの送信者がPA-TNCのPA-TNCメッセージヘッダーに含まれるPA-TNCバージョン番号をサポートしていないことを示すIETF標準PA-TNCエラーコード（値2）です。現在の評価でこのエラーコードの受信者によって送信されたメッセージ。
For this error code, the Error Information field contains the first 8 octets of the PA-TNC message that contained the unsupported version as well as Max Version and Min Version fields that indicate which PA-TNC version numbers are supported by the sender of the error code.
このエラーコードの場合、エラー情報フィールドには、サポートされていないバージョンと、エラーの送信者によってサポートされているPA-TNCバージョン番号を示す最大バージョンおよびMINバージョンフィールドを含むPA-TNCメッセージの最初の8オクテットが含まれています。コード。
The sender MUST support all PA-TNC versions between the Min Version and the Max Version, inclusive (i.e., including the Min Version and the Max Version). When possible, recipients of this error code SHOULD send future messages to the Posture Collector or Posture Validator that originated this error message with a PA-TNC version number within the stated range.
送信者は、MINバージョンとMAXバージョンの間のすべてのPA-TNCバージョンを包括的（つまり、MINバージョンとMAXバージョンを含む）をサポートする必要があります。可能であれば、このエラーコードの受信者は、このエラーメッセージを発信した姿勢コレクターまたは姿勢バリデーターに、指定された範囲内のPA-TNCバージョン番号で将来のメッセージを送信する必要があります。
Any party that is sending the Version Not Supported error code MUST include that error code as the only PA-TNC attribute in a PA-TNC message with version number 1. All parties that send PA-TNC messages MUST be able to properly process a message that meets this description, even if they cannot process any other aspect of PA-TNC version 1. This ensures that a PA-TNC version exchange can proceed properly, no matter what versions of PA-TNC the parties implement.
サポートされていないエラーコードを送信しているバージョンを送信しているパーティは、そのエラーコードをバージョン番号1のPA-TNCメッセージの唯一のPA-TNC属性として含める必要があります。PA-TNCメッセージを送信するすべての関係者は、メッセージを適切に処理できる必要がありますこれは、PA-TNCバージョン1の他の側面を処理できない場合でも、この説明を満たしています。これにより、PA-TNCバージョンの交換が適切に進行できることが保証されます。
The following diagram illustrates the format and contents of the Error Information field for this error code. The text after this diagram describes the fields shown here.
次の図は、このエラーコードのエラー情報フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Version | Min Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
バージョン
This field MUST contain an exact copy of the Version field in the PA-TNC Message Header of the PA-TNC message that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーにバージョンフィールドの正確なコピーを含める必要があります。
Copy of Reserved
予約済みのコピー
This field MUST contain an exact copy of the Reserved field in the PA-TNC Message Header of the PA-TNC message that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーに予約済みフィールドの正確なコピーを含める必要があります。
Message Identifier
メッセージ識別子
This field MUST contain an exact copy of the Message Identifier field in the PA-TNC Message Header of the PA-TNC message that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーのメッセージ識別子フィールドの正確なコピーを含める必要があります。
Max Version
最大バージョン
This field MUST contain the maximum PA-TNC version supported by the sender of this error code.
このフィールドには、このエラーコードの送信者がサポートする最大PA-TNCバージョンを含める必要があります。
Min Version
最小バージョン
This field MUST contain the minimum PA-TNC version supported by the sender of this error code.
このフィールドには、このエラーコードの送信者がサポートする最小PA-TNCバージョンを含める必要があります。
Reserved
予約済み
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
将来の使用のために予約されています。このフィールドは、送信時に0に設定し、受信時に無視する必要があります。
The Attribute Type Not Supported error code is an IETF Standard PA-TNC Error Code (value 3) that indicates that the sender of this error code does not support the PA-TNC Attribute Type included in the Error Information field. This PA-TNC Attribute Type was included in a PA-TNC message sent by the recipient of this error code in the current assessment.
属性タイプのサポートされていないエラーコードは、このエラーコードの送信者がエラー情報フィールドに含まれるPA-TNC属性タイプをサポートしていないことを示すIETF標準PA-TNCエラーコード（値3）です。このPA-TNC属性タイプは、現在の評価でこのエラーコードの受信者が送信したPA-TNCメッセージに含まれていました。
For this error code, the Error Information field contains the first 8 octets of the PA-TNC message that contained the unsupported attribute type as well as a copy of the attribute type that caused the problem.
このエラーコードの場合、エラー情報フィールドには、サポートされていない属性タイプを含むPA-TNCメッセージの最初の8オクテットと、問題を引き起こした属性タイプのコピーが含まれています。
The following diagram illustrates the format and contents of the Error Information field for this error code. The text after this diagram describes the fields shown here.
次の図は、このエラーコードのエラー情報フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
バージョン
This field MUST contain an exact copy of the Version field in the PA-TNC Message Header of the PA-TNC message that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーにバージョンフィールドの正確なコピーを含める必要があります。
Copy of Reserved
予約済みのコピー
This field MUST contain an exact copy of the Reserved field in the PA-TNC Message Header of the PA-TNC message that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーに予約済みフィールドの正確なコピーを含める必要があります。
Message Identifier
メッセージ識別子
This field MUST contain an exact copy of the Message Identifier field in the PA-TNC Message Header of the PA-TNC message that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNCメッセージのPA-TNCメッセージヘッダーのメッセージ識別子フィールドの正確なコピーを含める必要があります。
Flags
フラグ
This field MUST contain an exact copy of the Flags field in the PA-TNC Attribute Header of the PA-TNC attribute that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNC属性のPA-TNC属性ヘッダーのフラグフィールドの正確なコピーを含める必要があります。
PA-TNC Attribute Vendor ID
PA-TNC属性ベンダーID
This field MUST contain an exact copy of the PA-TNC Attribute Vendor ID field in the PA-TNC Attribute Header of the PA-TNC attribute that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNC属性のPA-TNC属性ヘッダーにPA-TNC属性ベンダーIDフィールドの正確なコピーを含める必要があります。
PA-TNC Attribute Type
PA-TNC属性タイプ
This field MUST contain an exact copy of the PA-TNC Attribute Type field in the PA-TNC Attribute Header of the PA-TNC attribute that caused this error.
このフィールドには、このエラーを引き起こしたPA-TNC属性のPA-TNC属性ヘッダーのPA-TNC属性タイプフィールドの正確なコピーを含める必要があります。
This PA-TNC attribute contains the final assessment result from a particular Posture Validator. This attribute might be returned to a Posture Collector for information purposes such as when an endpoint is compliant. Similarly, the Assessment Result attribute could be sent to indicate a non-compliant result where specific actions are needed to bring an endpoint into compliance with the network's policies. These actions could be defined in other PA-TNC attributes such as Remediation Instructions sent to the Posture Collector.
このPA-TNC属性には、特定の姿勢検証装置からの最終的な評価結果が含まれています。この属性は、エンドポイントが準拠している場合など、情報目的で姿勢コレクターに戻される可能性があります。同様に、評価結果属性を送信して、エンドポイントをネットワークのポリシーに準拠させるために特定のアクションが必要な非準拠の結果を示すことができます。これらのアクションは、姿勢コレクターに送信された修復命令など、他のPA-TNC属性で定義できます。
All Posture Collectors that support an IETF Standard PA Subtype defined in this specification SHOULD support receiving and processing the Assessment Result attribute. All Posture Validators that implement an IETF Standard PA Subtype defined in this specification SHOULD support sending the Assessment Result attribute.
この仕様で定義されているIETF標準PAサブタイプをサポートするすべての姿勢コレクターは、評価結果属性の受信と処理をサポートする必要があります。この仕様で定義されているIETF標準PAサブタイプを実装するすべての姿勢バリエーターは、評価結果属性の送信をサポートする必要があります。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 9.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドをゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドを9に設定する必要があります。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assessment Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assessment Result
評価結果
This 32-bit field MUST contain one of the following values;
この32ビットフィールドには、次の値のいずれかを含める必要があります。
Value Description
----- -----------
0 Posture Validator assessed the endpoint component to
be compliant with policy.
1 Posture Validator assessed the endpoint component to be non-compliant with policy but the difference from compliant was minor.
1 Positure Validatorは、エンドポイントコンポーネントがポリシーに準拠していないと評価しましたが、準拠との違いはマイナーでした。
2 Posture Validator assessed the endpoint component to be non-compliant with policy and the assessed difference was very significant.
2 Positure Validatorは、エンドポイントコンポーネントがポリシーに準拠していないと評価し、評価された違いは非常に重要でした。
3 Posture Validator was unable to determine policy compliance of an endpoint component due to an error.
3 Posture Validatorは、エラーのためにエンドポイントコンポーネントのポリシーコンプライアンスを決定することができませんでした。
4 Posture Validator was unable to determine whether the assessed endpoint component was compliant with policy based on the attributes provided by the Posture Collector.
4 Posure Validatorは、評価されたエンドポイントコンポーネントが姿勢コレクターによって提供された属性に基づいてポリシーに準拠しているかどうかを判断できませんでした。
This PA-TNC attribute sent by the Posture Validator to the Posture Collector contains remediation instructions for updating a particular component to make the endpoint compliant with the assessment policies. A Posture Validator might choose to send more than one Remediation Instructions attribute in some circumstances (e.g., both a URI and a human-readable message are necessary) to remediate one or more components. This attribute supports the inclusion of either an IETF standard or vendor-specific remediation instruction.
姿勢バリーターによって姿勢コレクターに送信されたこのPA-TNC属性には、特定のコンポーネントを更新してエンドポイントを評価ポリシーに準拠させるための修復命令が含まれています。姿勢バリーターは、1つ以上のコンポーネントを修復するために、状況によっては複数の修復命令属性を送信することを選択する場合があります（たとえば、URIと人間の読み取り可能なメッセージの両方が必要です）。この属性は、IETF標準またはベンダー固有の修復命令のいずれかを含めることをサポートします。
All Posture Collectors that implement an IETF Standard PA Subtype defined in this specification SHOULD support receiving and processing the Remediation Instructions attribute. All Posture Validators that implement an IETF Standard PA Subtype defined in this specification SHOULD support sending this attribute type. Posture Collectors and Posture Validators supporting other non-IETF standard components MAY support this attribute.
この仕様で定義されているIETF標準PAサブタイプを実装するすべての姿勢コレクターは、修復命令属性の受信と処理をサポートする必要があります。この仕様で定義されているIETF標準PAサブタイプを実装するすべての姿勢バリエーターは、この属性タイプの送信をサポートする必要があります。姿勢コレクターと他の非標準コンポーネントをサポートする姿勢バリデーターは、この属性をサポートする場合があります。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 10.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドをゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドを10に設定する必要があります。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remediation Parameters Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (8 bits)
The Reserved bits MUST be set to 0 on transmission and ignored on reception.
予約されたビットは、送信時に0に設定し、受信時に無視する必要があります。
Remediation Parameters Vendor ID (24 bits)
修復パラメータベンダーID（24ビット）
The Remediation Parameters Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The Remediation Parameters Vendor ID qualifies the Remediation Parameters Type field so that each vendor has 2^32 separate Remediation Parameters Types available for its use. Remediation Parameters Types standardized by the IETF are always used with the value zero (0) in this field.
修復パラメータベンダーIDフィールドは、SMIプライベートエンタープライズ番号（PEN）を使用してベンダーを識別します。インターネットが番号を割り当てたIANAから独自のペンを受け取ることができます。修復パラメータベンダーIDは、各ベンダーに使用可能な2^32の個別の修復パラメータータイプを使用できるように、修復パラメータータイプフィールドを適格にします。IETFによって標準化された修復パラメータータイプは、このフィールドの値ゼロ（0）で常に使用されます。
Remediation Parameters Type (32 bits)
修復パラメータータイプ（32ビット）
The Remediation Parameters Type field identifies the different types of remediation instructions that can be contained in the Remediation Parameters field. IANA maintains a registry of PA-TNC Remediation Parameters Types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 7. A list of IETF Standard PA-TNC Remediation Parameters Types defined in this specification appears later in this section.
修復パラメータタイプフィールドは、修復パラメーターフィールドに含めることができるさまざまなタイプの修復命令を識別します。IANAは、PA-TNC修復パラメータータイプのレジストリを維持しています。このレジストリのエントリは、セクション7のガイドラインに従って、仕様が必要な専門家レビューによって追加されます。この仕様で定義されたIETF標準PA-TNC修復パラメータータイプのリストは、このセクションの後半に表示されます。
New vendor-specific remediation instructions can be created by adding new Remediation Parameters Types (those used with a non-zero Remediation Parameters vendor ID) without IETF or IANA involvement. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Remediation Parameters Types and MUST interoperate with other parties despite any differences in the set of vendor-specific PA-TNC Remediation Parameters Types supported (although they MAY permit administrators to configure them to require support for specific PA-TNC remediation parameter types).
新しいベンダー固有の修復命令は、IETFまたはIANAの関与なしに新しい修復パラメータータイプ（非ゼロ修復パラメーターベンダーIDで使用されるもの）を追加することで作成できます。姿勢コレクターと姿勢バリデーターは、特定のベンダー固有のPA-TNC修復パラメータタイプのサポートを必要としない必要があり、ベンダー固有のPA-TNC修復パラメータータイプのセットの違いにもかかわらず、他の関係者と相互運用する必要があります（ただし、管理者は管理者に許可する場合がありますが特定のPA-TNC修復パラメータータイプのサポートが必要になるように構成します）。
The following table lists the IETF Standard PA-TNC Remediation Parameters Type values defined in this specification:
次の表には、この仕様で定義されているIETF標準PA-TNC修復パラメータータイプ値を示します。
Integer Description
------- -----------
0 Reserved
1 Remediation URI
2 Remediation String
The next few subsections of this document provide detailed
definitions of the contents of the Remediation Parameters field
used with each Remediation Parameter Type.
Remediation Parameters (variable length)
修復パラメーター（変数長）
The Remediation Parameters field contains the actual remediation instructions for the Posture Collector.
修復パラメータフィールドには、姿勢コレクターの実際の修復命令が含まれています。
The Remediation URI Parameters Type is an IETF Standard Remediation Parameters Type (value 1) that indicates that the sending Posture Validator is providing a URI to instructions on how to remediate the endpoint.
Remediation URIパラメータータイプは、IETF標準修復パラメータータイプ（値1）です。これは、送信姿勢検証装置がエンドポイントの修復方法についての指示にURIを提供していることを示しています。
The following diagram illustrates the format and contents of the Remediation Parameters field when carrying a Remediation URI parameter. The text after this diagram describes the fields shown here.
次の図は、修復URIパラメーターを運ぶときの修復パラメーターフィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation URI (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Remediation URI
修復URI
The Remediation URI field MUST contain a URI, as described in RFC 3986 [7]. This URI SHOULD contain instructions to update a particular component so that it might result in the component being compliant with the policies in future assessments. Posture Collectors should validate that the URI and instructions come from a trustworthy source to avoid being tricked into performing damaging actions (see security considerations).
RFC 3986 [7]に記載されているように、修復URIフィールドにはURIが含まれている必要があります。このURIは、特定のコンポーネントを更新するための指示を含む必要があります。そうすれば、コンポーネントが将来の評価でポリシーに準拠する可能性があります。姿勢コレクターは、URIと指示が信頼できる情報源から来ていることを検証する必要があります。
The Remediation String Parameters Type is an IETF Standard Remediation Parameters Type (value 2) that indicates that the sending Posture Validator is providing a human-readable string containing instructions on how to remediate the endpoint.
Remediation Stringパラメータータイプは、IETF標準修復パラメータータイプ（値2）です。これは、送信姿勢検証装置がエンドポイントの修復方法に関する指示を含む人間の読み取り可能な文字列を提供していることを示しています。
The following diagram illustrates the format and contents of the Remediation Parameters field when the carrying a Remediation String parameter. The text after this diagram describes the fields shown here.
次の図は、修復文字列パラメーターを運ぶときの修復パラメーターの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Remediation String Lang Code (Variable Len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Remediation String Length
修復文字列の長さ
The Remediation String Length contains the length of the Remediation String field in octets.
修復文字列の長さには、オクテットの修復文字列フィールドの長さが含まれています。
Remediation String
修復文字列
The Remediation String field MUST contain a UTF-8 encoded string. This string contains human-readable instructions for remediation that MAY be displayed to the user by the Posture Collector. NUL termination MUST NOT be included. If a Posture Collector receives a Remediation String that does contain a NUL termination, it SHOULD send an Invalid Parameter error code.
修復文字列フィールドには、UTF-8エンコードされた文字列が含まれている必要があります。この文字列には、姿勢コレクターによってユーザーに表示される可能性のある修復のための人間の読み取り可能な命令が含まれています。NUL終了は含めてはなりません。姿勢コレクターがNUL終端を含む修復文字列を受信する場合、無効なパラメーターエラーコードを送信する必要があります。
Lang Code Len (Remediation String Language Code Length)
Lang CodeLen（修復文字列言語コードの長さ）
The Lang Code Len field contains the length of the Remediation String Language Code field in octets.
Lang Code Lenフィールドには、OctetsのRemediation String言語コードフィールドの長さが含まれています。
Remediation String Lang Code
修復文字列langコード
The Remediation String Lang(uage) Code field contains a US-ASCII string composed of a well-formed RFC 4646 [6] language tag that indicates the language(s) used in the Remediation String in the Remediation Parameters field. A zero-length string MAY be sent for this field (essentially omitting this field) to indicate that the language code for the remediation string is not known.
Remediation String Lang（UAGE）コードフィールドには、修復パラメータフィールドの修復文字列で使用されている言語を示す、よく形成されたRFC 4646 [6]言語タグで構成されるUS-ASCII文字列が含まれています。このフィールドにゼロ長さの文字列を送信して（本質的にこのフィールドを省略しています）、修復文字列の言語コードが不明であることを示します。
This PA-TNC attribute indicates whether the endpoint is forwarding traffic between interfaces. Endpoints that forward traffic between networks connected to multiple network interfaces may be considered non-compliant (and a security risk) in some enterprise network deployments. For example, an endpoint with multiple connected network interfaces might allow traffic from an interface connected to a public network to be forwarded through another interface carrying a VPN session to a protected enterprise network. This attribute is currently envisioned to be specific to reporting posture for the operating system component; however, could be useful for other future types of components.
このPA-TNC属性は、エンドポイントがインターフェイス間でトラフィックを転送しているかどうかを示します。複数のネットワークインターフェイスに接続されたネットワーク間のトラフィックを転送するエンドポイントは、一部のエンタープライズネットワークの展開で非準拠（およびセキュリティリスク）と見なされる場合があります。たとえば、複数の接続されたネットワークインターフェイスを備えたエンドポイントにより、パブリックネットワークに接続されたインターフェイスからのトラフィックを、VPNセッションを保護されたエンタープライズネットワークに運ぶ別のインターフェイスを介して転送できる場合があります。この属性は現在、オペレーティングシステムコンポーネントの姿勢を報告することに固有のものであると考えられています。ただし、他の将来の種類のコンポーネントに役立つ可能性があります。
Posture Collectors that implement the IETF Standard PA Subtype for Operating System SHOULD support sending the Forwarding Enabled attribute. Posture Collectors that do not implement the Operating System PA Subtype defined in this specification SHOULD NOT send the Forwarding Enabled attribute unless it is appropriate to their PA Subtype. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement the IETF Standard PA Subtype for Operating System SHOULD support receiving the Forwarding Enabled attribute type. Posture Validators supporting components other than Operating System MAY support receiving this attribute type if it is appropriate to their PA Subtype. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
オペレーティングシステムにIETF標準PAサブタイプを実装する姿勢コレクターは、転送可能な属性の送信をサポートする必要があります。この仕様で定義されているオペレーティングシステムPAサブタイプを実装していない姿勢コレクターは、PAサブタイプに適していない限り、転送可能な属性を送信してはなりません。特定の姿勢コレクターが実際にこの属性タイプを送信するかどうかは、現地のプライバシーとセキュリティポリシーによって依然として管理されるべきです。オペレーティングシステムにIETF標準PAサブタイプを実装するPosure Validatorsは、転送可能な属性タイプの受信をサポートする必要があります。オペレーティングシステム以外のコンポーネントをサポートする姿勢バリデーターは、PAサブタイプに適している場合、この属性タイプの受信をサポートする場合があります。この属性タイプの受信をサポートしていないPosure Validatorは、このタイプで属性を単純に無視する必要があります。姿勢バリデーターは、この属性タイプを送信してはなりません。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 11.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドをゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドを11に設定する必要があります。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Forwarding Enabled
転送が有効になっています
This 32-bit field MUST contain one of the following values;
この32ビットフィールドには、次の値のいずれかを含める必要があります。
Value Description
----- -----------
0 Disabled - Endpoint is not forwarding traffic.
1 Enabled - Endpoint is forwarding traffic.
1有効 - エンドポイントはトラフィックの転送です。
2 Unknown - Unable to determine whether endpoint is forwarding traffic
2不明 - エンドポイントがトラフィックを転送しているかどうかを判断できません
This PA-TNC attribute indicates whether the endpoint has a factory default password enabled for use. Some types of endpoints include a default static password for used to gain privileged access to the endpoint. If this password is not changed or disabled before the endpoint is accessible on the network, it's often easy to compromise the endpoint.
このPA-TNC属性は、エンドポイントにファクトリデフォルトのパスワードが有効になっているかどうかを示します。一部のタイプのエンドポイントには、エンドポイントへの特権アクセスを獲得するために使用されるデフォルトの静的パスワードが含まれます。エンドポイントにネットワーク上でアクセスできる前にこのパスワードが変更または無効になっていない場合、エンドポイントを妥協するのはしばしば簡単です。
Posture Collectors that implement the IETF Standard PA Subtype for Operating System SHOULD support sending the Factory Default Password Enabled attribute. Posture Collectors that implement other IETF Standard PA Subtypes defined in this specification SHOULD NOT support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending this attribute type, if it is appropriate to their PA subtype. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement the IETF Standard PA Subtype for Operating System SHOULD support receiving the Factory Default Password Enabled attribute. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
オペレーティングシステムにIETF標準PAサブタイプを実装する姿勢コレクターは、ファクトリーのデフォルトパスワード対応属性の送信をサポートする必要があります。この仕様で定義されている他のIETF標準PAサブタイプを実装する姿勢コレクターは、これらのPAサブタイプのこの属性タイプの送信をサポートしてはなりません。他の姿勢コレクターは、PAサブタイプに適している場合、この属性タイプの送信をサポートする場合があります。特定の姿勢コレクターが実際にこの属性タイプを送信するかどうかは、現地のプライバシーとセキュリティポリシーによって依然として管理されるべきです。オペレーティングシステムにIETF標準PAサブタイプを実装するPosure Validatorsは、工場出荷時のデフォルトパスワード対応属性の受信をサポートする必要があります。他の姿勢バリエーターは、この属性タイプの受信をサポートする場合があります。この属性タイプの受信をサポートしていないPosure Validatorは、このタイプで属性を単純に無視する必要があります。姿勢バリデーターは、この属性タイプを送信してはなりません。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 12.
この属性タイプの場合、PA-TNC属性ベンダーIDフィールドをゼロ（0）に設定する必要があり、PA-TNC属性タイプフィールドを12に設定する必要があります。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
次の図は、この属性タイプの属性値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Factory Default Password Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Factory Default Password Enabled
工場出荷時のデフォルトパスワードが有効になっています
This 32-bit field MUST contain one of the following values;
この32ビットフィールドには、次の値のいずれかを含める必要があります。
Value Description
----- -----------
0 Endpoint does not have factory default password enabled.
1 Endpoint has a factory default password enabled.
1エンドポイントには、工場出荷時のデフォルトパスワードが有効になっています。
This section discusses the use of vendor-defined attributes within PA-TNC. The PA-TNC protocol was designed to allow for vendor-defined attributes to be used as a replacement where a standard attribute could be used. In some cases, even the standard attributes allow for vendor-defined information to be included. It is envisioned that over time as particular vendor-defined attributes become popular, an equivalent standard attribute could be added allowing for broader interoperability.
このセクションでは、PA-TNC内のベンダー定義属性の使用について説明します。PA-TNCプロトコルは、ベンダー定義の属性を標準属性を使用できる置換として使用できるように設計されました。場合によっては、標準属性でさえベンダー定義の情報を含めることができます。特定のベンダー定義の属性が一般的になるにつれて、時間の経過とともに、同等の標準属性を追加して、より広い相互運用性を可能にすることができると想定されています。
This specification does not define vendor-defined attributes, but rather highlights how such attributes can be used with PA-TNC without the potential for namespace collisions or misinterpretations. In order to avoid collisions, PA-TNC uses the well-established SMI Private Enterprise Numbers as vendor IDs to define separate namespaces for important fields within a PA-TNC message. For example, to ensure the uniqueness of attribute types while providing for vendor extensions, vendor-defined attribute types include the vendor's unique vendor ID, to indicate the intended namespace for the attribute type, followed by the attribute type. IETF Standard PA-TNC Attribute Types use a vendor ID of zero (0).
この仕様は、ベンダー定義の属性を定義するのではなく、名前空間の衝突や誤解の可能性なしにPA-TNCでそのような属性をどのように使用できるかを強調しています。衝突を回避するために、PA-TNCは、確立されたSMIプライベートエンタープライズ番号をベンダーIDとして使用して、PA-TNCメッセージ内の重要なフィールドの個別の名前空間を定義します。たとえば、ベンダー拡張機能を提供しながら属性タイプの一意性を確保するために、ベンダー定義の属性タイプには、ベンダーの一意のベンダーIDが含まれており、属性タイプの意図した名前空間を示し、属性タイプが続きます。IETF標準PA-TNC属性タイプは、ゼロ（0）のベンダーIDを使用します。
SMI Private Enterprise Numbers are used to provide a separate identifier space for each vendor. The IANA provides a registry for SMI Private Enterprise Numbers. Any organization (including non-profit organizations, governmental bodies, etc.) can obtain one of these numbers at no charge, and thousands of organizations have done so. Within this document, SMI Private Enterprise Numbers are known as "vendor IDs".
SMIプライベートエンタープライズ番号は、各ベンダーに個別の識別子スペースを提供するために使用されます。IANAは、SMIプライベートエンタープライズ番号のレジストリを提供します。組織（非営利組織、政府機関など）は、これらの数値のいずれかを無料で取得でき、何千もの組織がそうしています。このドキュメント内では、SMIプライベートエンタープライズ番号は「ベンダーID」として知られています。
This section discusses the major potential types of security threats relevant to the PA-TNC message protocol. It is envisioned that additional attribute types could be defined in the future to facilitate the exchange of security capabilities, keys, and security protected attributes if future use cases are adopted that require such protections.
このセクションでは、PA-TNCメッセージプロトコルに関連する主要な潜在的なタイプのセキュリティ脅威について説明します。そのような保護を必要とする将来のユースケースが採用されている場合、セキュリティ能力、キー、およびセキュリティ保護属性の交換を促進するために、追加の属性タイプを将来定義できると想定されています。
In order to understand where security countermeasures are necessary, this section starts with a discussion of where the TNC architecture envisions some trust relationships between the processing elements of the PA-TNC protocol. The following subsections discuss the trust properties associated with each portion of the NEA reference model directly involved with the processing of the PA-TNC protocol.
セキュリティ対策が必要な場所を理解するために、このセクションは、TNCアーキテクチャがPA-TNCプロトコルの処理要素間の信頼関係を想定する場所についての議論から始まります。次のサブセクションでは、PA-TNCプロトコルの処理に直接関与するNEA参照モデルの各部分に関連付けられている信頼プロパティについて説明します。
The Posture Collectors are trusted by Posture Validators to:
姿勢コレクターは、姿勢バリデーターによって次のように信頼されています。
o Collect valid information about the component type associated with the Posture Collector
o 姿勢コレクターに関連付けられたコンポーネントタイプに関する有効な情報を収集する
o Report upon collected information consistent with local security and privacy policies
o 現地のセキュリティおよびプライバシーポリシーと一致する収集された情報に関する報告
o Accurately report information associated with the type of component for the PA-TNC message
o PA-TNCメッセージのコンポーネントのタイプに関連する情報を正確に報告する
o Not act maliciously to the Posture Broker Server and Posture Validators, including attacks such as denial of service
o 姿勢ブローカーサーバーや姿勢バリデーターに悪意を持って行動しないでください。
The Posture Validators are trusted by Posture Collectors to:
姿勢バリエーターは、姿勢コレクターによって次のように信頼されています。
o Only request information necessary to assess the security state of the endpoint
o エンドポイントのセキュリティ状態を評価するために必要な情報のみ
o Make assessment decisions based on deployer-defined policies
o 展開者定義のポリシーに基づいて評価を決定します
o Discard collected information consistent with data retention and privacy policies
o データ保持およびプライバシーポリシーと一致する収集された情報を廃棄する
o Not act maliciously to the Posture Broker Server and Posture Collectors, including attacks such as denial of service
o 姿勢ブローカーサーバーや姿勢コレクターに悪意を持って行動しないでください。
o Not send malicious remediation instructions that do not fix or that cause damage to the endpoint
o 修正しない、またはエンドポイントに損傷を引き起こす悪意のある修復指示を送信しない
The Posture Broker Client and Posture Broker Server are trusted by the Posture Collector and Posture Validator to:
姿勢ブローカーのクライアントと姿勢ブローカーサーバーは、姿勢コレクターと姿勢バリデーターによって信頼されています。
o Provide a reliable transport for PA-TNC messages
o PA-TNCメッセージの信頼できるトランスポートを提供します
o Deliver messages for a particular PA Subtype only to those Posture Collectors and Posture Validators that have registered for them
o 特定のPAサブタイプのメッセージをそれらに登録した姿勢コレクターと姿勢バリデーターにのみ配信します
o Not disclose any provided attributes to unauthorized parties o Not act maliciously to drop messages, duplicate messages, or flood Posture Collectors and Posture Validators with unnecessary messages
o 提供されていない属性を不正な関係者に開示しないoメッセージをドロップしたり、メッセージを複製したり、洪水の姿勢コレクターと不必要なメッセージを使用したりすることで、メッセージをドロップしたり、洪水の姿勢コレクターと姿勢を繰り返したりすることはありません
o Not observe, fabricate, or alter the contents of a PA-TNC message
o PA-TNCメッセージの内容を観察、製造、または変更しない
o Properly place Posture Collector and Posture Validator identifiers into the PB-TNC protocol, deliver those identifiers to Posture Collectors and Posture Validators as needed, and manage exclusive delivery to a particular Posture Collector or Posture Validator when requested
o 適切に姿勢コレクターと姿勢検証装置識別子をPB-TNCプロトコルに配置し、必要に応じて姿勢コレクターと姿勢バリエーターにそれらの識別子を配信し、要求されたときに特定の姿勢コレクターまたは姿勢バリデーターへの排他的配信を管理します
o Properly expose authentication information from PT security so that Posture Collectors and Posture Validators can use the peer's identity information to safely make policy decisions
o Pture Collectors and Possure ValidatorがPeerのID情報を使用して政策決定を安全に行うことができるように、PTセキュリティから認証情報を適切に公開します。
Beyond the trusted relationships assumed in section 5.1, the PA-TNC protocol faces a number of potential security attacks that could require security countermeasures.
セクション5.1で想定されている信頼できる関係を超えて、PA-TNCプロトコルは、セキュリティ対策を必要とする可能性のある多くの潜在的なセキュリティ攻撃に直面しています。
Generally, the PA-TNC protocol relies upon the underlying PT protocol's security to protect the messages from attack when traveling over the network. Once the message resides on the Posture Broker Client or Posture Broker Server, the posture brokers are trusted to properly and safely deliver the messages to the appropriate Posture Collectors and Posture Validators.
一般に、PA-TNCプロトコルは、ネットワーク上を移動するときに攻撃からメッセージを保護するために、基礎となるPTプロトコルのセキュリティに依存しています。メッセージが姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーに存在すると、姿勢ブローカーは、適切かつ安全に適切な姿勢コレクターと姿勢検証装置にメッセージを配信することが信頼されます。
When PA-TNC messages are sent over unprotected network links or spanning local software stacks that are not trusted, the contents of the PA-TNC messages may be subject to information theft by an intermediary party. This theft could result in information being recorded for future use or analysis by the adversary. Attributes observed by eavesdroppers could contain information that exposes potential weaknesses in the security of the endpoint, or system fingerprinting information easing the ability of the attacker to employ attacks more likely to be successful against the endpoint. The eavesdropper might also learn information about the endpoint or network policies that either singularly or collectively is considered sensitive information (e.g., certain endpoints are lacking patches, or particular sub-networks have more lenient policies).
PA-TNCメッセージが保護されていないネットワークリンクまたは信頼されていないローカルソフトウェアスタックにまたがる場合、PA-TNCメッセージの内容は、仲介者による情報盗難の対象となる場合があります。この盗難により、将来の使用または敵による分析のために情報が記録される可能性があります。盗聴者によって観察された属性には、エンドポイントのセキュリティの潜在的な弱点を暴露する情報、またはシステムフィンガープリント情報が攻撃者がエンドポイントに対して成功する可能性が高い攻撃を使用する能力を容易にする情報を含めることができます。盗聴者は、特異または集合的に機密情報と見なされるエンドポイントまたはネットワークポリシーに関する情報を学習する場合があります（たとえば、特定のエンドポイントにはパッチが不足しているか、特定のサブネットワークにはより寛大なポリシーがあります）。
PA-TNC attributes are not intended to carry privacy-sensitive information, but should some exist in a message, the adversary could come into possession of the information, which could be used for financial gain. Therefore, it is important that PT provide strong confidentiality protection to protect the message from eavesdroppers when being sent between the Posture Transport Client and Posture Transport Server.
PA-TNC属性は、プライバシーに敏感な情報を携帯することを意図したものではありませんが、メッセージに存在する場合、敵は情報の所有になり、金銭的利益に使用できる可能性があります。したがって、PTは、姿勢輸送クライアントと姿勢輸送サーバーの間に送信される際に、盗聴者からメッセージを保護するために強力な機密性保護を提供することが重要です。
Attackers on the network or present within the NEA system could introduce fabricated PA-TNC messages intending to trick or create a denial of service against aspects of an assessment. For example, an adversary could attempt to send a falsified set of remediation instructions using the Remediation URI support in hopes of the Posture Collector automatically following the instructions. Posture Collectors need to ensure that any requests to take actions on the endpoint (such as remediation instructions) received from Posture Validators are authentic and trustworthy using strong authentication and integrity protections offered by PT. Posture Collectors should not blindly follow remediation instructions received from a trusted NEA Server. At least for patches and other potentially dangerous actions, Posture Collectors should validate these actions (e.g., via user confirmation) before proceeding.
NEAシステム内のネットワーク上の攻撃者または存在は、評価の側面に対してサービスの拒否をトリックまたは作成することを目的とした製造されたPA-TNCメッセージを導入できます。たとえば、敵は、指示に従って自動的に姿勢コレクターを期待して、修復URIサポートを使用して、改善された一連の修復指示を送信しようとすることができます。姿勢コレクターは、姿勢バリーターから受け取ったエンドポイント（修復指示など）でアクションを実行するリクエストが、PTが提供する強力な認証と整合性保護を使用して本物で信頼できることを確認する必要があります。姿勢コレクターは、信頼できるNEAサーバーから受け取った修復指示に盲目的に従うべきではありません。少なくともパッチやその他の潜在的に危険なアクションの場合、姿勢コレクターは、進行前にこれらのアクション（たとえば、ユーザー確認を介して）を検証する必要があります。
Such an attack could occur if an active attacker launches a man-in-the-middle (MitM) attack by proxying the PA-TNC messages and was able to replace undesired messages with ones easing future attack upon the endpoint. Consider a scenario where PT security protection is not used and the Posture Broker Server proxies all assessment traffic to a remote Posture Broker Server. The proxy could eavesdrop and replace assessment results attributes, tricking the endpoint into thinking it has passed an assessment, when in fact it has not and requires remediation. Because the Posture Collector has no way to verify that attributes were actually created by an authentic Posture Validator, it is unable to detect the falsified attribute or message. Therefore, it is important that PT provides strong authentication and integrity protection.
このような攻撃は、アクティブな攻撃者がPA-TNCメッセージをプロキシすることにより中間（MITM）攻撃を開始し、望ましくないメッセージをエンドポイントへの将来の攻撃を緩和するものに置き換えることができた場合に発生する可能性があります。PTセキュリティ保護が使用されていないシナリオと、Positure Broker Serverがすべての評価トラフィックをリモートPosure Broker Serverにプロキシすることを考えてください。プロキシは、評価結果の属性を盗聴して置き換えることができ、実際には修復が必要であり、修復が必要な場合、エンドポイントを評価に合格したと思わせることができます。姿勢コレクターには、属性が実際に本物の姿勢バリーターによって作成されたことを確認する方法がないため、偽造属性またはメッセージを検出できません。したがって、PTが強力な認証と整合性の保護を提供することが重要です。
This attack could allow an active attacker capable of intercepting a message to modify a PA-TNC message attribute to a desired value to ease the compromise of an endpoint. Without the ability for message recipients to detect whether a received message contains the same content as what was originally sent, active attackers can stealthily modify the attribute exchange.
この攻撃により、メッセージを傍受できるアクティブな攻撃者が、PA-TNCメッセージ属性を希望の値に変更して、エンドポイントの妥協を緩和できるようになります。メッセージ受信者が受信したメッセージに最初に送信されたものと同じコンテンツが含まれているかどうかを検出する機能がないと、アクティブな攻撃者は属性交換を著しく変更できます。
For example, an attacker might wish to change the contents of the firewall component's version string attribute to disguise the fact that the firewall is running an old, vulnerable version. The attacker would change the version string sent by the firewall Posture Collector to the current version number, so the Posture Validator's assessment passes while leaving the endpoint vulnerable to attack. Similarly, an attacker could achieve widespread denial of service by altering large numbers of assessments' version string attributes to an old value so they repeatedly fail assessments even after a successful remediation. Upon receiving the lower value, the Posture Validator would continue to believe that the endpoint is running old, potentially vulnerable versions of the firewall that does not meet network compliance policy, so therefore the endpoint would not be allowed to join the network. Use of a PT protocol providing strong integrity protection and authentication is essential as countermeasures to these attacks.
たとえば、攻撃者は、ファイアウォールコンポーネントのバージョン文字列属性の内容を変更して、ファイアウォールが古い脆弱なバージョンを実行しているという事実を偽装したい場合があります。攻撃者は、ファイアウォール姿勢コレクターによって送信されたバージョン文字列を現在のバージョン番号に変更するため、姿勢バリエーターの評価は、エンドポイントを攻撃に対して脆弱なままにしながら通過します。同様に、攻撃者は、多数の評価のバージョン文字列属性を古い値に変更することにより、広範囲にわたるサービスの拒否を達成することができるため、修復が成功した後でも繰り返し評価に失敗します。より低い値を受信すると、Posture Validatorは、エンドポイントがネットワークコンプライアンスポリシーを満たさないファイアウォールの古い、潜在的に脆弱なバージョンを実行していると信じ続けます。したがって、エンドポイントはネットワークに参加できません。これらの攻撃への対策として、強力な整合性保護と認証を提供するPTプロトコルの使用が不可欠です。
Another potential attack against an unprotected PA-TNC message attribute exchange is to exploit the lack of a strong binding between the attributes sent during an assessment to the specific endpoint. Without a strong binding of the endpoint to the posture information, an attacker could record the attributes sent during an assessment of a compliant endpoint and later replay those attributes so that a non-compliant endpoint can now gain access to the network or protected resource. This attack could be employed by a network MitM that is able to eavesdrop and proxy message exchanges, or by using local rogue agents on the endpoints. Assessments lacking some form of freshness exchange could be subject to replay of prior assessment data, even if it no longer reflects the current state of the endpoint. Use of a PT protocol providing strong integrity protection and authentication including a freshness exchange is necessary countermeasure to these attacks.
保護されていないPA-TNCメッセージ属性交換に対する別の潜在的な攻撃は、特定のエンドポイントへの評価中に送信された属性間の強力な結合の欠如を活用することです。姿勢情報へのエンドポイントの強力な結合がなければ、攻撃者は、準拠したエンドポイントの評価中に送信された属性を記録し、後でそれらの属性を再生して、非準拠エンドポイントがネットワークまたは保護されたリソースにアクセスできるようにすることができます。この攻撃は、メッセージ交換とプロキシメッセージ交換を盗聴できるネットワークMITM、またはエンドポイントでローカルローグエージェントを使用することができるネットワークMITMによって使用できます。何らかの形の鮮度交換を欠く評価は、エンドポイントの現在の状態を反映しなくても、以前の評価データの再生の対象となる可能性があります。PTプロトコルの使用は、これらの攻撃に必要な対策を講じることが必要です。
Similar to the attribute modification attacks, an adversary wishing to include one or more attributes or PA-TNC messages inside a valid assessment may be able to insert the attributes or messages without detection by the recipient. For example, an attacker could add attributes to the front of a PA-TNC message to cause an assessment to succeed even for a non-compliant endpoint, particularly if it knew that the recipient ignored repeated attributes within a message. Similarly, if a Posture Collector or Posture Validator always generated an error if it saw unexpected attributes, the attacker could cause failures and denial of service by adding attributes or messages to an exchange. Use of a PT protocol providing strong authentication and integrity protection could prevent the adversary from inserting attributes into the assessment.
属性修正攻撃と同様に、有効な評価内に1つ以上の属性またはPA-TNCメッセージを含めることを希望する敵は、受信者による検出なしに属性またはメッセージを挿入できる場合があります。たとえば、攻撃者は、PA-TNCメッセージの前面に属性を追加して、特に受信者がメッセージ内の繰り返し属性を無視していることを知っていた場合でも、非準拠エンドポイントでも評価を成功させることができます。同様に、姿勢コレクターまたは姿勢検証装置が予期しない属性を見た場合、常にエラーを生成した場合、攻撃者は属性またはメッセージを交換に追加することにより、失敗とサービス拒否を引き起こす可能性があります。強力な認証と整合性保護を提供するPTプロトコルの使用は、敵が評価に属性を挿入することを妨げる可能性があります。
A variety of types of denial-of-service attacks are possible against the PA-TNC message exchange if left unprotected from untrusted parties along the communication path between the Posture Collector and Posture Validator. Normally, the PT exchange is bidirectionally authenticated, which helps to prevent a MitM on the network from becoming an active proxy, but transparent message routing gateways may still exist on the communication path and can modify the integrity of the message exchange unless adequate integrity protection is provided. If the MitM or other entities on the network can send messages to the Posture Broker Client or Posture Broker Server that appear to be part of an assessment, these messages could confuse the Posture Collector and Posture Validator or cause them to perform unnecessary work or take incorrect action. Several example denial-of-service situations are described in sections 5.2.3 and 5.2.5. Many potential denial-of-service examples exist, including flooding messages to the Posture Collector or Posture Validator, sending very large messages containing many attributes, and repeatedly asking for resource-intensive operations.
PA-TNCメッセージ交換は、PA-TNCメッセージ交換に対して、姿勢コレクターと姿勢検証装置の間の通信パスに沿って信頼されていない当事者から保護されていない場合、さまざまな種類のサービス攻撃に対して可能です。通常、PT交換は双方向に認証されているため、ネットワーク上のMITMがアクティブなプロキシになるのを防ぐのに役立ちますが、通信パスには透明なメッセージルーティングゲートウェイが存在し、適切な整合性保護がない限り、メッセージ交換の整合性を変更できます。提供された。ネットワーク上のMITMまたは他のエンティティが評価の一部であると思われる姿勢ブローカークライアントまたは姿勢ブローカーサーバーにメッセージを送信できる場合、これらのメッセージは姿勢コレクターと姿勢検証装置を混同したり、不必要な作業を実行したり、不正確な作業を実行したりする可能性があります。アクション。サービスの拒否状況のいくつかの例については、セクション5.2.3および5.2.5で説明しています。姿勢コレクターまたは姿勢バリデーターへのフラッディングメッセージ、多くの属性を含む非常に大きなメッセージの送信、リソース集約型の操作を繰り返し要求するなど、多くの潜在的なサービス拒否の例が存在します。
The PA-TNC protocol is designed to allow for controlled disclosure of security-relevant information about an endpoint, specifically for the purpose of enabling an assessment of the endpoint's compliance with network policy. The purpose of this protocol is to provide visibility into the state of the protective mechanisms on the endpoint, in order for the Posture Validators and Posture Broker Server to determine whether the endpoint is up to date and thus has the best chance of being resilient in the face of malware threats. One risk associated with providing visibility into the contents of an endpoint is the increased chance for exposure of privacy-sensitive information without the consent of the user.
PA-TNCプロトコルは、特にエンドポイントのネットワークポリシーへのコンプライアンスの評価を可能にする目的で、エンドポイントに関するセキュリティ関連情報の制御された開示を可能にするように設計されています。このプロトコルの目的は、姿勢バリエーターと姿勢ブローカーサーバーがエンドポイントが最新であるかどうかを判断するために、エンドポイント上の保護メカニズムの状態を可視化することです。マルウェアの脅威の顔。エンドポイントの内容への可視性を提供することに関連する1つのリスクは、ユーザーの同意なしにプライバシーに敏感な情報を露出させる可能性が高まることです。
While this protocol does provide the Posture Validator the ability to request specific information about the endpoint, the protocol is not open ended, bounding the Posture Validator to only query specific information (attributes) about specific security features (component types) of the endpoint. Each PA-TNC message is explicitly about a single component from the list of components in section 3.5. These components include a list of security-related aspects of the endpoint that affect the ability of the endpoint to resist attacks and thus are of interest during an assessment. Discretionary components used by the user to create or view content are not on the list, as they are more likely to have access to privacy-sensitive information.
このプロトコルは、姿勢バリエーターにエンドポイントに関する特定の情報を要求する機能を提供しますが、プロトコルはオープンエンドではなく、姿勢バリーターをエンドポイントの特定のセキュリティ機能（コンポーネントタイプ）に関する特定の情報（属性）のみをクエリするように制限します。各PA-TNCメッセージは、セクション3.5のコンポーネントのリストからの単一のコンポーネントについて明示的にあります。これらのコンポーネントには、攻撃に抵抗するエンドポイントの能力に影響するエンドポイントのセキュリティ関連の側面のリストが含まれているため、評価中に関心があります。ユーザーがコンテンツを作成または表示するために使用する裁量的コンポーネントは、プライバシーに敏感な情報にアクセスできる可能性が高いため、リストに載っていません。
Similarly, PA-TNC messages contain a set of attributes that describe the particular component. Each attribute contains generic information (e.g., product information or versions) about the component, so it is unlikely to include any user-specific or identifying information. This combination of a limited set of security-related components with non-user-specific attributes greatly reduces the risk of exposure of privacy-sensitive information. Vendors that choose to define additional component types and/or attributes within their namespace are encouraged to provide similar constraints.
同様に、PA-TNCメッセージには、特定のコンポーネントを記述する一連の属性が含まれています。各属性には、コンポーネントに関する一般的な情報（製品情報やバージョンなど）が含まれているため、ユーザー固有または識別情報を含めることはほとんどありません。限られたセキュリティ関連コンポーネントのセットと非ユーザー固有の属性の組み合わせは、プライバシーに敏感な情報の暴露リスクを大幅に減らします。名前空間内の追加のコンポーネントタイプおよび/または属性を定義することを選択したベンダーは、同様の制約を提供することをお勧めします。
Even with the bounding of standard attribute information to specific components, it is possible that individuals might wish to share less information with different networks they wish to access. For example, a user may wish to share more information when connecting to or being reassessed by the user's employer network than what would be made available to the local coffee shop wireless network. While these situations do not impact the protocol itself, they do suggest that Posture Collector implementations should consider supporting a privacy filter allowing the user and/or system owner to restrict access to certain attributes based upon the target network.
特定のコンポーネントへの標準属性情報の限界があっても、個人がアクセスしたい異なるネットワークとより少ない情報を共有したいと思う可能性があります。たとえば、ユーザーは、地元のコーヒーショップワイヤレスネットワークで利用できるものよりも、ユーザーの雇用主ネットワークに接続または再評価されるときに、より多くの情報を共有したい場合があります。これらの状況はプロトコル自体に影響を与えませんが、姿勢コレクターの実装は、ユーザーおよび/またはシステムの所有者がターゲットネットワークに基づいて特定の属性へのアクセスを制限できるようにプライバシーフィルターをサポートすることを検討する必要があることを示唆しています。
The underlying PT protocol authenticates the network's Posture Broker Server at the start of an assessment, so identity can be made available to the Posture Collector and per-network privacy filtering is possible. Network owners should make available a list of the attributes they require to perform an assessment and any privacy policy they enforce when handling the data. Users wishing to use a more restricted privacy filter on the endpoint may risk not being able to pass an assessment and thus not gain access to the requested network or resource.
基礎となるPTプロトコルは、評価の開始時にネットワークの姿勢ブローカーサーバーを認証するため、姿勢コレクターが利用できるようになり、ネットワークごとのプライバシーフィルタリングが可能になります。ネットワーク所有者は、データを処理する際に実施する評価を実行するために必要な属性のリストを利用できるようにする必要があります。エンドポイントでより制限されたプライバシーフィルターを使用したいユーザーは、評価に合格できないため、要求されたネットワークまたはリソースにアクセスできないリスクがあります。
This section defines the contents of three new IANA registries: PA-TNC Attribute Types, PA-TNC Error Codes, and PA-TNC Remediation Parameters Types. This section explains how these registries work. Also, this specification defines several new PA Subtypes for use with PA-TNC.
このセクションでは、PA-TNC属性タイプ、PA-TNCエラーコード、およびPA-TNC修復パラメータータイプの3つの新しいIANAレジストリの内容を定義します。このセクションでは、これらのレジストリがどのように機能するかについて説明します。また、この仕様では、PA-TNCで使用するためのいくつかの新しいPAサブタイプを定義します。
All of the registries defined in this document support IETF standard values and vendor-defined values. To explain this phenomenon, we will use the PA-TNC Attribute Type as an example, but the other three registries work the same way. Whenever a PA-TNC Attribute Type appears on a network, it is always accompanied by an SMI Private Enterprise Number (PEN), also known as a vendor ID. If this vendor ID is zero, the accompanying PA-TNC Attribute Type is an IETF standard value listed in the IANA registry for PA-TNC Attribute Types, and its meaning is defined in the specification listed for that PA-TNC Attribute Type in that registry. If the vendor ID is not zero, the meaning of the PA-TNC Attribute Type is defined by the vendor identified by the vendor ID (as listed in the IANA registry for SMI PENs). The identified vendor is encouraged but not required to register with IANA some or all of the PA-TNC Attribute Types used with their vendor ID and publish a specification for each of these values.
このドキュメントで定義されているすべてのレジストリは、IETF標準値とベンダー定義値をサポートしています。この現象を説明するために、PA-TNC属性タイプを例として使用しますが、他の3つのレジストリも同じように機能します。PA-TNC属性タイプがネットワークに表示されるたびに、ベンダーIDとも呼ばれるSMIプライベートエンタープライズ番号（PEN）が常に添付されます。このベンダーIDがゼロの場合、付随するPA-TNC属性タイプは、PA-TNC属性タイプのIANAレジストリにリストされているIETF標準値であり、その意味は、そのレジストリのPA-TNC属性タイプのリストされている仕様で定義されています。。ベンダーIDがゼロでない場合、PA-TNC属性タイプの意味は、ベンダーIDによって識別されたベンダーによって定義されます（SMIペンのIANAレジストリに記載されています）。識別されたベンダーは奨励されていますが、ベンダーIDで使用されているPA-TNC属性タイプの一部またはすべてをIANAに登録し、これらの各値の仕様を公開する必要はありません。
This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require support for particular vendor-specific values. However, such behavior is explicitly prohibited by this specification (in section 4.1), which dictates that "Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Attribute Types and MUST interoperate with other parties despite any differences in the set of vendor-specific PA-TNC Attribute Types supported (although they MAY permit administrators to configure them to require support for specific PA-TNC Attribute Types)". Similar requirements are included for PA Subtypes, Remediation Parameters Types, and PA-TNC Error Codes.
この名前空間の委任は、OIDに使用される手法に類似しています。ベンダーが特定のベンダー固有の値をサポートする必要がある場合、相互運用性の問題を引き起こす可能性があります。ただし、このような動作は、この仕様（セクション4.1の）によって明示的に禁止されており、「姿勢コレクターと姿勢バリーターは特定のベンダー固有のPA-TNC属性のサポートを必要としてはならず、他の当事者と相互に操作する必要があります。サポートされているベンダー固有のPA-TNC属性タイプのセット（特定のPA-TNC属性タイプのサポートを要求するように管理者がそれらを構成することを許可する場合があります）。PAサブタイプ、修復パラメータータイプ、およびPA-TNCエラーコードについても同様の要件が含まれています。
For all of the IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [3].
この仕様で定義されたすべてのIANAレジストリについて、RFC 5226 [3]で定義された指定されたエキスパートプロセスを使用して、必要な仕様を使用して専門家のレビューにより、新しい値がレジストリに追加されます。
This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for these registries.
このセクションでは、指定された専門家へのガイダンスを提供して、これらのレジストリに適した哲学を使用して決定を下すことができます。
The registries defined in this document have plenty of values. In most cases, the IETF has approximately 2^32 values available for it to define and each vendor the same number of values for its use. Because there are so many values available, designated experts should not be terribly concerned about exhausting the set of values.
このドキュメントで定義されているレジストリには、多くの価値があります。ほとんどの場合、IETFには約2^32の値が定義し、各ベンダーが使用するために同じ数の値を使用できます。利用可能な価値が非常に多いため、指定された専門家は、価値のセットを使い果たすことをひどく懸念すべきではありません。
Instead, designated experts should focus on the following requirements. All values in these IANA registries MUST be documented in a specification that is permanently and publicly available. IETF standard values MUST also be useful, not harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability.
代わりに、指定された専門家は次の要件に焦点を当てる必要があります。これらのIANAレジストリのすべての値は、永続的かつ公開されている仕様に文書化する必要があります。IETF標準値も有用であり、インターネットに有害ではなく、明確で相互運用性を確保する可能性が高い方法で定義されている必要があります。
Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single IETF standard value. However, it is beneficial to document existing practice.
指定された専門家は、ベンダーが同様のが互換性のない値を定義することを避け、代わりに単一のIETF標準値に同意するように奨励する必要があります。ただし、既存の実践を文書化することは有益です。
There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor MUST supply a copy to the IANA and authorize the IANA to archive this copy and make it freely available to all if at some point the document becomes no longer freely available to all through other channels.
仕様が永続的かつ公開されていることを確認するには、いくつかの方法があります。RFCとして公開される場合があります。あるいは、誰でも自由に利用できるようにする別の方法で公開される場合があります。ただし、この後者の場合、ベンダーはIANAにコピーを提供し、IANAがこのコピーをアーカイブすることを許可し、ある時点でドキュメントが他のチャネル全体で自由に利用できなくなった場合、すべてを自由に利用できるようにする必要があります。
Section 7.2 defines the new PA Subtypes. The following three sections provide guidance to the IANA in creating and managing the new IANA registries defined by this specification.
セクション7.2は、新しいPAサブタイプを定義しています。次の3つのセクションでは、この仕様で定義された新しいIANAレジストリの作成と管理におけるIANAへのガイダンスを提供します。
Section 3.5 of this specification defines several new PA Subtypes that have been added to the PA Subtypes registry defined in the PB-TNC specification. Here is a list of these assignments:
この仕様のセクション3.5では、PB-TNC仕様で定義されたPAサブタイプレジストリに追加されたいくつかの新しいPAサブタイプを定義します。これらの割り当てのリストは次のとおりです。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Testing RFC 5792
0 1 Operating System RFC 5792
0 2 Anti-Virus RFC 5792
0 3 Anti-Spyware RFC 5792
0 4 Anti-Malware RFC 5792
0 5 Firewall RFC 5792
0 6 IDPS RFC 5792
0 7 VPN RFC 5792
0 8 NEA Client RFC 5792
These PA Subtypes have been added to the registry for PA Subtypes defined in the PB-TNC specification, with this RFC as the reference.
これらのPAサブタイプは、PB-TNC仕様で定義されたPAサブタイプのレジストリに追加され、このRFCは参照としてこのRFCです。
The name for this registry is "PA-TNC Attribute Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference to the specification where the contents of this attribute type are defined. This specification must define the meaning of this PA-TNC attribute type and the format and semantics of the PA-TNC Attribute Value field for PA-TNC attributes that include the designated Private Enterprise Number in the PA-TNC Attribute Vendor ID field and the designated numeric value in the PA-TNC Attribute Type field.
このレジストリの名前は「PA-TNC属性タイプ」です。このレジストリの各エントリには、人間の読み取り可能な名前、SMIプライベートエンタープライズ番号、0〜2^32-1の小数整数値、およびこの属性タイプの内容が定義されている仕様への参照を含める必要があります。この仕様は、このPA-TNC属性タイプの意味と、PA-TNC属性ベンダーIDフィールドの指定されたプライベートエンタープライズ番号を含むPA-TNC属性のPA-TNC属性値フィールドの形式とセマンティクスを定義する必要があります。PA-TNC属性タイプフィールドの数値。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PA-TNC Attribute Types. Additional entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 7.1.
このレジストリの次のエントリは、このドキュメントで定義されています。これらは、PA-TNC属性タイプのレジストリの初期エントリです。このレジストリへの追加のエントリは、セクション7.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Testing RFC 5792
0 1 Attribute Request RFC 5792
0 2 Product Information RFC 5792
0 3 Numeric Version RFC 5792
0 4 String Version RFC 5792
0 5 Operational Status RFC 5792
0 6 Port Filter RFC 5792
0 7 Installed Packages RFC 5792
0 8 PA-TNC Error RFC 5792
0 9 Assessment Result RFC 5792
0 10 Remediation Instructions RFC 5792
0 11 Forwarding Enabled RFC 5792
0 12 Factory Default Password RFC 5792
Enabled
0 0xffffffff Reserved RFC 5792
The name for this registry is "PA-TNC Error Codes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference to the specification where this error code is defined. This specification must define the meaning of this error code and the format and semantics of the Error Information field for PA-TNC attributes that have a PA-TNC vendor ID of 0, a PA-TNC Attribute Type of PA-TNC Error, the designated Private Enterprise Number in the PA-TNC Error Code Vendor ID field, and the designated numeric value in the PA-TNC Error Code field.
このレジストリの名前は「PA-TNCエラーコード」です。このレジストリの各エントリには、人間の読み取り可能な名前、SMIプライベートエンタープライズ番号、0〜2^32-1の間の小数整数値、およびこのエラーコードが定義されている仕様への参照が含まれます。この仕様は、このエラーコードの意味と、0のPA-TNCベンダーIDを持つPA-TNC属性のエラー情報フィールドの形式とセマンティクスを定義する必要があります。PA-TNCエラーコードベンダーIDフィールドのプライベートエンタープライズ番号、およびPA-TNCエラーコードフィールドの指定された数値。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PA-TNC Error Codes. Additional entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 7.1.
このレジストリの次のエントリは、このドキュメントで定義されています。これらは、PA-TNCエラーコードのレジストリの初期エントリです。このレジストリへの追加のエントリは、セクション7.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 Invalid Parameter RFC 5792
0 2 Version Not Supported RFC 5792
0 3 Attribute Type Not Supported RFC 5792
The name for this registry is "PA-TNC Remediation Parameters Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 1 and 2^32-1, and a reference to the specification where the contents of this remediation parameters type are defined. This specification must define the meaning of this PA-TNC Remediation Parameters Type and the format and semantics of the Remediation Parameters field for PA-TNC attributes that include the designated Private Enterprise Number in the Remediation Parameters Vendor ID field and the designated numeric value in the Remediation Parameters Type field.
このレジストリの名前は「PA-TNC修復パラメータータイプ」です。このレジストリの各エントリには、人間の読み取り可能な名前、SMIプライベートエンタープライズ番号、1〜2^32-1の小数整数値、およびこの修復パラメータータイプの内容が定義されている仕様への参照を含める必要があります。この仕様は、このPA-TNC修復パラメータータイプの意味と、修復パラメーターベンダーIDフィールドの指定されたプライベートエンタープライズ番号と、指定された数値を含むPA-TNC属性の修復パラメーターフィールドの形式とセマンティクスを定義する必要があります。修復パラメータータイプフィールド。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PA-TNC Remediation Parameters Types. Additional entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 7.1.
このレジストリの次のエントリは、このドキュメントで定義されています。これらは、PA-TNC修復パラメータータイプのレジストリの初期エントリです。このレジストリへの追加のエントリは、セクション7.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 URI RFC 5792
0 2 Remediation String RFC 5792
Thanks to the Trusted Computing Group for contributing the initial text [8] upon which this document was based. The authors would also like to acknowledge the following people who have contributed to or provided substantial input on the preparation of this document or predecessors to it: Stuart Bailey, Roger Chickering, Lauren Giroux, Charles Goldberg, Steve Hanna, Ryan Hurst, Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, PJ Kirner, Houcheng Lee, Lisa Lorenzin, Mahalingam Mani, Sung Lee, Ravi Sahita, Mauricio Sanchez, Brad Upson, and Han Yin.
このドキュメントが基づいている最初のテキスト[8]を貢献してくれた信頼できるコンピューティンググループに感謝します。著者はまた、この文書またはその前任者の準備に貢献した、または提供した以下の人々を認めたいと思います：スチュアート・ベイリー、ロジャー・チカリング、ローレン・ジルー、チャールズ・ゴールドバーグ、スティーブ・ハンナ、ライアン・ハースト、ミーナキシク、グレッグ・カズミエルカック、スコット・ケリー、PJキーナー、フーシェン・リー、リサ・ロレンツィン、マハリンガム・マニ、ソン・リー、ラビ・サヒタ、マウリシオ・サンチェス、ブラッド・アップソン、ハン・イン。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[2] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[3] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[4] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[4] Klyne、G。and C. Newman、「インターネット上の日時：タイムスタンプ」、RFC 3339、2002年7月。
[5] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010.
[5] Sahita、R.、Hanna、S.、Hurst、R。、およびK. Narayan、「PB-TNC：姿勢ブローカー（PB）プロトコル信頼ネットワークConnect（TNC）と互換性がある」、RFC 5793、2010年3月。
[6] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[6] Phillips、A.、ed。、およびM. Davis、ed。、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[8] Trusted Computing Group, "IF-M: TLV Binding", http://www.trustedcomputinggroup.org/resources/ tnc_ifm_tlv_binding_specification, February 2010.
[8] 信頼できるコンピューティンググループ、「IF-M：TLVバインディング」、http：//www.trustedcomputinggroup.org/resources/ tnc_ifm_tlv_bindient_specification、2010年2月。
[9] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[9] Sangster、P.、Khosravi、H.、Mani、M.、Narayan、K。、およびJ. Tardo、「ネットワークエンドポイント評価（NEA）：概要と要件」、RFC 5209、2008年6月。
This scenario involves the assessment of an endpoint initiated during network join. The assessment is triggered by the Posture Broker Client (PBC) and involves collection of patch information from both Standard Operating System (OS) Posture Collector and vendor-specific Patch Posture Collector (PC). The assessment by both the vendor-specific Patch Posture Validator (PV) and Standard OS Posture Validator result in a compliant assessment decision that results in a compliant System Assessment Decision to be returned by the Posture Broker Server (PBS).
このシナリオには、ネットワーク結合中に開始されたエンドポイントの評価が含まれます。この評価は、姿勢ブローカークライアント（PBC）によってトリガーされ、標準オペレーティングシステム（OS）姿勢コレクターとベンダー固有のパッチ姿勢コレクター（PC）の両方からのパッチ情報の収集が含まれます。ベンダー固有のパッチ姿勢検証装置（PV）と標準のOS姿勢検証装置の両方による評価により、姿勢ブローカーサーバー（PBS）によって返される準拠システム評価決定をもたらす準拠の評価決定が得られます。
+--------+ +-------+ +---------+ +--------+ +-------++--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
+--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+
| | N/W Join| | | |
| | ----->| | | |
| | Req Post. | | | |
| |<----------| | | |
| | Req Post. | | | |
|<--------------------| | | |
|Vndr X Patch Posture | | | |
|-------------------->| | | |
| |OS Posture | | | |
| |---------->| | | |
| | | Posture | | |
| | | Report | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |---------> |
| | | | | Verify |
| | | | | Posture |
| | | |------------------->|
| | | | OS Reslt | |
| | | |<---------| |
| | | | VndrX Patch Result |
| | | Assess |<-------------------|
| | | Result | |
| | |<--------| | |
| | OS Reslt | | | |
| |<----------| | | |
| VndrX Patch Result | | | |
|<--------------------| | | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
このセクションでは、このユースケースで交換されるPAメッセージのそれぞれの重要なフィールドの内容を示しています。必要に応じて、特定のフィールドに表示された値が含まれている理由を説明するために、追加の解説が提供されます。表示されるフローの多くは同じシステム上のコンポーネント間にあるため、メッセージの内容は表示されないことに注意してください。
This flow represents the event that causes the PBC to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and does not include a message being sent.
このフローは、PBCがネットワークにアクセスするためにエンドポイントの評価を開始することを決定するイベントを表しています。これは単なるイベントであり、送信されるメッセージは含まれていません。
This flow illustrates an invocation of the OS and patch posture collectors requesting particular posture attributes to be sent. Because this use case is triggered locally, the contents of this flow aren't specified by NEA.
このフローは、特定の姿勢属性を送信することを要求するOSとパッチ姿勢コレクターの呼び出しを示しています。このユースケースはローカルでトリガーされるため、このフローの内容はNEAで指定されていません。
This flow contains the PA message from the Patch Posture Collector:
このフローには、パッチ姿勢コレクターからのPAメッセージが含まれています。
Vendor X Patch Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1 (vendor X)
type=1 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute1=123
}
}
Attribute 2 {
vendor-id=1 (vendor X)
type=2 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute2=456
}
}
}
This flow contains the PA message from the OS Posture Collector:
このフローには、OS姿勢コレクターからのPAメッセージが含まれています。
OS Posture PA Message {
os posure pa message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
Product-vendor-id=311 -- Microsoft's PEN
Product-name="Windows Vista"
}
}
Attribute 2 {
vendor-id=0
type=3 (numeric version)
length
Value = {
major-version=6 -- Vista is version 6.0
minor-version=0
build-number=456789
service-pack-major=0 -- No service packs
service-pack-minor=0
}
}
}
This flow contains the PB message containing the PA messages from the Patch and OS Posture Collectors; the message content is described in the PB-TNC specification.
このフローには、パッチとOSの姿勢コレクターからのPAメッセージを含むPBメッセージが含まれています。メッセージコンテンツは、PB-TNC仕様で説明されています。
This flow illustrates an invocation of the OS and patch Posture Validators requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA does not specify the message contents.
このフローは、受信した姿勢属性の検証を要求するOSとパッチ姿勢バリデーターの呼び出しを示しています。このフローはNEAサーバー内で局所的に発生するため、NEAはメッセージの内容を指定しません。
This flow contains the PA message (Posture Assessment Result) from the OS Posture Validator
このフローには、OS姿勢バリデーターからのPAメッセージ（姿勢評価結果）が含まれています
OS Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
This flow contains the PA message (Posture Assessment Result) from the Vendor X Patch Posture Validator
このフローには、ベンダーXパッチ姿勢バリーターからのPAメッセージ（姿勢評価結果）が含まれています
Patch Vendor X Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the Patch and OS Posture Validators; the message content is described in the PB-TNC specification.
このフローには、姿勢ブローカーサーバーによって計算されたシステム評価結果と、パッチおよびOS姿勢バリエーターからのPAメッセージを含むPBメッセージが含まれています。メッセージコンテンツは、PB-TNC仕様で説明されています。
These flows illustrate an invocation of the OS and Vendor X Patch Posture Collectors to receive the posture assessment results. Because this flow is triggered locally, NEA does not specify the contents of this flow.
これらのフローは、姿勢評価の結果を受け取るために、OSおよびベンダーXパッチ姿勢コレクターの呼び出しを示しています。このフローはローカルでトリガーされるため、NEAはこのフローの内容を指定しません。
This scenario involves the assessment of an endpoint initiated by the NEA Server. The assessment is triggered by the Posture Broker Server and involves collection of Anti-Virus attributes for two Anti-Virus components running on the endpoint. The endpoint is assessed to be compliant by one of the vendor (Vendor X) anti-virus Posture Validators and non-compliant by the other vendor (Vendor Y) anti-virus Posture Validator. Based upon the Posture Broker Server's policy, this results in a non-compliant system assessment decision to be returned by the Posture Broker Server. The Posture Broker Server also returns remediation instructions for the endpoint as part of the response.
このシナリオには、NEAサーバーによって開始されたエンドポイントの評価が含まれます。この評価は、姿勢ブローカーサーバーによってトリガーされ、エンドポイントで実行されている2つのウイルス対策コンポーネントの属性の収集が含まれます。エンドポイントは、ベンダー（ベンダーX）アンチウイルス姿勢検証装置の1つによって準拠し、他のベンダー（ベンダーY）アンチウイルス姿勢検証装置によって非準拠していると評価されます。姿勢ブローカーサーバーのポリシーに基づいて、これにより、姿勢ブローカーサーバーによって返されるという非準拠システム評価決定が行われます。Posture Broker Serverは、応答の一部としてエンドポイントの修復命令も返します。
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | ------->| | |
| | | | Create | |
| | | |Post. Req | |
| | | |--------->| |
| | | |Create Posture Req |
| | | |----------+--------->|
| | | | Vndr Y AV Post Req |
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post. Req | |
| | | Posture |<---------| |
| | | Request | | |
| | Vndr X AV |<--------| | |
| | Post. Req | | | |
| |<----------| | | |
| Vndr Y AV | | | |
| Posture Req | | | |
+<---------+-----------| | | |
| Vndr Y AV Posture | | | |
+----------+---------->| | | |
| | Vndr X AV | | | |
| | Posture | | | |
| |---------->| Posture | | |
| | |Response | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |--------->| |
| | | | Verify Posture |
| | | |----------+--------->|
| | | |Vndr Y AV Post Result|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post Reslt| |
| | | Assess |<---------| |
| | | Result | | |
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
+<---------+-----------| | | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
このセクションでは、このユースケースで交換されるPAメッセージのそれぞれの重要なフィールドの内容を示しています。必要に応じて、特定のフィールドに表示された値が含まれている理由を説明するために、追加の解説が提供されます。表示されるフローの多くは同じシステム上のコンポーネント間にあるため、メッセージの内容は表示されないことに注意してください。
This flow represents the event that causes the PBS to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and does not include a message being sent.
このフローは、ネットワークにアクセスするためにPBSがエンドポイントの評価を開始することを決定するイベントを表しています。これは単なるイベントであり、送信されるメッセージは含まれていません。
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Validators enabling posture request attributes to be created. Because this use case is triggered locally, NEA does not specify the contents of this flow.
このフローは、ベンダーXおよびベンダーYアンチウイルス姿勢バリデーターの呼び出しを、姿勢要求属性を作成できることを示しています。このユースケースはローカルでトリガーされるため、NEAはこのフローの内容を指定しません。
This flow contains the PA message (Posture Request) from the Vendor Y Anti-Virus Posture Validator
このフローには、ベンダーYアンチウイルス姿勢検証装置からのPAメッセージ（姿勢要求）が含まれています
Vendor Y AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
Vendor-id=1 (Vendor Y)
Type=2 (Vendor Y attribute, Extended-Dat-Version)
}
}
}
This flow contains the PA message (Posture Request) from the Vendor X Anti-Virus Posture Validator
このフローには、ベンダーXアンチウイルス姿勢検証装置からのPAメッセージ（姿勢要求）が含まれています
Vendor X AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=1 (Vendor X)
Type=1 (Vendor X attribute, Scan-Engine-Version)
Vendor-id=0 (IETF Standard)
Type=5 (Standard, Operational-Status)
}
}
}
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators; the message content is described in the PB-TNC specification.
このフローには、ベンダーXおよびベンダーYアンチウイルス姿勢検証装置からのPAメッセージを含むPBメッセージが含まれています。メッセージコンテンツは、PB-TNC仕様で説明されています。
These flows illustrate an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to process the Posture Request and return the particular posture attributes requested. Because this flow is triggered locally, NEA does not specify the contents of this flow.
これらのフローは、ベンダーXおよびベンダーYアンチウイルス姿勢コレクターの呼び出しを示しており、姿勢要求を処理し、要求された特定の姿勢属性を返します。このフローはローカルでトリガーされるため、NEAはこのフローの内容を指定しません。
This flow contains the PA message (response to the Posture Request) from the Vendor Y Anti-Virus Posture Collector.
このフローには、ベンダーYアンチウイルス姿勢コレクターからのPAメッセージ（姿勢要求への応答）が含まれています。
Vendor Y AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
length
Value = {
product-vendor-id=12345 (vendor Y)
product-id=987 (AV product id from vendor Y)
product-name="Vendor Y Anti-Virus"
}
}
Attribute 2 {
vendor-id=2 (vendor Y)
type=2 (vendor Y attribute, DAT-Version)
length
Value = {
DAT-version=5678
}
}
}
This flow contains the PA message (response to the Posture Request) from the Vendor X Anti-Virus Posture Collector.
このフローには、ベンダーXアンチウイルス姿勢コレクターからのPAメッセージ（姿勢要求への応答）が含まれています。
Vendor X AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1
type=1 (vendor X attribute, Scan-Engine-Version)
length
Value = {
scan-engine-version=1234
}
}
Attribute 2 {
vendor-id=0 (IETF Standard)
type=5 (Standard, Operational-Status)
length
Value = {
status=2 (installed but non-operational)
result=0 (unknown)
last use="" (never used)
}
}
}
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Collectors; the message content is described in the PB-TNC specification.
このフローには、ベンダーXおよびベンダーYアンチウイルス姿勢コレクターからのPAメッセージを含むPBメッセージが含まれています。メッセージコンテンツは、PB-TNC仕様で説明されています。
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Validators requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA does not specify the message contents.
このフローは、受け取った姿勢属性の検証を要求するベンダーXおよびベンダーYアンチウイルス姿勢検証装置の呼び出しを示しています。このフローはNEAサーバー内で局所的に発生するため、NEAはメッセージの内容を指定しません。
This flow contains the PA message (Posture Assessment Result) from the Vendor Y Anti-Virus Posture Validator
このフローには、ベンダーyアンチウイルス姿勢検証装置からのPAメッセージ（姿勢評価結果）が含まれています
Vendor Y AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
This flow contains the PA message (Posture Assessment Result) from the Vendor X Anti-Virus Posture Validator
このフローには、ベンダーXアンチウイルス姿勢検証装置からのPAメッセージ（姿勢評価結果）が含まれています
Vendor X AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators; the message content is described in the PB-TNC specification.
このフローには、姿勢ブローカーサーバーによって計算されたシステム評価結果とベンダーXおよびベンダーYアンチウイルス姿勢検証装置からのPAメッセージを含むPBメッセージが含まれています。メッセージコンテンツは、PB-TNC仕様で説明されています。
These flows illustrate an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to receive the posture assessment results. Because this flow is triggered locally, NEA does not specify the contents of this flow.
これらのフローは、姿勢評価の結果を受け取るために、ベンダーXおよびベンダーYアンチウイルス姿勢コレクターの呼び出しを示しています。このフローはローカルでトリガーされるため、NEAはこのフローの内容を指定しません。
This scenario involves the reassessment of an endpoint as a result of enabling a software component on the endpoint. The endpoint has two VPN client software components, one from vendor X for the user's home network and other from vendor Y for the network that the endpoint is currently accessing. The assessment is triggered when the user tries to use the Vendor X VPN client; this is a violation of the assessment policy. The Posture Broker Client triggers the posture assessment when it receives a notification from the VPN Posture Collector about the change to the operational state of the VPN component on the endpoint. Note that the VPN Posture Collector may support standard attributes and some vendor-defined attributes from vendor X's and vendor Y's namespaces. This use case does not leverage vendor-defined attributes. The assessment involves verification of the standard VPN posture attributes by the standard VPN Posture Validator that results in a non-compliant assessment result.
このシナリオには、エンドポイントでソフトウェアコンポーネントを有効にした結果としてのエンドポイントの再評価が含まれます。エンドポイントには2つのVPNクライアントソフトウェアコンポーネントがあります。1つはユーザーのホームネットワーク用のベンダーXから、もう1つはエンドポイントが現在アクセスしているネットワークのベンダーYからです。評価は、ユーザーがベンダーX VPNクライアントを使用しようとするとトリガーされます。これは評価ポリシーの違反です。姿勢ブローカーのクライアントは、エンドポイントのVPNコンポーネントの運用状態への変更についてVPN Possure Collectorから通知を受け取ったときに姿勢評価をトリガーします。VPN Posture Collectorは、ベンダーXおよびベンダーYの名前空間から標準属性および一部のベンダー定義属性をサポートする場合があることに注意してください。このユースケースは、ベンダー定義の属性を活用しません。この評価には、標準のVPN姿勢属性の検証が含まれます。
This use case relies on the use of multiple Posture Collector IDs for a single Posture Collector as described in section 3.3 of the PA-TNC specification. In this example, the Posture Collector will obtain two Posture Collector IDs to a single Posture Collector (Standard VPN PC) and the Posture Collector will generate two separate PA messages each using a different ID to report the posture for Vendor X and Vendor Y VPN Clients. The Posture Broker Client will associate the assigned IDs in the PB message sent to the NEA Server. This entire behavior will be completely opaque to the NEA Server, which will handle the PB message as if there were two VPN Posture Collectors on the NEA Client.
このユースケースは、PA-TNC仕様のセクション3.3で説明されているように、単一の姿勢コレクターに対する複数の姿勢コレクターIDの使用に依存しています。この例では、姿勢コレクターは単一の姿勢コレクター（標準VPN PC）に2つの姿勢コレクターIDを取得し、姿勢コレクターはそれぞれ別のIDを使用して2つの別々のPAメッセージを生成し、ベンダーXとベンダーY VPNクライアントの姿勢を報告します。姿勢ブローカークライアントは、NEAサーバーに送信されたPBメッセージで割り当てられたIDを関連付けます。この動作全体は、NEAサーバーにとって完全に不透明になり、NEAクライアントに2つのVPN姿勢コレクターがいるかのようにPBメッセージを処理します。
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
---->| | | | | |
| VPN Status Change | | | |
|--------------------->| Posture | | |
| | | Change | | |
| | |-------->| | |
| | |Req. Post| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |VPNY Post| | |
| | |-------->| | |
| | | | Posture | |
| | | | Report | |
| | | |--------->| |
| | | | |Vrfy Post. |
| | | | |---------->|
| | | | |VPN PRslt |
| | | | Assess |<----------|
| | | | Result | |
| | | |<---------| |
| | |VPN PRslt| | |
| | |<--------| | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
このセクションでは、このユースケースで交換されるPAメッセージのそれぞれの重要なフィールドの内容を示しています。必要に応じて、特定のフィールドに表示された値が含まれている理由を説明するために、追加の解説が提供されます。表示されるフローの多くは同じシステム上のコンポーネント間にあるため、メッセージの内容は表示されないことに注意してください。
This flow represents the end user triggered event of starting the VPN Client software from Vendor X. This is merely an event and does not include a message being sent.
このフローは、ベンダーXからVPNクライアントソフトウェアを起動するエンドユーザートリガーイベントを表します。これは単なるイベントであり、送信されるメッセージは含まれません。
This flow represents the detection of the active state of the Vendor X VPN Client software by the VPN Posture Collector. This is merely an event and does not include a message being sent.
このフローは、VPN Posture CollectorによるベンダーX VPNクライアントソフトウェアのアクティブ状態の検出を表します。これは単なるイベントであり、送信されるメッセージは含まれていません。
This flow represents the notification of the VPN posture change sent from the VPN Posture Collector to the Standard Posture Broker Client. This is merely an event and does not include a message being sent.
このフローは、VPN姿勢コレクターから標準的な姿勢ブローカークライアントに送られたVPN姿勢の変更の通知を表しています。これは単なるイベントであり、送信されるメッセージは含まれていません。
This flow illustrates an invocation of the VPN Posture Collector requesting particular posture attributes to be sent. Because this use case is triggered locally, NEA does not specify the contents of this flow.
このフローは、送信する特定の姿勢属性を要求するVPN姿勢コレクターの呼び出しを示しています。このユースケースはローカルでトリガーされるため、NEAはこのフローの内容を指定しません。
This flow illustrates the acquisition of the posture information by the VPN Posture Collector from the Vendor X and Vendor Y VPN Client components. Because this flow is triggered locally, NEA does not specify the message contents.
このフローは、ベンダーXおよびベンダーY VPNクライアントコンポーネントからのVPN姿勢コレクターによる姿勢情報の取得を示しています。このフローはローカルでトリガーされるため、NEAはメッセージの内容を指定しません。
This flow contains the PA message from the VPN Posture Collector describing the Vendor X VPN Client's posture:
このフローには、ベンダーX VPNクライアントの姿勢を説明するVPN姿勢コレクターからのPAメッセージが含まれています。
Vendor X VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=9876 (vendor X)
product-id=567 (VPN client identifier for Vndr X)
product-name="Vendor X VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T12:00:00Z"
}
}
This flow contains the PA message from the VPN Posture Collector including the Vendor Y VPN Client's posture:
このフローには、ベンダーY VPNクライアントの姿勢を含むVPN姿勢コレクターからのPAメッセージが含まれています。
Vendor Y VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=Vendor Y
product-id=234 (VPN client identifier for Vndr Y)
product-name="Vendor Y VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T14:05:00Z"
}
}
}
This flow contains the PB message containing the PA message from the VPN Posture Collector; the message content is described in the PB-TNC specification.
このフローには、VPN Posure CollectorからのPAメッセージを含むPBメッセージが含まれています。メッセージコンテンツは、PB-TNC仕様で説明されています。
This flow illustrates an invocation of the VPN Posture Validator requesting verification of the posture attributes received. Because this flow happens locally within the NEA Server, NEA does not specify the message contents.
このフローは、受信した姿勢属性の検証を要求するVPN姿勢検証器の呼び出しを示しています。このフローはNEAサーバー内で局所的に発生するため、NEAはメッセージの内容を指定しません。
This flow contains the PA message (Posture Assessment Result) from the VPN Posture Validator
このフローには、VPN Posure ValidatorからのPAメッセージ（姿勢評価結果）が含まれています
VPN Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the VPN Posture Validator; the message content is described in the PB-TNC specification.
このフローには、姿勢ブローカーサーバーによって計算されたシステム評価結果とVPN Posure ValidatorからのPAメッセージを含むPBメッセージが含まれています。メッセージコンテンツは、PB-TNC仕様で説明されています。
This flow illustrates an invocation of the VPN Posture Collector to receive the posture assessment result. Because this flow is triggered locally, NEA does not specify the contents of this flow.
このフローは、姿勢評価の結果を受け取るためのVPN姿勢コレクターの呼び出しを示しています。このフローはローカルでトリガーされるため、NEAはこのフローの内容を指定しません。
This section evaluates the PA-TNC protocol against the requirements defined in the NEA Requirements document. Each subsection considers a separate requirement from the NEA Requirements document. Only common requirements (C-1 through C-10) and PA requirements (PA-1 through PA-6) are considered, since these are the only ones that apply to PA.
このセクションでは、NEA要件ドキュメントで定義されている要件に対してPA-TNCプロトコルを評価します。各サブセクションでは、NEA要件ドキュメントとは別の要件を考慮します。PAに適用される唯一のものであるため、一般的な要件（C-1からC-10）およびPA要件（PA-1からPA-6）のみが考慮されます。
Requirement C-1 says:
要件C-1は言う：
C-1 NEA protocols MUST support multiple round trips between the NEA Client and NEA Server in a single assessment.
C-1 NEAプロトコルは、単一の評価でNEAクライアントとNEAサーバー間の複数のラウンド旅行をサポートする必要があります。
PA-TNC meets this requirement. It allows an unlimited number of round trips between the NEA Client and NEA Server.
PA-TNCはこの要件を満たしています。これにより、NEAクライアントとNEAサーバー間の無制限の数の往復が可能になります。
Requirement C-2 says:
要件C-2は次のように述べています
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.
C-2 NEAプロトコルは、NEAクライアントとNEAサーバーの両方が、必要に応じて姿勢評価または再評価を開始する方法を提供する必要があります。
PA-TNC meets this requirement. PA-TNC is designed to work whether the NEA Client or the NEA Server initiates a posture assessment or reassessment.
PA-TNCはこの要件を満たしています。PA-TNCは、NEAクライアントまたはNEAサーバーが姿勢評価または再評価を開始するかどうかにかかわらず機能するように設計されています。
Requirement C-3 says:
要件C-3は次のように述べています
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.
セキュリティ機能を含むC-3 NEAプロトコルは、リプレイベースの攻撃の防止を含む仲介者やエンドポイントによるアクティブおよびパッシブ攻撃から保護できる必要があります。
Security for PA-TNC messages being sent over the network is provided through PT protocol security. Therefore, PA-TNC does not include any security capabilities. Since this requirement only applies to NEA protocols "including security capabilities", this specification is not subject to this requirement (see section 5.2).
ネットワークを介して送信されるPA-TNCメッセージのセキュリティは、PTプロトコルセキュリティを通じて提供されます。したがって、PA-TNCにはセキュリティ機能は含まれていません。この要件は「セキュリティ機能を含む」NEAプロトコルにのみ適用されるため、この仕様はこの要件の対象ではありません（セクション5.2を参照）。
Requirement C-4 says:
要件C-4は言う：
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).
C-4 PAおよびPBプロトコルは、任意のPTプロトコルを操作できる必要があります。たとえば、PBプロトコルは、PAプロトコルがさまざまなネットワークプロトコル環境で変更せずに動作できるように、トランスポートに依存しないインターフェイスを提供する必要があります（例：EAP/802.1x、PANA、TLS、IKE/IPSEC）。
PA-TNC meets this requirement. PA-TNC can operate over any PT protocol that meets the requirements for PT stated in the NEA Requirements document. PA-TNC does not have any dependencies on specific details of the underlying PT protocol.
PA-TNCはこの要件を満たしています。PA-TNCは、NEA要件文書に記載されているPTの要件を満たすPTプロトコルで動作できます。PA-TNCには、基礎となるPTプロトコルの特定の詳細に依存関係がありません。
Requirement C-5 says:
要件C-5は次のように述べています
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.
C-5 NEAプロトコルの選択プロセスは、新しいものを定義する前に要件を満たす既存のオープン標準の再利用を評価し、好む必要があります。NEAの目標は、許容可能なソリューションがすでに存在する場合に追加の代替プロトコルを作成することではありません。
Based on this requirement, PA-TNC should receive a strong preference. PA-TNC is equivalent with IF-M 1.0, an open TCG specification. Other specifications from TCG and other groups are also under development based on the IF-M 1.0 specification. Selecting PA-TNC as the basis for the PA protocol will ensure compatibility with IF-M 1.0, with these other specifications, and with their implementations.
この要件に基づいて、PA-TNCは強い好みを受け取る必要があります。PA-TNCは、Open TCG仕様であるIF-M 1.0と同等です。TCGおよび他のグループからのその他の仕様も、IF-M 1.0仕様に基づいて開発中です。PAプロトコルの基礎としてPA-TNCを選択すると、IF-M 1.0、これらの他の仕様とその実装との互換性が確保されます。
Requirement C-6 says:
要件C-6は言う：
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.
C-6 NEAプロトコルは非常にスケーラブルでなければなりません。このプロトコルは、複数のNEAサーバーに存在する多数の姿勢バリデーターによって評価されるために、多数のNEAクライアントの多くの姿勢コレクターをサポートする必要があります。
PA-TNC meets this requirement. PA-TNC supports an unlimited number of Posture Collectors, Posture Validators, NEA Clients, and NEA Servers. It also is quite scalable in many other aspects as well. A PA-TNC message can contain up to 2^32-1 octets and about 2^28 PA-TNC attributes. Each organization with an SMI Private Enterprise Number is entitled to define up to 2^32 vendor-specific PA-TNC Attribute Types, 2^16 vendor-specific PA-TNC Product IDs, and 2^32 vendor- specific PA-TNC Error Codes. Each attribute can contain almost 2^32 octets. It is generally not advisable or necessary to send this much data in a NEA assessment, but still PA-TNC is highly scalable and meets requirement C-6 easily.
PA-TNCはこの要件を満たしています。PA-TNCは、無制限の数の姿勢コレクター、姿勢バリエーター、NEAクライアント、およびNEAサーバーをサポートしています。また、他の多くの面でも非常にスケーラブルです。PA-TNCメッセージには、最大2^32-1オクテットと約2^28 PA-TNC属性を含めることができます。SMIプライベートエンタープライズ番号を持つ各組織は、最大2^32ベンダー固有のPA-TNC属性タイプ、2^16ベンダー固有のPA-TNC製品ID、および2^32ベンダー固有のPA-TNCエラーコードを定義する権利があります。。各属性には、ほぼ2^32オクテットを含めることができます。一般に、NEA評価でこの多くのデータを送信することは一般にお勧めまたは必要ではありませんが、それでもPA-TNCは非常にスケーラブルで、要件C-6を簡単に満たしています。
Requirement C-7 says:
要件C-7は次のように述べています
C-7 The protocols MUST support efficient transport of a large number of attribute messages between the NEA Client and the NEA Server.
C-7プロトコルは、NEAクライアントとNEAサーバー間の多数の属性メッセージの効率的な輸送をサポートする必要があります。
PA-TNC meets this requirement. Each PA-TNC message can contain about 2^28 PA-TNC attributes. PA-TNC supports up to 2^32 round trips in a session so the maximum number of attribute messages that can be sent in a single session is actually about 2^50. However, it is generally inadvisable and unnecessary to send a large number of messages in a NEA assessment. As for efficiency, PA-TNC adds only 12 octets of overhead per attribute and 8 octets per message (which is negligible on a per-attribute basis).
PA-TNCはこの要件を満たしています。各PA-TNCメッセージには、約2^28 PA-TNC属性を含めることができます。PA-TNCはセッションで最大2^32のラウンドトリップをサポートするため、1回のセッションで送信できる属性メッセージの最大数は実際には約2^50です。ただし、一般に、NEA評価で多数のメッセージを送信することは通常は不可能ではありません。効率に関しては、PA-TNCは、属性あたりのオーバーヘッド12オクテットとメッセージごとに8オクテットのみを追加します（これは、属性ごとに無視できます）。
Requirement C-8 says:
要件C-8は次のように述べています
C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links.
C-8 NEAプロトコルは、低帯域幅または高レイテンシリンクで効率的に動作する必要があります。
PA-TNC meets this requirement. A PA-TNC exchange is envisioned (based on current deployment experience) to involve one or two round trips with less than 500 octets of PA-TNC messages. Of course, use of vendor-specific PA-TNC attribute types could expand the assessment. However, PA-TNC itself imposes an overhead of only 8 octets per PA-TNC message and 12 octets per attribute.
PA-TNCはこの要件を満たしています。PA-TNC交換は（現在の展開エクスペリエンスに基づいて）、500オクテット未満のPA-TNCメッセージを使用して1回または2回のラウンド旅行を含むと想定されています。もちろん、ベンダー固有のPA-TNC属性タイプを使用すると、評価が拡大する可能性があります。ただし、PA-TNC自体は、PA-TNCメッセージごとにわずか8オクテットと属性あたり12オクテットのオーバーヘッドを課します。
Requirement C-9 says:
要件C-9は次のように述べています
C-9 For any strings intended for display to a user, the protocols MUST support adapting these strings to the user's language preferences.
C-9ユーザーへの表示を目的とした文字列の場合、プロトコルはこれらの文字列をユーザーの言語設定に適応させることをサポートする必要があります。
PA-TNC meets this requirement. The only field included in a PB-TNC attribute for display to the user includes a language tag that could be selected based upon the user's PB-TNC negotiated preferred language for the assessment (see section 4.10 of the PB-TNC specification). With this exception, all of the strings in the standard PA-TNC attributes are intended for logging and programmatic comparisons.
PA-TNCはこの要件を満たしています。ユーザーへの表示用のPB-TNC属性に含まれる唯一のフィールドには、評価のためにユーザーのPB-TNC交渉優先言語に基づいて選択できる言語タグが含まれています（PB-TNC仕様のセクション4.10を参照）。この例外を除き、標準のPA-TNC属性のすべての文字列は、ロギングとプログラムの比較を目的としています。
If any vendor-specific PA-TNC attribute types or future IETF Standard PA-TNC Attribute Types include strings that are intended for display to a user, they should be translated to the user's preferred language. The Posture Broker Server will need to expose the user's preferences to the Posture Validators through whatever API or protocol is used to connect those components. However, that is all out of scope for this specification.
ベンダー固有のPA-TNC属性タイプまたは将来のIETF標準PA-TNC属性タイプには、ユーザーへの表示用の文字列が含まれている場合は、ユーザーの優先言語に翻訳する必要があります。Posture Broker Serverは、これらのコンポーネントを接続するために使用されるAPIまたはプロトコルを使用して、ユーザーの好みをPosure Validatorsに公開する必要があります。ただし、この仕様の範囲外です。
Requirement C-10 says:
要件C-10は次のように述べています
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.
C-10 NEAプロトコルは、UTF-8形式の文字列のエンコードをサポートする必要があります。
PA-TNC meets this requirement. All strings in the PA-TNC protocol are encoded in UTF-8 format. This allows the protocol to support a wide range of languages efficiently.
PA-TNCはこの要件を満たしています。PA-TNCプロトコルのすべての文字列は、UTF-8形式でエンコードされています。これにより、プロトコルは幅広い言語を効率的にサポートできます。
Requirement C-11 says:
要件C-11は次のように述べています
C-11 Due to the potentially different transport characteristics provided by the underlying candidate PT protocols, the NEA Client and NEA Server MUST be capable of becoming aware of and adapting to the limitations of the available PT protocol. For example, some PT protocol characteristics that might impact the operation of PA and PB include restrictions on which end can initiate a NEA connection, maximum data size in a message or full assessment, upper bound on number of round trips, and ordering (duplex) of messages exchanged. The selection process for the PT protocols MUST consider the limitations the candidate PT protocol would impose upon the PA and PB protocols.
C-11基礎となる候補PTプロトコルによって提供される潜在的に異なる輸送特性により、NEAクライアントとNEAサーバーは、利用可能なPTプロトコルの制限を認識し、適応させることができなければなりません。たとえば、PAとPBの動作に影響を与える可能性のあるPTプロトコルの特性には、端がNEA接続を開始できる制限、メッセージまたは完全な評価の最大データサイズ、往復数の上限、および注文（デュプレックス）が含まれます。交換されたメッセージの。PTプロトコルの選択プロセスは、候補PTプロトコルがPAおよびPBプロトコルに課す制限を考慮する必要があります。
PA-TNC meets this requirement. The design of the PA-TNC protocol emphasizes efficient transport of information in order to maximize its usability in constrained PT environments. Local APIs could allow Posture Collectors and Posture Validators to discover when they are operating in a less constrained deployment and then make use of more verbose attributes. Similarly, Posture Collectors could choose not to send or use smaller attributes (including assertions from previous assessments) when faced with a very constrained network connection.
PA-TNCはこの要件を満たしています。PA-TNCプロトコルの設計は、制約されたPT環境での使いやすさを最大化するために、情報の効率的な輸送を強調しています。ローカルAPIは、姿勢コレクターと姿勢バリエーターが、制約の少ない展開で動作しているときに発見し、より多くの冗長属性を利用できるようにすることができます。同様に、姿勢コレクターは、非常に制約されたネットワーク接続に直面した場合、より小さな属性（以前の評価からのアサーションを含む）を送信または使用しないことを選択できます。
Requirement PA-1 says:
要件PA-1は次のように述べています
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-1 PAプロトコルは、NEA標準定義属性の拡張可能なセットの通信をサポートする必要があります。これらの属性は、非標準属性から一意に識別できます。
PA-TNC meets this requirement. Each attribute is identified with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. IETF Standard PA-TNC Attribute Types use a vendor ID of zero (0), in contrast with vendor-specific PA-TNC Attribute Types, which will use the vendor's SMI Private Enterprise Number as the vendor ID. The IANA will maintain a registry of PA-TNC Attribute Types with new values added by Expert Review with Specification Required, as described in the IANA Considerations section of this specification. Thus, the set of standard attribute types is extensible, but all standard attribute types are uniquely identifiable.
PA-TNCはこの要件を満たしています。各属性は、PA-TNC属性ベンダーIDおよびPA-TNC属性タイプで識別されます。IETF標準PA-TNC属性タイプは、ベンダー固有のPA-TNC属性タイプとは対照的に、ベンダーのSMIプライベートエンタープライズ番号をベンダーIDとして使用します。IANAは、この仕様のIANA考慮事項セクションで説明されているように、専門家のレビューによって必要な専門家レビューによって追加された新しい値を使用して、PA-TNC属性タイプのレジストリを維持します。したがって、標準属性タイプのセットは拡張可能ですが、すべての標準属性タイプは一意に識別できます。
Requirement PA-2 says:
要件PA-2は次のように述べています
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 namespaces.
PA-2 PAプロトコルは、ベンダー固有の属性の拡張可能なセットの通信をサポートする必要があります。これらの属性は、一意に識別可能なベンダー固有の名前空間にセグメント化されます。
PA-TNC meets this requirement. Each attribute is identified with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. Vendor-defined PA-TNC Attribute Types use the vendor's SMI Private Enterprise Number as the PA-TNC Attribute Vendor ID. Each vendor can define up to 2^32 PA-TNC Attribute Types, using its own internal processes to manage its set of attribute types.
PA-TNCはこの要件を満たしています。各属性は、PA-TNC属性ベンダーIDおよびPA-TNC属性タイプで識別されます。ベンダー定義のPA-TNC属性タイプベンダーのSMIプライベートエンタープライズ番号をPA-TNC属性ベンダーIDとして使用します。各ベンダーは、独自の内部プロセスを使用して属性タイプのセットを管理し、最大2^32 PA-TNC属性タイプを定義できます。
The IANA is not involved, other than the initial assignment of the vendor's SMI Private Enterprise Number. Thus, the set of vendor-specific attributes is segmented into uniquely identifiable vendor-specific namespaces.
IANAは、ベンダーのSMIプライベートエンタープライズ番号の最初の割り当てを除いて、関与していません。したがって、ベンダー固有の属性のセットは、一意に識別可能なベンダー固有の名前空間にセグメント化されます。
Requirement PA-3 says:
要件PA-3は次のように述べています
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-3 PAプロトコルは、姿勢バリーターが単一の評価内で姿勢コレクターから属性を1つ以上の要求を行うことを可能にする必要があります。これにより、姿勢バリーターは特定のエンドポイント機能の姿勢を再評価したり、エンドポイントの他の部分から追加の姿勢を要求したりできます。
PA-TNC meets this requirement. The Attribute Request attribute type is an IETF Standard PA-TNC Attribute Type that permits a Posture Validator to send to one or more Posture Collectors a request for one or more attributes. This attribute may be sent at any point in the posture assessment process and may in fact be sent more than once if the Posture Validator needs to first determine the type of operating system and then request certain attributes specific to that operating system, for example.
PA-TNCはこの要件を満たしています。属性要求属性タイプは、IETF標準PA-TNC属性タイプで、姿勢バリーターが1つ以上の姿勢コレクターに1つ以上の属性のリクエストを送信できます。この属性は、姿勢評価プロセスの任意の時点で送信される場合があり、実際に姿勢バリーターが最初にオペレーティングシステムのタイプを決定し、次にそのオペレーティングシステムに固有の特定の属性などを要求する必要がある場合、実際には複数回送信される場合があります。
Requirement PA-4 says:
要件PA-4は言う：
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-4 PAプロトコルは、姿勢バリデーターから姿勢コレクターに属性を返すことができなければなりません。たとえば、これにより、姿勢コレクターが評価に失敗した特定の理由を学び、システム所有者の修復と通知を支援できるようになります。
PA-TNC meets this requirement. A Posture Validator can easily send attributes to one or more Posture Collectors.
PA-TNCはこの要件を満たしています。姿勢バリーターは、1つ以上の姿勢コレクターに属性を簡単に送信できます。
Requirement PA-5 says:
要件PA-5は次のように述べています
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-5 PAプロトコルは、姿勢コレクターと姿勢バリエーターの間で伝達される属性の認証、整合性、および機密性を提供する必要があります。これにより、いくつかのシステムの移動または信頼の境界を伴う可能性のあるNEA展開全体のエンドツーエンドのセキュリティが可能になります。
PA-TNC does not include an explicit PA-level security mechanism but does lay a foundation allowing attribute-level security protections to be added later. As an existence proof, the NEA working group considered an Internet-Draft proposal capable of encapsulating PA attributes within a Cryptographic Message Syntax (CMS) security wrapper in a new attribute type. This proposal offered the protections described in this requirement. However, the NEA WG decided that the use cases in scope for the working group did not require PA-level security. The use cases involving PA message traversal of multiple systems or trust boundaries were considered out of scope; therefore, a Posture Validator to Posture Collector end-to-end security protection was considered not to be required.
PA-TNCには、明示的なPAレベルのセキュリティメカニズムは含まれていませんが、後で属性レベルのセキュリティ保護を追加できる基盤を築きます。存在証明として、NEAワーキンググループは、暗号化メッセージ構文（CMS）セキュリティラッパー内でPA属性を新しい属性タイプにカプセル化できるインターネットドラフトの提案を検討しました。この提案は、この要件に記載されている保護を提供しました。ただし、NEA WGは、ワーキンググループの範囲内のユースケースがPAレベルのセキュリティを必要としないと判断しました。複数のシステムまたは信頼の境界のPAメッセージトラバーサルを含むユースケースは、範囲外であると見なされました。したがって、コレクターのエンドツーエンドのセキュリティ保護を姿勢する姿勢検証装置は、必要ないと見なされました。
Instead, PA-TNC attributes are protected by the PT layer authentication, integrity, and confidentiality support. This protects the attributes communicated between the Posture Transport Client and Posture Transport Server. Because the Posture Collector is in the same address space as the Posture Broker Client and Posture Transport Client and the Posture Validator is in the same address space as the Posture Broker Server and Posture Transport Server, the underlying broker and transport components are deemed trusted with respect to not tampering with the PA messages (see trust model in section 5.1 for details). Encrypting the PA-TNC messages would not prevent a hostile broker or transport component from attacking the messages.
代わりに、PA-TNC属性は、PTレイヤー認証、完全性、および機密性のサポートによって保護されます。これにより、Positure Transport ClientとPossure Transport Serverの間で伝達される属性が保護されます。姿勢コレクターは姿勢ブローカークライアントおよび姿勢輸送クライアントと同じアドレス空間にあるため、姿勢検証装置は姿勢ブローカーサーバーと姿勢輸送サーバーと同じアドレス空間にあるため、基礎となるブローカーと輸送コンポーネントは敬意を持って信頼されているとみなされますPAメッセージを改ざんしないようにします（詳細については、セクション5.1の信頼モデルを参照してください）。PA-TNCメッセージを暗号化しても、敵対的なブローカーや輸送コンポーネントがメッセージを攻撃することを妨げません。
Requirement PA-6 says:
要件PA-6は次のように述べています
PA-6 The PA protocol MUST be capable of carrying attributes that contain non-binary and binary data including encrypted content.
PA-6 PAプロトコルは、暗号化されたコンテンツを含む非バイナリデータとバイナリデータを含む属性を運ぶことができる必要があります。
PA-TNC meets this requirement. PA-TNC attributes can contain non-binary and binary data including encrypted content. For examples, see the attribute type definitions contained in this specification.
PA-TNCはこの要件を満たしています。PA-TNC属性には、暗号化されたコンテンツを含む非バイナリおよびバイナリデータを含めることができます。たとえば、この仕様に含まれる属性タイプ定義を参照してください。
Authors' Addresses
著者のアドレス
Paul Sangster Symantec Corporation 6825 Citrine Drive Carlsbad, CA 92009 USA EMail: Paul_Sangster@symantec.com
Paul Sangster Symantec Corporation 6825 Citrine Drive Carlsbad、CA 92009 USAメール：paul_sangster@symantec.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 USA EMail: kaushik@cisco.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose、CA 95134 USAメール：kaushik@cisco.com