Internet Engineering Task Force (IETF) R. Sahita
Request for Comments: 5793 Intel
Category: Standards Track S. Hanna
ISSN: 2070-1721 Juniper
R. Hurst
Microsoft
K. Narayan
Cisco Systems
March 2010
PB-TNC: A Posture Broker (PB) Protocol Compatible
with Trusted Network Connect (TNC)
Abstract
抽象
This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification.
この文書では、PB-TNC、トラステッド・コンピューティング・グループのIF-TNCCS 2.0プロトコルと同一の姿勢ブローカープロトコルを指定します。文書は、NEAの要件の仕様で定義された要件に照らしPB-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/rfc5793.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5793で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Terminology ................................................4
1.4. Conventions Used in This Document ..........................4
2. PB-TNC Design Considerations ....................................5
2.1. Message Addressing .........................................5
2.2. Vendor IDs .................................................7
2.3. Efficiency .................................................7
3. PB-TNC Protocol Description .....................................7
3.1. Protocol Overview ..........................................7
3.2. PB-TNC State Machine .......................................8
3.3. Layering on PT ............................................11
3.4. Example of PB-TNC Encapsulation ...........................12
4. PB-TNC Protocol Specification ..................................13
4.1. PB-TNC Header .............................................13
4.2. PB-TNC Message ............................................16
4.3. IETF Standard PB-TNC Message Types ........................19
4.4. PB-Experimental ...........................................19
4.5. PB-PA .....................................................20
4.6. PB-Assessment-Result ......................................25
4.7. PB-Access-Recommendation ..................................26
4.8. PB-Remediation-Parameters .................................28
4.9. PB-Error ..................................................32
4.10. PB-Language-Preference ...................................37
4.11. PB-Reason-String .........................................38
5. Security Considerations ........................................41
5.1. Threat Model ..............................................41
5.2. Countermeasures ...........................................42
6. IANA Considerations ............................................43
6.1. Designated Expert Guidelines ..............................44
6.2. Registry for PB-TNC Message Types .........................45
6.3. Registry for PA Subtypes ..................................45
6.4. Registry for PB-TNC Remediation Parameters Types ..........46
6.5. Registry for PB-TNC Error Codes ...........................46
7. Acknowledgments ................................................47
8. References .....................................................47
8.1. Normative References ......................................47
8.2. Informative References ....................................48
Appendix A. Use Cases .............................................49
A.1. Initial Client-Triggered Assessment .......................49
A.2. Server-Initiated Assessment with Remediation ..............54
A.3. Client-Triggered Reassessment .............................63
Appendix B. Evaluation against NEA Requirements ...................70
B.1. Evaluation against Requirement C-1 ........................70
B.2. Evaluation against Requirement C-2 ........................70
B.3. Evaluation against Requirement C-3 ........................70
B.4. Evaluation against Requirement C-4 ........................71
B.5. Evaluation against Requirement C-5 ........................71
B.6. Evaluation against Requirement C-6 ........................71
B.7. Evaluation against Requirement C-7 ........................72
B.8. Evaluation against Requirement C-8 ........................72
B.9. Evaluation against Requirement C-9 ........................72
B.10. Evaluation against Requirement C-10 ......................73
B.11. Evaluation against Requirement C-11 ......................73
B.12. Evaluation against Requirement PB-1 ......................74
B.13. Evaluation against Requirement PB-2 ......................74
B.14. Evaluation against Requirement PB-3 ......................74
B.15. Evaluation against Requirement PB-4 ......................75
B.16. Evaluation against Requirement PB-5 ......................75
B.17. Evaluation against Requirement PB-6 ......................76
This document specifies PB-TNC, a Posture Broker (PB) protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol [7]. The document then evaluates PB-TNC against the requirements defined in the Network Endpoint Assessment (NEA) Requirements specification [8].
この文書では、PB-TNC、トラステッドコンピューティンググループのIF-TNCCS 2.0プロトコル[7]と同じ姿勢ブローカー（PB）プロトコルを指定します。ドキュメントは、ネットワークエンドポイントの評価（NEA）要求仕様[8]で定義された要件に対するPB-TNCを評価します。
This document does not define an architecture or reference model. Instead, it defines a protocol that works within the reference model described in the NEA Requirements specification [8]. The reader is assumed to be thoroughly familiar with that document. No familiarity with TCG specifications is assumed.
この文書では、アーキテクチャや参照モデルを定義していません。代わりに、NEA要件仕様[8]に記載の参照モデル内で動作するプロトコルを定義しています。読者はその文書を熟知であると仮定されます。 TCG仕様のいかなる知識が前提とされていません。
This specification defines the syntax of PB-TNC messages using diagrams. Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits in each diagram as they are shown, traversing the diagram from top to bottom and then from left to right within each line (which represents a 32-bit quantity). Multi-byte fields representing numeric values must be sent in network (big endian) byte order.
この仕様は、図を用いてPB-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を有しています。
This document reuses the terminology defined in the NEA Requirements document. One new term is defined in this section.
この文書では、NEAの要件文書に定義された用語を再利用します。一つの新しい用語は、このセクションで定義されています。
Batch - A group of PB-TNC messages sent over a Posture Transport (PT) protocol at one time. Since the PB-TNC protocol needs to be able to work over a half-duplex PT protocol, PB-TNC messages are grouped into batches. The Posture Broker Client sends one batch to the Posture Broker Server, which responds with a batch.
バッチ - 一度姿勢トランス（PT）プロトコルを介して送信されたPB-TNCメッセージのグループ。 PB-TNCプロトコルは半二重PTプロトコル上で動作できるようにする必要があるため、PB-TNCメッセージをバッチにグループ化されます。姿勢ブローカークライアントは、バッチで応答姿勢ブローカーサーバー、1つのバッチを送信します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
The primary purpose of the PB-TNC protocol is to carry Posture Attribute (PA) messages between Posture Collectors and Posture Validators. Also, PB-TNC must carry messages between the Posture Broker Client and the Posture Broker Server (known as PB-TNC messages) and manage the state of the assessment.
PB-TNCプロトコルの主な目的は、姿勢コレクターと姿勢バリ間の姿勢属性（PA）メッセージを搬送することです。また、PB-TNCは、姿勢ブローカークライアント・姿勢ブローカーサーバー間でメッセージを伝える（PB-TNCメッセージとして知られている）と評価の状態を管理しなければなりません。
The NEA Overview and Requirements document [8] describes in section 5.1.1.1 several ways that messages can be addressed and delivered to the proper Posture Collector(s) and Posture Validator(s). Of the techniques described in that section, PB-TNC supports dynamic identifiers and message types.
NEA概要と要件文書[8]のメッセージがアドレスと正しい姿勢コレクタ（複数可）及び姿勢検証（S）に送達することができるセクション5.1.1.1いくつかの方法で記載されています。そのセクションで説明した技術を、PB-TNCは動的識別子およびメッセージタイプをサポート。
Message types are the simplest and most common way to handle message delivery. Each PA message sent via PB-TNC has an associated PA message type, composed of a PA Message Vendor ID and a PA subtype.
メッセージタイプは、メッセージ配信を処理するための最も単純で最も一般的な方法です。 PB-TNCを介して送信された各PAメッセージは、PAメッセージのベンダーID及びPAサブタイプからなる関連PAメッセージタイプを有しています。
The PA-TNC specification [10] provides a list of IETF Standard PA Subtypes, which are used with a PA Message Vendor ID of 0. These include values such as Operating System and Anti-Virus, which are used for messages relating to operating system and anti-virus posture.
PA-TNC仕様[10] 0これらのPAメッセージベンダーIDと共に使用されるIETF標準PAサブタイプのリストを提供する、オペレーティングシステムに関連するメッセージのために使用されるオペレーティングシステムとアンチウィルス、などの値を含みますおよびアンチウイルス姿勢。
Vendor-specific PA message types may be indicated by placing the defining vendor's Structure of Management Information (SMI) Private Enterprise Number into the PA Message Vendor ID field and a PA Subtype value assigned by that vendor in the PA Subtype field. This allows each vendor to define its own set of PA Subtype values without worrying about collisions with other vendors or with standard values.
ベンダー固有のPAメッセージタイプは、（SMI）管理情報の定義、ベンダーの構造を配置することにより、プライベートPAメッセージベンダーIDフィールドにエンタープライズ番号とPAサブタイプフィールドにそのベンダーによって割り当てられPAサブタイプの値を示すことができます。これは、各ベンダーが他のベンダーとのまたは標準値との衝突を心配することなく、PAサブタイプ値の独自のセットを定義することができます。
The PA message type is somewhat analogous to a MIME type in that it indicates the type of the PA message. Posture Collectors and Posture Validators can use local APIs to indicate to the Posture Broker Client and Posture Broker Server which PA message types they are interested in receiving. For instance, a Posture Validator that evaluates anti-virus posture might indicate that it would like to receive PA messages with a PA Message Vendor ID of 0 and a PA Subtype that matches the IETF Standard PA Subtype for Anti-Virus. It might also indicate interest in some vendor-specific PA message types to get additional vendor-specific information on anti-virus posture.
PAメッセージタイプは、PAメッセージのタイプを示すことで入力MIMEに幾分類似しています。姿勢コレクターと姿勢バリデータは、彼らが受け取ることに興味を持っているPAは、メッセージの種類姿勢ブローカークライアントと姿勢ブローカーサーバーに示すために地元のAPIを使用することができます。例えば、アンチウイルス姿勢を評価する姿勢Validatorは、それが0のPAメッセージベンダーIDとアンチウィルスのためのIETF標準PAサブタイプと一致したPAのサブタイプとPAメッセージを受信したいことを示している可能性があります。また、アンチウイルス姿勢に追加のベンダー固有の情報を取得するには、いくつかのベンダー固有のPAメッセージタイプに興味を示している可能性があります。
This type-based subscription model allows great flexibility in design and implementation. One Posture Validator may be responsible for evaluating several functions: anti-virus and host-based firewall, for instance. Posture Collectors do not need to know which Posture Validators are installed on the Posture Broker Server or what they handle. The Posture Collector simply sends PA messages with message types and the Posture Broker Server delivers them to the right Posture Validators.
このタイプのベースのサブスクリプションモデルは、設計と実装に大きな柔軟性を可能にします。例えばアンチウイルスおよびホストベースのファイアウォール、：一つの姿勢Validatorはいくつかの機能を評価するための責任があるかもしれません。姿勢コレクターは姿勢バリデータは、姿勢ブローカーサーバーまたは彼らが扱うにインストールされている知っている必要はありません。姿勢コレクターは、単にメッセージタイプとPAメッセージを送信し、姿勢ブローカーサーバーは、右の姿勢バリに配信します。
Because the Posture Broker Client and Posture Broker Server must have access to the PA Message Vendor ID and PA Subtype fields and because these are routing identifiers independent of the contents of the PA messages, these fields are located in PB-TNC not inside the PA messages themselves.
姿勢ブローカークライアントと姿勢ブローカーサーバーはPAメッセージベンダーIDおよびPAサブタイプフィールドへのアクセスを持っている必要がありますし、これらのためにPAメッセージの内容とは無関係に識別子をルーティングしているので、これらのフィールドはないPAメッセージ内のPB-TNCに位置しています自分自身。
A similar type-based system is used to tag PB-TNC messages. In this case, the extensibility benefits are not as essential as with PA-TNC messages, but the ability to define IETF Standard PB-TNC Message Types and vendor-specific PB-TNC message types is still valuable.
同様のタイプベースのシステムは、PB-TNCメッセージにタグを付けるために使用されます。この場合は、拡張性の利点は、PA-TNCメッセージほど必須ではないですが、IETF標準PB-TNCメッセージタイプとベンダー固有のPB-TNCのメッセージタイプを定義する機能はまだ価値があります。
The type-based message delivery model described above is not ideal for all circumstances. Sometimes it is important for a Posture Collector to deliver a message to a particular Posture Validator. For example, a particular Posture Validator might send a remediation message and the Posture Collector might need to send a response only to that one Posture Validator. To handle this circumstance, PB-TNC provides delivery based on dynamic identifiers.
上述のタイプベースのメッセージ配信モデルは、すべての状況のために理想的ではありません。姿勢コレクターが特定の姿勢バリにメッセージを配信するために時にはそれが重要です。例えば、特定の姿勢Validatorは修復メッセージを送信することがありますし、姿勢コレクターはその1つの姿勢バリへの応答を送信する必要がある場合があります。この状況を処理するために、PB-TNCは動的識別子に基づいて配信を提供します。
When a Posture Broker Server loads a Posture Validator, it assigns it a Posture Validator ID. Any PA messages sent by a Posture Validator include that Posture Validator's Posture Validator ID in the Posture Validator ID field of the PB-PA message. A Posture Collector that receives such a message can send a message in response and request exclusive delivery to the Posture Validator identified by that Posture Validator ID.
姿勢ブローカーサーバーは姿勢バリデータをロードすると、それはそれのPosture ValidatorのIDを割り当てます。姿勢Validatorによって送信されたPAメッセージは、PB-PAメッセージの姿勢ValidatorのIDフィールドの姿勢Validatorの姿勢ValidatorのIDことが含まれます。そのようなメッセージを受信した姿勢コレクタは応答メッセージを送信し、そのポスチャ検証ツールIDによって識別されるポスチャ検証に排他的配信を要求することができます。
Dynamic identifiers avoid problems caused by the multicast nature of message types. Multiple Posture Collectors or Posture Validators may be registered for the same message type, and this can cause confusion if they all respond and the software designer did not consider that possibility. The dynamic identifier system allows more directed responses, but it does not work until at least one message has been received (so that the dynamic identifiers can be received). Static identifiers were considered as another alternative but rejected because they result in a brittle system that only works with a particular set of Posture Collectors and Posture Validators and causes problems if two Posture Collectors or Posture Validators with the same static identifier are installed.
ダイナミックな識別子は、メッセージタイプのマルチキャストな性質に起因する問題を避けます。複数の姿勢コレクターや姿勢バリデータは、同じメッセージタイプに対して登録されている場合があり、それらはすべてが応答し、ソフトウェア設計者は、その可能性を考慮していない場合、これは混乱を引き起こす可能性があります。動的識別子システムは、より指向応答を可能にするが、（動的識別子を受信することができるように）少なくとも1つのメッセージが受信されるまでは動作しません。静的な識別子は、別の代替として考えられたが、彼らは唯一の姿勢コレクターや姿勢バリデータの特定のセットで動作し、同じ静的な識別子を持つ2つの姿勢コレクターや姿勢バリデータがインストールされている場合は問題が発生する脆性システムになるために拒否されました。
In several places, PB-TNC needs to define a set of standard values but also allow vendor-specific extensions. In each of these places (PB-TNC Message Types, PA Subtypes, Remediation Parameters Types, and Error Codes), the solution chosen was to preface the values with a vendor ID. If a vendor ID is 0, the values in the next field are registered in an IANA registry and their meanings defined in an RFC. If a vendor ID is non-zero, the values in the next field are vendor specific and defined by the vendor whose SMI Private Enterprise Number matches the vendor ID. Vendor-specific messages that are not understood by the recipient are ignored and skipped unless they have the NOSKIP flag set, in which case an error code is returned.
いくつかの場所では、PB-TNCは、標準値のセットを定義するだけでなく、ベンダー固有の拡張機能を許可する必要があります。これらの場所（PB-TNCメッセージの種類、PAサブタイプ、修復パラメータの種類、およびエラーコード）のそれぞれにおいて、選択したソリューションは、ベンダーIDと値を前置きすることでした。ベンダーIDが0の場合、次のフィールドの値は、IANAレジストリに登録されており、その意味は、RFCで定義されています。ベンダーIDがゼロでない場合、次のフィールドの値は、ベンダー固有の、そのSMI民間企業の数は、ベンダーIDと一致して、ベンダによって定義されています。彼らは、エラーコードが返される場合にNOSKIPフラグセットを持っていない限り、受信者によって理解されていないベンダー固有のメッセージは無視され、スキップされます。
PB-TNC needs to work with low bandwidth transports and low power devices. Therefore, a simple, compact format was chosen for the PB-TNC protocol: binary messages with a Type-Length-Value structure.
PB-TNCは、低帯域幅のトランスポートと低消費電力のデバイスで動作する必要があります。なType-Length-Valueの構造を有するバイナリメッセージ：したがって、シンプル、コンパクトな形式はPB-TNCのプロトコルのために選択しました。
The PB-TNC protocol carries batches of PB messages between a Posture Broker Client and a Posture Broker Server. It encapsulates PA messages and manages the NEA session. It runs over a PT protocol.
PB-TNCプロトコルは、姿勢ブローカークライアント・姿勢ブローカーサーバー間のPBメッセージのバッチを運びます。これは、PAメッセージをカプセル化し、NEAのセッションを管理します。これは、PTプロトコル上で動作します。
In order to work well over half-duplex PT protocols (such as those based on EAP [9]), PB-TNC supports half-duplex protocol operation. In this mode, the Posture Broker Client and Posture Broker Server take turns sending a single batch of messages to each other. While the half-duplex nature of PB-TNC could slow exchanges that require many round trips or bidirectional multimedia exchanges, this is not a problem in practice because endpoint assessments do not typically involve multimedia or a large number of round trips. The benefit of working over half-duplex transports outweighs any limitations imposed.
（例えば、EAP [9]に基づくものなど）半二重PTプロトコルでうまく動作するために、PB-TNCは、半二重プロトコルの動作をサポートします。このモードでは、姿勢ブローカークライアント・姿勢ブローカーサーバーは互いにメッセージの単一のバッチを送信するターンを取ります。 PB-TNCの半二重性質は、多くのラウンドトリップや双方向マルチメディアの交換が必要な交換を遅らせることもできますが、エンドポイントの評価は、一般的に、マルチメディアやラウンドトリップの多数を伴わないので、これは実際には問題ではありません。半二重の上に作業の利点は、課せられた制限事項を上回る輸送します。
PB-TNC also supports full-duplex protocol operation so that PB-TNC exchanges can be re-initialized immediately when needed (e.g., if the Posture Broker Server policy changes or if the Posture Broker Client detects a suspicious event).
必要なときPB-TNC交換（例えば、姿勢ブローカサーバのポリシーが変更された場合や姿勢ブローカクライアントが疑わしいイベントが検出された場合）、直ちに再初期化することができるように、PB-TNCはまた、全二重プロトコルの動作をサポートします。
Each PB-TNC batch consists of a header followed by a sequence of PB-TNC messages. Each PB-TNC message has a Type-Length-Value (TLV) format with a few flags. The TLV format allows a recipient to skip messages that it does not understand. The TLV format also provides a standard way to mark messages as mandatory to ensure interoperability between a Posture Broker Client and a Posture Broker Server.
各PB-TNCバッチは、PB-TNCメッセージのシーケンスが続くヘッダから成ります。各PB-TNCメッセージは、いくつかのフラグを有するタイプレングス値（TLV）形式を有します。 TLV形式は、受信者がそれを理解していないメッセージをスキップすることができます。 TLV形式も姿勢ブローカークライアント・姿勢ブローカーサーバー間の相互運用性を確保するために必須としてメッセージをマークするための標準的な方法を提供します。
This specification defines certain standard PB-TNC message types. It also permits vendors to define their own vendor-specific message types. One of the most important standard PB-TNC message types is PB-PA. A message with this type contains a PA message and various message routing information. A Posture Broker Client or Posture Broker Server that receives such a message does not interpret the PA message within. Instead, it delivers the PA message to the appropriate set of Posture Collectors or Posture Validators, as determined using the message routing information contained in the PB-PA message.
この仕様は、特定の標準PB-TNCのメッセージタイプを定義します。また、独自のベンダー固有のメッセージタイプを定義するために、ベンダーが可能になります。最も重要な標準PB-TNCメッセージの種類の一つは、PB-PAです。このタイプのメッセージは、PAメッセージや各種メッセージルーティング情報を含んでいます。このようなメッセージを受け取る姿勢ブローカークライアントや姿勢ブローカーサーバーは、内のPAメッセージを解釈することはありません。代わりに、PB-PAメッセージに含まれるルーティング情報メッセージを使用して決定されるように、姿勢コレクターや姿勢バリデータの適切なセットにPAメッセージを配信します。
A Posture Broker Server will often need to communicate with several Posture Broker Clients at once. The reverse may also be true, as when an endpoint has multiple network interfaces connected to different networks. Each connection between a Posture Broker Server and a Posture Broker Client is instantiated as a separate PB-TNC session. There may be several simultaneous sessions between a single Posture Broker Server and Posture Broker Client, but this is unusual.
姿勢ブローカーサーバーは、多くの場合、一度に複数のPosture Brokerのクライアントと通信する必要があります。逆もまたエンドポイントが異なるネットワークに接続された複数のネットワークインタフェースを有する場合のように、真であってもよいです。姿勢ブローカーサーバーと姿勢ブローカクライアント間の各接続は別々のPB-TNCセッションとしてインスタンス化されます。そこ単一姿勢ブローカーサーバーと姿勢Brokerのクライアントの間にはいくつかの同時セッションであってもよいが、これは珍しいですがあります。
Figure 1 illustrates the PB-TNC state machine, showing the set of states that a PB-TNC session can have and the possible transitions among these states. The following paragraphs describe this state machine in more detail.
図1は、PB-TNCセッションを持つことができる状態とこれらの状態間の可能な遷移のセットを示し、PB-TNC状態マシンを示します。次の段落では、より詳細にこのステート・マシンを記述する。
Receive CRETRY SRETRY
or SRETRY +----------------+
+--+ | |
v | v |
+---------+ CRETRY +---------+
CDATA | Server |<---------| Decided | CLOSE
+----------->| Working |--------->| |-------+
| +---------+ RESULT +---------+ |
| ^ | | v
| | | +---------------------->=======
======== | | CLOSE " End "
" Init " CDATA| |SDATA =======
======== | | ^ ^
| | | v | |
| | SDATA +---------+ CLOSE | |
| +-------->| Client |----------------------+ |
| | Working | |
| +---------+ |
| | ^ |
| +--+ |
| Receive CRETRY |
| CLOSE |
+--------------------------------------------------+
Figure 1: PB-TNC state machine
図1：PB-TNCステートマシン
In this diagram, states are indicated by rectangular boxes. The initial and terminal states have double outlines (with = and "). State transitions are indicated by unidirectional arrows marked with the cause of the transition.
この図では、状態は、長方形のボックスで示されています。初期と端末状態は、（=と「付き）二重の輪郭を持っている。状態遷移は、遷移の原因でマークされた一方向の矢印で示されています。
Many transitions (CDATA, SDATA, CRETRY, SRETRY, and RESULT) are triggered by the transmission or reception of a PB-TNC batch of a particular type. The type of a PB-TNC batch is indicated by the contents of the Batch Type field in the PB-TNC header for that batch. For brevity, this document says "a FOO batch" instead of "a PB-TNC batch whose Batch Type field contains FOO". Other transitions are triggered by receiving a PB-TNC batch of a particular type (e.g., Receive CRETRY). The CLOSE transition may be triggered by sending or receiving a CLOSE batch but may also be triggered by termination of the underlying PT connection.
多くの遷移（CDATA、SDATA、CRETRY、SRETRY、その結果が）特定のタイプのPB-TNCバッチの送信または受信によってトリガされます。 PB-TNCバッチの種類は、そのバッチのPB-TNCヘッダーのバッチ式フィールドの内容によって示されます。簡潔にするために、このドキュメントではなく、「バッチタイプフィールドは、FOOが含まれているPB-TNCバッチ」の「FOOバッチ」を言います。他の遷移は、特定のタイプ（例えば、CRETRY受信）のPB-TNCのバッチを受信することによってトリガーされます。 CLOSE遷移CLOSEバッチを送信または受信することによってトリガすることができるだけでなく、基礎となるPT接続の終了によってトリガされてもよいです。
A PB-TNC session starts in the Init state when the underlying transport protocol (PT) establishes a connection between a Posture Broker Client and a Posture Broker Server. If the Posture Broker Client initiated the underlying transport session, it starts by sending a CDATA batch to the Posture Broker Server, thus causing a transition to the Server Working state. If the Posture Broker Server initiated the transport session, it starts by sending a PB-TNC batch of type SDATA to the Posture Broker Client, thus causing a transition to the Client Working state.
基礎となるトランスポートプロトコル（PT）は姿勢ブローカクライアント・姿勢ブローカサーバ間の接続を確立するときPB-TNCセッションが初期状態で開始されます。姿勢ブローカークライアントが基盤となるトランスポート・セッションを開始した場合、それはこのようにサーバーの作業状態への遷移を引き起こし、姿勢ブローカーサーバーにCDATAのバッチを送信することにより開始します。姿勢ブローカーサーバーは、トランスポート・セッションを開始した場合、それはこのように、クライアントの作業状態への遷移を引き起こし、姿勢ブローカークライアントに型SDATAのPB-TNCのバッチを送信することにより開始します。
The Posture Broker Client and Posture Broker Server may now alternate sending CDATA and SDATA batches to each other. Only the Posture Broker Client can send a data batch when the session is in the Client Working state, and only the Posture Broker Server can send a data batch when the session is in the Server Working state.
姿勢ブローカークライアント・姿勢ブローカーサーバーは現在、別のはお互いにCDATAとSDATAのバッチを送信することがあります。セッションは、クライアントの作業状態にあるときにのみ姿勢ブローカークライアントは、データのバッチを送信することができ、そしてセッションはサーバーの作業状態にあるときにのみ姿勢ブローカーサーバーは、データのバッチを送信することができます。
The most common way to end an exchange is for the Posture Broker Server to send a RESULT batch. This causes a transition into the Decided state. This is not a terminal state. The PT session can remain open and another exchange can be initiated by having the Posture Broker Client send a CRETRY batch. This can be useful when the Posture Broker Client (or more likely a Posture Collector) discovers a suspicious condition on the endpoint, for example. If the underlying transport protocol (PT) supports full-duplex operation, the Posture Broker Server can also initiate another exchange from this state by sending a SRETRY batch. This can be useful when the policy changes on the server, for example.
姿勢ブローカーサーバーが結果バッチを送信するために交換を終了する最も一般的な方法です。これが決定状態に遷移させます。これは、端末の状態ではありません。 PTセッションが開いたままにすることができますし、別の交換が姿勢ブローカークライアントがCRETRYバッチを送信することによって開始することができます。姿勢ブローカクライアント（または可能性が高い姿勢コレクタ）は、例えば、エンドポイント上の不審な状況を発見したときに便利です。基礎となるトランスポートプロトコル（PT）は、全二重動作をサポートしている場合、姿勢ブローカサーバはまたSRETRYバッチを送信することにより、この状態から別の交換を開始することができます。ポリシーは、たとえば、サーバー上で変更する場合に便利です。
Whether an SRETRY or CRETRY message or both are sent, the next state is the Server Working State. From this state, the Posture Broker Server sends an SDATA batch and the new exchange begins. The state transitions marked Receive CRETRY and Receive CRETRY or SRETRY indicate that it is permissible to receive such messages in the indicated states, generally when the Posture Broker Client sent a CRETRY message at roughly the same time as the Posture Broker Server decided to send an SRETRY. In that case, a CRETRY message may be received while in the Server Working or Client Working state. Also, an SRETRY message may be received while in the Server Working state. These messages are redundant and therefore ignored, as indicated by the relevant transitions, which don't cause a state change.
SRETRYまたはCRETRYメッセージまたはその両方が送られているかどうかは、次の状態は、サーバの作業状態です。この状態から、姿勢ブローカーサーバーは、SDATAのバッチを送信し、新たな交換が開始されます。姿勢ブローカーサーバーはSRETRYを送信することを決定したとして、状態遷移はCRETRYを受信し、受信CRETRYまたはSRETRYを、姿勢ブローカークライアントがほぼ同時にCRETRYメッセージを送信したとき、一般的に、示された状態で、このようなメッセージを受け取ることは許されていることを示すマーク。サーバー作業又はクライアントの作業状態にしながら、その場合、CRETRYメッセージが受信されてもよいです。サーバーの状態を作業中にも、SRETRYメッセージを受信することができます。状態変化が発生することはありません関連する遷移によって示されるように、これらのメッセージは、冗長なので、無視しています。
The only terminal state is the End state. This state is reached if the underlying PT connection closes. This can be caused by an action of the Posture Broker Client or Posture Broker Server or it can be caused by some external factor, such as pulling the network plug. When possible, a CLOSE batch SHOULD be sent before the underlying PT connection is terminated. However, there may be cases where the PT connection is closed without notice. For example, a plug may be pulled, a software program may fail, or a Posture Broker Client or Posture Broker Server may be unable to send a CLOSE message due to half-duplex limitations in the underlying PT protocol. In these cases, the Posture Broker Client and Posture Broker Server will generally receive some form of notification from the Posture Transport Client and Posture Transport Server that the PT connection has been closed. This notification can trigger the CLOSE transition. However, the notification interaction is not standardized since the vertical interfaces in the NEA Reference Model are not standardized. In any case, the reception of the CLOSE batch or notification of termination of the transport causes the transition to the End state.
唯一の端末状態が終了状態です。基礎となるPT接続が閉じた場合、この状態に達しています。これは、姿勢ブローカクライアントや姿勢ブローカサーバの作用によることができ、またはそのようなネットワークプラグを引っ張るように、いくつかの外部要因によって引き起こされ得ます。可能な場合は基礎となるPTの接続が終了する前に、CLOSEバッチを送ってください。しかし、PT接続が予告なく閉鎖される場合があります。例えば、プラグは、ソフトウェアプログラムが失敗することがあり、引っ張ることができる、または姿勢ブローカクライアントや姿勢ブローカサーバが原因根底PTプロトコルにおける半二重限界に近いメッセージを送信することができません。これらのケースでは、姿勢ブローカークライアント・姿勢ブローカーサーバーは、一般的にPT接続が閉じられた姿勢交通クライアントおよび姿勢トランスポートサーバーからの通知のいくつかのフォームを受信します。この通知はCLOSE遷移を引き起こすことができます。 NEA参照モデルにおける垂直インターフェースが標準化されていないので、通知の相互作用は、標準化されていません。いずれの場合においても、搬送の終了CLOSEバッチまたは通知の受信が終了状態に遷移させます。
Note that a Posture Broker Client and Posture Broker Server may not always have exactly the same state for a given PB-TNC session. For example, say that a session is in the Client Working state and the Posture Broker Client transmits a CDATA batch. While this batch is in transit (transmitted by the Posture Broker Client but not yet received by the Posture Broker Server), the Posture Broker Client will think that the session is in Server Working state but the Posture Broker Server will think that the session is in Client Working state. However, this is a temporary condition and does not cause problems in practice. The only possible issue is that a Posture Broker Client or Posture Broker Server does not know whether the other party has received its message until it receives a response from the other party.
姿勢ブローカークライアントと姿勢ブローカーサーバーは、常に与えられたPB-TNCセッションのためのまったく同じ状態を持っていないことに注意してください。たとえば、セッションは、クライアントの作業状態にあり、姿勢ブローカークライアントがCDATAバッチを送信することを言います。このバッチはトランジット（姿勢ブローカクライアントが送信したが、まだ姿勢ブローカーサーバーによって受信されない）であるが、姿勢ブローカークライアントは、セッションがサーバーの作業状態にあると思いますが、姿勢ブローカーサーバーは、セッションがでていると思いますクライアントの作業状態。しかし、これは一時的な状態であり、実際に問題が発生することはありません。唯一の可能な問題は、姿勢ブローカークライアントや姿勢ブローカーサーバーは、それが他の当事者からの応答を受信するまで、相手がそのメッセージを受信したかどうかわからないということです。
If a half-duplex transport is used, note that the Posture Broker Server cannot send a SRETRY batch when the session is in the Decided state because the Posture Broker Server sent the most recent batch (the RESULT batch) and this would violate the half-duplex nature of the transport protocol. Instead, a server that wishes to initiate a new exchange in the Decided state when a half-duplex transport is in use should close the PT connection without sending a CLOSE batch and start a new PB-TNC session. This limitation does not exist when a full-duplex transport is used.
半二重トランスポートが使用されている場合は、姿勢ブローカーサーバーは、最新のバッチ（結果バッチ）に送られ、これは半分に違反するため、セッションが確定した状態にあるとき、姿勢ブローカーサーバーがSRETRYバッチを送信することはできませんのでご注意トランスポートプロトコルの二重本質。代わりに、半二重輸送が使用されているときに決めた状態で、新たな交換を開始したいサーバがCLOSEバッチを送信せずにPTの接続を閉じ、新しいPB-TNCセッションを開始する必要があります。全二重トランスポートを使用する場合、この制限は存在しません。
The Posture Broker Server and Posture Broker Client MUST follow the state machine described in this section.
姿勢ブローカーサーバーと姿勢ブローカークライアントは、このセクションで説明したステートマシンに従わなければなりません。
PB-TNC batches are carried over protocol bindings of the PT protocol, which provides the interaction between a Posture Transport Client and a Posture Transport Server. PB-TNC counts on PT to provide a secure transport. In particular, PT MUST support mutual authentication of the Posture Transport Client and the Posture Transport Server, confidentiality and integrity protection for PB-TNC batches, and protection against replay attacks. PB-TNC is unaware of the underlying transport protocols being used. PB-TNC operates directly on PT; no further layer of PB-TNC is expected.
PB-TNCバッチは姿勢交通クライアント・姿勢トランスポートサーバーとの間の相互作用を提供PTプロトコルのプロトコルバインディングを介して搬送されます。 PB-TNCは、安全な輸送を提供するために、PTにカウントされます。特に、PTは、姿勢交通クライアントと姿勢トランスポートサーバー、機密性と完全性PB-TNCバッチの保護、およびリプレイ攻撃に対する保護の相互認証をサポートしなければなりません。 PB-TNCは、基礎となるトランスポートプロトコルが使用されているのを認識しません。 PB-TNCはPT上で直接動作します。 PB-TNCのさらなる層が予想されていません。
RFC 5209 [8] describes normative requirements for the Posture Transport protocol. This section specifies additional requirements for the Posture Transport protocol. Candidate Posture Transport protocols must indicate conformance to requirements specified in this section as well as section 7.4 of RFC 5209.
RFC 5209 [8]姿勢トランスポートプロトコルのための規範的な要件について説明します。このセクションでは、姿勢トランスポートプロトコルのための追加要件を指定します。候補姿勢トランスポートプロトコルは、このセクションだけでなく、RFC 5209のセクション7.4で指定された要件への適合性を示さなければなりません。
The additional requirements for candidate PT protocols are:
候補PTプロトコルのための追加要件は次のとおりです。
PT-6 The PT protocol MUST be connection oriented; it MUST support confirmed initiation and close down.
PT-6ザPTプロトコルが接続指向でなければなりません。それを確認し、開始をサポートし、閉鎖しなければなりません。
PT-7 The PT protocol MUST be able to carry binary data.
PT-7 PTプロトコルは、バイナリデータを運ぶことができなければなりません。
PT-8 The PT protocol MUST provide mechanisms for flow control and congestion control.
PT-8ザPTプロトコルは、フロー制御および輻輳制御のためのメカニズムを提供しなければなりません。
PT-9 PT protocol specifications MUST describe the capabilities that they provide for and limitations that they impose on the PB protocol (e.g., half/full duplex, maximum message size).
PT-9 PTプロトコル仕様は、それらがPBプロトコル（例えば、半/全二重、メッセージの最大サイズ）に課す彼らが提供する機能と制限について説明しなければなりません。
This section shows how PA messages can be carried inside a PB-TNC batch that is inside a PT protocol.
このセクションでは、PAメッセージがPTプロトコルの内側にあるPB-TNCバッチ内で実施することができる方法を示しています。
Within the PT protocol, the PB-TNC header is packaged next, followed by two PB-PA messages that contain PA messages meant for the Posture Collectors and Posture Validators on the platform.
PTプロトコル内で、PB-TNCヘッダはPAメッセージは、プラットフォーム上の姿勢コレクターと姿勢バリのためのもの含む2つのPB-PAメッセージに続いて、次のパッケージ化されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example of PB-TNC message encapsulation
図2：PB-TNCメッセージのカプセル化の例
This figure is conceptual, of course, and not an exact byte-for-byte replica.
この図は、概念的もちろん、なくバイト単位での正確なレプリカです。
This section defines the syntax and semantics of the PB-TNC protocol fields. If a Posture Broker Client or Posture Broker Server receives a batch that violates the requirements of this specification, it MUST respond by sending a fatal Invalid Parameter error in a CLOSE batch unless this document specifies otherwise.
このセクションでは、PB-TNCのプロトコルフィールドの構文とセマンティクスを定義します。姿勢ブローカークライアントや姿勢ブローカーサーバーは、この仕様の要件に違反するバッチを受信した場合、この文書に特別な指示がない限り、それはCLOSEバッチで致命的な無効なパラメータエラーを送信することによって応答しなければなりません。
Every PB-TNC batch MUST start with the following header. A PB-TNC batch MUST contain only one instance of this header followed by zero or more PB-TNC messages. The PB-TNC messages are defined in subsequent sections of this specification.
すべてのPB-TNCバッチは、次のヘッダーで始まる必要があります。 PB-TNCバッチは、ゼロまたはそれ以上のPB-TNCメッセージに続くこのヘッダのインスタンスを1つだけ含まなければなりません。 PB-TNCメッセージは、この明細書の後の節で定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |D| Reserved | B-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (8 bits)
バージョン（8ビット）
This field indicates the version of the format for the PB-TNC message. This version is intended to allow for evolution of the PB-TNC protocol in a manner that can easily be detected by message recipients.
このフィールドは、PB-TNCメッセージのフォーマットのバージョンを示します。このバージョンは、容易にメッセージ受信者によって検出することができるようにPB-TNCプロトコルの進化を可能にするために意図されています。
This field MUST be set to 2 when the batch conforms to this specification. Later versions of PB-TNC may define other values for this field. The values 0x00, 0x09, 0x0a, 0x0d, 0x20, and 0x3c are reserved and cannot be used for any version of PB-TNC to ensure that PB-TNC can be easily distinguished from earlier posture broker protocols already in use.
バッチがこの仕様に準拠した場合、このフィールドは2に設定しなければなりません。 PB-TNCの以降のバージョンでは、このフィールドの他の値を定義することができます。値は0x00、0x09の、は0x0A、0x0Dを、0x20の、および0x3cのが予約されており、PB-TNCは、既に使用中の以前の姿勢ブローカープロトコルから容易に区別することができることを保証するために、PB-TNCの任意のバージョンのために使用することができません。
If a Posture Broker Client or Posture Broker Server receives a Version value that it does not support, it MUST respond with a PB-TNC batch with batch type CLOSE that contains only a fatal Version Not Supported error code and whose Version header field has the value 2. Implementations responding to a PB-TNC message containing a supported version MUST use the same Version number to minimize the risk of version incompatibility. PB-TNC message initiators that support multiple PB-TNC protocol versions SHOULD be able to alter which version of PB-TNC message they send based on prior message exchanges with a particular peer Posture Broker Client or Posture Broker Server.
姿勢ブローカークライアントや姿勢ブローカーServerがサポートしていないことをバージョン値を受信した場合、それはバージョンヘッダーフィールド値を持つエラーコードとサポートだけでなく、致命的なバージョンが含まれているバッチ式のCLOSEとPB-TNCバッチで応じなければなりませんバージョンの非互換性のリスクを最小限にするために、同じバージョン番号を使用する必要があり、サポートされるバージョンを含むPB-TNCメッセージに応答2.実装。複数PB-TNCプロトコルバージョンをサポートPB-TNCメッセージ開始剤は、それらが特定のピア姿勢ブローカクライアントや姿勢ブローカサーバ先行メッセージ交換に基づいて送るPB-TNCメッセージのバージョンを変更することができるべきです。
Directionality (D) (1 bit)
指向性（D）（1ビット）
When a Posture Broker Client is sending this message, the Directionality bit MUST be set to 0. When a Posture Broker Server is sending this message, the Directionality bit MUST be set to 1. This helps avoid any situation where two Posture Broker Clients or two Posture Broker Servers engage in a dialog. It also helps with debugging.
姿勢ブローカクライアントがこのメッセージを送信しているときの姿勢ブローカーサーバーは、これはどのような状況を回避でき、方向性ビットを1に設定しなければならない。このメッセージを送信しているときに、方向性ビットが0に設定されなければならない2つの姿勢ブローカークライアントまたは2姿勢ブローカーサーバーは、ダイアログに従事します。また、デバッグに役立ちます。
Reserved (19 bits)
予約（19ビット）
This field is reserved. For this version of this specification, it MUST be set to 0 on transmission and ignored on reception. Future versions of this specification may allow senders to set some of these bits and recipients to interpret them.
このフィールドは予約されています。本明細書のこのバージョンのために、それは送信時に0に設定しなければならなくて、受信時には無視します。この仕様の将来のバージョンでは、送信者がそれらを解釈するために、これらのビットと受信者のいくつかを設定できるようにしてもよいです。
B-Type (Batch Type) (4 bits)
B型（バッチタイプ）（4ビット）
This field is used to drive the state machine described in section 3.2. This field MUST have one of the values from the following table. If any other value is received, the recipient MUST ignore the contents of the batch and send a fatal Invalid Parameter error code in a CLOSE batch. If the value received is not permitted for the current state, according to the state machine in section 3.2., the recipient MUST ignore the contents of the batch and send a fatal Unexpected Batch Type error code in a CLOSE batch.
このフィールドは、セクション3.2で説明したステートマシンを駆動するために使用されます。このフィールドには、次の表のいずれかの値を持たなければなりません。他の値を受信した場合、受信者は、バッチの内容を無視して、CLOSEバッチに致命的な無効なパラメータのエラーコードを送信しなければなりません。受信された値は3.2でステートマシンによれば、現在の状態のために許可されていない場合、受信者は、バッチの内容を無視して、CLOSEバッチに致命的な予期しないバッチ式エラーコードを送信しなければなりません。
Number Name Definition
------ ---- ----------
1 CDATA The Posture Broker Client may send a batch with this Batch Type to convey messages to the Posture Broker Server. A Posture Broker Server MUST NOT send this Batch Type. A CDATA batch may be empty (contain no messages) if the Posture Broker Client has nothing to send.
1 CDATAザ・姿勢ブローカーClientは姿勢ブローカーサーバーにメッセージを伝えるために、このバッチタイプでバッチを送信することができます。姿勢ブローカーサーバーは、このバッチタイプを送ってはいけません。姿勢ブローカークライアントが送信するために何もしていた場合にCDATAバッチが空であってもよい（何もメッセージが含まれていません）。
2 SDATA The Posture Broker Server may send a batch with this Batch Type to convey messages to the Posture Broker Client. A Posture Broker Client MUST NOT send this Batch Type. An SDATA batch may be empty (contain no messages) if the Posture Broker Server has nothing to send.
2 SDATAザ・姿勢ブローカーサーバーは、姿勢ブローカクライアントにメッセージを伝えるために、このバッチタイプでバッチを送信することができます。姿勢ブローカークライアントは、このバッチタイプを送ってはいけません。姿勢ブローカーサーバーが送信するためには何も持っていない場合SDATAバッチが空であってもよい（何もメッセージが含まれていません）。
3 RESULT The Posture Broker Server may send a batch with this Batch Type to indicate that it has completed its evaluation. The batch MUST include a PB-Assessment-Result message and MAY include a PB-Access-Recommendation message.
3 RESULT姿勢ブローカーサーバーは、その評価を完了したことを示すために、このバッチタイプでバッチを送信することができます。バッチは、PB-アセスメント結果メッセージを含まなければならないし、PB-ACCESS勧告メッセージを含んでいてもよいです。
4 CRETRY The Posture Broker Client may send a batch with this Batch Type to indicate that it wishes to restart an exchange. A Posture Broker Server MUST NOT send this Batch Type. A CRETRY batch may be empty (contain no messages) if the Posture Broker Client has nothing else to send.
4 CRETRYザ・姿勢ブローカークライアントは、それが交流を再開したいことを示すために、このバッチタイプでバッチを送信することができます。姿勢ブローカーサーバーは、このバッチタイプを送ってはいけません。姿勢ブローカークライアントが送信するために何もしていない場合CRETRYバッチが空であってもよい（何もメッセージが含まれていません）。
5 SRETRY The Posture Broker Server may send a batch with this Batch Type to indicate that it wishes to restart the exchange. A Posture Broker Client MUST NOT send this Batch Type. A SRETRY batch may be empty (contain no messages) if the Posture Broker Server has nothing else to send.
5 SRETRY姿勢ブローカーサーバーは、それが交流を再開したいことを示すために、このバッチタイプでバッチを送信することができます。姿勢ブローカークライアントは、このバッチタイプを送ってはいけません。姿勢ブローカーサーバーが送信するために何もしていない場合SRETRYバッチが空であってもよい（何もメッセージが含まれていません）。
6 CLOSE The Posture Broker Server or Posture Broker Client may send a batch with this Batch Type to indicate that it is about to terminate the underlying PT connection. A CLOSE batch may be empty (contain no messages) if there is nothing to send. However, if the termination is due to a fatal error, then the CLOSE batch MUST contain a PB-Error message.
6 CLOSE姿勢ブローカーサーバーや姿勢ブローカークライアントは、基礎となるPTの接続を終了しようとしていることを示すために、このバッチタイプでバッチを送信することができます。 CLOSEバッチは空で送信するためには何も存在しない場合（何もメッセージが含まれていない）ことがあります。終了は致命的なエラーが原因である場合は、[閉じるバッチは、PB-エラーメッセージを含まなければなりません。
Batch Length (32 bits)
バッチの長さ（32ビット）
This length field contains the size of the full PB-TNC batch in octets. This length includes the PB-TNC header and all the PB-TNC messages in the batch. In other words, it includes the entire contents of the batch. This field MUST contain at least the value 8 for the fixed-length fields in this header. Any Posture Broker Client or Posture Broker Server that receives a PB-TNC message with a PB-TNC Message Length field whose value is less than 8 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
この長さフィールドは、オクテットでフルPB-TNCバッチのサイズが含まれています。この長さは、PB-TNCヘッダーとバッチ内のすべてのPB-TNCのメッセージを含みます。言い換えれば、それはバッチのすべての内容を含んでいます。このフィールドは、このヘッダ内の固定長フィールドに少なくとも8の値を含まなければなりません。任意姿勢ブローカクライアント又はその値が8未満であるCLOSEバッチにおける致命的な無効なパラメータのエラーコードで応答しなければならないPB-TNCメッセージ長フィールドとPB-TNCのメッセージを受信したポスチャブローカサーバ。
All PB-TNC messages have the same overall structure, which is described in this section. Of course, the format and semantics of the PB-TNC Message Value field will vary, depending on the values of the PB-TNC Vendor ID and PB-TNC Message Type fields.
すべてのPB-TNCメッセージは、このセクションで説明されているのと同じ全体構造を、持っています。もちろん、形式及びPB-TNCメッセージ値フィールドのセマンティクスは、PB-TNCのベンダーID及びPB-TNCメッセージタイプフィールドの値に依存して、変化するであろう。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PB-TNC Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
フラグ（8ビット）
This field defines flags impacting the processing of this message.
このフィールドは、このメッセージの処理に影響を与えるフラグを定義します。
Bit 0 of this Flags field (the most significant bit) is known as the NOSKIP flag. If this flag is cleared (value 0), then the recipient (a Posture Broker Client or Posture Broker Server) may skip (ignore) this message if the message type is not understood or the recipient cannot or will not process the message as required in the definition of that message. If this flag is set (value 1), then recipients MUST NOT skip this attribute.
このフラグフィールド（最上位ビット）のビット0はNOSKIPフラグとして知られています。このフラグがクリアされている場合（値が0）、次いで、レシピエント（姿勢ブローカクライアントや姿勢ブローカサーバ）がスキップ（無視）このメッセージをメッセージタイプが理解されていない場合、またはで必要に応じて、受信者は、またはメッセージを処理しないであろうことができないかもしれそのメッセージの定義。このフラグが（値1）に設定されている場合、受信者は、この属性を省略してはなりません。
This flag does not mean that all recipients must support this message. Instead, any recipient that receives a message with this flag set to 1 but cannot or will not process it as required MUST NOT act on any part of the PB-TNC batch. Instead, the recipient MUST respond with a fatal Unsupported Mandatory Message error code in a CLOSE batch. In order to avoid taking action on some messages in a batch only to later find an unsupported NOSKIP flagged message, recipients of a PB-TNC batch might choose to scan all of the messages in the batch prior to acting upon any of the messages, checking to determine whether one of them is an unsupported message with the NOSKIP flag set.
このフラグは、すべての受信者がこのメッセージをサポートしなければならないことを意味するものではありません。その代わりに、1に設定され、このフラグを有するメッセージを受信するができない、または必要に応じてそれを処理しない任意の受信者は、PB-TNCバッチの任意の部分に作用してはいけません。代わりに、受信者はCLOSEバッチで致命的なサポートされていない必須のメッセージのエラーコードで応じなければなりません。以降でのみサポートされていないNOSKIPがメッセージをフラグを立て見つけるために、バッチ内の一部のメッセージに行動を取る避けるために、PB-TNCバッチの受信者が確認し、前のメッセージのいずれかに作用するバッチ内のすべてのメッセージをスキャンすることを選択するかもしれませんそれらの一つはNOSKIPフラグが設定されたサポートされていないメッセージであるかどうかを決定します。
The other bits in this Flags field are reserved. For this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception.
このFlagsフィールド内の他のビットは予約されています。 PB-TNCのこのバージョンのために、彼らは、送信時に0に設定しなければならなくて、レセプションで無視します。
PB-TNC Vendor ID (24 bits)
PB-TNCのベンダーID（24ビット）
The PB-TNC Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. This Vendor ID qualifies the PB-TNC Message Type field so that each vendor has 2^32-1 separate message types available for their use.
PB-TNCベンダーIDフィールドは、SMI民間企業番号（PEN）を使用して、ベンダーを識別します。どのような組織は、IANA、インターネット割り当て番号機関から独自のPENを受け取ることができます。各ベンダーは、それらの使用のための可能な2 ^ 32-1個別のメッセージの種類を持っているように、このベンダーIDは、PB-TNCメッセージタイプフィールドを修飾します。
Message types standardized by the IETF use zero (0) in this field. The Vendor ID 0xffffff is reserved. Posture Broker Clients and Posture Broker Servers MUST NOT send messages in which the Vendor ID has this reserved value (0xffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PB-TNC Vendor ID has this reserved value (0xffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
この分野におけるIETF使用ゼロ（0）によって標準化されたメッセージの種類。ベンダID 0xFFFFFFのが予約されています。姿勢ブローカクライアントと姿勢ブローカーサーバーは、ベンダーIDは、この予約値（0xFFFFFFのを）持っているメッセージを送ってはいけません。姿勢ブローカクライアントや姿勢ブローカサーバがPB-TNCベンダーIDは、この予約値（0xFFFFFFの）を有しているメッセージを受信した場合、それはCLOSEバッチで致命的な無効なパラメータのエラーコードで応答しなければなりません。
PB-TNC Message Type (32 bits)
PB-TNCメッセージタイプ（32ビット）
The PB-TNC Message Type field identifies the type of the PB-TNC message contained in the PB-TNC Message Value field. The PB-TNC message type 0xffffffff is reserved. Posture Broker Clients and Posture Broker Servers MUST NOT send messages in which the PB-TNC Message Type field has this reserved value (0xffffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PB-TNC Message Type field has this reserved value (0xffffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Unless otherwise prohibited in the definition of a particular PB-TNC message type (e.g., PB-Language-Preference), a single PB-TNC batch may contain multiple messages with the same message type and/or vendor ID.
PB-TNCメッセージタイプフィールドは、PB-TNCメッセージ値フィールドに含まPB-TNCメッセージのタイプを識別する。 PB-TNCメッセージタイプ0xFFFFFFFFのが予約されています。姿勢ブローカクライアントと姿勢ブローカーサーバーは、PB-TNCメッセージタイプフィールドは、この予約値（0xffffffffのを）持っているメッセージを送ってはいけません。姿勢ブローカークライアントや姿勢ブローカーサーバーは、PB-TNCメッセージタイプフィールドは、この予約値（0xffffffffのを）持っているメッセージを受信した場合、それはCLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりません。そうでなければ特定のPB-TNCメッセージタイプ（例えば、PB-言語嗜好）の定義に禁止されない限り、単一PB-TNCバッチは同じメッセージ・タイプおよび/またはベンダーIDで複数のメッセージを含んでいてもよいです。
The IETF and any other organization with a PEN can define 2^32-1 unique PB-TNC message types, as long as the organization's PEN is placed in the PB-TNC Vendor ID field of the message. Since the PB-TNC message type is qualified by the vendor ID, there is no risk of conflicts as long as each organization uses its own PEN for the vendor ID and manages its own set of 2^32-1 message type values.
IETF及びPENを有する任意の他の組織であれば、組織のPENがメッセージのPB-TNCベンダIDフィールドに配置されるように、2 ^ 32-1一意PB-TNCのメッセージタイプを定義することができます。 PB-TNCメッセージタイプはベンダーIDで修飾されているので、限り、各組織は、ベンダIDのために独自のPENを使用し、2 ^ 32-1メッセージタイプ値の独自のセットを管理するように衝突の危険性はありません。
This document defines certain PB-TNC message types that, when used with the IETF SMI PEN (0), have standard meanings. These are known as IETF Standard PB-TNC Message Types. Some of these PB-TNC message types are mandatory and therefore MUST be implemented by all Posture Broker Client and Posture Broker Server implementations that claim compliance with this specification. For details on which PB-TNC message types are mandatory, see the description of these message types later in section 4.
この文書は、IETF SMI PEN（0）で使用される、特定のPB-TNCのメッセージタイプを定義し、標準的な意味を有します。これらは、IETF標準のPB-TNCメッセージタイプとして知られています。これらのPB-TNCメッセージタイプのいくつかは必須であるため、この仕様への準拠を主張するすべての姿勢ブローカークライアントと姿勢ブローカーサーバーの実装によって実装されなければなりません。 PB-TNCメッセージタイプが必須であるの詳細については、後のセクション4で、これらのメッセージタイプの説明を参照してください。
IANA maintains a registry of PB-TNC message types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
IANAは、PB-TNCメッセージタイプのレジストリを維持します。このレジストリのエントリはセクション6.1のガイドライン以下、仕様が必要であるとの専門家レビューによって追加されます。
New vendor-specific PB-TNC message types (those used with a non-zero PB-TNC vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PB-TNC message types and MUST interoperate with other parties despite any differences in the set of vendor-specific PB-TNC message types supported (although they MAY permit administrators to configure them to require support for specific PB-TNC message types).
新しいベンダー固有のPB-TNCメッセージタイプ（非ゼロPB-TNCベンダーIDで使用されるもの）、IETFまたはIANAの関与なしで定義され、ベンダによって使用されてもよいです。しかし、姿勢ブローカークライアントおよび姿勢ブローカーサーバーは、特定のベンダー固有のPB-TNCメッセージタイプのサポートを要求してはなりませんし、それらが許可してもよいが、（サポート対象のベンダー固有のPB-TNCメッセージタイプのセットの違いにもかかわらず、他の関係者と相互運用しなければなりません）特定のPB-TNCメッセージタイプのためのサポートを必要とするように設定するには、管理者。
Note that the PB-TNC Message Type field is completely separate from the PA Subtype field. The same value (e.g., 0) may have different meanings as a PB-TNC message type and as a PA subtype.
PB-TNCメッセージタイプフィールドは、PAのサブタイプフィールドから完全に分離されていることに注意してください。同じ値（例えば、0）PB-TNCメッセージタイプ等のPAサブタイプとして異なる意味を有していてもよいです。
PB-TNC Message Length (32 bits)
PB-TNCメッセージ長（32ビット）
This field specifies the length of this PB-TNC message in octets. It includes this header (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length). Therefore, this value MUST always be at least 12. Any Posture Broker Client or Posture Broker Server that receives a message with a PB-TNC Message Length field whose value is less than 12 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
このフィールドは、オクテットで、このPB-TNCメッセージの長さを指定します。これは、このヘッダ（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージ・タイプ、およびPB-TNCメッセージ長）を含みます。したがって、この値は常にその値が12未満であるPB-TNCメッセージ長のフィールドを有するメッセージを受信する任意の姿勢ブローカクライアントや姿勢ブローカサーバがCLOSEバッチで致命的な無効なパラメータのエラーコードで応答しなければならない、少なくとも12でなければなりません。
PB-TNC Message Value (variable length)
PB-TNCメッセージ値（可変長）
The syntax and semantics of this field vary, depending on the values in the PB-TNC Vendor ID and PB-TNC Message Type fields. The syntax and semantics of several standard messages are defined in subsequent sections of this specification.
構文とこのフィールドのセマンティクスは、PB-TNCのベンダーIDおよびPB-TNCメッセージタイプフィールドの値によって異なります。いくつかの標準メッセージの構文と意味は、本明細書の後の節で定義されています。
The following table provides a reference list with brief descriptions of the IETF Standard PB-TNC Message Types defined in this specification. These PB-TNC message types must be used with a PB-TNC vendor ID of zero (0). If these PB-TNC message type values are used with a different PB-TNC vendor ID, they have a completely different meaning that is not defined in this specification.
次の表は、この明細書で定義されているIETF標準PB-TNCメッセージタイプの簡単な説明で参照リストを提供します。これらPB-TNCメッセージタイプは、ゼロ（0）のPB-TNCのベンダーIDと一緒に使用されなければなりません。これらPB-TNCメッセージタイプ値が異なるPB-TNCベンダーIDと共に使用される場合、それらは、本明細書で定義されていない完全に異なる意味を持ちます。
For more details on these message types, see the remainder of section 4. For IETF Standard PA Subtypes (which are completely different from PB-TNC message types), please refer to the PA-TNC specification [10].
これらのメッセージタイプの詳細については、（PB-TNCメッセージタイプとは全く異なっている）IETF標準PAサブタイプ部4の残りの部分を参照して、PA-TNC仕様[10]を参照してください。
Message Type Definition
------------ ----------
0 PB-Experimental - reserved for experimental use
1 PB-PA - contains a PA message
2 PB-Assessment-Result - the overall assessment result
computed by the Posture Broker Server
3 PB-Access-Recommendation - includes Posture Broker
Server access recommendation
4 PB-Remediation-Parameters - includes Posture Broker
Server remediation parameters
5 PB-Error - error indicator
6 PB-Language-Preference - sender's preferred
language(s) for human-readable strings
7 PB-Reason-String - string explaining reason for
Posture Broker Server access recommendation
The PB-Experimental PB-TNC message type is a PB-TNC message type (value 0) that has been set aside for experimental purposes. It may be used to test code or for other experimental purposes. It MUST NOT be used in a production environment or in a product. This meaning for this PB-TNC message type only applies if the PB-TNC Vendor ID field in the PB-TNC Message Header contains the value zero (0). If a different Vendor ID is contained in that field, the PB-TNC message type 0 has a completely different meaning not defined in this specification.
PB-実験PB-TNCメッセージタイプは、実験の目的のために確保されているPB-TNCメッセージタイプ（値0）です。これは、テストコード、または他の実験目的のために使用することができます。これは、本番環境または製品に使用してはいけません。このPB-TNCのメッセージタイプについて、この意味は、PB-TNCメッセージヘッダーにおけるPB-TNCベンダIDフィールドが値ゼロが含まれている場合に適用される（0）。異なるベンダIDがそのフィールドに含まれている場合、PB-TNCメッセージタイプ0は、本明細書で定義されていない完全に異なる意味を持ちます。
The contents of the PB-TNC Message Length and PB-TNC Message Value fields for this PB-TNC message type are not specified. They may have almost any value, depending on what experiments are being conducted. Similarly, the Flags field for this message may have the NOSKIP bit set or cleared, depending on what experiments are being conducted. However, note that the PB-TNC Message Length field must have a value of at least 12 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length). Any Posture Broker Client or Posture Broker Server that receives a message with a PB-TNC Message Length field whose value is invalid MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
このPB-TNCメッセージタイプのためのPB-TNCメッセージ長、およびPB-TNCメッセージ値フィールドの内容が指定されていません。彼らは、実験が行われているものに応じて、ほぼすべての値を有することができます。同様に、NOSKIPを有していてもよく、このメッセージのFlagsフィールドは、ビットセットや実験が行われているものに応じて、クリア。しかし、それは、PB-TNCメッセージ（フィールドフラグ、PB-TNCの開始時の固定長フィールドの長さの合計であるので、PB-TNCメッセージ長フィールドは、少なくとも12の値を有していなければならないことに注意してくださいベンダーID、PB-TNCメッセージ・タイプ、およびPB-TNCメッセージ長）。任意の姿勢ブローカークライアントまたは値は無効ですCLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりませんPB-TNCメッセージ長さフィールドを持つメッセージを受信した姿勢ブローカーサーバー。
A Posture Broker Client or Posture Broker Server implementation intended for production use MUST NOT send a message with this Message Type with the value zero (0) as the vendor ID. If it receives a message with this message type and with the value zero (0) as the vendor ID, it MUST ignore the message unless the NOSKIP bit is set, in which case it MUST respond with a fatal Unsupported Mandatory Message error code in a CLOSE batch.
生産使用のために意図姿勢ブローカクライアントや姿勢ブローカサーバの実装では、ベンダIDとして、値がゼロ（0）で、このメッセージタイプのメッセージを送ってはいけません。それは、このメッセージタイプで、ベンダーIDなどの値がゼロ（0）でメッセージを受信した場合、それは致命的なサポートされていない必須のメッセージのエラーコードで応答しなければならない場合にはNOSKIPビットが設定されていない限りメッセージを無視しなければなりませんCLOSEバッチ。
The PB-TNC message type named PB-PA (value 1) contains one PA message. Many batches will contain several PB-PA messages, but some batches may not contain any messages of this type.
PB-PA（値1）と名付けられたPB-TNCメッセージタイプは、一PAメッセージを含みます。多くのバッチは、いくつかのPB-PAメッセージが含まれていますが、いくつかのバッチは、このタイプのすべてのメッセージを含めることはできません。
All Posture Broker Client and Posture Broker Server implementations MUST implement support for this PB-TNC message type. Generally, this support will consist of forwarding the enclosed PA message to the appropriate Posture Collectors and Posture Validators. Specific requirements are contained later in the description of this message type.
すべての姿勢ブローカークライアントと姿勢ブローカーサーバーの実装は、このPB-TNCメッセージタイプのサポートを実装しなければなりません。一般的に、このサポートは、適切な姿勢コレクターと姿勢バリに囲まれたPAメッセージを転送で構成されます。特定の要件は、後に、このメッセージタイプの記述に含まれています。
The type of the PA message contained in a PB-PA message is indicated by the PA Message Vendor ID and PA Subtype fields, as described later in this section. The PA-TNC specification [10] describes several standard PA message types that can be identified by the PA Message Vendor ID and PA Subtype values listed in the PA-TNC specification. Other PA message types may also be defined, as described in the description of the PA Subtype field later in this section.
このセクションで後述するように、PB-PAメッセージに含まれるPAメッセージのタイプは、PAメッセージベンダID及びPAサブタイプフィールドで示されています。 PA-TNC仕様[10] PA-TNC仕様に記載されているPAメッセージベンダID及びPAサブタイプ値によって識別することができるいくつかの標準PAメッセージタイプを記述する。このセクションで後述PAサブタイプフィールドの説明に記載されているように他のPAメッセージタイプはまた、定義されてもよいです。
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. Any Posture Broker Client or Posture Broker Server that receives a PB-PA message with the NOSKIP flag not set MUST ignore the message and MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージヘッダ内NOSKIPフラグは、このメッセージタイプに設定しなければなりません。任意の姿勢ブローカーClientまたは設定されていないNOSKIPフラグでPB-PAメッセージを受信した姿勢ブローカーサーバーは、メッセージを無視しなければなりませんし、CLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりません。
For the PB-PA message type, the PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 1. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 1 has a completely different meaning not defined in this specification.
PB-PAメッセージタイプのために、PB-TNCベンダIDフィールドは、値を含まなければならないゼロ（0）と非ゼロ値をPB-TNCベンダーIDに含まれている場合PB-TNCメッセージタイプフィールドは1を含まなければなりませんフィールドには、メッセージタイプ1は、この仕様で定義されていない完全に異なる意味を持ちます。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, PA Message Vendor ID, PA Subtype, Posture Collector Identifier, and Posture Validator Identifier), and the PA Message Body. Since the PA Message Body is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 24 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client or Posture Broker Server that receives a PB-PA message with a PB-TNC Message Length field that has an invalid value MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージ長フィールドは、PB-TNCメッセージ（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプの開始時の固定長フィールドを含む、全体のPB-TNCメッセージの長さを含まなければなりません、およびPB-TNCメッセージ長）、（フラグ、PAメッセージベンダーID、PAサブタイプ、姿勢コレクタ識別子、及び姿勢検証識別子）、およびPAメッセージ本文下記固定長フィールド。 PAメッセージ本文が可変長であることから、PB-TNCのメッセージ長フィールドの値も変化します。しかし、それは常に先行する文に記載されている固定長フィールドをカバーするために、少なくとも24でなければなりません。 CLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりません無効な値を持つPB-TNCメッセージ長フィールドでPB-PAメッセージを受信し、任意の姿勢ブローカークライアントや姿勢ブローカーサーバー。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのフォーマットとPB-TNCメッセージ値フィールドの内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA Message Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Posture Collector Identifier | Posture Validator Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Message Body (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
フラグ（8ビット）
This field contains flags relating to the PA message.
このフィールドには、PAメッセージに関連するフラグが含まれています。
Bit 0 of this flags field (the most significant bit) is known as the EXCL flag (for exclusive). If the EXCL bit is cleared (value 0), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message SHOULD deliver the PA message contained in this PB-TNC message to all Posture Collectors or Posture Validators that have expressed an interest in PA messages with this PA Message Vendor ID and PA subtype. If a Posture Broker Client receives a message with the EXCL flag set (value 1), the Posture Broker Client SHOULD deliver the PA message contained in this PB-TNC message only to the Posture Collector identified by the Posture Collector Identifier field. However, if the identified Posture Collector has not expressed an interest in PA messages with this PA Message Vendor ID and PA subtype, the PA message should be silently discarded. Analogous requirements apply to a Posture Broker Server that receives a message with the EXCL flag set.
このフラグフィールド（最上位ビット）のビット0は、（排他用）EXCLフラグとして知られています。 EXCLビットがクリアされている場合（値が0）、すべての姿勢コレクターや姿勢バリこのPB-TNCメッセージに含まれるPAメッセージを配信すべきである。このPB-TNCメッセージを受信する姿勢ブローカクライアントや姿勢ブローカサーバは、関心を表明していることこのPAメッセージベンダーIDおよびPAサブタイプとPAメッセージインチ姿勢ブローカクライアントはEXCLフラグを設定（値1）でメッセージを受信した場合、姿勢ブローカクライアントはポスチャコレクタ識別子フィールドによって識別姿勢コレクタこのPB-TNCメッセージに含まれるPAメッセージを配信すべきです。識別姿勢コレクターはこのPAメッセージベンダーIDおよびPAサブタイプとPAメッセージに関心を示していない場合は、PAメッセージは静かに捨てられるべきです。類似の要件はEXCLフラグを設定してメッセージを受信した姿勢ブローカーサーバーに適用されます。
The EXCL bit allows, for example, a Posture Validator to handle the circumstance where there are two Posture Collectors on the endpoint that are interested in a particular kind of PA messages and the Posture Validator has remediation instructions that only apply to one of those Posture Collectors.
EXCLビットは、例えば、可能、PAメッセージの特定の種類及び姿勢検証に関心のあるエンドポイント上の2人の姿勢コレクターが存在する状況を処理する姿勢Validatorはのみ姿勢コレクターのいずれかに適用する修正命令を有します。
The other bits in this Flags field are reserved. For this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception.
このFlagsフィールド内の他のビットは予約されています。 PB-TNCのこのバージョンのために、彼らは、送信時に0に設定しなければならなくて、レセプションで無視します。
PA Message Vendor ID (24 bits)
PAメッセージベンダーID（24ビット）
The PA Message Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The PA Message Vendor ID qualifies the PA Subtype field so that each vendor has 2^32-1 separate PA subtypes available for its use. PA subtypes standardized by the IETF are always used with a PA Message Vendor ID of the value zero (0) in this field. The PA Message Vendor ID 0xffffff is reserved. A Posture Broker Client or Posture Broker Server MUST NOT send messages in which the PA Message Vendor ID field has this reserved value (0xffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PA Message Vendor ID has this reserved value (0xffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PAメッセージベンダーIDフィールドは、SMI民間企業番号（PEN）を使用して、ベンダーを識別します。どのような組織は、IANA、インターネット割り当て番号機関から独自のPENを受け取ることができます。各ベンダーは、その使用のために利用可能な2 ^ 32-1個別のPAサブタイプを持つようにPAメッセージベンダーIDは、PAサブタイプフィールドを修飾します。 IETFで標準化PAサブタイプは、常にこのフィールドの値がゼロ（0）のPAメッセージベンダーIDと共に使用されます。 PAメッセージベンダーIDの0xFFFFFFのが予約されています。姿勢ブローカークライアントや姿勢ブローカーサーバーはPAメッセージベンダーIDフィールドは、この予約値（0xFFFFFFのを）持っているメッセージを送ってはいけません。姿勢ブローカークライアントや姿勢ブローカーサーバーはPAメッセージベンダーIDは、この予約値（0xFFFFFFのを）持っているメッセージを受信した場合、それはCLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりません。
PA Subtype (32 bits)
PAサブタイプ（32ビット）
The PA Subtype field identifies the type of the PA message contained in the PA Message Body field. The PA subtype 0xffffffff is reserved. A Posture Broker Client or Posture Broker Server MUST NOT send messages in which the PA Subtype field has this reserved value (0xffffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PA Subtype has this reserved value (0xffffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. A Posture Broker Client or Posture Broker Server MUST support having multiple PA messages in a single PB-TNC batch that have the same PA subtype and/or PA Message Vendor ID.
PAサブタイプフィールドはPAメッセージ本文フィールドに含まれるPAメッセージのタイプを識別する。 PAのサブタイプは0xffffffffが予約されています。姿勢ブローカークライアントや姿勢ブローカーサーバーは、PAサブタイプのフィールドは、この予約値（0xffffffffのを）持っているメッセージを送ってはいけません。姿勢ブローカークライアントや姿勢ブローカーサーバーはPAサブタイプは、この予約値（0xffffffffのを）持っているメッセージを受信した場合、それはCLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりません。姿勢ブローカークライアントや姿勢ブローカーサーバーは同じPAサブタイプおよび/またはPAメッセージベンダーIDを持つ単一PB-TNCバッチで複数のPAメッセージを持つサポートしなければなりません。
IANA maintains a registry of PA subtypes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. No PA subtypes are
IANAは、PAサブタイプのレジストリを維持します。このレジストリのエントリはセクション6.1のガイドライン以下、仕様が必要であるとの専門家レビューによって追加されます。いいえPAのサブタイプがありません
defined in this specification. Definitions of IETF Standard PA Subtypes are contained in the PA-TNC specification [10] and other specifications. IETF Standard PA Subtypes are always used with a PA Message Vendor ID of zero (0).
この仕様で定義されています。 IETF標準PAサブタイプの定義は、PA-TNC仕様[10]、およびその他の仕様に含まれています。 IETF標準PAサブタイプは常にゼロのPAメッセージベンダーID（0）で使用されています。
New vendor-specific PA subtypes (those used with a non-zero PA Message Vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PA subtypes and MUST interoperate with other parties despite any differences in the set of vendor-specific PA subtypes supported (although they MAY permit administrators to configure them to require support for specific PA subtypes).
新しいベンダー固有のPAサブタイプ（非ゼロPAメッセージベンダーIDと共に使用されるもの）、IETFまたはIANAの関与なしで定義され、ベンダによって使用されてもよいです。しかし、姿勢ブローカークライアントおよび姿勢ブローカーサーバーは、特定のベンダー固有のPAサブタイプのサポートを要求してはなりませんし、彼らが必要とするためにそれらを設定するには、管理者が許可することができるが、（サポート対象のベンダー固有のPAサブタイプのセットの違いにもかかわらず、他の関係者と相互運用しなければなりません特定のPAサブタイプをサポート）。
Note that the PB-TNC Message Type field is completely separate from the PA Subtype field. The same value (e.g., 0) may have different meanings as a PB-TNC message type and as a PA subtype.
PB-TNCメッセージタイプフィールドは、PAのサブタイプフィールドから完全に分離されていることに注意してください。同じ値（例えば、0）PB-TNCメッセージタイプ等のPAサブタイプとして異なる意味を有していてもよいです。
Posture Collector Identifier (16 bits)
姿勢コレクタ識別子（16ビット）
The Posture Collector Identifier field contains the identifier of the Posture Collector associated with this PA message.
姿勢コレクタ識別子フィールドは、このPAメッセージに関連付けられた姿勢コレクタの識別子を含みます。
The Posture Broker Client is responsible for assigning one or more Posture Collector Identifier values (but not 0xffff) to each Posture Collector involved in a message exchange. Multiple Posture Collector identifiers are required for appropriate correlation in cases where there are multiple components of the same type handled by a single Posture Collector, e.g., an endpoint with two VPN client implementations handled by a single VPN Posture Collector. Please refer to section 3.3 of the PA-TNC specification for an example that illustrates the use of multiple Posture Collector Identifiers. The Posture Collector Identifier value(s) assigned to a Posture Collector by a Posture Broker Client MUST NOT change during the course of a PT session. This identifier is used to identify a unique Posture Collector communicating with the Posture Broker Client on the endpoint during a NEA exchange, and is used by the Posture Validator to send response attributes to a specific Posture Collector component if required.
姿勢ブローカクライアントは、メッセージ交換に関与する各姿勢コレクタへの1つまたは複数のポスチャコレクタ識別子値（0xFFFFではなく）を割り当てる責任があります。複数姿勢コレクタ識別子は、単一の姿勢コレクタ、例えば、単一のVPN姿勢コレクタによって処理2つのVPNクライアント実装とエンドポイントにより処理同じタイプの複数のコンポーネントが存在する場合には適切な相関のために必要とされます。複数姿勢コレクタ識別子の使用を示し、例えばPA-TNC仕様のセクション3.3を参照してください。姿勢ブローカクライアントによって姿勢コレクタに割り当てられた姿勢コレクタ識別子値（S）がPTセッションの進行中に変更してはいけません。この識別子は、NEA交換中エンドポイントの姿勢ブローカクライアントと通信ユニーク姿勢コレクタを識別するために使用され、必要に応じて応答が特定姿勢コレクタコンポーネントに属性を送信する姿勢バリデータによって使用されます。
When a Posture Broker Server sets the EXCL flag for a PA message, the Posture Broker Server MUST set the Posture Collector Identifier field to the identifier of the Posture Collector that should receive the PA message. If the EXCL flag is not set, a Posture Broker Server MAY still set the Posture Collector Identifier value for PA messages that it sends to indicate that the PA message is intended as a response to a message sent by the
姿勢ブローカサーバがPAメッセージのEXCLフラグを設定すると、姿勢ブローカサーバは、PAメッセージを受信する姿勢コレクタの識別子に姿勢コレクタ識別子フィールドを設定しなければなりません。 EXCLフラグが設定されていない場合、姿勢ブローカーサーバーはまだそれはPAメッセージがで送信されたメッセージへの応答として意図されていることを示すために、送信PAメッセージの姿勢コレクター識別子の値を設定することができ
Posture Collector associated with the specified Posture Collector Identifier. If the Posture Broker Server does not wish to indicate any Posture Collector in this manner, it SHOULD set this field to the reserved value 0xffff.
指定された姿勢コレクタ識別子に関連付けられた姿勢コレクタ。姿勢ブローカーサーバーは、このように任意の姿勢Collectorを示すために希望しない場合は、予約値の0xffffのこのフィールドを設定する必要があります。
Posture Validator Identifier (16 bits)
姿勢検証識別子（16ビット）
The Posture Validator Identifier field contains the identifier of the Posture Validator associated with this PA message.
姿勢バリデータ識別子フィールドは、このPAメッセージに関連付けられたポスチャ検証の識別子を含みます。
The Posture Broker Server MUST assign a unique Posture Validator Identifier value (but not 0xffff) to each Posture Validator involved in a message exchange and include this Posture Validator identifier in this field for any PA messages sent by that Posture Validator. The Posture Validator Identifier value assigned to a Posture Validator by a Posture Broker Server MUST NOT change during the course of a PT session. This identifier is used to identify a unique Posture Validator communicating with the Posture Broker Server endpoint during a NEA exchange, and is used by the Posture Collector to send attributes to a specific Posture Validator if required.
姿勢ブローカサーバは、メッセージ交換に関与する各ポスチャ検証に固有のポスチャ検証識別子値（0xFFFFではなく）を割り当て、その姿勢Validatorによって送信されたPAメッセージのためにこの分野において、この姿勢バリデータ識別子を含まなければなりません。姿勢ブローカーサーバーでのPosture検証に割り当てられた姿勢Validatorの識別子の値は、PTセッションの途中で変化してはいけません。この識別子は、NEA交換中に姿勢ブローカーサーバーのエンドポイントとの通信のユニークな姿勢バリデータを識別するために使用され、必要に応じて特定のPosture検証に属性を送信するためのPostureコレクタによって使用されています。
When a Posture Broker Client sets the EXCL flag for a PA message, the Posture Broker Client MUST set the Posture Validator Identifier field to the identifier of the Posture Validator that should receive the PA message. If the EXCL flag is not set, a Posture Broker Client MAY still set the Posture Validator Identifier value for PA messages that it sends to indicate that the PA message is intended as a response to a message sent by the Posture Validator associated with the specified Posture Validator Identifier. If the Posture Broker Client does not wish to indicate any Posture Validator in this manner, it SHOULD set this field to the reserved value 0xffff.
姿勢ブローカクライアントはPAメッセージのEXCLフラグを設定すると、姿勢ブローカクライアントはPAメッセージを受信する姿勢検証の識別子に姿勢バリデータ識別子フィールドを設定しなければなりません。 EXCLフラグが設定されていない場合、姿勢ブローカクライアントはまだそれはPAメッセージを指定姿勢で関連付けられたポスチャ検証によって送信されたメッセージへの応答として意図されていることを示すために送信PAメッセージの姿勢バリデータ識別子の値を設定してもよいですバリデータ識別子。姿勢ブローカークライアントは、このように任意の姿勢バリデータを示すために希望しない場合は、予約値の0xffffのこのフィールドを設定する必要があります。
PA Message Body (variable length)
PAメッセージ本文（可変長）
The PA Message Body field contains the body of the PA message that is being carried in this PB-TNC message. The length of this field can be determined by subtracting the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the fixed-length fields at the start of the PB-PA message (Flags, PA Message Vendor ID, PA Subtype, Posture Collector Identifier, and Posture Validator Identifier) from the message length contained in the PB-TNC Message Length field. The length of these fixed-length fields is 24 octets. Therefore, any Posture Broker Client or Posture Broker Server that receives a PB-PA message with a PB-TNC Message Length field whose value is less than 24 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PAメッセージ本文フィールドは、このPB-TNCメッセージで運ばれているPAメッセージの本文が含まれています。このフィールドの長さは、PB-TNCのベンダーID、PB-TNCメッセージ・タイプ、およびPB-TNCメッセージ長（PB-TNCメッセージの開始時にフィールドフラグを固定長フィールドの長さを減算することによって決定することができます）およびPB-TNCメッセージ長フィールドに含まれるメッセージ長からPB-PAメッセージの開始時の固定長フィールド（フラグ、PAメッセージベンダーID、PAサブタイプ、姿勢コレクタ識別子、及び姿勢検証識別子）。これらの固定長フィールドの長さが24オクテットです。したがって、任意の姿勢ブローカクライアント又はその値が24未満であるCLOSEバッチにおける致命的な無効なパラメータのエラーコードで応答しなければならないPB-TNCメッセージ長フィールドとPB-PAメッセージを受信したポスチャブローカサーバ。
The PB-TNC message type named PB-Assessment-Result (value 2) is used by the Posture Broker Server to provide the assessment result after the Posture Broker Server has completed the assessment of the endpoint. The Posture Broker Server will typically compute the assessment result as a cumulative of the individual assessment results received from the various Posture Validators; the algorithm for computation of assessment result at the Posture Broker layer is implementation specific and can also change based on policies in a specific deployment. The Posture Broker Server MUST include one message of this type in any batch of type RESULT and MUST NOT include a message of this type in any other type of batch. The Posture Broker Client MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client MUST implement and process this message and MUST ignore any message with this message type that is not part of a batch of type RESULT.
PB-TNCメッセージタイプという名前のPB-評価結果（値2）姿勢ブローカーサーバーは、エンドポイントの評価を完了した後に評価結果を提供するために、姿勢ブローカーサーバーによって使用されます。姿勢ブローカサーバは、典型的には、様々な姿勢バリから受信した個々の評価結果の累積のような評価結果を計算します。姿勢ブローカー層での評価結果を計算するためのアルゴリズムは、実装固有のものであり、また、特定の展開でのポリシーに基づいて変更することができます。姿勢ブローカーサーバーは、Result型のいずれかのバッチで、このタイプの一つのメッセージを含まなければならないし、バッチの他のタイプで、このタイプのメッセージを含んではいけません。姿勢ブローカークライアントは、このメッセージタイプとPB-TNCメッセージを送ってはいけません。姿勢ブローカーサーバーは、このメッセージタイプでPB-TNCメッセージを受信した場合、それはCLOSEバッチで致命的な無効なパラメータエラーで応じなければなりません。姿勢ブローカクライアントが実装し、このメッセージを処理し、タイプ結果のバッチの一部ではない、このメッセージタイプを持つすべてのメッセージを無視しなければならないしなければなりません。
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 2. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 2 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the value 16 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with the Assessment Result field described below. Any Posture Broker Client or Posture Broker Server that receives a PB-Assessment-Result message with a PB-TNC Message Length field that does not have a value of 16 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージヘッダ内NOSKIPフラグは、このメッセージタイプに設定しなければなりません。 PB-TNCベンダIDフィールドは、ゼロ（0）と非ゼロ値をPB-TNCベンダIDフィールドに含まれている場合PB-TNCメッセージタイプフィールドが2を含まなければならない、メッセージ・タイプ2が完全有する値を含まなければなりません別の意味では、この仕様で定義されていません。すなわちPB-TNCメッセージ（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージの開始時の固定長フィールドの長さの合計であるので、PB-TNCメッセージ長フィールドは、値16を含まなければなりません下記の評価結果フィールドと一緒にタイプ、およびPB-TNCのメッセージ長）。 CLOSEバッチで致命的な無効なパラメータのエラーコードで応答しなければならない16の値を持っていないPB-TNCメッセージ長フィールドでPB-評価結果メッセージを受信し、任意の姿勢ブローカークライアントや姿勢ブローカーサーバー。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのフォーマットとPB-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assessment Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assessment Result
評価結果
This 32-bit field MUST contain one of the following values
この32ビットのフィールドは以下の値のいずれかを含まなければなりません
Value Description
----- -----------
0 Posture Broker Server assessed the endpoint to be
compliant with policy.
1 Posture Broker Server assessed the endpoint to be non-compliant with policy but the difference from compliance was minor.
1姿勢ブローカーサーバーは、ポリシーと非準拠するようにエンドポイントを評価したが、コンプライアンスの差が軽微でした。
2 Posture Broker Server assessed the endpoint to be non-compliant with policy and the assessed difference from compliance was very significant.
2姿勢ブローカーサーバーは、ポリシーと非準拠するようにエンドポイントを評価し、コンプライアンスの評価の違いは非常に有意でした。
3 Posture Broker Server was unable to determine policy compliance due to an error.
3姿勢ブローカーサーバーエラーが発生したため、ポリシーコンプライアンスを決定することができませんでした。
4 Posture Broker Server was unable to determine whether the assessed endpoint is compliant with policy based on the attributes provided by endpoint.
4姿勢ブローカーサーバーを評価したエンドポイントは、エンドポイントが提供する属性に基づいてポリシーに準拠しているかどうかを確認することができませんでした。
If a Posture Broker Client receives an Assessment Result value other than the five values described above, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. Other values may be defined in future versions of PB-TNC but only if the PB-TNC version number is changed. Therefore, there is no need for an IANA registry for Assessment Result values.
姿勢ブローカクライアントは、上記の5つの値以外の評価結果値を受信した場合、それはCLOSEバッチで致命的な無効なパラメータエラーで応じなければなりません。他の値は、PB-TNCの将来のバージョンで定義されてもよいが、PB-TNCのバージョン番号が変更された場合にのみ。そのため、評価結果の値のためのIANAレジストリは必要ありません。
The PB-TNC message type named PB-Access-Recommendation (value 3) is used by the Posture Broker Server to provide an access recommendation after the Posture Broker Server has completed some assessment of the endpoint. The PB-Assessment-Result and the PB-Access-Recommendation attribute together constitute the global assessment decision for an endpoint. The PB-Access-Recommendation is not authoritative, and the network and host-based access control systems would typically use additional information to determine the network access that is granted to the endpoint. The Posture Broker Server MAY include one message of this type in any batch of type RESULT and MUST NOT include a message of this type in any other type of batch. Posture Broker Clients MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client MUST implement and process this message and MUST ignore any message with this message type that is not part of a batch of type RESULT.
PB-ACCESS勧告（値3）と命名PB-TNCメッセージタイプは、姿勢ブローカーサーバーがエンドポイントのいくつかの評価を完了した後にアクセス勧告を提供するために、姿勢ブローカーサーバーによって使用されます。 PB-評価結果及びPB-ACCESS勧告属性一緒にエンドポイントのグローバルな査定決定を構成しています。 PB-ACCESS勧告は、信頼されず、ネットワークおよびホストベースのアクセス制御システムは、典型的には、エンドポイントに許可されるネットワークアクセスを決定するために、追加の情報を使用します。姿勢ブローカーサーバーは、Result型のいずれかのバッチで、このタイプの一つのメッセージを含んでもよく、バッチの他のタイプで、このタイプのメッセージを含んではいけません。姿勢ブローカクライアントは、このメッセージタイプとPB-TNCメッセージを送ってはいけません。姿勢ブローカーサーバーは、このメッセージタイプでPB-TNCメッセージを受信した場合、それはCLOSEバッチで致命的な無効なパラメータエラーで応じなければなりません。姿勢ブローカクライアントが実装し、このメッセージを処理し、タイプ結果のバッチの一部ではない、このメッセージタイプを持つすべてのメッセージを無視しなければならないしなければなりません。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. Any Posture Broker Client or Posture Broker Server that receives a PB-Access-Recommendation message with the NOSKIP flag set MUST ignore the message and MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 3. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 3 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the value 16 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with the Access Recommendation field described below. Any Posture Broker Client or Posture Broker Server that receives a PB-Access-Recommendation message with a PB-TNC Message Length field that does not have a value of 16 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージヘッダ内NOSKIPフラグは、このメッセージタイプに設定してはいけません。 NOSKIPフラグを設定してPB-ACCESS勧告メッセージを受信する任意の姿勢ブローカクライアントや姿勢ブローカサーバは、メッセージを無視しなければならなくて、CLOSEバッチで致命的な無効なパラメータのエラーコードで応答しなければなりません。 PB-TNCベンダIDフィールドは、ゼロ（0）と非ゼロ値をPB-TNCベンダIDフィールドに含まれている場合PB-TNCメッセージタイプフィールドが3を含まなければならない、メッセージタイプ3が完全有する値を含まなければなりません別の意味では、この仕様で定義されていません。すなわちPB-TNCメッセージ（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージの開始時の固定長フィールドの長さの合計であるので、PB-TNCメッセージ長フィールドは、値16を含まなければなりません以下で説明するアクセス勧告フィールドと共に種類、およびPB-TNCメッセージ長）。 CLOSEバッチで致命的な無効なパラメータのエラーコードで応答しなければならない16の値を持っていないPB-TNCメッセージ長フィールドでPB-ACCESS勧告メッセージを受信した任意の姿勢ブローカークライアントや姿勢ブローカーサーバー。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのフォーマットとPB-TNCメッセージ値フィールドの内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Access Recommendation Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (16 bits)
予約（16ビット）
These Reserved bits MUST be set to 0 on transmission and ignored on reception.
これらの予約ビットは、送信時に0に設定され、受信時には無視されなければなりません。
Access Recommendation Code (16 bits)
アクセス勧告コード（16ビット）
The Access Recommendation Code field identifies the Access Recommendation that the Posture Broker Server has made for this Posture Broker Client at this time. This field MUST have one of these three values: 1 for Access Allowed (full access), 2 for Access Denied (no access), or 3 for Quarantined (partial access). If a Posture Broker Client receives an Access Recommendation Code value other than these three values, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Other values may be defined in future versions of PB-TNC but only if the PB-TNC version number is changed. Therefore, there is no need for an IANA registry for Access Recommendation Codes.
アクセス勧告コードフィールドは、姿勢ブローカーサーバーは、この時点で、この姿勢ブローカークライアントのために作られたアクセス勧告を識別します。隔離のためのアクセス拒否のために許可されたアクセスのための1（フルアクセス）、2（アクセスなし）、または3（部分アクセス）：このフィールドは、これらの3つの値のいずれかを持っていなければなりません。姿勢ブローカクライアントは、以下の3つの値以外のアクセス勧告コード値を受信した場合、それはCLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりません。他の値は、PB-TNCの将来のバージョンで定義されてもよいが、PB-TNCのバージョン番号が変更された場合にのみ。そのため、アクセス勧告コードのためのIANAレジストリは必要ありません。
The PB-TNC message type named PB-Remediation-Parameters (value 4) is used by the Posture Broker Server to provide global (not Posture Validator-specific) remediation parameters after the Posture Broker Server has completed some assessment of the endpoint. The Posture Broker Server MAY include one or more messages of this type in any batch of any type, but this message type is most useful in batches of type RESULT.
PB-修復・パラメータ（値4）という名前のPB-TNCメッセージタイプは、姿勢ブローカーサーバーがエンドポイントのいくつかの評価を完了した後にグローバル（ない姿勢検証固有の）修復パラメータを提供する姿勢ブローカーサーバーによって使用されます。姿勢ブローカーサーバーは、任意のタイプのいずれかのバッチで、このタイプの1つまたは複数のメッセージを含んでもよいが、このメッセージタイプは、タイプ結果のバッチで最も有用です。
The Posture Broker Client MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client may implement and process this message but is not required to do so. It may skip this message. Even if the Posture Broker Client implements this message type, it is not obligated to act on it.
姿勢ブローカークライアントは、このメッセージタイプとPB-TNCメッセージを送ってはいけません。姿勢ブローカーサーバーは、このメッセージタイプでPB-TNCメッセージを受信した場合、それはCLOSEバッチで致命的な無効なパラメータエラーで応じなければなりません。姿勢ブローカークライアントが実装し、処理し、このメッセージをしかし、そうするために必要とされていないことがあります。これは、このメッセージをスキップすることがあります。姿勢ブローカクライアントは、このメッセージタイプを実装したとしても、それに基づいて行動する義務を負いません。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 4. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 4 has a completely different meaning not defined in this specification.
PB-TNCメッセージヘッダ内NOSKIPフラグは、このメッセージタイプに設定してはいけません。 PB-TNCベンダIDフィールドは、ゼロ（0）と非ゼロ値をPB-TNCベンダIDフィールドに含まれている場合PB-TNCメッセージタイプフィールドが4を含まなければならない、メッセージタイプ4が完全有する値を含まなければなりません別の意味では、この仕様で定義されていません。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reserved, Remediation Parameters Vendor ID, and Remediation Parameters Type), and the Remediation Parameters. Since the Remediation Parameters field is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 20 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client that receives a PB-Remediation-Parameters message with a PB-TNC Message Length field that contains an invalid value (e.g., less than 20) MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージ長フィールドは、PB-TNCメッセージ（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプの開始時の固定長フィールドを含む、全体のPB-TNCメッセージの長さを含まなければなりません、およびPB-TNCメッセージ長）、（予約、修正パラメータベンダーID、及び修復パラメータタイプ）の下に列挙された固定長フィールド、及び修復パラメータ。修正パラメータフィールドが可変長であるため、PB-TNCメッセージ長フィールドの値も変化するであろう。しかし、それは常に先行する文に記載されている固定長フィールドをカバーするために、少なくとも20でなければなりません。無効な値が含まれているPB-TNCメッセージ長フィールドとPB-修復パラメータメッセージを受信する任意の姿勢ブローカクライアント（例えば、20未満）CLOSEバッチに致命的な無効なパラメータのエラーコードで応答しなければなりません。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのフォーマットとPB-TNCメッセージ値フィールドの内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remediation Parameters Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (8 bits)
予約（8ビット）
These 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、インターネット割り当て番号機関から独自のPENを受け取ることができます。各ベンダーは、その使用のために利用可能な2 ^ 32の別々の修復パラメータの種類を持つように修復パラメータベンダーIDは、修復パラメータTypeフィールドを修飾します。 IETFで標準化され、修復パラメータの種類は、常に、このフィールドの値はゼロ（0）で使用されています。
Remediation Parameters Type (32 bits)
修復パラメータタイプ（32ビット）
The Remediation Parameters Type field identifies the type of remediation parameters contained in the Remediation Parameters field. A Posture Broker Client or Posture Broker Server MUST support having multiple Remediation Parameters messages contained in a single PB-TNC batch that have the same Remediation Parameters Type and/or Remediation Parameters Vendor ID.
修復パラメータTypeフィールドは、修正パラメータフィールドに含まれる修正パラメータのタイプを識別する。姿勢ブローカークライアントや姿勢ブローカーサーバーは同じ修復パラメータの種類および/または修復パラメータのベンダーIDを持つ単一PB-TNCバッチに含まれる複数の修復パラメータメッセージを持つサポートしなければなりません。
IANA maintains a registry of PB-TNC Remediation Parameters Types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. A list of IETF Standard PB-TNC Remediation Parameters Types defined in this specification appears later in this section.
IANAは、PB-TNC修復パラメータタイプのレジストリを維持します。このレジストリのエントリはセクション6.1のガイドライン以下、仕様が必要であるとの専門家レビューによって追加されます。この仕様で定義されたIETF標準PB-TNC修復パラメータタイプのリストは、このセクションの後半で表示されます。
New vendor-specific Remediation Parameters Types (those used with a non-zero Remediation Parameters vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific Remediation Parameters Types and MUST interoperate with other parties despite any differences in the set of vendor-specific Remediation Parameters
新しいベンダー固有の修復パラメータタイプ（非ゼロの修復パラメータベンダIDで使用されるもの）は、IETFまたはIANAの関与なしで定義され、ベンダによって使用されてもよいです。しかし、姿勢ブローカークライアントおよび姿勢ブローカーサーバーは、特定のベンダー固有の修復パラメータの種類のサポートを要求してはなりませんし、ベンダー固有の修復パラメータのセットの違いにもかかわらず、他の関係者と相互運用しなければなりません
Types supported (although they MAY permit administrators to configure them to require support for specific Remediation Parameters Types).
サポートされているタイプ（彼らは、特定の修復パラメータの種類のサポートを必要とするためにそれらを設定するために、管理者が許可してもよいが）。
Note that the Remediation Parameters Type is completely separate from the PB-TNC Message Type and the PA Subtype fields. The same value (e.g., 0) may have different meanings in each of these fields.
修復パラメータタイプはPB-TNCメッセージタイプとPAサブタイプフィールドから完全に分離されていることに注意してください。同じ値（例えば、0）これらのフィールドのそれぞれに異なる意味を有していてもよいです。
Remediation Parameters (variable length)
修復パラメータ（可変長）
The Remediation Parameters field contains the actual remediation parameters carried in this PB-TNC message. The length of this field can be determined by subtracting the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the fixed-length fields at the start of the PB-Remediation-Parameters message (Reserved, Remediation Parameters Vendor ID, and Remediation Parameters Type) from the message length contained in the PB-TNC Message Length field. The length of these fixed-length fields is 20 octets. Therefore, any Posture Broker Client that receives a PB-Remediation-Parameters message with a PB-TNC Message Length field whose value is less than 20 MUST consider this a malformed message. The Posture Broker Client MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
修復パラメータフィールドは、このPB-TNCメッセージで運ばれた実際の修復パラメータが含まれています。このフィールドの長さは、PB-TNCのベンダーID、PB-TNCメッセージ・タイプ、およびPB-TNCメッセージ長（PB-TNCメッセージの開始時にフィールドフラグを固定長フィールドの長さを減算することによって決定することができます）およびPB-修復パラメータメッセージ（予約開始時の固定長フィールドは、メッセージの長さから修正パラメータベンダーID、及び修復パラメータタイプ）PB-TNCメッセージ長フィールドに含まれます。これらの固定長フィールドの長さは20オクテットです。したがって、その値が20未満であるPB-TNCメッセージ長フィールドとPB-修復パラメータメッセージを受信する任意の姿勢ブローカクライアントは、この不正な形式のメッセージを考慮しなければなりません。姿勢ブローカークライアントはCLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりません。
This subsection defines several Remediation Parameters Types that
have been standardized by the IETF.
Remediation-URI
修復-URI
This Remediation Parameters Type is employed by creating a PB-Remediation-Parameters message with a Remediation Parameters Vendor ID equal to the value zero (0) and a Remediation Parameters Type of 1. The Remediation Parameters field in the PB-Remediation-Parameters message MUST contain a URI, as described in RFC 3986 [2]. This URI contains instructions and resources for remediation. The Posture Broker Client MAY load the URI and display the resulting web page to the user. The Posture Broker Client MAY also ignore the URI or take another action with it. The Posture Broker Server and any other parties involved in configuring this remediation URI should consider the likely capabilities of the Posture Broker Client when creating the URI and the content referenced by the URI. For example, they should consider the Posture Broker Client's language preferences as expressed in the PB-Language-Preference message.
この修復パラメータタイプは、値ゼロに等しい修正パラメータベンダIDとPB-修復パラメータメッセージを作成することによって採用されている（0）およびPB-修復パラメータメッセージで1.修復パラメータフィールドの修復パラメータ入力する必要がありますRFC 3986に記載されているように、URIが含まれている[2]。このURIは、修復のための指示やリソースが含まれています。姿勢ブローカークライアントは、URIをロードし、ユーザーにその結果のWebページを表示することがあります。姿勢ブローカークライアントも、URIを無視するか、それを別の行動を取るかもしれません。姿勢ブローカーサーバーとURIとURIによって参照されるコンテンツを作成する際にURIが姿勢ブローカークライアントの可能性が高い能力を考慮する必要があり、この修復の設定に関わる他の当事者。 PB-言語プリファレンスメッセージで表現たとえば、彼らは姿勢ブローカークライアントの言語設定を検討すべきです。
Remediation-String
修復弦
This Remediation Parameters Type is employed by creating a PB-Remediation-Parameters message with a Remediation Parameters Vendor ID equal to the value zero (0) and a Remediation Parameters Type of 2. The Remediation Parameters field in the PB-Remediation-Parameters message MUST contain the structure defined below, which contains human-readable instructions for remediation.
この修復パラメータタイプは、値ゼロに等しい修正パラメータベンダIDとPB-修復パラメータメッセージを作成することによって採用されている（0）およびPB-修復パラメータメッセージ2.ザ修復パラメータフィールドの修復パラメータ入力する必要があります修復のための人間可読命令を含んで以下に定義された構造を含みます。
The Posture Broker Client MAY display the instructions to the user. The Posture Broker Client MAY also ignore the instructions or take another action with them. The Posture Broker Server and any other parties involved in configuring these instructions should consider the likely capabilities of the Posture Broker Client when creating the instructions. For example, they should consider the Posture Broker Client's language preferences as expressed in the PB-Language-Preference message.
姿勢ブローカークライアントは、ユーザに指示を表示することがあります。姿勢ブローカークライアントも、指示を無視したりして、別行動を取るかもしれません。説明書を作成する際に姿勢ブローカーサーバーと、これらの命令を設定するに関与し、他の当事者は、姿勢ブローカークライアントの可能性が高い能力を考慮すべきです。 PB-言語プリファレンスメッセージで表現たとえば、彼らは姿勢ブローカークライアントの言語設定を検討すべきです。
The following diagram illustrates the format and contents of the Remediation Parameters field when 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 (32 bits)
修正文字列の長さ（32ビット）
The Remediation String Length contains the length of the Remediation String field in octets.
修復文字列の長さはオクテット単位で修復文字列フィールドの長さが含まれています。
Remediation String (variable length)
修復列（可変長）
The Remediation String field MUST contain a UTF-8 [6] encoded string. This string contains human-readable instructions for remediation that MAY be displayed to the user by the Posture Broker Client. NUL termination MUST NOT be included. If a
修正文字列フィールドは、UTF-8 [6]エンコードされた文字列を含まなければなりません。この文字列は、姿勢ブローカクライアントによってユーザに表示することができる修復のための人間可読命令が含まれています。 NUL終端は含んではいけません。もし
Posture Broker Client receives a Reason String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch.
姿勢ブローカークライアントがNUL終端を含んでいない理由文字列を受け取り、それはCLOSEバッチで致命的な無効なパラメータエラーで応じなければなりません。
Lang Code Len (8 bits)
ラングコードレン（8ビット）
The Lang Code Len field contains the length of the Remediation String Lang Code field in octets. This value may be set to zero to indicate that the language code for the Remediation String field is not known.
ラングコードレンフィールドは、オクテットで修復文字列ラングCodeフィールドの長さが含まれています。この値は、修正文字列フィールドの言語コードが知られていないことを示すためにゼロに設定されてもよいです。
Remediation String Lang Code (variable length)
修復文字列ラングコード（可変長）
The Remediation String Lang Code field contains a US-ASCII string composed of a well-formed RFC 4646 [3] 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 field is not known.
修正文字列ラングコードフィールドは、修正パラメータフィールドに修正文字列で使用される言語（複数可）を示し、十分に形成されたRFC 4646 [3]言語タグからなるUS-ASCII文字列が含まれています。長さゼロの文字列は、修正文字列フィールドの言語コードが知られていないことを示すために（本質的には、このフィールドを省略）このフィールドに送信されてもよいです。
The PB-TNC message type named PB-Error (value 5) is used by the Posture Broker Client or Posture Broker Server to indicate that an error has occurred. The Posture Broker Client or Posture Broker Server MAY include one or more messages of this type in any batch of any type. Other messages may also be included in the same batch. The party that receives a PB-Error message MAY log it or take other action as deemed appropriate. If the FATAL flag is set (value 1), the recipient MUST terminate the PB-TNC session after processing the batch without sending any messages in response. Every Posture Broker Client and Posture Broker Server MUST implement this message type.
PB-エラー（値5）と名付けられたPB-TNCメッセージタイプは、エラーが発生したことを示すために姿勢ブローカクライアントや姿勢ブローカサーバによって使用されます。姿勢ブローカークライアントや姿勢ブローカーサーバーは、任意のタイプのいずれかのバッチで、このタイプの1つまたは複数のメッセージを含むかもしれません。他のメッセージも同じバッチに含まれていてもよいです。 PB-エラーメッセージを受け取る当事者は、それを記録したり、適切と思われるように、他のアクションをとるかもしれません。 FATALフラグ（値1）に設定されている場合、受信者は応答してすべてのメッセージを送信せずにバッチを処理した後PB-TNCセッションを終了しなければなりません。すべての姿勢ブローカークライアント・姿勢ブローカーサーバーは、このメッセージタイプを実装しなければなりません。
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 5. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 5 has a completely different meaning not defined in this specification.
PB-TNCメッセージヘッダ内NOSKIPフラグは、このメッセージタイプに設定しなければなりません。 PB-TNCベンダIDフィールドは、ゼロ（0）と非ゼロ値をPB-TNCベンダIDフィールドに含まれている場合PB-TNCメッセージタイプフィールドが5を含まなければならない、メッセージタイプ5が完全有する値を含まなければなりません別の意味では、この仕様で定義されていません。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, Error Code Vendor ID, Error Code, and Reserved), and the Error Parameters. Since the Error Parameters field is variable length, the value in the PB-TNC Message Length field will vary also.
PB-TNCメッセージ長フィールドは、PB-TNCメッセージ（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプの開始時の固定長フィールドを含む、全体のPB-TNCメッセージの長さを含まなければなりません、およびPB-TNCメッセージ長）、下記固定長フィールド（フラグ、エラーコードベンダーID、エラーコード、および予約済み）、およびエラーパラメータ。エラーパラメータフィールドは可変長であることから、PB-TNCのメッセージ長フィールドの値も変化します。
However, it MUST always be at least 20 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client or Posture Broker Server that receives a PB-Error message with a PB-TNC Message Length field that contains an invalid value (e.g., less than 20) MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Any PB-Error message generated while processing a PB-Error message MUST be a fatal error to avoid the chance of generating an infinite loop of errors.
しかし、それは常に先行する文に記載されている固定長フィールドをカバーするために、少なくとも20でなければなりません。無効な値が含まれているPB-TNCメッセージ長フィールドとPB-エラーメッセージを受信し、任意の姿勢ブローカクライアントや姿勢ブローカサーバ（例えば、20未満）CLOSEバッチに致命的な無効なパラメータのエラーコードで応答しなければなりません。 PB-エラーメッセージの処理中に生成されたPB-エラーメッセージは、エラーの無限ループが発生する可能性を避けるために、致命的なエラーでなければなりません。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのフォーマットとPB-TNCメッセージ値フィールドの内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
フラグ（8ビット）
This field defines flags relating to the error.
このフィールドは、エラーに関連するフラグを定義します。
Bit 0 of this flags field (the most significant bit) is known as the FATAL flag. If the FATAL bit is cleared (value 0), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message SHOULD process this error and then continue with the exchange. If the FATAL flag is set (value 1), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message MUST terminate the exchange after processing the error. In addition, any Posture Broker Client or Posture Broker Server that sends a fatal error MUST NOT process the batch that caused the error and MUST terminate the exchange after sending the batch containing the error report. A PB-Error message with the FATAL flag set MUST always be sent in a CLOSE batch since the sender will be terminating the exchange immediately after sending the batch.
このフラグフィールド（最上位ビット）のビット0は、FATALフラグとして知られています。 FATALビット（値0）がクリアされた場合、交換に進み、このエラーを処理するべきであり、このPB-TNCメッセージを受信する姿勢ブローカクライアントや姿勢ブローカサーバ。 FATALフラグ（値1）に設定されている場合、このPB-TNCメッセージを受信する姿勢ブローカクライアントや姿勢ブローカサーバは、エラーを処理した後に交換を終了しなければなりません。また、エラーの原因となったバッチを処理てはならない致命的なエラーを送信し、エラーレポートを含むバッチを送信した後交換を終えなければなりません任意の姿勢ブローカークライアントや姿勢ブローカーサーバー。送信者がバッチを送信した後、すぐに交換を終了されますので、FATALフラグが設定されたPB-エラーメッセージは、常にCLOSEバッチで送らなければなりません。
The FATAL bit allows a Posture Broker Client or Posture Broker Server to signal a fatal error (like an invalid batch type) and/or a non-fatal error (like an invalid language tag for a preferred language).
FATALビット姿勢ブローカクライアントや姿勢ブローカサーバ（無効なバッチ式のような）致命的なエラー、および/または（言語の無効な言語タグのような）非致命的なエラーを通知することを可能にします。
The other bits in this Flags field are reserved. For this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception.
このFlagsフィールド内の他のビットは予約されています。 PB-TNCのこのバージョンのために、彼らは、送信時に0に設定しなければならなくて、レセプションで無視します。
Error Code Vendor ID (24 bits)
エラーコードベンダーID（24ビット）
The Error Code Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The Error Code Vendor ID qualifies the Error Code field so that each vendor has 2^16 separate Error Codes available for its use. Error codes standardized by the IETF are always used with the value zero (0) in this field. For detailed descriptions of those messages, see the next few subsections.
エラーコードベンダーIDフィールドは、SMIプライベートエンタープライズ番号（PEN）を使用して、ベンダーを識別します。どのような組織は、IANA、インターネット割り当て番号機関から独自のPENを受け取ることができます。各ベンダーは、その使用のために利用可能な2 ^ 16の別々のエラーコードを持つようにエラーコードベンダーIDは、エラーコードフィールドを修飾します。 IETFで標準化エラー・コードは、常にこのフィールドの値はゼロ（0）で使用されています。これらのメッセージの詳細については、次のいくつかのサブセクションを参照してください。
Error Code (16 bits)
エラーコード（16ビット）
The Error Code field identifies the type of error being signaled with this message. The format of the Error Parameters field depends on the value of the Error Code Vendor ID and the Error Code. However, any recipient that does not understand a particular error code can process the error fairly well by using the FATAL flag to determine whether the error is fatal and the PB-TNC Message Length to skip over the Error Parameters field (or log it).
エラーコードフィールドは、このメッセージに合図しているエラーの種類を識別します。エラーパラメータフィールドのフォーマットは、エラーコードのベンダーIDとエラーコードの値に依存します。しかし、特定のエラーコードを理解していないすべての受信者は、エラーが致命的であるとPB-TNCのメッセージ長は、エラーパラメータフィールドをスキップ（またはそれをログに記録）するかどうかを判断するためにFATALフラグを使用してかなりよくエラーを処理することができます。
IANA maintains a registry of PB-TNC Error Codes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. A list of IETF Standard PB-TNC Error Codes defined in this specification appears later in section 4.9.1.
IANAは、PB-TNCエラーコードのレジストリを維持します。このレジストリのエントリはセクション6.1のガイドライン以下、仕様が必要であるとの専門家レビューによって追加されます。この仕様で定義されたIETF標準PB-TNCエラーコードのリストは、後のセクション4.9.1に表示されます。
New vendor-specific error codes (those used with a non-zero error code vendor ID) may be defined and employed by vendors without IETF or IANA involvement. Posture Broker Clients and Posture Broker Servers that receive an unknown error code MUST process this error code gracefully by ignoring or logging it if it is not marked as fatal and terminating the exchange if it is marked as fatal.
新しいベンダー固有のエラーコード（非ゼロのエラーコードベンダーIDと共に使用されるもの）、IETFまたはIANAの関与なしで定義され、ベンダによって使用されてもよいです。それは致命的なエラーとしてマークされている場合、それが致命的な交換を終了としてマークされていない場合は姿勢ブローカクライアントと不明なエラーコードを受け取る姿勢ブローカーサーバーはそれを無視するか、ログインすることで、優雅に、このエラーコードを処理しなければなりません。
Reserved (16 bits)
予約（16ビット）
The Reserved bits MUST be set to 0 on transmission and ignored on reception.
予約ビットは、送信時に0に設定され、受信時には無視されなければなりません。
The following error codes are IETF Standard PB-TNC Error Codes, hence the Error Code Vendor ID MUST be the value zero (0). The following table defines the 16-bit error code. Vendor-specific error codes may be defined by setting the Error Code Vendor ID to the defining vendor's SMI PEN and setting the Error Code field to whatever error code(s) that vendor has defined. The format, length, and meaning of the Error Parameters field varies, based on the Error Code Vendor ID and Error Code. Subsequent sections of this document define the format, length, and meaning of the Error Parameters for the IETF Standard PB-TNC Error Codes defined in this section.
以下のエラーコードは、従ってエラーコードベンダーIDは、値ゼロ（0）にする必要があり、IETF標準PB-TNCエラーコードです。次の表は、16ビットのエラーコードを定義します。ベンダー固有のエラーコードを定義するベンダーのSMI PENにエラーコードベンダーIDを設定し、ベンダーが定義したどのようなエラーコード（単数または複数）にエラーコードフィールドを設定することによって定義することができます。フォーマット、長さ、およびエラー・パラメータ・フィールドの意味は、エラーコードベンダーIDとエラーコードに基づいて、変化します。本文書の以降のセクションは、このセクションで定義されたIETF標準PB-TNCのエラーコードのエラーパラメータのフォーマット、長さ、および意味を定義します。
Error Code Definition
---------- ----------
0 Unexpected Batch Type. Error Parameters are empty.
1 Invalid Parameter. Error Parameters has offset where invalid value was found.
1無効なパラメータ。無効な値が見つかったところエラーパラメータがオフセットしています。
2 Local Error. Error Parameters are empty.
2ローカルエラー。エラーパラメータは空です。
3 Unsupported Mandatory Message. Error Parameters has offset of offending PB-TNC Message
3サポートされていない必須のメッセージ。エラーパラメータは、PB-TNCメッセージを怒らオフセットしています
4 Version Not Supported. Error Parameters has information about which versions are supported.
4バージョンではサポートされていません。エラーパラメータは、バージョンがサポートされているかについての情報を持っています。
This section defines the format, length, and meaning of the Error Parameters field for the IETF Standard PB-TNC Error Codes defined in this specification.
このセクションでは、本明細書で定義されているIETF標準PB-TNCのエラーコードのエラーパラメータフィールドのフォーマット、長さ、および意味を定義します。
The Error Parameters field is zero length for the IETF Standard PB-TNC Error Code 0. The FATAL flag MUST be set for this error code.
エラーパラメータフィールドは、FATALフラグは、このエラーコードを設定する必要がありIETF標準PB-TNCのエラーコード0の長さがゼロです。
The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 1. The Offset field is the offset in octets from the start of the PB-TNC batch to the invalid value. The FATAL flag may be either set or cleared for this error code.
エラーパラメータフィールドが無効な値にPB-TNCバッチの開始からのオクテットにオフセットされたIETF標準PB-TNCのエラーコード1.オフセットフィールドに次のような構造を持っています。 FATALフラグをセットするか、このエラーコードをクリアすることができるいずれか。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Parameters field is zero length for the IETF Standard PB-TNC Error Code 2. The FATAL flag MUST be set for this error code.
エラーパラメータフィールドは、FATALフラグは、このエラーコードを設定する必要がありIETF標準PB-TNCのエラーコード2の長さゼロです。
The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 3. The Offset field is the offset in octets from the start of the PB-TNC batch to the PB-TNC message whose message type was not recognized (and where the NOSKIP flag was set). The FATAL flag MUST be set for this error code.
エラーパラメータフィールドはOffsetフィールドがメッセージタイプ認識されませんでしたPB-TNCメッセージにPB-TNCバッチの開始からのオクテットにオフセットされたIETF標準PB-TNCのエラーコード3.以下の構造を有する（とNOSKIPフラグが設定された場合）。 FATALフラグは、このエラーコードを設定しなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 4. The FATAL flag MUST be set for this error code.
エラーパラメータフィールドはIETF標準PB-TNCのエラーコード4については、以下の構造を有するFATALフラグは、このエラーコードを設定する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bad Version | Max Version | Min Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bad Version field is the version number that was received and is not supported. The Max Version and Min Version fields indicate which PB-TNC version numbers are supported by the sender of the error code. The sender MUST support all PB-TNC versions between the Min Version and the Max Version, inclusive (i.e., including the Min Version and the Max Version) but excluding the reserved versions listed in section 4.1. The Reserved field MUST be set to 0 on transmission and ignored upon reception. When possible, recipients of this error code SHOULD send future messages to the Posture Broker Server or Posture Broker Client that originated this error message with a PB-TNC version number within the stated range.
バート・バージョンフィールドは、受信され、サポートされていないバージョン番号です。マックス・バージョンとMinバージョンのフィールドは、PB-TNCのバージョン番号は、エラーコードの送信者によってサポートされているかを示しています。送信者が最小バージョンと最大バージョンとの間の全てのPB-TNCのバージョンをサポートしなければならない（すなわち、最小バージョンおよび最大バージョンを含む）が、セクション4.1に記載されている予約済みバージョンを除く包括。予約フィールドは、送信時に0に設定されて、レセプションで無視しなければなりません。可能な場合、このエラーコードの受信者が記載された範囲内でPB-TNCのバージョン番号と、このエラーメッセージを発信した姿勢ブローカーサーバーや姿勢ブローカクライアントへの将来のメッセージを送信すべきです。
Any party that is sending the Version Not Supported error code MUST include that error code as the only PB-TNC message in a PB-TNC CLOSE batch with version number 2. All parties that send PB-TNC batches SHOULD be able to properly process a batch that meets this description, even if they cannot process any other aspect of PB-TNC version 2. This ensures that a PB-TNC version exchange can proceed properly, no matter what versions of PB-TNC the parties implement.
バージョンサポートされていないエラーコードを送信している当事者は、PB-TNCバッチが適切に処理することができるべきで送るバージョン番号2.すべての当事者とPB-TNC CLOSEバッチ内の唯一のPB-TNCメッセージとしてそのエラーコードを含まなければなりません彼らはこれがPB-TNC版交換は関係なく、当事者が実装PB-TNCのどのバージョンが、適切に進めることはできないことを保証PB-TNCバージョン2の他の側面を処理できない場合でも、この説明を満たしているバッチ。
The PB-TNC message type named PB-Language-Parameters (value 6) is used by the Posture Broker Client to indicate which language or languages it would prefer for any human-readable strings that might be sent to it. This allows the Posture Broker Server and Posture Validators to adapt any messages they may send to the Posture Broker Client's preferences (probably determined by the language preferences of the endpoint's users).
（値6）PB-言語 - パラメータの名前PB-TNCメッセージタイプは、それに送信される可能性があります任意の判読可能な文字列を希望する言語や言語を示すためのPosture Brokerのクライアントによって使用されます。これは、姿勢ブローカーサーバーと姿勢バリデータは、彼らが姿勢ブローカークライアントの好みに送ることができすべてのメッセージ（おそらく、エンドポイントのユーザーの言語設定によって決定）を適応することができます。
The Posture Broker Server may also send this message type to the Posture Broker Client to indicate the Posture Broker Server's language preferences, but this is not very useful since the Posture Broker Client rarely sends human-readable strings to the Posture Broker Server and, if it does, rarely can adapt those strings to the preferences of the Posture Broker Server.
それがあれば、姿勢ブローカーサーバーも姿勢ブローカーサーバーの言語設定を示すためのPosture Brokerのクライアントには、このメッセージタイプを送ることができますが、これは姿勢ブローカクライアントはめったに姿勢ブローカーサーバーに判読可能な文字列を送信しないので、非常に便利なものではなく、 、めったに姿勢ブローカーサーバーの好みにこれらの文字列を適応させることはできませんありません。
No Posture Broker Client or Posture Broker Server is required to send or implement this message type. However, a Posture Broker Server SHOULD attempt to adapt to user language preferences by implementing this message type, passing the language preference information to Posture Validators, and allowing administrators to configure human-readable languages in whatever languages are preferred by their users.
いいえ姿勢ブローカークライアントや姿勢ブローカーサーバーが送信または、このメッセージタイプを実装するために必要とされません。しかし、姿勢ブローカーサーバーは、このメッセージタイプを実装する姿勢バリデータに言語設定情報を渡して、管理者は言語がそのユーザーによって好まれるものは何でもして、人間が読める言語を設定できるようにすることで、ユーザーの言語設定に適応しようとすべきです。
A Posture Broker Client or Posture Broker Server may include a message of this type in any batch of any type. However, it is suggested that this message be included in the first batch sent by the Posture Broker Client or Posture Broker Server in a PB-TNC session so that the recipient can start adapting its human-readable messages as soon as possible. If one PB-Language-Parameters message is received and then another one is received in a later batch for the same PB-TNC session, the value included in the later message should be considered to replace the value in the earlier message.
姿勢ブローカクライアントや姿勢ブローカサーバは、任意のタイプの任意のバッチで、このタイプのメッセージを含んでもよいです。しかし、受信者が、できるだけ早くその人間が読めるメッセージを適応始めることができるように、このメッセージはPB-TNCセッションで姿勢ブローカークライアントや姿勢ブローカーサーバーによって送信された第1のバッチに含まれることが示唆されています。 1 PB-言語パラメータメッセージを受信した後、別の1が同じPB-TNCのセッションの後のバッチで受信された場合、以降のメッセージに含まれる値は、以前のメッセージの値を置き換えるために考慮されるべきです。
A Posture Broker Client or Posture Broker Server MUST NOT include more than one message of this type in a single batch. If a Posture Broker Client or Posture Broker Server receives more than one message of this type in a single batch, it should ignore all but the last one.
姿勢ブローカークライアントや姿勢ブローカーサーバーは、単一のバッチで、このタイプの複数のメッセージを含んではいけません。姿勢ブローカークライアントや姿勢ブローカーサーバーが単一のバッチで、このタイプの複数のメッセージを受信した場合、それは最後の1以外のすべてを無視すべきです。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 6. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 6 has a completely different meaning not defined in this specification.
PB-TNCメッセージヘッダ内NOSKIPフラグは、このメッセージタイプに設定してはいけません。 PB-TNCベンダIDフィールドは、ゼロ（0）と非ゼロ値をPB-TNCベンダIDフィールドに含まれている場合PB-TNCメッセージタイプフィールドは、6を含まなければならない、メッセージタイプ6が完全有する値を含まなければなりません別の意味では、この仕様で定義されていません。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the Language Preference field. Since the Language Preference field is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 12 to cover the fixed-length fields listed in the preceding sentences.
PB-TNCメッセージ長フィールドは、PB-TNCメッセージ（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプの開始時の固定長フィールドを含む、全体のPB-TNCメッセージの長さを含まなければなりません、およびPB-TNCメッセージ長）と言語の優先順位フィールド。言語の優先順位フィールドは可変長であるため、PB-TNCメッセージ長フィールドの値も変化するであろう。しかし、それは常に先行する文に記載されている固定長フィールドをカバーするために、少なくとも12でなければなりません。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのフォーマットとPB-TNCメッセージ値フィールドの内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Preference (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Language Preference (variable length)
言語設定（可変長）
The Language Preference field contains an Accept-Language header, as described in RFC 3282 [4] (using the RFC 2234 ABNF definition of Accept-Language included in that RFC, US-ASCII only, no control characters allowed, no comments, no NUL termination). Any Posture Broker Client or Posture Broker Server that sends a PB-Language-Preference message MUST ensure that the Language Preference field conforms to this format. For example, one acceptable value would be "Accept-Language: fr, en" (without the quote marks).
RFC 3282に記載されるように言語の優先順位フィールドは、受け入れ-Languageヘッダが含まれている[4]（受け入れ言語のRFC 2234 ABNFの定義を使用して、そのRFCに含まれる、US-ASCIIのみ、許可されない制御文字、ノーコメント、無NUL終了）。 PB-言語プリファレンスメッセージを送信し、任意の姿勢ブローカークライアントや姿勢ブローカーサーバーは、言語の優先順位フィールドは、このフォーマットに準拠していることを保証しなければなりません。 （引用符なし）：「FR、ENのAccept-Language」フィールドたとえば、1許容値は次のようになります。
A zero-length Language Preference field indicates that no language preference information is available. Generally, there's no need to send a PB-Language-Preference message with a zero-length Language Preference field since this is equivalent to sending no PB-Language-Preference message at all, but it may be useful to send a zero-length Language Preference field if a PB-Language-Preference message with a non-zero-length Language Preference field was sent in an earlier batch but these preferences no longer apply.
長さがゼロの言語の優先順位フィールドには、言語プリファレンス情報が利用できないことを示しています。これは全くPB-言語プリファレンスメッセージを送信しないと同じですが、長さゼロの言語を送信することが有用であることから、一般的に、長さゼロの言語の優先順位フィールドとPB-言語プリファレンスメッセージを送信する必要はありません非ゼロ長言語の優先順位フィールドとPB-言語プリファレンスメッセージは、以前のバッチで送信されたが、これらの設定がもはや適用されない場合、優先フィールド。
The PB-TNC message type named PB-Reason-String (value 7) is used by the Posture Broker Server to provide a human-readable explanation for the global assessment decision conveyed in the PB-Assessment-Result & PB-Access-Recommendation messages. Therefore, a PB-Reason-String message SHOULD only be included in the same batch as the PB-Assessment-Result and PB-Access-Recommendation message. The Posture Broker Client MUST NOT ever send a PB-Reason-String message.
PB-理由弦という名前のPB-TNCのメッセージタイプは（値は7）PB-評価結果＆PB-ACCESS勧告メッセージで伝えグローバル査定決定のための人間可読な説明を提供するために、姿勢ブローカーサーバーで使用されています。したがって、PB-理由ストリングメッセージは、PB-評価結果及びPB-ACCESS勧告メッセージと同一バッチに含まれるべきです。姿勢ブローカークライアントは、これまでPB-理由 - 文字列メッセージを送ってはいけません。
The Posture Broker Client is not required to implement this message type and the Posture Broker Server is not required to send it. However, there is some benefit to doing so since users are often curious about why the endpoint was considered non-compliant. The manner in which a Posture Broker Client uses this field is up to the implementer and not specified here. The Posture Broker Client MAY display the message to the user, log it, ignore it, or take any other action that is not inconsistent with the requirements of this specification. Since the strings contained in this message are human-readable, the Posture Broker Server SHOULD adapt them to the Posture Broker Client's language preferences as expressed in any PB-Language-Preference message sent by the Posture Broker Client in this PB-TNC session.
姿勢ブローカーClientは、このメッセージタイプを実装するために必要とされていないと姿勢ブローカーサーバーは、それを送信するために必要とされていません。ただし、ユーザーがエンドポイントが非準拠と見なされた理由について、多くの場合、興味があるので、そうすることにはいくつかの利点があります。姿勢ブローカクライアントがこのフィールドを使用する方法は、実装者に任され、ここで指定されていません。姿勢ブローカークライアントは、ユーザーにメッセージを表示し、それをログに記録し、それを無視するか、この仕様の要件と矛盾しない他のアクションをとることができます。このメッセージに含まれる文字列は、人間が読めるので、姿勢ブローカーサーバーは、このPB-TNCセッションで姿勢ブローカークライアントから送信されたすべてのPB-言語プリファレンスメッセージで表現されるよう姿勢ブローカークライアントの言語設定にそれらを適応させるべきです。
A Posture Broker Server MAY include more than one message of this type in any batch of any type. However, it is suggested that this message be included in the same batch as the PB-Assessment-Result and PB-Access-Recommendation message. If more than one PB-Reason-String message is included in a single batch, the Posture Broker Client SHOULD consider the strings included in these messages to be equivalent in meaning. This allows the Posture Broker Server to return multiple equivalent reason strings in different languages, which may help if the Posture Broker Server is not able to accommodate the Posture Broker Client's language preferences.
姿勢ブローカーサーバーは、任意のタイプのいずれかのバッチで、このタイプの複数のメッセージを含んでいてもよいです。しかし、このメッセージがPB-評価結果及びPB-ACCESS勧告メッセージと同じバッチに含まれることが示唆されています。複数のPB-理由 - 文字列メッセージは単一のバッチに含まれている場合は、姿勢ブローカークライアントはこれらのメッセージに含まれる文字列が意味で同等であることを考慮すべきです。これは、姿勢ブローカーサーバーは、姿勢ブローカーサーバーは、姿勢ブローカークライアントの言語設定に対応できない場合に役立つ可能性がある、異なる言語で複数の同等の理由の文字列を返すことができます。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 7. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 7 has a completely different meaning not defined in this specification.
PB-TNCメッセージヘッダ内NOSKIPフラグは、このメッセージタイプに設定してはいけません。 PB-TNCベンダIDフィールドは、ゼロ（0）と非ゼロ値をPB-TNCベンダIDフィールドに含まれている場合PB-TNCメッセージタイプフィールドは7を含まなければならない、メッセージタイプ7が完全有する値を含まなければなりません別の意味では、この仕様で定義されていません。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reason String Length and Lang Code Len), and the Reason String and Reason String Language Code fields. Since the Reason String and Reason String Language Code fields are variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 17 to cover the fixed-length fields listed in the preceding sentences. In fact, the PB-TNC Message Length field MUST be exactly the sum of 17 (for the fixed-length fields) and the values of the Reason String Length and Lang Code Len fields. If this is not the case, the recipient MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージ長フィールドは、PB-TNCメッセージ（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプの開始時の固定長フィールドを含む、全体のPB-TNCメッセージの長さを含まなければなりません、およびPB-TNCメッセージ長）、下記固定長フィールド（理由文字列の長さとラングコードレン）、および理由文字列と理由String言語コードフィールド。理由文字列と理由String言語コードフィールドは可変長であるため、PB-TNCメッセージ長フィールドの値も変化するであろう。しかし、それは常に先行する文に記載されている固定長フィールドをカバーするために、少なくとも17でなければなりません。実際には、PB-TNCメッセージ長フィールドは、正確に（固定長フィールド用）17の和と理由文字列の長さとラングコードレンフィールドの値がなければなりません。そうでない場合、受信者はCLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりません。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのフォーマットとPB-TNCメッセージ値フィールドの内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Reason String Language Code (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason String Length (32 bits)
理由文字列の長さ（32ビット）
The Reason String Length field contains the length of the Reason String field in octets.
理由文字列の長さフィールドは、オクテットで理由文字列フィールドの長さが含まれています。
Reason String (variable length)
理由列（可変長）
The Reason String field contains a UTF-8 encoded string that provides a human-readable reason for the Posture Broker Server's assessment decision. NUL termination MUST NOT be included. If a Posture Broker Client receives a Reason String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. A zero-length string MUST NOT be sent since this is the same as sending no reason string at all, leaving the reason unspecified.
理由文字列フィールドには、姿勢ブローカーサーバーの査定の裁判のために、人間が読み取り可能な理由を提供してUTF-8でエンコードされた文字列が含まれています。 NUL終端は含んではいけません。姿勢ブローカークライアントがNUL終端を含んでいない理由文字列を受信した場合、それはCLOSEバッチで致命的な無効なパラメータのエラーコードで応じなければなりません。これはまったく理由文字列を送信していないと同じであるので、長さゼロの文字列が指定されていない理由を残して、送ってはいけません。
Lang Code Len (8 bits)
ラングコードレン（8ビット）
The Lang Code Len field contains the length of the Reason String Language Code field in octets.
ラングコードレンフィールドは、オクテットで理由String言語コードフィールドの長さが含まれています。
Reason String Language Code (variable length)
理由String言語コード（可変長）
The Reason String Language Code field contains a US-ASCII string containing a well-formed RFC 4646 [3] language tag that indicates the language(s) used in the Reason String in this message. NUL termination MUST NOT be included in this field. A zero-length string MAY be sent for this field (essentially omitting this field) to indicate that the language code for the reason string is not known.
理由String言語コードフィールドは、整形RFCこのメッセージに理由文字列で使用される言語（複数可）を表す4646 [3]の言語タグを含むUS-ASCII文字列が含まれています。 NUL終端は、このフィールドに含まれてはなりません。長さゼロの文字列は、理由文字列の言語コードが知られていないことを示すために（本質的には、このフィールドを省略）このフィールドのために送られるかもしれません。
PT is required and assumed to provide reliable and secure transport for the PB-TNC protocol (including authentication, confidentiality, integrity protection, and replay protection). Still, it is useful to describe the possible threats to PB-TNC and the countermeasures that are or can be employed. This section does that.
PTは必要と（認証、機密性、完全性保護、および再生保護を含む）PB-TNCプロトコルの信頼性と安全性の高いトランスポートを提供すると想定されます。それでも、PB-TNCとされているかを採用することができる対策への脅威の可能性を説明することが有用です。このセクションでは、それを行います。
There are several possible threats to the PB-TNC protocol.
PB-TNCプロトコルにはいくつかの脅威の可能性があります。
Untrusted intermediaries on the network between the NEA Client and the NEA Server may attempt to observe data sent between the Posture Broker Client and the Posture Broker Server via PB-TNC, modify this data in transit, reorder it, or replay it. They may also attempt to mount a denial-of-service attack against either party or truncate the exchange prematurely. If successful, these attacks may result in improper assessment decisions relating to the NEA Client, failure to reassess these decisions in light of changed circumstances, improper remediation instructions sent to the NEA Client (which could lead to the compromise of the NEA Client), unauthorized access to confidential information about the NEA Client's health and/or identity, improper reason strings or other messages that might be displayed to the user, access to reusable credentials such as posture assertions, denial of service on the NEA Client, and even complete denial of access to the network (if a denial-of-service attack against the NEA Server was successful and the network required permission from the NEA Server to grant network access).
NEA ClientとNEA Serverの間のネットワーク上の信頼できない仲介業者は、PB-TNC経由姿勢ブローカークライアント・姿勢ブローカーサーバー間で送信されるデータを観察しようとトランジットでこのデータを変更し、それを並べ替える、またはそれを再生します。彼らはまた、いずれの当事者に対するサービス拒否攻撃をマウントしようとか、途中で交換を切り捨てることがあります。成功した場合、これらの攻撃は、（NEAクライアントの妥協につながる可能性）NEAクライアントに送信された変更の状況、不適切な改善命令の光の中でこれらの決定を再評価するために失敗し、不正NEAクライアントに関する不適切な評価の決定をもたらすことができますNEAクライアントの健康および/または同一性についての機密情報、ユーザーに表示されることがあります、不適切な理由の文字列や他のメッセージは、そのような姿勢の表明、NEAクライアント上のサービス拒否、とさえ完全否定として再利用可能な資格情報へのアクセスへのアクセスネットワークへのアクセス（NEA Serverに対してサービス拒否攻撃が成功したとのネットワークは、ネットワークへのアクセスを許可するためにNEA Serverからの許可が必要な場合）。
Trusted intermediaries between the Posture Broker Client and the Posture Broker Server include the Posture Transport Client and the Posture Transport Server. These parties are considered trusted because they are responsible for properly implementing the security protections provided by PT. If they fail to do so properly, these security protections may be diminished or eliminated altogether. The possible attacks are the same as those listed in the previous paragraph. To give one fairly likely example, if a Posture Transport Client fails to properly authenticate and authorize the Posture Transport Server (whether through implementation error or through user configuration to "trust anyone"), the improperly authorized Posture Transport Server may mount any of the previously described attacks against the NEA Client.
姿勢ブローカークライアント・姿勢ブローカーサーバー間の信頼できる仲介者は、姿勢交通クライアントおよび姿勢トランスポートサーバーが含まれます。彼らは適切にPTが提供するセキュリティ保護を実装するための責任があるので、これらの当事者は、信頼できると考えられています。彼らは適切にこれを行うに失敗した場合、これらのセキュリティ保護が減少または完全に排除することができます。攻撃の可能性は、前の段落で示したものと同じです。姿勢交通クライアントが正しく認証して（かどうか、「誰を信頼」を実装エラーを介して、またはユーザ設定による）姿勢トランスポートサーバーを承認しなかった場合、1つのかなりありそうな例を与えるために、不適切な許可姿勢トランスポートサーバーは、以前のいずれかを搭載可能NEAクライアントに対する攻撃を説明しました。
Compromise of any of the trusted parties (the Posture Broker Client, the Posture Transport Client, the Posture Broker Server, or the Posture Transport Server) may result in failures that are equivalent to those listed in the first paragraph. These failures may be even more dangerous since they will not be detectable by observing network traffic or by examining and comparing audit logs. Failure to properly secure communications between the Posture Broker Client and the Posture Transport Client or between the Posture Broker Server and the Posture Transport Server is usually indistinguishable from compromise of those parties. Compromise of the operating system or other critical software, firmware, or hardware components on the NEA Client or NEA Server will typically result in an equivalent result. And an attacker's ability to gain privileged access to the NEA Client or NEA Server (even for a brief time, long enough to disable or misconfigure security settings) is generally equivalent as well. If the NEA Client or NEA Server are dependent on other services for their proper operation (including Posture Collectors, Posture Validators, directories, and patch management services), compromise of those services may result in compromise or failure of the dependent parties. Of course, compromise or failure of NEA Server components is most serious since this would probably affect a large number of NEA Clients while the effects of NEA Client compromise might well be limited to a single machine.
信頼できる関係者（姿勢ブローカークライアント、姿勢交通クライアント、姿勢ブローカーサーバー、または姿勢トランスポートサーバー）のいずれかの妥協は、最初の段落に記載されたものと同等で障害が発生することがあります。彼らは、ネットワークトラフィックを観察することによって、または監査ログを調べると比較することで、検出されませんので、これらの障害は、さらに危険かもしれません。姿勢ブローカークライアントと姿勢交通クライアント間や姿勢ブローカーサーバー・姿勢トランスポートサーバー間の障害に適切に安全な通信は、通常は、これらの当事者の妥協と区別がつきません。 NEA ClientまたはNEAサーバー上のオペレーティングシステムやその他の重要なソフトウェア、ファームウェア、またはハードウェアコンポーネントの妥協点は、一般的に同等の結果になります。そして、NEA ClientまたはNEAサーバー（でも、短い時間のために、十分な長無効にするか、設定ミスのセキュリティ設定）への特権アクセスを取得するために攻撃者の能力だけでなく、一般的に等価です。 NEAクライアントまたはNEA Serverは、（姿勢コレクター、姿勢バリデータ、ディレクトリ、およびパッチ管理サービスを含む）が正常に動作するため、他のサービスに依存している場合は、それらのサービスの妥協は依存関係者の妥協や故障の原因となることがあります。もちろん、NEA Serverコンポーネントの妥協や失敗はNEA Clientの妥協の効果が十分に単一のマシンに限定される可能性がありますしながら、これはおそらく、NEAの多数のクライアントに影響を与えるので、最も深刻です。
The primary countermeasure against attacks by untrusted network intermediaries is the security provided by the PT protocol. Any candidate PT protocols should be carefully examined to ensure that all the threats described above are adequately addressed.
信頼できないネットワーク仲介による攻撃に対する一次対策は、PTプロトコルによって提供されるセキュリティです。いずれの候補PTプロトコルは慎重に、上記のすべての脅威が適切に対処されることを保証するために検討されなければなりません。
As noted above, compromise or erroneous operation of any of the trusted parties is a serious matter with substantial security implications. This includes the Posture Broker Client, the Posture Broker Server, the Posture Transport Client, and the Posture Transport Server. These are all security-sensitive components so they should be built and managed in accordance with best practices for security devices. This is especially important for the NEA Server and its components since a compromise of this device would affect the security and availability of the entire network (similar to compromise of a AAA server). Communications between the trusted parties must also be secured. For example, if the Posture Broker Server and the Posture Transport Server are separate components, their communications must be secured.
上述したように、信頼できる当事者のいずれかの妥協や誤作動がかなりのセキュリティへの影響の深刻な問題です。これは、姿勢ブローカークライアント、姿勢ブローカーサーバー、姿勢交通クライアント、および姿勢トランスポートサーバーが含まれています。彼らはセキュリティデバイスのためのベスト・プラクティスに基づいて構築され、管理されなければならないので、これらは、すべてのセキュリティに敏感なコンポーネントです。このデバイスの妥協は（AAAサーバの妥協に類似）、ネットワーク全体のセキュリティと可用性に影響を与えるので、これはNEA Serverとそのコンポーネントのために特に重要です。信頼された当事者間の通信も確保しなければなりません。姿勢ブローカーサーバーと姿勢トランスポートサーバーは、別々のコンポーネントである場合、例えば、その通信が確保されなければなりません。
Since the NEA Client may be a mobile device with little physical security (such as a laptop computer or even a public telephone), it should generally be assumed that some proportion of Access NEA Clients will be compromised and therefore hostile. The NEA Server should be designed to be robust against hostile NEA Clients. Once a compromised NEA Client is detected, it can be treated in a manner equivalent to an untrusted party and should pose no greater threat than any other untrusted party.
NEAクライアント（例えば、ラップトップコンピュータ、あるいは公衆電話など）はほとんどの物理的セキュリティとモバイルデバイスとすることができるので、一般に、アクセスNEAクライアントの一部割合が損なわしたがって敵対することを想定しなければなりません。 NEA Serverは、敵対的なNEAクライアントに対して堅牢になるように設計されなければなりません。妥協NEA Clientが検出されると、それは信頼できない相手に同等の方法で処理することができ、他の信頼できないの当事者よりも大きな脅威を与えてはなりません。
Countermeasures against a compromised NEA Server (or a component thereof such as a Posture Broker Server or a Posture Transport Server) include prevention of compromise, detection of compromise, and mitigation of the effects of compromise. For prevention, the NEA Server and its components and dependencies should be implemented using secure implementation techniques (e.g., secure coding and minimization) and managed using secure practices (e.g., strong authentication and separation of duty). For detection, the behavior of the NEA Server should be monitored (e.g., via logging especially of remediation instructions, intrusion detection systems, and probes that impersonate a valid NEA Client and record NEA Server behavior) and any anomalies analyzed. For mitigation, NEA Clients should not blindly follow remediation instructions received from a trusted NEA Server. At least for patches and other dangerous actions, they should validate these actions (e.g., via user confirmation) before proceeding. It should not be possible to configure a NEA Client to trust all NEA Servers without proper authentication and authorization.
損なわNEAサーバ（または姿勢ブローカサーバや姿勢トランスポートサーバーのようなその成分）対策は、妥協の効果の妥協の予防、妥協の検出、及び緩和を含みます。予防のために、NEA Serverとそのコンポーネントとの依存関係は、安全な実装技術（例えば、セキュアな符号化および最小化）を使用して実装され、安全な慣行（例えば、強力な認証および職務の分離）を使用して管理されなければなりません。検出のために、NEA Serverの動作は、（特に改善命令、侵入検知システム、および有効なNEAクライアントを偽装し、NEA Serverの動作を記録したプローブのログを経て、例えば）監視する必要がありますし、任意の異常を分析します。緩和のために、NEAクライアントは盲目的に信頼さNEAサーバから受信した修復指示に従うべきではありません。少なくとも、パッチやその他の危険な行動のために、彼らは先に進む前に、これらのアクション（例えば、ユーザの確認を経由して）を検証する必要があります。適切な認証および承認なしに、すべてのNEAのサーバーを信頼するようにNEA Clientを設定することはできないはずです。
Four new IANA registries are defined by this specification: PB-TNC Message Types, PA Subtypes, PB-TNC Remediation Parameters Types, and PB-TNC Error Codes. This section explains how these registries work.
四つの新しいIANAレジストリは、この仕様で定義されています：PB-TNCメッセージの種類、PAサブタイプ、PB-TNC修復パラメータの種類、およびPB-TNCエラーコード。このセクションでは、これらのレジストリがどのように動作するかを説明します。
All of these registries support IETF standard values and vendor-defined values. To explain this phenomenon, we will use the PB-TNC Message Type as an example but the other three registries work the same way. Whenever a PB-TNC Message Type appears on a network, it is always accompanied by an SMI Private Enterprise Number (PEN), also known as a vendor ID. If this vendor ID is zero, the accompanying PB-TNC Message Type is an IETF standard value listed in the IANA registry for PB-TNC Message Types and its meaning is defined in the specification listed for that PB-TNC Message Type in that registry. If the vendor ID is not zero, the meaning of the PB-TNC Message Type 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 PB-TNC Message Types used with their vendor ID and publish a specification for each of these values.
これらのレジストリのすべては、IETF標準値とベンダー定義の値をサポートしています。この現象を説明するために、我々は、一例として、PB-TNCメッセージタイプを使用しますが、他の3つのレジストリが同じように動作します。 PB-TNCのメッセージタイプは、ネットワーク上に現れるたびに、それは常に、SMIプライベートエンタープライズ番号（PEN）を伴っても、ベンダーIDとして知られています。このベンダーIDがゼロの場合は、付属のPB-TNCメッセージタイプは、PB-TNCメッセージタイプのためのIANAレジストリに記載されているIETF標準値であり、その意味は、そのレジストリにそのPB-TNCメッセージタイプのためにリストされている仕様で定義されています。ベンダIDがゼロでない場合は、PB-TNCメッセージ・タイプの意味はベンダーIDによって識別されるベンダー（SMIのPENのためのIANAレジストリにリストされている）によって定義されます。識別ベンダーが奨励が、IANAで自分のベンダーIDと一緒に使用PB-TNCのメッセージタイプの一部またはすべてを登録し、これらの値のそれぞれの仕様を公開する必要はありません。
This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require support for particular vendor-specific values. However, such behavior is explicitly prohibited by this specification, which dictates that "Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PB-TNC message types and MUST interoperate with other parties despite any differences in the set of vendor-specific PB-TNC message types supported (although they MAY permit administrators to configure them to require support for specific PB-TNC message types)." Similar requirements are included for PA Subtypes, Remediation Parameters Types, and PB-TNC Error Codes.
名前空間のこの代表団は、OIDのために使用される技術と類似しています。ベンダーが特定のベンダ固有の値のサポートが必要な場合には、相互運用性の問題が発生することができます。しかし、そのような行動を明示的に「姿勢ブローカクライアントと姿勢ブローカーサーバーは、特定のベンダー固有のPB-TNCメッセージタイプのサポートを要求してはなりませんし、ベンダーのセットの違いにもかかわらず、他の関係者と相互運用しなければならないことを規定し、この仕様で禁止されています（彼らは、特定のPB-TNCメッセージタイプのためのサポートを必要とするためにそれらを設定するために、管理者が許可するかもしれないが）特異PB-TNCのメッセージタイプがサポートされています。」同様の要件は、PAサブタイプ、修復パラメータの種類、およびPB-TNCエラーコードのために含まれています。
For all of the four 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 [5].
この仕様で定義された4つのIANAレジストリのすべてのために、新しい値は、RFC 5226で定義された指定エキスパートプロセスを使用して、仕様が必要であるとの専門家のレビューによってレジストリに追加されている[5]。
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. The only exception is the registry for PB-TNC Error Codes where 2^16 values are available for the IETF and 2^16 values for each vendor. Because there are so many values available, designated experts should not be terribly concerned about exhausting the set of values.
この文書で定義されたレジストリの値をたくさん持っています。それは定義し、各その使用のために同じ数の値をベンダため、ほとんどの場合、IETFは、利用可能な約2 ^ 32個の値を有しています。唯一の例外は、2 ^ 16の値は、IETFおよびベンダーごとに2 ^ 16の値のために用意されていPB-TNCエラーコードのレジストリです。利用できるので、多くの値が存在するため、指定された専門家は、値のセットを排出する程度ひどく心配すべきではありません。
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を承認しなければなりません。
The name for this registry is "PB-TNC Message 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-2, and a reference to a specification where the contents of this message type are defined. This specification must define the meaning of this PB-TNC message type and the format and semantics of the PB-TNC Message Value field for PB-TNC messages that include the designated numeric value in the PB-TNC Message Type field and the designated Private Enterprise Number in the PB-TNC Vendor ID field.
このレジストリの名前は、「PB-TNCメッセージタイプ」です。このレジストリ内の各エントリは、SMI民間企業数、0から2 ^ 32-2の間の10進数の整数値、及びこのメッセージタイプの内容が定義されている仕様への参照を人間可読な名前を含むべきです。この仕様は、このPB-TNCメッセージタイプとPB-TNCメッセージの種類]フィールドで指定された数値と指定された民間企業を含めPB-TNCメッセージのPB-TNCメッセージValueフィールドの形式と意味論の意味を定義する必要がありますPB-TNCベンダーIDフィールドの数。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリのエントリは、6.1節のガイドラインに従って、仕様が必要であるとの専門家レビューによって追加されます。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Message Types.
このレジストリのための次のエントリは、この文書で定義されています。彼らは、PB-TNCのメッセージタイプのためのレジストリで最初のエントリです。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 PB-Experimental RFC 5793
0 1 PB-PA RFC 5793
0 2 PB-Assessment-Result RFC 5793
0 3 PB-Access-Recommendation RFC 5793
0 4 PB-Remediation-Parameters RFC 5793
0 5 PB-Error RFC 5793
0 6 PB-Language-Preference RFC 5793
0 7 PB-Reason-String RFC 5793
0 0xffffffff Reserved RFC 5793
The name for this registry is "PA Subtypes". 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-2, and a reference to a specification where the contents of this PA subtype are defined. This specification must define the meaning of this PA subtype and the format and semantics of the PA Message Body field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-PA, the designated numeric value in the PA Subtype field, and the designated Private Enterprise Number in the PA Message Vendor ID field.
このレジストリの名前は、「PAサブタイプ」です。このレジストリ内の各エントリは、SMI民間企業数、0から2 ^ 32-2の間の10進数の整数値、及びこのPAサブタイプの内容が定義されている仕様への参照を人間可読な名前を含むべきです。この仕様は、このPAサブタイプの意味と0のPB-TNCベンダーID、PB-PAのPB-TNCメッセージタイプ、指定さを持っているPB-TNCメッセージ用のPAメッセージ本文フィールドのフォーマットとセマンティクスを定義する必要がありますPAサブタイプフィールドに数値、およびPAメッセージベンダーIDフィールドに指定された民間企業数。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリのエントリは、6.1節のガイドラインに従って、仕様が必要であるとの専門家レビューによって追加されます。
This document does not define any initial entries for this registry. Therefore, this registry should initially be empty. Subsequent RFCs (such as PA-TNC) will define entries in this registry.
この文書では、このレジストリのための任意の初期エントリを定義しません。したがって、このレジストリは、最初は空でなければなりません。 （例えばPA-TNCなど）以降のRFCは、このレジストリのエントリを定義します。
The name for this registry is "PB-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 0 and 2^32-1, and a reference to a specification where the contents of this remediation parameters type are defined. This specification must define the meaning of this remediation parameters type value and the format and semantics of the Remediation Parameters field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Remediation-Parameters, the designated numeric value in the Remediation Parameters Type field, and the designated Private Enterprise Number in the Remediation Parameters Vendor ID field.
このレジストリの名前は、「PB-TNC修復パラメータの種類」です。このレジストリ内の各エントリは、SMI民間企業数、0から2 ^ 32-1の間の10進数の整数値、この修復パラメータタイプの内容が定義されている仕様への参照を人間可読な名前を含むべきです。この仕様は、この修復パラメータタイプ値と0のPB-TNCベンダーID、PB-修復・パラメータのPB-TNCメッセージタイプを持っているPB-TNCメッセージの修復パラメータフィールドのフォーマットと意味論の意味を定義する必要があります、修復パラメータタイプ]フィールドで指定された数値、および修復パラメータベンダーIDフィールドに指定された民間企業数。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリのエントリは、6.1節のガイドラインに従って、仕様が必要であるとの専門家レビューによって追加されます。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Remediation Parameters Types.
このレジストリのための次のエントリは、この文書で定義されています。彼らは、PB-TNC修復パラメータタイプのレジストリで最初のエントリです。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 1 Remediation-URI RFC 5793
0 2 Remediation-String RFC 5793
The name for this registry is "PB-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^16-1, and a reference to a 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 Parameters field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Error, the designated numeric value in the Error Code field, and the designated Private Enterprise Number in the Error Code Vendor ID field.
このレジストリの名前は、「PB-TNCエラーコード」です。このレジストリ内の各エントリは、SMI民間企業数、0から2 ^ 16-1の間の10進数の整数値、およびこのエラーコードが定義されている仕様への参照を人間可読な名前を含むべきです。この仕様は、このエラーコードの意味と0のPB-TNCベンダーID、PB-エラーのPB-TNCメッセージタイプ、指定された数値を持っているPB-TNCメッセージのエラーパラメータフィールドのフォーマットとセマンティクスを定義する必要がありますエラーコードフィールドの値、およびエラーコードのベンダーIDフィールドに指定された民間企業数。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリのエントリは、6.1節のガイドラインに従って、仕様が必要であるとの専門家レビューによって追加されます。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Error Codes.
このレジストリのための次のエントリは、この文書で定義されています。彼らは、PB-TNCエラーコードのためのレジストリで最初のエントリです。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Unexpected Batch Type RFC 5793
0 1 Invalid Parameter RFC 5793
0 2 Local Error RFC 5793
0 3 Unsupported Mandatory Message RFC 5793
0 4 Version Not Supported RFC 5793
Thanks to the Trusted Computing Group for contributing the initial text upon which this document was based.
この文書がベースになった最初のテキストに貢献するための信頼できるコンピューティンググループに感謝します。
The authors of this document would like to acknowledge the following people who have contributed to or provided substantial input on the preparation of this document or predecessors to it: Bernard Aboba, Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Gene Chang, Roger Chickering, Scott Cochrane, Pasi Eronen, Aman Garg, Sandilya Garimella, Lauren Giroux, Mudit Goel, Charles Goldberg, Thomas Hardjono, Chris Hessing, Hidenobu Ito, John Jerrim, Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Tom Kelnar, Bryan Kingsford, PJ Kirner, Houcheng Lee, Sung Lee, Lisa Lorenzin, Mahalingam Mani, Paul Mayfield, Michael McDaniels, Bipin Mistry, Rod Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn, Alex Romanyuk, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad, Joseph Tardo, Lee Terrell, Chris Trytten, Brad Upson, Ram Vadali, Guha Prasad Venataraman, John Vollbrecht, Jun Wang, and Han Yin.
バーナードAboba、アミットAgarwalさん、モーテッサ・アンサリ、ダイアナアロヨ、スチュアート・ベイリー、ボリスBalacheff、ジーン：本書の著者はに貢献したか、それには、この文書または前任者の準備に相当な入力を提供した以下の方々に感謝しますチャン、ロジャー・チカーリング、スコット・コクラン、パシEronen、アマンガーグ、Sandilya Garimella、ローレン・ジルー、Mudit Goelさん、チャールズ・ゴールドバーグ、トーマスHardjono、クリスHessing、秀信伊藤、ジョンJerrim、Meenakshi Kaushikによる、グレッグKazmierczak、スコット・ケリー、トムKelnar、ブライアン・キングスフォード、PJ Kirner、Houchengリー、宋・リー、リサLorenzin、Mahalingamマニ、ポール・メイフィールド、マイケルMcDaniels、Bipin Mistryさん、ロッドマーチソン、バーバラ・ネルソン、和明二村、ロン・ポン、イワンPulleyn、アレックスRomanyuk、クリス・ソルター、マウリシオ・サンチェス、ポール・サングスター、ディーン・シェフィールド、カーティスSimonson、ジェフ・六、ネッド・スミス、ミシェルSommerstad、ジョセフTardo、リー・テレル、クリスTrytten、ブラッド・アップソン、ラムVadali、グハプラサドVenataraman、ジョンVollbrecht、6月王、そして漢殷。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[2]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[3] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[3]フィリップス、A.編、およびM.デイビス、エド。、 "言語を識別するためのタグ"、BCP 47、RFC 5646、2009年9月。
[4] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[4] Alvestrand、H.、 "コンテンツ言語ヘッダ"、RFC 3282、2002年5月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[5] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[6] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[7] Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV Binding", Trusted Computing Group, February 2008.
[7]ハンナ、S.、ハースト、R.とR. Sahita、 "TNC IF-TNCCS：バインディングTLV"、トラステッド・コンピューティング・グループ、2008年2月。
[8] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[8]サングスター、P.、Khosravi、H.、マニ、M.、ナラヤン、K.、およびJ. Tardo、 "ネットワークエンドポイントの評価（NEA）：概要および要件"、RFC 5209、2008年6月。
[9] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[9] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[10] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
[10]サングスター、P.、およびK.ナラヤン、 "PA-TNC：トラステッドネットワーク接続（TNC）に対応姿勢属性（PA）プロトコル"、RFC 5792、2010年3月。
Appendix A. Use Cases
付録A.ユースケース
A.1. Initial Client-Triggered Assessment
A.1。初期クライアント・トリガアセスメント
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）の両方からパッチ情報の収集を伴います。ベンダー固有のパッチのPosture検証（PV）と姿勢ブローカーサーバー（PBS）によって返される準拠したシステムアセスメントの意思決定につながる対応の査定の裁判での標準OSのPosture検証結果の両方による評価。
+--------+ +-------+ +---------+ +--------+ +-------++--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
| Vndr。 X | | STD。 | | STD。 | | STD。 | | STD。 || Vndr。 X |
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
|パッチPC | | OS PC | | PBC | | PBS | | OS PV ||パッチPV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----++---+---+
| | N/W Join| | | |
| | N / W参加します| | | |
| | ----->| | | |
| | Req Post. | | | |
| |必須ポスト。 | | | |
| +<----------+ | | |
| | Req Post. | | | |
| |必須ポスト。 | | | |
+<--------------------| | | |
|Vndr X Patch Posture | | | |
| Vndr Xパッチ姿勢| | | |
|-------------------->| | | |
| |OS Posture | | | |
| | OS姿勢| | | |
| |---------->| | | |
| | | Posture | | |
| | |姿勢| | |
| | | Report | | |
| | |レポート| | |
| | +-------->| | |
| | | | Verify | |
| | | |確認してください| |
| | | | Posture | |
| | | |姿勢| |
| | | |---------> |
| | | | | Verify |
| | | | |確認してください|
| | | | | Posture |
| | | | |姿勢|
| | | |------------------->|
| | | | OS Reslt | |
| | | | OS結果| |
| | | |<---------| |
| | | | VndrX Patch Result |
| | | | VndrXパッチ結果|
| | | Assess |<-------------------|
| | | Result | |
| | |結果| |
| | <---------| | |
| | OS PRslt | | | |
| | PRslt | | | |
| |<----------| | | |
| VndrX Patch PResult | | | |
| VndrXのパッチディレクトリ| | | |
|<--------------------| | | |
A.1.1. Message Contents
A.1.1。メッセージの内容
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メッセージのそれぞれのキー・フィールドの内容を示しています。必要な場合には、追加的な解説は、特定のフィールドが示されている値が含まれている理由を説明するために提供されます。メッセージ・コンテンツが表示されないように示すフローの多くは、同じシステム上のコンポーネントの間であることに留意されたいです。
A.1.1.1. N/W Join
A.1.1.1。 N / Wに参加
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 doesn't include a message being sent.
この流れは、ネットワークへのアクセスを得るために、エンドポイントの評価を開始することを決定するPBCの原因となるイベントを表します。これは単なるイベントであり、送信されたメッセージが含まれていません。
A.1.1.2. Request Posture (Req Post.)
A.1.1.2。リクエスト姿勢（必須ポスト。）
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, NEA doesn't specify the contents of this flow.
このフローは、OSの起動を示し、特定の姿勢を要求するパッチ姿勢コレクターが送信される属性。このユースケースは、ローカルにトリガされますので、NEAは、このフローの内容を指定していません。
A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)
A.1.1.3。ベンダーXパッチ姿勢（VndrXパッチ姿勢）
This flow contains the PA message from the Vendor X Patch Posture Collector; the message content is described in the PA-TNC specification.
この流れは、ベンダーXパッチ姿勢コレクターからPAメッセージが含まれています。メッセージの内容は、PA-TNCの明細書に記載されています。
A.1.1.4. OS Posture
A.1.1.4。姿勢
This flow contains the PA message from the OS Posture Collector; the message content is described in the PA-TNC specification.
この流れは、OSのPostureコレクターからPAメッセージが含まれています。メッセージの内容は、PA-TNCの明細書に記載されています。
A.1.1.5. Posture Report
A.1.1.5。姿勢レポート
This flow contains the PB message containing the PA messages from the Patch and OS Posture Collectors:
この流れは、パッチおよびOS姿勢コレクターからPAメッセージを含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=0 (Posture Broker Client is originator)
Dビット= 0（姿勢ブローカクライアントは、発信者です）
Batch Type=CDATA
バッチタイプ= CDATA
Batch Length
バッチの長さ
}
｝
PB Message 1 {
PBメッセージ1 {
Vendor-id=0
ベンダーID = 0
Type =2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=0 (Standard)
PA-MSG-ベンダーID = 0（標準）
PA-subtype=1 (OS)
PA-サブタイプ= 1（OS）
OS Posture PA Message
OS PA姿勢のメッセージ
}
｝
}
｝
PB Message 2 {
PBメッセージ2 {
Vendor-id=0
ベンダーID = 0
Type =2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=1 (Vendor X)
PA-MSG-ベンダーID = 1（ベンダーX）
PA-subtype=1 (Vendor X PA sub-type for patch management)
PAサブタイプ= 1（パッチ管理のためのベンダーX PAサブタイプ）
Vendor X Patch Posture PA Message
ベンダーXパッチ姿勢PAメッセージ
}
｝
}
｝
}
｝
A.1.1.6. Verify Posture
A.1.1.6。姿勢を確認してください
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 doesn't specify the message content.
この流れは、OSの起動や属性が受信姿勢のパッチ姿勢バリデータ要求の検証を示しています。このフローはNEAサーバ内でローカルに行われるため、NEAは、メッセージの内容を指定していません。
A.1.1.7. OS Posture Result (OS Reslt)
A.1.1.7。姿勢結果（結果）
This flow contains the PA message (Posture Assessment Result) from the OS Posture Validator; the message content is described in the PA-TNC specification.
この流れは、OSのPosture検証からPAメッセージ（姿勢評価結果）を含んでいます。メッセージの内容は、PA-TNCの明細書に記載されています。
A.1.1.8. Vendor X Patch Posture Result (VndrX Patch Result)
A.1.1.8。ベンダーXパッチ姿勢結果（VndrXパッチ結果）
This flow contains the PA message (Posture Assessment Result) from the Vendor X Patch Posture Validator; the message content is described in the PA-TNC specification.
この流れは、ベンダーXパッチのPosture検証からPAメッセージ（姿勢評価結果）を含んでいます。メッセージの内容は、PA-TNCの明細書に記載されています。
A.1.1.9. Assessment Result (Assess Result)
A.1.1.9。評価結果（検索結果を評価します）
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:
この流れは、パッチおよびOS姿勢バリデータから姿勢ブローカーサーバーとPAメッセージによって計算されたシステムの評価結果を含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
Dビット= 1（姿勢ブローカサーバが発信元です）
Batch Type=RESULT
バッチタイプ= RESULT
Batch Length
バッチの長さ
}
｝
PB Message 1 {
PBメッセージ1 {
Vendor-id=0,
ベンダーID = 0、
Type =3 (Access-Recommendation)
タイプ= 3（アクセス推薦）
Length
長さ
Value = {
値= {
System-Evaluation-Result=0 (Compliant)
システム評価結果= 0（準拠）
}
｝
}
｝
PB Message 2 {
PBメッセージ2 {
Vendor-id=0,
ベンダーID = 0、
Type=2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=0
PA-MSG-ベンダーID = 0
PA-subtype=1 (OS)
PA-サブタイプ= 1（OS）
OS Posture Result PA Message
OS姿勢結果PAメッセージ
}
｝
}
｝
PB Message 3 {
PBメッセージ3 {
Vendor-id=0,
ベンダーID = 0、
Type=2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=1 (Vendor X)
PA-MSG-ベンダーID = 1（ベンダーX）
PA-subtype=1 (Vendor X PA sub-type for patch management)
PAサブタイプ= 1（パッチ管理のためのベンダーX PAサブタイプ）
Vendor X Patch Posture Result PA Message
ベンダーXパッチ姿勢結果PAメッセージ
}
｝
}
｝
}
｝
A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)
A.1.1.10。姿勢の結果（印刷＆Vndr Xポスト結果）
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 doesn't specify the contents of this flow.
これらのフローは、ポスチャ評価結果を受け取るためにOSやベンダーXパッチ姿勢コレクターの呼び出しを示しています。このフローはローカルにトリガされますので、NEAは、このフローの内容を指定していません。
A.2. Server-Initiated Assessment with Remediation
A.2。修復とサーバ起動アセスメント
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. 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つのアンチウイルスコンポーネントのためにAnti-Virusの属性のコレクションを伴います。エンドポイントは、他のベンダー（ベンダーY）アンチウイルス姿勢バリデータによってベンダー（ベンダーX）のいずれかでアンチウイルス姿勢バリデータと非準拠を準拠するように評価されます。非準拠システムアセスメントの意思決定におけるこの結果は、姿勢ブローカーサーバーによって返されます。姿勢ブローカーサーバーは、応答の一部として、エンドポイントの修復指示を返します。
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| Vndr Y | | Vndr X | | STD。 | | STD。 | | Vndr X | | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
| PC OF | | PC OF | | PBC | | PBS | | PV OF | | PV OF |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | N / W参加します| | |
| | | ----->| | |
| | | | Create | |
| | | |作成| |
| | | |Post. Req | |
| | | |ポスト。必須| |
| | | |--------->| |
| | | |Create Posture Req |
| | | |姿勢必須作成|
| | | |----------+--------->|
| | | |Vndr Y AV Posture Req|
| | | |姿勢必須OF Vndr Y |
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | | X Vndr OFF | |
| | | |Post. Req | |
| | | |ポスト。必須| |
| | | Posture |<---------| |
| | | Request | | |
| | |リクエスト| | |
| | Vndr X AV |<--------| | |
| | Post. Req | | | |
| |役職。必須| | | |
| |<----------| | | |
| Vndr Y AV | | | |
| Vndr Y OFF | | | |
| Posture Req | | | |
|姿勢必須| | | |
+<---------+-----------| | | |
| Vndr Y AV Posture | | | |
|姿勢Vndr Y | | | |
+----------+---------->| | | |
| | Vndr X AV | | | |
| | Vndr X OFF | | | |
| | Posture | | | |
| |姿勢| | | |
| |---------->| Posture | | |
| | |Response | | |
| | |レスポンス| | |
| | |-------->| | |
| | | | Verify | |
| | | |確認してください| |
| | | | Posture | |
| | | |姿勢| |
| | | |--------->| |
| | | | Verify Posture |
| | | |姿勢を確認してください|
| | | |----------+--------->|
| | | |Vndr Y Posture Result|
| | | | Vndr Y姿勢結果|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | | X Vndr OFF | |
| | | |Post Reslt| |
| | | |ポスト結果| |
| | | Assess |<---------| |
| | | Result | | |
| | |結果| | |
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
| Vndr Y POST結果| | | |
+<---------+-----------| | | |
| | | | | |
｜ ｜ ｜ ｜ ｜ ｜
A.2.1. Message Contents
A.2.1。メッセージの内容
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メッセージのそれぞれのキー・フィールドの内容を示しています。必要な場合には、追加的な解説は、特定のフィールドが示されている値が含まれている理由を説明するために提供されます。メッセージ・コンテンツが表示されないように示すフローの多くは、同じシステム上のコンポーネントの間であることに留意されたいです。
A.2.1.1. N/W Join
A.2.1.1。 N / Wに参加
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 doesn't include a message being sent.
この流れは、ネットワークへのアクセスを得るために、エンドポイントの評価を開始することを決定するためにPBSの原因となるイベントを表します。これは単なるイベントであり、送信されたメッセージが含まれていません。
A.2.1.2. Create Posture Request (Create Posture Req)
A.2.1.2。姿勢の要求を作成します（姿勢のReqを作成します）
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus posture validators requesting posture requests to be created. Because this use case is triggered locally, NEA doesn't specify the contents of this flow.
この流れは、作成するベンダーXと姿勢の要求を要求するベンダーY Anti-Virusの姿勢バリデータの呼び出しを示しています。このユースケースは、ローカルにトリガされますので、NEAは、このフローの内容を指定していません。
A.2.1.3. Vendor X Anti-Virus Posture Request (Vndr X AV Post. Req)
A.2.1.3。ベンダーX Anti-Virusの姿勢要求（Vndr X AVポスト。必須）
This flow contains the PA message (Posture Request) from the Vendor X Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.
この流れは、ベンダーX Anti-Virusの姿勢バリデータからPAメッセージ（姿勢Request）を含んでいます。メッセージの内容は、PA-TNCの明細書に記載されています。
A.2.1.4. Vendor Y Anti-Virus Posture Request
A.2.1.4。ベンダーY Anti-Virusの姿勢リクエスト
This flow contains the PA message (Posture Request) from the Vendor Y Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.
この流れは、ベンダーYアンチウイルスポスチャ検証からPAメッセージ（姿勢Request）を含有します。メッセージの内容は、PA-TNCの明細書に記載されています。
A.2.1.5. Posture Request
A.2.1.5。姿勢リクエスト
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators:
この流れは、ベンダーXとYベンダーAnti-Virusの姿勢バリデータからPAメッセージを含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
Dビット= 1（姿勢ブローカサーバが発信元です）
Batch Type=SDATA
バッチタイプ= SDATA
Batch Length
バッチの長さ
}
｝
PB Message 1 {
PBメッセージ1 {
Vendor-id=0
ベンダーID = 0
Type =2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=1 (Vendor X)
PA-MSG-ベンダーID = 1（ベンダーX）
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
PA-サブタイプ= 2（Anti-VirusのためのベンダーX PAサブタイプ）
Vendor X AV Posture Request PA Message
ベンダーX AV姿勢リクエストPAメッセージ
}
｝
}
｝
PB Message 2 {
PBメッセージ2 {
Vendor-id=0
ベンダーID = 0
Type =2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=2 (Vendor Y)
PA-MSG-ベンダーID = 2（ベンダーY）
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
PAサブタイプ= 1（アンチウイルス用のベンダーY PAサブタイプ）
Vendor Y AV Posture Request PA Message
ベンダーY AV姿勢リクエストPAメッセージ
}
｝
}
｝
}
｝
A.2.1.6. Process Posture Request (Vndr X AV Post Req & Vndr Y AV Posture Req)
A.2.1.6。プロセス姿勢要求（姿勢必須のポスト必須＆Vndr YのVndr X）
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to process the Posture Request and return particular posture attributes requested. Because this use case is triggered locally, NEA doesn't specify the contents of this flow.
この流れは、ベンダーXと姿勢の要求を処理し、要求された特定の姿勢の属性を返すためにベンダーY Anti-Virusの姿勢コレクターの呼び出しを示しています。このユースケースは、ローカルにトリガされますので、NEAは、このフローの内容を指定していません。
A.2.1.7. Vendor Y Anti-Virus Posture (Vndr Y AV Posture)
A.2.1.7。そして、アンチウィルスベンダーの姿勢（vndrとAV姿勢）
This flow contains the PA message (response to the Posture Request) from the Vendor Y Anti-Virus Posture Collector; the message content is described in the PA-TNC specification.
この流れは、ベンダーYアンチウィルス姿勢コレクタからPAメッセージ（ポスチャ要求に対する応答）が含まれ;メッセージの内容は、PA-TNCの明細書に記載されています。
A.2.1.8. Vendor X Anti-Virus Posture (Vndr X AV Posture)
A.2.1.8。ベンダーXアンチウイルス姿勢（Vndr X AV姿勢）
This flow contains the PA message (response to the Posture Request) from the Vendor X Anti-Virus Posture Collector; the message content is described in the PA-TNC specification.
この流れは、ベンダーXアンチウィルス姿勢コレクタからPAメッセージ（ポスチャ要求に対する応答）が含まれ;メッセージの内容は、PA-TNCの明細書に記載されています。
A.2.1.9. Posture Response
A.2.1.9。姿勢応答
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Collectors:
この流れは、ベンダーXとYベンダーAnti-Virusの姿勢コレクターからPAメッセージを含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=0 (Posture Broker Client is originator)
Dビット= 0（姿勢ブローカクライアントは、発信者です）
Batch Type=CDATA
バッチタイプ= CDATA
Batch Length
バッチの長さ
}
｝
PB Message 1 {
PBメッセージ1 {
Vendor-id=0
ベンダーID = 0
Type =2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=1 (Vendor X)
PA-MSG-ベンダーID = 1（ベンダーX）
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
PA-サブタイプ= 2（Anti-VirusのためのベンダーX PAサブタイプ）
Vendor X AV Posture PA Message
ベンダーX AV姿勢PAメッセージ
}
｝
}
｝
PB Message 2 {
PBメッセージ2 {
Vendor-id=0
ベンダーID = 0
Type =2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=2 (Vendor Y)
PA-MSG-ベンダーID = 2（ベンダーY）
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
PAサブタイプ= 1（アンチウイルス用のベンダーY PAサブタイプ）
Vendor Y AV Posture PA Message
姿勢PAメッセージのベンダーY
}
｝
}
｝
}
｝
A.2.1.10. Verify Posture
A.2.1.10。姿勢を確認してください
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 doesn't specify the message contents.
このフローは、属性は、受信姿勢の検証を要求するベンダXとベンダーYアンチウィルス姿勢バリデータの呼び出しを示しています。このフローはNEAサーバ内でローカルに行われるため、NEAは、メッセージの内容を指定していません。
A.2.1.11. Vendor Y Anti-Virus Posture Result (Vndr Y AV Post Result)
A.2.1.11。ベンダーY Anti-Virusの姿勢の結果（Vndr Y AVポスト結果）
This flow contains the PA message (Posture Assessment Result) from the Vendor Y Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.
この流れは、ベンダーY Anti-Virusの姿勢バリデータからPAメッセージ（姿勢評価結果）を含んでいます。メッセージの内容は、PA-TNCの明細書に記載されています。
A.2.1.12. Vendor X Anti-Virus Posture Result (Vndr Y AV Post Result)
A.2.1.12。ベンダーX Anti-Virusの姿勢の結果（Vndr Y AVポスト結果）
This flow contains the PA message (Posture Assessment Result) from the Vendor X Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.
この流れは、ベンダーX Anti-Virusの姿勢バリデータからPAメッセージ（姿勢評価結果）を含んでいます。メッセージの内容は、PA-TNCの明細書に記載されています。
A.2.1.13. Assessment Result (Assess Result)
A.2.1.13。評価結果（検索結果を評価します）
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:
この流れは、パッチおよびOS姿勢バリデータから姿勢ブローカーサーバーとPAメッセージによって計算されたシステムの評価結果を含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
Dビット= 1（姿勢ブローカサーバが発信元です）
Batch Type=RESULT
バッチタイプ= RESULT
Batch Length
バッチの長さ
}
｝
PB Message 1 {
PBメッセージ1 {
Vendor-id=0,
ベンダーID = 0、
Type=3 (Access-Recommendation)
タイプ= 3（アクセス推薦）
Length
長さ
Value = {
値= {
PB-Assessment-Result=1 (Non-Compliant)
PB-評価結果= 1（非準拠）
}
｝
}
｝
PB Message 2 {
PBメッセージ2 {
Vendor-id=0,
ベンダーID = 0、
Type=4 (Remediation-Parameters)
タイプ= 4（修正パラメータ）
Length
長さ
Value = {
値= {
Remediation-Param-Vendor-ID=0
修復-のParam-ベンダーID = 0
Remediation-Param-Type=1 (Remediation-URI)
修復-Paramのタイプ= 1（修復-URI）
Remediation-Param=''http://xyz''
修復-のParam = '' のhttp：// XYZ ''
}
｝
}
｝
PB Message 3 {
PBメッセージ3 {
Vendor-id=0,
ベンダーID = 0、
Type=4 (Remediation-Parameters)
タイプ= 4（修正パラメータ）
Length
長さ
Value = {
値= {
Remediation-Param-Vendor-ID=0
修復-のParam-ベンダーID = 0
Remediation-Param-Type=2 (Remediation-String)
修復-Paramのタイプ= 2（修復ストリング）
Remediation-Param=''Try Step1, Step2,...''
修復-のParam = '' お試しくださいステップ1、ステップ2、... ''
}
｝
}
｝
PB Message 4 {
PBメッセージ4 {
Vendor-id=0,
ベンダーID = 0、
Type=2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=1 (Vendor X)
PA-MSG-ベンダーID = 1（ベンダーX）
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
PA-サブタイプ= 2（Anti-VirusのためのベンダーX PAサブタイプ）
Vendor X AV Posture Result PA Message
ベンダーX AV姿勢結果PAメッセージ
}
｝
}
｝
PB Message 5 {
PBメッセージ5 {
Vendor-id=0,
ベンダーID = 0、
Type=2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=2 (Vendor Y)
PA-MSG-ベンダーID = 2（ベンダーY）
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
PAサブタイプ= 1（アンチウイルス用のベンダーY PAサブタイプ）
Vendor Y AV Posture Result PA Message
姿勢の結果PAメッセージのベンダーY
}
｝
}
｝
}
｝
A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post Reslt)
A.2.1.14。姿勢の結果（ポストResltのポストReslt＆Vndr YのVndr X）
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 doesn't specify the contents of this flow.
これらのフローは、姿勢の評価結果を受信するためにベンダーX及びベンダーYアンチウィルス姿勢コレクターの呼び出しを示します。このフローはローカルにトリガされますので、NEAは、このフローの内容を指定していません。
A.3. Client-Triggered Reassessment
A.3。クライアント・トリガ再評価
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 posture policy. The Posture Broker Client triggers the posture assessment when it receives a notification from the Standard VPN Posture Collector about the change to the operational state of the VPN component on the endpoint. Note that the VPN Posture Collector supports standard attributes and some vendor-defined attributes from vendor X's and vendor Y's namespaces. This use case doesn't 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. This use case relies on the use of a virtual Posture Collector concept described in section 3.3 of the PA-TNC specification. As illustrated in this example, the Posture Broker Client will assign two Posture Collector IDs to a single Posture Collector (Standard VPN PC), and the Posture Collector will generate two separate PA messages to report the posture for Vendor X and Vendor Y VPN Clients. The Posture Broker Client will use 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.
このシナリオでは、エンドポイント上のソフトウェア・コンポーネントを有効にした結果として、エンドポイントの再評価することを含みます。エンドポイントは、2つのVPNクライアントソフトウェアコンポーネント、ユーザのホームネットワークのためのベンダーXから1とエンドポイントは、現在アクセスしているネットワークのベンダーYから他のを持っています。評価は、ユーザーがベンダーX VPNクライアントを使用しようとしたときにトリガされます。これは、姿勢ポリシーの違反です。姿勢ブローカークライアントは、エンドポイントのVPNコンポーネントの動作状態への変化についての標準VPN姿勢コレクターからの通知を受けたポスチャ評価をトリガします。 VPN姿勢コレクタは、標準の属性とベンダーのXさんとYベンダーの名前空間からのいくつかのベンダー定義の属性をサポートしていることに注意してください。このユースケースは、ベンダー定義属性を活用しません。評価は、非準拠査定結果になり、標準VPNのPosture Validatorによって属性標準VPN姿勢の検証を必要とします。このユースケースは、PA-TNC仕様のセクション3.3で説明した仮想姿勢コレクターの概念の使用に依存しています。この例に示すように、姿勢ブローカークライアントは、単一の姿勢コレクタ（標準VPNのPC）への2つの姿勢コレクターIDを割り当てます、そして姿勢コレクターは、ベンダーXおよびベンダーY VPNクライアントの姿勢を報告するための2つの別々のPAメッセージを生成します。姿勢ブローカークライアントは、NEA Serverに送信PBメッセージに割り当てられたIDを使用します。この全体の動作は、NEAクライアント上の2人のVPN姿勢コレクターがあったかのようにPBメッセージを処理するNEAサーバーに完全に不透明になります。
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
| Vndr X | | Vndr Y | |標準| |標準| |標準| |標準|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
| VPNクライアント| | VPNクライアント| | VPN PC | | PBC | | PBS | | VPN PC |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
---->| | | | | |
| VPN Status Change | | | |
| VPNのステータス変更| | | |
|--------------------->| Posture | | |
| | | Change | | |
| | |変更| | |
| | |-------->| | |
| | |Req. Post| | |
| | |必須。ポスト| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |イン/ Rqの情報| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
|点検/リクエスト情報| | | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |VPNY Post| | |
| | | VPNYポスト| | |
| | |-------->| | |
| | | | Posture | |
| | | |姿勢| |
| | | | Report | |
| | | |レポート| |
| | | |--------->| |
| | | | |Vrfy Post. |
| | | | | VRFYポスト。 |
| | | | |---------->|
| | | | |VPN PRslt |
| | | | | VPN PRslt |
| | | | Assess |<----------|
| | | | Result | |
| | | |結果| |
| | | |<---------| |
| | |VPN PRslt| | |
| | | VPN PRslt | | |
| | |<--------| | |
A.3.1. Message Contents
A.3.1。メッセージの内容
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メッセージのそれぞれのキー・フィールドの内容を示しています。必要な場合には、追加的な解説は、特定のフィールドが示されている値が含まれている理由を説明するために提供されます。メッセージ・コンテンツが表示されないように示すフローの多くは、同じシステム上のコンポーネントの間であることに留意されたいです。
A.3.1.1. Enable VPN Client (Enble)
A.3.1.1。 VPNクライアントを有効にする（有効）
This flow represents the end user triggered event of starting the VPN Client software from Vendor X. This is merely an event and doesn't include a message being sent.
この流れは、これは単にイベントであり、送信されるメッセージが含まれていないベンダーXからVPNクライアントソフトウェアを起動するイベントをトリガしたエンドユーザを表します。
A.3.1.2. Notify Status Change (VPN Status Change)
A.3.1.2。ステータス変更を通知する（VPNのステータス変更）
This flow represents the detection of the active state of the Vendor X VPN Client software by the Standard VPN Posture Collector. This is merely an event and doesn't include a message being sent.
この流れは、標準VPN姿勢コレクタによってベンダーX VPNクライアントソフトウェアのアクティブ状態の検出を表します。これは単なるイベントであり、送信されたメッセージが含まれていません。
A.3.1.3. Notify Posture Change (Posture Change)
A.3.1.3。通知姿勢変更（姿勢変更）
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 doesn't include a message being sent.
この流れは、基準姿勢ブローカクライアントにVPN姿勢コレクタから送信されたVPN姿勢変化の通知を表します。これは単なるイベントであり、送信されたメッセージが含まれていません。
A.3.1.4. Request Posture (Req. Post)
A.3.1.4。リクエスト姿勢（必須。ポスト）
This flow illustrates an invocation of the VPN Posture Collector requesting particular posture attributes to be sent. Because this use case is triggered locally, the contents of this flow aren't specified by NEA.
このフローは、特定の姿勢を送信する属性要求VPN姿勢コレクタの呼び出しを示します。このユースケースは、ローカルにトリガされているので、このフローの内容は、NEAによって指定されていません。
A.3.1.5. Inspect/Request Information (Ins/Rq Info)
A.3.1.5。点検/リクエスト情報（INS / Rqの情報）
This flow illustrates the acquisition of the posture attributes by the Standard VPN Posture Collector from the Vendor X and Vendor Y VPN Client components. Because this flow is triggered locally, NEA doesn't specify the message contents.
この流れは、姿勢ベンダーX及びベンダーY VPNクライアントコンポーネントからの標準VPN姿勢コレクタによって属性の取得を示します。このフローはローカルにトリガされますので、NEAは、メッセージの内容を指定していません。
A.3.1.6. Vendor X VPN Posture (VPNX Post.)
A.3.1.6。ベンダーX VPN姿勢（VPNXポスト。）
This flow contains the PA message from the VPN Posture Collector for Vendor X VPN Client posture; the message content is described in the PA-TNC specification.
この流れは、ベンダーX VPN Clientの姿勢のためのVPN姿勢コレクターからPAメッセージが含まれています。メッセージの内容は、PA-TNCの明細書に記載されています。
A.3.1.7. Vendor Y VPN Posture (VPNY Post.)
A.3.1.7。ベンダーY VPN姿勢（VPNYポスト。）
This flow contains the PA message from the VPN Posture Collector for Vendor Y VPN Client posture; the message content is described in the PA-TNC specification.
この流れは、ベンダーY VPN Clientの姿勢のためのVPN姿勢コレクターからPAメッセージが含まれています。メッセージの内容は、PA-TNCの明細書に記載されています。
A.3.1.8. Posture Report (Post. Rpt.)
A.3.1.8。姿勢報告書（ポスト。RPT。）
This flow contains the PB message containing the PA message from the VPN Posture Collector:
この流れは、VPN姿勢コレクターからPAメッセージを含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=0 (Posture Broker Client is originator)
Dビット= 0（姿勢ブローカクライアントは、発信者です）
Batch Type=CRETRY
バッチタイプ= CRETRY
Batch Length
バッチの長さ
}
｝
PB Message 1 {
PBメッセージ1 {
Vendor-id=0
ベンダーID = 0
Type =2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=0
PA-MSG-ベンダーID = 0
PA-subtype=7 (VPN)
PAサブタイプ= 7（VPN）
Posture-Collector-ID=1 //Virtual Posture Collector ID for Vendor X VPN Client
ベンダーX VPN Clientの姿勢コレクター-ID = 1 //仮想姿勢コレクターID
Vendor X VPN Posture PA Message
ベンダーX VPN姿勢PAメッセージ
}
｝
}
｝
PB Message 2 {
PBメッセージ2 {
Vendor-id=0
ベンダーID = 0
Type =2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=0
PA-MSG-ベンダーID = 0
PA-subtype=7 (VPN)
PAサブタイプ= 7（VPN）
Posture-Collector-ID=2 //Virtual Posture Collector ID for Vendor Y VPN Client
ベンダーY VPN Clientの姿勢コレクター-ID = 2 //仮想姿勢コレクターID
Vendor Y VPN Posture PA Message
ベンダーY VPN姿勢PAメッセージ
}
｝
}
｝
A.3.1.9. Verify Posture (Vrfy Post.)
A.3.1.9。姿勢を確認（VRFYポストを。）
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 doesn't specify the message contents.
このフローは、受信された姿勢属性のVPN姿勢検証要求検証の呼び出しを示しています。このフローはNEAサーバ内でローカルに行われるため、NEAは、メッセージの内容を指定していません。
A.3.1.10. VPN Posture Result (VPN PRslt)
A.3.1.10。 VPN姿勢結果（VPN PRslt）
This flow contains the PA message (Posture Assessment Result) from the VPN Posture Validator; the message content is described in the PA-TNC specification.
この流れは、VPNのPosture検証からPAメッセージ（姿勢評価結果）を含んでいます。メッセージの内容は、PA-TNCの明細書に記載されています。
A.3.1.11. Assessment Result (Assess Result)
A.3.1.11。評価結果（検索結果を評価します）
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:
この流れは、姿勢ブローカーサーバーとVPNのPosture検証からPAメッセージによって計算されたシステムの評価結果を含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
Dビット= 1（姿勢ブローカサーバが発信元です）
Batch Type=RESULT
バッチタイプ= RESULT
Batch Length
バッチの長さ
}
｝
PB Message 1 {
PBメッセージ1 {
Vendor-id=0,
ベンダーID = 0、
Type =3 (Access-Recommendation)
タイプ= 3（アクセス推薦）
Length
長さ
Value = {
値= {
PB-Assessment-Result=1 (Non-Compliant)
PB-評価結果= 1（非準拠）
}
｝
}
｝
PB Message 2 {
PBメッセージ2 {
Vendor-id=0,
ベンダーID = 0、
Type=2 (PB-PA)
タイプ= 2（PB-PA）
Length
長さ
Value = {
値= {
PA-Msg-vendor-id=0
PA-MSG-ベンダーID = 0
PA-subtype=7 (VPN)
PAサブタイプ= 7（VPN）
VPN Posture Result PA Message
VPN姿勢結果PAメッセージ
}
｝
}
｝
A.3.1.12. Posture Result (VPN PRslt)
A.3.1.12。姿勢の結果（VPN PRslt）
This flow illustrate an invocation of the VPN Posture Collectors to receive the posture assessment result. Because this flow is triggered locally, NEA doesn't specify the contents of this flow.
この流れは、ポスチャ評価結果を受け取るためにVPN姿勢コレクターの呼び出しを示しています。このフローはローカルにトリガされますので、NEAは、このフローの内容を指定していません。
Appendix B. Evaluation against NEA Requirements
NEAの要件に対する付録B.評価
This section evaluates the PB-TNC protocol against the requirements defined in the NEA Requirements document. Each subsection considers a separate requirement from the NEA Requirements document. Only common requirements (C-1 through C-11) and PB requirements (PB-1 through PB-6) are considered, since these are the only ones that apply to PB.
このセクションでは、NEAの要件文書に定義された要件に対するPB-TNCプロトコルを評価します。各サブセクションはNEAの要件文書とは別の要件を検討します。これらは、PBに適用される唯一のものであるので、（PB-6を介してPB-1）およびPB要件（C-11を介してC-1）のみ共通の要件が考慮されます。
B.1. Evaluation against Requirement C-1
B.1。要件C-1に対する評価
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 ClientとNEA Serverの間の複数のラウンドトリップをサポートしなければなりません。
PB-TNC meets this requirement. It allows an unlimited number of round trips between the NEA Client and NEA Server.
PB-TNCは、この要件を満たしています。これは、NEA ClientとNEA Serverの間のラウンドトリップの数に制限することができます。
B.2. Evaluation against Requirement C-2
B.2。要件C-2に対する評価
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 ClientとNEA Serverの両方のための方法を提供する必要があります。
PB-TNC meets this requirement. Either the NEA Client or the NEA Server can initiate a posture assessment or reassessment.
PB-TNCは、この要件を満たしています。どちらのNEAクライアントまたはNEA Serverは、ポスチャ評価や再評価を開始することができます。
There is one limitation on this support. If a NEA Server wishes to initiate a reassessment after it has sent a RESULT batch, it must close the underlying transport session and initiate a new assessment. For half-duplex transports, this is unavoidable unless a constant exchange of messages is maintained, which would be very wasteful. For full-duplex transports, it would be possible to allow the Posture Broker Server to send an SRETRY batch even in the Decided state. If the NEA working group reaches consensus that this change should be made, it will be.
この支持体上で1つの制限があります。 NEA Serverは、それが結果バッチを送信した後に再評価を開始することを希望する場合は、基礎となるトランスポートセッションを閉じ、新しい評価を開始する必要があります。メッセージの一定の交換は非常に無駄が多いと思われる、維持されていない限り、半二重トランスポートの場合、これは避けられません。全二重のトランスポートのために、それも決めた状態でSRETRYバッチを送信するために姿勢ブローカーサーバーを許可することが可能であろう。 NEAワーキンググループは、この変更がなされるべきであるというコンセンサスに達した場合、それは次のようになります。
B.3. Evaluation against Requirement C-3
B.3。要件C-3に対する評価
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プロトコルは、再生ベースの攻撃から予防を含む仲介及び端点による能動的および受動的攻撃から保護することができなければなりません。
PB-TNC does not include any security capabilities. It depends on PT to supply a secure transport. This addresses all the necessary threats without adding an extra layer of security. Since this requirement only applies to NEA protocols that include security capabilities, PB-TNC meets this requirement.
PB-TNCは、すべてのセキュリティ機能が含まれていません。それは、安全な輸送を提供するためにPTに依存します。これは、セキュリティの余分なレイヤを追加することなく、必要なすべての脅威に対処しています。この要件は唯一のセキュリティ機能を含むNEAプロトコルに適用されているので、PB-TNCは、この要件を満たしています。
B.4. Evaluation against Requirement C-4
B.4。要件C-4に対する評価
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の）。
PB-TNC meets this requirement. PB-TNC can operate over any PT protocol that meets the requirements for PT stated in the NEA Requirements document. Also, PB-TNC insulates the PA protocol from any specifics of the PT protocol. With PB-TNC, all PT protocols are equivalent from the perspective of the PA protocol.
PB-TNCは、この要件を満たしています。 PB-TNCは、PTがNEA要件文書に記載されているための要件を満たす任意のPTプロトコル上で動作することができます。また、PB-TNCは、PTプロトコルの任意の仕様からPAプロトコルを絶縁します。 PB-TNCと、全てのPTプロトコルはPAプロトコルの観点から同等です。
B.5. Evaluation against Requirement C-5
B.5。要件C-5に対する評価
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, PB-TNC should receive a strong preference. PB-TNC is equivalent with IF-TNCCS 2.0, an open TCG specification. IF-TNCCS 2.0 is an extension of the existing IF-TNCCS 1.X protocols, which have been implemented by dozens of vendors and open source projects.
この要求に基づいて、PB-TNCは強い優先を受けるべきです。 PB-TNCは、IF-TNCCS 2.0、オープンTCG仕様と等価です。 IF-TNCCS 2.0ベンダーの多数のオープンソースプロジェクトで実施されている既存のIF-TNCCS 1.Xプロトコルの拡張です。
B.6. Evaluation against Requirement C-6
B.6。要件C-6に対する評価
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クライアントの数が多い上、多くの姿勢コレクターをサポートしなければなりません。
PB-TNC meets this requirement. PB-TNC supports up to 2^16-1 Posture Collectors and an equal number of Posture Validators in a given PB-TNC session. It also supports an unlimited number of NEA Clients and NEA Servers.
PB-TNCは、この要件を満たしています。 PB-TNCは、2 ^ 16-1姿勢コレクターと所定のPB-TNCセッション姿勢バリの等しい数までサポート。また、NEAクライアントとNEA Serverの無制限の数をサポートしています。
The scalability of PB-TNC extends into other areas as well. For example, PB-TNC supports an unlimited number of batches and each batch can contain up to 2^32-1 octets and about 2^24 PA messages. Each PA message can contain up to 2^32-1 octets. Of course, sending this much data in a NEA assessment is not generally advisable, but the point is that PB-TNC is highly scalable.
PB-TNCのスケーラビリティは、同様に他の領域内に延びています。例えば、PB-TNCは、バッチの数に制限をサポートし、各バッチには、最大2 ^ 32-1オクテット約2 ^ 24 PAメッセージを含めることができます。各PAメッセージには、最大2 ^ 32-1オクテットを含めることができます。もちろん、NEAの評価でこれだけのデータを送信することは、一般的にはお勧めしませんが、ポイントは、PB-TNCは非常にスケーラブルであるということです。
B.7. Evaluation against Requirement C-7
B.7。要件C-7に対する評価
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 ClientとNEA Serverの間の属性のメッセージが多数の効率的な輸送をサポートしなければなりません。
PB-TNC meets this requirement. Each PB-TNC batch can contain about 2^24 PA messages. Since PB-TNC supports an unlimited number of batches in a session, this number is actually unlimited (except perhaps by PT protocols, user patience, or other external factors). As for efficiency, PB-TNC adds only 24 octets of overhead per PA message. PA-TNC can include many attributes in a single PA message so this overhead is diluted further.
PB-TNCは、この要件を満たしています。各PB-TNCバッチは約2 ^ 24 PAメッセージを含めることができます。 PB-TNCは、セッション中のバッチの数に制限をサポートしているので、この数は（おそらくPTプロトコル、ユーザ忍耐、または他の外部要因による場合を除いて）、実際に無制限です。効率については、PB-TNCはPAメッセージごとのオーバーヘッドの唯一の24オクテットが追加されます。このオーバーヘッドがさらに希釈されるように、PA-TNCは、単一のPAメッセージに多くの属性を含むことができます。
B.8. Evaluation against Requirement C-8
B.8。要件C-8に対する評価
Requirement C-8 says:
要件C-8は述べています：
C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links.
C-8 NEAプロトコルは、低帯域幅または高レイテンシのリンクを介して効率的に動作しなければなりません。
PB-TNC meets this requirement. A minimal PB-TNC exchange can be as small as 72 octets and one round trip. Even if privacy policies or other factors require multiple round trips, PB-TNC generally imposes an overhead of only 8 octets per batch and 24 octets per PA message.
PB-TNCは、この要件を満たしています。最小限のPB-TNC交換は72オクテットと1つの往復だけ小さくすることができます。プライバシーポリシーやその他の要因は、複数のラウンドトリップが必要な場合でも、PB-TNCは、一般的にバッチあたりわずか8オクテットとPAメッセージあたり24オクテットのオーバーヘッドを課します。
B.9. Evaluation against Requirement C-9
B.9。要件C-9に対する評価
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のユーザーに表示するためのものの任意の文字列の場合、プロトコルは、ユーザーの言語設定にこれらの文字列を適応サポートしなければなりません。
PB-TNC meets this requirement. It defines a standard way for
the NEA Client and NEA Server to send their language
preferences to each other, leveraging the widely implemented
Accept-Language format defined in RFC 3282.
B.10. Evaluation against Requirement C-10
B.10。要件C-10に対する評価
Requirement C-10 says:
要件C-10は述べています：
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.
C-10 NEAプロトコルは、UTF-8形式の文字列の符号化をサポートしなければなりません。
PB-TNC meets this requirement. All strings in the PB-TNC protocol are encoded in UTF-8 format. This allows the protocol to support a wide range of languages efficiently.
PB-TNCは、この要件を満たしています。 PB-TNCプロトコルのすべての文字列はUTF-8形式でエンコードされています。これは、プロトコルは、効率的な言語の広い範囲をサポートすることができます。
B.11. Evaluation against Requirement C-11
B.11。要件C-11に対する評価
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 ClientとNEA Serverは、の認識になり、利用可能なPTプロトコルの制約に適応できなければなりません。例えば、PA及びPBの動作に影響を与える可能性のあるPTプロトコル特性は、メッセージまたは完全な評価、往復回数の上限、および順序（二重）でNEA接続、最大データサイズを開始することができる端部に制限を含みますメッセージの交換。 PTプロトコルの選択プロセスは、候補PTプロトコルはPAとPBプロトコルに課す制限を考慮する必要があります。
PB-TNC meets this requirement. The PB-TNC protocol is designed to be flexible enough to operate with a variety of underlying PT protocols, including those that may have limitations on message or assessment size, number of round trips, and duplex. Local APIs can 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.
PB-TNCは、この要件を満たしています。 PB-TNCプロトコルは、メッセージまたは評価サイズ、ラウンドトリップの数、および二重に制限を有していてもよいものを含む下地PTプロトコルの様々な動作に十分柔軟であるように設計されます。ローカルAPIは姿勢コレクターと姿勢バリデータは、彼らは以下の制約の展開で動作しているとき発見し、その後、より詳細な属性を利用することを許可することができます。同様に、姿勢コレクターは、非常に制約されたネットワーク接続に直面したとき（前回の評価から、アサーションを含む）小さい属性を送信したり、使用しないことを選択することができます。
B.12. Evaluation against Requirement PB-1
B.12。要件PB-1に対する評価
Requirement PB-1 says:
要件PB-1は述べています：
PB-1 The PB protocol MUST be capable of carrying attributes from the Posture Broker Server to the Posture Broker Client. This enables the Posture Broker Client to learn the posture assessment decision and if appropriate to aid in remediation and notification of the endpoint owner.
PB-1 PBプロトコルは姿勢ブローカクライアントに姿勢ブローカサーバから属性を運ぶことができなければなりません。このことは、適切であれば修復し、エンドポイントの所有者の通知を支援するために姿勢査定決定を学び、する姿勢ブローカークライアントを可能にします。
PB-TNC meets this requirement. It can carry attributes from the Posture Broker Client to the Posture Broker Server and back in an unlimited number of round trips. Furthermore, PB-TNC provides explicit attribute support for posture decision and remediation aid notification.
PB-TNCは、この要件を満たしています。これは、ラウンドトリップの数は無制限に戻っ姿勢ブローカーサーバーへの姿勢ブローカクライアントから属性を運ぶことができます。さらに、PB-TNCは、姿勢の決定および修復援助通知の明示的な属性のサポートを提供します。
B.13. Evaluation against Requirement PB-2
B.13。要件PB-2に対する評価
Requirement PB-2 says:
要件PB-2は述べています：
PB-2 The PB protocol MUST NOT interpret the contents of PA messages being carried; i.e., the data it is carrying must be opaque to it.
PB-2 PBプロトコルが搭載されているPAメッセージの内容を解釈してはいけません。すなわち、それが搬送されたデータは、それに対して不透明でなければなりません。
PB-TNC meets this requirement. It does not parse or interpret PA messages in any way.
PB-TNCは、この要件を満たしています。それはどのような方法でPAメッセージを解析または解釈しません。
B.14. Evaluation against Requirement PB-3
B.14。要件PB-3に対する評価
Requirement PB-3 says:
要件PB-3は述べています：
PB-3 The PB protocol MUST carry unique identifiers that are used by the Posture Brokers to route (deliver) PA messages between Posture Collectors and Posture Validators. Such message routing should facilitate dynamic registration or deregistration of Posture Collectors and Validators. For example, a dynamically registered anti-virus Posture Validator should be able to subscribe to receive messages from its respective anti-virus Posture Collector on NEA Clients.
PB-3、PBプロトコルは、ルート（配信）姿勢コレクターと姿勢バリ間PAメッセージにポスチャブローカーによって使用される一意の識別子を運ばなければなりません。そのようなメッセージルーティングは、姿勢コレクターとバリデータの動的な登録または登録解除を容易にするはずです。たとえば、動的に登録されたアンチウイルスのPosture ValidatorはNEAクライアント上で、それぞれのアンチウイルス姿勢コレクターからのメッセージを受信するためにサブスクライブすることができるはずです。
PB-TNC meets this requirement. PB-TNC tags each PA message with a PA subtype that the Posture Brokers can use to deliver the PA messages to the proper Posture Collectors and Posture Validators. By tagging messages according to their content, PB-TNC allows Posture Collectors and Posture Validators to be dynamically registered and deregistered, ensuring that each one receives the proper data. PB-TNC also supports exclusive delivery, which allows messages to be targeted at a particular Posture Collector or Posture Validator.
PB-TNCは、この要件を満たしています。 PB-TNCは、姿勢ブローカーが正しい姿勢コレクターと姿勢バリデータにPAメッセージを配信するために使用できるPAサブタイプと各PAメッセージをタグ付けします。その内容に応じてメッセージをタグ付けすることにより、PB-TNCは、それぞれが適切なデータを受信することを確実に、姿勢コレクターと姿勢バリデータが動的に登録し登録解除されることを可能にします。 PB-TNCまた、メッセージが特定の姿勢コレクターや姿勢バリデータを対象とすることを可能にする排他的な配信をサポートしています。
B.15. Evaluation against Requirement PB-4
B.15。要件PB-4に対する評価
Requirement PB-4 says:
要件PB-4は述べています：
PB-4 The PB protocol MUST be capable of supporting a half-duplex PT protocol. However, this does not preclude PB from operating full-duplex when running over a full-duplex PT.
PB-4ザPBプロトコルは半二重PTプロトコルをサポートできなければなりません。しかし、これは全二重PT上で実行している場合、全二重動作してからPBを排除するものではありません。
PB-TNC meets this requirement. In order to insulate PA from any differences between half-duplex and full-duplex PT protocols, PB-TNC always operates in a half-duplex mode, regardless of the capabilities of the PT protocol. While this could in theory slow assessments that require many round trips or bidirectional multimedia exchanges, this is not a problem in practice because endpoint assessments do not typically involve multimedia or a large number of round trips.
PB-TNCは、この要件を満たしています。半二重および全二重PTプロトコル間の相違からPAを絶縁するためには、PB-TNCは関係なく、常にPTプロトコルの機能を、半二重モードで動作します。これは、多くのラウンドトリップや双方向マルチメディアの交換が必要な理論遅い評価でもできますが、エンドポイントの評価は、一般的に、マルチメディアやラウンドトリップの多数を伴わないので、これは実際には問題ではありません。
B.16. Evaluation against Requirement PB-5
B.16。要件PB-5に対する評価
Requirement PB-5 says:
要件PB-5は述べています：
PB-5 The PB protocol MAY support authentication, integrity, and confidentiality protection for the attribute messages it carries between a Posture Broker Client and Posture Broker Server. This provides security protection for a message dialog of the groupings of attribute messages exchanged between the Posture Broker Client and Posture Broker Server. Such protection is orthogonal to PA protections (which are end to end) and allows for simpler Posture Collector and Validators to be implemented, and for consolidation of cryptographic operations possibly improving scalability and manageability.
PB-5 PBプロトコルは、それが姿勢ブローカークライアント・姿勢ブローカーサーバーの間で運ぶ属性のメッセージのための認証、整合性、および機密保護をサポートするかもしれません。これは、姿勢ブローカークライアント・姿勢ブローカーサーバーの間で交換される属性のメッセージのグループ化のメッセージダイアログのセキュリティ保護を提供します。そのような保護は、（エンドツーエンドである）PAの保護に直交し、かつ簡単姿勢コレクタとバリデータを実装することを可能にし、暗号化操作を統合するための可能性のスケーラビリティと管理性を向上させることができます。
PB-TNC does not address this optional requirement. It leaves security to PT (which is required to address it) and PA (which SHOULD do so). There seems to be minimal benefit in adding a third layer of security to the NEA protocol stack. However, if the NEA working group determines that PB should include support for authentication, integrity protection, and confidentiality protection, then this could be added to PB in a similar manner to the way that the PA-TNC security is done.
PB-TNCは、このオプションの要件に対処しません。これは、PT（それに対処するために必要とされる）と、（そうする必要があります）PAにセキュリティを残します。 NEAプロトコルスタックへのセキュリティの第三の層を追加することで、最小限の利益があるようです。 NEAのワーキンググループは、PBは、認証、完全性保護、および機密保護のためのサポートを含むべきであると判断した場合は、これはPA-TNCセキュリティが行われている方法と同様にPBに加えることができます。
B.17. Evaluation against Requirement PB-6
B.17。要件PB-6に対する評価
Requirement PB-6 says:
要件PB-6は述べています：
PB-6 The PB protocol MUST support grouping of attribute messages to optimize transport of messages and minimize round trips.
PB-6ザ・PBプロトコルは、メッセージの転送を最適化し、ラウンドトリップを最小限にするために属性メッセージのグループ化をサポートしなければなりません。
PB-TNC meets this requirement. Multiple attribute messages can be conveyed in a single PA message. In fact, that's how PA-TNC works.
PB-TNCは、この要件を満たしています。複数の属性のメッセージは、単一のPAメッセージに搬送することができます。実際には、それはPA-TNCがどのように動作するかです。
Authors' Addresses
著者のアドレス
Ravi Sahita Intel Corporation 2200 Mission College Blvd. Santa Clara, CA 95054 USA EMail: Ravi.Sahita@intel.com
ラヴィSahitaインテルコーポレーション2200ミッション・カレッジブルバードサンタクララ、CA 95054 USA電子メール：Ravi.Sahita@intel.com
Steve Hanna Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA EMail: shanna@juniper.net
スティーブ・ハンナジュニパーネットワークス株式会社1194北マチルダアベニューサニーベール、CA 94089 USA Eメール：shanna@juniper.net
Ryan Hurst Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: Ryan.Hurst@microsoft.com
ライアン・ハーストマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052 USA電子メール：Ryan.Hurst@microsoft.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 USA EMail: kaushik@cisco.com
Kaushikによるナラヤンシスコシステムズ株式会社10西タスマン・ドライブサンノゼ、CA 95134 USA電子メール：kaushik@cisco.com