Network Working Group A. Jungmaier
Request for Comments: 3436 University of Essen
Category: Standards Track E. Rescorla
RTFM Inc.
M. Tuexen
Siemens AG
December 2002
Transport Layer Security over
Stream Control Transmission Protocol
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309.
この文書は、RFC 2960およびRFC 3309で定義されているように、ストリーム制御伝送プロトコル（SCTP）の上に、RFC 2246で定義されているように、トランスポート層セキュリティ（TLS）プロトコルの使用法を説明します。
The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance.
TLSのユーザは、即ち複数のストリームのサポートは、ラインブロックの先頭及びネットワークレベルのフォールトトレランスを提供するために、マルチホーミングのサポートを避けるために、SCTPによって提供される機能を利用することができます。
Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP-addresses.
また、SCTPの拡張の議論はまた、IP-アドレスの動的再構成の特に支援を意味し、サポートされています。
This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in [RFC2246], over the Stream Control Transmission Protocol (SCTP), as defined in [RFC2960] and [RFC3309].
[RFC2246]で定義されるように[RFC2960]及び[RFC3309]で定義されるように、この文書は、ストリーム制御伝送プロトコル（SCTP）を介して、トランスポート層セキュリティ（TLS）プロトコルの使用を記載しています。
TLS is designed to run on top of a byte-stream oriented transport protocol providing a reliable, in-sequence delivery. Thus, TLS is currently mainly being used on top of the Transmission Control Protocol (TCP), as defined in [RFC793].
TLSは、信頼性、インシーケンス配信を提供するバイトストリーム指向のトランスポートプロトコルの上で動作するように設計されています。 [RFC793]で定義されるようにこのように、TLSは現在、主に、伝送制御プロトコル（TCP）の上で使用されています。
Comparing TCP and SCTP, the latter provides additional features and this document shows how TLS should be used with SCTP to provide some of these additional features to the TLS user.
TCPとSCTPを比較すると、後者は、追加機能を提供し、この文書では、TLSは、TLSのユーザーにこれらの追加機能の一部を提供するために、SCTPを使用する方法を示しています。
This document defines:
この文書では、定義されています。
- how to use the multiple streams feature of SCTP.
- SCTPの複数のストリーム機能を使用する方法について説明します。
- how to handle the message oriented nature of SCTP.
- SCTPのメッセージ指向の性質をどのように処理しますか。
It should be noted that the TLS user can take advantage of the multi-homing support of SCTP. The dynamic reconfiguration of IP-addresses, as currently being discussed, can also be used with the described solution.
TLSのユーザーがSCTPのマルチホーミングサポートを利用できることに留意すべきです。 IP-アドレスの動的再構成は、現在議論されているように、また、記載溶液と共に使用することができます。
The method described in this document does not require any changes of TLS or SCTP. It is only required that SCTP implementations support the optional feature of fragmentation of SCTP user messages.
この文書に記載された方法は、TLSまたはSCTPの変更を必要としません。それだけでSCTPの実装は、SCTPユーザメッセージの断片化のオプション機能をサポートすることが必要とされます。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています：
Association: An SCTP association.
協会：SCTPアソシエーション。
Connection: A TLS connection.
接続：TLS接続。
Session: A TLS session.
セッション：TLSセッション。
Stream: A unidirectional stream of an SCTP association. It is uniquely identified by a stream identifier.
ストリーム：SCTPアソシエーションの一方向の流れ。これは、一意のストリーム識別子によって識別されます。
MTU: Maximum Transmission Unit
MTU：最大伝送単位
SCTP: Stream Control Transmission Protocol
SCTP：ストリーム制御伝送プロトコル
TCP: Transmission Control Protocol
TCP：伝送制御プロトコル
TLS: Transport Layer Security
TLS：トランスポート層セキュリティ
The keywords "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, RFC 2119 [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、 "推奨NOT"、および "OPTIONAL" BCP 14、RFC 2119 [RFC2119]に記載されているように、本書では解釈されるべきです。
An association between the endpoints A and Z provides n streams from A to Z and m streams from Z to A.
エンドポイントAとZとの間の関連付けは、AからZからZおよびmのストリームからn個のストリームを提供します
A pair consisting of two streams with the same stream identifier is considered and used as one bi-directional stream.
同じストリーム識別子を持つ2つのストリームの組を考慮すると一つの双方向ストリームとして使用されます。
Thus an SCTP association can be considered as a set of min(n,m) bi-directional streams and (max(n,m) - min(n,m)) uni-directional streams.
片方向ストリーム - こうしてSCTPアソシエーションが分（n、m）は双方向ストリームと（MIN（n、m）が最大（N、M））の集合とみなすことができます。
To avoid the knowledge and handling of the MTU inside TLS, SCTP MUST provide fragmentation of user messages, which is an optional feature of [RFC2960]. Since SCTP is a message oriented protocol, it must be able to transmit all TLS records as SCTP user messages. Thus the supported maximum length of SCTP user messages MUST be at least 2^14 + 2048 + 5 = 18437 bytes, which is the maximum length of a TLSCiphertext, as defined in [RFC2246].
TLS内部MTUの知識や取り扱いを避けるために、SCTPは、[RFC2960]のオプション機能であるユーザメッセージの断片化を提供しなければなりません。 SCTPは、メッセージ指向のプロトコルであるので、SCTPユーザメッセージとして、すべてのTLSレコードを送信することができなければなりません。したがってSCTPユーザメッセージのサポートされる最大長は[RFC2246]で定義されるように、TLSCiphertextの最大長さは、少なくとも2 ^ 14 + 2048 + 5 = 18437バイトでなければなりません。
Please note that an SCTP implementation might need to support the partial delivery API to be able to support the transport of user messages of this size.
SCTPの実装は、このサイズのユーザメッセージの転送をサポートできるようにする部分配信APIをサポートする必要がある場合がありますのでご注意ください。
Therefore, SCTP takes care of fragmenting and reassembling the TLS records in order to avoid IP-fragmentation.
したがって、SCTPは、IP-断片化を避けるために、TLSレコードを断片化し、再組み立ての世話をします。
A TLS implementation for TLS over SCTP MUST support at least the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA as defined in [RFC3268].
[RFC3268]で定義されるようにSCTP上のTLSのTLSの実装は、少なくとも暗号スイートTLS_RSA_WITH_AES_128_CBC_SHAをサポートしなければなりません。
TLS makes use of a bi-directional stream by establishing a connection over it. This means that the number of connections for an association is limited by the number of bi-directional streams.
TLSは、それ以上の接続を確立することにより、双方向ストリームを利用します。これは、関連付けのための接続の数は双方向ストリームの数によって制限されることを意味します。
The TLS handshake protocol is used on each bi-directional stream separately. Each handshake can be:
TLSハンドシェイクプロトコルは、別々に各双方向ストリーム上で使用されています。それぞれの握手はすることができ：
- a full handshake or
- 完全なハンドシェイクや
- an abbreviated handshake that resumes a TLS session with a session id from another connection (on the same or another association).
- （同じまたは別の関連で）別の接続からのセッションIDとTLSセッションを再開略記握手。
After completing the handshake for a connection, the bi-directional stream can be used for TLS-based user data transmission. It should also be noted that the handshakes for the different connections are independent and can be delayed until the bi-directional stream is used for user data transmission.
接続のためのハンドシェイクが完了した後、双方向ストリームは、TLSベースのユーザデータ伝送のために使用することができます。また、異なる接続のためのハンドシェイクが独立しており、双方向ストリームは、ユーザデータの送信に使用されるまで遅らせることができることに留意すべきです。
It is not required that all bi-directional streams are used for TLS-based user data transmission. If TLS is not used, it is called SCTP-based user data transmission.
すべての双方向ストリームはTLSベースのユーザデータの送信に使用されることが必要とされません。 TLSが使用されていない場合は、SCTPベースのユーザデータ伝送と呼ばれています。
If a bi-directional stream is not used for TLS-based communication there are no restrictions on the features provided by SCTP for SCTP-based user data transmission.
双方向ストリームはTLSベースの通信のために使用されていない場合、SCTPベースのユーザデータ伝送のためにSCTPによって提供される機能に制限はありません。
In general, the bi-directional stream will be used for TLS-based user data transmission and it SHOULD NOT be used for SCTP-based user data transmission. The exception to this rule is for protocols which contain upgrade-to-TLS mechanisms, such as those of HTTP upgrade [RFC2817] and SMTP over TLS [RFC3207].
一般的に、双方向ストリームは、TLSベースのユーザデータ送信のために使用され、それはSCTPベースのユーザデータの送信には使用できません。この規則の例外は、アップグレード・ツー・TLSようなHTTPのもののようなメカニズム、アップグレード[RFC2817]とTLS [RFC3207]上SMTPを含むプロトコルするためのものです。
TLS requires that the underlying transport delivers TLS records in strict sequence. Thus, the 'unordered delivery' feature of SCTP MUST NOT be used on streams which are used for TLS based user data transmission. For the same reason, TLS records delivered to SCTP for transmission MUST NOT have limited lifetimes.
TLSは、基礎となるトランスポートは、厳密な順序でTLSレコードを提供することが必要です。したがって、SCTPの「順不同配信」機能は、TLSベースのユーザ・データ送信のために使用されるストリームに使用してはいけません。同じ理由で、TLSレコードは、限られた寿命を持つことはできません送信するためにSCTPに配信しました。
The uni-directional streams can not be used for TLS-based user data transmission. Nevertheless, they can be used without any restrictions for SCTP-based communication.
単方向ストリームは、TLSベースのユーザデータ伝送のために使用することができません。それにもかかわらず、彼らはSCTPベースの通信のための任意の制限なく使用することができます。
In these examples we consider the case of an association with two bi-directional streams.
これらの例では、2つの双方向ストリームとの関連付けの場合を考えます。
Just after the association has been established, the client sends two ClientHello messages on the bi-directional streams 0 and 1. After a full handshake has been completed on each bi-directional stream, TLS-based user data transmission can take place on that stream. It is possible that on the bi-directional stream 0, the handshake has been completed, and user data transmission is ongoing, while on the bi-directional stream 1, the handshake has not been completed, or vice versa.
アソシエーションが確立された直後、クライアントは完全なハンドシェイクは、各双方向ストリーム上で完了した後、TLSベースのユーザデータの送信は、そのストリーム上で行うことができる双方向ストリーム0と1で2つのClientHelloメッセージを送信します。双方向ストリーム1に、ハンドシェイクが完了し、またはその逆されていないが、双方向ストリーム0上で、ハンドシェイクが完了し、ユーザデータ伝送が進行中であることが可能です。
After establishing the association, the client starts a full handshake on the bi-directional stream 0. The server provides a session identifier which allows session resumption. After the full handshake has been completed, the client initiates an abbreviated handshake on the bi-directional stream 1, using the session identifier from the handshake on the bi-directional stream 0. User data can be transmitted on the bi-directional stream 0, but not on the bi-directional stream stream 1 in that state. After completion of the abbreviated handshake on the bi-directional stream 1, user data can be transmitted on both streams.
アソシエーションを確立した後、クライアントは、サーバがセッション再開を可能にするセッション識別子を提供する双方向ストリーム0上で完全なハンドシェイクを開始します。完全なハンドシェイクが完了した後、クライアントは双方向ストリーム0上で送信することができる双方向ストリーム0ユーザデータにハンドシェークからセッション識別子を使用して、双方向ストリーム1に略記ハンドシェイクを開始し、なく、その状態で双方向ストリームストリーム1に。双方向ストリーム1に略記ハンドシェークの完了後、ユーザデータは、両方のストリーム上で送信することができます。
Whether or not to use abbreviated handshakes during the setup phase of a TLS connection over an SCTP association depends on several factors:
SCTPアソシエーション上のTLS接続のセットアップ段階簡略ハンドシェイクを使用するかどうかは、いくつかの要因に依存します。
- the complexity and duration of the initial handshake processing (also determined by the number of connections),
- （また、接続の数によって決定される）初期ハンドシェイク処理の複雑さおよび持続時間、
- the network performance (round-trip times, bandwidth).
- ネットワークパフォーマンス（ラウンドトリップ時間、帯域幅）。
Abbreviated handshakes can reduce computational complexity of the handshake considerably, in case this is a limiting resource. If a large number of connections need to be established, it may be advantageous to use the TLS session resumption feature. On the other hand, before an abbreviated handshake can take place, a full handshake needs to have been completed. In networks with large round-trip time delays, it may be favorable to perform a number of full handshakes in parallel. Therefore, both possibilities are allowed.
略称握手をする場合には、これはリソース制限され、かなり握手の計算の複雑さを軽減することができます。多数の接続を確立する必要がある場合は、TLSセッション再開機能を使用することが有利です。一方、簡略ハンドシェイクが行われることができる前に、完全なハンドシェイクが完了している必要があります。大往復時間遅延を持つネットワークでは、並行して、完全なハンドシェイクの数を行うことが好都合であり得ます。したがって、両方の可能性が許可されています。
This example resembles the last one, but after the completion of the full handshake on the bi-directional stream 0, the abbreviated handshake on the bi-directional stream 1 is not started immediately. The bi-directional stream 0 can be used for user data transmission. It is only when the user also wants to transmit data on the bi-directional stream 1 that the abbreviated handshake for the bi-directional stream 1 is initiated.
この例では、最後の1に似ているが、双方向ストリーム0上の完全なハンドシェイクが完了した後、双方向ストリーム1上の簡略ハンドシェイクがすぐに開始されていません。双方向ストリーム0は、ユーザデータ伝送のために使用することができます。これは、ユーザが双方向ストリーム1のための簡略ハンドシェイクが開始されていることを双方向ストリーム1上にデータを送信したいときにだけです。
This allows the user of TLS to request a large number of bi-directional streams without having to provide all the resources at association start-up if not all bi-directional streams are used right from the beginning.
これは、TLSのユーザーがすべての双方向ストリームが最初から使用されていない場合は、アソシエーション起動時にすべてのリソースを提供することなく、双方向ストリームの多数を要求することができます。
This example is like the second and third one, but an abbreviated handshake is used for both bi-directional streams. This requires the existence of a valid session identifier from connections handled by another association.
この例では、第2および第3のものと同様であるが、略記ハンドシェイクは、両方の双方向ストリームのために使用されます。これは、別の関連付けによって処理された接続から有効なセッション識別子の存在を必要とします。
Using TLS on top of SCTP does not provide any new security issues beside the ones discussed in [RFC2246] and [RFC2960].
SCTPの上にTLSを使用すると、[RFC2246]と[RFC2960]で説明したもののそばにどんな新しいセキュリティ問題を提供していません。
It is possible to authenticate TLS endpoints based on IP-addresses in certificates. Unlike TCP, SCTP associations can use multiple addresses per SCTP endpoint. Therefore it is possible that TLS records will be sent from a different IP-address than that originally authenticated. This is not a problem provided that no security decisions are made based on that IP-address. This is a special case of a general rule: all decisions should be based on the peer's authenticated identity, not on its transport layer identity.
証明書におけるIP-アドレスに基づいてTLSエンドポイントを認証することが可能です。 TCPとは異なり、SCTP協会はSCTP端末ごとに複数のアドレスを使用することができます。そのためには、TLSレコードが最初に認証されたものとは異なるIPアドレスから送信されることも可能です。これには、セキュリティ上の決定は、そのIPアドレスに基づいて行われていないことを提供する問題ではありません。これは、一般的なルールの特殊ケースである：すべての決定は、ピアの認証されたアイデンティティのではなく、そのトランスポート層のアイデンティティに基づくべきです。
The authors would like to thank P. Calhoun, J. Wood, and many others for their invaluable comments and suggestions.
作者は彼らの貴重なコメントと提案のためにP.カルフーン、J.ウッド、および多くの他に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2246] Diercks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Diercks、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxon, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.およびV. Paxon、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[RFC3268]のchown、P.、RFC 3268、2002年6月 "トランスポート層セキュリティ（TLS）用のAdvanced Encryption Standard（AES）暗号の組み合わせ"。
[RFC3309] Stone, J., Stewart, R., Otis, D., "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]石、J.、スチュワート、R.、オーティス、D.、 "ストリーム制御伝送プロトコル（SCTP）チェックサムの変更"、RFC 3309、2002年9月。
[RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.（編）、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817] Khare、R.およびS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 3207, February 2002.
[RFC3207]ホフマン、P.、 "TLSの上にセキュアなSMTPのためのSMTPサービス拡張子"、RFC 3207、2002年2月。
Andreas Jungmaier University of Essen Networking Technology Group at the IEM Ellernstrasse 29 D-45326 Essen Germany
IEM Ellernstrasse 29 D-45326エッセンドイツのエッセン・ネットワーキング・テクノロジー・グループのアンドレアスJungmaier大学
Phone: +49 201 1837667 EMail: ajung@exp-math.uni-essen.de
電話：+49 201 1837667 Eメール：ajung@exp-math.uni-essen.de
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
エリックレスコラRTFM、Inc.の2064エッジウッドドライブパロアルト、CA 94303 USA
Phone: +1 650-320-8549 EMail: ekr@rtfm.com
電話：+1 650-320-8549電子メール：ekr@rtfm.com
Michael Tuexen Siemens AG D-81359 Munich Germany
マイケルTuexenシーメンスAG D-81359ミュンヘンドイツ
Phone: +49 89 722 47210 EMail: Michael.Tuexen@siemens.com
電話：+49 89 722 47210 Eメール：Michael.Tuexen@siemens.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。