RFC 9150 - TLS 1.3 Authentication and Integrity-Only Cipher Suites (RFC 9150) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9150.html
タイトル : RFC 9150 - TLS 1.3認証と整合性のみの暗号スイート（RFC 9150）
翻訳編集 : 自動生成

[要約] RFC 9150はTLS 1.3認証および完全性のみの暗号スイートに関するもので、セキュアな通信の認証とデータの完全性を保証することを目的としています。この文書は、データの機密性を必要としないが、改ざん防止は必要とする特定の利用場面での使用が想定されています。

Independent Submission                                     N. Cam-Winget
Request for Comments: 9150                                 Cisco Systems
Category: Informational                                        J. Visoky
ISSN: 2070-1721                                                     ODVA
                                                              April 2022

TLS 1.3 Authentication and Integrity-Only Cipher Suites

TLS 1.3認証と整合性のみの暗号スイート

Abstract

概要

This document defines the use of cipher suites for TLS 1.3 based on Hashed Message Authentication Code (HMAC). Using these cipher suites provides server and, optionally, mutual authentication and data authenticity, but not data confidentiality. Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication. This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced-security mechanism that provides authentication and message integrity without supporting confidentiality.

このドキュメントでは、ハッシュされたメッセージ認証コード（HMAC）に基づいて、TLS 1.3の暗号スイートの使用を定義しています。これらの暗号スイートを使用すると、サーバーと、オプションでは相互認証とデータの信頼性が提供されますが、データの機密性は提供されません。これらのプロパティを備えた暗号スイートは一般的な適用性ではありませんが、特にモノのインターネット（IoT）および制約された環境にはユースケースがあります。。このドキュメントには、これらの整合性のみの暗号スイートを使用する前に、手元の状況の脅威モデルが必要であり、そのモデル内で脅威分析を実行する必要があるという警告があり、そのようなユースケースの例を示します。整合性のみの暗号スイートが適切です。このドキュメントで説明されているアプローチはIETFによって承認されておらず、IETFコンセンサスはありませんが、ここでは、機密性をサポートすることなく認証とメッセージの整合性を提供する減少したセキュリティメカニズムの相互運用可能な実装を可能にするために提示されています。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9150.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc9150で入手できます。

著作権表示

著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Applicability Statement
   4.  Cryptographic Negotiation Using Integrity-Only Cipher Suites
   5.  Record Payload Protection for Integrity-Only Cipher Suites
   6.  Key Schedule when Using Integrity-Only Cipher Suites
   7.  Error Alerts
   8.  IANA Considerations
   9.  Security and Privacy Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

There are several use cases in which communications privacy is not strictly needed, although authenticity of the communications transport is still very important. For example, within the industrial automation space, there could be TCP or UDP communications that command a robotic arm to move a certain distance at a certain speed. Without authenticity guarantees, an attacker could modify the packets to change the movement of the robotic arm, potentially causing physical damage. However, the motion control commands are not always considered to be sensitive information, and thus there is no requirement to provide confidentiality. Another Internet of Things (IoT) example with no strong requirement for confidentiality is the reporting of weather information; however, message authenticity is required to ensure integrity of the message.

通信トランスポートの信憑性はまだ非常に重要であるが、通信のプライバシーが厳密に必要とされないいくつかのユースケースがある。例えば、産業用オートメーション空間内では、ある速度である距離を移動するためにロボットアームを指令するTCPまたはUDP通信がある可能性がある。信頼性が保証されていないと、攻撃者は、ロボットアームの動きを変えるためにパケットを修正し、潜在的に物理的な損傷を引き起こす可能性があります。ただし、モーションコントロールコマンドは必ずしも機密情報と見なされるわけではなく、機密性を提供する必要はありません。機密性の強い要求なしのものの別のインターネット（IoT）の例は、気象情報の報告です。ただし、メッセージの完全性を確保するためにメッセージの信頼性が必要です。

There is no requirement to encrypt messages in environments where the information is not confidential, such as when there is no intellectual property associated with the processes, or where the threat model does not indicate any outsider attacks (such as in a closed system). Note, however, that this situation will not apply equally to all use cases (for example, in one case a robotic arm might be used for a process that does not involve any intellectual property but in another case might be used in a different process that does contain intellectual property). Therefore, it is important that a user or system developer carefully examine both the sensitivity of the data and the system threat model to determine the need for encryption before deploying equipment and security protections.

プロセスに関連する知的財産がない場合、または脅威モデルが部外者攻撃（閉じたシステムなど）を示さない場合など、情報が機密ではない環境でメッセージを暗号化する要件はありません。ただし、この状況はすべてのユースケースに等しく適用されないことに注意してください（たとえば、あるケースでは、知的財産を伴わないプロセスにロボットアームが使用される場合がありますが、別のケースでは別のプロセスで使用される場合があります。知的財産が含まれています）。したがって、ユーザーまたはシステム開発者がデータの感度とシステム脅威モデルの両方を慎重に調べて、機器とセキュリティ保護を展開する前に暗号化の必要性を判断することが重要です。

Besides having a strong need for authenticity and no need for confidentiality, many of these systems also have a strong requirement for low latency. Furthermore, several classes of IoT devices (industrial or otherwise) have limited processing capability. However, these IoT systems still gain great benefit from leveraging TLS 1.3 for secure communications. Given the reduced need for confidentiality, TLS 1.3 cipher suites [RFC8446] that maintain data integrity without confidentiality are described in this document. These cipher suites are not meant for general use, as they do not meet the confidentiality and privacy goals of TLS. They should only be used in cases where confidentiality and privacy are not a concern and there are constraints on using cipher suites that provide the full set of security properties. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced-security mechanism that provides authentication and message integrity with supporting confidentiality.

信頼性と機密性を必要としない強力な必要性を持たせることに加えて、これらのシステムの多くは低い待ち時間にとって強い要件を持っています。さらに、いくつかの種類のIoTデバイス（産業用またはその他の方法）は、制限された処理能力を有する。ただし、これらのIOTシステムは依然として安全な通信のためにTLS 1.3を活用することから大きな利益を得ます。機密保持の必要性が低減された場合、機密性なしにデータの整合性を維持するTLS 1.3暗号スイート[RFC8446]がこの文書に記載されています。これらの暗号スイートは、機密性とTLSのプライバシーの目標を満たしていないため、一般的な使用のためのものではありません。それらは、機密性とプライバシーが関心事ではなく、セキュリティプロパティの完全なセットを提供する暗号スイートを使用することに制約がある場合にのみ使用してください。この文書に記載されているアプローチはIETFによって承認されず、IETFコンセンサスはありませんが、認証とメッセージの整合性をサポートしている縮小セキュリティメカニズムの相互運用可能な実装を可能にするためにここに表示されます。

2. Terminology

2. 用語

This document adopts the conventions for normative language to provide clarity of instructions to the implementer. The key words "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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書は、実装者に指示を明確にするための規範的言語の規則を採用しています。「必須」、「必須」、「必須」、「必須」、「しない」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「5月」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されているように解釈されるべきです。

3. Applicability Statement

3. 適用状況

The two cipher suites defined in this document, which are based on Hashed Message Authentication Code (HMAC) SHAs [RFC6234], are intended for a small limited set of applications where confidentiality requirements are relaxed and the need to minimize the number of cryptographic algorithms is prioritized. This section describes some of those applicable use cases.

ハッシュメッセージ認証コード（HMAC）SHAS [RFC6234]に基づくこの文書で定義されている2つの暗号スイートは、機密性の要件が緩和され、暗号化アルゴリズムの数を最小限に抑える必要がある小さな限界のアプリケーションのセットを目的としています。優先順位このセクションでは、適用可能な使用例のいくつかについて説明します。

Use cases in the industrial automation industry, while requiring data integrity, often do not require confidential communications. Mainly, data communicated to unmanned machines to execute repetitive tasks does not convey private information. For example, there could be a system with a robotic arm that paints the body of a car. This equipment is used within a car manufacturing plant and is just one piece of equipment in a multi-step manufacturing process. The movements of this robotic arm are likely not a trade secret or sensitive intellectual property, although some portions of the manufacturing of the car might very well contain sensitive intellectual property. Even the mixture for the paint itself might be confidential, but the mixing is done by a completely different piece of equipment and therefore communication to/from that equipment can be encrypted without requiring the communication to/from the robotic arm to be encrypted. Modern manufacturing often has segmented equipment with different levels of risk related to intellectual property, although nearly every communication interaction has strong data authenticity requirements.

産業用自動化業界のユースケースは、データの完全性を必要としますが、多くの場合、機密コミュニケーションを必要としません。主に、無人のマシンに伝えられたデータは、繰り返しタスクを実行しても個人情報を伝えません。たとえば、車の体を塗るロボットアームを備えたシステムがある可能性があります。この機器は、自動車製造工場内で使用されており、マルチステップ製造プロセスで1つの機器にすぎません。このロボットアームの動きは、企業秘密や敏感な知的財産ではない可能性がありますが、車の製造の一部には敏感な知的財産が非常によく含まれている可能性があります。塗料自体の混合物でさえ機密性があるかもしれませんが、混合はまったく異なる機器によって行われるため、その機器との間の通信は、暗号化されるロボットアームへの通信/からの通信を必要とせずに暗号化できます。近代的な製造業には、知的財産に関連するリスクレベルのさまざまなリスクを備えたセグメント化された機器がしばしばありますが、ほとんどすべてのコミュニケーションインタラクションには強力なデータの信頼性要件があります。

Another use case that is closely related is that of fine-grained time updates. Motion systems often rely on time synchronization to ensure proper execution. Time updates are essentially public; there is no threat from an attacker knowing the time update information. This should make intuitive sense to those not familiar with these applications; rarely if ever does time information present a serious attack surface dealing with privacy. However, the authenticity is still quite important. The consequences of maliciously modified time data can vary from mere denial of service to actual physical damage, depending on the particular situation and attacker capability. As these time synchronization updates are very fine-grained, it is again important for latency to be very low.

密接に関連している別のユースケースは、きめ細かい時間更新のそれです。動きシステムはしばしば適切な実行を確実にするために時間同期に依存しています。時間の更新は基本的に公開されています。時間更新情報を知っている攻撃者からの脅威はありません。これは、これらのアプリケーションに精通していない人々に直感的な意味を持つべきです。時間情報を経験したら、プライバシーを扱う深刻な攻撃面を紹介します。しかし、信憑性はまだ非常に重要です。悪意内の変更された時間データの結果は、特定の状況や攻撃者の能力に応じて、単なるサービス拒否から実際の物理的損傷までさまざまです。これらの時間同期の更新は非常に微細に微細になっているので、待ち時間が非常に低くなるのにまた重要です。

A third use case deals with data related to alarms. Industrial control sensing equipment can be configured to send alarm information when it meets certain conditions -- for example, temperature goes above or below a given threshold. Oftentimes, this data is used to detect certain out-of-tolerance conditions, allowing an operator or automated system to take corrective action. Once again, in many systems the reading of this data doesn't grant the attacker information that can be exploited; it is generally just information regarding the physical state of the system. At the same time, being able to modify this data would allow an attacker to either trigger alarms falsely or cover up evidence of an attack that might allow for detection of their malicious activity. Furthermore, sensors are often low-powered devices that might struggle to process encrypted and authenticated data. These sensors might be very cost sensitive such that there is not enough processing power for data encryption. Sending data that is just authenticated but not encrypted eases the burden placed on these devices yet still allows the data to be protected against any tampering threats. A user can always choose to pay more for a sensor with encryption capability, but for some, data authenticity will be sufficient.

3番目のユースケースは、アラームに関するデータを扱います。産業用制御センシング装置は、一定の条件を満たすときに警報情報を送信するように構成することができる - 例えば、温度は与えられた閾値を上または下回る。 ententimes、このデータは特定の許容範囲外条件を検出するために使用され、オペレータまたは自動システムが是正措置を講じることができます。やはり、多くのシステムで、このデータの読み取りは攻撃者情報を利用できません。それは一般的にシステムの物理的状態に関する情報です。同時に、このデータを変更することができることは、攻撃者が誤って誤ってトリガーされるか、または悪意のある活動の検出を可能にする可能性がある攻撃の証拠を賄うことを可能にするでしょう。さらに、センサーは、暗号化され認証されたデータを処理するのに苦労する可能性がある低給電装置です。データ暗号化に十分な処理能力がないように、これらのセンサーは非常にコストに敏感である可能性があります。認証されているが暗号化されていないデータの送信は、これらのデバイスに配置されている負担をまだ緩和することで、まだデータを改ざんする脅威から保護することができます。ユーザーは暗号化機能を備えたセンサーにもっと支払うことを選択できますが、一部のデータの真正性で十分です。

A fourth use case considers the protection of commands in the railway industry. In railway control systems, no confidentiality requirements are applied for the command exchange between an interlocking controller and a railway equipment controller (for instance, a railway point controller of a tram track where the position of the controlled point is publicly available). However, protecting the integrity and authenticity of those commands is vital; otherwise, an adversary could change the target position of the point by modifying the commands, which consequently could lead to the derailment of a passing train. Furthermore, requirements for providing flight-data recording of the safety-related network traffic can only be fulfilled through using authenticity-only ciphers as, typically, the recording is used by a third party responsible for the analysis after an accident. The analysis requires such third party to extract the safety-related commands from the recording.

4番目のユースケースは、鉄道業界におけるコマンドの保護を考慮しています。鉄道制御システムでは、インターロックコントローラーと鉄道機器コントローラーとの間のコマンド交換に機密性の要件が適用されません（たとえば、制御ポイントの位置が公開されている路面電車の鉄道ポイントコントローラー）。ただし、これらのコマンドの完全性と信頼性を保護することが不可欠です。それ以外の場合、敵はコマンドを変更することにより、ポイントのターゲット位置を変更する可能性があり、その結果、通過列車の脱線につながる可能性があります。さらに、安全関連ネットワークトラフィックのフライトデータ記録を提供するための要件は、通常、事故後の分析の責任者が録音を使用するため、信頼性のみの暗号を使用することでのみ満たすことができます。分析では、そのような第三者が録音から安全関連のコマンドを抽出する必要があります。

The fifth use case deals with data related to civil aviation airplanes and ground communication. Pilots can send and receive messages to/from ground control, such as airplane route-of-flight updates, weather information, controller and pilot communication, and airline back-office communication. Similarly, the Air Traffic Control (ATC) service uses air-to-ground communication to receive the surveillance data that relies on (is dependent on) downlink reports from an airplane's avionics. This communication occurs automatically in accordance with contracts established between the ATC ground system and the airplane's avionics. Reports can be sent whenever specific events occur or specific time intervals are reached. In many systems, the reading of this data doesn't grant the attacker information that can be exploited; it is generally just information regarding the states of the airplane, controller pilot communication, meteorological information, etc. At the same time, being able to modify this data would allow an attacker to either put aircraft in the wrong flight trajectory or provide false information to ground control that might delay flights, damage property, or harm life. Sending data that is not encrypted but is authenticated allows the data to be protected against any tampering threats. Data authenticity is sufficient for the air traffic, weather, and surveillance information exchanges between airplanes and the ground systems.

5番目のユースケースは、民間航空飛行機と地上コミュニケーションに関連するデータを扱います。パイロットは、飛行機のルートアップデート、気象情報、コントローラーとパイロットコミュニケーション、航空会社のバックオフィスコミュニケーションなど、地上統制にメッセージを送信および受信できます。同様に、航空交通管制（ATC）サービスは、航空機から地下通信を使用して、飛行機のアビオニクスからのダウンリンクレポートに依存する（依存している）監視データを受け取ります。この通信は、ATCグラウンドシステムと飛行機のアビオニクスとの間に確立された契約に従って自動的に発生します。特定のイベントが発生したり、特定の時間間隔に到達するたびにレポートを送信できます。多くのシステムでは、このデータの読み取りでは、悪用される可能性のある攻撃者の情報が付与されません。通常、飛行機の状態、コントローラーパイロット通信、気象情報などに関する情報だけです。同時に、このデータを変更できると、攻撃者が航空機を間違った飛行軌道に配置するか、誤った情報を提供するか、フライト、損害の財産、または害を及ぼす可能性のある地上統制。暗号化されていないが認証されているデータを送信すると、改ざんされた脅威に対してデータを保護できます。データの信頼性は、航空機と地上システムの間の航空交通、天候、監視情報交換に十分です。

The above use cases describe the requirements where confidentiality is not needed and/or interferes with other requirements. Some of these use cases are based on devices that come with a small runtime memory footprint and reduced processing power; therefore, the need to minimize the number of cryptographic algorithms used is a priority. Despite this, it is noted that memory, performance, and processing power implications of any given algorithm or set of algorithms are highly dependent on hardware and software architecture. Therefore, although these cipher suites may provide performance benefits, they will not necessarily provide these benefits in all cases on all platforms. Furthermore, in some use cases, third-party inspection of data is specifically needed, which is also supported through the lack of confidentiality mechanisms.

上記のユースケースは、機密性が必要でない要件および/または他の要件を妨害する要件を記載している。これらのユースケースのいくつかは、ランタイムメモリのフットプリントが小さく、処理能力の低下が付いているデバイスに基づいています。したがって、使用される暗号化アルゴリズムの数を最小限に抑える必要性は優先順位です。これにもかかわらず、任意の所与のアルゴリズムまたはアルゴリズムのセットのメモリ、性能、および処理電力の影響は、ハードウェアおよびソフトウェアアーキテクチャに大きく依存することに留意されたい。したがって、これらの暗号スイートはパフォーマンス上の利点を提供する可能性がありますが、すべてのプラットフォームですべての場合にこれらの利点を必ずしも提供しません。さらに、いくつかの用途の場合には、データの第三者検査が特に必要とされ、それは機密性メカニズムの欠如を通してもサポートされる。

4. Cryptographic Negotiation Using Integrity-Only Cipher Suites

4. 完全性のみの暗号スイートを使用した暗号化ネゴシエーション

The cryptographic negotiation as specified in [RFC8446], Section 4.1.1 remains the same, with the inclusion of the following cipher suites:

[RFC8446]で指定されている暗号化交渉は、次の暗号スイートを含めると同じままであり、同じままです。

TLS_SHA256_SHA256 {0xC0,0xB4}

TLS_SHA256_SHA256 {0xC0,0XB4}

TLS_SHA384_SHA384 {0xC0,0xB5}

TLS_SHA384_SHA384 {0xC0,0XB5}

As defined in [RFC8446], TLS 1.3 cipher suites denote the Authenticated Encryption with Associated Data (AEAD) algorithm for record protection and the hash algorithm to use with the HMAC-based Key Derivation Function (HKDF). The cipher suites provided by this document are defined in a similar way, but they use the HMAC authentication tag to model the AEAD interface, as only an HMAC is provided for record protection (without encryption). These cipher suites allow the use of SHA-256 or SHA-384 as the HMAC for data integrity protection as well as its use for the HKDF. The authentication mechanisms remain unchanged with the intent to only update the cipher suites to relax the need for confidentiality.

[RFC8446]で定義されているように、TLS 1.3暗号スイートは、RECORD保護のための関連データ（AEAD）アルゴリズムとHMACベースのキー導入関数（HKDF）で使用するハッシュアルゴリズムを使用した認証された暗号化を示します。このドキュメントで提供される暗号スイートは同様の方法で定義されていますが、HMAC認証タグを使用してAEADインターフェイスをモデル化します。これは、HMACのみがレコード保護のために提供されるためです（暗号化なし）。これらの暗号スイートにより、SHA-256またはSHA-384をデータ整合性保護のためのHMACとして使用し、HKDFに使用することができます。認証メカニズムは、暗号スイートを更新して機密性の必要性を緩和することのみを目的としています。

Given that these cipher suites do not support confidentiality, they MUST NOT be used with authentication and key exchange methods that rely on confidentiality.

これらの暗号スイートが機密性をサポートしていないことを考えると、機密性に依存する認証と鍵交換方法と一緒に使用してはいけません。

5. Record Payload Protection for Integrity-Only Cipher Suites

5. 完全性のみの暗号スイートのペイロード保護を記録します

Record payload protection as defined in [RFC8446] is retained in modified form when integrity-only cipher suites are used. Note that due to the purposeful use of hash algorithms, instead of AEAD algorithms, confidentiality protection of the record payload is not provided. This section describes the mapping of record payload structures when integrity-only cipher suites are employed.

[RFC8446]で定義されているレコードペイロード保護は、整合性のみの暗号スイートを使用すると、修正された形で保持されます。ハッシュアルゴリズムの意図的な使用により、AEADアルゴリズムの代わりに、レコードペイロードの機密保護は提供されていないことに注意してください。このセクションでは、整合性のみの暗号スイートが採用されている場合のレコードペイロード構造のマッピングについて説明します。

Given that there is no encryption to be done at the record layer, the operations "Protect" and "Unprotect" take the place of "AEAD-Encrypt" and "AEAD-Decrypt" [RFC8446], respectively.

レコード層で行うべき暗号化がないことを考えると、操作は「Aead-Encrypt」と「Aead-Decrypt」[RFC8446]の代わりに「保護」と「非侵入」を取得します。

As integrity protection is provided over the full record, the encrypted_record in the TLSCiphertext along with the additional_data input to protected_data (termed AEADEncrypted data in [RFC8446]) as defined in Section 5.2 of [RFC8446] remain the same. The TLSCiphertext.length for the integrity cipher suites will be:

完全な記録で整合性保護が提供されるため、[RFC8446]のセクション5.2で定義されているように、tlsciphertextのadtation_data入力（[rfc8446]のaeadencryptedデータと呼ばれる）とともに、tlsciphertextで暗号化された_ecordが同じままです。整合性暗号スイートのtlsciphertext.lengthは次のとおりです。

TLS_SHA256_SHA256: TLSCiphertext.length = TLSInnerPlaintext_length + 32

TLS_SHA256_SHA256：TLScipherText.Length = TLSInnerpleAntext_Length 32

TLS_SHA384_SHA384: TLSCiphertext.length = TLSInnerPlaintext_length + 48

tls_sha384_sha384：tlsciphertext.length = tlsinnerplaintext_length 48

Note that TLSInnerPlaintext_length is not defined as an explicit field in [RFC8446]; this refers to the length of the encoded TLSInnerPlaintext structure.

tlsinnerplaintext_lengthは[RFC8446]の明示的なフィールドとして定義されていないことに注意してください。これは、エンコードされたTLSINNERPLANTEXT構造の長さを指します。

The resulting protected_record is the concatenation of the TLSInnerPlaintext with the resulting HMAC. Note that this is analogous to the "encrypted_record" as defined in [RFC8446], although it is referred to as a "protected_record" because of the lack of confidentiality via encryption. With this mapping, the record validation order as defined in Section 5.2 of [RFC8446] remains the same. That is, the encrypted_record field of TLSCiphertext is set to:

結果のprotected_recordは、結果のHMACとのtlsinnerplaintextの連結です。これは、[RFC8446]で定義されている「ancrypted_record」に類似していることに注意してください。ただし、暗号化による機密性がないため、「保護された_record」と呼ばれます。このマッピングでは、[RFC8446]のセクション5.2で定義されているレコード検証順序は同じままです。つまり、tlsciphertextの暗号化された_recordフィールドは次のように設定されています。

encrypted_record = TLS13-HMAC-Protected = TLSInnerPlaintext || HMAC(write_key, nonce || additional_data || TLSInnerPlaintext)

encrypted_record = tls13-hmac-protected = tlsinnerplaintext ||hmac（write_key、nonce || adstition_data || tlsinnerplaintext）

Here, "nonce" refers to the per-record nonce described in Section 5.3 of [RFC8446].

ここで、「Nonce」とは、[RFC8446]のセクション5.3に記載されているレコードごとのNonceを指します。

For DTLS 1.3, the DTLSCiphertext is set to:

DTLS 1.3の場合、DTLSciphertextは次のように設定されています。

encrypted_record = DTLS13-HMAC-Protected = DTLSInnerPlaintext || HMAC(write_key, nonce || additional_data || DTLSInnerPlaintext)

encrypted_record = dtls13-hmac-protected = dtlsinnerplaintext ||hmac（write_key、nonce || adstition_data || dtlsinnerplaintext）

The DTLS "nonce" refers to the per-record nonce described in Section 4.2.2 of [DTLS13].

DTLS「Nonce」とは、[DTLS13]のセクション4.2.2で説明されているレコードごとのNonceを指します。

The Protect and Unprotect operations provide the integrity protection using HMAC SHA-256 or HMAC SHA-384 as described in [RFC6234].

[RFC6234]に記載されているように、保護および非保護操作は、HMAC SHA-256またはHMAC SHA-384を使用した整合性保護を提供します。

Due to the lack of encryption of the plaintext, record padding does not provide any obfuscation as to the plaintext size, although it can be optionally included.

平文の暗号化が不足しているため、記録パディングは平文サイズに関して難読化はありませんが、オプションで含まれていますが。

6. Key Schedule when Using Integrity-Only Cipher Suites

6. 整合性専用暗号スイートを使用するときのキースケジュール

The key derivation process for integrity-only cipher suites remains the same as that defined in [RFC8446]. The only difference is that the keys used to protect the tunnel apply to the negotiated HMAC SHA-256 or HMAC SHA-384 ciphers. Note that the traffic key material (client_write_key, client_write_iv, server_write_key, and server_write_iv) MUST be calculated as per [RFC8446], Section 7.3. The key lengths and Initialization Vectors (IVs) for these cipher suites are according to the hash output lengths. In other words, the following key lengths and IV lengths SHALL be:

整合性のみの暗号スイートのための鍵導出プロセスは[RFC8446]で定義されているものと同じままです。唯一の違いは、トンネルを保護するために使用されたキーが交渉されたHMAC SHA-256またはHMAC SHA-384暗号に適用されることです。トラフィックキーマテリアル（client_write_key、client_write_iv、server_write_iv）は、[RFC8446]、セクション7.3に従って計算する必要があります。これらの暗号スイートのための鍵の長さおよび初期化ベクトル（IVS）はハッシュ出力長に従ってある。言い換えれば、次のキー長とIVの長さは次のとおりです。

              +===================+============+===========+
              | Cipher Suite      | Key Length | IV Length |
              +===================+============+===========+
              | TLS_SHA256_SHA256 | 32 Bytes   | 32 Bytes  |
              +-------------------+------------+-----------+
              | TLS_SHA384_SHA384 | 48 Bytes   | 48 Bytes  |
              +-------------------+------------+-----------+

Table 1

表1

7. Error Alerts

7. エラーアラート

The error alerts as defined by [RFC8446] remain the same; in particular:

[RFC8446]で定義されたエラーアラートは同じままです。特に：

bad_record_mac: This alert can also occur for a record whose message authentication code cannot be validated. Since these cipher suites do not involve record encryption, this alert will only occur when the HMAC fails to verify.

bad_record_mac：このアラートは、メッセージ認証コードを検証できないレコードに対しても発生する可能性があります。これらの暗号スイートには記録的な暗号化が含まれないため、このアラートは、HMACが検証に失敗した場合にのみ発生します。

decrypt_error: This alert, as described in [RFC8446], Section 6.2, occurs when the signature or message authentication code cannot be validated. Note that this error is only sent during the handshake, not for an error in validating record HMACs.

Decrypt_Error：[RFC8446]で説明されているように、セクション6.2であるこのアラートは、署名またはメッセージ認証コードを検証できないときに発生します。このエラーは、握手中にのみ送信されることに注意してください。レコードHMACSを検証する際のエラーではありません。

8. IANA Considerations

8. IANAの考慮事項

IANA has registered the following cipher suites, defined by this document, in the "TLS Cipher Suites" registry:

IANAは、このドキュメントで定義された「TLS Cipher Suites」レジストリで次の暗号スイートを登録しました。

         +===========+===================+=========+=============+
         | Value     | Description       | DTLS-OK | Recommended |
         +===========+===================+=========+=============+
         | 0xC0,0xB4 | TLS_SHA256_SHA256 | Y       | N           |
         +-----------+-------------------+---------+-------------+
         | 0xC0,0xB5 | TLS_SHA384_SHA384 | Y       | N           |
         +-----------+-------------------+---------+-------------+

Table 2

表2

9. Security and Privacy Considerations

9. セキュリティとプライバシーの考慮事項

In general, except for confidentiality and privacy, the security considerations detailed in [RFC8446] and [RFC5246] apply to this document. Furthermore, as the cipher suites described in this document do not provide any confidentiality, it is important that they only be used in cases where there are no confidentiality or privacy requirements and concerns; the runtime memory requirements can accommodate support for authenticity-only cryptographic constructs.

一般に、機密性とプライバシーを除き、[RFC8446]および[RFC5246]に詳述されているセキュリティ上の考慮事項がこのドキュメントに適用されます。さらに、このドキュメントに記載されている暗号スイートは機密性を提供していないため、機密性やプライバシー要件や懸念がない場合にのみ使用することが重要です。ランタイムメモリの要件は、信頼性のみの暗号化構造のサポートに対応できます。

With the lack of data encryption specified in this specification, no confidentiality or privacy is provided for the data transported via the TLS session. That is, the record layer is not encrypted when using these cipher suites, nor is the handshake. To highlight the loss of privacy, the information carried in the TLS handshake, which includes both the server and client certificates, while integrity protected, will be sent unencrypted. Similarly, other TLS extensions that may be carried in the server's EncryptedExtensions message will only be integrity protected without provisions for confidentiality. Furthermore, with this lack of confidentiality, any private Pre-Shared Key (PSK) data MUST NOT be sent in the handshake while using these cipher suites. However, as PSKs may be loaded externally, these cipher suites can be used with the 0-RTT handshake defined in [RFC8446], with the same security implications discussed therein applied.

この仕様で指定されたデータ暗号化が不足しているため、TLSセッションを介して転送されたデータに対して機密性やプライバシーは提供されません。つまり、これらの暗号スイートを使用すると、記録層は暗号化されていません。プライバシーの損失を強調するには、TLSハンドシェイクで運ばれた情報は、保護されている間に保護されている間、サーバー証明書とクライアント証明書の両方を含みますが、暗号化されていません。同様に、サーバーのEncryptedExtensionsメッセージで実行できる他のTLS拡張機能は、機密保持のための規定なしにのみ保護されています。さらに、この機密性の欠如では、これらの暗号スイートを使用しながら、任意のプリシェアリングキー（PSK）データをハンドシェイクに送信してはいけません。しかしながら、PSKが外部でロードされてもよいので、これらの暗号スイートは[RFC8446]で定義された0-RTTハンドシェイクと共に使用することができ、同じセキュリティの意味は適用されたのと同じセキュリティの意味を説明する。

Application protocols that build on TLS or DTLS for protection (e.g., HTTP) may have implicit assumptions of data confidentiality. Any assumption of data confidentiality is invalidated by the use of these cipher suites, as no data confidentiality is provided. This applies to any data sent over the application-data channel (e.g., bearer tokens in HTTP), as data requiring confidentiality MUST NOT be sent using these cipher suites.

保護のためにTLSまたはDTLS（HTTPなど）に基づいて構築されるアプリケーションプロトコルには、データの機密性の暗黙の仮定がある場合があります。データの機密性が提供されていないため、データの機密性の仮定は、これらの暗号スイートの使用によって無効になります。これは、機密性を必要とするデータをこれらの暗号スイートを使用して送信しないでください。

Limits on key usage for AEAD-based ciphers are described in [RFC8446]. However, as the cipher suites discussed here are not AEAD, those same limits do not apply. The general security properties of HMACs discussed in [RFC2104] and [BCK1] apply. Additionally, security considerations on the algorithm's strength based on the HMAC key length and truncation length further described in [RFC4868] also apply. Until further cryptanalysis demonstrates limitations on key usage for HMACs, general practice for key usage recommends that implementations place limits on the lifetime of the HMAC keys and invoke a key update as described in [RFC8446] prior to reaching this limit.

AEADベースの暗号の主要な使用法の制限は、[RFC8446]で説明されています。ただし、ここで説明した暗号スイートはAEADではないため、同じ制限は適用されません。[RFC2104]および[BCK1]で説明されているHMACSの一般的なセキュリティプロパティが適用されます。さらに、[RFC4868]に記載されているHMACキーの長さと切り捨て長に基づくアルゴリズムの強度に関するセキュリティ上の考慮事項も適用されます。さらなる暗号化がHMACSのキー使用に関する制限を示すまで、キー使用の一般的な慣行は、実装がHMACキーの寿命に制限を設け、この制限に達する前に[RFC8446]に記載されているキーアップデートを呼び出すことを推奨しています。

DTLS 1.3 defines a mechanism for encrypting the DTLS record sequence numbers. However, as these cipher suites do not utilize encryption, the record sequence numbers are sent unencrypted. That is, the procedure for DTLS record sequence number protection is to apply no protection for these cipher suites.

DTLS 1.3は、DTLSレコードシーケンス番号を暗号化するメカニズムを定義します。ただし、これらの暗号スイートは暗号化を使用していないため、レコードシーケンス番号は暗号化されていないと送信されます。つまり、DTLSレコードシーケンス番号保護の手順は、これらの暗号スイートを保護しないことです。

Given the lack of confidentiality, these cipher suites MUST NOT be enabled by default. As these cipher suites are meant to serve the IoT market, it is important that any IoT endpoint that uses them be explicitly configured with a policy of non-confidential communications.

機密性がないことを考えると、これらの暗号スイートをデフォルトで有効にする必要はありません。これらの暗号スイートはIoT市場にサービスを提供することを目的としているため、それらを使用するIoTエンドポイントは、非信頼性通信のポリシーで明示的に構成されることが重要です。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[BCK1] Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash Functions for Message Authentication", DOI 10.1007/3-540-68697-5_1, 1996, <https://link.springer.com/ chapter/10.1007/3-540-68697-5_1>.

[BCK1] Bellare、M.、Canetti、R.、およびH. Krawczyk、「メッセージ認証のためのキーハッシュ機能」、DOI 10.1007/3-540-68697-5_1、1996、<https://link.springer.com/章10.1007/3-540-68697-5_1>。

[DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

[DTLS13] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「Datagram Transport Layer Security（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

[RFC2104] Krawczyk、H.、Belleare、M.、およびR. Canetti、 "HMAC：メッセージ認証のための鍵付きハッシング"、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-編集者.org / info / rfc2104>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.

[RFC4868] Kelly、S.およびS. Frankel、「HMAC-SHA-256、HMAC-SHA-384、およびIPSecおよびHMAC-SHA-512を使用する」、RFC 4868、DOI 10.17487 / RFC4868、2007年5月、<https：//www.rfc-editor.org/info/rfc4868>。

[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC6234] EastLake 3rd、D。およびT. Hansen、「米国安全なハッシュアルゴリズム（SHAおよびSHAベースのHMACおよびHKDF）」、RFC 6234、DOI 10.17487/RFC6234、2011年5月、<https：//ww.rfc-editor.org/info/rfc6234>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、<https：//www.rfc-editor.org/info/rfc8446>。

10.2. Informative References

10.2. 参考引用

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、DOI 10.17487/RFC5246、2008年8月、<https://www.rfc-editor.org/info/RFC5246>。

Acknowledgements

謝辞

The authors would like to acknowledge the work done by Industrial Communications Standards Groups (such as ODVA) as the motivation for this document. We would also like to thank Steffen Fries for providing a fourth use case and Madhu Niraula for a fifth use case. In addition, we are grateful for the advice and feedback from Joe Salowey, Blake Anderson, David McGrew, Clement Zeller, and Peter Wu.

著者らは、この文書の動機として、産業通信標準グループ（ODVAなど）によって行われた作業を承認したいと思います。また、5番目のユースケースのための4番目のユースケースとMADHU NIRAULAを提供するためにSteff Friesに感謝します。また、Joe Salowey、Blake Anderson、David McGrew、Clement Zeller、Peter Wuからのアドバイスとフィードバックに感謝します。

Authors' Addresses

著者のアドレス

Nancy Cam-Winget Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America Email: ncamwing@cisco.com

ナンシー・カム・ウィンゲット・シスコ・システム3550シスコ・ウェイ・サンノゼ、カリフォルニア州95134アメリカ合衆国電子メール：ncamwing@cisco.com

Jack Visoky ODVA 1 Allen Bradley Dr Mayfield Heights, OH 44124 United States of America Email: jmvisoky@ra.rockwell.com

Jack Visoky Odva 1 Allen Bradley Dr Mayfield Heights、OH 44124アメリカ合衆国Eメール：jmvisky@rockwell.com