RFC 8471 - The Token Binding Protocol Version 1.0 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8471
タイトル : RFC 8471 - トークンバインディングプロトコルバージョン1.0
翻訳編集 : 自動生成

[要約] RFC 8471は、Token Binding Protocol Version 1.0に関する仕様書であり、トークンバインディングのセキュリティプロトコルを提供することを目的としています。トークンバインディングは、トークンとセッションを結び付けることで、セキュリティの向上とトークンの偽造の防止を実現します。

Internet Engineering Task Force (IETF)                     A. Popov, Ed.
Request for Comments: 8471                                   M. Nystroem
Category: Standards Track                                Microsoft Corp.
ISSN: 2070-1721                                               D. Balfanz
                                                             Google Inc.
                                                               J. Hodges
                                                  Kings Mountain Systems
                                                            October 2018

The Token Binding Protocol Version 1.0

トークンバインディングプロトコルバージョン1.0

Abstract

概要

This document specifies version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.

このドキュメントは、トークンバインディングプロトコルのバージョン1.0を指定します。トークンバインディングプロトコルを使用すると、クライアント/サーバーアプリケーションは、複数のTLSセッションと接続にまたがる、長期間にわたって一意に識別可能なTLSバインディングを作成できます。その後、アプリケーションはセキュリティトークンをTLSレイヤーに暗号化してバインドできるようになり、トークンのエクスポートとリプレイ攻撃を防ぎます。プライバシーを保護するために、トークンバインディング識別子はTLS経由でのみ伝達され、ユーザーはいつでもリセットできます。

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 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8471.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8471で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Token Binding Protocol Overview . . . . . . . . . . . . . . .   4
   3.  Token Binding Protocol Message  . . . . . . . . . . . . . . .   5
     3.1.  TokenBinding.tokenbinding_type  . . . . . . . . . . . . .   6
     3.2.  TokenBinding.tokenbindingid . . . . . . . . . . . . . . .   7
     3.3.  TokenBinding.signature  . . . . . . . . . . . . . . . . .   7
     3.4.  TokenBinding.extensions . . . . . . . . . . . . . . . . .   9
   4.  Establishing a Token Binding  . . . . . . . . . . . . . . . .   9
     4.1.  Client Processing Rules . . . . . . . . . . . . . . . . .   9
     4.2.  Server Processing Rules . . . . . . . . . . . . . . . . .  10
   5.  Bound Security Token Creation and Validation  . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Token Binding Key Parameters Registry . . . . . . . . . .  11
     6.2.  Token Binding Types Registry  . . . . . . . . . . . . . .  12
     6.3.  Token Binding Extensions Registry . . . . . . . . . . . .  13
     6.4.  Registration of Token Binding TLS Exporter Label  . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     7.1.  Security Token Replay . . . . . . . . . . . . . . . . . .  14
     7.2.  Downgrade Attacks . . . . . . . . . . . . . . . . . . . .  14
     7.3.  Token Binding Key-Sharing between Applications  . . . . .  14
     7.4.  Triple Handshake Vulnerability in TLS 1.2 and Older TLS
           Versions  . . . . . . . . . . . . . . . . . . . . . . . .  15
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction

1. はじめに

Servers often generate various security tokens (e.g., HTTP cookies, OAuth tokens [RFC6749]) for applications to present when accessing protected resources. In general, any party in possession of bearer security tokens gains access to certain protected resource(s). Attackers take advantage of this by exporting bearer tokens from a user's application connections or machines, presenting them to application servers, and impersonating authenticated users. The idea of Token Binding is to prevent such attacks by cryptographically binding application security tokens to the underlying TLS layer [RFC5246]. (Note: This document deals with TLS 1.2 and therefore refers to RFC 5246 (which has been obsoleted by RFC 8446); [TOKENBIND-TLS13] addresses Token Binding in TLS 1.3.)

サーバーは多くの場合、保護されたリソースにアクセスするときにアプリケーションが提示するさまざまなセキュリティトークン（HTTP Cookie、OAuthトークン[RFC6749]など）を生成します。一般に、無記名セキュリティトークンを所持している当事者は、特定の保護されたリソースにアクセスできます。攻撃者はこれを利用して、ベアラートークンをユーザーのアプリケーション接続またはマシンからエクスポートし、アプリケーションサーバーに提示し、認証されたユーザーに偽装します。トークンバインディングのアイデアは、アプリケーションのセキュリティトークンを基礎となるTLSレイヤーに暗号化してバインドすることにより、このような攻撃を防ぐことです[RFC5246]。（注：このドキュメントはTLS 1.2を扱っているため、RFC 5246に言及しています（RFC 8446によって廃止されました）。[TOKENBIND-TLS13]はTLS 1.3のトークンバインディングに対応しています。）

A Token Binding is established by a User Agent generating a private-public key pair (possibly within a secure hardware module, such as a Trusted Platform Module) per target server, providing the public key to the server, and proving possession of the corresponding private key, on every TLS connection to the server. The proof of possession involves signing the Exported Keying Material (EKM) [RFC5705] from the TLS connection with the private key. The corresponding public key is included in the Token Binding identifier structure (described in Section 3.2 ("TokenBinding.tokenbindingid")). Token Bindings are long-lived, i.e., they encompass multiple TLS connections and TLS sessions between a given client and server. To protect privacy, Token Binding IDs are never conveyed over insecure connections and can be reset by the user at any time, e.g., when clearing browser cookies.

トークンバインディングは、ターゲットサーバーごとに秘密鍵と公開鍵のペアを生成する（おそらくTrusted Platform Moduleなどの安全なハードウェアモジュール内で）ユーザーエージェントによって確立され、サーバーに公開鍵を提供し、対応する秘密鍵の所有を証明しますキー、サーバーへのすべてのTLS接続で。所持証明には、秘密鍵を使用したTLS接続からのエクスポートされた鍵素材（EKM）[RFC5705]への署名が含まれます。対応する公開鍵は、トークンバインディング識別子構造に含まれています（セクション3.2（「TokenBinding.tokenbindingid」）で説明）。トークンバインディングは存続期間が長いため、特定のクライアントとサーバー間の複数のTLS接続とTLSセッションを包含します。プライバシーを保護するために、トークンバインディングIDは安全でない接続を介して伝達されることはなく、ユーザーはいつでも（たとえば、ブラウザーのCookieをクリアするときに）リセットできます。

When issuing a security token to a client that supports Token Binding, a server includes the client's Token Binding ID (or its cryptographic hash) in the token. Later on, when a client presents a security token containing a Token Binding ID, the server verifies that the ID in the token matches the ID of the Token Binding established with the client. In the case of a mismatch, the server rejects the token (details are application specific).

トークンバインディングをサポートするクライアントにセキュリティトークンを発行する場合、サーバーはクライアントのトークンバインディングID（またはその暗号化ハッシュ）をトークンに含めます。その後、クライアントがトークンバインディングIDを含むセキュリティトークンを提示すると、サーバーは、トークン内のIDがクライアントで確立されたトークンバインディングのIDと一致することを確認します。不一致の場合、サーバーはトークンを拒否します（詳細はアプリケーション固有です）。

In order to successfully export and replay a bound security token, an attacker needs to also be able to use the client's private key; this is hard to do if the key is specially protected, e.g., generated in a secure hardware module.

バインドされたセキュリティトークンを正常にエクスポートして再生するには、攻撃者はクライアントの秘密キーも使用できる必要があります。キーが特別に保護されている場合、たとえば、安全なハードウェアモジュールで生成されている場合、これは困難です。

1.1. Requirements Language

1.1. 要件言語

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2. Token Binding Protocol Overview

2. トークンバインディングプロトコルの概要

In the course of a TLS handshake, a client and server can use the Token Binding negotiation TLS extension [RFC8472] to negotiate the Token Binding protocol version and the parameters (signature algorithm, length) of the Token Binding key. This negotiation does not require additional round trips.

TLSハンドシェイクの過程で、クライアントとサーバーはトークンバインディングネゴシエーションTLS拡張[RFC8472]を使用して、トークンバインディングプロトコルのバージョンとトークンバインディングキーのパラメーター（署名アルゴリズム、長さ）をネゴシエートできます。この交渉では、追加の往復は必要ありません。

Version 1.0 of the Token Binding protocol is represented by TB_ProtocolVersion.major = 1 and TB_ProtocolVersion.minor = 0 in the Token Binding negotiation TLS extension; see [RFC8472] ("Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation").

トークンバインディングプロトコルのバージョン1.0は、トークンバインディングネゴシエーションTLS拡張のTB_ProtocolVersion.major = 1およびTB_ProtocolVersion.minor = 0で表されます。 [RFC8472]を参照してください（「トークンバインディングプロトコルネゴシエーション用のトランスポート層セキュリティ（TLS）拡張機能」）。

The Token Binding protocol consists of one message sent by the client to the server, proving possession of one or more client-generated asymmetric private keys. This message is not sent if the Token Binding negotiation has been unsuccessful. The Token Binding message is sent with the application protocol data over TLS.

トークンバインディングプロトコルは、クライアントからサーバーに送信される1つのメッセージで構成され、クライアントが生成した1つ以上の非対称秘密鍵を所有していることを証明します。トークンバインディングのネゴシエーションが失敗した場合、このメッセージは送信されません。トークンバインディングメッセージは、TLSを介してアプリケーションプロトコルデータとともに送信されます。

A server receiving the Token Binding message verifies that the key parameters in the message match the Token Binding parameters negotiated (e.g., via [RFC8472]) and then validates the signatures contained in the Token Binding message. If either of these checks fails, the server rejects the binding, along with all associated bound tokens. Otherwise, the Token Binding is successfully established with the ID contained in the Token Binding message.

トークンバインディングメッセージを受信するサーバーは、メッセージ内のキーパラメーターが（[RFC8472]などを介して）ネゴシエートされたトークンバインディングパラメーターと一致することを確認し、トークンバインディングメッセージに含まれる署名を検証します。これらのチェックのいずれかが失敗した場合、サーバーはすべての関連するバインドされたトークンとともにバインドを拒否します。それ以外の場合、トークンバインディングは、トークンバインディングメッセージに含まれているIDで正常に確立されます。

When a server supporting the Token Binding protocol receives a bound token, the server compares the Token Binding ID in the token with the Token Binding ID established with the client. If the bound token is received on a TLS connection without a Token Binding or if the Token Binding IDs do not match, the token is rejected.

トークンバインディングプロトコルをサポートするサーバーがバインドされたトークンを受信すると、サーバーは、トークン内のトークンバインディングIDを、クライアントで確立されたトークンバインディングIDと比較します。バインドされたトークンがトークンバインディングのないTLS接続で受信された場合、またはトークンバインディングIDが一致しない場合、トークンは拒否されます。

This document defines the format of the Token Binding protocol message, the process of establishing a Token Binding, the format of the Token Binding ID, and the process of validating a bound token. [RFC8472] describes the negotiation of the Token Binding protocol and key parameters. [RFC8473] ("Token Binding over HTTP") explains how the Token Binding message is encapsulated within HTTP/1.1 messages

このドキュメントでは、トークンバインディングプロトコルメッセージの形式、トークンバインディングを確立するプロセス、トークンバインディングIDの形式、およびバインドされたトークンを検証するプロセスを定義します。 [RFC8472]は、トークンバインディングプロトコルとキーパラメータのネゴシエーションについて説明しています。 [RFC8473]（ "HTTP Binding over HTTP"）は、トークンバインディングメッセージがHTTP / 1.1メッセージ内にカプセル化される方法を説明しています

[RFC7230] or HTTP/2 messages [RFC7540]. [RFC8473] also describes Token Binding between multiple communicating parties: User Agent, Identity Provider, and Relying Party.

[RFC7230]またはHTTP / 2メッセージ[RFC7540]。 [RFC8473]は、ユーザーエージェント、アイデンティティプロバイダー、証明書利用者など、複数の通信当事者間のトークンバインディングについても説明しています。

3. Token Binding Protocol Message

3. トークンバインディングプロトコルメッセージ

The Token Binding message is sent by the client to prove possession of one or more private keys held by the client. This message MUST be sent if the client and server successfully negotiated the use of the Token Binding protocol (e.g., via [RFC8472] or a different mechanism) and MUST NOT be sent otherwise. This message MUST be sent in the client's first application protocol message. This message MAY also be sent in subsequent application protocol messages, proving possession of additional private keys held by the same client; this information can be used to facilitate Token Binding between more than two communicating parties. For example, [RFC8473] specifies an encapsulation of the Token Binding message in HTTP application protocol messages, as well as scenarios involving more than two communicating parties.

トークンバインディングメッセージは、クライアントが保持する1つ以上の秘密鍵の所有を証明するためにクライアントによって送信されます。このメッセージは、クライアントとサーバーが（[RFC8472]または別のメカニズムなどを介して）トークンバインディングプロトコルの使用を正常にネゴシエートした場合に送信する必要があり、それ以外の場合は送信してはなりません（MUST）。このメッセージは、クライアントの最初のアプリケーションプロトコルメッセージで送信する必要があります。このメッセージは、後続のアプリケーションプロトコルメッセージでも送信される場合があり、同じクライアントが保持する追加の秘密鍵を所有していることを証明します。この情報は、3つ以上の通信パーティ間のトークンバインディングを容易にするために使用できます。たとえば、[RFC8473]は、HTTPアプリケーションプロトコルメッセージでのトークンバインディングメッセージのカプセル化、および3つ以上の通信パーティが関与するシナリオを指定しています。

The Token Binding message format is defined using the TLS presentation language (see Section 4 of [RFC5246]):

トークンバインディングメッセージ形式は、TLSプレゼンテーション言語を使用して定義されます（[RFC5246]のセクション4を参照）。

   enum {
       rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255)
   } TokenBindingKeyParameters;

   struct {
       opaque modulus<1..2^16-1>;
       opaque publicexponent<1..2^8-1>;
   } RSAPublicKey;

   struct {
       opaque point <1..2^8-1>;
   } TB_ECPoint;

   struct {
       TokenBindingKeyParameters key_parameters;
       uint16 key_length;  /* Length (in bytes) of the following
                              TokenBindingID.TokenBindingPublicKey */
       select (key_parameters) {
           case rsa2048_pkcs1.5:
           case rsa2048_pss:
               RSAPublicKey rsapubkey;
           case ecdsap256:
               TB_ECPoint point;
       } TokenBindingPublicKey;
   } TokenBindingID;

   enum {
       (255)        /* No initial TB_ExtensionType registrations */
   } TB_ExtensionType;

   struct {
       TB_ExtensionType extension_type;
       opaque extension_data<0..2^16-1>;
   } TB_Extension;

   enum {
       provided_token_binding(0), referred_token_binding(1), (255)
   } TokenBindingType;

   struct {
       TokenBindingType tokenbinding_type;
       TokenBindingID tokenbindingid;
       opaque signature<64..2^16-1>; /* Signature over the concatenation
                                        of tokenbinding_type,
                                        key_parameters, and EKM */
       TB_Extension extensions<0..2^16-1>;
   } TokenBinding;

   struct {
       TokenBinding tokenbindings<132..2^16-1>;
   } TokenBindingMessage;

The Token Binding message consists of a series of TokenBinding structures, each containing the type of the Token Binding, the TokenBindingID, and a signature using the Token Binding key, optionally followed by TB_Extension structures.

トークンバインディングメッセージは一連のTokenBinding構造で構成され、それぞれにトークンバインディングのタイプ、TokenBindingID、およびトークンバインディングキーを使用した署名が含まれ、オプションでTB_Extension構造が後に続きます。

3.1. TokenBinding.tokenbinding_type

This document defines two Token Binding types:

このドキュメントでは、2つのトークンバインディングタイプを定義しています。

o provided_token_binding - used to establish a Token Binding when connecting to a server.

o provided_token_binding-サーバーに接続するときにトークンバインディングを確立するために使用されます。

o referred_token_binding - used when requesting tokens that are intended to be presented to a different server.

o referred_token_binding-別のサーバーに提示することを目的としたトークンを要求するときに使用されます。

[RFC8473] describes a use case for referred_token_binding where Token Bindings are established between multiple communicating parties: User Agent, Identity Provider, and Relying Party. The User Agent sends referred_token_binding to the Identity Provider in order to prove possession of the Token Binding key it uses with the Relying Party. The Identity Provider can then bind the token it is supplying (for presentation to the Relying Party) to the Token Binding ID contained in referred_token_binding.

[RFC8473]は、トークンバインディングが複数の通信パーティ間で確立される場合のrefered_token_bindingの使用例について説明しています：ユーザーエージェント、アイデンティティプロバイダー、および証明書利用者。ユーザーエージェントは、依拠当事者と一緒に使用するトークンバインディングキーの所有を証明するために、referred_token_bindingをアイデンティティプロバイダーに送信します。次に、アイデンティティプロバイダーは、それが提供するトークン（依存パーティに提示するため）を、referred_token_bindingに含まれるトークンバインディングIDにバインドできます。

An implementation MUST ignore any unknown Token Binding types.

実装では、不明なトークンバインディングタイプを無視する必要があります。

3.2. TokenBinding.tokenbindingid

The ID of the Token Binding established as a result of Token Binding message processing contains the identifier of the negotiated key parameters, the length (in bytes) of the Token Binding public key, and the Token Binding public key itself. The Token Binding ID can be obtained from the TokenBinding structure by discarding the Token Binding type, signature, and extensions.

トークンバインディングメッセージ処理の結果として確立されたトークンバインディングのIDには、ネゴシエートされたキーパラメータの識別子、トークンバインディング公開キーの長さ（バイト単位）、およびトークンバインディング公開キー自体が含まれます。トークンバインディングIDは、トークンバインディングタイプ、署名、および拡張機能を破棄することにより、TokenBinding構造から取得できます。

When rsa2048_pkcs1.5 or rsa2048_pss is used, RSAPublicKey.modulus and RSAPublicKey.publicexponent contain the modulus and exponent of a 2048-bit RSA public key represented in big-endian format, with leading zero bytes omitted.

rsa2048_pkcs1.5またはrsa2048_pssを使用する場合、RSAPublicKey.modulusおよびRSAPublicKey.publicexponentには、ビッグエンディアン形式で表される2048ビットのRSA公開鍵の係数と指数が含まれ、先頭のゼロバイトは省略されます。

When ecdsap256 is used, TB_ECPoint.point contains the X coordinate followed by the Y coordinate of a Curve P-256 key. The X and Y coordinates are unsigned 32-byte integers encoded in big-endian format, preserving any leading zero bytes. Future specifications may define Token Binding keys using other elliptic curves with their corresponding signature and point formats.

ecdsap256を使用する場合、TB_ECPoint.pointには、X座標とそれに続くCurve P-256キーのY座標が含まれます。 X座標とY座標は、ビッグエンディアン形式でエンコードされた符号なし32バイト整数であり、先頭のゼロバイトを保持します。将来の仕様では、他の楕円曲線と対応する署名およびポイント形式を使用してトークンバインディングキーを定義する可能性があります。

Token Binding protocol implementations SHOULD make Token Binding IDs available to the application as opaque byte sequences, so that applications do not rely on a particular Token Binding ID structure. For example, server applications will use Token Binding IDs when generating and verifying bound tokens.

トークンバインディングプロトコルの実装では、トークンバインディングIDを不透明なバイトシーケンスとしてアプリケーションで使用できるようにする必要があります。これにより、アプリケーションは特定のトークンバインディングID構造に依存しなくなります。たとえば、サーバーアプリケーションは、バインドされたトークンを生成および検証するときにトークンバインドIDを使用します。

3.3. TokenBinding.signature

When rsa2048_pkcs1.5 is used, TokenBinding.signature contains the signature generated using the RSASSA-PKCS1-v1_5 signature scheme defined in [RFC8017] with SHA256 [FIPS.180-4.2015] as the hash function.

rsa2048_pkcs1.5を使用する場合、TokenBinding.signatureには、ハッシュ関数としてSHA256 [FIPS.180-4.2015]を使用して[RFC8017]で定義されたRSASSA-PKCS1-v1_5署名方式を使用して生成された署名が含まれます。

When rsa2048_pss is used, TokenBinding.signature contains the signature generated using the RSA Probabilistic Signature Scheme (RSASSA-PSS) defined in [RFC8017] with SHA256 as the hash function. MGF1 with SHA256 MUST be used as the mask generation function (MGF), and the salt length MUST equal 32 bytes.

rsa2048_pssを使用する場合、TokenBinding.signatureには、[RFC8017]で定義されているRSA確率的署名方式（RSASSA-PSS）を使用して生成された署名が含まれ、ハッシュ関数としてSHA256が使用されます。 SHA256を使用するMGF1は、マスク生成関数（MGF）として使用する必要があり、ソルト長は32バイトに等しい必要があります。

When ecdsap256 is used, TokenBinding.signature contains a pair of 32-byte integers, R followed by S, generated with the Elliptic Curve Digital Signature Algorithm (ECDSA) using Curve P-256 and SHA256 as defined in [FIPS.186-4.2013] and [ANSI.X9-62.2005]. R and S are encoded in big-endian format, preserving any leading zero bytes.

ecdsap256を使用する場合、TokenBinding.signatureには、[FIPS.186-4.2013]で定義されている曲線P-256およびSHA256を使用して楕円曲線デジタル署名アルゴリズム（ECDSA）で生成された32バイト整数のペア、Rの後にSが含まれます。および[ANSI.X9-62.2005]。 RとSはビッグエンディアン形式でエンコードされ、先頭のゼロバイトは保持されます。

The signature is computed over the byte string representing the concatenation of:

署名は、以下の連結を表すバイト文字列に対して計算されます。

o The TokenBindingType value contained in the TokenBinding.tokenbinding_type field,

o TokenBinding.tokenbinding_typeフィールドに含まれるTokenBindingType値、

o The TokenBindingKeyParameters value contained in the TokenBindingID.key_parameters field, and

o TokenBindingID.key_parametersフィールドに含まれるTokenBindingKeyParameters値、および

o The EKM value obtained from the current TLS connection.

o 現在のTLS接続から取得したEKM値。

Please note that TLS 1.2 and earlier versions support renegotiation, which produces a new TLS master secret for the same connection, with the associated session keys and EKM value. TokenBinding.signature MUST be a signature of the EKM value derived from the TLS master secret that produced the session keys encrypting the TLS application_data record(s) containing this TokenBinding. Such use of the current EKM for the TLS connection makes replay of bound tokens within renegotiated TLS sessions detectable but requires the application to synchronize Token Binding message generation and verification with the TLS handshake state.

TLS 1.2以前のバージョンは再ネゴシエーションをサポートしていることに注意してください。これにより、関連するセッションキーとEKM値を使用して、同じ接続に対して新しいTLSマスターシークレットが生成されます。 TokenBinding.signatureは、このTokenBindingを含むTLS application_dataレコードを暗号化するセッションキーを生成したTLSマスターシークレットから派生したEKM値の署名である必要があります。 TLS接続に現在のEKMをこのように使用すると、再ネゴシエートされたTLSセッション内のバインドされたトークンの再生が検出可能になりますが、トークンバインディングメッセージの生成と検証をTLSハンドシェイク状態と同期するアプリケーションが必要です。

Specifications defining the use of Token Binding with application protocols, such as Token Binding over HTTP [RFC8473], MAY prohibit the use of TLS renegotiation in combination with Token Binding, obviating the need for such synchronization. Alternatively, such specifications need to define (1) a way to determine which EKM value corresponds to a given TokenBindingMessage and (2) a mechanism that prevents a TokenBindingMessage from being split across TLS renegotiation boundaries due to TLS message fragmentation; see Section 6.2.1 of [RFC5246]. Note that application-layer messages conveying a TokenBindingMessage may cross renegotiation boundaries in ways that make processing difficult.

HTTP経由のトークンバインディング[RFC8473]などのアプリケーションプロトコルでのトークンバインディングの使用を定義する仕様では、トークンバインディングと組み合わせたTLS再ネゴシエーションの使用を禁止して、そのような同期の必要性を取り除くことができます。または、このような仕様では、（1）特定のTokenBindingMessageに対応するEKM値を決定する方法と、（2）TLSメッセージの断片化によりTokenBindingMessageがTLS再ネゴシエーション境界を越えて分割されるのを防ぐメカニズムを定義する必要があります。 [RFC5246]のセクション6.2.1を参照してください。 TokenBindingMessageを伝達するアプリケーション層メッセージは、再交渉の境界を越えて処理が困難になる可能性があることに注意してください。

The EKM is obtained using the keying material exporters for TLS as defined in [RFC5705], by supplying the following input values:

EKMは、[RFC5705]で定義されているように、TLSの鍵素材エクスポーターを使用して、次の入力値を提供することにより取得されます。

o Label: The ASCII string "EXPORTER-Token-Binding" with no terminating NUL.

o ラベル：終了NULのないASCII文字列「EXPORTER-Token-Binding」。

o Context value: No application context supplied.

o コンテキスト値：アプリケーションコンテキストが指定されていません。

o Length: 32 bytes.

o 長さ：32バイト。

3.4. TokenBinding.extensions

A Token Binding message may optionally contain a series of TB_Extension structures, each consisting of an extension_type and extension_data. The structure and meaning of extension_data depends on the specific extension_type.

トークンバインディングメッセージには、オプションで、それぞれがextension_typeとextension_dataで構成される一連のTB_Extension構造を含めることができます。 extension_dataの構造と意味は、特定のextension_typeによって異なります。

Initially, no extension types are defined (see Section 6.3 ("Token Binding Extensions Registry")). One of the possible uses of extensions envisioned at the time of this writing is attestation: cryptographic proof that allows the server to verify that the Token Binding key is hardware bound. The definitions of such Token Binding protocol extensions are outside the scope of this specification.

最初は、拡張タイプは定義されていません（セクション6.3（「トークンバインディング拡張レジストリ」）を参照）。この記事の執筆時点で想定されていた拡張機能の可能な使用法の1つは証明です。これは、サーバーがトークンバインディングキーがハードウェアにバインドされていることを確認できる暗号化の証明です。このようなトークンバインディングプロトコル拡張の定義は、この仕様の範囲外です。

4. Establishing a Token Binding

4. トークンバインディングの確立

4.1. Client Processing Rules

4.1. クライアント処理ルール

The client MUST include at least one TokenBinding structure in the Token Binding message. When a provided_token_binding is included, the key parameters used in a provided_token_binding MUST match those negotiated with the server (e.g., via [RFC8472] or a different mechanism).

クライアントは、トークンバインディングメッセージに少なくとも1つのTokenBinding構造を含める必要があります。 provided_token_bindingが含まれている場合、provide_token_bindingで使用される主要なパラメーターは、サーバーとネゴシエートされたパラメーターと一致する必要があります（たとえば、[RFC8472]または別のメカニズムを介して）。

The client MUST generate and store Token Binding keys in a secure manner that prevents key export. In order to prevent cooperating servers from linking user identities, the scope of the Token Binding keys MUST NOT be broader than the scope of the tokens, as defined by the application protocol.

クライアントは、キーのエクスポートを防止する安全な方法でトークンバインディングキーを生成して保存する必要があります。連携するサーバーがユーザーIDをリンクしないようにするために、トークンバインディングキーのスコープは、アプリケーションプロトコルで定義されているように、トークンのスコープよりも広くしてはなりません。

When the client needs to send a referred_token_binding to the Identity Provider, the client SHALL construct the referred TokenBinding structure in the following manner:

クライアントがrefered_token_bindingをアイデンティティプロバイダーに送信する必要がある場合、クライアントは次の方法で参照されたTokenBinding構造を構築する必要があります（SHALL）。

o Set TokenBinding.tokenbinding_type to referred_token_binding.

o TokenBinding.tokenbinding_typeをreferred_token_bindingに設定します。

o Set TokenBinding.tokenbindingid to the Token Binding ID used with the Relying Party.

o TokenBinding.tokenbindingidを依存パーティで使用されるトークンバインディングIDに設定します。

o Generate TokenBinding.signature, using the EKM value of the TLS connection to the Identity Provider, the Token Binding key established with the Relying Party, and the signature algorithm indicated by the associated key parameters. Note that these key parameters may differ from the key parameters negotiated with the Identity Provider.

o IDプロバイダーへのTLS接続のEKM値、証明書利用者で確立されたトークンバインディングキー、および関連するキーパラメーターで示される署名アルゴリズムを使用して、TokenBinding.signatureを生成します。これらのキーパラメータは、アイデンティティプロバイダとネゴシエートするキーパラメータとは異なる場合があることに注意してください。

Conveying referred Token Bindings in this fashion allows the Identity Provider to verify that the client controls the Token Binding key used with the Relying Party.

この方法で参照トークンバインディングを伝達することにより、IDプロバイダーは、クライアントが証明書利用者で使用されるトークンバインディングキーを制御していることを確認できます。

4.2. Server Processing Rules

4.2. サーバー処理ルール

The triple handshake vulnerability in TLS 1.2 and older TLS versions affects the security of the Token Binding protocol, as described in Section 7 ("Security Considerations"). Therefore, the server MUST NOT negotiate the use of the Token Binding protocol with these TLS versions, unless the server also negotiates the extended master secret TLS extension [RFC7627] and the renegotiation indication TLS extension [RFC5746].

セクション7（「セキュリティの考慮事項」）で説明されているように、TLS 1.2以前のTLSバージョンのトリプルハンドシェイクの脆弱性は、トークンバインディングプロトコルのセキュリティに影響します。したがって、サーバーが拡張マスターシークレットTLS拡張[RFC7627]と再ネゴシエーション表示TLS拡張[RFC5746]もネゴシエートしない限り、サーバーはこれらのTLSバージョンでトークンバインディングプロトコルの使用をネゴシエートしてはなりません（MUST NOT）。

If the use of the Token Binding protocol was not negotiated but the client sends a Token Binding message, the server MUST reject any contained bindings.

トークンバインディングプロトコルの使用がネゴシエートされなかったが、クライアントがトークンバインディングメッセージを送信した場合、サーバーは含まれているバインディングをすべて拒否する必要があります。

If the Token Binding type is "provided_token_binding", the server MUST verify that the signature algorithm (including an elliptic curve in the case of ECDSA) and key length in the Token Binding message match those negotiated with this client (e.g., via [RFC8472] or a different mechanism). In the case of a mismatch, the server MUST reject the binding. Token Bindings of type "referred_token_binding" may use different key parameters than those negotiated with this client.

トークンバインディングタイプが「provided_token_binding」の場合、サーバーは、署名アルゴリズム（ECDSAの場合は楕円曲線を含む）とトークンバインディングメッセージのキーの長さが、このクライアントと交渉したもの（たとえば[RFC8472]を介して）と一致することを確認する必要があります。または別のメカニズム）。不一致の場合、サーバーはバインディングを拒否する必要があります。タイプ「referred_token_binding」のトークンバインディングは、このクライアントとネゴシエートされたものとは異なるキーパラメータを使用する場合があります。

If the Token Binding message does not contain at least one TokenBinding structure or if a signature contained in any TokenBinding structure is invalid, the server MUST reject the binding.

トークンバインディングメッセージに少なくとも1つのTokenBinding構造が含まれていない場合、またはTokenBinding構造に含まれている署名が無効な場合、サーバーはバインディングを拒否する必要があります。

Servers MUST ignore any unknown extensions. Initially, no extension types are defined (see Section 6.3 ("Token Binding Extensions Registry")).

サーバーは不明な拡張機能を無視する必要があります。最初は、拡張タイプは定義されていません（セクション6.3（「トークンバインディング拡張レジストリ」）を参照）。

If all checks defined above have passed successfully, the Token Binding between this client and server is established. The Token Binding ID(s) conveyed in the Token Binding message can be provided to the server-side application. The application may then use the Token Binding IDs for bound security token creation and validation; see Section 5.

上記で定義されたすべてのチェックが成功した場合、このクライアントとサーバー間のトークンバインディングが確立されます。トークンバインディングメッセージで伝達されるトークンバインディングIDは、サーバー側アプリケーションに提供できます。アプリケーションは、バインドされたセキュリティトークンの作成と検証にトークンバインドIDを使用できます。セクション5を参照してください。

If a Token Binding is rejected, any associated bound tokens presented on the current TLS connection MUST also be rejected by the server. The effect of this is application specific, e.g., failing requests, a requirement for the client to re-authenticate and present a different token, or connection termination.

トークンバインディングが拒否された場合、現在のTLS接続で提示されている関連するバインドされたトークンもサーバーによって拒否されなければなりません（MUST）。これの影響は、アプリケーション固有です。たとえば、要求の失敗、クライアントが再認証して別のトークンを提示するための要件、または接続の終了などです。

5. Bound Security Token Creation and Validation

5. バインドされたセキュリティトークンの作成と検証

Security tokens can be bound to the TLS layer in a variety of ways, e.g., by embedding the Token Binding ID or its cryptographic hash in the token or by maintaining a database mapping tokens to Token Binding IDs. The specific method of generating bound security tokens is defined by the application and is beyond the scope of this document. Note that applicable security considerations are outlined in Section 7.

セキュリティトークンは、さまざまな方法でTLSレイヤーにバインドできます。たとえば、トークンバインディングIDまたはその暗号化ハッシュをトークンに埋め込むか、データベースマッピングトークンをトークンバインディングIDに維持することにより、バインドされたセキュリティトークンを生成する具体的な方法はアプリケーションによって定義されており、このドキュメントの範囲を超えています。該当するセキュリティの考慮事項については、セクション7で概説しています。

Either or both clients and servers MAY create bound security tokens. For example, HTTPS servers employing Token Binding for securing their HTTP cookies will bind these cookies. In the case of a server-initiated challenge-response protocol employing Token Binding and TLS, the client can, for example, incorporate the Token Binding ID within the signed object it returns, thus binding the object.

クライアントとサーバーのどちらかまたは両方が、バインドされたセキュリティトークンを作成する場合があります。たとえば、HTTP Cookieを保護するためにトークンバインディングを採用しているHTTPSサーバーは、これらのCookieをバインドします。トークンバインディングとTLSを使用するサーバー起動チャレンジ/レスポンスプロトコルの場合、クライアントは、たとえば、トークンバインディングIDを、それが返す署名付きオブジェクト内に組み込んで、オブジェクトをバインドできます。

Upon receipt of a security token, the server attempts to retrieve Token Binding ID information from the token and from the TLS connection with the client. Application-provided policy determines whether to honor non-bound (bearer) tokens. If the token is bound and a Token Binding has not been established for the client connection, the server MUST reject the token. If the Token Binding ID for the token does not match the Token Binding ID established for the client connection, the server MUST reject the token.

サーバーは、セキュリティトークンを受信すると、トークンとクライアントとのTLS接続からトークンバインディングID情報を取得しようとします。アプリケーションが提供するポリシーは、非バインド（ベアラー）トークンを受け入れるかどうかを決定します。トークンがバインドされていて、クライアント接続のトークンバインディングが確立されていない場合、サーバーはトークンを拒否する必要があります。トークンのトークンバインディングIDがクライアント接続用に確立されたトークンバインディングIDと一致しない場合、サーバーはトークンを拒否する必要があります。

6. IANA Considerations

6. IANAに関する考慮事項

This section establishes a new IANA registry titled "Token Binding Protocol" with subregistries "Token Binding Key Parameters", "Token Binding Types", and "Token Binding Extensions". It also registers a new TLS exporter label in the "TLS Exporter Labels" registry.

このセクションでは、「トークンバインディングプロトコル」というタイトルの新しいIANAレジストリを、サブレジストリ「トークンバインディングキーパラメータ」、「トークンバインディングタイプ」、および「トークンバインディング拡張」で確立します。また、新しいTLSエクスポーターラベルを「TLSエクスポーターラベル」レジストリに登録します。

6.1. Token Binding Key Parameters Registry

6.1. トークンバインディングキーパラメータレジストリ

This document establishes a subregistry for identifiers of Token Binding key parameters titled "Token Binding Key Parameters" under the "Token Binding Protocol" registry.

このドキュメントは、「Token Binding Protocol」レジストリの下に「Token Binding Key Parameters」というタイトルのトークンバインディングキーパラメータの識別子のサブレジストリを確立します。

Entries in this registry require the following fields:

このレジストリのエントリには、次のフィールドが必要です。

o Value: The octet value that identifies a set of Token Binding key parameters (0-255).

o 値：トークンバインディングキーパラメーターのセット（0〜255）を識別するオクテット値。

o Description: The description of the Token Binding key parameters.

o 説明：トークンバインディングキーパラメータの説明。

o Reference: A reference to a specification that defines the Token Binding key parameters.

o 参照：トークンバインディングキーパラメータを定義する仕様への参照。

This registry operates under the "Specification Required" policy as defined in [RFC8126]. The designated expert will require the inclusion of a reference to a permanent and readily available specification that enables the creation of interoperable implementations using the identified set of Token Binding key parameters.

このレジストリは、[RFC8126]で定義されている「Specification Required」ポリシーの下で動作します。指定された専門家は、識別されたトークンバインディングキーパラメータのセットを使用して相互運用可能な実装の作成を可能にする永続的ですぐに利用可能な仕様への参照を含める必要があります。

An initial set of registrations for this registry follows:

このレジストリの最初の登録セットは次のとおりです。

Value: 0 Description: rsa2048_pkcs1.5 Specification: This document

値：0説明：rsa2048_pkcs1.5仕様：このドキュメント

Value: 1 Description: rsa2048_pss Specification: This document

値：1説明：rsa2048_pss仕様：このドキュメント

Value: 2 Description: ecdsap256 Specification: This document

値：2説明：ecdsap256仕様：このドキュメント

6.2. Token Binding Types Registry

6.2. トークンバインディングタイプレジストリ

This document establishes a subregistry for Token Binding type identifiers titled "Token Binding Types" under the "Token Binding Protocol" registry.

このドキュメントは、「Token Binding Protocol」レジストリの下に「Token Binding Types」というタイトルのトークンバインディングタイプ識別子のサブレジストリを確立します。

Entries in this registry require the following fields:

このレジストリのエントリには、次のフィールドが必要です。

o Value: The octet value that identifies the Token Binding type (0-255).

o 値：トークンバインディングタイプを識別するオクテット値（0〜255）。

o Description: The description of the Token Binding type.

o 説明：トークンバインディングタイプの説明。

o Reference: A reference to a specification that defines the Token Binding type.

o 参照：トークンバインディングタイプを定義する仕様への参照。

このレジストリは、[RFC8126]で定義されている「Specification Required」ポリシーの下で動作します。指定されたエキスパートは、識別されたトークンバインディングタイプを使用して相互運用可能な実装の作成を可能にする永続的ですぐに利用可能な仕様への参照を含める必要があります。

An initial set of registrations for this registry follows:

このレジストリの最初の登録セットは次のとおりです。

Value: 0 Description: provided_token_binding Specification: This document

値：0説明：provided_token_binding仕様：このドキュメント

Value: 1 Description: referred_token_binding Specification: This document

値：1説明：referred_token_binding仕様：このドキュメント

6.3. Token Binding Extensions Registry

6.3. トークンバインディング拡張レジストリ

This document establishes a subregistry for Token Binding extensions titled "Token Binding Extensions" under the "Token Binding Protocol" registry.

このドキュメントでは、「Token Binding Protocol」レジストリの下に「Token Binding Extensions」というタイトルのトークンバインディング拡張のサブレジストリを設定します。

Entries in this registry require the following fields:

このレジストリのエントリには、次のフィールドが必要です。

o Value: The octet value that identifies the Token Binding extension (0-255).

o 値：トークンバインディング拡張機能を識別するオクテット値（0〜255）。

o Description: The description of the Token Binding extension.

o 説明：トークンバインディング拡張機能の説明。

o Reference: A reference to a specification that defines the Token Binding extension.

o 参照：トークンバインディング拡張を定義する仕様への参照。

このレジストリは、[RFC8126]で定義されている「Specification Required」ポリシーの下で動作します。指定されたエキスパートは、識別されたトークンバインディング拡張を使用して相互運用可能な実装の作成を可能にする永続的ですぐに利用可能な仕様への参照を含める必要があります。このドキュメントでは、「Token Binding Extensions」レジストリに初期登録は作成されません。

6.4. Registration of Token Binding TLS Exporter Label

6.4. トークンバインディングTLSエクスポーターラベルの登録

This document adds the following registration in the "TLS Exporter Labels" registry:

このドキュメントは、「TLS Exporter Labels」レジストリに次の登録を追加します。

Value: EXPORTER-Token-Binding DTLS-OK: Y Recommended: Y Reference: This document

値：EXPORTER-Token-Binding DTLS-OK：Y推奨：Y参照：このドキュメント

7. Security Considerations

7. セキュリティに関する考慮事項

7.1. Security Token Replay

7.1. セキュリティトークンの再生

The goal of the Token Binding protocol is to prevent attackers from exporting and replaying security tokens and from thereby impersonating legitimate users and gaining access to protected resources. Bound tokens can be replayed by malware present in User Agents; this may be undetectable to a server. However, in order to export bound tokens to other machines and successfully replay them, attackers also need to export corresponding Token Binding private keys. Token Binding private keys are therefore high-value assets and SHOULD be strongly protected, ideally by generating them in a hardware security module that prevents key export.

トークンバインディングプロトコルの目的は、攻撃者がセキュリティトークンをエクスポートして再生し、それによって正当なユーザーになりすまして、保護されたリソースにアクセスすることを防ぐことです。バインドされたトークンは、ユーザーエージェントに存在するマルウェアによって再生できます。これはサーバーで検出できない場合があります。ただし、バインドされたトークンを他のマシンにエクスポートして正常に再生するために、攻撃者は対応するトークンバインディングの秘密鍵もエクスポートする必要があります。したがって、トークンバインディングの秘密鍵は価値の高い資産であり、理想的には鍵のエクスポートを防止するハードウェアセキュリティモジュールで生成することにより、強力に保護する必要があります。

The manner in which a token is bound to the TLS layer is defined by the application and is beyond the scope of this document. However, the resulting bound token needs to be integrity-protected, so that an attacker cannot remove the binding or substitute a Token Binding ID of their choice without detection.

トークンがTLSレイヤーにバインドされる方法はアプリケーションによって定義され、このドキュメントの範囲を超えています。ただし、結果のバインドされたトークンは整合性が保護されている必要があるため、攻撃者はバインディングを削除したり、選択したトークンバインディングIDを検出せずに置き換えたりすることはできません。

The Token Binding protocol does not prevent cooperating clients from sharing a bound token. A client could intentionally export a bound token with the corresponding Token Binding private key or perform signatures using this key on behalf of another client.

トークンバインドプロトコルは、連携するクライアントがバインドされたトークンを共有することを妨げません。クライアントは、対応するトークンバインディングの秘密キーを使用して、バインドされたトークンを意図的にエクスポートしたり、別のクライアントに代わってこのキーを使用して署名を実行したりできます。

7.2. Downgrade Attacks

7.2. ダウングレード攻撃

The Token Binding protocol MUST be negotiated using a mechanism that prevents downgrade attacks. For example, [RFC8472] specifies a TLS extension for Token Binding negotiation. TLS detects handshake message modification by active attackers; therefore, it is not possible for an attacker to remove or modify the "token_binding" extension without breaking the TLS handshake. The signature algorithm and key length used in the TokenBinding of type "provided_token_binding" MUST match the negotiated parameters.

トークンバインディングプロトコルは、ダウングレード攻撃を防止するメカニズムを使用してネゴシエートする必要があります。たとえば、[RFC8472]は、トークンバインディングネゴシエーションのTLS拡張を指定します。 TLSは、アクティブな攻撃者によるハンドシェイクメッセージの変更を検出します。したがって、攻撃者がTLSハンドシェイクを中断せずに「token_binding」拡張を削除または変更することはできません。タイプ「provided_token_binding」のTokenBindingで使用される署名アルゴリズムとキーの長さは、ネゴシエートされたパラメーターと一致する必要があります。

7.3. アプリケーション間のトークンバインディングキー共有

Existing systems provide a variety of platform-specific mechanisms for certain applications to share tokens, e.g., to enable "single sign-on" scenarios. For these scenarios to keep working with bound tokens, the applications that are allowed to share tokens will need to also share Token Binding keys. Care must be taken to restrict the sharing of Token Binding keys to the same group(s) of applications that shares the same tokens.

既存のシステムは、特定のアプリケーションがトークンを共有するためのさまざまなプラットフォーム固有のメカニズムを提供します。たとえば、「シングルサインオン」シナリオを有効にします。これらのシナリオでバインドされたトークンを引き続き使用するには、トークンの共有を許可されているアプリケーションがトークンバインディングキーも共有する必要があります。トークンバインディングキーの共有を、同じトークンを共有するアプリケーションの同じグループに制限するように注意する必要があります。

7.4. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions

7.4. TLS 1.2以前のTLSバージョンでのトリプルハンドシェイクの脆弱性

The Token Binding protocol relies on the TLS exporters [RFC5705] to associate a TLS connection with a Token Binding. The triple handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and older TLS versions, allowing the attacker to synchronize keying material between TLS connections. The attacker can then successfully replay bound tokens. For this reason, the Token Binding protocol MUST NOT be negotiated with these TLS versions, unless the extended master secret TLS extension [RFC7627] and the renegotiation indication TLS extension [RFC5746] have also been negotiated.

トークンバインディングプロトコルは、TLSエクスポータ[RFC5705]に依存して、TLS接続をトークンバインディングに関連付けます。トリプルハンドシェイク攻撃[TRIPLE-HS]は、TLS 1.2以前のTLSバージョンの既知の脆弱性であり、攻撃者がTLS接続間でキー情報を同期できるようにします。その後、攻撃者はバインドされたトークンを正常に再生できます。このため、拡張マスターシークレットTLS拡張[RFC7627]と再ネゴシエーション表示TLS拡張[RFC5746]もネゴシエートされていない限り、トークンバインディングプロトコルはこれらのTLSバージョンとネゴシエートしてはなりません（MUST NOT）。

8. Privacy Considerations

8. プライバシーに関する考慮事項

The Token Binding protocol uses persistent, long-lived Token Binding IDs. To protect privacy, Token Binding IDs are never transmitted in clear text and can be reset by the user at any time, e.g., when clearing browser cookies. Some applications offer a special privacy mode where they don't store or use tokens supplied by the server, e.g., "in private" browsing. When operating in this special privacy mode, applications SHOULD use newly generated Token Binding keys and delete them when exiting this mode; otherwise, they SHOULD NOT negotiate Token Binding at all.

トークンバインディングプロトコルは、永続的で存続期間の長いトークンバインディングIDを使用します。プライバシーを保護するために、トークンバインディングIDがクリアテキストで送信されることはなく、ユーザーはいつでも（たとえば、ブラウザーのCookieをクリアするときに）リセットできます。一部のアプリケーションは、サーバーから提供されたトークンを保存または使用しない特別なプライバシーモードを提供します（「プライベート」ブラウジングなど）。この特別なプライバシーモードで動作する場合、アプリケーションは新しく生成されたトークンバインディングキーを使用し、このモードを終了するときにそれらを削除する必要があります。それ以外の場合は、トークンバインディングをネゴシエートしないでください。

In order to prevent cooperating servers from linking user identities, the scope of the Token Binding keys MUST NOT be broader than the scope of the tokens, as defined by the application protocol.

連携するサーバーがユーザーIDをリンクしないようにするために、トークンバインディングキーのスコープは、アプリケーションプロトコルで定義されているように、トークンのスコープよりも広くしてはなりません。

A server can use tokens and Token Binding IDs to track clients. Client applications that automatically limit the lifetime or scope of tokens to maintain user privacy SHOULD apply the same validity time and scope limits to Token Binding keys.

サーバーは、トークンとトークンバインディングIDを使用してクライアントを追跡できます。トークンの有効期間またはスコープを自動的に制限してユーザーのプライバシーを維持するクライアントアプリケーションは、同じ有効時間とスコープの制限をトークンバインディングキーに適用する必要があります（SHOULD）。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[ANSI.X9-62.2005] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, November 2005.

[ANSI.X9-62.2005] American National Standards Institute、「金融サービス業界の公開鍵暗号化：楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI X9.62、2005年11月。

[FIPS.180-4.2015] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.

[FIPS.180-4.2015]国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<https：//nvlpubs.nist .gov / nistpubs / FIPS / NIST.FIPS.180-4.pdf>。

[FIPS.186-4.2013] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://nvlpubs.nist.gov/nistpubs/fips/ nist.fips.186-4.pdf>.

[FIPS.186-4.2013]国立標準技術研究所、「デジタル署名標準（DSS）」、FIPS 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<https：//nvlpubs.nist .gov / nistpubs / fips / nist.fips.186-4.pdf>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。

[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.

[RFC5705] Rescorla、E。、「Keying Material Exporters for Transport Layer Security（TLS）」、RFC 5705、DOI 10.17487 / RFC5705、2010年3月、<https://www.rfc-editor.org/info/rfc5705>。

[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <https://www.rfc-editor.org/info/rfc5746>.

[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「Transport Layer Security（TLS）Renegotiation Indication Extension」、RFC 5746、DOI 10.17487 / RFC5746、2010年2月、<https：/ /www.rfc-editor.org/info/rfc5746>。

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。

[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.

[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：// www.rfc-editor.org/info/rfc7540>。

[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <https://www.rfc-editor.org/info/rfc7627>.

[RFC7627] Bhargavan、K。、編、Delignat-Lavaud、A.、Pironti、A.、Langley、A。、およびM. Ray、「Transport Layer Security（TLS）Session Hash and Extended Master Secret Extension」、RFC 7627、DOI 10.17487 / RFC7627、2015年9月、<https://www.rfc-editor.org/info/rfc7627>。

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 2018, <https://www.rfc-editor.org/info/rfc8472>.

[RFC8472] Popov、A.、Ed。、Nystroem、M。、およびD. Balfanz、「Transport Layer Security（TLS）Extension for Token Binding Protocol Negotiation」、RFC 8472、DOI 10.17487 / RFC8472、2018年10月、<https： //www.rfc-editor.org/info/rfc8472>。

[RFC8473] Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and J. Hodges, "Token Binding over HTTP", RFC 8473, DOI 10.17487/RFC8473, October 2018, <https://www.rfc-editor.org/info/rfc8473>.

[RFC8473] Popov、A.、Nystroem、M.、Balfanz、D.、Ed。、Harper、N。、およびJ. Hodges、「HTTPによるトークンバインディング」、RFC 8473、DOI 10.17487 / RFC8473、2018年10月、< https://www.rfc-editor.org/info/rfc8473>。

9.2. Informative References

9.2. 参考引用

[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https://www.rfc-editor.org/info/rfc6749>。

[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.

[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J.、and A. Rusch、 "PKCS＃1：RSA Cryptography Specifications Version 2.2"、RFC 8017、DOI 10.17487 / RFC8017、November 2016、< https://www.rfc-editor.org/info/rfc8017>。

[TOKENBIND-TLS13] Harper, N., "Token Binding for Transport Layer Security (TLS) Version 1.3 Connections", Work in Progress, draft-ietf-tokbind-tls13-01, May 2018.

[TOKENBIND-TLS13] Harper、N。、「トランスポート層セキュリティ（TLS）バージョン1.3接続のトークンバインディング」、作業中、draft-ietf-tokbind-tls13-01、2018年5月。

[TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Symposium on Security and Privacy, DOI 10.1109/SP.2014.14, May 2014.

[TRIPLE-HS] Bhargavan、K.、Delignat-Lavaud、A.、Fournet、C.、Pironti、A。、およびP. Strub、「Triple Handshakes and Cookie Cutters：Breaking and Fixing Authentication over TLS over」、IEEEシンポジウムセキュリティとプライバシー、DOI 10.1109 / SP.2014.14、2014年5月。

Acknowledgements

謝辞

This document incorporates comments and suggestions offered by Eric Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony Nadalin, Michael B. Jones, Bill Cox, Nick Harper, Brian Campbell, Benjamin Kaduk, Alexey Melnikov, and others.

このドキュメントには、Eric Rescorla、Gabriel Montenegro、Martin Thomson、Vinod Anupam、Anthony Nadalin、Michael B. Jones、Bill Cox、Nick Harper、Brian Campbell、Benjamin Kaduk、Alexey Melnikovなどが提供するコメントと提案が組み込まれています。

This document was produced under the chairmanship of John Bradley and Leif Johansson. The area directors included Eric Rescorla, Kathleen Moriarty, and Stephen Farrell.

このドキュメントは、John BradleyとLeif Johanssonの議長の下で作成されました。エリアディレクターには、Eric Rescorla、Kathleen Moriarty、Stephen Farrellが含まれていました。

Authors' Addresses

著者のアドレス

Andrei Popov (editor) Microsoft Corp. United States of America

アンドレイ・ポポフ（編集者）マイクロソフト社アメリカ合衆国

   Email: andreipo@microsoft.com

Magnus Nystroem Microsoft Corp. United States of America

Magnus Nystroem Microsoft Corp.アメリカ合衆国

   Email: mnystrom@microsoft.com

Dirk Balfanz Google Inc. United States of America

Dirk Balfanz Google Inc.アメリカ合衆国

   Email: balfanz@google.com

Jeff Hodges Kings Mountain Systems United States of America

ジェフホッジスキングスマウンテンシステムズアメリカ合衆国

   Email: Jeff.Hodges@KingsMountain.com