[要約] RFC 5793は、Trusted Network Connect（TNC）と互換性のあるPosture Broker（PB）プロトコルであり、ネットワークポストチャーの評価と報告を提供します。このRFCの目的は、ネットワークセキュリティの向上と、異なるベンダー間での相互運用性の促進です。
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：信頼できるネットワークコネクト（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.
このドキュメントは、信頼できるコンピューティンググループのIF-TNCCS 2.0プロトコルと同一の姿勢ブローカープロトコルであるPB-TNCを指定しています。次に、このドキュメントは、NEA要件仕様で定義されている要件に対してPB-TNCを評価します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5793.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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および文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Terminology ................................................4
1.4. Conventions Used in This Document ..........................4
2. PB-TNC Design Considerations ....................................5
2.1. Message Addressing .........................................5
2.2. Vendor IDs .................................................7
2.3. Efficiency .................................................7
3. PB-TNC Protocol Description .....................................7
3.1. Protocol Overview ..........................................7
3.2. PB-TNC State Machine .......................................8
3.3. Layering on PT ............................................11
3.4. Example of PB-TNC Encapsulation ...........................12
4. PB-TNC Protocol Specification ..................................13
4.1. PB-TNC Header .............................................13
4.2. PB-TNC Message ............................................16
4.3. IETF Standard PB-TNC Message Types ........................19
4.4. PB-Experimental ...........................................19
4.5. PB-PA .....................................................20
4.6. PB-Assessment-Result ......................................25
4.7. PB-Access-Recommendation ..................................26
4.8. PB-Remediation-Parameters .................................28
4.9. PB-Error ..................................................32
4.10. PB-Language-Preference ...................................37
4.11. PB-Reason-String .........................................38
5. Security Considerations ........................................41
5.1. Threat Model ..............................................41
5.2. Countermeasures ...........................................42
6. IANA Considerations ............................................43
6.1. Designated Expert Guidelines ..............................44
6.2. Registry for PB-TNC Message Types .........................45
6.3. Registry for PA Subtypes ..................................45
6.4. Registry for PB-TNC Remediation Parameters Types ..........46
6.5. Registry for PB-TNC Error Codes ...........................46
7. Acknowledgments ................................................47
8. References .....................................................47
8.1. Normative References ......................................47
8.2. Informative References ....................................48
Appendix A. Use Cases .............................................49
A.1. Initial Client-Triggered Assessment .......................49
A.2. Server-Initiated Assessment with Remediation ..............54
A.3. Client-Triggered Reassessment .............................63
Appendix B. Evaluation against NEA Requirements ...................70
B.1. Evaluation against Requirement C-1 ........................70
B.2. Evaluation against Requirement C-2 ........................70
B.3. Evaluation against Requirement C-3 ........................70
B.4. Evaluation against Requirement C-4 ........................71
B.5. Evaluation against Requirement C-5 ........................71
B.6. Evaluation against Requirement C-6 ........................71
B.7. Evaluation against Requirement C-7 ........................72
B.8. Evaluation against Requirement C-8 ........................72
B.9. Evaluation against Requirement C-9 ........................72
B.10. Evaluation against Requirement C-10 ......................73
B.11. Evaluation against Requirement C-11 ......................73
B.12. Evaluation against Requirement PB-1 ......................74
B.13. Evaluation against Requirement PB-2 ......................74
B.14. Evaluation against Requirement PB-3 ......................74
B.15. Evaluation against Requirement PB-4 ......................75
B.16. Evaluation against Requirement PB-5 ......................75
B.17. Evaluation against Requirement PB-6 ......................76
This document specifies PB-TNC, a Posture Broker (PB) protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol [7]. The document then evaluates PB-TNC against the requirements defined in the Network Endpoint Assessment (NEA) Requirements specification [8].
このドキュメントは、信頼できるコンピューティンググループのIF-TNCCS 2.0プロトコル[7]と同じ姿勢ブローカー（PB）プロトコルであるPB-TNCを指定します。次に、このドキュメントは、ネットワークエンドポイント評価（NEA）要件仕様[8]で定義されている要件に対してPB-TNCを評価します。
This document does not define an architecture or reference model. Instead, it defines a protocol that works within the reference model described in the NEA Requirements specification [8]. The reader is assumed to be thoroughly familiar with that document. No familiarity with TCG specifications is assumed.
このドキュメントは、アーキテクチャまたは参照モデルを定義しません。代わりに、NEA要件仕様[8]で説明されている参照モデル内で機能するプロトコルを定義します。読者は、その文書に完全に精通していると想定されています。TCG仕様に精通していることは想定されていません。
This specification defines the syntax of PB-TNC messages using diagrams. Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits in each diagram as they are shown, traversing the diagram from top to bottom and then from left to right within each line (which represents a 32-bit quantity). Multi-byte fields representing numeric values must be sent in network (big endian) byte order.
この仕様は、図を使用してPB-TNCメッセージの構文を定義します。各図は、ビットの各フィールドの形式とサイズを示しています。実装は、表示されているときに各図にビットを送信する必要があり、上から下への図を通過し、次に各行内で左から右に通過します（32ビット量を表します）。数値を表すマルチバイトフィールドは、ネットワーク（ビッグエンディアン）バイト順序で送信する必要があります。
Descriptions of bit field (e.g., flag) values are described referring to the position of the bit within the field. These bit positions are numbered from the most significant bit through the least significant bit, so a 1-octet field with only bit 0 set has the value 0x80.
ビットフィールド（フラグ）値の説明は、フィールド内のビットの位置を参照しています。これらのビット位置は、最も重要なビットから最も重要なビットから番号が付けられているため、ビット0セットのみを持つ1オクテットのフィールドには値0x80があります。
This document reuses the terminology defined in the NEA Requirements document. One new term is defined in this section.
このドキュメントは、NEA要件文書で定義されている用語を再利用します。このセクションでは、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.
バッチ - 姿勢輸送（PT）プロトコルを一度に送信したPB -TNCメッセージのグループ。PB-TNCプロトコルは半分二重PTプロトコルで動作できる必要があるため、PB-TNCメッセージはバッチにグループ化されます。Posture Brokerクライアントは、1つのバッチをPositure Broker Serverに送信します。これは、バッチで応答します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
The primary purpose of the PB-TNC protocol is to carry Posture Attribute (PA) messages between Posture Collectors and Posture Validators. Also, PB-TNC must carry messages between the Posture Broker Client and the Posture Broker Server (known as PB-TNC messages) and manage the state of the assessment.
PB-TNCプロトコルの主な目的は、姿勢属性（PA）メッセージを姿勢コレクターと姿勢バリエーターの間に伝えることです。また、PB-TNCは、Posture BrokerクライアントとPossure Broker Server（PB-TNCメッセージとして知られている）の間にメッセージを伝達し、評価の状態を管理する必要があります。
The NEA Overview and Requirements document [8] describes in section 5.1.1.1 several ways that messages can be addressed and delivered to the proper Posture Collector(s) and Posture Validator(s). Of the techniques described in that section, PB-TNC supports dynamic identifiers and message types.
NEAの概要と要件のドキュメント[8]は、セクション5.1.1.1で、メッセージに対処し、適切な姿勢コレクターと姿勢バリエーターに配信できるいくつかの方法を説明しています。そのセクションで説明されている手法のうち、PB-TNCは動的識別子とメッセージタイプをサポートしています。
Message types are the simplest and most common way to handle message delivery. Each PA message sent via PB-TNC has an associated PA message type, composed of a PA Message Vendor ID and a PA subtype.
メッセージタイプは、メッセージ配信を処理する最も簡単で最も一般的な方法です。PB-TNCを介して送信される各PAメッセージには、PAメッセージベンダーIDとPAサブタイプで構成される関連するPAメッセージタイプがあります。
The PA-TNC specification [10] provides a list of IETF Standard PA Subtypes, which are used with a PA Message Vendor ID of 0. These include values such as Operating System and Anti-Virus, which are used for messages relating to operating system and anti-virus posture.
PA-TNC仕様[10]は、0のPAメッセージベンダーIDで使用されるIETF標準PAサブタイプのリストを提供します。これらには、オペレーティングシステムやアンチウイルスなどの値が含まれ、オペレーティングシステムに関連するメッセージに使用されます。アンチウイルスの姿勢。
Vendor-specific PA message types may be indicated by placing the defining vendor's Structure of Management Information (SMI) Private Enterprise Number into the PA Message Vendor ID field and a PA Subtype value assigned by that vendor in the PA Subtype field. This allows each vendor to define its own set of PA Subtype values without worrying about collisions with other vendors or with standard values.
ベンダー固有のPAメッセージタイプは、ベンダーの管理情報（SMI）の構造（SMI）の構造（PAメッセージベンダーIDフィールドに、PAサブタイプフィールドのベンダーが割り当てたPAサブタイプ値に配置することで示される場合があります。これにより、各ベンダーは、他のベンダーとの衝突や標準値を心配することなく、独自のPAサブタイプ値のセットを定義できます。
The PA message type is somewhat analogous to a MIME type in that it indicates the type of the PA message. Posture Collectors and Posture Validators can use local APIs to indicate to the Posture Broker Client and Posture Broker Server which PA message types they are interested in receiving. For instance, a Posture Validator that evaluates anti-virus posture might indicate that it would like to receive PA messages with a PA Message Vendor ID of 0 and a PA Subtype that matches the IETF Standard PA Subtype for Anti-Virus. It might also indicate interest in some vendor-specific PA message types to get additional vendor-specific information on anti-virus posture.
PAメッセージタイプは、PAメッセージのタイプを示すという点で、MIMEタイプに多少類似しています。姿勢コレクターと姿勢バリデーターは、ローカルAPIを使用して、姿勢ブローカークライアントと姿勢ブローカーサーバーに、受信に関心のあるPAメッセージタイプを示すことができます。たとえば、アンチウイルス姿勢を評価する姿勢バリエーターは、0のPAメッセージベンダーIDを使用してPAメッセージを受信し、アンチウイルスのIETF標準PAサブタイプと一致するPAサブタイプを受信したいことを示している可能性があります。また、一部のベンダー固有のPAメッセージタイプへの関心を示して、アンチウイルス姿勢に関するベンダー固有の追加情報を取得することもできます。
This type-based subscription model allows great flexibility in design and implementation. One Posture Validator may be responsible for evaluating several functions: anti-virus and host-based firewall, for instance. Posture Collectors do not need to know which Posture Validators are installed on the Posture Broker Server or what they handle. The Posture Collector simply sends PA messages with message types and the Posture Broker Server delivers them to the right Posture Validators.
このタイプベースのサブスクリプションモデルにより、設計と実装の柔軟性が非常に高くなります。たとえば、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.
Positure BrokerクライアントとPossure Broker ServerはPAメッセージベンダーIDおよびPAサブタイプフィールドにアクセスする必要があり、これらはPAメッセージの内容とは独立したルーティング識別子であるため、これらのフィールドはPAメッセージ内ではなくPB-TNCにあります。彼ら自身。
A similar type-based system is used to tag PB-TNC messages. In this case, the extensibility benefits are not as essential as with PA-TNC messages, but the ability to define IETF Standard PB-TNC Message Types and vendor-specific PB-TNC message types is still valuable.
同様のタイプベースのシステムを使用して、PB-TNCメッセージにタグ付けされます。この場合、拡張性の利点はPA-TNCメッセージほど重要ではありませんが、IETF標準PB-TNCメッセージタイプとベンダー固有のPB-TNCメッセージタイプを定義する機能は依然として価値があります。
The type-based message delivery model described above is not ideal for all circumstances. Sometimes it is important for a Posture Collector to deliver a message to a particular Posture Validator. For example, a particular Posture Validator might send a remediation message and the Posture Collector might need to send a response only to that one Posture Validator. To handle this circumstance, PB-TNC provides delivery based on dynamic identifiers.
上記のタイプベースのメッセージ配信モデルは、すべての状況に理想的ではありません。姿勢コレクターが特定の姿勢バリーターにメッセージを配信することが重要な場合があります。たとえば、特定の姿勢バリーターは修復メッセージを送信する場合があり、姿勢コレクターはその1つの姿勢バリーターにのみ応答を送信する必要があります。この状況を処理するために、PB-TNCは動的識別子に基づいて配信を提供します。
When a Posture Broker Server loads a Posture Validator, it assigns it a Posture Validator ID. Any PA messages sent by a Posture Validator include that Posture Validator's Posture Validator ID in the Posture Validator ID field of the PB-PA message. A Posture Collector that receives such a message can send a message in response and request exclusive delivery to the Posture Validator identified by that Posture Validator ID.
姿勢ブローカーサーバーがPossure Validatorをロードすると、Possure Validator IDを割り当てます。Posure Validatorによって送信されたPAメッセージには、PB-PAメッセージのPosure Validator IDフィールドにPosure ValidatorのPosture Validator IDが含まれています。そのようなメッセージを受信する姿勢コレクターは、その姿勢バリーターIDによって識別された姿勢検証装置への排他的配信を応答し、リクエストすることができます。
Dynamic identifiers avoid problems caused by the multicast nature of message types. Multiple Posture Collectors or Posture Validators may be registered for the same message type, and this can cause confusion if they all respond and the software designer did not consider that possibility. The dynamic identifier system allows more directed responses, but it does not work until at least one message has been received (so that the dynamic identifiers can be received). Static identifiers were considered as another alternative but rejected because they result in a brittle system that only works with a particular set of Posture Collectors and Posture Validators and causes problems if two Posture Collectors or Posture Validators with the same static identifier are installed.
動的識別子は、メッセージタイプのマルチキャストの性質によって引き起こされる問題を回避します。複数の姿勢コレクターまたは姿勢バリデーターが同じメッセージタイプに登録される場合があります。これは、それらがすべて応答し、ソフトウェアデザイナーがその可能性を考慮しなかった場合、混乱を引き起こす可能性があります。動的識別子システムにより、より指向性のある応答が可能になりますが、少なくとも1つのメッセージが受信されるまで機能しません（動的識別子を受信できるように）。静的識別子は別の代替手段と見なされましたが、特定の姿勢コレクターと姿勢検証装置のみで動作する脆性システムになり、同じ静的識別子を持つ2つの姿勢コレクターまたは姿勢検証装置がインストールされている場合、問題を引き起こすため、拒否されました。
In several places, PB-TNC needs to define a set of standard values but also allow vendor-specific extensions. In each of these places (PB-TNC Message Types, PA Subtypes, Remediation Parameters Types, and Error Codes), the solution chosen was to preface the values with a vendor ID. If a vendor ID is 0, the values in the next field are registered in an IANA registry and their meanings defined in an RFC. If a vendor ID is non-zero, the values in the next field are vendor specific and defined by the vendor whose SMI Private Enterprise Number matches the vendor ID. Vendor-specific messages that are not understood by the recipient are ignored and skipped unless they have the NOSKIP flag set, in which case an error code is returned.
いくつかの場所では、PB-TNCは一連の標準値を定義する必要がありますが、ベンダー固有の拡張機能も許可する必要があります。これらの各場所（PB-TNCメッセージタイプ、PAサブタイプ、修復パラメータータイプ、およびエラーコード）で、選択されたソリューションは、ベンダーIDで値を序文に序文であることでした。ベンダーIDが0の場合、次のフィールドの値はIANAレジストリに登録され、その意味はRFCで定義されます。ベンダーIDがゼロ以外の場合、次のフィールドの値はベンダー固有であり、SMIプライベートエンタープライズ番号がベンダーIDと一致するベンダーによって定義されます。受信者が理解していないベンダー固有のメッセージは、ノスキップフラグがセットされていない限り無視され、スキップされます。その場合、エラーコードが返されます。
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プロトコル：型長の価値構造を持つバイナリメッセージには、シンプルでコンパクトな形式が選択されました。
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プロトコルには、Posture BrokerクライアントとPossure Broker Serverの間に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.
半過剰PTプロトコル（EAP [9]に基づくものなど）を超えて機能するため、PB-TNCは半分二重プロトコル操作をサポートします。このモードでは、Positure BrokerクライアントとPossure Broker Serverが順番に、互いに単一のメッセージを送信します。PB-TNCの半分二重性の性質は、多くの往復や双方向のマルチメディア交換を必要とする交換を遅くする可能性がありますが、エンドポイントの評価には通常、マルチメディアや多数の往復が含まれないため、これは実際には問題ではありません。半過激なトランスポートを超える作業の利点は、課される制限を上回ります。
PB-TNC also supports full-duplex protocol operation so that PB-TNC exchanges can be re-initialized immediately when needed (e.g., if the Posture Broker Server policy changes or if the Posture Broker Client detects a suspicious event).
PB-TNCはまた、全二重プロトコル操作をサポートしているため、PB-TNC交換は必要に応じてすぐに再開できます（たとえば、姿勢ブローカーサーバーポリシーが変更された場合、または姿勢ブローカークライアントが疑わしいイベントを検出した場合）。
Each PB-TNC batch consists of a header followed by a sequence of PB-TNC messages. Each PB-TNC message has a Type-Length-Value (TLV) format with a few flags. The TLV format allows a recipient to skip messages that it does not understand. The TLV format also provides a standard way to mark messages as mandatory to ensure interoperability between a Posture Broker Client and a Posture Broker Server.
各PB-TNCバッチは、ヘッダーに続いてPB-TNCメッセージのシーケンスで構成されています。各PB-TNCメッセージには、いくつかのフラグを備えたタイプ長値（TLV）形式があります。TLV形式により、受信者は理解できないメッセージをスキップできます。TLV形式は、姿勢ブローカークライアントと姿勢ブローカーサーバーの間の相互運用性を確保するために、メッセージとしてメッセージを必須とマークする標準的な方法も提供します。
This specification defines certain standard PB-TNC message types. It also permits vendors to define their own vendor-specific message types. One of the most important standard PB-TNC message types is PB-PA. A message with this type contains a PA message and various message routing information. A Posture Broker Client or Posture Broker Server that receives such a message does not interpret the PA message within. Instead, it delivers the PA message to the appropriate set of Posture Collectors or Posture Validators, as determined using the message routing information contained in the PB-PA message.
この仕様では、特定の標準PB-TNCメッセージタイプを定義します。また、ベンダーが独自のベンダー固有のメッセージタイプを定義することもできます。最も重要な標準PB-TNCメッセージタイプの1つはPB-PAです。このタイプのメッセージには、PAメッセージとさまざまなメッセージルーティング情報が含まれています。そのようなメッセージを受信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、内部のPAメッセージを解釈しません。代わりに、PB-PAメッセージに含まれるメッセージルーティング情報を使用して決定されるように、適切な姿勢コレクターまたは姿勢バリデーターのセットにPAメッセージを配信します。
A Posture Broker Server will often need to communicate with several Posture Broker Clients at once. The reverse may also be true, as when an endpoint has multiple network interfaces connected to different networks. Each connection between a Posture Broker Server and a Posture Broker Client is instantiated as a separate PB-TNC session. There may be several simultaneous sessions between a single Posture Broker Server and Posture Broker Client, but this is unusual.
姿勢ブローカーサーバーは、多くの場合、いくつかの姿勢ブローカークライアントと一度に通信する必要があります。エンドポイントに異なるネットワークに接続されている複数のネットワークインターフェイスがある場合のため、逆も当てはまります。姿勢ブローカーサーバーと姿勢ブローカークライアントとの間の各接続は、個別の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.
この図では、状態は長方形の箱で示されています。初期状態と端子状態には二重の輪郭があります（= and "）。状態の遷移は、遷移の原因とマークされた一方向の矢印で示されます。
Many transitions (CDATA, SDATA, CRETRY, SRETRY, and RESULT) are triggered by the transmission or reception of a PB-TNC batch of a particular type. The type of a PB-TNC batch is indicated by the contents of the Batch Type field in the PB-TNC header for that batch. For brevity, this document says "a FOO batch" instead of "a PB-TNC batch whose Batch Type field contains FOO". Other transitions are triggered by receiving a PB-TNC batch of a particular type (e.g., Receive CRETRY). The CLOSE transition may be triggered by sending or receiving a CLOSE batch but may also be triggered by termination of the underlying PT connection.
多くの遷移（CDATA、SDATA、CRETRY、SRETRY、および結果）は、特定のタイプのPB-TNCバッチの送信または受信によって引き起こされます。PB-TNCバッチのタイプは、そのバッチのPB-TNCヘッダーのバッチタイプフィールドの内容によって示されます。簡潔にするために、このドキュメントでは、「バッチタイプのフィールドがFooが含まれているPB-TNCバッチ」の代わりに「Foo Batch」と書かれています。他の遷移は、特定のタイプのPB-TNCバッチを受信することによりトリガーされます（例：受信クレトリー）。緊密な遷移は、近接バッチを送信または受信することによりトリガーされる場合がありますが、基礎となる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状態で開始されます。Positure Brokerクライアントが基礎となる輸送セッションを開始した場合、CDATAバッチを姿勢ブローカーサーバーに送信し、サーバー作業状態に移行することから始まります。Positure Broker Serverがトランスポートセッションを開始した場合、SDATAのタイプSDATAのPB-TNCバッチを姿勢ブローカークライアントに送信し、クライアント作業状態に移行することから始まります。
The Posture Broker Client and Posture Broker Server may now alternate sending CDATA and SDATA batches to each other. Only the Posture Broker Client can send a data batch when the session is in the Client Working state, and only the Posture Broker Server can send a data batch when the session is in the Server Working state.
姿勢ブローカーのクライアントと姿勢ブローカーサーバーは、CDATAとSDATAバッチを互いに交互に送信することができます。セッションがクライアントの作業状態にあるときに姿勢ブローカークライアントのみがデータバッチを送信できます。また、セッションがサーバー作業状態にあるときに、Positure Brokerサーバーのみがデータバッチを送信できます。
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.
Exchangeを終了する最も一般的な方法は、Posture Broker Serverが結果バッチを送信することです。これにより、決定的な状態への移行が発生します。これは端末状態ではありません。PTセッションは開いたままであり、Posture BrokerクライアントにCretryバッチを送信させることで別の交換を開始できます。これは、姿勢ブローカーのクライアント（またはおそらく姿勢コレクター）がエンドポイントで疑わしい状態を発見した場合に役立ちます。基礎となる輸送プロトコル（PT）が全二重操作をサポートしている場合、姿勢ブローカーサーバーは、Stretryバッチを送信することにより、この状態から別の交換を開始することもできます。これは、たとえばサーバー上のポリシーが変更される場合に役立ちます。
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.
StretryまたはCretryメッセージが送信されるかどうかにかかわらず、次の状態はサーバー作業状態です。この状態から、姿勢ブローカーサーバーはSDATAバッチを送信し、新しい交換が開始されます。マークされた状態の遷移は、クレトリーを受信し、クレトリーまたは補償を受信することは、姿勢ブローカーのクライアントが姿勢ブローカーサーバーがsretryを送信することを決定したのとほぼ同じ時期にクレトリーメッセージを送信したときに、指定された状態でそのようなメッセージを受信することが許されることを示しています。。その場合、サーバーの動作またはクライアントの作業状態でクレトリーメッセージが受信される場合があります。また、サーバーの動作状態でsretryメッセージが受信される場合があります。これらのメッセージは冗長であり、したがって、州の変更を引き起こさない関連する遷移によって示されるように、無視されます。
The only terminal state is the End state. This state is reached if the underlying PT connection closes. This can be caused by an action of the Posture Broker Client or Posture Broker Server or it can be caused by some external factor, such as pulling the network plug. When possible, a CLOSE batch SHOULD be sent before the underlying PT connection is terminated. However, there may be cases where the PT connection is closed without notice. For example, a plug may be pulled, a software program may fail, or a Posture Broker Client or Posture Broker Server may be unable to send a CLOSE message due to half-duplex limitations in the underlying PT protocol. In these cases, the Posture Broker Client and Posture Broker Server will generally receive some form of notification from the Posture Transport Client and Posture Transport Server that the PT connection has been closed. This notification can trigger the CLOSE transition. However, the notification interaction is not standardized since the vertical interfaces in the NEA Reference Model are not standardized. In any case, the reception of the CLOSE batch or notification of termination of the transport causes the transition to the End state.
唯一の端子状態は最終状態です。基礎となるPT接続が閉じると、この状態に達します。これは、姿勢ブローカークライアントまたは姿勢ブローカーサーバーのアクションによって引き起こされる可能性があります。または、ネットワークプラグを引くなどの外部要因によって引き起こされる可能性があります。可能であれば、基礎となるPT接続が終了する前に、クローズバッチを送信する必要があります。ただし、PT接続が予告なく閉じられている場合があります。たとえば、プラグが引っ張られたり、ソフトウェアプログラムが故障したり、Posure BrokerクライアントまたはPossure Brokerサーバーが、基礎となるPTプロトコルの半分二重制限のために緊密なメッセージを送信できない場合があります。これらの場合、Positure BrokerクライアントとPossure Broker Serverは、一般に、PTの接続が閉じられているというPossure Transport ClientおよびPosture Transport Serverから何らかの通知を受け取ります。この通知は、緊密な遷移をトリガーする可能性があります。ただし、NEA参照モデルの垂直インターフェイスは標準化されていないため、通知相互作用は標準化されていません。いずれにせよ、閉鎖バッチの受信または輸送の終了の通知により、最終状態への移行が発生します。
Note that a Posture Broker Client and Posture Broker Server may not always have exactly the same state for a given PB-TNC session. For example, say that a session is in the Client Working state and the Posture Broker Client transmits a CDATA batch. While this batch is in transit (transmitted by the Posture Broker Client but not yet received by the Posture Broker Server), the Posture Broker Client will think that the session is in Server Working state but the Posture Broker Server will think that the session is in Client Working state. However, this is a temporary condition and does not cause problems in practice. The only possible issue is that a Posture Broker Client or Posture Broker Server does not know whether the other party has received its message until it receives a response from the other party.
姿勢ブローカーのクライアントと姿勢ブローカーサーバーは、特定のPB-TNCセッションに対して常にまったく同じ状態を持っているとは限らないことに注意してください。たとえば、セッションがクライアントの作業状態にあり、姿勢ブローカークライアントがCDATAバッチを送信するとします。このバッチはトランジット（Positure Brokerクライアントによって送信されますが、Poshipure Broker Serverがまだ受け取っていません）である間、Possure Brokerクライアントはセッションがサーバー作業状態にあると考えますが、Possure Broker Serverはセッションがあると考えるでしょうクライアント作業状態。ただし、これは一時的な状態であり、実際には問題を引き起こしません。唯一の可能な問題は、姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーが、相手から応答を受信するまで相手がメッセージを受け取ったかどうかを知らないことです。
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.
ハーフダップレックストランスポートが使用されている場合、Positure Brokerサーバーが最新のバッチ（結果バッチ）を送信し、これが半分に違反するため、セッションが決定状態にあるときに姿勢ブローカーサーバーがSTRETRYバッチを送信できないことに注意してください。輸送プロトコルの二重性。代わりに、半分二重輸送が使用されている場合に決定的な状態で新しい交換を開始したいサーバーは、近接バッチを送信せずにPT接続を閉じて、新しいPB-TNCセッションを開始する必要があります。この制限は、全二重輸送が使用されている場合は存在しません。
The Posture Broker Server and Posture Broker Client MUST follow the state machine described in this section.
姿勢ブローカーサーバーと姿勢ブローカーのクライアントは、このセクションで説明する状態マシンに従う必要があります。
PB-TNC batches are carried over protocol bindings of the PT protocol, which provides the interaction between a Posture Transport Client and a Posture Transport Server. PB-TNC counts on PT to provide a secure transport. In particular, PT MUST support mutual authentication of the Posture Transport Client and the Posture Transport Server, confidentiality and integrity protection for PB-TNC batches, and protection against replay attacks. PB-TNC is unaware of the underlying transport protocols being used. PB-TNC operates directly on PT; no further layer of PB-TNC is expected.
PB-TNCバッチは、PTプロトコルのプロトコルバインディングに掲載されており、Posture Transport ClientとPossure Transport Serverの相互作用を提供します。PB-TNCはPTをカウントして、安全な輸送を提供します。特に、PTは姿勢輸送クライアントと姿勢輸送サーバーの相互認証、PB-TNCバッチの機密性と整合性保護、およびリプレイ攻撃に対する保護をサポートする必要があります。PB-TNCは、基礎となる輸送プロトコルが使用されていることを認識していません。PB-TNCはPTで直接動作します。PB-TNCのそれ以上の層は予想されません。
RFC 5209 [8] describes normative requirements for the Posture Transport protocol. This section specifies additional requirements for the Posture Transport protocol. Candidate Posture Transport protocols must indicate conformance to requirements specified in this section as well as section 7.4 of RFC 5209.
RFC 5209 [8]は、姿勢輸送プロトコルの規範的要件を説明しています。このセクションでは、姿勢輸送プロトコルの追加要件を指定します。候補姿勢輸送プロトコルは、このセクションで指定された要件およびRFC 5209のセクション7.4への適合を示す必要があります。
The additional requirements for candidate PT protocols are:
候補PTプロトコルの追加要件は次のとおりです。
PT-6 The PT protocol MUST be connection oriented; it MUST support confirmed initiation and close down.
PT-6 PTプロトコルは接続指向でなければなりません。確認された開始と閉鎖をサポートする必要があります。
PT-7 The PT protocol MUST be able to carry binary data.
PT-7 PTプロトコルはバイナリデータを運ぶことができなければなりません。
PT-8 The PT protocol MUST provide mechanisms for flow control and congestion control.
PT-8 PTプロトコルは、フロー制御と輻輳制御のメカニズムを提供する必要があります。
PT-9 PT protocol specifications MUST describe the capabilities that they provide for and limitations that they impose on the PB protocol (e.g., half/full duplex, maximum message size).
PT-9 PTプロトコル仕様は、提供する機能とPBプロトコルに課す制限（例：半分/完全なデュプレックス、最大メッセージサイズ）を記述する必要があります。
This section shows how PA messages can be carried inside a PB-TNC batch that is inside a PT protocol.
このセクションでは、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ヘッダーが次にパッケージ化され、その後、プラットフォーム上のPosure CollectorsとPosuture Validatorを対象としたPAメッセージを含む2つのPB-PAメッセージが続きます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example of PB-TNC message encapsulation
図2：PB-TNCメッセージカプセル化の例
This figure is conceptual, of course, and not an exact byte-for-byte replica.
もちろん、この図は概念的なものであり、正確なバイトバイトレプリカではありません。
This section defines the syntax and semantics of the PB-TNC protocol fields. If a Posture Broker Client or Posture Broker Server receives a batch that violates the requirements of this specification, it MUST respond by sending a fatal Invalid Parameter error in a CLOSE batch unless this document specifies otherwise.
このセクションでは、PB-TNCプロトコルフィールドの構文とセマンティクスを定義します。姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーがこの仕様の要件に違反するバッチを受け取った場合、このドキュメントが特に指定しない限り、致命的な無効なパラメーターエラーをクローズバッチで送信することで応答する必要があります。
Every PB-TNC batch MUST start with the following header. A PB-TNC batch MUST contain only one instance of this header followed by zero or more PB-TNC messages. The PB-TNC messages are defined in subsequent sections of this specification.
すべてのPB-TNCバッチは、次のヘッダーから開始する必要があります。PB-TNCバッチには、このヘッダーの1つのインスタンスのみがゼロ以上のPB-TNCメッセージのみを含める必要があります。PB-TNCメッセージは、この仕様の後続のセクションで定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |D| Reserved | B-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (8 bits)
バージョン（8ビット）
This field indicates the version of the format for the PB-TNC message. This version is intended to allow for evolution of the PB-TNC protocol in a manner that can easily be detected by message recipients.
このフィールドは、PB-TNCメッセージの形式のバージョンを示します。このバージョンは、メッセージ受信者が簡単に検出できる方法でPB-TNCプロトコルの進化を可能にすることを目的としています。
This field MUST be set to 2 when the batch conforms to this specification. Later versions of PB-TNC may define other values for this field. The values 0x00, 0x09, 0x0a, 0x0d, 0x20, and 0x3c are reserved and cannot be used for any version of PB-TNC to ensure that PB-TNC can be easily distinguished from earlier posture broker protocols already in use.
バッチがこの仕様に準拠している場合、このフィールドは2に設定する必要があります。PB-TNCの後のバージョンは、このフィールドの他の値を定義する場合があります。値0x00、0x09、0x0a、0x0d、0x20、および0x3cは予約されており、PB-TNCのどのバージョンにも使用できないため、PB-TNCがすでに使用されている以前の姿勢ブローカープロトコルと簡単に区別できるようにします。
If a Posture Broker Client or Posture Broker Server receives a Version value that it does not support, it MUST respond with a PB-TNC batch with batch type CLOSE that contains only a fatal Version Not Supported error code and whose Version header field has the value 2. Implementations responding to a PB-TNC message containing a supported version MUST use the same Version number to minimize the risk of version incompatibility. PB-TNC message initiators that support multiple PB-TNC protocol versions SHOULD be able to alter which version of PB-TNC message they send based on prior message exchanges with a particular peer Posture Broker Client or Posture Broker Server.
姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーがサポートしていないバージョン値を受信した場合、サポートされていないエラーコードとそのバージョンヘッダーフィールドに値がある致命的なバージョンのみを含むバッチタイプのクローズを持つPB-TNCバッチで応答する必要があります2.サポートされているバージョンを含むPB-TNCメッセージに応答する実装は、同じバージョン番号を使用して、バージョンの互換性のリスクを最小限に抑える必要があります。複数のPB-TNCプロトコルバージョンをサポートするPB-TNCメッセージイニシエーターは、特定のピア姿勢ブローカークライアントまたは姿勢ブローカーサーバーとの以前のメッセージ交換に基づいて送信するPB-TNCメッセージのバージョンを変更できるはずです。
Directionality (D) (1 bit)
方向性（d）（1ビット）
When a Posture Broker Client is sending this message, the Directionality bit MUST be set to 0. When a Posture Broker Server is sending this message, the Directionality bit MUST be set to 1. This helps avoid any situation where two Posture Broker Clients or two Posture Broker Servers engage in a dialog. It also helps with debugging.
姿勢ブローカークライアントがこのメッセージを送信している場合、方向性ビットを0に設定する必要があります。PositureBrokerサーバーがこのメッセージを送信する場合、方向性ビットは1に設定する必要があります。姿勢ブローカーサーバーはダイアログに参加します。また、デバッグにも役立ちます。
Reserved (19 bits)
予約済み（19ビット）
This field is reserved. For this version of this specification, it MUST be set to 0 on transmission and ignored on reception. Future versions of this specification may allow senders to set some of these bits and recipients to interpret them.
このフィールドは予約されています。この仕様のこのバージョンでは、送信時に0に設定し、受信で無視する必要があります。この仕様の将来のバージョンにより、送信者はこれらのビットと受信者の一部を設定してそれらを解釈することができます。
B-Type (Batch Type) (4 bits)
Bタイプ（バッチタイプ）（4ビット）
This field is used to drive the state machine described in section 3.2. This field MUST have one of the values from the following table. If any other value is received, the recipient MUST ignore the contents of the batch and send a fatal Invalid Parameter error code in a CLOSE batch. If the value received is not permitted for the current state, according to the state machine in section 3.2., the recipient MUST ignore the contents of the batch and send a fatal Unexpected Batch Type error code in a CLOSE batch.
このフィールドは、セクション3.2で説明されている状態マシンを駆動するために使用されます。このフィールドには、次の表の値の1つが必要です。他の値が受信された場合、受信者はバッチの内容を無視し、致命的な無効なパラメーターエラーコードをクローズバッチに送信する必要があります。セクション3.2の状態マシンによると、受信した値が現在の状態で許可されていない場合、受信者はバッチの内容を無視し、致命的な予期しないバッチタイプエラーコードをクローズバッチに送信する必要があります。
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 Positure Brokerクライアントは、このバッチタイプでバッチを送信して、姿勢ブローカーサーバーにメッセージを伝えることができます。姿勢ブローカーサーバーは、このバッチタイプを送信してはなりません。Posture Brokerクライアントに送信するものがない場合、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 Positure Broker Serverは、このバッチタイプでバッチを送信して、姿勢ブローカークライアントにメッセージを伝えることができます。姿勢ブローカークライアントは、このバッチタイプを送信してはなりません。Posture Broker Serverに送信するものがない場合、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結果Positure Broker Serverは、このバッチタイプのバッチを送信して、評価が完了したことを示します。バッチには、PBアセスメント応答メッセージを含める必要があり、PB-Access-Cremendationメッセージが含まれる場合があります。
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 Positure Brokerクライアントは、このバッチタイプでバッチを送信して、交換を再開したいことを示す場合があります。姿勢ブローカーサーバーは、このバッチタイプを送信してはなりません。Posture Brokerクライアントが他に送信するものがない場合、クレトリーバッチは空になる可能性があります（メッセージが含まれていません）。
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 Stretry Positure Broker Serverは、このバッチタイプでバッチを送信して、交換を再起動したいことを示す場合があります。姿勢ブローカークライアントは、このバッチタイプを送信してはなりません。Posture Broker Serverに送信するものがない場合、Stretryバッチは空になる可能性があります（メッセージが含まれていません）。
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 Positure Broker ServerまたはPossure Brokerクライアントの閉鎖は、このバッチタイプでバッチを送信して、基礎となるPT接続を終了しようとしていることを示します。送信するものがない場合、クローズバッチは空になっている場合があります（メッセージが含まれていません）。ただし、終了が致命的なエラーによるものである場合、クローズバッチにはPB-errorメッセージが含まれている必要があります。
Batch Length (32 bits)
バッチ長（32ビット）
This length field contains the size of the full PB-TNC batch in octets. This length includes the PB-TNC header and all the PB-TNC messages in the batch. In other words, it includes the entire contents of the batch. This field MUST contain at least the value 8 for the fixed-length fields in this header. Any Posture Broker Client or Posture Broker Server that receives a PB-TNC message with a PB-TNC Message Length field whose value is less than 8 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
この長さフィールドには、オクテットの完全なPB-TNCバッチのサイズが含まれています。この長さには、PB-TNCヘッダーとバッチ内のすべてのPB-TNCメッセージが含まれます。つまり、バッチの内容全体が含まれます。このフィールドには、このヘッダーの固定長フィールドに少なくとも値8が含まれている必要があります。値が8未満のPB-TNCメッセージ長さフィールドを使用してPB-TNCメッセージを受信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、致命的な無効なパラメーターエラーコードをクローズバッチで応答する必要があります。
All PB-TNC messages have the same overall structure, which is described in this section. Of course, the format and semantics of the PB-TNC Message Value field will vary, depending on the values of the PB-TNC Vendor ID and PB-TNC Message Type fields.
すべてのPB-TNCメッセージには、このセクションで説明されている全体的な構造が同じです。もちろん、PB-TNCベンダーIDとPB-TNCメッセージタイプフィールドの値によって、PB-TNCメッセージ値フィールドの形式とセマンティクスは異なります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PB-TNC Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
フラグ（8ビット）
This field defines flags impacting the processing of this message.
このフィールドは、このメッセージの処理に影響を与えるフラグを定義します。
Bit 0 of this Flags field (the most significant bit) is known as the NOSKIP flag. If this flag is cleared (value 0), then the recipient (a Posture Broker Client or Posture Broker Server) may skip (ignore) this message if the message type is not understood or the recipient cannot or will not process the message as required in the definition of that message. If this flag is set (value 1), then recipients MUST NOT skip this attribute.
このフラグフィールドのビット0（最も重要なビット）は、Noskipフラグとして知られています。このフラグがクリアされている場合（値0）、受信者（姿勢ブローカークライアントまたは姿勢ブローカーサーバー）は、メッセージタイプが理解されていない場合、または受信者が必要に応じてメッセージを処理できない場合または処理できない場合、このメッセージをスキップ（無視）できます。そのメッセージの定義。このフラグが設定されている場合（値1）、受信者はこの属性をスキップしてはなりません。
This flag does not mean that all recipients must support this message. Instead, any recipient that receives a message with this flag set to 1 but cannot or will not process it as required MUST NOT act on any part of the PB-TNC batch. Instead, the recipient MUST respond with a fatal Unsupported Mandatory Message error code in a CLOSE batch. In order to avoid taking action on some messages in a batch only to later find an unsupported NOSKIP flagged message, recipients of a PB-TNC batch might choose to scan all of the messages in the batch prior to acting upon any of the messages, checking to determine whether one of them is an unsupported message with the NOSKIP flag set.
このフラグは、すべての受信者がこのメッセージをサポートする必要があるという意味ではありません。代わりに、このフラグを1に設定してメッセージを受信したが、必要に応じて処理できない、または処理できない受信者は、PB-TNCバッチのどの部分でも作用してはなりません。代わりに、受信者は、近接バッチで致命的なサポートされていない必須メッセージエラーコードで応答する必要があります。バッチ内のいくつかのメッセージに対するアクションを避けるために、後でサポートされていないNoskipフラグ付きメッセージを見つけるためだけに、PB-TNCバッチの受信者は、メッセージのいずれかに動作する前にバッチ内のすべてのメッセージをスキャンすることを選択する場合があります。それらの1つが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.
このフラグフィールドの他のビットは予約されています。このバージョンのPB-TNCの場合、送信時に0に設定し、受信で無視する必要があります。
PB-TNC Vendor ID (24 bits)
PB-TNCベンダーID（24ビット）
The PB-TNC Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. This Vendor ID qualifies the PB-TNC Message Type field so that each vendor has 2^32-1 separate message types available for their use.
PB-TNCベンダーIDフィールドは、SMIプライベートエンタープライズ番号（PEN）を使用してベンダーを識別します。インターネットが番号を割り当てたIANAから独自のペンを受け取ることができます。このベンダーIDは、PB-TNCメッセージタイプフィールドを適格であるため、各ベンダーには使用可能な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）を使用します。ベンダーID 0xffffffは予約されています。姿勢ブローカーのクライアントと姿勢ブローカーサーバーは、ベンダーIDがこの予約価値（0xffffffff）を持っているメッセージを送信してはなりません。姿勢ブローカークライアントまたは姿勢ブローカーサーバーが、PB-TNCベンダーIDにこの予約値（0xFFFFFF）があるメッセージを受信する場合、致命的な無効なパラメーターエラーコードでクローズバッチで応答する必要があります。
PB-TNC Message Type (32 bits)
PB-TNCメッセージタイプ（32ビット）
The PB-TNC Message Type field identifies the type of the PB-TNC message contained in the PB-TNC Message Value field. The PB-TNC message type 0xffffffff is reserved. Posture Broker Clients and Posture Broker Servers MUST NOT send messages in which the PB-TNC Message Type field has this reserved value (0xffffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PB-TNC Message Type field has this reserved value (0xffffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Unless otherwise prohibited in the definition of a particular PB-TNC message type (e.g., PB-Language-Preference), a single PB-TNC batch may contain multiple messages with the same message type and/or vendor ID.
PB-TNCメッセージタイプフィールドは、PB-TNCメッセージ値フィールドに含まれるPB-TNCメッセージのタイプを識別します。PB-TNCメッセージタイプ0xffffffffは予約されています。Posture BrokerクライアントとPosture Brokerサーバーは、PB-TNCメッセージタイプフィールドにこの予約値（0xffffffffff）があるメッセージを送信してはなりません。姿勢ブローカークライアントまたは姿勢ブローカーサーバーが、PB-TNCメッセージタイプフィールドにこの予約値（0xFFFFFFFF）があるメッセージを受信した場合、致命的な無効なパラメーターエラーコードでクローズバッチで応答する必要があります。特定のPB-TNCメッセージタイプの定義（PB-Language-Preferenceなど）で特に禁止されていない限り、単一のPB-TNCバッチには、同じメッセージタイプおよび/またはベンダーIDを持つ複数のメッセージが含まれる場合があります。
The IETF and any other organization with a PEN can define 2^32-1 unique PB-TNC message types, as long as the organization's PEN is placed in the PB-TNC Vendor ID field of the message. Since the PB-TNC message type is qualified by the vendor ID, there is no risk of conflicts as long as each organization uses its own PEN for the vendor ID and manages its own set of 2^32-1 message type values.
IETFとペンを備えた他の組織は、メッセージのPB-TNCベンダーIDフィールドに組織のペンが配置されている限り、2^32-1ユニークなPB-TNCメッセージタイプを定義できます。PB-TNCメッセージタイプはベンダーIDによって適格であるため、各組織がベンダー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ペン（0）で使用すると標準的な意味がある特定のPB-TNCメッセージタイプを定義します。これらは、IETF標準PB-TNCメッセージタイプとして知られています。これらのPB-TNCメッセージタイプの一部は必須であるため、この仕様の順守を主張するすべてのPossure BrokerクライアントおよびPossure Broker Serverの実装によって実装する必要があります。PB-TNCメッセージタイプが必須である詳細については、セクション4の後半のこれらのメッセージタイプの説明を参照してください。
IANA maintains a registry of PB-TNC message types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
IANAは、PB-TNCメッセージタイプのレジストリを維持しています。このレジストリのエントリは、セクション6.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。
New vendor-specific PB-TNC message types (those used with a non-zero PB-TNC vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PB-TNC message types and MUST interoperate with other parties despite any differences in the set of vendor-specific PB-TNC message types supported (although they MAY permit administrators to configure them to require support for specific PB-TNC message types).
新しいベンダー固有のPB-TNCメッセージタイプ（ゼロ以外のPB-TNCベンダーIDで使用されるもの）は、IETFまたはIANAの関与なしにベンダーによって定義および採用される場合があります。ただし、姿勢ブローカーのクライアントと姿勢ブローカーサーバーは、特定のベンダー固有のPB-TNCメッセージタイプのサポートを必要としてはならず、ベンダー固有のPB-TNCメッセージタイプのセットがサポートされているにもかかわらず、他の関係者と相互運用する必要があります（ただし、彼らは許可する可能性がありますが特定のPB-TNCメッセージタイプのサポートを要求するように構成する管理者。
Note that the PB-TNC Message Type field is completely separate from the PA Subtype field. The same value (e.g., 0) may have different meanings as a PB-TNC message type and as a PA subtype.
PB-TNCメッセージタイプフィールドは、PAサブタイプフィールドとは完全に分離されていることに注意してください。同じ値（例：0）は、PB-TNCメッセージタイプとして、およびPAサブタイプとして異なる意味を持つ場合があります。
PB-TNC Message Length (32 bits)
PB-TNCメッセージ長（32ビット）
This field specifies the length of this PB-TNC message in octets. It includes this header (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length). Therefore, this value MUST always be at least 12. Any Posture Broker Client or Posture Broker Server that receives a message with a PB-TNC Message Length field whose value is less than 12 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
このフィールドは、オクテットのこのPB-TNCメッセージの長さを指定します。このヘッダー（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプ、およびPB-TNCメッセージの長さ）が含まれます。したがって、この値は常に少なくとも12でなければなりません。姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、値が12未満のPB-TNCメッセージ長フィールドでメッセージを受信します。。
PB-TNC Message Value (variable length)
PB-TNCメッセージ値（変数長）
The syntax and semantics of this field vary, depending on the values in the PB-TNC Vendor ID and PB-TNC Message Type fields. The syntax and semantics of several standard messages are defined in subsequent sections of this specification.
このフィールドの構文とセマンティクスは、PB-TNCベンダーIDおよびPB-TNCメッセージタイプフィールドの値によって異なります。いくつかの標準メッセージの構文とセマンティクスは、この仕様の後続のセクションで定義されています。
The following table provides a reference list with brief descriptions of the IETF Standard PB-TNC Message Types defined in this specification. These PB-TNC message types must be used with a PB-TNC vendor ID of zero (0). If these PB-TNC message type values are used with a different PB-TNC vendor ID, they have a completely different meaning that is not defined in this specification.
次の表には、この仕様で定義されているIETF標準PB-TNCメッセージタイプの簡単な説明を含む参照リストを示します。これらのPB-TNCメッセージタイプは、ゼロ（0）のPB-TNCベンダーIDで使用する必要があります。これらのPB-TNCメッセージタイプの値が異なるPB-TNCベンダーIDで使用される場合、この仕様では定義されていない完全に異なる意味があります。
For more details on these message types, see the remainder of section 4. For IETF Standard PA Subtypes (which are completely different from PB-TNC message types), please refer to the PA-TNC specification [10].
これらのメッセージタイプの詳細については、セクション4の残りの部分を参照してください。IETF標準PAサブタイプ（PB-TNCメッセージタイプとはまったく異なります）については、PA-TNC仕様[10]を参照してください。
Message Type Definition
------------ ----------
0 PB-Experimental - reserved for experimental use
1 PB-PA - contains a PA message
2 PB-Assessment-Result - the overall assessment result
computed by the Posture Broker Server
3 PB-Access-Recommendation - includes Posture Broker
Server access recommendation
4 PB-Remediation-Parameters - includes Posture Broker
Server remediation parameters
5 PB-Error - error indicator
6 PB-Language-Preference - sender's preferred
language(s) for human-readable strings
7 PB-Reason-String - string explaining reason for
Posture Broker Server access recommendation
The PB-Experimental PB-TNC message type is a PB-TNC message type (value 0) that has been set aside for experimental purposes. It may be used to test code or for other experimental purposes. It MUST NOT be used in a production environment or in a product. This meaning for this PB-TNC message type only applies if the PB-TNC Vendor ID field in the PB-TNC Message Header contains the value zero (0). If a different Vendor ID is contained in that field, the PB-TNC message type 0 has a completely different meaning not defined in this specification.
PB実験PB-TNCメッセージタイプは、実験目的で確保されたPB-TNCメッセージタイプ（値0）です。コードまたは他の実験目的でテストするために使用できます。生産環境や製品で使用してはなりません。このPB-TNCメッセージタイプのこの意味は、PB-TNCメッセージヘッダーのPB-TNCベンダーIDフィールドに値ゼロ（0）が含まれている場合にのみ適用されます。そのフィールドに別のベンダーIDが含まれている場合、PB-TNCメッセージタイプ0は、この仕様では定義されていないまったく異なる意味を持ちます。
The contents of the PB-TNC Message Length and PB-TNC Message Value fields for this PB-TNC message type are not specified. They may have almost any value, depending on what experiments are being conducted. Similarly, the Flags field for this message may have the NOSKIP bit set or cleared, depending on what experiments are being conducted. However, note that the PB-TNC Message Length field must have a value of at least 12 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length). Any Posture Broker Client or Posture Broker Server that receives a message with a PB-TNC Message Length field whose value is invalid MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
このPB-TNCメッセージタイプのPB-TNCメッセージの長さとPB-TNCメッセージ値フィールドの内容は指定されていません。実験が行われている実験に応じて、ほぼすべての価値がある場合があります。同様に、このメッセージのフラグフィールドには、実験が行われている実験に応じて、Noskipビットが設定またはクリアされている場合があります。ただし、PB-TNCメッセージの開始時の固定長フィールドの合計の合計であるため、PB-TNCメッセージの長さフィールドは少なくとも12の値を持たなければならないことに注意してください（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプ、およびPB-TNCメッセージの長さ）。姿勢のブローカークライアントまたは姿勢ブローカーサーバーは、値が無効なPB-TNCメッセージ長フィールドを使用してメッセージを受信し、近接バッチの致命的な無効なパラメーターエラーコードで応答する必要があります。
A Posture Broker Client or Posture Broker Server implementation intended for production use MUST NOT send a message with this Message Type with the value zero (0) as the vendor ID. If it receives a message with this message type and with the value zero (0) as the vendor ID, it MUST ignore the message unless the NOSKIP bit is set, in which case it MUST respond with a fatal Unsupported Mandatory Message error code in a CLOSE batch.
姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーの実装使用を目的とした姿勢ブローカーサーバーの実装は、ベンダーIDとして値ゼロ（0）のこのメッセージタイプを使用してメッセージを送信してはなりません。ベンダーIDとしてこのメッセージタイプと値ゼロ（0）を使用してメッセージを受信した場合、Noskipビットが設定されていない限り、メッセージを無視する必要があります。バッチを閉じます。
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メッセージタイプには、1つのPAメッセージが含まれています。多くのバッチにはいくつかのPB-PAメッセージが含まれますが、一部のバッチにはこのタイプのメッセージが含まれていない場合があります。
All Posture Broker Client and Posture Broker Server implementations MUST implement support for this PB-TNC message type. Generally, this support will consist of forwarding the enclosed PA message to the appropriate Posture Collectors and Posture Validators. Specific requirements are contained later in the description of this message type.
すべてのPossure BrokerクライアントとPossure Broker Serverの実装は、このPB-TNCメッセージタイプのサポートを実装する必要があります。一般に、このサポートは、囲まれたPAメッセージを適切な姿勢コレクターと姿勢バリエーターに転送することで構成されます。特定の要件は、このメッセージタイプの説明の後半に含まれています。
The type of the PA message contained in a PB-PA message is indicated by the PA Message Vendor ID and PA Subtype fields, as described later in this section. The PA-TNC specification [10] describes several standard PA message types that can be identified by the PA Message Vendor ID and PA Subtype values listed in the PA-TNC specification. Other PA message types may also be defined, as described in the description of the PA Subtype field later in this section.
PB-PAメッセージに含まれるPAメッセージのタイプは、このセクションで後述するように、PAメッセージベンダーIDおよびPAサブタイプフィールドで示されます。PA-TNC仕様[10]は、PAメッセージベンダーIDおよびPA-TNC仕様にリストされているPAサブタイプの値で識別できるいくつかの標準PAメッセージタイプを説明しています。このセクションの後半でPAサブタイプフィールドの説明で説明されているように、他のPAメッセージタイプも定義される場合があります。
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. Any Posture Broker Client or Posture Broker Server that receives a PB-PA message with the NOSKIP flag not set MUST ignore the message and MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージヘッダーのNosKipフラグは、このメッセージタイプに設定する必要があります。NosKipフラグが設定されていないPB-PAメッセージを受信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、メッセージを無視する必要があり、致命的な無効なパラメーターエラーコードでクローズバッチで応答する必要があります。
For the PB-PA message type, the PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 1. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 1 has a completely different meaning not defined in this specification.
PB-PAメッセージタイプの場合、PB-TNCベンダーIDフィールドには値ゼロ（0）を含める必要があり、PB-TNCメッセージタイプフィールドには1を含める必要があります。フィールド、メッセージタイプ1には、この仕様では定義されていないまったく異なる意味があります。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, PA Message Vendor ID, PA Subtype, Posture Collector Identifier, and Posture Validator Identifier), and the PA Message Body. Since the PA Message Body is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 24 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client or Posture Broker Server that receives a PB-PA message with a PB-TNC Message Length field that has an invalid value MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージの長さフィールドには、PB-TNCメッセージの開始時の固定長フィールド（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプなど）を含むPB-TNCメッセージ全体の長さを含める必要があります。、およびPB-TNCメッセージの長さ）、以下にリストされている固定長のフィールド（フラグ、PAメッセージベンダーID、PAサブタイプ、姿勢コレクター識別子、および姿勢検証装置識別子）、およびPAメッセージボディ。PAメッセージ本文は長さが変動するため、PB-TNCメッセージの長さフィールドの値も異なります。ただし、前の文にリストされている固定長のフィールドをカバーするには、常に少なくとも24でなければなりません。姿勢ブローカークライアントまたはPB-TNCメッセージ長のフィールドを使用してPB-PAメッセージを受信する姿勢ブローカーサーバーは、近いバッチで致命的な無効なパラメーターエラーコードで応答する必要があります。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのPB-TNCメッセージ値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA Message Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Posture Collector Identifier | Posture Validator Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Message Body (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
フラグ（8ビット）
This field contains flags relating to the PA message.
このフィールドには、PAメッセージに関連するフラグが含まれています。
Bit 0 of this flags field (the most significant bit) is known as the EXCL flag (for exclusive). If the EXCL bit is cleared (value 0), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message SHOULD deliver the PA message contained in this PB-TNC message to all Posture Collectors or Posture Validators that have expressed an interest in PA messages with this PA Message Vendor ID and PA subtype. If a Posture Broker Client receives a message with the EXCL flag set (value 1), the Posture Broker Client SHOULD deliver the PA message contained in this PB-TNC message only to the Posture Collector identified by the Posture Collector Identifier field. However, if the identified Posture Collector has not expressed an interest in PA messages with this PA Message Vendor ID and PA subtype, the PA message should be silently discarded. Analogous requirements apply to a Posture Broker Server that receives a message with the EXCL flag set.
このフラグフィールドのビット0（最も重要なビット）は、除外フラグ（排他的）として知られています。除外ビットがクリアされている場合（値0）、このPB-TNCメッセージを受信するPositure BrokerクライアントまたはPosture Broker Serverは、このPB-TNCメッセージに含まれるPAメッセージをすべてのPositureコレクターまたは関心を表明した姿勢バリデーターに配信する必要があります。このPAメッセージベンダーIDおよびPAサブタイプを使用したPAメッセージ。姿勢ブローカークライアントが除外フラグセット（値1）でメッセージを受信した場合、姿勢ブローカークライアントは、姿勢コレクター識別子フィールドによって識別された姿勢コレクターにのみ、このPB-TNCメッセージに含まれるPAメッセージを配信する必要があります。ただし、特定された姿勢コレクターが、このPAメッセージベンダーIDおよびPAサブタイプでPAメッセージに関心を表明していない場合、PAメッセージは静かに破棄する必要があります。類似の要件は、除外フラグセットでメッセージを受信する姿勢ブローカーサーバーに適用されます。
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.
除外ビットでは、たとえば、特定の種類の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.
このフラグフィールドの他のビットは予約されています。このバージョンのPB-TNCの場合、送信時に0に設定し、受信で無視する必要があります。
PA Message Vendor ID (24 bits)
PAメッセージベンダーID（24ビット）
The PA Message Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The PA Message Vendor ID qualifies the PA Subtype field so that each vendor has 2^32-1 separate PA subtypes available for its use. PA subtypes standardized by the IETF are always used with a PA Message Vendor ID of the value zero (0) in this field. The PA Message Vendor ID 0xffffff is reserved. A Posture Broker Client or Posture Broker Server MUST NOT send messages in which the PA Message Vendor ID field has this reserved value (0xffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PA Message Vendor ID has this reserved value (0xffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PAメッセージベンダーIDフィールドは、SMIプライベートエンタープライズ番号（PEN）を使用してベンダーを識別します。インターネットが番号を割り当てたIANAから独自のペンを受け取ることができます。PAメッセージベンダーIDは、PAサブタイプフィールドを適格であるため、各ベンダーには使用可能な2^32-1個の個別のPAサブタイプがあります。IETFによって標準化されたPAサブタイプは、このフィールドの値ゼロ（0）のPAメッセージベンダーIDで常に使用されます。PAメッセージベンダーID 0xffffffは予約されています。姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、PAメッセージベンダーIDフィールドにこの予約値（0xFFFFFF）があるメッセージを送信してはなりません。姿勢ブローカークライアントまたは姿勢ブローカーサーバーが、PAメッセージベンダーIDにこの予約値（0xFFFFFF）があるメッセージを受信した場合、致命的な無効なパラメーターエラーコードでクローズバッチで応答する必要があります。
PA Subtype (32 bits)
PAサブタイプ（32ビット）
The PA Subtype field identifies the type of the PA message contained in the PA Message Body field. The PA subtype 0xffffffff is reserved. A Posture Broker Client or Posture Broker Server MUST NOT send messages in which the PA Subtype field has this reserved value (0xffffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PA Subtype has this reserved value (0xffffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. A Posture Broker Client or Posture Broker Server MUST support having multiple PA messages in a single PB-TNC batch that have the same PA subtype and/or PA Message Vendor ID.
PAサブタイプフィールドは、PAメッセージボディフィールドに含まれるPAメッセージのタイプを識別します。PAサブタイプ0xffffffffffは予約されています。姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーは、PAサブタイプフィールドにこの予約値（0xffffffffff）があるメッセージを送信してはなりません。姿勢ブローカーのクライアントまたはPosture Brokerサーバーが、PAサブタイプにこの予約値（0xFFFFFFFF）があるメッセージを受信した場合、致命的な無効なパラメーターエラーコードで近接バッチで応答する必要があります。姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、同じPAサブタイプおよび/またはPAメッセージベンダーIDを持つ単一のPB-TNCバッチに複数のPAメッセージを持つことをサポートする必要があります。
IANA maintains a registry of PA subtypes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. No PA subtypes are 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サブタイプのレジストリを維持しています。このレジストリのエントリは、セクション6.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。この仕様では、PAサブタイプは定義されていません。IETF標準PAサブタイプの定義は、PA-TNC仕様[10]およびその他の仕様に含まれています。IETF標準PAサブタイプは、常にゼロ（0）のPAメッセージベンダーIDで使用されます。
New vendor-specific PA subtypes (those used with a non-zero PA Message Vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PA subtypes and MUST interoperate with other parties despite any differences in the set of vendor-specific PA subtypes supported (although they MAY permit administrators to configure them to require support for specific PA subtypes).
新しいベンダー固有のPAサブタイプ（ゼロ以外のPAメッセージベンダーIDで使用されるもの）は、IETFまたはIANAの関与なしにベンダーによって定義および採用される場合があります。ただし、姿勢ブローカーのクライアントと姿勢ブローカーサーバーは、特定のベンダー固有のPAサブタイプのサポートを必要としてはならず、サポートされているベンダー固有のPAサブタイプのセットの違いにもかかわらず、他の関係者と相互運用する必要があります（ただし、管理者は管理者がそれらを設定することを許可する場合がありますが、特定のPAサブタイプのサポート）。
Note that the PB-TNC Message Type field is completely separate from the PA Subtype field. The same value (e.g., 0) may have different meanings as a PB-TNC message type and as a PA subtype.
PB-TNCメッセージタイプフィールドは、PAサブタイプフィールドとは完全に分離されていることに注意してください。同じ値（例：0）は、PB-TNCメッセージタイプとして、およびPAサブタイプとして異なる意味を持つ場合があります。
Posture Collector Identifier (16 bits)
姿勢コレクター識別子（16ビット）
The Posture Collector Identifier field contains the identifier of the Posture Collector associated with this PA message.
姿勢コレクター識別子フィールドには、このPAメッセージに関連付けられた姿勢コレクターの識別子が含まれています。
The Posture Broker Client is responsible for assigning one or more Posture Collector Identifier values (but not 0xffff) to each Posture Collector involved in a message exchange. Multiple Posture Collector identifiers are required for appropriate correlation in cases where there are multiple components of the same type handled by a single Posture Collector, e.g., an endpoint with two VPN client implementations handled by a single VPN Posture Collector. Please refer to section 3.3 of the PA-TNC specification for an example that illustrates the use of multiple Posture Collector Identifiers. The Posture Collector Identifier value(s) assigned to a Posture Collector by a Posture Broker Client MUST NOT change during the course of a PT session. This identifier is used to identify a unique Posture Collector communicating with the Posture Broker Client on the endpoint during a NEA exchange, and is used by the Posture Validator to send response attributes to a specific Posture Collector component if required.
姿勢ブローカークライアントは、メッセージ交換に関与する各姿勢コレクターに1つ以上の姿勢コレクター識別子値（0xffffではない）を割り当てる責任があります。単一の姿勢コレクターによって処理される同じタイプの複数のコンポーネントがある場合、たとえば、単一のVPNクライアントの実装を持つ2つのVPNクライアント実装を備えたエンドポイントがある場合、適切な相関関係には複数の姿勢コレクター識別子が必要です。複数の姿勢コレクター識別子の使用を示す例については、PA-TNC仕様のセクション3.3を参照してください。姿勢ブローカークライアントによって姿勢コレクターに割り当てられた姿勢コレクター識別子値は、PTセッション中に変更されてはなりません。この識別子は、NEA交換中にエンドポイントで姿勢ブローカークライアントと通信するユニークな姿勢コレクターを識別するために使用され、姿勢バリーターが必要に応じて特定の姿勢コレクターコンポーネントに応答属性を送信するために使用されます。
When a Posture Broker Server sets the EXCL flag for a PA message, the Posture Broker Server MUST set the Posture Collector Identifier field to the identifier of the Posture Collector that should receive the PA message. If the EXCL flag is not set, a Posture Broker Server MAY still set the Posture Collector Identifier value for PA messages that it sends to indicate that the PA message is intended as a response to a message sent by the 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メッセージの除外フラグを設定する場合、Posure Broker Serverは、PAメッセージを受信するはずのPosure Collectorの識別子にPosture Collector Identifierフィールドを設定する必要があります。除外フラグが設定されていない場合、姿勢ブローカーサーバーは、PAメッセージが指定された姿勢に関連付けられた姿勢コレクターによって送信されたメッセージへの応答として意図されていることを示すために送信するPAメッセージの姿勢コレクター識別子値を設定することができますコレクター識別子。姿勢ブローカーサーバーがこの方法で姿勢コレクターを示したくない場合、このフィールドを予約済みの値0xffffに設定する必要があります。
Posture Validator Identifier (16 bits)
Positure Validator Identifier（16ビット）
The Posture Validator Identifier field contains the identifier of the Posture Validator associated with this PA message.
Positure Validator Identifierフィールドには、このPAメッセージに関連付けられたPosure Validatorの識別子が含まれています。
The Posture Broker Server MUST assign a unique Posture Validator Identifier value (but not 0xffff) to each Posture Validator involved in a message exchange and include this Posture Validator identifier in this field for any PA messages sent by that Posture Validator. The Posture Validator Identifier value assigned to a Posture Validator by a Posture Broker Server MUST NOT change during the course of a PT session. This identifier is used to identify a unique Posture Validator communicating with the Posture Broker Server endpoint during a NEA exchange, and is used by the Posture Collector to send attributes to a specific Posture Validator if required.
姿勢ブローカーサーバーは、メッセージ交換に関与する各姿勢バリーターに一意の姿勢検証装置識別子値（0xffffではない）を割り当て、その姿勢バリーターによって送信されたPAメッセージにこのフィールドにこの姿勢検証装置識別子を含める必要があります。Posure Broker ServerによってPosure Validatorに割り当てられたPosure Validator Identifier値は、PTセッション中に変更されてはなりません。この識別子は、NEA交換中に姿勢ブローカーサーバーのエンドポイントと通信する一意の姿勢バリエーターを識別するために使用され、姿勢コレクターが必要に応じて特定のPosureバリーターに属性を送信するために使用されます。
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メッセージの除外フラグを設定する場合、Posure Brokerクライアントは、PAメッセージを受信するはずのPosure Validatorの識別子にPosure Validator Identifierフィールドを設定する必要があります。除外フラグが設定されていない場合、姿勢ブローカークライアントは、PAメッセージが指定された姿勢に関連付けられた姿勢バリーターによって送信されたメッセージへの応答として意図されていることを示すために送信するPAメッセージの姿勢検証装置識別子値をまだ設定することができますバリデーター識別子。姿勢ブローカーのクライアントがこの方法で姿勢バリーターを示すことを望まない場合、このフィールドを予約済みの値0xffffに設定する必要があります。
PA Message Body (variable length)
PAメッセージボディ（可変長）
The PA Message Body field contains the body of the PA message that is being carried in this PB-TNC message. The length of this field can be determined by subtracting the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the fixed-length fields at the start of the PB-PA message (Flags, PA Message Vendor ID, PA Subtype, Posture Collector Identifier, and Posture Validator Identifier) from the message length contained in the PB-TNC Message Length field. The length of these fixed-length fields is 24 octets. Therefore, any Posture Broker Client or Posture Broker Server that receives a PB-PA message with a PB-TNC Message Length field whose value is less than 24 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PAメッセージボディフィールドには、このPB-TNCメッセージに掲載されているPAメッセージの本文が含まれています。このフィールドの長さは、PB-TNCメッセージの開始時に固定長フィールドの長さを差し引くことで決定できます（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプ、およびPB-TNCメッセージの長さを決定できます。）およびPB-PAメッセージの開始時の固定長フィールド（フラグ、PAメッセージベンダーID、PAサブタイプ、姿勢コレクター識別子、およびPosture Validator Identifier）からPB-TNCメッセージ長のフィールドに含まれるメッセージの長さ。これらの固定長フィールドの長さは24オクテットです。したがって、値が24未満のPB-TNCメッセージの長さフィールドを使用してPB-PAメッセージを受信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、致命的な無効なパラメーターエラーコードで近接バッチで応答する必要があります。
The PB-TNC message type named PB-Assessment-Result (value 2) is used by the Posture Broker Server to provide the assessment result after the Posture Broker Server has completed the assessment of the endpoint. The Posture Broker Server will typically compute the assessment result as a cumulative of the individual assessment results received from the various Posture Validators; the algorithm for computation of assessment result at the Posture Broker layer is implementation specific and can also change based on policies in a specific deployment. The Posture Broker Server MUST include one message of this type in any batch of type RESULT and MUST NOT include a message of this type in any other type of batch. The Posture Broker Client MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client MUST implement and process this message and MUST ignore any message with this message type that is not part of a batch of type RESULT.
PB-Assessment-Result（Value 2）という名前のPB-TNCメッセージタイプは、Positure Broker Serverによって使用され、姿勢ブローカーサーバーがエンドポイントの評価を完了した後に評価結果を提供します。姿勢ブローカーサーバーは、通常、さまざまな姿勢バリエーターから受け取った個々の評価結果の累積として評価結果を計算します。姿勢ブローカーレイヤーでの評価結果を計算するためのアルゴリズムは実装固有であり、特定の展開のポリシーに基づいて変更することもできます。Posture Broker Serverには、このタイプのタイプの1つのメッセージをタイプ結果のバッチに含める必要があり、他のタイプのバッチにこのタイプのメッセージを含めてはなりません。姿勢ブローカークライアントは、このメッセージタイプでPB-TNCメッセージを送信してはなりません。姿勢ブローカーサーバーがこのメッセージタイプを使用してPB-TNCメッセージを受信した場合、近接バッチで致命的な無効なパラメーターエラーで応答する必要があります。姿勢ブローカークライアントは、このメッセージを実装および処理する必要があり、タイプの結果のバッチの一部ではないこのメッセージタイプを使用してメッセージを無視する必要があります。
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 2. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 2 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the value 16 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with the Assessment Result field described below. Any Posture Broker Client or Posture Broker Server that receives a PB-Assessment-Result message with a PB-TNC Message Length field that does not have a value of 16 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージヘッダーのNosKipフラグは、このメッセージタイプに設定する必要があります。PB-TNCベンダーIDフィールドには値ゼロ（0）を含む必要があり、PB-TNCメッセージタイプフィールドには2を含める必要があります。この仕様では定義されていない異なる意味。PB-TNCメッセージの長さフィールドには、PB-TNCメッセージの開始時の固定長フィールドの合計の合計（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージ）を含む必要があります。以下に説明する評価結果フィールドとともに、タイプ、およびPB-TNCメッセージの長さ）。姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーは、16の値がないPB-TNCメッセージ長フィールドを使用してPB-Assessment-Resultメッセージを受信し、致命的な無効なパラメーターエラーコードで応答する必要があります。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのPB-TNCメッセージ値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assessment Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assessment Result
評価結果
This 32-bit field MUST contain one of the following values
この32ビットフィールドには、次の値のいずれかが含まれている必要があります
Value Description
----- -----------
0 Posture Broker Server assessed the endpoint to be
compliant with policy.
1 Posture Broker Server assessed the endpoint to be non-compliant with policy but the difference from compliance was minor.
1 Positure Broker Serverは、エンドポイントをポリシーに準拠していないと評価しましたが、コンプライアンスとの違いは軽微でした。
2 Posture Broker Server assessed the endpoint to be non-compliant with policy and the assessed difference from compliance was very significant.
2 Positure Broker Serverは、エンドポイントがポリシーに準拠していないと評価し、コンプライアンスとの評価された違いは非常に重要でした。
3 Posture Broker Server was unable to determine policy compliance due to an error.
3 Posture Broker Serverは、エラーのためにポリシーコンプライアンスを決定することができませんでした。
4 Posture Broker Server was unable to determine whether the assessed endpoint is compliant with policy based on the attributes provided by endpoint.
4 Posture Broker Serverは、評価されたエンドポイントがエンドポイントによって提供された属性に基づいてポリシーに準拠しているかどうかを判断できませんでした。
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つの値以外の評価結果値を受け取る場合、閉鎖バッチで致命的な無効なパラメーターエラーで応答する必要があります。他の値は、PB-TNCの将来のバージョンで定義される場合がありますが、PB-TNCバージョン番号が変更された場合のみです。したがって、評価結果値を評価するためのIANAレジストリは必要ありません。
The PB-TNC message type named PB-Access-Recommendation (value 3) is used by the Posture Broker Server to provide an access recommendation after the Posture Broker Server has completed some assessment of the endpoint. The PB-Assessment-Result and the PB-Access-Recommendation attribute together constitute the global assessment decision for an endpoint. The PB-Access-Recommendation is not authoritative, and the network and host-based access control systems would typically use additional information to determine the network access that is granted to the endpoint. The Posture Broker Server MAY include one message of this type in any batch of type RESULT and MUST NOT include a message of this type in any other type of batch. Posture Broker Clients MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client MUST implement and process this message and MUST ignore any message with this message type that is not part of a batch of type RESULT.
PB-Access-recommendation（Value 3）という名前のPB-TNCメッセージタイプは、Positure Broker Serverが姿勢ブローカーサーバーがエンドポイントの評価を完了した後にアクセス推奨を提供するために使用されます。PB評価とPB-Access-Cremendation属性が一緒になっていることは、エンドポイントのグローバルな評価決定を構成します。PB-Access-Cremendationは権威がなく、ネットワークおよびホストベースのアクセス制御システムは通常、追加情報を使用してエンドポイントに付与されたネットワークアクセスを決定します。Posture Broker Serverには、タイプの結果のバッチにこのタイプの1つのメッセージが含まれている場合があり、他のタイプのバッチにこのタイプのメッセージを含めてはなりません。Posture Brokerクライアントは、このメッセージタイプでPB-TNCメッセージを送信してはなりません。姿勢ブローカーサーバーがこのメッセージタイプを使用してPB-TNCメッセージを受信した場合、近接バッチで致命的な無効なパラメーターエラーで応答する必要があります。姿勢ブローカークライアントは、このメッセージを実装および処理する必要があり、タイプの結果のバッチの一部ではないこのメッセージタイプを使用してメッセージを無視する必要があります。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. Any Posture Broker Client or Posture Broker Server that receives a PB-Access-Recommendation message with the NOSKIP flag set MUST ignore the message and MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 3. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 3 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the value 16 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with the Access Recommendation field described below. Any Posture Broker Client or Posture Broker Server that receives a PB-Access-Recommendation message with a PB-TNC Message Length field that does not have a value of 16 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージヘッダーのNosKipフラグは、このメッセージタイプに設定してはなりません。NoskipフラグセットでPB-Access-Commendationメッセージを受信する姿勢ブローカークライアントまたはPosture Brokerサーバーは、メッセージを無視する必要があり、致命的な無効なパラメーターエラーコードで閉鎖バッチで応答する必要があります。PB-TNCベンダーIDフィールドには値ゼロ（0）を含む必要があり、PB-TNCメッセージタイプフィールドには3.を含める必要があります。この仕様では定義されていない異なる意味。PB-TNCメッセージの長さフィールドには、PB-TNCメッセージの開始時の固定長フィールドの合計の合計（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージ）を含む必要があります。以下で説明するアクセス推奨フィールドとともに、タイプ、およびPB-TNCメッセージの長さ）。姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、16の値がないPB-TNCメッセージ長フィールドを使用してPB-Access-Commendationメッセージを受信し、近接バッチで致命的な無効なパラメーターエラーコードで応答する必要があります。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのPB-TNCメッセージ値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Access Recommendation Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (16 bits)
予約済み（16ビット）
These Reserved bits MUST be set to 0 on transmission and ignored on reception.
これらの予約されたビットは、送信時に0に設定し、受信で無視する必要があります。
Access Recommendation Code (16 bits)
アクセス推奨コード（16ビット）
The Access Recommendation Code field identifies the Access Recommendation that the Posture Broker Server has made for this Posture Broker Client at this time. This field MUST have one of these three values: 1 for Access Allowed (full access), 2 for Access Denied (no access), or 3 for Quarantined (partial access). If a Posture Broker Client receives an Access Recommendation Code value other than these three values, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Other values may be defined in future versions of PB-TNC but only if the PB-TNC version number is changed. Therefore, there is no need for an IANA registry for Access Recommendation Codes.
アクセス推奨コードフィールドは、現時点でこのPossure Brokerクライアントに対してPositure Broker Serverが作成したアクセス推奨事項を識別します。このフィールドには、これらの3つの値のいずれかが必要です。1アクセス許可（フルアクセス）、アクセスの場合は2つ（アクセスなし）、または隔離された（部分アクセス）の場合は3つです。Posture Brokerクライアントがこれらの3つの値以外のアクセス推奨コード値を受信した場合、近接バッチで致命的な無効なパラメーターエラーコードで応答する必要があります。他の値は、PB-TNCの将来のバージョンで定義される場合がありますが、PB-TNCバージョン番号が変更された場合のみです。したがって、アクセス推奨コードのためのIANAレジストリは必要ありません。
The PB-TNC message type named PB-Remediation-Parameters (value 4) is used by the Posture Broker Server to provide global (not Posture Validator-specific) remediation parameters after the Posture Broker Server has completed some assessment of the endpoint. The Posture Broker Server MAY include one or more messages of this type in any batch of any type, but this message type is most useful in batches of type RESULT.
PB-Remediation-Parametersという名前のPB-TNCメッセージタイプ（値4）は、姿勢ブローカーサーバーを提供するために姿勢ブローカーサーバーによって使用されます（姿勢検証器固有の）修復パラメーターは、姿勢ブローカーサーバーがエンドポイントの評価を完了した後です。Posture Broker Serverには、任意のタイプのバッチにこのタイプの1つ以上のメッセージが含まれる場合がありますが、このメッセージタイプは、型のバッチで最も役立ちます。
The Posture Broker Client MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client may implement and process this message but is not required to do so. It may skip this message. Even if the Posture Broker Client implements this message type, it is not obligated to act on it.
姿勢ブローカークライアントは、このメッセージタイプでPB-TNCメッセージを送信してはなりません。姿勢ブローカーサーバーがこのメッセージタイプを使用してPB-TNCメッセージを受信した場合、近接バッチで致命的な無効なパラメーターエラーで応答する必要があります。姿勢ブローカークライアントは、このメッセージを実装および処理する場合がありますが、そうする必要はありません。このメッセージをスキップする可能性があります。姿勢ブローカーのクライアントがこのメッセージタイプを実装していても、それに基づいて行動する義務はありません。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 4. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 4 has a completely different meaning not defined in this specification.
PB-TNCメッセージヘッダーのNosKipフラグは、このメッセージタイプに設定してはなりません。PB-TNCベンダーIDフィールドには値ゼロ（0）を含む必要があり、PB-TNCメッセージタイプフィールドには4を含める必要があります。この仕様では定義されていない異なる意味。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reserved, Remediation Parameters Vendor ID, and Remediation Parameters Type), and the Remediation Parameters. Since the Remediation Parameters field is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 20 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client that receives a PB-Remediation-Parameters message with a PB-TNC Message Length field that contains an invalid value (e.g., less than 20) MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージの長さフィールドには、PB-TNCメッセージの開始時の固定長フィールド（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプなど）を含むPB-TNCメッセージ全体の長さを含める必要があります。、およびPB-TNCメッセージの長さ）、以下にリストされている固定長のフィールド（予約された、修復パラメーターベンダーID、および修復パラメータータイプ）、および修復パラメーター。修復パラメータフィールドは長さが変動するため、PB-TNCメッセージ長フィールドの値も異なります。ただし、前の文にリストされている固定長のフィールドをカバーするには、常に少なくとも20でなければなりません。無効な値（20未満）を含むPB-TNCメッセージの長さフィールドを使用して、PB-Remediation-Parametersメッセージを受信する姿勢ブローカークライアントは、致命的な無効なパラメーターエラーコードで閉鎖バッチで応答する必要があります。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのPB-TNCメッセージ値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remediation Parameters Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (8 bits)
予約済み（8ビット）
These Reserved bits MUST be set to 0 on transmission and ignored on reception.
これらの予約されたビットは、送信時に0に設定し、受信で無視する必要があります。
Remediation Parameters Vendor ID (24 bits)
修復パラメータベンダーID（24ビット）
The Remediation Parameters Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The Remediation Parameters Vendor ID qualifies the Remediation Parameters Type field so that each vendor has 2^32 separate Remediation Parameters Types available for its use. Remediation Parameters Types standardized by the IETF are always used with the value zero (0) in this field.
修復パラメータベンダーIDフィールドは、SMIプライベートエンタープライズ番号（PEN）を使用してベンダーを識別します。インターネットが番号を割り当てたIANAから独自のペンを受け取ることができます。修復パラメータベンダーIDは、各ベンダーに使用可能な2^32の個別の修復パラメータータイプを使用できるように、修復パラメータータイプフィールドを適格にします。IETFによって標準化された修復パラメータータイプは、このフィールドの値ゼロ（0）で常に使用されます。
Remediation Parameters Type (32 bits)
修復パラメータータイプ（32ビット）
The Remediation Parameters Type field identifies the type of remediation parameters contained in the Remediation Parameters field. A Posture Broker Client or Posture Broker Server MUST support having multiple Remediation Parameters messages contained in a single PB-TNC batch that have the same Remediation Parameters Type and/or Remediation Parameters Vendor ID.
修復パラメータタイプフィールドは、修復パラメーターフィールドに含まれる修復パラメーターのタイプを識別します。姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、同じ修復パラメータータイプおよび/または修復パラメーターベンダーIDを持つ単一のPB-TNCバッチに含まれる複数の修復パラメーターメッセージをサポートする必要があります。
IANA maintains a registry of PB-TNC Remediation Parameters Types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. A list of IETF Standard PB-TNC Remediation Parameters Types defined in this specification appears later in this section.
IANAは、PB-TNC修復パラメータータイプのレジストリを維持しています。このレジストリのエントリは、セクション6.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。この仕様で定義されているIETF標準PB-TNC修復パラメータータイプのリストは、このセクションの後半に表示されます。
New vendor-specific Remediation Parameters Types (those used with a non-zero Remediation Parameters vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific Remediation Parameters Types and MUST interoperate with other parties despite any differences in the set of vendor-specific Remediation Parameters Types supported (although they MAY permit administrators to configure them to require support for specific Remediation Parameters Types).
新しいベンダー固有の修復パラメータータイプ（非ゼロ修復パラメータベンダーIDで使用されるもの）は、IETFまたはIANAの関与なしにベンダーによって定義および採用される場合があります。ただし、姿勢ブローカーのクライアントと姿勢ブローカーサーバーは、特定のベンダー固有の修復パラメータータイプのサポートを必要としない必要があり、ベンダー固有の修復パラメータータイプのセットの違いにもかかわらず、他の関係者と相互運用する必要があります（ただし、管理者はそれらを構成することができますが、特定の修復パラメータータイプのサポートを必要とするため）。
Note that the Remediation Parameters Type is completely separate from the PB-TNC Message Type and the PA Subtype fields. The same value (e.g., 0) may have different meanings in each of these fields.
修復パラメータータイプは、PB-TNCメッセージタイプとPAサブタイプフィールドとは完全に分離されていることに注意してください。同じ値（0、0）は、これらの各フィールドで異なる意味を持つ場合があります。
Remediation Parameters (variable length)
修復パラメーター（変数長）
The Remediation Parameters field contains the actual remediation parameters carried in this PB-TNC message. The length of this field can be determined by subtracting the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the fixed-length fields at the start of the PB-Remediation-Parameters message (Reserved, Remediation Parameters Vendor ID, and Remediation Parameters Type) from the message length contained in the PB-TNC Message Length field. The length of these fixed-length fields is 20 octets. Therefore, any Posture Broker Client that receives a PB-Remediation-Parameters message with a PB-TNC Message Length field whose value is less than 20 MUST consider this a malformed message. The Posture Broker Client MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
修復パラメータフィールドには、このPB-TNCメッセージに掲載された実際の修復パラメーターが含まれています。このフィールドの長さは、PB-TNCメッセージの開始時に固定長フィールドの長さを差し引くことで決定できます（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプ、およびPB-TNCメッセージの長さを決定できます。）およびPB-TNCメッセージ長のフィールドに含まれるメッセージの長さから、PB-Remediation-Parametersメッセージ（予約済み、修復パラメーターベンダーID、および修復パラメータータイプ）の開始時の固定長フィールド。これらの固定長フィールドの長さは20オクテットです。したがって、値が20未満のPB-TNCメッセージ長さフィールドを使用して、PB-Remediation-Parametersメッセージを受信するPositure Brokerクライアントは、これを奇形のメッセージと見なす必要があります。姿勢ブローカーのクライアントは、近接バッチで致命的な無効なパラメーターエラーコードで応答する必要があります。
This subsection defines several Remediation Parameters Types that have been standardized by the IETF.
このサブセクションでは、IETFによって標準化されたいくつかの修復パラメータータイプを定義します。
Remediation-URI
修復-URI
This Remediation Parameters Type is employed by creating a PB-Remediation-Parameters message with a Remediation Parameters Vendor ID equal to the value zero (0) and a Remediation Parameters Type of 1. The Remediation Parameters field in the PB-Remediation-Parameters message MUST contain a URI, as described in RFC 3986 [2]. This URI contains instructions and resources for remediation. The Posture Broker Client MAY load the URI and display the resulting web page to the user. The Posture Broker Client MAY also ignore the URI or take another action with it. The Posture Broker Server and any other parties involved in configuring this remediation URI should consider the likely capabilities of the Posture Broker Client when creating the URI and the content referenced by the URI. For example, they should consider the Posture Broker Client's language preferences as expressed in the PB-Language-Preference message.
この修復パラメータタイプは、値ゼロ（0）と修復パラメータータイプタイプの修復パラメーターベンダーIDを使用して、PB-Remediation-Parametersメッセージを作成することで採用されています。RFC 3986 [2]に記載されているように、URIが含まれています。このURIには、修復のための指示とリソースが含まれています。Posture Brokerクライアントは、URIをロードし、結果のWebページをユーザーに表示することができます。姿勢ブローカーのクライアントは、URIを無視するか、別の行動をとることもあります。姿勢ブローカーサーバーおよびこの修復URIの構成に関与する他の関係者は、URIとURIが参照されるコンテンツを作成する際に、Posure Brokerクライアントの可能性のある機能を考慮する必要があります。たとえば、PB-Language-Preferenceメッセージで表現されているように、姿勢ブローカークライアントの言語の好みを考慮する必要があります。
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.
この修復パラメータタイプは、値ゼロ（0）と修復パラメータータイプの修復パラメーターベンダーIDを使用して、PB-Remediation-Parametersメッセージを作成することで採用されています。以下に定義された構造が含まれています。
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.
姿勢ブローカークライアントは、ユーザーに指示を表示する場合があります。姿勢ブローカーのクライアントは、指示を無視したり、別の行動をとったりすることもあります。姿勢ブローカーサーバーおよびこれらの指示の構成に関与する他の関係者は、指示を作成する際にPosure Brokerクライアントの可能性のある機能を考慮する必要があります。たとえば、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.
次の図は、修復パラメーターを運ぶときの修復パラメーターフィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Remediation String Lang Code (Variable Len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Remediation String Length (32 bits)
修復文字列長（32ビット）
The Remediation String Length contains the length of the Remediation String field in octets.
修復文字列の長さには、オクテットの修復文字列フィールドの長さが含まれています。
Remediation String (variable length)
修復文字列（変数長）
The Remediation String field MUST contain a UTF-8 [6] encoded string. This string contains human-readable instructions for remediation that MAY be displayed to the user by the Posture Broker Client. NUL termination MUST NOT be included. If a 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.
修復文字列フィールドには、UTF-8 [6]エンコードされた文字列が含まれている必要があります。この文字列には、姿勢ブローカーのクライアントがユーザーに表示できる人間の読み取り可能な指示が含まれています。NUL終了は含めてはなりません。姿勢ブローカーのクライアントがNUL終了を含む理由を受け取る場合、閉鎖バッチで致命的な無効なパラメーターエラーで応答する必要があります。
Lang Code Len (8 bits)
ラングコードレン（8ビット）
The Lang Code Len field contains the length of the Remediation String Lang Code field in octets. This value may be set to zero to indicate that the language code for the Remediation String field is not known.
Lang Code Lenフィールドには、OctetsのRemediation String Langコードフィールドの長さが含まれています。この値は、修復文字列フィールドの言語コードが不明であることを示すためにゼロに設定される場合があります。
Remediation String Lang Code (variable length)
修復文字列langコード（変数長）
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コードフィールドには、修復パラメーターフィールドの修復文字列で使用される言語を示す、よく形成されたRFC 4646 [3]言語タグで構成されるUS-ASCII文字列が含まれています。このフィールドにゼロ長さの文字列を送信して（本質的にこのフィールドを省略しています）、修復文字列フィールドの言語コードが不明であることを示します。
The PB-TNC message type named PB-Error (value 5) is used by the Posture Broker Client or Posture Broker Server to indicate that an error has occurred. The Posture Broker Client or Posture Broker Server MAY include one or more messages of this type in any batch of any type. Other messages may also be included in the same batch. The party that receives a PB-Error message MAY log it or take other action as deemed appropriate. If the FATAL flag is set (value 1), the recipient MUST terminate the PB-TNC session after processing the batch without sending any messages in response. Every Posture Broker Client and Posture Broker Server MUST implement this message type.
PB-Error（値5）という名前のPB-TNCメッセージタイプは、姿勢ブローカークライアントまたは姿勢ブローカーサーバーによって使用され、エラーが発生したことを示します。Posture Broker ClientまたはPosture Broker Serverには、任意のタイプのバッチにこのタイプの1つ以上のメッセージが含まれる場合があります。他のメッセージも同じバッチに含まれる場合があります。PB-Errorメッセージを受け取った当事者は、それを記録するか、適切とみなされる他の行動をとることがあります。致命的なフラグが設定されている場合（値1）、受信者は、それに応じてメッセージを送信せずにバッチを処理した後、PB-TNCセッションを終了する必要があります。すべての姿勢ブローカークライアントと姿勢ブローカーサーバーは、このメッセージタイプを実装する必要があります。
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 5. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 5 has a completely different meaning not defined in this specification.
PB-TNCメッセージヘッダーのNosKipフラグは、このメッセージタイプに設定する必要があります。PB-TNCベンダーIDフィールドには値ゼロ（0）を含む必要があり、PB-TNCメッセージタイプフィールドには5を含める必要があります。この仕様では定義されていない異なる意味。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, Error Code Vendor ID, Error Code, and Reserved), and the Error Parameters. Since the Error Parameters field is variable length, the value in the PB-TNC Message Length field will vary also.
PB-TNCメッセージの長さフィールドには、PB-TNCメッセージの開始時の固定長フィールド（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプなど）を含むPB-TNCメッセージ全体の長さを含める必要があります。、およびPB-TNCメッセージの長さ）、以下にリストされている固定長のフィールド（フラグ、エラーコードベンダーID、エラーコード、および予約済み）、およびエラーパラメーター。エラーパラメータフィールドは長さが変動するため、PB-TNCメッセージ長の値も異なります。
However, it MUST always be at least 20 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client or Posture Broker Server that receives a PB-Error message with a PB-TNC Message Length field that contains an invalid value (e.g., less than 20) MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Any PB-Error message generated while processing a PB-Error message MUST be a fatal error to avoid the chance of generating an infinite loop of errors.
ただし、前の文にリストされている固定長のフィールドをカバーするには、常に少なくとも20でなければなりません。無効な値（20未満）を含むPB-TNCメッセージの長さフィールドを使用してPB-Errorメッセージを受信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、致命的な無効なパラメーターエラーコードをクローズバッチで応答する必要があります。PB-Errorメッセージの処理中に生成されたPB-ERRORメッセージは、エラーの無限ループを生成する可能性を回避するために致命的なエラーでなければなりません。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのPB-TNCメッセージ値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
フラグ（8ビット）
This field defines flags relating to the error.
このフィールドは、エラーに関連するフラグを定義します。
Bit 0 of this flags field (the most significant bit) is known as the FATAL flag. If the FATAL bit is cleared (value 0), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message SHOULD process this error and then continue with the exchange. If the FATAL flag is set (value 1), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message MUST terminate the exchange after processing the error. In addition, any Posture Broker Client or Posture Broker Server that sends a fatal error MUST NOT process the batch that caused the error and MUST terminate the exchange after sending the batch containing the error report. A PB-Error message with the FATAL flag set MUST always be sent in a CLOSE batch since the sender will be terminating the exchange immediately after sending the batch.
このフラグフィールドのビット0（最も重要なビット）は、致命的なフラグとして知られています。致命的なビットがクリアされている場合（値0）、このPB-TNCメッセージを受信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、このエラーを処理してから交換を続行する必要があります。致命的なフラグが設定されている場合（値1）、このPB-TNCメッセージを受信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、エラーを処理した後に交換を終了する必要があります。さらに、致命的なエラーを送信する姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、エラーを引き起こしたバッチを処理してはならず、エラーレポートを含むバッチを送信した後に交換を終了する必要があります。致命的なフラグセットを使用したPB-ERRORメッセージは、バッチを送信した直後に送信者が交換を終了するため、常に緊密なバッチで送信する必要があります。
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).
致命的なビットにより、姿勢ブローカークライアントまたは姿勢ブローカーサーバーは、致命的なエラー（無効なバッチタイプなど）および/または非脂肪エラー（優先言語の無効な言語タグなど）を信号することができます。
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.
このフラグフィールドの他のビットは予約されています。このバージョンのPB-TNCの場合、送信時に0に設定し、受信で無視する必要があります。
Error Code Vendor ID (24 bits)
エラーコードベンダーID（24ビット）
The Error Code Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The Error Code Vendor ID qualifies the Error Code field so that each vendor has 2^16 separate Error Codes available for its use. Error codes standardized by the IETF are always used with the value zero (0) in this field. For detailed descriptions of those messages, see the next few subsections.
エラーコードベンダーIDフィールドは、SMIプライベートエンタープライズ番号（PEN）を使用してベンダーを識別します。インターネットが番号を割り当てたIANAから独自のペンを受け取ることができます。エラーコードベンダーIDは、各ベンダーに使用可能な2^16個の個別のエラーコードを使用できるように、エラーコードフィールドを適格にします。IETFによって標準化されたエラーコードは、このフィールドの値ゼロ（0）で常に使用されます。これらのメッセージの詳細な説明については、次のいくつかのサブセクションを参照してください。
Error Code (16 bits)
エラーコード（16ビット）
The Error Code field identifies the type of error being signaled with this message. The format of the Error Parameters field depends on the value of the Error Code Vendor ID and the Error Code. However, any recipient that does not understand a particular error code can process the error fairly well by using the FATAL flag to determine whether the error is fatal and the PB-TNC Message Length to skip over the Error Parameters field (or log it).
エラーコードフィールドは、このメッセージで信号されるエラーのタイプを識別します。エラーパラメータフィールドの形式は、エラーコードベンダーIDの値とエラーコードに依存します。ただし、特定のエラーコードを理解していない受信者は、致命的なフラグを使用してエラーが致命的であるかどうかを判断し、PB-TNCメッセージの長さがエラーパラメータフィールドをスキップする（またはログ）かどうかを判断することにより、エラーをかなりうまく処理できます。
IANA maintains a registry of PB-TNC Error Codes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. A list of IETF Standard PB-TNC Error Codes defined in this specification appears later in section 4.9.1.
IANAは、PB-TNCエラーコードのレジストリを維持しています。このレジストリのエントリは、セクション6.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。この仕様で定義されているIETF標準PB-TNCエラーコードのリストは、セクション4.9.1の後半に表示されます。
New vendor-specific error codes (those used with a non-zero error code vendor ID) may be defined and employed by vendors without IETF or IANA involvement. Posture Broker Clients and Posture Broker Servers that receive an unknown error code MUST process this error code gracefully by ignoring or logging it if it is not marked as fatal and terminating the exchange if it is marked as fatal.
新しいベンダー固有のエラーコード（ゼロ以外のエラーコードベンダーIDで使用されるもの）は、IETFまたはIANAの関与なしにベンダーによって定義および採用される場合があります。姿勢ブローカーのクライアントと不明なエラーコードを受信する姿勢ブローカーサーバーは、致命的であるとマークされていない場合は無視またはログすることにより、このエラーコードを優雅に処理する必要があり、致命的であるとマークされている場合は交換を終了する必要があります。
Reserved (16 bits)
予約済み（16ビット）
The Reserved bits MUST be set to 0 on transmission and ignored on reception.
予約されたビットは、送信時に0に設定し、受信時に無視する必要があります。
The following error codes are IETF Standard PB-TNC Error Codes, hence the Error Code Vendor ID MUST be the value zero (0). The following table defines the 16-bit error code. Vendor-specific error codes may be defined by setting the Error Code Vendor ID to the defining vendor's SMI PEN and setting the Error Code field to whatever error code(s) that vendor has defined. The format, length, and meaning of the Error Parameters field varies, based on the Error Code Vendor ID and Error Code. Subsequent sections of this document define the format, length, and meaning of the Error Parameters for the IETF Standard PB-TNC Error Codes defined in this section.
次のエラーコードはIETF標準PB-TNCエラーコードです。したがって、エラーコードベンダーIDは値ゼロ（0）でなければなりません。次の表には、16ビットエラーコードが定義されています。ベンダー固有のエラーコードは、エラーコードベンダーIDをベンダーのSMIペンの定義に設定し、エラーコードフィールドをベンダーが定義したエラーコードに設定することにより定義できます。エラーコードベンダーIDとエラーコードに基づいて、エラーパラメーターの形式、長さ、および意味フィールドは異なります。このドキュメントの次のセクションでは、このセクションで定義されているIETF標準PB-TNCエラーコードのエラーパラメーターの形式、長さ、および意味を定義します。
Error Code Definition
---------- ----------
0 Unexpected Batch Type. Error Parameters are empty.
1 Invalid Parameter. Error Parameters has offset where invalid value was found.
1無効なパラメーター。エラーパラメーターには、無効な値が見つかった場合にオフセットがあります。
2 Local Error. Error Parameters are empty.
2ローカルエラー。エラーパラメーターは空です。
3 Unsupported Mandatory Message. Error Parameters has offset of offending PB-TNC Message
3サポートされていない必須メッセージ。エラーパラメーターには、PB-TNCメッセージが違反するオフセットがあります
4 Version Not Supported. Error Parameters has information about which versions are supported.
4バージョンはサポートされていません。エラーパラメーターには、どのバージョンがサポートされているかに関する情報があります。
This section defines the format, length, and meaning of the Error Parameters field for the IETF Standard PB-TNC Error Codes defined in this specification.
このセクションでは、この仕様で定義されているIETF標準PB-TNCエラーコードのエラーパラメーターフィールドの形式、長さ、および意味を定義します。
The Error Parameters field is zero length for the IETF Standard PB-TNC Error Code 0. The FATAL flag MUST be set for this error code.
エラーパラメーターフィールドは、IETF標準PB-TNCエラーコード0の長さゼロです。このエラーコードに対して致命的なフラグを設定する必要があります。
The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 1. The Offset field is the offset in octets from the start of the PB-TNC batch to the invalid value. The FATAL flag may be either set or cleared for this error code.
エラーパラメータフィールドには、IETF標準PB-TNCエラーコード1の次の構造があります。オフセットフィールドは、PB-TNCバッチの開始から無効な値までのオクテットのオフセットです。致命的なフラグは、このエラーコードのために設定またはクリアされる場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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エラーコード2の長さゼロです。このエラーコードに対して致命的なフラグを設定する必要があります。
The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 3. The Offset field is the offset in octets from the start of the PB-TNC batch to the PB-TNC message whose message type was not recognized (and where the NOSKIP flag was set). The FATAL flag MUST be set for this error code.
エラーパラメータフィールドには、IETF標準PB-TNCエラーコードの次の構造があります。オフセットフィールドは、PB-TNCバッチの開始からメッセージタイプが認識されていないPB-TNCメッセージまでのオクテットのオフセットです（そしてNoskipフラグが設定された場所）。このエラーコードには、致命的なフラグを設定する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 4. The FATAL flag MUST be set for this error code.
エラーパラメーターフィールドには、IETF標準PB-TNCエラーコード4の次の構造があります。このエラーコードには、致命的なフラグを設定する必要があります。
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.
悪いバージョンフィールドは、受信され、サポートされていないバージョン番号です。MAXバージョンとMINバージョンフィールドは、エラーコードの送信者によってサポートされているPB-TNCバージョン番号を示しています。送信者は、MINバージョンとMAXバージョンの間のすべてのPB-TNCバージョンをサポートする必要があります。予約済みフィールドは、送信時に0に設定し、受信時に無視する必要があります。可能であれば、このエラーコードの受信者は、将来のメッセージをPosure Broker ServerまたはPossure Brokerクライアントに送信する必要があります。
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.
サポートされていないエラーコードを送信しているバージョンを送信している当事者は、そのエラーコードをバージョン番号2のPB-TNCクローズバッチに唯一のPB-TNCメッセージとして含める必要があります。PB-TNCバージョン2の他の側面を処理できない場合でも、この説明を満たすバッチにより、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（Value 6）という名前のPB-TNCメッセージタイプは、Possure Brokerクライアントが使用して、送信される可能性のある人間の読み取り可能な文字列を好む言語または言語を示します。これにより、Posture Broker ServerとPossure Validatorsは、Positure Brokerクライアントの好みに送信する可能性のあるメッセージを適応させることができます（おそらくエンドポイントのユーザーの言語設定によって決定されます）。
The Posture Broker Server may also send this message type to the Posture Broker Client to indicate the Posture Broker Server's language preferences, but this is not very useful since the Posture Broker Client rarely sends human-readable strings to the Posture Broker Server and, if it does, rarely can adapt those strings to the preferences of the Posture Broker Server.
Posture Broker Serverは、このメッセージタイプをPossure Brokerクライアントに送信してPositure Broker Serverの言語設定を示すこともできますが、Positure Brokerクライアントが姿勢ブローカーサーバーに人間の読み取り可能な文字列を送信することはめったにないため、これはあまり役に立ちません。これらの文字列を姿勢ブローカーサーバーの好みに適合させることはめったにありません。
No Posture Broker Client or Posture Broker Server is required to send or implement this message type. However, a Posture Broker Server SHOULD attempt to adapt to user language preferences by implementing this message type, passing the language preference information to Posture Validators, and allowing administrators to configure human-readable languages in whatever languages are preferred by their users.
このメッセージタイプを送信または実装するために、姿勢ブローカークライアントまたは姿勢ブローカーサーバーは必要ありません。ただし、Positure Broker Serverは、このメッセージタイプを実装し、言語設定情報を姿勢バリエーターに渡すこと、および管理者がユーザーが好む言語で人間の読み取り可能な言語を構成できるようにすることにより、ユーザー言語の好みに適応しようとする必要があります。
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.
姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーには、あらゆるタイプのバッチにこのタイプのメッセージが含まれる場合があります。ただし、このメッセージは、Posure BrokerクライアントまたはPosture Broker ServerがPB-TNCセッションで送信した最初のバッチに含めることをお勧めします。1つのPB-Language-Parametersメッセージが受信され、同じPB-TNCセッションの後のバッチで別のメッセージが受信される場合、後のメッセージに含まれる値を以前のメッセージの値を置き換えるために考慮する必要があります。
A Posture Broker Client or Posture Broker Server MUST NOT include more than one message of this type in a single batch. If a Posture Broker Client or Posture Broker Server receives more than one message of this type in a single batch, it should ignore all but the last one.
姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーには、単一のバッチにこのタイプの複数のメッセージを含めることはできません。姿勢ブローカーのクライアントまたは姿勢ブローカーサーバーがこのタイプの複数のメッセージを1つのバッチで受信した場合、最後のバッチ以外はすべて無視する必要があります。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 6. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 6 has a completely different meaning not defined in this specification.
PB-TNCメッセージヘッダーのNosKipフラグは、このメッセージタイプに設定してはなりません。PB-TNCベンダーIDフィールドには値ゼロ（0）を含む必要があり、PB-TNCメッセージタイプフィールドには6を含める必要があります。この仕様では定義されていない異なる意味。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the Language Preference field. Since the Language Preference field is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 12 to cover the fixed-length fields listed in the preceding sentences.
PB-TNCメッセージの長さフィールドには、PB-TNCメッセージの開始時の固定長フィールド（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプなど）を含むPB-TNCメッセージ全体の長さを含める必要があります。、およびPB-TNCメッセージの長さ）および言語設定フィールド。言語設定フィールドは長さが変動するため、PB-TNCメッセージの長さフィールドの値も異なります。ただし、前の文にリストされている固定長のフィールドをカバーするには、常に少なくとも12でなければなりません。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのPB-TNCメッセージ値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Preference (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Language Preference (variable length)
言語選好（変動長）
The Language Preference field contains an Accept-Language header, as described in RFC 3282 [4] (using the RFC 2234 ABNF definition of Accept-Language included in that RFC, US-ASCII only, no control characters allowed, no comments, no NUL termination). Any Posture Broker Client or Posture Broker Server that sends a PB-Language-Preference message MUST ensure that the Language Preference field conforms to this format. For example, one acceptable value would be "Accept-Language: fr, en" (without the quote marks).
言語選好フィールドには、RFC 3282 [4]に記載されているように、受け入れ言語ヘッダーが含まれています（RFC 2234を使用して、そのRFCに含まれる受け入れ言語の定義、US-ASCIIのみ、コントロール文字なし、コメントなし、ヌルル終了）。PB-Language-Preferenceメッセージを送信するPositure BrokerクライアントまたはPosture Brokerサーバーは、言語選好フィールドがこの形式に準拠していることを確認する必要があります。たとえば、1つの許容値は「承認言語：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.
ゼロの長さの言語選好フィールドは、言語選好情報が利用できないことを示します。一般的に、これはPBランゲージプレープレファレンスメッセージを送信しないことに相当するため、ゼロ長さの言語選好フィールドでPB言語プレーファレンスメッセージを送信する必要はありませんが、ゼロレングス言語を送信すると便利かもしれません設定フィールドゼロ以外の言語設定フィールドを使用したPB言語プレーションメッセージが以前のバッチで送信された場合、これらの好みはもはや適用されません。
The PB-TNC message type named PB-Reason-String (value 7) is used by the Posture Broker Server to provide a human-readable explanation for the global assessment decision conveyed in the PB-Assessment-Result & PB-Access-Recommendation messages. Therefore, a PB-Reason-String message SHOULD only be included in the same batch as the PB-Assessment-Result and PB-Access-Recommendation message. The Posture Broker Client MUST NOT ever send a PB-Reason-String message.
PB-Reason-String（値7）という名前のPB-TNCメッセージタイプは、Positure Broker Serverによって使用され、PB評価とPB-Access-Commendationメッセージで伝えられたグローバル評価決定の人間が読みやすい説明を提供します。。したがって、PB-Reason-Stringメッセージは、PB評価とPB-Access-Cremendationメッセージと同じバッチにのみ含める必要があります。姿勢ブローカーのクライアントは、PB-Reasonストリングメッセージを送信してはなりません。
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.
姿勢ブローカークライアントはこのメッセージタイプを実装する必要はなく、Positure Brokerサーバーはそれを送信する必要はありません。ただし、ユーザーがエンドポイントが非準拠と見なされた理由に興味があることが多いため、そうすることにはいくつかの利点があります。姿勢ブローカークライアントがこのフィールドを使用する方法は、実装者次第であり、ここでは指定されていません。姿勢ブローカーのクライアントは、ユーザーにメッセージを表示したり、ログにしたり、無視したり、この仕様の要件と矛盾しない他のアクションを実行したりする場合があります。このメッセージに含まれる文字列は人間が読みにくいため、姿勢ブローカーサーバーは、このPB-TNCセッションでPosure Brokerクライアントによって送信されたPBランガージプレーファレンスメッセージで表現されているように、Possure Brokerクライアントの言語設定に適応する必要があります。
A Posture Broker Server MAY include more than one message of this type in any batch of any type. However, it is suggested that this message be included in the same batch as the PB-Assessment-Result and PB-Access-Recommendation message. If more than one PB-Reason-String message is included in a single batch, the Posture Broker Client SHOULD consider the strings included in these messages to be equivalent in meaning. This allows the Posture Broker Server to return multiple equivalent reason strings in different languages, which may help if the Posture Broker Server is not able to accommodate the Posture Broker Client's language preferences.
姿勢ブローカーサーバーには、任意のタイプのバッチにこのタイプの複数のメッセージが含まれる場合があります。ただし、このメッセージは、PB評価とPB-Access-Cremendationメッセージと同じバッチに含まれることが示唆されています。複数のPB-Reasonストリングメッセージが単一のバッチに含まれている場合、Positure Brokerクライアントは、これらのメッセージに含まれる文字列を意味に同等であると考える必要があります。これにより、Possure Broker Serverはさまざまな言語で複数の同等の理由文字列を返すことができます。これにより、Posuture Broker ServerがPosture Brokerクライアントの言語の好みに対応できない場合に役立ちます。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 7. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 7 has a completely different meaning not defined in this specification.
PB-TNCメッセージヘッダーのNosKipフラグは、このメッセージタイプに設定してはなりません。PB-TNCベンダーIDフィールドには値ゼロ（0）を含む必要があり、PB-TNCメッセージタイプフィールドには7を含める必要があります。この仕様では定義されていない異なる意味。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reason String Length and Lang Code Len), and the Reason String and Reason String Language Code fields. Since the Reason String and Reason String Language Code fields are variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 17 to cover the fixed-length fields listed in the preceding sentences. In fact, the PB-TNC Message Length field MUST be exactly the sum of 17 (for the fixed-length fields) and the values of the Reason String Length and Lang Code Len fields. If this is not the case, the recipient MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNCメッセージの長さフィールドには、PB-TNCメッセージの開始時の固定長フィールド（フィールドフラグ、PB-TNCベンダーID、PB-TNCメッセージタイプなど）を含むPB-TNCメッセージ全体の長さを含める必要があります。、およびPB-TNCメッセージの長さ）、以下にリストされている固定長のフィールド（Reason String Length and Lang Code Len）、およびSting and Reason String Language Codeフィールド。String and Reason String Language Codeフィールドは長さが変動するため、PB-TNCメッセージの長さフィールドの値も異なります。ただし、前の文にリストされている固定長のフィールドをカバーするには、常に少なくとも17でなければなりません。実際、PB-TNCメッセージの長さフィールドは、まさに17の合計（固定長のフィールド）と、文字列長とLangコードLENフィールドの値でなければなりません。これが当てはまらない場合、受信者は、近接バッチで致命的な無効なパラメーターエラーコードで応答する必要があります。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
次の図は、このメッセージタイプのPB-TNCメッセージ値フィールドの形式と内容を示しています。この図の後のテキストは、ここに示されているフィールドについて説明しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Reason String Language Code (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason String Length (32 bits)
理由文字列長（32ビット）
The Reason String Length field contains the length of the Reason String field in octets.
理由弦の長さフィールドには、オクテットの理由弦フィールドの長さが含まれています。
Reason String (variable length)
理由文字列（変数長）
The Reason String field contains a UTF-8 encoded string that provides a human-readable reason for the Posture Broker Server's assessment decision. NUL termination MUST NOT be included. If a Posture Broker Client receives a Reason String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. A zero-length string MUST NOT be sent since this is the same as sending no reason string at all, leaving the reason unspecified.
Sting Stringフィールドには、姿勢ブローカーサーバーの評価決定の人間が読みやすい理由を提供するUTF-8エンコード文字列が含まれています。NUL終了は含めてはなりません。姿勢ブローカーのクライアントがNUL終了を含む理由を受け取る場合、近接バッチで致命的な無効なパラメーターエラーコードで応答する必要があります。これは、理由がまったく送信されず、理由が不特定のままになるのと同じであるため、ゼロ長さの文字列を送信してはなりません。
Lang Code Len (8 bits)
ラングコードレン（8ビット）
The Lang Code Len field contains the length of the Reason String Language Code field in octets.
Lang Code Lenフィールドには、OctetsのReason String Language Codeフィールドの長さが含まれています。
Reason String Language Code (variable length)
理由文字列言語コード（変数長）
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.
理由の文字列言語コードフィールドには、このメッセージの理由で使用されている言語を示す、よく形成されたRFC 4646 [3]言語タグを含むUS-ASCII文字列が含まれています。NUL終了はこの分野に含めてはなりません。このフィールドにゼロ長さの文字列を送信して（本質的にこのフィールドを省略しています）、理由の理由の言語コードが不明であることを示します。
PT is required and assumed to provide reliable and secure transport for the PB-TNC protocol (including authentication, confidentiality, integrity protection, and replay protection). Still, it is useful to describe the possible threats to PB-TNC and the countermeasures that are or can be employed. This section does that.
PTが必要であり、PB-TNCプロトコル（認証、機密性、整合性保護、およびリプレイ保護を含む）に信頼性の高い安全な輸送を提供することが想定されています。それでも、PB-TNCに対する脅威の脅威と採用できる、または採用できる対策を説明することは有用です。このセクションはそれを行います。
There are several possible threats to the PB-TNC protocol.
PB-TNCプロトコルにはいくつかの脅威があります。
Untrusted intermediaries on the network between the NEA Client and the NEA Server may attempt to observe data sent between the Posture Broker Client and the Posture Broker Server via PB-TNC, modify this data in transit, reorder it, or replay it. They may also attempt to mount a denial-of-service attack against either party or truncate the exchange prematurely. If successful, these attacks may result in improper assessment decisions relating to the NEA Client, failure to reassess these decisions in light of changed circumstances, improper remediation instructions sent to the NEA Client (which could lead to the compromise of the NEA Client), unauthorized access to confidential information about the NEA Client's health and/or identity, improper reason strings or other messages that might be displayed to the user, access to reusable credentials such as posture assertions, denial of service on the NEA Client, and even complete denial of access to the network (if a denial-of-service attack against the NEA Server was successful and the network required permission from the NEA Server to grant network access).
NEAクライアントと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.
Positure BrokerクライアントとPossure Broker Serverの間の信頼できる仲介者には、Positure Transport ClientとPossure Transport Serverが含まれます。これらの当事者は、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.
信頼できる当事者のいずれかの妥協（姿勢ブローカークライアント、姿勢輸送クライアント、姿勢ブローカーサーバー、または姿勢輸送サーバー）は、最初の段落にリストされているものと同等の障害をもたらす可能性があります。これらの障害は、ネットワークトラフィックを観察したり、監査ログを調べたり比較したりすることによって検出できないため、さらに危険になる可能性があります。姿勢ブローカークライアントと姿勢トランスポートクライアント間、またはPositureブローカーサーバーと姿勢輸送サーバー間の通信を適切に確保できないことは、通常、それらの関係者の妥協と区別できません。NEAクライアントまたはNEAサーバーのオペレーティングシステムまたはその他の重要なソフトウェア、ファームウェア、またはハードウェアコンポーネントの妥協は、通常、同等の結果をもたらします。また、NEAクライアントまたはNEAサーバーへの特権アクセスを獲得する攻撃者の能力（短い時間であっても、セキュリティ設定を無効または誤解するのに十分な長さ）も同様に同等です。NEAクライアントまたはNEAサーバーが、適切な操作（姿勢コレクター、姿勢バリーター、ディレクトリ、パッチ管理サービスを含む）のために他のサービスに依存している場合、それらのサービスの妥協は、依存関係者の妥協または失敗につながる可能性があります。もちろん、NEAサーバーコンポーネントの妥協または障害は最も深刻です。これはおそらく多数のNEAクライアントに影響を与えるため、NEAクライアントの妥協の影響は単一のマシンに限定される可能性があるためです。
The primary countermeasure against attacks by untrusted network intermediaries is the security provided by the PT protocol. Any candidate PT protocols should be carefully examined to ensure that all the threats described above are adequately addressed.
信頼されていないネットワーク仲介者による攻撃に対する主要な対策は、PTプロトコルによって提供されるセキュリティです。候補のPTプロトコルは、上記のすべての脅威が適切に対処されていることを確認するために慎重に検討する必要があります。
As noted above, compromise or erroneous operation of any of the trusted parties is a serious matter with substantial security implications. This includes the Posture Broker Client, the Posture Broker Server, the Posture Transport Client, and the Posture Transport Server. These are all security-sensitive components so they should be built and managed in accordance with best practices for security devices. This is especially important for the NEA Server and its components since a compromise of this device would affect the security and availability of the entire network (similar to compromise of a AAA server). Communications between the trusted parties must also be secured. For example, if the Posture Broker Server and the Posture Transport Server are separate components, their communications must be secured.
上記のように、信頼できる当事者のいずれかの妥協または誤った運用は、重大なセキュリティに影響を与える深刻な問題です。これには、Positure Brokerクライアント、Positure Broker Server、Positure Transport Client、Positure Transport Serverが含まれます。これらはすべてセキュリティに敏感なコンポーネントであるため、セキュリティデバイスのベストプラクティスに従って構築および管理する必要があります。これは、このデバイスの妥協がネットワーク全体のセキュリティと可用性に影響するため、NEAサーバーとそのコンポーネントにとって特に重要です（AAAサーバーの妥協と同様）。信頼できる当事者間の通信も確保する必要があります。たとえば、Positure Broker ServerとPossure Transport Serverが個別のコンポーネントである場合、それらの通信を保護する必要があります。
Since the NEA Client may be a mobile device with little physical security (such as a laptop computer or even a public telephone), it should generally be assumed that some proportion of Access NEA Clients will be compromised and therefore hostile. The NEA Server should be designed to be robust against hostile NEA Clients. Once a compromised NEA Client is detected, it can be treated in a manner equivalent to an untrusted party and should pose no greater threat than any other untrusted party.
NEAクライアントは、物理的なセキュリティがほとんどないモバイルデバイス（ラップトップコンピューターや公衆電話など）である可能性があるため、一般に、アクセスNEAクライアントのある割合が損なわれ、したがって敵対的であると想定されるはずです。NEAサーバーは、敵対的な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.
この仕様では、4つの新しいIANAレジストリが定義されています：PB-TNCメッセージタイプ、PAサブタイプ、PB-TNC修復パラメータータイプ、およびPB-TNCエラーコード。このセクションでは、これらのレジストリがどのように機能するかについて説明します。
All of these registries support IETF standard values and vendor-defined values. To explain this phenomenon, we will use the PB-TNC Message Type as an example but the other three registries work the same way. Whenever a PB-TNC Message Type appears on a network, it is always accompanied by an SMI Private Enterprise Number (PEN), also known as a vendor ID. If this vendor ID is zero, the accompanying PB-TNC Message Type is an IETF standard value listed in the IANA registry for PB-TNC Message Types and its meaning is defined in the specification listed for that PB-TNC Message Type in that registry. If the vendor ID is not zero, the meaning of the PB-TNC Message Type is defined by the vendor identified by the vendor ID (as listed in the IANA registry for SMI PENs). The identified vendor is encouraged but not required to register with IANA some or all of the PB-TNC Message Types used with their vendor ID and publish a specification for each of these values.
これらのレジストリはすべて、IETF標準値とベンダー定義値をサポートしています。この現象を説明するために、PB-TNCメッセージタイプを例として使用しますが、他の3つのレジストリも同じように機能します。PB-TNCメッセージタイプがネットワークに表示されるたびに、ベンダーIDとも呼ばれるSMIプライベートエンタープライズ番号（PEN）が常に伴います。このベンダーIDがゼロの場合、付随するPB-TNCメッセージタイプは、PB-TNCメッセージタイプのIANAレジストリにリストされているIETF標準値であり、その意味は、そのレジストリのPB-TNCメッセージタイプの指定された仕様に定義されます。ベンダーIDがゼロでない場合、PB-TNCメッセージタイプの意味は、ベンダーIDによって識別されたベンダーによって定義されます（SMIペンのIANAレジストリに記載されています）。識別されたベンダーは奨励されていますが、ベンダーIDで使用されているPB-TNCメッセージタイプの一部またはすべてをIANAに登録し、これらの各値の仕様を公開する必要はありません。
This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require support for particular vendor-specific values. However, such behavior is explicitly prohibited by this specification, which dictates that "Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PB-TNC message types and MUST interoperate with other parties despite any differences in the set of vendor-specific PB-TNC message types supported (although they MAY permit administrators to configure them to require support for specific PB-TNC message types)." Similar requirements are included for PA Subtypes, Remediation Parameters Types, and PB-TNC Error Codes.
この名前空間の委任は、OIDに使用される手法に類似しています。ベンダーが特定のベンダー固有の値をサポートする必要がある場合、相互運用性の問題を引き起こす可能性があります。ただし、このような動作は、この仕様によって明示的に禁止されており、「姿勢ブローカーのクライアントと姿勢ブローカーサーバーは、特定のベンダー固有のPB-TNCメッセージタイプのサポートを必要としないため、ベンダーのセットの違いにもかかわらず他の関係者と相互運用する必要があります。 - 固有のPB-TNCメッセージタイプはサポートされています（ただし、管理者は特定のPB-TNCメッセージタイプのサポートを要求するように構成することができます）。」PAサブタイプ、修復パラメータータイプ、およびPB-TNCエラーコードについても同様の要件が含まれています。
For all of the four IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [5].
この仕様で定義された4つのIANAレジストリのすべてについて、RFC 5226 [5]で定義された指定されたエキスパートプロセスを使用して、必要な仕様を使用して専門家のレビューにより、新しい値がレジストリに追加されます。
This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for these registries.
このセクションでは、指定された専門家へのガイダンスを提供して、これらのレジストリに適した哲学を使用して決定を下すことができます。
The registries defined in this document have plenty of values. In most cases, the IETF has approximately 2^32 values available for it to define and each vendor the same number of values for its use. The only exception is the registry for PB-TNC Error Codes where 2^16 values are available for the IETF and 2^16 values for each vendor. Because there are so many values available, designated experts should not be terribly concerned about exhausting the set of values.
このドキュメントで定義されているレジストリには、多くの価値があります。ほとんどの場合、IETFには約2^32の値が定義し、各ベンダーが使用するために同じ数の値を使用できます。唯一の例外は、PB-TNCエラーコードのレジストリです。これは、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レジストリのすべての値は、永続的かつ公開されている仕様に文書化する必要があります。IETF標準値も有用であり、インターネットに有害ではなく、明確で相互運用性を確保する可能性が高い方法で定義されている必要があります。
Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single IETF standard value. However, it is beneficial to document existing practice.
指定された専門家は、ベンダーが同様のが互換性のない値を定義することを避け、代わりに単一のIETF標準値に同意するように奨励する必要があります。ただし、既存の実践を文書化することは有益です。
There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor MUST supply a copy to the IANA and authorize the IANA to archive this copy and make it freely available to all if at some point the document becomes no longer freely available to all through other channels.
仕様が永続的かつ公開されていることを確認するには、いくつかの方法があります。RFCとして公開される場合があります。あるいは、誰でも自由に利用できるようにする別の方法で公開される場合があります。ただし、この後者の場合、ベンダーはIANAにコピーを提供し、IANAがこのコピーをアーカイブすることを許可し、ある時点でドキュメントが他のチャネル全体で自由に利用できなくなった場合、すべてを自由に利用できるようにする必要があります。
The name for this registry is "PB-TNC Message Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-2, and a reference to a specification where the contents of this message type are defined. This specification must define the meaning of this PB-TNC message type and the format and semantics of the PB-TNC Message Value field for PB-TNC messages that include the designated numeric value in the PB-TNC Message Type field and the designated Private Enterprise Number in the PB-TNC Vendor ID field.
このレジストリの名前は「PB-TNCメッセージタイプ」です。このレジストリの各エントリには、人間の読み取り可能な名前、SMIプライベートエンタープライズ番号、0〜2^32-2の小数整数値、およびこのメッセージタイプの内容が定義されている仕様への参照を含める必要があります。この仕様は、このPB-TNCメッセージタイプの意味と、PB-TNCメッセージタイプフィールドに指定された数値を含むPB-TNCメッセージのPB-TNCメッセージ値フィールドの形式とセマンティクスを定義する必要があります。PB-TNCベンダーIDフィールドの番号。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリへのエントリは、セクション6.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Message Types.
このレジストリの次のエントリは、このドキュメントで定義されています。これらは、PB-TNCメッセージタイプのレジストリの初期エントリです。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 PB-Experimental RFC 5793
0 1 PB-PA RFC 5793
0 2 PB-Assessment-Result RFC 5793
0 3 PB-Access-Recommendation RFC 5793
0 4 PB-Remediation-Parameters RFC 5793
0 5 PB-Error RFC 5793
0 6 PB-Language-Preference RFC 5793
0 7 PB-Reason-String RFC 5793
0 0xffffffff Reserved RFC 5793
The name for this registry is "PA Subtypes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-2, and a reference to a specification where the contents of this PA subtype are defined. This specification must define the meaning of this PA subtype and the format and semantics of the PA Message Body field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-PA, the designated numeric value in the PA Subtype field, and the designated Private Enterprise Number in the PA Message Vendor ID field.
このレジストリの名前は「PAサブタイプ」です。このレジストリの各エントリには、人間の読み取り可能な名前、SMIプライベートエンタープライズ番号、0〜2^32-2の小数整数値、およびこのPAサブタイプの内容が定義されている仕様への参照を含める必要があります。この仕様は、このPAサブタイプの意味と、PB-TNCベンダーIDが0のPB-TNCベンダーIDを持つPB-TNCメッセージのPAメッセージボディフィールドの形式とセマンティクスを定義する必要があります。PAサブタイプフィールドの数値、およびPAメッセージベンダーIDフィールドの指定されたプライベートエンタープライズ番号。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリへのエントリは、セクション6.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。
This document does not define any initial entries for this registry. Therefore, this registry should initially be empty. Subsequent RFCs (such as PA-TNC) will define entries in this registry.
このドキュメントは、このレジストリの初期エントリを定義しません。したがって、このレジストリは最初は空にする必要があります。後続の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修復パラメータータイプ」です。このレジストリの各エントリには、人間の読み取り可能な名前、SMIプライベートエンタープライズ番号、0〜2^32-1の小数整数値、およびこの修復パラメータータイプの内容が定義されている仕様への参照を含める必要があります。この仕様は、この修復パラメータータイプ値の意味と、PB-TNCベンダーIDが0、PB-TNCメッセージタイプのPB-Remediation-Parametersを持つPB-TNCメッセージの改善パラメーターフィールドの形式とセマンティクスを定義する必要があります。、修復パラメータータイプフィールドの指定された数値、および修復パラメータベンダーIDフィールドの指定されたプライベートエンタープライズ番号。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリへのエントリは、セクション6.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Remediation Parameters Types.
このレジストリの次のエントリは、このドキュメントで定義されています。これらは、PB-TNC修復パラメータータイプのレジストリの初期エントリです。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 1 Remediation-URI RFC 5793
0 2 Remediation-String RFC 5793
The name for this registry is "PB-TNC Error Codes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^16-1, and a reference to a specification where this error code is defined. This specification must define the meaning of this error code and the format and semantics of the Error Parameters field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Error, the designated numeric value in the Error Code field, and the designated Private Enterprise Number in the Error Code Vendor ID field.
このレジストリの名前は「PB-TNCエラーコード」です。このレジストリの各エントリには、人間の読み取り可能な名前、SMIプライベートエンタープライズ番号、0〜2^16-1の小数整数値、およびこのエラーコードが定義されている仕様への参照を含める必要があります。この仕様は、このエラーコードの意味と、0のPB-TNCベンダーIDを持つPB-TNCメッセージのエラーパラメーターの形式とセマンティクスを定義する必要があります。エラーコードフィールドの値、およびエラーコードベンダーIDフィールドの指定されたプライベートエンタープライズ番号。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
このレジストリへのエントリは、セクション6.1のガイドラインに従って、必要な仕様とともに専門家のレビューによって追加されます。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Error Codes.
このレジストリの次のエントリは、このドキュメントで定義されています。これらは、PB-TNCエラーコードのレジストリの初期エントリです。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Unexpected Batch Type RFC 5793
0 1 Invalid Parameter RFC 5793
0 2 Local Error RFC 5793
0 3 Unsupported Mandatory Message RFC 5793
0 4 Version Not Supported RFC 5793
Thanks to the Trusted Computing Group for contributing the initial text upon which this document was based.
このドキュメントが基づいている最初のテキストに貢献してくれた信頼できるコンピューティンググループに感謝します。
The authors of this document would like to acknowledge the following people who have contributed to or provided substantial input on the preparation of this document or predecessors to it: Bernard Aboba, Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Gene Chang, Roger Chickering, Scott Cochrane, Pasi Eronen, Aman Garg, Sandilya Garimella, Lauren Giroux, Mudit Goel, Charles Goldberg, Thomas Hardjono, Chris Hessing, Hidenobu Ito, John Jerrim, Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Tom Kelnar, Bryan Kingsford, PJ Kirner, Houcheng Lee, Sung Lee, Lisa Lorenzin, Mahalingam Mani, Paul Mayfield, Michael McDaniels, Bipin Mistry, Rod Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn, Alex Romanyuk, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad, Joseph Tardo, Lee Terrell, Chris Trytten, Brad Upson, Ram Vadali, Guha Prasad Venataraman, John Vollbrecht, Jun Wang, and Han Yin.
この文書の著者は、この文書またはその前任者の準備に貢献または実質的な情報を提供した、または提供した以下の人々を認めたいと考えています：バーナード・アボバ、アミット・アガルワル、モルテザ・アンサリ、ダイアナ・アロヨ、スチュアート・ベイリー、ボリス・バラシュフ、ジーンチャン、ロジャー・チカリング、スコット・コクラン、パシ・エロネン、アマン・ガーグ、サンディリヤ・ガリメラ、ローレン・ジルー、ムディット・ゴエル、チャールズ・ゴールドバーグ、トーマス・ハードジョノ、クリス・ヘッシング、ハイデノブ・イト、ジョン・ジェリム、ミーナクシ・カウシク、グレッグ・カズミエルクザック、スカット・ケルザック、ブライアン・キングスフォード、PJキーナー、フーシェン・リー、ソン・リー、リサ・ロレンツィン、マハリンガム・マニ、ポール・メイフィールド、マイケル・マクダニエルズ、ビピン・ミストリー、ロッド・マーチソン、バーバラ・ネルソン、カズアキ・ニムラ、ロンポン、イバン・プリーン、、ポール・サンスター、ディーン・シェフィールド、カーティス・シモンソン、ジェフ・シックス、ネッド・スミス、ミシェル・ソマースタッド、ジョセフ・タルド、リー・テレル、クリス・トライトテン、ブラッド・アップソン、ラム・ヴァダリ、グハ・プラサド・ヴェナタラマン、ジョン・ヴォルブレヒト、ジュン・ワン、ハナン陰。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] 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。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[3] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[3] Phillips、A.、ed。、およびM. Davis、ed。、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[4] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[4] Alvestrand、H。、「Content Language Headers」、RFC 3282、2002年5月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[5] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[6] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[7] Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV Binding", Trusted Computing Group, February 2008.
[7] Hanna、S.、Hurst、R。およびR. Sahita、「TNC IF-TNCCS：TLV Binding」、信頼できるコンピューティンググループ、2008年2月。
[8] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[8] Sangster、P.、Khosravi、H.、Mani、M.、Narayan、K。、およびJ. Tardo、「ネットワークエンドポイント評価（NEA）：概要と要件」、RFC 5209、2008年6月。
[9] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[9] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「Extensible認証プロトコル（EAP）」、RFC 3748、2004年6月。
[10] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
[10] Sangster、P。、およびK. Narayan、「PA-TNC：姿勢属性（PA）プロトコルが信頼できるネットワークConnect（TNC）と互換性がある」、RFC 5792、2010年3月。
This scenario involves the assessment of an endpoint initiated during network join. The assessment is triggered by the Posture Broker Client (PBC) and involves collection of patch information from both Standard Operating System (OS) Posture Collector and vendor-specific Patch Posture Collector (PC). The assessment by both the vendor-specific Patch Posture Validator (PV) and Standard OS Posture Validator result in a compliant assessment decision that results in a compliant System Assessment Decision to be returned by the Posture Broker Server (PBS).
このシナリオには、ネットワーク結合中に開始されたエンドポイントの評価が含まれます。この評価は、姿勢ブローカークライアント（PBC）によってトリガーされ、標準オペレーティングシステム（OS）姿勢コレクターとベンダー固有のパッチ姿勢コレクター（PC）の両方からのパッチ情報の収集が含まれます。ベンダー固有のパッチ姿勢検証装置（PV）と標準のOS姿勢検証装置の両方による評価により、姿勢ブローカーサーバー（PBS）によって返される準拠システム評価決定をもたらす準拠の評価決定が得られます。
+--------+ +-------+ +---------+ +--------+ +-------++--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----++---+---+
| | N/W Join| | | |
| | ----->| | | |
| | Req Post. | | | |
| +<----------+ | | |
| | Req Post. | | | |
+<--------------------| | | |
|Vndr X Patch Posture | | | |
|-------------------->| | | |
| |OS Posture | | | |
| |---------->| | | |
| | | Posture | | |
| | | Report | | |
| | +-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |---------> |
| | | | | Verify |
| | | | | Posture |
| | | |------------------->|
| | | | OS Reslt | |
| | | |<---------| |
| | | | VndrX Patch Result |
| | | Assess |<-------------------|
| | | Result | |
| | <---------| | |
| | OS 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.
このフローには、ベンダー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エンベロープ{
HDR {
HDR {
D bit=0 (Posture Broker Client is originator)
Dビット= 0（姿勢ブローカークライアントはオリジネーターです）
Batch Type=CDATA
バッチタイプ= cdata
Batch Length
バッチ長
}
}
PB Message 1 {
PBメッセージ1 {
Vendor-id=0
ベンダー-ID = 0
Type =2 (PB-PA)
type = 2（pb-pa）
Length
長さ
Value = {
PA-Msg-vendor-id=0 (Standard)
pa-msg-vendor-id = 0（標準）
PA-subtype=1 (OS) OS Posture PA Message
pa-subtype = 1（os）os posure paメッセージ
}
}
}
}
PB Message 2 {
PBメッセージ2 {
Vendor-id=0
ベンダー-ID = 0
Type =2 (PB-PA)
type = 2（pb-pa）
Length
長さ
Value = {
PA-Msg-vendor-id=1 (Vendor X)
pa-msg-vendor-id = 1（ベンダーx）
PA-subtype=1 (Vendor X PA sub-type for patch management)
pa-subtype = 1（パッチ管理のためのベンダーx paサブタイプ）
Vendor X Patch Posture PA Message
ベンダーxパッチ姿勢PAメッセージ
}
}
}
}
}
}
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エンベロープ{
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
Dビット= 1（姿勢ブローカーサーバーはオリジネーターです）
Batch Type=RESULT
バッチタイプ=結果
Batch Length
バッチ長
}
}
PB Message 1 {
PBメッセージ1 {
Vendor-id=0,
Vendor-id = 0、
Type =3 (Access-Recommendation)
type = 3（Access-recommendation）
Length
長さ
Value = {
System-Evaluation-Result=0 (Compliant)
System-Evaluation-Result = 0（準拠）
}
}
}
}
PB Message 2 {
PBメッセージ2 {
Vendor-id=0,
Vendor-id = 0、
Type=2 (PB-PA)
type = 2（pb-pa）
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姿勢結果paメッセージ
}
}
}
}
PB Message 3 {
PBメッセージ3 {
Vendor-id=0,
Vendor-id = 0、
Type=2 (PB-PA)
type = 2（pb-pa）
Length
長さ
Value = {
PA-Msg-vendor-id=1 (Vendor X)
pa-msg-vendor-id = 1（ベンダーx）
PA-subtype=1 (Vendor X PA sub-type for patch management)
pa-subtype = 1（パッチ管理のためのベンダーx paサブタイプ）
Vendor X Patch Posture Result PA Message
ベンダーxパッチ姿勢結果paメッセージ
}
}
}
}
}
}
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）アンチウイルス姿勢検証装置の1つによって準拠し、他のベンダー（ベンダーY）アンチウイルス姿勢検証装置によって非準拠していると評価されます。これにより、姿勢ブローカーサーバーによって返される非準拠システム評価決定が行われます。Posture Broker Serverは、応答の一部としてエンドポイントの修復命令も返します。
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | ----->| | |
| | | | Create | |
| | | |Post. Req | |
| | | |--------->| |
| | | |Create Posture Req |
| | | |----------+--------->|
| | | |Vndr Y AV 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.
このフローは、ベンダーXとベンダー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.
このフローには、ベンダーXアンチウイルス姿勢検証装置からのPAメッセージ（姿勢要求）が含まれています。メッセージコンテンツは、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.
このフローには、ベンダーYアンチウイルス姿勢検証装置からのPAメッセージ（姿勢要求）が含まれています。メッセージコンテンツは、PA-TNC仕様で説明されています。
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators:
このフローには、ベンダーXおよびベンダーYアンチウイルス姿勢検証因子からのPAメッセージを含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
Dビット= 1（姿勢ブローカーサーバーはオリジネーターです）
Batch Type=SDATA
バッチタイプ= sdata
Batch Length
バッチ長
}
}
PB Message 1 {
PBメッセージ1 {
Vendor-id=0
ベンダー-ID = 0
Type =2 (PB-PA)
type = 2（pb-pa）
Length
長さ
Value = {
PA-Msg-vendor-id=1 (Vendor X)
pa-msg-vendor-id = 1（ベンダーx）
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
pa-subtype = 2（アンチウイルスのベンダーx paサブタイプ）
Vendor X AV Posture Request PA Message
ベンダーX AV姿勢要求PAメッセージ
}
}
}
}
PB Message 2 {
PBメッセージ2 {
Vendor-id=0
ベンダー-ID = 0
Type =2 (PB-PA)
type = 2（pb-pa）
Length
長さ
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
pa-msg-vendor-id = 2（ベンダーy）
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
pa-subtype = 1（アンチウイルスのベンダーy paサブタイプ）
Vendor Y AV Posture Request PA Message
ベンダーY AV姿勢要求PAメッセージ
}
}
}
}
}
}
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to process the Posture Request and return particular posture attributes requested. Because this use case is triggered locally, NEA doesn't specify the contents of this flow.
このフローは、ベンダーXおよびベンダーYアンチウイルス姿勢コレクターの呼び出しを示しており、姿勢要求を処理し、要求された特定の姿勢属性を返します。このユースケースはローカルでトリガーされるため、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.
このフローには、ベンダー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.
このフローには、ベンダー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:
このフローには、ベンダーXおよびベンダーYアンチウイルス姿勢コレクターからのPAメッセージを含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=0 (Posture Broker Client is originator)
Dビット= 0（姿勢ブローカークライアントはオリジネーターです）
Batch Type=CDATA
バッチタイプ= cdata
Batch Length
バッチ長
}
}
PB Message 1 {
PBメッセージ1 {
Vendor-id=0
ベンダー-ID = 0
Type =2 (PB-PA)
type = 2（pb-pa）
Length
長さ
Value = {
PA-Msg-vendor-id=1 (Vendor X)
pa-msg-vendor-id = 1（ベンダーx）
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
pa-subtype = 2（アンチウイルスのベンダーx paサブタイプ）
Vendor X AV Posture PA Message
ベンダーX AV POSURE PAメッセージ
}
}
}
}
PB Message 2 {
PBメッセージ2 {
Vendor-id=0
ベンダー-ID = 0
Type =2 (PB-PA)
type = 2（pb-pa）
Length
長さ
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
pa-msg-vendor-id = 2（ベンダーy）
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
pa-subtype = 1（アンチウイルスのベンダーy paサブタイプ）
Vendor Y AV Posture PA Message
ベンダーY AV POSURE PAメッセージ
}
}
}
}
}
}
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Validators requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA doesn't specify the message contents.
このフローは、受け取った姿勢属性の検証を要求するベンダーXおよびベンダーYアンチウイルス姿勢検証装置の呼び出しを示しています。このフローはNEAサーバー内で局所的に発生するため、NEAはメッセージの内容を指定しません。
This flow contains the PA message (Posture Assessment Result) from the Vendor Y Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.
このフローには、ベンダーyアンチウイルス姿勢検証装置からのPAメッセージ（姿勢評価結果）が含まれています。メッセージコンテンツは、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.
このフローには、ベンダーXアンチウイルス姿勢検証装置からの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エンベロープ{
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
Dビット= 1（姿勢ブローカーサーバーはオリジネーターです）
Batch Type=RESULT
バッチタイプ=結果
Batch Length
バッチ長
}
}
PB Message 1 {
PBメッセージ1 {
Vendor-id=0,
Vendor-id = 0、
Type=3 (Access-Recommendation)
type = 3（Access-recommendation）
Length
長さ
Value = {
PB-Assessment-Result=1 (Non-Compliant)
pb-assessment-result = 1（非準拠）
}
}
}
}
PB Message 2 {
PBメッセージ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メッセージ3 {
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=2 (Remediation-String)
Remediation-Param-Type = 2（修復弦）
Remediation-Param=''Try Step1, Step2,...''
Remediation-Param = ''ステップ1、ステップ2、... ''
}
}
}
}
PB Message 4 {
PBメッセージ4 {
Vendor-id=0,
Vendor-id = 0、
Type=2 (PB-PA)
type = 2（pb-pa）
Length
長さ
Value = {
PA-Msg-vendor-id=1 (Vendor X)
pa-msg-vendor-id = 1（ベンダーx）
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
pa-subtype = 2（アンチウイルスのベンダーx paサブタイプ）
Vendor X AV Posture Result PA Message
ベンダーX AV姿勢結果PAメッセージ
}
}
}
}
PB Message 5 {
PBメッセージ5 {
Vendor-id=0,
Vendor-id = 0、
Type=2 (PB-PA)
type = 2（pb-pa）
Length
長さ
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
pa-msg-vendor-id = 2（ベンダーy）
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
pa-subtype = 1（アンチウイルスのベンダーy paサブタイプ）
Vendor Y AV Posture Result PA Message
ベンダーY AV姿勢結果PAメッセージ
}
}
}
}
}
}
These flows illustrate an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to receive the posture assessment results. Because this flow is triggered locally, NEA doesn't specify the contents of this flow.
これらのフローは、姿勢評価の結果を受け取るために、ベンダーXおよびベンダーYアンチウイルス姿勢コレクターの呼び出しを示しています。このフローはローカルでトリガーされるため、NEAはこのフローの内容を指定しません。
This scenario involves the reassessment of an endpoint as a result of enabling a software component on the endpoint. The endpoint has two VPN client software components, one from vendor X for the user's home network and other from vendor Y for the network that the endpoint is currently accessing. The assessment is triggered when the user tries to use the Vendor X VPN client; this is a violation of the posture policy. The Posture Broker Client triggers the posture assessment when it receives a notification from the Standard VPN Posture Collector about the change to the operational state of the VPN component on the endpoint. Note that the VPN Posture Collector supports standard attributes and some vendor-defined attributes from vendor X's and vendor Y's namespaces. This use case doesn't leverage vendor-defined attributes. The assessment involves verification of the standard VPN posture attributes by the Standard VPN Posture Validator that results in a non-compliant assessment result. This use case relies on the use of a virtual Posture Collector concept described in section 3.3 of the PA-TNC specification. As illustrated in this example, the Posture Broker Client will assign two Posture Collector IDs to a single Posture Collector (Standard VPN PC), and the Posture Collector will generate two separate PA messages to report the posture for Vendor X and Vendor Y VPN Clients. The Posture Broker Client will use the assigned IDs in the PB message sent to the NEA Server. This entire behavior will be completely opaque to the NEA Server, which will handle the PB message as if there were two VPN Posture Collectors on the NEA Client.
このシナリオには、エンドポイントでソフトウェアコンポーネントを有効にした結果としてのエンドポイントの再評価が含まれます。エンドポイントには2つのVPNクライアントソフトウェアコンポーネントがあります。1つはユーザーのホームネットワーク用のベンダーXから、もう1つはエンドポイントが現在アクセスしているネットワークのベンダーYからです。評価は、ユーザーがベンダーX VPNクライアントを使用しようとするとトリガーされます。これは姿勢政策の違反です。姿勢ブローカーのクライアントは、エンドポイントのVPNコンポーネントの運用状態への変更に関する標準VPN姿勢コレクターから通知を受け取ったときに姿勢評価をトリガーします。VPN Posture Collectorは、ベンダーXおよびベンダーYの名前空間から標準属性と一部のベンダー定義属性をサポートしていることに注意してください。このユースケースは、ベンダー定義の属性を活用しません。この評価には、標準のVPN姿勢属性の検証が含まれます。このユースケースは、PA-TNC仕様のセクション3.3で説明されている仮想姿勢コレクターの概念の使用に依存しています。この例に示されているように、Posture Brokerクライアントは2つの姿勢コレクターIDを単一の姿勢コレクター（標準VPN PC）に割り当て、Positure CollectorはベンダーXおよびベンダーY VPNクライアントの姿勢を報告する2つの個別のPAメッセージを生成します。Posture Brokerクライアントは、NEAサーバーに送信されたPBメッセージで割り当てられたIDを使用します。この動作全体は、NEAサーバーにとって完全に不透明になり、NEAクライアントに2つのVPN姿勢コレクターがいるかのようにPBメッセージを処理します。
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
---->| | | | | |
| VPN Status Change | | | |
|--------------------->| Posture | | |
| | | Change | | |
| | |-------->| | |
| | |Req. Post| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |VPNY Post| | |
| | |-------->| | |
| | | | Posture | |
| | | | Report | |
| | | |--------->| |
| | | | |Vrfy Post. |
| | | | |---------->|
| | | | |VPN PRslt |
| | | | Assess |<----------|
| | | | Result | |
| | | |<---------| |
| | |VPN PRslt| | |
| | |<--------| | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
このセクションでは、このユースケースで交換されるPAメッセージのそれぞれの重要なフィールドの内容を示しています。必要に応じて、特定のフィールドに表示された値が含まれている理由を説明するために、追加の解説が提供されます。表示されるフローの多くは同じシステム上のコンポーネント間にあるため、メッセージの内容は表示されないことに注意してください。
This flow represents the end user triggered event of starting the VPN Client software from Vendor X. This is merely an event and doesn't include a message being sent.
このフローは、ベンダーXからVPNクライアントソフトウェアを起動するエンドユーザートリガーイベントを表します。これは単なるイベントであり、送信されるメッセージは含まれていません。
This flow represents the detection of the active state of the Vendor X VPN Client software by the Standard VPN Posture Collector. This is merely an event and doesn't include a message being sent.
このフローは、標準のVPN Posure CollectorによるベンダーX VPNクライアントソフトウェアのアクティブ状態の検出を表します。これは単なるイベントであり、送信されるメッセージは含まれていません。
This flow represents the notification of the VPN Posture change sent from the VPN Posture Collector to the Standard Posture Broker Client. This is merely an event and doesn't include a message being sent.
このフローは、VPN姿勢コレクターから標準的な姿勢ブローカークライアントに送られたVPN姿勢の変更の通知を表しています。これは単なるイベントであり、送信されるメッセージは含まれていません。
This flow illustrates an invocation of the VPN Posture Collector requesting particular posture attributes to be sent. Because this use case is triggered locally, the contents of this flow aren't specified by NEA.
このフローは、送信する特定の姿勢属性を要求するVPN姿勢コレクターの呼び出しを示しています。このユースケースはローカルでトリガーされるため、このフローの内容は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エンベロープ{
HDR {
HDR {
D bit=0 (Posture Broker Client is originator)
Dビット= 0（姿勢ブローカークライアントはオリジネーターです）
Batch Type=CRETRY
バッチタイプ=クレトリー
Batch Length
バッチ長
}
}
PB Message 1 {
PBメッセージ1 {
Vendor-id=0
ベンダー-ID = 0
Type =2 (PB-PA)
type = 2（pb-pa）
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
POSURE-COLLECTOR-ID = 1 //ベンダーX VPNクライアントの仮想姿勢コレクターID
Vendor X VPN Posture PA Message
ベンダーX VPN POSURE PAメッセージ
}
}
}
}
PB Message 2 {
PBメッセージ2 {
Vendor-id=0
ベンダー-ID = 0
Type =2 (PB-PA)
type = 2（pb-pa）
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
POSURE-COLLECTOR-ID = 2 //ベンダーY VPNクライアントの仮想姿勢コレクターID
Vendor Y VPN Posture PA Message
ベンダーY VPN POSURE PAメッセージ
}
}
}
}
This flow illustrates an invocation of the VPN Posture Validator requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA doesn't specify the message contents.
このフローは、受信した姿勢属性の検証を要求するVPN姿勢検証器の呼び出しを示しています。このフローはNEAサーバー内で局所的に発生するため、NEAはメッセージの内容を指定しません。
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 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 VPN Posture Validator:
このフローには、姿勢ブローカーサーバーによって計算されたシステム評価結果とVPN Posure ValidatorからのPAメッセージを含むPBメッセージが含まれています。
PB Envelope {
PBエンベロープ{
HDR {
HDR {
D bit=1 (Posture Broker Server is originator)
Dビット= 1（姿勢ブローカーサーバーはオリジネーターです）
Batch Type=RESULT
バッチタイプ=結果
Batch Length
バッチ長
}
}
PB Message 1 {
PBメッセージ1 {
Vendor-id=0,
Vendor-id = 0、
Type =3 (Access-Recommendation)
type = 3（Access-recommendation）
Length
長さ
Value = {
PB-Assessment-Result=1 (Non-Compliant)
pb-assessment-result = 1（非準拠）
}
}
} PB Message 2 {
} pbメッセージ2 {
Vendor-id=0,
Vendor-id = 0、
Type=2 (PB-PA)
type = 2（pb-pa）
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姿勢結果PAメッセージ
}
}
}
}
This flow illustrate an invocation of the VPN Posture Collectors to receive the posture assessment result. Because this flow is triggered locally, NEA doesn't specify the contents of this flow.
このフローは、姿勢評価の結果を受け取るためのVPN姿勢コレクターの呼び出しを示しています。このフローはローカルでトリガーされるため、NEAはこのフローの内容を指定しません。
This section evaluates the PB-TNC protocol against the requirements defined in the NEA Requirements document. Each subsection considers a separate requirement from the NEA Requirements document. Only common requirements (C-1 through C-11) and PB requirements (PB-1 through PB-6) are considered, since these are the only ones that apply to PB.
このセクションでは、NEA要件ドキュメントで定義されている要件に対してPB-TNCプロトコルを評価します。各サブセクションでは、NEA要件ドキュメントとは別の要件を考慮します。PBに適用される唯一のものであるため、一般的な要件（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プロトコルは、単一の評価でNEAクライアントとNEAサーバー間の複数のラウンド旅行をサポートする必要があります。
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サーバーの両方が、必要に応じて姿勢評価または再評価を開始する方法を提供する必要があります。
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サーバーが結果バッチを送信した後に再評価を開始したい場合、基礎となる輸送セッションを閉じて新しい評価を開始する必要があります。半過剰輸送の場合、これはメッセージの絶え間ない交換が維持されない限り避けられません。これは非常に無駄になります。全二重トランスポートの場合、姿勢ブローカーサーバーが決定された状態でもStretryバッチを送信できるようにすることができます。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プロトコルは、リプレイベースの攻撃の防止を含む仲介者やエンドポイントによるアクティブおよびパッシブ攻撃から保護できる必要があります。
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プロトコルを操作できる必要があります。たとえば、PBプロトコルは、PAプロトコルがさまざまなネットワークプロトコル環境（EAP/802.1x、PANA、TLS、IKE/IPSECなど）で変更なしで動作できるように、トランスポートに依存しないインターフェイスを提供する必要があります。
PB-TNC meets this requirement. PB-TNC can operate over any PT protocol that meets the requirements for PT stated in the NEA Requirements document. Also, PB-TNC insulates the PA protocol from any specifics of the PT protocol. With PB-TNC, all PT protocols are equivalent from the perspective of the PA protocol.
PB-TNCはこの要件を満たしています。PB-TNCは、NEA要件文書に記載されているPTの要件を満たすPTプロトコルで動作できます。また、PB-TNCはPTプロトコルの詳細からPAプロトコルを絶縁します。PB-TNCを使用すると、すべてのPTプロトコルはPAプロトコルの観点と同等です。
Requirement C-5 says:
要件C-5は次のように述べています
C-5 The selection process for NEA protocols MUST evaluate and prefer the reuse of existing open standards that meet the requirements before defining new ones. The goal of NEA is not to create additional alternative protocols where acceptable solutions already exist.
C-5 NEAプロトコルの選択プロセスは、新しいものを定義する前に要件を満たす既存のオープン標準の再利用を評価し、好む必要があります。NEAの目標は、許容可能なソリューションがすでに存在する場合に追加の代替プロトコルを作成することではありません。
Based on this requirement, PB-TNC should receive a strong preference. PB-TNC is equivalent with IF-TNCCS 2.0, an open TCG specification. IF-TNCCS 2.0 is an extension of the existing IF-TNCCS 1.X protocols, which have been implemented by dozens of vendors and open source projects.
この要件に基づいて、PB-TNCは強い好みを受け取る必要があります。PB-TNCは、Open 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プロトコルは非常にスケーラブルでなければなりません。このプロトコルは、複数のNEAサーバーに存在する多数の姿勢バリデーターによって評価されるために、多数のNEAクライアントの多くの姿勢コレクターをサポートする必要があります。
PB-TNC meets this requirement. PB-TNC supports up to 2^16-1 Posture Collectors and an equal number of Posture Validators in a given PB-TNC session. It also supports an unlimited number of NEA Clients and NEA Servers.
PB-TNCはこの要件を満たしています。PB-TNCは、特定の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のスケーラビリティは、他の領域にも拡張されます。たとえば、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サーバー間の多数の属性メッセージの効率的な輸送をサポートする必要があります。
PB-TNC meets this requirement. Each PB-TNC batch can contain about 2^24 PA messages. Since PB-TNC supports an unlimited number of batches in a session, this number is actually unlimited (except perhaps by PT protocols, user patience, or other external factors). As for efficiency, PB-TNC adds only 24 octets of overhead per PA message. PA-TNC can include many attributes in a single PA message so this overhead is diluted further.
PB-TNCはこの要件を満たしています。各PB-TNCバッチには、約2^24 PAメッセージを含めることができます。PB-TNCはセッションで無制限の数のバッチをサポートしているため、この数は実際には無制限です（おそらくPTプロトコル、ユーザーの忍耐、またはその他の外部要因を除く）。効率に関しては、PB-TNCはPAメッセージごとに24オクテットのオーバーヘッドを追加します。PA-TNCは、単一のPAメッセージに多くの属性を含めることができるため、このオーバーヘッドはさらに希釈されます。
Requirement C-8 says:
要件C-8は次のように述べています
C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links.
C-8 NEAプロトコルは、低帯域幅または高レイテンシリンクで効率的に動作する必要があります。
PB-TNC meets this requirement. A minimal PB-TNC exchange can be as small as 72 octets and one round trip. Even if privacy policies or other factors require multiple round trips, PB-TNC generally imposes an overhead of only 8 octets per batch and 24 octets per PA message.
PB-TNCはこの要件を満たしています。最小限のPB-TNC交換は、72オクテットと1回の往復である可能性があります。プライバシーポリシーやその他の要因に複数のラウンド旅行が必要であっても、PB-TNCは通常、バッチごとに8オクターと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ユーザーへの表示を目的とした文字列の場合、プロトコルはこれらの文字列をユーザーの言語設定に適応させることをサポートする必要があります。
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はこの要件を満たしています。NEAクライアントとNEAサーバーが、RFC 3282で定義されている広く実装されているAccept-Language形式を活用して、言語の好みを相互に送信する標準的な方法を定義します。
Requirement C-10 says:
要件C-10は次のように述べています
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.
C-10 NEAプロトコルは、UTF-8形式の文字列のエンコードをサポートする必要があります。
PB-TNC meets this requirement. All strings in the PB-TNC protocol are encoded in UTF-8 format. This allows the protocol to support a wide range of languages efficiently.
PB-TNCはこの要件を満たしています。PB-TNCプロトコルのすべての文字列は、UTF-8形式でエンコードされています。これにより、プロトコルは幅広い言語を効率的にサポートできます。
Requirement C-11 says:
要件C-11は次のように述べています
C-11 Due to the potentially different transport characteristics provided by the underlying candidate PT protocols, the NEA Client and NEA Server MUST be capable of becoming aware of and adapting to the limitations of the available PT protocol. For example, some PT protocol characteristics that might impact the operation of PA and PB include restrictions on which end can initiate a NEA connection, maximum data size in a message or full assessment, upper bound on number of round trips, and ordering (duplex) of messages exchanged. The selection process for the PT protocols MUST consider the limitations the candidate PT protocol would impose upon the PA and PB protocols.
C-11基礎となる候補PTプロトコルによって提供される潜在的に異なる輸送特性により、NEAクライアントとNEAサーバーは、利用可能なPTプロトコルの制限を認識し、適応させることができなければなりません。たとえば、PAとPBの動作に影響を与える可能性のあるPTプロトコルの特性には、端がNEA接続を開始できる制限、メッセージまたは完全な評価の最大データサイズ、往復数の上限、および注文（デュプレックス）が含まれます。交換されたメッセージの。PTプロトコルの選択プロセスは、候補PTプロトコルがPAおよびPBプロトコルに課す制限を考慮する必要があります。
PB-TNC meets this requirement. The PB-TNC protocol is designed to be flexible enough to operate with a variety of underlying PT protocols, including those that may have limitations on message or assessment size, number of round trips, and duplex. Local APIs can allow Posture Collectors and Posture Validators to discover when they are operating in a less constrained deployment and then make use of more verbose attributes. Similarly, Posture Collectors could choose not to send or use smaller attributes (including assertions from previous assessments) when faced with a very constrained network connection.
PB-TNCはこの要件を満たしています。PB-TNCプロトコルは、メッセージまたは評価サイズ、往復数、および二重鎖に制限がある可能性のあるものを含む、さまざまな基礎となるPTプロトコルで動作するほど柔軟になるように設計されています。ローカルAPIは、姿勢コレクターと姿勢バリエーターが、制約の少ない展開で動作しているときに発見し、より多くの冗長属性を利用できるようにすることができます。同様に、姿勢コレクターは、非常に制約されたネットワーク接続に直面した場合、より小さな属性（以前の評価からのアサーションを含む）を送信または使用しないことを選択できます。
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プロトコルは、姿勢ブローカーサーバーからPossure Brokerクライアントに属性を運ぶことができなければなりません。これにより、姿勢ブローカークライアントは、姿勢評価の決定を学習でき、適切な場合はエンドポイントの所有者の修復と通知を支援することができます。
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はこの要件を満たしています。Posture BrokerクライアントからPossure Broker Serverに属性を持ち、無制限の数の往復に戻すことができます。さらに、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メッセージの内容を解釈してはなりません。つまり、携帯しているデータはそれに不透明でなければなりません。
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メッセージをルーティング（配信）する必要があります。このようなメッセージルーティングは、姿勢コレクターとバリデーターの動的な登録または登録を容易にするはずです。たとえば、動的に登録されたウイルス対策姿勢検証装置は、NEAクライアントに関するそれぞれのウイルス対策姿勢コレクターからメッセージを受信するためにサブスクライブすることができるはずです。
PB-TNC meets this requirement. PB-TNC tags each PA message with a PA subtype that the Posture Brokers can use to deliver the PA messages to the proper Posture Collectors and Posture Validators. By tagging messages according to their content, PB-TNC allows Posture Collectors and Posture Validators to be dynamically registered and deregistered, ensuring that each one receives the proper data. PB-TNC also supports exclusive delivery, which allows messages to be targeted at a particular Posture Collector or Posture Validator.
PB-TNCはこの要件を満たしています。PB-TNCは、姿勢ブローカーがPAメッセージを適切な姿勢コレクターと姿勢バリエーターに配信するために使用できるPAサブタイプで各PAメッセージをタグ付けします。コンテンツに応じてメッセージをタグ付けすることにより、PB-TNCを使用すると、姿勢コレクターと姿勢バリエーターを動的に登録および登録し、それぞれが適切なデータを受信するようにします。PB-TNCは排他的配信もサポートしています。これにより、メッセージを特定の姿勢コレクターまたは姿勢検証器をターゲットにすることができます。
Requirement PB-4 says:
要件PB-4は次のように述べています
PB-4 The PB protocol MUST be capable of supporting a half-duplex PT protocol. However, this does not preclude PB from operating full-duplex when running over a full-duplex PT.
PB-4 PBプロトコルは、半分二重PTプロトコルをサポートできる必要があります。ただし、これは、全二重PTを実行するときにPBが全二重の動作を妨げるものではありません。
PB-TNC meets this requirement. In order to insulate PA from any differences between half-duplex and full-duplex PT protocols, PB-TNC always operates in a half-duplex mode, regardless of the capabilities of the PT protocol. While this could in theory slow assessments that require many round trips or bidirectional multimedia exchanges, this is not a problem in practice because endpoint assessments do not typically involve multimedia or a large number of round trips.
PB-TNCはこの要件を満たしています。半分二重PTプロトコルと全二重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プロトコルは、姿勢ブローカークライアントと姿勢ブローカーサーバーの間で持つ属性メッセージの認証、整合性、および機密性保護をサポートする場合があります。これにより、Positure Broker ClientとPossure Broker Serverの間で交換される属性メッセージのグループのメッセージダイアログのセキュリティ保護が提供されます。このような保護は、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に追加できます。
Requirement PB-6 says:
要件PB-6は次のように述べています
PB-6 The PB protocol MUST support grouping of attribute messages to optimize transport of messages and minimize round trips.
PB-6 PBプロトコルは、メッセージの輸送を最適化し、往復を最小化するために属性メッセージのグループ化をサポートする必要があります。
PB-TNC meets this requirement. Multiple attribute messages can be conveyed in a single PA message. In fact, that's how PA-TNC works.
PB-TNCはこの要件を満たしています。複数の属性メッセージを単一のPAメッセージで伝えることができます。実際、それがPA-TNCの仕組みです。
Authors' Addresses
著者のアドレス
Ravi Sahita Intel Corporation 2200 Mission College Blvd. Santa Clara, CA 95054 USA EMail: Ravi.Sahita@intel.com
Ravi Sahita Intel Corporation 2200 Mission College Blvd.カリフォルニア州サンタクララ95054 USAメール：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メール：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メール：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メール：kaushik@cisco.com