Internet Engineering Task Force (IETF) G. Selander
Request for Comments: 9528 J. Preuß Mattsson
Category: Standards Track F. Palombini
ISSN: 2070-1721 Ericsson
March 2024
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low.
この文書は、Ephemeral Diffie-Hellman Over COSE（EDHOC）を指定しており、非常にコンパクトで軽量な認証済みDiffie-Hellman鍵交換を提供します。EDHOCは相互認証、前方秘匿、および識別情報保護を提供します。EDHOCは制約のあるシナリオでの使用を想定しており、主なユースケースはConstrained RESTful Environments（OSCORE）のセキュリティコンテキストを確立することです。暗号化にはCBOR Object Signing and Encryption（COSE）、エンコーディングにはConcise Binary Object Representation（CBOR）、輸送にはConstrained Application Protocol（CoAP）を再利用することで、追加のコードサイズを非常に低く抑えることができます。
This is an Internet Standards Track document.
これはインターネット標準トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書はInternet Engineering Task Force（IETF）の製品です。IETFコミュニティの合意を表しています。公開レビューを受け、Internet Engineering Steering Group（IESG）によって出版が承認されました。Internet Standardsに関する詳細情報は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/rfc9528.
このドキュメントの現在の状況、誤植、およびフィードバックの方法に関する情報は、https://www.rfc-editor.org/info/rfc9528 で入手できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なBCP 78およびIETF文書に関連するIETF信託の法的規定（https://trustee.ietf.org/license-info）の対象となります。これらの文書を注意深く確認してください。なぜなら、これらはこの文書に関するあなたの権利と制限を説明しているからです。この文書から抽出されたコードコンポーネントには、信託法的規定のセクション4.eに記載されているように、修正されたBSDライセンステキストを含める必要があり、修正されたBSDライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Motivation
1.2. Message Size Examples
1.3. Document Structure
1.4. Terminology and Requirements Language
2. EDHOC Outline
3. Protocol Elements
3.1. General
3.2. Method
3.3. Connection Identifiers
3.4. Transport
3.5. Authentication Parameters
3.6. Cipher Suites
3.7. Ephemeral Public Keys
3.8. External Authorization Data (EAD)
3.9. Application Profile
4. Key Derivation
4.1. Keys for EDHOC Message Processing
4.2. Keys for EDHOC Applications
5. Message Formatting and Processing
5.1. EDHOC Message Processing Outline
5.2. EDHOC Message 1
5.3. EDHOC Message 2
5.4. EDHOC Message 3
5.5. EDHOC Message 4
6. Error Handling
6.1. Success
6.2. Unspecified Error
6.3. Wrong Selected Cipher Suite
6.4. Unknown Credential Referenced
7. EDHOC Message Deduplication
8. Compliance Requirements
9. Security Considerations
9.1. Security Properties
9.2. Cryptographic Considerations
9.3. Cipher Suites and Cryptographic Algorithms
9.4. Post-Quantum Considerations
9.5. Unprotected Data and Privacy
9.6. Updated Internet Threat Model Considerations
9.7. Denial of Service
9.8. Implementation Considerations
10. IANA Considerations
10.1. EDHOC Exporter Label Registry
10.2. EDHOC Cipher Suites Registry
10.3. EDHOC Method Type Registry
10.4. EDHOC Error Codes Registry
10.5. EDHOC External Authorization Data Registry
10.6. COSE Header Parameters Registry
10.7. Well-Known URI Registry
10.8. Media Types Registry
10.9. CoAP Content-Formats Registry
10.10. Resource Type (rt=) Link Target Attribute Values Registry
10.11. Expert Review Instructions
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Use with OSCORE and Transfer over CoAP
A.1. Deriving the OSCORE Security Context
A.2. Transferring EDHOC over CoAP
Appendix B. Compact Representation
Appendix C. Use of CBOR, CDDL, and COSE in EDHOC
C.1. CBOR and CDDL
C.2. CDDL Definitions
C.3. COSE
Appendix D. Authentication-Related Verifications
D.1. Validating the Authentication Credential
D.2. Identities
D.3. Certification Path and Trust Anchors
D.4. Revocation Status
D.5. Unauthenticated Operation
Appendix E. Use of External Authorization Data
Appendix F. Application Profile Example
Appendix G. Long PLAINTEXT_2
Appendix H. EDHOC_KeyUpdate
Appendix I. Example Protocol State Machine
I.1. Initiator State Machine
I.2. Responder State Machine
Acknowledgments
Authors' Addresses
Many Internet of Things (IoT) deployments require technologies that are highly performant in constrained environments [RFC7228]. IoT devices may be constrained in various ways, including memory, storage, processing capacity, and power. The connectivity for these settings may also exhibit constraints, such as unreliable and lossy channels, highly restricted bandwidth, and dynamic topology. The IETF has acknowledged this problem by standardizing a range of lightweight protocols and enablers designed for the IoT, including CoAP [RFC7252], CBOR [RFC8949], and Static Context Header Compression (SCHC) [RFC8724].
多くのインターネット・オブ・シングス（IoT）の展開では、制約のある環境で高性能な技術が必要とされます[RFC7228]。 IoTデバイスは、メモリ、ストレージ、処理能力、電力など、さまざまな方法で制約される可能性があります。 これらの設定のための接続性には、信頼性の低いチャネル、損失の多いチャネル、非常に制限された帯域幅、動的なトポロジなどの制約がある場合もあります。 IETFは、IoT向けに設計された軽量プロトコルやイネーブラを標準化することで、この問題に対処しています。これには、CoAP[RFC7252]、CBOR[RFC8949]、Static Context Header Compression（SCHC）[RFC8724]などが含まれます。
The need for special protocols targeting constrained IoT deployments extends also to the security domain [LAKE-REQS]. Important characteristics in constrained environments are the number of round trips and protocol message sizes, which (if kept low) can contribute to good performance by enabling transport over a small number of radio frames, reducing latency due to fragmentation, duty cycles, etc. Another important criterion is code size, which may be prohibitively large for certain deployments due to device capabilities or network load during firmware updates. Some IoT deployments also need to support a variety of underlying transport technologies, potentially even with a single connection.
特定の制約のあるIoT展開を対象とした特別なプロトコルの必要性は、セキュリティ領域にも及びます。制約のある環境で重要な特性は、ラウンドトリップの数やプロトコルメッセージのサイズであり、これらが低い場合は、ラジオフレームの数を少なくしてトランスポートを可能にすることで、フラグメンテーションやデューティサイクルなどによる遅延を減らすことができ、良好なパフォーマンスに貢献します。もう1つの重要な基準はコードサイズであり、デバイスの能力やファームウェアの更新時のネットワーク負荷により、特定の展開において過大なものとなる可能性があります。一部のIoT展開では、1つの接続でさまざまな基盤となるトランスポート技術をサポートする必要がある場合もあります。
Some security solutions for such settings exist already. COSE [RFC9052] specifies basic application-layer security services efficiently encoded in CBOR. Another example is OSCORE [RFC8613], which is a lightweight communication security extension to CoAP using CBOR and COSE. In order to establish good quality cryptographic keys for security protocols such as COSE and OSCORE, the two endpoints may run an authenticated Diffie-Hellman key exchange protocol, from which shared secret keying material can be derived. Such a key exchange protocol should also be lightweight to prevent bad performance in case of repeated use, e.g., due to device rebooting or frequent rekeying for security reasons or to avoid latencies in a network formation setting with many devices authenticating at the same time.
そのような設定に対するいくつかのセキュリティソリューションはすでに存在しています。COSE [RFC9052] は、CBOR で効率的にエンコードされた基本的なアプリケーション層セキュリティサービスを指定しています。別の例として、OSCORE [RFC8613] があります。これは、CBOR と COSE を使用した CoAP への軽量通信セキュリティ拡張です。COSE や OSCORE などのセキュリティプロトコルのために良質な暗号鍵を確立するために、2つのエンドポイントは認証済みの Diffie-Hellman 鍵交換プロトコルを実行することができます。このプロトコルから共有秘密鍵材料を導出することができます。このような鍵交換プロトコルは、デバイスの再起動やセキュリティ上の理由、ネットワーク形成設定で多くのデバイスが同時に認証する場合など、繰り返し使用される場合にパフォーマンスが低下しないように軽量であるべきです。
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a lightweight authenticated key exchange protocol providing good security properties including forward secrecy, identity protection, and cipher suite negotiation. Authentication can be based on raw public keys (RPKs) or public key certificates and requires the application to provide input on how to verify that endpoints are trusted. This specification supports the referencing of credentials in order to reduce message overhead, but credentials may alternatively be embedded in the messages. EDHOC does not currently support Pre-Shared Key (PSK) authentication as authentication with static Diffie-Hellman (DH) public keys by reference produces equally small message sizes but with much simpler key distribution and identity protection.
この文書は、Ephemeral Diffie-Hellman Over COSE（EDHOC）を指定しており、フォワードセクレシー、アイデンティティ保護、および暗号スイートのネゴシエーションを含む良好なセキュリティ特性を提供する軽量認証キー交換プロトコルです。認証は生の公開鍵（RPKs）または公開鍵証明書に基づくことができ、エンドポイントが信頼されているかどうかを検証する方法についての入力をアプリケーションに提供する必要があります。この仕様は、メッセージのオーバーヘッドを削減するために資格情報の参照をサポートしていますが、代わりに資格情報をメッセージに埋め込むこともできます。EDHOCは現在、Pre-Shared Key（PSK）認証をサポートしておらず、静的Diffie-Hellman（DH）公開鍵を参照して認証することで同様に小さなメッセージサイズを実現しますが、キー配布とアイデンティティ保護がはるかに簡単です。
EDHOC makes use of known protocol constructions, such as SIGn-and-MAc [SIGMA], the Noise XX pattern [Noise], and Extract-and-Expand [RFC5869]. EDHOC uses COSE for cryptography and identification of credentials (including COSE_Key, CBOR Web Token (CWT), CWT Claims Set (CCS), X.509, and CBOR-encoded X.509 (C509) certificates; see Section 3.5.2). COSE provides crypto agility and enables the use of future algorithms and credential types targeting IoT.
EDHOCは、SIGn-and-MAc [SIGMA]、Noise XXパターン[Noise]、Extract-and-Expand [RFC5869]などの既知のプロトコル構造を利用しています。EDHOCは、暗号化と資格情報の識別のためにCOSEを使用しています（COSE_Key、CBOR Web Token（CWT）、CWT Claims Set（CCS）、X.509、およびCBORエンコードされたX.509（C509）証明書を含む；セクション3.5.2を参照）。COSEは暗号アジリティを提供し、将来のアルゴリズムやIoTを対象とした資格情報タイプの使用を可能にします。
EDHOC is designed for highly constrained settings, making it especially suitable for low-power networks [RFC8376] such as Cellular IoT, IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH), and LoRaWAN. A main objective for EDHOC is to be a lightweight authenticated key exchange for OSCORE, i.e., to provide authentication and session key establishment for IoT use cases such as those built on CoAP [RFC7252] involving 'things' with embedded microcontrollers, sensors, and actuators. By reusing the same lightweight primitives as OSCORE (CBOR, COSE, and CoAP), the additional code size can be kept very low. Note that while CBOR and COSE primitives are built into the protocol messages, EDHOC is not bound to a particular transport.
EDHOCは、高度に制約のある環境向けに設計されており、特に低電力ネットワーク（RFC8376）に適しています。例えば、Cellular IoT、IEEE 802.15.4eのTSCHモード（6TiSCH）、およびLoRaWANなどが挙げられます。EDHOCの主な目的は、OSCORE向けの軽量認証キー交換であり、つまり、CoAP（RFC7252）をベースにしたIoTユースケース向けの認証とセッションキーの確立を提供することです。これには、組み込みマイクロコントローラ、センサー、アクチュエータを備えた「物」を含むIoTユースケースが含まれます。OSCORE（CBOR、COSE、CoAP）と同じ軽量プリミティブを再利用することで、追加のコードサイズを非常に低く抑えることができます。CBORとCOSEのプリミティブはプロトコルメッセージに組み込まれていますが、EDHOCは特定のトランスポートには結び付いていません。
A typical setting is when one of the endpoints is constrained or in a constrained network and the other endpoint is a node on the Internet (such as a mobile phone). Thing-to-thing interactions over constrained networks are also relevant since both endpoints would then benefit from the lightweight properties of the protocol. EDHOC could, e.g., be run when a device connects for the first time or to establish fresh keys that are not revealed by a later compromise of the long-term keys.
典型的な設定は、エンドポイントの1つが制約されているか、制約されたネットワークにある場合であり、もう1つのエンドポイントがインターネット上のノード（例：携帯電話など）である場合です。 制約されたネットワーク上でのデバイス間の相互作用も関連しており、その場合、プロトコルの軽量な特性から両方のエンドポイントが利益を得ることができます。 たとえば、EDHOCは、デバイスが初めて接続するときや、長期キーの後での妥協によって明らかにされない新しいキーを確立するときに実行される可能性があります。
Examples of EDHOC message sizes are shown in Table 1, which use different kinds of authentication keys and COSE header parameters for identification, including static Diffie-Hellman keys or signature keys, either in CWT/CCS [RFC8392] identified by a key identifier using 'kid' [RFC9052] or in X.509 certificates identified by a hash value using 'x5t' [RFC9360]. EDHOC always uses ephemeral-ephemeral key exchange. As a comparison, in the case of RPK authentication and when transferred in CoAP, the EDHOC message size can be less than 1/7 of the DTLS 1.3 handshake [RFC9147] with Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) and connection ID; see [CoAP-SEC-PROT].
EDHOC メッセージサイズの例は、異なる種類の認証キーと識別のために COSE ヘッダーパラメータを使用する表1に示されています。これには、静的ディフィー・ヘルマンキーまたは署名キーが含まれ、それぞれが 'kid' [RFC9052] を使用してキー識別子で識別される CWT/CCS [RFC8392] または 'x5t' [RFC9360] を使用してハッシュ値で識別される X.509 証明書が含まれます。EDHOC は常に一時的な一時的な鍵交換を使用します。比較として、RPK 認証の場合や CoAP で転送される場合、EDHOC メッセージサイズは、Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) と接続 ID を使用した DTLS 1.3 ハンドシェイク [RFC9147] の1/7未満になる場合があります。[CoAP-SEC-PROT] を参照してください。
+===========+================+================+
| | Static DH Keys | Signature Keys |
+===========+==========+=====+==========+=====+
| | kid | x5t | kid | x5t |
+===========+==========+=====+==========+=====+
| message_1 | 37 | 37 | 37 | 37 |
+-----------+----------+-----+----------+-----+
| message_2 | 45 | 58 | 102 | 115 |
+-----------+----------+-----+----------+-----+
| message_3 | 19 | 33 | 77 | 90 |
+-----------+----------+-----+----------+-----+
| Total | 101 | 128 | 216 | 242 |
+-----------+----------+-----+----------+-----+
Table 1: Examples of EDHOC Message Sizes in Bytes
表1：バイト単位でのEDHOCメッセージサイズの例
The remainder of the document is organized as follows: Section 2 outlines EDHOC authenticated with signature keys; Section 3 describes the protocol elements of EDHOC, including formatting of the ephemeral public keys; Section 4 specifies the key derivation; Section 5 specifies message processing for EDHOC authenticated with signature keys or static Diffie-Hellman keys; Section 6 describes the error messages; Section 7 describes EDHOC support for transport that does not handle message duplication; and Section 8 lists compliance requirements. Note that normative text is also used in appendices, in particular Appendix A.
ドキュメントの残りは次のように構成されています：セクション2では署名キーで認証されたEDHOCが概説されています。セクション3では、EDHOCのプロトコル要素が説明されており、エフェメラル公開鍵のフォーマットも含まれています。セクション4では鍵導出が指定されています。セクション5では、署名キーまたは静的Diffie-Hellmanキーで認証されたEDHOCのメッセージ処理が指定されています。セクション6ではエラーメッセージが説明されています。セクション7では、メッセージの重複を処理しないトランスポートに対するEDHOCのサポートが説明されています。セクション8では適合要件がリストされています。規範的なテキストは付録にも使用されており、特に付録Aにあります。
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.
この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、全て大文字で表記されている場合に限り、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されるべきです。
Readers are expected to be familiar with the terms and concepts described in CBOR [RFC8949], CBOR Sequences [RFC8742], COSE Structures and Processing [RFC9052], COSE Algorithms [RFC9053], CWT and CCS [RFC8392], and the Concise Data Definition Language (CDDL) [RFC8610], which is used to express CBOR data structures. Examples of CBOR and CDDL are provided in Appendix C.1. When referring to CBOR, this specification always refers to Deterministically Encoded CBOR, as specified in Sections 4.2.1 and 4.2.2 of [RFC8949]. The single output from authenticated encryption (including the authentication tag) is called "ciphertext", following [RFC5116].
読者は、CBOR [RFC8949]、CBOR Sequences [RFC8742]、COSE Structures and Processing [RFC9052]、COSE Algorithms [RFC9053]、CWT および CCS [RFC8392]、および Concise Data Definition Language (CDDL) [RFC8610] で説明されている用語や概念に精通していることが期待されています。CBOR データ構造を表現するために使用される Concise Data Definition Language (CDDL) [RFC8610] についても理解している必要があります。CBOR および CDDL の例は、付録 C.1 に提供されています。CBOR に言及する際、この仕様書では常に [RFC8949] のセクション 4.2.1 および 4.2.2 で指定されている決定的に符号化された CBOR を指します。認証付き暗号化からの単一の出力（認証タグを含む）は、[RFC5116] に従って "ciphertext" と呼ばれます。
EDHOC supports different authentication methods of the ephemeral-ephemeral Diffie-Hellman key exchange. This document specifies authentication methods based on signature keys and static Diffie-Hellman keys. This section outlines the signature-key-based method. Further details of protocol elements and other authentication methods are provided in the remainder of this document.
EDHOCは、一時的なDiffie-Hellman鍵交換のさまざまな認証方法をサポートしています。この文書では、署名鍵と静的Diffie-Hellman鍵に基づく認証方法が指定されています。このセクションでは、署名鍵に基づく方法について概説します。プロトコル要素の詳細や他の認証方法については、この文書の残りの部分で提供されています。
SIGn-and-MAc (SIGMA) is a family of theoretical protocols with a number of variants [SIGMA]. Like in Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] and (D)TLS 1.3 [RFC8446] [RFC9147], EDHOC authenticated with signature keys is built on a variant of the SIGMA protocol, SIGMA-I, which provides identity protection against active attacks on the party initiating the protocol. Also like IKEv2, EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol. The message flow (excluding an optional fourth message) is shown in Figure 1.
SIGn-and-MAc（SIGMA）は、いくつかのバリアントを持つ理論プロトコルファミリーです。インターネットキー交換プロトコルバージョン2（IKEv2）や（D）TLS 1.3などと同様に、署名キーで認証されたEDHOCは、SIGMAプロトコルのバリアントであるSIGMA-Iに基づいて構築されており、プロトコルを開始する側に対するアクティブ攻撃に対するアイデンティティ保護を提供します。IKEv2と同様に、EDHOCはSIGMA-IプロトコルのMAC-then-Signバリアントを実装しています。図1には、（オプションの第4メッセージを除く）メッセージフローが示されています。
Initiator Responder
| G_X |
+------------------------------------------------------------------>|
| |
| G_Y, Enc( ID_CRED_R, Sig( R; MAC( CRED_R, G_X, G_Y ) ) ) |
|<------------------------------------------------------------------+
| |
| AEAD( ID_CRED_I, Sig( I; MAC( CRED_I, G_Y, G_X ) ) ) |
+------------------------------------------------------------------>|
| |
Figure 1: MAC-then-Sign Variant of the SIGMA-I Protocol Used by the EDHOC Method 0
図1：EDHOCメソッドで使用されるSIGMA-IプロトコルのMAC-then-Signバリアント
The parties exchanging messages in an EDHOC session are called the Initiator (I) and the Responder (R), where the Initiator sends message_1 (see Section 3). They exchange ephemeral public keys, compute a shared secret session key PRK_out, and derive symmetric application keys used to protect application data.
EDHOCセッションでメッセージを交換するパーティは、イニシエータ（I）とレスポンダ（R）と呼ばれます。イニシエータはメッセージ_1を送信します（セクション3を参照）。彼らは一時的な公開鍵を交換し、共有秘密セッションキーPRK_outを計算し、アプリケーションデータを保護するために使用される対称アプリケーションキーを導出します。
* G_X and G_Y are the Elliptic Curve Diffie-Hellman (ECDH) ephemeral public keys of I and R, respectively.
* G_XとG_Yは、それぞれIとRの楕円曲線ディフィー・ヘルマン（ECDH）の一時的な公開鍵です。
* CRED_I and CRED_R are the authentication credentials containing the public authentication keys of I and R, respectively.
* CRED_IとCRED_Rは、それぞれIとRの公開認証キーを含む認証資格情報です。
* ID_CRED_I and ID_CRED_R are used to identify and optionally transport the credentials of I and R, respectively.
* ID_CRED_IとID_CRED_Rは、それぞれIとRの資格情報を識別およびオプションで転送するために使用されます。
* Sig(I; . ) and Sig(R; . ) denote signatures made with the private authentication key of I and R, respectively.
* Sig(I; . ) と Sig(R; . ) は、それぞれ I と R のプライベート認証キーで作成された署名を示します。
* Enc(), AEAD(), and MAC() denote encryption, Authenticated Encryption with Associated Data, and Message Authentication Code -- crypto algorithms applied with keys derived from one or more shared secrets calculated during the protocol.
* Enc（）, AEAD（）, および MAC（）は、プロトコル中に計算された1つ以上の共有秘密から派生したキーを使用して適用される暗号アルゴリズムである暗号化、関連データを持つ認証付き暗号化、およびメッセージ認証コードを示します。
In order to create a "full-fledged" protocol, some additional protocol elements are needed. This specification adds:
「本格的な」プロトコルを作成するためには、いくつかの追加プロトコル要素が必要です。この仕様には次の要素が追加されます。
* transcript hashes (hashes of message data), TH_2, TH_3, and TH_4, used for key derivation and as additional authenticated data,
* トランスクリプトハッシュ（メッセージデータのハッシュ）、TH_2、TH_3、およびTH_4は、鍵導出および追加認証データとして使用されます。
* computationally independent keys derived from the ECDH shared secret and used for authenticated encryption of different messages,
* ECDH共有秘密から導出された計算上独立なキーを使用して、異なるメッセージの認証付き暗号化を行います。
* an optional fourth message giving key confirmation to I in deployments where no protected application data is sent from R to I,
* 保護されたアプリケーションデータが R から I に送信されない展開で、I にキー確認を提供するオプションの第4メッセージ、
* a keying material exporter and a key update function with forward secrecy,
* 鍵素材の輸出業者と前方秘匿性を持つ鍵更新機能、
* secure negotiation of the cipher suite,
* 暗号スイートの安全な交渉、
* method types, error handling, and padding,
* メソッドの種類、エラー処理、およびパディング、
* the selection of connection identifiers, C_I and C_R, which may be used in EDHOC to identify the protocol state, and
* EDHOCでプロトコルの状態を識別するために使用される接続識別子C_IとC_Rの選択、
* transport of external authorization data.
* 外部認証データの転送。
EDHOC is designed to encrypt and integrity protect as much information as possible. Symmetric keys and random material used in EDHOC are derived using EDHOC_KDF with as much previous information as possible; see Figure 6. EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, processing, and the ability to reuse already existing CBOR, COSE, and CoAP libraries. Like in (D)TLS, authentication is the responsibility of the application. EDHOC identifies (and optionally transports) authentication credentials and provides proof-of-possession of the private authentication key.
EDHOCはできるだけ多くの情報を暗号化および整合性保護するように設計されています。EDHOCで使用される対称鍵とランダム素材は、できるだけ多くの以前の情報を使用してEDHOC_KDFを使用して派生されます。さらに、EDHOCはメッセージサイズ、処理、および既存のCBOR、COSE、およびCoAPライブラリを再利用する能力に関して、できるだけコンパクトで軽量に設計されています。 (D)TLSと同様に、認証はアプリケーションの責任です。EDHOCは認証資格情報を識別し（必要に応じて輸送し）、プライベート認証キーの所持の証明を提供します。
To simplify for implementors, the use of CBOR, CDDL, and COSE in EDHOC is summarized in Appendix C. Test vectors, including CBOR diagnostic notation, are provided in [RFC9529].
実装者のために、EDHOCでのCBOR、CDDL、およびCOSEの使用は付録Cにまとめられています。CBOR診断表記を含むテストベクターは[RFC9529]で提供されています。
The EDHOC protocol consists of three mandatory messages (message_1, message_2, and message_3), an optional fourth message (message_4), and an error message, between an Initiator (I) and a Responder (R). The odd messages are sent by I, the even by R. Both I and R can send error messages. The roles have slightly different security properties that should be considered when the roles are assigned; see Section 9.1. All EDHOC messages are CBOR Sequences [RFC8742] and are defined to be deterministically encoded CBOR as specified in Section 4.2.1 of [RFC8949]. Figure 2 illustrates an EDHOC message flow with the optional fourth message as well as the content of each message. The protocol elements in the figure are introduced in Sections 3 and 5. Message formatting and processing are specified in Sections 5 and 6.
EDHOCプロトコルは、3つの必須メッセージ（message_1、message_2、message_3）、オプションの第4メッセージ（message_4）、およびイニシエータ（I）とレスポンダ（R）の間のエラーメッセージで構成されています。奇数のメッセージはIから送信され、偶数のメッセージはRから送信されます。IとRの両方がエラーメッセージを送信できます。役割にはわずかに異なるセキュリティプロパティがあり、役割が割り当てられる際に考慮すべきです。すべてのEDHOCメッセージはCBORシーケンス[RFC8742]であり、[RFC8949]のセクション4.2.1で指定されているように、決定的にエンコードされたCBORと定義されています。図2は、オプションの第4メッセージを含むEDHOCメッセージフローと各メッセージの内容を示しています。図中のプロトコル要素は、セクション3および5で紹介されています。メッセージのフォーマットと処理は、セクション5および6で指定されています。
Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see Section 3.6), and the application can make use of the established connection identifiers C_I and C_R (see Section 3.3). Media types that may be used for EDHOC are defined in Section 10.8.
アプリケーションデータは、選択された暗号スイート（セクション3.6を参照）で合意されたアプリケーションアルゴリズム（AEAD、ハッシュ）を使用して保護される可能性があり、アプリケーションは確立された接続識別子C_IおよびC_Rを利用することができます（セクション3.3を参照）。EDHOCに使用できるメディアタイプは、セクション10.8で定義されています。
The Initiator can derive symmetric application keys after creating EDHOC message_3; see Section 4.2.1. Protected application data can therefore be sent in parallel or together with EDHOC message_3. EDHOC message_4 is typically not sent.
イニシエーターは、EDHOCメッセージ_3を作成した後に対称アプリケーションキーを導出できます。セクション4.2.1を参照してください。したがって、保護されたアプリケーションデータは、EDHOCメッセージ_3と並行してまたは一緒に送信することができます。通常、EDHOCメッセージ_4は送信されません。
Initiator Responder
| METHOD, SUITES_I, G_X, C_I, EAD_1 |
+------------------------------------------------------------------>|
| message_1 |
| |
| G_Y, Enc( C_R, ID_CRED_R, Signature_or_MAC_2, EAD_2 ) |
|<------------------------------------------------------------------+
| message_2 |
| |
| AEAD( ID_CRED_I, Signature_or_MAC_3, EAD_3 ) |
+------------------------------------------------------------------>|
| message_3 |
| |
| AEAD( EAD_4 ) |
|<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| message_4 |
Figure 2: EDHOC Message Flow Including the Optional Fourth Message
図2: オプションの第4メッセージを含むEDHOCメッセージフロー
The data item METHOD in message_1 (see Section 5.2.1) is an integer specifying the authentication method. EDHOC currently supports authentication with signature or static Diffie-Hellman keys, as defined in the four authentication methods: 0, 1, 2, and 3; see Table 2. When using a static Diffie-Hellman key, the authentication is provided by a Message Authentication Code (MAC) computed from an ephemeral-static ECDH shared secret that enables significant reductions in message sizes. Note that, also in the static Diffie-Hellman-based authentication methods, there is an ephemeral-ephemeral Diffie-Hellman key exchange.
メッセージ_1のMETHODデータ項目（5.2.1節を参照）は、認証方法を指定する整数です。EDHOCは現在、署名または静的Diffie-Hellmanキーによる認証をサポートしており、これは4つの認証方法（0、1、2、3）で定義されています。静的Diffie-Hellmanキーを使用する場合、認証は、メッセージサイズの大幅な削減を可能にする、一時的な静的ECDH共有秘密から計算されたメッセージ認証コード（MAC）によって提供されます。静的Diffie-Hellmanベースの認証方法でも、一時的な一時的Diffie-Hellman鍵交換が行われます。
The Initiator and Responder need to have agreed on a single method to be used for EDHOC; see Section 3.9.
イニシエーターとレスポンダーは、EDHOCに使用する単一の方法に合意する必要があります。セクション3.9を参照してください。
+===================+====================+====================+
| Method Type Value | Initiator | Responder |
| | Authentication Key | Authentication Key |
+===================+====================+====================+
| 0 | Signature Key | Signature Key |
+-------------------+--------------------+--------------------+
| 1 | Signature Key | Static DH Key |
+-------------------+--------------------+--------------------+
| 2 | Static DH Key | Signature Key |
+-------------------+--------------------+--------------------+
| 3 | Static DH Key | Static DH Key |
+-------------------+--------------------+--------------------+
| 23 | Reserved | Reserved |
+-------------------+--------------------+--------------------+
Table 2: Authentication Keys for Method Types
表2：メソッドタイプ用の認証キー
EDHOC does not have a dedicated message field to indicate the protocol version. Breaking changes to EDHOC can be introduced by specifying and registering new methods.
EDHOCにはプロトコルバージョンを示すための専用のメッセージフィールドがありません。新しいメソッドを指定して登録することで、EDHOCには破壊的な変更が導入される可能性があります。
EDHOC includes the selection of connection identifiers (C_I and C_R) identifying a connection for which keys are agreed.
EDHOCには、鍵が合意された接続を識別する接続識別子（C_IおよびC_R）の選択が含まれます。
Connection identifiers may be used to correlate EDHOC messages and facilitate the retrieval of protocol state during an EDHOC session (see Section 3.4) or may be used in applications of EDHOC, e.g., in OSCORE (see Section 3.3.3). The connection identifiers do not have any cryptographic purpose in EDHOC and only facilitate the retrieval of security data associated with the protocol state.
接続識別子は、EDHOCメッセージを関連付け、EDHOCセッション中のプロトコル状態の取得を容易にするために使用される場合があります（セクション3.4を参照）。また、EDHOCのアプリケーションで使用される場合もあります。たとえば、OSCORE（セクション3.3.3を参照）。接続識別子は、EDHOCにおいては暗号目的を持たず、プロトコル状態に関連するセキュリティデータの取得を容易にするだけです。
Connection identifiers in EDHOC are intrinsically byte strings. Most constrained devices only have a few connections for which short identifiers may be sufficient. In some cases, minimum length identifiers are necessary to comply with overhead requirements. However, CBOR byte strings -- with the exception of the empty byte string h'', which encodes as one byte (0x40) -- are encoded as two or more bytes. To enable one-byte encoding of certain byte strings while maintaining CBOR encoding, EDHOC represents certain identifiers as CBOR integers on the wire; see Section 3.3.2.
EDHOCにおける接続識別子は本質的にバイト文字列です。ほとんどの制約のあるデバイスは、短い識別子で十分な接続しか持っていません。一部の場合、オーバーヘッド要件を満たすために最小長の識別子が必要です。ただし、CBORバイト文字列は、空のバイト文字列h''を除いて、2バイト以上でエンコードされます。特定のバイト文字列を1バイトでエンコードするために、CBORエンコーディングを維持しながら、EDHOCはワイヤ上で特定の識別子をCBOR整数として表現します。セクション3.3.2を参照してください。
C_I and C_R are chosen by I and R, respectively. The Initiator selects C_I and sends it in message_1 for the Responder to use as a reference to the connection in communications with the Initiator. The Responder selects C_R and sends it in message_2 for the Initiator to use as a reference to the connection in communications with the Responder.
C_IとC_Rは、それぞれIとRによって選択されます。イニシエータはC_Iを選択し、それをメッセージ1でレスポンダに送信して、イニシエータとの通信における接続の参照として使用します。レスポンダはC_Rを選択し、それをメッセージ2でイニシエータに送信して、レスポンダとの通信における接続の参照として使用します。
If connection identifiers are used by an application protocol for which EDHOC establishes keys, then the selected connection identifiers SHALL adhere to the requirements for that protocol; see Section 3.3.3 for an example.
EDHOCがキーを確立するアプリケーションプロトコルで接続識別子が使用される場合、選択された接続識別子はそのプロトコルの要件に従う必要があります。例についてはセクション3.3.3を参照してください。
To allow identifiers with minimal overhead on the wire, certain byte strings used in connection identifiers and credential identifiers (see Section 3.5.3) are defined to have integer representations.
ワイヤー上でのオーバーヘッドを最小限に抑えるために、接続識別子および資格情報識別子で使用される特定のバイト文字列には整数表現が定義されています。
The integers with one-byte CBOR encoding are -24, ..., 23; see Figure 3.
1バイトのCBORエンコーディングを持つ整数は、-24から23までです。図3を参照してください。
Integer: -24 -23 ... -11 ... -2 -1 0 1 ... 15 ... 23
Encoding: 37 36 ... 2A ... 21 20 00 01 ... 0F ... 17
Figure 3: One-Byte CBOR-Encoded Integers
図3：1バイトのCBOR符号化整数
The byte strings that coincide with a one-byte CBOR encoding of an integer MUST be represented by the CBOR encoding of that integer. Other byte strings are simply encoded as CBOR byte strings.
整数の1バイトのCBORエンコーディングと一致するバイト文字列は、その整数のCBORエンコーディングで表現されなければなりません。他のバイト文字列は単純にCBORバイト文字列としてエンコードされます。
For example:
例えば：
* 0x21 is represented by 0x21 (CBOR encoding of the integer -2), not by 0x4121 (CBOR encoding of the byte string 0x21).
* 0x21は0x21で表されます（整数-2のCBORエンコーディング）、0x4121ではありません（バイト文字列0x21のCBORエンコーディング）。
* 0x0D is represented by 0x0D (CBOR encoding of the integer 13), not by 0x410D (CBOR encoding of the byte string 0x0D).
* 0x0D は整数 13 の CBOR エンコーディングである 0x0D で表されます。バイト列 0x0D の CBOR エンコーディングである 0x410D ではありません。
* 0x18 is represented by 0x4118 (CBOR encoding of the byte string 0x18).
* 0x18 は 0x4118 で表されます（0x18 のバイトストリングの CBOR エンコーディング）。
* 0x38 is represented by 0x4138 (CBOR encoding of the byte string 0x38).
* 0x38 は 0x4138 で表されます（0x38 のバイトストリングの CBOR エンコーディング）。
* 0xABCD is represented by 0x42ABCD (CBOR encoding of the byte string 0xABCD).
* 0xABCD は 0x42ABCD で表されます（0xABCD のバイト文字列の CBOR エンコーディング）。
One may view this representation of byte strings as a transport encoding, i.e., a byte string that parses as the one-byte CBOR encoding of an integer (i.e., integer in the interval -24, ..., 23) is just copied directly into the message, and a byte string that does not is encoded as a CBOR byte string during transport.
この表現は、輸送エンコーディングとしてバイト文字列を見ることができます。つまり、整数の1バイトのCBORエンコーディングとして解析されるバイト文字列（つまり、-24から23の間の整数）は、そのままメッセージにコピーされ、解析されないバイト文字列は輸送中にCBORバイト文字列としてエンコードされます。
Implementation Note: When implementing the byte string identifier representation, in some programming languages, it can help to define a new type or other data structure, which (in its user-facing API) behaves like a byte string but when serializing to CBOR produces a CBOR byte string or a CBOR integer depending on its value.
実装ノート：バイト文字列識別子表現を実装する際には、いくつかのプログラミング言語では、新しいタイプや他のデータ構造を定義すると役立つことがあります。これらは、ユーザーに対してはバイト文字列のように振る舞いますが、CBOR にシリアル化する際には、その値に応じて CBOR バイト文字列または CBOR 整数を生成します。
For OSCORE, the choice of connection identifier results in the endpoint selecting its Recipient ID (see Section 3.1 of [RFC8613]) for which certain uniqueness requirements apply (see Section 3.3 of [RFC8613]). Therefore, the Initiator and Responder MUST NOT select connection identifiers such that it results in the same OSCORE Recipient ID. Since the connection identifier is a byte string, it is converted to an OSCORE Recipient ID equal to the byte string.
OSCOREにおいて、接続識別子の選択により、エンドポイントはその受信者ID（[RFC8613]のセクション3.1を参照）を選択します。この受信者IDには特定の一意性要件が適用されます（[RFC8613]のセクション3.3を参照）。したがって、イニシエータとレスポンダは、同じOSCORE受信者IDになるような接続識別子を選択してはいけません。接続識別子はバイト文字列であるため、それはバイト文字列と等しいOSCORE受信者IDに変換されます。
Examples:
例:
* A connection identifier 0xFF (represented in the EDHOC message as 0x41FF; see Section 3.3.2) is converted to the OSCORE Recipient ID 0xFF.
* 接続識別子0xFF（EDHOCメッセージ中の0x41FFとして表される；セクション3.3.2を参照）はOSCORE受信者ID 0xFFに変換されます。
* A connection identifier 0x21 (represented in the EDHOC message as 0x21; see Section 3.3.2) is converted to the OSCORE Recipient ID 0x21.
* 接続識別子0x21（EDHOCメッセージ中の0x21として表される；セクション3.3.2を参照）はOSCORE受信者ID 0x21に変換されます。
Cryptographically, EDHOC does not put requirements on the underlying layers. Received messages are processed as the expected next message according to the protocol state; see Section 5. If processing fails for any reason, then typically an error message is attempted to be sent and the EDHOC session is aborted.
暗号的に、EDHOCは基礎となるレイヤーに要件を課しません。 受信したメッセージは、プロトコルの状態に応じて期待される次のメッセージとして処理されます。処理が失敗した場合、通常はエラーメッセージが送信され、EDHOCセッションが中止されます。
EDHOC is not bound to a particular transport layer and can even be used in environments without IP. Ultimately, the application is free to choose how to transport EDHOC messages including errors. In order to avoid unnecessary message processing or protocol termination, it is RECOMMENDED to use reliable transport, such as CoAP in reliable mode, which is the default transport; see Appendix A.2. In general, the transport SHOULD handle:
EDHOCは特定のトランスポート層に拘束されず、IPのない環境でも使用できます。最終的に、アプリケーションはEDHOCメッセージをどのように転送するかを自由に選択できます。不要なメッセージ処理やプロトコルの終了を避けるためには、信頼性のあるトランスポート、例えば信頼性モードのCoAPを使用することが推奨されます。これはデフォルトのトランスポートです。一般的に、トランスポートは次のように処理すべきです。
* message loss,
* メッセージの損失
* message duplication (see Section 7 for an alternative),
* メッセージの複製（代替手段についてはセクション7を参照してください）
* flow control,
* フロー制御
* congestion control,
* 輻輳制御
* fragmentation and reassembly,
* 断片化と再構築、
* demultiplexing EDHOC messages from other types of messages,
* 他の種類のメッセージからEDHOCメッセージをデマルチプレクシングする、
* denial-of-service mitigation, and
* サービス拒否攻撃の緩和、および
* message correlation (see Section 3.4.1).
* メッセージ相関（セクション3.4.1を参照）。
EDHOC does not require error-free transport since a change in message content is detected through the transcript hashes in a subsequent integrity verification; see Section 5. The transport does not require additional means to handle message reordering because of the lockstep processing of EDHOC.
EDHOCは、メッセージ内容の変更が後続の整合性検証で検出されるため、エラーのない輸送を必要としません。EDHOCのロックステップ処理により、メッセージの再順序処理に追加手段が必要ありません。
EDHOC is designed to enable an authenticated key exchange with small messages, where the minimum message sizes are of the order illustrated in the first column of Table 1. There is no maximum message size specified by the protocol; for example, this is dependent on the size of the authentication credentials (if they are transported, see Section 3.5). The encryption of very large content in message_2 when using certain hash algorithms is described in Appendix G.
EDHOCは、最小メッセージサイズが表1の最初の列に示されているオーダーで小さなメッセージを使用した認証キー交換を可能にするよう設計されています。プロトコルで指定された最大メッセージサイズはありません。たとえば、これは認証資格情報のサイズに依存します（それらが転送される場合は、セクション3.5を参照）。特定のハッシュアルゴリズムを使用する場合、message_2で非常に大きなコンテンツの暗号化が付録Gに記載されています。
The use of transport is specified in the application profile, which in particular, may specify limitations in message sizes; see Section 3.9.
輸送手段の使用は、特にメッセージサイズの制限を指定する場合があります。セクション3.9を参照してください。
Correlation between EDHOC messages is needed to facilitate the retrieval of the protocol state and security context during an EDHOC session. It is also helpful for the Responder to get an indication that a received EDHOC message is the beginning of a new EDHOC session, such that no existing protocol state or security context needs to be retrieved.
EDHOC メッセージ間の相関は、EDHOC セッション中にプロトコルの状態とセキュリティコンテキストの取得を容易にするために必要です。また、受信した EDHOC メッセージが新しい EDHOC セッションの開始であることを示すことは、レスポンダにとっても役立ちます。
Correlation may be based on existing mechanisms in the transport protocol; for example, the CoAP Token may be used to correlate EDHOC messages in a CoAP response and in an associated CoAP request. The connection identifiers may also be used to correlate EDHOC messages.
相関は、輸送プロトコル内の既存のメカニズムに基づいている可能性があります。たとえば、CoAP トークンは、CoAP レスポンス内の EDHOC メッセージと関連する CoAP リクエスト内の EDHOC メッセージを相関させるために使用されるかもしれません。接続識別子も、EDHOC メッセージを相関させるために使用されるかもしれません。
If correlation between consecutive messages is not provided by other means, then the transport binding SHOULD mandate prepending of an appropriate connection identifier (when available from the EDHOC protocol) to the EDHOC message. If message_1 indication is not provided by other means, then the transport binding SHOULD mandate prepending of message_1 with the CBOR simple value true (0xf5).
もし連続するメッセージ間の相関が他の手段で提供されていない場合、輸送バインディングはEDHOCプロトコルから利用可能な適切な接続識別子をEDHOCメッセージに先頭に付加することを要求すべきです。もしmessage_1の指示が他の手段で提供されていない場合、輸送バインディングはmessage_1にCBORの単純な値true（0xf5）を先頭に付加することを要求すべきです。
Transport of EDHOC in CoAP payloads is described in Appendix A.2, including how to use connection identifiers and message_1 indication with CoAP. A similar construction is possible for other client-server protocols. Protocols that do not provide any correlation at all can prescribe prepending of the peer's connection identifier to all messages.
EDHOCのCoAPペイロードでの輸送方法は、付録A.2に記載されており、接続識別子とCoAPでのmessage_1 indicationの使用方法も含まれています。他のクライアント-サーバープロトコルに対しても同様の構築が可能です。相関性を提供しないプロトコルは、すべてのメッセージの先頭にピアの接続識別子を付加することを規定できます。
Note that correlation between EDHOC messages may be obtained without transport support or connection identifiers, for example, if the endpoints only accept a single instance of the protocol at a time and execute conditionally on a correct sequence of messages.
EDHOCメッセージ間の相関は、輸送サポートや接続識別子なしに取得できることに注意してください。たとえば、エンドポイントが一度にプロトコルの単一のインスタンスのみを受け入れ、メッセージの正しいシーケンスに応じて条件付きで実行する場合があります。
EDHOC supports various settings for how the other endpoint's public key for authentication may be transported, identified, and trusted. We shall use the term "authentication key" to mean key used for authentication in general, or specifically, the public key, when there is no risk for confusion.
EDHOCは、他のエンドポイントの認証用の公開鍵を輸送、識別、信頼する方法に関するさまざまな設定をサポートしています。混乱のリスクがない場合、一般的な認証に使用される鍵、または特に公開鍵を意味する用語として「認証鍵」という用語を使用します。
EDHOC performs the following authentication-related operations:
EDHOCは次の認証関連の操作を実行します。
* EDHOC transports information about credentials in ID_CRED_I and ID_CRED_R (described in Section 3.5.3). Based on this information, the authentication credentials CRED_I and CRED_R (described in Section 3.5.2) can be obtained. EDHOC may also transport certain authentication-related information as external authorization data (see Section 3.8).
* EDHOCは、ID_CRED_IおよびID_CRED_Rに関する資格情報に関する情報を転送します（セクション3.5.3で説明）。この情報に基づいて、認証資格情報CRED_IおよびCRED_R（セクション3.5.2で説明）を取得できます。EDHOCは、外部認証データとして特定の認証関連情報も転送する場合があります（セクション3.8を参照）。
* EDHOC uses the authentication credentials in two ways (see Sections 5.3.2 and 5.4.2):
* EDHOCは認証資格情報を2つの方法で使用します（セクション5.3.2および5.4.2を参照）。
- The authentication credential is input to the integrity verification using the MAC fields.
- 認証資格情報はMACフィールドを使用して整合性検証に入力されます。
- The authentication key of the authentication credential is used with the Signature_or_MAC field to verify proof-of-possession of the private key.
- 認証資格情報の認証キーは、Signature_or_MACフィールドと共に使用され、秘密鍵の所持の証明を検証します。
Other authentication-related verifications are out of scope for EDHOC and are the responsibility of the application. In particular, the authentication credential needs to be validated in the context of the connection for which EDHOC is used; see Appendix D. EDHOC MUST allow the application to read received information about credentials in ID_CRED_R and ID_CRED_I. EDHOC MUST have access to the authentication key and the authentication credential.
EDHOC に関連する他の認証関連の検証は対象外であり、アプリケーションの責任です。特に、認証資格情報は、EDHOC が使用される接続のコンテキストで検証する必要があります。受信した ID_CRED_R および ID_CRED_I の資格情報に関する情報をアプリケーションが読むことを EDHOC は許可しなければなりません。EDHOC は認証キーと認証資格情報にアクセスする必要があります。
Note that the type of authentication key, the type of authentication credential, and the identification of the credential have a large impact on the message size. For example, the Signature_or_MAC field is much smaller with a static DH key than with a signature key. A CWT Claims Set (CCS) is much smaller than a self-signed certificate / CWT, but if it is possible to reference the credential with a COSE header like 'kid', then that is in turn much smaller than a CCS.
注意してください。認証キーのタイプ、認証資格情報のタイプ、および資格情報の識別は、メッセージサイズに大きな影響を与えます。例えば、Signature_or_MACフィールドは、署名キーと比較して、静的DHキーの場合ははるかに小さくなります。CWT Claims Set（CCS）は、自己署名証明書/CWTよりもはるかに小さくなりますが、COSEヘッダーのような 'kid' で資格情報を参照できる場合、それはCCSよりもはるかに小さくなります。
The authentication key MUST be a signature key or a static Diffie-Hellman key. The Initiator and Responder MAY use different types of authentication keys, e.g., one uses a signature key and the other uses a static Diffie-Hellman key.
認証キーは署名キーまたは静的ディフィー・ヘルマンキーである必要があります。イニシエーターとレスポンダーは異なる種類の認証キーを使用することができます。例えば、片方が署名キーを使用し、もう片方が静的ディフィー・ヘルマンキーを使用することがあります。
The authentication key algorithm needs to be compatible with the method and the selected cipher suite (see Section 3.6). The authentication key algorithm needs to be compatible with the EDHOC key exchange algorithm when static Diffie-Hellman authentication is used and compatible with the EDHOC signature algorithm when signature authentication is used.
認証キーのアルゴリズムは、選択された暗号スイートとメソッドと互換性が必要です（セクション3.6を参照）。静的Diffie-Hellman認証が使用される場合は、認証キーのアルゴリズムはEDHOC鍵交換アルゴリズムと互換性が必要であり、署名認証が使用される場合はEDHOC署名アルゴリズムと互換性が必要です。
Note that for most signature algorithms, the signature is determined jointly by the signature algorithm and the authentication key algorithm. When using static Diffie-Hellman keys, the Initiator's and the Responder's private authentication keys are denoted as I and R, respectively, and the public authentication keys are denoted G_I and G_R, respectively.
ほとんどの署名アルゴリズムでは、署名は署名アルゴリズムと認証キーのアルゴリズムによって共同で決定されます。静的Diffie-Hellmanキーを使用する場合、イニシエーターとレスポンダーのプライベート認証キーはそれぞれIとRと表され、公開認証キーはそれぞれG_IとG_Rと表されます。
For X.509 certificates, the authentication key is represented by a SubjectPublicKeyInfo field, which also contains information about authentication key algorithm. For CWT and CCS (see Section 3.5.2), the authentication key is represented by a 'cnf' claim [RFC8747] containing a COSE_Key [RFC9052], which contains information about authentication key algorithm. In EDHOC, a raw public key (RPK) is an authentication key encoded as a COSE_Key wrapped in a CCS, an example is given in Figure 4.
X.509証明書の場合、認証キーはSubjectPublicKeyInfoフィールドによって表され、認証キーアルゴリズムに関する情報も含まれています。CWTおよびCCS（セクション3.5.2を参照）の場合、認証キーはCOSE_Key [RFC9052]を含む'cnf'クレーム[RFC8747]によって表され、認証キーアルゴリズムに関する情報が含まれています。EDHOCでは、COSE_Keyでエンコードされた認証キーである生の公開鍵（RPK）がCCSでラップされています。図4に例が示されています。
The authentication credentials, CRED_I and CRED_R, contain the public authentication key of the Initiator and Responder, respectively. We use the notation CRED_x to refer to CRED_I or CRED_R. Requirements on CRED_x applies both to CRED_I and to CRED_R. The authentication credential typically also contains other parameters that needs to be verified by the application (see Appendix D) and in particular information about the identity ("subject") of the endpoint to prevent misbinding attacks (see Appendix D.2).
認証資格情報であるCRED_IとCRED_Rには、それぞれイニシエーターとレスポンダーの公開認証キーが含まれています。CRED_xという表記法を使用して、CRED_IまたはCRED_Rを参照します。CRED_xに関する要件は、CRED_IとCRED_Rの両方に適用されます。認証資格情報には通常、アプリケーションによって検証される他のパラメータも含まれています（付録Dを参照）。特に、エンドポイントの識別（"subject"）に関する情報が含まれており、誤ったバインディング攻撃を防ぐために使用されます（付録D.2を参照）。
EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example, X.509 certificates [RFC9360], C509 certificates [C509-CERTS], CWTs [RFC8392], and CCSs [RFC8392]. When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT. In the choice between a chain or a bag, it is RECOMMENDED to use a chain, since the certificates in a bag are unordered and may contain self-signed and extraneous certificates, which can add complexity to the process of extracting the end entity certificate. The Initiator and Responder MAY use different types of authentication credentials, e.g., one uses an RPK and the other uses a public key certificate.
EDHOCは、資格情報の識別にCOSEを使用しています（セクション3.5.3を参照）。たとえば、X.509証明書[RFC9360]、C509証明書[C509-CERTS]、CWT[RFC8392]、およびCCS[RFC8392]などがあります。識別された資格情報がチェーンまたはバッグの場合、認証資格情報CRED_xは単なるエンドエンティティX.509またはC509証明書/CWTです。チェーンまたはバッグの選択肢の間で、チェーンを使用することが推奨されています。なぜなら、バッグ内の証明書は順序付けされておらず、自己署名や余分な証明書が含まれている可能性があり、エンドエンティティ証明書を抽出するプロセスに複雑さを加える可能性があるためです。イニシエーターとレスポンダーは、異なる種類の認証資格情報を使用する場合があります。たとえば、1つはRPKを使用し、もう1つは公開鍵証明書を使用します。
Since CRED_R is used in the integrity verification (see Section 5.3.2), it needs to be specified such that it is identical when used by the Initiator or Responder. Similarly for CRED_I, see Section 5.4.2. The Initiator and Responder are expected to agree on the specific encoding of the authentication credentials; see Section 3.9. It is RECOMMENDED that the COSE 'kid' parameter, when used to identify the authentication credential, refers to such a specific encoding of the authentication credential. The Initiator and Responder SHOULD use an available authentication credential without re-encoding, i.e. an authentication credential transported in EDHOC by value, or otherwise provisioned, SHOULD be used as is. If for some reason re-encoding of an authentication credential passed by reference may occur, then a potential common encoding for CBOR-based credentials is deterministically encoded CBOR, as specified in Sections 4.2.1 and 4.2.2 of [RFC8949].
CRED_R は整合性検証で使用されるため（セクション5.3.2を参照）、イニシエータまたはレスポンダが使用する際に同一である必要があります。同様に、CRED_I についてもセクション5.4.2を参照してください。イニシエータとレスポンダは、認証資格情報の特定のエンコーディングに合意することが期待されます。認証資格情報を識別するために COSE の 'kid' パラメータを使用する場合、その認証資格情報の特定のエンコーディングを参照するように推奨されます。イニシエータとレスポンダは、利用可能な認証資格情報を再エンコードせずに使用するべきです。つまり、EDHOC によって値で転送される認証資格情報、または他の方法で供給された認証資格情報はそのまま使用されるべきです。参照によって渡された認証資格情報の再エンコードが発生する可能性がある場合、CBOR ベースの認証資格情報のための潜在的な共通エンコーディングは、[RFC8949]のセクション4.2.1および4.2.2で指定されているように、決定的にエンコードされた CBOR です。
* When the authentication credential is an X.509 certificate, CRED_x SHALL be the DER-encoded certificate, encoded as a bstr [RFC9360].
* 認証資格情報がX.509証明書である場合、CRED_xはDERエンコードされた証明書である必要があり、bstr [RFC9360]としてエンコードされます。
* When the authentication credential is a C509 certificate, CRED_x SHALL be the C509 certificate [C509-CERTS].
* 認証資格情報がC509証明書の場合、CRED_xはC509証明書である必要があります。
* When the authentication credential is a CWT including a COSE_Key, CRED_x SHALL be the untagged CWT.
* 認証資格情報がCOSE_Keyを含むCWTの場合、CRED_xはタグのないCWTであるべきです。
* When the authentication credential includes a COSE_Key but is not in a CWT, CRED_x SHALL be an untagged CCS. This is how RPKs are encoded, see Figure 4 for an example.
* 認証資格情報に COSE_Key が含まれているが CWT に含まれていない場合、CRED_x はタグなしの CCS であるべきです。これが RPK がエンコードされる方法です。例については図4を参照してください。
- Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in its simplest form by prefixing the COSE_Key with 0xA108A101 (a map with a 'cnf' claim). In that case, the resulting authentication credential contains no other identity than the public key itself; see Appendix D.2.
- 裸のCOSE_Keysは、EDHOCで使用される際に、COSE_Keyを0xA108A101（'cnf'クレームを持つマップ）で接頭辞付けすることで、CCSとして着飾られます。 その場合、認証資格情報には公開鍵自体以外のアイデンティティは含まれません。Appendix D.2を参照してください。
An example of CRED_x is shown below:
CRED_xの例を以下に示します。
{ /CCS/
2 : "42-50-31-FF-EF-37-32-39", /sub/
8 : { /cnf/
1 : { /COSE_Key/
1 : 1, /kty/
2 : h'00', /kid/
-1 : 4, /crv/
-2 : h'b1a3e89460e88d3a8d54211dc95f0b90 /x/
3ff205eb71912d6db8f4af980d2db83a'
}
}
}
Figure 4: CCS Containing an X25519 Static Diffie-Hellman Key and an EUI-64 Identity
図4：X25519静的ディフィー・ヘルマン鍵とEUI-64識別子を含むCCS
The ID_CRED fields, ID_CRED_R and ID_CRED_I, are transported in message_2 and message_3, respectively; see Sections 5.3.2 and 5.4.2. We use the notation ID_CRED_x to refer to ID_CRED_I or ID_CRED_R. Requirements on ID_CRED_x applies both to ID_CRED_I and to ID_CRED_R. The ID_CRED fields are used to identify and optionally transport credentials:
ID_CREDフィールド、ID_CRED_R、およびID_CRED_Iは、それぞれmessage_2およびmessage_3で転送されます。セクション5.3.2および5.4.2を参照してください。私たちは、ID_CRED_xという表記法を使用して、ID_CRED_IまたはID_CRED_Rを参照します。ID_CRED_xに関する要件は、ID_CRED_IおよびID_CRED_Rの両方に適用されます。ID_CREDフィールドは、資格情報を識別およびオプションで転送するために使用されます。
* ID_CRED_R is intended to facilitate for the Initiator retrieving the authentication credential CRED_R and the authentication key of R.
* ID_CRED_Rは、イニシエーターが認証資格情報CRED_RとRの認証キーを取得するのを容易にすることを意図しています。
* ID_CRED_I is intended to facilitate for the Responder retrieving the authentication credential CRED_I and the authentication key of I.
* ID_CRED_Iは、レスポンダーが認証資格情報CRED_IとIの認証キーを取得するのを容易にすることを意図しています。
ID_CRED_x may contain the authentication credential CRED_x, for x = I or R, but for many settings, it is not necessary to transport the authentication credential within EDHOC. For example, it may be pre-provisioned or acquired out-of-band over less constrained links. ID_CRED_I and ID_CRED_R do not have any cryptographic purpose in EDHOC since the authentication credentials are integrity protected by the Signature_or_MAC field.
ID_CRED_x には、x = I または R の場合、認証資格情報 CRED_x が含まれている可能性がありますが、多くの設定では EDHOC 内で認証資格情報を転送する必要はありません。たとえば、事前に設定されたり、制約の少ないリンクを介して帯域外で取得されたりする場合があります。ID_CRED_I と ID_CRED_R は、認証資格情報が Signature_or_MAC フィールドによって整合性保護されているため、EDHOC においては暗号目的を持ちません。
EDHOC relies on COSE for identification of credentials and supports all credential types for which COSE header parameters are defined, including X.509 certificates [RFC9360], C509 certificates [C509-CERTS], CWTs (Section 3.5.3.1) and CCSs (Section 3.5.3.1).
EDHOCは、資格情報の識別にCOSEを依存し、COSEヘッダーパラメータが定義されているすべての資格情報タイプをサポートしています。これには、X.509証明書[RFC9360]、C509証明書[C509-CERTS]、CWT（セクション3.5.3.1）およびCCS（セクション3.5.3.1）が含まれます。
ID_CRED_I and ID_CRED_R are of type COSE header_map, as defined in Section 3 of [RFC9052], and contain one or more COSE header parameters. If a map contains several header parameters, the labels do not need to be sorted in bytewise lexicographic order. ID_CRED_I and ID_CRED_R MAY contain different header parameters. The header parameters typically provide some information about the format of the credential.
ID_CRED_IとID_CRED_Rは[RFC9052]のセクション3で定義されているCOSE header_map型であり、1つ以上のCOSEヘッダーパラメータを含んでいます。もしマップが複数のヘッダーパラメータを含む場合、ラベルはバイト単位の辞書順に並べる必要はありません。ID_CRED_IとID_CRED_Rには異なるヘッダーパラメータが含まれている可能性があります。ヘッダーパラメータは通常、資格情報の形式に関する情報を提供します。
Example: X.509 certificates can be identified by a hash value using the 'x5t' parameter; see Section 2 of [RFC9360]:
X.509証明書は、'x5t'パラメータを使用してハッシュ値で識別できます。[RFC9360]のセクション2を参照してください。
* ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R
* ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R
(ID_CRED_x = { 34 : COSE_CertHash }, x = IまたはRの場合)
Example: CWT or CCS can be identified by a key identifier using the 'kid' parameter; see Section 3.1 of [RFC9052]:
CWTまたはCCSは、'kid'パラメータを使用してキー識別子で識別できます。[RFC9052]のセクション3.1を参照してください。
* ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R
* ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R
ID_CRED_x = { 4 : kid_x }、ここで kid_x : kid、x = I または R の場合
Note that COSE header parameters in ID_CRED_x are used to identify the message sender's credential. Therefore, there is no reason to use the "-sender" header parameters, such as x5t-sender, defined in Section 3 of [RFC9360]. Instead, the corresponding parameter without "-sender", such as x5t, SHOULD be used.
ID_CRED_x内のCOSEヘッダーパラメータは、メッセージ送信者の資格情報を識別するために使用されます。そのため、x5t-senderなどの"-sender"ヘッダーパラメータを使用する理由はありません。[RFC9360]のセクション3で定義されている代わりに、"-sender"を含まない対応するパラメータ、例えばx5t、を使用するべきです。
As stated in Section 3.1 of [RFC9052], applications MUST NOT assume that 'kid' values are unique and several keys associated with a 'kid' may need to be checked before the correct one is found. Applications might use additional information such as 'kid context' or lower layers to determine which key to try first. Applications should strive to make ID_CRED_x as unique as possible, since the recipient may otherwise have to try several keys.
[RFC9052]のセクション3.1に記載されているように、アプリケーションは 'kid' の値が一意であるとは仮定してはならず、'kid' に関連付けられた複数のキーをチェックする必要があるかもしれません。アプリケーションは、'kid context' や下位レイヤーなどの追加情報を使用して、最初に試すべきキーを決定することがあります。受信者が複数のキーを試す必要がある場合があるため、アプリケーションはID_CRED_xを可能な限り一意にするよう努めるべきです。
See Appendix C.3 for more examples.
より多くの例については付録C.3を参照してください。
This document registers two new COSE header parameters, 'kcwt' and 'kccs', for use with CBOR Web Token (CWT) [RFC8392] and CWT Claims Set (CCS) [RFC8392], respectively. The CWT/CCS MUST contain a COSE_Key in a 'cnf' claim [RFC8747]. There may be any number of additional claims present in the CWT/CCS.
この文書は、CBOR Web Token（CWT）[RFC8392]およびCWT Claims Set（CCS）[RFC8392]で使用するための2つの新しいCOSEヘッダーパラメータ、「kcwt」と「kccs」を登録します。CWT/CCSには、それぞれCOSE_Keyを含む必要があります（'cnf' claim [RFC8747]）。CWT/CCSには、追加のクレームが任意の数含まれる可能性があります。
CWTs sent in 'kcwt' are protected using a MAC or a signature and are similar to a certificate (when used with public key cryptography) or a Kerberos ticket (when used with symmetric key cryptography). CCSs sent in 'kccs' are not protected and are therefore similar to raw public keys or self-signed certificates.
'kcwt' で送信される CWT は MAC または署名を使用して保護され、公開鍵暗号を使用する場合は証明書に類似し、対称鍵暗号を使用する場合は Kerberos チケットに類似します。一方、'kccs' で送信される CCS は保護されず、そのため生の公開鍵や自己署名証明書に類似します。
Security considerations for 'kcwt' and 'kccs' are made in Section 9.8.
セクション9.8で、'kcwt'と'kccs'のセキュリティに関する考慮事項が述べられています。
To comply with the Lightweight Authenticated Key Exchange (LAKE) message size requirements (see [LAKE-REQS]), two optimizations are made for the case when ID_CRED_x, for x = I or R, contains a single 'kid' parameter.
Lightweight Authenticated Key Exchange（LAKE）メッセージサイズ要件（[LAKE-REQS]を参照）に準拠するために、ID_CRED_x（x = IまたはRの場合）に単一の 'kid' パラメータが含まれている場合には、2つの最適化が行われます。
1. The CBOR map { 4 : kid_x } is replaced by the byte string kid_x.
1. CBOR マップ { 4 : kid_x } はバイト文字列 kid_x に置き換えられます。
2. The representation of identifiers specified in Section 3.3.2 is applied to kid_x.
2. Section 3.3.2 で指定された識別子の表現は、kid_x に適用されます。
These optimizations MUST be applied if and only if ID_CRED_x = { 4 : kid_x } and ID_CRED_x in PLAINTEXT_y of message_y, y = 2 or 3; see Sections 5.3.2 and 5.4.2. Note that these optimizations are not applied to instances of ID_CRED_x that have no impact on message size, e.g., context_y, or the COSE protected header. For example:
これらの最適化は、ID_CRED_x = { 4 : kid_x } かつ ID_CRED_x がメッセージ_yのPLAINTEXT_yに含まれる場合にのみ適用されます。y = 2 または 3 の場合に該当します。セクション 5.3.2 および 5.4.2 を参照してください。これらの最適化は、メッセージサイズに影響を与えない ID_CRED_x のインスタンスには適用されません。例えば、context_y や COSE 保護ヘッダーなどです。
* For ID_CRED_x = { 4 : h'FF' }, the encoding in PLAINTEXT_y is not the CBOR map 0xA10441FF but the CBOR byte string h'FF', i.e., 0x41FF.
* ID_CRED_x = { 4 : h'FF' }の場合、PLAINTEXT_yでのエンコーディングはCBORマップ0xA10441FFではなく、CBORバイトストリングh'FF'、つまり0x41FFです。
* For ID_CRED_x = { 4 : h'21' }, the encoding in PLAINTEXT_y is neither the CBOR map 0xA1044121 nor the CBOR byte string h'21', i.e., 0x4121, but the CBOR integer 0x21.
* ID_CRED_x = { 4 : h'21' } に対して、PLAINTEXT_y でのエンコーディングは、CBOR マップ 0xA1044121 でも CBOR バイトストリング h'21' でもなく、CBOR 整数 0x21 です。
An EDHOC cipher suite consists of an ordered set of algorithms from the "COSE Algorithms" and "COSE Elliptic Curves" registries as well as the EDHOC MAC length. All algorithm names and definitions follow COSE Algorithms [RFC9053]. Note that COSE sometimes uses peculiar names such as ES256 for Elliptic Curve Digital Signature Algorithm (ECDSA) with SHA-256, A128 for AES-128, and Ed25519 for the curve edwards25519. Algorithms need to be specified with enough parameters to make them completely determined. The EDHOC MAC length MUST be at least 8 bytes. Any cryptographic algorithm used in the COSE header parameters in ID_CRED fields is selected independently of the selected cipher suite. EDHOC is currently only specified for use with key exchange algorithms of type ECDH curves, but any Key Encapsulation Mechanism (KEM), including Post-Quantum Cryptography (PQC) KEMs, can be used in method 0; see Section 9.4. Use of other types of key exchange algorithms to replace static DH authentication (methods 1, 2, and 3) would likely require a specification updating EDHOC with new methods.
EDHOCサイファースイートは、「COSE Algorithms」と「COSE Elliptic Curves」レジストリからのアルゴリズムの順序付きセットとEDHOC MAC長から構成されます。すべてのアルゴリズム名と定義はCOSE Algorithms [RFC9053] に従います。COSEは、時折、ES256（SHA-256を使用した楕円曲線デジタル署名アルゴリズム（ECDSA）のためのもの）、A128（AES-128のためのもの）、Ed25519（edwards25519曲線のためのもの）など、独特な名前を使用します。アルゴリズムは、それらを完全に決定するために十分なパラメータで指定する必要があります。EDHOC MAC長は少なくとも8バイトである必要があります。ID_CREDフィールドのCOSEヘッダパラメータで使用される暗号アルゴリズムは、選択されたサイファースイートとは独立して選択されます。EDHOCは現在、ECDH曲線タイプの鍵交換アルゴリズムとの使用についてのみ指定されていますが、Post-Quantum Cryptography（PQC）KEMを含む任意のKey Encapsulation Mechanism（KEM）をメソッド0で使用することができます。他の種類の鍵交換アルゴリズムを使用して静的DH認証（methods 1、2、および3）を置き換える場合、おそらく新しい方法でEDHOCを更新する仕様が必要になるでしょう。
EDHOC supports all signature algorithms defined by COSE. Just like in (D)TLS 1.3 [RFC8446] [RFC9147] and IKEv2 [RFC7296], a signature in COSE is determined jointly by the signature algorithm and the authentication key algorithm; see Section 3.5.1. The exact details of the authentication key algorithm depend on the type of authentication credential. COSE supports different formats for storing the public authentication keys including COSE_Key and X.509, which use different names and ways to represent the authentication key and the authentication key algorithm.
EDHOCはCOSEで定義されたすべての署名アルゴリズムをサポートしています。COSEにおける署名は、(D)TLS 1.3 [RFC8446] [RFC9147] やIKEv2 [RFC7296] と同様に、署名アルゴリズムと認証キーのアルゴリズムによって共同で決定されます。認証キーのアルゴリズムの詳細は、認証資格情報の種類に依存します。COSEは、COSE_KeyやX.509を含む公開認証キーを格納するための異なる形式をサポートしており、これらは認証キーと認証キーのアルゴリズムを表現するために異なる名前や方法を使用しています。
An EDHOC cipher suite consists of the following parameters:
EDHOCサイファースイートは、次のパラメータで構成されています。
* EDHOC AEAD algorithm,
* EDHOC AEAD アルゴリズム、
* EDHOC hash algorithm,
* EDHOCハッシュアルゴリズム
* EDHOC MAC length in bytes (Static DH),
* EDHOC MAC長（Static DH）
* EDHOC key exchange algorithm (ECDH curve),
* EDHOC鍵交換アルゴリズム（ECDH曲線）、
* EDHOC signature algorithm,
* EDHOC署名アルゴリズム、
* application AEAD algorithm, and
* AEADアルゴリズム、および
* application hash algorithm.
* アプリケーションのハッシュアルゴリズム。
Each cipher suite is identified with a predefined integer label.
各暗号スイートは事前定義された整数ラベルで識別されます。
EDHOC can be used with all algorithms and curves defined for COSE. Implementations can either use any combination of COSE algorithms and parameters to define their own private cipher suite or use one of the predefined cipher suites. Private cipher suites can be identified with any of the four values: -24, -23, -22, and -21. The predefined cipher suites are listed in the IANA registry (Section 10.2) with the initial content outlined here:
EDHOCはCOSEで定義されたすべてのアルゴリズムと曲線と一緒に使用できます。実装は、独自のプライベート暗号スイートを定義するためにCOSEアルゴリズムとパラメータの任意の組み合わせを使用するか、事前定義された暗号スイートの1つを使用できます。プライベート暗号スイートは、-24、-23、-22、-21のいずれかの値で識別できます。事前定義された暗号スイートは、IANAレジストリ（セクション10.2）にリストされており、初期コンテンツはここに概説されています。
* Cipher suites 0-3, based on AES-CCM, are intended for constrained IoT where message overhead is a very important factor. Note that AES-CCM-16-64-128 and AES-CCM-16-128-128 are compatible with the IEEE AES-CCM* mode of operation defined in Annex B of [IEEE.802.15.4-2015].
* AES-CCMに基づくサイファースイート0-3は、メッセージのオーバーヘッドが非常に重要な要素である制約のあるIoT向けです。AES-CCM-16-64-128とAES-CCM-16-128-128は、[IEEE.802.15.4-2015]の付録Bで定義されたIEEE AES-CCM*動作モードと互換性があります。
- Cipher suites 1 and 3 use a larger tag length (128 bits) in EDHOC than in the application AEAD algorithm (64 bits).
- Cipher suites 1 および 3 は、EDHOC においてアプリケーションの AEAD アルゴリズム（64 ビット）よりも大きなタグ長（128 ビット）を使用します。
* Cipher suites 4 and 5, based on ChaCha20, are intended for less constrained applications and only use 128-bit tag lengths.
* Cipher suites 4と5は、ChaCha20に基づいており、制約の少ないアプリケーション向けであり、128ビットのタグ長のみを使用します。
* Cipher suite 6, based on AES-GCM, is for general non-constrained applications. It consists of high-performance algorithms that are widely used in non-constrained applications.
* AES-GCM に基づく Cipher suite 6 は、一般的な非制約アプリケーション向けです。非制約アプリケーションで広く使用されている高性能アルゴリズムから構成されています。
* Cipher suites 24 and 25 are intended for high security applications such as government use and financial applications. These cipher suites do not share any algorithms. Cipher suite 24 consists of algorithms from the Commercial National Security Algorithm (CNSA) 1.0 suite [CNSA].
* 暗号スイート24および25は、政府や金融機関などの高セキュリティアプリケーション向けに設計されています。これらの暗号スイートは、どのアルゴリズムも共有しません。暗号スイート24は、Commercial National Security Algorithm (CNSA) 1.0スイート[CNSA]のアルゴリズムから構成されています。
The different methods (Section 3.2) use the same cipher suites, but some algorithms are not used in some methods. The EDHOC signature algorithm is not used in methods without signature authentication.
異なるメソッド（セクション3.2）は同じ暗号スイートを使用しますが、一部のアルゴリズムは一部のメソッドで使用されていません。EDHOC署名アルゴリズムは、署名認証のないメソッドでは使用されません。
The Initiator needs to have a list of cipher suites it supports in order of preference. The Responder needs to have a list of cipher suites it supports. SUITES_I contains cipher suites supported by the Initiator and formatted and processed as detailed in Section 5.2.1 to secure the cipher suite negotiation. Examples of cipher suite negotiation are given in Section 6.3.2.
イニシエーターは、希望する順にサポートする暗号スイートのリストを持っている必要があります。レスポンダーは、サポートする暗号スイートのリストを持っている必要があります。 SUITES_I には、イニシエーターがサポートする暗号スイートが含まれており、セクション5.2.1で詳細に説明された形式でフォーマットおよび処理され、暗号スイートの交渉を保護します。暗号スイートの交渉の例は、セクション6.3.2に示されています。
The ephemeral public keys in EDHOC (G_X and G_Y) use compact representation of elliptic curve points; see Appendix B. In COSE, compact representation is achieved by formatting the ECDH ephemeral public keys as COSE_Keys of type EC2 or Octet Key Pair (OKP) according to Sections 7.1 and 7.2 of [RFC9053] but only including the 'x' parameter in G_X and G_Y. For Elliptic Curve Keys of type EC2, compact representation MAY be used also in the COSE_Key. COSE always uses compact output for Elliptic Curve Keys of type EC2. If the COSE implementation requires a 'y' parameter, the value y = false or a calculated y-coordinate can be used; see Appendix B.
EDHOCの一時的な公開鍵（G_XとG_Y）は、楕円曲線点のコンパクトな表現を使用します。COSEでは、ECDHの一時的な公開鍵を[RFC9053]のセクション7.1および7.2に従ってEC2型またはOctet Key Pair（OKP）のCOSE_Keysとしてフォーマットすることで、コンパクトな表現が実現されますが、G_XとG_Yには 'x' パラメータのみが含まれます。EC2型の楕円曲線鍵の場合、コンパクトな表現はCOSE_Keyでも使用できます。COSEは常にEC2型の楕円曲線鍵に対してコンパクトな出力を使用します。COSEの実装が 'y' パラメータを必要とする場合、値 y = false または計算されたy座標を使用できます。
In order to reduce round trips and the number of messages or to simplify processing, external security applications may be integrated into EDHOC by transporting authorization-related data in the messages.
外部セキュリティアプリケーションを統合することで、ラウンドトリップやメッセージの数を減らしたり、処理を簡素化したりするために、EDHOCに認可関連データをメッセージで転送することができます。
EDHOC allows processing of external authorization data (EAD) to be defined in a separate specification and sent in dedicated fields of the four EDHOC messages: EAD_1, EAD_2, EAD_3, and EAD_4. EAD is opaque data to EDHOC.
EDHOCは、外部認可データ（EAD）の処理を別の仕様で定義し、4つのEDHOCメッセージの専用フィールドに送信することを可能にします：EAD_1、EAD_2、EAD_3、およびEAD_4。EADはEDHOCにとって不透明なデータです。
Each EAD field, EAD_x, for x = 1, 2, 3, or 4, is a CBOR sequence (see Appendix C.1) consisting of one or more EAD items. EAD item ead is a CBOR sequence of an ead_label and an optional ead_value; see Figure 5 and Appendix C.2 for the CDDL definitions.
各EADフィールド、EAD_x（x = 1、2、3、または4）、は1つ以上のEADアイテムで構成されたCBORシーケンスです（Appendix C.1を参照）。EADアイテムeadは、ead_labelとオプションのead_valueからなるCBORシーケンスです。CDDLの定義については、Figure 5とAppendix C.2を参照してください。
ead = (
ead_label : int,
? ead_value : bstr,
)
Figure 5: EAD Item
図5：EADアイテム
A security application may register one or more EAD labels (see Section 10.5) and specify the associated processing and security considerations. The IANA registry contains the absolute value of the ead_label, |ead_label|; the same ead_value applies independently of the sign of the ead_label.
セキュリティアプリケーションは、1つ以上のEADラベル（セクション10.5を参照）を登録し、関連する処理とセキュリティに関する考慮事項を指定することができます。 IANAレジストリには、ead_labelの絶対値、|ead_label|が含まれており、ead_labelの符号にかかわらず、同じead_valueが適用されます。
An EAD item can be either critical or non-critical, determined by the sign of the ead_label in the EAD item transported in the EAD field. A negative value indicates that the EAD item is critical, and a nonnegative value indicates that the EAD item is non-critical.
EADアイテムは、EADフィールドで輸送されるEADアイテムのead_labelの符号によって、重要または非重要のいずれかになります。負の値はEADアイテムが重要であることを示し、非負の値はEADアイテムが非重要であることを示します。
If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, then the endpoint MUST send an EDHOC error message back as defined in Section 6, and the EDHOC session MUST be aborted. The EAD item specification defines the error processing. A non-critical EAD item can be ignored.
エンドポイントが認識できない重要なEADアイテムを受信した場合、または処理できない情報を含む重要なEADアイテムを受信した場合、そのエンドポイントはセクション6で定義されたEDHOCエラーメッセージを送信し、EDHOCセッションを中止しなければなりません。EADアイテムの仕様にはエラー処理が定義されています。非重要なEADアイテムは無視して構いません。
The security application registering a new EAD item needs to describe under what conditions the EAD item is critical or non-critical, and thus whether the ead_label is used with a negative or positive sign. ead_label = 0 is used for padding; see Section 3.8.1.
セキュリティアプリケーションが新しいEADアイテムを登録する際には、EADアイテムが重要か非重要かを説明し、そのためにead_labelが負の符号と共に使用されるか正の符号と共に使用されるかを示す必要があります。 ead_label = 0 はパディングに使用されます。セクション3.8.1を参照してください。
The security application may define multiple uses of certain EAD items, e.g., the same EAD item may be used in different EDHOC messages. Multiple occurrences of an EAD item in one EAD field may also be specified, but the criticality of the repeated EAD item is expected to be the same.
セキュリティアプリケーションは、特定のEADアイテムの複数の使用方法を定義することができます。例えば、同じEADアイテムが異なるEDHOCメッセージで使用されることがあります。1つのEADフィールド内で複数のEADアイテムの出現も指定できますが、繰り返されるEADアイテムの重要度は同じであることが期待されています。
The EAD fields of EDHOC MUST only be used with registered EAD items; see Section 10.5. Examples of the use of EAD are provided in Appendix E.
EDHOCのEADフィールドは、登録されたEADアイテムのみ使用する必要があります。セクション10.5を参照してください。EADの使用例は付録Eに記載されています。
EDHOC message_1 and the plaintext of message_2, message_3, and message_4 can be padded with the use of the corresponding EAD_x field, for x = 1, 2, 3, or 4. Padding in EAD_1 mitigates amplification attacks (see Section 9.7), and padding in EAD_2, EAD_3, and EAD_4 hides the true length of the plaintext (see Section 9.6). Padding MUST be ignored and discarded by the receiving application.
EDHOCメッセージ1およびメッセージ2、メッセージ3、メッセージ4の平文は、対応するEAD_xフィールド（x = 1、2、3、または4）を使用してパディングすることができます。EAD_1でのパディングは増幅攻撃を緩和します（セクション9.7を参照）、EAD_2、EAD_3、およびEAD_4でのパディングは平文の真の長さを隠します（セクション9.6を参照）。パディングは受信アプリケーションによって無視および破棄される必要があります。
Padding is obtained by using an EAD item with ead_label = 0 and a (pseudo)randomly generated byte string of appropriate length as ead_value, noting that the ead_label and the CBOR encoding of ead_value also add bytes. For example:
パディングは、ead_label = 0 を使用して EAD アイテムを使用し、適切な長さの（疑似）ランダムに生成されたバイト文字列を ead_value として使用することで得られます。なお、ead_label と ead_value の CBOR エンコーディングもバイトを追加します。例えば：
* One-byte padding (optional ead_value omitted):
* 1 バイトのパディング（オプションの ead_value は省略されています）:
EAD_x = 0x00
EAD_x = 0x00
* Two-byte padding, using the empty byte string (0x40) as ead_value:
* 2 バイトのパディング、空のバイト文字列 (0x40) を ead_value として使用します。
EAD_x = 0x0040
EAD_x = 0x0040
* Three-byte padding, constructed from the pseudorandomly generated ead_value 0xe9 encoded as byte string:
* 3バイトのパディング、疑似乱数生成された ead_value 0xe9 をバイト文字列としてエンコードしたもの：
EAD_x = 0x0041e9
EAD_x = 0x0041e9
Multiple occurrences of EAD items with ead_label = 0 are allowed. Certain padding lengths require the use of at least two such EAD items.
特定のパディング長さには、少なくとも2つのこのようなEADアイテムを使用する必要があります。
Note that padding is non-critical because the intended behavior when receiving is to ignore it.
パディングは重要ではないことに注意してください。受信時の意図された動作は、それを無視することです。
EDHOC requires certain parameters to be agreed upon between the Initiator and Responder. Some parameters can be negotiated through the protocol execution (specifically, cipher suite; see Section 3.6), but other parameters are only communicated and may not be negotiated (e.g., which authentication method is used; see Section 3.2). Yet, other parameters need to be known out-of-band to ensure successful completion, e.g., whether message_4 is used or not. The application decides which endpoint is the Initiator and which is the Responder.
EDHOCは、イニシエーターとレスポンダーの間で合意される必要がある特定のパラメータを必要とします。一部のパラメータはプロトコルの実行を通じて交渉されることができます（具体的には、暗号スイートを参照してください3.6節）、しかし、他のパラメータは通信されるのみで交渉されない場合もあります（例：使用される認証方法を参照してください3.2節）。さらに、他のパラメータは、成功裏に完了するためにアウトオブバンドで知られている必要があります。例えば、message_4が使用されるかどうかなどです。アプリケーションは、どちらがイニシエーターであり、どちらがレスポンダーであるかを決定します。
The purpose of an application profile is to describe the intended use of EDHOC to allow for the relevant processing and verifications to be made, including things like the following:
アプリケーションプロファイルの目的は、EDHOCの意図された使用方法を記述し、関連する処理や検証を行うためのものです。
1. How the endpoint detects that an EDHOC message is received. This includes how EDHOC messages are transported, for example, in the payload of a CoAP message with a certain Uri-Path or Content-Format; see Appendix A.2.
1. エンドポイントがEDHOCメッセージを受信したことを検出する方法。これには、EDHOCメッセージがどのように転送されるかが含まれます。たとえば、特定のUri-PathやContent-Formatを持つCoAPメッセージのペイロード内に含まれる場合があります。Appendix A.2を参照してください。
The method of transporting EDHOC messages may also describe data carried along with the messages that are needed for the transport to satisfy the requirements of Section 3.4, e.g., connection identifiers used with certain messages; see Appendix A.2.
EDHOC メッセージを輸送する方法は、メッセージと一緒に運ばれるデータを記述することもでき、これらのデータは輸送がセクション 3.4 の要件を満たすために必要です。たとえば、特定のメッセージで使用される接続識別子などがあります。Appendix A.2 を参照してください。
2. Authentication method (METHOD; see Section 3.2).
2. 認証方法（METHOD; セクション3.2を参照）。
3. Profile for authentication credentials (CRED_I and CRED_R; see Section 3.5.2), e.g., profile for certificate or CCS, including supported authentication key algorithms (subject public key algorithm in X.509 or C509 certificate).
3. 認証資格情報（CRED_IおよびCRED_R）のプロファイル（セクション3.5.2を参照）、たとえば、証明書またはCCSのプロファイル、サポートされている認証キーのアルゴリズム（X.509またはC509証明書のサブジェクト公開鍵アルゴリズム）を含みます。
4. Type used to identify credentials (ID_CRED_I and ID_CRED_R; see Section 3.5.3).
4. 資格情報を識別するために使用されるタイプ（ID_CRED_IおよびID_CRED_Rを参照してください。セクション3.5.3を参照）。
5. Use and type of external authorization data (EAD_1, EAD_2, EAD_3, and EAD_4; see Section 3.8).
5. 外部認証データ（EAD_1、EAD_2、EAD_3、およびEAD_4）の使用とタイプ（セクション3.8を参照）
6. Identifier used as the identity of the endpoint; see Appendix D.2.
6. エンドポイントの識別子として使用されるもの；付録 D.2 を参照してください。
7. If message_4 shall be sent/expected, and if not, how to ensure a protected application message is sent from the Responder to the Initiator; see Section 5.5.
7. もしメッセージ4が送信/期待される場合、もしくはそうでない場合、レスポンダからイニシエータに保護されたアプリケーションメッセージを送信する方法はどうすればよいかを確認してください。セクション5.5を参照してください。
The application profile may also contain information about supported cipher suites. The procedure for selecting and verifying a cipher suite is still performed as described in Sections 5.2.1 and 6.3, but it may become simplified by this knowledge. EDHOC messages can be processed without the application profile, i.e., the EDHOC messages include information about the type and length of all fields.
アプリケーションプロファイルには、サポートされている暗号スイートに関する情報も含まれる場合があります。 暗号スイートの選択および検証手順は、引き続き5.2.1節および6.3節で説明されているように実行されますが、この知識によって簡略化される可能性があります。 EDHOCメッセージは、アプリケーションプロファイルなしでも処理できます。つまり、EDHOCメッセージにはすべてのフィールドのタイプと長さに関する情報が含まれています。
An example of an application profile is shown in Appendix F.
アプリケーションプロファイルの例は付録Fに示されています。
For some parameters, like METHOD, the type of the ID_CRED field, or EAD, the receiver of an EDHOC message is able to verify compliance with the application profile and, if it needs to fail because of the lack of compliance, to infer the reason why the EDHOC session failed.
EDHOCメッセージの受信者は、METHODのようなパラメータやID_CREDフィールドのタイプ、またはEADなどについて、アプリケーションプロファイルの遵守を検証し、違反があるために失敗する必要がある場合、なぜEDHOCセッションが失敗したかを推測することができます。
For other encodings, like the profiling of CRED_x in the case that it is not transported, it may not be possible to verify that the lack of compliance with the application profile was the reason for failure. For example, integrity verification in message_2 or message_3 may fail not only because of a wrong credential. For example, in case the Initiator uses a public key certificate by reference (i.e., not transported within the protocol), then both endpoints need to use an identical data structure as CRED_I or else the integrity verification will fail.
他のエンコーディングの場合、例えばCRED_xのプロファイリングが輸送されない場合、アプリケーションプロファイルに準拠していないことが失敗の原因であることを検証することができない可能性があります。たとえば、メッセージ_2またはメッセージ_3の整合性検証が失敗する理由は、誤った資格情報だけでない場合があります。たとえば、イニシエータが参照による公開鍵証明書を使用する場合（つまり、プロトコル内で輸送されない場合）、両端点はCRED_Iと同一のデータ構造を使用する必要があります。さもないと、整合性検証が失敗します。
Note that it is not necessary for the endpoints to specify a single transport for the EDHOC messages. For example, a mix of CoAP and HTTP may be used along the path, and this may still allow correlation between messages.
注意点は、エンドポイントがEDHOCメッセージの輸送手段を1つだけ指定する必要はないことです。たとえば、CoAPとHTTPの組み合わせがパス上で使用されることがあり、それでもメッセージ間の相関を可能にすることができます。
The application profile may be dependent on the identity of the other endpoint or other information carried in an EDHOC message, but it then applies only to the later phases of the protocol when such information is known. (The Initiator does not know the identity of the Responder before having verified message_2, and the Responder does not know the identity of the Initiator before having verified message_3.)
アプリケーションプロファイルは、EDHOCメッセージに含まれる他のエンドポイントの識別情報に依存する場合がありますが、その情報がわかる後のプロトコルの段階にのみ適用されます。（イニシエーターは、message_2を検証する前にレスポンダーの識別情報を知らないため、レスポンダーはmessage_3を検証する前にイニシエーターの識別情報を知りません。）
Other conditions may be part of the application profile, such as what is the target application or use (if there is more than one application/use) to the extent that EDHOC can distinguish between them. In case multiple application profiles are used, the receiver needs to be able to determine which is applicable for a given EDHOC session, for example, based on the URI to which the EDHOC message is sent, or external authorization data type.
他の条件がアプリケーションプロファイルの一部となる場合があります。たとえば、EDHOCがそれらを区別できる範囲で、対象のアプリケーションや使用方法（複数のアプリケーション/使用方法がある場合）などが含まれるかもしれません。複数のアプリケーションプロファイルが使用される場合、受信者は、特定のEDHOCセッションに適用されるプロファイルを決定できる必要があります。たとえば、EDHOCメッセージが送信されるURIや外部認証データタイプに基づいてなどです。
EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm in the selected cipher suite to derive keys used in message processing. This section defines EDHOC_Extract (Section 4.1.1) and EDHOC_Expand (Section 4.1.2) and how to use them to derive PRK_out (Section 4.1.3), which is the shared secret session key resulting from a completed EDHOC session.
EDHOCは、メッセージ処理に使用される鍵を導出するために、選択された暗号スイートでEDHOCハッシュアルゴリズムを使用したExtract-and-Expand [RFC5869]を使用します。このセクションでは、EDHOC_Extract（セクション4.1.1）とEDHOC_Expand（セクション4.1.2）を定義し、完了したEDHOCセッションから得られる共有秘密セッションキーであるPRK_out（セクション4.1.3）を導出する方法を説明します。
EDHOC_Extract is used to derive fixed-length uniformly pseudorandom keys (PRKs) from ECDH shared secrets. EDHOC_Expand is used to define EDHOC_KDF for generating MACs and for deriving output keying material (OKM) from PRKs.
EDHOC_Extractは、ECDH共有秘密から固定長の一様疑似乱数鍵（PRKs）を導出するために使用されます。EDHOC_Expandは、MACを生成するためのEDHOC_KDFを定義し、PRKsから出力鍵素材（OKM）を導出するために使用されます。
In EDHOC, a specific message is protected with a certain PRK, but how the key is derived depends on the authentication method (Section 3.2), as detailed in Section 5.
EDHOCでは、特定のメッセージが特定のPRKで保護されますが、鍵がどのように派生されるかは認証方法（セクション3.2）に依存します。セクション5で詳細が説明されています。
The pseudorandom keys (PRKs) used for EDHOC message processing are derived using EDHOC_Extract:
EDHOCメッセージ処理に使用される疑似乱数鍵（PRKs）は、EDHOC_Extractを使用して導出されます。
PRK = EDHOC_Extract( salt, IKM )
where the input keying material (IKM) and salt are defined for each PRK below.
各PRKの入力鍵材料（IKM）とソルトが定義されている場所。
The definition of EDHOC_Extract depends on the EDHOC hash algorithm of the selected cipher suite:
選択された暗号スイートのEDHOCハッシュアルゴリズムに依存します。
* If the EDHOC hash algorithm is SHA-2, then EDHOC_Extract( salt, IKM ) = HKDF-Extract( salt, IKM ) [RFC5869].
* EDHOCのハッシュアルゴリズムがSHA-2の場合、EDHOC_Extract( salt, IKM ) = HKDF-Extract( salt, IKM ) [RFC5869] となります。
* If the EDHOC hash algorithm is SHAKE128, then EDHOC_Extract( salt, IKM ) = KMAC128( salt, IKM, 256, "" ).
* EDHOCのハッシュアルゴリズムがSHAKE128の場合、EDHOC_Extract( salt, IKM ) = KMAC128( salt, IKM, 256, "" ) となります。
* If the EDHOC hash algorithm is SHAKE256, then EDHOC_Extract( salt, IKM ) = KMAC256( salt, IKM, 512, "" ).
* EDHOCハッシュアルゴリズムがSHAKE256の場合、EDHOC_Extract( salt, IKM ) = KMAC256( salt, IKM, 512, "" ) となります。
where the Keccak Message Authentication Code (KMAC) is specified in [SP800-185].
[SP800-185] で Keccak メッセージ認証コード（KMAC）が指定されています。
The rest of the section defines the pseudorandom keys PRK_2e, PRK_3e2m, and PRK_4e3m; their use is shown in Figure 6. The index of a PRK indicates its use or in what message protection operation it is involved. For example, PRK_3e2m is involved in the encryption of message 3 and in calculating the MAC of message 2.
セクションの残りの部分では、疑似ランダムキー PRK_2e、PRK_3e2m、および PRK_4e3m を定義しています。これらの使用方法は図6に示されています。PRK のインデックスは、その使用方法や関与するメッセージ保護操作を示しています。たとえば、PRK_3e2m は、メッセージ3の暗号化とメッセージ2のMACの計算に関与しています。
The pseudorandom key PRK_2e is derived with the following input:
PRK_2e という疑似乱数鍵は、以下の入力を使用して派生されます。
* The salt SHALL be TH_2.
* 塩は TH_2 であるべきです。
* The IKM SHALL be the ephemeral-ephemeral ECDH shared secret G_XY (calculated from G_X and Y or G_Y and X) as defined in Section 6.3.1 of [RFC9053]. The use of G_XY gives forward secrecy in the sense that compromise of the private authentication keys does not compromise past session keys.
* IKMは[RFC9053]のセクション6.3.1で定義されているephemeral-ephemeral ECDH共有秘密G_XY（G_XとYまたはG_YとXから計算される）であるべきです。G_XYの使用により、プライベート認証キーの侵害が過去のセッションキーを危険にさらすことなく、将来の秘密を提供します。
Example: Assuming the use of curve25519, the ECDH shared secret G_XY is the output of the X25519 function [RFC7748]:
curve25519を使用すると仮定すると、ECDH共有秘密G_XYはX25519関数[RFC7748]の出力です。
G_XY = X25519( Y, G_X ) = X25519( X, G_Y )
Example: Assuming the use of SHA-256, the extract phase of the key derivation function is HKDF-Extract, which produces PRK_2e as follows:
例：SHA-256を使用する場合、鍵導出関数の抽出フェーズはHKDF-Extractであり、PRK_2eを次のように生成します。
PRK_2e = HMAC-SHA-256( TH_2, G_XY )
The pseudorandom key PRK_3e2m is derived as follows:
疑似乱数鍵 PRK_3e2m は次のように導出されます。
If the Responder authenticates with a static Diffie-Hellman key, then PRK_3e2m = EDHOC_Extract( SALT_3e2m, G_RX ), where
応答者が静的Diffie-Hellman鍵で認証する場合、PRK_3e2m = EDHOC_Extract( SALT_3e2m, G_RX ) となります。
* SALT_3e2m is derived from PRK_2e (see Section 4.1.2) and
* SALT_3e2mはPRK_2eから派生しています（セクション4.1.2を参照）。
* G_RX is the ECDH shared secret calculated from G_R and X, or G_X and R (the Responder's private authentication key; see Section 3.5.1),
* G_RXは、G_RとX、またはG_XとR（応答者のプライベート認証キー；セクション3.5.1を参照）から計算されたECDH共有秘密です。
else PRK_3e2m = PRK_2e.
それ以外の場合、PRK_3e2m = PRK_2e.
The pseudorandom key PRK_4e3m is derived as follows:
疑似乱数鍵 PRK_4e3m は次のように導出されます。
If the Initiator authenticates with a static Diffie-Hellman key, then PRK_4e3m = EDHOC_Extract( SALT_4e3m, G_IY ), where
もしイニシエーターが静的Diffie-Hellman鍵で認証する場合、その場合、PRK_4e3m = EDHOC_Extract( SALT_4e3m, G_IY ) となります。
* SALT_4e3m is derived from PRK_3e2m (see Section 4.1.2) and
* SALT_4e3m は PRK_3e2m から派生しています（セクション 4.1.2 を参照）。
* G_IY is the ECDH shared secret calculated from G_I and Y, or G_Y and I (the Initiator's private authentication key; see Section 3.5.1),
* G_IYは、G_IとY、またはG_YとI（イニシエーターのプライベート認証キー；セクション3.5.1を参照）から計算されるECDH共有秘密です。
else PRK_4e3m = PRK_3e2m.
それ以外の場合、PRK_4e3m = PRK_3e2m.
The output keying material (OKM) -- including keys, initialization vectors (IVs), and salts -- are derived from the PRKs using the EDHOC_KDF, which is defined through EDHOC_Expand:
出力鍵素材（OKM）- キー、初期化ベクトル（IV）、および塩 - は、PRKを使用してEDHOC_KDFを介して導出され、これはEDHOC_Expandを通じて定義されます。
OKM = EDHOC_KDF( PRK, info_label, context, length )
= EDHOC_Expand( PRK, info, length )
where info is encoded as the CBOR sequence:
情報がCBORシーケンスとしてエンコードされている場所：
info = (
info_label : int,
context : bstr,
length : uint,
)
where:
ただし：
* info_label is an int,
* info_label は整数です。
* context is a bstr, and
* 文脈は bstr であり、
* length is the length of OKM in bytes.
* length は OKM の長さをバイト単位で表したものです。
When EDHOC_KDF is used to derive OKM for EDHOC message processing, then the context includes one of the transcript hashes, TH_2, TH_3, or TH_4, defined in Sections 5.3.2 and 5.4.2.
EDHOCメッセージ処理のためにOKMを導出する際にEDHOC_KDFが使用される場合、コンテキストにはセクション5.3.2および5.4.2で定義されたTH_2、TH_3、またはTH_4のいずれかのトランスクリプトハッシュが含まれます。
The definition of EDHOC_Expand depends on the EDHOC hash algorithm of the selected cipher suite:
選択された暗号スイートのEDHOCハッシュアルゴリズムに依存します。
* If the EDHOC hash algorithm is SHA-2, then EDHOC_Expand( PRK, info, length ) = HKDF-Expand( PRK, info, length ) [RFC5869].
* EDHOCハッシュアルゴリズムがSHA-2の場合、EDHOC_Expand(PRK、info、length) = HKDF-Expand(PRK、info、length) [RFC5869]。
* If the EDHOC hash algorithm is SHAKE128, then EDHOC_Expand( PRK, info, length ) = KMAC128( PRK, info, L, "" ).
* EDHOCのハッシュアルゴリズムがSHAKE128の場合、EDHOC_Expand(PRK, info, length) = KMAC128(PRK, info, L, "")となります。
* If the EDHOC hash algorithm is SHAKE256, then EDHOC_Expand( PRK, info, length ) = KMAC256( PRK, info, L, "" ).
* EDHOCのハッシュアルゴリズムがSHAKE256の場合、EDHOC_Expand(PRK, info, length) = KMAC256(PRK, info, L, "")となります。
where L = 8 ⋅ length, the output length in bits.
L = 8倍の長さ、出力の長さ（ビット単位）です。
Figure 6 lists derivations made with EDHOC_KDF, where:
図6は、EDHOC_KDFを使用して行われた導出をリストアップしています。
* hash_length is the length of output size of the EDHOC hash algorithm of the selected cipher suite,
* hash_lengthは、選択した暗号スイートのEDHOCハッシュアルゴリズムの出力サイズの長さです。
* key_length is the length of the encryption key of the EDHOC AEAD algorithm of the selected cipher suite, and
* key_lengthは、選択した暗号スイートのEDHOC AEADアルゴリズムの暗号鍵の長さです。
* iv_length is the length of the initialization vector of the EDHOC AEAD algorithm of the selected cipher suite
* iv_lengthは選択された暗号スイートのEDHOC AEADアルゴリズムの初期化ベクトルの長さです。
Further details of the key derivation and how the output keying material is used are specified in Section 5.
キー導出の詳細と出力キー材料の使用方法についての詳細は、セクション5で指定されています。
KEYSTREAM_2 = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length )
SALT_3e2m = EDHOC_KDF( PRK_2e, 1, TH_2, hash_length )
MAC_2 = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 )
K_3 = EDHOC_KDF( PRK_3e2m, 3, TH_3, key_length )
IV_3 = EDHOC_KDF( PRK_3e2m, 4, TH_3, iv_length )
SALT_4e3m = EDHOC_KDF( PRK_3e2m, 5, TH_3, hash_length )
MAC_3 = EDHOC_KDF( PRK_4e3m, 6, context_3, mac_length_3 )
PRK_out = EDHOC_KDF( PRK_4e3m, 7, TH_4, hash_length )
K_4 = EDHOC_KDF( PRK_4e3m, 8, TH_4, key_length )
IV_4 = EDHOC_KDF( PRK_4e3m, 9, TH_4, iv_length )
PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length )
Figure 6: Key Derivations Using EDHOC_KDF
図6: EDHOC_KDFを使用した鍵導出
h'' is CBOR diagnostic notation for the empty byte string, 0x40.
"h''" は、空のバイト列、0x40 の CBOR 診断表記です。
The pseudorandom key PRK_out, derived as shown in Figure 6, is the output session key of a completed EDHOC session.
図6に示すように導出される疑似乱数鍵PRK_outは、完了したEDHOCセッションの出力セッション鍵です。
Keys for applications are derived using EDHOC_Exporter (see Section 4.2.1) from PRK_exporter, which in turn is derived from PRK_out as shown in Figure 6. For the purpose of generating application keys, it is sufficient to store PRK_out or PRK_exporter. (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a Trusted Execution Environment (TEE); see Section 9.8.)
アプリケーションの鍵は、図6に示すようにPRK_outから導出されたPRK_exporterを使用してEDHOC_Exporter（セクション4.2.1を参照）から導出されます。アプリケーション鍵を生成する目的では、PRK_outまたはPRK_exporterを保存するだけで十分です。（ここで使用されている「保存」という言葉は、アプリケーションが平文のPRK_outにアクセスできることを意味するものではないことに注意してください。これは、信頼された実行環境（TEE）内のコードに予約されている可能性があるためです。セクション9.8を参照してください。）
This section defines EDHOC_Exporter in terms of EDHOC_KDF and PRK_exporter. A key update function is defined in Appendix H.
このセクションは、EDHOC_KDFとPRK_exporterを用いてEDHOC_Exporterを定義します。キー更新関数は付録Hで定義されています。
Keying material for the application can be derived using the EDHOC_Exporter interface defined as:
アプリケーション用の鍵材料は、EDHOC_Exporterインターフェースを使用して導出できます。
EDHOC_Exporter(exporter_label, context, length)
= EDHOC_KDF(PRK_exporter, exporter_label, context, length)
where:
ただし：
* exporter_label is a registered uint from the "EDHOC Exporter Labels" registry (Section 10.1),
* exporter_label は、"EDHOC Exporter Labels" レジストリ（セクション 10.1）から登録された uint です。
* context is a bstr defined by the application, and
* 文脈はアプリケーションによって定義されたbstrです。
* length is a uint defined by the application.
* 長さはアプリケーションによって定義されたuintです。
The (exporter_label, context) pair used in EDHOC_Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two different purposes. However, an application can re-derive the same key several times as long as it is done securely. For example, in most encryption algorithms, the same key can be reused with different nonces. The context can, for example, be the empty CBOR byte string.
EDHOC_Exporterで使用される（exporter_label、context）ペアは一意でなければなりません。つまり、（exporter_label、context）は2つの異なる目的で使用してはいけません。ただし、アプリケーションは、安全に行われる限り、同じキーを複数回再導出することができます。たとえば、ほとんどの暗号化アルゴリズムでは、同じキーを異なるナンスと再利用できます。コンテキストは、たとえば、空のCBORバイト文字列にすることができます。
Examples of use of the EDHOC_Exporter are given in Appendix A.
EDHOC_Exporterの使用例は付録Aに記載されています。
This section specifies formatting of the messages and processing steps. Error messages are specified in Section 6. Annotated traces of EDHOC sessions are provided in [RFC9529].
このセクションは、メッセージのフォーマットと処理手順を指定しています。エラーメッセージはセクション6で指定されています。EDHOCセッションの注釈付きトレースは[RFC9529]で提供されています。
An EDHOC message is encoded as a sequence of CBOR data items (CBOR Sequence [RFC8742]). Additional optimizations are made to reduce message overhead.
EDHOCメッセージは、CBORデータ項目のシーケンスとしてエンコードされます（CBOR Sequence [RFC8742]）。メッセージのオーバーヘッドを削減するために追加の最適化が行われます。
While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0 structures, only a subset of the parameters is included in the EDHOC messages; see Appendix C.3. In order to recreate the COSE object, the recipient endpoint may need to add parameters to the COSE headers not included in the EDHOC message, for example, the parameter 'alg' to COSE_Sign1 or COSE_Encrypt0.
EDHOCはCOSE_Key、COSE_Sign1、およびCOSE_Encrypt0の構造を使用しますが、EDHOCメッセージにはパラメータのサブセットのみが含まれています。COSEオブジェクトを再作成するためには、受信エンドポイントが、EDHOCメッセージに含まれていないCOSEヘッダーにパラメータを追加する必要がある場合があります。例えば、COSE_Sign1またはCOSE_Encrypt0に'alg'パラメータを追加することがあります。
For each new/ongoing EDHOC session, the endpoints are assumed to keep an associated protocol state containing identifiers, keying material, etc. used for subsequent processing of protocol-related data. The protocol state is assumed to be associated with an application profile (Section 3.9) that provides the context for how messages are transported, identified, and processed.
新しい/進行中のEDHOCセッションごとに、エンドポイントは、プロトコル関連データの後続処理に使用される識別子、鍵素材などを含む関連プロトコル状態を保持するものとします。プロトコル状態は、メッセージがどのように輸送され、識別され、処理されるかを提供するアプリケーションプロファイル（セクション3.9）に関連付けられているものとします。
EDHOC messages SHALL be processed according to the current protocol state. The following steps are expected to be performed at reception of an EDHOC message:
EDHOC メッセージは現在のプロトコル状態に従って処理されるべきです。EDHOC メッセージを受信した際には、以下の手順が実行されることが期待されています。
1. Detect that an EDHOC message has been received, for example, by means of a port number, URI, or media type (Section 3.9).
1. EDHOCメッセージが受信されたことを検出するために、ポート番号、URI、またはメディアタイプなどの手段を使用します（セクション3.9）。
2. Retrieve the protocol state according to the message correlation; see Section 3.4.1. If there is no protocol state, in the case of message_1, a new protocol state is created. The Responder endpoint needs to make use of available denial-of-service mitigation (Section 9.7).
2. メッセージの相関に従ってプロトコルの状態を取得します。セクション3.4.1を参照してください。プロトコルの状態がない場合、message_1の場合、新しいプロトコルの状態が作成されます。応答エンドポイントは利用可能なサービス拒否防止策（セクション9.7）を利用する必要があります。
3. If the message received is an error message, then process it according to Section 6, else process it as the expected next message according to the protocol state.
3. 受信したメッセージがエラーメッセージである場合は、セクション6に従って処理し、それ以外の場合はプロトコルの状態に応じて期待される次のメッセージとして処理します。
The message processing steps SHALL be processed in order, unless otherwise stated. If the processing fails for some reason, then typically an error message is sent, the EDHOC session is aborted, and the protocol state is erased. When the composition and sending of one message is completed and before the next message is received, error messages SHALL NOT be sent.
メッセージ処理手順は、別途記載されていない限り、順番に処理されます。処理が何らかの理由で失敗した場合、通常はエラーメッセージが送信され、EDHOCセッションが中止され、プロトコルの状態が消去されます。1つのメッセージの構成と送信が完了した後、次のメッセージが受信される前に、エラーメッセージを送信してはいけません。
After having successfully processed the last message (message_3 or message_4 depending on application profile), the EDHOC session is completed; after which, no error messages are sent and EDHOC session output MAY be maintained even if error messages are received. Further details are provided in the following subsections and in Section 6.
最後のメッセージ（アプリケーションプロファイルに応じてmessage_3またはmessage_4）を正常に処理した後、EDHOCセッションが完了します。その後、エラーメッセージは送信されず、エラーメッセージが受信されてもEDHOCセッションの出力は保持される場合があります。詳細は以下のサブセクションおよびセクション6に記載されています。
Different instances of the same message MUST NOT be processed in one EDHOC session. Note that processing will fail if the same message appears a second time for EDHOC processing in the same EDHOC session because the state of the protocol has moved on and now expects something else. Message deduplication MUST be done by the transport protocol (see Section 3.4) or, if not supported by the transport, as described in Section 7.
同じメッセージの異なるインスタンスは、1つのEDHOCセッションで処理してはいけません。同じメッセージがEDHOCセッション内で2回目に現れると、プロトコルの状態が進行しているため、処理が失敗します。メッセージの重複排除は、輸送プロトコルによって行われなければならず（セクション3.4を参照）、輸送プロトコルでサポートされていない場合は、セクション7で説明されている方法で行われなければなりません。
message_1 SHALL be a CBOR Sequence (see Appendix C.1), as defined below.
message_1は、以下で定義されるCBORシーケンスである必要があります（付録C.1を参照）。
message_1 = (
METHOD : int,
SUITES_I : suites,
G_X : bstr,
C_I : bstr / -24..23,
? EAD_1,
)
suites = [ 2* int ] / int
EAD_1 = 1* ead
where:
ただし：
* METHOD is an authentication method; see Section 3.2,
* METHODは認証方法です。セクション3.2を参照してください。
* SUITES_I is an array of cipher suites that the Initiator supports constructed as specified in Section 5.2.2,
* SUITES_Iは、Section 5.2.2で指定された方法で構築された、イニシエータがサポートする暗号スイートの配列です。
* G_X is the ephemeral public key of the Initiator, and
* G_X はイニシエーターの一時的な公開鍵です。
* C_I is a variable-length connection identifier (note that connection identifiers are byte strings but certain values are represented as integers in the message; see Section 3.3.2), and
* C_Iは可変長の接続識別子です（接続識別子はバイト文字列ですが、一部の値はメッセージ内で整数として表されます。セクション3.3.2を参照）。
* EAD_1 is external authorization data; see Section 3.8.
* EAD_1は外部認証データです。セクション3.8を参照してください。
The processing steps are detailed below and in Section 6.3.
処理手順は以下およびセクション6.3に詳細に記載されています。
The Initiator SHALL compose message_1 as follows:
イニシエーターは、次のようにメッセージ1を作成しなければなりません。
* Construct SUITES_I as an array of cipher suites supported by I in order of preference by I with the first cipher suite in the array being the most preferred by I and the last being the one selected by I for this EDHOC session. If the cipher suite most preferred by I is selected, then SUITES_I contains only that cipher suite and is encoded as an int. All cipher suites, if any, preferred by I over the selected one MUST be included. (See also Section 6.3.)
* Iは、最も好ましい暗号スイートの順にIによってサポートされる暗号スイートの配列としてSUITES_Iを構築します。配列内の最初の暗号スイートがIによって最も好まれ、最後の暗号スイートがこのEDHOCセッションでIによって選択されます。Iが最も好ましい暗号スイートを選択した場合、SUITES_Iにはその暗号スイートのみが含まれ、intとしてエンコードされます。選択された暗号スイートよりもIによって好まれる暗号スイートがある場合は、すべて含める必要があります。（詳細はセクション6.3も参照してください。）
- The selected suite is based on what the Initiator can assume to be supported by the Responder; if the Initiator previously received from the Responder an error message with error code 2 containing SUITES_R (see Section 6.3) indicating cipher suites supported by the Responder, then the Initiator SHOULD select its most preferred supported cipher suite among those (bearing in mind that error messages may be forged).
- 選択されたスイートは、イニシエーターがレスポンダーによってサポートされると仮定できるものに基づいています。イニシエーターが以前にエラーコード2を含むエラーメッセージをレスポンダーから受信し、SUITES_R（セクション6.3を参照）を示す場合、イニシエーターはその中から最も好ましいサポートされる暗号スイートを選択すべきです（エラーメッセージが偽造されている可能性があることを念頭に置いて）。
- The Initiator MUST NOT change its order of preference for cipher suites and MUST NOT omit a cipher suite preferred to the selected one because of previous error messages received from the Responder.
- イニシエーターは、レスポンダーから受信した以前のエラーメッセージによって選択されたものよりも優先される暗号スイートを省略してはならず、暗号スイートの優先順位を変更してはなりません。
* Generate an ephemeral ECDH key pair using the curve in the selected cipher suite and format it as a COSE_Key. Let G_X be the 'x' parameter of the COSE_Key.
* 選択した暗号スイート内の曲線を使用して、一時的なECDH鍵ペアを生成し、それをCOSE_Keyとしてフォーマットしてください。G_XはCOSE_Keyの 'x' パラメータであるとします。
* Choose a connection identifier C_I and store it during the EDHOC session.
* EDHOCセッション中に接続識別子C_Iを選択し、保存してください。
* Encode message_1 as a sequence of CBOR-encoded data items as specified in Section 5.2.1
* セクション5.2.1で指定されているように、メッセージ1をCBORエンコードされたデータ項目のシーケンスとしてエンコードしてください。
The Responder SHALL process message_1 in the following order:
応答者は、次の順序でメッセージ1を処理する必要があります。
1. Decode message_1 (see Appendix C.1).
1. メッセージ_1をデコードしてください（付録C.1を参照）。
2. Process message_1. In particular, verify that the selected cipher suite is supported and that no prior cipher suite as ordered in SUITES_I is supported.
2. メッセージ1の処理を行います。特に、選択された暗号スイートがサポートされていること、およびSUITES_Iで指定された順序で以前の暗号スイートがサポートされていないことを確認してください。
3. If all processing completed successfully, and if EAD_1 is present, then make it available to the application for EAD processing.
3. すべての処理が正常に完了し、かつ EAD_1 が存在する場合、それを EAD 処理のためにアプリケーションで利用可能にしてください。
If any processing step fails, then the Responder MUST send an EDHOC error message back as defined in Section 6, and the EDHOC session MUST be aborted.
もし処理ステップのいずれかが失敗した場合、レスポンダーはセクション6で定義されたEDHOCエラーメッセージを送信し、EDHOCセッションは中止されなければなりません。
message_2 SHALL be a CBOR Sequence (see Appendix C.1), as defined below.
message_2は、以下で定義されるCBORシーケンスである必要があります（付録C.1を参照）。
message_2 = (
G_Y_CIPHERTEXT_2 : bstr,
)
where:
ただし：
* G_Y_CIPHERTEXT_2 is the concatenation of G_Y (i.e., the ephemeral public key of the Responder) and CIPHERTEXT_2.
* G_Y_CIPHERTEXT_2は、G_Y（つまり、応答者の一時的な公開鍵）とCIPHERTEXT_2の連結です。
The Responder SHALL compose message_2 as follows:
応答者は、次のようにメッセージ_2を作成しなければなりません。
* Generate an ephemeral ECDH key pair using the curve in the selected cipher suite and format it as a COSE_Key. Let G_Y be the 'x' parameter of the COSE_Key.
* 選択した暗号スイート内の曲線を使用して、一時的なECDHキーペアを生成し、それをCOSE_Keyとしてフォーマットします。G_YをCOSE_Keyの 'x' パラメータとします。
* Choose a connection identifier C_R and store it for the length of the EDHOC session.
* EDHOCセッションの長さの間、接続識別子C_Rを選択して保存してください。
* Compute the transcript hash TH_2 = H( G_Y, H(message_1) ), where H() is the EDHOC hash algorithm of the selected cipher suite. The input to the hash function is a CBOR Sequence. Note that H(message_1) can be computed and cached already in the processing of message_1.
* 指定された暗号スイートのEDHOCハッシュアルゴリズムを使用して、トランスクリプトハッシュTH_2 = H( G_Y, H(message_1) )を計算します。ハッシュ関数への入力はCBORシーケンスです。H(message_1)は、message_1の処理中にすでに計算およびキャッシュされている可能性があることに注意してください。
* Compute MAC_2 as in Section 4.1.2 with context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >> (see Appendix C.1 for notation).
* セクション4.1.2でcontext_2 = << C_R、ID_CRED_R、TH_2、CRED_R、? EAD_2 >>を使用してMAC_2を計算します（記法については付録C.1を参照）。
- If the Responder authenticates with a static Diffie-Hellman key (method equals 1 or 3), then mac_length_2 is the EDHOC MAC length of the selected cipher suite. If the Responder authenticates with a signature key (method equals 0 or 2), then mac_length_2 is equal to hash_length.
- 応答者が静的Diffie-Hellman鍵（methodが1または3の場合）で認証する場合、mac_length_2は選択された暗号スイートのEDHOC MAC長です。応答者が署名鍵（methodが0または2の場合）で認証する場合、mac_length_2はhash_lengthに等しいです。
- C_R is a variable-length connection identifier. Note that connection identifiers are byte strings but certain values are represented as integers in the message; see Section 3.3.2.
- C_Rは可変長の接続識別子です。接続識別子はバイト文字列ですが、一部の値はメッセージ中で整数として表されます。セクション3.3.2を参照してください。
- ID_CRED_R is an identifier to facilitate the retrieval of CRED_R; see Section 3.5.3.
- ID_CRED_Rは、CRED_Rの取得を容易にするための識別子です。セクション3.5.3を参照してください。
- CRED_R is a CBOR item containing the authentication credential of the Responder; see Section 3.5.2.
- CRED_R は、応答者の認証資格情報を含む CBOR アイテムです。セクション 3.5.2 を参照してください。
- EAD_2 is external authorization data; see Section 3.8.
- EAD_2は外部認証データです。セクション3.8を参照してください。
* If the Responder authenticates with a static Diffie-Hellman key (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the Responder authenticates with a signature key (method equals 0 or 2), then Signature_or_MAC_2 is the 'signature' field of a COSE_Sign1 object, computed as specified in Section 4.4 of [RFC9052] using the signature algorithm of the selected cipher suite, the private authentication key of the Responder, and the following parameters as input (see Appendix C.3 for an overview of COSE and Appendix C.1 for notation):
* 応答者が静的Diffie-Hellman鍵（methodが1または3の場合）で認証する場合、Signature_or_MAC_2はMAC_2です。応答者が署名鍵（methodが0または2の場合）で認証する場合、Signature_or_MAC_2はCOSE_Sign1オブジェクトの「signature」フィールドであり、[RFC9052]のセクション4.4で指定された方法で計算されます。選択した暗号スイートの署名アルゴリズム、応答者のプライベート認証鍵、および次のパラメータを入力として使用します（COSEの概要については付録C.3、記法については付録C.1を参照）。
- protected = << ID_CRED_R >>
- 保護された = << ID_CRED_R >>
- external_aad = << TH_2, CRED_R, ? EAD_2 >>
- external_aad = << TH_2, CRED_R, ? EAD_2 >>
- payload = MAC_2
- payload = MAC_2
* CIPHERTEXT_2 is calculated with a binary additive stream cipher, using a keystream generated with EDHOC_Expand and the following plaintext:
* CIPHERTEXT_2 は、EDHOC_Expand で生成されたキーストリームを使用してバイナリ加算ストリーム暗号で計算されます。指定された平文を使用します。
- PLAINTEXT_2 = ( C_R, ID_CRED_R / bstr / -24..23, Signature_or_MAC_2, ? EAD_2 )
- PLAINTEXT_2 = ( C_R、ID_CRED_R / bstr / -24..23、Signature_or_MAC_2、? EAD_2 )
o If ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4 : kid_R }, then the compact encoding is applied; see Section 3.5.3.2.
o ID_CRED_R に 'kid' パラメーターが1つだけ含まれている場合、つまり、ID_CRED_R = { 4 : kid_R } の場合、コンパクトエンコーディングが適用されます。セクション3.5.3.2 を参照してください。
o C_R is the variable-length connection identifier. Note that connection identifiers are byte strings, but certain values are represented as integers in the message; see Section 3.3.2.
o C_Rは可変長の接続識別子です。接続識別子はバイト文字列ですが、一部の値はメッセージ内で整数として表されます。セクション3.3.2を参照してください。
- Compute KEYSTREAM_2 as in Section 4.1.2, where plaintext_length is the length of PLAINTEXT_2. For the case of plaintext_length exceeding the EDHOC_KDF output size, see Appendix G.
- セクション4.1.2でPLAINTEXT_2の長さであるplaintext_lengthを使用して、KEYSTREAM_2を計算します。PLAINTEXT_2の長さがEDHOC_KDFの出力サイズを超える場合は、付録Gを参照してください。
- CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2
- CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 -> CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2
* Encode message_2 as a sequence of CBOR-encoded data items as specified in Section 5.3.1.
* セクション5.3.1で指定されているように、メッセージ_2をCBORエンコードされたデータ項目のシーケンスとしてエンコードしてください。
The Initiator SHALL process message_2 in the following order:
イニシエーターは、次の順序でメッセージ_2を処理しなければなりません。
1. Decode message_2 (see Appendix C.1).
1. メッセージ_2をデコードしてください（付録C.1を参照）。
2. Retrieve the protocol state using available message correlation (e.g., the CoAP Token, the 5-tuple, or the prepended C_I; see Section 3.4.1).
2. 利用可能なメッセージ相関（たとえば、CoAP トークン、5つ組、または先頭に挿入された C_I を参照してください。）を使用してプロトコルの状態を取得します。
3. Decrypt CIPHERTEXT_2; see Section 5.3.2.
3. CIPHERTEXT_2を復号化してください。セクション5.3.2を参照してください。
4. If all processing is completed successfully, then make ID_CRED_R and (if present) EAD_2 available to the application for authentication and EAD processing. When and how to perform authentication is up to the application.
4. すべての処理が正常に完了した場合、ID_CRED_Rと（存在する場合）EAD_2を認証およびEAD処理のためにアプリケーションで利用可能にしてください。認証をいつ、どのように行うかはアプリケーション次第です。
5. Obtain the authentication credential (CRED_R) and the authentication key of R from the application (or by other means).
5. アプリケーションから認証資格情報（CRED_R）とRの認証キーを取得してください。
6. Verify Signature_or_MAC_2 using the algorithm in the selected cipher suite. The verification process depends on the method; see Section 5.3.2. Make the result of the verification available to the application.
6. 選択された暗号スイート内のアルゴリズムを使用して、Signature_or_MAC_2を検証します。検証プロセスは、手法に依存します。セクション5.3.2を参照してください。検証結果をアプリケーションに利用可能にしてください。
If any processing step fails, then the Initiator MUST send an EDHOC error message back as defined in Section 6, and the EDHOC session MUST be aborted.
もし処理のステップが失敗した場合、イニシエーターはセクション6で定義されたEDHOCエラーメッセージを送信しなければならず、EDHOCセッションは中止されなければなりません。
message_3 SHALL be a CBOR Sequence (see Appendix C.1), as defined below.
message_3は、以下で定義されるCBORシーケンスである必要があります（付録C.1を参照）。
message_3 = (
CIPHERTEXT_3 : bstr,
)
The Initiator SHALL compose message_3 as follows:
イニシエーターは、次のようにメッセージ_3を作成しなければなりません。
* Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R), where H() is the EDHOC hash algorithm of the selected cipher suite. The input to the hash function is a CBOR Sequence. Note that TH_3 can be computed and cached already in the processing of message_2.
* TH_3 = H(TH_2, PLAINTEXT_2, CRED_R) の計算を行います。ここで、H() は選択された暗号スイートのEDHOCハッシュアルゴリズムです。ハッシュ関数への入力はCBORシーケンスです。TH_3 は message_2 の処理中にすでに計算およびキャッシュされている可能性があります。
* Compute MAC_3 as in Section 4.1.2, with context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>
* セクション4.1.2でMAC_3を計算します。context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >> を使用します。
- If the Initiator authenticates with a static Diffie-Hellman key (method equals 2 or 3), then mac_length_3 is the EDHOC MAC length of the selected cipher suite. If the Initiator authenticates with a signature key (method equals 0 or 1), then mac_length_3 is equal to hash_length.
- イニシエーターが静的Diffie-Hellman鍵で認証する場合（methodが2または3の場合）、mac_length_3は選択された暗号スイートのEDHOC MAC長です。イニシエーターが署名鍵で認証する場合（methodが0または1の場合）、mac_length_3はhash_lengthと等しいです。
- ID_CRED_I is an identifier to facilitate the retrieval of CRED_I; see Section 3.5.3.
- ID_CRED_Iは、CRED_Iの取得を容易にするための識別子です。セクション3.5.3を参照してください。
- CRED_I is a CBOR item containing the authentication credential of the Initiator; see Section 3.5.2.
- CRED_I は、イニシエーターの認証資格情報を含む CBOR アイテムです。セクション 3.5.2 を参照してください。
- EAD_3 is external authorization data; see Section 3.8.
- EAD_3は外部認証データです。セクション3.8を参照してください。
* If the Initiator authenticates with a static Diffie-Hellman key (method equals 2 or 3), then Signature_or_MAC_3 is MAC_3. If the Initiator authenticates with a signature key (method equals 0 or 1), then Signature_or_MAC_3 is the 'signature' field of a COSE_Sign1 object, computed as specified in Section 4.4 of [RFC9052] using the signature algorithm of the selected cipher suite, the private authentication key of the Initiator, and the following parameters as input (see Appendix C.3):
* イニシエーターが静的Diffie-Hellman鍵（methodが2または3の場合）で認証する場合、Signature_or_MAC_3はMAC_3です。イニシエーターが署名鍵（methodが0または1の場合）で認証する場合、Signature_or_MAC_3はCOSE_Sign1オブジェクトの「signature」フィールドであり、[RFC9052]のセクション4.4で指定された方法で計算されます。選択した暗号スイートの署名アルゴリズム、イニシエーターのプライベート認証鍵、および次のパラメーターを入力として使用します（Appendix C.3を参照）。
- protected = << ID_CRED_I >>
- 保護されました = << ID_CRED_I >>
- external_aad = << TH_3, CRED_I, ? EAD_3 >>
- external_aad = << TH_3、CRED_I、? EAD_3 >>
- payload = MAC_3
- ペイロード = MAC_3
* Compute a COSE_Encrypt0 object as defined in Sections 5.2 and 5.3 of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_3, the initialization vector IV_3 (if used by the AEAD algorithm), the plaintext PLAINTEXT_3, and the following parameters as input (see Appendix C.3):
* [RFC9052]のセクション5.2および5.3で定義されているCOSE_Encrypt0オブジェクトを、選択された暗号スイートのEDHOC AEADアルゴリズムを使用して、暗号化キーK_3、初期化ベクトルIV_3（AEADアルゴリズムで使用される場合）、平文PLAINTEXT_3、および次のパラメータを入力として計算します（付録C.3を参照）。
- protected = h''
- 保護された = h''
- external_aad = TH_3
- external_aad = TH_3
- K_3 and IV_3 are defined in Section 4.1.2
- K_3とIV_3はセクション4.1.2で定義されています。
- PLAINTEXT_3 = ( ID_CRED_I / bstr / -24..23, Signature_or_MAC_3, ? EAD_3 )
- PLAINTEXT_3 = ( ID_CRED_I / bstr / -24..23、Signature_or_MAC_3、? EAD_3 )
o If ID_CRED_I contains a single 'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, then the compact encoding is applied; see Section 3.5.3.2.
o ID_CRED_I に単一の 'kid' パラメータが含まれている場合、つまり、ID_CRED_I = { 4 : kid_I } の場合、コンパクトエンコーディングが適用されます。セクション 3.5.3.2 を参照してください。
CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.
CIPHERTEXT_3はCOSE_Encrypt0の「暗号文」です。
* Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I), where H() is the EDHOC hash algorithm of the selected cipher suite. The input to the hash function is a CBOR Sequence.
* 選択された暗号スイートのEDHOCハッシュアルゴリズムを使用して、トランスクリプトハッシュTH_4 = H(TH_3, PLAINTEXT_3, CRED_I)を計算します。ハッシュ関数への入力はCBORシーケンスです。
* Calculate PRK_out as defined in Figure 6. The Initiator can now derive application keys using the EDHOC_Exporter interface; see Section 4.2.1.
* Figure 6 で定義されている PRK_out を計算します。イニシエータは、EDHOC_Exporter インターフェースを使用してアプリケーションキーを導出できます。セクション 4.2.1 を参照してください。
* Encode message_3 as a CBOR data item as specified in Section 5.4.1.
* セクション5.4.1で指定されているように、メッセージ_3をCBORデータアイテムとしてエンコードしてください。
* Make the connection identifiers (C_I and C_R) and the application algorithms in the selected cipher suite available to the application.
* 選択された暗号スイート内の接続識別子（C_IおよびC_R）とアプリケーションアルゴリズムをアプリケーションに利用可能にしてください。
After creating message_3, the Initiator can compute PRK_out (see Section 4.1.3) and derive application keys using the EDHOC_Exporter interface (see Section 4.2.1). The Initiator SHOULD NOT persistently store PRK_out or application keys until the Initiator has verified message_4 or a message protected with a derived application key, such as an OSCORE message, from the Responder and the application has authenticated the Responder. This is similar to waiting for an acknowledgment (ACK) in a transport protocol. The Initiator SHOULD NOT send protected application data until the application has authenticated the Responder.
message_3 を作成した後、イニシエーターは PRK_out を計算し（4.1.3節を参照）、EDHOC_Exporter インターフェースを使用してアプリケーションキーを導出することができます（4.2.1節を参照）。イニシエーターは、message_4 または OSCORE メッセージなどの導出されたアプリケーションキーで保護されたメッセージを、レスポンダーから受信し、アプリケーションがレスポンダーを認証するまで、PRK_out やアプリケーションキーを永続的に保存すべきではありません。これは、トランスポートプロトコルにおける確認（ACK）を待つのに似ています。イニシエーターは、アプリケーションがレスポンダーを認証するまで、保護されたアプリケーションデータを送信すべきではありません。
The Responder SHALL process message_3 in the following order:
応答者は、メッセージ3を次の順序で処理しなければなりません。
1. Decode message_3 (see Appendix C.1).
1. メッセージ_3をデコードしてください（付録C.1を参照）。
2. Retrieve the protocol state using available message correlation (e.g., the CoAP Token, the 5-tuple, or the prepended C_R; see Section 3.4.1).
2. 利用可能なメッセージ相関（たとえば、CoAP トークン、5つ組、または先行する C_R を参照してください。セクション3.4.1を参照してください）を使用してプロトコルの状態を取得します。
3. Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of [RFC9052], with the EDHOC AEAD algorithm in the selected cipher suite and the parameters defined in Section 5.4.2.
3. [RFC9052]のセクション5.2および5.3で定義されたCOSE_Encrypt0を、選択した暗号スイート内のEDHOC AEADアルゴリズムとセクション5.4.2で定義されたパラメータで復号化および検証してください。
4. If all processing completed successfully, then make ID_CRED_I and (if present) EAD_3 available to the application for authentication and EAD processing. When and how to perform authentication is up to the application.
4. すべての処理が正常に完了した場合、ID_CRED_Iと（存在する場合）EAD_3をアプリケーションに認証およびEAD処理のために利用可能にしてください。認証を行うタイミングや方法はアプリケーション次第です。
5. Obtain the authentication credential (CRED_I) and the authentication key of I from the application (or by other means).
5. アプリケーションから認証資格情報（CRED_I）とIの認証キーを取得してください。
6. Verify Signature_or_MAC_3 using the algorithm in the selected cipher suite. The verification process depends on the method; see Section 5.4.2. Make the result of the verification available to the application.
6. 選択された暗号スイート内のアルゴリズムを使用して、Signature_or_MAC_3を検証します。検証プロセスは、手法に依存します。セクション5.4.2を参照してください。検証結果をアプリケーションに利用可能にしてください。
7. Make the connection identifiers (C_I and C_R) and the application algorithms in the selected cipher suite available to the application.
7. 選択された暗号スイート内の接続識別子（C_IおよびC_R）およびアプリケーションアルゴリズムをアプリケーションに利用可能にしてください。
After processing message_3, the Responder can compute PRK_out (see Section 4.1.3) and derive application keys using the EDHOC_Exporter interface (see Section 4.2.1). The Responder SHOULD NOT persistently store PRK_out or application keys until the application has authenticated the Initiator. The Responder SHOULD NOT send protected application data until the application has authenticated the Initiator.
message_3 を処理した後、Responder は PRK_out を計算し（4.1.3 節を参照）、EDHOC_Exporter インターフェースを使用してアプリケーションキーを導出できます（4.2.1 節を参照）。Responder は、アプリケーションが Initiator を認証するまで PRK_out やアプリケーションキーを永続的に保存すべきではありません。Responder は、アプリケーションが Initiator を認証するまで保護されたアプリケーションデータを送信すべきではありません。
If any processing step fails, then the Responder MUST send an EDHOC error message back as defined in Section 6, and the EDHOC session MUST be aborted.
もし処理のステップが失敗した場合、Responderはセクション6で定義されたEDHOCエラーメッセージを送信し、EDHOCセッションは中止されなければなりません。
This section specifies message_4, which is OPTIONAL to support. Key confirmation is normally provided by sending an application message from the Responder to the Initiator protected with a key derived with the EDHOC_Exporter, e.g., using OSCORE (see Appendix A). In deployments where no protected application message is sent from the Responder to the Initiator, message_4 MUST be supported and MUST be used. Two examples of such deployments are:
このセクションは、サポートがオプションであるメッセージ_4を指定しています。通常、鍵確認は、EDHOC_Exporterで導出された鍵を用いて保護されたアプリケーションメッセージをレスポンダからイニシエータに送信することで提供されます。例えば、OSCOREを使用します（付録Aを参照）。レスポンダからイニシエータに保護されたアプリケーションメッセージが送信されない展開では、メッセージ_4をサポートし、使用する必要があります。そのような展開の2つの例は次の通りです：
1. when EDHOC is only used for authentication and no application data is sent and
1. EDHOCが認証のみに使用され、アプリケーションデータが送信されない場合
2. when application data is only sent from the Initiator to the Responder.
2. アプリケーションデータがイニシエーターからレスポンダーに送信される場合。
Further considerations about when to use message_4 are provided in Sections 3.9 and 9.1.
セクション3.9と9.1には、message_4を使用するタイミングに関するさらなる考慮事項が提供されています。
message_4 SHALL be a CBOR Sequence (see Appendix C.1), as defined below.
message_4は、以下で定義されているCBORシーケンスである必要があります（詳細は付録C.1を参照）。
message_4 = (
CIPHERTEXT_4 : bstr,
)
The Responder SHALL compose message_4 as follows:
応答者は、次のようにメッセージ_4を作成しなければなりません。
* Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_4, the initialization vector IV_4 (if used by the AEAD algorithm), the plaintext PLAINTEXT_4, and the following parameters as input (see Appendix C.3):
* [RFC9052]のセクション5.2および5.3で定義されているCOSE_Encrypt0を、選択した暗号スイートのEDHOC AEADアルゴリズムを使用して、暗号化キーK_4、初期化ベクトルIV_4（AEADアルゴリズムで使用される場合）、平文PLAINTEXT_4、および入力として以下のパラメータを使用して計算します（付録C.3を参照）。
- protected = h''
- 保護された = h''
- external_aad = TH_4
- external_aad = TH_4
- K_4 and IV_4 are defined in Section 4.1.2
- K_4とIV_4はセクション4.1.2で定義されています。
- PLAINTEXT_4 = ( ? EAD_4 )
- PLAINTEXT_4 = ( ? EAD_4 )
o EAD_4 is external authorization data; see Section 3.8.
o EAD_4は外部認証データです。セクション3.8を参照してください。
CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.
CIPHERTEXT_4はCOSE_Encrypt0の「暗号文」です。
* Encode message_4 as a CBOR data item as specified in Section 5.5.1.
* 指定されたセクション5.5.1に従って、メッセージ_4をCBORデータアイテムとしてエンコードしてください。
The Initiator SHALL process message_4 as follows:
イニシエーターは、メッセージ_4を以下のように処理する必要があります。
* Decode message_4 (see Appendix C.1).
* メッセージ_4をデコードしてください（付録C.1を参照）。
* Retrieve the protocol state using available message correlation (e.g., the CoAP Token, the 5-tuple, or the prepended C_I; see Section 3.4.1).
* 利用可能なメッセージ相関（たとえば、CoAP トークン、5つ組、または先頭に挿入された C_I を参照してください。）を使用してプロトコルの状態を取得します。
* Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of [RFC9052], with the EDHOC AEAD algorithm in the selected cipher suite and the parameters defined in Section 5.5.2.
* [RFC9052]のセクション5.2および5.3で定義されているCOSE_Encrypt0を、選択された暗号スイート内のEDHOC AEADアルゴリズムとセクション5.5.2で定義されたパラメータを使用して復号化および検証してください。
* Make (if present) EAD_4 available to the application for EAD processing.
* アプリケーションで EAD 処理のために EAD_4 を利用可能にしてください。
If any processing step fails, then the Initiator MUST send an EDHOC error message back as defined in Section 6, and the EDHOC session MUST be aborted.
もし処理のステップが失敗した場合、イニシエーターはセクション6で定義されたEDHOCエラーメッセージを送信しなければならず、EDHOCセッションは中止されなければなりません。
After verifying message_4, the Initiator is assured that the Responder has calculated the key PRK_out (key confirmation) and that no other party can derive the key.
メッセージ_4を検証した後、イニシエーターは、レスポンダーが鍵PRK_out（鍵確認）を計算し、他の誰もその鍵を導出できないことを確信しています。
This section defines the format for error messages and the processing associated with the currently defined error codes. Additional error codes may be registered; see Section 10.4.
このセクションは、エラーメッセージのフォーマットと現在定義されているエラーコードに関連する処理を定義しています。追加のエラーコードを登録することができます。セクション10.4を参照してください。
Many kinds of errors can occur during EDHOC processing. As in CoAP, an error can be triggered by errors in the received message or internal errors in the receiving endpoint. Except for processing and formatting errors, it is up to the application when to send an error message. Sending error messages is essential for debugging but MAY be skipped if, for example, an EDHOC session cannot be found or due to denial-of-service reasons; see Section 9.7. Error messages in EDHOC are always fatal. After sending an error message, the sender MUST abort the EDHOC session. The receiver SHOULD treat an error message as an indication that the other party likely has aborted the EDHOC session. But since error messages might be forged, the receiver MAY try to continue the EDHOC session.
EDHOC処理中にはさまざまな種類のエラーが発生する可能性があります。CoAPと同様に、エラーは受信メッセージのエラーまたは受信エンドポイント内部のエラーによって引き起こされることがあります。処理およびフォーマットエラーを除いて、エラーメッセージを送信するタイミングはアプリケーション次第です。エラーメッセージの送信はデバッグには不可欠ですが、たとえばEDHOCセッションが見つからない場合やサービス拒否の理由などでスキップしても構いません。EDHOCにおけるエラーメッセージは常に致命的です。エラーメッセージを送信した後、送信者はEDHOCセッションを中止しなければなりません。受信者は、エラーメッセージを受信した場合、他の当事者がEDHOCセッションを中止した可能性が高いことを示すものとして扱うべきです。ただし、エラーメッセージが偽造されている可能性があるため、受信者はEDHOCセッションを継続しようとしても構いません。
An EDHOC error message can be sent by either endpoint as a reply to any non-error EDHOC message. How errors at the EDHOC layer are transported depends on lower layers, which need to enable error messages to be sent and processed as intended.
EDHOCエラーメッセージは、エンドポイントのどちらかが、エラーでないEDHOCメッセージに対する返信として送信できます。EDHOCレイヤーでのエラーの輸送方法は、下位レイヤーに依存し、エラーメッセージが意図どおりに送信および処理されるようにする必要があります。
error SHALL be a CBOR Sequence (see Appendix C.1), as defined below.
エラーは、以下で定義されているように、CBORシーケンスでなければなりません（付録C.1を参照）。
error = (
ERR_CODE : int,
ERR_INFO : any,
)
Figure 7: EDHOC Error Message
図7：EDHOCエラーメッセージ
where:
ただし：
* ERR_CODE is an error code encoded as an integer. The value 0 is reserved for success and can only be used internally; all other values (negative or positive) indicate errors.
* ERR_CODEは整数としてエンコードされたエラーコードです。値0は成功のために予約されており、内部でのみ使用できます。他のすべての値（負の値または正の値）はエラーを示します。
* ERR_INFO is error information. Content and encoding depend on the error code.
* ERR_INFOはエラー情報です。コンテンツとエンコーディングはエラーコードに依存します。
The remainder of this section specifies the currently defined error codes; see Table 3. Additional error codes and corresponding error information may be specified.
このセクションの残り部分は現在定義されているエラーコードを指定しています。表3を参照してください。追加のエラーコードと対応するエラー情報が指定される場合があります。
+==========+===============+===============================+
| ERR_CODE | ERR_INFO Type | Description |
+==========+===============+===============================+
| 0 | | Reserved for success |
+----------+---------------+-------------------------------+
| 1 | tstr | Unspecified error |
+----------+---------------+-------------------------------+
| 2 | suites | Wrong selected cipher suite |
+----------+---------------+-------------------------------+
| 3 | true | Unknown credential referenced |
+----------+---------------+-------------------------------+
| 23 | | Reserved |
+----------+---------------+-------------------------------+
Table 3: EDHOC Error Codes and Error Information
表3：EDHOCエラーコードとエラー情報
Error code 0 MAY be used internally in an application to indicate success, i.e., as a standard value in case of no error, e.g., in status reporting or log files. Error code 0 MUST NOT be used as part of the EDHOC message exchange. If an endpoint receives an error message with error code 0, then it MUST abort the EDHOC session and MUST NOT send an error message.
エラーコード0は、アプリケーション内で成功を示すために使用される場合があります。つまり、エラーがない場合の標準値として、ステータスレポートやログファイルなどで使用されます。エラーコード0は、EDHOCメッセージ交換の一部として使用してはいけません。エンドポイントがエラーコード0を含むエラーメッセージを受信した場合、EDHOCセッションを中止し、エラーメッセージを送信してはいけません。
Error code 1 is used for errors that do not have a specific error code defined. ERR_INFO MUST be a text string containing a human-readable diagnostic message that SHOULD be written in English, for example, "Method not supported". The diagnostic text message is mainly intended for software engineers who during debugging need to interpret it in the context of the EDHOC specification. The diagnostic message SHOULD be provided to the calling application where it SHOULD be logged.
エラーコード1は、特定のエラーコードが定義されていないエラーに使用されます。 ERR_INFOは、人間が読める診断メッセージを含むテキスト文字列でなければなりません。例えば、「Method not supported（サポートされていないメソッド）」といった内容です。診断用のテキストメッセージは、主にソフトウェアエンジニア向けに、EDHOC仕様のコンテキストで解釈する必要があるデバッグ中に使用されます。診断メッセージは、呼び出し元のアプリケーションに提供され、ログに記録されるべきです。
Error code 2 MUST only be used when replying to message_1 in case the cipher suite selected by the Initiator is not supported by the Responder or if the Responder supports a cipher suite more preferred by the Initiator than the selected cipher suite; see Section 5.2.3. In this case, ERR_INFO = SUITES_R and is of type suites; see Section 5.2.1. If the Responder does not support the selected cipher suite, then SUITES_R MUST include one or more supported cipher suites. If the Responder supports a cipher suite in SUITES_I other than the selected cipher suite (independently of if the selected cipher suite is supported or not), then SUITES_R MUST include the supported cipher suite in SUITES_I, which is most preferred by the Initiator. SUITES_R MAY include a single cipher suite; in which case, it is encoded as an int. If the Responder does not support any cipher suite in SUITES_I, then it SHOULD include all its supported cipher suites in SUITES_R.
エラーコード2は、イニシエーターが選択した暗号スイートがレスポンダーによってサポートされていない場合、またはレスポンダーが選択された暗号スイートよりもイニシエーターがより好ましい暗号スイートをサポートしている場合にのみ使用される必要があります。この場合、ERR_INFO = SUITES_Rであり、タイプはスイートです。レスポンダーが選択された暗号スイートをサポートしていない場合、SUITES_Rには1つ以上のサポートされている暗号スイートを含める必要があります。レスポンダーが選択された暗号スイート以外のSUITES_I内の暗号スイートをサポートしている場合（選択された暗号スイートがサポートされているかどうかに関係なく）、SUITES_Rにはイニシエーターが最も好ましいとするサポートされている暗号スイートを含める必要があります。SUITES_Rには1つの暗号スイートを含めることができます。この場合、intとしてエンコードされます。レスポンダーがSUITES_I内の任意の暗号スイートをサポートしていない場合、SUITES_Rにはすべてのサポートされている暗号スイートを含めるべきです。
In contrast to SUITES_I, the order of the cipher suites in SUITES_R has no significance.
SUITES_Iとは対照的に、SUITES_Rの暗号スイートの順序には意味がありません。
After receiving SUITES_R, the Initiator can determine which cipher suite to select (if any) for the next EDHOC run with the Responder. The Initiator SHOULD remember which selected cipher suite to use until the next message_1 has been sent; otherwise, the Initiator and Responder will run into an infinite loop where the Initiator selects its most preferred cipher suite and the Responder sends an error with supported cipher suites.
SUITES_Rを受け取った後、イニシエーターは、次のEDHOCランでレスポンダーと選択する暗号スイートを決定できます。イニシエーターは、次のmessage_1が送信されるまで使用する選択された暗号スイートを覚えておくべきです。そうでないと、イニシエーターとレスポンダーは、イニシエーターが最も好ましい暗号スイートを選択し、レスポンダーがサポートされている暗号スイートとエラーを送信する無限ループに陥ります。
After a completed EDHOC session, the Initiator MAY remember the selected cipher suite to use in future EDHOC sessions with this Responder. Note that if the Initiator or Responder is updated with new cipher suite policies, any cached information may be outdated.
EDHOC セッションが完了した後、イニシエーターはこのレスポンダーとの将来の EDHOC セッションで使用する選択された暗号スイートを覚えてもよいです。イニシエーターまたはレスポンダーが新しい暗号スイートポリシーで更新された場合、キャッシュされた情報は古くなる可能性があることに注意してください。
Note that the Initiator's list of supported cipher suites and order of preference is fixed (see Sections 5.2.1 and 5.2.2). Furthermore, the Responder SHALL only accept message_1 if the selected cipher suite is the first cipher suite in SUITES_I that the Responder also supports (see Section 5.2.3). Following this procedure ensures that the selected cipher suite is the most preferred (by the Initiator) cipher suite supported by both parties. For examples, see Section 6.3.2.
イニシエーターのサポートする暗号スイートのリストと優先順位は固定されています（セクション5.2.1および5.2.2を参照）。さらに、レスポンダーは、選択された暗号スイートが、レスポンダーもサポートしているSUITES_I内の最初の暗号スイートである場合にのみ、message_1を受け入れなければなりません（セクション5.2.3を参照）。この手順に従うことで、選択された暗号スイートが、両者によってサポートされる最も優先される（イニシエーターによって）暗号スイートであることが保証されます。例については、セクション6.3.2を参照してください。
If the selected cipher suite is not the first cipher suite that the Responder supports in SUITES_I received in message_1, then the Responder MUST abort the EDHOC session; see Section 5.2.3. If SUITES_I in message_1 is manipulated, then the integrity verification of message_2 containing the transcript hash TH_2 will fail and the Initiator will abort the EDHOC session.
選択された暗号スイートが、message_1で受信したSUITES_IでResponderがサポートする最初の暗号スイートでない場合、ResponderはEDHOCセッションを中止しなければなりません。SUITES_Iがmessage_1で操作されている場合、トランスクリプトハッシュTH_2を含むmessage_2の整合性検証が失敗し、InitiatorはEDHOCセッションを中止します。
Assume that the Initiator supports the five cipher suites, 5, 6, 7, 8, and 9, in decreasing order of preference. Figures 8 and 9 show two examples of how the Initiator can format SUITES_I and how SUITES_R is used by Responders to give the Initiator information about the cipher suites that the Responder supports.
前提として、イニシエーターが暗号スイート5、6、7、8、9を好みの順にサポートしていると仮定します。図8と9は、イニシエーターがSUITES_Iをどのようにフォーマットできるかの2つの例を示しており、SUITES_Rがレスポンダーによって使用され、レスポンダーがサポートしている暗号スイートに関する情報をイニシエーターに提供します。
In Example 1 (Figure 8), the Responder supports cipher suite 6 but not the initially selected cipher suite 5. The Responder rejects the first message_1 with an error indicating support for suite 6 in SUITES_R. The Initiator also supports suite 6 and therefore selects suite 6 in the second message_1. The Initiator prepends in SUITES_I the selected suite 6 with the more preferred suites, in this case suite 5, to mitigate a potential attack on the cipher suite negotiation.
Example 1（図8）では、レスポンダは暗号スイート6をサポートしていますが、最初に選択された暗号スイート5はサポートしていません。レスポンダは、SUITES_Rでスイート6をサポートしていることを示すエラーを含む最初のメッセージ_1を拒否します。イニシエータもスイート6をサポートしているため、2番目のメッセージ_1でスイート6を選択します。イニシエータは、暗号スイートの交渉に対する潜在的な攻撃を緩和するために、選択されたスイート6をより好ましいスイート（この場合はスイート5）でSUITES_Iに先頭に追加します。
Initiator Responder
| METHOD, SUITES_I = 5, G_X, C_I, EAD_1 |
+------------------------------------------------------------------>|
| message_1 |
| |
| ERR_CODE = 2, SUITES_R = 6 |
|<------------------------------------------------------------------+
| error |
| |
| METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1 |
+------------------------------------------------------------------>|
| message_1 |
Figure 8: Cipher Suite Negotiation Example 1
図8：暗号スイートの交渉例1
In Example 2 (Figure 9), the Responder supports cipher suites 8 and 9 but not the more preferred (by the Initiator) cipher suites 5, 6 or 7. To illustrate the negotiation mechanics, we let the Initiator first make a guess that the Responder supports suite 6 but not suite 5. Since the Responder supports neither 5 nor 6, it rejects the first message_1 with an error indicating support for suites 8 and 9 in SUITES_R (in any order). The Initiator also supports suites 8 and 9, and prefers suite 8, so it selects suite 8 in the second message_1. The Initiator prepends in SUITES_I the selected suite 8 with the more preferred suites in order of preference, in this case, suites 5, 6 and 7, to mitigate a potential attack on the cipher suite negotiation.
例2（図9）では、レスポンダは暗号スイート8と9をサポートしていますが、より好ましい（イニシエータにとって）暗号スイート5、6、7はサポートしていません。交渉のメカニズムを説明するために、イニシエータが最初にレスポンダがスイート6をサポートしているがスイート5をサポートしていないと推測することにしました。レスポンダは5も6もサポートしていないため、最初のメッセージ_1をエラーで拒否し、SUITES_Rでスイート8と9をサポートしていることを示します（どちらの順序でも）。イニシエータもスイート8と9をサポートしており、スイート8を選択します。イニシエータは、選択したスイート8を、この場合はスイート5、6、7の順に好ましいスイートとともにSUITES_Iに追加します。これにより、暗号スイートの交渉に対する潜在的な攻撃を緩和します。
Note 1. If the Responder had supported suite 5, then the first message_1 would not have been accepted either, since the Responder observes that suite 5 is more preferred by the Initiator than the selected suite 6. In that case, the Responder would have included suite 5 in SUITES_R of the response, and it would then have become the selected and only suite in the second message_1.
注1：もしレスポンダがスイート5をサポートしていた場合、最初のメッセージ1も受け入れられなかったでしょう。なぜなら、レスポンダはイニシエータよりも選択されたスイート6よりもスイート5をより好むと観察しているからです。その場合、レスポンダは応答のSUITES_Rにスイート5を含め、それが第2のメッセージ1で選択された唯一のスイートになったでしょう。
Note 2. For each message_1, the Initiator MUST generate a new ephemeral ECDH key pair matching the selected cipher suite.
各メッセージ_1について、イニシエーターは選択された暗号スイートに一致する新しいエフェメラルECDHキーペアを生成する必要があります。
Initiator Responder
| METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1 |
+------------------------------------------------------------------>|
| message_1 |
| |
| ERR_CODE = 2, SUITES_R = [9, 8] |
|<------------------------------------------------------------------+
| error |
| |
| METHOD, SUITES_I = [5, 6, 7, 8], G_X, C_I, EAD_1 |
+------------------------------------------------------------------>|
| message_1 |
Figure 9: Cipher Suite Negotiation Example 2
図9：暗号スイートの交渉例2
Error code 3 is used for errors due to a received credential identifier (ID_CRED_R in message_2 or ID_CRED_I message_3) containing a reference to a credential that the receiving endpoint does not have access to. The intent with this error code is that the endpoint who sent the credential identifier should, for the next EDHOC session, try another credential identifier supported according to the application profile.
エラーコード3は、受信した資格情報識別子（メッセージ2のID_CRED_Rまたはメッセージ3のID_CRED_I）が、受信エンドポイントがアクセス権を持っていない資格情報への参照を含んでいるためのエラーに使用されます。このエラーコードの意図は、資格情報識別子を送信したエンドポイントは、次のEDHOCセッションでは、アプリケーションプロファイルに従ってサポートされる別の資格情報識別子を試すべきであることです。
For example, an application profile could list x5t and x5chain as supported credential identifiers and state that x5t should be used if it can be assumed that the X.509 certificate is available at the receiving side. This error code thus enables the certificate chain to be sent only when needed, bearing in mind that error messages are not protected so an adversary can try to cause unnecessary, large credential identifiers.
たとえば、アプリケーションプロファイルには、サポートされる資格情報識別子としてx5tおよびx5chainがリストされ、x5tが受信側でX.509証明書が利用可能であると仮定できる場合に使用されるべきであると記載されています。したがって、このエラーコードにより、エラーメッセージが保護されていないため、敵対者が不必要な大きな資格情報識別子を引き起こそうとする可能性があることを考慮して、証明書チェーンが必要な場合にのみ送信されるようになります。
For the error code 3, the error information SHALL be the CBOR simple value true (0xf5). Error code 3 MUST NOT be used when the received credential identifier type is not supported.
エラーコード3について、エラー情報はCBORの単純な値であるtrue (0xf5) でなければなりません。受信した資格情報識別子のタイプがサポートされていない場合、エラーコード3は使用してはいけません。
By default, EDHOC assumes that message duplication is handled by the transport (which is exemplified by CoAP in this section); see Appendix A.2.
デフォルトでは、EDHOCはメッセージの重複がトランスポートによって処理されると想定しています（このセクションではCoAPが例示されています）；Appendix A.2を参照してください。
Deduplication of CoAP messages is described in Section 4.5 of [RFC7252]. This handles the case when the same Confirmable (CON) message is received multiple times due to missing acknowledgment on the CoAP messaging layer. The recommended processing in [RFC7252] is that the duplicate message is acknowledged, but the received message is only processed once by the CoAP stack.
CoAPメッセージの重複排除は[RFC7252]のセクション4.5で説明されています。これは、CoAPメッセージングレイヤーで確認応答が欠落したために同じ確認可能(CON)メッセージが複数回受信された場合を扱います。[RFC7252]で推奨される処理は、重複メッセージが確認されるが、受信したメッセージはCoAPスタックによって1回だけ処理されることです。
Message deduplication is resource demanding and therefore not supported in all CoAP implementations. Since EDHOC is targeting constrained environments, it is desirable that EDHOC can optionally support transport layers that do not handle message duplication. Special care is needed to avoid issues with duplicate messages; see Section 5.1.
メッセージの重複排除はリソースを要求するため、すべてのCoAP実装でサポートされているわけではありません。EDHOCは制約のある環境を対象としているため、メッセージの重複を処理しないトランスポート層をオプションでサポートできると望ましいです。重複メッセージの問題を回避するためには特別な注意が必要です。セクション5.1を参照してください。
The guiding principle here is similar to the deduplication processing on the CoAP messaging layer, i.e., a received duplicate EDHOC message SHALL NOT result in another instance of the next EDHOC message. The result MAY be that a duplicate next EDHOC message is sent, provided it is still relevant with respect to the current protocol state. In any case, the received message MUST NOT be processed more than once in the same EDHOC session. This is called "EDHOC message deduplication".
ここでの指針は、CoAPメッセージングレイヤーでの重複排除処理と類似しており、つまり、受信した重複したEDHOCメッセージは、次のEDHOCメッセージの別のインスタンスにはならないべきです。結果として、重複した次のEDHOCメッセージが送信される可能性がありますが、それが現在のプロトコル状態に関連している場合に限ります。いずれの場合でも、受信したメッセージは同じEDHOCセッション内で複数回処理されてはなりません。これを「EDHOCメッセージの重複排除」と呼びます。
An EDHOC implementation MAY store the previously sent EDHOC message to be able to resend it.
EDHOCの実装は、以前に送信されたEDHOCメッセージを保存して再送信できるようにしてもよいです。
In principle, if the EDHOC implementation would deterministically regenerate the identical EDHOC message previously sent, it would be possible to instead store the protocol state to be able to recreate and resend the previously sent EDHOC message. However, even if the protocol state is fixed, the message generation may introduce differences that compromise security. For example, in the generation of message_3, if I is performing a (non-deterministic) ECDSA signature (say, method 0 or 1 and cipher suite 2 or 3), then PLAINTEXT_3 is randomized, but K_3 and IV_3 are the same, leading to a key and nonce reuse.
原則として、EDHOCの実装が以前に送信された同一のEDHOCメッセージを決定的に再生成する場合、代わりにプロトコルの状態を保存して以前に送信されたEDHOCメッセージを再作成して再送信することが可能になります。ただし、プロトコルの状態が固定されていても、メッセージ生成によってセキュリティが損なわれる可能性があります。たとえば、メッセージ_3の生成時に、Iが（非決定的な）ECDSA署名（たとえば、メソッド0または1および暗号スイート2または3）を実行している場合、PLAINTEXT_3はランダム化されますが、K_3とIV_3は同じままであり、鍵とノンスの再利用が発生します。
The EDHOC implementation MUST NOT store the previous protocol state and regenerate an EDHOC message if there is a risk that the same key and IV are used for two (or more) distinct messages.
EDHOCの実装は、前のプロトコルの状態を保存しておくべきではなく、同じ鍵とIVが2つ以上の異なるメッセージで使用されるリスクがある場合には、EDHOCメッセージを再生成する必要があります。
The previous message or protocol state MUST NOT be kept longer than what is required for retransmission, for example, in the case of CoAP transport, no longer than the EXCHANGE_LIFETIME (see Section 4.8.2 of [RFC7252]).
前のメッセージやプロトコルの状態は、再送信に必要な時間よりも長く保持してはいけません。たとえば、CoAPトランスポートの場合、EXCHANGE_LIFETIME（[RFC7252]のセクション4.8.2を参照）よりも長く保持してはいけません。
In the absence of an application profile specifying otherwise:
特定の指定がない場合:
* An implementation MAY support only an Initiator or only a Responder.
* 実装はイニシエーターのみまたはレスポンダーのみをサポートする場合があります。
* An implementation MAY support only a single method. None of the methods are mandatory to implement.
* 実装は1つのメソッドのみをサポートする場合があります。いずれのメソッドも実装が必須ではありません。
* Implementations MUST support 'kid' parameters. None of the other COSE header parameters are mandatory to implement.
* 実装は 'kid' パラメータをサポートする必要があります。他のCOSEヘッダーパラメータは実装する必要はありません。
* An implementation MAY support only a single credential type (CCS, CWT, X.509, or C509). None of the credential types are mandatory to implement.
* 実装は1つの資格情報タイプ（CCS、CWT、X.509、またはC509）のみをサポートしてもよい。いずれの資格情報タイプも実装が必須ではありません。
* Implementations MUST support the EDHOC_Exporter.
* 実装はEDHOC_Exporterをサポートする必要があります。
* Implementations MAY support message_4. Error codes (ERR_CODE) 1 and 2 MUST be supported.
* 実装は message_4 をサポートする場合があります。エラーコード（ERR_CODE）1 および 2 はサポートされる必要があります。
* Implementations MUST support EAD.
* 実装は EAD をサポートする必要があります。
* Implementations MUST support cipher suites 2 and 3. Cipher suites 2 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-16-64-128, SHA-256) only differ in the size of the MAC length, so supporting one or both of these is not significantly different. Implementations only need to implement the algorithms needed for their supported methods.
* 実装は、暗号スイート2および3をサポートする必要があります。暗号スイート2（AES-CCM-16-64-128、SHA-256、8、P-256、ES256、AES-CCM-16-64-128、SHA-256）および3（AES-CCM-16-128-128、SHA-256、16、P-256、ES256、AES-CCM-16-64-128、SHA-256）は、MAC長のサイズのみ異なるため、これらのいずれかまたは両方をサポートすることには大きな違いはありません。実装は、サポートされているメソッドに必要なアルゴリズムのみを実装する必要があります。
EDHOC has similar security properties as can be expected from the theoretical SIGMA-I protocol [SIGMA] and the Noise XX pattern [Noise], which are similar to methods 0 and 3, respectively. Proven security properties are detailed in the security analysis publications referenced at the end of this section.
EDHOCは、理論的なSIGMA-Iプロトコル[SIGMA]およびNoise XXパターン[Noise]に期待されるような類似したセキュリティ特性を持っています。それぞれ、メソッド0および3に類似しています。証明されたセキュリティ特性は、このセクションの最後に参照されているセキュリティ分析の出版物に詳細に記載されています。
Using the terminology from [SIGMA], EDHOC provides forward secrecy, mutual authentication with aliveness, consistency, and peer awareness. As described in [SIGMA], message_3 provides peer awareness to the Responder, while message_4 provides peer awareness to the Initiator. By including the authentication credentials in the transcript hash, EDHOC protects against an identity misbinding attack like the Duplicate Signature Key Selection (DSKS) that the MAC-then-Sign variant of SIGMA-I is otherwise vulnerable to.
[EDHOC]は、[SIGMA]の用語を使用して、前方秘匿性、生存確認を伴う相互認証、一貫性、およびピア認識を提供します。[SIGMA]に記載されているように、message_3はResponderにピア認識を提供し、message_4はInitiatorにピア認識を提供します。認証資格情報をトランスクリプトハッシュに含めることで、EDHOCは、MAC-then-SignバリアントのSIGMA-Iが脆弱性を持つDuplicate Signature Key Selection（DSKS）のようなアイデンティティ誤結合攻撃に対して保護します。
As described in [SIGMA], different levels of identity protection are provided to the Initiator and Responder. EDHOC provides identity protection of the Initiator against active attacks and identity protection of the Responder against passive attacks. An active attacker can get the credential identifier of the Responder by eavesdropping on the destination address used for transporting message_1 and then sending its own message_1 to the same address. The roles should be assigned to protect the most sensitive identity/ identifier, typically that which is not possible to infer from routing information in the lower layers.
[シグマ] に記載されているように、EDHOC はイニシエータとレスポンダに対して異なるレベルのアイデンティティ保護を提供します。EDHOC は、アクティブ攻撃に対するイニシエータのアイデンティティ保護と、受動攻撃に対するレスポンダのアイデンティティ保護を提供します。アクティブ攻撃者は、メッセージ_1 を輸送するために使用される宛先アドレスを盗聴し、その後自分自身のメッセージ_1 を同じアドレスに送信することで、レスポンダの資格情報識別子を取得することができます。役割は、通常、下位層のルーティング情報から推測することができない最も機密性の高いアイデンティティ/識別子を保護するために割り当てられるべきです。
EDHOC messages might change in transit due to a noisy channel or through modification by an attacker. Changes in message_1 and message_2 (except Signature_or_MAC_2 when the signature scheme is not strongly unforgeable) are detected when verifying Signature_or_MAC_2. Changes to not strongly unforgeable Signature_or_MAC_2 and message_3 are detected when verifying CIPHERTEXT_3. Changes to message_4 are detected when verifying CIPHERTEXT_4.
EDHOC メッセージは、ノイズの多いチャネルや攻撃者による改ざんによって送信中に変更される可能性があります。Signature_or_MAC_2 の検証時には、message_1 と message_2 の変更が検出されます（署名スキームが強力に偽造できない場合を除く）。Signature_or_MAC_2 と message_3 の強力に偽造できない変更は、CIPHERTEXT_3 の検証時に検出されます。message_4 の変更は、CIPHERTEXT_4 の検証時に検出されます。
Compared to [SIGMA], EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as algorithms, external authorization data, and previous plaintext messages. This protects against an attacker replaying messages or injecting messages from another EDHOC session.
[EDHOC]は[SIGMA]と比較して、明示的なメソッドタイプを追加し、アルゴリズム、外部認可データ、および以前の平文メッセージなどの追加要素に対するメッセージ認証範囲を拡大しています。これにより、攻撃者がメッセージをリプレイしたり、別のEDHOCセッションからメッセージを挿入することを防ぎます。
EDHOC also adds the selection of connection identifiers and downgrade-protected negotiation of cryptographic parameters, i.e., an attacker cannot affect the negotiated parameters. A single session of EDHOC does not include negotiation of cipher suites, but it enables the Responder to verify that the selected cipher suite is the most preferred cipher suite by the Initiator that is supported by both the Initiator and Responder and to abort the EDHOC session if not.
EDHOCは接続識別子の選択と暗号パラメータのダウングレード保護付き交渉も追加します。つまり、攻撃者は交渉されたパラメータに影響を与えることができません。EDHOCの単一セッションには、暗号スイートの交渉は含まれていませんが、Responderは選択された暗号スイートがInitiatorによって最も好ましい暗号スイートであり、InitiatorとResponderの両方でサポートされていることを検証し、そうでない場合はEDHOCセッションを中止できます。
As required by [RFC7258], IETF protocols need to mitigate pervasive monitoring when possible. Therefore, EDHOC only supports methods with ephemeral Diffie-Hellman and provides a key update function (see Appendix H) for lightweight application protocol rekeying. Either of these provides forward secrecy, in the sense that compromise of the private authentication keys does not compromise past session keys (PRK_out) and compromise of a session key does not compromise past session keys. Frequently re-running EDHOC with ephemeral Diffie-Hellman forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, which is a significant sustained attack.
[RFC7258] によって要求されているように、IETF プロトコルは可能な限り普遍的な監視を緩和する必要があります。そのため、EDHOC は一時的な Diffie-Hellman をサポートし、軽量アプリケーションプロトコルの再鍵交換のためのキー更新機能（付録 H を参照）を提供しています。これらのいずれかが前方秘匿性を提供し、つまり、プライベート認証キーの侵害が過去のセッションキー（PRK_out）を侵害しないようにし、セッションキーの侵害が過去のセッションキーを侵害しないようにします。一時的な Diffie-Hellman を使用して EDHOC を頻繁に再実行することで、攻撃者は動的な鍵の流出を行う必要があり、そのためには共犯者との継続的なやり取りが必要となり、それは重大な持続的な攻撃です。
To limit the effect of breaches, it is important to limit the use of symmetric group keys for bootstrapping. Therefore, EDHOC strives to make the additional cost of using raw public keys and self-signed certificates as small as possible. Raw public keys and self-signed certificates are not a replacement for a public key infrastructure but SHOULD be used instead of symmetric group keys for bootstrapping.
侵害の影響を制限するためには、ブートストラップ用の対称グループキーの使用を制限することが重要です。そのため、EDHOCは、生の公開鍵と自己署名証明書を使用する追加コストをできるだけ小さくするよう努めています。生の公開鍵と自己署名証明書は、公開鍵インフラの代替ではありませんが、ブートストラップ用の対称グループキーの代わりに使用するべきです。
Compromise of the long-term keys (private signature or static DH keys) does not compromise the security of completed EDHOC sessions. Compromising the private authentication keys of one party lets an active attacker impersonate that compromised party in EDHOC sessions with other parties but does not let the attacker impersonate other parties in EDHOC sessions with the compromised party. Compromise of the long-term keys does not enable a passive attacker to compromise future session keys (PRK_out). Compromise of the HKDF input parameters (ECDH shared secret) leads to compromise of all session keys derived from that compromised shared secret. Compromise of one session key does not compromise other session keys. Compromise of PRK_out leads to compromise of all keying material derived with the EDHOC_Exporter.
長期キー（プライベート署名または静的DHキー）の妥協は、完了したEDHOCセッションのセキュリティを妥協させません。一方の当事者のプライベート認証キーを妥協させると、アクティブな攻撃者がその妥協された当事者を他の当事者とのEDHOCセッションで偽装することができますが、その攻撃者が妥協された当事者とのEDHOCセッションで他の当事者を偽装することはできません。長期キーの妥協は、受動的な攻撃者が将来のセッションキー（PRK_out）を妥協することを可能にしません。HKDFの入力パラメータ（ECDH共有秘密）の妥協は、その妥協された共有秘密から派生したすべてのセッションキーの妥協につながります。1つのセッションキーの妥協は他のセッションキーを妥協させません。PRK_outの妥協は、EDHOC_Exporterで派生したすべての鍵材料の妥協につながります。
Based on the cryptographic algorithm requirements (Section 9.3), EDHOC provides a minimum of 64-bit security against online brute force attacks and a minimum of 128-bit security against offline brute force attacks. To break 64-bit security against online brute force, an attacker would on average have to send 4.3 billion messages per second for 68 years, which is infeasible in constrained IoT radio technologies. A forgery against a 64-bit MAC in EDHOC breaks the security of all future application data, while a forgery against a 64-bit MAC in the subsequent application protocol (e.g., OSCORE [RFC8613]) typically only breaks the security of the data in the forged packet.
暗号アルゴリズムの要件（セクション9.3）に基づいて、EDHOCはオンラインの総当たり攻撃に対して最低64ビットのセキュリティを提供し、オフラインの総当たり攻撃に対しては最低128ビットのセキュリティを提供します。オンラインの総当たり攻撃に対して64ビットのセキュリティを破るには、攻撃者は平均して68年間にわたって1秒あたり43億のメッセージを送信する必要がありますが、これは制約のあるIoT無線技術では実現不可能です。EDHOCの64ビットMACに対する偽造は、すべての将来のアプリケーションデータのセキュリティを破りますが、後続のアプリケーションプロトコル（例：OSCORE [RFC8613]）における64ビットMACに対する偽造は通常、偽造されたパケット内のデータのセキュリティのみを破ります。
As the EDHOC session is aborted when verification fails, the security against online attacks is given by the sum of the strength of the verified signatures and MACs (including MAC in AEAD). As an example, if EDHOC is used with method 3, cipher suite 2, and message_4, the Responder is authenticated with 128-bit security against online attacks (the sum of the 64-bit MACs in message_2 and message_4). The same principle applies for MACs in an application protocol keyed by EDHOC as long as EDHOC is re-run when verification of the first MACs in the application protocol fails. As an example, if EDHOC with method 3 and cipher suite 2 is used as in Figure 2 of [EDHOC-CoAP-OSCORE], 128-bit mutual authentication against online attacks can be achieved after completion of the first OSCORE request and response.
EDHOCセッションが検証に失敗した場合に中止されるため、オンライン攻撃に対するセキュリティは、検証された署名とMAC（AEAD内のMACを含む）の強度の合計によって提供されます。例えば、EDHOCがメソッド3、暗号スイート2、およびメッセージ_4と一緒に使用される場合、レスポンダはオンライン攻撃に対して128ビットのセキュリティで認証されます（メッセージ_2とメッセージ_4の64ビットのMACの合計）。同じ原則は、アプリケーションプロトコル内のMACにEDHOCでキー付けされる場合にも適用されます。アプリケーションプロトコル内の最初のMACの検証に失敗した場合は、EDHOCが再実行される限りです。例えば、[EDHOC-CoAP-OSCORE]の図2のように、メソッド3および暗号スイート2を使用したEDHOCが、最初のOSCOREリクエストとレスポンスの完了後に128ビットの相互認証をオンライン攻撃に対して達成できます。
After sending message_3, the Initiator is assured that no other party than the Responder can compute the key PRK_out. While the Initiator can securely send protected application data, the Initiator SHOULD NOT persistently store the keying material PRK_out until the Initiator has verified message_4 or a message protected with a derived application key, such as an OSCORE message, from the Responder. After verifying message_3, the Responder is assured that an honest Initiator has computed the key PRK_out. The Responder can securely derive and store the keying material PRK_out and send protected application data.
message_3を送信した後、イニシエーターは、レスポンダー以外の他の当事者が鍵PRK_outを計算できないことを確信しています。イニシエーターは保護されたアプリケーションデータを安全に送信できますが、イニシエーターはmessage_4を検証するか、OSCOREメッセージなどの派生アプリケーションキーで保護されたメッセージをレスポンダーから受信するまで、鍵素材PRK_outを永続的に保存すべきではありません。message_3を検証した後、レスポンダーは正直なイニシエーターが鍵PRK_outを計算したことを確信しています。レスポンダーは安全に鍵素材PRK_outを導出して保存し、保護されたアプリケーションデータを送信できます。
External authorization data sent in message_1 (EAD_1) or message_2 (EAD_2) should be considered unprotected by EDHOC; see Section 9.5. EAD_2 is encrypted, but the Responder has not yet authenticated the Initiator and the encryption does not provide confidentiality against active attacks.
メッセージ_1（EAD_1）またはメッセージ_2（EAD_2）に送信された外部認証データは、EDHOCによって保護されていないと見なすべきです。EAD_2は暗号化されていますが、応答者はまだイニシエータを認証しておらず、暗号化は能動的な攻撃に対して機密性を提供していません。
External authorization data sent in message_3 (EAD_3) or message_4 (EAD_4) is protected between the Initiator and Responder by the protocol, but note that EAD fields may be used by the application before the message verification is completed; see Section 3.8. Designing a secure mechanism that uses EAD is not necessarily straightforward. This document only provides the EAD transport mechanism, but the problem of agreeing on the surrounding context and the meaning of the information passed to and from the application remains. Any new uses of EAD should be subject to careful review.
外部認証データがメッセージ_3（EAD_3）またはメッセージ_4（EAD_4）で送信されますが、イニシエータとレスポンダ間でプロトコルによって保護されています。ただし、EADフィールドはメッセージの検証が完了する前にアプリケーションによって使用される可能性があります。セクション3.8を参照してください。EADを使用する安全なメカニズムを設計することは必ずしも簡単ではありません。この文書はEAD輸送メカニズムのみを提供していますが、アプリケーション間で渡される情報の周囲の文脈や意味について合意する問題は残っています。EADの新しい使用は注意深く検討されるべきです。
Key Compromise Impersonation (KCI):
キー妥協詐欺（KCI）:
In EDHOC authenticated with signature keys, EDHOC provides KCI protection against an attacker having access to the long-term key or the ephemeral secret key. With static Diffie-Hellman key authentication, KCI protection would be provided against an attacker having access to the long-term Diffie-Hellman key but not to an attacker having access to the ephemeral secret key. Note that the term KCI has typically been used for compromise of long-term keys and that an attacker with access to the ephemeral secret key can only attack that specific EDHOC session.
EDHOCで署名キーを使用して認証された場合、EDHOCは長期キーまたは一時的な秘密キーにアクセスできる攻撃者に対してKCI保護を提供します。静的Diffie-Hellman鍵認証では、長期Diffie-Hellman鍵にアクセスできる攻撃者に対してKCI保護が提供されますが、一時的な秘密キーにアクセスできる攻撃者には提供されません。KCIという用語は通常、長期キーの侵害に使用されており、一時的な秘密キーにアクセスできる攻撃者は特定のEDHOCセッションのみを攻撃できることに注意してください。
Repudiation:
拒否:
If an endpoint authenticates with a signature, the other endpoint can prove that the endpoint performed a run of the protocol by presenting the data being signed as well as the signature itself. With static Diffie-Hellman key authentication, the authenticating endpoint can deny having participated in the protocol.
エンドポイントが署名で認証する場合、もう一方のエンドポイントは、署名されたデータと署名自体を提示することで、プロトコルの実行を証明できます。静的Diffie-Hellman鍵認証では、認証するエンドポイントはプロトコルに参加していないと否定することができます。
Earlier versions of EDHOC have been formally analyzed [Bruni18] [Norrman20] [CottierPointcheval22] [Jacomme23] [GuentherIlunga22], and the specification has been updated based on the analysis.
以前のバージョンのEDHOCは形式的に分析されており、仕様はその分析に基づいて更新されています。
The SIGMA protocol requires that the encryption of message_3 provides confidentiality against active attackers and EDHOC message_4 relies on the use of authenticated encryption. Hence, the message authenticating functionality of the authenticated encryption in EDHOC is critical, i.e., authenticated encryption MUST NOT be replaced by plain encryption only, even if authentication is provided at another level or through a different mechanism.
SIGMAプロトコルでは、message_3の暗号化がアクティブな攻撃者に対して機密性を提供する必要があり、EDHOC message_4は認証付き暗号の使用に依存しています。したがって、EDHOCの認証付き暗号のメッセージ認証機能は重要であり、つまり、認証付き暗号は他のレベルで認証が提供されている場合や異なるメカニズムを通じて提供されている場合でも、プレーンな暗号化のみで認証付き暗号を置き換えてはなりません。
To reduce message overhead, EDHOC does not use explicit nonces and instead relies on the ephemeral public keys to provide randomness to each EDHOC session. A good amount of randomness is important for the key generation to provide liveness and to protect against interleaving attacks. For this reason, the ephemeral keys MUST NOT be used in more than one EDHOC message, and both parties SHALL generate fresh, random ephemeral key pairs. Note that an ephemeral key may be used to calculate several ECDH shared secrets. When static Diffie-Hellman authentication is used, the same ephemeral key is used in both ephemeral-ephemeral and ephemeral-static ECDH.
EDHOCは明示的なナンスを使用せず、代わりに一時的な公開鍵を各EDHOCセッションにランダム性を提供するために使用します。キー生成には十分なランダム性が重要であり、ライブネスを提供し、交差攻撃に対して保護するためです。そのため、一時的な鍵は1つのEDHOCメッセージで複数回使用してはならず、両者は新しいランダムな一時的な鍵ペアを生成しなければなりません。一時的な鍵は複数のECDH共有秘密を計算するために使用できます。静的Diffie-Hellman認証が使用される場合、同じ一時的な鍵が一時的-一時的および一時的-静的ECDHの両方で使用されます。
As discussed in [SIGMA], the encryption of message_2 only needs to protect against a passive attacker since active attackers can always get the Responder's identity by sending their own message_1. EDHOC uses the EDHOC_Expand function (typically HKDF-Expand) as a binary additive stream cipher that is proven secure as long as the expand function is a Pseudorandom Function (PRF). HKDF-Expand is not often used as a stream cipher as it is slow on long messages, and most applications require both confidentiality with indistinguishability under adaptive chosen ciphertext attack (IND-CCA2) as well as integrity protection. For the encryption of message_2, any speed difference is negligible, IND-CCA2 does not increase security, and integrity is provided by the inner MAC (and signature depending on method).
[SIGMA] で議論されたように、message_2 の暗号化は、アクティブな攻撃者が常に自分自身の message_1 を送信することで Responder のアイデンティティを取得できるため、受動的な攻撃者に対してのみ保護する必要があります。EDHOC は、拡張関数（通常は HKDF-Expand）をバイナリ加算ストリーム暗号として使用し、その拡張関数が擬似ランダム関数（PRF）である限り安全であることが証明されています。HKDF-Expand は、長いメッセージでは遅いため、ストリーム暗号としてはあまり使用されません。ほとんどのアプリケーションでは、適応的選択された暗号文攻撃（IND-CCA2）における区別不能性と機密性の両方が必要であり、整合性保護も必要です。message_2 の暗号化において、速度の違いは無視でき、IND-CCA2 はセキュリティを向上させません。整合性は内部 MAC によって提供されます（およびメソッドによっては署名も）。
Requirements for how to securely generate, validate, and process the public keys depend on the elliptic curve. For X25519 and X448, the requirements are defined in [RFC7748]. For X25519 and X448, the check for all-zero output as specified in Section 6 of [RFC7748] MUST be done. For secp256r1, secp384r1, and secp521r1, the requirements are defined in Section 5 of [SP-800-56A]. For secp256r1, secp384r1, and secp521r1, at least partial public key validation MUST be done.
X25519およびX448については、要件は[RFC7748]で定義されています。X25519およびX448については、[RFC7748]のセクション6で指定されたすべてゼロの出力のチェックが必須です。secp256r1、secp384r1、およびsecp521r1については、要件は[SP-800-56A]のセクション5で定義されています。secp256r1、secp384r1、およびsecp521r1については、少なくとも部分的な公開鍵の検証が必要です。
The same authentication credential MAY be used for both the Initiator and Responder roles. As noted in Section 12 of [RFC9052], the use of a single key for multiple algorithms is strongly discouraged unless proven secure by a dedicated cryptographic analysis. In particular, this recommendation applies to using the same private key for static Diffie-Hellman authentication and digital signature authentication. A preliminary conjecture is that a minor change to EDHOC may be sufficient to fit the analysis of a secure shared signature and ECDH key usage in [Degabriele11] and [Thormarker21]. Note that Section 5.6.3.2 of [SP-800-56A] allows a key agreement key pair to be used with a signature algorithm in certificate requests.
同じ認証資格情報は、イニシエーターとレスポンダーの両方に使用することができます。[RFC9052]のセクション12に記載されているように、複数のアルゴリズムに単一のキーを使用することは、専用の暗号解析によって安全性が証明されるまで強く推奨されません。特に、静的ディフィー・ヘルマン認証とデジタル署名認証に同じ秘密鍵を使用する場合には、この推奨事項が適用されます。EDHOCにわずかな変更を加えることで、[Degabriele11]および[Thormarker21]での安全な共有署名とECDH鍵の使用の解析に適合する可能性があるという仮説が立てられます。[SP-800-56A]のセクション5.6.3.2によると、鍵合意鍵ペアを証明書リクエストで署名アルゴリズムと共に使用することが許可されています。
The property that a completed EDHOC session implies that another identity has been active is upheld as long as the Initiator does not have its own identity in the set of Responder identities it is allowed to communicate with. In trust-on-first-use (TOFU) use cases (see Appendix D.5), the Initiator should verify that the Responder's identity is not equal to its own. Any future EDHOC methods using, e.g., PSKs might need to mitigate this in other ways. However, an active attacker can gain information about the set of identities an Initiator is willing to communicate with. If the Initiator is willing to communicate with all identities except its own, an attacker can determine that a guessed Initiator identity is correct. To not leak any long-term identifiers, using a freshly generated authentication key as an identity in each initial TOFU session is RECOMMENDED.
完了したEDHOCセッションが別のアイデンティティがアクティブであることを意味する性質は、イニシエーターが通信を許可されているレスポンダーのアイデンティティのセットに自身のアイデンティティを持っていない限り維持されます。信頼性のある初回使用（TOFU）の使用例（付録D.5を参照）では、イニシエーターはレスポンダーのアイデンティティが自身と等しくないことを確認すべきです。例えばPSKを使用する将来のEDHOCメソッドは、他の方法でこれを緩和する必要があるかもしれません。ただし、アクティブな攻撃者は、イニシエーターが通信を行う意思のあるアイデンティティのセットに関する情報を入手することができます。イニシエーターが自身以外のすべてのアイデンティティと通信する意思がある場合、攻撃者は推測されたイニシエーターのアイデンティティが正しいことを特定できます。長期識別子を漏洩させないために、初期のTOFUセッションごとに新しく生成された認証キーをアイデンティティとして使用することが推奨されます。
NIST SP 800-56A [SP-800-56A] forbids deriving secret and non-secret randomness from the same Key Derivation Function (KDF) instance, but this decision has been criticized by Krawczyk in [HKDFpaper] and doing so is common practice. In addition to IVs, other examples are the challenge in Extensible Authentication Protocol Tunneled Transport Layer Security (EAP-TTLS), the RAND in 3GPP Authentication and Key Agreement (AKA), and the Session-Id in EAP-TLS 1.3. Note that part of KEYSTREAM_2 is also non-secret randomness, as it is known or predictable to an attacker. The more recent NIST SP 800-108 [SP-800-108] aligns with [HKDFpaper] and states that, for a secure KDF, the revelation of one portion of the derived keying material must not degrade the security of any other portion of that keying material.
NIST SP 800-56A [SP-800-56A] は、同じ鍵導出関数（KDF）インスタンスから秘密および非秘密のランダム性を導出することを禁止していますが、この決定は[Krawczyk]によって批判されており、実際には一般的な慣行となっています。IV以外の例としては、Extensible Authentication Protocol Tunneled Transport Layer Security（EAP-TTLS）のチャレンジ、3GPP Authentication and Key Agreement（AKA）のRAND、およびEAP-TLS 1.3のSession-Idがあります。KEYSTREAM_2の一部も非秘密のランダム性であり、攻撃者には既知または予測可能です。より新しいNIST SP 800-108 [SP-800-108] は[HKDFpaper]と一致し、安全なKDFの場合、導出された鍵素材の一部が漏洩しても、その鍵素材の他の部分のセキュリティが低下してはならないと述べています。
When using a private cipher suite or registering new cipher suites, the choice of the key length used in the different algorithms needs to be harmonized so that a sufficient security level is maintained for authentication credentials, the EDHOC session, and the protection of application data. The Initiator and Responder should enforce a minimum security level.
プライベートな暗号スイートを使用する場合や新しい暗号スイートを登録する場合、異なるアルゴリズムで使用される鍵の長さの選択は調和させる必要があります。これにより、認証資格情報、EDHOCセッション、およびアプリケーションデータの保護に十分なセキュリティレベルが維持されます。イニシエーターとレスポンダーは最低セキュリティレベルを強制する必要があります。
The output size of the EDHOC hash algorithm MUST be at least 256 bits. In particular, the hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to 64 bits) SHALL NOT be supported for use in EDHOC except for certificate identification with x5t and c5t. For security considerations of SHA-1, see [RFC6194]. As EDHOC integrity protects all the authentication credentials, the choice of hash algorithm in x5t and c5t does not affect security and using the same hash algorithm as in the cipher suite, but with as much truncation as possible, is RECOMMENDED. That is, when the EDHOC hash algorithm is SHA-256, using SHA-256/64 in x5t and c5t is RECOMMENDED. The EDHOC MAC length MUST be at least 8 bytes and the tag length of the EDHOC AEAD algorithm MUST be at least 64 bits. Note that secp256k1 is only defined for use with ECDSA and not for ECDH. Note that some COSE algorithms are marked as not recommended in the COSE IANA registry.
EDHOCハッシュアルゴリズムの出力サイズは少なくとも256ビットでなければなりません。特に、ハッシュアルゴリズムSHA-1およびSHA-256/64（64ビットに切り捨てられたSHA-256）は、x5tおよびc5tを使用した証明書識別を除いて、EDHOCでの使用はサポートされません。SHA-1のセキュリティに関する考慮事項については、[RFC6194]を参照してください。EDHOCの整合性はすべての認証資格情報を保護するため、x5tおよびc5tでのハッシュアルゴリズムの選択はセキュリティに影響を与えず、暗号スイートと同じハッシュアルゴリズムを使用することが推奨されますが、できるだけ切り捨てを多くしてください。つまり、EDHOCハッシュアルゴリズムがSHA-256の場合、x5tおよびc5tでSHA-256/64を使用することが推奨されます。EDHOC MAC長は少なくとも8バイトでなければならず、EDHOC AEADアルゴリズムのタグ長は少なくとも64ビットでなければなりません。secp256k1はECDSAでの使用のみが定義されており、ECDHでは使用されていません。COSEアルゴリズムのうち、COSE IANAレジストリで推奨されていないものがいくつかあることに注意してください。
As of the publication of this specification, it is unclear when or even if a quantum computer of sufficient size and power to exploit public key cryptography will exist. Deployments that need to consider risks decades into the future should transition to Post-Quantum Cryptography (PQC) in the not-too-distant future. Many other systems should take a slower wait-and-see approach where PQC is phased in when the quantum threat is more imminent. Current PQC algorithms have limitations compared to Elliptic Curve Cryptography (ECC), and the data sizes would be problematic in many constrained IoT systems.
この仕様書が公開された時点では、十分なサイズとパワーを持つ量子コンピュータがいつ登場するか、あるいは登場するかどうかは不明です。将来数十年にわたるリスクを考慮する必要がある展開は、近い将来にポスト量子暗号（PQC）に移行すべきです。他の多くのシステムは、量子脅威がより差し迫っているときにPQCが段階的に導入されるような、より慎重な待ち構えるアプローチを取るべきです。現在のPQCアルゴリズムは、楕円曲線暗号（ECC）と比較して制約の多いIoTシステムにおいてデータサイズが問題となる制限があります。
Symmetric algorithms used in EDHOC, such as SHA-256 and AES-CCM-16-64-128, are practically secure against even large quantum computers. Two of NIST's security levels for quantum-resistant public key cryptography are based on AES-128 and SHA-256. A quantum computer will likely be expensive and slow due to heavy error correction. Grover's algorithm, which is proven to be optimal, cannot effectively be parallelized. It will provide little or no advantage in attacking AES, and AES-128 will remain secure for decades to come [NISTPQC].
EDHOCで使用される対称アルゴリズム、例えばSHA-256やAES-CCM-16-64-128などは、大規模な量子コンピュータに対して実質的に安全です。NISTの量子耐性公開鍵暗号のセキュリティレベルのうち2つは、AES-128とSHA-256に基づいています。量子コンピュータは、重い誤り訂正により高価で遅くなる可能性があります。最適であることが証明されているGroverのアルゴリズムは、効果的に並列化することができません。AESを攻撃する際にほとんどまたは全く利点を提供せず、AES-128は今後数十年間安全であるでしょう。
EDHOC supports all signature algorithms defined by COSE, including PQC signature algorithms such as HSS-LMS. EDHOC is currently only specified for use with key exchange algorithms of type ECDH curves, but any Key Encapsulation Method (KEM), including PQC KEMs, can be used in method 0. While the key exchange in method 0 is specified with the terms of the Diffie-Hellman protocol, the key exchange adheres to a KEM interface: G_X is then the public key of the Initiator, G_Y is the encapsulation, and G_XY is the shared secret. Use of PQC KEMs to replace static DH authentication would likely require a specification updating EDHOC with new methods.
EDHOCは、HSS-LMSなどのPQC署名アルゴリズムを含むCOSEで定義されたすべての署名アルゴリズムをサポートしています。EDHOCは現在、ECDH曲線タイプの鍵交換アルゴリズムにのみ指定されていますが、PQC KEMを含む任意の鍵カプセル化メソッド（KEM）をメソッド0で使用することができます。メソッド0の鍵交換はDiffie-Hellmanプロトコルの用語で指定されていますが、鍵交換はKEMインターフェースに従います：G_Xはイニシエーターの公開鍵であり、G_Yはカプセル化であり、G_XYは共有秘密です。静的DH認証を置き換えるためにPQC KEMを使用する場合、おそらく新しいメソッドでEDHOCを更新する仕様が必要になるでしょう。
The Initiator and Responder must make sure that unprotected data and metadata do not reveal any sensitive information. This also applies for encrypted data sent to an unauthenticated party. In particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error messages. Using the same EAD_1 in several EDHOC sessions allows passive eavesdroppers to correlate the different sessions. Note that even if ead_value is encrypted outside of EDHOC, the ead_labels in EAD_1 are revealed to passive attackers and the ead_labels in EAD_2 are revealed to active attackers. Another consideration is that the list of supported cipher suites may potentially be used to identify the application. The Initiator and Responder must also make sure that unauthenticated data does not trigger any harmful actions. In particular, this applies to EAD_1 and error messages.
イニシエーターとレスポンダーは、未保護のデータやメタデータが機密情報を漏洩しないようにする必要があります。これは、認証されていない相手に送信される暗号化されたデータにも適用されます。特に、EAD_1、ID_CRED_R、EAD_2、およびエラーメッセージに適用されます。複数のEDHOCセッションで同じEAD_1を使用すると、受動的な盗聴者が異なるセッションを関連付けることができます。EAD_1のead_valueがEDHOCの外部で暗号化されていても、EAD_1のead_labelsは受動的な攻撃者に、EAD_2のead_labelsは能動的な攻撃者に露呈されます。サポートされている暗号スイートのリストは、アプリケーションを特定するために潜在的に使用される可能性があることも考慮すべきです。イニシエーターとレスポンダーは、未認証のデータが有害なアクションを引き起こさないようにも注意する必要があります。特に、これはEAD_1とエラーメッセージに適用されます。
An attacker observing network traffic may use connection identifiers sent in clear in EDHOC or the subsequent application protocol to correlate packets sent on different paths or at different times. The attacker may use this information for traffic flow analysis or to track an endpoint. Application protocols using connection identifiers from EDHOC SHOULD provide mechanisms to update the connection identifiers and MAY provide mechanisms to issue several simultaneously active connection identifiers. See [RFC9000] for a non-constrained example of such mechanisms. Connection identifiers can, e.g., be chosen randomly among the set of unused 1-byte connection identifiers. Connection identity privacy mechanisms are only useful when there are not fixed identifiers, such as IP address or MAC address in the lower layers.
ネットワークトラフィックを監視する攻撃者は、EDHOCでクリアに送信される接続識別子、またはその後のアプリケーションプロトコルで送信される接続識別子を使用して、異なるパスや異なる時点で送信されたパケットを関連付けることができます。攻撃者はこの情報をトラフィックフローの分析やエンドポイントの追跡に使用する可能性があります。EDHOCから接続識別子を使用するアプリケーションプロトコルは、接続識別子を更新するメカニズムを提供すべきであり、同時に複数のアクティブな接続識別子を発行するメカニズムを提供することができます。このようなメカニズムの非制約例については、[RFC9000]を参照してください。接続識別子は、例えば、未使用の1バイト接続識別子のセットからランダムに選択されることがあります。接続識別子のプライバシーメカニズムは、下位層にIPアドレスやMACアドレスなどの固定識別子がない場合にのみ有用です。
Since the publication of [RFC3552], there has been an increased awareness of the need to protect against endpoints that are compromised or malicious or whose interests simply do not align with the interests of users [THREAT-MODEL-GUIDANCE]. [RFC7624] describes an updated threat model for Internet confidentiality; see Section 9.1. [THREAT-MODEL-GUIDANCE] further expands the threat model. Implementations and users should take these threat models into account and consider actions to reduce the risk of tracking by other endpoints. In particular, even data sent protected to the other endpoint, such as ID_CRED fields and EAD fields, can be used for tracking; see Section 2.7 of [THREAT-MODEL-GUIDANCE].
[RFC3552]の公開以来、エンドポイントが危険にさらされたり悪意を持っていたり、または単にユーザーの利益と一致しないエンドポイントに対して保護する必要性についての認識が高まっています。[THREAT-MODEL-GUIDANCE]を参照してください。[RFC7624]はインターネットの機密性に対する更新された脅威モデルを説明しています。セクション9.1を参照してください。[THREAT-MODEL-GUIDANCE]は脅威モデルをさらに拡大しています。実装およびユーザーはこれらの脅威モデルを考慮に入れ、他のエンドポイントによるトラッキングのリスクを軽減するための行動を検討すべきです。特に、ID_CREDフィールドやEADフィールドなど、他のエンドポイントに保護されたデータであっても、トラッキングに使用される可能性があります。[THREAT-MODEL-GUIDANCE]のセクション2.7を参照してください。
The fields ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 have variable length, and information regarding the length may leak to an attacker. A passive attacker may, e.g., be able to differentiate endpoints using identifiers of different length. To mitigate this information leakage, an implementation may ensure that the fields have a fixed length or use padding. An implementation may, e.g., only use fixed length identifiers like 'kid' of length 1. Alternatively, padding may be used (see Section 3.8.1) to hide the true length of, e.g., certificates by value in 'x5chain' or 'c5c'.
ID_CRED_I、ID_CRED_R、EAD_2、EAD_3、およびEAD_4のフィールドは可変長であり、その長さに関する情報が攻撃者に漏れる可能性があります。たとえば、受動的な攻撃者は、異なる長さの識別子を使用してエンドポイントを区別できるかもしれません。この情報漏洩を軽減するために、実装ではフィールドが固定長であることを確認するか、パディングを使用することができます。たとえば、実装では長さ1の 'kid' のような固定長の識別子のみを使用することができます。また、パディングを使用することもできます（セクション3.8.1を参照）。例えば、 'x5chain'または 'c5c'の値によって証明書の真の長さを隠すために。
EDHOC itself does not provide countermeasures against denial-of-service attacks. In particular, by sending a number of new or replayed message_1, an attacker may cause the Responder to allocate the state, perform cryptographic operations, and amplify messages. To mitigate such attacks, an implementation SHOULD make use of available lower layer mechanisms. For instance, when EDHOC is transferred as an exchange of CoAP messages, the CoAP server can use the Echo option defined in [RFC9175], which forces the CoAP client to demonstrate reachability at its apparent network address. To avoid an additional round trip, the Initiator can reduce the amplification factor by padding message_1, i.e., using EAD_1; see Section 3.8.1. Note that while the Echo option mitigates some resource exhaustion aspects of spoofing, it does not protect against a distributed denial-of-service attack made by real, potentially compromised, clients. Similarly, limiting amplification only reduces the impact, which still may be significant because of a large number of clients engaged in the attack.
EDHOC自体は、サービス拒否攻撃に対する対策を提供していません。特に、新しいまたは再生されたメッセージ_1を送信することで、攻撃者はResponderに状態を割り当て、暗号操作を実行し、メッセージを増幅させる可能性があります。このような攻撃を緩和するために、実装は利用可能な下位層メカニズムを使用するべきです。たとえば、EDHOCがCoAPメッセージの交換として転送される場合、CoAPサーバは[RFC9175]で定義されたEchoオプションを使用できます。これにより、CoAPクライアントはその見かけのネットワークアドレスで到達可能であることを証明する必要があります。追加のラウンドトリップを避けるために、イニシエータはメッセージ_1をパディングして増幅係数を減らすことができます。つまり、EAD_1を使用します。Echoオプションはスプーフィングのリソース枯渇の一部を緩和しますが、実際には、潜在的に危険なクライアントによる分散型サービス拒否攻撃からは保護しません。同様に、増幅を制限するだけでも影響は軽減されますが、攻撃に参加するクライアントの数が多いため、依然として重要な影響がある可能性があります。
An attacker can also send a faked message_2, message_3, message_4, or error in an attempt to trick the receiving party to send an error message and abort the EDHOC session. EDHOC implementations MAY evaluate if a received message is likely to have been forged by an attacker and ignore it without sending an error message or aborting the EDHOC session.
攻撃者は、受信側をだましてエラーメッセージを送らせ、EDHOCセッションを中止させる試みとして、偽のメッセージ_2、メッセージ_3、メッセージ_4、またはエラーを送信することもできます。EDHOCの実装は、受信したメッセージが攻撃者によって偽造された可能性があるかどうかを評価し、エラーメッセージを送信せずに無視したり、EDHOCセッションを中止したりすることがあります。
The availability of a secure random number generator is essential for the security of EDHOC. If no true random number generator is available, a random seed MUST be provided from an external source and used with a cryptographically secure pseudorandom number generator. As each pseudorandom number must only be used once, an implementation needs to get a unique input to the pseudorandom number generator after reboot or continuously store state in nonvolatile memory. Appendix B.1.1 of [RFC8613] describes issues and solution approaches for writing to nonvolatile memory. Intentionally or unintentionally weak or predictable pseudorandom number generators can be abused or exploited for malicious purposes. [RFC8937] describes a way for security protocol implementations to augment their (pseudo)random number generators using a long-term private key and a deterministic signature function. This improves randomness from broken or otherwise subverted random number generators. The same idea can be used with other secrets and functions, such as a Diffie-Hellman function or a symmetric secret, and a PRF like HMAC or KMAC. It is RECOMMENDED to not trust a single source of randomness and to not put unaugmented random numbers on the wire.
セキュアな乱数生成器の利用可能性は、EDHOCのセキュリティにとって不可欠です。真の乱数生成器が利用できない場合、外部ソースからランダムシードを提供し、暗号的に安全な疑似乱数生成器と共に使用する必要があります。各疑似乱数は一度だけ使用される必要があるため、実装は再起動後に疑似乱数生成器に一意の入力を取得するか、非揮発性メモリに状態を継続的に保存する必要があります。[RFC8613]の付録B.1.1では、非揮発性メモリへの書き込みに関する問題と解決策が説明されています。意図的または意図しない弱いまたは予測可能な疑似乱数生成器は、悪意のある目的で悪用される可能性があります。[RFC8937]では、セキュリティプロトコルの実装が、長期の秘密鍵と決定論的署名関数を使用して（疑似）乱数生成器を拡張する方法が説明されています。これにより、壊れたまたは他の方法で破壊された乱数生成器からのランダム性が向上します。同じ考え方は、Diffie-Hellman関数や対称秘密など、他の秘密や関数にも適用できます。HMACやKMACのようなPRF。単一の乱数源を信頼せず、未加工の乱数をワイヤーに置かないことが推奨されています。
For many constrained IoT devices, it is problematic to support several crypto primitives. Existing devices can be expected to support either ECDSA or Edwards-curve Digital Signature Algorithm (EdDSA). If ECDSA is supported, "deterministic ECDSA", as specified in [RFC6979], MAY be used. Pure deterministic elliptic-curve signatures, such as deterministic ECDSA and EdDSA, have gained popularity over randomized ECDSA as their security does not depend on a source of high-quality randomness. Recent research has however found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their determinism. For example, see Section 1 of [HEDGED-ECC-SIGS] for a list of attack papers. As suggested in Section 2.1.1 of [RFC9053], this can be addressed by combining randomness and determinism.
多くの制約のあるIoTデバイスにとって、複数の暗号プリミティブをサポートすることは問題です。既存のデバイスは、ECDSAまたはEdwards-curve Digital Signature Algorithm（EdDSA）のいずれかをサポートすることが期待されます。ECDSAがサポートされている場合、[RFC6979]で指定されている「deterministic ECDSA」を使用することができます。決定論的楕円曲線署名、例えばdeterministic ECDSAやEdDSAのような純粋な決定論的楕円曲線署名は、セキュリティが高品質のランダム性源に依存しないため、ランダム化されたECDSAよりも人気があります。しかし、最近の研究では、これらの署名アルゴリズムの実装が決定論性に起因して特定のサイドチャネル攻撃やフォルトインジェクション攻撃に脆弱である可能性があることがわかりました。例えば、攻撃論文のリストについては[HEDGED-ECC-SIGS]のセクション1を参照してください。[RFC9053]のセクション2.1.1で提案されているように、これはランダム性と決定論を組み合わせることで対処できます。
Appendix D of [CURVE-REPR] describes how Montgomery curves, such as X25519 and X448, and (twisted) Edwards curves, such as Ed25519 and Ed448, can be mapped to and from short-Weierstrass form for implementations on platforms that accelerate elliptic curve group operations in short-Weierstrass form.
[CURVE-REPR]の付録Dでは、X25519やX448などのモンゴメリ曲線、およびEd25519やEd448などの（ねじれた）エドワーズ曲線が、楕円曲線群操作を加速するプラットフォーム上での実装のために、短いワイエルシュトラス形式にマッピングおよび逆マッピングされる方法が説明されています。
All private keys, symmetric keys, and IVs MUST be secret. Only the Responder SHALL have access to the Responder's private authentication key, and only the Initiator SHALL have access to the Initiator's private authentication key. Implementations should provide countermeasures to side-channel attacks, such as timing attacks. Intermediate computed values, such as ephemeral ECDH keys and ECDH shared secrets, MUST be deleted after key derivation is completed.
すべての秘密鍵、対称鍵、およびIVは秘密でなければなりません。応答者の秘密認証鍵にアクセスできるのは応答者のみであり、イニシエーターの秘密認証鍵にアクセスできるのはイニシエーターのみです。実装は、タイミング攻撃などのサイドチャネル攻撃に対する対策を提供すべきです。エフェメラルECDH鍵やECDH共有秘密などの中間計算値は、鍵導出が完了した後に削除されなければなりません。
The Initiator and Responder are responsible for verifying the integrity and validity of certificates. Verification of validity may require the use of a Real-Time Clock (RTC). The selection of trusted certification authorities (CAs) should be done very carefully and certificate revocation should be supported. The choice of revocation mechanism is left to the application. For example, in case of X.509 certificates, Certificate Revocation Lists [RFC5280] or the Online Certificate Status Protocol (OCSP) [RFC6960] may be used.
イニシエーターとレスポンダーは、証明書の整合性と有効性を検証する責任があります。有効性の検証にはリアルタイムクロック（RTC）の使用が必要になる場合があります。信頼できる認証機関（CAs）の選択は非常に注意深く行われるべきであり、証明書の取り消しもサポートされるべきです。取り消しメカニズムの選択はアプリケーションに任されています。たとえば、X.509証明書の場合、証明書取り消しリスト[RFC5280]またはオンライン証明書ステータスプロトコル（OCSP）[RFC6960]が使用されることがあります。
Similar considerations as for certificates are needed for CWT/CCS. The endpoints are responsible for verifying the integrity and validity of CWT/CCS and to handle revocation. The application needs to determine what trust anchors are relevant and have a well-defined trust-establishment process. A self-signed certificate / CWT or CCS appearing in the protocol cannot be a trigger to modify the set of trust anchors. One common way for a new trust anchor to be added to (or removed from) a device is by means firmware upgrade. See [RFC9360] for a longer discussion on trust and validation in constrained devices.
証明書に関する考慮事項と同様に、CWT/CCSについても同様の考慮が必要です。エンドポイントは、CWT/CCSの整合性と有効性を検証し、失効を処理する責任があります。アプリケーションは、どの信頼アンカーが関連するかを決定し、明確に定義された信頼確立プロセスを持つ必要があります。プロトコルに現れる自己署名証明書/CWTまたはCCSは、信頼アンカーのセットを変更するきっかけにはなりません。新しい信頼アンカーがデバイスに追加される（または削除される）一般的な方法の1つは、ファームウェアのアップグレードによるものです。信頼と検証に関する詳細な議論については、[RFC9360]を参照してください。
Just like for certificates, the contents of the COSE header parameters 'kcwt' and 'kccs' defined in Section 10.6 must be processed as untrusted inputs. Endpoints that intend to rely on the assertions made by a CWT/CCS obtained from any of these methods need to validate the contents. For 'kccs', which enables transport of raw public keys, the data structure used does not include any protection or verification data. 'kccs' may be used for unauthenticated operations, e.g., trust on first use, with the limitations and caveats entailed; see Appendix D.5.
証明書と同様に、セクション10.6で定義されたCOSEヘッダーパラメータ 'kcwt' と 'kccs' の内容は信頼できない入力として処理する必要があります。これらの方法から取得したCWT/CCSの主張を信頼するエンドポイントは、その内容を検証する必要があります。 'kccs' については、生の公開鍵の転送を可能にするため、使用されるデータ構造には保護や検証データが含まれていません。 'kccs' は認証されていない操作に使用される可能性があり、たとえば最初の使用時の信頼などが制約と注意事項として含まれます。Appendix D.5を参照してください。
The Initiator and Responder are allowed to select connection identifiers C_I and C_R, respectively, for the other party to use in the ongoing EDHOC session as well as in a subsequent application protocol (e.g., OSCORE [RFC8613]). The choice of the connection identifier is not security critical in EDHOC but intended to simplify the retrieval of the right security context in combination with using short identifiers. If the wrong connection identifier of the other party is used in a protocol message, it will result in the receiving party not being able to retrieve a security context (which will abort the EDHOC session) or retrieve the wrong security context (which also aborts the EDHOC session as the message cannot be verified).
イニシエーターとレスポンダーは、相手が現在のEDHOCセッションおよびその後のアプリケーションプロトコル（例：OSCORE [RFC8613]）で使用するために、接続識別子C_IおよびC_Rを選択することが許可されています。接続識別子の選択は、EDHOCにおいてセキュリティ上重要ではありませんが、短い識別子を使用することで正しいセキュリティコンテキストの取得を簡素化することを意図しています。プロトコルメッセージで相手の間違った接続識別子が使用されると、受信側はセキュリティコンテキストを取得できなくなり（これによりEDHOCセッションが中止される）、または誤ったセキュリティコンテキストを取得します（これもメッセージが検証できないためEDHOCセッションが中止されます）。
If two nodes unintentionally initiate two simultaneous EDHOC sessions with each other, even if they only want to complete a single EDHOC session, they MAY abort the EDHOC session with the lexicographically smallest G_X. Note that in cases where several EDHOC sessions with different parameter sets (method, COSE headers, etc.) are used, an attacker can affect which parameter set will be used by blocking some of the parameter sets.
もし2つのノードが互いに意図せずに2つの同時のEDHOCセッションを開始した場合、1つのEDHOCセッションのみを完了したい場合でも、それらは辞書順で最も小さいG_Xを持つEDHOCセッションを中止することができます。異なるパラメータセット（メソッド、COSEヘッダなど）を使用した複数のEDHOCセッションが使用される場合、攻撃者は一部のパラメータセットをブロックすることで、どのパラメータセットが使用されるかに影響を与えることができます。
If supported by the device, it is RECOMMENDED that at least the long-term private keys are stored in a Trusted Execution Environment (TEE) (for example, see [RFC9397]) and that sensitive operations using these keys are performed inside the TEE. To achieve even higher security, it is RECOMMENDED that additional operations such as ephemeral key generation, all computations of shared secrets, and storage of the PRK keys can be done inside the TEE. The use of a TEE aims at preventing code within that environment to be tampered with and preventing data used by such code to be read or tampered with by code outside that environment.
デバイスがサポートしている場合、少なくとも長期の秘密鍵は信頼された実行環境（TEE）に保存されることが推奨されます（例：[RFC9397]を参照）。これらの鍵を使用する機密操作は、TEE内で実行されることが推奨されます。さらに高いセキュリティを実現するために、TEE内での追加の操作（例：一時鍵生成、共有シークレットの計算、PRK鍵の保存）が行われることが推奨されます。TEEの使用は、その環境内のコードが改ざんされることを防ぎ、そのコードによって使用されるデータがその環境外のコードによって読まれたり改ざんされたりすることを防ぐことを目的としています。
Note that HKDF-Expand has a relatively small maximum output length of 255 ⋅ hash_length, where hash_length is the output size in bytes of the EDHOC hash algorithm of the selected cipher suite. This means that when SHA-256 is used as a hash algorithm, PLAINTEXT_2 cannot be longer than 8160 bytes. This is probably not a limitation for most intended applications, but to be able to support, for example, long certificate chains or large external authorization data, there is a backwards compatible method specified in Appendix G.
HKDF-Expandには、選択した暗号スイートのEDHOCハッシュアルゴリズムの出力サイズ（バイト単位）に応じて、比較的小さな最大出力長があることに注意してください。これは、SHA-256がハッシュアルゴリズムとして使用される場合、PLAINTEXT_2が8160バイトを超えることはできないことを意味します。これは、ほとんどの想定されるアプリケーションにとって制限になる可能性は低いかもしれませんが、例えば長い証明書チェーンや大きな外部認可データをサポートするために、Appendix Gで指定された後方互換性のある方法があります。
The sequence of transcript hashes in EDHOC (TH_2, TH_3, and TH_4) does not make use of a so-called running hash. This is a design choice, as running hashes are often not supported on constrained platforms.
EDHOC（TH_2、TH_3、およびTH_4のトランスクリプトハッシュのシーケンス）は、いわゆるランニングハッシュを使用していません。これは、ランニングハッシュが制約のあるプラットフォームでサポートされていないことが多いため、設計上の選択です。
When parsing a received EDHOC message, implementations MUST abort the EDHOC session if the message does not comply with the CDDL for that message. Implementations are not required to support non-deterministic encodings and MAY abort the EDHOC session if the received EDHOC message is not encoded using deterministic CBOR. Implementations MUST abort the EDHOC session if validation of a received public key fails or if any cryptographic field has the wrong length. It is RECOMMENDED to abort the EDHOC session if the received EDHOC message is not encoded using deterministic CBOR.
EDHOC メッセージを受信した際に、実装はそのメッセージに対応する CDDL に準拠していない場合、EDHOC セッションを中止する必要があります。実装は非決定的エンコーディングをサポートする必要はなく、受信した EDHOC メッセージが決定論的 CBOR を使用してエンコードされていない場合、EDHOC セッションを中止することができます。受信した公開鍵の検証に失敗した場合や、暗号フィールドの長さが間違っている場合、実装は EDHOC セッションを中止する必要があります。受信した EDHOC メッセージが決定論的 CBOR を使用してエンコードされていない場合、EDHOC セッションを中止することが推奨されます。
This section gives IANA considerations and, unless otherwise noted, conforms with [RFC8126].
このセクションは IANA の考慮事項を示しており、特に指定されていない限り、[RFC8126] に準拠しています。
IANA has created a new registry under the new registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
IANAは、新しいレジストリグループ「Ephemeral Diffie-Hellman Over COSE (EDHOC)」の下に新しいレジストリを作成しました。
Registry Name:
登録名:
EDHOC Exporter Labels
EDHOCエクスポーターラベル
Reference:
参照:
RFC 9528
RFC 9528
+=============+==============================+===========+
| Label | Description | Reference |
+=============+==============================+===========+
| 0 | Derived OSCORE Master Secret | RFC 9528 |
+-------------+------------------------------+-----------+
| 1 | Derived OSCORE Master Salt | RFC 9528 |
+-------------+------------------------------+-----------+
| 2-22 | Unassigned | |
+-------------+------------------------------+-----------+
| 23 | Reserved | RFC 9528 |
+-------------+------------------------------+-----------+
| 24-32767 | Unassigned | |
+-------------+------------------------------+-----------+
| 32768-65535 | Reserved for Private Use | |
+-------------+------------------------------+-----------+
Table 4: EDHOC Exporter Labels
表4：EDHOCエクスポーターラベル
This registry also has a "Change Controller" field. For registrations made by IETF documents, the IETF is listed.
この登録には「変更コントローラー」フィールドもあります。IETF文書による登録の場合、IETFがリストされています。
+=============+=========================+
| Range | Registration Procedures |
+=============+=========================+
| 0-23 | Standards Action |
+-------------+-------------------------+
| 24-32767 | Expert Review |
+-------------+-------------------------+
| 32768-65535 | Private Use |
+-------------+-------------------------+
Table 5: Registration Procedures for EDHOC Exporter Labels
表5：EDHOC輸出業者ラベルの登録手続き
IANA has created a new registry under the new registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
IANAは、新しいレジストリグループ「Ephemeral Diffie-Hellman Over COSE (EDHOC)」の下に新しいレジストリを作成しました。
Registry Name:
登録名:
EDHOC Cipher Suites
EDHOC 暗号スイート
Reference:
参照:
RFC 9528
RFC 9528
The columns of the registry are Value, Array, Description, and Reference, where Value is an integer and the other columns are text strings. The initial contents of the registry are:
登録の列は、値、配列、説明、参照であり、値は整数で、他の列はテキスト文字列です。登録の初期内容は次のとおりです。
+=======+================+=============================+===========+
| Value | Array | Description | Reference |
+=======+================+=============================+===========+
| -24 | N/A | Private Use | RFC 9528 |
+-------+----------------+-----------------------------+-----------+
| -23 | N/A | Private Use | RFC 9528 |
+-------+----------------+-----------------------------+-----------+
| -22 | N/A | Private Use | RFC 9528 |
+-------+----------------+-----------------------------+-----------+
| -21 | N/A | Private Use | RFC 9528 |
+-------+----------------+-----------------------------+-----------+
| 0 | 10, -16, 8, 4, | AES-CCM-16-64-128, SHA-256, | RFC 9528 |
| | -8, 10, -16 | 8, X25519, EdDSA, | |
| | | AES-CCM-16-64-128, SHA-256 | |
+-------+----------------+-----------------------------+-----------+
| 1 | 30, -16, 16, | AES-CCM-16-128-128, | RFC 9528 |
| | 4, -8, 10, -16 | SHA-256, 16, X25519, EdDSA, | |
| | | AES-CCM-16-64-128, SHA-256 | |
+-------+----------------+-----------------------------+-----------+
| 2 | 10, -16, 8, 1, | AES-CCM-16-64-128, SHA-256, | RFC 9528 |
| | -7, 10, -16 | 8, P-256, ES256, | |
| | | AES-CCM-16-64-128, SHA-256 | |
+-------+----------------+-----------------------------+-----------+
| 3 | 30, -16, 16, | AES-CCM-16-128-128, | RFC 9528 |
| | 1, -7, 10, -16 | SHA-256, 16, P-256, ES256, | |
| | | AES-CCM-16-64-128, SHA-256 | |
+-------+----------------+-----------------------------+-----------+
| 4 | 24, -16, 16, | ChaCha20/Poly1305, SHA-256, | RFC 9528 |
| | 4, -8, 24, -16 | 16, X25519, EdDSA, | |
| | | ChaCha20/Poly1305, SHA-256 | |
+-------+----------------+-----------------------------+-----------+
| 5 | 24, -16, 16, | ChaCha20/Poly1305, SHA-256, | RFC 9528 |
| | 1, -7, 24, -16 | 16, P-256, ES256, | |
| | | ChaCha20/Poly1305, SHA-256 | |
+-------+----------------+-----------------------------+-----------+
| 6 | 1, -16, 16, 4, | A128GCM, SHA-256, 16, | RFC 9528 |
| | -7, 1, -16 | X25519, ES256, A128GCM, | |
| | | SHA-256 | |
+-------+----------------+-----------------------------+-----------+
| 23 | | Reserved | RFC 9528 |
+-------+----------------+-----------------------------+-----------+
| 24 | 3, -43, 16, 2, | A256GCM, SHA-384, 16, | RFC 9528 |
| | -35, 3, -43 | P-384, ES384, A256GCM, | |
| | | SHA-384 | |
+-------+----------------+-----------------------------+-----------+
| 25 | 24, -45, 16, | ChaCha20/Poly1305, | RFC 9528 |
| | 5, -8, 24, -45 | SHAKE256, 16, X448, EdDSA, | |
| | | ChaCha20/Poly1305, SHAKE256 | |
+-------+----------------+-----------------------------+-----------+
Table 6: EDHOC Cipher Suites
表6：EDHOC暗号スイート
+===============+=====================================+
| Range | Registration Procedures |
+===============+=====================================+
| -65536 to -25 | Specification Required |
+---------------+-------------------------------------+
| -24 to -21 | Private Use |
+---------------+-------------------------------------+
| -20 to 23 | Standards Action with Expert Review |
+---------------+-------------------------------------+
| 24 to 65535 | Specification Required |
+---------------+-------------------------------------+
Table 7: Registration Procedures for EDHOC Cipher Suites
表7：EDHOC暗号スイートの登録手続き
IANA has created a new registry under the new registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
IANAは、新しいレジストリグループ「Ephemeral Diffie-Hellman Over COSE (EDHOC)」の下に新しいレジストリを作成しました。
Registry Name:
登録名:
EDHOC Method Types
EDHOCメソッドの種類
Reference:
参照:
RFC 9528
RFC 9528
The columns of the registry are Value, Initiator Authentication Key, Responder Authentication Key, and Reference, where Value is an integer and the key columns are text strings describing the authentication keys.
登録の列は、値、イニシエータ認証キー、レスポンダ認証キー、およびリファレンスです。ここで、値は整数で、キーの列は認証キーを説明するテキスト文字列です。
The initial contents of the registry are shown in Table 2. Method 23 is Reserved.
登録簿の最初の内容は表2に示されています。Method 23は予約されています。
+===============+=====================================+
| Range | Registration Procedures |
+===============+=====================================+
| -65536 to -25 | Specification Required |
+---------------+-------------------------------------+
| -24 to 23 | Standards Action with Expert Review |
+---------------+-------------------------------------+
| 24 to 65535 | Specification Required |
+---------------+-------------------------------------+
Table 8: Registration Procedures for EDHOC Method Types
表8：EDHOCメソッドタイプの登録手順
IANA has created a new registry under the new registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
IANAは、新しいレジストリグループ「Ephemeral Diffie-Hellman Over COSE (EDHOC)」の下に新しいレジストリを作成しました。
Registry Name:
登録名:
EDHOC Error Codes
EDHOC エラーコード
Reference:
参照:
RFC 9528
RFC 9528
The columns of the registry are ERR_CODE, ERR_INFO Type, Description, Change Controller, and Reference, where ERR_CODE is an integer, ERR_INFO is a CDDL defined type, and Description is a text string. The initial contents of the registry are shown in Table 3. Error code 23 is Reserved. This registry also has a "Change Controller" field. For registrations made by IETF documents, the IETF is listed.
登録の列は ERR_CODE、ERR_INFO タイプ、説明、変更コントローラ、および参照です。ERR_CODE は整数で、ERR_INFO は CDDL で定義されたタイプであり、説明はテキスト文字列です。登録の初期内容は表3に示されています。エラーコード23は予約されています。この登録には「変更コントローラ」フィールドもあります。IETF 文書による登録の場合、IETF がリストされています。
+===============+=========================+
| Range | Registration Procedures |
+===============+=========================+
| -65536 to -25 | Expert Review |
+---------------+-------------------------+
| -24 to 23 | Standards Action |
+---------------+-------------------------+
| 24 to 65535 | Expert Review |
+---------------+-------------------------+
Table 9: Registration Procedures for EDHOC Error Codes
テーブル9：EDHOCエラーコードの登録手順
IANA has created a new registry under the new registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
IANAは、新しいレジストリグループ「Ephemeral Diffie-Hellman Over COSE (EDHOC)」の下に新しいレジストリを作成しました。
Registry Name:
登録名:
EDHOC External Authorization Data
EDHOC外部認証データ
Reference:
参照:
RFC 9528
RFC 9528
The columns of the registry are Name, Label, Description, and Reference, where Label is a nonnegative integer and the other columns are text strings. The initial contents of the registry are shown in Table 10. EAD label 23 is Reserved.
登録の列は、名前、ラベル、説明、および参照です。ここで、ラベルは非負の整数であり、他の列はテキスト文字列です。登録の初期内容は、表10に示されています。EADラベル23は予約されています。
+=========+=======+====================+===============+
| Name | Label | Description | Reference |
+=========+=======+====================+===============+
| Padding | 0 | Randomly generated | RFC 9528, |
| | | CBOR byte string | Section 3.8.1 |
+---------+-------+--------------------+---------------+
| | 23 | Reserved | RFC 9528 |
+---------+-------+--------------------+---------------+
Table 10: EDHOC EAD Labels
テーブル10：EDHOC EADラベル
+=============+=====================================+
| Range | Registration Procedures |
+=============+=====================================+
| 0 to 23 | Standards Action with Expert Review |
+-------------+-------------------------------------+
| 24 to 65535 | Specification Required |
+-------------+-------------------------------------+
Table 11: Registration Procedures for EDHOC EAD Labels
表11：EDHOC EADラベルの登録手続き
IANA has registered the following entries in the "COSE Header Parameters" registry under the registry group "CBOR Object Signing and Encryption (COSE)" (see Table 12). The value of the 'kcwt' header parameter is a COSE Web Token (CWT) [RFC8392], and the value of the 'kccs' header parameter is a CWT Claims Set (CCS); see Section 1.4. The CWT/CCS must contain a COSE_Key in a 'cnf' claim [RFC8747]. The Value Registry column for this item is empty and omitted from the table below.
IANAは、「COSEヘッダーパラメータ」レジストリの下に、「CBOR Object Signing and Encryption (COSE)」レジストリグループで次のエントリを登録しました（表12を参照）。 'kcwt'ヘッダーパラメータの値はCOSE Web Token（CWT）[RFC8392]であり、'kccs'ヘッダーパラメータの値はCWT Claims Set（CCS）です。CWT/CCSには、'cnf'クレーム内にCOSE_Keyが含まれている必要があります[RFC8747]。このアイテムの値レジストリ列は空であり、以下の表から省略されています。
+======+=======+===============+===============================+
| Name | Label | Value Type | Description |
+======+=======+===============+===============================+
| kcwt | 13 | COSE_Messages | A CBOR Web Token (CWT) |
| | | | containing a COSE_Key in a |
| | | | 'cnf' claim and possibly |
| | | | other claims. CWT is defined |
| | | | in RFC 8392. COSE_Messages |
| | | | is defined in RFC 9052. |
+------+-------+---------------+-------------------------------+
| kccs | 14 | map | A CWT Claims Set (CCS) |
| | | | containing a COSE_Key in a |
| | | | 'cnf' claim and possibly |
| | | | other claims. CCS is defined |
| | | | in RFC 8392. |
+------+-------+---------------+-------------------------------+
Table 12: COSE Header Parameter Labels
表12：COSEヘッダーパラメータラベル
IANA has added the well-known URI "edhoc" to the "Well-Known URIs" registry.
IANAは「Well-Known URIs」レジストリに「edhoc」というよく知られたURIを追加しました。
URI Suffix:
URIサフィックス:
edhoc
edhoc
Change Controller:
コントローラーを変更します。
IETF
IETF
Reference:
参照:
RFC 9528
RFC 9528
Related Information:
関連情報:
None
なし
IANA has added the media types "application/edhoc+cbor-seq" and "application/cid-edhoc+cbor-seq" to the "Media Types" registry.
IANAは「Media Types」レジストリに「application/edhoc+cbor-seq」と「application/cid-edhoc+cbor-seq」というメディアタイプを追加しました。
Type name:
タイプ名:
application
応用
Subtype name:
サブタイプ名:
edhoc+cbor-seq
edhoc+cbor-seq
Required parameters:
必須パラメータ:
N/A
N/A
Optional parameters:
オプションのパラメータ:
N/A
N/A
Encoding considerations:
エンコーディングに関する考慮事項:
binary
バイナリ
Security considerations:
セキュリティに関する考慮事項:
See Section 7 of RFC 9528.
RFC 9528のセクション7を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
N/A
Published specification:
公開された仕様書:
RFC 9528
RFC 9528
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
To be identified
特定される
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
N/A
Additional information:
追加情報:
Magic number(s):
魔法の数字:
N/A
N/A
File extension(s):
ファイルの拡張子:
N/A
N/A
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
N/A
Person & email address to contact for further information:
さらなる情報を得るための担当者とメールアドレス：
See "Authors' Addresses" section in RFC 9528.
RFC 9528の「Authors' Addresses」セクションを参照してください。
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用制限:
N/A
N/A
Author:
著者
See "Authors' Addresses" section.
「著者の住所」セクションをご覧ください。
Change Controller:
コントローラーの変更:
IETF
IETF
Type name:
タイプ名:
application
応用
Subtype name:
サブタイプ名:
cid-edhoc+cbor-seq
cid-edhoc+cbor-seq
Required parameters:
必須パラメータ:
N/A
N/A
Optional parameters:
オプションのパラメータ:
N/A
N/A
Encoding considerations:
エンコーディングに関する考慮事項:
binary
バイナリ
Security considerations:
セキュリティに関する考慮事項:
See Section 7 of RFC 9528.
RFC 9528のセクション7を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
N/A
Published specification:
公開された仕様書:
RFC 9528
RFC 9528
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
To be identified
特定される
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
N/A
Additional information:
追加情報:
Magic number(s):
魔法の数字:
N/A
N/A
File extension(s):
ファイルの拡張子:
N/A
N/A
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
N/A
Person & email address to contact for further information:
さらなる情報を得るための担当者とメールアドレス：
See "Authors' Addresses" section in RFC 9528.
RFC 9528の「Authors' Addresses」セクションを参照してください。
Intended usage:
意図された使用方法:
COMMON
一般的な
Restrictions on usage:
使用制限:
N/A
I'm sorry, but "N/A" is not a phrase that can be translated.
Author:
著者:
See "Authors' Addresses" section.
「著者の住所」セクションをご覧ください。
Change Controller:
コントローラーの変更:
IETF
IETF
IANA has added the media types "application/edhoc+cbor-seq" and "application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats" registry under the registry group "Constrained RESTful Environments (CoRE) Parameters".
IANAは、"CoAP Content-Formats"レジストリの"Constrained RESTful Environments (CoRE) Parameters"レジストリグループに、"application/edhoc+cbor-seq"および"application/cid-edhoc+cbor-seq"というメディアタイプを追加しました。
+================================+================+====+===========+
| Content Type | Content Coding | ID | Reference |
+================================+================+====+===========+
| application/edhoc+cbor-seq | - | 64 | RFC 9528 |
+--------------------------------+----------------+----+-----------+
| application/cid-edhoc+cbor-seq | - | 65 | RFC 9528 |
+--------------------------------+----------------+----+-----------+
Table 13: CoAP Content-Format IDs
テーブル13: CoAPコンテンツフォーマットID
IANA has added the resource type "core.edhoc" to the "Resource Type (rt=) Link Target Attribute Values" registry under the registry group "Constrained RESTful Environments (CoRE) Parameters".
IANAは、「Resource Type (rt=) Link Target Attribute Values」レジストリの「Constrained RESTful Environments (CoRE) Parameters」レジストリグループに、リソースタイプ「core.edhoc」を追加しました。
Value:
値：
core.edhoc
core.edhoc
Description:
英語のまま出力します。
EDHOC resource
EDHOC リソース
Reference:
参照:
RFC 9528
RFC 9528
The IANA registries established in this document are defined as "Expert Review", "Specification Required", or "Standards Action with Expert Review". This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude.
この文書で確立されたIANAレジストリは、「専門家による審査」、「仕様必須」、または「専門家による標準アクション」に定義されています。このセクションでは、専門家が何を探しているかについて一般的なガイドラインを示していますが、彼らは理由があって専門家として指定されているので、かなりの裁量を与えられるべきです。
Expert reviewers should take into consideration the following points:
専門家のレビュアーは、以下のポイントを考慮すべきです。
* The clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Expert needs to make sure the values of algorithms are taken from the right registry when that is required. Experts should consider requesting an opinion on the correctness of registered parameters from relevant IETF working groups. Encodings that do not meet these objectives of clarity and completeness should not be registered.
* 登録の明確さと正確さ。専門家は、要求されたエントリの目的の明確さと使用をチェックすることが期待されています。必要に応じて、アルゴリズムの値が適切なレジストリから取得されていることを専門家が確認する必要があります。専門家は、関連するIETFワーキンググループから登録されたパラメータの正確さについて意見を求めることを検討すべきです。これらの目的でないエンコーディングは登録されるべきではありません。
* The expected usage of fields when approving code point assignment. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.
* コードポイントの割り当てを承認する際のフィールドの予想される使用方法。 エンコードされた値の長さは、その長さのコードポイントが残っている数、使用されるデバイスのサイズ、およびそのサイズにエンコードされる残りのコードポイントの数と比較されるべきです。
* It is recommended to have a specification even if the registration procedure is "Expert Review". When specifications are not provided for a request where Expert Review is the assignment policy, the description provided needs to have sufficient information to verify the code points as above.
* 「Expert Review」が登録手続きの場合でも、仕様があることが推奨されています。Expert Reviewが割り当てポリシーであるリクエストに仕様が提供されていない場合、上記のコードポイントを検証するために十分な情報が記載されている必要があります。
[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>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for
Ed25519, Ed448, X25519, and X448 for Use in the Internet
X.509 Public Key Infrastructure", RFC 8410,
DOI 10.17487/RFC8410, August 2018,
<https://www.rfc-editor.org/info/rfc8410>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/info/rfc9053>.
[RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander,
"Constrained Application Protocol (CoAP): Echo, Request-
Tag, and Token Processing", RFC 9175,
DOI 10.17487/RFC9175, February 2022,
<https://www.rfc-editor.org/info/rfc9175>.
[RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://www.rfc-editor.org/info/rfc9360>.
[Bruni18] Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and
C. Schürmann, "Formal Verification of Ephemeral Diffie-
Hellman Over COSE (EDHOC)", November 2018,
<https://www.springerprofessional.de/en/formal-
verification-of-ephemeral-diffie-hellman-over-cose-
edhoc/16284348>.
[C509-CERTS]
Preuß Mattsson, J., Selander, G., Raza, S., Höglund, J.,
and M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-09, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-09>.
[CborMe] Bormann, C., "CBOR Playground", <https://cbor.me/>.
[CNSA] Wikipedia, "Commercial National Security Algorithm Suite",
October 2023, <https://en.wikipedia.org/w/index.php?title=
Commercial_National_Security_Algorithm_Suite&oldid=1181333
611>.
[CoAP-SEC-PROT]
Mattsson, J. P., Palombini, F., and M. Vučinić,
"Comparison of CoAP Security Protocols", Work in Progress,
Internet-Draft, draft-ietf-iotops-security-protocol-
comparison-04, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-iotops-
security-protocol-comparison-04>.
[CottierPointcheval22]
Cottier, B. and D. Pointcheval, "Security Analysis of the
EDHOC protocol", September 2022,
<https://arxiv.org/abs/2209.03599>.
[CURVE-REPR]
Struik, R., "Alternative Elliptic Curve Representations",
Work in Progress, Internet-Draft, draft-ietf-lwig-curve-
representations-23, 21 January 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lwig-
curve-representations-23>.
[Degabriele11]
Degabriele, J., Lehmann, A., Paterson, K., Smart, N., and
M. Strefler, "On the Joint Security of Encryption and
Signature in EMV", December 2011,
<https://eprint.iacr.org/2011/615>.
[EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-25, 15
January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-25>.
[EDHOC-CoAP-OSCORE]
Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
(EDHOC) with the Constrained Application Protocol (CoAP)
and Object Security for Constrained RESTful Environments
(OSCORE)", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-edhoc-10, 29 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-edhoc-10>.
[GuentherIlunga22]
Günther, F. and M. Mukendi, "Careful with MAc-then-SIGn: A
Computational Analysis of the EDHOC Lightweight
Authenticated Key Exchange Protocol", December 2022,
<https://eprint.iacr.org/2022/1705>.
[HEDGED-ECC-SIGS]
Preuß Mattsson, J., Thormarker, E., and S. Ruohomaa,
"Hedged ECDSA and EdDSA Signatures", Work in Progress,
Internet-Draft, draft-irtf-cfrg-det-sigs-with-noise-02, 1
March 2024, <https://datatracker.ietf.org/doc/html/draft-
irtf-cfrg-det-sigs-with-noise-02>.
[HKDFpaper]
Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", May 2010,
<https://eprint.iacr.org/2010/264.pdf>.
[IEEE.802.15.4-2015]
IEEE, "IEEE Standard for Low-Rate Wireless Networks",
DOI 10.1109/IEEESTD.2016.7460875, April 2016,
<https://ieeexplore.ieee.org/document/7460875>.
[Jacomme23]
Jacomme, C., Klein, E., Kremer, S., and M. Racouchot, "A
comprehensive, formal and automated analysis of the EDHOC
protocol", October 2022,
<https://hal.inria.fr/hal-03810102/>.
[KUDOS] Höglund, R. and M. Tiloca, "Key Update for OSCORE
(KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-key-update-07, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-key-update-07>.
[LAKE-AUTHZ]
Selander, G., Mattsson, J. P., Vučinić, M., Fedrecheski,
G., and M. Richardson, "Lightweight Authorization using
Ephemeral Diffie-Hellman Over COSE", Work in Progress,
Internet-Draft, draft-ietf-lake-authz-01, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lake-
authz-01>.
[LAKE-REQS]
Vučinić, M., Selander, G., Preuß Mattsson, J., and D.
Garcia-Carillo, "Requirements for a Lightweight AKE for
OSCORE", Work in Progress, Internet-Draft, draft-ietf-
lake-reqs-04, 8 June 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-lake-
reqs-04>.
[NISTPQC] National Institute Standards and Technology (NIST), "Post-
Quantum Cryptography FAQs",
<https://csrc.nist.gov/Projects/post-quantum-cryptography/
faqs>.
[Noise] Perrin, T., "The Noise Protocol Framework", Revision 34,
July 2018, <https://noiseprotocol.org/noise.html>.
[Norrman20]
Norrman, K., Sundararajan, V., and A. Bruni, "Formal
Analysis of EDHOC Key Establishment for Constrained IoT
Devices", September 2020,
<https://arxiv.org/abs/2007.11427>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
[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>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/info/rfc8937>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9147] 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>.
[RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
P. van der Stok, "Constrained RESTful Environments (CoRE)
Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
2022, <https://www.rfc-editor.org/info/rfc9176>.
[RFC9397] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP)
Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023,
<https://www.rfc-editor.org/info/rfc9397>.
[RFC9529] Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M.,
and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over
COSE (EDHOC)", RFC 9529, DOI 10.17487/RFC9529, March 2024,
<https://www.rfc-editor.org/info/rfc9529>.
[SECG] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
Standards for Efficient Cryptography, May 2009,
<https://www.secg.org/sec1-v2.pdf>.
[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and Its Use in the IKE-
Protocols", June 2003,
<https://www.iacr.org/cryptodb/archive/2003/
CRYPTO/1495/1495.pdf>.
[SP-800-108]
Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions", NIST Special Publication 800-108
Revision 1, DOI 10.6028/NIST.SP.800-108r1-upd1, August
2022, <https://doi.org/10.6028/NIST.SP.800-108r1-upd1>.
[SP-800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm Cryptography",
NIST Special Publication 800-56A Revision 3,
DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
<https://doi.org/10.6028/NIST.SP.800-56Ar3>.
[SP800-185]
Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived
Functions cSHAKE, KMAC, TupleHash and ParallelHash",
NIST Special Publication 800-185,
DOI 10.6028/NIST.SP.800-185, December 2016,
<https://doi.org/10.6028/NIST.SP.800-185>.
[Thormarker21]
Thormarker, E., "On using the same key pair for Ed25519
and an X25519 based KEM", April 2021,
<https://eprint.iacr.org/2021/509.pdf>.
[THREAT-MODEL-GUIDANCE]
Arkko, J. and S. Farrell, "Internet Threat Model
Guidance", Work in Progress, Internet-Draft, draft-arkko-
arch-internet-threat-model-guidance-00, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-arkko-arch-
internet-threat-model-guidance-00>.
This appendix describes how to derive an OSCORE security context when EDHOC is used to key OSCORE and how to transfer EDHOC messages over CoAP. The use of CoAP or OSCORE with EDHOC is optional, but if you are using CoAP or OSCORE, then certain normative requirements apply as detailed in the subsections.
この付録は、EDHOCがOSCOREの鍵を生成する際のOSCOREセキュリティコンテキストの導出方法と、EDHOCメッセージをCoAP経由で転送する方法について説明しています。CoAPまたはOSCOREをEDHOCと組み合わせて使用することは任意ですが、CoAPまたはOSCOREを使用する場合は、特定の規範要件が詳細に記載された副セクションに従う必要があります。
This section specifies how to use EDHOC output to derive the OSCORE security context.
このセクションは、EDHOCの出力を使用してOSCOREセキュリティコンテキストを導出する方法を指定しています。
After successful processing of EDHOC message_3, the Client and Server derive Security Context parameters for OSCORE as follows (see Section 3.2 of [RFC8613]):
EDHOCメッセージ_3の処理が成功した後、クライアントとサーバーは、OSCOREのためのセキュリティコンテキストパラメータを次のように導出します（[RFC8613]のセクション3.2を参照）。
* The Master Secret and Master Salt SHALL be derived by using the EDHOC_Exporter interface (see Section 4.2.1):
* マスターシークレットとマスターソルトは、EDHOC_Exporterインターフェースを使用して導出されます（セクション4.2.1を参照）。
- The EDHOC Exporter Labels for deriving the OSCORE Master Secret and OSCORE Master Salt are the uints 0 and 1, respectively.
- EDHOCエクスポーターラベルは、OSCOREマスターシークレットとOSCOREマスターソルトを導出するためのuints 0および1です。
- The context parameter is h'' (0x40), the empty CBOR byte string.
- コンテキストパラメータは h'' (0x40)、空の CBOR バイト文字列です。
- By default, oscore_key_length is the key length (in bytes) of the application AEAD Algorithm of the selected cipher suite for the EDHOC session. Also by default, oscore_salt_length has value 8. The Initiator and Responder MAY agree out-of-band on a longer oscore_key_length than the default and on shorter or longer than the default oscore_salt_length.
- デフォルトでは、oscore_key_lengthはEDHOCセッションの選択された暗号スイートのアプリケーションAEADアルゴリズムのキー長（バイト単位）です。デフォルトでは、oscore_salt_lengthは値8です。イニシエータとレスポンダは、デフォルトよりも長いoscore_key_lengthや、デフォルトよりも短いまたは長いoscore_salt_lengthについて、アウトオブバンドで合意することができます。
Master Secret = EDHOC_Exporter( 0, h'', oscore_key_length )
Master Salt = EDHOC_Exporter( 1, h'', oscore_salt_length )
* The AEAD Algorithm SHALL be the application AEAD algorithm of the selected cipher suite for the EDHOC session.
* 選択された暗号スイートのアプリケーションAEADアルゴリズムは、EDHOCセッションのためのアプリケーションAEADアルゴリズムであるべきです。
* The HKDF Algorithm SHALL be the one based on the application hash algorithm of the selected cipher suite for the EDHOC session. For example, if SHA-256 is the application hash algorithm of the selected cipher suite, HKDF SHA-256 is used as the HKDF Algorithm in the OSCORE Security Context.
* HKDFアルゴリズムは、EDHOCセッションの選択された暗号スイートのアプリケーションハッシュアルゴリズムに基づくものでなければなりません。たとえば、選択された暗号スイートのアプリケーションハッシュアルゴリズムがSHA-256である場合、OSCOREセキュリティコンテキストでHKDF SHA-256がHKDFアルゴリズムとして使用されます。
* The relationship between identifiers in OSCORE and EDHOC is specified in Section 3.3.3. The OSCORE Sender ID and Recipient ID SHALL be determined by EDHOC connection identifiers C_R and C_I for the EDHOC session as shown in Table 14.
* OSCOREとEDHOCの識別子間の関係は、セクション3.3.3で指定されています。 OSCOREのSender IDとRecipient IDは、EDHOC接続識別子C_RおよびC_IによってEDHOCセッションのために決定されます（表14に示されています）。
+=================+==================+=====================+
| | OSCORE Sender ID | OSCORE Recipient ID |
+=================+==================+=====================+
| EDHOC Initiator | C_R | C_I |
+-----------------+------------------+---------------------+
| EDHOC Responder | C_I | C_R |
+-----------------+------------------+---------------------+
Table 14: Usage of Connection Identifiers in OSCORE
表14：OSCOREでの接続識別子の使用
The Client and Server SHALL use the parameters above to establish an OSCORE Security Context, as per Section 3.2.1 of [RFC8613].
クライアントとサーバーは、上記のパラメータを使用して、[RFC8613]のセクション3.2.1に従ってOSCOREセキュリティコンテキストを確立する必要があります。
From then on, the Client and Server retrieve the OSCORE protocol state using the Recipient ID and optionally other transport information such as the 5-tuple.
その後、クライアントとサーバーは、受信者IDやオプションで他の輸送情報（5つ組など）を使用して、OSCOREプロトコルの状態を取得します。
This section specifies how EDHOC can be transferred as an exchange of CoAP [RFC7252] messages. CoAP provides a reliable transport that can preserve packet ordering, provides flow and congestion control, and handles message duplication. CoAP can also perform fragmentation and mitigate certain denial-of-service attacks. The underlying CoAP transport should be used in reliable mode, in particular, when fragmentation is used, to avoid, e.g., situations with hanging endpoints waiting for each other.
このセクションは、EDHOCがCoAP [RFC7252] メッセージの交換としてどのように転送されるかを指定しています。CoAPは、パケットの順序を保持し、フローおよび輻輳制御を提供し、メッセージの重複を処理できる信頼性のあるトランスポートを提供します。CoAPはまた、フラグメンテーションを実行し、特定のサービス拒否攻撃を緩和することができます。フラグメンテーションが使用される場合など、相互に待ち合わせるエンドポイントが発生しないようにするために、信頼性のあるモードで基盤となるCoAPトランスポートを使用する必要があります。
EDHOC may run with the Initiator either being a CoAP client or CoAP server. We denote the former by the "forward message flow" (see Appendix A.2.1) and the latter by the "reverse message flow" (see Appendix A.2.2). By default, we assume the forward message flow, but the roles SHOULD be chosen to protect the most sensitive identity; see Section 9.
EDHOCは、イニシエータがCoAPクライアントまたはCoAPサーバで実行できます。前者を「フォワードメッセージフロー」とし、後者を「リバースメッセージフロー」とします。デフォルトでは、フォワードメッセージフローを想定していますが、役割は最も機密性の高いアイデンティティを保護するために選択されるべきです。セクション9を参照してください。
According to this specification, EDHOC is transferred in POST requests to the Uri-Path: "/.well-known/edhoc" (see Section 10.7) and 2.04 (Changed) responses. An application may define its own path that can be discovered, e.g., using a resource directory [RFC9176]. Client applications can use the resource type "core.edhoc" to discover a server's EDHOC resource, i.e., where to send a request for executing the EDHOC protocol; see Section 10.10. An alternative transfer of the forward message flow is specified in [EDHOC-CoAP-OSCORE].
この仕様によると、EDHOCはPOSTリクエストでUri-Pathに転送されます："/.well-known/edhoc"（セクション10.7を参照）および2.04（変更済み）の応答。アプリケーションは、リソースディレクトリ[RFC9176]を使用して、独自のパスを定義し、発見できます。クライアントアプリケーションは、リソースタイプ"core.edhoc"を使用して、サーバーのEDHOCリソースを発見できます。つまり、EDHOCプロトコルを実行するためのリクエストを送信する場所を示します。詳細はセクション10.10を参照してください。フォワードメッセージフローの代替転送は、[EDHOC-CoAP-OSCORE]で指定されています。
In order for the server to correlate a message received from a client to a message previously sent in the same EDHOC session over CoAP, messages sent by the client SHALL be prepended with the CBOR serialization of the connection identifier that the server has selected; see Section 3.4.1. This applies both to the forward and the reverse message flows. To indicate a new EDHOC session in the forward message flow, message_1 SHALL be prepended with the CBOR simple value true (0xf5). Even if CoAP is carried over a reliable transport protocol, such as TCP, the prepending of identifiers specified here SHALL be practiced to enable interoperability independent of how CoAP is transported.
サーバーがクライアントから受信したメッセージを、同じEDHOCセッション内で以前に送信されたメッセージと関連付けるためには、クライアントが送信するメッセージには、サーバーが選択した接続識別子のCBORシリアル化が先頭に付加される必要があります。これは、前方および逆方向のメッセージフローの両方に適用されます。前方のメッセージフローで新しいEDHOCセッションを示すためには、message_1にCBORのシンプルな値であるtrue（0xf5）が先頭に付加される必要があります。TCPなどの信頼性のある転送プロトコルを介してCoAPが転送されている場合でも、ここで指定された識別子の先頭付加は、CoAPの転送方法に関係なく相互運用性を実現するために実施される必要があります。
The prepended identifiers are encoded in CBOR and thus self-delimiting. The representation of identifiers described in Section 3.3.2 SHALL be used. They are sent in front of the actual EDHOC message to keep track of messages in an EDHOC session, and only the part of the body following the identifier is used for EDHOC processing. In particular, the connection identifiers within the EDHOC messages are not impacted by the prepended identifiers.
事前に付加された識別子はCBORでエンコードされており、そのため自己区切りです。セクション3.3.2で説明されている識別子の表現が使用されます。これらは、EDHOCセッション内のメッセージを追跡するために実際のEDHOCメッセージの前に送信され、識別子に続く本文の部分のみがEDHOC処理に使用されます。特に、EDHOCメッセージ内の接続識別子は、事前に付加された識別子に影響を受けません。
An EDHOC message has media type "application/edhoc+cbor-seq", whereas an EDHOC message prepended by a connection identifier has media type "application/cid-edhoc+cbor-seq"; see Section 10.9.
EDHOC メッセージのメディアタイプは "application/edhoc+cbor-seq" であり、接続識別子が前置された EDHOC メッセージのメディアタイプは "application/cid-edhoc+cbor-seq" です。セクション 10.9 を参照してください。
To mitigate certain denial-of-service attacks, the CoAP server MAY respond to the first POST request with a 4.01 (Unauthorized) containing an Echo option [RFC9175]. This forces the Initiator to demonstrate reachability at its apparent network address. If message fragmentation is needed, the EDHOC messages may be fragmented using the CoAP Block-Wise Transfer mechanism [RFC7959].
特定のサービス拒否攻撃を緩和するために、CoAPサーバーは最初のPOSTリクエストに4.01（Unauthorized）を含むEchoオプション[RFC9175]で応答することができます。これにより、イニシエーターは自身のネットワークアドレスで到達可能であることを証明する必要があります。メッセージの断片化が必要な場合、EDHOCメッセージはCoAPブロックワイズ転送メカニズム[RFC7959]を使用して断片化される可能性があります。
EDHOC error messages need to be transported in response to a message that failed (see Section 6). EDHOC error messages transported with CoAP are carried in the payload.
EDHOCエラーメッセージは、失敗したメッセージに応答して転送する必要があります（セクション6を参照）。 CoAPで転送されるEDHOCエラーメッセージは、ペイロードに含まれています。
Note that the transport over CoAP can serve as a blueprint for other client-server protocols:
CoAPを介した輸送は、他のクライアントサーバープロトコルの設計図として機能する可能性があります。
* The client prepends the connection identifier selected by the server (or, for message_1, the CBOR simple value true) to any request message it sends.
* クライアントは、サーバーが選択した接続識別子（または、message_1の場合はCBORシンプル値true）を、送信するすべてのリクエストメッセージの前に付加します。
* The server does not send any such indicator, as responses are matched to request by the client-server protocol design.
* サーバーはそのような指標を送信しません。応答はクライアントサーバープロトコルの設計によってリクエストに一致します。
In the forward message flow, the CoAP client is the Initiator and the CoAP server is the Responder. This flow protects the client identity against active attackers and the server identity against passive attackers.
フォワードメッセージフローでは、CoAPクライアントがイニシエーターであり、CoAPサーバーがレスポンダーです。このフローは、クライアントのアイデンティティをアクティブな攻撃者から保護し、サーバーのアイデンティティを受動的な攻撃者から保護します。
In the forward message flow, the CoAP Token enables correlation on the Initiator (client) side, and the prepended C_R enables correlation on the Responder (server) side.
フォワードメッセージフローでは、CoAP トークンがイニシエーター（クライアント）側で相関を可能にし、先行する C_R がレスポンダー（サーバー）側で相関を可能にします。
* EDHOC message_1 is sent in the payload of a POST request from the client to the server's resource for EDHOC, prepended with the identifier true (0xf5), indicating a new EDHOC session.
* EDHOCメッセージ1は、クライアントからサーバーのEDHOCリソースに送信されるPOSTリクエストのペイロードに含まれており、新しいEDHOCセッションを示す識別子true（0xf5）が前置されています。
* EDHOC message_2 or the EDHOC error message is sent from the server to the client in the payload of the response, in the former case with response code 2.04 (Changed) and in the latter with response code as specified in Appendix A.2.3.
* サーバーからクライアントへのEDHOCメッセージ_2またはEDHOCエラーメッセージは、レスポンスのペイロードで送信されます。前者の場合はレスポンスコード2.04（変更）で、後者の場合は付録A.2.3で指定されたレスポンスコードで送信されます。
* EDHOC message_3 or the EDHOC error message is sent from the client to the server's resource in the payload of a POST request, prepended with connection identifier C_R.
* EDHOCメッセージ_3またはEDHOCエラーメッセージは、クライアントからサーバーのリソースにPOSTリクエストのペイロードとして送信され、接続識別子C_Rが前置されます。
* If EDHOC message_4 is used, or in case of an error message, it is sent from the server to the client in the payload of the response, with response codes analogously to message_2. In case of an error message sent in response to message_4, it is sent analogously to the error message sent in response to message_2.
* EDHOCメッセージ4が使用される場合、またはエラーメッセージの場合、サーバーからクライアントに応答のペイロード内で送信され、応答コードはメッセージ2と同様になります。メッセージ4への応答として送信されるエラーメッセージの場合、メッセージ2への応答として送信されるエラーメッセージと同様に送信されます。
An example of a completed EDHOC session over CoAP in the forward message flow is shown in Figure 10.
図10には、CoAP上でのEDHOCセッションの完了例が示されています。
Client Server
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc"
| | Content-Format: application/cid-edhoc+cbor-seq
| | Payload: true, EDHOC message_1
| |
|<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/edhoc+cbor-seq
| | Payload: EDHOC message_2
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc"
| | Content-Format: application/cid-edhoc+cbor-seq
| | Payload: C_R, EDHOC message_3
| |
|<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/edhoc+cbor-seq
| | Payload: EDHOC message_4
| |
Figure 10: Example of the Forward Message Flow
図10：フォワードメッセージフローの例
The forward message flow of EDHOC can be combined with an OSCORE exchange in a total of two round trips; see [EDHOC-CoAP-OSCORE].
EDHOCのフォワードメッセージフローは、合計2つのラウンドトリップでOSCORE交換と組み合わせることができます。[EDHOC-CoAP-OSCORE]を参照してください。
In the reverse message flow, the CoAP client is the Responder and the CoAP server is the Initiator. This flow protects the server identity against active attackers and the client identity against passive attackers.
逆メッセージフローでは、CoAPクライアントがレスポンダーであり、CoAPサーバーがイニシエーターです。このフローは、サーバーのアイデンティティをアクティブな攻撃者から保護し、クライアントのアイデンティティを受動的な攻撃者から保護します。
In the reverse message flow, the CoAP Token enables correlation on the Responder (client) side, and the prepended C_I enables correlation on the Initiator (server) side.
逆メッセージフローでは、CoAP トークンが応答者（クライアント）側で相関を可能にし、先行する C_I がイニシエータ（サーバー）側で相関を可能にします。
* To trigger a new EDHOC session, the client makes an empty POST request to the server's resource for EDHOC.
* 新しいEDHOCセッションを開始するために、クライアントはEDHOCのサーバーリソースに空のPOSTリクエストを送信します。
* EDHOC message_1 is sent from the server to the client in the payload of the response with response code 2.04 (Changed).
* サーバーからクライアントへのEDHOCメッセージ1は、レスポンスのペイロード内でレスポンスコード2.04（変更）と共に送信されます。
* EDHOC message_2 or the EDHOC error message is sent from the client to the server's resource in the payload of a POST request, prepended with connection identifier C_I.
* EDHOCメッセージ_2またはEDHOCエラーメッセージは、クライアントからサーバーのリソースに、POSTリクエストのペイロード内で、接続識別子C_Iを前置して送信されます。
* EDHOC message_3 or the EDHOC error message is sent from the server to the client in the payload of the response, in the former case with response code 2.04 (Changed) and in the latter with response code as specified in Appendix A.2.3.
* EDHOCメッセージ_3またはEDHOCエラーメッセージは、サーバーからクライアントにレスポンスのペイロードで送信されます。前者の場合はレスポンスコード2.04（変更済み）、後者の場合は付録A.2.3で指定されたレスポンスコードで送信されます。
* If EDHOC message_4 is used, or in case of an error message, it is sent from the client to the server's resource in the payload of a POST request, prepended with connection identifier C_I. In case of an error message sent in response to message_4, it is sent analogously to an error message sent in response to message_2.
* EDHOCメッセージ4が使用される場合、またはエラーメッセージの場合、クライアントからサーバーのリソースに、POSTリクエストのペイロード内で、接続識別子C_Iを前置して送信されます。メッセージ4に対するエラーメッセージが送信される場合、それはメッセージ2に対するエラーメッセージと同様に送信されます。
An example of a completed EDHOC session over CoAP in the reverse message flow is shown in Figure 11.
CoAP上で完了したEDHOCセッションの逆メッセージフローの例が図11に示されています。
Client Server
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc"
| |
|<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/edhoc+cbor-seq
| | Payload: EDHOC message_1
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc"
| | Content-Format: application/cid-edhoc+cbor-seq
| | Payload: C_I, EDHOC message_2
| |
|<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/edhoc+cbor-seq
| | Payload: EDHOC message_3
| |
Figure 11: Example of the Reverse Message Flow
図11：逆メッセージフローの例
When using EDHOC over CoAP, EDHOC error messages sent as CoAP responses MUST be sent in the payload of error responses, i.e., they MUST specify a CoAP error response code. In particular, it is RECOMMENDED that such error responses have response code either 4.00 (Bad Request) in case of client error (e.g., due to a malformed EDHOC message) or 5.00 (Internal Server Error) in case of server error (e.g., due to failure in deriving EDHOC keying material). The Content-Format of the error response MUST be set to "application/ edhoc+cbor-seq"; see Section 10.9.
CoAPを介してEDHOCを使用する場合、EDHOCエラーメッセージはCoAP応答として送信される必要があり、つまり、CoAPエラー応答コードを指定する必要があります。特に、そのようなエラー応答は、クライアントエラー（たとえば、形式が正しくないEDHOCメッセージのため）の場合は4.00（Bad Request）またはサーバーエラー（たとえば、EDHOC鍵材料の導出に失敗した場合）の場合は5.00（Internal Server Error）の応答コードを持つことが推奨されます。エラー応答のContent-Formatは、"application/edhoc+cbor-seq"に設定する必要があります。Section 10.9を参照してください。
This section defines a format for compact representation based on the Elliptic-Curve-Point-to-Octet-String Conversion defined in Section 2.3.3 of [SECG].
このセクションは、[SECG]のセクション2.3.3で定義された楕円曲線ポイントからオクテット文字列への変換に基づくコンパクト表現の形式を定義しています。
As described in Section 4.2 of [RFC6090], the x-coordinate of an elliptic curve public key is a suitable representative for the entire point whenever scalar multiplication is used as a one-way function. One example is ECDH with compact output, where only the x-coordinate of the computed value is used as the shared secret.
[RFC6090]のセクション4.2に記載されているように、楕円曲線公開鍵のx座標は、スカラー乗算が一方向関数として使用される場合には、全体のポイントの適切な代表となります。1つの例は、コンパクトな出力を持つECDHで、計算された値のx座標のみが共有秘密として使用されます。
In EDHOC, compact representation is used for the ephemeral public keys (G_X and G_Y); see Section 3.7. Using the notation from [SECG], the output is an octet string of length ceil( (log2 q) / 8 ), where ceil(x) is the smallest integer not less than x. See [SECG] for a definition of q, M, X, xp, and ~yp. The steps in Section 2.3.3 of [SECG] are replaced with the following steps:
EDHOCでは、一時的な公開鍵（G_XとG_Y）のコンパクトな表現が使用されます。[SECG]からの表記を使用すると、出力は長さが ceil( (log2 q) / 8 ) のオクテット文字列です。ここで、ceil(x) は x より小さくない最小の整数です。q、M、X、xp、および ~yp の定義については[SECG]を参照してください。[SECG]のセクション2.3.3の手順は、以下の手順で置き換えられます。
1. Convert the field element xp to an octet string X of length ceil( (log2 q) / 8 ) octets using the conversion routine specified in Section 2.3.5 of [SECG].
1. 「xp」というフィールド要素を、長さが ceil( (log2 q) / 8 ) オクテットのオクテット文字列Xに変換します。この変換ルーチンは、[SECG]のセクション2.3.5で指定されています。
2. Output M = X.
2. M = X を出力します。
The encoding of the point at infinity is not supported.
無限遠点のエンコーディングはサポートされていません。
Compact representation does not change any requirements on validation; see Section 9.2. Using compact representation has some security benefits. An implementation does not need to check that the point is not the point at infinity (the identity element). Similarly, as not even the sign of the y-coordinate is encoded, compact representation trivially avoids so-called "benign malleability" attacks where an attacker changes the sign; see [SECG].
コンパクトな表現は検証に関する要件を変更しません。セクション9.2を参照してください。コンパクトな表現を使用すると、いくつかのセキュリティ上の利点があります。実装では、点が無限の点（単位元）でないことを確認する必要はありません。同様に、y座標の符号さえエンコードされていないため、コンパクトな表現は「良性の可変性」攻撃を回避します。攻撃者が符号を変更する攻撃を簡単に回避します。[SECG]を参照してください。
The following may be needed for validation or compatibility with APIs that do not support compact representation or do not support the full [SECG] format:
次のテキストは、コンパクトな表現をサポートしていないAPIや完全な[SECG]形式をサポートしていないAPIとの検証や互換性のために必要となる場合があります。
* If a compressed y-coordinate is required, then the value ~yp set to zero can be used. In such a case, the compact representation described above can be transformed into the Standards for Efficient Cryptography Group (SECG) point-compressed format by prepending it with the single byte 0x02 (i.e., M = 0x02 || X).
* 圧縮されたy座標が必要な場合、ゼロに設定された値~ypを使用できます。そのような場合、上記で説明したコンパクト表現は、単一バイト0x02（すなわち、M = 0x02 || X）を前置して、効率的な暗号化グループ（SECG）の点圧縮形式に変換できます。
* If an uncompressed y-coordinate is required, then a y-coordinate has to be calculated following Section 2.3.4 of [SECG] or Appendix C of [RFC6090]. Any of the square roots (see [SECG] or [RFC6090]) can be used. The uncompressed SECG format is M = 0x04 || X || Y.
* 圧縮されていない y 座標が必要な場合は、[SECG] のセクション 2.3.4 または [RFC6090] の付録 C に従って y 座標を計算する必要があります。いずれかの平方根（[SECG] または [RFC6090] を参照）を使用できます。圧縮されていない SECG フォーマットは M = 0x04 || X || Y です。
For example: The curve P-256 has the parameters (using the notation in [RFC6090]):
例えば、曲線P-256はパラメータを持っています（[RFC6090]の表記法を使用）。
* p = 2^256 - 2^224 + 2^192 + 2^96 - 1
* p = 2^256 - 2^224 + 2^192 + 2^96 - 1
* a = -3
* a = -3
* b = 410583637251521421293261297800472684091144410159937255 54835256314039467401291
* b = 410583637251521421293261297800472684091144410159937255 54835256314039467401291
Given an example x:
与えられた例 x:
* x = 115792089183396302095546807154740558443406795108653336 398970697772788799766525
* x = 115792089183396302095546807154740558443406795108653336 398970697772788799766525
We can calculate y as the square root w = (x^3 + a ⋅ x + b)^((p + 1)/4) (mod p).
私たちは、yを次のように計算できます：w = (x^3 + a ⋅ x + b)^((p + 1)/4) (mod p)。
* y = 834387180070192806820075864918626005281451259964015754 16632522940595860276856
* y = 834387180070192806820075864918626005281451259964015754 16632522940595860276856
Note that this does not guarantee that (x, y) is on the correct elliptic curve. A full validation according to Section 5.6.2.3.3 of [SP-800-56A] is done by also checking that 0 ≤ x < p and that y^2 ≡ x^3 + a ⋅ x + b (mod p).
注意：これは（x、y）が正しい楕円曲線上にあることを保証するものではありません。[SP-800-56A]のセクション5.6.2.3.3に従った完全な検証では、xが0以上p未満であることと、y^2 ≡ x^3 + a ⋅ x + b (mod p)であることも確認されます。
This appendix is intended to help implementors not familiar with CBOR [RFC8949], CDDL [RFC8610], COSE [RFC9052], and HKDF [RFC5869].
この付録は、CBOR [RFC8949]、CDDL [RFC8610]、COSE [RFC9052]、およびHKDF [RFC5869]に精通していない実装者の支援を目的としています。
The Concise Binary Object Representation (CBOR) [RFC8949] is a data format designed for small code size and small message size. CBOR builds on the JSON data model but extends it by, e.g., encoding binary data directly without base64 conversion. In addition to the binary CBOR encoding, CBOR also has a diagnostic notation that is readable and editable by humans. The Concise Data Definition Language (CDDL) [RFC8610] provides a way to express structures for protocol messages and APIs that use CBOR. [RFC8610] also extends the diagnostic notation.
CBOR（Concise Binary Object Representation）[RFC8949]は、小さなコードサイズと小さなメッセージサイズを目指して設計されたデータ形式です。CBORはJSONデータモデルを基にしており、例えば、バイナリデータをbase64変換せずに直接エンコードするなどの拡張を行っています。バイナリCBORエンコーディングに加えて、CBORには人間が読み取りやすく編集可能な診断表記もあります。Concise Data Definition Language（CDDL）[RFC8610]は、CBORを使用するプロトコルメッセージやAPIの構造を表現する方法を提供しています。[RFC8610]は診断表記も拡張しています。
CBOR data items are encoded to or decoded from byte strings using a type-length-value encoding scheme, where the three highest order bits of the initial byte contain information about the major type. CBOR supports several types of data items, integers (int, uint), simple values, byte strings (bstr), and text strings (tstr). CBOR also supports arrays [] of data items, maps {} of pairs of data items, and sequences [RFC8742] of data items. Some examples are given below.
CBORデータアイテムは、タイプ・長さ・値のエンコーディング方式を使用してバイト文字列にエンコードまたはデコードされます。初期バイトの上位3ビットには、メジャータイプに関する情報が含まれています。CBORは、整数（int、uint）、単純な値、バイト文字列（bstr）、およびテキスト文字列（tstr）など、いくつかの種類のデータアイテムをサポートしています。CBORはまた、データアイテムの配列[]、データアイテムのペアのマップ{}、およびデータアイテムのシーケンス[RFC8742]をサポートしています。以下にいくつかの例を示します。
The EDHOC specification sometimes use CDDL names in CBOR diagnostic notation as in, e.g., << ID_CRED_R, ? EAD_2 >>. This means that EAD_2 is optional and that ID_CRED_R and EAD_2 should be substituted with their values before evaluation. That is, if ID_CRED_R = { 4 : h'' } and EAD_2 is omitted, then << ID_CRED_R, ? EAD_2 >> = << { 4 : h'' } >>, which encodes to 0x43a10440. We also make use of the occurrence symbol "*", like in, e.g., 2* int, meaning two or more CBOR integers.
EDHOC仕様では、たとえば << ID_CRED_R, ? EAD_2 >> のように、時々CBOR診断表記でCDDL名が使用されます。これは、EAD_2がオプションであり、ID_CRED_RとEAD_2は評価の前にそれぞれの値に置き換えられるべきことを意味します。つまり、ID_CRED_R = { 4 : h'' } であり、EAD_2が省略された場合、<< ID_CRED_R, ? EAD_2 >> = << { 4 : h'' } >> となり、これは0x43a10440にエンコードされます。また、2* intのように、出現記号"*"も使用しています。
For a complete specification and more examples, see [RFC8949] and [RFC8610]. We recommend implementors get used to CBOR by using the CBOR playground [CborMe].
完全な仕様とさらなる例については、[RFC8949]と[RFC8610]を参照してください。私たちは、CBOR playground [CborMe]を使用してCBORに慣れることを推奨します。
+==================+==============+==================+
| Diagnostic | Encoded | Type |
+==================+==============+==================+
| 1 | 0x01 | unsigned integer |
+------------------+--------------+------------------+
| 24 | 0x1818 | unsigned integer |
+------------------+--------------+------------------+
| -24 | 0x37 | negative integer |
+------------------+--------------+------------------+
| -25 | 0x3818 | negative integer |
+------------------+--------------+------------------+
| true | 0xf5 | simple value |
+------------------+--------------+------------------+
| h'' | 0x40 | byte string |
+------------------+--------------+------------------+
| h'12cd' | 0x4212cd | byte string |
+------------------+--------------+------------------+
| '12cd' | 0x4431326364 | byte string |
+------------------+--------------+------------------+
| "12cd" | 0x6431326364 | text string |
+------------------+--------------+------------------+
| { 4 : h'cd' } | 0xa10441cd | map |
+------------------+--------------+------------------+
| << 1, 2, true >> | 0x430102f5 | byte string |
+------------------+--------------+------------------+
| [ 1, 2, true ] | 0x830102f5 | array |
+------------------+--------------+------------------+
| ( 1, 2, true ) | 0x0102f5 | sequence |
+------------------+--------------+------------------+
| 1, 2, true | 0x0102f5 | sequence |
+------------------+--------------+------------------+
Table 15: Examples of Use of CBOR and CDDL
表15：CBORとCDDLの使用例
This section compiles the CDDL definitions for ease of reference.
このセクションは、参照しやすいように CDDL の定義をまとめたものです。
suites = [ 2* int ] / int
ead = (
ead_label : int,
? ead_value : bstr,
)
EAD_1 = 1* ead
EAD_2 = 1* ead
EAD_3 = 1* ead
EAD_4 = 1* ead
message_1 = (
METHOD : int,
SUITES_I : suites,
G_X : bstr,
C_I : bstr / -24..23,
? EAD_1,
)
message_2 = (
G_Y_CIPHERTEXT_2 : bstr,
)
PLAINTEXT_2 = (
C_R,
ID_CRED_R : map / bstr / -24..23,
Signature_or_MAC_2 : bstr,
? EAD_2,
)
message_3 = (
CIPHERTEXT_3 : bstr,
)
PLAINTEXT_3 = (
ID_CRED_I : map / bstr / -24..23,
Signature_or_MAC_3 : bstr,
? EAD_3,
)
message_4 = (
CIPHERTEXT_4 : bstr,
)
PLAINTEXT_4 = (
? EAD_4,
)
error = (
ERR_CODE : int,
ERR_INFO : any,
)
info = (
info_label : int,
context : bstr,
length : uint,
)
CBOR Object Signing and Encryption (COSE) [RFC9052] describes how to create and process signatures, MACs, and encryptions using CBOR. COSE builds on JSON Object Signing and Encryption (JOSE) but is adapted to allow more efficient processing in constrained devices. EDHOC makes use of COSE_Key, COSE_Encrypt0, and COSE_Sign1 objects in the message processing:
CBOR Object Signing and Encryption (COSE) [RFC9052]は、CBORを使用して署名、MAC、および暗号化を作成および処理する方法を説明しています。COSEはJSON Object Signing and Encryption (JOSE)に基づいて構築されていますが、制約のあるデバイスで効率的な処理を可能にするように適応されています。EDHOCは、メッセージ処理でCOSE_Key、COSE_Encrypt0、およびCOSE_Sign1オブジェクトを使用します。
* ECDH ephemeral public keys of type EC2 or OKP in message_1 and message_2 consist of the COSE_Key parameter named 'x'; see Sections 7.1 and 7.2 of [RFC9053].
* メッセージ1およびメッセージ2の中のEC2またはOKPタイプのECDH一時公開鍵は、'x'というCOSE_Keyパラメータで構成されています。[RFC9053]のセクション7.1および7.2を参照してください。
* The ciphertexts in message_3 and message_4 consist of a subset of the single recipient encrypted data object COSE_Encrypt0, which is described in Sections 5.2 and 5.3 of [RFC9052]. The ciphertext is computed over the plaintext and associated data, using an encryption key and an initialization vector. The associated data is an Enc_structure consisting of protected headers and externally supplied data (external_aad). COSE constructs the input to the AEAD [RFC5116] for message_i (i = 3 or 4; see Sections 5.4 and 5.5, respectively) as follows:
* message_3とmessage_4の暗号文は、[RFC9052]のセクション5.2および5.3で説明されているCOSE_Encrypt0という単一の受信者暗号化データオブジェクトの部分集合で構成されています。 暗号文は、暗号化キーと初期化ベクトルを使用して、平文と関連データ上に計算されます。 関連データは、保護されたヘッダーと外部提供データ（external_aad）からなるEnc_structureです。 COSEは、メッセージ_i（i = 3または4；それぞれセクション5.4および5.5を参照）のAEAD [RFC5116]への入力を構築します。
- Secret key K = K_i
- 秘密鍵 K = K_i
- Nonce N = IV_i
- Nonce N = IV_i
- Plaintext P for message_i
- メッセージ_iの平文P
- Associated Data A = [ "Encrypt0", h'', TH_i ]
- 関連データ A = [ "Encrypt0", h'', TH_i ]
* Signatures in message_2 of method 0 and 2, and in message_3 of method 0 and 1, consist of a subset of the single signer data object COSE_Sign1, which is described in Sections 4.2 and 4.4 of [RFC9052]. The signature is computed over a Sig_structure containing payload, protected headers and externally supplied data (external_aad) using a private signature key, and verified using the corresponding public signature key. For COSE_Sign1, the message to be signed is:
* メソッド0および2のmessage_2の署名、およびメソッド0および1のmessage_3の署名は、[RFC9052]のセクション4.2および4.4で説明されているCOSE_Sign1という単一署名者データオブジェクトの部分集合で構成されています。署名は、ペイロード、保護されたヘッダー、および外部提供されたデータ（external_aad）を含むSig_structure上で、プライベート署名キーを使用して計算され、対応する公開署名キーを使用して検証されます。COSE_Sign1の場合、署名されるメッセージは次のとおりです：
[ "Signature1", protected, external_aad, payload ]
where protected, external_aad, and payload are specified in Sections 5.3 and 5.4.
セクション5.3および5.4でwhere protected、external_aad、およびpayloadが指定されています。
Different header parameters to identify X.509 or C509 certificates by reference are defined in [RFC9360] and [C509-CERTS]:
[RFC9360]および[C509-CERTS]で定義されている、X.509またはC509証明書を識別するための異なるヘッダーパラメーターがあります。
* by a hash value with the 'x5t' or 'c5t' parameters, respectively:
* 'x5t'または'c5t'パラメーターでハッシュ値によって：
- ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R and
- ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R and
- ID_CRED_x = { 22 : COSE_CertHash }, for x = I or R,
- ID_CRED_x = { 22 : COSE_CertHash }, for x = I or R,
* or by a URI with the 'x5u' or 'c5u' parameters, respectively:
* URIには、それぞれ 'x5u' または 'c5u' パラメータを使用して指定することもできます。
- ID_CRED_x = { 35 : uri }, for x = I or R, and
- ID_CRED_x = { 35 : uri }, for x = I or R, and
- ID_CRED_x = { 23 : uri }, for x = I or R.
- ID_CRED_x = { 23 : uri }, for x = I or R.
When ID_CRED_x does not contain the actual credential, it may be very short, e.g., if the endpoints have agreed to use a key identifier parameter 'kid':
ID_CRED_x に実際の資格情報が含まれていない場合、非常に短くなる可能性があります。たとえば、エンドポイントがキー識別子パラメータ 'kid' を使用することに同意している場合:
* ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R. For further optimization, see Section 3.5.3.
* ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R. For further optimization, see Section 3.5.3.
Note that ID_CRED_x can contain several header parameters, for example, { x5u, x5t } or { kid, kid_context }.
ID_CRED_xには、例えば{ x5u、x5t }や{ kid、kid_context }など、複数のヘッダーパラメータが含まれることがあります。
ID_CRED_x MAY also identify the credential by value. For example, a certificate chain can be transported in an ID_CRED field with COSE header parameter c5c or x5chain, as defined in [C509-CERTS] and [RFC9360]. Credentials of type CWT and CCS can be transported with the COSE header parameters registered in Section 10.6.
ID_CRED_xは値によっても資格情報を識別することができます。たとえば、証明書チェーンは、[C509-CERTS]および[RFC9360]で定義されているc5cまたはx5chainのCOSEヘッダーパラメータを持つID_CREDフィールドで転送することができます。CWTおよびCCSのタイプの資格情報は、セクション10.6で登録されたCOSEヘッダーパラメータを使用して転送することができます。
EDHOC performs certain authentication-related operations (see Section 3.5), but in general, it is necessary to make additional verifications beyond EDHOC message processing. Which verifications that are needed depend on the deployment, in particular, the trust model and the security policies, but most commonly, it can be expressed in terms of verifications of credential content.
EDHOCは特定の認証関連の操作を実行します（セクション3.5を参照）。ただし、一般的には、EDHOCメッセージ処理を超えて追加の検証が必要です。必要な検証は、展開に依存し、特に信頼モデルとセキュリティポリシーによりますが、最も一般的には、資格情報の内容の検証として表現できます。
EDHOC assumes the existence of mechanisms (certification authority or other trusted third party, pre-provisioning, etc.) for generating and distributing authentication credentials and other credentials, as well as the existence of trust anchors (CA certificates, trusted public keys, etc.). For example, a public key certificate or CWT may rely on a trusted third party whose public key is pre-provisioned, whereas a CCS or a self-signed certificate / CWT may be used when trust in the public key can be achieved by other means, or in the case of trust on first use, see Appendix D.5.
EDHOCは、認証資格情報やその他の資格情報を生成および配布するためのメカニズム（認証機関または他の信頼できる第三者、事前設定など）の存在を前提とし、信頼アンカー（CA証明書、信頼できる公開鍵など）の存在を前提とします。たとえば、公開鍵証明書やCWTは、事前に設定された公開鍵を持つ信頼できる第三者に依存する場合がありますが、信頼できる公開鍵が他の手段で達成される場合や、最初の使用時の信頼の場合など、他の手段で公開鍵への信頼が得られる場合には、CCSや自己署名証明書/CWTが使用されることがあります。
In this section, we provide some examples of such verifications. These verifications are the responsibility of the application but may be implemented as part of an EDHOC library.
このセクションでは、そのような検証の例をいくつか提供します。これらの検証はアプリケーションの責任ですが、EDHOCライブラリの一部として実装されることがあります。
In addition to the authentication key, the authentication credential may contain other parameters that need to be verified. For example:
認証キーに加えて、認証資格情報には検証が必要な他のパラメータが含まれる場合があります。例えば：
* In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature", and Diffie-Hellman public keys typically have key usage "keyAgreement" [RFC3279] [RFC8410].
* X.509およびC509証明書では、署名キーには通常、キー使用法が「digitalSignature」となり、Diffie-Hellman公開キーには通常、キー使用法が「keyAgreement」になります。
* In X.509 and C509 certificates, validity is expressed using Not After and Not Before. In CWT and CCS, the "exp" and "nbf" claims have similar meanings.
* X.509およびC509証明書では、有効期間は「Not After」と「Not Before」を使用して表現されます。CWTおよびCCSでは、「exp」と「nbf」のクレームが類似した意味を持っています。
The application must decide on allowing a connection or not, depending on the intended endpoint, and in particular whether it is a specific identity or in a set of identities. To prevent misbinding attacks, the identity of the endpoint is included in a MAC verified through the protocol. More details and examples are provided in this section.
アプリケーションは、意図されたエンドポイントに応じて、接続を許可するかどうかを決定する必要があり、特に特定のアイデンティティかアイデンティティのセットかどうかによってです。誤ったバインディング攻撃を防ぐために、エンドポイントのアイデンティティはプロトコルを通じて検証されたMACに含まれています。このセクションでは、詳細や例が提供されています。
Policies for what connections to allow are typically set based on the identity of the other endpoint, and endpoints typically only allow connections from a specific identity or a small restricted set of identities. For example, in the case of a device connecting to a network, the network may only allow connections from devices that authenticate with certificates having a particular range of serial numbers and signed by a particular CA. Conversely, a device may only be allowed to connect to a network that authenticates with a particular public key.
他のエンドポイントの識別に基づいて許可する接続のポリシーが通常設定され、エンドポイントは通常、特定の識別子または限られた識別子のセットからの接続のみを許可します。たとえば、デバイスがネットワークに接続する場合、ネットワークは特定のシリアル番号の証明書で認証されたデバイスからの接続のみを許可する場合があります。逆に、デバイスは特定の公開鍵で認証されたネットワークにのみ接続を許可される場合があります。
* When a Public Key Infrastructure (PKI) is used with certificates, the identity is the subject whose unique name, e.g., a domain name, a Network Access Identifier (NAI), or an Extended Unique Identifier (EUI), is included in the endpoint's certificate.
* 公開鍵基盤（PKI）が証明書と共に使用される場合、識別子はエンドポイントの証明書に含まれる、例えばドメイン名、ネットワークアクセス識別子（NAI）、または拡張ユニーク識別子（EUI）などの固有名を持つサブジェクトです。
* Similarly, when a PKI is used with CWTs, the identity is the subject identified by the relevant claim(s), such as 'sub' (subject).
* 同様に、PKIがCWTと共に使用される場合、アイデンティティは、関連するクレーム（例： 'sub'（subject））によって識別される主体です。
* When PKI is not used (e.g., CCS, self-signed certificate / CWT), the identity is typically directly associated with the authentication key of the other party. For example, if identities can be expressed in the form of unique subject names assigned to public keys, then a binding to identity is achieved by including both the public key and associated subject name in the authentication credential. CRED_I or CRED_R may be a self-signed certificate / CWT or CCS containing the authentication key and the subject name; see Section 3.5.2. Thus, each endpoint needs to know the specific authentication key / unique associated subject name or set of public authentication keys / unique associated subject names, which it is allowed to communicate with.
* PKIが使用されていない場合（例：CCS、自己署名証明書/CWT）、通常、アイデンティティは他の当事者の認証キーと直接関連付けられます。たとえば、アイデンティティが公開鍵に割り当てられた固有のサブジェクト名の形で表現できる場合、アイデンティティへのバインディングは、認証資格情報に公開鍵と関連するサブジェクト名の両方を含めることで達成されます。CRED_IまたはCRED_Rは、認証キーとサブジェクト名を含む自己署名証明書/CWTまたはCCSである可能性があります。セクション3.5.2を参照してください。したがって、各エンドポイントは、通信を許可されている特定の認証キー/固有の関連するサブジェクト名または一連の公開認証キー/固有の関連するサブジェクト名を知っている必要があります。
To prevent misbinding attacks in systems where an attacker can register public keys without proving knowledge of the private key, SIGMA [SIGMA] enforces a MAC to be calculated over the "identity". EDHOC follows SIGMA by calculating a MAC over the whole authentication credential, which in case of an X.509 or C509 certificate, includes the "subject" and "subjectAltName" fields and, in the case of CWT or CCS, includes the "sub" claim.
攻撃者が秘密鍵の知識を証明せずに公開鍵を登録できるシステムでの誤バインディング攻撃を防ぐために、SIGMAは「identity」に対してMACを計算するよう強制します。EDHOCは、X.509またはC509証明書の場合、「subject」と「subjectAltName」フィールドを含む認証資格情報全体にMACを計算することで、SIGMAに従います。CWTまたはCCSの場合、「sub」クレームを含みます。
(While the SIGMA paper only focuses on the identity, the same principle is true for other information such as policies associated with the public key.)
SIGMA論文はアイデンティティに焦点を当てていますが、同じ原則が公開鍵に関連するポリシーなどの他の情報にも当てはまります。
When a Public Key Infrastructure (PKI) is used with certificates, the trust anchor is a certification authority (CA) certificate. Each party needs at least one CA public key certificate or just the CA public key. The certification path contains proof that the subject of the certificate owns the public key in the certificate. Only validated public key certificates are to be accepted.
公開鍵基盤（PKI）が証明書と共に使用される場合、信頼のアンカーは認証局（CA）証明書です。各当事者は少なくとも1つのCA公開鍵証明書またはCA公開鍵だけが必要です。認証パスには、証明書の主体が証明書内の公開鍵を所有していることを証明する情報が含まれています。検証された公開鍵証明書のみが受け入れられるべきです。
Similarly, when a PKI is used with CWTs, each party needs to have at least one trusted third-party public key as a trust anchor to verify the end entity CWTs. The trusted third-party public key can, e.g., be stored in a self-signed CWT or in a CCS.
同様に、PKIがCWTと共に使用される場合、各当事者は少なくとも1つの信頼された第三者公開鍵を信頼アンカーとして持っている必要があり、エンドエンティティCWTを検証するために使用します。信頼された第三者公開鍵は、たとえば、自己署名CWTまたはCCSに格納されることがあります。
The signature of the authentication credential needs to be verified with the public key of the issuer. X.509 and C509 certificates includes the "Issuer" field. In CWT and CCS, the "iss" claim has a similar meaning. The public key is either a trust anchor or the public key in another valid and trusted credential in a certification path from the trust anchor to the authentication credential.
認証資格情報の署名は発行者の公開鍵で検証する必要があります。X.509およびC509証明書には「発行者」フィールドが含まれています。CWTおよびCCSでは、「iss」クレームに類似した意味があります。公開鍵は、信頼アンカーまたは認証資格情報から信頼アンカーまでの認証パス内の他の有効で信頼された資格情報の公開鍵です。
Similar verifications as made with the authentication credential (see Appendix D.1) are also needed for the other credentials in the certification path.
認証資格情報（付録D.1を参照）と同様の検証が、認証パス内の他の資格情報にも必要です。
When PKI is not used (CCS and self-signed certificate / CWT), the trust anchor is the authentication key of the other party; in which case, there is no certification path.
PKIが使用されていない場合（CCSおよび自己署名証明書/ CWT）、信頼アンカーは他の当事者の認証キーです。その場合、認証パスは存在しません。
The application may need to verify that the credentials are not revoked; see Section 9.8. Some use cases may be served by short-lived credentials, for example, where the validity of the credential is on par with the interval between revocation checks. But, in general, credential lifetime and revocation checking are complementary measures to control credential status. Revocation information may be transported as External Authorization Data (EAD); see Appendix E.
アプリケーションは、資格情報が取り消されていないことを確認する必要がある場合があります。セクション9.8を参照してください。一部のユースケースでは、短命な資格情報が利用されることがあります。たとえば、資格情報の有効期間が取り消しチェックの間隔と同等である場合です。ただし、一般的には、資格情報の有効期間と取り消しチェックは、資格情報の状態を制御する補完的な手段です。取り消し情報は、外部認可データ（EAD）として転送される場合があります。付録Eを参照してください。
EDHOC might be used without authentication by allowing the Initiator or Responder to communicate with any identity except its own. Note that EDHOC without mutual authentication is vulnerable to active on-path attacks and therefore unsafe for general use. However, it is possible to later establish a trust relationship with an unknown or not-yet-trusted endpoint. Some examples are listed below:
EDHOCは、イニシエーターまたはレスポンダーが自分自身以外の任意のアイデンティティと通信することで、認証なしで使用することができます。相互認証のないEDHOCは、アクティブな経路上攻撃に対して脆弱であり、一般的な使用には安全ではありません。ただし、後で未知のまたはまだ信頼されていないエンドポイントとの信頼関係を確立することが可能です。以下にいくつかの例を示します。
* The EDHOC authentication credential can be verified out-of-band at a later stage.
* EDHOC認証資格情報は後でオフバンドで検証できます。
* The EDHOC session key can be bound to an identity out-of-band at a later stage.
* EDHOCセッションキーは後でアウト・オブ・バンドでアイデンティティにバインドできます。
* Trust on first use (TOFU) can be used to verify that several EDHOC connections are made to the same identity. TOFU combined with proximity is a common IoT deployment model that provides good security if done correctly. Note that secure proximity based on short range wireless technology requires very low signal strength or very low latency.
* 最初の使用時に信頼（TOFU）は、複数のEDHOC接続が同じアイデンティティに行われたことを検証するために使用できます。TOFUは近接性と組み合わせることで、正しく行われれば良好なセキュリティを提供する一般的なIoT展開モデルです。安全な近接性は、短距離無線技術に基づくものであり、非常に低い信号強度または非常に低い遅延が必要です。
In order to reduce the number of messages and round trips, or to simplify processing, external security applications may be integrated into EDHOC by transporting related external authorization data (EAD) in the messages.
外部セキュリティアプリケーションを統合するために、メッセージ数やラウンドトリップを減らしたり、処理を簡素化したりするために、関連する外部認可データ（EAD）をメッセージに輸送することで、EDHOCに統合することができます。
The EAD format is specified in Section 3.8. This section contains examples and further details of how EAD may be used with an appropriate accompanying specification.
EAD形式はセクション3.8で指定されています。このセクションには、EADが適切な伴う仕様とともに使用される方法の例や詳細が含まれています。
* One example is third-party-assisted authorization, requested with EAD_1, and an authorization artifact ("voucher", cf. [RFC8366]) returned in EAD_2; see [LAKE-AUTHZ].
* 1つの例は、EAD_1でリクエストされたサードパーティ支援認証であり、EAD_2で返される認証アーティファクト（「バウチャー」、参照[RFC8366]）を参照してください。[LAKE-AUTHZ]。
* Another example is remote attestation, requested in EAD_2, and an Entity Attestation Token (EAT) [EAT] returned in EAD_3.
* 別の例は、EAD_2で要求されたリモートアテステーションであり、EAD_3で返されるエンティティアテステーショントークン（EAT）[EAT]です。
* A third example is certificate enrollment, where a Certificate Signing Request (CSR) [RFC2986] is included in EAD_3, and the issued public key certificate (X.509 [RFC5280] and C509 [C509-CERTS]) or a reference thereof is returned in EAD_4.
* 第3の例は、証明書の登録であり、証明書署名リクエスト（CSR）[RFC2986] が EAD_3 に含まれ、発行された公開鍵証明書（X.509 [RFC5280] および C509 [C509-CERTS]）またはその参照が EAD_4 に返されます。
External authorization data should be considered unprotected by EDHOC, and the protection of EAD is the responsibility of the security application (third-party authorization, remote attestation, certificate enrollment, etc.). The security properties of the EAD fields (after EDHOC processing) are discussed in Section 9.1.
外部認証データはEDHOCによって保護されていないと見なすべきであり、EADの保護はセキュリティアプリケーション（サードパーティの認証、リモートアテステーション、証明書の登録など）の責任です。EADフィールドのセキュリティプロパティ（EDHOC処理後）については、セクション9.1で議論されています。
The content of the EAD field may be used in the EDHOC processing of the message in which they are contained. For example, authentication-related information, like assertions and revocation information, transported in EAD fields may provide input about trust anchors or validity of credentials relevant to the authentication processing. The EAD fields (like ID_CRED fields) are therefore made available to the application before the message is verified; see details of message processing in Section 5. In the first example above, a voucher in EAD_2 made available to the application can enable the Initiator to verify the identity or the public key of the Responder before verifying the signature. An application allowing EAD fields containing authentication information thus may need to handle authentication-related verifications associated with EAD processing.
EAD フィールドの内容は、それらが含まれるメッセージの EDHOC 処理に使用される可能性があります。たとえば、EAD フィールドに輸送される認証関連情報（アサーションや失効情報など）は、認証処理に関連する信頼アンカーや資格情報の有効性についての入力を提供する可能性があります。したがって、EAD フィールド（ID_CRED フィールドのような）は、メッセージが検証される前にアプリケーションで利用可能になります。詳細はセクション 5 のメッセージ処理の詳細を参照してください。上記の最初の例では、EAD_2 のバウチャーがアプリケーションで利用可能になり、イニシエーターが署名を検証する前にレスポンダーの ID または公開鍵を検証できるようになります。したがって、認証情報を含む EAD フィールドを許可するアプリケーションは、EAD 処理に関連する認証関連検証を処理する必要があるかもしれません。
Conversely, the security application may need to wait for EDHOC message verification to complete. In the third example above, the validation of a CSR carried in EAD_3 is not started by the Responder before EDHOC has successfully verified message_3 and proven the possession of the private key of the Initiator.
逆に、セキュリティアプリケーションは、EDHOCメッセージの検証が完了するのを待つ必要があるかもしれません。上記の3番目の例では、EAD_3に含まれるCSRの検証は、EDHOCがmessage_3を正常に検証し、イニシエーターの秘密鍵の所有を証明する前に、レスポンダーによって開始されません。
The security application may reuse EDHOC protocol fields that therefore need to be available to the application. For example, the security application may use the same crypto algorithms as in the EDHOC session and therefore needs access to the selected cipher suite (or the whole SUITES_I). The application may use the ephemeral public keys G_X and G_Y as ephemeral keys or as nonces; see [LAKE-AUTHZ].
セキュリティアプリケーションは、そのためにアプリケーションで利用可能である必要があるEDHOCプロトコルのフィールドを再利用する可能性があります。たとえば、セキュリティアプリケーションは、EDHOCセッションで使用される暗号アルゴリズムと同じものを使用する場合があり、そのために選択された暗号スイート（または全体のSUITES_I）にアクセスする必要があります。アプリケーションは、エフェメラル公開鍵G_XおよびG_Yをエフェメラルキーまたはノンスとして使用する場合があります。
The processing of the EAD item (ead_label, ? ead_value) by the security application needs to be described in the specification where the ead_label is registered (see Section 10.5), including the optional ead_value for each message and actions in case of errors. An application may support multiple security applications that make use of EAD, which may result in multiple EAD items in one EAD field; see Section 3.8. Any dependencies on security applications with previously registered EAD items need to be documented, and the processing needs to consider their simultaneous use.
EADアイテム（ead_label、? ead_value）の処理は、ead_labelが登録されている仕様書に記載する必要があります（セクション10.5を参照）。エラーが発生した場合の各メッセージとアクションのオプションのead_valueを含める必要があります。1つのEADフィールドに複数のEADアイテムが含まれる可能性があるため、1つのアプリケーションはEADを使用する複数のセキュリティアプリケーションをサポートすることがあります（セクション3.8を参照）。以前に登録されたEADアイテムを持つセキュリティアプリケーションへの依存関係は文書化する必要があり、処理はそれらの同時利用を考慮する必要があります。
Since data carried in EAD may not be protected, or processed by the application before the EDHOC message is verified, special considerations need to be made such that it does not violate security and privacy requirements of the service that uses this data; see Section 9.5. The content in an EAD item may impact the security properties provided by EDHOC. Security applications making use of the EAD items must perform the necessary security analysis.
EADに含まれるデータは保護されない可能性があるため、EDHOCメッセージが検証される前にアプリケーションによって処理されることがないように特別な配慮が必要です。このデータを使用するサービスのセキュリティとプライバシー要件に違反しないようにする必要があります。EADアイテムの内容は、EDHOCによって提供されるセキュリティプロパティに影響を与える可能性があります。EADアイテムを使用するセキュリティアプリケーションは、必要なセキュリティ分析を実行する必要があります。
This appendix contains a rudimentary example of an application profile; see Section 3.9.
この付録には、アプリケーションプロファイルの基本的な例が含まれています。セクション3.9を参照してください。
For use of EDHOC with application X, the following assumptions are made:
EDHOCをアプリケーションXで使用する場合、以下の仮定がされます。
1. Transfer in CoAP as specified in Appendix A.2 with requests expected by the CoAP server (= Responder) at /app1-edh, no Content-Format needed.
1. CoAPの転送は、Appendix A.2で指定された方法で行われ、CoAPサーバー（＝レスポンダー）が/app1-edhで要求を受け付けることが期待されます。Content-Formatは必要ありません。
2. METHOD = 1 (I uses signature key; R uses static DH key.)
2. METHOD = 1（私は署名キーを使用します。Rは静的DHキーを使用します。）
3. CRED_I is an IEEE 802.1AR Initial Device Identifier (IDevID) encoded as a C509 certificate of type 0 [C509-CERTS].
3. CRED_Iは、タイプ0のC509証明書としてエンコードされたIEEE 802.1AR Initial Device Identifier（IDevID）です。
* R acquires CRED_I out-of-band, indicated in EAD_1.
* RはCRED_Iをアウトオブバンドで取得し、EAD_1で示されています。
* ID_CRED_I = {4: h''} is a 'kid' with the value of the empty CBOR byte string.
* ID_CRED_I = {4: h''} は、空のCBORバイト文字列の値を持つ 'kid' です。
4. CRED_R is a CCS of type OKP as specified in Section 3.5.2.
4. CRED_Rは、セクション3.5.2で指定されたOKPタイプのCCSです。
* The CBOR map has parameters 1 (kty), -1 (crv), and -2 (x-coordinate).
* CBORマップには、パラメータ1（kty）、-1（crv）、および-2（x座標）があります。
* ID_CRED_R is {14 : CCS}.
* ID_CRED_R は {14 : CCS} です。
5. External authorization data is defined and processed as specified in [LAKE-AUTHZ].
5. 外部認証データは、[LAKE-AUTHZ] で指定された方法で定義および処理されます。
6. EUI-64 is used as the identity of the endpoint (see an example in Section 3.5.2).
6. EUI-64はエンドポイントの識別子として使用されます（セクション3.5.2の例を参照）。
7. No use of message_4. The application sends protected messages from R to I.
7. メッセージ_4の使用はありません。アプリケーションはRからIへ保護されたメッセージを送信します。
By the definition of encryption of PLAINTEXT_2 with KEYSTREAM_2, it is limited to lengths of PLAINTEXT_2 not exceeding the output of EDHOC_KDF; see Section 4.1.2. If the EDHOC hash algorithm is SHA-2, then HKDF-Expand is used, which limits the length of the EDHOC_KDF output to 255 ⋅ hash_length, where hash_length is the length of the output of the EDHOC hash algorithm given by the cipher suite. For example, with SHA-256 as the EDHOC hash algorithm, the length of the hash output is 32 bytes and the maximum length of PLAINTEXT_2 is 255 ⋅ 32 = 8160 bytes.
暗号化の定義によると、KEYSTREAM_2でPLAINTEXT_2を暗号化する場合、PLAINTEXT_2の長さはEDHOC_KDFの出力を超えてはなりません。セクション4.1.2を参照してください。EDHOCハッシュアルゴリズムがSHA-2の場合、HKDF-Expandが使用され、EDHOC_KDFの出力の長さは255⋅ハッシュ長に制限されます。ここで、ハッシュ長は暗号スイートによって指定されたEDHOCハッシュアルゴリズムの出力の長さです。たとえば、EDHOCハッシュアルゴリズムとしてSHA-256を使用する場合、ハッシュ出力の長さは32バイトであり、PLAINTEXT_2の最大長は255⋅32 = 8160バイトです。
While PLAINTEXT_2 is expected to be much shorter than 8 kB for the intended use cases, it seems nevertheless prudent to specify a solution for the event that this should turn out to be a limitation.
PLAINTEXT_2が意図された使用例では8 kBよりもはるかに短いことが期待されていますが、それでも、これが制限となる可能性がある場合の解決策を指定することが賢明であるように思われます。
A potential work-around is to use a cipher suite with a different hash function. In particular, the use of KMAC removes all practical limitations in this respect.
潜在的な回避策は、異なるハッシュ関数を使用する暗号スイートを使用することです。特に、KMACの使用はこの点におけるすべての実用的な制限を取り除きます。
This section specifies a solution that works with any hash function by making use of multiple invocations of HKDF-Expand and negative values of info_label.
このセクションは、HKDF-Expandの複数の呼び出しとinfo_labelの負の値を利用して、任意のハッシュ関数と連携する解決策を指定しています。
Consider the PLAINTEXT_2 partitioned in parts P(i) of length equal to M = 255 ⋅ hash_length, except possibly the last part P(last), which has 0 < length ≤ M.
PLAINTEXT_2をM = 255 ⋅ hash_lengthと等しい長さの部分P(i)に分割することを考えます。最後の部分P(last)は長さが0 < length ≤ Mである可能性があります。
PLAINTEXT_2 = P(0) | P(1) | ... | P(last)
where "|" indicates concatenation.
ただし、「|」は結合を表します。
The object is to define a matching KEYSTREAM_2 of the same length and perform the encryption in the same way as defined in Section 5.3.2:
目的は、同じ長さの一致するKEYSTREAM_2を定義し、5.3.2節で定義された方法と同じように暗号化を行うことです。
CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2
Define the keystream as:
キーストリームを次のように定義します。
KEYSTREAM_2 = OKM(0) | OKM(1) | ... | OKM(last)
where:
ただし：
OKM(i) = EDHOC_KDF( PRK_2e, -i, TH_2, length(P(i)) )
Note that if length(PLAINTEXT_2) ≤ M, then P(0) = PLAINTEXT_2 and the definition of KEYSTREAM_2 = OKM(0) coincides with Figure 6.
PLAINTEXT_2の長さがM以下の場合、P(0) = PLAINTEXT_2 であり、KEYSTREAM_2の定義はOKM(0)と一致します。
This describes the processing of the Responder when sending message_2. The Initiator makes the same calculations when receiving message_2 but interchanging PLAINTEXT_2 and CIPHERTEXT_2.
これは、メッセージ_2を送信する際のResponderの処理を説明しています。 Initiatorは、メッセージ_2を受信する際に同じ計算を行いますが、PLAINTEXT_2とCIPHERTEXT_2を入れ替えます。
An application profile may specify if it supports or does not support the method described in this appendix.
アプリケーションプロファイルは、この付録で説明されている方法をサポートするかどうかを指定することがあります。
To provide forward secrecy in an even more efficient way than re-running EDHOC, this section specifies the optional function EDHOC_KeyUpdate in terms of EDHOC_KDF and PRK_out.
EDHOC_KeyUpdate 関数は、EDHOC_KDF と PRK_out を用いて、EDHOC を再実行するよりもさらに効率的な方法で前方秘匿性を提供します。
When EDHOC_KeyUpdate is called, a new PRK_out is calculated as the output of the EDHOC_Expand function with the old PRK_out as input. The change of PRK_out causes a change to PRK_exporter, which enables the derivation of new application keys superseding the old ones, using EDHOC_Exporter; see Section 4.2.1. The process is illustrated by the following pseudocode.
EDHOC_KeyUpdate が呼び出されると、新しい PRK_out が古い PRK_out を入力として EDHOC_Expand 関数の出力として計算されます。PRK_out の変更により PRK_exporter も変更され、EDHOC_Exporter を使用して古いアプリケーションキーを上書きする新しいアプリケーションキーの導出が可能になります。プロセスは以下の疑似コードで示されています。
EDHOC_KeyUpdate( context ):
new PRK_out = EDHOC_KDF( old PRK_out, 11, context, hash_length )
new PRK_exporter = EDHOC_KDF( new PRK_out, 10, h'', hash_length )
where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite.
選択された暗号スイートのEDHOCハッシュアルゴリズムの出力サイズ（バイト単位）を示すハッシュ長。
The EDHOC_KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the key update. The Initiator and Responder need to agree on the context, which can, e.g., be a counter, a pseudorandom number, or a hash. To provide forward secrecy, the old PRK_out and keys derived from it (old PRK_exporter and old application keys) must be deleted as soon as they are not needed. When to delete the old keys and how to verify that they are not needed is up to the application. Note that the security properties depend on the type of context and the number of KeyUpdate iterations.
EDHOC_KeyUpdateは、更新されたPRK_outをトリガーとなったイベントにバインドするために、コンテキストを入力として取ります。イニシエーターとレスポンダーは、例えばカウンター、疑似乱数、またはハッシュなどのコンテキストに合意する必要があります。将来の秘匿性を提供するために、古いPRK_outおよびそれから派生したキー（古いPRK_exporterおよび古いアプリケーションキー）は、必要なくなったらすぐに削除されなければなりません。古いキーをいつ削除するか、それらが不要であることをどのように検証するかは、アプリケーションによって決定されます。セキュリティの特性は、コンテキストの種類とKeyUpdateの反復回数に依存します。
An application using EDHOC_KeyUpdate needs to store PRK_out. Compromise of PRK_out leads to compromise of all keying material derived with the EDHOC_Exporter since the last invocation of the EDHOC_KeyUpdate function.
EDHOC_KeyUpdateを使用するアプリケーションは、PRK_outを保存する必要があります。PRK_outの妥協は、EDHOC_KeyUpdate関数の最後の呼び出し以降に派生したすべての鍵素材の妥協につながります。
While this key update method provides forward secrecy, it does not give as strong security properties as re-running EDHOC. EDHOC_KeyUpdate can be used to meet cryptographic limits and provide partial protection against key leakage, but it provides significantly weaker security properties than re-running EDHOC with ephemeral Diffie-Hellman. Even with frequent use of EDHOC_KeyUpdate, compromise of one session key compromises all future session keys, and an attacker therefore only needs to perform static key exfiltration [RFC7624], which is less complicated and has a lower risk profile than the dynamic case; see Section 9.1.
このキー更新方法は前方秘匿性を提供しますが、EDHOCを再実行するほど強力なセキュリティプロパティを提供しません。EDHOC_KeyUpdateは暗号的な制限を満たし、鍵漏洩に対する部分的な保護を提供するために使用できますが、一時的なDiffie-Hellmanを使用してEDHOCを再実行するよりも、はるかに弱いセキュリティプロパティを提供します。EDHOC_KeyUpdateを頻繁に使用しても、1つのセッションキーが妥協されると、すべての将来のセッションキーが妥協され、攻撃者は静的な鍵の外部流出[RFC7624]を実行する必要があります。これは、動的なケースよりも複雑さが低く、リスクプロファイルが低いためです。セクション9.1を参照してください。
A similar method to do a key update for OSCORE is KUDOS; see [KUDOS].
OSCOREのキー更新を行うための類似した方法はKUDOSです。[KUDOS]を参照してください。
This appendix describes an example protocol state machine for the Initiator and Responder. States are denoted in all capitals, and parentheses denote actions taken only in some circumstances.
この付録は、イニシエーターとレスポンダーのためのプロトコル状態機械の例を説明しています。状態はすべて大文字で示され、かっこ内は特定の状況でのみ実行されるアクションを示します。
Note that this state machine is just an example, and that details of processing are omitted. For example:
このステートマシンは単なる例であり、処理の詳細は省略されています。例えば：
* when error messages are being sent (with one exception);
* エラーメッセージが送信されているとき（1つの例外を除いて）;
* how credentials and EAD are processed by EDHOC and the application in the RCVD state; and
* EDHOCとアプリケーションがRCVD状態で資格情報とEADを処理する方法；そして
* what verifications are made, which includes not only MACs and signatures.
* どの検証が行われるか、MACや署名だけでなく含まれます。
The Initiator sends message_1, triggering the state machine to transition from START to WAIT_M2, and waits for message_2.
イニシエーターはメッセージ1を送信し、ステートマシンをSTARTからWAIT_M2に遷移させ、メッセージ2を待ちます。
If the incoming message is an error message, then the Initiator transitions from WAIT_M2 to ABORTED. In case of error code 2 (Wrong Selected Cipher Suite), the Initiator remembers the supported cipher suites for this particular Responder and transitions from ABORTED to START. The message_1 that the Initiator subsequently sends takes into account the cipher suites supported by the Responder.
もし着信メッセージがエラーメッセージである場合、イニシエーターはWAIT_M2からABORTEDに遷移します。エラーコード2（誤った選択された暗号スイート）の場合、イニシエーターはこの特定のレスポンダーのサポートされている暗号スイートを記憶し、ABORTEDからSTARTに遷移します。その後にイニシエーターが送信するmessage_1は、レスポンダーがサポートする暗号スイートを考慮に入れます。
Upon receiving a non-error message, the Initiator transitions from WAIT_M2 to RCVD_M2 and processes the message. If a processing error occurs on message_2, then the Initiator transitions from RCVD_M2 to ABORTED. In case of successful processing of message_2, the Initiator transitions from RCVD_M2 to VRFD_M2.
受信したエラーメッセージ以外の場合、イニシエータはWAIT_M2からRCVD_M2に移行し、メッセージを処理します。メッセージ2の処理中にエラーが発生した場合、イニシエータはRCVD_M2からABORTEDに移行します。メッセージ2の処理が成功した場合、イニシエータはRCVD_M2からVRFD_M2に移行します。
The Initiator prepares and processes message_3 for sending. If any processing error is encountered, the Initiator transitions from VRFD_M2 to ABORTED. If message_3 is successfully sent, the Initiator transitions from VRFD_M2 to COMPLETED.
イニシエーターは、送信のためにメッセージ_3を準備し処理します。処理中にエラーが発生した場合、イニシエーターはVRFD_M2からABORTEDに遷移します。メッセージ_3が正常に送信された場合、イニシエーターはVRFD_M2からCOMPLETEDに遷移します。
If the application profile includes message_4, then the Initiator waits for message_4. If the incoming message is an error message, then the Initiator transitions from COMPLETED to ABORTED. Upon receiving a non-error message, the Initiator transitions from COMPLETED (="WAIT_M4") to RCVD_M4 and processes the message. If a processing error occurs on message_4, then the Initiator transitions from RCVD_M4 to ABORTED. In case of successful processing of message_4, the Initiator transitions from RCVD_M4 to PERSISTED (="VRFD_M4").
もしアプリケーションプロファイルにmessage_4が含まれている場合、イニシエータはmessage_4を待ちます。 もし着信メッセージがエラーメッセージである場合、イニシエータはCOMPLETEDからABORTEDに遷移します。 エラーでないメッセージを受信した場合、イニシエータはCOMPLETED（="WAIT_M4"）からRCVD_M4に遷移し、メッセージを処理します。 message_4の処理中にエラーが発生した場合、イニシエータはRCVD_M4からABORTEDに遷移します。 message_4の処理が成功した場合、イニシエータはRCVD_M4からPERSISTED（="VRFD_M4"）に遷移します。
If the application profile does not include message_4, then the Initiator waits for an incoming application message. If the decryption and verification of the application message is successful, then the Initiator transitions from COMPLETED to PERSISTED.
アプリケーションプロファイルにmessage_4が含まれていない場合、イニシエーターは着信アプリケーションメッセージを待機します。アプリケーションメッセージの復号化と検証が成功した場合、イニシエーターはCOMPLETEDからPERSISTEDに遷移します。
+- - - - - - - - - -> START
| |
| Send message_1
| |
Receive error v
ABORTED <---------------- WAIT_M2
^ |
| | Receive message_2
| |
| Processing error v
+-------------------- RCVD_M2
^ |
| | Verify message_2
| |
| Processing error v
+-------------------- VRFD_M2
^ |
| | Send message_3
| |
| (Receive error) v
+-------------------- COMPLETED ----------------+
^ | |
| | (Receive message_4) |
| | |
| (Processing error) v | (Verify
+------------------- (RCVD_M4) | application
| | message)
| (Verify message_4) |
| |
v |
PERSISTED <---------------+
Figure 12: Initiator State Machine
図12：イニシエータ状態機械
Upon receiving message_1, the Responder transitions from START to RCVD_M1.
メッセージ1を受信すると、レスポンダーはSTARTからRCVD_M1に移行します。
If a processing error occurs on message_1, the Responder transitions from RCVD_M1 to ABORTED. This includes sending an error message with error code 2 (Wrong Selected Cipher Suite) if the selected cipher suite in message_1 is not supported. In case of successful processing of message_1, the Responder transitions from RCVD_M1 to VRFD_M1.
もしmessage_1で処理エラーが発生した場合、ResponderはRCVD_M1からABORTEDに遷移します。これには、message_1で選択された暗号スイートがサポートされていない場合、エラーコード2（Wrong Selected Cipher Suite）を含むエラーメッセージを送信することが含まれます。message_1の処理が成功した場合、ResponderはRCVD_M1からVRFD_M1に遷移します。
The Responder prepares and processes message_2 for sending. If any processing error is encountered, the Responder transitions from VRFD_M1 to ABORTED. If message_2 is successfully sent, the Initiator transitions from VRFD_M2 to WAIT_M3 and waits for message_3.
レスポンダーは、メッセージ_2を送信するために準備し、処理します。処理中にエラーが発生した場合、レスポンダーはVRFD_M1からABORTEDに遷移します。メッセージ_2が正常に送信された場合、イニシエーターはVRFD_M2からWAIT_M3に遷移し、メッセージ_3を待機します。
If the incoming message is an error message, then the Responder transitions from WAIT_M3 to ABORTED.
もし受信メッセージがエラーメッセージである場合、Responder は WAIT_M3 から ABORTED に遷移します。
Upon receiving message_3, the Responder transitions from WAIT_M3 to RCVD_M3. If a processing error occurs on message_3, the Responder transitions from RCVD_M3 to ABORTED. In case of successful processing of message_3, the Responder transitions from RCVD_M3 to COMPLETED (="VRFD_M3").
message_3を受信した場合、ResponderはWAIT_M3からRCVD_M3に移行します。message_3で処理エラーが発生した場合、ResponderはRCVD_M3からABORTEDに移行します。message_3の処理が成功した場合、ResponderはRCVD_M3からCOMPLETED（="VRFD_M3"）に移行します。
If the application profile includes message_4, the Responder prepares and processes message_4 for sending. If any processing error is encountered, the Responder transitions from COMPLETED to ABORTED.
アプリケーションプロファイルにmessage_4が含まれている場合、レスポンダは送信のためにmessage_4を準備し処理します。処理中にエラーが発生した場合、レスポンダはCOMPLETEDからABORTEDに遷移します。
If message_4 is successfully sent, or if the application profile does not include message_4, the Responder transitions from COMPLETED to PERSISTED.
もしmessage_4が正常に送信された場合、またはアプリケーションプロファイルにmessage_4が含まれていない場合、ResponderはCOMPLETEDからPERSISTEDに遷移します。
START
|
| Receive message_1
|
Processing error v
ABORTED <---------------- RCVD_M1
^ |
| | Verify message_1
| |
| Processing error v
+-------------------- VRFD_M1
^ |
| | Send message_2
| |
| Receive error v
+-------------------- WAIT_M3
^ |
| | Receive message_3
| |
| Processing error v
+-------------------- RCVD_M3
^ |
| | Verify message_3
| |
| (Processing error) v
+------------------- COMPLETED
|
| (Send message_4)
|
v
PERSISTED
Figure 13: Responder State Machine
図13: レスポンダーの状態機械
The authors want to thank Christian Amsüss, Karthikeyan Bhargavan, Carsten Bormann, Alessandro Bruni, Timothy Claeys, Baptiste Cottier, Roman Danyliw, Martin Disch, Martin Duke, Donald Eastlake 3rd, Lars Eggert, Stephen Farrell, Loïc Ferreira, Theis Grønbech Petersen, Felix Günther, Dan Harkins, Klaus Hartke, Russ Housley, Stefan Hristozov, Marc Ilunga, Charlie Jacomme, Elise Klein, Erik Kline, Steve Kremer, Alexandros Krontiris, Ilari Liusvaara, Rafa Marín-López, Kathleen Moriarty, David Navarro, Karl Norrman, Salvador Pérez, Radia Perlman, David Pointcheval, Maïwenn Racouchot, Eric Rescorla, Michael Richardson, Thorvald Sahl Jørgensen, Zaheduzzaman Sarker, Jim Schaad, Michael Scharf, Carsten Schürmann, John Scudder, Ludwig Seitz, Brian Sipos, Stanislav Smyshlyaev, Valery Smyslov, Peter van der Stok, Rene Struik, Vaishnavi Sundararajan, Erik Thormarker, Marco Tiloca, Sean Turner, Michel Veillette, Mališa Vučinić, Paul Wouters, and Lei Yan for reviewing and commenting on intermediate draft versions of this document.
著者たちは、この文書の中間ドラフトバージョンをレビューしコメントしてくれたChristian Amsüss、Karthikeyan Bhargavan、Carsten Bormann、Alessandro Bruni、Timothy Claeys、Baptiste Cottier、Roman Danyliw、Martin Disch、Martin Duke、Donald Eastlake 3rd、Lars Eggert、Stephen Farrell、Loïc Ferreira、Theis Grønbech Petersen、Felix Günther、Dan Harkins、Klaus Hartke、Russ Housley、Stefan Hristozov、Marc Ilunga、Charlie Jacomme、Elise Klein、Erik Kline、Steve Kremer、Alexandros Krontiris、Ilari Liusvaara、Rafa Marín-López、Kathleen Moriarty、David Navarro、Karl Norrman、Salvador Pérez、Radia Perlman、David Pointcheval、Maïwenn Racouchot、Eric Rescorla、Michael Richardson、Thorvald Sahl Jørgensen、Zaheduzzaman Sarker、Jim Schaad、Michael Scharf、Carsten Schürmann、John Scudder、Ludwig Seitz、Brian Sipos、Stanislav Smyshlyaev、Valery Smyslov、Peter van der Stok、Rene Struik、Vaishnavi Sundararajan、Erik Thormarker、Marco Tiloca、Sean Turner、Michel Veillette、Mališa Vučinić、Paul Wouters、Lei Yanに感謝します。
We are especially indebted to the late Jim Schaad for his continuous review and implementation of draft versions of this document, as well as his work on other technologies such as COSE and OSCORE without which EDHOC would not have been.
私たちは、特に故ジム・シャード氏に、この文書の草案バージョンの継続的なレビューや実装、およびCOSEやOSCOREなどの他の技術に関する彼の業績に深く感謝しています。彼なしでは、EDHOCは存在しなかったでしょう。
Work on this document has in part been supported by the H2020 project SIFIS-Home (grant agreement 952652).
この文書の作業は一部、H2020プロジェクトSIFIS-Home（補助金契約952652）によって支援されています。
Göran Selander
Ericsson AB
SE-164 80 Stockholm
Sweden
Email: goran.selander@ericsson.com
John Preuß Mattsson
Ericsson AB
SE-164 80 Stockholm
Sweden
Email: john.mattsson@ericsson.com
Francesca Palombini
Ericsson AB
SE-164 80 Stockholm
Sweden
Email: francesca.palombini@ericsson.com