[要約] RFC 4680は、TLS (Transport Layer Security) プロトコルにおける補足データのためのハンドシェイクメッセージを定義しています。このRFCの目的は、TLSハンドシェイクプロセス中に追加情報を交換するための標準的な方法を提供することです。利用場面としては、認証プロセス中にクライアントやサーバーが追加の属性やポリシー情報を交換する必要がある場合などが挙げられます。関連するRFCには、TLSを定義するRFC 5246（TLS 1.2）や、その後継であるRFC 8446（TLS 1.3）などがあります。RFC 4680は、TLSの拡張性と柔軟性を高めるために重要な役割を果たしています。
Network Working Group S. Santesson
Request for Comments: 4680 Microsoft
Updates: 4346 September 2006
Category: Standards Track
TLS Handshake Message for Supplemental Data
TLS補足データの握手メッセージ
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types.
この仕様は、補足アプリケーションデータの交換のためのTLSハンドシェイクメッセージを定義します。TLS Helloメッセージ拡張機能は、TLSクライアントとTLSサーバーの両方でサポートされている補足データ型を決定するために使用されます。次に、補足データハンドシェイクメッセージを使用してデータを交換します。他のドキュメントでは、これらの拡張の構文と、関連する補足データ型の構文を定義します。
Recent standards activities have proposed different mechanisms for transmitting supplemental application data in the TLS handshake message. For example, recent proposals transfer data that is not processed by the TLS protocol itself, but assist the TLS-protected application in the authentication and authorization decisions. One proposal transfers user name hints for locating credentials, and another proposal transfers attribute certificates and Security Assertions Markup Language (SAML) assertions for authorization checks.
最近の標準活動により、TLSハンドシェイクメッセージに補足アプリケーションデータを送信するためのさまざまなメカニズムが提案されています。たとえば、最近の提案は、TLSプロトコル自体によって処理されないが、認証および承認の決定においてTLS保護されたアプリケーションを支援するデータを転送します。1つの提案は、資格情報を見つけるためのユーザー名を転送し、別の提案は属性証明書とセキュリティアサーションマークアップ言語（SAML）の認可チェックのアサーションを転送します。
In order to avoid definition of multiple handshake messages, one for each new type of application-specific supplemental data, this specification defines a new handshake message type that bundles together all data objects that are to be delivered to the TLS-protected application and sends them in a single handshake message.
複数のハンドシェイクメッセージの定義を回避するために、1つは新しいタイプのアプリケーション固有の補足データに1つずつ、この仕様では、TLS保護されたアプリケーションに配信されるすべてのデータオブジェクトをバンドルする新しいハンドシェイクメッセージタイプを定義します。単一のハンドシェイクメッセージで。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [N1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [N1]に記載されているように解釈される。
The syntax for the supplemental_data handshake message is defined using the TLS Presentation Language, which is specified in Section 4 of [N2].
補足_DATAハンドシェイクメッセージの構文は、[N2]のセクション4で指定されているTLSプレゼンテーション言語を使用して定義されます。
The new supplemental_data handshake message type is defined to accommodate communication of supplemental data objects as agreed during the exchange of extensions in the client and server hello messages. See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake message types.
新しいsupplemental_dataハンドシェイクメッセージタイプは、クライアントとサーバーのヘラメッセージの拡張の交換中に合意された補足データオブジェクトの通信に対応するために定義されます。他のハンドシェイクメッセージタイプについては、RFC 2246（TLS 1.0）[N2]およびRFC 4346（TLS 1.1）[N3]を参照してください。
Information provided in a supplemental data object MUST be intended to be used exclusively by applications and protocols above the TLS protocol layer. Any such data MUST NOT need to be processed by the TLS protocol.
補足データオブジェクトで提供される情報は、TLSプロトコル層の上のアプリケーションとプロトコルによってのみ使用することを目的としている必要があります。このようなデータは、TLSプロトコルで処理する必要はありません。
enum {
supplemental_data(23), (255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* octets in message */
select (HandshakeType) {
case supplemental_data: SupplementalData;
} body;
} Handshake;
struct {
SupplementalDataEntry supp_data<1..2^24-1>;
} SupplementalData;
struct {
SupplementalDataType supp_data_type;
uint16 supp_data_length;
select(SupplementalDataType) { }
} SupplementalDataEntry;
enum {
(65535)
} SupplementalDataType;
supp_data_length This field is the length (in bytes) of the data selected by SupplementalDataType.
supp_data_lengthこのフィールドは、補足乳酸型によって選択されたデータの長さ（バイト単位）です。
The client MUST NOT send more than one SupplementalData handshake message, and the server MUST NOT send more than one SupplementalData handshake message. Receiving more than one SupplementalData handshake message results in a fatal error, and the receiver MUST close the connection with a fatal unexpected_message alert.
クライアントは、複数の補足乳酸ハンドシェイクメッセージを送信してはなりません。サーバーは、複数の補足乳房ハンドシェイクメッセージを送信してはなりません。複数のサプリメントダルタタヤングハンドシェイクメッセージを受信すると、致命的なエラーが発生し、受信者は致命的な予想外の_messageアラートで接続を閉じる必要があります。
If present, the SupplementalData handshake message MUST contain a non-empty SupplementalDataEntry structure carrying data associated with at least one defined SupplementalDataType. An explicit agreement that governs presence of any supplemental data MUST be concluded between client and server for each SupplementalDataType using the TLS extensions [N4] in the client and server hello messages. Receiving an unexpected SupplementalData handshake message results in a fatal error, and the receiver MUST close the connection with a fatal unexpected_message alert.
存在する場合、サプリメントダルタタの握手メッセージには、少なくとも1つの定義された補足乳房型に関連付けられたデータを運ぶ非空白の補足エントリ構造が含まれている必要があります。クライアントとサーバーのHelloメッセージのTLS拡張機能[N4]を使用して、各補足データの補足データの存在を支配する明示的な合意は、クライアントとサーバーの間で締めくくる必要があります。予期しない補足乳房の握手メッセージを受信すると、致命的なエラーが発生し、受信者は致命的な予想外の_messageアラートで接続を閉じる必要があります。
Other documents will define specific SupplementalDataTypes and their associated data syntax and processing. These same specifications must also specify the client and server hello message extensions that are used to negotiate the support for the specified supplemental data type. This document simply specifies the TLS Handshake Protocol message that will carry the supplemental data objects.
他のドキュメントでは、特定の補足乳酸タイプとそれに関連するデータの構文と処理を定義します。これらの同じ仕様は、指定された補足データタイプのサポートをネゴシエートするために使用されるクライアントとサーバーのHelloメッセージ拡張機能を指定する必要があります。このドキュメントは、補足データオブジェクトを伝えるTLSハンドシェイクプロトコルメッセージを指定するだけです。
Different situations require the transfer of supplemental data from the client to the server, require the transfer of supplemental data from the server to the client, or both ways. All three situations are fully supported.
さまざまな状況では、クライアントからサーバーに補足データを転送する必要があり、サーバーからクライアント、またはその両方に補足データを転送する必要があります。3つの状況はすべて完全にサポートされています。
The SupplementalData handshake message, if exchanged, MUST be sent as the first handshake message as illustrated in Figure 1 below.
Supplementaldataの握手メッセージは、交換された場合、以下の図1に示すように、最初の手揺るメッセージとして送信する必要があります。
Client Server
クライアントサーバー
ClientHello (with extensions) -------->
ServerHello(with extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages.
* オプションまたは状況に依存するメッセージを示します。
Figure 1. Message Flow with SupplementalData
図1.補足乳酸によるメッセージの流れ
Each SupplementalDataType included in the handshake message defined in this specification introduces its own unique set of security properties and related considerations. Security considerations must therefore be defined in each document that defines a supplemental data type.
この仕様で定義されているハンドシェイクメッセージに含まれる各補足乳酸タイプは、独自のセキュリティプロパティと関連する考慮事項を紹介します。したがって、セキュリティ上の考慮事項は、補足データ型を定義する各ドキュメントで定義する必要があります。
In some cases, the SupplementalData information may be sensitive. The double handshake technique can be used to provide protection for the SupplementalData information. Figure 2 illustrates the double handshake, where the initial handshake does not include any extensions, but it does result in protected communications. Then, a second handshake that includes the SupplementalData information is performed using the protected communications. In Figure 2, the number on the right side indicates the amount of protection for the TLS message on that line. A zero (0) indicates that there is no communication protection; a one (1) indicates that protection is provided by the first TLS session; and a two (2) indicates that protection is provided by both TLS sessions.
場合によっては、補足情報が敏感になる場合があります。ダブルハンドシェイクテクニックは、補足情報を保護するために使用できます。図2は、最初の握手には拡張機能が含まれていないが、保護された通信が発生するダブルハンドシェイクを示しています。次に、補足情報を含む中握手が保護された通信を使用して実行されます。図2では、右側の数値は、その行のTLSメッセージの保護量を示しています。ゼロ（0）は、通信保護がないことを示します。A（1）は、保護が最初のTLSセッションによって提供されることを示します。また、2つのTLSセッションによって保護が提供されることを2つ示します。
The placement of the SupplementalData message in the TLS Handshake results in the server providing its SupplementalData information before the client is authenticated. In many situations, servers will not want to provide authorization information until the client is authenticated. The double handshake illustrated in Figure 2 provides a technique to ensure that the parties are mutually authenticated before either party provides SupplementalData information.
TLSの握手に補足メッセージを配置すると、クライアントが認証される前に補足情報を提供するサーバーになります。多くの状況では、サーバーはクライアントが認証されるまで許可情報を提供したくありません。図2に示されている二重の握手は、いずれかの当事者が補足情報を提供する前に、当事者が相互に認証されることを保証するための手法を提供します。
Client Server
クライアントサーバー
ClientHello (no extensions) --------> |0
ServerHello (no extensions) |0
Certificate* |0
ServerKeyExchange* |0
CertificateRequest* |0
<-------- ServerHelloDone |0
Certificate* |0
ClientKeyExchange |0
CertificateVerify* |0
[ChangeCipherSpec] |0
Finished --------> |1
[ChangeCipherSpec] |0
<-------- Finished |1
ClientHello (w/ extensions) --------> |1
ServerHello (w/ extensions) |1
SupplementalData* |1
Certificate* |1
ServerKeyExchange* |1
CertificateRequest* |1
<-------- ServerHelloDone |1
SupplementalData* |1
Certificate* |1
ClientKeyExchange |1
CertificateVerify* |1
[ChangeCipherSpec] |1
Finished --------> |2
[ChangeCipherSpec] |1
<-------- Finished |2
Application Data <-------> Application Data |2
* Indicates optional or situation-dependent messages.
* オプションまたは状況に依存するメッセージを示します。
Figure 2. Double Handshake to Protect Supplemental Data
図2.補足データを保護するための二重の握手
IANA has taken the following actions:
IANAは次のアクションをとっています。
1) Created an entry, supplemental_data(23), in the existing registry for HandshakeType (defined in RFC 2246 [N2]).
1) HandShakeTypeの既存のレジストリ（RFC 2246 [N2]で定義）にエントリsupplemental_data（23）を作成しました。
2) Established a registry for TLS Supplemental Data Formats (SupplementalDataType). Values in the inclusive range 0-16385 (decimal) are assigned via RFC 2434 [N5] Standards Action. Values from the inclusive range 16386-65279 (decimal) are assigned via RFC 2434 IETF Consensus. Values from the inclusive range 65280-65535 (decimal) are reserved for RFC 2434 Private Use.
2) TLS補足データ形式（SupplientAldatype）のレジストリを確立しました。包括的範囲0-16385（小数）の値は、RFC 2434 [N5]標準アクションを介して割り当てられます。包括的範囲16386-65279（小数）の値は、RFC 2434 IETFコンセンサスを介して割り当てられます。包括的範囲65280-65535（小数）からの値は、RFC 2434の私的使用のために予約されています。
[N1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[N2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[N2] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[N3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[N3] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[N4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[N4] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[N5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[N5] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
The fundamental architectural idea for the supplemental data handshake message was provided by Russ Housley and Eric Rescorla.
補足データハンドシェイクメッセージの基本的な建築のアイデアは、Russ HousleyとEric Rescorlaによって提供されました。
Author's Address
著者の連絡先
Stefan Santesson Microsoft Finlandsgatan 30 164 93 KISTA Sweden
Stefan Santesson Microsoft Finlandsgatan 30 164 93 Kista Sweden
EMail: stefans@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。