▶ テレフオンアクチーボラゲット エル エム エリクソン（パブル）の特許一覧
特表2024-541821ストリーム制御伝送プロトコル（ＳＣＴＰ）上で並列のデータグラムトランスポート層セキュリティ（ＤＴＬＳ）コネクションを使用するための方法及びシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-11-13
(54)【発明の名称】ストリーム制御伝送プロトコル（ＳＣＴＰ）上で並列のデータグラムトランスポート層セキュリティ（ＤＴＬＳ）コネクションを使用するための方法及びシステム
(51)【国際特許分類】
H04L 9/08 20060101AFI20241106BHJP
H04L 9/32 20060101ALI20241106BHJP
H04L 69/326 20220101ALI20241106BHJP
H04L 65/1101 20220101ALI20241106BHJP
H04L 65/1069 20220101ALI20241106BHJP
【ＦＩ】
H04L9/08 C
H04L9/32 200A
H04L69/326
H04L65/1101
H04L65/1069
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024520798
(86)(22)【出願日】2022-08-17
(85)【翻訳文提出日】2024-06-04
(86)【国際出願番号】 IB2022057712
(87)【国際公開番号】W WO2023067400
(87)【国際公開日】2023-04-27
(31)【優先権主張番号】63/270,064
(32)【優先日】2021-10-21
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】598036300
【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）
(74)【代理人】
【識別番号】110003281
【氏名又は名称】弁理士法人大塚国際特許事務所
(72)【発明者】
【氏名】ウェスタールンド， マグナス
(72)【発明者】
【氏名】マットソン， ジョン
(72)【発明者】
【氏名】ポルフィーニ， クラウディオ
(57)【要約】
実施形態は、ＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上で並列のＤＴＬＳ（データグラムプロトコルトランスポート層セキュリティ）コネクションを実装するための方法、電子デバイス、記憶媒体、及びコンピュータプログラムを含む。一実施形態では、第２のネットワークノードへのセキュア伝送のためにユーザメッセージを符号化するための、第１のネットワークノードにおける方法は、ユーザメッセージを送信するＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上の既存のＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションからの既存のＳＣＴＰ－ＡＵＴＨ（ＳＣＴＰのための認証されたチャンク）キーを使用したＤＴＬＳハンドシェイクを通じて、当該ＳＣＴＰアソシエーション上でＤＴＬＳコネクションを開始することと、開始されたＤＴＬＳコネクションから新規のＳＣＴＰ－ＡＵＴＨキーを導出することと、新規のＳＣＴＰ－ＡＵＴＨキーを用いて、開始されたＤＴＬＳコネクションを通じて更なるユーザメッセージを送信することと、既存のＤＴＬＳコネクションで暗号化されたＳＣＴＰパケットと、既存のＳＣＴＰ－ＡＵＴＨキーによって認証されたＳＣＴＰパケットとが配信されたことの確認に応じて、ＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションをクローズすることと、を含む。
【特許請求の範囲】
【請求項1】
第２のネットワークノードへのセキュア伝送のためにユーザメッセージを符号化するための、第１のネットワークノードにおける方法であって、ユーザメッセージを送信するＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上の既存のＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションからの既存のＳＣＴＰ－ＡＵＴＨ（ＳＣＴＰのための認証されたチャンク）キーを使用したＤＴＬＳハンドシェイクを通じて、前記ＳＣＴＰアソシエーション上でＤＴＬＳコネクションを開始すること（２０４）と、
前記開始されたＤＴＬＳコネクションから新規のＳＣＴＰ－ＡＵＴＨキーを導出すること（２０６）と、
前記新規のＳＣＴＰ－ＡＵＴＨキーを用いて、前記開始されたＤＴＬＳコネクションを通じて更なるユーザメッセージを送信すること（２１０）と、
前記既存のＤＴＬＳコネクションで暗号化されたＳＣＴＰパケットと、前記既存のＳＣＴＰ－ＡＵＴＨキーによって認証されたＳＣＴＰパケットとが配信されたことの確認に応じて、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすること（２１２）と、
を含む、方法。
【請求項2】
請求項１に記載の方法であって、前記開始されたＤＬＴＳコネクションによって保護されているが前記既存のＳＣＴＰ－ＡＵＴＨキーで認証されているユーザメッセージの更なる部分を含む、進行中のＳＣＴＰパケットを送信すること（２０８）を更に含む、方法。
【請求項3】
請求項１又は２に記載の方法であって、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすることは、第１のＤＴＬＳコネクションクローズ通知を前記第２のネットワークノードへ送信することを含む、方法。
【請求項4】
請求項１乃至３のいずれか一項に記載の方法であって、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすることは、第２のＤＴＬＳコネクションクローズ通知を前記第２のネットワークノードから受信することを更に含む、方法。
【請求項5】
請求項１乃至４のいずれか一項に記載の方法であって、前記第１のＤＴＬＳコネクションクローズ通知を送信することは、前記第１のＤＴＬＳコネクションクローズ通知を送信する前に、前記既存のＤＴＬＳコネクションにおける送信データが非再現可能な方法で前記第２のネットワークノードによって確認応答されたことを確認することを含む、方法。
【請求項6】
請求項１乃至５のいずれか一項に記載の方法であって、前記既存のＳＣＴＰ－ＡＵＴＨキー及び前記新規のＳＣＴＰ－ＡＵＴＨキーは、対応する既存の及び新規のキー識別子（ＩＤ）によって識別され、前記新規のキー識別子は、前記既存のキー識別子から１だけ増加した値である、方法。
【請求項7】
請求項１乃至６のいずれか一項に記載の方法であって、前記ＤＴＬＳコネクションは、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションの１つ以上の証明書が失効する前に確立される、方法。
【請求項8】
請求項１乃至７のいずれか一項に記載の方法であって、前記ＤＴＬＳハンドシェイクを通じて前記ＳＣＴＰアソシエーション上で前記ＤＴＬＳコネクションを開始することは、前記１つ以上の証明書内のタイムスタンプを含む前記既存のＤＴＬＳコネクションの前記１つ以上の証明書を維持することを含む、方法。
【請求項9】
請求項１乃至８のいずれか一項に記載の方法であって、前記第１のネットワークノードと前記第２のネットワークノードとの間で前記ハンドシェイクを実行することは、
前記ハンドシェイクを開始し、かつ、前記ハンドシェイクのイニシエーションを受信したことに応答して、前記第１のネットワークノードが前記ＤＴＬＳコネクションのＤＴＬＳクライアントとして機能する場合に前記開始されたハンドシェイクを継続することを含む、方法。
【請求項10】
請求項１乃至９のいずれか一項に記載の方法であって、前記既存のＳＣＴＰ－ＡＵＴＨキーは、前記既存のＤＴＬＳコネクションのクローズに応じて削除される、方法。
【請求項11】
ネットワークノード（４０２）であって、プロセッサ（４４２）と、命令を提供する非一時的なマシン読取可能読記憶媒体（４４９）と、を備え、前記命令は、前記プロセッサ（４４２）によって実行されると前記プロセッサ（４４２）に、
ユーザメッセージを送信するＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上の既存のＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションからの既存のＳＣＴＰ－ＡＵＴＨ（ＳＣＴＰのための認証されたチャンク）キーを使用したＤＴＬＳハンドシェイクを通じて、前記ＳＣＴＰアソシエーション上でＤＴＬＳコネクションを開始すること（２０４）と、
前記開始されたＤＴＬＳコネクションから新規のＳＣＴＰ－ＡＵＴＨキーを導出すること（２０６）と、
前記新規のＳＣＴＰ－ＡＵＴＨキーを用いて、前記開始されたＤＴＬＳコネクションを通じて更なるユーザメッセージを送信すること（２１０）と、
前記既存のＤＴＬＳコネクションで暗号化されたＳＣＴＰパケットと、前記既存のＳＣＴＰ－ＡＵＴＨキーによって認証されたＳＣＴＰパケットとが配信されたことの確認に応じて、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすること（２１２）と、
を実行させることができる、ネットワークノード。
【請求項12】
請求項１１に記載のネットワークノード（４０２）であって、前記非一時的なマシン読取可能読記憶媒体は、前記プロセッサ（４４２）によって実行されると前記プロセッサ（４４２）に、
前記開始されたＤＬＴＳコネクションによって保護されているが前記既存のＳＣＴＰ－ＡＵＴＨキーで認証されているユーザメッセージの更なる部分を含む、進行中のＳＣＴＰパケットを送信すること（２０８）、
を更に実行させることができる命令を提供する、ネットワークノード。
【請求項13】
請求項１１又は１２に記載のネットワークノード（４０２）であって、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすることは、第１のＤＴＬＳコネクションクローズ通知を前記第２のネットワークノードへ送信することを含む、ネットワークノード。
【請求項14】
請求項１１乃至１３のいずれか一項に記載のネットワークノード（４０２）であって、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすることは、第２のＤＴＬＳコネクションクローズ通知を前記第２のネットワークノードから受信することを更に含む、ネットワークノード。
【請求項15】
請求項１１乃至１４のいずれか一項に記載のネットワークノード（４０２）であって、前記第１のＤＴＬＳコネクションクローズ通知を送信することは、前記第１のＤＴＬＳコネクションクローズ通知を送信する前に、前記既存のＤＴＬＳコネクションにおける送信データが非再現可能な方法で前記第２のネットワークノードによって確認応答されたことを確認することを含む、ネットワークノード。
【請求項16】
請求項１１乃至１５のいずれか一項に記載のネットワークノード（４０２）であって、前記既存のＳＣＴＰ－ＡＵＴＨキー及び前記新規のＳＣＴＰ－ＡＵＴＨキーは、対応する既存の及び新規のキー識別子（ＩＤ）によって識別され、前記新規のキー識別子は、前記既存のキー識別子から１だけ増加した値である、ネットワークノード。
【請求項17】
請求項１１乃至１６のいずれか一項に記載のネットワークノード（４０２）であって、前記ＤＴＬＳコネクションは、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションの１つ以上の証明書が失効する前に確立される、ネットワークノード。
【請求項18】
請求項１１乃至１７のいずれか一項に記載のネットワークノード（４０２）であって、前記ＤＴＬＳハンドシェイクを通じて前記ＳＣＴＰアソシエーション上で前記ＤＴＬＳコネクションを開始することは、前記１つ以上の証明書内のタイムスタンプを含む前記既存のＤＴＬＳコネクションの前記１つ以上の証明書を維持することを含む、ネットワークノード。
【請求項19】
請求項１１乃至１８のいずれか一項に記載のネットワークノード（４０２）であって、前記第１のネットワークノードと前記第２のネットワークノードとの間で前記ハンドシェイクを実行することは、
前記ハンドシェイクを開始し、かつ、前記ハンドシェイクのイニシエーションを受信したことに応答して、前記第１のネットワークノードが前記ＤＴＬＳコネクションのＤＴＬＳクライアントとして機能する場合に前記開始されたハンドシェイクを継続することを含む、ネットワークノード。
【請求項20】
請求項１１乃至１９のいずれか一項に記載のネットワークノード（４０２）であって、前記既存のＳＣＴＰ－ＡＵＴＨキーは、前記既存のＤＴＬＳコネクションのクローズに応じて削除される、ネットワークノード。
【請求項21】
非一時的なマシン読取可能記憶媒体（４４９）であって、プロセッサ（４４２）によって実行されると前記プロセッサ（４４２）に、方法１乃至１０のいずれかを実行させることができる命令を提供する、マシン読取可能記憶媒体。
【請求項22】
コンピュータプログラムであって、前記コンピュータプログラムがネットワークノード（４０２）によって実行されると前記デバイスに、方法１乃至１０のいずれかを実行させることができる命令を含む、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、２０２１年１０月２１日に提出された米国仮出願第６３／２７０，０６４号の利益を主張し、当該仮出願は本明細書で援用される。
本出願は、２０２１年１０月２１日に提出された米国仮出願第６３／２７０，０６４号の利益を主張し、当該仮出願は本明細書で援用される。
【0002】
本発明の実施形態は、ネットワーキングの分野に関するものであり、より具体的には、ストリーム制御伝送プロトコル（ＳＣＴＰ）上で並列のデータグラムトランスポート層セキュリティ（ＤＴＬＳ）コネクションを使用することに関するものである。
【背景技術】
【0003】
第５世代（５Ｇ）ネットワークにおけるシグナリングプロトコルは、モバイル機器、それらの位置及び同様のもの情報を取得するために活用されうる、感知可能なデータをトランスポートするために、５Ｇ無線アクセスネットワーク（ＲＡＮ）における次世代制御プレーンインタフェース（ＮＧ－Ｃ）、Ｘｎ、Ｅ１、及びＦ１等のインタフェースを使用する。シグナリングデータは、抽象構文表記法１（ＡＳＮ．１：Abstract Syntax Notation One）で符号化され、ノード間でストリーム制御伝送プロトコル（ＳＣＴＰ：Stream Control Transmission Protocol）を介して転送される。第３世代パートナーシッププロジェクト（３ＧＰＰ(登録商標)）は、セキュリティ及び機密性のためにインターネットプロトコルセキュリティ（ＩＰＳｅｃ：Internet Protocol Security）でデータを保護することを推奨する。信号のサイズは任意の長さであり、１４４Ｋバイトまでの信号が存在する場合もある。
【0004】
ＩＰＳｅｃゲートウェイとノードとの間のコネクションは保護されないので、３ＧＰＰは、エンド・ツー・エンド保護のためにＤＴＬＳ／ＳＣＴＰを採用することも推奨する。３ＧＰＰによれば、ＤＴＬＳ／ＳＣＴＰ保護は、ノード実装者にとって必須であり、アクティブ化するためにオペレータにとってはオプションである。しかし、ＳＣＴＰアソシエーションは非常に長寿命（long lived）であることがあり、場合によっては数週間又は数ヶ月で測定される存続期間（lifetime）を有することがあり、エンド・ツー・エンドのノードコネクションにおけるピアノードは、大きなＳＣＴＰメッセージをサポートする長寿命ＳＣＴＰアソシエーションのためのソリューションを有する必要がある。
【発明の概要】
【0005】
実施形態は、ストリーム制御伝送プロトコル（ＳＣＴＰ）アソシエーション上で並列のデータグラムトランスポート層セキュリティ（ＤＴＬＳ）コネクションを実装するための方法、ネットワークノード、記憶媒体、及びコンピュータプログラムを含む。一実施形態において、第２のネットワークノードへのセキュア伝送のためにユーザメッセージを符号化するための、第１のネットワークノードにおける方法は、ユーザメッセージを送信するＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上の既存のＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションからの既存のＳＣＴＰ－ＡＵＴＨ（ＳＣＴＰのための認証されたチャンク）キーを使用したＤＴＬＳハンドシェイクを通じて、ＳＣＴＰアソシエーション上でＤＴＬＳコネクションを開始することと、開始されたＤＴＬＳコネクションから新規のＳＣＴＰ－ＡＵＴＨキーを導出することと、新規のＳＣＴＰ－ＡＵＴＨキーを用いて、開始されたＤＴＬＳコネクションを通じて更なるユーザメッセージを送信すること（２１０）と、既存のＤＴＬＳコネクションで暗号化されたＳＣＴＰパケットと、既存のＳＣＴＰ－ＡＵＴＨキーによって認証されたＳＣＴＰパケットとが配信されたことの確認に応じて、ＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションをクローズすることと、を含む。
【0006】
実施形態は、ストリーム制御伝送プロトコル（ＳＣＴＰ）アソシエーション上で並列のデータグラムトランスポート層セキュリティ（ＤＴＬＳ）コネクションを実装するためのネットワークノードを含む。一実施形態において、ネットワークノードは、プロセッサと、命令を提供する非一時的なマシン読取可能読記憶媒体と、を備え、命令は、プロセッサによって実行されるとネットワークノードに、ユーザメッセージを送信するＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上の既存のＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションからの既存のＳＣＴＰ－ＡＵＴＨ（ＳＣＴＰのための認証されたチャンク）キーを使用したＤＴＬＳハンドシェイクを通じて、ＳＣＴＰアソシエーション上でＤＴＬＳコネクションを開始することと、開始されたＤＴＬＳコネクションから新規のＳＣＴＰ－ＡＵＴＨキーを導出することと、新規のＳＣＴＰ－ＡＵＴＨキーを用いて、開始されたＤＴＬＳコネクションを通じて更なるユーザメッセージを送信することと、既存のＤＴＬＳコネクションで暗号化されたＳＣＴＰパケットと、既存のＳＣＴＰ－ＡＵＴＨキーによって認証されたＳＣＴＰパケットとが配信されたことの確認に応じて、ＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションをクローズすることと、を実行させることができる。
【0007】
実施形態は、ストリーム制御伝送プロトコル（ＳＣＴＰ）アソシエーション上で並列のデータグラムトランスポート層セキュリティ（ＤＴＬＳ）コネクションを実装するためのマシン読取可能記憶媒体を含む。一実施形態において、マシン読取可能記憶媒体は、命令を提供し、当該命令は、実行されるネットワークノードに、ユーザメッセージを送信するＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上の既存のＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションからの既存のＳＣＴＰ－ＡＵＴＨ（ＳＣＴＰのための認証されたチャンク）キーを使用したＤＴＬＳハンドシェイクを通じて、ＳＣＴＰアソシエーション上でＤＴＬＳコネクションを開始することと、開始されたＤＴＬＳコネクションから新規のＳＣＴＰ－ＡＵＴＨキーを導出することと、新規のＳＣＴＰ－ＡＵＴＨキーを用いて、開始されたＤＴＬＳコネクションを通じて更なるユーザメッセージを送信することと、既存のＤＴＬＳコネクションで暗号化されたＳＣＴＰパケットと、既存のＳＣＴＰ－ＡＵＴＨキーによって認証されたＳＣＴＰパケットとが配信されたことの確認に応じて、ＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションをクローズすることと、を実行させることができる。
【0008】
本発明の実施形態は、既存のソリューションによるキー変更時のデータドレイニング（draining）ドレインフェーズ中に、ＤＴＬＳ／ＳＣＴＰセッションにおいてデータ送信をアプリケーションが一時停止又は少なくとも遅延させる、アプリケーションの影響を回避する。ＤＴＬＳ保護レコードは自己記述型（self-describing）であり、かつ、共存しうるので、ドレイニングフェーズは回避される。更に、独立ＤＴＬＳコネクション管理は、このキーを使用する全データが最初に配信されたことをそれぞれのサイドが知っている場合に、明示的な非同期クローズシグナリングを可能にし、その結果、コネクションをクローズダウンし、秘密キーマテリアルを廃棄する。
【図面の簡単な説明】
【0009】
本発明は、本発明の実施形態を例示するために使用される以下の説明及び添付の図面を参照することによって最もよく理解されうる。図面において：
【発明を実施するための形態】
【0010】
一般に、本明細書で使用される全ての用語は、異なる意味が明確に与えられ、及び／又は、それが使用される文脈から暗示されない限り、関連する技術分野におけるそれらの通常の意味に従って解釈されるべきである。エレメント、装置、コンポーネント、手段、ステップ等へのあらゆる言及は、特に明記しない限り、エレメント、装置、コンポーネント、手段、ステップ等の少なくとも１つのインスタンスを指すものとしてオープンに解釈されるべきである。本明細書に開示される任意の方法のステップは、ステップが別のステップの後又は前として明示的に説明されている場合、及び／又はステップが別のステップの後又は前になければならないことが黙示的でる場合を除き、開示される正確な順序で実行される必要はない。本明細書に開示される実施形態のいずれかの任意の特徴は、適切な場合には、任意の他の実施形態に適用されてもよい。同様に、任意の実施形態の任意の利点は、任意の他の実施形態に適用されることができ、その逆も同様である。包含される実施形態の他の目的、特徴、及び利点は、以下の説明から明らかになる。
【0011】
１． 導入
既存の技術において長寿命のストリーム制御伝送プロトコル（ＳＣＴＰ）アソシエーションを実装することは困難である。例えば、データグラムトランスポート層セキュリティ（ＤＴＬＳ：Datagram Transport Layer Security）１．３は、相互再認証をサポートしておらず、また、ＤＴＬＳ自体の（Diffie-Hellmanを用いた）再キーイング（rekeying）を有効にしておらず、これにより、モバイルネットワークで使用される基本形式のような長寿命（数週間及び数ヶ月）のＳＣＴＰアソシエーションの保護には適していない。キーの変更を扱う、IETF（Internet Engineering Task Force）RFC（Request for Comment）6083によるＤＴＬＳ（１．０及び１．２）再ネゴシエーションのための手順は、キー変更の前に、ドレイニング、即ち、全データが受信されるまで送信を停止することを必要とするので、アプリケーションに影響を及ぼす可能性がある。「アソシエーション」及び「ＳＣＴＰアソシエーション」との用語は、本明細書において互換的に使用されることに留意されたい。
既存の技術において長寿命のストリーム制御伝送プロトコル（ＳＣＴＰ）アソシエーションを実装することは困難である。例えば、データグラムトランスポート層セキュリティ（ＤＴＬＳ：Datagram Transport Layer Security）１．３は、相互再認証をサポートしておらず、また、ＤＴＬＳ自体の（Diffie-Hellmanを用いた）再キーイング（rekeying）を有効にしておらず、これにより、モバイルネットワークで使用される基本形式のような長寿命（数週間及び数ヶ月）のＳＣＴＰアソシエーションの保護には適していない。キーの変更を扱う、IETF（Internet Engineering Task Force）RFC（Request for Comment）6083によるＤＴＬＳ（１．０及び１．２）再ネゴシエーションのための手順は、キー変更の前に、ドレイニング、即ち、全データが受信されるまで送信を停止することを必要とするので、アプリケーションに影響を及ぼす可能性がある。「アソシエーション」及び「ＳＣＴＰアソシエーション」との用語は、本明細書において互換的に使用されることに留意されたい。
【0012】
１．１ 概要
そのような課題を克服するために、本発明の実施形態は、同じＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションと並列に新たなＤＴＬＳコネクションを確立し、これにより、長寿命ＳＣＴＰアソシエーションのためのアプリケーションへの最小限の影響で、ＤＴＬＳ保護されたＳＣＴＰアソシエーションのための再キーイング、相互再認証、及び更新された証明書を実現にする。
そのような課題を克服するために、本発明の実施形態は、同じＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションと並列に新たなＤＴＬＳコネクションを確立し、これにより、長寿命ＳＣＴＰアソシエーションのためのアプリケーションへの最小限の影響で、ＤＴＬＳ保護されたＳＣＴＰアソシエーションのための再キーイング、相互再認証、及び更新された証明書を実現にする。
【0013】
これは、ＤＴＬＳハンドシェイクにおける相互認証と、既存のＤＴＬＳコネクションによってキーイングされたＳＣＴＰ－ＡＵＴＨが提供する、完全性（integrity）及びソース認証とによって、安全に行われうる。新たなハンドシェイクが実行され、かつ、セキュリティコンテキスト及びキーが配置されている場合、両方のネットワークノード・エンドポイントは、両方のＤＴＬＳレコードについての新たなキーと、ＳＣＴＰ－ＡＵＴＨについてのエクスポートされたキーとを使用するように切り替える。ＤＴＬＳレコードは、ＤＴＬＳコネクション識別子（ＩＤ）機能を使用し、ＳＣＴＰ－ＡＵＴＨは、正しいコンテキストを識別するためにそのｋｅｙ－ｉｄ機構を使用する。
【0014】
各送信者が、古いＳＣＴＰ－ＡＵＴＨキーによって保護された全てのＤＴＬＳレコード及びＳＣＴＰパケットが正常に配信されたことを保証した場合、古いＤＴＬＳコネクションは一方向に閉じられる。両方のエンドポイントがＤＴＬＳコネクションを閉じた場合、このＤＴＬＳコネクションに関連する全てのキーが削除されうる。このため、本発明の実施形態は、２つのＤＴＬＳコネクションの並存がアプリケーションに対して最小限の影響を及ぼすことを可能にし、確実に配信されるべき任意のＳＣＴＰメッセージに対して、仮定されたトランスポートセマンティクス（transport semantics）を維持し続ける。
【0015】
いくつかの実施形態では、ＳＣＴＰ上のＤＴＬＳが、ＳＣＴＰのための認証されたチャンク（ＳＣＴＰ－ＡＵＴＨ：Authenticated Chunks for SCTP）とともに使用される。ＤＴＬＳは、ＤＴＬＳ １．２［IETF RFC 6347］又はＤＴＬＳ １．３［IETF RFC 9147］に規定されるように実装されうる一方、ＳＣＴＰは、ＳＣＴＰ－ＡＵＴＨ［IETF RFC 4895］とともに［IETF RFC 4960］に規定されるように実装されうる。トランスポートプロトコルとしてＳＣＴＰを使用するアプリケーションは、エンドポイントの相互認証、機密性、完全性保護、及びユーザメッセージの再生保護を提供するために、これらの実施形態及び他の実施形態を使用してもよい。
【0016】
ＤＴＬＳ／ＳＣＴＰは、ユーザメッセージの完全性保護及び再生保護のためにＳＣＴＰとＳＣＴＰ－ＡＵＴＨとを使用する。ＤＴＬＳ ｏｖｅｒ ＳＣＴＰを使用するアプリケーションは、ＳＣＴＰ及びその拡張によって提供されるほぼ全てのトランスポート機能を使用できる。ＤＴＬＳ／ＳＣＴＰは、１）メッセージ境界の保存、２）多数の単方向及び双方向ストリーム、３）ＳＣＴＰユーザメッセージの順序付き及び非順序付き配信、４）［IETF RFC 3758］に規定される部分信頼性拡張、５）［IETF RFC 5061］に規定される動的アドレス再構成拡張、及び、６）最大２＾６４－１のユーザメッセージサイズ、を含む機能をサポートする。特記されない限り、本明細書におけるストリームは、ＳＣＴＰアソシエーションの単方向ストリームであり、ストリーム識別子によって一意に識別される。
【0017】
いくつかの実施形態は、ＳＣＴＰ実装が［IETF RFC 4960］に規定されるＳＣＴＰユーザメッセージのフラグメンテーションのオプション機能をサポートすることを要求しうる。 当該実装は、部分的なユーザメッセージ配信をサポートするＳＣＴＰ ＡＰＩ（例えば、［IETF RFC 6458］に記載のもの）を有することを要求されるとともに、［IETF RFC 8260］に規定されるＩ－ＤＡＴＡチャンクが、より大きなユーザメッセージを効率的に実装及びサポートするために使用されることを推奨する。
【0018】
図１は、いくつかの実施形態による、拡張ＤＴＬＳ／ＳＣＴＰシグナリング及びメッセージングを提供するためのシステム図を示す。図１は、トラフィックフローを実装するノード１００を示し、アプリケーションプログラミングインタフェース（ＡＰＩ）１０１は、ＳＣＴＰ機能ブロック（又はモジュール）１２０と、メッセージが受信又は復元される上位層プロトコルとの間のインタフェースである。ＡＰＩ １０１とＳＣＴＰ機能ブロック１２０との間には、ＤＴＬＳ／ＳＣＴＰ機能ブロック（又はモジュール）１１０が介在する。いくつかの実施形態では、ＡＰＩ １０１は、ＤＴＬＳ ＡＰＩ及びＳＣＴＰ ＡＰＩを含む。
【0019】
ＤＴＬＳ／ＳＣＴＰ機能ブロック１１０は、ユーザメッセージ及びＳＣＴＰ－ＡＵＴＨキーを保護するためにＤＴＬＳ及びＳＣＴＰを一緒に使用する。ＤＴＬＳ／ＳＣＴＰ機能ブロック１１０は、本発明の実施形態を実装する並列ＤＴＬＳコネクションコーディネータモジュール１１２を含む。いくつかの実施形態では、ＤＴＬＳ／ＳＣＴＰ機能ブロック１１０は、上位層プロトコルからのメッセージをフラグメンテーションし、そのフラグメントをＳＣＴＰ １２０に提供し、ＳＣＴＰ １２０からのメッセージ（ＳＣＴＰパケット）をデフラグし、それらをアセンブルし、アセンブルされたメッセージを上位層プロトコルに提供する。
【0020】
ＤＴＬＳ／ＳＣＴＰ機能ブロック１１０は、ＤＴＬＳモジュール１１５を含み、当該モジュールは、ＤＴＬＳプロトコルを実装し、かつ、最大２＾１４バイトのサイズのＤＴＬＳレコードを提供する。ＤＴＬＳモジュール１１５は、いくつかの実施形態ではＴＬＳエクスポータ１１４を含み、ＴＬＳエクスポータ１１４は、ＤＴＬＳコネクションから共有認証キーをエクスポートする。共有認証キーは、参照番号１１６においてｋｅｙ－ｉｄとペアにされ、キー及び対応するｋｅｙ－ｉｄをＳＣＴＰ１２０へ提供する。
【0021】
ＳＣＴＰ１２０は、例えば、IETF RFC 4960及び種々の拡張又は他のＩＥＴＦ標準提案に従って、ＳＣＴＰプロトコルを実装する機能ブロックである。いくつかの実施形態では、ＳＣＴＰ機能ブロック１２０は、以下のセクション４．７に詳述されるように、共有認証キー及び完全性保護のために使用される対応するｋｅｙ－ｉｄを受け入れるための、ＳＣＴＰ－ＡＵＴＨモジュール１２４を含む。
【0022】
実装を単純化し、セキュリティホールのリスクを低減するために、［IETF RFC 3788］に規定されるようなＳＴＡＲＴＴＬＳがいくつかの実施形態においてもはやサポートされないように、制限が規定されている。
【0023】
１．１．１． ＳＣＴＰのためのＴＬＳとの比較
ＴＬＳからＤＴＬＳが導出された場合の当該ＴＬＳは、信頼できるインシーケンス配信を提供するバイトストリーム指向トランスポートプロトコルの上で動作するように設計される。［IETF RFC 3436］に記述されているようなＴＬＳ ｏｖｅｒ ＳＣＴＰにはいくつかの重大な制限がある：
‐ＳＣＴＰユーザメッセージの非順序付け配信をサポートしないこと；
‐［IETF RFC 3758］に規定されているような部分信頼性をサポートしないこと；
‐双方向で同じ数のストリームの使用をサポートするだけであること；及び
‐双方向ストリームごとにＴＬＳコネクションを使用し、これは、多数のストリームが使用される場合にかなりの量のリソース及びメッセージ交換を必要とすること。
ＴＬＳからＤＴＬＳが導出された場合の当該ＴＬＳは、信頼できるインシーケンス配信を提供するバイトストリーム指向トランスポートプロトコルの上で動作するように設計される。［IETF RFC 3436］に記述されているようなＴＬＳ ｏｖｅｒ ＳＣＴＰにはいくつかの重大な制限がある：
‐ＳＣＴＰユーザメッセージの非順序付け配信をサポートしないこと；
‐［IETF RFC 3758］に規定されているような部分信頼性をサポートしないこと；
‐双方向で同じ数のストリームの使用をサポートするだけであること；及び
‐双方向ストリームごとにＴＬＳコネクションを使用し、これは、多数のストリームが使用される場合にかなりの量のリソース及びメッセージ交換を必要とすること。
【0024】
１．１．２． IETF RFC 6083からの変更点
IETF RFC 6083に規定されているＤＴＬＳ ｏｖｅｒ ＳＣＴＰソリューションには、以下の制限があった： 最大ユーザメッセージサイズが２＾１４ （１６３８４） バイトであり、これは単一のＤＴＬＳレコード限界である。
IETF RFC 6083に規定されているＤＴＬＳ ｏｖｅｒ ＳＣＴＰソリューションには、以下の制限があった： 最大ユーザメッセージサイズが２＾１４ （１６３８４） バイトであり、これは単一のＤＴＬＳレコード限界である。
【0025】
本発明の実施形態は、IETF RFC 6083を置き換えうるとともに、以下の変更を含みうる：
‐セキュアなフラグメンテーション機構を規定することによって、ユーザメッセージサイズの制限を削除する；
‐より最新のＤＴＬＳバージョンが必要とされることを必須にする（ＤＴＬＳ １．２又は１．３）；
‐ＳＣＴＰ認証拡張［IETF RFC 4895］における最新のハッシュベースのメッセージ認証コード（ＨＭＡＣ：hash-based message authentication code） アルゴリズム（ＳＨＡ－２５６）の使用を必須にする；
‐スケジューリングの問題を回避するために、大きなＳＣＴＰユーザメッセージのインタリーブを可能にする［IETF RFC 8260］のサポートを推奨する；
‐ＳＣＴＰアソシエーション内の全てのユーザメッセージに対してＤＴＬＳを常に使用することに対して、より厳しい要件を適用する；
‐認証が行われることが可能な全てのＳＣＴＰチャンクに対してＳＣＴＰ－ＡＵＴＨが適用されることを要求する；及び
‐ユーザメッセージの部分配信のサポートを要求する。
‐セキュアなフラグメンテーション機構を規定することによって、ユーザメッセージサイズの制限を削除する；
‐より最新のＤＴＬＳバージョンが必要とされることを必須にする（ＤＴＬＳ １．２又は１．３）；
‐ＳＣＴＰ認証拡張［IETF RFC 4895］における最新のハッシュベースのメッセージ認証コード（ＨＭＡＣ：hash-based message authentication code） アルゴリズム（ＳＨＡ－２５６）の使用を必須にする；
‐スケジューリングの問題を回避するために、大きなＳＣＴＰユーザメッセージのインタリーブを可能にする［IETF RFC 8260］のサポートを推奨する；
‐ＳＣＴＰアソシエーション内の全てのユーザメッセージに対してＤＴＬＳを常に使用することに対して、より厳しい要件を適用する；
‐認証が行われることが可能な全てのＳＣＴＰチャンクに対してＳＣＴＰ－ＡＵＴＨが適用されることを要求する；及び
‐ユーザメッセージの部分配信のサポートを要求する。
【0026】
１．２． ＤＴＬＳバージョン
本書において定義されるＤＴＬＳ／ＳＣＴＰは、ＤＴＬＳ １．２［IETF RFC ６３４７］又はＤＴＬＳ １．３［IETF RFC 9147］ のいずれかを使用しうる。一般に、ＤＴＬＳ １．３は、既知の脆弱性に対処し、かつ、公開時に既知の主要な弱点を有しない強力なアルゴリズムのみを定義する、より新しいプロトコルであることが好ましい。
本書において定義されるＤＴＬＳ／ＳＣＴＰは、ＤＴＬＳ １．２［IETF RFC ６３４７］又はＤＴＬＳ １．３［IETF RFC 9147］ のいずれかを使用しうる。一般に、ＤＴＬＳ １．３は、既知の脆弱性に対処し、かつ、公開時に既知の主要な弱点を有しない強力なアルゴリズムのみを定義する、より新しいプロトコルであることが好ましい。
【0027】
ＤＴＬＳ １．０ を使用する代わりにＤＴＬＳ １．２を使用すると、ＤＴＬＳコネクションの存続期間（lifetime）と、ＤＴＬＳコネクションを介して転送できるデータ量とが制限される。これは以下に起因する：
‐ＤＴＬＳ １．２における再ネゴシエーションの回数が、ＤＴＬＳ １．０ の無制限と比較して６５５３４ に制限されている；及び
‐ＤＴＬＳ １．３の関連データ付き認証暗号化（ＡＥＡＤ：authenticated encryption with associated data）限界は、ＤＴＬＳ １．２には正式に適用されないが、数学的制限は、ＤＴＬＳ １．２にも同様に適用される。
‐ＤＴＬＳ １．２における再ネゴシエーションの回数が、ＤＴＬＳ １．０ の無制限と比較して６５５３４ に制限されている；及び
‐ＤＴＬＳ １．３の関連データ付き認証暗号化（ＡＥＡＤ：authenticated encryption with associated data）限界は、ＤＴＬＳ １．２には正式に適用されないが、数学的制限は、ＤＴＬＳ １．２にも同様に適用される。
【0028】
ＤＴＬＳ １．３には以下の多数の重要な変更がある：
‐再ネゴシエーションはサポートされておらず、その代わりに部分的にKeyUpdatesに置き換えられる。KeyUpdatesの個数は２＾６４に制限されている。
‐厳格なＡＥＡＤでは、再キーイング前に送信できるパケットの個数が大幅に制限されている。
‐再ネゴシエーションはサポートされておらず、その代わりに部分的にKeyUpdatesに置き換えられる。KeyUpdatesの個数は２＾６４に制限されている。
‐厳格なＡＥＡＤでは、再キーイング前に送信できるパケットの個数が大幅に制限されている。
【0029】
ＤＴＬＳ／ＳＣＴＰを使用する多くのアプリケーションは、半永続的な性質のものであり、数ヶ月又は数年の予想される存続期間を有するＳＣＴＰアソシエーションを使用し、ＳＣＴＰアソシエーションを再開するためにＳＣＴＰアソシエーションをダウンさせるのはかなりのコストがある。そのようなＤＴＬＳ／ＳＣＴＰの使用が必要である：
‐（ＤＴＬＳクライアントだけでなく）両方のエンドポイントの定期的な再認証；
‐あらゆるキー開示の影響を低減するための、Diffie-Hellmanキー交換の定期的な再実行によるＰＦＳ（Perfect Forward Secrecy）の提供；及び
‐ＳＣＴＰ－ＡＵＴＨ再キーイングを実行する。
‐（ＤＴＬＳクライアントだけでなく）両方のエンドポイントの定期的な再認証；
‐あらゆるキー開示の影響を低減するための、Diffie-Hellmanキー交換の定期的な再実行によるＰＦＳ（Perfect Forward Secrecy）の提供；及び
‐ＳＣＴＰ－ＡＵＴＨ再キーイングを実行する。
【0030】
公開時にはＤＴＬＳ １．３はこれらのいずれもサポートしていないが、ＤＴＬＳ １．２の再ネゴシエーション機能は、ＤＴＬＳ／ＳＣＴＰのコンテキストにおいてこの機能を提供しうる。半永続的なアプリケーションからのこれらの要件に対処するために、本発明の実施形態は、ＤＴＬＳ １．２又は１．３のいずれかとの、いくつかの重複するＤＴＬＳコネクションを使用する。統一した手順を有することで、１．２から１．３へのアップグレード時の影響が軽減され、多くのＤＴＬＳ実装でデフォルトで無効になっている再ネゴシエーションメカニズムの使用が回避される。
【0031】
ＤＴＬＳ １．２における既知の脆弱性に対処するために、本明細書では、暗号、プロトコルオプション、及びＤＴＬＳ再ネゴシエーションメカニズムの使用方法に関する実装制約を記述及び要求している。
【0032】
本明細書の残りの部分では、ＤＴＬＳのバージョンが特に宣言されない限り、本テキストはＤＴＬＳの両方のバージョンに適用される。
【0033】
２． 慣例
本文書中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、及び「OPTIONAL」は、以下に示されるように、全て大文字で表記される場合に限り、BCP 14［IETF RFC 2119］［IETF RFC 8174］に記載されているように解釈されるものとする。
本文書中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、及び「OPTIONAL」は、以下に示されるように、全て大文字で表記される場合に限り、BCP 14［IETF RFC 2119］［IETF RFC 8174］に記載されているように解釈されるものとする。
【0034】
３． ＤＴＬＳ留意事項
３．１． ＤＴＬＳのバージョン
本文書は、ＤＴＬＳ １．３［I-D.ietf-tls-dtls13］又はＤＴＬＳ １．２［IETF RFC 6347］の使用を定義する。以前のバージョンのＤＴＬＳは使用されてはならない（MUST NOT）（[IETF RFC 8996］を参照）。本文書に記載のＤＴＬＳ／ＳＣＴＰは、ＤＴＬＳの将来のバージョンで動作することが期待される。
３．１． ＤＴＬＳのバージョン
本文書は、ＤＴＬＳ １．３［I-D.ietf-tls-dtls13］又はＤＴＬＳ １．２［IETF RFC 6347］の使用を定義する。以前のバージョンのＤＴＬＳは使用されてはならない（MUST NOT）（[IETF RFC 8996］を参照）。本文書に記載のＤＴＬＳ／ＳＣＴＰは、ＤＴＬＳの将来のバージョンで動作することが期待される。
【0035】
３．２． 暗号スイート及び暗号パラメータ
ＤＴＬＳ １．２の場合、[IETF RFC 7540］によって禁止されている暗号スイートは使用されてはならない（MUST NOT）。ＤＴＬＳの全てのバージョンについて、機密性と完全前方秘匿性（ＰＦＳ：Perfect Forward Secrecy）を与える暗号パラメータが使用されなければならない（MUST）。
ＤＴＬＳ １．２の場合、[IETF RFC 7540］によって禁止されている暗号スイートは使用されてはならない（MUST NOT）。ＤＴＬＳの全てのバージョンについて、機密性と完全前方秘匿性（ＰＦＳ：Perfect Forward Secrecy）を与える暗号パラメータが使用されなければならない（MUST）。
【0036】
３．３． メッセージサイズ
ＤＴＬＳ／ＳＣＴＰは、自動的にユーザメッセージをフラグメンテーションし、再アセンブルする。本明細書では、ユーザメッセージをＤＴＬＳレコードに分割する方法を定義し、各ＤＴＬＳ １．３レコードは最大２＾１４ 個の保護バイトを使用できる。各ＤＴＬＳレコードは、いくらかのオーバヘッドを付加し、このため、可能性のある最大サイズのレコードを使用することが、送信されるオーバヘッドを最小限に抑えるために推奨される。
ＤＴＬＳ／ＳＣＴＰは、自動的にユーザメッセージをフラグメンテーションし、再アセンブルする。本明細書では、ユーザメッセージをＤＴＬＳレコードに分割する方法を定義し、各ＤＴＬＳ １．３レコードは最大２＾１４ 個の保護バイトを使用できる。各ＤＴＬＳレコードは、いくらかのオーバヘッドを付加し、このため、可能性のある最大サイズのレコードを使用することが、送信されるオーバヘッドを最小限に抑えるために推奨される。
【0037】
次に、ＤＴＬＳレコードのシーケンスは、ＳＣＴＰによってパスＭＴＵにフィットするようにデータ又はＩ－データチャンクにフラグメンテーションされる。本明細書で定義されているメカニズムを使用して可能な最大のユーザメッセージは、２＾６４－１バイトである。
【0038】
セキュリティ動作及びリアセンブリ・プロセスは、保護されたユーザメッセージ、即ち、ＤＴＬＳレコードオーバヘッドを伴うメッセージが、受信機においてバッファリングされることを必要とする。このため、このバッファ空間は、安全に転送可能なプレーンテキストユーザメッセージの最大サイズに制限を課すことになる。しかし、ＳＣＴＰからのユーザメッセージの部分配信の使用を要求し、かつ、同じストリーム上で受信された２つのメッセージがインタリーブされないと仮定することによって（［IETF RFC ６４５８］で定義されるＡＰＩを使用する場合のように）、ＤＴＬＳ処理の前に必要とされるバッファリングは、使用される着信ストリームごとに単一のＤＴＬＳレコードに制限されうる。
【0039】
これにより、ＤＴＬＳ／ＳＣＴＰ実装は、復号されてその完全性が検証された際に、各ＤＴＬＳレコードのコンテンツを上位層プロトコル（ＵＬＰ：Upper Layer Protocol）に提供し、ＵＬＰへの部分的なユーザメッセージ配信を可能にすることができる。実装は、より小さいＤＴＬＳレコードを使用することによって、ＤＴＬＳ層におけるバッファメモリ要件とトランスポートオーバヘッドとをトレードオフとしうる。
【0040】
ＤＴＬＳ／ＳＣＴＰ実装は、ユーザメッセージの処理、大規模なユーザメッセージの処理、及びそれらのリアセンブリ及び処理に関して、単にＳＣＴＰと非常に似た振る舞いをすることが期待される。ＵＬＰに、大規模なユーザメッセージに関連するリソース競合を処理することに関与させる。
【0041】
３．４． 再生保護（Replay Protection）
ＳＣＴＰ－ＡＵＴＨ [IETF RFC 4895］は、明示的な再生保護を有していない。しかし、ＳＣＴＰ－ＡＵＴＨのＤＡＴＡ又はＩ－ＤＡＴＡチャンクの保護とＳＣＴＰユーザメッセージ処理の組み合わせは、第三者がＳＣＴＰパケットを注入又は再生しようとする試みを防ぎ、受信された保護ユーザメッセージに影響を与える。実際、この文書のソリューションは、各保護ユーザメッセージ内のＤＴＬＳレコードの並べ替え、複製、及び削除を防止するために、ＳＣＴＰ－ＡＵＴＨ及びＳＣＴＰに依存する。これには、どのＤＴＬＳレコードがＳＣＴＰユーザメッセージを開始及び終了するかの変更の検出、及びエポックへのインクリメント前のＤＴＬＳレコードの削除が含まれる。ＳＣＴＰ－ＡＵＴＨがない場合、これらは全て明示的な処理を必要とする。
ＳＣＴＰ－ＡＵＴＨ [IETF RFC 4895］は、明示的な再生保護を有していない。しかし、ＳＣＴＰ－ＡＵＴＨのＤＡＴＡ又はＩ－ＤＡＴＡチャンクの保護とＳＣＴＰユーザメッセージ処理の組み合わせは、第三者がＳＣＴＰパケットを注入又は再生しようとする試みを防ぎ、受信された保護ユーザメッセージに影響を与える。実際、この文書のソリューションは、各保護ユーザメッセージ内のＤＴＬＳレコードの並べ替え、複製、及び削除を防止するために、ＳＣＴＰ－ＡＵＴＨ及びＳＣＴＰに依存する。これには、どのＤＴＬＳレコードがＳＣＴＰユーザメッセージを開始及び終了するかの変更の検出、及びエポックへのインクリメント前のＤＴＬＳレコードの削除が含まれる。ＳＣＴＰ－ＡＵＴＨがない場合、これらは全て明示的な処理を必要とする。
【0042】
ＤＴＬＳは、レコード再生検出をオプションでサポートしている。そのような再生検出は、ＤＴＬＳ層がＤＴＬＳ再生ウィンドウ外で受信された有効なメッセージをドロップすることをもたらしうる。ＤＴＬＳ／ＳＣＴＰは、ＤＴＬＳ再生保護なしでも再生保護を提供するので、ＤＴＬＳの再生検出は使用されてはならない（MUST NOT）。
【0043】
３．５． パスＭＴＵディスカバリ
ＤＴＬＳパスＭＴＵディスカバリ（DTLS Path MTU Discovery）は使用されてはならない（MUST NOT）。ＳＣＴＰがユーザメッセージのためのパスＭＴＵディスカバリ及びフラグメンテーション／リアセンブリ（reassembly）を提供するので、セクション３．３に従って、ＤＴＬＳは最大サイズのＤＴＬＳレコードを送信しうる。
ＤＴＬＳパスＭＴＵディスカバリ（DTLS Path MTU Discovery）は使用されてはならない（MUST NOT）。ＳＣＴＰがユーザメッセージのためのパスＭＴＵディスカバリ及びフラグメンテーション／リアセンブリ（reassembly）を提供するので、セクション３．３に従って、ＤＴＬＳは最大サイズのＤＴＬＳレコードを送信しうる。
【0044】
３．６． メッセージの再送信
ＳＣＴＰは、信頼性の高いインシーケンス（in-sequence）トランスポートサービスを、それを必要とするＤＴＬＳ メッセージに対して提供する。セクション４．４を参照。したがって、再送信のためのＤＴＬＳ手順は使用されてはならない（MUST NOT）。
ＳＣＴＰは、信頼性の高いインシーケンス（in-sequence）トランスポートサービスを、それを必要とするＤＴＬＳ メッセージに対して提供する。セクション４．４を参照。したがって、再送信のためのＤＴＬＳ手順は使用されてはならない（MUST NOT）。
【0045】
４． ＳＣＴＰ留意事項
４．１． ＤＴＬＳレコードのマッピング
ＳＣＴＰ実装は、ＤＡＴＡ［IETF RFC 4960］と、オプションでＩ－ＤＡＴＡ［IETF RFC 8260］チャンクを使用するユーザメッセージのフラグメンテーションをサポートしなければならない（MUST）。
４．１． ＤＴＬＳレコードのマッピング
ＳＣＴＰ実装は、ＤＡＴＡ［IETF RFC 4960］と、オプションでＩ－ＤＡＴＡ［IETF RFC 8260］チャンクを使用するユーザメッセージのフラグメンテーションをサポートしなければならない（MUST）。
【0046】
ＤＴＬＳ／ＳＣＴＰは、ユーザメッセージＡＰＩとＳＣＴＰとの間のシムレイヤ（shim layer）として機能する。フラグメンテーションは、ハンドシェイクメッセージのＤＴＬＳフラグメンテーションと同様に機能する。送信側では、ユーザメッセージはフラグメントｍ０、ｍ１、ｍ２にフラグメンテーションされ、それぞれ２＾１４＝１６３８４バイト以下である。
m0 | m1 | m2 | ... ＝ user_message
結果として生じるフラグメントはＤＴＬＳで保護され、レコードは連結される
user_message' ＝ DTLS( m0 ) | DTLS( m1 ) | DTLS( m2 ) ...
新たなuser_message'、即ち、保護されたユーザメッセージは、ＳＣＴＰへの入力である。
受信側では、ＤＴＬＳが、個々のレコードを解読するために使用される。
実装によって検出し、その後にアクションを行う必要がある３つの障害ケースがある：
m0 | m1 | m2 | ... ＝ user_message
結果として生じるフラグメントはＤＴＬＳで保護され、レコードは連結される
user_message' ＝ DTLS( m0 ) | DTLS( m1 ) | DTLS( m2 ) ...
新たなuser_message'、即ち、保護されたユーザメッセージは、ＳＣＴＰへの入力である。
受信側では、ＤＴＬＳが、個々のレコードを解読するために使用される。
実装によって検出し、その後にアクションを行う必要がある３つの障害ケースがある：
【0047】
１．ＤＴＬＳレコードの復号及び完全性検証プロセスの障害。ＳＣＴＰ－ＡＵＴＨが、保護されたユーザメッセージの注入（injected）又は破損（corrupt）フラグメントの配信を防ぐことに起因して、これは、実装エラー又は内部ハードウェア障害の場合、又は必要なセキュリティコンテキストが時期尚早に破棄された場合にのみ発生するはずである。
【0048】
２．ＳＣＴＰ層が、例えば、［IETF RFC 6458］に記載のＡＰＩを使用するときにrecvmsg()コールでMSG_EORを受信する場合に、ユーザメッセージの終わりを示し、最後にバッファリングされたＤＴＬＳレコード長フィールドが一致しない、即ち、ＤＴＬＳレコードが不完全である場合。
【0049】
３．メモリ等のリソースが不足していることに起因して、復号プロセスを実行できず、ユーザメッセージフラグメントを破棄する必要がある。本明細書は、ＤＴＬＳ／ＳＣＴＰ動作に必要なリソースが、所与の数の、同時送信されるＳＣＴＰストリーム又は順序付けられていないユーザメッセージに対して制限されるように、定義される。
【0050】
上記の障害のケースは全て、受信機が完全なユーザメッセージを再現できないという結果につながる。これは、ＤＴＬＳ／ＳＣＴＰ層において復元することが不可能なトランスポートサービスの障害であり、送信者は完全なメッセージが配信されたと考えうる。このエラーは無視されてはならず（MUST NOT）、これは、ＳＣＴＰが、特定のストリーム又はユーザメッセージで障害を宣言する機能を欠いているためであり、ＤＴＬＳコネクションとＳＣＴＰアソシエーションは終了されるべきである（SHOULD）。ＳＣＴＰアソシエーションの終了（termination）に対する有効な例外は、受信機が配信の障害についてＵＬＰに通知することができ、ＵＬＰがこの障害から回復することができる場合である。
【0051】
部分的信頼性のためのＳＣＴＰ拡張（ＰＲ－ＳＣＴＰ：SCTP extension for Partial Reliability）［IETF RFC 3758］がユーザメッセージのために使用される場合、ユーザメッセージは、部分的に配信又は放棄されうることに留意されたい。これらの障害は、ＤＴＬＳコネクション及びＳＣＴＰアソシエーションを終了する理由ではない。
【0052】
ＤＴＬＳコネクションＩＤは、ネゴシエーションされなければならない（MUST）（［draft-ietf-tls-dtls-connection-id］又は［I-D.ietf-tls-dtls13］のセクション９）。ＤＴＬＳ １．３が使用される場合、長さフィールドが含まれなければならず（MUST）、１６ビットシーケンス番号が使用されるべきである（SHOULD）。
【0053】
［draft-ietf-tls-dtls-connection-id］のセクション４は、「しかし、実装が、異なる長さのＣＩＤを受信することを選択する場合、どのコネクション（及びそれ故に、どのＣＩＤ長）が使用されているかを判定するために利用可能な他のメカニズムが存在しないので、割り当てられたＣＩＤ値は自己描写型（self-delineating）でなければならない」と述べている。このソリューションは複数のコネクションＩＤを必要とするため、長さゼロのＣＩＤを使用すると、長さゼロのＣＩＤを有するＤＴＬＳレコードが別のＤＴＬＳコネクションコンテキストになり、解読及び完全性検証に失敗する可能性があるため、非常に問題になる。その場合、ＤＴＬＳレコードを失わないようにするために、ＤＴＬＳコネクションを使用してゼロ長ＣＩＤへ転送されなければならず、復号及び検証が試みられなければならない。リソース使用率が向上する。したがって、ゼロ長のＣＩＤ値を使用せず、代わりにＣＩＤ値に対して単一の共通長を使用することが推奨される（RECOMMENDED）。古いＣＩＤの再利用は、その実装が以前の使用と近い時期に使用されないことを保証する限り可能であるため、１バイトで十分であるはずである。
【0054】
４．２ ＤＴＬＳコネクションの取り扱い
ＤＴＬＳコネクションは、ＳＣＴＰアソシエーションの開始時に確立されなければならない（MUST）。ＳＣＴＰアソシエーションが終了された場合、全てのＤＴＬＳコネクションが終了される。ＤＴＬＳコネクションは、複数のＳＣＴＰアソシエーションにまたがってはならない（MUST NOT）。
ＤＴＬＳコネクションは、ＳＣＴＰアソシエーションの開始時に確立されなければならない（MUST）。ＳＣＴＰアソシエーションが終了された場合、全てのＤＴＬＳコネクションが終了される。ＤＴＬＳコネクションは、複数のＳＣＴＰアソシエーションにまたがってはならない（MUST NOT）。
【0055】
ＳＣＴＰアソシエーションの開始時にＤＴＬＳ接続を確立することが要求されるので、いずれのピアも、ＤＴＬＳによって保護されていないＳＣＴＰユーザメッセージを送信すべきではない。したがって、エンドポイントが、ストリーム０上のＤＴＬＳメッセージでも、任意のストリーム上のＤＴＬＳレコードのシーケンスの形式で保護されたユーザメッセージでもないデータを受信するケースは、プロトコル違反である。受信者は、このプロトコル違反に起因してＳＣＴＰアソシエーションを終了してもよい（MAY）。
【0056】
相互認証、更新されたセキュリティパラメータ、Diffie-Hellmanキー交換の再実行、又はＳＣＴＰ－ＡＵＴＨ再キーイングが必要とされる場合にはいつでも、新たなＤＴＬＳコネクションが、古いコネクションと並列にセットアップされる（即ち、１つのアソシエーション内に最大２つの同時ＤＴＬＳコネクションが存在しうる）。
【0057】
４．３ ペイロードプロトコル識別子の使用
ＳＣＴＰペイロードプロトコル識別子は、ＩＡＮＡによって割り当てられる。ＤＴＬＳ ｏｖｅｒ ＳＣＴＰを使用するアプリケーションプロトコルは、別個のペイロードプロトコル識別子（ＰＰＩＤ）を登録及び使用すべきであり（SHOULD）、ＳＣＴＰ上で直接実行するために登録されたＰＰＩＤを再利用すべきではない（SHOULD NOT）。
ＳＣＴＰペイロードプロトコル識別子は、ＩＡＮＡによって割り当てられる。ＤＴＬＳ ｏｖｅｒ ＳＣＴＰを使用するアプリケーションプロトコルは、別個のペイロードプロトコル識別子（ＰＰＩＤ）を登録及び使用すべきであり（SHOULD）、ＳＣＴＰ上で直接実行するために登録されたＰＰＩＤを再利用すべきではない（SHOULD NOT）。
【0058】
アプリケーションが、ＤＴＬＳが使用されるか否かを判定できる限り、同じＰＰＩＤを使用することに害はない。しかし、例えば、プロトコルアナライザの場合、別個のＰＰＩＤが使用される場合にははるかに容易である。
【0059】
これは、特に、ＤＴＬＳのための固有のＰＰＩＤが存在しないことを意味する。
【0060】
４．４ ストリームの使用
全てのＤＴＬＳハンドシェイク、アラート、又はChangeCipherSpec（ＤＴＬＳ １．２のみ）メッセージは、無制限の信頼性と、順序付けられた配信の機能とを有するストリーム０で転送されなければならない（MUST）。
全てのＤＴＬＳハンドシェイク、アラート、又はChangeCipherSpec（ＤＴＬＳ １．２のみ）メッセージは、無制限の信頼性と、順序付けられた配信の機能とを有するストリーム０で転送されなければならない（MUST）。
【0061】
保護されたユーザメッセージを運ぶ、レコードプロトコルのＤＴＬＳメッセージは、ストリーム０以外の複数のストリームを使うべきであり（SHOULD）、それらはストリーム０を使ってもよい（MAY）。ストリーム０では、保護されたユーザメッセージと、プロトコルを記録しないＤＴＬＳメッセージとが混在するため、ヘッドオブラインブロッキングが（head of line blocking）が発生しうる。
【0062】
４．５ チャンクの取り扱い
ＳＣＴＰのＤＡＴＡチャンクは、［IETF RFC 4895］に記述されているように、認証された方法で送信されなければならない（MUST）。認証されうる他の全てのチャンク、即ち、チャンクリストパラメータ（Chunk List Parameter）[IETF RFC 4895］にリストされうる全てのチャンクタイプも、認証された方法で送信しなければならない（MUST）。これにより、攻撃者が、メッセージが送信されるストリームを変更したり、メッセージの順序付けられた／順序付けられていない配信に影響を与えることができなくなる。
ＳＣＴＰのＤＡＴＡチャンクは、［IETF RFC 4895］に記述されているように、認証された方法で送信されなければならない（MUST）。認証されうる他の全てのチャンク、即ち、チャンクリストパラメータ（Chunk List Parameter）[IETF RFC 4895］にリストされうる全てのチャンクタイプも、認証された方法で送信しなければならない（MUST）。これにより、攻撃者が、メッセージが送信されるストリームを変更したり、メッセージの順序付けられた／順序付けられていない配信に影響を与えることができなくなる。
【0063】
［IETF RFC 3758］で定義されている、部分信頼性のあるＳＣＴＰ（ＰＲ-ＳＣＴＰ：partial reliable SCTP）が使用される場合、ＦＯＲＷＡＲＤ－ＴＳＮチャンクもまた、[IETF RFC 4895］で説明されているように認証された方法で送信されなければならない（MUST）。これは、攻撃者が、メッセージをドロップし、偽造されたＦＯＲＷＡＲＤ－ＴＳＮ、ＳＡＣＫ、及び／又はＳＨＵＴＤＯＷＮチャンクを使用して、このドロップを隠すことが不可能になることを確実にする。
【0064】
［IETF RFC 8260］で定義されているＩ－ＤＡＴＡチャンクタイプは、大きなユーザメッセージが、後に到着する高優先度のユーザメッセージの送信をブロックする際に有する下向きの側面のいくつかを避けるためにサポートされることが推奨される（RECOMMENDED）。ただし、サポートは、ＤＴＬＳ／ＳＣＴＰとは独立して必須ではなく、ネゴシエーションされない。Ｉ－ＤＡＴＡチャンクが使用される場合、それらは、[IETF RFC 4895］に記述されているように認証された方法で送られなければならない。
【0065】
４．６ ＳＣＴＰ－ＡＵＴＨハッシュ関数
ＤＴＬＳ／ＳＣＴＰを使用する場合、ＳＨＡ－２５６メッセージダイジェストアルゴリズムは、ＳＣＴＰ－ＡＵＴＨ［IETF RFC 4895］実装でサポートされなければならない（MUST）。ＤＴＬＳ／ＳＣＴＰを使用する場合にはＳＨＡ－１は使用されてはならない（MUST NOT）。［IETF RFC 4895］は、HMAC-ALGOパラメータのサポート及びそれを含めることを要求し、それ故に、両方の要件を満たすために、HMAC-ALGOパラメータは、ＳＨＡ－２５６と、優先度を示すためにＳＨＡ－１の前にリストされたＳＨＡ－２５６を有するＳＨＡ－１との両方を含む。
ＤＴＬＳ／ＳＣＴＰを使用する場合、ＳＨＡ－２５６メッセージダイジェストアルゴリズムは、ＳＣＴＰ－ＡＵＴＨ［IETF RFC 4895］実装でサポートされなければならない（MUST）。ＤＴＬＳ／ＳＣＴＰを使用する場合にはＳＨＡ－１は使用されてはならない（MUST NOT）。［IETF RFC 4895］は、HMAC-ALGOパラメータのサポート及びそれを含めることを要求し、それ故に、両方の要件を満たすために、HMAC-ALGOパラメータは、ＳＨＡ－２５６と、優先度を示すためにＳＨＡ－１の前にリストされたＳＨＡ－２５６を有するＳＨＡ－１との両方を含む。
【0066】
４．７ 並列ＤＴＬＳコネクション
ＳＣＴＰ－ＡＵＴＨの再キーイング、両方のエンドポイントの定期的な認証、及び攻撃者に動的キー抽出を強制することを有効にするために、この明細書によるＤＴＬＳ／ＳＣＴＰは、同じＳＣＴＰアソシエーション上での並列ＤＴＬＳコネクションの使用を定義する。このソリューションは、ＤＴＬＳによるＳＣＴＰアソシエーションの存続期間に制限がないことを保証し、また、ＤＴＬＳ再ネゴシエーション（ＤＴＬＳ １．２ のみ）、又は相互エンドポイント再認証を許可しないＤＴＬＳ １．３のキー更新のプロパティへの依存も回避する。既存のＤＴＬＳがそのまま維持される一方で、並列ＤＴＬＳコネクションは、フルハンドシェイクを実行する新たなＤＴＬＳコネクションを開くことを可能にし、再開を使用しうる。ハンドシェイク完了時に、新たなＤＴＬＳコネクションのセキュリティコンテキストに切り替え、古いＤＴＬＳコネクションのセキュリティコンテキストを使用して全てのＳＣＴＰチャンクの配信を確実にする。これが達成されると、古いＤＴＬＳコネクションを閉じ、関連するセキュリティコンテキストを破棄する。
ＳＣＴＰ－ＡＵＴＨの再キーイング、両方のエンドポイントの定期的な認証、及び攻撃者に動的キー抽出を強制することを有効にするために、この明細書によるＤＴＬＳ／ＳＣＴＰは、同じＳＣＴＰアソシエーション上での並列ＤＴＬＳコネクションの使用を定義する。このソリューションは、ＤＴＬＳによるＳＣＴＰアソシエーションの存続期間に制限がないことを保証し、また、ＤＴＬＳ再ネゴシエーション（ＤＴＬＳ １．２ のみ）、又は相互エンドポイント再認証を許可しないＤＴＬＳ １．３のキー更新のプロパティへの依存も回避する。既存のＤＴＬＳがそのまま維持される一方で、並列ＤＴＬＳコネクションは、フルハンドシェイクを実行する新たなＤＴＬＳコネクションを開くことを可能にし、再開を使用しうる。ハンドシェイク完了時に、新たなＤＴＬＳコネクションのセキュリティコンテキストに切り替え、古いＤＴＬＳコネクションのセキュリティコンテキストを使用して全てのＳＣＴＰチャンクの配信を確実にする。これが達成されると、古いＤＴＬＳコネクションを閉じ、関連するセキュリティコンテキストを破棄する。
【0067】
セクション４．１に規定されているように、ＤＴＬＳコネクションＩＤの使用は、その保護解除（de-protection）動作を実行する場合に、受信機が、ＤＴＬＳコネクション及びそのセキュリティコンテキストを正しく識別できることを保証するために必要とされる。また、ＤＴＬＳ １．２の再ネゴシエーションが、複数のキーがエクスポートされうる場合に使用されない限り、各ｋｅｙ－ｉｄに対してＤＴＬＳコネクションとＳＣＴＰ－ＡＵＴＨ セキュリティコンテキストとの間に明確なマッピングがあることを保証するＤＴＬＳコネクションごとにエクスポートされるＳＣＴＰ－ＡＵＴＨキーは、１つだけである。
【0068】
アプリケーションライターは、新たなＤＴＬＳコネクションを確立することによってセキュリティパラメータが変更される可能性があることに注意する必要がある。再キーイングに関するセキュリティの留意事項についてはセクション８を参照のこと。
【0069】
ＤＴＬＳ／ＳＣＴＰエンドポイントは、同時に２つ以上のＤＴＬＳコネクションを開いてはならない（MUST NOT）。いずれのエンドポイントも、完全なＤＴＬＳハンドシェイクを実行することによって新たなＤＴＬＳコネクションを開始してもよく（MAY）、該当する場合、ＤＴＬＳ再開を使用してもよい（MAY）。いずれのエンドポイントも、同時に両側でＤＴＬＳハンドシェイクを開始しうるので、いずれのエンドポイントも、独自のClientHelloを送信した際にDTLS ClientHelloを受信しうる。この場合、既存のＤＴＬＳコネクションの確立においてＤＴＬＳクライアントの役割を有するエンドポイントからのClientHelloは処理され続けられるべきであり、他方はドロップされる。
【0070】
ＤＴＬＳハンドシェイクを実行する際、エンドポイントは、ピアが、以前のＤＴＬＳコネクションと同じアイデンティティを使用して識別することを検証しなければならない（MUST）。
【0071】
ＤＴＬＳハンドシェイクが完了すると、（図１に示されるような）新たなＳＣＴＰ－ＡＵＴＨキーが、セクション４．９に従ってエクスポートされ、新たなＤＴＬＳコネクションが、将来の保護ＳＣＴＰメッセージのＤＴＬＳ保護動作のために使用されなければならない（MUST）。エンドポイントは、ハンドシェイクが完了した後に発生するＤＴＬＳ保護動作のために新たなＤＴＬＳコネクションのセキュリティコンテキストを使用することを推奨される（RECOMMENDED）。新たなＳＣＴＰ－ＡＵＴＨキーは、ＤＴＬＳハンドシェイクが完了した後に送信される任意のＳＣＴＰメッセージのために使用されるべきである（SHALL）。新たなＤＴＬＳハンドシェイクの完了前に開始されたがまだ完全には送信されていないＳＣＴＰメッセージの任意のＳＣＴＰパケット部分に対して、新たなＳＣＴＰ－ＡＵＴＨキーを使用する可能性があるが、［IETF RFC 6458］において定義されたＡＰＩは、セクション６の拡張がサポートされない限り、これをサポートしない。
【0072】
ＳＣＴＰエンドポイントは、以前のＤＴＬＳコネクション及びそのコンテキストが、いつ、このエンドポイントからそれ以上のデータを受信するためにもはや必要とされなくなるのかを、そのピアに知らせる。これは、ＤＴＬＳに、DTLS close_notifyアラートを送信させることによって行われる。エンドポイントは、以下の２つの条件が満たされるまではclose_notifyを送信してはならない（MUST NOT）：
‐このＤＴＬＳコネクションのセキュリティコンテキストを使用して保護された任意のＤＴＬＳレコード又はメッセージの一部を含む全てのＳＣＴＰパケットが、非再現可能な方法で確認応答される；及び
‐このＤＴＬＳコネクションのセキュリティコンテキストと関連付けられたＳＣＴＰ－ＡＵＴＨキーを使用する全てのＳＣＴＰパケットが、非再現可能な方法で確認応答される。
‐このＤＴＬＳコネクションのセキュリティコンテキストを使用して保護された任意のＤＴＬＳレコード又はメッセージの一部を含む全てのＳＣＴＰパケットが、非再現可能な方法で確認応答される；及び
‐このＤＴＬＳコネクションのセキュリティコンテキストと関連付けられたＳＣＴＰ－ＡＵＴＨキーを使用する全てのＳＣＴＰパケットが、非再現可能な方法で確認応答される。
【0073】
保護される全ての将来のＤＴＬＳレコードに対して新たなＤＴＬＳコネクションのセキュリティコンテキストを使用し、関連付けられた新たなＳＣＴＰ－ＡＵＴＨキーを同時に有効にし、将来の保護動作のために古いコンテキストを使用しないことを可能にする実装について、上記の条件を決定する非常に基本的な方法がある。新たなセキュリティコンテキストを使用する最初の（部分的な）ＳＣＴＰメッセージ送信コールの一部である最初のＳＣＴＰチャンクが送信された時刻をマークする。そのＳＣＴＰチャンク、及び、それ故に古いセキュリティコンテキストを使用する全ての以前のチャンクは、エンドポイント障害検出（［IETF RFC 4960］のセクション８．１を参照）が、ＳＣＴＰアソシエーションをトリガ及び終了する前に、ピアへ配信されていなければならない。このタイムアウト期間の上限を算出し、これは、２つの設定変更可能なパラメータに依存する。最大エンドポイント障害タイムアウト期間は、'Association.Max.Retrans'とRTO.Maxパラメータとの積である。RTO.Max＝６０秒で１０回試行の時間（即ち、１０分）［IETF RFC ４９６０］ごとのデフォルト値の場合。
【0074】
［IETF RFC 6458］のようなＡＰＩを公開するＳＣＴＰ実装の場合、セキュリティコンテキストの変更前に開始された部分的なＳＣＴＰメッセージのＳＣＴＰ－ＡＵＴＨキーを変更することが不可能であるため、ＳＣＴＰメッセージを追跡して、古いセキュリティコンテキストを使用する全てのメッセージが送信されたタイミングを判定することを余儀なくされる。これは、ＤＴＬＳ／ＳＣＴＰ層とＳＣＴＰ実装との間のより緊密な統合無で、完全に信頼性があるようにすることは不可能でありうる。このタイプの実装は更に、それがサポートすることができるＳＣＴＰメッセージの大きさにも暗黙の制限を有する。各ＳＣＴＰメッセージは、更に別のＤＴＬＳコネクションを作成する必要がある前に、配信を完了し、以前のＤＴＬＳコネクションをクローズすることを可能にする必要がある。このため、ＳＣＴＰメッセージは、このＳＣＴＰアソシエーションのための再キーイング又は再認証の間の持続時間よりも短い時間で送信が完了するよりも、大きくされることはできない。
【0075】
ＤＴＬＳ／ＳＣＴＰ実装が、ＳＣＴＰスタックとより緊密に統合されるか、又はＤＴＬＳ／ＳＣＴＰ実装が、ＳＣＰＴメッセージがいつ配信されたかを知ることを可能にするより完全なＡＰＩを有する場合、古いＤＴＬＳコネクションをよりタイムリーにクローズすることができ、それ故に、必要に応じて、より頻繁な再キーイング等をサポートする。
【0076】
受信機がデータを受信するより前に古いＤＴＬＳコネクションでDTLS close_notifyアラートを送信した結果、セクション４．１に記載の障害ケース１が発生する可能性があり、これはＳＣＴＰアソシエーションの終了につながる可能性がある。
【0077】
４．７ｂ． 再ネゴシエーションとKeyUpdate
ＤＴＬＳ １．２の再ネゴシエーションにより、ＤＴＬＳ １．２コネクション内での相互再認証と同様に、ＤＴＬＳの（短期（ephemeral）Diffie-Hellmanを用いた）再キーイングが可能になる。再ネゴシエーションは、ＤＴＬＳ １．３から削除され、一部はKeyUpdate等のハンドシェイク後のメッセージに置き換えられている。並列ＤＴＬＳコネクション・ソリューションは、相互再認証だけでなく（短期Diffie-Hellmanを用いた）再キーイング等、長寿命ＳＣＴＰアソシエーションに必要と考えられる、ＤＴＬＳ １．３に必要な機能が存在しないために規定された。
ＤＴＬＳ １．２の再ネゴシエーションにより、ＤＴＬＳ １．２コネクション内での相互再認証と同様に、ＤＴＬＳの（短期（ephemeral）Diffie-Hellmanを用いた）再キーイングが可能になる。再ネゴシエーションは、ＤＴＬＳ １．３から削除され、一部はKeyUpdate等のハンドシェイク後のメッセージに置き換えられている。並列ＤＴＬＳコネクション・ソリューションは、相互再認証だけでなく（短期Diffie-Hellmanを用いた）再キーイング等、長寿命ＳＣＴＰアソシエーションに必要と考えられる、ＤＴＬＳ １．３に必要な機能が存在しないために規定された。
【0078】
本明細書では、これらのメカニズムのいずれかを使用せず、代わりに並列ＤＴＬＳコネクションに依存することを推奨する。ＤＴＬＳ １．３の場合、機能パリティはない。両方とも、ＩＥＴＦ ＲＦＣを含む標準規格に従うＤＴＬＳ実装は、以前のエポックのセキュリティコンテキストが維持され、それ故にエポック処理（セクション４．８）への変更が必要であるＳＣＴＰに対して、あまりに制限されたウィンドウを仮定しうるという問題を有する。したがって、ドレイニングに影響を及ぼす、以下で規定されるより多くのアプリケーションが使用されない限り、送信者が、確実に配信されたと想定されるデータを失うリスクが存在する。
【0079】
４．７ｂ．１ ＤＴＬＳ １．２の留意事項
エンドポイントは、このＳＣＴＰアソシエーションで新たな並列ＤＴＬＳコネクションの確立を開始した後、既存の／古いＤＴＬＳコネクションでＤＴＬＳ再ネゴシエーションを開始してはならない（MUST NOT）。エンドポイントが既存のＤＴＬＳコネクションでＤＴＬＳ再ネゴシエーションを開始した後に新たなＤＴＬＳコネクション・ハンドシェイクが受信される場合、両パーティは、再ネゴシエーションを完了する必要があり、ＳＣＰＴ－ＡＵＴＨキー識別子はｎ＋１であるべきであり、新たなＤＴＬＳコネクションはｎ＋２を使用すべきである。これは、最初に再ネゴシエーションを終了し、再ネゴシエーションが完了するまで新たなＤＴＬＳハンドシェイク処理を保持することによって達成されうる。
エンドポイントは、このＳＣＴＰアソシエーションで新たな並列ＤＴＬＳコネクションの確立を開始した後、既存の／古いＤＴＬＳコネクションでＤＴＬＳ再ネゴシエーションを開始してはならない（MUST NOT）。エンドポイントが既存のＤＴＬＳコネクションでＤＴＬＳ再ネゴシエーションを開始した後に新たなＤＴＬＳコネクション・ハンドシェイクが受信される場合、両パーティは、再ネゴシエーションを完了する必要があり、ＳＣＰＴ－ＡＵＴＨキー識別子はｎ＋１であるべきであり、新たなＤＴＬＳコネクションはｎ＋２を使用すべきである。これは、最初に再ネゴシエーションを終了し、再ネゴシエーションが完了するまで新たなＤＴＬＳハンドシェイク処理を保持することによって達成されうる。
【0080】
再ネゴシエーション中にClientHelloメッセージ又はServerHelloメッセージを送信する前に、ＤＴＬＳエンドポイントは、以前のエポックを使用する全てのＤＴＬＳメッセージが、取り消し不可能な方法でＳＣＴＰピアによって確認応答されていることを保証なければならない（MUST）。
【0081】
受信されたClientHelloメッセージ又はServerHelloメッセージを処理する前に、ＳＣＴＰ層にバッファリングされ、ＤＴＬＳ層に配信されうる、他の全ての受信されたＳＣＴＰユーザメッセージは、ＤＴＬＳによって読み出されて処理されなければならない（MUST）。
【0082】
４．７ｂ．２ ＤＴＬＳ １．３の留意事項
KeyUpdateメッセージを送信する前に、ＤＴＬＳエンドポイントは、全てのＤＴＬＳメッセージが取り消し不可能な方法でＳＣＴＰピアによって確認応答されていることを保証しなければならない。KeyUpdateメッセージの送信後、対応するＡｃｋメッセージが処理されるまでＤＴＬＳメッセージの送信を停止する。
KeyUpdateメッセージを送信する前に、ＤＴＬＳエンドポイントは、全てのＤＴＬＳメッセージが取り消し不可能な方法でＳＣＴＰピアによって確認応答されていることを保証しなければならない。KeyUpdateメッセージの送信後、対応するＡｃｋメッセージが処理されるまでＤＴＬＳメッセージの送信を停止する。
【0083】
受信されたKeyUpdateメッセージを処理する前に、ＳＣＴＰ層にバッファリングされ、ＤＴＬＳ層に配信されうる、他の全ての受信されたＳＣＴＰユーザメッセージは、ＤＴＬＳによって読み出されて処理されなければならない（MUST）。
【0084】
４．７ｃ 動作フロー
いくつかの実施形態では、ＳＣＴＰアソシエーション上で２つの並列ＤＴＬＳコネクションを確立することは、以下の動作を含む：
いくつかの実施形態では、ＳＣＴＰアソシエーション上で２つの並列ＤＴＬＳコネクションを確立することは、以下の動作を含む：
【0085】
１． 既存のＳＣＴＰ－ＡＵＴＨキーによって保護された新たなＤＴＬＳハンドシェイクを開始する。
２． ＤＴＬＳハンドシェイクを完了し、新たなセキュリティコンテキストを確立し、キー識別子を与えられた新たなＳＣＴＰ－ＡＵＴＨキーをエクスポートする。
３． 新たなＤＴＬＳコネクション及び確立されたセキュリティコンテキストの使用を開始することで、メッセージの全体又はフラグメントを上位層プロトコルから保護し、任意の新たなＵＬＰメッセージを保護するために以前のＤＴＬＳコネクションを使用することを停止する。
４． 任意の将来のＳＣＴＰパケット又はＳＣＴＰメッセージで新たなＳＣＰＴ－ＡＵＴＨキーの使用を開始し、任意の新たなＳＣＴＰメッセージに対して古いキーを使用しない。
５． 各エンドポイントは、全ての保護されたメッセージフラグメントとＳＣＴＰパケットとがいつ配信されたかを判定し、古いＤＴＬＳコネクションの方向をクローズする。
６． ＤＴＬＳコネクションがクローズした場合、セキュリティコンテキストと、このＤＴＬＳコネクションにエクスポートされたＳＣＴＰ－ＡＵＴＨキーを削除する。
２． ＤＴＬＳハンドシェイクを完了し、新たなセキュリティコンテキストを確立し、キー識別子を与えられた新たなＳＣＴＰ－ＡＵＴＨキーをエクスポートする。
３． 新たなＤＴＬＳコネクション及び確立されたセキュリティコンテキストの使用を開始することで、メッセージの全体又はフラグメントを上位層プロトコルから保護し、任意の新たなＵＬＰメッセージを保護するために以前のＤＴＬＳコネクションを使用することを停止する。
４． 任意の将来のＳＣＴＰパケット又はＳＣＴＰメッセージで新たなＳＣＰＴ－ＡＵＴＨキーの使用を開始し、任意の新たなＳＣＴＰメッセージに対して古いキーを使用しない。
５． 各エンドポイントは、全ての保護されたメッセージフラグメントとＳＣＴＰパケットとがいつ配信されたかを判定し、古いＤＴＬＳコネクションの方向をクローズする。
６． ＤＴＬＳコネクションがクローズした場合、セキュリティコンテキストと、このＤＴＬＳコネクションにエクスポートされたＳＣＴＰ－ＡＵＴＨキーを削除する。
【0086】
図２は、いくつかの実施形態による、ＳＣＴＰアソシエーション上で並列のＤＴＬＳコネクションを確立する動作を示す。本動作は、並列ＤＴＬＳコネクションコーディネータ１１２を実装するネットワークノードによって実行されうる。ネットワークノードは、いくつかの実施形態において、第２のネットワークノードへのセキュア伝送（secure transmission）のためにユーザメッセージを符号化する、第１のネットワークノードである。
【0087】
リファレンス２０２において、ネットワークノードは、１つ以上のアプリケーションのためのユーザメッセージを送信するために、ＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上でＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションを確立する。このＤＴＬＳコネクションは、同じＳＣＴＰアソシエーション上の２つの並列ＤＴＬＳコネクションのうちの第１のＤＴＬＳコネクションであり、既存のＤＴＬＳコネクションとも称されうる。
【0088】
リファレンス２０４において、ネットワークノードは、ユーザメッセージを送信するＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションからの、既存のＳＣＴＰ－ＡＵＴＨ（ＳＣＴＰのための認証されたチャンク、Authenticated Chunks for SCTP）キーを使用したＤＴＬＳハンドシェイクを通じて、ＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上でＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションを開始する。開始されたＤＴＬＳコネクションは、同じＳＣＴＰアソシエーション上の２つの並列ＤＴＬＳコネクションのうちの第２のＤＴＬＳコネクションである。
【0089】
リファレンス２０６において、ネットワークノードは、開始されたＤＴＬＳコネクションから新規のＳＣＴＰ－ＡＵＴＨキーを導出する。オプションとしてリファレンス２０８において、ネットワークノードは、いくつかの実施形態において、開始されたＤＬＴＳコネクションによって保護されているが既存のＳＣＴＰ－ＡＵＴＨキーで認証されているユーザメッセージの更なる部分を含む、進行中のＳＣＴＰパケットを送信する。あるいは、ネットワークノードは、既存のＤＴＬＳコネクションによって保護され、かつ、既存のＳＣＴＰ－ＡＵＴＨキーで認証されるべきユーザメッセージの更なる部分を含む、進行中のＳＣＴＰパケットを送信してもよい。
【0090】
リファレンス２１０において、ネットワークノードは、新規のＳＣＴＰ－ＡＵＴＨキーを用いて、開始されたＤＴＬＳコネクションを通じて更なるユーザメッセージを送信する。リファレンス２１２において、ネットワークノードは、既存のＤＴＬＳコネクションで暗号化されたＳＣＴＰパケットと、既存のＳＣＴＰ－ＡＵＴＨキーによって認証されたＳＣＴＰパケットとが配信されたことを確認すると、ＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションをクローズする。
【0091】
いくつかの実施形態では、ＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションをクローズすることは、第１のＤＴＬＳコネクションクローズ通知を第２のネットワークノードへ送信することを含む。第１のＤＴＬＳコネクションクローズ通知は、上述のDTLS close_notifyアラートであってもよい。
【0092】
いくつかの実施形態では、ＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションをクローズすることは、第２のＤＴＬＳコネクションクローズ通知を第２のネットワークノードから受信することを更に含む。
【0093】
いくつかの実施形態では、第１のＤＴＬＳコネクションクローズ通知を送信することは、第１のＤＴＬＳコネクションクローズ通知を送信する前に、既存のＤＴＬＳコネクションにおける送信データが非再現可能な方法で（in a non-renegable way）第２のネットワークノードによって確認応答されたことを確認することを含む。例えば、当該確認は、１）このＤＴＬＳコネクションのセキュリティコンテキストを使用して保護された任意のＤＴＬＳレコード又はメッセージの一部を含む、全てのＳＣＴＰパケットが、非再現可能な方法で確認応答されたこと、及び／又は、２）このＤＴＬＳコネクションのセキュリティコンテキストと関連付けられたＳＣＴＰ－ＡＵＴＨキーを使用する全てのＳＣＴＰパケットが、非再現可能な方法で確認応答されたこと、を確認することを含む。
【0094】
いくつかの実施形態では、既存の及び新規のＳＣＴＰ－ＡＵＴＨキーは、対応する既存の新規のキー識別子（ＩＤ）によって識別され、新規の識別子は、既存のキー識別子から１だけ増加させた値である。上記の例が示すように、以前の共有シークレット（shared secret）が、共有キー識別子ｎを使用した場合、新規のものは共有キー識別子ｎ＋１を使用する。いくつかの実施形態では、モジュロ演算が実行されてもよく、例えば、新規の共有キー識別子は、１６ビット実装の場合には（ｎ＋１）ｍｏｄ ６５５３５である（結果＝０の場合、１に設定される；例えば、ｎ＝６５５３４、ｎ＋１＝６５５３５、及び（ｎ＋１）ｍｏｄ（６５５３５）＝０の場合、それ故に新規のキーＩＤは１である）。キーＩＤが別のビット幅で実装された場合、除数も変更される。例えば、キーＩＤが８ビットで実装される場合、除数は２５５である。
【0095】
いくつかの実施形態では、ＤＴＬＳコネクションは、ＳＣＴＰアソシエーション上の既存のＤＴＬＳコネクションの１つ以上の証明書が失効する前に確立される。いくつかの実施形態では、ＤＴＬＳハンドシェイクを通じてＳＣＴＰアソシエーション上でＤＴＬＳコネクションを開始することは、１つ以上の証明書内のタイムスタンプを含む既存のＤＴＬＳコネクションの１つ以上の証明書を維持することを含む。
【0096】
いくつかの実施形態では、第１のネットワークノードと第２のネットワークノードとの間でハンドシェイクを実行することは、ハンドシェイクを開始し、かつ、当該ハンドシェイクのイニシエーションを受信したことに応答して、第１のネットワークノードがＤＴＬＳコネクションのＤＴＬＳクライアントとして機能する場合に、開始されたハンドシェイクを継続することを含む。
【0097】
いくつかの実施形態では、既存のＳＣＴＰ－ＡＵＴＨキーは、既存のＤＴＬＳコネクションのクローズに応じて削除される。
【0098】
本発明の実施形態は、既存のソリューションによるキー変更時のデータドレイニングドレインフェーズ中に、ＤＴＬＳ／ＳＣＴＰセッションにおいてデータ送信をアプリケーションが一時停止又は少なくとも遅延させる、アプリケーションの影響を回避する。ＤＴＬＳ保護レコードは、自己記述型であり（ＤＴＬＳ １．３の機能及びＤＴＬＳ １．２の拡張）、セッションＩＤが有効になっている場合に共存しうるため、ドレインフェーズが回避される。更に、独立ＤＴＬＳコネクション管理は、このキーを使用する全データが最初に配信されたことをそれぞれのサイドが知っている場合に、明示的な非同期クローズシグナリングを可能にし、その結果、コネクションをクローズダウンし、秘密キーマテリアルを廃棄する。したがって、並列ＤＴＬＳコネクションは、再ネゴシエーションでＤＴＬＳ １．２を使用するいくつかの問題を回避する。また、ＤＴＬＳ １．３を使用した場合にも、重要な機能が実現されうることが保証される。
【0099】
４．８ ＤＴＬＳエポック
一般に、ＤＴＬＳの実装は、以前のエポックからのレコードを破棄すべきである（SHOULD）。しかし、信頼性のある通信のコンテキストではこれは適切ではない。
一般に、ＤＴＬＳの実装は、以前のエポックからのレコードを破棄すべきである（SHOULD）。しかし、信頼性のある通信のコンテキストではこれは適切ではない。
【0100】
４．８．１ ＤＴＬＳ １．２の留意事項
［IETF RFC 6347］のセクション４．１の手順に従うべきではない（MUST NOT）。
［IETF RFC 6347］のセクション４．１の手順に従うべきではない（MUST NOT）。
【0101】
その代わりに、エポックｎを現在使用している場合、ｎ＞１について、エポックｎ－１とｎからのＤＴＬＳパケットが処理されなければならない（MUST）。
【0102】
４．８．２． ＤＴＬＳ １．３の留意事項
［I-D.ietf-tls-dtls13］のセクション４．２．１の手順は無関係である。エポックｎを使用してＤＴＬＳパケットを受信する場合、以前のエポックからのＤＴＬＳパケットは受信されない。
［I-D.ietf-tls-dtls13］のセクション４．２．１の手順は無関係である。エポックｎを使用してＤＴＬＳパケットを受信する場合、以前のエポックからのＤＴＬＳパケットは受信されない。
【0103】
４．９． エンドポイントペア共有シークレットの処理
ＳＣＴＰ－ＡＵＴＨ［IETF RFC 4895］は、エンドポイントペア共有シークレットを使用してキーイングされる。ＤＴＬＳが使用されるＳＣＴＰアソシエーションでは、これらのシークレットを確立するためにＤＴＬＳが使用される。エンドポイントは、ＳＣＴＰ－ＡＵＴＨの共有シークレットを確立するために別のメカニズムを使用してはならない（MUST NOT）。共有キー識別子０についてのエンドポイントペア共有シークレットは空であり、第１のＤＴＬＳコネクションを確立する際に使用されなければならない（MUST）。
ＳＣＴＰ－ＡＵＴＨ［IETF RFC 4895］は、エンドポイントペア共有シークレットを使用してキーイングされる。ＤＴＬＳが使用されるＳＣＴＰアソシエーションでは、これらのシークレットを確立するためにＤＴＬＳが使用される。エンドポイントは、ＳＣＴＰ－ＡＵＴＨの共有シークレットを確立するために別のメカニズムを使用してはならない（MUST NOT）。共有キー識別子０についてのエンドポイントペア共有シークレットは空であり、第１のＤＴＬＳコネクションを確立する際に使用されなければならない（MUST）。
【0104】
イニシャルＤＴＬＳコネクションが、以下のＤＴＬＳバージョンに従って規定された新規の共有シークレットを確立するために使用され、共有キー識別子１を使用しなければならない（MUST）。DTLS Finishedメッセージを送信した後、アクティブなＳＣＴＰ－ＡＵＴＨキーは、新しいものに切り替えられなければならない（MUST）。ピアからのイニシャルFinishedメッセージが、ＤＴＬＳによって処理されると、共有キー識別子０を有するＳＣＴＰ－ＡＵＴＨキーは削除されなければならない（MUST）。
【0105】
後続のＤＴＬＳコネクションがセットアップされた場合、TLS-Exporterを使用して新規の６４バイトの共有シークレットが導出される。共有シークレット識別子は、シーケンスを形成する。以前の共有シークレットが共有キー識別子ｎを使用した場合、新規のものは共有キー識別子ｎ＋１を使用しなければならない（MUST）。
【0106】
DTLS Finishedメッセージを送信した後、アクティブなＳＣＴＰ－ＡＵＴＨキーは、新しいものに切り替えられなければならない（MUST）。エンドポイントが、古いＤＴＬＳコネクションでcloseNotifyの送信及び受信の両方を行った場合、エンドポイントは、古いＤＴＬＳコネクションに関連する（１つ以上の）共有シークレットを削除する必要がある。
【0107】
４．９．１． ＤＴＬＳ １．２の留意事項
マスターシークレットが変更されるごとに、即ち、ＤＴＬＳ再ネゴシエーション又は新たなＤＴＬＳコネクションの確立のいずれかに起因して、６４バイトの共有シークレットが、全てのマスターシークレットから導出され、［IETF RFC 5705］に記載のされているＴＬＳエクスポータ（TLS-Exporter）を使用することによって、新たなエンドポイントペア共有シークレットとして提供される。
マスターシークレットが変更されるごとに、即ち、ＤＴＬＳ再ネゴシエーション又は新たなＤＴＬＳコネクションの確立のいずれかに起因して、６４バイトの共有シークレットが、全てのマスターシークレットから導出され、［IETF RFC 5705］に記載のされているＴＬＳエクスポータ（TLS-Exporter）を使用することによって、新たなエンドポイントペア共有シークレットとして提供される。
【0108】
６４バイトの共有シークレットは、演算が可能であればすぐにＳＣＴＰスタックに提供されなければならない（MUST）。エクスポータは、セクション７で与えられたラベルを使用し、かつ、コンテキストを使用してはならない（MUST）。共有キー識別子は、再ネゴシエーションに起因したエポック変更に対してもｎ＋１となるように、上記に従って選択される。
【0109】
ｍ＞２のＤＴＬＳエポックｍを使用するFinishedメッセージがＤＴＬＳによって処理されると、このＤＴＬＳコネクションとエポックｍ－２のための共有キー識別子を有するＳＣＴＰ－ＡＵＴＨキーは削除されなければならない。
【0110】
ＤＴＬＳコネクションがクローズし、かつ、それが再ネゴシエーションを使用する場合、新たなＤＴＬＳコネクションがｎ＋１を作成したとき、未削除の全ての共有キーが削除されなければならず（MUST）、これは、ｎとｎ－１であるべきである。
【0111】
４．９．２． ＤＴＬＳ １．３の留意事項
exporter_secretが演算されうる場合、６４ バイトの共有シークレットがそれから導出され、［IETF RFC 8446］に記載のＴＬＳエクスポータを使用することによって新たなエンドポイントペア共有シークレットとして提供される。６４バイトの共有シークレットは、演算が可能であればすぐにＳＣＴＰスタックに提供されなければならない（MUST）。エクスポータは、セクション７で与えられたラベルを使用し、かつ、コンテキストを使用してはならない（MUST）。
exporter_secretが演算されうる場合、６４ バイトの共有シークレットがそれから導出され、［IETF RFC 8446］に記載のＴＬＳエクスポータを使用することによって新たなエンドポイントペア共有シークレットとして提供される。６４バイトの共有シークレットは、演算が可能であればすぐにＳＣＴＰスタックに提供されなければならない（MUST）。エクスポータは、セクション７で与えられたラベルを使用し、かつ、コンテキストを使用してはならない（MUST）。
【0112】
４．１０． シャットダウン
ＤＴＬＳが、シャットダウン中にＤＴＬＳユーザメッセージを破棄しないようにするために、CloseNotifyメッセージは、全ての未処理のＳＣＴＰユーザメッセージが取り消し不可能な方法でＳＣＴＰピアによって確認応答された後にのみ送信されなければならない（MUST）。
ＤＴＬＳが、シャットダウン中にＤＴＬＳユーザメッセージを破棄しないようにするために、CloseNotifyメッセージは、全ての未処理のＳＣＴＰユーザメッセージが取り消し不可能な方法でＳＣＴＰピアによって確認応答された後にのみ送信されなければならない（MUST）。
【0113】
受信されたCloseNotifyを処理する前に、ＳＣＴＰ層にバッファリングされている他の全ての受信されたＳＣＴＰユーザメッセージは、ＤＴＬＳによって読み出されて処理されなければならない（MUST）。
【0114】
５． ＤＴＬＳ ｏｖｅｒ ＳＣＴＰサービス
現在の記述に従ってＤＴＬＳ ｏｖｅｒ ＳＣＴＰを採用することは、暗号化されたデータを転送するためのオプションをＳＣＴＰに追加することを意味する。
現在の記述に従ってＤＴＬＳ ｏｖｅｒ ＳＣＴＰを採用することは、暗号化されたデータを転送するためのオプションをＳＣＴＰに追加することを意味する。
【0115】
ＤＴＬＳ ｏｖｅｒ ＳＣＴＰが使用される場合、転送される全てのデータはチャンク認証とＤＴＬＳ暗号化によって保護されなければならない（MUST）。認証された方法で受信される必要があるチャンクは、[IETF RFC 4895］に従ってＣＨＵＮＫリストパラメータで規定される。認証されたチャンクのエラー処理は、［IETF RFC 4895］に従う。
【0116】
５．１． ＩＮＩＴ／ＩＮＩＴ－ＡＣＫにおけるアダプテーション層インジケーション
アソシエーションの初期化時に、この明細書において規定されたＤＴＬＳ／ＳＣＴＰを使用しようとするＩＮＩＴ又はINIT ACKチャンクの送信者は、この明細書に従ってＤＴＬＳ ｏｖｅｒ ＳＣＴＰをサポートできることをピアに知らせなけれるために、ＩＡＮＡ割り当て値ＴＢＤ（セクション７．２）を有するアダプテーション層インジケーションパラメータ（Adaptation Layer Indication Parameter）を含めなければならない（MUST）。
アソシエーションの初期化時に、この明細書において規定されたＤＴＬＳ／ＳＣＴＰを使用しようとするＩＮＩＴ又はINIT ACKチャンクの送信者は、この明細書に従ってＤＴＬＳ ｏｖｅｒ ＳＣＴＰをサポートできることをピアに知らせなけれるために、ＩＡＮＡ割り当て値ＴＢＤ（セクション７．２）を有するアダプテーション層インジケーションパラメータ（Adaptation Layer Indication Parameter）を含めなければならない（MUST）。
【0117】
５．２． ＤＴＬＳ ｏｖｅｒ ＳＣＴＰの初期化
図３は、本開示のいくつかの実施形態による、第１のノードと第２のノードとの間のシグナリングダイアグラム３００を示す。ダイアグラム３００は、第１のノード（ネットワークノード１）３１０と第２のノード（ネットワークノード２）３２０との間の初期化を示す。ネットワークノード１及びネットワークノード２は、通信ネットワーク内のノード等の、互いに通信する任意のタイプのノードでありうる。
図３は、本開示のいくつかの実施形態による、第１のノードと第２のノードとの間のシグナリングダイアグラム３００を示す。ダイアグラム３００は、第１のノード（ネットワークノード１）３１０と第２のノード（ネットワークノード２）３２０との間の初期化を示す。ネットワークノード１及びネットワークノード２は、通信ネットワーク内のノード等の、互いに通信する任意のタイプのノードでありうる。
【0118】
ＤＴＬＳ／ＳＣＴＰの初期化は、ＩＮＩＴ／ＩＮＩＴ－ＡＣＫハンドシェイクの一部として、以下の全てのオプションを必要とする：
‐RANDOM： [IETF RFC 4895］で定義されている
‐CHUNKS： [IETF RFC 4895］で定義されている、許可されたチャンクのリスト
‐HMAC-ALGO： [IETF RFC 4895］で定義されている
‐ADAPTATION-LAYER-INDICATION： [IETF RFC 5061］で定義されている
‐RANDOM： [IETF RFC 4895］で定義されている
‐CHUNKS： [IETF RFC 4895］で定義されている、許可されたチャンクのリスト
‐HMAC-ALGO： [IETF RFC 4895］で定義されている
‐ADAPTATION-LAYER-INDICATION： [IETF RFC 5061］で定義されている
【0119】
上記の全てのオプションが存在する場合、アソシエーションは、ＤＴＬＳ／ＳＣＴＰのサポートから開始する。示されているオプションのセットは、ＤＴＬＳ／ＳＣＴＰ必須オプションである。ＤＴＬＳハンドシェイクが完了する前にはデータ転送は許可されない。チャンクバンドリングは、［[IETF RFC 4960］に従って許可される。ＤＴＬＳハンドシェイクは、両方のピアの認証を可能にするとともに、更に、それらのサポートメッセージサイズを宣言する。
【0120】
他のオプション又は代替技術が実装されうることが理解されるべきである。上記のオプションが存在する場合、アソシエーションは、ノード３２０がシグナリングを開始することから始まる。ＩＮＩＴ Ｓ３０１におけるＤＴＬＳサポートインジケーション（又は同様の代替のもの）は、ノード３２０が拡張ＤＴＬＳ／ＳＣＴＰをサポートすることをノード３１０に通知する。いくつかの実施形態では、ＤＴＬＳサポートインジケーションは、ＤＴＬＳ／ＳＣＴＰ機能を示す値を有するアダプテーション層インジケーション（Adaptation-Layer-Indication）である。ＤＴＬＳハンドシェイクが完了する前にはデータ転送は許可されない。ＤＴＬＳハンドシェイクの前に受信されたデータチャンクは、サイレントに破棄されうる。チャンクバンドリングは、IETF RFC 4960に従って許可される。ＤＴＬＳハンドシェイクは、両方のピアの認証を可能にするとともに、それらのサポートされるメッセージサイズも有する。
【0121】
ＳＣＴＰクライアントノード３２０がアソシエーションＳ３０１を開始すると、DTLS-Supportedインジケーションは、クライアントが拡張ＤＴＬＳ／ＳＣＴＰオプションをサポートしていることをノード３１０にシグナリングし、、DTLS-Supportedは更に、それが受信することができるメッセージのサイズ、又は代替的には、それが受信することができるＤＴＬＳフラグメントの数をインジケーションしうる。種々のファクタによって、受信できるメッセージサイズ又はフラグメントの数が制限されうる。それに応じて、サーバノード３１０は、拡張ＤＴＬＳ／ＳＣＴＰオプションも含むＩＮＩＴ－ＡＣＫ Ｓ３０２を送信することで、ノード３１０が、拡張が可能であり、かつ、単一のＤＴＬＳセグメントのみのレガシー使用に格下げされないことを示す。いくつかの実施形態では、DTLS-Supportedは、拡張ＤＴＬＳ／ＳＣＴＰを実装する能力に関連する情報のみを含みうる。その場合、メッセージ／フラグメントサイズに関する情報は、後述するように、後のハンドシェイク信号において交換されうる。DTLS-Supportedシグナリングは、２つのノード間の転送のための他の情報も同様に含みうる。
【0122】
ノード３２０は、拡張ＤＴＬＳ／ＳＣＴＰオプションも含むＩＮＩＴ－ＡＣＫ Ｓ３０２を送信することで、ノード３１０が、拡張が可能であり、かつ、単一のＤＴＬＳセグメントのみのレガシー使用に格下げされないことを示しうる。「オプション」との用語は、いくつかの実施形態ではレガシー技術又は拡張技術を使用するオプションが存在するインスタンスを指す。いくつかの実施形態では、拡張技術は必須要件とされうる。ノード３１０が、拡張ＤＴＬＳ／ＳＣＴＰオプションを含まないＩＮＩＴ－ＡＣＫで応答する場合、ノード３２０は、レガシーIETF RFC 6083（例えば、単一ＤＴＬＳ）で動作し続けること、プレーンデータのみで動作し続けること、又はアソシエーションを中止することを決定しうる。
【0123】
ノード３１０（例えば、ＳＣＴＰサーバ）は、拡張ＤＴＬＳ／ＳＣＴＰをサポートする場合、ＤＴＬＳ／ＳＣＴＰオプションを有するＩＮＩＴシグナリングＳ３０１を受信すると、拡張ＤＴＬＳ／ＳＣＴＰオプションも含むＩＮＩＴ－ＡＣＫシグナリングＳ３０２で応答することで、ノード３１０が拡張ＤＴＬＳ／ＳＣＴＰを送信できることを示しうる。ノード３１０は、ＤＴＬＳ初期化のためのシーケンス及び関連するトラフィックケースに従いうる。SCTP COOKIE-ECHO S３０３及びCOOKIE-ACK S３０４シグナリングの転送後、ノード３２０は、ＤＴＬＳハンドシェイクＳ３０５を送信することで、ＤＴＬＳ転送を開始する。それに応じて、ノード３１０は、Ｓ３０６において、ノード３２０によってインジケーションされたサイズ制限に基づいて、拡張ＤＴＬＳ／ＳＣＴＰでメッセージを送信する。
【0124】
上記のように、いくつかの実施形態では、ノード３２０が受信することができるメッセージサイズ又はフラグメントの数のシグナリングが、Ｓ３０１においてDTLS-Supportedインジケーションとともに含まれうる。しかしながら、いくつかの実施形態では、この情報は、DTLS-Supportedに代えて、ＤＴＬＳハンドシェイクＳ３０５のイニシエーション中に送信されうる。更に、他の実施形態は、他のシグナリングにおいてこの情報を提供しうる。
【0125】
５．３ クライアントユースケース
クライアントがＤＴＬＳ保護を伴うＳＣＴＰアソシエーション、即ち、ＤＴＳＬ／ＳＣＴＰ必須オプションを含むＳＣＴＰ ＩＮＩＴを開始する場合、クライアントはＤＴＬＳ／ＳＣＴＰ必須オプションも含むＩＮＩＴ－ＡＣＫを受信することができ、その場合、アソシエーションは前のセクション５．２で規定されるように進む。ピアが、全てのＤＴＬＳ／ＳＣＴＰ必須オプションを含まないＩＮＩＴ－ＡＣＫで応答する場合、クライアントは、SCTP ABORTで応答するべきである（SHOULD）。
クライアントがＤＴＬＳ保護を伴うＳＣＴＰアソシエーション、即ち、ＤＴＳＬ／ＳＣＴＰ必須オプションを含むＳＣＴＰ ＩＮＩＴを開始する場合、クライアントはＤＴＬＳ／ＳＣＴＰ必須オプションも含むＩＮＩＴ－ＡＣＫを受信することができ、その場合、アソシエーションは前のセクション５．２で規定されるように進む。ピアが、全てのＤＴＬＳ／ＳＣＴＰ必須オプションを含まないＩＮＩＴ－ＡＣＫで応答する場合、クライアントは、SCTP ABORTで応答するべきである（SHOULD）。
【0126】
５．４． サーバのユースケース
ＳＣＴＰサーバがＤＴＬＳ／ＳＣＴＰをサポートする場合、即ち、この明細書によれば、全てのＤＴＬＳ／ＳＣＴＰ必須オプションを有するＩＮＩＴチャンクを受信するとき、ＤＴＬＳ初期化セクション５．２のシーケンス及び関連するトラフィックケースに続いて、全てのＤＴＬＳ／ＳＣＴＰ必須オプションも含むＩＮＩＴ－ＡＣＫで応答する。ＤＴＬＳをサポートし、かつ、それを使用するように構成されたＳＣＴＰサーバが、全てのＤＴＬＳ／ＳＣＴＰ必須オプション無しのＩＮＩＴチャンクを受信する場合、ＳＣＴＰ ABORTで応答するべきである（SHOULD）。
ＳＣＴＰサーバがＤＴＬＳ／ＳＣＴＰをサポートする場合、即ち、この明細書によれば、全てのＤＴＬＳ／ＳＣＴＰ必須オプションを有するＩＮＩＴチャンクを受信するとき、ＤＴＬＳ初期化セクション５．２のシーケンス及び関連するトラフィックケースに続いて、全てのＤＴＬＳ／ＳＣＴＰ必須オプションも含むＩＮＩＴ－ＡＣＫで応答する。ＤＴＬＳをサポートし、かつ、それを使用するように構成されたＳＣＴＰサーバが、全てのＤＴＬＳ／ＳＣＴＰ必須オプション無しのＩＮＩＴチャンクを受信する場合、ＳＣＴＰ ABORTで応答するべきである（SHOULD）。
【0127】
５．５ IETF RFC 6083フォールバック
このセクションでは、この明細書をサポートするエンドポイントが、IETF RFC 6083のＤＴＬＳ／ＳＣＴＰ動作にフォールバックする方法について説明する。フォールバックを許可するか否かを示す設定を定義することが推奨される。しかしながら、フォールバックを使用する可能性は、ＵＬＰが１６３８４バイト以下のユーザメッセージを使用して動作することができ、セキュリティ問題が緩和されうるか又は許容可能と見なされうることに基づく。
このセクションでは、この明細書をサポートするエンドポイントが、IETF RFC 6083のＤＴＬＳ／ＳＣＴＰ動作にフォールバックする方法について説明する。フォールバックを許可するか否かを示す設定を定義することが推奨される。しかしながら、フォールバックを使用する可能性は、ＵＬＰが１６３８４バイト以下のユーザメッセージを使用して動作することができ、セキュリティ問題が緩和されうるか又は許容可能と見なされうることに基づく。
【0128】
considered acceptable.フォールバックは、ＤＴＬＳのより弱いアルゴリズム及びバージョンへのダウングレードを可能にするため、有効にすることが推奨されない（NOT RECOMMENDED）。
【0129】
ＤＴＬＳ／ＳＣＴＰアダプテーション層コードポイントを有するＳＣＴＰアダプテーションインジケーションパラメータを含まないＩＮＩＴチャンク又はＩＮＩＴ－ＡＣＫチャンクを受信するＳＣＴＰエンドポイント（セクション７．２を参照）は、あるケースでは、IETF RFC 6083の挙動へのフォールバックを潜在的に実行しうる。ただし、フォールバックの試行は、ポリシーがそれを受け入れ可能であると述べている場合にのみ実行される必要がある。
【0130】
フォールバックが許可される場合、クライアントは、IETF RFC 6083に従って許可されるように、ＤＴＬＳハンドシェイクの前にプレーンテキストユーザメッセージを送信することが可能である。そのため、それは、フォールバックを許可するポリシーの留意事項の一部とされる必要がある。
【0131】
６． ソケットＡＰＩの留意事項
このセクションでは、［IETF RFC6458］で定義されたソケットＡＰＩを、ＡＵＴＨチャンクの送受信に使用されるＨＭＡＣアルゴリズムをアプリケーションが観察する方法を提供するためにどのように拡張するかについて説明する。
このセクションでは、［IETF RFC6458］で定義されたソケットＡＰＩを、ＡＵＴＨチャンクの送受信に使用されるＨＭＡＣアルゴリズムをアプリケーションが観察する方法を提供するためにどのように拡張するかについて説明する。
【0132】
このセクションは、情報提供のみを目的としている。
【0133】
［IETF RFC 6458］に基づくソケットＡＰＩ実装は、既存のSCTP_AUTHENTICATION_EVENTイベントによって、受信されたＡＵＴＨチャンクにおいて新たなＨＭＡＣアルゴリズムが使用される場合にはいつでもイベント通知を提供するように拡張される。
【0134】
更に、レベルIPPROTO_SCTPと、名称SCTP_SEND_HMAC_IDENT及びSCTP_EXPOSE_HMAC_IDENT_CHANGESとのための２つの新たなソケットオプションが、以下で説明されるように定義される。第１のソケットオプションは、ＡＵＴＨチャンクを送信するために使用されるＨＭＡＣアルゴリズムを問い合わせるために使用される。第２のソケットオプションは、SCTP_AUTHENTICATION_EVENTイベントを介して受信されたＡＵＴＨ チャンクで使用されるＨＭＡＣアルゴリズムのモニタリングを有効にする。
【0135】
SCTP_SEND_HMAC_IDENT及びSCTP_EXPOSE_HMAC_IDENT_CHANGESソケットオプションのサポートも、関数sctp_opt_info()に追加される必要がある。
【0136】
６．１． 送信されるＨＭＡＣ識別子を取得するソケットオプション（SCTP_SEND_HMAC_IDENT）
ＳＣＴＰアソシエーション確立中に、ＡＵＴＨチャンクを送信する場合にＳＣＴＰエンドポイントによって使用されるＨＭＡＣ識別子が選択される。
ＳＣＴＰアソシエーション確立中に、ＡＵＴＨチャンクを送信する場合にＳＣＴＰエンドポイントによって使用されるＨＭＡＣ識別子が選択される。
【0137】
アプリケーションは、レベルIPPROTO_SCTP及び名称SCTP_SEND_HMAC_IDENT.Devicesを使用する、この読み出し専用のソケットオプションを使用することによって、この選択の結果にアクセスできる。
【0138】
以下の構成は、ＡＵＴＨチャンクを送信するために使用されるＨＭＡＣ識別子にアクセスするために使用される：
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
【0139】
assoc_id： このパラメータは、１対１スタイルのソケットでは無視される。
【0140】
１対多スタイルのソケットの場合、アプリケーションは、アソシエーション識別子を入力する。assoc_idにおいてSCTP_{FUTURE|CURRENT|ALL}_ASSOCを使用することは誤りである。
【0141】
assoc_value： このパラメータは、ＡＵＴＨチャンクを送信するために使用されるＨＭＡＣ識別子を含む。
【0142】
６．２． 受信されるＨＭＡＣ識別子の公開
［IETF RFC 6458］のセクション６．１．８は、SCTP_AUTHENTICATION_EVENTイベントを定義し、これは以下の構造を使用する：
struct sctp_authkey_event {
uint16_t auth_type;
uint16_t auth_flags;
uint32_t auth_length;
uint16_t auth_keynumber;
uint32_t auth_indication;
sctp_assoc_t auth_assoc_id;
};
［IETF RFC 6458］のセクション６．１．８は、SCTP_AUTHENTICATION_EVENTイベントを定義し、これは以下の構造を使用する：
struct sctp_authkey_event {
uint16_t auth_type;
uint16_t auth_flags;
uint32_t auth_length;
uint16_t auth_keynumber;
uint32_t auth_indication;
sctp_assoc_t auth_assoc_id;
};
【0143】
本明細書は、
struct sctp_authkey_event {
uint16_t auth_type;
uint16_t auth_flags;
uint32_t auth_length;
uint16_t auth_identifier; /* 以前のauth_keynumber */
uint32_t auth_indication;
sctp_assoc_t auth_assoc_id;
};
に対して、auth_keynumberをauth_identifierに名称変更することによって、この構造を更新する。auth_keynumberをauth_identifierに名称変更すると、auth_identifierは、単に［IETF RFC 6458］のコンテキストでauth_keynumberを置き換える。それに加えて、SCTP_AUTHENTICATION_EVENTイベントは更に、新たなＨＭＡＣ識別子がいつ受信されるかを示すように拡張され、そのような報告は、セクション６．３に記載のように明示的に有効化される。この場合、auth_indicationは、SCTP_AUTH_NEW_HMACであり、新たなＨＭＡＣ識別子はauth_identifierで報告される。
struct sctp_authkey_event {
uint16_t auth_type;
uint16_t auth_flags;
uint32_t auth_length;
uint16_t auth_identifier; /* 以前のauth_keynumber */
uint32_t auth_indication;
sctp_assoc_t auth_assoc_id;
};
に対して、auth_keynumberをauth_identifierに名称変更することによって、この構造を更新する。auth_keynumberをauth_identifierに名称変更すると、auth_identifierは、単に［IETF RFC 6458］のコンテキストでauth_keynumberを置き換える。それに加えて、SCTP_AUTHENTICATION_EVENTイベントは更に、新たなＨＭＡＣ識別子がいつ受信されるかを示すように拡張され、そのような報告は、セクション６．３に記載のように明示的に有効化される。この場合、auth_indicationは、SCTP_AUTH_NEW_HMACであり、新たなＨＭＡＣ識別子はauth_identifierで報告される。
【0144】
６．３． ＨＭＡＣ識別子の使用を公開するソケットオプション（SCTP_EXPOSE_HMAC_IDENT_CHANGES）
このオプションを使用すると、アプリケーションが、ＡＵＴＨチャンクで新たなＨＭＡＣ 識別子を受信された場合に、SCTP_AUTHENTICATION_EVENTイベントの受信を有効化又は無効化することが可能になる（セクション６．２を参照）。
このオプションを使用すると、アプリケーションが、ＡＵＴＨチャンクで新たなＨＭＡＣ 識別子を受信された場合に、SCTP_AUTHENTICATION_EVENTイベントの受信を有効化又は無効化することが可能になる（セクション６．２を参照）。
【0145】
この読み書きソケットオプションは、レベルIPPROTO_SCTPと名称SCTP_EXPOSE_HMAC_IDENT_CHANGESとを使用する。後方互換性を提供する必要があり、デフォルトではこれらのイベントは報告されない。
【0146】
以下の構造は、ＡＵＴＨチャンクで新たに受信されたＨＭＡＣ識別子の報告を有効化又は無効化するために使用される：
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
【0147】
assoc_id： このパラメータは、１対１スタイルのソケットに対して無視される。
【0148】
１対多スタイルソケットの場合、アプリケーションは、アソシエーション識別子又はSCTP_{FUTURE|CURRENT|ALL}_ASSOCを入力しうる。
【0149】
assoc_value： 新たに受信したＨＭＡＣ識別子は、このパラメータがゼロ以外の場合に、及びその場合にのみ報告される。
【0150】
７． ＩＡＮＡの留意事項
７．１． ＴＬＳエクスポータラベル
IETF RFC 6083は、[IETF RFC 5705］に記載のようにＴＬＳエクスポータラベルレジストリを定義した。ＩＡＮＡは、この仕様へのラベル「EXPORTER_DTLS_OVER_SCTP」のリファレンスを更新するように要求される。
７．１． ＴＬＳエクスポータラベル
IETF RFC 6083は、[IETF RFC 5705］に記載のようにＴＬＳエクスポータラベルレジストリを定義した。ＩＡＮＡは、この仕様へのラベル「EXPORTER_DTLS_OVER_SCTP」のリファレンスを更新するように要求される。
【0151】
７．２． ＳＣＴＰアダプテーション層インジケーションコードポイント
［IETF RFC 5061］は、アダプテーション層インジケーションパラメータで使用されるアダプテーションコードポイントのためのＩＡＮＡレジストリを定義した。
［IETF RFC 5061］は、アダプテーション層インジケーションパラメータで使用されるアダプテーションコードポイントのためのＩＡＮＡレジストリを定義した。
【0152】
８． セキュリティの留意事項
［I-D.ietf-tls-dtls13］、[IETF RFC 4895］、及びIETF RFC 4960］において与えられているセキュリティの留意事項も、この文書に適用される。
［I-D.ietf-tls-dtls13］、[IETF RFC 4895］、及びIETF RFC 4960］において与えられているセキュリティの留意事項も、この文書に適用される。
【0153】
８．１． 暗号化の留意事項
長年にわたって、最も一般的に使用される暗号及び動作のモードに対する攻撃を含む、トランスポート層セキュリティ（ＴＬＳ）の以前のバージョンに対するいくつかの深刻な攻撃があった。［IETF RFC 7457］は、公開時に知られていた攻撃を要約し、ＢＣＰ １９５［IETF RFC 7525]［IETF RFC 8996］は、ＴＬＳを使用する、展開されたサービスのセキュリティを改善するための推奨事項を提供する。
長年にわたって、最も一般的に使用される暗号及び動作のモードに対する攻撃を含む、トランスポート層セキュリティ（ＴＬＳ）の以前のバージョンに対するいくつかの深刻な攻撃があった。［IETF RFC 7457］は、公開時に知られていた攻撃を要約し、ＢＣＰ １９５［IETF RFC 7525]［IETF RFC 8996］は、ＴＬＳを使用する、展開されたサービスのセキュリティを改善するための推奨事項を提供する。
【0154】
ＤＴＬＳ １．２［IETF RFC 6347］でＤＴＬＳ／ＳＣＴＰが使用される場合、ＤＴＬＳ １．２は、不十分なセキュリティを提供することが知られているオプションを無効にするように構成されなければならない（MUST）。
【0155】
ＨＴＴＰ／２［IETF RFC 7540］は、２０１５年に公に知られた攻撃に基づいて、良好な最低限の要件を与えている。ＤＴＬＳ １．３［I-D.ietf-tls-dtls13］は、公開時に主要な弱点を有しない強力なアルゴリズムを定義するのみである。ＴＬＳレジストの多くは、「推奨された」列（column）を有する。
【0156】
「Ｙ」とマークされていないパラメータは、サポートすることが推奨されない（NOT RECOMMENDED）。ＤＴＬＳ １．３は、既知の脆弱性に対処し、かつ、公開時に既知の主要な弱点を有しない強力なアルゴリズムのみを定義する、より新しいプロトコルであることが好ましい。
【0157】
ＤＴＬＳ １．３は、アルゴリズム固有のＡＥＡＤ限界に達する前に、再キーイングを必要とする。ＡＥＡＤ限界式は、ＤＴＬＳ １．２に対しても等しく有効であり、ＤＴＬＳ／ＳＣＴＰに対しては従うべきであるが（SHOULD）、ＤＴＬＳ １．２仕様によって必須とされていない。
【0158】
ＳＣＴＰ－ＡＵＴＨで使用されるＨＭＡＣ－ＳＨＡ－２５６は、非常に大きいタグ長及び非常に良好な完全性特性を有する。ＳＣＴＰ－ＡＵＴＨキーは、ＴＬＳレコード層の現在のアルゴリズムよりも長く使用されうる。ＳＣＴＰ－ＡＵＴＨキーは、ＴＬＳエクスポータを使用して新たなＳＣＴＰ－ＡＵＴＨキーが導出される時点で新たなコネクションがセットアップされる場合に、再キーイングされる。
【0159】
ＤＴＬＳ／ＳＣＴＰは、ＩＰｓｅｃに代わって多くの導入が進んでいる。ＩＰｓｅｃについては、ＮＩＳＴ（ＵＳ）、ＢＳＩ（ドイツ）、及びＡＮＳＳＩ（フランス）は、Diffie-Hellmanを頻繁に再実行することで、完全前方秘匿性（Perfect Forward Secrecy）を提供し、かつ、攻撃者に動的キー抽出を強制することを推奨している。ＡＮＳＳＩは、「キー漏洩の影響を抑えるために、キーの定期的な更新（例えば、１時間ごと、及び１００ＧＢのデータごと）を強制することが推奨される。」と記述している［ANSSI-DAT-NT-003］。
【0160】
多くのＤＴＬＳ／ＳＣＴＰ展開では、ＤＴＬＳコネクションは数ヶ月又は数年の非常に長い存続期間を有することが期待される。そのような長い存続期間を有するコネクションについては、クライアントとサーバとの両方を頻繁に再認証する必要がある。ＴＬＳ証明書の存続期間は、１年未満が一般的であるが、これは多くの予想されるＤＴＬＳ／ＳＣＴＰアソシエーションよりも短い。
【0161】
ＳＣＴＰ－ＡＵＴＨの再キーイング、両方のエンドポイントの定期的な認証、及び攻撃者に動的キー抽出を強制するためのDiffie-Hellmanの頻繁な再実行は、同じＳＣＴＰアソシエーション上で新たなＤＴＬＳコネクションをセットアップすることによって達成される、本明細書によるＤＴＬＳ／ＳＣＴＰにおけるものである。実装は、攻撃者に動的キー抽出を強制するために、頻繁に新たなコネクションをセットアップすべきである（SHOULD）。実装は、証明書のいずれかが失効する前に新たなコネクションをセットアップしなければならない（MUST）。証明書が新しい場合、当該証明書におけるタイムスタンプを除き、ネゴシエーション及び交換された全てのパラメータは同じであることが推奨される（RECOMMENDED）。いくつかのパラメータは、典型的には、乱数及びコネクションｉｄ等、新たなハンドシェイクにおいて変更されることに留意されたい。一部のパラメータは、典型的には、シリアル番号等、新たな証明書で変更されることに留意されたい。クライアントとサーバは、新たなコネクションのセットアップ中にアイデンティティの変更を受け入れてはならないが（MUST NOT）、より強力なアルゴリズム及びセキュリティパラメータのネゴシエーションを受け入れてもよく（MAY）、これは新たな攻撃によって動機づけられうる。
【0162】
ＤＴＬＳ １．２［IETF RFC 6347］を使用する場合、ＡＥＡＤ限界、頻繁な再認証、及びDiffie-Hellmanの頻繁な再実行も、再ネゴシエーションで実現されうる（ＴＬＳ １．２［IETF RFC 5246］を参照）。再ネゴシエーションが使用される場合、クライアントとサーバの両方は、再ネゴシエーション情報（renegotiation_info）拡張［IETF RFC 5746］を使用しなければならず（MUST）、ＢＣＰ １９５［IETF RFC 7525］の再ネゴシエーションガイドラインに従わなければならない（MUST）。特に、クライアントとサーバの両方は、再ネゴシエーション中にアイデンティティの変更を受け入れてはならない（MUST NOT）。多くのＤＴＬＳ実装では、デフォルトで再ネゴシエーションは無効化されている。再ネゴシエーションがexporter_secretを更新する間に、本明細書によるＤＴＬＳ／ＳＣＴＰは、新たなコネクションがセットアップされた場合に新たなＳＣＴＰ－ＡＵＴＨキーを導出するだけである。
【0163】
ＤＴＬＳ １．３では、再ネゴシエーションは、ＤＴＬＳ １．３から削除され、一部はPost-Handshake KeyUpdate（ハンドシェイク後のKeyUpdate）に置き換えられた。ＤＴＬＳ １．３ ［I-D.ietf-tls-dtls13］を使用する場合、ＡＥＡＤ限界（AEAD limits）は、頻繁なハンドシェイク後のKeyUpdateメッセージを送信することによっても実現できる。
【0164】
対称再キーイングは、Diffie-Hellmanを再実行するよりも、キー漏洩に対する保護が大幅に低くなる。application_traffic_secret_Nの漏洩後、パッシブ攻撃者は、
【0165】
application_traffic_secret_N+1、application_traffic_secret_N+2等で暗号化されたアプリケーションデータを含む、コネクション上で送信された全ての将来のアプリケーションデータをパッシブに傍受しうる。
【0166】
KeyUpdateはexporter_secretを更新しないことに留意されたい。
【0167】
クライアントが開始した再ネゴシエーション及びクライアントが開始した新しいコネクションを許可することで、サービス拒否攻撃を有効にすることができる。サーバは、クライアントが開始した再ネゴシエーションと新たなコネクションの頻度を制限する必要がある。
【0168】
ＤＴＬＳ １．２［IETF RFC 6347］でＤＴＬＳ／ＳＣＴＰが使用される場合、攻撃者が複数のコネクションで同じキーを確立する未知のキー共有攻撃を防ぐために、ＴＬＳセッションハッシュと拡張マスターシークレット拡張［IETF RFC 7627］とが使用されなければならない（MUST）。ＤＴＬＳ １．３は、常にこれらの種類の攻撃を防ぐ。ＳＣＴＰ－ＡＵＴＨの使用により、新たなコネクションが古いコネクションに暗号でバインドされる。これは、（ＤＴＬＳ層上の）強制的な相互認証と、新たなアイデンティティを受け入れないという要件と共に、再ネゴシエーション［3SHAKE］が悩まされたＭＩＴＭ攻撃を軽減する。
【0169】
８．２． ダウングレード攻撃
本明細書によるＤＴＬＳ／ＳＣＴＰ、［IETF RFC 6083］によるＤＴＬＳ／ＳＣＴＰ、及び／又はＤＴＬＳ無しのＳＣＴＰをサポートするピアは、オンパス攻撃者がセキュリティを低下又は無効化するためにプロトコルセットアップに干渉するダウングレード攻撃に対して脆弱である可能性がある。可能な場合には、ピアは、本明細書によるＤＴＬＳ／ＳＣＴＰのみを許可するポリシーを有することが推奨される（RECOMMENDED）。
本明細書によるＤＴＬＳ／ＳＣＴＰ、［IETF RFC 6083］によるＤＴＬＳ／ＳＣＴＰ、及び／又はＤＴＬＳ無しのＳＣＴＰをサポートするピアは、オンパス攻撃者がセキュリティを低下又は無効化するためにプロトコルセットアップに干渉するダウングレード攻撃に対して脆弱である可能性がある。可能な場合には、ピアは、本明細書によるＤＴＬＳ／ＳＣＴＰのみを許可するポリシーを有することが推奨される（RECOMMENDED）。
【0170】
８．３． 認証及びポリシーの決定
ＤＴＬＳ／ＳＣＴＰは、相互に認証されなければならない（MUST）。ＤＴＬＳ／ＳＣＴＰが証明書ベースの認証で使用されることが推奨される（RECOMMENDED）。全てのセキュリティ決定は、そのトランスポート層アイデンティティではなく、ピアの認証されたアイデンティティに基づいていなければならない（MUST）。
ＤＴＬＳ／ＳＣＴＰは、相互に認証されなければならない（MUST）。ＤＴＬＳ／ＳＣＴＰが証明書ベースの認証で使用されることが推奨される（RECOMMENDED）。全てのセキュリティ決定は、そのトランスポート層アイデンティティではなく、ピアの認証されたアイデンティティに基づいていなければならない（MUST）。
【0171】
証明書におけるＩＰ アドレスに基づいてＤＴＬＳ エンドポイントを認証することが可能である。ＳＣＴＰアソシエーションは、ＳＣＴＰ エンドポイントごとに複数のＩＰアドレスを使用できる。したがって、ＤＴＬＳレコードは、最初に認証されたものとは異なる、送信元ＩＰアドレスから、又は異なる宛先ＩＰアドレスへ、送信される可能性がある。これは、送信元ＩＰアドレス又は宛先ＩＰアドレスに基づいてセキュリティ決定が行われない限り、問題にはならない。
【0172】
８．４． プライバシーの留意事項
［IETF RFC 6973］は、ＩＥＴＦプロトコルのプライバシーに関する留意事項を文書化することを提案している。
［IETF RFC 6973］は、ＩＥＴＦプロトコルのプライバシーに関する留意事項を文書化することを提案している。
【0173】
各ＳＣＴＰユーザメッセージについて、ユーザは、ストリーム識別子、メッセージが順序付けられているか順序付けられていないかを示すフラグ、及びペイロードプロトコル識別子も提供する。ＤＴＬＳ／ＳＣＴＰは実際のユーザメッセージに対してプライバシーを提供するが、他の３つの情報フィールドは機密性保護がなされない。これらは、ＳＣＴＰ ＤＡＴＡチャンクヘッダの一部であるため、クリアテキストとして送信される。
【0174】
ＤＴＬＳ／ＳＣＴＰは、アイデンティティ保護を提供するために、ＤＴＬＳ １．３［I-D.ietf-tls-dtls13］における証明書ベースの認証とともに使用されることが推奨される（RECOMMENDED）。ＤＴＬＳ／ＳＣＴＰは、完全前方秘匿性を提供するキー交換方法とともに使用されなければならない（MUST）。完全前方秘匿性は、キー漏洩に起因して漏洩されうるデータの量を大幅に制限する。
【0175】
８．５． パーベイシブ・モニタリング（Pervasive Monitoring）
［IETF RFC 7258］で要求されているように、ＩＥＴＦプロトコルに関する作業は、パーベイシブ・モニタリングの影響を考慮し、かつ、可能な場合にはそれらを軽減する必要がある。
［IETF RFC 7258］で要求されているように、ＩＥＴＦプロトコルに関する作業は、パーベイシブ・モニタリングの影響を考慮し、かつ、可能な場合にはそれらを軽減する必要がある。
【0176】
パーベイシブ・モニタリングは、ユーザの広範な監視である。ユーザアイデンティティを含む、より多くの情報を暗号化することにより、ＤＴＬＳ １．３は、広範なモニタリングに対してはるかに優れた保護を提供する。
【0177】
前方秘匿性なしのキー交換に依存する大規模パーベイシブ・モニタリング攻撃が報告されている。完全前方秘匿性を必須にすることによって、ＤＴＬＳ／ＳＣＴＰは、多くの形態のパッシブ・パーベイシブ・モニタリングを効果的に軽減し、キー漏洩に起因して漏洩するデータの量を制限する。
【0178】
パーベイシブ・モニタリングの重要な軽減は、静的キー抽出に代えて動的キー抽出の実行を強制することである。動的キー抽出は、攻撃者の発見のリスクを増加させる［IETF RFC 7624］。本明細書によるＤＴＬＳ／ＳＣＴＰは、動的キー抽出を攻撃者に強制するために、同じＳＣＴＰアソシエーション上で新たなＤＴＬＳコネクションを頻繁にセットアップすることを、実装に奨励する。
【0179】
上述のプライバシー攻撃に加えて、大規模な監視は、より広い地理的エリアで、及び異なるアクセスネットワークにわたって、ユーザの追跡を可能にしうる。ＤＴＬＳ／ＳＣＴＰからの情報を、他のプロトコルから収集された情報とともに使用することにより、個々のユーザを識別するリスクが増加する。
【0180】
９． 本発明の実施形態の実装
図４は、いくつかの実施形態による、ＳＣＴＰアソシエーション上で並列のＤＴＬＳコネクションを実装するネットワークノードを示す。ネットワークノード４０２は、プロセッサ及び専用オペレーティングシステム（ＯＳ）、又はコモン・オフ・ザ・シェルフ（ＣＯＴＳ：common off-the-shelf）プロセッサ及び標準ＯＳとして、カスタム特定用途向け集積回路（ＡＳＩＣ）を使用して実装されうる。
図４は、いくつかの実施形態による、ＳＣＴＰアソシエーション上で並列のＤＴＬＳコネクションを実装するネットワークノードを示す。ネットワークノード４０２は、プロセッサ及び専用オペレーティングシステム（ＯＳ）、又はコモン・オフ・ザ・シェルフ（ＣＯＴＳ：common off-the-shelf）プロセッサ及び標準ＯＳとして、カスタム特定用途向け集積回路（ＡＳＩＣ）を使用して実装されうる。
【0181】
ネットワークノード４０２は、（典型的にはＣＯＴＳプロセッサ又はプロセッサコア又はＡＳＩＣである）１つ以上のプロセッサ４４２及び物理ＮＩ４４６のセットを備えるハードウェア４４０と、内部に格納されたソフトウェア４５０を有する非一時的なマシン読取可能記憶媒体４４９とを含む。動作中、１つ以上のプロセッサ４４２は、ソフトウェア４５０を実行することで、１つ以上のアプリケーション４６４Ａ～Ｒのうちの１つ以上のセットをインスタンス化しうる。一実施形態は仮想化を実装しないが、代替の実施形態は異なる形態の仮想化を使用しうる。例えば、１つのそのような代替の実施形態では、仮想化レイヤ４５４は、アプリケーション４６４Ａ～Ｒのセットのうちの１つ（又は複数）を実行するためにそれぞれ使用されうるソフトウェアコンテナと称される複数のインスタンス４６２Ａ～Ｒの作成を可能にする、オペレーティングシステム（又は基本オペレーティングシステム上で実行されるシム）のカーネルを表す。複数のソフトウェアコンテナ（仮想化エンジン、仮想プライベートサーバ、又はジェイルとも称される）は、オペレーティングシステムが実行されるカーネルスペースとは別個の、ユーザスペース（典型的には仮想メモリスペース）である。所与のユーザ空間で実行されているアプリケーションのセットは、明示的に許可されていない限り、他のプロセスのメモリにアクセスできない。別のそのような代替の実施形態では、仮想化レイヤ４５４は、ハイパーバイザ（仮想マシンモニタ（ＶＭＭ）と称されることもある）又はホストオペレーティングシステムの上で実行されるハイパーバイザを表し、アプリケーション４６４Ａ～Ｒのセットの各々は、ハイパーバイザの上で実行される仮想マシン４６２Ａ～Ｒと称されるインスタンス内のゲストオペレーティングシステムの上で実行され（場合によってはソフトウェアコンテナの厳密に隔離された形態とみなされうる）‐ ゲストオペレーティングシステム及びアプリケーションは、「ベアメタル」ホスト電子デバイス上で実行されるのとは対照的に、仮想マシン上で実行されることを知らない可能性があり、または、準仮想化によって、オペレーティングシステム及び／又はアプリケーションは、最適化の目的で仮想化の存在を認識する可能性がある。更に他の代替の実施形態では、アプリケーションのうちの１つ、一部又は全部は、（１つ以上の）ユニカーネルとして実装され、ユニカーネルは、アプリケーションによって必要とされる特定のＯＳサービスを提供する（例えば、ＯＳサービスのドライバ／ライブラリを含むライブラリオペレーティングシステム（ＬｉｂＯＳ）からの）限られたライブラリのセットのみを用いてアプリケーションを直接コンパイルすることによって生成されうる。ユニカーネルは、ハードウェア４４０上で直接、ハイパーバイザ上で直接（この場合、ユニカーネルは時にはＬｉｂＯＳ仮想マシン内で実行されるものとして説明される）、又はソフトウェアコンテナ内で実行されるように実装されうるため、実施形態は、仮想化レイヤ４５４によって表されるハイパーバイザ上で直接実行されるユニカーネル、インスタンス４６２Ａ～Ｒによって表されるソフトウェアコンテナ内で実行されるユニカーネル、ま又はユニカーネルと上述の技術の組み合わせとして（例えば、ユニカーネルと仮想マシンの両方がハイパーバイザ上で直接実行される、ユニカーネル、及び異なるソフトウェアコンテナ内で実行されるアプリケーションのセット）、完全に実装されうる。
【0182】
ソフトウェア４５０は、本明細書で上述した動作を実行する、並列ＤＴＬＳコネクションコーディネータ１１２を含む。並列ＤＴＬＳコネクション続コーディネータ１１２は、アプリケーション４６４Ａ～Ｒ内にインスタンス化されうる。１つ以上のアプリケーション４６４Ａ～Ｒののうちの１つ以上のセットのインスタンス化、及び実装される場合の仮想化は、まとめて（１つ以上の）ソフトウェアインスタンス４５２と称される。アプリケーション４６４Ａ～Ｒの各セット、実装される場合の対応する仮想化構築物（例えば、インスタンス４６２Ａ～Ｒ）、及びそれらを実行するハードウェア４４０のその部分（時間的に共有されるハードウェアのその実行及び／又は時間スライスに専用のハードウェアである）は、別個の仮想電子デバイス４６０Ａ～Ｒを形成する。
【0183】
ネットワークインタフェース（ＮＩ）は、物理的又は仮想的でありうる。ＩＰのコンテキストでは、インタフェースアドレスは、ＮＩに割り当てられたＩＰアドレスであり、物理ＮＩ又は仮想ＮＩである。仮想ＮＩは、物理ＮＩと関連付けられるか、別の仮想インタフェースと関連付けられるか、又はそれ自体（例えば、ループバックインタフェース、ポイントツーポイントプロトコルインタフェース）上にありうる。ＮＩ（物理的又は仮想的）は、ナンバリングされていてもよいし（ＩＰアドレスを有するＮＩ）、ナンバリングされていなくてもよい（ＩＰアドレスを有しないＮＩ）。
【0184】
用語
一般に、本明細書で使用される全ての用語は、異なる意味が明確に与えられ、及び／又は、それが使用される文脈から暗示されない限り、関連する技術分野におけるそれらの通常の意味に従って解釈されるべきである。エレメント、装置、コンポーネント、手段、ステップ等へのあらゆる言及は、特に明記しない限り、エレメント、装置、コンポーネント、手段、ステップ等の少なくとも１つのインスタンスを指すものとしてオープンに解釈されるべきである。本明細書に開示される任意の方法のステップは、ステップが別のステップの後又は前として明示的に説明されている場合、及び／又はステップが別のステップの後又は前になければならないことが黙示的でる場合を除き、開示される正確な順序で実行される必要はない。本明細書に開示される実施形態のいずれかの任意の特徴は、適切な場合には、任意の他の実施形態に適用されてもよい。同様に、任意の実施形態の任意の利点は、任意の他の実施形態に適用されることができ、その逆も同様である。包含される実施形態の他の目的、特徴、及び利点は、以下の説明から明らかになる。
一般に、本明細書で使用される全ての用語は、異なる意味が明確に与えられ、及び／又は、それが使用される文脈から暗示されない限り、関連する技術分野におけるそれらの通常の意味に従って解釈されるべきである。エレメント、装置、コンポーネント、手段、ステップ等へのあらゆる言及は、特に明記しない限り、エレメント、装置、コンポーネント、手段、ステップ等の少なくとも１つのインスタンスを指すものとしてオープンに解釈されるべきである。本明細書に開示される任意の方法のステップは、ステップが別のステップの後又は前として明示的に説明されている場合、及び／又はステップが別のステップの後又は前になければならないことが黙示的でる場合を除き、開示される正確な順序で実行される必要はない。本明細書に開示される実施形態のいずれかの任意の特徴は、適切な場合には、任意の他の実施形態に適用されてもよい。同様に、任意の実施形態の任意の利点は、任意の他の実施形態に適用されることができ、その逆も同様である。包含される実施形態の他の目的、特徴、及び利点は、以下の説明から明らかになる。
【0185】
本明細書において、「一実施形態」、「実施形態」、「例示的な実施形態」等への言及は、記載される実施形態が特定の特徴、構造、又は特性を含みうることを示すが、全ての実施形態が必ずしも当該特定の特徴、構造、又は特性を含まなくてもよい。更に、そのようなフレーズは、必ずしも同じ実施形態を参照するものではない。更に、特定の特徴、構造、又は特性が実施形態に関連して説明される場合、明示的に説明されているか否かにかかわらず、他の実施形態に関連してそのような特徴、構造、又は特性に影響を及ぼすことは、当業者の知識の範囲内であると言える。
【0186】
本明細書及び特許請求の範囲は、「結合された（coupled）」及び「接続された（connected）」との用語を、それらの派生語とともに使用することがある。これらの用語は、互いに同義語としては意図されていない。「結合された」は、２つ以上の要素が互いに協働又は相互作用することを示すために使用され、これらは互いに直接物理的又は電気的に接触していてもいなくてもよい。「接続された」は、互いに結合された２つ以上の要素間の無線又は有線通信の確立を示すために使用される。本明細書で使用される「セット」は、１つの項目を含む任意の正の整数の項目を指す。
【0187】
電子デバイスは、マシン読取可能記憶媒体（例えば、磁気ディスク、光ディスク、ソリッドステートドライブ、リードオンリーメモリ（ＲＯＭ）、フラッシュメモリデバイス、相変化メモリ）、及び（キャリアとも称される）マシン読取可能伝送媒体（例えば、電気、光、無線、音響、又は搬送波、赤外線信号等の他の形態の伝搬信号）等のマシン読取可能媒体（コンピュータ読取可能媒体とも呼ばれる）を使用して、（ソフトウェア命令から構成され、コンピュータプログラムコード又はコンピュータプログラムと称されうる）コード及び／又はデータを（内部的に、及び／又はネットワークを介して他の電子デバイスとともに）記憶及び送信する。このため、電子デバイス（例えば、コンピュータ）は、プロセッサのセット上で実行するためのコードを記憶する、及び／又はデータを記憶するための１つ以上のマシン読取可能記憶媒体に結合された、１つ以上のプロセッサのセット（例えば、そのうちの１つが、マイクロプロセッサ、コントローラ、マイクロコントローラ、中央演算処理装置、デジタルシグナルプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、他の電子回路、又は先行のもののうちの１つ以上の組み合わせである）等の、ハードウェア及びソフトウェアを含む。例えば、電子デバイスは、コードを含む不揮発性メモリを含み、これは、電子デバイスが（電源が取り除かれたときに）オフにされた場合であっても不揮発性メモリがコード／データを持続することができるためである。電子デバイスがオンにされると、電子デバイスの（１つ以上の）プロセッサによって実行されるコードのその部分は、典型的には、より遅い不揮発性メモリから電子デバイスの揮発性メモリ（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ））にコピーされる。典型的な電子デバイスは更に、他の電子デバイスとの（伝搬信号を使用してコード及び／又はデータを送信及び／又は受信するための）ネットワークコネクションを確立するための、１つ以上の物理ネットワークインタフェース（ＮＩ）のセットを含む。例えば、物理ＮＩのセット（又はコードを実行するプロセッサのセットと組み合わせた物理ＮＩのセット）は、電子デバイスが有線及び／又は無線コネクション上でデータを送信及び受信することを可能にするために、任意のフォーマット、コーディング、又は変換を実行しうる。いくつかの実施形態では、物理ＮＩは、（１）無線コネクション上で他の電子デバイスからデータを受信すること、及び／又は（２）無線コネクションを通じて他のデバイスにデータを送信すること、を行うことが可能な無線回路を含みうる。この無線回路は、無線周波数通信に適した（１つ以上の）送信機、（１つ以上の）受信機、及び／又は（１つ以上の）トランシーバを含みうる。無線回路は、デジタルデータを、適切なパラメータ（例えば、周波数、タイミング、チャネル、帯域幅等）を有する無線信号に変換しうる。その後、無線信号は、アンテナを通じて適切な（１つ以上の）受信者へ送信されうる。いくつかの実施形態では、（１つ以上の）物理ＮＩのセットは、ネットワークインタフェースコントローラカード、ネットワークアダプタ、又はローカルエリアネットワーク（ＬＡＮ）アダプタとしても知られる、（１つ以上の）ネットワークインタフェースコントローラ（ＮＩＣ）を含みうる。（１つ以上の）ＮＩＣは、電子デバイスを他の電子デバイスに接続することを容易にすることができ、ＮＩＣに接続された物理ポートへのケーブルの差し込みを通して、電子デバイスが有線で通信することを可能にする。本発明の実施形態の１つ以上の部分は、ソフトウェア、ファームウェア、及び／又はハードウェアの異なる組み合わせを使用して実装されうる。
【0188】
ネットワークノード（ネットワークデバイス又は単にノードとも称される）は、ネットワーク上の他の電子デバイス（例えば、他のネットワークデバイス、エンドユーザデバイス）を通信可能に相互接続する電子デバイスである。いくつかのネットワークノードは、複数のネットワーキング機能（例えば、ルーティング、ブリッジング、スイッチング、レイヤ２アグリゲーション、セッション境界制御、サービス品質、及び／又は加入者管理）のサポートを提供する、及び／又は、複数のアプリケーションサービス（例えば、データ、音声、及びビデオ）のサポートを提供する、「マルチサービスネットワークノード（multiple services network nodes）」である。
【0189】
本出願で使用される「モジュール」、「ロジック」、及び「ユニット」との用語は、規定された機能を実行するための回路を指しうる。いくつかの実施形態では、規定された機能は、汎用プロセッサによって実行されるソフトウェアによって等、ソフトウェアと組み合わせて回路によって実行されうる。
【0190】
本明細書で開示される任意の適切なステップ、方法、特徴、機能、又は効果は、１つ以上の仮想装置の１つ以上の機能ユニット又はモジュールを通じて実行されうる。各仮想装置は、いくつかのこれらの機能ユニットを含みうる。これらの機能ユニットは、１つ以上のマイクロプロセッサ又はマイクロコントローラを含みうる処理回路と、デジタルシグナルプロセッサ（ＤＳＰ）、専用デジタルロジック等を含みうる他のデジタルハードウェアを用いて実装されてもよい。処理回路は、メモリに格納されたプログラムコードを実行するように構成されてもよく、当該メモリは、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、キャッシュメモリ、フラッシュメモリデバイス、光ストレージデバイス等の、１つ以上のタイプのメモリを含んでもよい。メモリに格納されたプログラムコードは、１つ以上の遠隔通信及び／又はデータ通信プロトコルを実行するためのプログラム命令と、本明細書で説明される技術のうちの１つ以上を実行するための命令とを含む。いくつかの実装において、処理回路は、本開示の１つ以上の実施形態に従って、個別の機能ユニットに、対応する機能を実行させるために使用されてもよい。
【0191】
ユニットとの用語は、電子機器、電気デバイス、及び／又は電子デバイスの分野において従来の意味を有してもよく、例えば、本明細書で説明されるような、電気回路及び／又は電子回路、デバイス、モジュール、プロセッサ、メモリ、ロジックソリッドステート及び／又はディスクリートデバイス、それぞれのタスク、手順、計算、出力及び／又は表示機能等を実行するためのコンピュータプログラム又は命令を含んでもよい。
【図1】
【図2】
【図3】
【図4】
【手続補正書】
【提出日】2024-06-04
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
第２のネットワークノードへのセキュア伝送のためにユーザメッセージを符号化するための、第１のネットワークノードにおける方法であって、ユーザメッセージを送信するＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上の既存のＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションからの既存のＳＣＴＰ－ＡＵＴＨ（ＳＣＴＰのための認証されたチャンク）キーを使用したＤＴＬＳハンドシェイクを通じて、前記ＳＣＴＰアソシエーション上でＤＴＬＳコネクションを開始すること（２０４）と、
前記開始されたＤＴＬＳコネクションから新規のＳＣＴＰ－ＡＵＴＨキーを導出すること（２０６）と、
前記新規のＳＣＴＰ－ＡＵＴＨキーを用いて、前記開始されたＤＴＬＳコネクションを通じて更なるユーザメッセージを送信すること（２１０）と、
前記既存のＤＴＬＳコネクションで暗号化されたＳＣＴＰパケットと、前記既存のＳＣＴＰ－ＡＵＴＨキーによって認証されたＳＣＴＰパケットとが配信されたことの確認に応じて、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすること（２１２）と、
を含む、方法。
【請求項2】
請求項１に記載の方法であって、前記開始されたＤＬＴＳコネクションによって保護されているが前記既存のＳＣＴＰ－ＡＵＴＨキーで認証されているユーザメッセージの更なる部分を含む、進行中のＳＣＴＰパケットを送信すること（２０８）を更に含む、方法。
【請求項3】
請求項１に記載の方法であって、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすることは、第１のＤＴＬＳコネクションクローズ通知を前記第２のネットワークノードへ送信することを含む、方法。
【請求項4】
請求項１に記載の方法であって、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすることは、第２のＤＴＬＳコネクションクローズ通知を前記第２のネットワークノードから受信することを更に含む、方法。
【請求項5】
請求項３に記載の方法であって、前記第１のＤＴＬＳコネクションクローズ通知を送信することは、前記第１のＤＴＬＳコネクションクローズ通知を送信する前に、前記既存のＤＴＬＳコネクションにおける送信データが非再現可能な方法で前記第２のネットワークノードによって確認応答されたことを確認することを含む、方法。
【請求項6】
請求項１に記載の方法であって、前記既存のＳＣＴＰ－ＡＵＴＨキー及び前記新規のＳＣＴＰ－ＡＵＴＨキーは、対応する既存の及び新規のキー識別子（ＩＤ）によって識別され、前記新規のキー識別子は、前記既存のキー識別子から１だけ増加した値である、方法。
【請求項7】
請求項１に記載の方法であって、前記ＤＴＬＳコネクションは、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションの１つ以上の証明書が失効する前に確立される、方法。
【請求項8】
請求項７に記載の方法であって、前記ＤＴＬＳハンドシェイクを通じて前記ＳＣＴＰアソシエーション上で前記ＤＴＬＳコネクションを開始することは、前記１つ以上の証明書内のタイムスタンプを含む前記既存のＤＴＬＳコネクションの前記１つ以上の証明書を維持することを含む、方法。
【請求項9】
請求項１に記載の方法であって、前記第１のネットワークノードと前記第２のネットワークノードとの間で前記ＤＴＬＳハンドシェイクを実行することは、
前記ＤＴＬＳハンドシェイクを開始し、かつ、前記ＤＴＬＳハンドシェイクのイニシエーションを受信したことに応答して、前記第１のネットワークノードが前記ＤＴＬＳコネクションのＤＴＬＳクライアントとして機能する場合に前記開始されたＤＴＬＳハンドシェイクを継続することを含む、方法。
【請求項10】
請求項１に記載の方法であって、前記既存のＳＣＴＰ－ＡＵＴＨキーは、前記既存のＤＴＬＳコネクションのクローズに応じて削除される、方法。
【請求項11】
ネットワークノード（４０２）であって、プロセッサ（４４２）と、命令を提供する非一時的なマシン読取可能読記憶媒体（４４９）と、を備え、前記命令は、前記プロセッサ（４４２）によって実行されると前記プロセッサ（４４２）に、
ユーザメッセージを送信するＳＣＴＰ（ストリーム制御伝送プロトコル）アソシエーション上の既存のＤＴＬＳ（データグラムトランスポート層セキュリティ）コネクションからの既存のＳＣＴＰ－ＡＵＴＨ（ＳＣＴＰのための認証されたチャンク）キーを使用したＤＴＬＳハンドシェイクを通じて、前記ＳＣＴＰアソシエーション上でＤＴＬＳコネクションを開始すること（２０４）と、
前記開始されたＤＴＬＳコネクションから新規のＳＣＴＰ－ＡＵＴＨキーを導出すること（２０６）と、
前記新規のＳＣＴＰ－ＡＵＴＨキーを用いて、前記開始されたＤＴＬＳコネクションを通じて更なるユーザメッセージを送信すること（２１０）と、
前記既存のＤＴＬＳコネクションで暗号化されたＳＣＴＰパケットと、前記既存のＳＣＴＰ－ＡＵＴＨキーによって認証されたＳＣＴＰパケットとが配信されたことの確認に応じて、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすること（２１２）と、
を実行させることができる、ネットワークノード。
【請求項12】
請求項１１に記載のネットワークノード（４０２）であって、前記非一時的なマシン読取可能読記憶媒体は、前記プロセッサ（４４２）によって実行されると前記プロセッサ（４４２）に、
前記開始されたＤＬＴＳコネクションによって保護されているが前記既存のＳＣＴＰ－ＡＵＴＨキーで認証されているユーザメッセージの更なる部分を含む、進行中のＳＣＴＰパケットを送信すること（２０８）、
を更に実行させることができる命令を提供する、ネットワークノード。
【請求項13】
請求項１１に記載のネットワークノード（４０２）であって、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすることは、第１のＤＴＬＳコネクションクローズ通知を第２のネットワークノードへ送信することを含む、ネットワークノード。
【請求項14】
請求項１１に記載のネットワークノード（４０２）であって、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションをクローズすることは、第２のＤＴＬＳコネクションクローズ通知を第２のネットワークノードから受信することを更に含む、ネットワークノード。
【請求項15】
請求項１３に記載のネットワークノード（４０２）であって、前記第１のＤＴＬＳコネクションクローズ通知を送信することは、前記第１のＤＴＬＳコネクションクローズ通知を送信する前に、前記既存のＤＴＬＳコネクションにおける送信データが非再現可能な方法で前記第２のネットワークノードによって確認応答されたことを確認することを含む、ネットワークノード。
【請求項16】
請求項１１に記載のネットワークノード（４０２）であって、前記既存のＳＣＴＰ－ＡＵＴＨキー及び前記新規のＳＣＴＰ－ＡＵＴＨキーは、対応する既存の及び新規のキー識別子（ＩＤ）によって識別され、前記新規のキー識別子は、前記既存のキー識別子から１だけ増加した値である、ネットワークノード。
【請求項17】
請求項１１に記載のネットワークノード（４０２）であって、前記ＤＴＬＳコネクションは、前記ＳＣＴＰアソシエーション上の前記既存のＤＴＬＳコネクションの１つ以上の証明書が失効する前に確立される、ネットワークノード。
【請求項18】
請求項１７に記載のネットワークノード（４０２）であって、前記ＤＴＬＳハンドシェイクを通じて前記ＳＣＴＰアソシエーション上で前記ＤＴＬＳコネクションを開始することは、前記１つ以上の証明書内のタイムスタンプを含む前記既存のＤＴＬＳコネクションの前記１つ以上の証明書を維持することを含む、ネットワークノード。
【請求項19】
請求項１１に記載のネットワークノード（４０２）であって、前記ネットワークノードと第２のネットワークノードとの間で前記ＤＴＬＳハンドシェイクを実行することは、
前記ＤＴＬＳハンドシェイクを開始し、かつ、前記ＤＴＬＳハンドシェイクのイニシエーションを受信したことに応答して、前記ネットワークノードが前記ＤＴＬＳコネクションのＤＴＬＳクライアントとして機能する場合に前記開始されたＤＴＬＳハンドシェイクを継続することを含む、ネットワークノード。
【請求項20】
請求項１１に記載のネットワークノード（４０２）であって、前記既存のＳＣＴＰ－ＡＵＴＨキーは、前記既存のＤＴＬＳコネクションのクローズに応じて削除される、ネットワークノード。
【請求項21】
非一時的なマシン読取可能記憶媒体（４４９）であって、プロセッサ（４４２）によって実行されると前記プロセッサ（４４２）に、請求項１乃至１０のいずれか一項に記載の方法を実行させることができる命令を提供する、マシン読取可能記憶媒体。
【請求項22】
コンピュータプログラムであって、前記コンピュータプログラムがネットワークノード（４０２）によって実行されると前記ネットワークノードに、請求項１乃至１０のいずれか一項に記載の方法を実行させることができる命令を含む、コンピュータプログラム。
【国際調査報告】