[要約] RFC 3436は、Stream Control Transmission Protocol (SCTP) 上でのTransport Layer Security (TLS) の使用を定義しています。この文書の目的は、データのプライバシーと完全性を保護するために、SCTPを使用するアプリケーションにTLSのセキュリティメカニズムを提供することです。利用場面としては、信頼性と順序付けが必要な通信を行うアプリケーションでのデータ転送のセキュリティを強化する場合などがあります。関連するRFCには、RFC 5246 (TLS 1.2の定義) やRFC 4960 (SCTPの仕様) などがあります。
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.
Copyright（c）The Internet Society（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で定義されているRFC 2246で定義されている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].
このドキュメントでは、[RFC2960]および[RFC3309]で定義されているストリーム制御伝送プロトコル（SCTP）で[RFC2246]で定義されている輸送層セキュリティ（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は、信頼性の高いシーケンス配信を提供するバイトストリーム指向の輸送プロトコルの上で実行されるように設計されています。したがって、TLSは現在、[RFC793]で定義されているように、主に伝送制御プロトコル（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をSCTPで使用してTLSユーザーにこれらの追加機能の一部を提供する方法を示しています。
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].
キーワードは「必要」、「必要」、「必要」、「shill」、「shall "、" should "、" nove "、" becommented "、" becommented "、" may "、" 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からZからAまでのNストリームを提供します。
A pair consisting of two streams with the same stream identifier is considered and used as one bi-directional stream.
同じストリーム識別子を持つ2つのストリームで構成されるペアが考慮され、1つの双方向ストリームとして使用されます。
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関連は、min（n、m）の双方向の流れのセットと（max（n、m） - min（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はメッセージ指向プロトコルであるため、すべてのTLSレコードをSCTPユーザーメッセージとして送信できる必要があります。したがって、[RFC2246]で定義されているように、サポートされているSCTPユーザーメッセージの最大長さは少なくとも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].
SCTPを介したTLSのTLS実装は、[RFC3268]で定義されているように、少なくともCiphersuite TLS_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ベースのユーザーデータ伝送には使用しないでください。このルールの例外は、HTTPアップグレード[RFC2817]やTLSを介したSMTP [RFC3207]などのアップグレードメカニズムを含むプロトコルです。
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ベースのユーザーデータ送信に使用されるストリームで使用してはなりません。同じ理由で、送信のためにSCTPに配信されたTLSレコードには、寿命が限られていてはなりません。
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.
協会が確立された直後、クライアントは双方向のストリーム0および1で2つのClientHelloメッセージを送信します。。双方向のストリーム0では、握手が完了し、ユーザーデータの送信が進行中であり、双方向のストリーム1では、握手が完了していないか、その逆も同様です。
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の握手からセッション識別子を使用して、双方向ストリーム1での略式の握手を開始します。ユーザーデータは、双方向ストリーム0で送信できます。しかし、その状態の双方向のストリーム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.
この例は最後の例に似ていますが、双方向の流れ0での完全な握手が完了した後、双方向のストリーム1の略式された握手はすぐには開始されません。双方向のストリーム0は、ユーザーデータ送信に使用できます。双方向ストリーム1の双方向ストリーム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.Calhoun、J。Wood、その他多くの人々に貴重なコメントや提案に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2246] Diercks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Diercks、T。およびC. Allen、「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] 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、2000年10月。
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[RFC3268] Chown、P。、「輸送層セキュリティ（TLS）用の高度な暗号化標準（AES）ciphersuites」、RFC 3268、2002年6月。
[RFC3309] Stone, J., Stewart, R., Otis, D., "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309] Stone、J.、Stewart、R.、Otis、D。、「Stream Control Transmission Protocol（SCTP）チェックサムの変更」、RFC 3309、2002年9月。
[RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。（ed。）、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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. Lawrence、「HTTP/1.1内のTLSへのアップグレード」、RFC 2817、2000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 3207, February 2002.
[RFC3207] Hoffman、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
Andreas Jungmaier Essen Networking Technology GroupのIEM Ellernstrasse 29 D-45326 Essenドイツ
Phone: +49 201 1837667
EMail: ajung@exp-math.uni-essen.de
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
Eric Rescorla RTFM、Inc。2064 Edgewood Drive Palo Alto、CA 94303 USA
Phone: +1 650-320-8549
EMail: ekr@rtfm.com
Michael Tuexen Siemens AG D-81359 Munich Germany
Michael Tuexen Siemens AG D-81359ミュンヘンドイツ
Phone: +49 89 722 47210
EMail: Michael.Tuexen@siemens.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。