RFC4680 日本語訳
4680 TLS Handshake Message for Supplemental Data. S. Santesson. October 2006. (Format: TXT=15602 bytes) (Updates RFC4346) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Santesson Request for Comments: 4680 Microsoft Updates: 4346 September 2006 Category: Standards Track
Santessonがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4680のマイクロソフトアップデート: 4346 2006年9月のカテゴリ: 標準化過程
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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クライアントとTLSサーバの両方によってサポートされるかを決定するのに使用されます。TLS、こんにちは、次に、補足のデータ握手メッセージは、データを交換するのに使用されます。 他のドキュメントはこれらの拡大の構文と関連補足のデータ型の構文を定義するでしょう。
Santesson Standards Track [Page 1] RFC 4680 TLS Handshake Message for Supplemental Data September 2006
Santesson規格は2006年9月に補足のデータへのRFC4680TLS握手メッセージを追跡します[1ページ]。
1. Introduction
1. 序論
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つの提案が資格証明書の場所を見つけるためのユーザ名前ヒントを移します、そして、別の提案は許可検査のための属性証明書とSecurity Assertions Markup Language(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.
複数の握手メッセージの定義、それぞれの新しいタイプのアプリケーション特有の補足のデータのためのものを避けるために、この仕様はすべてのデータがTLSの保護されたアプリケーションに提供されることになっているオブジェクトであると一緒に添付して、ただ一つの握手メッセージで彼らを送る新しい握手メッセージタイプを定義します。
1.1. Terminology
1.1. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [N1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[N1]で説明されるように本書では解釈されることであるべきですか?
The syntax for the supplemental_data handshake message is defined using the TLS Presentation Language, which is specified in Section 4 of [N2].
補足_データ握手メッセージのための構文は、TLS Presentation Language([N2]のセクション4で指定される)を使用することで定義されます。
2. Supplemental Data Handshake Message
2. 補足のデータ握手メッセージ
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.
タイプがクライアントとサーバにおける、拡大の交換の間、こんにちはに同意するので補足のデータ・オブジェクトに関するコミュニケーションに対応するために定義されるという新しい補足_データ握手メッセージは通信します。 RFC2246(TLS1.0)[N2]を見てください。そうすれば、他の握手メッセージのためのRFC4346(TLS1.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プロトコルで処理しなければならない必要はありません。
Santesson Standards Track [Page 2] RFC 4680 TLS Handshake Message for Supplemental Data September 2006
Santesson規格は2006年9月に補足のデータへのRFC4680TLS握手メッセージを追跡します[2ページ]。
enum {
supplemental_data(23), (255)
} HandshakeType;
enum、補足_データ(23)、(255)HandshakeType。
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* octets in message */
select (HandshakeType) {
case supplemental_data: SupplementalData;
} body;
} Handshake;
struct、HandshakeType msg_タイプ; /*握手タイプ*/uint24の長さ; /*八重奏が中で*/選んだ(HandshakeType)を通信させる、補足_データをケースに入れてください: SupplementalData、ボディー;、握手。
struct {
SupplementalDataEntry supp_data<1..2^24-1>;
} SupplementalData;
struct、SupplementalDataEntry supp_データ<1..2^24-1>;、SupplementalData。
struct {
SupplementalDataType supp_data_type;
uint16 supp_data_length;
select(SupplementalDataType) { }
} SupplementalDataEntry;
struct、SupplementalDataType supp_データ_タイプ; uint16 supp_データ_の長さ;が(SupplementalDataType)を選択する、SupplementalDataEntry。
enum {
(65535)
} SupplementalDataType;
enum(65535)SupplementalDataType。
supp_data_length
This field is the length (in bytes) of the data selected by
SupplementalDataType.
Thisがさばくsupp_データ_の長さはSupplementalDataTypeによって選択されたデータの長さ(バイトによる)です。
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.
クライアントは1つ以上のSupplementalData握手メッセージを送ってはいけません、そして、サーバは1つ以上のSupplementalData握手メッセージを送ってはいけません。 1つ以上のSupplementalData握手メッセージを受け取ると、致命的な誤りはもたらされます、そして、受信機は致命的な予期していなかった_メッセージアラートとの関係を終えなければなりません。
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.
存在しているなら、SupplementalData握手メッセージは少なくとも1定義されたSupplementalDataTypeに関連しているデータを運ぶ非空のSupplementalDataEntry構造を含まなければなりません。 各SupplementalDataTypeのためにクライアントとサーバの間でクライアントとサーバにTLS拡張子[N4]を使用することでどんな補足のデータの存在も決定する明白な協定を締結しなければならない、こんにちは、メッセージ。 予期していなかったSupplementalData握手メッセージを受け取ると、致命的な誤りはもたらされます、そして、受信機は致命的な予期していなかった_メッセージアラートとの関係を終えなければなりません。
Santesson Standards Track [Page 3] RFC 4680 TLS Handshake Message for Supplemental Data September 2006
Santesson規格は2006年9月に補足のデータへのRFC4680TLS握手メッセージを追跡します[3ページ]。
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.
他のドキュメントは彼らの特定のSupplementalDataTypes、関連データ構文、および処理を定義するでしょう。 また、これらの同じ仕様がクライアントとサーバを指定しなければならない、こんにちは、指定された補足のデータ型のサポートを交渉するのに使用されるメッセージ拡張子。 このドキュメントは単に補足のデータ・オブジェクトを運ぶTLS Handshakeプロトコルメッセージを指定します。
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つの状況が完全にサポートされます。
3. Message Flow
3. メッセージ流動
The SupplementalData handshake message, if exchanged, MUST be sent as the first handshake message as illustrated in Figure 1 below.
交換するなら、以下の図1で例証される最初の握手メッセージとしてSupplementalData握手メッセージを送らなければなりません。
Client Server
クライアントサーバ
ClientHello (with extensions) -------->
ClientHello(拡大を伴う)-------->。
ServerHello(with extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
ServerHello(拡大を伴う)SupplementalData*証明書*ServerKeyExchange*CertificateRequest*<。-------- ServerHelloDone
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
SupplementalData*証明書*ClientKeyExchange CertificateVerify*[ChangeCipherSpec]は終わりました。-------->[ChangeCipherSpec]<。-------- 完成アプリケーションデータ<。------->アプリケーションデータ
* Indicates optional or situation-dependent messages.
* 任意の、または、状況依存するメッセージを示します。
Figure 1. Message Flow with SupplementalData
図1。 SupplementalDataがあるメッセージ流動
Santesson Standards Track [Page 4] RFC 4680 TLS Handshake Message for Supplemental Data September 2006
Santesson規格は2006年9月に補足のデータへのRFC4680TLS握手メッセージを追跡します[4ページ]。
4. Security Considerations
4. セキュリティ問題
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.
この仕様に基づき定義された握手メッセージに各SupplementalDataTypeを含んでいると、それ自身のユニークなセットのセキュリティ資産と関連する問題は紹介されます。 したがって、補足のデータ型を定義する各ドキュメントでセキュリティ問題を定義しなければなりません。
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.
いくつかの場合、SupplementalData情報は機密であるかもしれません。 SupplementalData情報のための保護を提供するのに二重握手のテクニックを使用できます。 初期の握手が少しの拡大も含んでいませんが、保護されたコミュニケーションをもたらすところで図2は二重握手を例証します。 そして、SupplementalData情報を含んでいる2番目の握手は、保護されたコミュニケーションを使用することで実行されます。 図2では、右側の数はその系列に関するTLSメッセージのための保護の量を示します。 Aゼロ(0)は、コミュニケーション保護が全くないのを示します。 人(1)は、保護が最初のTLSセッションで提供されるのを示します。 そして、2(2)は、保護が両方のTLSセッションで提供されるのを示します。
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 HandshakeのSupplementalDataメッセージのプレースメントはクライアントが認証される前にSupplementalData情報を提供するサーバをもたらします。 多くの状況で、クライアントが認証されるまで、サーバは承認情報を提供したくならないでしょう。 図2で例証された二重握手は、何れの当事者が情報をSupplementalDataに供給する前にパーティーが互いに認証されるのを保証するためにテクニックを提供します。
Santesson Standards Track [Page 5] RFC 4680 TLS Handshake Message for Supplemental Data September 2006
Santesson規格は2006年9月に補足のデータへのRFC4680TLS握手メッセージを追跡します[5ページ]。
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
ClientHello(拡大がありません)-------->| 0ServerHello(拡大がありません)|0 証明書*|0 ServerKeyExchange*|0 CertificateRequest*|0 <。-------- ServerHelloDone|0 証明書*|0 ClientKeyExchange|0 CertificateVerify*|0 [ChangeCipherSpec]|0は終わりました。-------->| 1[ChangeCipherSpec]|0 <。-------- 終わっています。|1 ClientHello(拡大を伴う)-------->| 1ServerHello(拡大を伴う)|1 SupplementalData*|1 証明書*|1 ServerKeyExchange*|1 CertificateRequest*|1 <。-------- ServerHelloDone|1 SupplementalData*|1 証明書*|1 ClientKeyExchange|1 CertificateVerify*|1 [ChangeCipherSpec]|1は終わりました。-------->| 2[ChangeCipherSpec]|1 <。-------- 終わっています。|2 アプリケーションデータ<。------->アプリケーションデータ|2
* Indicates optional or situation-dependent messages.
* 任意の、または、状況依存するメッセージを示します。
Figure 2. Double Handshake to Protect Supplemental Data
図2。 握手を倍にして、補足のデータを保護してください。
Santesson Standards Track [Page 6] RFC 4680 TLS Handshake Message for Supplemental Data September 2006
Santesson規格は2006年9月に補足のデータへのRFC4680TLS握手メッセージを追跡します[6ページ]。
5. IANA Considerations
5. IANA問題
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(RFC2246[N2]では、定義される)のために既存の登録でエントリー、補足_データ(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 Supplemental Data Formats(SupplementalDataType)のために登録を確立しました。 包括的な範囲0-16385(小数)における値はRFC2434[N5]規格Actionを通して割り当てられます。 包括的な範囲16386-65279(小数)からの値はRFC2434IETF Consensusを通して割り当てられます。 包括的な範囲65280-65535(小数)からの値はRFC2434兵士のUseのために予約されます。
6. Normative References
6. 引用規格
[N1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[N2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[N2] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[N3] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[N3] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[N4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC
4366, April 2006.
[N4]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
7. Acknowledgements
7. 承認
The fundamental architectural idea for the supplemental data handshake message was provided by Russ Housley and Eric Rescorla.
補足のデータ握手メッセージのための基本的な建築考えはラスHousleyとエリック・レスコラによって提供されました。
Santesson Standards Track [Page 7] RFC 4680 TLS Handshake Message for Supplemental Data September 2006
Santesson規格は2006年9月に補足のデータへのRFC4680TLS握手メッセージを追跡します[7ページ]。
Author's Address
作者のアドレス
Stefan Santesson Microsoft Finlandsgatan 30 164 93 KISTA Sweden
ステファンSantessonマイクロソフトFinlandsgatan30 164 93KISTAスウェーデン
EMail: stefans@microsoft.com
メール: stefans@microsoft.com
Santesson Standards Track [Page 8] RFC 4680 TLS Handshake Message for Supplemental Data September 2006
Santesson規格は2006年9月に補足のデータへのRFC4680TLS握手メッセージを追跡します[8ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Santesson Standards Track [Page 9]
Santesson標準化過程[9ページ]
一覧
スポンサーリンク
