[要約] RFC 5793は、ネットワークエンドポイント評価（NEA）において、複数の評価アプリケーションのメッセージを効率的に集約・転送するための「ポスチャブローカープロトコル（PB-TNC）」を定義しています。TCGの仕様に基づき、クライアント側のコレクターとサーバー側のバリデーター間で、異なる種類のセキュリティ評価データ（RFC 5792等）をカプセル化して運ぶためのセッション管理とメッセージ多重化の手順を規定しています。
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)
PB-TNC：Trusted Network Connect (TNC) と互換性のある姿勢ブローカー (PB) プロトコル
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.
この文書では、Trusted Computing GroupのIF-TNCCS 2.0プロトコルと同一のPosture BrokerプロトコルであるPB-TNCを規定します。さらに、Network Endpoint Assessment (NEA) Requirements仕様で定められた要件に照らして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.
この文書はInternet Engineering Task Force (IETF)が作成したもので、IETFコミュニティの合意を表します。公開レビューを経て、Internet Engineering Steering Group (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.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
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 Trustの「IETF文書に関する法的規定」（http://trustee.ietf.org/license-info）が適用されます。これらの文書には本書に関する権利と制限が記載されているため、注意深く確認してください。本書から抽出したコードコンポーネントには、Trustの法的規定のセクション4.eで説明されている簡易BSDライセンスの文面を含める必要があります。また、簡易BSDライセンスに記載されているとおり、保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008年11月10日より前に公開された、または一般に利用可能になったIETF文書またはIETFコントリビューションの素材が含まれている場合があります。この素材の一部について著作権を管理する者は、IETF標準プロセスの外でその素材を変更することを許可する権利をIETFトラストに付与していない可能性があります。そのような素材の著作権を管理する者から適切なライセンスを取得しない限り、IETF標準プロセスの外でこの文書を変更することはできません。また、RFCとして発行するために書式を整える場合と英語以外の言語に翻訳する場合を除き、IETF標準プロセスの外でこの文書の派生物を作成することはできません。
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
1. Introduction ....................................................4
1. はじめに ........................................................4
1.1. Prerequisites ..............................................4
1.1. 前提条件 ...................................................4
1.2. Message Diagram Conventions ................................4
1.2. メッセージ図の表記規則 .....................................4
1.3. Terminology ................................................4
1.3. 用語 .......................................................4
1.4. Conventions Used in This Document ..........................4
1.4. 本文書で使用する表記規則 ...................................4
2. PB-TNC Design Considerations ....................................5
2. PB-TNCの設計上の考慮事項 ........................................5
2.1. Message Addressing .........................................5
2.1. メッセージのアドレス指定 ...................................5
2.2. Vendor IDs .................................................7
2.2. ベンダーID .................................................7
2.3. Efficiency .................................................7
2.3. 効率性 .....................................................7
3. PB-TNC Protocol Description .....................................7
3. PB-TNCプロトコルの説明 ..........................................7
3.1. Protocol Overview ..........................................7
3.1. プロトコルの概要 ...........................................7
3.2. PB-TNC State Machine .......................................8
3.2. PB-TNC状態機械 .............................................8
3.3. Layering on PT ............................................11
3.3. PT上での階層化 ............................................11
3.4. Example of PB-TNC Encapsulation ...........................12
3.4. PB-TNCカプセル化の例 ......................................12
4. PB-TNC Protocol Specification ..................................13
4. PB-TNCプロトコル仕様 ...........................................13
4.1. PB-TNC Header .............................................13
4.1. PB-TNCヘッダー ............................................13
4.2. PB-TNC Message ............................................16
4.2. PB-TNCメッセージ ..........................................16
4.3. IETF Standard PB-TNC Message Types ........................19
4.3. IETF標準PB-TNCメッセージタイプ ............................19
4.4. PB-Experimental ...........................................19
4.4. PB-Experimental ...........................................19
4.5. PB-PA .....................................................20
4.5. PB-PA .....................................................20
4.6. PB-Assessment-Result ......................................25
4.6. PB-Assessment-Result ......................................25
4.7. PB-Access-Recommendation ..................................26
4.7. PB-Access-Recommendation ..................................26
4.8. PB-Remediation-Parameters .................................28
4.8. PB-Remediation-Parameters .................................28
4.9. PB-Error ..................................................32
4.9. PB-Error ..................................................32
4.10. PB-Language-Preference ...................................37
4.10. PB-Language-Preference ...................................37
4.11. PB-Reason-String .........................................38
4.11. PB-Reason-String .........................................38
5. Security Considerations ........................................41
5. セキュリティに関する考慮事項 ...................................41
5.1. Threat Model ..............................................41
5.1. 脅威モデル ................................................41
5.2. Countermeasures ...........................................42
5.2. 対策 ......................................................42
6. IANA Considerations ............................................43
6. IANAに関する考慮事項 ...........................................43
6.1. Designated Expert Guidelines ..............................44
6.1. 指定専門家のガイドライン ..................................44
6.2. Registry for PB-TNC Message Types .........................45
6.2. PB-TNC Message Typeのレジストリ ...........................45
6.3. Registry for PA Subtypes ..................................45
6.3. PA Subtypeのレジストリ ....................................45
6.4. Registry for PB-TNC Remediation Parameters Types ..........46
6.4. PB-TNC Remediation Parameters Typeのレジストリ ............46
6.5. Registry for PB-TNC Error Codes ...........................46
6.5. PB-TNC Error Codeのレジストリ .............................46
7. Acknowledgments ................................................47
7. 謝辞 ...........................................................47
8. References .....................................................47
8. 参考文献 .......................................................47
8.1. Normative References ......................................47
8.1. 規範的参考文献 ............................................47
8.2. Informative References ....................................48
8.2. 参考情報 ..................................................48
Appendix A. Use Cases .............................................49
Appendix A. ユースケース ..........................................49
A.1. Initial Client-Triggered Assessment .......................49
A.1. クライアント起動による初期評価 ............................49
A.2. Server-Initiated Assessment with Remediation ..............54
A.2. 修復によるサーバー開始評価 ................................54
A.3. Client-Triggered Reassessment .............................63
A.3. クライアント起動による再評価 ..............................63
Appendix B. Evaluation against NEA Requirements ...................70
Appendix B. NEA要件に対する評価 ...................................70
B.1. Evaluation against Requirement C-1 ........................70
B.1. 要件C-1に対する評価 .......................................70
B.2. Evaluation against Requirement C-2 ........................70
B.2. Evaluation against Requirement C-2 ........................70
B.3. Evaluation against Requirement C-3 ........................70
B.3. 要件C-3に対する評価 .......................................70
B.4. Evaluation against Requirement C-4 ........................71
B.4. 要件C-4に対する評価 .......................................71
B.5. Evaluation against Requirement C-5 ........................71
B.5. 要件C-5に対する評価 .......................................71
B.6. Evaluation against Requirement C-6 ........................71
B.6. 要件C-6に対する評価 .......................................71
B.7. Evaluation against Requirement C-7 ........................72
B.7. 要件C-7に対する評価 .......................................72
B.8. Evaluation against Requirement C-8 ........................72
B.8. 要件C-8に対する評価 .......................................72
B.9. Evaluation against Requirement C-9 ........................72
B.9. 要件C-9に対する評価 .......................................72
B.10. Evaluation against Requirement C-10 ......................73
B.10. 要件C-10に対する評価 .....................................73
B.11. Evaluation against Requirement C-11 ......................73
B.11. 要件C-11に対する評価 .....................................73
B.12. Evaluation against Requirement PB-1 ......................74
B.12. 要件PB-1に対する評価 .....................................74
B.13. Evaluation against Requirement PB-2 ......................74
B.13. 要件PB-2に対する評価 .....................................74
B.14. Evaluation against Requirement PB-3 ......................74
B.14. 要件PB-3に対する評価 .....................................74
B.15. Evaluation against Requirement PB-4 ......................75
B.15. 要件PB-4に対する評価 .....................................75
B.16. Evaluation against Requirement PB-5 ......................75
B.16. 要件PB-5に対する評価 .....................................75
B.17. Evaluation against Requirement PB-6 ......................76
B.17. 要件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].
この文書では、Trusted Computing GroupのIF-TNCCS 2.0プロトコル [7] と同一のPosture Broker (PB) プロトコルであるPB-TNCを規定します。さらに、Network Endpoint Assessment (NEA) Requirements仕様 [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 Requirements仕様 [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ビットの値を表す行）の中では左から右へたどる順序で送信しなければなりません (MUST)。数値を表す複数バイトのフィールドは、ネットワークバイト順（ビッグエンディアン）で送信しなければなりません。
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にした1オクテットのフィールド値は0x80です。
This document reuses the terminology defined in the NEA Requirements document. One new term is defined in this section.
この文書では、NEA Requirements文書で定義された用語を再利用します。このセクションでは新たに1つの用語を定義します。
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.
バッチ：Posture Transport (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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「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プロトコルの主な目的は、姿勢収集器と姿勢検証器の間でPosture Attribute (PA) メッセージを運ぶことです。また、姿勢ブローカークライアントと姿勢ブローカーサーバーの間で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 Overview and Requirements文書 [8] のセクション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 Message Vendor 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] には、PA Message Vendor IDが0の場合に使用するIETF標準PAサブタイプの一覧があります。Operating SystemやAnti-Virusなどの値があり、OSやウイルス対策に関する姿勢情報を伝えるメッセージに使います。
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メッセージタイプは、定義元ベンダーのStructure of Management Information (SMI) Private Enterprise NumberをPA Message Vendor IDフィールドに設定し、そのベンダーが割り当てたPA Subtype値をPA Subtypeフィールドに設定することで表します。これにより、各ベンダーは他のベンダーや標準値との衝突を気にせず、独自のPA Subtype値を定義できます。
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タイプにやや似ています。姿勢収集器と姿勢検証器は、ローカルAPIを使って、どのPAメッセージタイプを受信したいかを姿勢ブローカークライアントと姿勢ブローカーサーバーに通知できます。たとえば、ウイルス対策の状態を評価する姿勢検証器は、PA Message Vendor IDが0で、Anti-VirusのIETF標準PA Subtypeに一致するPA Subtypeを持つ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.
このタイプベースの購読モデルにより、設計と実装に高い柔軟性が得られます。たとえば、1つの姿勢検証器がウイルス対策やホストベースファイアウォールなど複数の機能を評価する場合があります。姿勢収集器は、姿勢ブローカーサーバーにどの姿勢検証器がインストールされているか、また各検証器が何を扱うかを知る必要はありません。姿勢収集器はメッセージタイプを付けて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 Message Vendor IDフィールドとPA Subtypeフィールドにアクセスする必要があります。また、これらは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.
前述のタイプベースのメッセージ配信方式が、すべての状況に適しているとは限りません。姿勢収集器から特定の姿勢検証器へメッセージを送る必要がある場合もあります。たとえば、特定の姿勢検証器が修復メッセージを送信し、姿勢収集器がその検証器だけに応答する必要がある場合です。このような状況に対応するため、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を割り当てます。姿勢検証器が送信するPAメッセージには、その姿勢検証器のPosture Validator IDがPB-PAメッセージのPosture Validator IDフィールドに含まれます。このメッセージを受信した姿勢収集器は応答を送信し、該当するPosture Validator 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つのメッセージを受信して動的識別子を知るまでは機能しません。静的識別子も代替案として検討されましたが、特定の姿勢収集器と姿勢検証器の組み合わせでしか動かない脆弱な方式となり、同じ静的識別子を持つ装置が複数インストールされたときに問題が生じるため、採用されませんでした。
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 Message Type、PA Subtype、Remediation Parameter Type、Error Codeの各値には、先頭にベンダーIDを付ける方式を採用しています。ベンダーIDが0の場合、後続フィールドの値はIANAレジストリに登録され、その意味はRFCで定義されます。ベンダーIDが0以外の場合、後続フィールドの値はベンダー固有であり、そのベンダーIDとStructure of Management Information (SMI) Private Enterprise Numberが一致するベンダーが定義します。受信者が理解できないベンダー固有メッセージは、NOSKIPフラグが設定されていない限り無視して読み飛ばします。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は、帯域幅が狭いトランスポートや低消費電力の装置でも動作する必要があります。そのため、PB-TNCプロトコルには、Type-Length-Value構造を持つバイナリメッセージという単純でコンパクトな形式を採用しました。
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 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メッセージは、いくつかのフラグを持つType-Length-Value (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メッセージタイプの1つがPB-PAです。このタイプのメッセージには、PAメッセージと各種ルーティング情報が含まれます。PB-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.
姿勢ブローカーサーバーは、多くの場合、複数の姿勢ブローカークライアントと同時に通信する必要があります。逆に、異なるネットワークにつながる複数のネットワークインターフェイスをエンドポイントが持つ場合など、1つのクライアントが複数のサーバーと通信することもあります。姿勢ブローカーサーバーと姿勢ブローカークライアント間の各接続は、個別のPB-TNCセッションとして確立されます。同じサーバーとクライアントの間で複数のセッションが同時に存在することもありますが、一般的ではありません。
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、RESULT）は、特定タイプのPB-TNCバッチの送信または受信によって発生します。PB-TNCバッチのタイプは、そのバッチのPB-TNCヘッダーにあるBatch Typeフィールドの値で示します。簡潔にするため、本書では「Batch TypeフィールドにFOOが含まれるPB-TNCバッチ」の代わりに「FOOバッチ」と記します。特定タイプのPB-TNCバッチの受信によって発生する遷移もあります（例：Receive CRETRY）。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セッションはInit状態で始まります。姿勢ブローカークライアントがPTセッションを開始した場合、CDATAバッチを姿勢ブローカーサーバーへ送信してServer Working状態に遷移します。姿勢ブローカーサーバーがPTセッションを開始した場合、SDATAタイプのPB-TNCバッチを姿勢ブローカークライアントへ送信してClient Working状態に遷移します。
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バッチを交互に送信できます。セッションがClient Working状態にあるときにデータバッチを送信できるのは姿勢ブローカークライアントだけです。Server Working状態にあるときは、姿勢ブローカーサーバーだけがデータバッチを送信できます。
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.
交換を終了する最も一般的な方法は、姿勢ブローカーサーバーがRESULTバッチを送信することです。これによりDecided状態へ遷移しますが、これは終端状態ではありません。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のいずれか、または両方のメッセージが送信された後、次の状態はServer Working Stateです。この状態から姿勢ブローカーサーバーがSDATAバッチを送信し、新しい交換が始まります。「Receive CRETRY」および「Receive CRETRY or SRETRY」と記された状態遷移は、該当する状態でこれらのメッセージを受信してもよいことを示します。これは通常、姿勢ブローカークライアントがCRETRYを送信するのとほぼ同時に、姿勢ブローカーサーバーがSRETRYの送信を決めた場合に起きます。この場合、Server Working状態またはClient Working状態でCRETRYを受信することがあります。また、Server Working状態で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.
唯一の終端状態はEnd状態です。基盤となるPT接続が閉じられると、この状態に到達します。姿勢ブローカークライアントや姿勢ブローカーサーバーの操作が原因の場合もあれば、ネットワークケーブルを抜くなどの外部要因が原因の場合もあります。可能であれば、PT接続を終了する前にCLOSEバッチを送信すべきです (SHOULD)。ただし、PT接続が予告なく閉じられる場合があります。たとえば、ケーブルが抜かれた場合、ソフトウェアに障害が発生した場合、またはPTの半二重制約により姿勢ブローカークライアントや姿勢ブローカーサーバーがCLOSEメッセージを送信できない場合です。このような場合、両者は通常、Posture Transport ClientやPosture Transport ServerからPT接続が閉じられたことを何らかの形で通知されます。この通知によりCLOSE遷移が発生することがあります。ただし、NEA参照モデルの垂直インターフェイスが標準化されていないため、通知のやり取りも標準化されていません。いずれの場合も、CLOSEバッチの受信またはトランスポート終了の通知によってEnd状態へ遷移します。
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セッションにおいて、姿勢ブローカークライアントと姿勢ブローカーサーバーが常にまったく同じ状態にあるとは限りません。たとえば、Client Working状態のセッションで姿勢ブローカークライアントがCDATAバッチを送信したとします。このバッチの送信後、姿勢ブローカーサーバーが受信するまでの間、クライアント側はセッションがServer Working状態だと認識しますが、サーバー側はClient Working状態だと認識します。ただし、これは一時的な状態であり、実際には問題になりません。起こり得る唯一の問題は、相手から応答を受信するまで、相手が自分のメッセージを受信したかどうか分からないことです。
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.
半二重トランスポートを使う場合、セッションがDecided状態にあるとき、姿勢ブローカーサーバーはSRETRYバッチを送信できません。サーバーは直前にRESULTバッチを送信しており、次に送信するとトランスポートプロトコルの半二重性に反するためです。代わりに、半二重トランスポートでDecided状態から新しい交換を開始したいサーバーは、CLOSEバッチを送らずにPT接続を閉じ、新しいPB-TNCセッションを開始することが望ましいです。この制約は全二重トランスポートにはありません。
The Posture Broker Server and Posture Broker Client MUST follow the state machine described in this section.
姿勢ブローカーサーバーと姿勢ブローカークライアントは、このセクションで説明する状態機械に従わなければなりません (MUST)。
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バッチの機密性と完全性の保護、およびリプレイ攻撃への対策を提供しなければなりません (MUST)。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]では、Posture Transportプロトコルの規範的要件を説明しています。このセクションでは、その追加要件を規定します。候補となるPosture Transportプロトコルは、このセクションと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プロトコルはコネクション型でなければならず (MUST)、接続開始と切断を確認する機構をサポートしなければなりません (MUST)。
PT-7 The PT protocol MUST be able to carry binary data.
PT-7 PTプロトコルはバイナリデータを運べなければなりません (MUST)。
PT-8 The PT protocol MUST provide mechanisms for flow control and congestion control.
PT-8 PTプロトコルはフロー制御機構と輻輳制御機構を提供しなければなりません (MUST)。
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プロトコルに提供する機能と課す制約（半二重/全二重、最大メッセージサイズなど）を説明しなければなりません (MUST)。
This section shows how PA messages can be carried inside a PB-TNC batch that is inside a PT protocol.
このセクションでは、PTプロトコル内のPB-TNCバッチにPAメッセージを格納して運ぶ方法を示します。
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ヘッダーが置かれ、その後にPB-PAメッセージが2つ続きます。各PB-PAメッセージには、プラットフォーム上の姿勢収集器または姿勢検証器宛ての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バッチで致命的なInvalid Parameterエラーを返さなければなりません (MUST)。
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バッチは、次のヘッダーで始まらなければなりません (MUST)。各PB-TNCバッチに含めるこのヘッダーは1つだけとし、その後に0個以上のPB-TNCメッセージを続けなければなりません (MUST)。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)
Version（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に設定しなければなりません (MUST)。後の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.
サポートしていないVersion値を受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、Versionヘッダーフィールドを2に設定し、致命的なVersion Not Supportedエラーコードだけを含むCLOSEタイプのPB-TNCバッチで応答しなければなりません (MUST)。サポート対象バージョンを含むPB-TNCメッセージへの応答では、バージョン非互換のリスクを抑えるため、実装は同じVersion番号を使わなければなりません (MUST)。複数のPB-TNCプロトコルバージョンに対応するメッセージ送信側は、特定の相手である姿勢ブローカークライアントまたは姿勢ブローカーサーバーとの先行するメッセージ交換に基づき、送信するPB-TNCメッセージのバージョンを変更できるべきです (SHOULD)。
Directionality (D) (1 bit)
Directionality (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.
姿勢ブローカークライアントがこのメッセージを送信する場合、Directionalityビットを0に設定しなければなりません (MUST)。姿勢ブローカーサーバーが送信する場合は、Directionalityビットを1に設定しなければなりません (MUST)。これにより、姿勢ブローカークライアント同士、または姿勢ブローカーサーバー同士が対話を始める状況を防ぎ、デバッグにも役立ちます。
Reserved (19 bits)
Reserved（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を設定しなければならず (MUST)、受信時には無視します。本仕様の将来のバージョンでは、送信側が一部のビットを設定し、受信側がそれを解釈できるようにする場合があります。
B-Type (Batch Type) (4 bits)
B-Type (Batch Type)（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で説明する状態機械を動作させるために使います。このフィールドには、次の表に示す値のいずれかを設定しなければなりません (MUST)。それ以外の値を受信した場合、受信側はバッチの内容を無視し、CLOSEバッチで致命的なInvalid Parameterエラーコードを送信しなければなりません (MUST)。セクション3.2の状態機械上、受信した値が現在の状態では許可されない場合も、受信側はバッチの内容を無視し、CLOSEバッチで致命的なUnexpected Batch Typeエラーコードを送信しなければなりません (MUST)。
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 姿勢ブローカークライアントは、このBatch Typeのバッチを送信して姿勢ブローカーサーバーへメッセージを伝えられます。姿勢ブローカーサーバーはこのBatch Typeを送信してはなりません (MUST NOT)。送信するメッセージがない場合、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 姿勢ブローカーサーバーは、このBatch Typeのバッチを送信して姿勢ブローカークライアントへメッセージを伝えられます。姿勢ブローカークライアントはこのBatch Typeを送信してはなりません (MUST NOT)。送信するメッセージがない場合、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 姿勢ブローカーサーバーは、このBatch Typeのバッチを送信して評価の完了を示せます。バッチにはPB-Assessment-Resultメッセージを含めなければならず (MUST)、PB-Access-Recommendationメッセージを含めてもかまいません (MAY)。
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 姿勢ブローカークライアントは、交換を再開したいことを示すため、このBatch Typeのバッチを送信できます。姿勢ブローカーサーバーはこのBatch Typeを送信してはなりません (MUST NOT)。姿勢ブローカークライアントにほかに送信するものがない場合、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 姿勢ブローカーサーバーは、交換を再開したいことを示すため、このBatch Typeのバッチを送信できます。姿勢ブローカークライアントはこのBatch Typeを送信してはなりません (MUST NOT)。姿勢ブローカーサーバーにほかに送信するものがない場合、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接続を終了しようとしていることを示すため、このBatch Typeのバッチを送信できます。送信するものがない場合、CLOSEバッチは空でもかまいません（メッセージを含みません）。ただし、致命的なエラーが原因で接続を終了する場合、CLOSEバッチにはPB-Errorメッセージを含めなければなりません (MUST)。
Batch Length (32 bits)
Batch Length（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を示さなければなりません (MUST)。PB-TNC Message Lengthフィールドの値が8未満のPB-TNCメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
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 Message Valueフィールドの形式と意味は、PB-TNC Vendor IDフィールドおよびPB-TNC Message Typeフィールドの値に応じて異なります。
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)
Flags（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.
Flagsフィールドのビット0（最上位ビット）はNOSKIPフラグです。このフラグがクリア（値0）の場合、受信側（姿勢ブローカークライアントまたは姿勢ブローカーサーバー）は、メッセージタイプを理解できない場合や、そのメッセージの定義どおりに処理できない、または処理しない場合に、メッセージをスキップ（無視）できます。このフラグが設定（値1）されている場合、受信側はこの属性をスキップしてはなりません (MUST NOT)。
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バッチのどの部分にも作用してはなりません (MUST NOT)。その代わり、CLOSEバッチで致命的なUnsupported Mandatory Messageエラーコードを返さなければなりません (MUST)。バッチ内の一部のメッセージを処理した後で未対応のNOSKIPフラグ付きメッセージが見つかる事態を避けるため、受信側は処理を始める前にバッチ内のすべてのメッセージを走査し、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に設定し、受信時には無視しなければなりません (MUST)。
PB-TNC Vendor ID (24 bits)
PB-TNC Vendor 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 Vendor IDフィールドは、SMI Private Enterprise Number (PEN) を使ってベンダーを識別します。どの組織も、Internet Assigned Numbers Authority (IANA) から固有のPENを取得できます。このVendor IDによってPB-TNC Message Typeフィールドを区別し、各ベンダーが2^32-1個の異なるメッセージタイプを使用できるようにします。
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を使います。Vendor ID 0xffffffは予約されています。姿勢ブローカークライアントと姿勢ブローカーサーバーは、予約値0xffffffをVendor IDに持つメッセージを送信してはなりません (MUST NOT)。PB-TNC Vendor IDが予約値0xffffffのメッセージを受信した場合、致命的なInvalid Parameterエラーコードを含むCLOSEバッチで応答しなければなりません (MUST)。
PB-TNC Message Type (32 bits)
PB-TNC Message Type（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 Message Typeフィールドは、PB-TNC Message Valueフィールドに含まれるPB-TNCメッセージのタイプを識別します。PB-TNC Message Type 0xffffffffは予約されています。姿勢ブローカークライアントと姿勢ブローカーサーバーは、PB-TNC Message Typeフィールドに予約値0xffffffffを持つメッセージを送信してはなりません (MUST NOT)。この予約値0xffffffffを持つPB-TNC Message Typeフィールドを含むメッセージを受信した場合、致命的なInvalid Parameterエラーコードを含むCLOSEバッチで応答しなければなりません (MUST)。個別のPB-TNCメッセージタイプの定義（PB-Language-Preferenceなど）で禁止されていない限り、1つのPB-TNCバッチに同じメッセージタイプやVendor IDを持つメッセージを複数含めてもかまいません。
The IETF and any other organization with a PEN can define 2^32-1 unique PB-TNC message types, as long as the organization's PEN is placed in the PB-TNC Vendor ID field of the message. Since the PB-TNC message type is qualified by the vendor ID, there is no risk of conflicts as long as each organization uses its own PEN for the vendor ID and manages its own set of 2^32-1 message type values.
PENを持つIETFその他の組織は、その組織のPENをメッセージのPB-TNC Vendor IDフィールドに設定すれば、2^32-1個の固有のPB-TNCメッセージタイプを定義できます。PB-TNC Message TypeはVendor IDと組み合わせて識別されます。各組織が自身のPENをVendor IDとして使い、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 Standard PB-TNC Message Typesと呼びます。このうち一部は必須であり、本仕様への準拠を主張するすべての姿勢ブローカークライアントおよび姿勢ブローカーサーバーの実装が実装しなければなりません (MUST)。必須の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の指針に従い、Expert ReviewとSpecification Requiredの手続きでレジストリエントリーを追加します。
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 Vendor IDが0以外のもの）は、IETFやIANAが関与しなくても、ベンダーが定義して使用できます。ただし、姿勢ブローカークライアントと姿勢ブローカーサーバーは、特定のベンダー固有PB-TNCメッセージタイプへの対応を必須としてはなりません (MUST NOT)。また、対応するベンダー固有メッセージタイプの集合に違いがあっても、他の相手と相互運用できなければなりません (MUST)。ただし、管理者が特定のPB-TNCメッセージタイプへの対応を必須にするよう構成できるようにしてもかまいません (MAY)。
Note that the PB-TNC Message Type field is completely separate from the PA Subtype field. The same value (e.g., 0) may have different meanings as a PB-TNC message type and as a PA subtype.
PB-TNC Message TypeフィールドはPA Subtypeフィールドとは完全に別のフィールドです。同じ値（たとえば0）でも、PB-TNCメッセージタイプとPAサブタイプでは意味が異なる場合があります。
PB-TNC Message Length (32 bits)
PB-TNC Message Length（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メッセージの長さをオクテット単位で示します。Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Lengthの各フィールドから成るヘッダーも長さに含みます。したがって、この値は常に12以上でなければなりません (MUST)。PB-TNC Message Lengthフィールドの値が12未満のメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
PB-TNC Message Value (variable length)
PB-TNC Message Value（可変長）
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 Vendor IDフィールドおよびPB-TNC Message Typeフィールドの値に応じて異なります。いくつかの標準メッセージの構文と意味は、本仕様の後続セクションで定義します。
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メッセージタイプはPB-TNC Vendor IDが0の場合に使います。異なるPB-TNC Vendor 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].
これらのメッセージタイプの詳細については、セクション4の後半を参照してください。PB-TNCメッセージタイプとはまったく異なるIETF標準PA Subtypeについては、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-Experimentalは、実験用に確保されたPB-TNCメッセージタイプ（値0）です。コードの試験など、実験目的で使用できます。製品や運用環境では使用してはなりません (MUST NOT)。このメッセージタイプの意味は、PB-TNC Message Header内のPB-TNC Vendor IDフィールドが0の場合に限り適用されます。そのフィールドのVendor IDが異なる場合、PB-TNC Message Type 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 Message LengthフィールドとPB-TNC Message Valueフィールドの内容は規定しません。実施する実験に応じて、ほぼ任意の値を設定できます。同様に、実験内容に応じて、このメッセージのFlagsフィールドでNOSKIPビットを設定またはクリアできます。ただし、PB-TNCメッセージの先頭にある固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）の合計が12オクテットであるため、PB-TNC Message Lengthは少なくとも12でなければなりません。無効な値のPB-TNC Message Lengthフィールドを含むメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
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.
製品で使うことを意図した姿勢ブローカークライアントまたは姿勢ブローカーサーバーの実装は、Vendor IDを0としたこのMessage Typeのメッセージを送信してはなりません (MUST NOT)。Vendor IDが0でこのMessage Typeのメッセージを受信した場合、NOSKIPビットが設定されていなければ、そのメッセージを無視しなければなりません (MUST)。NOSKIPビットが設定されている場合は、CLOSEバッチで致命的なUnsupported Mandatory Messageエラーコードを返さなければなりません (MUST)。
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メッセージが1つ含まれます。多くのバッチには複数の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メッセージタイプへの対応を実装しなければなりません (MUST)。通常は、内包された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 Message Vendor IDフィールドとPA Subtypeフィールドで示します。PA-TNC仕様 [10] では、同仕様に記載されたPA Message Vendor IDとPA Subtypeの値で識別できる標準PAメッセージタイプをいくつか定義しています。このセクションの後半でPA Subtypeフィールドの説明に記載するとおり、他の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 Message HeaderのNOSKIPフラグを設定しなければなりません (MUST)。NOSKIPフラグが設定されていないPB-PAメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、そのメッセージを無視しなければなりません (MUST)。さらに、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
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 Vendor IDフィールドを0にしなければならず (MUST)、PB-TNC Message Typeフィールドを1にしなければなりません (MUST)。PB-TNC Vendor IDフィールドが0以外の場合、メッセージタイプ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 Message Lengthフィールドには、PB-TNCメッセージ全体の長さを格納しなければなりません (MUST)。長さには、PB-TNCメッセージ先頭の固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）、以下に示す固定長フィールド（Flags、PA Message Vendor ID、PA Subtype、Posture Collector Identifier、Posture Validator Identifier）、およびPA Message Bodyを含みます。PA Message Bodyは可変長なので、PB-TNC Message Lengthの値も変わります。ただし、前述の固定長フィールドを含めるため、常に24以上でなければなりません (MUST)。無効な値のPB-TNC Message Lengthフィールドを含むPB-PAメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
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 Message Valueフィールドの形式と内容を示します。図の後で各フィールドを説明します。
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)
Flags（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.
このFlagsフィールドのビット0（最上位ビット）は、exclusiveを表すEXCLフラグです。EXCLビットがクリア（値0）の場合、このPB-TNCメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、同じPA Message Vendor IDとPA Subtypeを持つPAメッセージに関心を示したすべての姿勢収集器または姿勢検証器に、このPB-TNCメッセージ内のPAメッセージを配信すべきです (SHOULD)。EXCLフラグが設定（値1）されたメッセージを姿勢ブローカークライアントが受信した場合、Posture Collector Identifierフィールドで識別される姿勢収集器だけにPAメッセージを配信すべきです (SHOULD)。ただし、識別された姿勢収集器が該当するPA Message Vendor IDとPA Subtypeのメッセージに関心を示していなければ、その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つあり、姿勢検証器の修復指示がそのうち一方だけに適用される場合に対応できます。
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に設定し、受信時には無視しなければなりません (MUST)。
PA Message Vendor ID (24 bits)
PA Message Vendor 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 Message Vendor IDフィールドは、SMI Private Enterprise Number (PEN) を使ってベンダーを識別します。どの組織もInternet Assigned Numbers Authority (IANA) から固有のPENを取得できます。PA Message Vendor IDによってPA Subtypeフィールドを区別し、各ベンダーが2^32-1個の異なるPAサブタイプを使用できるようにします。IETF標準PAサブタイプでは、このフィールドのPA Message Vendor IDを常に0にします。PA Message Vendor ID 0xffffffは予約されています。姿勢ブローカークライアントと姿勢ブローカーサーバーは、PA Message Vendor IDフィールドに予約値0xffffffを持つメッセージを送信してはなりません (MUST NOT)。PA Message Vendor IDが予約値0xffffffのメッセージを受信した場合、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
PA Subtype (32 bits)
PA Subtype（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 Subtypeフィールドは、PA Message Bodyフィールドに含まれるPAメッセージのタイプを識別します。PA Subtype 0xffffffffは予約されています。姿勢ブローカークライアントと姿勢ブローカーサーバーは、PA Subtypeフィールドに予約値0xffffffffを持つメッセージを送信してはなりません (MUST NOT)。PA Subtypeが予約値0xffffffffのメッセージを受信した場合、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。また、姿勢ブローカークライアントと姿勢ブローカーサーバーは、同じPA SubtypeやPA Message Vendor IDを持つ複数のPAメッセージを1つのPB-TNCバッチに含められるようにしなければなりません (MUST)。
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 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).
IANAはPA Subtypeのレジストリを管理します。セクション6.1の指針に従い、Expert ReviewとSpecification Requiredの手続きでエントリーを追加します。本仕様ではPA Subtypeを定義しません。IETF標準PA Subtypeは、PA-TNC仕様 [10] やその他の仕様で定義されています。IETF標準PA Subtypeでは、PA Message Vendor 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 Subtype（PA Message Vendor IDが0以外のもの）は、IETFやIANAが関与しなくてもベンダーが定義して使用できます。ただし、姿勢ブローカークライアントと姿勢ブローカーサーバーは、特定のベンダー固有PA Subtypeへの対応を必須としてはなりません (MUST NOT)。また、対応するベンダー固有PA Subtypeの集合に違いがあっても、他の相手と相互運用できなければなりません (MUST)。ただし、管理者が特定のPA Subtypeへの対応を必須にするよう構成できるようにしてもかまいません (MAY)。
Note that the PB-TNC Message Type field is completely separate from the PA Subtype field. The same value (e.g., 0) may have different meanings as a PB-TNC message type and as a PA subtype.
PB-TNC Message TypeフィールドはPA Subtypeフィールドとは完全に別のフィールドです。同じ値（たとえば0）でも、PB-TNCメッセージタイプとPA Subtypeでは意味が異なる場合があります。
Posture Collector Identifier (16 bits)
Posture Collector Identifier（16ビット）
The Posture Collector Identifier field contains the identifier of the Posture Collector associated with this PA message.
Posture Collector Identifierフィールドには、この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つ以上のPosture Collector Identifier値（0xffffを除く）を割り当てます。単一の姿勢収集器が同じ種類のコンポーネントを複数扱う場合には、適切に対応付けるため複数の識別子が必要です。たとえば、単一のVPN姿勢収集器が2つのVPNクライアント実装を扱うエンドポイントが該当します。複数のPosture Collector Identifierの使い方を示す例については、PA-TNC仕様のセクション3.3を参照してください。姿勢ブローカークライアントが姿勢収集器に割り当てたPosture Collector Identifier値は、PTセッション中に変更してはなりません (MUST NOT)。この識別子は、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 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.
姿勢ブローカーサーバーがPAメッセージにEXCLフラグを設定する場合、PAメッセージの宛先となる姿勢収集器の識別子をPosture Collector Identifierフィールドに設定しなければなりません (MUST)。EXCLフラグが設定されていない場合でも、姿勢ブローカーサーバーは送信するPAメッセージにPosture Collector Identifier値を設定し、そのPAメッセージが指定された識別子に対応する姿勢収集器からのメッセージへの応答であることを示してもかまいません (MAY)。この方法で姿勢収集器を指定しない場合は、このフィールドを予約値0xffffに設定すべきです (SHOULD)。
Posture Validator Identifier (16 bits)
Posture Validator Identifier（16ビット）
The Posture Validator Identifier field contains the identifier of the Posture Validator associated with this PA message.
Posture Validator Identifierフィールドには、この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.
姿勢ブローカーサーバーは、メッセージ交換に関与する各姿勢検証器に一意のPosture Validator Identifier値（0xffffを除く）を割り当て、その検証器が送信するすべてのPAメッセージでこのフィールドに識別子を含めなければなりません (MUST)。姿勢ブローカーサーバーが姿勢検証器に割り当てたPosture Validator Identifier値は、PTセッション中に変更してはなりません (MUST NOT)。この識別子は、NEA交換中に姿勢ブローカーサーバー側のエンドポイントと通信する個々の姿勢検証器を識別します。また、姿勢収集器が必要に応じて特定の姿勢検証器に属性を送るために使います。
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メッセージの宛先となる姿勢検証器の識別子をPosture Validator Identifierフィールドに設定しなければなりません (MUST)。EXCLフラグが設定されていない場合でも、姿勢ブローカークライアントは送信するPAメッセージにPosture Validator Identifier値を設定し、そのPAメッセージが指定された識別子に対応する姿勢検証器からのメッセージへの応答であることを示してもかまいません (MAY)。この方法で姿勢検証器を指定しない場合は、このフィールドを予約値0xffffに設定すべきです (SHOULD)。
PA Message Body (variable length)
PA Message Body（可変長）
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 Message Bodyフィールドには、このPB-TNCメッセージが運ぶPAメッセージの本文を格納します。このフィールドの長さは、PB-TNC Message Lengthフィールドが示すメッセージ全体の長さから、PB-TNCメッセージ先頭の固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）と、PB-PAメッセージ先頭の固定長フィールド（Flags、PA Message Vendor ID、PA Subtype、Posture Collector Identifier、Posture Validator Identifier）の長さを差し引いて求められます。これらの固定長フィールドの合計は24オクテットです。したがって、PB-TNC Message Lengthフィールドの値が24未満のPB-PAメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
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-Assessment-Result（値2）というPB-TNCメッセージタイプは、エンドポイントの評価が完了した後、姿勢ブローカーサーバーが評価結果を通知するために使用します。姿勢ブローカーサーバーは通常、複数の姿勢検証器から受け取った個々の評価結果を集約して評価結果を算出します。PB層で評価結果を算出するアルゴリズムは実装に依存し、特定の導入環境のポリシーに応じて変わることもあります。姿勢ブローカーサーバーは、RESULTバッチにこのタイプのメッセージを1つ含めなければなりません (MUST)。また、ほかのタイプのバッチにはこのタイプのメッセージを含めてはなりません (MUST NOT)。姿勢ブローカークライアントは、このメッセージタイプのPB-TNCメッセージを送信してはなりません (MUST NOT)。姿勢ブローカーサーバーがこのメッセージタイプのPB-TNCメッセージを受信した場合、CLOSEバッチで致命的なInvalid Parameterエラーを返さなければなりません (MUST)。姿勢ブローカークライアントは、このメッセージを実装して処理しなければなりません (MUST)。また、RESULTタイプのバッチに含まれていないこのメッセージタイプのメッセージは無視しなければなりません (MUST)。
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 Message HeaderのNOSKIPフラグを設定しなければなりません (MUST)。PB-TNC Vendor IDフィールドには値0を格納しなければなりません (MUST)。PB-TNC Message Typeフィールドには値2を格納しなければなりません (MUST)。PB-TNC Vendor IDフィールドに0以外の値が格納されている場合、メッセージタイプ2は本仕様で定義されていない、まったく異なる意味になります。PB-TNC Message Lengthフィールドには値16を格納しなければなりません (MUST)。これは、PB-TNCメッセージ先頭の固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）の長さと、後述するAssessment Resultフィールドの長さの合計です。PB-Assessment-Resultメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、PB-TNC Message Lengthフィールドの値が16でない場合、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
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 Message Valueフィールドの形式と内容を示します。図の後では、ここに示す各フィールドについて説明します。
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
Assessment Result
This 32-bit field MUST contain one of the following values
この32ビットフィールドには、次のいずれかの値を格納しなければなりません (MUST)。
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つの値以外のAssessment Result値を受信した場合、CLOSEバッチで致命的なInvalid Parameterエラーを返さなければなりません (MUST)。PB-TNCの将来のバージョンでは、バージョン番号を変更する場合に限り、ほかの値を定義できます。したがって、Assessment Result値の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-Recommendation（値3）というPB-TNCメッセージタイプは、エンドポイントの評価がある程度完了した後、姿勢ブローカーサーバーがアクセス推奨を通知するために使用します。PB-Assessment-ResultとPB-Access-Recommendationの属性を合わせて、エンドポイントに対する全体的な評価判断を構成します。PB-Access-Recommendationに権威はなく、ネットワークおよびホストベースのアクセス制御システムは通常、追加情報を使ってエンドポイントに許可するネットワークアクセスを決定します。姿勢ブローカーサーバーは、RESULTタイプのバッチにこのタイプのメッセージを1つ含めてもかまいません (MAY)。また、ほかのタイプのバッチにはこのタイプのメッセージを含めてはなりません (MUST NOT)。姿勢ブローカークライアントは、このメッセージタイプのPB-TNCメッセージを送信してはなりません (MUST NOT)。姿勢ブローカーサーバーがこのメッセージタイプのPB-TNCメッセージを受信した場合、CLOSEバッチで致命的なInvalid Parameterエラーを返さなければなりません (MUST)。姿勢ブローカークライアントは、このメッセージを実装して処理しなければなりません (MUST)。また、RESULTタイプのバッチに含まれていないこのメッセージタイプのメッセージは無視しなければなりません (MUST)。
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 Message HeaderのNOSKIPフラグを設定してはなりません (MUST NOT)。NOSKIPフラグが設定されたPB-Access-Recommendationメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、そのメッセージを無視しなければなりません (MUST)。さらに、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。PB-TNC Vendor IDフィールドには値0を格納しなければなりません (MUST)。PB-TNC Message Typeフィールドには値3を格納しなければなりません (MUST)。PB-TNC Vendor IDフィールドに0以外の値が格納されている場合、メッセージタイプ3は本仕様で定義されていない、まったく異なる意味になります。PB-TNC Message Lengthフィールドには値16を格納しなければなりません (MUST)。これは、PB-TNCメッセージ先頭の固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）の長さと、後述するAccess Recommendationフィールドの長さの合計です。PB-Access-Recommendationメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、PB-TNC Message Lengthフィールドの値が16でない場合、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
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 Message Valueフィールドの形式と内容を示します。図の後では、ここに示す各フィールドについて説明します。
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)
Reserved（16ビット）
These Reserved bits MUST be set to 0 on transmission and ignored on reception.
これらのReservedビットは、送信時に0に設定し、受信時には無視しなければなりません (MUST)。
Access Recommendation Code (16 bits)
Access Recommendation Code（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.
Access Recommendation Codeフィールドは、現時点で姿勢ブローカーサーバーがこの姿勢ブローカークライアントに対して行ったアクセス推奨を示します。このフィールドには、次の3つの値のいずれかを設定しなければなりません (MUST)。1はAccess Allowed（全面的なアクセス）、2はAccess Denied（アクセスなし）、3はQuarantined（部分的なアクセス）を表します。姿勢ブローカークライアントがこの3つ以外のAccess Recommendation Code値を受信した場合、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。PB-TNCの将来のバージョンでは、バージョン番号を変更する場合に限り、ほかの値を定義できます。したがって、Access Recommendation Codeの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-Remediation-Parameters（値4）というPB-TNCメッセージタイプは、エンドポイントの評価がある程度完了した後、姿勢ブローカーサーバーが全体的な（姿勢検証器固有ではない）修復パラメーターを通知するために使用します。姿勢ブローカーサーバーは、任意のタイプのバッチにこのタイプのメッセージを1つ以上含めてもかまいません (MAY)。ただし、このメッセージタイプはRESULTタイプのバッチで最も有用です。
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メッセージを送信してはなりません (MUST NOT)。姿勢ブローカーサーバーがこのメッセージタイプのPB-TNCメッセージを受信した場合、CLOSEバッチで致命的なInvalid Parameterエラーを返さなければなりません (MUST)。姿勢ブローカークライアントは、このメッセージを実装して処理してもかまいませんが、必須ではありません。このメッセージをスキップしてもかまいません。姿勢ブローカークライアントがこのメッセージタイプを実装していても、それに基づいて動作する義務はありません。
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 Message HeaderのNOSKIPフラグを設定してはなりません (MUST NOT)。PB-TNC Vendor IDフィールドには値0を格納しなければなりません (MUST)。PB-TNC Message Typeフィールドには値4を格納しなければなりません (MUST)。PB-TNC Vendor IDフィールドに0以外の値が格納されている場合、メッセージタイプ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 Message Lengthフィールドには、PB-TNCメッセージ先頭の固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）、以下に示す固定長フィールド（Reserved、Remediation Parameters Vendor ID、Remediation Parameters Type）、およびRemediation Parametersを含む、PB-TNCメッセージ全体の長さを格納しなければなりません (MUST)。Remediation Parametersフィールドは可変長であるため、PB-TNC Message Lengthフィールドの値も変わります。ただし、前述の固定長フィールドを収めるため、値は常に20以上でなければなりません (MUST)。無効な値（たとえば20未満）が格納されたPB-TNC Message Lengthフィールドを持つPB-Remediation-Parametersメッセージを受信した姿勢ブローカークライアントは、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
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 Message Valueフィールドの形式と内容を示します。図の後では、ここに示す各フィールドについて説明します。
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)
Reserved（8ビット）
These Reserved bits MUST be set to 0 on transmission and ignored on reception.
これらのReservedビットは、送信時に0に設定し、受信時には無視しなければなりません (MUST)。
Remediation Parameters Vendor ID (24 bits)
Remediation Parameters Vendor 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.
Remediation Parameters Vendor IDフィールドは、SMI Private Enterprise Number（PEN）を使ってベンダーを識別します。どの組織も、Internet Assigned Numbers Authority（IANA）から固有のPENを取得できます。Remediation Parameters Vendor IDはRemediation Parameters Typeフィールドを修飾し、各ベンダーが使用できる2^32個の異なるRemediation Parameters Typeを提供します。IETFが標準化したRemediation Parameters Typeでは、このフィールドの値として常に0を使用します。
Remediation Parameters Type (32 bits)
Remediation Parameters Type（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.
Remediation Parameters Typeフィールドは、Remediation Parametersフィールドに含まれる修復パラメーターの種類を示します。姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、同じRemediation Parameters Typeおよび／または同じRemediation Parameters Vendor IDを持つ複数のRemediation Parametersメッセージが1つのPB-TNCバッチに含まれることをサポートしなければなりません (MUST)。
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 Remediation Parameters Typeのレジストリを管理します。このレジストリへの登録は、セクション6.1のガイドラインに従い、Specification RequiredポリシーのもとでExpert Reviewによって追加されます。この仕様で定義するIETF標準PB-TNC Remediation Parameters Typeの一覧は、このセクションの後半に示します。
New vendor-specific Remediation Parameters Types (those used with a non-zero Remediation Parameters vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific Remediation Parameters Types and MUST interoperate with other parties despite any differences in the set of vendor-specific Remediation Parameters Types supported (although they MAY permit administrators to configure them to require support for specific Remediation Parameters Types).
新しいベンダー固有のRemediation Parameters Type（Remediation Parameters Vendor IDが0以外の場合に使うもの）は、IETFやIANAの関与なしにベンダーが定義して使用できます。ただし、姿勢ブローカークライアントおよび姿勢ブローカーサーバーは、特定のベンダー固有Remediation Parameters Typeへの対応を必須としてはなりません (MUST NOT)。また、サポートするベンダー固有Remediation Parameters Typeの集合に違いがあっても、他の当事者と相互運用しなければなりません (MUST)。管理者が、特定のRemediation Parameters Typeへの対応を必須にするよう構成できるようにしてもかまいません (MAY)。
Note that the Remediation Parameters Type is completely separate from the PB-TNC Message Type and the PA Subtype fields. The same value (e.g., 0) may have different meanings in each of these fields.
Remediation Parameters Typeは、PB-TNC Message TypeフィールドおよびPA Subtypeフィールドとは完全に別のものです。同じ値（たとえば0）でも、これらの各フィールドでは意味が異なる場合があります。
Remediation Parameters (variable length)
Remediation Parameters（可変長）
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.
Remediation Parametersフィールドには、このPB-TNCメッセージが運ぶ実際の修復パラメーターが含まれます。このフィールドの長さは、PB-TNC Message Lengthフィールドに格納されたメッセージ長から、PB-TNCメッセージ先頭の固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）と、PB-Remediation-Parametersメッセージ先頭の固定長フィールド（Reserved、Remediation Parameters Vendor ID、Remediation Parameters Type）の長さを差し引いて求められます。これらの固定長フィールドの長さは合計20オクテットです。したがって、PB-TNC Message Lengthフィールドの値が20未満のPB-Remediation-Parametersメッセージを受信した姿勢ブローカークライアントは、そのメッセージを不正形式と見なさなければなりません (MUST)。姿勢ブローカークライアントは、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
This subsection defines several Remediation Parameters Types that have been standardized by the IETF.
この節では、IETFが標準化した複数のRemediation Parameters Typeを定義します。
Remediation-URI
Remediation-URI
This Remediation Parameters Type is employed by creating a PB-Remediation-Parameters message with a Remediation Parameters Vendor ID equal to the value zero (0) and a Remediation Parameters Type of 1. The Remediation Parameters field in the PB-Remediation-Parameters message MUST contain a URI, as described in RFC 3986 [2]. This URI contains instructions and resources for remediation. The Posture Broker Client MAY load the URI and display the resulting web page to the user. The Posture Broker Client MAY also ignore the URI or take another action with it. The Posture Broker Server and any other parties involved in configuring this remediation URI should consider the likely capabilities of the Posture Broker Client when creating the URI and the content referenced by the URI. For example, they should consider the Posture Broker Client's language preferences as expressed in the PB-Language-Preference message.
このRemediation Parameters Typeは、Remediation Parameters Vendor IDを0に、Remediation Parameters Typeを1に設定したPB-Remediation-Parametersメッセージを作成して使用します。PB-Remediation-ParametersメッセージのRemediation Parametersフィールドには、RFC 3986 [2]で説明されているURIを格納しなければなりません (MUST)。このURIには、修復のための手順とリソースが含まれます。姿勢ブローカークライアントは、URIを読み込み、表示されたウェブページをユーザーに提示してもかまいません (MAY)。URIを無視するか、別の方法で処理してもかまいません (MAY)。姿勢ブローカーサーバーおよびこの修復URIの設定に関わる他の当事者は、URIとその参照先コンテンツを作成する際、姿勢ブローカークライアントが備えている可能性の高い機能を考慮する必要があります。たとえば、PB-Language-Preferenceメッセージで示される姿勢ブローカークライアントの言語設定を考慮する必要があります。
Remediation-String
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.
このRemediation Parameters Typeは、Remediation Parameters Vendor IDを0に、Remediation Parameters Typeを2に設定したPB-Remediation-Parametersメッセージを作成して使用します。PB-Remediation-ParametersメッセージのRemediation Parametersフィールドには、以下に定義する構造を格納しなければなりません (MUST)。この構造には、人が読める修復手順が含まれます。
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.
姿勢ブローカークライアントは、この手順をユーザーに表示してもかまいません (MAY)。手順を無視するか、別の方法で処理してもかまいません (MAY)。姿勢ブローカーサーバーおよびこれらの手順の設定に関わる他の当事者は、手順を作成する際、姿勢ブローカークライアントが備えている可能性の高い機能を考慮する必要があります。たとえば、PB-Language-Preferenceメッセージで示される姿勢ブローカークライアントの言語設定を考慮する必要があります。
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.
次の図に、Remediation-Stringパラメーターを格納する場合のRemediation Parametersフィールドの形式と内容を示します。図の後では、ここに示す各フィールドについて説明します。
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)
Remediation String Length（32ビット）
The Remediation String Length contains the length of the Remediation String field in octets.
Remediation String Lengthには、Remediation Stringフィールドの長さをオクテット単位で格納します。
Remediation String (variable length)
Remediation String（可変長）
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 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.
Remediation Stringフィールドには、UTF-8 [6]でエンコードした文字列を格納しなければなりません (MUST)。この文字列には、人が読める修復手順が含まれ、姿勢ブローカークライアントがユーザーに表示してもかまいません (MAY)。NUL終端を含めてはなりません (MUST NOT)。NUL終端を含むReason Stringを受信した姿勢ブローカークライアントは、CLOSEバッチで致命的なInvalid Parameterエラーを返さなければなりません (MUST)。
Lang Code Len (8 bits)
Lang Code Len（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.
Lang Code Lenフィールドには、Remediation String Lang Codeフィールドの長さをオクテット単位で格納します。この値を0に設定して、Remediation Stringフィールドの言語コードが不明であることを示すことができます。
Remediation String Lang Code (variable length)
Remediation String Lang Code（可変長）
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.
Remediation String Lang Codeフィールドには、Remediation Parametersフィールド内のRemediation Stringで使用する言語を示す、正しい形式のRFC 4646 [3]言語タグからなるUS-ASCII文字列を格納します。このフィールドの言語コードが不明であることを示すため、このフィールドには長さ0の文字列を送信できます（実質的にこのフィールドを省略します）。
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-Error（値5）というPB-TNCメッセージタイプは、エラーが発生したことを示すため、姿勢ブローカークライアントまたは姿勢ブローカーサーバーが使用します。姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、任意のタイプのバッチにこのタイプのメッセージを1つ以上含めてもかまいません (MAY)。同じバッチには、ほかのメッセージも含められます。PB-Errorメッセージを受信した側は、適切と判断した場合、そのメッセージを記録するか、ほかの対応をしてもかまいません (MAY)。FATALフラグが設定されている（値1）場合、受信側はバッチを処理した後、応答メッセージを送信せずにPB-TNCセッションを終了しなければなりません (MUST)。すべての姿勢ブローカークライアントおよび姿勢ブローカーサーバーは、このメッセージタイプを実装しなければなりません (MUST)。
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 Message HeaderのNOSKIPフラグを設定しなければなりません (MUST)。PB-TNC Vendor IDフィールドには値0を格納しなければなりません (MUST)。PB-TNC Message Typeフィールドには値5を格納しなければなりません (MUST)。PB-TNC Vendor IDフィールドに0以外の値が格納されている場合、メッセージタイプ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 Message Lengthフィールドには、PB-TNCメッセージ先頭の固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）、以下に示す固定長フィールド（Flags、Error Code Vendor ID、Error Code、Reserved）、およびError Parametersを含む、PB-TNCメッセージ全体の長さを格納しなければなりません (MUST)。Error Parametersフィールドは可変長であるため、PB-TNC Message Lengthフィールドの値も変わります。
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以上でなければなりません (MUST)。無効な値（たとえば20未満）が格納されたPB-TNC Message Lengthフィールドを持つPB-Errorメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。PB-Errorメッセージの処理中に生成するPB-Errorメッセージは、エラーの無限ループが発生する可能性を避けるため、致命的なエラーでなければなりません (MUST)。
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 Message Valueフィールドの形式と内容を示します。図の後では、ここに示す各フィールドについて説明します。
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)
Flags（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.
このFlagsフィールドのビット0（最上位ビット）をFATALフラグと呼びます。FATALビットがクリアされている（値0）場合、このPB-TNCメッセージを受信した姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、このエラーを処理した後、交換を続けるべきです (SHOULD)。FATALフラグが設定されている（値1）場合、受信側はエラーを処理した後、交換を終了しなければなりません (MUST)。さらに、致命的なエラーを送信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、エラーの原因となったバッチを処理してはなりません (MUST NOT)。また、エラー報告を含むバッチを送信した後、交換を終了しなければなりません (MUST)。FATALフラグを設定したPB-Errorメッセージは、送信者がバッチ送信直後に交換を終了するため、必ずCLOSEバッチで送信しなければなりません (MUST)。
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に設定し、受信時には無視しなければなりません (MUST)。
Error Code Vendor ID (24 bits)
Error Code Vendor 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.
Error Code Vendor IDフィールドは、SMI Private Enterprise Number（PEN）を使ってベンダーを識別します。どの組織も、Internet Assigned Numbers Authority（IANA）から固有のPENを取得できます。Error Code Vendor IDはError Codeフィールドを修飾し、各ベンダーが使用できる2^16個の異なるError Codeを提供します。IETFが標準化したエラーコードでは、このフィールドの値として常に0を使用します。これらのメッセージの詳細については、後続の各節を参照してください。
Error Code (16 bits)
Error Code（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).
Error Codeフィールドは、このメッセージで通知するエラーの種類を示します。Error Parametersフィールドの形式は、Error Code Vendor IDとError Codeの値によって異なります。ただし、特定のエラーコードを理解できない受信者でも、FATALフラグでエラーが致命的かどうかを判断し、PB-TNC Message Lengthを使ってError Parametersフィールドを読み飛ばす（または記録する）ことで、エラーを適切に処理できます。
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 Error Codeのレジストリを管理します。このレジストリへの登録は、セクション6.1のガイドラインに従い、Specification RequiredポリシーのもとでExpert Reviewによって追加されます。この仕様で定義するIETF標準PB-TNC Error Codeの一覧は、後述のセクション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.
新しいベンダー固有のエラーコード（Error Code Vendor IDが0以外の場合に使うもの）は、IETFやIANAの関与なしにベンダーが定義して使用できます。未知のエラーコードを受信した姿勢ブローカークライアントおよび姿勢ブローカーサーバーは、そのエラーコードが致命的とマークされていない場合は無視または記録し、致命的とマークされている場合は交換を終了することで、適切に処理しなければなりません (MUST)。
Reserved (16 bits)
Reserved（16ビット）
The Reserved bits MUST be set to 0 on transmission and ignored on reception.
Reservedビットは、送信時に0に設定し、受信時には無視しなければなりません (MUST)。
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.
次のエラーコードはIETF標準PB-TNC Error Codeであるため、Error Code Vendor IDは値0でなければなりません (MUST)。次の表で16ビットのエラーコードを定義します。ベンダー固有のエラーコードは、Error Code Vendor IDに定義元ベンダーのSMI PENを設定し、Error Codeフィールドにそのベンダーが定義した任意のエラーコードを設定することで定義できます。Error Parametersフィールドの形式、長さ、意味は、Error Code Vendor IDとError Codeに応じて異なります。この文書の後続の各節では、本節で定義するIETF標準PB-TNC Error CodeのError Parametersについて、その形式、長さ、意味を定義します。
Error Code Definition
---------- ----------
0 Unexpected Batch Type. Error Parameters are empty.
1 Invalid Parameter. Error Parameters has offset where invalid value was found.
1 Invalid Parameter（無効なパラメーター）。Error Parametersには、無効な値が見つかった位置のオフセットを格納します。
2 Local Error. Error Parameters are empty.
2 Local Error（ローカルエラー）。Error Parametersは空です。
3 Unsupported Mandatory Message. Error Parameters has offset of offending PB-TNC Message
3 Unsupported Mandatory Message（未対応の必須メッセージ）。Error Parametersには、問題のあるPB-TNC Messageのオフセットを格納します。
4 Version Not Supported. Error Parameters has information about which versions are supported.
4 Version Not Supported（未対応のバージョン）。Error Parametersには、サポート対象バージョンに関する情報を格納します。
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 Error Codeについて、Error Parametersフィールドの形式、長さ、意味を定義します。
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.
IETF標準PB-TNC Error Code 0では、Error Parametersフィールドの長さは0です。このエラーコードではFATALフラグを設定しなければなりません (MUST)。
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.
IETF標準PB-TNC Error Code 1では、Error Parametersフィールドは次の構造になります。Offsetフィールドは、PB-TNCバッチの先頭から無効な値までのオフセットをオクテット単位で表します。このエラーコードでは、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.
IETF標準PB-TNC Error Code 2では、Error Parametersフィールドの長さは0です。このエラーコードではFATALフラグを設定しなければなりません (MUST)。
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.
IETF標準PB-TNC Error Code 3では、Error Parametersフィールドは次の構造になります。Offsetフィールドは、認識できなかったメッセージタイプを持つPB-TNCメッセージ（NOSKIPフラグが設定されていたもの）までの、PB-TNCバッチ先頭からのオフセットをオクテット単位で表します。このエラーコードではFATALフラグを設定しなければなりません (MUST)。
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 Error Code 4では、Error Parametersフィールドは次の構造になります。このエラーコードではFATALフラグを設定しなければなりません (MUST)。
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.
Bad Versionフィールドには、受信したもののサポートされていないバージョン番号を格納します。Max VersionフィールドとMin Versionフィールドは、エラーコードの送信者がサポートするPB-TNCのバージョン番号を示します。送信者は、Min VersionからMax Versionまで（両端を含む）のすべてのPB-TNCバージョンをサポートしなければなりません (MUST)。ただし、セクション4.1に記載されている予約済みバージョンは除きます。Reservedフィールドは、送信時に0に設定し、受信時には無視しなければなりません (MUST)。可能であれば、このエラーコードの受信者は、今後のメッセージをこのエラーの発生元である姿勢ブローカーサーバーまたは姿勢ブローカークライアントに対し、示された範囲内のPB-TNCバージョン番号で送信すべきです (SHOULD)。
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.
Version Not Supportedエラーコードを送信する当事者は、そのエラーコードだけを含むPB-TNCメッセージを、バージョン番号2のPB-TNC CLOSEバッチに含めなければなりません (MUST)。PB-TNCバッチを送信するすべての当事者は、PB-TNCバージョン2の他の機能を処理できない場合でも、この説明に合致するバッチを適切に処理できるべきです (SHOULD)。これにより、当事者が実装するPB-TNCのバージョンにかかわらず、PB-TNCのバージョン交渉を正しく進められます。
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).
PB-Language-Parameters（値6）というPB-TNCメッセージタイプは、姿勢ブローカークライアントが、送信される可能性のある人が読める文字列に希望する言語を示すために使用します。これにより、姿勢ブローカーサーバーと姿勢検証器は、姿勢ブローカークライアントの希望（おそらくエンドポイントのユーザーの言語設定によって決まります）に合わせて送信メッセージを調整できます。
The Posture Broker Server may also send this message type to the Posture Broker Client to indicate the Posture Broker Server's language preferences, but this is not very useful since the Posture Broker Client rarely sends human-readable strings to the Posture Broker Server and, if it does, rarely can adapt those strings to the preferences of the Posture Broker Server.
姿勢ブローカーサーバーも、自身の言語設定を示すため、このメッセージタイプを姿勢ブローカークライアントに送信できます。しかし、姿勢ブローカークライアントが姿勢ブローカーサーバーに人が読める文字列を送ることはまれであり、送る場合もサーバーの希望に合わせて文字列を調整できることはまれなので、あまり有用ではありません。
No Posture Broker Client or Posture Broker Server is required to send or implement this message type. However, a Posture Broker Server SHOULD attempt to adapt to user language preferences by implementing this message type, passing the language preference information to Posture Validators, and allowing administrators to configure human-readable languages in whatever languages are preferred by their users.
姿勢ブローカークライアントも姿勢ブローカーサーバーも、このメッセージタイプを送信または実装する義務はありません。ただし、姿勢ブローカーサーバーは、このメッセージタイプを実装し、言語設定情報を姿勢検証器に渡し、管理者がユーザーの希望する言語で人が読める文字列を設定できるようにすることで、ユーザーの言語設定に対応するよう努めるべきです (SHOULD)。
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セッションで最初に送信するバッチにこのメッセージを含めることが推奨されています。同じPB-TNCセッションでPB-Language-Parametersメッセージを受信した後、後続のバッチでもう1つ受信した場合、後のメッセージの値は、前のメッセージの値を置き換えるものとして扱うべきです。
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つのバッチにこのタイプのメッセージを複数含めてはなりません (MUST NOT)。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 Message HeaderのNOSKIPフラグを設定してはなりません (MUST NOT)。PB-TNC Vendor IDフィールドには値0を格納しなければなりません (MUST)。PB-TNC Message Typeフィールドには値6を格納しなければなりません (MUST)。PB-TNC Vendor IDフィールドに0以外の値が格納されている場合、メッセージタイプ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 Message Lengthフィールドには、PB-TNCメッセージ先頭の固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）とLanguage Preferenceフィールドを含む、PB-TNCメッセージ全体の長さを格納しなければなりません (MUST)。Language Preferenceフィールドは可変長であるため、PB-TNC Message Lengthフィールドの値も変わります。ただし、前述の固定長フィールドを収めるため、値は常に12以上でなければなりません (MUST)。
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 Message Valueフィールドの形式と内容を示します。図の後では、ここに示す各フィールドについて説明します。
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)
Language Preference（可変長）
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).
Language Preferenceフィールドには、RFC 3282 [4]で説明されているAccept-Languageヘッダーを格納します（同RFCに含まれるAccept-LanguageのRFC 2234 ABNF定義を使用し、US-ASCIIのみとし、制御文字、コメント、NUL終端を許可しません）。PB-Language-Preferenceメッセージを送信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、Language Preferenceフィールドがこの形式に適合することを確認しなければなりません (MUST)。たとえば、`Accept-Language: fr, en`は有効な値です（引用符を除く）。
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.
長さ0のLanguage Preferenceフィールドは、言語設定情報がないことを示します。これはPB-Language-Preferenceメッセージをまったく送信しない場合と同じなので、通常、長さ0のLanguage Preferenceフィールドを持つPB-Language-Preferenceメッセージを送信する必要はありません。ただし、以前のバッチで長さが0以外のLanguage Preferenceフィールドを持つPB-Language-Preferenceメッセージを送信した後、その設定が適用されなくなった場合は、長さ0のLanguage Preferenceフィールドを送信すると役立つことがあります。
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-Reason-String（値7）というPB-TNCメッセージタイプは、PB-Assessment-ResultおよびPB-Access-Recommendationメッセージが伝える全体的な評価判断について、人が読める説明を姿勢ブローカーサーバーが提供するために使用します。したがって、PB-Reason-Stringメッセージは、PB-Assessment-ResultメッセージおよびPB-Access-Recommendationメッセージと同じバッチにのみ含めるべきです (SHOULD)。姿勢ブローカークライアントは、PB-Reason-Stringメッセージを決して送信してはなりません (MUST NOT)。
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.
姿勢ブローカークライアントはこのメッセージタイプを実装する義務はなく、姿勢ブローカーサーバーも送信する義務はありません。ただし、エンドポイントが非適合と判断された理由にユーザーが関心を持つことが多いため、実装や送信には一定の利点があります。姿勢ブローカークライアントがこのフィールドをどう使うかは実装者に委ねられ、本仕様では定めません。姿勢ブローカークライアントは、本仕様の要件に反しない限り、メッセージをユーザーに表示したり、記録したり、無視したり、その他の対応をしたりしてもかまいません (MAY)。このメッセージの文字列は人が読むものなので、姿勢ブローカーサーバーは、このPB-TNCセッションで姿勢ブローカークライアントが送信したPB-Language-Preferenceメッセージに示される言語設定に合わせて調整すべきです (SHOULD)。
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.
姿勢ブローカーサーバーは、任意のタイプのバッチにこのタイプのメッセージを複数含めてもかまいません (MAY)。ただし、このメッセージをPB-Assessment-ResultメッセージおよびPB-Access-Recommendationメッセージと同じバッチに含めることが推奨されています。1つのバッチに複数のPB-Reason-Stringメッセージを含める場合、姿勢ブローカークライアントは、各メッセージの文字列が同じ意味を持つものとして扱うべきです (SHOULD)。これにより、姿勢ブローカーサーバーは同じ理由を異なる言語で複数返せます。姿勢ブローカーサーバーが姿勢ブローカークライアントの言語設定に対応できない場合に役立つことがあります。
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 Message HeaderのNOSKIPフラグを設定してはなりません (MUST NOT)。PB-TNC Vendor IDフィールドには値0を格納しなければなりません (MUST)。PB-TNC Message Typeフィールドには値7を格納しなければなりません (MUST)。PB-TNC Vendor IDフィールドに0以外の値が格納されている場合、メッセージタイプ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 Message Lengthフィールドには、PB-TNCメッセージ先頭の固定長フィールド（Flags、PB-TNC Vendor ID、PB-TNC Message Type、PB-TNC Message Length）、以下に示す固定長フィールド（Reason String Length、Lang Code Len）、Reason Stringフィールド、Reason String Language Codeフィールドを含む、PB-TNCメッセージ全体の長さを格納しなければなりません (MUST)。Reason StringフィールドとReason String Language Codeフィールドは可変長であるため、PB-TNC Message Lengthフィールドの値も変わります。ただし、前述の固定長フィールドを収めるため、値は常に17以上でなければなりません (MUST)。実際には、PB-TNC Message Lengthフィールドの値は、固定長フィールド分の17にReason String LengthフィールドとLang Code Lenフィールドの値を加えたものと正確に一致しなければなりません (MUST)。一致しない場合、受信側はCLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。
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 Message Valueフィールドの形式と内容を示します。図の後では、ここに示す各フィールドについて説明します。
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)
Reason String Length（32ビット）
The Reason String Length field contains the length of the Reason String field in octets.
Reason String Lengthフィールドには、Reason Stringフィールドの長さをオクテット単位で格納します。
Reason String (variable length)
Reason String（可変長）
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.
Reason Stringフィールドには、姿勢ブローカーサーバーの評価判断の理由を人が読める形で示すUTF-8エンコード文字列を格納します。NUL終端を含めてはなりません (MUST NOT)。NUL終端を含むReason Stringを受信した姿勢ブローカークライアントは、CLOSEバッチで致命的なInvalid Parameterエラーコードを返さなければなりません (MUST)。理由をまったく送信せず未指定のままにする場合と同じになるため、長さ0の文字列を送信してはなりません (MUST NOT)。
Lang Code Len (8 bits)
Lang Code Len（8ビット）
The Lang Code Len field contains the length of the Reason String Language Code field in octets.
Lang Code Lenフィールドには、Reason String Language Codeフィールドの長さをオクテット単位で格納します。
Reason String Language Code (variable length)
Reason String Language Code（可変長）
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.
Reason String Language Codeフィールドには、このメッセージのReason Stringで使用する言語を示す、正しい形式のRFC 4646 [3]言語タグを含むUS-ASCII文字列を格納します。このフィールドにNUL終端を含めてはなりません (MUST NOT)。理由文字列の言語コードが不明であることを示すため、このフィールドには長さ0の文字列を送信してもかまいません (MAY)（実質的にこのフィールドを省略します）。
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クライアントとNEAサーバーの間のネットワークにいる信頼されていない中継者は、PB-TNCを介して姿勢ブローカークライアントと姿勢ブローカーサーバーの間で送信されるデータの盗聴、転送中の改ざん、並べ替え、リプレイを試みる可能性があります。また、いずれかの当事者へのサービス拒否攻撃や、通信の早期切断を試みる可能性もあります。攻撃に成功すると、NEAクライアントに対する不適切な評価判断、状況が変化しても評価をやり直せないこと、不適切な修復指示のNEAクライアントへの送信（NEAクライアントの侵害につながる可能性があります）、NEAクライアントの健全性や識別情報に関する機密情報への不正アクセス、ユーザーに表示される不適切な理由文字列やその他のメッセージ、姿勢アサーションなど再利用可能な認証情報へのアクセス、NEAクライアントへのサービス拒否、さらにはネットワークへの完全なアクセス拒否につながる可能性があります（NEAサーバーへのサービス拒否攻撃が成功し、ネットワークアクセスの許可にNEAサーバーの承認が必要な場合）。
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が提供するセキュリティ保護を正しく実装する責任を負うため、信頼された当事者と見なされます。正しく実装できなければ、これらの保護は弱まるか、完全に失われる可能性があります。考えられる攻撃は前段落に挙げたものと同じです。十分に起こりそうな例を挙げると、姿勢トランスポートクライアントが姿勢トランスポートサーバーを適切に認証・認可できない場合（実装上の誤り、または「誰でも信頼する」というユーザー設定による場合）、認可が不適切な姿勢トランスポートサーバーは、前述の攻撃を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.
信頼された当事者（姿勢ブローカークライアント、姿勢トランスポートクライアント、姿勢ブローカーサーバー、姿勢トランスポートサーバー）のいずれかが侵害されると、第1段落に挙げたものと同等の障害が起こる可能性があります。これらの障害は、ネットワーク通信を監視したり、監査ログを調べて比較したりしても検出できないため、さらに危険な場合があります。姿勢ブローカークライアントと姿勢トランスポートクライアントの間、または姿勢ブローカーサーバーと姿勢トランスポートサーバーの間の通信を適切に保護できないことは、通常、それらの当事者の侵害と区別できません。NEAクライアントまたはNEAサーバーのOSや、その他の重要なソフトウェア、ファームウェア、ハードウェアコンポーネントが侵害された場合も、通常、同等の結果になります。また、攻撃者がNEAクライアントまたはNEAサーバーへの特権アクセスを得る能力も、一般に同等の脅威です。短時間であっても、その間にセキュリティ設定を無効化または誤設定できれば十分です。NEAクライアントまたはNEAサーバーが適切に動作するために他のサービス（姿勢収集器、姿勢検証器、ディレクトリ、パッチ管理サービスなど）に依存している場合、それらのサービスの侵害によって、依存する当事者も侵害されたり、動作不能になったりする可能性があります。もちろん、NEAサーバーのコンポーネントの侵害や障害が最も深刻です。多数のNEAクライアントに影響する可能性が高い一方、NEAクライアントの侵害の影響は1台に限られることがあるためです。
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.
前述のとおり、信頼された当事者の侵害や誤動作は、セキュリティに重大な影響を与えます。これには、姿勢ブローカークライアント、姿勢ブローカーサーバー、姿勢トランスポートクライアント、姿勢トランスポートサーバーが含まれます。これらはいずれもセキュリティ上重要なコンポーネントであるため、セキュリティ機器のベストプラクティスに従って構築・管理する必要があります。特にNEAサーバーとそのコンポーネントでは重要です。この機器が侵害されると、ネットワーク全体のセキュリティと可用性に影響するためです（AAAサーバーの侵害と同様です）。信頼された当事者間の通信も保護する必要があります。たとえば、姿勢ブローカーサーバーと姿勢トランスポートサーバーが別々のコンポーネントである場合、その間の通信を保護する必要があります。
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クライアントは、ノートPCや公衆電話のように物理的な保護がほとんどないモバイル機器の場合があるため、アクセスを試みるNEAクライアントの一部は侵害され、敵対的になっていると一般に想定する必要があります。NEAサーバーは、敵対的なNEAクライアントに対して堅牢になるよう設計する必要があります。侵害されたNEAクライアントを検出した後は、信頼されていない当事者と同様に扱うことができ、他の信頼されていない当事者より大きな脅威にならないようにする必要があります。
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サーバー、その構成要素および依存先には、安全な実装手法（セキュアコーディングや機能の最小化など）を用い、安全な運用手順（強力な認証や職務分離など）で管理する必要があります。検出のため、NEAサーバーの動作を監視し（修復指示の記録、侵入検知システム、有効なNEAクライアントになりすましてNEAサーバーの動作を記録するプローブなどを利用します）、異常を分析する必要があります。影響を緩和するため、NEAクライアントは信頼されたNEAサーバーから受信した修復指示に盲目的に従うべきではありません。少なくともパッチなどの危険な操作については、実行前に（ユーザーの確認などによって）妥当性を確認する必要があります。適切な認証と認可を行わずに、すべてのNEAサーバーを信頼するようNEAクライアントを設定できないようにする必要があります。
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.
本仕様では、PB-TNC Message Type、PA Subtype、PB-TNC Remediation Parameters Type、PB-TNC Error Codeの4つのIANAレジストリを新たに定義します。本節では、これらのレジストリの仕組みを説明します。
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 Message Typeを例にしますが、他の3つのレジストリも同様です。PB-TNC Message Typeがネットワーク上に現れる場合、ベンダーIDとも呼ばれるSMI Private Enterprise Number（PEN）が必ず付随します。ベンダーIDが0の場合、付随するPB-TNC Message TypeはPB-TNC Message TypeのIANAレジストリに登録されたIETF標準値であり、その意味は同レジストリでそのPB-TNC Message Typeに指定された仕様で定義されます。ベンダーIDが0以外の場合、PB-TNC Message Typeの意味は、そのベンダーIDで識別されるベンダーが定義します（SMI PENのIANAレジストリを参照）。識別されたベンダーには、そのベンダーIDとともに使用するPB-TNC Message Typeの一部またはすべてをIANAに登録し、各値の仕様を公開することが推奨されますが、義務ではありません。
This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require support for particular vendor-specific values. However, such behavior is explicitly prohibited by this specification, 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メッセージタイプへの対応を必須としてはなりません (MUST NOT)。サポートするベンダー固有PB-TNCメッセージタイプの集合に違いがあっても、他の当事者と相互運用しなければなりません (MUST)（ただし、管理者が特定のPB-TNCメッセージタイプへの対応を必須にするよう構成できるようにしてもかまいません (MAY)）。」PA Subtype、Remediation Parameters Type、PB-TNC Error Codeにも同様の要件があります。
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]で定義する指定専門家プロセスを用い、Specification RequiredポリシーのもとでExpert Reviewにより新しい値を追加します。
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個で、各ベンダーにも同数の値が割り当てられています。唯一の例外はPB-TNC Error Codeのレジストリで、IETF向けに2^16個、各ベンダー向けに2^16個の値があります。使用可能な値は非常に多いため、指定専門家は値の枯渇を過度に心配する必要はありません。
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レジストリのすべての値は、恒久的に公開される仕様で文書化されなければなりません (MUST)。IETF標準値は有用であり、インターネットに害を与えず、明確で相互運用性を確保できる可能性の高い方法で定義されなければなりません (MUST)。
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がコピーを保存して誰でも無料で利用できるようにすることを認めなければなりません (MUST)。
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 Message Types」です。各エントリには、人が読める名称、SMI Private Enterprise Number、0から2^32-2までの10進整数値、およびこのメッセージタイプの内容を定義する仕様への参照を含めるべきです。この仕様では、このPB-TNC Message Typeの意味と、PB-TNC Message Typeフィールドに指定数値を、PB-TNC Vendor IDフィールドに指定Private Enterprise Numberを格納したPB-TNCメッセージについて、PB-TNC Message Valueフィールドの形式とセマンティクスを定義すべきです。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリへのエントリは、セクション6.1のガイドラインに従い、Specification RequiredポリシーのもとでExpert Reviewによって追加します。
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 Message Typesレジストリの初期エントリです。
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 Subtypes」です。各エントリには、人が読める名称、SMI Private Enterprise Number、0から2^32-2までの10進整数値、およびこのPA Subtypeの内容を定義する仕様への参照を含めるべきです。この仕様では、PA Subtypeの意味と、PB-TNC Vendor IDが0、PB-TNC Message TypeがPB-PA、PA Subtypeフィールドに指定数値、PA Message Vendor IDフィールドに指定Private Enterprise Numberを格納したPB-TNCメッセージについて、PA Message Bodyフィールドの形式とセマンティクスを定義すべきです。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリへのエントリは、セクション6.1のガイドラインに従い、Specification RequiredポリシーのもとでExpert Reviewによって追加します。
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.
本書では、このレジストリの初期エントリを定義しません。したがって、初期状態では空にすべきです。後続のRFC（PA-TNCなど）で、このレジストリのエントリを定義します。
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 Remediation Parameters Types」です。各エントリには、人が読める名称、SMI Private Enterprise Number、0から2^32-1までの10進整数値、およびこのRemediation Parameters Typeの内容を定義する仕様への参照を含めるべきです。この仕様では、Remediation Parameters Typeの値の意味と、PB-TNC Vendor IDが0、PB-TNC Message TypeがPB-Remediation-Parameters、Remediation Parameters Typeフィールドに指定数値、Remediation Parameters Vendor IDフィールドに指定Private Enterprise Numberを格納したPB-TNCメッセージについて、Remediation Parametersフィールドの形式とセマンティクスを定義すべきです。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリへのエントリは、セクション6.1のガイドラインに従い、Specification RequiredポリシーのもとでExpert Reviewによって追加します。
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 Remediation Parameters Typesレジストリの初期エントリです。
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 Error Codes」です。各エントリには、人が読める名称、SMI Private Enterprise Number、0から2^16-1までの10進整数値、およびこのError Codeを定義する仕様への参照を含めるべきです。この仕様では、Error Codeの意味と、PB-TNC Vendor IDが0、PB-TNC Message TypeがPB-Error、Error Codeフィールドに指定数値、Error Code Vendor IDフィールドに指定Private Enterprise Numberを格納したPB-TNCメッセージについて、Error Parametersフィールドの形式とセマンティクスを定義すべきです。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリへのエントリは、セクション6.1のガイドラインに従い、Specification RequiredポリシーのもとでExpert Reviewによって追加します。
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 Error Codesレジストリの初期エントリです。
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.
本書の基となった初期テキストを提供してくださったTrusted Computing Groupに感謝します。
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.
本書の著者は、本書またはその前身の文書の作成に貢献した、または重要な意見を寄せた次の方々に謝意を表します: 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.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[3] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[3] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[4] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[4] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[7] Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV Binding", Trusted Computing Group, February 2008.
[7] Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV Binding", Trusted Computing Group, February 2008.
[8] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[8] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[9] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[9] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[10] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
[10] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
This scenario involves the assessment of an endpoint initiated during network join. The assessment is triggered by the Posture Broker Client (PBC) and involves collection of patch information from both Standard Operating System (OS) Posture Collector and vendor-specific Patch Posture Collector (PC). The assessment by both the vendor-specific Patch Posture Validator (PV) and Standard OS Posture Validator result in a compliant assessment decision that results in a compliant System Assessment Decision to be returned by the Posture Broker Server (PBS).
このシナリオでは、ネットワークへの参加時に開始するエンドポイント評価を扱います。評価は姿勢ブローカークライアント（PBC）が開始し、標準OS姿勢収集器とベンダー固有のパッチ姿勢収集器（PC）の両方からパッチ情報を収集します。ベンダー固有のパッチ姿勢検証器（PV）と標準OS姿勢検証器の双方による評価で適合との判断になり、その結果、姿勢ブローカーサーバー（PBS）は適合を示すSystem Assessment Decisionを返します。
+--------+ +-------+ +---------+ +--------+ +-------++--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----++---+---+
| | N/W Join| | | |
| | ----->| | | |
| | Req Post. | | | |
| +<----------+ | | |
| | Req Post. | | | |
+<--------------------| | | |
|Vndr X Patch Posture | | | |
|-------------------->| | | |
| |OS Posture | | | |
| |---------->| | | |
| | | Posture | | |
| | | Report | | |
| | +-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |---------> |
| | | | | Verify |
| | | | | Posture |
| | | |------------------->|
| | | | OS Reslt | |
| | | |<---------| |
| | | | VndrX Patch Result |
| | | Assess |<-------------------|
| | | Result | |
| | <---------| | |
| | OS PRslt | | | |
| |<----------| | | |
| VndrX Patch PResult | | | |
|<--------------------| | | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
この節では、このユースケースで交換する各PAメッセージの主要フィールドの内容を示します。特定のフィールドに示した値が入っている理由を説明するため、必要に応じて補足します。図示するフローの多くは同一システム内のコンポーネント間のやり取りであるため、メッセージ内容は示していません。
This flow represents the event that causes the PBC to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and doesn't include a message being sent.
このフローは、ネットワークへのアクセスを得るため、PBCがエンドポイントの評価を開始すると決定するきっかけとなるイベントを表します。これはイベントのみを表し、メッセージの送信は含みません。
This flow illustrates an invocation of the OS and Patch Posture Collectors requesting particular posture attributes to be sent. Because this use case is triggered locally, NEA doesn't specify the contents of this flow.
このフローは、OS姿勢収集器およびパッチ姿勢収集器を呼び出し、特定の姿勢属性を送信するよう要求する様子を示します。このユースケースはローカルで開始されるため、NEAではこのフローの内容を規定しません。
This flow contains the PA message from the Vendor X Patch Posture Collector; the message content is described in the PA-TNC specification.
このフローには、Vendor Xのパッチ姿勢収集器からのPAメッセージが含まれます。メッセージの内容はPA-TNC仕様で説明されています。
This flow contains the PA message from the OS Posture Collector; the message content is described in the PA-TNC specification.
このフローには、OS姿勢収集器からのPAメッセージが含まれます。メッセージの内容はPA-TNC仕様で説明されています。
This flow contains the PB message containing the PA messages from the Patch and OS Posture Collectors:
このフローには、パッチとOS姿勢コレクターからのPAメッセージを含むPBメッセージが含まれています。
PB Envelope {
PB Envelope {
HDR {
HDR {
D bit=0 (Posture Broker Client is originator)
D bit=0 (Posture Broker Client is originator)
Batch Type=CDATA
Batch Type=CDATA
Batch Length
Batch Length
}
}
PB Message 1 {
PB Message 1 {
Vendor-id=0
Vendor-id=0
Type =2 (PB-PA)
Type =2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=0 (Standard)
PA-Msg-vendor-id=0 (Standard)
PA-subtype=1 (OS) OS Posture PA Message
PA-subtype=1 (OS) OS Posture PA Message
}
}
}
}
PB Message 2 {
PB Message 2 {
Vendor-id=0
Vendor-id=0
Type =2 (PB-PA)
Type =2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=1 (Vendor X PA sub-type for patch management)
PA-subtype=1 (Vendor X PA sub-type for patch management)
Vendor X Patch Posture PA Message
Vendor X Patch Posture PA Message
}
}
}
}
}
}
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はメッセージコンテンツを指定しません。
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姿勢バリデーターからのPAメッセージ（姿勢評価結果）が含まれています。メッセージコンテンツは、PA-TNC仕様で説明されています。
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パッチPosure ValidatorからのPAメッセージ（姿勢評価結果）が含まれています。メッセージコンテンツは、PA-TNC仕様で説明されています。
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 Envelope {
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
D bit=1 (Posture Broker Server is originator)
Batch Type=RESULT
Batch Type=RESULT
Batch Length
Batch Length
}
}
PB Message 1 {
PB Message 1 {
Vendor-id=0,
Vendor-id=0,
Type =3 (Access-Recommendation)
Type =3 (Access-Recommendation)
Length
Length
Value = {
System-Evaluation-Result=0 (Compliant)
System-Evaluation-Result=0 (Compliant)
}
}
}
}
PB Message 2 {
PB Message 2 {
Vendor-id=0,
Vendor-id=0,
Type=2 (PB-PA)
Type=2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=0
PA-Msg-vendor-id=0
PA-subtype=1 (OS) OS Posture Result PA Message
PA-subtype=1 (OS) OS Posture Result PA Message
}
}
}
}
PB Message 3 {
PB Message 3 {
Vendor-id=0,
Vendor-id=0,
Type=2 (PB-PA)
Type=2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=1 (Vendor X PA sub-type for patch management)
PA-subtype=1 (Vendor X PA sub-type for patch management)
Vendor X Patch Posture Result PA Message
Vendor X Patch Posture Result PA Message
}
}
}
}
}
}
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はこのフローの内容を指定しません。
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つのウイルス対策コンポーネントから属性を収集します。ベンダーXのウイルス対策姿勢検証器はエンドポイントを適合と評価し、ベンダーYのウイルス対策姿勢検証器は不適合と評価します。その結果、姿勢ブローカーサーバーは不適合を示すSystem Assessment Decisionを返します。また、応答の一部としてエンドポイント向けの修復手順も返します。
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | ----->| | |
| | | | Create | |
| | | |Post. Req | |
| | | |--------->| |
| | | |Create Posture Req |
| | | |----------+--------->|
| | | |Vndr Y AV Posture Req|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post. Req | |
| | | Posture |<---------| |
| | | Request | | |
| | Vndr X AV |<--------| | |
| | Post. Req | | | |
| |<----------| | | |
| Vndr Y AV | | | |
| Posture Req | | | |
+<---------+-----------| | | |
| Vndr Y AV Posture | | | |
+----------+---------->| | | |
| | Vndr X AV | | | |
| | Posture | | | |
| |---------->| Posture | | |
| | |Response | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |--------->| |
| | | | Verify Posture |
| | | |----------+--------->|
| | | |Vndr Y Posture Result|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post Reslt| |
| | | Assess |<---------| |
| | | Result | | |
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
+<---------+-----------| | | |
| | | | | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
この節では、このユースケースで交換する各PAメッセージの主要フィールドの内容を示します。特定のフィールドに示した値が入っている理由を説明するため、必要に応じて補足します。図示するフローの多くは同一システム内のコンポーネント間のやり取りであるため、メッセージ内容は示していません。
This flow represents the event that causes the PBS to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and doesn't include a message being sent.
このフローは、ネットワークへのアクセスを得るため、PBSがエンドポイントの評価を開始すると決定するきっかけとなるイベントを表します。これはイベントのみを表し、メッセージの送信は含みません。
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.
このフローは、Vendor XおよびVendor Yのウイルス対策姿勢検証器を呼び出し、姿勢要求を作成するよう求める様子を示します。このユースケースはローカルで開始されるため、NEAではこのフローの内容を規定しません。
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.
このフローには、Vendor Xのウイルス対策姿勢検証器からのPAメッセージ（Posture Request）が含まれます。メッセージの内容はPA-TNC仕様で説明されています。
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.
このフローには、Vendor Yのウイルス対策姿勢検証器からのPAメッセージ（Posture Request）が含まれます。メッセージの内容はPA-TNC仕様で説明されています。
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators:
このフローには、Vendor XおよびVendor Yのウイルス対策姿勢検証器からのPAメッセージを含むPBメッセージが含まれます。
PB Envelope {
PB Envelope {
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
D bit=1 (Posture Broker Server is originator)
Batch Type=SDATA
Batch Type=SDATA
Batch Length
Batch Length
}
}
PB Message 1 {
PB Message 1 {
Vendor-id=0
Vendor-id=0
Type =2 (PB-PA)
Type =2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
Vendor X AV Posture Request PA Message
Vendor X AV Posture Request PA Message
}
}
}
}
PB Message 2 {
PB Message 2 {
Vendor-id=0
Vendor-id=0
Type =2 (PB-PA)
Type =2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA-Msg-vendor-id=2 (Vendor Y)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
Vendor Y AV Posture Request PA Message
Vendor Y AV Posture Request PA Message
}
}
}
}
}
}
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.
このフローは、姿勢要求を処理して要求された姿勢属性を返すために、Vendor XおよびVendor Yのウイルス対策姿勢収集器を呼び出す様子を示します。このユースケースはローカルで開始されるため、NEAではこのフローの内容を規定しません。
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.
このフローには、Vendor Yのウイルス対策姿勢収集器からのPAメッセージ（姿勢要求への応答）が含まれます。メッセージの内容はPA-TNC仕様で説明されています。
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.
このフローには、Vendor Xのウイルス対策姿勢収集器からのPAメッセージ（姿勢要求への応答）が含まれます。メッセージの内容はPA-TNC仕様で説明されています。
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Collectors:
このフローには、Vendor XおよびVendor Yのウイルス対策姿勢収集器からのPAメッセージを含むPBメッセージが含まれます。
PB Envelope {
PB Envelope {
HDR {
HDR {
D bit=0 (Posture Broker Client is originator)
D bit=0 (Posture Broker Client is originator)
Batch Type=CDATA
Batch Type=CDATA
Batch Length
Batch Length
}
}
PB Message 1 {
PB Message 1 {
Vendor-id=0
Vendor-id=0
Type =2 (PB-PA)
Type =2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
Vendor X AV Posture PA Message
Vendor X AV Posture PA Message
}
}
}
}
PB Message 2 {
PB Message 2 {
Vendor-id=0
Vendor-id=0
Type =2 (PB-PA)
Type =2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA-Msg-vendor-id=2 (Vendor Y)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
Vendor Y AV Posture PA Message
Vendor Y AV Posture PA Message
}
}
}
}
}
}
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.
このフローは、受信した姿勢属性の検証を求めるVendor XおよびVendor Yのウイルス対策姿勢検証器を呼び出す様子を示します。このフローはNEAサーバー内でローカルに発生するため、NEAではメッセージ内容を規定しません。
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.
このフローには、Vendor Yのウイルス対策姿勢検証器からのPAメッセージ（Posture Assessment Result）が含まれます。メッセージの内容はPA-TNC仕様で説明されています。
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.
このフローには、Vendor Xのウイルス対策姿勢検証器からのPAメッセージ（Posture Assessment Result）が含まれます。メッセージの内容はPA-TNC仕様で説明されています。
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 Envelope {
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
D bit=1 (Posture Broker Server is originator)
Batch Type=RESULT
Batch Type=RESULT
Batch Length
Batch Length
}
}
PB Message 1 {
PB Message 1 {
Vendor-id=0,
Vendor-id=0,
Type=3 (Access-Recommendation)
Type=3 (Access-Recommendation)
Length
Length
Value = {
PB-Assessment-Result=1 (Non-Compliant)
PB-Assessment-Result=1 (Non-Compliant)
}
}
}
}
PB Message 2 {
PB Message 2 {
Vendor-id=0,
Vendor-id=0,
Type=4 (Remediation-Parameters)
Type=4 (Remediation-Parameters)
Length
Value = {
Remediation-Param-Vendor-ID=0
Remediation-Param-Vendor-ID=0
Remediation-Param-Type=1 (Remediation-URI)
Remediation-Param-Type=1 (Remediation-URI)
Remediation-Param=''http://xyz''
Remediation-Param=''http://xyz''
}
}
}
}
PB Message 3 {
PB Message 3 {
Vendor-id=0,
Vendor-id=0,
Type=4 (Remediation-Parameters)
Type=4 (Remediation-Parameters)
Length
Length
Value = {
Remediation-Param-Vendor-ID=0
Remediation-Param-Vendor-ID=0
Remediation-Param-Type=2 (Remediation-String)
Remediation-Param-Type=2 (Remediation-String)
Remediation-Param=''Try Step1, Step2,...''
Remediation-Param=''Try Step1, Step2,...''
}
}
}
}
PB Message 4 {
PB Message 4 {
Vendor-id=0,
Vendor-id=0,
Type=2 (PB-PA)
Type=2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
Vendor X AV Posture Result PA Message
Vendor X AV Posture Result PA Message
}
}
}
}
PB Message 5 {
PB Message 5 {
Vendor-id=0,
Vendor-id=0,
Type=2 (PB-PA)
Type=2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA-Msg-vendor-id=2 (Vendor Y)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
Vendor Y AV Posture Result PA Message
Vendor Y AV Posture Result PA Message
}
}
}
}
}
}
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.
これらのフローは、姿勢評価結果を受け取るためにVendor XおよびVendor Yのウイルス対策姿勢収集器を呼び出す様子を示します。このユースケースはローカルで開始されるため、NEAではフローの内容を規定しません。
This scenario involves the reassessment of an endpoint as a result of enabling a software component on the endpoint. The endpoint has two VPN client software components, one from vendor X for the user's home network and other from vendor Y for the network that the endpoint is currently accessing. The assessment is triggered when the user tries to use the Vendor X VPN client; this is a violation of the 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.
このシナリオでは、エンドポイント上のソフトウェアコンポーネントを有効にしたことに伴う再評価を扱います。エンドポイントにはVPNクライアントソフトウェアが2つあります。1つはユーザーのホームネットワーク用のVendor X製、もう1つはエンドポイントが現在アクセスしているネットワーク用のVendor Y製です。ユーザーがVendor X VPNクライアントを使おうとすると評価が開始されますが、これは姿勢ポリシー違反です。エンドポイント上のVPNコンポーネントの動作状態が変わったという通知をStandard VPN Posture Collectorから受け取ると、姿勢ブローカークライアントが姿勢評価を開始します。VPN Posture Collectorは、標準属性に加えて、Vendor XとVendor Yの名前空間にある一部のベンダー定義属性にも対応します。このユースケースではベンダー定義属性を使用しません。Standard VPN Posture Validatorが標準VPN姿勢属性を検証し、不適合との評価結果を返します。このユースケースでは、PA-TNC仕様のセクション3.3で説明される仮想Posture Collectorの概念を使用します。この例のように、姿勢ブローカークライアントは単一のPosture Collector（Standard VPN PC）に2つのPosture Collector IDを割り当て、そのPosture CollectorはVendor XおよびVendor YのVPNクライアントの姿勢を報告するため、別々のPAメッセージを2つ生成します。姿勢ブローカークライアントは、NEAサーバーに送信するPBメッセージで割り当て済みIDを使用します。この動作はNEAサーバーから完全に見えず、NEAサーバーはNEAクライアント上にVPN Posture Collectorが2つあるかのようにPBメッセージを処理します。
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
---->| | | | | |
| VPN Status Change | | | |
|--------------------->| Posture | | |
| | | Change | | |
| | |-------->| | |
| | |Req. Post| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |VPNY Post| | |
| | |-------->| | |
| | | | Posture | |
| | | | Report | |
| | | |--------->| |
| | | | |Vrfy Post. |
| | | | |---------->|
| | | | |VPN PRslt |
| | | | Assess |<----------|
| | | | Result | |
| | | |<---------| |
| | |VPN PRslt| | |
| | |<--------| | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
この節では、このユースケースで交換する各PAメッセージの主要フィールドの内容を示します。特定のフィールドに示した値が入っている理由を説明するため、必要に応じて補足します。図示するフローの多くは同一システム内のコンポーネント間のやり取りであるため、メッセージ内容は示していません。
This flow represents the end user triggered event of starting the VPN Client software from Vendor X. This is merely an event and doesn't include a message being sent.
このフローは、エンドユーザーがVendor Xの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.
このフローは、Standard VPN Posture CollectorがVendor XのVPNクライアントソフトウェアのアクティブ状態を検出するイベントを表します。これはイベントのみを表し、メッセージの送信は含みません。
This flow represents the notification of the VPN Posture change sent from the VPN Posture Collector to the Standard Posture Broker Client. This is merely an event and doesn't include a message being sent.
このフローは、VPN Posture CollectorからStandard Posture Broker Clientに送信されるVPN姿勢の変化通知を表します。これはイベントのみを表し、メッセージの送信は含みません。
This flow illustrates an invocation of the VPN Posture Collector requesting particular posture attributes to be sent. Because this use case is triggered locally, the contents of this flow aren't specified by NEA.
このフローは、特定の姿勢属性を送信するようVPN Posture Collectorに要求する呼び出しを示します。このユースケースはローカルで開始されるため、NEAではこのフローの内容を規定しません。
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はメッセージの内容を指定しません。
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クライアント姿勢のVPN Posture CollectorからのPAメッセージが含まれています。メッセージコンテンツは、PA-TNC仕様で説明されています。
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クライアント姿勢のVPN Posure CollectorからのPAメッセージが含まれています。メッセージコンテンツは、PA-TNC仕様で説明されています。
This flow contains the PB message containing the PA message from the VPN Posture Collector:
このフローには、VPN姿勢コレクターからのPAメッセージを含むPBメッセージが含まれています。
PB Envelope {
PB Envelope {
HDR {
HDR {
D bit=0 (Posture Broker Client is originator)
D bit=0 (Posture Broker Client is originator)
Batch Type=CRETRY
Batch Type=CRETRY
Batch Length
Batch Length
}
}
PB Message 1 {
PB Message 1 {
Vendor-id=0
Vendor-id=0
Type =2 (PB-PA)
Type =2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=0
PA-Msg-vendor-id=0
PA-subtype=7 (VPN)
PA-subtype=7 (VPN)
Posture-Collector-ID=1 //Virtual Posture Collector ID for Vendor X VPN Client
Posture-Collector-ID=1 //Virtual Posture Collector ID for Vendor X VPN Client
Vendor X VPN Posture PA Message
Vendor X VPN Posture PA Message
}
}
}
}
PB Message 2 {
PB Message 2 {
Vendor-id=0
Vendor-id=0
Type =2 (PB-PA)
Type =2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=0
PA-Msg-vendor-id=0
PA-subtype=7 (VPN)
PA-subtype=7 (VPN)
Posture-Collector-ID=2 //Virtual Posture Collector ID for Vendor Y VPN Client
Posture-Collector-ID=2 //Virtual Posture Collector ID for Vendor Y VPN Client
Vendor Y VPN Posture PA Message
Vendor Y VPN Posture PA Message
}
}
}
}
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 Posture Validatorの呼び出しを示します。このフローはNEAサーバー内でローカルに発生するため、NEAではメッセージの内容を規定しません。
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 ValidatorからのPAメッセージ（Posture Assessment Result）が含まれます。メッセージの内容はPA-TNC仕様で説明されています。
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 ValidatorからのPAメッセージを含むPBメッセージが含まれます。
PB Envelope {
PB Envelope {
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
D bit=1 (Posture Broker Server is originator)
Batch Type=RESULT
Batch Type=RESULT
Batch Length
Batch Length
}
}
PB Message 1 {
PB Message 1 {
Vendor-id=0,
Vendor-id=0,
Type =3 (Access-Recommendation)
Type =3 (Access-Recommendation)
Length
Length
Value = {
PB-Assessment-Result=1 (Non-Compliant)
PB-Assessment-Result=1 (Non-Compliant)
}
}
} PB Message 2 {
} PB Message 2 {
Vendor-id=0,
Vendor-id=0,
Type=2 (PB-PA)
Type=2 (PB-PA)
Length
Length
Value = {
PA-Msg-vendor-id=0
PA-Msg-vendor-id=0
PA-subtype=7 (VPN)
PA-subtype=7 (VPN)
VPN Posture Result PA Message
VPN Posture Result PA Message
}
}
}
}
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 Posture Collectorを呼び出す様子を示します。このユースケースはローカルで開始されるため、NEAではこのフローの内容を規定しません。
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 Requirements文書で定義された要件に照らしてPB-TNCプロトコルを評価します。各項では、NEA Requirements文書の個別の要件を取り上げます。PBに適用されるのは共通要件（C-1〜C-11）とPB要件（PB-1〜PB-6）のみであるため、これらだけを評価します。
Requirement C-1 says:
要件C-1は次のとおりです。
C-1 NEA protocols MUST support multiple round trips between the NEA Client and NEA Server in a single assessment.
C-1 NEAプロトコルは、1回の評価中にNEAクライアントとNEAサーバー間の複数回の往復をサポートしなければなりません (MUST)。
PB-TNC meets this requirement. It allows an unlimited number of round trips between the NEA Client and NEA Server.
PB-TNCはこの要件を満たしています。NEAクライアントとNEAサーバー間で、回数に制限のない往復を可能にします。
Requirement C-2 says:
要件C-2は次のとおりです。
C-2 NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed.
C-2 NEAプロトコルは、必要に応じてNEAクライアントとNEAサーバーの双方が姿勢評価または再評価を開始する方法を提供すべきです (SHOULD)。
PB-TNC meets this requirement. Either the NEA Client or the NEA Server can initiate a posture assessment or reassessment.
PB-TNCはこの要件を満たしています。NEAクライアントまたはNEAサーバーのどちらからでも、姿勢評価または再評価を開始できます。
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サーバーがRESULTバッチを送信した後に再評価を開始する場合、基盤となるトランスポートセッションを終了し、新しい評価を開始する必要があります。半二重トランスポートでは、絶えずメッセージを交換し続けない限り、これは避けられません。そのような交換は非常に非効率です。全二重トランスポートであれば、Decided状態でも姿勢ブローカーサーバーがSRETRYバッチを送信できるようにすることは可能です。NEAワーキンググループがこの変更に合意すれば、変更されるでしょう。
Requirement C-3 says:
要件C-3は次のとおりです。
C-3 NEA protocols including security capabilities MUST be capable of protecting against active and passive attacks by intermediaries and endpoints including prevention from replay-based attacks.
C-3 セキュリティ機能を含むNEAプロトコルは、中継者およびエンドポイントによる能動的攻撃と受動的攻撃（リプレイ攻撃の防止を含みます）から保護できなければなりません (MUST)。
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はこの要件を満たしています。
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プロトコル上で動作できなければなりません (MUST)。たとえば、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はこの要件を満たしています。NEA Requirements文書で定めるPT要件を満たす任意のPTプロトコル上で動作できます。また、PB-TNCはPAプロトコルをPTプロトコル固有の事項から切り離します。PB-TNCを使うと、PAプロトコルから見てすべてのPTプロトコルが同等になります。
Requirement C-5 says:
要件C-5は次のとおりです。
C-5 The selection process for NEA protocols MUST evaluate and prefer the reuse of existing open standards that meet the requirements before defining new ones. The goal of NEA is not to create additional alternative protocols where acceptable solutions already exist.
C-5 NEAプロトコルの選定では、新たなものを定義する前に、要件を満たす既存のオープン標準を評価し、その再利用を優先しなければなりません (MUST)。許容できる解決策がすでにある場合に、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は、オープンなTCG仕様であるIF-TNCCS 2.0と同等です。IF-TNCCS 2.0は、数十のベンダーやオープンソースプロジェクトが実装してきた既存のIF-TNCCS 1.Xプロトコルを拡張したものです。
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プロトコルは高い拡張性を備えなければなりません (MUST)。多数のNEAクライアント上にある多くの姿勢収集器を、複数のNEAサーバーに配置された多数の姿勢検証器が評価できるようサポートしなければなりません (MUST)。
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個の姿勢収集器と同数の姿勢検証器をサポートします。また、NEAクライアントとNEAサーバーの数に制限はありません。
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は、他の面でも高い拡張性を備えます。たとえば、無制限の数のバッチをサポートし、各バッチには最大2^32-1オクテット、約2^24個のPAメッセージを含められます。各PAメッセージの長さは最大2^32-1オクテットです。もちろん、NEA評価でこれほど大量のデータを送信することは一般に推奨されませんが、ここで示す要点はPB-TNCの拡張性が高いことです。
Requirement C-7 says:
要件C-7は次のとおりです。
C-7 The protocols MUST support efficient transport of a large number of attribute messages between the NEA Client and the NEA Server.
C-7 これらのプロトコルは、多数の属性メッセージをNEAクライアントとNEAサーバー間で効率よく転送できなければなりません (MUST)。
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メッセージを含められます。セッション内で無制限の数のバッチをサポートするため、PTプロトコル、ユーザーの忍耐、その他の外部要因による制約を除けば、実際には無制限です。効率の面では、PB-TNCがPAメッセージごとに追加するオーバーヘッドは24オクテットだけです。PA-TNCでは1つのPAメッセージに多数の属性を含められるため、このオーバーヘッドはさらに小さくなります。
Requirement C-8 says:
要件C-8は次のとおりです。
C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links.
C-8 NEAプロトコルは、帯域幅が狭いリンクや遅延が大きいリンク上でも効率よく動作しなければなりません (MUST)。
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オクテットだけです。
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 ユーザーに表示する文字列について、プロトコルはユーザーの言語設定に合わせて文字列を調整できなければなりません (MUST)。
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.
PB-TNCはこの要件を満たしています。RFC 3282で定義され、広く実装されているAccept-Language形式を利用し、NEAクライアントとNEAサーバーが互いの言語設定を送信する標準的な方法を定義しています。
Requirement C-10 says:
要件C-10は次のとおりです。
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.
C-10 NEAプロトコルは、文字列をUTF-8形式でエンコードできなければなりません (MUST)。
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形式でエンコードされます。これにより、幅広い言語を効率よくサポートできます。
Requirement C-11 says:
要件C-11は次のとおりです。
C-11 Due to the potentially different transport characteristics provided by the underlying candidate PT protocols, the NEA Client and NEA Server MUST be capable of becoming aware of and adapting to the limitations of the available PT protocol. For example, some PT protocol characteristics that might impact the operation of PA and PB include restrictions on which end can initiate a NEA connection, maximum data size in a message or full assessment, upper bound on number of round trips, and ordering (duplex) of messages exchanged. The selection process for the PT protocols MUST consider the limitations the candidate PT protocol would impose upon the PA and PB protocols.
C-11 基盤となる候補PTプロトコルが提供するトランスポート特性はそれぞれ異なる可能性があるため、NEAクライアントとNEAサーバーは、利用可能なPTプロトコルの制約を認識し、それに適応できなければなりません (MUST)。たとえば、PAとPBの動作に影響し得るPTプロトコルの特性には、NEA接続を開始できる側の制限、メッセージまたは評価全体の最大データ量、往復回数の上限、交換するメッセージの順序（全二重か半二重か）があります。PTプロトコルの選定では、候補PTプロトコルがPAおよびPBプロトコルに課す制約を考慮しなければなりません (MUST)。
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はこの要件を満たしています。メッセージや評価のサイズ、往復回数、全二重／半二重に制約があるPTプロトコルを含め、さまざまな基盤PTプロトコルで動作できるよう設計されています。ローカルAPIを使えば、姿勢収集器や姿勢検証器は制約の少ない環境で動作していることを確認し、より詳細な属性を利用できます。同様に、ネットワーク接続の制約が非常に大きい場合、姿勢収集器は属性を送信しないか、より小さい属性（以前の評価で得たアサーションを含みます）を選んで送信できます。
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プロトコルは、姿勢ブローカーサーバーから姿勢ブローカークライアントへ属性を運べなければなりません (MUST)。これにより、姿勢ブローカークライアントは姿勢評価の判断を把握し、必要に応じてエンドポイント所有者への修復支援や通知を行えます。
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はこの要件を満たしています。姿勢ブローカークライアントから姿勢ブローカーサーバーへ、またその逆方向にも、回数に制限のない往復で属性を運べます。さらに、姿勢判断、修復支援、通知のための属性を明示的にサポートします。
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メッセージの内容を解釈してはなりません (MUST NOT)。つまり、運搬するデータはPBプロトコルにとって不透明でなければなりません。
PB-TNC meets this requirement. It does not parse or interpret PA messages in any way.
PB-TNCはこの要件を満たしています。PAメッセージを解析したり、何らかの形で解釈したりしません。
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メッセージをルーティング（配送）するために使用する、一意の識別子を運ばなければなりません (MUST)。このメッセージルーティングは、姿勢収集器と姿勢検証器の動的な登録や登録解除を容易にすべきです。たとえば、動的に登録されたウイルス対策姿勢検証器は、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はこの要件を満たしています。各PAメッセージにPA Subtypeを付け、姿勢ブローカーが適切な姿勢収集器や姿勢検証器にメッセージを配送できるようにします。メッセージの内容に応じてタグを付けることで、姿勢収集器や姿勢検証器を動的に登録・登録解除でき、各コンポーネントが適切なデータを受信できるようにします。PB-TNCは排他的配送にも対応しており、特定の姿勢収集器または姿勢検証器にメッセージを送れます。
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プロトコルに対応できなければなりません (MUST)。ただし、全二重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プロトコルの機能にかかわらず、常に半二重モードで動作します。理論上は、多数の往復や双方向のマルチメディア交換を必要とする評価が遅くなる可能性があります。しかし、実際のエンドポイント評価では通常、マルチメディアや多数の往復を必要としないため問題になりません。
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プロトコルは、姿勢ブローカークライアントと姿勢ブローカーサーバーの間で運ぶ属性メッセージに、認証、完全性、機密性の保護を提供してもかまいません (MAY)。これにより、姿勢ブローカークライアントと姿勢ブローカーサーバーの間で交換する属性メッセージ群からなる対話にセキュリティ保護を提供します。この保護はエンドツーエンドの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プロトコルスタックに第3のセキュリティ層を追加する利点はほとんどないようです。ただし、NEAワーキンググループがPBに認証、完全性保護、機密性保護への対応を含めると判断すれば、PA-TNCのセキュリティと同様の方法でPBに追加できます。 (SHOULD)
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プロトコルは、メッセージの転送を最適化し、往復回数を最小限にするため、属性メッセージをグループ化できなければなりません (MUST)。
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 meets this requirement. Multiple attribute messages can be conveyed in a single PA message. In fact, that's how PA-TNC works.
Authors' Addresses
著者の連絡先
Ravi Sahita Intel Corporation 2200 Mission College Blvd. Santa Clara, CA 95054 USA EMail: Ravi.Sahita@intel.com
Ravi Sahita Intel Corporation 2200 Mission College Blvd. Santa Clara, CA 95054 USA EMail: Ravi.Sahita@intel.com
Steve Hanna Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA EMail: shanna@juniper.net
Steve Hanna Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA EMail: shanna@juniper.net
Ryan Hurst Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: Ryan.Hurst@microsoft.com
Ryan Hurst Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: Ryan.Hurst@microsoft.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 USA EMail: kaushik@cisco.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 USA EMail: kaushik@cisco.com