[要約] RFC 6876は、TLS上で動作する姿勢転送プロトコル（PT-TLS）に関するものであり、セキュアな通信環境で姿勢情報を転送するためのプロトコルです。目的は、セキュリティとプライバシーを確保しながら、姿勢情報の効率的な転送を実現することです。
Internet Engineering Task Force (IETF) P. Sangster
Request for Comments: 6876 Symantec Corporation
Category: Standards Track N. Cam-Winget
ISSN: 2070-1721 J. Salowey
Cisco Systems
February 2013
A Posture Transport Protocol over TLS (PT-TLS)
TLS経由のポスチャトランスポートプロトコル（PT-TLS）
Abstract
概要
This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel.
このドキュメントでは、TLSベースのポスチャトランスポート（PT）プロトコルであるPT-TLSを指定しています。 PT-TLSプロトコルは、トランスポート層セキュリティ（TLS）で保護されたトンネルの保護下で、ネットワークエンドポイントアセスメント（NEA）メッセージ交換を伝送します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6876.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6876で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Conventions Used in This Document ..........................4
1.4. Compatibility with Other Specifications ....................4
2. Design Considerations ...........................................5
2.1. Benefits of TCP/IP Connectivity ............................5
2.2. Leveraging Proven TLS Security .............................6
2.3. TLV-Based Message Encapsulation ............................6
2.4. No Change to Base TLS Protocol .............................6
3. PT-TLS Protocol .................................................7
3.1. Initiating a PT-TLS Session ................................8
3.1.1. Issues with Server-Initiated PT-TLS Sessions ........8
3.1.2. Establish or Re-Use Existing PT-TLS Session .........9
3.2. TCP Port Usage .............................................9
3.3. Preventing MITM Attacks with Channel Bindings ..............9
3.4. PT-TLS Message Flow .......................................10
3.4.1. Assessment Triggers ................................10
3.4.2. PT-TLS Message Exchange Phases .....................11
3.4.2.1. TLS Setup Phase ...........................12
3.4.2.2. PT-TLS Negotiation Phase ..................13
3.4.2.3. PT-TLS Data Transport Phase ...............14
3.4.3. TLS Requirements ...................................14
3.5. PT-TLS Message Format .....................................15
3.6. IETF Namespace PT-TLS Message Types .......................18
3.7. PT-TLS Version Negotiation ................................20
3.7.1. Version Request Message ............................21
3.7.2. Version Response Message ...........................22
3.8. Client Authentication Using SASL ..........................22
3.8.1. SASL Client Authentication Requirements ............23
3.8.2. SASL in PT-TLS Overview ............................24
3.8.3. SASL Authentication Flow ...........................24
3.8.4. Aborting SASL Authentication .......................25
3.8.5. Linkages to SASL Framework .........................25
3.8.5.1. SASL Service Name .........................25
3.8.5.2. SASL Authorization Identity ...............25
3.8.5.3. SASL Security Layer .......................25
3.8.5.4. Multiple Authentications ..................25
3.8.6. SASL Channel Bindings ..............................25
3.8.7. SASL Mechanisms ....................................26
3.8.8. SASL Mechanism Selection ...........................26
3.8.9. SASL Authentication Data ...........................27
3.8.10. SASL Result .......................................28
3.9. Error Message .............................................29
4. Security Considerations ........................................32
4.1. Trust Relationships .......................................32
4.1.1. Posture Transport Client ...........................33
4.1.2. Posture Transport Server ...........................34
4.2. Security Threats and Countermeasures ......................35
4.2.1. Message Theft ......................................35
4.2.2. Message Fabrication ................................36
4.2.3. Message Modification ...............................36
4.2.4. Denial of Service ..................................37
4.2.5. NEA Asokan Attacks .................................37
4.2.6. Trust Anchors ......................................38
5. Privacy Considerations .........................................38
6. IANA Considerations ............................................38
6.1. Designated Expert Guidelines ..............................39
6.2. Registry for PT-TLS Message Types .........................40
6.3. Registry for PT-TLS Error Codes ...........................41
7. Acknowledgments ................................................41
8. References .....................................................42
8.1. Normative References ......................................42
8.2. Informative References ....................................43
The NEA architecture [RFC5209] defines a system for communicating posture between a client, where it is collected, and server, where it is assessed. Posture is configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy. This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol protected by a TLS channel.
NEAアーキテクチャ[RFC5209]は、それが収集されるクライアントとそれが評価されるサーバーとの間でポスチャを通信するためのシステムを定義します。ポスチャとは、組織のセキュリティポリシーに関係するエンドポイント上のハードウェアまたはソフトウェアの構成やステータスです。このドキュメントでは、TLSチャネルで保護されたTLSベースのポスチャトランスポート（PT）プロトコルであるPT-TLSを指定します。
NEA protocols are intended to be used for pre-admission assessment of endpoints joining the network and to assess endpoints already present on the network. In order to support both usage models, two different types (or bindings) of PT protocols are necessary to operate before and after the endpoint has an assigned IP address and other network-layer information. This specification focuses on the PT protocol used to assess endpoints already present on the network and thus is able to use TCP/IP-based transport protocols. NEA has defined another protocol called PT-EAP [PT-EAP] to address assessment prior to the endpoint having an assigned IP address.
NEAプロトコルは、ネットワークに参加するエンドポイントの承認前の評価、およびネットワーク上に既に存在するエンドポイントの評価に使用することを目的としています。両方の使用モデルをサポートするには、エンドポイントにIPアドレスとその他のネットワーク層情報が割り当てられる前と後に動作する2つの異なるタイプ（またはバインディング）のPTプロトコルが必要です。この仕様は、ネットワーク上に既に存在するエンドポイントを評価するために使用されるPTプロトコルに焦点を当てているため、TCP / IPベースのトランスポートプロトコルを使用できます。 NEAは、エンドポイントにIPアドレスが割り当てられる前に、PT-EAP [PT-EAP]と呼ばれる別のプロトコルを定義して、評価に対処します。
The Posture Transport protocol in the NEA architecture [RFC5209] is responsible for transporting Posture Broker (PB-TNC [RFC5793]) batches, often containing Posture Attributes (PA-TNC [RFC5792]) over the network between the Posture Transport Client component of the NEA Client and the Posture Transport Server component of the NEA Server.
NEAアーキテクチャのポスチャトランスポートプロトコル[RFC5209]は、ポスチャブローカー（PB-TNC [RFC5793]）のバッチの転送を担当します。多くの場合、ポスチャトランスポートクライアントコンポーネント間のポスチャトランスポートクライアントコンポーネント間のポスチャ属性（PA-TNC [RFC5792]）を含みます。 NEAクライアントおよびNEAサーバーのポスチャトランスポートサーバーコンポーネント。
The PT protocol also offers strong security protections to ensure that the exchanged messages are protected from a variety of threats from hostile intermediaries.
PTプロトコルは強力なセキュリティ保護も提供し、交換されたメッセージが敵対的な仲介者からのさまざまな脅威から確実に保護されるようにします。
This document does not define an architecture or reference model. Instead, it defines one binding of the PT protocol that works within the reference model described in the NEA Overview and Requirements specification [RFC5209]. The reader is assumed to be thoroughly familiar with [RFC5209]. The NEA working group compared the functionality described in this specification with the requirements in [RFC5209] and found that each applicable requirement was addressed.
このドキュメントでは、アーキテクチャや参照モデルを定義していません。代わりに、NEAの概要と要件の仕様[RFC5209]で説明されている参照モデル内で機能するPTプロトコルの1つのバインディングを定義します。読者は[RFC5209]に完全に精通していると想定されます。 NEAワーキンググループは、この仕様で説明されている機能を[RFC5209]の要件と比較し、該当する各要件が対処されていることを確認しました。
This specification defines the syntax of PT-TLS 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.
この仕様は、ダイアグラムを使用してPT-TLSメッセージの構文を定義します。各図は、各フィールドのフォーマットとサイズをビット単位で示しています。実装は、図のように各図のビットを送信しなければなりません。各行内で図を上から下に、次に左から右に走査します（32ビットの数量を表します）。数値を表すマルチバイトフィールドは、ネットワーク（ビッグエンディアン）バイトオーダーで送信する必要があります。
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 one-octet field with only bit 0 set has the value 0x80.
ビットフィールド（フラグなど）の値は、フィールド内のビットの位置を参照して説明されます。これらのビット位置は、最上位ビットから最下位ビットまで番号が付けられているため、ビット0のみが設定された1オクテットフィールドの値は0x80です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
One of the goals of the NEA effort is to deliver a single set of endpoint assessment standards, agreed upon by all parties. For this reason, the authors understand that the Trusted Computing Group (TCG) will be replacing its existing posture transport protocols with new versions that are equivalent to and interoperable with the NEA specifications.
NEAの取り組みの目標の1つは、すべての関係者が合意した単一セットのエンドポイント評価標準を提供することです。このため、著者らはTrusted Computing Group（TCG）が既存のポスチャトランスポートプロトコルをNEA仕様と同等で相互運用可能な新しいバージョンに置き換えることを理解しています。
This section discusses some of the key design considerations for the PT protocol. This document specifies the PT binding for use when performing an assessment or reassessment after the endpoint has been admitted to the network and is capable of using TCP/IP to communicate with the NEA Server. If the endpoint does not yet have TCP/IP-layer access to the NEA Server (and vice versa), the endpoint can use the PT-EAP (Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods) protocol when performing an assessment.
このセクションでは、PTプロトコルの設計に関する重要な考慮事項のいくつかについて説明します。このドキュメントでは、エンドポイントがネットワークに許可された後に評価または再評価を実行するときに使用するPTバインディングを指定し、TCP / IPを使用してNEAサーバーと通信できます。エンドポイントがNEAサーバーへのTCP / IPレイヤーアクセスをまだ持っていない場合（またはその逆）、エンドポイントは次の場合にPT-EAP（拡張トランスポートプロトコル（EAP）トンネルメソッド用のポスチャトランスポート（PT）プロトコル）プロトコルを使用できます。評価を実行します。
Because the endpoint has TCP/IP access to the NEA Server (potentially on a restricted portion of the network), the NEA Client and NEA Server have the ability to establish (or re-use) a reliable TCP/IP connection in order to perform the assessment. The TCP/IP connection enables the assessment to occur over a relatively high-performance, reliable channel capable of supporting multiple roundtrip message exchanges in a full-duplex manner. These connection properties are very different from what is available when the endpoint is initially joining the network (e.g., during an 802.1X-based assessment); therefore, the design described in this specification follows a different path to maximize the benefits of the underlying TCP/IP connection.
エンドポイントはNEAサーバーへのTCP / IPアクセスを持っているため（ネットワークの制限された部分にある可能性があります）、NEAクライアントとNEAサーバーは、実行するために信頼できるTCP / IP接続を確立（または再利用）することができます。アセスメント。 TCP / IP接続により、複数の往復メッセージ交換を全二重方式でサポートできる、比較的高性能で信頼性の高いチャネルを介して評価を行うことができます。これらの接続プロパティは、エンドポイントが最初にネットワークに参加しているとき（たとえば、802.1Xベースの評価中）に利用できるものとは大きく異なります。したがって、この仕様で説明されている設計は、基礎となるTCP / IP接続の利点を最大化するために別の経路をたどっています。
The PT protocol over TLS is typically able to offer to the NEA Client and NEA Server significantly higher quality of service and flexibility of operation than PT-EAP. However, there may be some added risks when the endpoint is on the network prior to its initial assessment (if no admission time assessment had been performed). Because of these risks, the combined use of an EAP-based assessment during admission followed by reassessment using TCP/IP may be appropriate in some environments.
TLS上のPTプロトコルは、通常、PTA-EAPよりもはるかに高いサービス品質と運用の柔軟性をNEAクライアントとNEAサーバーに提供できます。ただし、エンドポイントが最初の評価の前にネットワーク上にある場合は、追加のリスクがいくつかある可能性があります（承認時間の評価が実行されていない場合）。これらのリスクがあるため、一部の環境では、入学中にEAPベースの評価とTCP / IPを使用した再評価を組み合わせて使用することが適切な場合があります。
Some of the benefits to having a TCP/IP-based transport during an assessment include:
評価中にTCP / IPベースのトランスポートを使用することには、次のような利点があります。
o Full-Duplex Connectivity - used to support asynchronous initiation of posture exchanges within a single TLS connection (e.g., triggered by alerts of posture or policy changes)
o 全二重接続-単一のTLS接続内でのポスチャ交換の非同期開始をサポートするために使用されます（たとえば、ポスチャまたはポリシー変更のアラートによってトリガーされます）
o High Bandwidth - potentially much higher bandwidth than other transports (e.g., EAP), allowing more in-band data (e.g., remediation, verbose posture information)
o 高帯域幅-潜在的に他のトランスポート（EAPなど）よりもはるかに高い帯域幅で、より多くの帯域内データ（修復、詳細なポスチャ情報など）を許可します
o Large Messages - ability to send very large Posture Attribute messages without directly fragmenting them (underlying carrier protocol may introduce fragmentation)
o 大きなメッセージ-直接フラグメント化せずに非常に大きなポスチャ属性メッセージを送信する機能（基礎となるキャリアプロトコルはフラグメント化を引き起こす可能性があります）
o Bidirectional - NEA Client and NEA Server can initiate an assessment or reassessment
o 双方向-NEAクライアントとNEAサーバーは評価または再評価を開始できます
o Multiple Roundtrips - NEA Client and NEA Server can exchange numerous messages without fear of infrastructure timeouts. However, the entire exchange should be kept as brief as possible if the user has to wait for its completion.
o 複数のラウンドトリップ-NEAクライアントとNEAサーバーは、インフラストラクチャのタイムアウトを心配することなく、多数のメッセージを交換できます。ただし、ユーザーが完了するまで待つ必要がある場合は、交換全体をできるだけ短くする必要があります。
All PT protocol bindings must be capable of providing strong authentication, integrity, and confidentiality protection for the PB-TNC batches. Rather than define a new protocol over TCP/IP to provide adequate protection, this specification requires the use of Transport Layer Security [RFC5246] to secure the connection. TLS was selected because it's a widely deployed protocol with parallel protections to a number of the EAP tunnel methods, and it meets all of the security requirements.
すべてのPTプロトコルバインディングは、PB-TNCバッチに対して強力な認証、整合性、および機密保護を提供できる必要があります。この仕様では、TCP / IPを介して新しいプロトコルを定義して適切な保護を提供するのではなく、トランスポート層セキュリティ[RFC5246]を使用して接続を保護する必要があります。 TLSが選択された理由は、TLSが広く展開されているプロトコルであり、多数のEAPトンネル方式に対する並列保護を備えており、すべてのセキュリティ要件を満たしているためです。
The design of the PT-TLS protocol is based upon the use of a type-length-value (TLV)-oriented protocol message that identifies the type of message, the message's length, and a potentially variable-length payload value. The use of a TLV-oriented encoding was chosen to match the Internet standard PA-TNC and PB-TNC protocols. Because the PA-TNC, PB-TNC, and PT-TLS protocols are typically implemented inside the same process space, this allows a common set of message-parsing code to be used. Similarly, creation of debugging tools is simplified by the common encoding methodologies. TLV-based encoding was used in each of the NEA protocols in part because it enables a very space-efficient representation on the network and is simpler to parse than some other encodings to benefit lower-powered (or battery constrained) devices.
PT-TLSプロトコルの設計は、メッセージのタイプ、メッセージの長さ、および潜在的に可変長のペイロード値を識別するType-Length-Value（TLV）指向のプロトコルメッセージの使用に基づいています。 TLV指向のエンコーディングの使用は、インターネット標準のPA-TNCおよびPB-TNCプロトコルに一致するように選択されました。 PA-TNC、PB-TNC、およびPT-TLSプロトコルは通常、同じプロセス空間内に実装されるため、これにより、共通のメッセージ解析コードのセットを使用できます。同様に、デバッグツールの作成は、一般的なエンコード方法によって簡素化されます。 TLVベースのエンコーディングは、ネットワーク上のスペース効率の高い表現を可能にし、他のいくつかのエンコーディングよりも解析が簡単なため、各NEAプロトコルで一部使用されました。
During the design of the PT-TLS protocol, several approaches were considered with different costs and benefits. Several considered approaches involved integrating the PT protocol into the TLS handshake protocol. Because the PT protocol requires the underlying TLS carrier to provide security protections, the PT protocol couldn't operate before the cipher suites were negotiated and in use. One option was to integrate into the TLS handshake protocol after the ChangeCipherSpec phase, allowing the PT message to be protected. The benefit of this approach is that the assessment protocol could operate below the application protocols, allowing for easier integration into applications. However, making this change would require some extensions to the TLS handshake protocol standards and existing widely deployed TLS implementations, so it wasn't clear that the cost was warranted, particularly because the application independence can also be offered by a shim library between the application and TLS library that provides the PT protocol encapsulation/decapsulation.
PT-TLSプロトコルの設計中に、さまざまなコストと利点を持ついくつかのアプローチが検討されました。いくつかの検討されたアプローチは、PTプロトコルをTLSハンドシェイクプロトコルに統合することを含みました。 PTプロトコルは、セキュリティ保護を提供するために基盤となるTLSキャリアを必要とするため、暗号スイートがネゴシエートされて使用されるまで、PTプロトコルは動作できませんでした。 1つのオプションは、ChangeCipherSpecフェーズの後にTLSハンドシェイクプロトコルに統合して、PTメッセージを保護できるようにすることでした。このアプローチの利点は、評価プロトコルがアプリケーションプロトコルの下で動作できるため、アプリケーションへの統合が容易になることです。ただし、この変更を行うには、TLSハンドシェイクプロトコル標準および既存の広く展開されているTLS実装に対するいくつかの拡張が必要になるため、特にアプリケーション間のシムライブラリーによってアプリケーションの独立性も提供できるため、コストが保証されているかどうかは明確ではありませんでしたPTプロトコルのカプセル化/カプセル化解除を提供するTLSライブラリ。
The other general approach considered was to have PT-TLS layer on top of TLS as an application protocol (using the standard application_data ContentType). This has the advantage that existing TLS software could be used. However, the PB-TNC traffic would need to be encapsulated/decapsulated by a new PT-TLS protocol layer before being passed to the TLS library. This didn't seem like a significant issue, as PB-TNC is architected to layer on PT anyway.
検討された他の一般的なアプローチは、アプリケーションプロトコルとして（標準のapplication_data ContentTypeを使用して）TLSの上にPT-TLSレイヤーを持つことでした。これには、既存のTLSソフトウェアを使用できるという利点があります。ただし、PB-TNCトラフィックは、TLSライブラリに渡される前に、新しいPT-TLSプロトコルレイヤーによってカプセル化/カプセル化解除される必要があります。 PB-TNCはとにかくPTにレイヤーするように設計されているため、これは重要な問題のようには見えませんでした。
After considering the different options, it was determined that layering the PT protocol on top of the TLS protocol without requiring current TLS protocol implementations to change met all the requirements and offered the best path toward rapid adoption and deployment. Therefore, the following sections describe a PT protocol that is carried on top of TLS.
さまざまなオプションを検討した結果、現在のTLSプロトコルの実装を変更せずにPTプロトコルをTLSプロトコルの上に重ねることがすべての要件を満たし、迅速な導入と展開に向けた最良の道を提供することが判明しました。したがって、以下のセクションでは、TLSの上で実行されるPTプロトコルについて説明します。
This section specifies the PT-TLS protocol, a Posture Transport (PT) protocol carried by the Transport Layer Security (TLS) protocol over a TCP/IP network. As shown in Figure 1, this protocol runs directly on top of TLS as an application. This means PT-TLS is encapsulated within the TLS Record Layer protocol using the standard ContentType for applications (application_data).
このセクションでは、PT-TLSプロトコル、TCP / IPネットワークを介してトランスポート層セキュリティ（TLS）プロトコルによって伝送されるポスチャトランスポート（PT）プロトコルを指定します。図1に示すように、このプロトコルはアプリケーションとしてTLSの上で直接実行されます。これは、PT-TLSがアプリケーションの標準ContentType（application_data）を使用してTLS Record Layerプロトコル内にカプセル化されることを意味します。
+---------------------------------------------------------------+
| TLV Encapsulation of PB-PA message |
+---------------------------------------------------------------+
| TLS |
+---------------------------------------------------------------+
| TCP |
+---------------------------------------------------------------+
Figure 1. PT-TLS Layering Model
図1. PT-TLSレイヤーモデル
The PT-TLS protocol may be initiated by a Posture Transport Client or a Posture Transport Server. This flexibility supports different use cases. For example, a Posture Transport Client that wishes to trigger a NEA assessment to determine whether its security posture is good can start up a PT-TLS session and request a posture assessment. On the other hand, when an endpoint requests access to a protected network or resource, a Posture Transport Server can start up a PT-TLS session and perform a posture assessment before deciding whether to grant access.
PT-TLSプロトコルは、ポスチャトランスポートクライアントまたはポスチャトランスポートサーバーによって開始されます。この柔軟性により、さまざまなユースケースがサポートされます。たとえば、NEA評価をトリガーしてセキュリティポスチャが良好であるかどうかを判断するポスチャトランスポートクライアントは、PT-TLSセッションを開始して、ポスチャ評価を要求できます。一方、エンドポイントが保護されたネットワークまたはリソースへのアクセスを要求すると、ポスチャトランスポートサーバーはPT-TLSセッションを開始し、アクセスを許可するかどうかを決定する前にポスチャ評価を実行できます。
The party that initiates a PT-TLS session is known as the "PT-TLS Initiator". The other party in the session (which receives the request to open a PT-TLS session) is known as the "PT-TLS Responder".
PT-TLSセッションを開始するパーティは、「PT-TLSイニシエーター」と呼ばれます。セッションの相手（PT-TLSセッションを開く要求を受け取る）は、「PT-TLSレスポンダ」と呼ばれます。
In order for a NEA Server to establish a PT-TLS session, the NEA Client needs to be listening for a connection request on a TCP port known by the NEA Server. In many deployments, the security policies of an endpoint (e.g., firewall software) or the security policies of a network (e.g., firewall devices) are designed to minimize the number of open inbound TCP/UDP ports that are available to the network to reduce the potential attack footprint. This is one issue that makes it difficult for a NEA Server to initiate a PT-TLS session.
NEAサーバーがPT-TLSセッションを確立するためには、NEAクライアントは、NEAサーバーによって認識されているTCPポートで接続要求をリッスンする必要があります。多くの展開では、エンドポイント（ファイアウォールソフトウェアなど）のセキュリティポリシーまたはネットワーク（ファイアウォールデバイスなど）のセキュリティポリシーは、ネットワークで使用可能な開いている受信TCP / UDPポートの数を最小限に抑えて削減するように設計されています潜在的な攻撃の足跡。これは、NEAサーバーがPT-TLSセッションを開始するのを困難にする1つの問題です。
Another issue with this scenario involves X.509 certificates. When the NEA Server creates a TLS session to the NEA Client, the NEA Client is effectively acting as the TLS server during the TLS protocol exchange. This means the NEA Client would typically need to possess an X.509 certificate to protect the initial portion of the TLS handshake. In situations where the NEA Server initiates the creation of the TLS session, both the NEA Client and NEA Server MUST possess X.509 certificates to fully authenticate the session. For many deployments, provisioning X.509 certificates to all NEA Clients has scalability and cost issues; therefore, it is recommended that the NEA Client not listen for connection requests from the NEA Server but instead establish and maintain a TLS session to the NEA Server proactively, so either party can initiate an assessment using the preexisting TLS session as required.
このシナリオの別の問題には、X.509証明書が含まれます。 NEAサーバーがNEAクライアントへのTLSセッションを作成するとき、NEAクライアントは、TLSプロトコル交換中にTLSサーバーとして効果的に機能します。つまり、NEAクライアントは通常、TLSハンドシェイクの最初の部分を保護するためにX.509証明書を所有する必要があります。 NEAサーバーがTLSセッションの作成を開始する状況では、NEAクライアントとNEAサーバーの両方が、セッションを完全に認証するためにX.509証明書を所有している必要があります。多くの展開では、すべてのNEAクライアントにX.509証明書をプロビジョニングすると、スケーラビリティとコストの問題があります。したがって、NEAクライアントはNEAサーバーからの接続要求をリッスンせず、代わりにNEAサーバーへのTLSセッションを事前に確立して維持することをお勧めします。これにより、どちらのパーティも必要に応じて既存のTLSセッションを使用して評価を開始できます。
In most cases, the traditional methods of server certificate ID validation will not apply when the NEA Server initiates the connection. In this case, the NEA Client and Server need to follow the certificate path validation rules in RFC 5280 [RFC5280]. In addition, each side needs to be able to authorize its peer based upon matching Subject and SubjectAltName fields for certificates issued by a particular trust anchor.
ほとんどの場合、NEAサーバーが接続を開始するときに、サーバー証明書ID検証の従来の方法は適用されません。この場合、NEAクライアントとサーバーは、RFC 5280 [RFC5280]の証明書パス検証ルールに従う必要があります。さらに、各サイドは、特定のトラストアンカーによって発行された証明書のSubjectおよびSubjectAltNameフィールドに一致することに基づいてピアを承認できる必要があります。
Therefore, NEA Clients SHOULD be capable of establishing and holding open a TLS session with the NEA Server immediately after obtaining network access. A NEA Client MAY listen for connection requests from the NEA Server and establish a new PT-TLS session when one does not already exist. Because of the potential added complexity, a NEA Client's support for accepting inbound PT-TLS connections is optional to implement. Having an existing PT-TLS session allows either party to initiate an assessment without requiring the NEA Client to be listening for new connection requests. In order to keep the TLS session alive, the NEA Client and NEA Server SHOULD be capable of supporting the TLS heartbeat protocol [RFC6520].
したがって、NEAクライアントは、ネットワークアクセスを取得した直後に、NEAサーバーとのTLSセッションを確立して開いたままにできる必要があります（SHOULD）。 NEAクライアントは、NEAサーバーからの接続要求をリッスンして、まだ存在しない場合は新しいPT-TLSセッションを確立できます。複雑になる可能性があるため、インバウンドPT-TLS接続を受け入れるためのNEAクライアントのサポートの実装はオプションです。既存のPT-TLSセッションがあると、どちらの当事者も、NEAクライアントが新しい接続要求をリッスンすることを要求せずに評価を開始できます。 TLSセッションを存続させるために、NEAクライアントとNEAサーバーは、TLSハートビートプロトコル[RFC6520]をサポートできる必要があります（SHOULD）。
A single PT-TLS session can support multiple NEA assessments, which can be started by either party (the PT-TLS Initiator or the PT-TLS Responder). The party that starts a NEA assessment is known as the "assessment initiator", and the other party is known as the "assessment responder".
単一のPT-TLSセッションは複数のNEA評価をサポートでき、どちらのパーティ（PT-TLSイニシエーターまたはPT-TLSレスポンダー）でも開始できます。 NEA評価を開始する当事者は「評価開始者」と呼ばれ、もう一方の当事者は「評価応答者」と呼ばれます。
If the assessment initiator already has a PT-TLS session to the assessment responder, the initiator can re-use this session; otherwise, a new PT-TLS session needs to be established.
評価開始者がすでに評価応答者へのPT-TLSセッションを持っている場合、開始者はこのセッションを再利用できます。それ以外の場合は、新しいPT-TLSセッションを確立する必要があります。
In order for a PT-TLS Initiator to establish a TCP connection to a PT-TLS Responder, the initiator needs to know the TCP port number on which the responder is listening for assessment requests. The IANA has reserved TCP port number 271 for use by "pt-tls".
PT-TLSイニシエーターがPT-TLSレスポンダーへのTCP接続を確立するためには、イニシエーターは、レスポンダーが評価要求をlistenしているTCPポート番号を知る必要があります。 IANAは、「pt-tls」で使用するためにTCPポート番号271を予約しています。
As described in "The Network Endpoint Assessment (NEA) Asokan Attack Analysis" [RFC6813], a sophisticated Man-in-the-Middle (MITM) attack can be mounted against NEA systems. The attacker forwards PA-TNC messages from a healthy machine through an unhealthy one so that the unhealthy machine can gain network access. Because there are easier attacks on NEA systems, like having the unhealthy machine lie about its configuration, this attack is generally only mounted against machines with an External Measurement Agent (EMA). The EMA is a separate entity, difficult to compromise, that measures and attests to the configuration of the endpoint.
「ネットワークエンドポイントアセスメント（NEA）阿蘇館攻撃分析」[RFC6813]で説明されているように、洗練された中間者（MITM）攻撃をNEAシステムに対してマウントできます。攻撃者は、正常なマシンから正常でないマシンを介してPA-TNCメッセージを転送し、異常なマシンがネットワークにアクセスできるようにします。 NEAシステムへの攻撃は簡単です。たとえば、異常なマシンにその構成を偽らせるなどの理由により、この攻撃は通常、外部測定エージェント（EMA）を備えたマシンに対してのみ行われます。 EMAは、エンドポイントの構成を測定および証明する独立したエンティティであり、妥協が困難です。
To protect against NEA Asokan attacks, the Posture Broker Client on an EMA-equipped endpoint should pass the tls-unique channel binding [RFC5929] for PT-TLS's underlying TLS session to the EMA. This value can then be included in the EMA's attestation, and the Posture Validator responsible for communicating with the EMA may then confirm that the value matches the tls-unique channel binding for its end of the connection. If the values match, the posture sent by the EMA and NEA Client is from the same endpoint as the client side of the TLS connection (since the endpoint knows the tls-unique value), so no man-in-the-middle is forwarding posture. If they differ, the Asokan attack has been detected. The Posture Validator MUST fail its verification of the endpoint if the Asokan attack has been detected.
NEA Asokan攻撃から保護するために、EMAが装備されたエンドポイント上のPosture Broker Clientは、PT-TLSの基礎となるTLSセッションのtls-uniqueチャネルバインディング[RFC5929]をEMAに渡す必要があります。次に、この値をEMAの証明書に含めることができます。EMAとの通信を担当するPosture Validatorは、値が接続の終端のtls固有のチャネルバインディングと一致することを確認できます。値が一致する場合、EMAおよびNEAクライアントによって送信されるポスチャは、TLS接続のクライアント側と同じエンドポイントからのものであるため（エンドポイントはtls-unique値を知っているため）、中間者は転送しません。姿勢。異なる場合は、麻生館攻撃が検出されています。 Asokan攻撃が検出された場合、Posture Validatorはエンドポイントの検証に失敗する必要があります。
This section discusses the general flow of messages between the NEA Client's Posture Transport Client and the NEA Server's Posture Transport Server in order to perform NEA assessments using the PT-TLS protocol.
このセクションでは、PT-TLSプロトコルを使用してNEA評価を実行するために、NEAクライアントのポスチャトランスポートクライアントとNEAサーバーのポスチャトランスポートサーバーの間のメッセージの一般的なフローについて説明します。
Initially, the NEA Client or NEA Server will decide that an assessment is needed. What stimulates the decision to perform an assessment is outside the scope of this specification, but some examples include:
最初に、NEAクライアントまたはNEAサーバーは、評価が必要であると判断します。評価を実行する決定を刺激するものはこの仕様の範囲外ですが、いくつかの例は次のとおりです。
o NEA Server becoming aware of suspicious behavior on an endpoint
o NEAサーバーがエンドポイントでの疑わしい動作を認識するようになる
o NEA Server receiving new policies requiring immediate action
o NEAサーバーが即時のアクションを必要とする新しいポリシーを受信
o NEA Client noticing a change in local security posture
o ローカルのセキュリティ体制の変化に気づいたNEAクライアント
o NEA Client wishing to access a protected network or resource
o 保護されたネットワークまたはリソースへのアクセスを希望するNEAクライアント
Because either the NEA Client or NEA Server can trigger the establishment of the TLS session and initiate the assessment, this document will use the terms "assessment initiator" and "assessment responder". This nomenclature allows either NEA component to fill either of the PT-TLS roles.
NEAクライアントまたはNEAサーバーのいずれかがTLSセッションの確立をトリガーして評価を開始できるため、このドキュメントでは「評価開始者」と「評価応答者」という用語を使用します。この命名法により、いずれかのNEAコンポーネントがいずれかのPT-TLSの役割を果たします。
The PT-TLS message exchange occurs in three distinct phases:
PT-TLSメッセージ交換は、3つの異なるフェーズで行われます。
o TLS Setup (including TLS handshake protocol)
o TLSセットアップ（TLSハンドシェイクプロトコルを含む）
o PT-TLS Negotiation
o PT-TLSネゴシエーション
o PT-TLS Data Transport
o PT-TLSデータ転送
The TLS Setup phase is responsible for the establishment of the TCP connection and the TLS protections for the PT-TLS messages. The TLS Setup phase starts with the establishment of a TCP connection between the Posture Transport Client and Posture Transport Server. The new connection triggers the TLS server to start the TLS handshake protocol to establish the cryptographic protections for the session. Once the TLS Setup phase has completed (after the TLS Finished messages), the TLS session MUST NOT be renegotiated. TLS session renegotiation MAY be used before the TLS Setup phase ends and the PT-TLS Negotiation phase begins. This phase also enables the establishment of the tls-unique shared secret. The tls-unique shared secret can later be used by the PA protocol to protect against some forms of man-in-the-middle attacks.
TLSセットアップフェーズは、TCP接続の確立とPT-TLSメッセージのTLS保護を担当します。 TLSセットアップフェーズは、ポスチャトランスポートクライアントとポスチャトランスポートサーバー間のTCP接続の確立から始まります。新しい接続はTLSサーバーをトリガーしてTLSハンドシェイクプロトコルを開始し、セッションの暗号保護を確立します。 TLSセットアップフェーズが完了すると（TLS終了メッセージの後）、TLSセッションを再ネゴシエートしてはなりません（MUST NOT）。 TLSセッション再ネゴシエーションは、TLSセットアップフェーズが終了してPT-TLSネゴシエーションフェーズが開始する前に使用される場合があります。このフェーズでは、tls固有の共有秘密の確立も可能になります。 tls固有の共有シークレットは、後でPAプロトコルによって使用され、何らかの形の中間者攻撃から保護されます。
The PT-TLS Negotiation phase is only performed at the start of the first assessment on a TLS session. During this phase, the NEA Client and NEA Server discover each other's PT-TLS capabilities and establish a context that will apply to all future PT-TLS messages sent over the TLS session. The PT-TLS Negotiation phase MUST NOT be repeated after the session has entered the Data Transport phase. NEA assessment messages (PB-TNC batches) MUST NOT be sent by the NEA Client or NEA Server prior to the completion of the PT-TLS Negotiation phase to ensure that the security protections for the session are properly established and applied to the NEA assessment messages.
PT-TLSネゴシエーションフェーズは、TLSセッションの最初の評価の開始時にのみ実行されます。このフェーズでは、NEAクライアントとNEAサーバーが互いのPT-TLS機能を検出し、TLSセッションを介して送信される今後のすべてのPT-TLSメッセージに適用されるコンテキストを確立します。セッションがデータ転送フェーズに入った後は、PT-TLSネゴシエーションフェーズを繰り返さないでください。 NEA評価メッセージ（PB-TNCバッチ）は、セッションのセキュリティ保護が適切に確立され、NEA評価メッセージに適用されていることを確認するために、PT-TLSネゴシエーションフェーズの完了前にNEAクライアントまたはNEAサーバーから送信してはなりません（MUST NOT） 。
Finally, the Data Transport phase allows the NEA Client and NEA Server to exchange PT messages under the protection of the TLS session consistent with the capabilities established in earlier phases. The exchanged messages can be a PT-TLS protected NEA assessment as described in this specification or other vendor-defined PT-TLS exchanged messages.
最後に、データ転送フェーズでは、NEAクライアントとNEAサーバーが、以前のフェーズで確立された機能と一致するTLSセッションの保護の下でPTメッセージを交換できます。交換されるメッセージは、この仕様で説明されているPT-TLSで保護されたNEA評価、または他のベンダー定義のPT-TLS交換メッセージです。
After a new TCP connection is established between the Posture Transport Client and Posture Transport Server, a standard TLS exchange is performed to negotiate a common security context for protecting subsequent communications. As discussed in Section 3.1, the TCP connection establishment and/or the TLS handshake protocol could be initiated by either the NEA Client or NEA Server. The most common situation would be for the assessment initiator to trigger the creation of the TCP connection and TLS handshake, so an assessment could begin when no session already exists. When the NEA Server has initiated the TLS Setup, the NEA Server is acting as a TLS client and the NEA Client is the TLS server (accepting the inbound TLS session request). The expected normal case is that the NEA Client initiates this phase, so that the NEA Server is acting as the TLS server and therefore the bootstrapping of the security of the TLS session is using the NEA Server's certificate. Having the NEA Client initiate the TLS session avoids the need for the NEA Client to also possess a certificate.
ポスチャトランスポートクライアントとポスチャトランスポートサーバーの間に新しいTCP接続が確立されると、標準のTLS交換が実行され、後続の通信を保護するための共通のセキュリティコンテキストがネゴシエートされます。セクション3.1で説明したように、TCP接続の確立やTLSハンドシェイクプロトコルは、NEAクライアントまたはNEAサーバーのいずれかによって開始できます。最も一般的な状況は、評価開始者がTCP接続とTLSハンドシェイクの作成をトリガーすることです。そのため、セッションがまだ存在しないときに評価を開始できます。 NEAサーバーがTLSセットアップを開始すると、NEAサーバーはTLSクライアントとして機能し、NEAクライアントはTLSサーバーになります（インバウンドTLSセッション要求を受け入れます）。予想される通常のケースでは、NEAクライアントがこのフェーズを開始し、NEAサーバーがTLSサーバーとして機能しているため、TLSセッションのセキュリティのブートストラップはNEAサーバーの証明書を使用しています。 NEAクライアントにTLSセッションを開始させると、NEAクライアントが証明書を所有する必要がなくなります。
During the TLS Setup phase of PT-TLS, the PT-TLS Initiator contacts the listening port of the PT-TLS Responder and performs a TLS handshake. The PT-TLS Responder MUST possess a trustworthy X.509 certificate used to authenticate to the PT-TLS Initiator and used to bootstrap the security protections of the TLS session. The PT-TLS Initiator MAY also use an X.509 certificate to authenticate to the PT-TLS Responder providing for a bidirectional authentication of the PT-TLS session. The NEA Client MUST provide certificate validation according to the rules in RFC 5280 when evaluating the server certificate. The NEA Client MAY perform certificate revocation checking on the NEA Server's certificate. This specification allows the NEA Client implementation to decide on what certificate revocation technique is to be implemented. If revocation information is not provided in a TLS handshake extension, then clients performing certificate validation will require some network access (e.g., HTTP) to be allowed during the assessment. NEA Client network access to other non-essential services might be restricted during assessments in some situations. If the client cannot access the status information, then its policy may prevent it from completing the TLS handshake.
PT-TLSのTLSセットアップフェーズ中に、PT-TLSイニシエーターはPT-TLSレスポンダーのリスニングポートに接続し、TLSハンドシェイクを実行します。 PT-TLSレスポンダは、PT-TLSイニシエータへの認証に使用され、TLSセッションのセキュリティ保護のブートストラップに使用される、信頼できるX.509証明書を所有している必要があります。 PT-TLSイニシエーターは、X-509証明書を使用して、PT-TLSセッションの双方向認証を提供するPT-TLSレスポンダーに対して認証してもよい（MAY）。 NEAクライアントは、サーバー証明書を評価するときに、RFC 5280の規則に従って証明書検証を提供する必要があります。 NEAクライアントは、NEAサーバーの証明書に対して証明書失効チェックを実行する場合があります。この仕様により、NEAクライアント実装は、実装する証明書失効技術を決定できます。失効情報がTLSハンドシェイク拡張で提供されていない場合、証明書の検証を実行するクライアントは、評価中にいくつかのネットワークアクセス（HTTPなど）を許可する必要があります。状況によっては、他の重要でないサービスへのNEAクライアントネットワークアクセスが評価中に制限される場合があります。クライアントがステータス情報にアクセスできない場合、そのポリシーにより、TLSハンドシェイクを完了できない場合があります。
In addition, the NEA Client MUST follow the recommendations in RFC 6125 [RFC6125] when validating the NEA Server domain name against the contents of the server certificate, taking into consideration the following restrictions:
さらに、NEAクライアントは、次の制限を考慮して、サーバー証明書の内容に対してNEAサーバードメイン名を検証するときに、RFC 6125 [RFC6125]の推奨事項に従う必要があります。
o Any SRV-IDs and URI-IDs in the certificate are ignored.
o 証明書内のSRV-IDとURI-IDは無視されます。
o Use of CN-IDs in certificates is NOT RECOMMENDED.
o 証明書でのCN-IDの使用は推奨されません。
o Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate identifying a PT-TLS server.
o ワイルドカードは、PT-TLSサーバーを識別する証明書のDNS-IDまたはCN-IDに使用してはなりません（MUST NOT）。
Details for the reverse direction are given in Section 3.1.
逆方向の詳細については、セクション3.1を参照してください。
Due to deployment issues with issuing and distributing certificates to a potentially large number of NEA Clients, this specification allows the NEA Client to be authenticated during the PT-TLS Negotiation phase using other more cost-effective methods, as described in Section 3.8.1. At the conclusion of a successful initial TLS Setup phase, the NEA Client and NEA Server have a protected session to exchange messages. This allows the protocol to transition to the PT-TLS Negotiation phase.
証明書の発行と潜在的に多数のNEAクライアントへの配布に関する展開の問題のため、この仕様では、セクション3.8.1で説明されているように、他のより費用効果の高い方法を使用して、PT-TLSネゴシエーションフェーズ中にNEAクライアントを認証できます。最初のTLSセットアップフェーズが正常に完了すると、NEAクライアントとNEAサーバーはメッセージを交換するための保護されたセッションを持ちます。これにより、プロトコルはPT-TLSネゴシエーションフェーズに移行できます。
Once a TLS session has been established between a Posture Transport Client and Posture Transport Server, the PT-TLS Initiator sends a Version Request message indicating its supported PT-TLS protocol version range. Next, the PT-TLS Responder sends a Version Response message, which selects a protocol version from within the range offered. The PT-TLS Responder SHOULD select the preferred version offered if supported; otherwise, the highest version that the responder is able to support from the received Version Request message will be used. If the PT-TLS Responder is unable or unwilling to support any of the versions included in the Version Request message, the responder SHOULD send a Version Not Supported error message.
ポスチャトランスポートクライアントとポスチャトランスポートサーバー間でTLSセッションが確立されると、PT-TLSイニシエーターは、サポートされているPT-TLSプロトコルのバージョン範囲を示すバージョン要求メッセージを送信します。次に、PT-TLSレスポンダは、バージョン応答メッセージを送信し、提供された範囲内からプロトコルバージョンを選択します。 PT-TLSレスポンダは、サポートされている場合に提供される優先バージョンを選択する必要があります（SHOULD）。それ以外の場合は、受信したバージョン要求メッセージからレスポンダがサポートできる最も高いバージョンが使用されます。 PT-TLSレスポンダがバージョンリクエストメッセージに含まれるバージョンのいずれかをサポートできない、またはサポートしたくない場合、レスポンダはバージョンがサポートされていないというエラーメッセージを送信する必要があります（SHOULD）。
If no client-side authentication occurred during the TLS Setup phase, the Posture Transport Server can authenticate the client using PT-TLS client authentication messages as described in Section 3.8. The NEA Server initiates the client authentication and indicates when the authentication is complete.
TLSセットアップフェーズ中にクライアント側の認証が発生しなかった場合、ポスチャトランスポートサーバーは、セクション3.8で説明されているように、PT-TLSクライアント認証メッセージを使用してクライアントを認証できます。 NEAサーバーはクライアント認証を開始し、認証が完了したことを示します。
When the NEA Client receives the Simple Authentication and Security Layer (SASL) [RFC4422] Mechanisms list, the NEA Client responds with a SASL Mechanism Selection TLV indicating the method of authentication to be used. Upon selecting an appropriate SASL mechanism, the NEA Client and Server exchange SASL-mechanism-specific messages in order to authenticate the NEA Client. When the client authentication successfully completes and no additional authentications are required (as indicated by the NEA Server sending an empty SASL Mechanisms list), the PT-TLS session transitions into the Data Transport phase, where it will remain for the duration of the session. Note that the NEA Server could choose to not authenticate the client (indicated by only sending an empty SASL Mechanisms list) or to continue performing a posture assessment even if the authentication did not complete successfully.
NEAクライアントがSimple Authentication and Security Layer（SASL）[RFC4422]メカニズムリストを受信すると、NEAクライアントは、使用する認証方法を示すSASLメカニズム選択TLVで応答します。適切なSASLメカニズムを選択すると、NEAクライアントとサーバーは、NEAクライアントを認証するためにSASLメカニズム固有のメッセージを交換します。クライアント認証が正常に完了し、追加の認証が必要ない場合（NEAサーバーが空のSASLメカニズムリストを送信することで示される）、PT-TLSセッションはデータトランスポートフェーズに移行し、セッションの期間中残ります。 NEAサーバーは、クライアントを認証しない（空のSASLメカニズムリストのみを送信することで示される）か、認証が正常に完了しなかった場合でもポスチャ評価の実行を継続することを選択できることに注意してください。
Once a PT-TLS session is available to carry NEA assessments, PT-TLS allows either side of the connection to send the first PB-TNC batch. The PB-TNC standard prescribes whether the Posture Broker Client or Posture Broker Server starts the assessment. The assessment initiator first envelopes the PB-TNC batch in a PT-TLS message, then assigns a message identifier to the message and finally transmits it over the session. The assessment responder validates the PT-TLS message and delivers the encapsulated PB-TNC batch to its upstream component (Posture Broker Client or Server).
PT-TLSセッションでNEA評価を実行できるようになると、PT-TLSにより、接続のどちらの側からも最初のPB-TNCバッチを送信できます。 PB-TNC標準は、Posture Broker ClientまたはPosture Broker Serverが評価を開始するかどうかを規定しています。評価の開始者は、最初にPB-TNCバッチをPT-TLSメッセージにエンベロープし、次にメッセージ識別子をメッセージに割り当て、最後にセッションを介して送信します。評価レスポンダはPT-TLSメッセージを検証し、カプセル化されたPB-TNCバッチをその上流コンポーネント（ポスチャブローカークライアントまたはサーバー）に配信します。
Most PT-TLS messages contain PB-TNC batches that house PA-TNC requests for posture information or a response containing the requested posture information. The Posture Transport Client and Posture Transport Server may also exchange messages between them, such as a PT-TLS Error message indicating that a problem occurred processing a message. During an assessment, the Posture Transport Client and Server merely encapsulate and exchange the PB-TNC batches and are unaware of the state of the assessment.
ほとんどのPT-TLSメッセージには、姿勢情報のPA-TNC要求または要求された姿勢情報を含む応答を格納するPB-TNCバッチが含まれています。ポスチャトランスポートクライアントとポスチャトランスポートサーバーは、メッセージの処理中に問題が発生したことを示すPT-TLSエラーメッセージなど、それらの間でメッセージを交換する場合もあります。評価中、ポスチャトランスポートクライアントとサーバーはPB-TNCバッチをカプセル化して交換するだけで、評価の状態を認識しません。
The PT-TLS protocol allows either party to send a PT-TLS message at any time, reflecting the full-duplex nature of the underlying TLS session. For example, an assessment initiator may send several PT-TLS messages prior to receiving any responses from the assessment responder. All implementations of PT-TLS MUST support full-duplex PT-TLS message exchange. However, some higher-layer NEA protocols (e.g., PB-TNC) may not be able to fully make use of the full-duplex message exchange.
PT-TLSプロトコルを使用すると、どちらの当事者もいつでもPT-TLSメッセージを送信でき、基礎となるTLSセッションの全二重の性質を反映します。たとえば、評価開始者は、評価応答者からの応答を受信する前に、いくつかのPT-TLSメッセージを送信できます。 PT-TLSのすべての実装は、全二重PT-TLSメッセージ交換をサポートする必要があります。ただし、一部の上位層のNEAプロトコル（PB-TNCなど）では、全二重メッセージ交換を完全に利用できない場合があります。
In order to ensure that strong security is always available for deployers and to improve interoperability, this section discusses some requirements on the underlying TLS transport used by PT-TLS. Whenever TLS is used by this specification, the appropriate version (or versions) of TLS will vary over time, based on the widespread deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but it has a very limited deployment base and might not be readily available for implementation. TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] are the most widely deployed versions and will provide the broadest interoperability. Implementations of PT-TLS SHOULD support use of TLS 1.2.
デプロイヤーが常に強力なセキュリティを利用できるようにし、相互運用性を向上させるために、このセクションでは、PT-TLSで使用される基になるTLSトランスポートのいくつかの要件について説明します。この仕様でTLSが使用されている場合は常に、TLSの適切なバージョン（1つまたは複数）は、広範囲にわたる展開と既知のセキュリティの脆弱性に基づいて、時間とともに変化します。これを書いている時点では、TLSバージョン1.2 [RFC5246]が最新バージョンですが、デプロイメントベースが非常に限定されており、実装にすぐに利用できない場合があります。 TLSバージョン1.0 [RFC2246]とバージョン1.1 [RFC4346]は、最も広く展開されているバージョンであり、幅広い相互運用性を提供します。 PT-TLSの実装は、TLS 1.2の使用をサポートする必要があります（SHOULD）。
For each TLS version supported, implementations of the PT-TLS protocol MUST at least support the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. This cipher suite requires the server to provide a certificate that can be used during the key exchange. Implementations SHOULD NOT include support for cipher suites that do not minimally offer PT-TLS Responder (typically Posture Transport Server) authentication, such as the anonymous Diffie-Hellman cipher suites (e.g., TLS_DH_anon_WITH_AES_128_CBC_SHA). Implementations MUST support RFC 5746 [RFC5746]. Implementations MAY allow renegotiation to provide confidentiality for the client certificate. If renegotiation is allowed, implementations need to select the appropriate handshake messages as described in RFC 5929 for the tls-unique value.
サポートされる各TLSバージョンについて、PT-TLSプロトコルの実装は、少なくともTLS_RSA_WITH_AES_128_CBC_SHA暗号スイートをサポートする必要があります。この暗号スイートでは、サーバーは、鍵交換中に使用できる証明書を提供する必要があります。実装には、匿名のDiffie-Hellman暗号スイート（TLS_DH_anon_WITH_AES_128_CBC_SHAなど）などのPT-TLS Responder（通常はPosture Transport Server）認証を最小限に提供しない暗号スイートのサポートを含めないでください。実装はRFC 5746 [RFC5746]をサポートする必要があります。実装は、再ネゴシエーションがクライアント証明書に機密性を提供することを許可する場合があります。再ネゴシエーションが許可されている場合、実装は、tls-unique値についてRFC 5929で説明されているように、適切なハンドシェイクメッセージを選択する必要があります。
This section describes the format and semantics of the PT-TLS message. Every message sent over a PT-TLS session MUST start with the PT-TLS header described in this section.
このセクションでは、PT-TLSメッセージの形式とセマンティクスについて説明します。 PT-TLSセッションを介して送信されるすべてのメッセージは、このセクションで説明されているPT-TLSヘッダーで始まる必要があります。
The PT-TLS header format is as follows:
PT-TLSヘッダーの形式は次のとおりです。
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 | Message Type Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Value (e.g., PB-TNC Batch) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約済み
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
将来の使用のために予約されています。このフィールドは送信時に0に設定されなければならず、受信時には無視されなければなりません。
Message Type Vendor ID
メッセージタイプベンダーID
This field indicates the owner of the namespace associated with the message type. This is accomplished by specifying the 24-bit Structure of Management Information (SMI) Private Enterprise Number [PEN] (Vendor ID) of the party who owns the message type namespace. Consistent with PA-TNC and PB-TNC, we depend on the PEN fitting in 24 bits, so if IANA were to register a wider PEN, then that PEN could not be used with NEA. IETF namespace PT-TLS Message Types MUST use zero (0) in this field. For more information about the intended use of NEA namespace identifiers, see the PA-TNC specification (RFC 5792), Sections 2.1 and 2.2.
このフィールドは、メッセージタイプに関連付けられている名前空間の所有者を示します。これは、メッセージタイプのネームスペースを所有するパーティの管理情報（SMI）のプライベートエンタープライズ番号[PEN]（ベンダーID）の24ビット構造を指定することによって実現されます。 PA-TNCおよびPB-TNCと一貫して、24ビットのPENフィッティングに依存しているため、IANAがより広いPENを登録する場合、そのPENはNEAで使用できませんでした。 IETF名前空間PT-TLSメッセージタイプでは、このフィールドでゼロ（0）を使用する必要があります。 NEA名前空間識別子の使用目的の詳細については、PA-TNC仕様（RFC 5792）、セクション2.1および2.2を参照してください。
The PT-TLS Message Type Vendor ID 0xffffff is reserved. Posture Transport Clients and Servers MUST NOT send PT-TLS messages in which the PT-TLS Message Type Vendor ID has this reserved value (0xffffff). If a Posture Transport Client or Posture Transport Server receives a message containing this reserved value (0xffffff) in the PT-TLS Message Type Vendor ID, the recipient SHOULD respond with an Invalid Parameter error code in a PT-TLS Error message.
PT-TLSメッセージタイプベンダーID 0xffffffは予約されています。ポスチャトランスポートクライアントおよびサーバーは、PT-TLSメッセージタイプベンダーIDがこの予約値（0xffffff）を持つPT-TLSメッセージを送信してはなりません（MUST NOT）。ポスチャトランスポートクライアントまたはポスチャトランスポートサーバーがこの予約値（0xffffff）を含むメッセージをPT-TLSメッセージタイプベンダーIDで受信した場合、受信者はPT-TLSエラーメッセージで無効なパラメーターのエラーコードで応答する必要があります。
Message Type
メッセージタイプ
This field defines the type of the PT-TLS message within the scope of the specified Message Type Vendor ID that is included in the Message Value field. The specific IETF-defined values allowable in this field when the Message Type Vendor ID is the IETF SMI Private Enterprise Number value (0) are defined in Section 3.6. Recipients of a message containing a Message Type Vendor ID and a message type that is unrecognized SHOULD respond with a Type Not Supported error code in a PT-TLS Error message.
このフィールドは、メッセージ値フィールドに含まれる指定されたメッセージタイプベンダーIDのスコープ内のPT-TLSメッセージのタイプを定義します。メッセージタイプベンダーIDがIETF SMIプライベートエンタープライズ番号の値（0）である場合にこのフィールドで許可される特定のIETF定義の値は、セクション3.6で定義されています。メッセージタイプベンダーIDを含むメッセージの受信者と、認識されないメッセージタイプは、PT-TLSエラーメッセージの「サポートされていないタイプ」エラーコードで応答する必要があります。
Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-defined PT-TLS Message Types in order to interoperate with other PT-TLS compliant implementations (although implementations MAY permit administrators to configure them to require support for specific vendor-defined PT-TLS Message Types).
ポスチャトランスポートクライアントとポスチャトランスポートサーバーは、他のPT-TLS準拠の実装と相互運用するために、特定のベンダー定義のPT-TLSメッセージタイプのサポートを必要としてはなりません（ただし、実装は、管理者が特定のベンダー定義のPTのサポートを要求するように構成することを許可する場合があります） -TLSメッセージタイプ）。
If the PT-TLS Message Type Vendor ID field has the value zero (0), then the PT-TLS Message Type field contains an IETF namespace PT-TLS Message Type, as listed in the IANA registry. IANA maintains a registry of PT-TLS Message Types. Entries in this registry are added following the IANA Specification Required policy, following the guidelines in Section 6.1. Section 3.6 of this specification defines the initial set of IETF-defined PT-TLS Message Types.
PT-TLSメッセージタイプベンダーIDフィールドの値がゼロ（0）の場合、PT-TLSメッセージタイプフィールドには、IANAレジストリにリストされているIETF名前空間PT-TLSメッセージタイプが含まれます。 IANAはPT-TLSメッセージタイプのレジストリを維持しています。このレジストリのエントリは、セクション6.1のガイドラインに従って、IANA Specification Requiredポリシーに従って追加されます。この仕様のセクション3.6は、IETF定義のPT-TLSメッセージタイプの初期セットを定義しています。
The PT-TLS Message Type 0xffffffff is reserved. Posture Transport Clients and Posture Transport Servers MUST NOT send PT-TLS messages in which the PT-TLS Message Type has this reserved value (0xffffffff). If a Posture Transport Client or Posture Transport Server receives a message in which the PT-TLS Message Type has this reserved value (0xffffffff), it SHOULD respond with an Invalid Parameter error code in a PT-TLS Error message.
PT-TLSメッセージタイプ0xffffffffは予約されています。ポスチャトランスポートクライアントとポスチャトランスポートサーバーは、PT-TLSメッセージタイプにこの予約値（0xffffffff）があるPT-TLSメッセージを送信してはなりません（MUST NOT）。ポスチャトランスポートクライアントまたはポスチャトランスポートサーバーが、PT-TLSメッセージタイプにこの予約値（0xffffffff）が含まれるメッセージを受信した場合、PT-TLSエラーメッセージで無効なパラメーターエラーコードで応答する必要があります（SHOULD）。
Message Length
メッセージの長さ
This field contains the length in octets of the entire PT-TLS message (including the entire header). Therefore, this value MUST always be at least 16. Any Posture Transport Client or Posture Transport Server that receives a message with a PT-TLS Message Length field whose value is less than 16 SHOULD respond with an Invalid Parameter PT-TLS Error Code. Similarly, if a Posture Transport Client or Posture Transport Server receives a PT-TLS message for a Message Type that has a known Message Length and the Message Length indicates a different value (greater or less than the expected value), the recipient SHOULD respond with an Invalid Parameter PT-TLS Error Code.
このフィールドには、PT-TLSメッセージ全体（ヘッダー全体を含む）のオクテットの長さが含まれます。したがって、この値は常に少なくとも16である必要があります。値が16未満のPT-TLSメッセージ長フィールドを持つメッセージを受信するポスチャトランスポートクライアントまたはポスチャトランスポートサーバーは、無効なパラメータPT-TLSエラーコードで応答する必要があります。同様に、ポスチャトランスポートクライアントまたはポスチャトランスポートサーバーが、既知のメッセージ長を持つメッセージタイプのPT-TLSメッセージを受信し、メッセージ長が異なる値（予想値より大きいまたは小さい）を示している場合、受信者は無効なパラメータPT-TLSエラーコード。
Message Identifier
メッセージ識別子
This field contains a value that uniquely identifies the PT-TLS message on a per message sender (Posture Transport Client or Server) basis. This value is copied into the body of the PT-TLS Error message so the recipient can determine which message caused the error.
このフィールドには、メッセージの送信者（ポスチャトランスポートクライアントまたはサーバー）ごとにPT-TLSメッセージを一意に識別する値が含まれます。この値はPT-TLSエラーメッセージの本文にコピーされるため、受信者はエラーの原因となったメッセージを判別できます。
The Message Identifier MUST be a monotonically increasing counter starting at zero indicating the number of the messages the sender has transmitted over the TLS session. It is possible that a busy or long-lived session might exceed 2^32-1 messages sent, so the message sender MUST roll over to zero upon reaching the 2^32nd message, thus restarting the increasing counter. During a rollover, it is feasible that the message recipient could be confused if it keeps track of every previously received Message Identifier, so recipients MUST be able to handle rollover situations without generating errors.
メッセージIDは、送信者がTLSセッションを介して送信したメッセージの数を示す、ゼロから始まる単調に増加するカウンターである必要があります。ビジーまたは長期間のセッションが送信された2 ^ 32-1メッセージを超える可能性があるため、メッセージ送信者は2 ^ 32番目のメッセージに到達するとゼロにロールオーバーし、増加するカウンターを再起動する必要があります。ロールオーバー中に、以前に受信したすべてのメッセージIDを追跡し続けると、メッセージ受信者が混乱する可能性があるため、受信者はエラーを生成せずにロールオーバー状況を処理できる必要があります。
Message Value
メッセージ値
The contents of this field vary depending on the particular Message Type Vendor ID and Message Type given in the PT-TLS header for this PT-TLS message. This field most frequently contains a PB-TNC batch. The contents of this field for each of the initial IETF namespace PT-TLS Message Types are defined in this specification.
このフィールドの内容は、このPT-TLSメッセージのPT-TLSヘッダーで指定された特定のメッセージタイプベンダーIDおよびメッセージタイプによって異なります。このフィールドには、最も頻繁にPB-TNCバッチが含まれます。各IETF名前空間のPT-TLSメッセージタイプのこのフィールドの内容は、この仕様で定義されています。
This section defines the NEA standard PT-TLS Message Types used to carry PT-TLS messages and PB-TNC batches between the Posture Transport Client and Posture Transport Server.
このセクションでは、ポスチャトランスポートクライアントとポスチャトランスポートサーバーの間でPT-TLSメッセージとPB-TNCバッチを伝送するために使用されるNEA標準PT-TLSメッセージタイプを定義します。
The following table summarizes the initial set of IETF-defined message type values, which are used with the PT-TLS Message Type Vendor ID field set to the IETF SMI PEN (0). Note that the IANA administers a PEN value of 0 on behalf of the IETF. These descriptions only apply to the IETF namespace.
次の表は、IETF定義のメッセージタイプ値の初期セットをまとめたもので、PT-TLSメッセージタイプベンダーIDフィールドをIETF SMI PEN（0）に設定して使用されます。 IANAはIETFに代わってPEN値0を管理することに注意してください。これらの説明は、IETF名前空間にのみ適用されます。
Value (Name) Definition
---------------------------- ---------------------------------------
0 (Experimental) Reserved for experimental use. This
type will not offer interoperability
but allows for experimentation. This
message type MUST only be sent when the
NEA Client and NEA Server are in the
Data Transport phase and only on a
restricted, experimental network.
Compliant implementations MUST send an
Invalid Message error code in a PT-TLS
Error message if an Experimental
message is received.
1 (Version Request) Version negotiation request including the range of versions supported by the sender. This message type MUST only be sent by the TLS session initiator as the first PT-TLS message in the PT-TLS Negotiation phase. Recipients MUST send an Invalid Message error code in a PT-TLS Error message if a Version Request is received at another time.
1（バージョン要求）送信者がサポートするバージョンの範囲を含むバージョンネゴシエーション要求。このメッセージタイプは、PT-TLSネゴシエーションフェーズの最初のPT-TLSメッセージとして、TLSセッションイニシエーターによってのみ送信される必要があります。受信者は、別のときにバージョン要求を受信した場合、PT-TLSエラーメッセージで無効なメッセージエラーコードを送信する必要があります。
2 (Version Response) PT-TLS protocol version selected by the responder. This message type MUST only be sent by the PT-TLS Responder as the second message in the PT-TLS Negotiation phase. Recipients MUST send an Invalid Message error code in a PT-TLS Error message if a Version Response is received at another time.
2（バージョン応答）レスポンダによって選択されたPT-TLSプロトコルバージョン。このメッセージタイプは、PT-TLSネゴシエーションフェーズの2番目のメッセージとして、PT-TLSレスポンダによってのみ送信される必要があります。受信者は、別のときにバージョン応答を受信した場合、PT-TLSエラーメッセージで無効なメッセージエラーコードを送信する必要があります。
3 (SASL Mechanisms) Sent by the NEA Server to indicate what SASL mechanisms it is willing to use for authentication on this session. This message type MUST only be sent by the NEA Server in the PT-TLS Negotiation phase. The NEA Client MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Mechanisms message is received at another time.
3（SASLメカニズム）NEAサーバーから送信され、このセッションでの認証に使用するSASLメカニズムを示します。このメッセージタイプは、PT-TLSネゴシエーションフェーズでのみNEAサーバーによって送信される必要があります。 SASLメカニズムメッセージが別の時間に受信された場合、NEAクライアントは、PT-TLSエラーメッセージで無効なメッセージエラーコードを送信する必要があります。
4 (SASL Mechanism Selection) Sent by the NEA Client to select a SASL mechanism from the list offered by the NEA Server. This message type MUST only be sent by the NEA Client in the PT-TLS Negotiation phase. The NEA Server MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Mechanism Selection is received after the PT-TLS Negotiation phase. Once a SASL mechanism has been selected, it may not change until the mechanism completes either successfully or as a failure.
4（SASLメカニズムの選択）NEAサーバーによって提供されるリストからSASLメカニズムを選択するためにNEAクライアントによって送信されます。このメッセージタイプは、PT-TLSネゴシエーションフェーズでのみNEAクライアントによって送信される必要があります。 PT-TLSネゴシエーションフェーズの後にSASLメカニズム選択を受信した場合、NEAサーバーは、PT-TLSエラーメッセージで無効なメッセージエラーコードを送信する必要があります。 SASLメカニズムが選択されると、メカニズムが正常に完了するか、失敗するまで変更されない場合があります。
5 (SASL Authentication Data) Opaque octets exchanged between the NEA Client and NEA Server's SASL mechanisms to perform the client authentication. This message type MUST only be sent during the PT-TLS Negotiation phase. Recipients MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Authentication Data message is received after the PT-TLS Negotiation phase.
5（SASL認証データ）クライアント認証を実行するためにNEAクライアントとNEAサーバーのSASLメカニズム間で交換される不透明オクテット。このメッセージタイプは、PT-TLSネゴシエーションフェーズ中にのみ送信する必要があります。 PT-TLSネゴシエーションフェーズの後にSASL認証データメッセージを受信した場合、受信者はPT-TLSエラーメッセージで無効なメッセージエラーコードを送信する必要があります。
6 (SASL Result) Indicates the result code of the SASL mechanism authentication as described in Section 3.8.10. This message type MUST only be sent by the NEA Server when the NEA Client and NEA Server are in the PT-TLS Negotiation phase. The NEA Client MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Result is received after the PT-TLS Negotiation phase.
6（SASL Result）セクション3.8.10で説明されているSASLメカニズム認証の結果コードを示します。このメッセージタイプは、NEAクライアントとNEAサーバーがPT-TLSネゴシエーションフェーズにあるときにのみ、NEAサーバーによって送信される必要があります。 PT-TLSネゴシエーションフェーズの後にSASL結果を受信した場合、NEAクライアントは、PT-TLSエラーメッセージで無効なメッセージエラーコードを送信する必要があります。
7 (PB-TNC Batch) Contains a PB-TNC batch. For more information on PB-TNC batches, see RFC 5793 (PB-TNC) Section 4. This message type MUST only be sent when the NEA Client and NEA Server are in the PT-TLS Data Transport phase. Recipients SHOULD send an Invalid Message error code in a PT-TLS Error message if a PB-TNC Batch is received outside of the Data Transport phase.
7（PB-TNCバッチ）PB-TNCバッチが含まれます。 PB-TNCバッチの詳細については、RFC 5793（PB-TNC）セクション4を参照してください。このメッセージタイプは、NEAクライアントとNEAサーバーがPT-TLSデータ転送フェーズにある場合にのみ送信する必要があります。データトランスポートフェーズ外でPB-TNCバッチを受信した場合、受信者はPT-TLSエラーメッセージで無効なメッセージエラーコードを送信する必要があります（SHOULD）。
8 (PT-TLS Error) PT-TLS Error message as described in Section 3.9. This message type may be used during any PT-TLS phase.
8（PT-TLSエラー）セクション3.9で説明されているPT-TLSエラーメッセージ。このメッセージタイプは、あらゆるPT-TLSフェーズで使用できます。
9-4294967294 (Unassigned) These values are for future allocation following guidelines defined in the IANA Considerations section (see Section 6.1). Recipients of unsupported messages in the IETF namespace using a message type of 9 to 4294967294 MUST respond with a Type Not Supported PT-TLS Error Code in a PT-TLS Error message.
9-4294967294（未割り当て）これらの値は、IANAの考慮事項セクション（セクション6.1を参照）で定義されたガイドラインに従う将来の割り当て用です。 9から4294967294までのメッセージタイプを使用するIETF名前空間でサポートされていないメッセージの受信者は、PT-TLSエラーメッセージでサポートされていないタイプのPT-TLSエラーコードで応答する必要があります。
4294967295 Reserved
4294967295予約済み
This section describes the message format and semantics for the PT-TLS protocol version negotiation. This exchange is used by the PT-TLS Initiator to trigger a version negotiation at the start of an assessment. The PT-TLS Initiator MUST send a Version Request message as its first PT-TLS message and MUST NOT send any other PT-TLS messages on this connection until it receives a Version Response message or an Error message. The PT-TLS Responder MUST complete the version negotiation (or cause an error) prior to sending or accepting reception of any additional messages. After the successful completion of the version negotiation, both the Posture Transport Client and Posture Transport Server MUST only send messages compliant with the negotiated protocol version. Subsequent assessments on the same session MUST use the negotiated version number and therefore MUST NOT send additional version negotiation messages.
このセクションでは、PT-TLSプロトコルバージョンネゴシエーションのメッセージフォーマットとセマンティクスについて説明します。この交換は、評価の開始時にバージョンネゴシエーションをトリガーするためにPT-TLSイニシエーターによって使用されます。 PT-TLSイニシエーターは、バージョン要求メッセージを最初のPT-TLSメッセージとして送信する必要があり、バージョン応答メッセージまたはエラーメッセージを受信するまで、この接続で他のPT-TLSメッセージを送信してはなりません。 PT-TLSレスポンダは、追加のメッセージを受信または送信する前に、バージョンネゴシエーションを完了する（またはエラーを引き起こす）必要があります。バージョンネゴシエーションが正常に完了した後、ポスチャトランスポートクライアントとポスチャトランスポートサーバーの両方が、ネゴシエートされたプロトコルバージョンに準拠したメッセージのみを送信する必要があります。同じセッションでの後続の評価では、ネゴシエートされたバージョン番号を使用する必要があるため、追加のバージョンネゴシエーションメッセージを送信してはなりません（MUST NOT）。
This message is sent by a PT-TLS Initiator as the first PT-TLS message in a PT-TLS session. This message discloses the sender's supported versions of the PT-TLS protocol. To ensure compatibility, this message MUST always be sent using version 1 of the PT-TLS protocol. Recipients of this message MUST respond with a Version Response or with a PT-TLS Error message (Version Not Supported or Invalid Message). The following diagram shows the format of the Version Request message:
このメッセージは、PT-TLSセッションの最初のPT-TLSメッセージとしてPT-TLSイニシエーターによって送信されます。このメッセージは、送信者がサポートするPT-TLSプロトコルのバージョンを開示します。互換性を確保するために、このメッセージは常にPT-TLSプロトコルのバージョン1を使用して送信する必要があります。このメッセージの受信者は、バージョン応答またはPT-TLSエラーメッセージ（バージョンがサポートされていないか、無効なメッセージ）で応答する必要があります。次の図は、バージョン要求メッセージのフォーマットを示しています。
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 | Min Vers | Max Vers | Pref Vers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約済み
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
将来の使用のために予約されています。このフィールドは送信時に0に設定されなければならず、受信時には無視されなければなりません。
Min Vers
最小
This field contains the minimum version of the PT-TLS protocol supported by the sender. This field MUST be set to 1 indicating support for the first version of PT-TLS. However, future versions of this specification will probably remove this requirement, so PT-TLS Responders MUST be prepared to receive other values.
このフィールドには、送信者がサポートするPT-TLSプロトコルの最小バージョンが含まれています。このフィールドは、PT-TLSの最初のバージョンのサポートを示す1に設定する必要があります。ただし、この仕様の将来のバージョンではおそらくこの要件が削除されるため、PT-TLSレスポンダは他の値を受信できるように準備する必要があります。
Max Vers
最大
This field contains the maximum version of the PT-TLS protocol supported by the sender. This field MUST be set to 1 indicating support for the first version of PT-TLS. However, future versions of this specification will probably remove this requirement, so PT-TLS Responders MUST be prepared to receive other values.
このフィールドには、送信者がサポートするPT-TLSプロトコルの最大バージョンが含まれています。このフィールドは、PT-TLSの最初のバージョンのサポートを示す1に設定する必要があります。ただし、この仕様の将来のバージョンではおそらくこの要件が削除されるため、PT-TLSレスポンダは他の値を受信できるように準備する必要があります。
Pref Vers
好み
This field contains the sender's preferred version of the PT-TLS protocol. This is a hint to the recipient that the sender would like this version selected if supported. The value of this field MUST fall within the range of Min Vers to Max Vers. This field MUST be set to 1 indicating support for the first version of PT-TLS. However, future versions of this specification will probably remove this requirement, so PT-TLS Responders MUST be prepared to receive other values.
このフィールドには、PT-TLSプロトコルの送信者の優先バージョンが含まれています。これは、サポートされている場合に送信者がこのバージョンを選択することを希望する受信者へのヒントです。このフィールドの値は、Min VersからMax Versの範囲内でなければなりません。このフィールドは、PT-TLSの最初のバージョンのサポートを示す1に設定する必要があります。ただし、この仕様の将来のバージョンではおそらくこの要件が削除されるため、PT-TLSレスポンダは他の値を受信できるように準備する必要があります。
This message is sent in response to receiving a Version Request message at the start of a new assessment session. If a recipient receives a Version Request after a successful version negotiation has occurred on the session, the recipient MUST send an Invalid Message error code in a PT-TLS Error message and have TLS close the session. This message MUST be sent using the syntax, semantics, and requirements of the protocol version specified in this message.
このメッセージは、新しい評価セッションの開始時にバージョン要求メッセージを受信したことに応答して送信されます。セッションでバージョンネゴシエーションが成功した後に受信者がバージョンリクエストを受信した場合、受信者はPT-TLSエラーメッセージで無効なメッセージエラーコードを送信し、TLSでセッションを閉じる必要があります。このメッセージは、このメッセージで指定されたプロトコルバージョンの構文、セマンティクス、および要件を使用して送信する必要があります。
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 | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約済み
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
将来の使用のために予約されています。このフィールドは送信時に0に設定されなければならず、受信時には無視されなければなりません。
Version
バージョン
This field contains the version selected by the sender of this message. The version selected MUST be within the Min Vers to Max Vers inclusive range sent in the Version Request message. If a PT-TLS Initiator receives a message with an invalid Version selected, the PT-TLS Initiator MUST respond with a Version Not Supported PT-TLS Error message.
このフィールドには、このメッセージの送信者が選択したバージョンが含まれています。選択されたバージョンは、バージョン要求メッセージで送信された最小バージョンから最大バージョンまでの範囲内である必要があります。 PT-TLSイニシエーターが無効なバージョンが選択されたメッセージを受信した場合、PT-TLSイニシエーターは、サポートされていないバージョンのPT-TLSエラーメッセージで応答する必要があります。
This section includes a description of the message format and semantics necessary to perform client authentication (authentication of the NEA Client) over PT-TLS. Client authentication could be necessary if the NEA Server requires such an authentication and it was not performed during the TLS handshake. The general model used for performing an authentication of the client using PT-TLS messages is to integrate the Simple Authentication and Security Layer (SASL) [RFC4422] framework. SASL provides a number of standards-based authentication mechanisms capable of authenticating the NEA Client using a variety of base technologies.
このセクションでは、PT-TLSを介したクライアント認証（NEAクライアントの認証）を実行するために必要なメッセージ形式とセマンティクスについて説明します。 NEAサーバーがそのような認証を必要とし、TLSハンドシェイク中に実行されなかった場合、クライアント認証が必要になる可能性があります。 PT-TLSメッセージを使用してクライアントの認証を実行するために使用される一般的なモデルは、Simple Authentication and Security Layer（SASL）[RFC4422]フレームワークを統合することです。 SASLは、さまざまな基本テクノロジーを使用してNEAクライアントを認証できる、標準ベースの認証メカニズムをいくつか提供します。
Client authentication could occur during the TLS handshake using TLS-defined authentication techniques. Because this client authentication is optional, the NEA Server's policy might require the client to be authenticated by PT-TLS before performing the assessment. Similarly, the NEA Server may require a PT-TLS authentication even if the NEA Client was authenticated during the TLS handshake (e.g., to allow a user authentication after a system-level authentication occurred during the TLS handshake). The decision of whether a SASL client authentication is to occur is left to the NEA Server's policy.
クライアント認証は、TLS定義の認証技術を使用したTLSハンドシェイク中に発生する可能性があります。このクライアント認証はオプションであるため、NEAサーバーのポリシーでは、評価を実行する前にPT-TLSでクライアントを認証する必要がある場合があります。同様に、NEAクライアントがTLSハンドシェイク中に認証された場合でも、NEAサーバーはPT-TLS認証を必要とする場合があります（たとえば、TLSハンドシェイク中にシステムレベルの認証が発生した後にユーザー認証を許可するため）。 SASLクライアント認証を実行するかどうかの決定は、NEAサーバーのポリシーに任されています。
As discussed in Section 3.1.1, it is possible that the NEA Server may initiate the TLS session to the NEA Client, thus causing it to fill the role of TLS client during the TLS handshake. Because the NEA Server is required to possess an X.509 certificate for those times when it is acting as the TLS server (normal case), PT-TLS requires that the NEA Server MUST use its X.509 certificate for TLS client authentication during the TLS handshake to authenticate itself even when it is acting as the TLS client. In this case, the NEA Client and NEA Server will authenticate using certificates during the TLS handshake, so the PT-TLS SASL client authentication might not be required unless NEA Server policy required an additional authentication of the NEA Client. Therefore, the normal usage for the SASL messages is when the NEA Client acted as the TLS client and did not authenticate during the TLS handshake.
セクション3.1.1で説明したように、NEAサーバーがNEAクライアントへのTLSセッションを開始し、TLSハンドシェイク中にTLSクライアントの役割を果たす可能性があります。 NEAサーバーは、TLSサーバーとして機能しているとき（通常の場合）にX.509証明書を所有する必要があるため、PT-TLSでは、NEAサーバーがTLSクライアント認証にX.509証明書を使用する必要があります。 TLSハンドシェイクは、TLSクライアントとして機能している場合でも、自身を認証します。この場合、NEAクライアントとNEAサーバーはTLSハンドシェイク中に証明書を使用して認証するため、NEAサーバーポリシーでNEAクライアントの追加認証が必要でない限り、PT-TLS SASLクライアント認証は必要ない場合があります。したがって、SASLメッセージの通常の使用法は、NEAクライアントがTLSクライアントとして機能し、TLSハンドシェイク中に認証されなかった場合です。
Implementations compliant with the PT-TLS specification MUST implement the PT-TLS client authentication messages described in this section. These PT-TLS client authentication messages are capable of carrying a variety of SASL authentication mechanisms' exchanges. In order to ensure interoperability, all PT-TLS implementations compliant with this specification MUST at least support the PLAIN SASL mechanism [RFC4616]. Similarly, implementations MUST provide the EXTERNAL SASL mechanism if both parties are authenticated during the TLS establishment. In order to be able to take advantage of other strong, widely deployed authentication technologies such as Kerberos and support for channel bindings, implementations MAY include support for GS2 (the second Generic Security Service Application Program Interface (GSS-API) bridge for SASL) [RFC5801]. GS2 includes negotiable support for channel binding for use with SASL (see Section 5 of RFC 5801).
PT-TLS仕様に準拠した実装では、このセクションで説明するPT-TLSクライアント認証メッセージを実装する必要があります。これらのPT-TLSクライアント認証メッセージは、さまざまなSASL認証メカニズムの交換を運ぶことができます。相互運用性を確保するために、この仕様に準拠するすべてのPT-TLS実装は、少なくともPLAIN SASLメカニズム[RFC4616]をサポートする必要があります。同様に、TLS確立中に両方の当事者が認証される場合、実装はEXTERNAL SASLメカニズムを提供する必要があります。 Kerberosやチャネルバインディングのサポートなど、広く普及している他の強力な認証技術を利用できるようにするために、実装にはGS2（SASL用の2番目のGeneric Security Service Application Program Interface（GSS-API）ブリッジ）のサポートが含まれる場合があります[ RFC5801]。 GS2には、SASLで使用するためのチャネルバインディングの交渉可能なサポートが含まれています（RFC 5801のセクション5を参照）。
Implementations MUST also support the case where no client authentication is required.
実装は、クライアント認証が不要な場合もサポートする必要があります。
Mechanism negotiation is initiated by the NEA Server sending the SASL Mechanisms TLV to the NEA Client to indicate the zero or more SASL mechanisms that the NEA Server's policy is willing to use with the NEA Client. The NEA Client selects one SASL mechanism from the list and sends a SASL Mechanism Selection TLV completing the negotiation. Subsequent challenges and responses are carried within the SASL Authentication Data TLV carrying the authentication data for the selected mechanism. The authentication outcome is communicated in a SASL Result TLV containing a status code. If additional authentications are required, the NEA Server could trigger the next authentication by sending another SASL Mechanisms TLV after sending the SASL Result TLV for the current authentication mechanism.
メカニズムネゴシエーションは、NEAサーバーのポリシーがNEAクライアントで使用するゼロ以上のSASLメカニズムを示すために、SASLメカニズムTLVをNEAクライアントに送信するNEAサーバーによって開始されます。 NEAクライアントはリストから1つのSASLメカニズムを選択し、SASLメカニズム選択TLVを送信してネゴシエーションを完了します。後続のチャレンジとレスポンスは、選択されたメカニズムの認証データを運ぶSASL認証データTLV内で運ばれます。認証結果は、ステータスコードを含むSASL結果TLVで通知されます。追加の認証が必要な場合、NEAサーバーは、現在の認証メカニズムのSASL結果TLVを送信した後で、別のSASLメカニズムTLVを送信することにより、次の認証をトリガーできます。
The SASL client authentication starts when the NEA Server enters the PT-TLS Negotiation phase and its policy indicates that an authentication of the NEA Client is necessary, such as if it was not performed during the TLS handshake protocol. The NEA Server is responsible for triggering the client authentication by sending the SASL Mechanisms TLV to the NEA Client listing the set of SASL mechanisms the server is willing to use based upon its policy.
SASLクライアント認証は、NEAサーバーがPT-TLSネゴシエーションフェーズに入ると開始され、そのポリシーは、TLSハンドシェイクプロトコル中に実行されなかった場合など、NEAクライアントの認証が必要であることを示します。 NEAサーバーは、サーバーがポリシーに基づいて使用するSASLメカニズムのセットをリストしたSASLメカニズムTLVをNEAクライアントに送信することにより、クライアント認証をトリガーします。
The NEA Client selects a SASL mechanism from the list proposed by the NEA Server or sends a PT-TLS Invalid Message error code indicating that it is unable or unwilling to perform any of the mechanisms that were offered. If the NEA Server receives a SASL Mechanism Selection TLV that contains an unacceptable SASL mechanism, the NEA Server would respond with a SASL Mechanism Error in a PT-TLS Error TLV.
NEAクライアントは、NEAサーバーによって提案されたリストからSASLメカニズムを選択するか、提供されたメカニズムを実行できない、または実行する意思がないことを示すPT-TLS無効メッセージエラーコードを送信します。 NEAサーバーが受け入れられないSASLメカニズムを含むSASLメカニズム選択TLVを受信した場合、NEAサーバーはPT-TLSエラーTLVのSASLメカニズムエラーで応答します。
In situations where the NEA Server does not require a client authentication, the NEA Server MUST send a SASL Mechanisms TLV with no mechanisms included (only the PT-TLS header) indicating that the connection should transition to the PT-TLS Data Transport phase. The same mechanism is employed to indicate that a SASL authentication already performed in this session is adequate to permit transition to the PT-TLS Data Transport phase. So the NEA Server MUST always send a SASL Mechanisms TLV with no mechanisms as the last message in the PT-TLS Negotiation phase, and the NEA Client MUST NOT transition to the PT-TLS Data Transport phase until it receives such a message.
NEAサーバーがクライアント認証を必要としない状況では、NEAサーバーは、メカニズムが含まれていない（PT-TLSヘッダーのみ）SASLメカニズムTLVを送信して、接続がPT-TLSデータ転送フェーズに移行する必要があることを示す必要があります。同じメカニズムを使用して、このセッションですでに実行されているSASL認証が、PT-TLSデータ転送フェーズへの移行を許可するのに適切であることを示します。したがって、NEAサーバーは、PT-TLSネゴシエーションフェーズの最後のメッセージとしてメカニズムのないSASLメカニズムTLVを常に送信する必要があり、NEAクライアントは、そのようなメッセージを受信するまでPT-TLSデータトランスポートフェーズに移行してはなりません。
If the NEA Server receives a NEA assessment message before the completion of the client authentication, the NEA Server MUST send an Authentication Required PT-TLS Error message indicating to the NEA Client that an authentication exchange is required prior to entering the PT-TLS Data Transport phase.
クライアント認証が完了する前にNEAサーバーがNEA評価メッセージを受信する場合、NEAサーバーは、PT-TLSデータトランスポートに入る前に認証交換が必要であることをNEAクライアントに示す認証必須PT-TLSエラーメッセージを送信する必要があります段階。
The NEA Server may abort the authentication exchange by sending the SASL Result TLV with a status code of Abort. The NEA Client may abort the authentication exchange by sending a PT-TLS Error message with an Error Code of SASL Mechanism Error.
NEAサーバーは、ステータスコードAbortを含むSASL Result TLVを送信することにより、認証交換を中止できます。 NEAクライアントは、SASLメカニズムエラーのエラーコードを含むPT-TLSエラーメッセージを送信することにより、認証交換を中止する場合があります。
The service name for PT-TLS is "nea-pt-tls".
PT-TLSのサービス名は「nea-pt-tls」です。
The PT-TLS protocol does not make use of a SASL authorization identity string as described in RFC 4422.
PT-TLSプロトコルは、RFC 4422で説明されているSASL許可ID文字列を使用しません。
The NEA PT-TLS protocol always runs under the protection of TLS. SASL security layers are not used and thus MUST be negotiated off during SASL authentication.
NEA PT-TLSプロトコルは常にTLSの保護の下で実行されます。 SASLセキュリティレイヤーは使用されないため、SASL認証中にネゴシエートする必要があります。
Only one SASL mechanism authentication may be in progress at any one time. Once a SASL mechanism completes (successfully or unsuccessfully), the NEA Server MAY trigger an additional authentication by sending a SASL Mechanisms TLV.
一度に実行できるSASLメカニズム認証は1つだけです。 SASLメカニズムが完了すると（成功または失敗）、NEAサーバーはSASLメカニズムTLVを送信して追加の認証をトリガーできます（MAY）。
SASL channel bindings are used to bind the SASL authentication to the outer TLS tunnel to ensure that the authenticating endpoints are the same as the TLS endpoints. For SASL mechanisms that support channel bindings, the tls-unique value defined in RFC 5929 is carried by the SASL mechanism. For most mechanisms, this means including the tls-unique value with the appropriate prefix defined in RFC 5929 in the application data portion of the SASL Mechanism channel-binding data. If the validation of the channel binding fails, then the connection MUST be aborted.
SASLチャネルバインディングは、SASL認証を外部TLSトンネルにバインドして、認証エンドポイントがTLSエンドポイントと同じであることを確認するために使用されます。チャネルバインディングをサポートするSASLメカニズムの場合、RFC 5929で定義されているtls-unique値はSASLメカニズムによって伝達されます。ほとんどのメカニズムでは、これは、SASLメカニズムのチャネルバインディングデータのアプリケーションデータ部分に、RFC 5929で定義された適切な接頭辞を持つtls-unique値を含めることを意味します。チャネルバインディングの検証が失敗した場合は、接続を中止する必要があります。
This TLV is sent by the NEA Server to indicate the list of SASL mechanisms that it is willing and able to use to authenticate the NEA Client. Each mechanism name consists of a length followed by a name. The total length of the list is determined by the TLV Length field.
このTLVはNEAサーバーから送信され、NEAクライアントの認証に使用できるSASLメカニズムのリストを示します。各メカニズム名は、長さとそれに続く名前で構成されます。リストの全長は、TLV長さフィールドによって決まります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |
Rsvd (Reserved)
Rsvd（予約済み）
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
将来の使用のために予約されています。このフィールドは送信時に0に設定されなければならず、受信時には無視されなければなりません。
Mech Len (Mechanism Name Length)
Mech Len（メカニズム名の長さ）
The length of the Mechanism Name field in octets.
オクテット単位のメカニズム名フィールドの長さ。
Mechanism Name
メカニズム名
SASL mechanism name adhering to the rules defined in RFC 4422 with no padding.
RFC 4422で定義されたルールに準拠し、パディングのないSASLメカニズム名。
This TLV is sent by the NEA Client in order to select a SASL mechanism for use on this session.
このTLVは、このセッションで使用するSASLメカニズムを選択するためにNEAクライアントによって送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Initial Mechanism Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsvd (Reserved)
Rsvd（予約済み）
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
将来の使用のために予約されています。このフィールドは送信時に0に設定されなければならず、受信時には無視されなければなりません。
Mech Len (Mechanism Name Length)
Mech Len（メカニズム名の長さ）
The length of the Mechanism Name field in octets.
オクテット単位のメカニズム名フィールドの長さ。
Mechanism Name
メカニズム名
SASL mechanism name adhering to the rules defined in RFC 4422.
RFC 4422で定義されているルールに準拠するSASLメカニズム名。
Optional Initial Mechanism Response
オプションの初期メカニズム応答
Initial set of authentication information required from the NEA Client to kick-start the authentication. This data is optional and if not provided would be solicited by the NEA Server in the first SASL Authentication Data TLV request.
認証を開始するためにNEAクライアントから要求される認証情報の初期セット。このデータはオプションであり、提供されない場合は、最初のSASL認証データTLV要求でNEAサーバーによって要求されます。
This TLV carries an opaque (to PT-TLS) blob of octets being exchanged between the NEA Client and the NEA Server. This TLV facilitates their communications without interpreting any of the bytes. The SASL Authentication Data TLV MUST NOT be sent until a SASL mechanism has been established for a session. The SASL Authentication Data TLV associated with the current authentication mechanism MUST NOT be sent after a SASL Result is sent with a Result Code of Success. Additional SASL Authentication Data TLVs would be sent if the PT-TLS Initiator and Responder desire a subsequent SASL authentication to occur but only after another SASL mechanism selection exchange occurs.
このTLVは、NEAクライアントとNEAサーバーの間で交換されるオクテットの（PT-TLSに対して）不透明なblobを伝送します。このTLVは、バイトを解釈せずに通信を容易にします。 SASLメカニズムがセッションに対して確立されるまで、SASL認証データTLVを送信してはならない（MUST NOT）。現在の認証メカニズムに関連付けられているSASL認証データTLVは、SASLの結果が成功の結果コードとともに送信された後に送信してはなりません（MUST NOT）。追加のSASL認証データTLVは、PT-TLSイニシエーターとレスポンダーが後続のSASL認証の実行を希望する場合に送信されますが、別のSASLメカニズム選択交換が発生した後にのみ送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SASL Mechanism Data (Variable Length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SASL Mechanism Data
SASLメカニズムデータ
Opaque, variable-length set of bytes exchanged between the PT-TLS Initiator's SASL mechanism and its peer PT-TLS Responder's SASL mechanism. These bytes MUST NOT be interpreted by the PT-TLS layer.
PT-TLSイニシエーターのSASLメカニズムとそのピアPT-TLSレスポンダーのSASLメカニズムの間で交換される不透明な可変長のバイトセット。これらのバイトは、PT-TLS層によって解釈されてはならない（MUST NOT）。
This TLV is sent by the NEA Server at the conclusion of the SASL exchange to indicate the authentication result. Upon reception of a SASL Result TLV indicating an Abort, the NEA Client MUST terminate the current authentication conversation. The recipient may retry the authentication in the event of an authentication failure. Similarly, the NEA Server may request that additional SASL authentication(s) be performed after the completion of a SASL mechanism by sending another SASL Mechanisms TLV including any mechanisms dictated by its policy.
このTLVは、SASL交換の終了時にNEAサーバーによって送信され、認証結果を示します。中止を示すSASL結果TLVを受信すると、NEAクライアントは現在の認証会話を終了する必要があります。受信者は、認証が失敗した場合に認証を再試行できます。同様に、NEAサーバーは、ポリシーで指定されたメカニズムを含む別のSASLメカニズムTLVを送信することにより、SASLメカニズムの完了後に追加のSASL認証を実行するように要求できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Optional Result Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Result Code
結果コード
This field contains the result of the SASL authentication exchange.
このフィールドには、SASL認証交換の結果が含まれます。
Value (Name) Definition
--------------------- -------------------------------------------
0 (Success) SASL authentication was successful, and
identity was confirmed.
1 (Failure) SASL authentication failed. This might be caused by the client providing an invalid user identity and/or credential pair. Note that this is not the same as a mechanism's failure to process the authentication as reported by the Mechanism Failure code.
1（失敗）SASL認証が失敗しました。これは、クライアントが無効なユーザーIDまたは資格情報のペアを提供したことが原因である可能性があります。これは、メカニズムの失敗コードによって報告されたメカニズムの認証の失敗と同じではないことに注意してください。
2 (Abort) SASL authentication exchange was aborted by the sender.
2（中止）SASL認証交換は送信者によって中止されました。
3 (Mechanism Failure) SASL "mechanism failure" during the processing of the client's authentication (e.g., not related to the user's input). For example, this could occur if the mechanism is unable to allocate memory (e.g., malloc) that is needed to process a received SASL mechanism message.
3（メカニズムの失敗）クライアントの認証の処理中のSASL "メカニズムの失敗"（たとえば、ユーザーの入力とは関係ありません）。たとえば、これは、メカニズムが、受信したSASLメカニズムメッセージを処理するために必要なメモリ（mallocなど）を割り当てることができない場合に発生する可能性があります。
Optional Result Data
オプションの結果データ
This field contains a variable-length set of additional data for a successful result. This field MUST be zero length unless the NEA Server is returning a Result Code of Success and has more data to return. For more information on the additional data with success in SASL, see RFC 4422.
このフィールドには、正常な結果を得るための可変長の追加データのセットが含まれています。 NEAサーバーが成功の結果コードを返し、さらに多くのデータを返す場合を除き、このフィールドの長さはゼロでなければなりません。 SASLで成功した追加データの詳細については、RFC 4422を参照してください。
This section describes the format and contents of the PT-TLS Error message sent by the NEA Client or NEA Server when it detects a PT-TLS-level protocol error. Each error message contains an error code indicating the error that occurred, followed by a copy of the message that caused the error.
このセクションでは、NEAクライアントまたはNEAサーバーがPT-TLSレベルのプロトコルエラーを検出したときに送信されるPT-TLSエラーメッセージの形式と内容について説明します。各エラーメッセージには、発生したエラーを示すエラーコードと、その後にエラーの原因となったメッセージのコピーが含まれています。
When a PT-TLS error is received, the recipient MUST NOT respond with a PT-TLS error, because this could result in an infinite loop of error messages being sent. Instead, the recipient MAY log the error, modify its behavior to avoid future errors, ignore the error, terminate the assessment, or take other action as appropriate (as long as it is consistent with the requirements of this specification).
PT-TLSエラーを受信した場合、受信者はPT-TLSエラーで応答してはなりません。これは、送信されるエラーメッセージの無限ループにつながる可能性があるためです。代わりに、受信者はエラーをログに記録し、その動作を変更して将来のエラーを回避するか、エラーを無視するか、評価を終了するか、または他のアクションを適切に実行します（この仕様の要件に一致する限り）。
The Message Value portion of a PT-TLS Error message contains the following information:
PT-TLSエラーメッセージのメッセージ値の部分には、次の情報が含まれています。
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 | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Original Message (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . |
Reserved
予約済み
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
将来の使用のために予約されています。このフィールドは送信時に0に設定されなければならず、受信時には無視されなければなりません。
Error Code Vendor ID
エラーコードベンダーID
This field contains the IANA-assigned SMI Private Enterprise Number for the vendor whose Error Code namespace is being used in the message. For IETF namespace Error Code values, this field MUST be set to zero (0). For other vendor-defined Error Code namespaces, this field MUST be set to the SMI Private Enterprise Number of the vendor.
このフィールドには、エラーコード名前空間がメッセージで使用されているベンダーにIANAが割り当てたSMIプライベートエンタープライズ番号が含まれます。 IETF名前空間のエラーコード値の場合、このフィールドはゼロ（0）に設定する必要があります。他のベンダー定義のエラーコード名前空間の場合、このフィールドはベンダーのSMI Private Enterprise Numberに設定する必要があります。
Error Code
エラーコード
This field contains the error code. This error code exists within the scope of Error Code Vendor ID in this message. Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-specific PT-TLS Error Codes in order to interoperate with other PT-TLS-compliant implementations (although implementations MAY permit administrators to configure them to require support for specific PT-TLS Error Codes).
このフィールドにはエラーコードが含まれます。このエラーコードは、このメッセージのエラーコードベンダーIDの範囲内にあります。ポスチャトランスポートクライアントとポスチャトランスポートサーバーは、他のPT-TLS準拠の実装と相互運用するために、特定のベンダー固有のPT-TLSエラーコードのサポートを必要としてはなりません（ただし、実装では、管理者が特定のPT-TLSのサポートを要求するように構成することを許可する場合があります）エラーコード）。
When the Error Code Vendor ID is set to the IETF Private Enterprise Number, the following table lists the initial supported IETF-defined numeric error codes:
エラーコードベンダーIDがIETF Private Enterprise Numberに設定されている場合、次の表に、サポートされている最初のIETF定義の数値エラーコードを示します。
Value (Name) Definition
------------------------- ---------------------------------------
0 (Reserved) Reserved value indicates that the
PT-TLS Error message SHOULD be ignored
by all recipients. This MAY be used
for debugging purposes to allow a
sender to see a copy of the message
that was received.
1 (Malformed Message) PT-TLS message unrecognized or unsupported. This error code SHOULD be sent when the basic message content sanity test fails. The sender of this error code MUST consider it a fatal error and abort the assessment.
1（改ざんされたメッセージ）認識されない、またはサポートされないPT-TLSメッセージ。このエラーコードは、基本的なメッセージコンテンツの健全性テストが失敗したときに送信する必要があります（SHOULD）。このエラーコードの送信者は、それを致命的なエラーと見なして、評価を中止する必要があります。
2 (Version Not Supported) This error SHOULD be sent when a PT-TLS Responder receives a PT-TLS Version Request message containing a range of version numbers that doesn't include any version numbers that the recipient is willing and able to support on the session. All PT-TLS messages carrying the Version Not Supported error code MUST use a version number of 1. All parties that receive or send PT-TLS messages MUST be able to properly process an error message that meets this description, even if they cannot process any other aspect of PT-TLS version 1. The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message.
2（サポートされていないバージョン）このエラーは、PT-TLSレスポンダが、受信者が喜んでサポートできるバージョン番号を含まないバージョン番号の範囲を含むPT-TLSバージョン要求メッセージを受信したときに送信される必要があります（SHOULD）。セッション。サポートされていないバージョンのエラーコードを含むすべてのPT-TLSメッセージは、バージョン番号1を使用する必要があります。PT-TLSメッセージを送受信するすべての当事者は、この説明を満たすエラーメッセージを適切に処理できなければなりません。 PT-TLSバージョン1の他の側面。このエラーコードの送信者と受信者は、それを致命的なエラーと見なし、このPT-TLSメッセージの送受信後にTLSセッションを閉じる必要があります。
3 (Type Not Supported) PT-TLS Message Type unknown or not supported. When a recipient receives a PT-TLS Message Type that it does not support, it MUST send back this error, ignore the message, and proceed. For example, this could occur if the sender used a Vendor ID for the Message Type that is not supported by the recipient. This error message does not indicate that a fatal error has occurred, so the assessment is allowed to continue.
3（サポートされていないタイプ）PT-TLSメッセージタイプが不明またはサポートされていません。受信者がサポートしていないPT-TLSメッセージタイプを受信した場合は、このエラーを返信し、メッセージを無視して続行する必要があります。たとえば、送信者が受信者によってサポートされていないメッセージタイプのベンダーIDを使用した場合に、これが発生する可能性があります。このエラーメッセージは、致命的なエラーが発生したことを示していないため、評価を続行できます。
4 (Invalid Message) PT-TLS message received was invalid based on the protocol state. For example, this error would be sent if a recipient receives a message associated with the PT-TLS Negotiation Phase (such as Version messages) after the protocol has reached the PT-TLS Data Transport Phase. The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message.
4（無効なメッセージ）受信したPT-TLSメッセージは、プロトコルの状態に基づいて無効でした。たとえば、プロトコルがPT-TLSデータ転送フェーズに達した後で、受信者がPT-TLSネゴシエーションフェーズに関連付けられたメッセージ（バージョンメッセージなど）を受信した場合、このエラーが送信されます。このエラーコードの送信者と受信者は、これを致命的なエラーと見なして、このPT-TLSメッセージの送受信後にTLSセッションを閉じる必要があります。
5 (SASL Mechanism Error) A fatal error occurred while trying to perform the client authentication. For example, the NEA Client is unable to support any of the offered SASL mechanisms. The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message.
5（SASLメカニズムエラー）クライアント認証の実行中に致命的なエラーが発生しました。たとえば、NEAクライアントは、提供されているSASLメカニズムをサポートできません。このエラーコードの送信者と受信者は、これを致命的なエラーと見なして、このPT-TLSメッセージの送受信後にTLSセッションを閉じる必要があります。
6 (Invalid Parameter) The PT-TLS Error message sender has received a message with an invalid or unsupported value in the PT-TLS header. This could occur if the NEA Client receives a PT-TLS message from the NEA Server with a Message Length of zero (see Section 3.5 for details). The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message.
6（無効なパラメーター）PT-TLSエラーメッセージの送信者が、PT-TLSヘッダーに無効またはサポートされていない値を含むメッセージを受信しました。これは、NEAクライアントがメッセージ長がゼロのNEAサーバーからPT-TLSメッセージを受信した場合に発生する可能性があります（詳細はセクション3.5を参照）。このエラーコードの送信者と受信者は、これを致命的なエラーと見なして、このPT-TLSメッセージの送受信後にTLSセッションを閉じる必要があります。
Copy of Original Message
元のメッセージのコピー
This variable-length value MUST contain a copy (up to 1024 bytes) of the original PT-TLS message that caused the error. If the original message is longer than 1024 bytes, only the initial 1024 bytes will be included in this field. This field is included so the error recipient can determine which message sent caused the error. In particular, the recipient can use the Message Identifier field from the Copy of Original Message data to determine which message caused the error.
この可変長の値には、エラーの原因となった元のPT-TLSメッセージのコピー（最大1024バイト）が含まれている必要があります。元のメッセージが1024バイトより長い場合、最初の1024バイトのみがこのフィールドに含まれます。このフィールドは、エラーの受信者が送信されたメッセージがエラーの原因であるかどうかを判別できるように含まれています。特に、受信者は、元のメッセージのコピーデータのメッセージ識別子フィールドを使用して、エラーの原因となったメッセージを特定できます。
This section discusses the major threats potentially faced by each binding of the PT protocol and countermeasures provided by the PT-TLS protocol.
このセクションでは、PTプロトコルの各バインディングが直面する可能性のある主な脅威と、PT-TLSプロトコルによって提供される対策について説明します。
In order to understand where security countermeasures are necessary, this section starts with a discussion of where the NEA architecture envisions some trust relationships between the processing elements of the PT-TLS protocol. Implementations or deployments where these trust relationships are not present would need to provide additional countermeasures to ensure the proper operation and security of PT-TLS (which relies upon these relationships to be trustworthy). The following subsections discuss the trust properties associated with each portion of the NEA reference model directly involved with the processing of the PT-TLS protocol.
セキュリティ対策が必要な場所を理解するために、このセクションではまず、NEAアーキテクチャがPT-TLSプロトコルの処理要素間の信頼関係を想定する場所について説明します。これらの信頼関係が存在しない実装または展開では、PT-TLSの適切な操作とセキュリティを保証するために追加の対策を提供する必要があります（これらの信頼関係に依存しています）。次のサブセクションでは、PT-TLSプロトコルの処理に直接関与するNEA参照モデルの各部分に関連付けられている信頼プロパティについて説明します。
The Posture Transport Client is trusted by the Posture Broker Client to:
ポスチャトランスポートクライアントは、ポスチャブローカクライアントから次のことを信頼されています。
o Not observe, fabricate, or alter the contents of the PB-TNC batches received from the network
o ネットワークから受信したPB-TNCバッチの内容を観察、加工、または変更しない
o Not observe, fabricate, or alter the PB-TNC batches passed down from the Posture Broker Client for transmission on the network
o ネットワークでの送信のためにPosture Broker Clientから渡されたPB-TNCバッチを観察、製造、または変更しない
o Transmit on the network any PB-TNC batches passed down from the Posture Broker Client
o Posture Broker Clientから渡されたPB-TNCバッチをネットワークで送信します
o Deliver properly security protected messages received from the network that are destined for the Posture Broker Client
o ネットワークから受信した、Posture Broker Client宛てのセキュリティで保護されたメッセージを適切に配信する
o Provide configured security protections (e.g., authentication, integrity, and confidentiality) for the Posture Broker Client's PB-TNC batches sent on the network
o ネットワーク上で送信されるポスチャブローカークライアントのPB-TNCバッチに構成済みのセキュリティ保護（認証、整合性、機密性など）を提供します
o Expose the authenticated identity of the Posture Transport Server only to the PB-TNC layer within the NEA Client
o ポスチャトランスポートサーバーの認証済みIDをNEAクライアント内のPB-TNCレイヤーにのみ公開します
o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
o ネットワークから受信したメッセージに適用されているセキュリティ保護を検証して、メッセージが信頼でき、ネットワークへの攻撃から保護されていることを確認します
o Provide a secure, reliable, "in-order delivery", full-duplex transport for the Posture Broker Client's messages
o ポスチャブローカークライアントのメッセージに対して、安全で信頼性の高い、「順序どおりの配信」、全二重トランスポートを提供します
The Posture Transport Client is trusted by the Posture Transport Server to:
ポスチャトランスポートクライアントは、ポスチャトランスポートサーバーによって次のことを信頼されます。
o Not send malicious traffic intending to harm (e.g., denial of service) the Posture Transport Server
o ポスチャトランスポートサーバーに危害を加えることを目的とした悪意のあるトラフィック（サービス拒否など）を送信しない
o Not send malformed messages (e.g., messages lacking a PT-TLS header)
o 不正なメッセージを送信しない（例：PT-TLSヘッダーがないメッセージ）
o Not send invalid or incorrect responses to messages (e.g., errors when no error is warranted)
o メッセージに無効または不正な応答を送信しない（たとえば、エラーが保証されていない場合のエラー）
o Not ignore or drop messages when such an action would cause issues for the protocol processing (e.g., dropping PT-TLS SASL Authentication Data messages)
o そのようなアクションがプロトコル処理に問題を引き起こす場合（たとえば、PT-TLS SASL認証データメッセージのドロップ）、メッセージを無視またはドロップしない
o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
o ネットワークから受信したメッセージに適用されているセキュリティ保護を検証して、メッセージが信頼でき、ネットワークへの攻撃から保護されていることを確認します
The Posture Transport Server is trusted by the Posture Broker Server to:
ポスチャトランスポートサーバーは、ポスチャーブローカーサーバーから次のことを信頼されます。
o Not observe, fabricate, or alter the contents of the PB-TNC batches received from the network
o ネットワークから受信したPB-TNCバッチの内容を観察、加工、または変更しない
o Not observe, fabricate, or alter the PB-TNC batches passed down from the Posture Broker Server for transmission on the network
o ネットワークでの送信のためにPosture Broker Serverから渡されたPB-TNCバッチを観察、製造、または変更しない
o Transmit on the network any PB-TNC batches passed down from the Posture Broker Server
o Posture Broker Serverから渡されたPB-TNCバッチをネットワークで送信します
o Deliver properly security protected messages received from the network that are destined for the Posture Broker Server
o ネットワークから受信した、Posture Broker Server宛ての適切にセキュリティ保護されたメッセージを配信する
o Provide configured security protections (e.g., authentication, integrity, and confidentiality) for the Posture Broker Server's messages sent on the network
o ネットワーク上で送信されるポスチャブローカーサーバーのメッセージに設定されたセキュリティ保護（認証、整合性、機密性など）を提供します
o Expose the authenticated identity of the Posture Transport Client only to the PB-TNC layer within the NEA Server
o ポスチャトランスポートクライアントの認証済みIDをNEAサーバー内のPB-TNCレイヤーにのみ公開します
o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
o ネットワークから受信したメッセージに適用されているセキュリティ保護を検証して、メッセージが信頼でき、ネットワークへの攻撃から保護されていることを確認します
o Provide a secure, reliable, "in-order delivery", full-duplex transport for the Posture Broker Server's messages
o Posture Broker Serverのメッセージに安全で信頼性の高い「順序どおりの配信」の全二重トランスポートを提供します
The Posture Transport Server is trusted by the Posture Transport Client to:
ポスチャトランスポートサーバーは、ポスチャトランスポートクライアントから次のことを信頼されます。
o Not send malicious traffic intending to harm (e.g., denial of service) the Posture Transport Client
o ポスチャトランスポートクライアントに危害を加えることを目的とした悪意のあるトラフィック（サービス拒否など）を送信しない
o Not send malformed messages (e.g., messages lacking a PT-TLS header)
o 不正なメッセージを送信しない（例：PT-TLSヘッダーがないメッセージ）
o Not send invalid or incorrect responses to messages (e.g., errors when no error is warranted)
o メッセージに無効または不正な応答を送信しない（たとえば、エラーが保証されていない場合のエラー）
o Not ignore or drop messages when such an action would cause issues for the protocol processing (e.g., dropping PT-TLS SASL Result messages)
o そのようなアクションがプロトコル処理に問題を引き起こす場合（たとえば、PT-TLS SASL結果メッセージのドロップ）、メッセージを無視またはドロップしない
o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
o ネットワークから受信したメッセージに適用されているセキュリティ保護を検証して、メッセージが信頼でき、ネットワークへの攻撃から保護されていることを確認します
Beyond the trust relationships assumed in Section 4.1, the PT-TLS protocol faces a number of potential security attacks that could require security countermeasures.
セクション4.1で想定されている信頼関係を超えて、PT-TLSプロトコルは、セキュリティ対策を必要とする可能性のある多くの潜在的なセキュリティ攻撃に直面しています。
Generally, the PT-TLS protocol is responsible for offering strong security protections for all of the NEA protocols, so any threats to its ability to protect NEA protocol messages could be very damaging to deployments. Once the message is delivered to the Posture Broker Client or Posture Broker Server, the posture brokers are trusted to properly and safely process the messages.
一般に、PT-TLSプロトコルは、すべてのNEAプロトコルに強力なセキュリティ保護を提供する責任があるため、NEAプロトコルメッセージを保護する機能に対する脅威は、展開に大きな損害を与える可能性があります。メッセージがPosture Broker ClientまたはPosture Broker Serverに配信されると、ポスチャブローカーはメッセージを適切かつ安全に処理することが信頼されます。
When PT-TLS messages are sent over unprotected network links or spanning local software stacks that are not trusted, the contents of the messages may be subject to information theft by an intermediary party. This theft could result in information being recorded for future use or analysis by the adversary. Messages observed by eavesdroppers could contain information that exposes potential weaknesses in the security of the endpoint, or system fingerprinting information; this information would make it easier for the attacker to employ attacks more likely to be successful against the endpoint. The eavesdropper might also learn information about the endpoint or network policies that either singularly or collectively is considered sensitive information. For example, if PT-TLS does not provide confidentiality protection, an adversary could observe the PA-TNC attributes included in the PT-TLS message and determine that the endpoint is lacking patches or that particular sub-networks have more lenient policies.
保護されていないネットワークリンクまたは信頼されていないローカルソフトウェアスタックにまたがってPT-TLSメッセージが送信される場合、メッセージの内容は、中間者による情報の盗難の対象となる可能性があります。この盗難により、攻撃者による将来の使用または分析のために情報が記録される可能性があります。盗聴者が監視するメッセージには、エンドポイントのセキュリティの潜在的な弱点を明らかにする情報や、システムのフィンガープリント情報が含まれる可能性があります。この情報により、攻撃者はエンドポイントに対して成功する可能性が高い攻撃をより簡単に利用できるようになります。盗聴者は、単独または集合的に機密情報と見なされるエンドポイントまたはネットワークポリシーに関する情報を知ることもあります。たとえば、PT-TLSが機密保護を提供しない場合、攻撃者はPT-TLSメッセージに含まれるPA-TNC属性を観察し、エンドポイントにパッチが不足しているか、特定のサブネットワークのポリシーがより緩やかであると判断できます。
In order to protect against NEA assessment message theft, the PT-TLS protocol provides strong cryptographic authentication, integrity, and confidentiality protection. Deployers are strongly encouraged to employ "best practice of the day" TLS ciphers to ensure that the information remains safe despite advances in technology and discovered cipher weaknesses. The use of bidirectional authentication of the assessment transport session ensures that only properly authenticated and authorized parties may be involved in an assessment dialog. The PT-TLS protocol also provides strong cryptography for all of the PB-TNC and PA-TNC protocol messages traveling over the network, allowing the message contents to be hidden from potential theft by the adversary even if the attacker is able to observe the encrypted PT-TLS session.
NEA評価メッセージの盗難から保護するために、PT-TLSプロトコルは強力な暗号化認証、完全性、および機密保護を提供します。技術者の進歩や発見された暗号の弱点にもかかわらず、情報が安全に保たれるように、「今日のベストプラクティス」のTLS暗号を採用することを配備者は強く推奨されます。評価トランスポートセッションの双方向認証を使用すると、適切に認証および承認された関係者のみが評価ダイアログに関与できるようになります。 PT-TLSプロトコルは、ネットワーク上を移動するすべてのPB-TNCおよびPA-TNCプロトコルメッセージに強力な暗号化を提供し、攻撃者が暗号化されたものを観察できたとしても、メッセージの内容を潜在的な盗難から隠します。 PT-TLSセッション。
Attackers on the network or present within the NEA system could introduce fabricated PT-TLS messages intending to trick or create a denial of service against aspects of an assessment. For example, an adversary could attempt to insert into the message exchange fake PT-TLS Error Codes in order to disrupt communications.
ネットワーク上の攻撃者またはNEAシステム内に存在する攻撃者は、評価の側面に対してサービス拒否をだましまたは作成することを目的とした、偽造されたPT-TLSメッセージを導入する可能性があります。たとえば、攻撃者はメッセージ交換に偽のPT-TLSエラーコードを挿入して、通信を妨害する可能性があります。
The PT-TLS protocol provides strong security protections for the complete message exchange over the network. These security protections prevent an intermediary from being able to insert fake messages into the assessment. In particular, TLS's use of hashing algorithms provides strong integrity protections that allow for detection of any changes in the content of the message stream. Additionally, adversaries are unable to observe the PT-TLS protocol exchanges because they are encrypted by the TLS ciphers and so would have difficulty determining where to insert the falsified message, since the attacker is unable to determine where the message boundaries exist. Even if a successful message insertion did occur, the recipient would be able to detect it due to failure of the TLS cipher suite's integrity check.
PT-TLSプロトコルは、ネットワーク上の完全なメッセージ交換に強力なセキュリティ保護を提供します。これらのセキュリティ保護により、中間者が偽のメッセージを評価に挿入することができなくなります。特に、TLSのハッシュアルゴリズムの使用は、メッセージストリームのコンテンツの変更の検出を可能にする強力な整合性保護を提供します。さらに、攻撃者はTLS暗号で暗号化されているため、攻撃者はメッセージ境界が存在する場所を特定できないため、PT-TLSプロトコル交換を監視できず、改ざんされたメッセージを挿入する場所を特定することが困難になります。メッセージの挿入が成功した場合でも、TLS暗号スイートの整合性チェックの失敗により、受信者はそれを検出できます。
This attack could allow an active attacker capable of intercepting a message to modify a PT-TLS message or transported PA-TNC attribute to a desired value to make it easier to compromise an endpoint. Without the ability for message recipients to detect whether a received message contains the same content as what was originally sent, active attackers can stealthily modify the attribute exchange.
この攻撃では、メッセージを傍受できるアクティブな攻撃者がPT-TLSメッセージまたはトランスポートされたPA-TNC属性を目的の値に変更して、エンドポイントのセキュリティを侵害しやすくする可能性があります。メッセージの受信者が、受信したメッセージに最初に送信されたものと同じコンテンツが含まれているかどうかを検出する機能がない場合、アクティブな攻撃者は属性交換を密かに変更できます。
The PT-TLS protocol leverages the TLS protocol to provide strong authentication and integrity protections as a countermeasure to this threat. The bidirectional authentication prevents the attacker from acting as an active man-in-the-middle to the protocol that could be used to modify the message exchange. The strong integrity protection (e.g., hashing) offered by TLS allows PT-TLS message recipients to detect message alterations by other types of network-based adversaries.
PT-TLSプロトコルはTLSプロトコルを利用して、この脅威への対策として強力な認証と整合性保護を提供します。双方向認証により、攻撃者がメッセージ交換の変更に使用される可能性のあるプロトコルのアクティブな中間者として機能することを防ぎます。 TLSによって提供される強力な整合性保護（ハッシュなど）により、PT-TLSメッセージ受信者は、他のタイプのネットワークベースの敵によるメッセージの変更を検出できます。
A variety of types of denial-of-service attacks are possible against the PT-TLS protocol if the message exchanges are left unprotected while traveling over the network. The Posture Transport Client and Posture Transport Server are trusted not to participate in the denial of service of the assessment session, leaving the threats to come from the network.
ネットワーク上を移動中にメッセージ交換が保護されないままになっている場合、PT-TLSプロトコルに対してさまざまなタイプのサービス拒否攻撃が可能です。ポスチャトランスポートクライアントとポスチャトランスポートサーバーは、評価セッションのサービス拒否に参加しないことが信頼されているため、脅威はネットワークから発信されます。
The PT-TLS protocol provides bidirectional authentication capabilities in order to prevent a man-in-the-middle on the network from becoming an undetected active proxy of PT-TLS messages. Because the PT-TLS protocol runs after the TLS handshake and thus cipher establishment/use, all of the PT-TLS messages are protected from undetected modification that could create a denial-of-service situation. However, it is possible for an adversary to alter the message flows, causing each message to be rejected by the recipient because it fails the integrity checking.
PT-TLSプロトコルは、ネットワークの中間者がPT-TLSメッセージの検出されないアクティブなプロキシになるのを防ぐために、双方向認証機能を提供します。 PT-TLSプロトコルはTLSハンドシェイクの後に実行されるため、暗号の確立/使用が行われるため、すべてのPT-TLSメッセージは、サービス拒否の状況を引き起こす可能性のある未検出の変更から保護されます。ただし、攻撃者がメッセージフローを変更して、各メッセージが整合性チェックに失敗したために受信者に拒否される可能性があります。
The PT-TLS protocol operates as an application protocol on top of TLS and thus TCP/IP protocols, so is subject to denial-of-service attacks against the TLS, TCP, and IP protocols.
PT-TLSプロトコルはTLS上のアプリケーションプロトコルとして動作するため、TCP / IPプロトコルであるため、TLS、TCP、およびIPプロトコルに対するサービス拒否攻撃の影響を受けます。
As described in Section 3.3 and in [RFC6813], a sophisticated MITM attack can be mounted against NEA systems. The attacker forwards PA-TNC messages from a healthy machine through an unhealthy one so that the unhealthy machine can gain network access. Section 3.3 and [RFC6813] provide a detailed description of this attack and of the countermeasures that can be employed against it.
セクション3.3と[RFC6813]で説明されているように、洗練されたMITM攻撃はNEAシステムに対してマウントできます。攻撃者は、正常なマシンから正常でないマシンを介してPA-TNCメッセージを転送し、異常なマシンがネットワークにアクセスできるようにします。セクション3.3と[RFC6813]は、この攻撃の詳細と、この攻撃に対して採用できる対策について説明しています。
Because lying endpoint attacks are much easier than Asokan attacks and the only known effective countermeasure against lying endpoint attacks is the use of an External Measurement Agent (EMA), countermeasures against an Asokan attack are not necessary unless an EMA is in use. However, PT-TLS implementers may not know whether an EMA will be used with their implementation. Therefore, PT-TLS implementers SHOULD support the Asokan attack countermeasures described in Section 3.3 by providing the value of the tls-unique channel binding to higher layers in the NEA reference model: Posture Broker Clients, Posture Broker Servers, Posture Collectors, and Posture Validators.
嘘つきエンドポイント攻撃はAsokan攻撃よりはるかに簡単であり、嘘つきエンドポイント攻撃に対する唯一の既知の効果的な対策は外部測定エージェント（EMA）の使用であるため、EMAが使用されていない限り、Asokan攻撃に対する対策は必要ありません。ただし、PT-TLSの実装者は、EMAがその実装で使用されるかどうかわからない場合があります。したがって、PT-TLS実装者は、NEA参照モデルの上位層にバインドするtls-uniqueチャネルの値を提供することにより、セクション3.3で説明されているAsokan攻撃対策をサポートする必要があります：ポスチャブローカークライアント、ポスチャブローカーサーバー、ポスチャコレクター、ポスチャバリデーター。
The Asokan attack can also apply to authentication mechanisms carried within TLS. SASL mechanisms providing channel bindings use the tls-unique channel-binding data as defined in Section 3.3 to protect against the attack.
Asokan攻撃は、TLS内で実行される認証メカニズムにも適用できます。チャネルバインディングを提供するSASLメカニズムは、セクション3.3で定義されているtls-uniqueチャネルバインディングデータを使用して、攻撃から保護します。
The TLS protocol bases its trust decision about the signer of the certificates received during the TLS authentication on using a set of trust anchor certificates. It is essential that these trust anchor certificates are integrity protected from unauthorized modification. Many common software components (e.g., browsers, operating systems, security protocols) include a set of trust anchor certificates that are relevant to their operation. The PT-TLS SHOULD use a PT-TLS-specific set of trust anchor certificates in order to limit what Certificate Authorities are authorized to issue certificates for use with NEA.
TLSプロトコルは、一連のトラストアンカー証明書を使用して、TLS認証中に受信した証明書の署名者に関する信頼の決定に基づいています。これらのトラストアンカー証明書は、無許可の変更から整合性を保護することが不可欠です。多くの一般的なソフトウェアコンポーネント（ブラウザ、オペレーティングシステム、セキュリティプロトコルなど）には、それらの操作に関連する一連のトラストアンカー証明書が含まれています。 PT-TLSは、NEAで使用する証明書の発行を許可されている認証局を制限するために、PT-TLS固有のトラストアンカー証明書のセットを使用する必要があります（SHOULD）。
The role of PT-TLS is to act as a secure transport for PB-TNC and other higher-layer protocols. As such, PT-TLS does not directly utilize personally identifiable information (PII) except when client authentication is enabled. When client authentication is being used, the NEA Client will be asked to use SASL, which may disclose a local identifier (e.g., username) associated with the endpoint and an authenticator (e.g., password) to authenticate that identity. Because the identity and authenticator are potentially privacy-sensitive information, the NEA Client MUST offer a mechanism to restrict which NEA Servers will be sent this information. Similarly, the NEA Client SHOULD provide an indication to the person being identified that a request for their identity has been made in case they choose to opt out of the authentication to remain anonymous unless no user interface is available. PT-TLS provides cryptographic peer authentication, message integrity, and data confidentiality protections to higher-layer NEA protocols that may exchange data potentially including PII. These security services can be used to protect any PII involved in an assessment from passive and active attackers on the network. Endpoints sending potentially privacy-sensitive information SHOULD ensure that the PT-TLS security protections (TLS cipher suites) negotiated for an assessment of the endpoint are adequate to avoid interception and off-line attacks of any long-term privacy-sensitive information unless other network protections are already present.
PT-TLSの役割は、PB-TNCおよびその他の上位層プロトコルの安全なトランスポートとして機能することです。そのため、クライアント認証が有効になっている場合を除いて、PT-TLSは直接個人情報（PII）を利用しません。クライアント認証が使用されている場合、NEAクライアントはSASLを使用するよう求められます。SASLは、エンドポイントに関連付けられたローカル識別子（ユーザー名など）と、そのIDを認証する認証子（パスワードなど）を開示する場合があります。 IDとオーセンティケーターはプライバシーに敏感な情報である可能性があるため、NEAクライアントは、この情報が送信されるNEAサーバーを制限するメカニズムを提供する必要があります。同様に、NEAクライアントは、ユーザーインターフェースが利用できない場合を除き、匿名のままにするために認証をオプトアウトすることを選択した場合に、IDのリクエストが行われたことを識別される人物に示します。 PT-TLSは、PIIを含む可能性のあるデータを交換する可能性のある上位層のNEAプロトコルに、暗号化ピア認証、メッセージ整合性、およびデータ機密保護を提供します。これらのセキュリティサービスを使用して、評価に関与するPIIをネットワーク上のパッシブおよびアクティブな攻撃者から保護できます。プライバシーに関わる可能性のある情報を送信するエンドポイントは、エンドポイントの評価のためにネゴシエートされたPT-TLSセキュリティ保護（TLS暗号スイート）が、他のネットワークを除いて、長期のプライバシーに敏感な情報の傍受やオフライン攻撃を回避するのに十分であることを保証する必要があります保護はすでに存在しています。
Per this specification, two new IANA registries have been created and a TCP port number has been assigned. IANA has permanently reserved the early allocated TCP port number 271 for use with the PT-TLS protocol.
この仕様に従って、2つの新しいIANAレジストリが作成され、TCPポート番号が割り当てられました。 IANAは、PT-TLSプロトコルで使用するために、早期に割り当てられたTCPポート番号271を永久に予約しました。
This section defines the contents of two new IANA registries, PT-TLS Message Types and PT-TLS Error Codes, and explains how these registries work.
このセクションでは、PT-TLSメッセージタイプとPT-TLSエラーコードの2つの新しいIANAレジストリの内容を定義し、これらのレジストリがどのように機能するかについて説明します。
Each of the registries defined in this document support IETF-defined values and vendor-defined values. To explain this phenomenon, we will use the PT-TLS Message Type as an example, but the other registry works the same way.
このドキュメントで定義されている各レジストリは、IETF定義の値とベンダー定義の値をサポートしています。この現象を説明するために、例としてPT-TLSメッセージタイプを使用しますが、他のレジストリも同じように機能します。
Whenever a PT-TLS 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 PT-TLS Message Type is an IETF namespace value listed in the IANA registry for PT-TLS Message Types, and its meaning is defined in the specification listed for that PT-TLS Message Type in that registry. If the vendor ID is not zero, the meaning of the PT-TLS 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 PT-TLS Message Types used with their vendor ID and publish a specification for each of these values.
PT-TLSメッセージタイプがネットワークに表示されるときは常に、ベンダーIDとも呼ばれるSMIプライベートエンタープライズ番号（PEN）が常に付随します。このベンダーIDがゼロの場合、付随するPT-TLSメッセージタイプは、PT-TLSメッセージタイプのIANAレジストリにリストされているIETF名前空間値であり、その意味は、そのレジストリのそのPT-TLSメッセージタイプにリストされている仕様で定義されています。 。ベンダーIDがゼロでない場合、PT-TLSメッセージタイプの意味は、ベンダーIDによって識別されるベンダーによって定義されます（SMI PENのIANAレジストリにリストされています）。識別されたベンダーは推奨されますが、ベンダーIDで使用されるPT-TLSメッセージタイプの一部またはすべてをIANAに登録し、これらの各値の仕様を公開する必要はありません。
For each of the IANA registries defined by this specification, new values are added to the registry by following the IANA Specification Required policy [RFC5226].
この仕様で定義されている各IANAレジストリについて、IANA仕様の必須ポリシー[RFC5226]に従って新しい値がレジストリに追加されます。
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 has the same number of values for its use. Because there are so many values available, designated experts should not be terribly concerned about exhausting the set of values.
このドキュメントで定義されているレジストリには、多くの値があります。ほとんどの場合、IETFで定義できる値は約2 ^ 32であり、各ベンダーは同じ数の値を使用しています。非常に多くの値が利用できるため、指定された専門家は、値のセットを使い果たすことについてひどく心配する必要はありません。
Instead, designated experts should focus on the following requirements. All values in these IANA registries are required to be documented in a specification that is permanently and publicly available. IETF namespace 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-reviewed approach and 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 will need to 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 following two sections provide guidance to the IANA in creating and managing the new IANA registries defined by this specification.
次の2つのセクションは、この仕様で定義された新しいIANAレジストリの作成と管理におけるIANAのガイダンスです。
The name for this registry is "PT-TLS 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 4294967294, and a reference to the specification where the contents of this message type are defined. This specification must define the meaning of the PT-TLS Message Type and the format and semantics of the PT-TLS Message Value field that include the designated Private Enterprise Number in the PT-TLS Message Type Vendor ID field and the designated numeric value in the PT-TLS Message Type field.
このレジストリの名前は「PT-TLSメッセージタイプ」です。このレジストリの各エントリには、人間が読み取れる名前、SMIプライベートエンタープライズ番号、0〜4294967294の10進整数値、およびこのメッセージタイプのコンテンツが定義されている仕様への参照を含める必要があります。この仕様は、PT-TLSメッセージタイプの意味、およびPT-TLSメッセージタイプベンダーIDフィールドに指定されたプライベートエンタープライズ番号と、 PT-TLSメッセージタイプフィールド。
The following entries for this registry are defined in this document. Additional entries to this registry are added by following the IANA Specification Required policy, consistent with the guidelines in Section 6.1.
このドキュメントでは、このレジストリの次のエントリが定義されています。このレジストリへの追加のエントリは、セクション6.1のガイドラインに従って、IANA Specification Requiredポリシーに従って追加されます。
PEN Value Name Reference
--- -------- ------------------------ ---------
0 0 Experimental RFC 6876
0 1 Version Request RFC 6876
0 2 Version Response RFC 6876
0 3 SASL Mechanisms RFC 6876
0 4 SASL Mechanism Selection RFC 6876
0 5 SASL Authentication Data RFC 6876
0 6 SASL Result RFC 6876
0 7 PB-TNC Batch RFC 6876
0 8 PT-TLS Error RFC 6876
0 9-4294967294 Unassigned
0 4294967295 Reserved RFC 6876
The PEN 0 (IETF) PT-TLS Message Type values between 9 and 4294967294 inclusive are allocated for future assignment by the IANA.
9から4294967294までのPEN 0（IETF）PT-TLSメッセージタイプ値は、IANAによる将来の割り当てのために割り当てられます。
The name for this registry is "PT-TLS 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 4294967295, and a reference to the specification where this error code is defined. This specification must define the meaning of this error code, a PT-TLS Message Type of PT-TLS Error, the designated Private Enterprise Number in the PT-TLS Error Code Vendor ID field, and the designated numeric value in the PT-TLS Error Code field.
このレジストリの名前は「PT-TLSエラーコード」です。このレジストリの各エントリには、人間が読み取れる名前、SMIプライベートエンタープライズ番号、0〜4294967295の10進整数値、およびこのエラーコードが定義されている仕様への参照が含まれている必要があります。この仕様では、このエラーコードの意味、PT-TLSエラーのPT-TLSメッセージタイプ、PT-TLSエラーコードベンダーIDフィールドに指定されたプライベートエンタープライズ番号、およびPT-TLSエラーに指定された数値を定義する必要があります。コードフィールド。
The following entries for this registry are defined in this document. Additional entries to this registry are added following the IANA Specification Required policy, consistent with the guidelines in Section 6.1.
このドキュメントでは、このレジストリの次のエントリが定義されています。このレジストリへの追加のエントリは、セクション6.1のガイドラインに従って、IANA仕様の必須ポリシーに従って追加されます。
PEN Value Name Reference
--- ------------ --------------------- ---------
0 0 Reserved RFC 6876
0 1 Malformed Message RFC 6876
0 2 Version Not Supported RFC 6876
0 3 Type Not Supported RFC 6876
0 4 Invalid Message RFC 6876
0 5 SASL Mechanism Error RFC 6876
0 6 Invalid Parameter RFC 6876
0 7-4294967295 Unassigned
The PEN 0 (IETF) PT-TLS Error Codes between 7 and 4294967295 inclusive are allocated for future assignment by the IANA.
7から4294967295までのPEN 0（IETF）PT-TLSエラーコードは、IANAによる将来の割り当てのために割り当てられます。
Thanks to the Trusted Computing Group for contributing the initial text upon which this document was based [IFT-TLS].
このドキュメントのベースとなった最初のテキストを提供してくれたTrusted Computing Groupに感謝します[IFT-TLS]。
The authors of this document would also like to acknowledge the following people who have contributed to or provided substantial input on the preparation of this document or predecessors to it: Syam Appala, Stuart Bailey, Lauren Giroux, Steve Hanna, Josh Howlett, Scott Kelly, Carolin Latze, Sung Lee, Lisa Lorenzin, Alexey Melnikov, Ravi Sahita, Subbu Srinivasan, Susan Thomson, and Mark Townsend.
このドキュメントの作成者は、このドキュメントの作成に貢献したか、またはこのドキュメントの前身についてかなりの情報を提供してくれた次の人々にも感謝したいと思います。SyamAppala、Stuart Bailey、Lauren Giroux、Steve Hanna、Josh Howlett、Scott Kelly、 Carolin Latze、Sung Lee、Lisa Lorenzin、Alexey Melnikov、Ravi Sahita、Subbu Srinivasan、Susan Thomson、およびMark Townsend。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A。、編、およびK. Zeilenga、編、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC4616] Zeilenga、K.、Ed。、「The PLAIN Simple Authentication and Security Layer（SASL）Mechanism」、RFC 4616、2006年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「Transport Layer Security（TLS）Renegotiation Indication Extension」、RFC 5746、2010年2月。
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
[RFC5792] Sangster、P。およびK. Narayan、「PA-TNC：A Posture Attribute（PA）Protocol Compatible with Trusted Network Connect（TNC）」、RFC 5792、2010年3月。
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010.
[RFC5793] Sahita、R.、Hanna、S.、Hurst、R。、およびK. Narayan、「PB-TNC：A Posture Broker（PB）Protocol Compatible with Trusted Network Connect（TNC）」、RFC 5793、2010年3月。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[RFC5929] Altman、J.、Williams、N。、およびL. Zhu、「TLSのチャネルバインディング」、RFC 5929、2010年7月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012.
[RFC6520] Seggelmann、R.、Tuexen、M。、およびM. Williams、「Transport Layer Security（TLS）and Datagram Transport Layer Security（DTLS）Heartbeat Extension」、RFC 6520、2012年2月。
[IFT-TLS] Trusted Computing Group, "TNC IF-T: Binding to TLS", <http://www.trustedcomputinggroup.org/>, May 2009.
[IFT-TLS] Trusted Computing Group、「TNC IF-T：Binding to TLS」、<http://www.trustedcomputinggroup.org/>、2009年5月。
[PEN] IANA Private Enterprise Numbers (PEN) registry, <http://www.iana.org/assignments/enterprise-numbers>.
[PEN] IANA Private Enterprise Numbers（PEN）レジストリ、<http://www.iana.org/assignments/enterprise-numbers>。
[PT-EAP] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Work in Progress, January 2013.
[PT-EAP] Cam-Winget、N。およびP. Sangster、「PT-EAP：Posture Transport（PT）Protocol For EAP Tunnel Methods」、Work in Progress、2013年1月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、2006年4月。
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[RFC5209] Sangster、P.、Khosravi、H.、Mani、M.、Narayan、K。、およびJ. Tardo、「Network Endpoint Assessment（NEA）：Overview and Requirements」、RFC 5209、2008年6月。
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010.
[RFC5801] Josefsson、S。およびN. Williams、「Simple Authentication and Security Layer（SASL）：The Generic Security Service Application Program Interface（GSS-API）Mechanisms in Simple Authentication and Security Layer（SASL）：The GS2 Mechanism Family」、RFC 5801、2010年7月。
[RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment (NEA) Asokan Attack Analysis", RFC 6813, December 2012.
[RFC6813] Salowey、J。およびS. Hanna、「The Network Endpoint Assessment（NEA）Asokan Attack Analysis」、RFC 6813、2012年12月。
Authors' Addresses
著者のアドレス
Paul Sangster Symantec Corporation 6825 Citrine Dr. Carlsbad, CA 92009
Paul Sangster Symantec Corporation 6825 Citrine Dr. Carlsbad、CA 92009
EMail: paul_sangster@symantec.com
Nancy Cam-Winget Cisco Systems 80 West Tasman Drive San Jose, CA 95134 US
Nancy Cam-Winget Cisco Systems 80 West Tasman Drive San Jose、CA 95134 US
EMail: ncamwing@cisco.com
Joseph Salowey Cisco Systems 2901 Third Avenue Seattle, WA 98121 US
Joseph Salowey Cisco Systems 2901 Third Avenue Seattle、WA 98121 US
EMail: jsalowey@cisco.com