Internet Engineering Task Force (IETF) R. Marin-Lopez
Request for Comments: 9820 University of Murcia
Category: Standards Track D. Garcia-Carrillo
ISSN: 2070-1721 University of Oviedo
September 2025
This document specifies an authentication service that uses the Constrained Application Protocol (CoAP) as a transport method to carry the Extensible Authentication Protocol (EAP). As such, it defines an EAP lower layer based on CoAP called "CoAP-EAP". One of the main goals is to authenticate a CoAP-enabled Internet of Things (IoT) device (EAP peer) that intends to join a security domain managed by a Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constrained RESTful Environments (OSCORE), enabling the establishment of a security association between them.
このドキュメントは、拡張可能な認証プロトコル（EAP）を運ぶための輸送方法として制約付きアプリケーションプロトコル（COAP）を使用する認証サービスを指定します。そのため、「coap-eap」と呼ばれるCoAPに基づいたEAP下層層を定義します。主な目標の1つは、コントローラー（EAP Authenticator）が管理するセキュリティドメインに参加する予定のCoAP対応のインターネット（IOT）デバイス（EAPピア）を認証することです。第二に、拘束された安らかな環境のオブジェクトセキュリティ（OSCORE）に基づいて交換された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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc9820.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9820で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. General Architecture
3. CoAP-EAP Operation
3.1. Discovery
3.2. Flow of Operation (OSCORE Establishment)
3.3. Re-Authentication
3.4. Managing the State of the Service
3.5. Error Handling
3.5.1. EAP Authentication Failure
3.5.2. Non-Responsive Endpoint
3.5.3. Duplicated Message with /.well-known/coap-eap
3.6. Proxy Operation in CoAP-EAP
4. CoAP-EAP Media Type Format
5. CBOR Objects in CoAP-EAP
6. Cipher Suite Negotiation and Key Derivation
6.1. Cipher Suite Negotiation
6.2. Deriving the OSCORE Security Context
7. Discussion
7.1. CoAP as the EAP Lower Layer
7.2. Size of the EAP Lower Layer vs. EAP Method Size
8. Security Considerations
8.1. Use of EAP Methods
8.2. Authorization
8.3. Allowing CoAP-EAP Traffic to Perform Authentication
8.4. Freshness of the Key Material
8.5. Channel-Binding Support
8.6. Additional Security Considerations
9. IANA Considerations
9.1. CoAP-EAP Cipher Suites
9.2. CDDL in CoAP-EAP Information Elements
9.3. The Well-Known URIs Registry
9.4. The EAP Lower Layers Registry
9.5. Media Types Registry
9.6. CoAP Content-Formats Registry
9.7. Resource Type (rt=) Link Target Attribute Values Registry
9.8. Expert Review Instructions
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Flow of Operation (DTLS Establishment)
A.1. Deriving DTLS_PSK and Identity
Appendix B. Using CoAP-EAP for Distributing Key Material for IoT
Networks
Appendix C. Example Use Case Scenarios
C.1. Example 1: CoAP-EAP Using ACE
C.2. Example 2: Multiple Domains with AAA Infrastructures
C.3. Example 3: Single Domain with a AAA Infrastructure
C.4. Example 4: Single Domain Without a AAA Infrastructure
C.5. Other Use Cases
C.5.1. CoAP-EAP for Network Access Authentication
C.5.2. CoAP-EAP for Service Authentication
Acknowledgments
Authors' Addresses
This document specifies an authentication service (application) that uses the Extensible Authentication Protocol (EAP) [RFC3748] and is built on top of the Constrained Application Protocol (CoAP) [RFC7252]; it is called "CoAP-EAP". CoAP-EAP is an application that allows authenticating two CoAP endpoints by using EAP and establishing an Object Security for Constrained RESTful Environments (OSCORE) security association between them. More specifically, this document specifies how CoAP can be used as a constrained, link-layer-independent, reliable EAP lower layer [RFC3748] to transport EAP messages between a CoAP server (acting as an EAP peer) and a CoAP client (acting as an EAP authenticator) using CoAP messages. The CoAP client has the option of contacting a backend Authentication, Authorization, and Accounting (AAA) infrastructure to complete the EAP negotiation, as described in the EAP specification [RFC3748].
このドキュメントは、拡張可能な認証プロトコル（EAP）[RFC3748]を使用し、制約付きアプリケーションプロトコル（COAP）[RFC7252]の上に構築される認証サービス（アプリケーション）を指定します。「coap-eap」と呼ばれます。COAP-EAPは、EAPを使用して、それらの間の制約されたRESTFUL環境（OSCORE）セキュリティ関連のオブジェクトセキュリティを確立することにより、2つのCOAPエンドポイントを認証できるアプリケーションです。より具体的には、このドキュメントは、COAPがCOAPサーバー（EAPピアとして機能する）とCOAPメッセージを使用してCOAPクライアント（EAP認証器として機能する）間でEAPメッセージを輸送するために、COAPを制約されたリンクレイヤーに依存しない、信頼性の高いEAP下層[RFC3748]として使用する方法を指定します。COAPクライアントには、EAP仕様[RFC3748]で説明されているように、EAP交渉を完了するために、バックエンド認証、承認、および会計（AAA）インフラストラクチャに連絡するオプションがあります。
In the case of this specification, the EAP methods that can be transported with CoAP-EAP MUST export cryptographic material [RFC5247]. Examples of such methods are the EAP Generalized Pre-Shared Key (EAP-GPSK) [RFC5433], the EAP Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) [RFC4186], the EAP Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') [RFC5448], EAP-TLS 1.3 [RFC9190], EAP with Ephemeral Diffie-Hellman over CBOR Object Signing and Encryption (EAP-EDHOC) [EAP-EDHOC], etc. ("CBOR" stands for "Concise Binary Object Representation".) In general, any EAP method designed in the EAP Method Update (EMU) Working Group that exports the Master Session Key (MSK) can be used with CoAP-EAP. The MSK is used as the basis for further cryptographic derivations. This way, CoAP messages are protected after authentication. After the CoAP-EAP operation, an OSCORE security association is established between the endpoints of the service. Using the keying material from the authentication, other security associations could be generated. Appendix A shows how to establish a (D)TLS security association using the keying material from the EAP authentication.
この仕様の場合、COAP-EAPで輸送できるEAPメソッドは暗号化材料[RFC5247]をエクスポートする必要があります。このような方法の例は、EAP一般化された事前共有キー（EAP-GPSK）[RFC5433]、モバイルコミュニケーション（GSM）サブスクライバーアイデンティティモジュール（EAP-SIM）[RFC4186]のグローバルシステムのEAPメソッド、第3世代認証および主要契約のEAPメソッド[RFC548]、EAP-TLS 1.3[RFC9190]、CBORオブジェクトの署名と暗号化（EAP-EDHOC）[EAP-EDHOC]などを介したEAPとのEAP（「CBOR」は「簡潔なバイナリオブジェクト表現」を表しています。）MSKは、さらなる暗号化導出の基礎として使用されます。このようにして、COAPメッセージは認証後に保護されます。COAP-EAP操作の後、オスコアセキュリティ協会がサービスのエンドポイント間に確立されます。認証からキーイング材料を使用して、他のセキュリティ協会を生成できます。付録Aは、EAP認証のキーイング資料を使用して（d）TLSセキュリティ協会を確立する方法を示しています。
One of the main applications of CoAP-EAP involves Internet of Things (IoT) networks, where we can find very constrained links (e.g., limited bandwidth) and devices with limited capabilities. In these IoT scenarios, we identify the IoT device as the entity that wants to be authenticated by using EAP to join a domain that is managed by a Controller. In these cases, the IoT device is the EAP peer and the Controller is the entity steering the authentication (i.e., the EAP authenticator); from now on, the IoT device will be referred to as the EAP peer and the Controller will be referred to as the EAP authenticator. In these cases, EAP methods with fewer exchanges, shorter messages, and cryptographic algorithms suitable for constrained devices are preferable. The benefits of the EAP framework in IoT networks are highlighted in [EAP-Framework-IoT].
COAP-EAPの主なアプリケーションの1つには、モノのインターネット（IoT）ネットワークが含まれます。このネットワークでは、非常に制約されたリンク（帯域幅が限られているなど）と、機能が限られているデバイスを見つけることができます。これらのIoTシナリオでは、IoTデバイスを、EAPを使用してコントローラーによって管理されるドメインを結合することにより、認証されたいエンティティとして識別します。これらの場合、IoTデバイスはEAPピアであり、コントローラーはエンティティが認証をステアリングします（つまり、EAP認証器）。これからは、IoTデバイスはEAPピアと呼ばれ、コントローラーはEAP認証器と呼ばれます。これらの場合、制約されたデバイスに適した交換、より短いメッセージ、暗号化アルゴリズムを備えたEAPメソッドが望ましいです。IoTネットワークにおけるEAPフレームワークの利点は、[EAPフレームワークイオット]で強調されています。
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 CoAP [RFC7252], EAP [RFC3748] [RFC5247], and OSCORE [RFC8613].
読者は、COAP [RFC7252]、EAP [RFC3748] [RFC5247]、およびOSCORE [RFC8613]に記載されている用語と概念に精通していることが期待されています。
Figure 1 illustrates the architecture defined in this document. In this architecture, the EAP peer will act as a CoAP server for this service and the domain EAP authenticator will act as a CoAP client. The rationale behind this decision is that EAP Requests will always travel from the EAP server to the EAP peer. Accordingly, EAP Responses will always travel from the EAP peer to the EAP server.
図1は、このドキュメントで定義されているアーキテクチャを示しています。このアーキテクチャでは、EAPピアはこのサービスのCOAPサーバーとして機能し、ドメインEAP認証者はCOAPクライアントとして機能します。この決定の背後にある理論的根拠は、EAP要求が常にEAPサーバーからEAPピアに移動することです。したがって、EAP応答は常にEAPピアからEAPサーバーに移動します。
It is worth noting that the EAP authenticator MAY interact with a backend AAA infrastructure when EAP pass-through mode is used, which will place the EAP server in the AAA server that contains the information required to authenticate the EAP peer.
EAPパススルーモードが使用されると、EAP認証器がバックエンドAAAインフラストラクチャと対話し、EAPピアを認証するために必要な情報を含むAAAサーバーにEAPサーバーを配置する可能性があることは注目に値します。
The protocol stack is described in Figure 2. CoAP-EAP is an application built on top of CoAP. On top of the application, there is an EAP state machine that can run any EAP method. In the case of this specification, the EAP method MUST support key derivation and export as specified in [RFC5247]: an MSK of at least 64 octets and an Extended Master Session Key (EMSK) of at least 64 octets. CoAP-EAP also relies on CoAP reliability mechanisms to transport EAP: CoAP over UDP with Confirmable messages [RFC7252] or CoAP over TCP, TLS, or WebSockets [RFC8323].
プロトコルスタックについては、図2に説明します。Coap-Eapは、COAPの上に構築されたアプリケーションです。アプリケーションに加えて、EAPメソッドを実行できるEAP状態マシンがあります。この仕様の場合、EAPメソッドは[RFC5247]で指定されているキーの派生とエクスポートをサポートする必要があります。COAP-EAPは、COAP信頼性メカニズムにも依存して、EAP：COAPをCOAPで確認可能なメッセージ[RFC7252]またはCOAPでTCP、TLS、またはWebSockets [RFC8323]で輸送します。
+--------+ +--------------+ +----------+
| EAP | | EAP | | AAA/ |
| peer |<------>| authenticator|<----------->|EAP server|
+--------+ CoAP +--------------+ AAA +----------+
(optional)
<---- SCOPE OF THIS DOCUMENT ---->
Figure 1: CoAP-EAP Architecture
図1：Coap-Eapアーキテクチャ
+-----------------------------------+
| EAP State Machine |
+-----------------------------------+
| Application (CoAP-EAP) | <-- This Document
+-----------------------------------+
| Requests / Responses / Signaling | RFC 7252 / RFC 8323
+-----------------------------------+
| Message / Message Framing | RFC 7252 / RFC 8323
+-----------------------------------+
| Unreliable / Reliable Transport | RFC 7252 / RFC 8323
+-----------------------------------+
Figure 2: CoAP-EAP Stack
図2：coap-eapスタック
Because CoAP-EAP uses reliable delivery as defined in CoAP [RFC7252] [RFC8323], EAP retransmission time is set to an infinite value, as mentioned in [RFC3748]. To maintain ordering guarantees, CoAP-EAP uses Hypermedia as the Engine of Application State (HATEOAS). Each step during the EAP authentication accesses a new resource in the CoAP server (EAP peer). The previous resource is removed once the new resource is created, indicating the resource that will process the next step of the EAP authentication.
COAP-Eapは、COAP [RFC7252] [RFC8323]で定義されているように信頼できる配信を使用するため、[RFC3748]で述べたように、EAPの再送信時間は無限の値に設定されます。注文保証を維持するために、Coap-Eapはアプリケーション状態（Hateoas）のエンジンとしてHyperMediaを使用します。EAP認証中の各ステップは、COAPサーバー（EAPピア）の新しいリソースにアクセスします。以前のリソースは、新しいリソースが作成されると削除され、EAP認証の次のステップを処理するリソースを示します。
One of the benefits of using EAP is that we can choose from a large variety of authentication methods.
EAPを使用する利点の1つは、多種多様な認証方法から選択できることです。
In CoAP-EAP, the EAP peer will only have one authentication session with a specific EAP authenticator, and it will not process any other EAP authentication in parallel (with the same EAP authenticator). That is, a single ongoing EAP authentication is permitted for the same EAP peer and the same EAP authenticator. It may be worth noting that the EAP authenticator may have parallel EAP sessions with multiple EAP peers.
COAP-EAPでは、EAPピアは特定のEAP認証器を使用して1つの認証セッションのみを持ち、他のEAP認証を並行して処理しません（同じEAP認証器を使用）。つまり、同じEAPピアと同じEAP Authenticatorに対して、単一の進行中のEAP認証が許可されています。EAP認証器が複数のEAPピアと並行してEAPセッションを持っている可能性があることは注目に値するかもしれません。
To access the authentication service, this document defines the well-known URI "coap-eap" (see Section 9.3). The /.well-known/coap-eap URI is used with "coap", "coap+tcp", or "coap+ws".
認証サービスにアクセスするために、このドキュメントはよく知られているURI「Coap-eap」を定義します（セクション9.3を参照）。/.well-known/coap-uriは、「coap」、「coap+tcp」、または「coap+ws」で使用されます。
Before the CoAP-EAP exchange takes place, the EAP peer needs to discover the EAP authenticator or the entity that will enable the CoAP-EAP exchange (i.e., an intermediary). The discovery process is outside the scope of this document.
COAP-EAP交換が行われる前に、EAPピアは、COAP-EAP Exchange（つまり、仲介者）を可能にするEAP認証器またはエンティティを発見する必要があります。発見プロセスは、このドキュメントの範囲外です。
The CoAP-EAP application can be accessed through the URI "coap-eap" for the trigger message (see Section 3.2, Step 0). The CoAP-EAP service can be discovered by asking directly about the services offered. This information can also be available in the resource directory [RFC9176].
COAP-EAPアプリケーションは、トリガーメッセージのURI「COAP-EAP」を介してアクセスできます（セクション3.2、ステップ0を参照）。COAP-EAPサービスは、提供されるサービスについて直接尋ねることで発見できます。この情報は、リソースディレクトリ[RFC9176]でも入手できます。
Implementation notes: There are different methods for discovering the IPv6 address of the EAP authenticator or intermediary entity. For example, in a 6LoWPAN network, the Border Router will typically act as the EAP authenticator. Hence, after receiving the Router Advertisement (RA) messages from the Border Router, the EAP peer may engage in the CoAP-EAP exchange.
実装メモ：EAP認証器または仲介エンティティのIPv6アドレスを発見するには、さまざまな方法があります。たとえば、6lowpanネットワークでは、境界線ルーターは通常、EAP認証器として機能します。したがって、Border Routerからルーター広告（RA）メッセージを受信した後、EAPピアはCOAP-EAP Exchangeに参加する場合があります。
Figure 3 shows the general flow of operation for CoAP-EAP to authenticate using EAP and establish an OSCORE Security Context. The flow does not show a specific EAP method. Instead, the chosen EAP method is represented by using a generic name (EAP-X). The flow assumes that the EAP peer knows the EAP authenticator implements the CoAP-EAP service. A CoAP-EAP message has the media type "application/coap-eap". See Section 9.5.
図3は、EAPを使用して認証し、OSCOREセキュリティコンテキストを確立するためのCOAP-EAPの操作の一般的な流れを示しています。フローには、特定のEAPメソッドが表示されません。代わりに、選択されたEAPメソッドは、汎用名（EAP-X）を使用して表されます。このフローは、EAPピアがEAP認証器がCOAP-EAPサービスを実装することを知っていることを前提としています。Coap-eapメッセージには、メディアタイプ「Application/Coap-Eap」があります。セクション9.5を参照してください。
The steps for this flow of operation are as follows:
この操作の流れの手順は次のとおりです。
* Step 0. The EAP peer MUST start the CoAP-EAP process by sending a "POST /.well-known/coap-eap" request (trigger message). This message carries the 'No-Response' CoAP option [RFC7967] to avoid waiting for a response that is not needed. This is the only message where the EAP authenticator acts as a CoAP server and the EAP peer acts as a CoAP client. The message also includes a URI in the payload of the message to indicate the resource where the EAP authenticator MUST send the next message. The name of the resource is selected by the CoAP server.
* ステップ0。EAPピアは、「post /.well-known /coap-eap-」要求（トリガーメッセージ）を送信して、Coap-eapプロセスを開始する必要があります。このメッセージには、必要のない応答を待たないように、「応答なし」COAPオプション[RFC7967]を伝えます。これは、EAP認証器がCOAPサーバーとして機能し、EAPピアがCOAPクライアントとして機能する唯一のメッセージです。メッセージには、EAP認証器が次のメッセージを送信する必要があるリソースを示すために、メッセージのペイロードにURIが含まれています。リソースの名前は、COAPサーバーによって選択されます。
Implementation notes: When generating the URI for a resource during a step of the authentication, the resource could have the following format as an example "path/eap/counter", where:
実装注：認証のステップ中にリソースのURIを生成する場合、リソースは「PATH/EAP/カウンター」の例として次の形式を持つことができます。
* "path" is some local path on the device to make the path unique. This could be omitted if desired.
* 「パス」は、パスをユニークにするためのデバイス上のローカルパスです。これは、必要に応じて省略できます。
* "eap" is the name that indicates that the URI is for the EAP peer. This has no meaning for the protocol but helps with debugging.
* 「EAP」は、URIがEAPピア用であることを示す名前です。これはプロトコルには意味がありませんが、デバッグに役立ちます。
* "counter" is an incrementing unique number for every new EAP Request.
* 「カウンター」は、新しいEAP要求ごとに一意の数字を増やすことです。
So, per Figure 3, the URI for the first resource would be "/a/eap/1".
したがって、図3によると、最初のリソースのURIは「/a/eap/1」です。
* Step 1. The EAP authenticator sends a POST message to the resource indicated in Step 0 (e.g., "/a/eap/1"). The payload in this message contains the first EAP message (EAP-Request/Identity, or EAP-Req/Id) and the Recipient ID of the EAP authenticator (RID-C) for OSCORE, and MAY contain a CBOR array with a list of proposed cipher suites (CS-C) for OSCORE. If the cipher suite list is not included, the default cipher suite for OSCORE is used. The details of the cipher suite negotiation are discussed in Section 6.1.
* ステップ1。EAP認証器は、ステップ0に示されているリソースに投稿メッセージを送信します（例： "/a/eap/1"）。このメッセージのペイロードには、最初のEAPメッセージ（EAP-Request/ID、またはEAP-REQ/ID）とOSCORE用のEAP認証器（RID-C）の受信者IDが含まれており、OSCORE用の提案されたCipherスイート（CS-C）のリストを含むCBORアレイが含まれている場合があります。暗号スイートリストが含まれていない場合、OSCOREのデフォルトの暗号スイートが使用されます。暗号スイートの交渉の詳細については、セクション6.1で説明します。
* Step 2. The EAP peer processes the POST message sending the EAP Request (EAP-Req/Id) to the EAP peer state machine, which returns an EAP Response (EAP-Response/Identity, or EAP-Resp/Id). Then, the CoAP-EAP application assigns a new resource to the ongoing authentication process (e.g., "/a/eap/2") and deletes the previous one ("/a/eap/1"). Finally, the CoAP-EAP application sends a '2.01 Created' response with the new resource identifier in the Location-Path (and/or Location-Query) Options for the next step. The EAP Response, the Recipient ID of the EAP peer (RID-I), and the selected cipher suite for OSCORE (CS-I) are included in the payload. In this step, the EAP peer may create an OSCORE Security Context (see Section 6.2). The required MSK will be available once the EAP authentication is successful (Step 7).
* ステップ2。EAPピアは、EAPリクエスト（EAP-REQ/ID）をEAPピアステートマシンに送信する投稿メッセージを処理します。EAP応答（EAP応答/ID、またはEAP-Resp/ID）を返します。次に、COAP-EAPアプリケーションは、新しいリソースを進行中の認証プロセス（ "/a/eap/2"など）に割り当て、前のリソース（ "/a/eap/1"）を削除します。最後に、COAP-EAPアプリケーションは、次のステップのロケーションパス（および/またはロケーションクエリ）オプションの新しいリソース識別子を使用して「2.01作成」応答を送信します。EAP応答、EAPピア（RID-I）の受信者ID、およびオスコア用の選択された暗号スイート（CS-I）がペイロードに含まれています。このステップでは、EAPピアがオスコアセキュリティコンテキストを作成する場合があります（セクション6.2を参照）。EAP認証が成功すると、必要なMSKが利用可能になります（ステップ7）。
* Steps 3-6. From now on, the EAP authenticator and the EAP peer will exchange EAP packets related to the EAP method (EAP-X), transported in the CoAP message payload. The EAP authenticator will use the POST method to send EAP Requests to the EAP peer. The EAP peer will use a CoAP response to carry the EAP Response in the payload. EAP Requests and responses are represented in Figure 3 using the nomenclature "EAP-X-Req" and "EAP-X-Resp", respectively. When a POST message arrives (e.g., "/a/eap/1") carrying an EAP Request message, if processed correctly by the EAP peer state machine, it returns an EAP Response. Along with each EAP Response, a new resource is created (e.g., "/a/eap/3") for processing the next EAP Request and the ongoing resource (e.g., "/a/eap/2") is erased. This way, ordering guarantees are achieved. Finally, an EAP Response is sent in the payload of a CoAP response that will also indicate the new resource in the Location-Path (and/or Location-Query) Options. If an error occurs while processing a legitimate message, the server will return a '4.00 Bad Request'. Error handling is discussed in Section 3.5.
* ステップ3-6。これから、EAP認証器とEAPピアは、COAPメッセージペイロードで輸送されるEAPメソッド（EAP-X）に関連するEAPパケットを交換します。EAP認証器は、POSTメソッドを使用してEAPリクエストをEAPピアに送信します。EAPピアは、COAP応答を使用して、ペイロードにEAP応答を運びます。EAPリクエストと応答は、それぞれ命名法「EAP-X-REQ」と「EAP-X-RESP」を使用して図3で表されます。EAPリクエストメッセージを運ぶ投稿メッセージが到着すると（ "/a/eap/1"）、EAPピアステートマシンによって正しく処理された場合、EAP応答が返されます。各EAP応答に加えて、次のEAP要求を処理するために新しいリソース（ "/a/eap/3"など）が作成され、進行中のリソース（ "/a/eap/2"など）が消去されます。このようにして、注文保証が達成されます。最後に、COAP応答のペイロードでEAP応答が送信され、場所パス（および/またはロケーションクエリ）オプションの新しいリソースも示されます。正当なメッセージの処理中にエラーが発生した場合、サーバーは「4.00の悪い要求」を返します。エラー処理については、セクション3.5で説明します。
* Step 7. When the EAP authentication ends successfully, the EAP authenticator obtains the MSK exported by the EAP method, an EAP Success message, and some authorization information [RFC5247] (e.g., Session-Lifetime). The EAP authenticator creates the OSCORE Security Context using the MSK and Recipient ID of both entities exchanged in Steps 1 and 2. The establishment of the OSCORE Security Context is defined in Section 6.2. Then, the EAP authenticator sends the POST message protected with OSCORE for key confirmation, including the EAP Success. The EAP authenticator MAY also send a Session-Lifetime, in seconds, which is represented by an unsigned integer in a CBOR Object (see Section 5). If this Session-Lifetime is not sent, the EAP peer assumes a default value of 8 hours, as RECOMMENDED in [RFC5247]. The reception of the OSCORE-protected POST message is considered by the EAP peer as an alternate indication of success [RFC3748]. The EAP peer state machine in the EAP peer interprets the alternate indication of success (similarly to the arrival of an EAP Success) and returns the MSK, which is used to create the OSCORE Security Context in the EAP peer to process the protected POST message received from the EAP authenticator.
* ステップ7。EAP認証が正常に終了すると、EAP認証器はEAPメソッド、EAP成功メッセージ、およびいくつかの承認情報[RFC5247]（例えば、セッションライフタイム）によってエクスポートされるMSKを取得します。EAP Authenticatorは、ステップ1および2で交換された両方のエンティティのMSKと受信者IDを使用してOSCOREセキュリティコンテキストを作成します。OSCOREセキュリティコンテキストの確立は、セクション6.2で定義されています。次に、EAP Authenticatorは、EAPの成功を含む重要な確認のためにOscoreで保護された投稿メッセージを送信します。EAP認証器は、CBORオブジェクトの署名されていない整数によって表されるセッションライフタイムを秒単位で送信することもできます（セクション5を参照）。このセッション - ラフタイムが送信されない場合、EAPピアは[RFC5247]で推奨されるように、デフォルト値の8時間を想定しています。オスコアで保護された投稿メッセージの受信は、EAPピアによって成功の代替兆候として考慮されます[RFC3748]。EAPピアのEAPピアステートマシンは、成功の代替兆候（EAP成功の到着と同様に）を解釈し、MSKを返します。
* Step 8. If the EAP authentication and the verification of the OSCORE-protected POST (Step 7) are successful, then the EAP peer answers with an OSCORE-protected '2.04 Changed'. From this point on, communication with the last resource (e.g., "/a/eap/(n)") MUST be protected with OSCORE. If allowed by application policy, the same OSCORE Security Context MAY be used to protect communication to other resources between the same endpoints.
* ステップ8。OSCORE保護された投稿（ステップ7）のEAP認証と検証が成功した場合、OSCOREで保護された「2.04変更」を使用したEAPピアは答えます。この時点から、最後のリソースとの通信（例： "/a/eap/（n）"）は、OSCOREで保護する必要があります。アプリケーションポリシーで許可されている場合、同じエンドポイント間の他のリソースへのコミュニケーションを保護するために、同じOSCOREセキュリティコンテキストを使用できます。
EAP peer EAP authenticator
------------- ------------
| POST /.well-known/coap-eap |
0)| No-Response |
| Payload("/a/eap/1") |
|---------------------------------------->|
| POST /a/eap/1 |
| Payload(EAP-Req/Id||CS-C||RID-C) |
1)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/2] |
| Payload(EAP-Resp/Id||CS-I||RID-I) |
2)|---------------------------------------->|
| POST /a/eap/2 |
| Payload(EAP-X-Req) |
3)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/3] |
| Payload(EAP-X-Resp) |
4)|---------------------------------------->|
....
| POST /a/eap/(n-1) |
| Payload(EAP-X-Req) |
5)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/(n)] |
| Payload(EAP-X-Resp) |
6)|---------------------------------------->|
| | MSK
| POST /a/eap/(n) | |
| OSCORE | v
| Payload(EAP Success||*Session-Lifetime)| OSCORE
MSK 7)|<----------------------------------------| CTX
| | |
v | 2.04 Changed |
OSCORE | OSCORE |
CTX 8)|---------------------------------------->|
*Session-Lifetime is optional
Figure 3: CoAP-EAP Flow of Operation with OSCORE
図3：OSCOREを使用した操作の協力の流れ
When the CoAP-EAP state is close to expiring, the EAP peer may want to start a new authentication process (re-authentication) to renew the state. The main goal is to obtain new and fresh keying material (MSK/EMSK) that, in turn, allows deriving a new OSCORE Security Context, increasing the protection against key leakage. The keying material MUST be renewed before the expiration of the Session-Lifetime. By default, the EAP key management framework [RFC5247] establishes a default value of 8 hours to refresh the keying material. Certain EAP methods such as Nimble Out-of-Band Authentication for EAP (EAP-NOOB) [RFC9140] or EAP-AKA' [RFC5448] provide fast reconnect for quicker re-authentication. The EAP Re-authentication Protocol (ERP) [RFC6696] MAY also be used to avoid the repetition of the entire EAP exchange.
Coap-Eap州が期限切れに近い場合、EAPピアは、状態を更新するために新しい認証プロセス（再認証）を開始したい場合があります。主な目標は、新しいオスコアセキュリティのコンテキストを導き出し、重要な漏れに対する保護を増やす新しい新鮮なキーイング素材（MSK/EMSK）を取得することです。キーリング資料は、セッションの有効期限が終了する前に更新する必要があります。デフォルトでは、EAPキー管理フレームワーク[RFC5247]は、キーイング素材を更新するために8時間のデフォルト値を確立します。EAP（EAP-NOOB）[RFC9140]またはEAP-AKA '[RFC5448]の雰囲気の雰囲気の範囲外認証などの特定のEAPメソッドは、迅速な再認証のために高速な再接続を提供します。EAP再認証プロトコル（ERP）[RFC6696]は、EAP交換全体の繰り返しを回避するためにも使用できます。
The re-authentication message flow will be the same as that shown in Figure 3. Nevertheless, two different CoAP-EAP states will be active during the re-authentication: the current CoAP-EAP state and the new CoAP-EAP state, which will be created once the re-authentication has finished successfully. Once the re-authentication is completed successfully, the current CoAP-EAP state is deleted and replaced by the new CoAP-EAP state. If for any reason the re-authentication fails, the current CoAP-EAP state will be available until it expires, or it will be renewed during a subsequent re-authentication attempt.
再認証メッセージのフローは、図3に示すものと同じです。それでも、再認証中に2つの異なるCoap-eap状態がアクティブになります。現在のCoap-eap状態と新しいCoap-eap状態は、再認証が成功したら作成されます。再認証が正常に完了すると、現在のCoap-Eap状態が削除され、新しいCoap-Eap状態に置き換えられます。何らかの理由で再認可が失敗した場合、現在のCoap-Eap状態が有効期限が切れるまで利用可能になります。または、その後の再認可の試みで更新されます。
If the re-authentication fails, it is up to the EAP peer to decide when to start a new re-authentication before the current EAP state expires.
再認証が失敗した場合、現在のEAP状態が期限切れになる前に新しい再認証を開始する時期を決定するのはEAPピア次第です。
The EAP peer and the EAP authenticator keep state during the CoAP-EAP negotiation. The CoAP-EAP state includes several important parts:
EAPピアとEAP認証者は、Coap-Eap交渉中に状態を維持します。Coap-eap州には、いくつかの重要な部分が含まれています。
* A reference to an instance of the EAP (peer or authenticator/ server) state machine.
* EAP（ピアまたは認証機/サーバー）状態マシンのインスタンスへの参照。
* The resource for the next message in the negotiation (e.g., "/a/ eap/2").
* ネゴシエーションの次のメッセージのリソース（例： "/a/eap/2"）。
* The MSK, which is exported when the EAP authentication is successful. CoAP-EAP can access the different variables via the EAP state machine (see [RFC4137]).
* EAP認証が成功したときにエクスポートされるMSK。COAP-EAPは、EAP状態マシンを介して異なる変数にアクセスできます（[RFC4137]を参照）。
* A reference to the OSCORE context.
* OSCOREコンテキストへの参照。
Once created, the EAP authenticator MAY choose to delete the state as described in Figure 4. Conversely, the EAP peer may need to renew the CoAP-EAP state because the key material is close to expiring, as mentioned in Section 3.3.
作成されたEAP認証器は、図4に記載されているように状態を削除することを選択できます。逆に、EAPピアは、セクション3.3で述べたように、主要な材料が期限切れに近いため、CoAP-EAP状態を更新する必要があります。
There are situations where the current CoAP-EAP state might need to be removed. For instance, due to its expiration or forced removal, the EAP peer has to be expelled from the security domain. Such an exchange is illustrated in Figure 4.
現在のCOAP-EAP状態を削除する必要がある状況があります。たとえば、有効期限や強制除去のために、EAPピアをセキュリティドメインから追放する必要があります。このような交換を図4に示します。
If the EAP authenticator deems it necessary to remove the CoAP-EAP state from the EAP peer before it expires, it can send a DELETE command in a request to the EAP peer, referencing the last CoAP-EAP state resource given by the CoAP server, whose identifier will be the last one received (e.g., "/a/eap/(n)" in Figure 3). This message is protected by the OSCORE security association to prevent forgery. Upon reception of this message, the CoAP server sends a response to the EAP authenticator with the code '2.02 Deleted', which is also protected by the OSCORE security association. If a response from the EAP peer does not arrive after EXCHANGE_LIFETIME, the EAP authenticator will remove the state.
EAP Authenticatorが有効期限が切れる前にCoap-Eap状態をEAPピアから削除する必要があると判断した場合、EAPピアにリクエストで削除コマンドを送信して、識別子が最後に受け取ったCoap-Eap Stateリソースを参照します（例： "/a/eap/（n）"）。このメッセージは、偽造を防ぐためにオスコアセキュリティ協会によって保護されています。このメッセージを受信すると、CoAPサーバーは、OSCOREセキュリティ協会によっても保護されているコード「2.02削除」を使用して、EAP認証器への応答を送信します。EAPピアからの応答がExchange_lifetime後に到着しない場合、EAP認証者は状態を削除します。
EAP peer EAP authenticator
------------- -------------
| |
| DELETE /a/eap/(n) |
| OSCORE |
|<--------------------------------------|
| |
| 2.02 Deleted |
| OSCORE |
|-------------------------------------->|
Figure 4: Deleting State
図4：削除状態
This section elaborates on how different errors are handled: EAP authentication failure (Section 3.5.1), a non-responsive endpoint (Section 3.5.2), and duplicated messages (Section 3.5.3).
このセクションでは、異なるエラーの処理方法について詳しく説明します：EAP認証障害（セクション3.5.1）、非応答性エンドポイント（セクション3.5.2）、および複製メッセージ（セクション3.5.3）。
The EAP authentication may fail in different situations (e.g., wrong credentials). The result is that the EAP authenticator will send an EAP Failure message because of a failed EAP authentication (Step 7 in Figure 3). In this case, the EAP peer MUST send a response '4.01 Unauthorized' in Step 8. Therefore, Steps 7 and 8 are not protected in this case because no MSK is exported and the OSCORE Security Context is not yet generated.
EAP認証は、さまざまな状況で失敗する可能性があります（たとえば、間違った資格情報）。その結果、EAP認証器がEAP認証に失敗したため、EAP障害メッセージが送信されます（図3のステップ7）。この場合、EAPピアはステップ8で「4.01 4.01が許可されていない」応答を送信する必要があります。したがって、MSKがエクスポートされず、OSCOREセキュリティコンテキストがまだ生成されていないため、ステップ7と8は保護されません。
If the EAP authentication fails during the re-authentication and the EAP authenticator sends an EAP Failure, the current CoAP-EAP state will still be usable until it expires.
再認証中にEAP認証が失敗し、EAP認証器がEAP障害を送信する場合、現在のCoap-eap状態は有効期限が切れるまで使用可能になります。
If for any reason one of the entities becomes non-responsive, the CoAP-EAP state SHOULD be removed after a stipulated amount of time. The amount of time can be adjusted according to the policies established by the application or use case where CoAP-EAP is used. As a default value, the CoAP EXCHANGE_LIFETIME parameter, as defined in CoAP [RFC7252], will be used.
何らかの理由で、エンティティのいずれかが反応しない場合、規定の時間の後にCoap-eap状態を削除する必要があります。COAP-EAPが使用されているアプリケーションまたはユースケースによって確立されたポリシーに従って、時間を調整できます。デフォルト値として、COAP [RFC7252]で定義されているCOAP Exchange_Lifetimeパラメーターが使用されます。
The removal of the CoAP-EAP state in the EAP authenticator assumes that the EAP peer will need to authenticate again.
EAP認証器のCoap-Eap状態の除去は、EAPピアが再び認証する必要があると想定しています。
According to CoAP, EXCHANGE_LIFETIME considers the time it takes until a client stops expecting a response to a request. A timer is reset every time a message is sent. By default, CoAP-EAP adopts the value of EXCHANGE_LIFETIME as a timer in the EAP peer and authenticator to remove the CoAP-EAP state if the authentication process has not progressed to completion during that time.
COAPによると、Exchange_lifetimeは、クライアントがリクエストへの応答を期待するのを停止するまでの時間を考慮します。メッセージが送信されるたびにタイマーがリセットされます。デフォルトでは、CoAp-Eapは、EAPピアおよび認証装置のタイマーとしてExchange_lifetimeの値を採用して、認証プロセスがその間に完了まで進行していない場合にCoAP-EAP状態を削除します。
The EAP peer will remove the CoAP-EAP state if either the EXCHANGE_LIFETIME is triggered or the EAP peer state machine returns an eapFail.
EAPPピアは、Exchange_lifetimeがトリガーされるか、EAPピアステートマシンがEAPFAILを返す場合、COAP-EAP状態を削除します。
The EAP authenticator will remove the CoAP-EAP state if either the EXCHANGE_LIFETIME is triggered or, when the EAP authenticator is operating in pass-through mode (i.e., the EAP authentication is performed against a AAA server), the EAP authenticator state machine returns "aaaTimeout" [RFC4137].
EAP Authenticatorは、Exchange_Lifetimeがトリガーされている場合、またはEAP認証器がパススルーモードで動作している場合（つまり、EAP認証がAAAサーバーに対して実行される場合）、EAP認証が実行される場合、EAP認証を削除します。
The reception of the trigger message (Step 0 in Figure 3) containing the URI /coap-eap needs some additional considerations, as the resource is always available in the EAP authenticator.
URI /COAP-EAPを含むトリガーメッセージ（図3のステップ0）の受信には、EAP Authenticatorで常にリソースが利用可能であるため、追加の考慮事項が必要です。
If a trigger message arrives at the EAP authenticator during an ongoing authentication with the same EAP peer, the EAP authenticator MUST silently discard this trigger message.
同じEAPピアを使用して継続的な認証中にトリガーメッセージがEAP認証器に到着する場合、EAP認証器はこのトリガーメッセージを静かに破棄する必要があります。
If an old "POST /.well-known/coap-eap" (Step 0 in Figure 5) arrives at the EAP authenticator and there is no authentication ongoing, the EAP authenticator may understand that a new authentication process is requested. Consequently, the EAP authenticator will start a new EAP authentication. However, if the EAP peer did not start any authentication, it will send a '4.04 Not Found' in the response (Figure 5).
古い「POST /.WELL-NOUCTER/COAP-EAP」（図5のステップ0）がEAP認証器に到着し、継続的に認証がない場合、EAP認証者は新しい認証プロセスが要求されていることを理解する場合があります。その結果、EAP認証器は新しいEAP認証を開始します。ただし、EAPピアが認証を開始しなかった場合、応答に「4.04が見つかりません」を送信します（図5）。
EAP peer EAP authenticator
---------- ----------
| *POST /.well-known/coap-eap |
0)| No-Response |
| Payload("/a/eap/1") |
| ------------------------->|
| POST /a/eap/1 |
| Payload(EAP-Req/Id||CS-C) |
1)|<----------------------------------------|
| |
| 4.04 Not Found |
|---------------------------------------->|
*Old
Figure 5: /.well-known/coap-eap with No Ongoing Authentication from the EAP Authenticator
図5：/.well-nown /coap-eapeapeapticatorからの継続的な認証なし
The CoAP-EAP operation is intended to be compatible with the use of intermediary entities between the EAP peer and the EAP authenticator when direct communication is not possible. In this context, CoAP proxies can be used as enablers of the CoAP-EAP exchange.
COAP-EAP操作は、直接通信が不可能な場合、EAPピアとEAP認証器の間の仲介エンティティの使用と互換性があることを目的としています。これに関連して、COAPプロキシは、COAP-EAP交換のイネーブラーとして使用できます。
This specification is limited to using standard CoAP [RFC7252] as well as standardized CoAP options [RFC8613]. It does not specify any addition in the form of CoAP options. This is expected to ease the integration of CoAP intermediaries in the CoAP-EAP exchange.
この仕様は、標準のCOAP [RFC7252]と標準化されたCOAPオプション[RFC8613]の使用に限定されます。COAPオプションの形で追加されていません。これにより、COAP-EAP交換におけるCOAP仲介者の統合が容易になると予想されます。
When using proxies in the CoAP-EAP exchange, it should be considered that the exchange contains a role-reversal process at the beginning of the exchange. In the first message, the EAP peer acts as a CoAP client and the EAP authenticator acts as the CoAP server. In the remaining exchanges, the roles are reversed (i.e., the EAP peer acts as the CoAP server, and the EAP authenticator acts as the CoAP client). When using a proxy in the exchange, for message 0 it will act as a forward proxy, and as a reverse proxy for the rest. Additionally, in the first exchange, the EAP peer, as a CoAP client, sends the URI for the next CoAP message in the payload of a request. This is not the typical behavior, as URIs referring to new services/ resources appear in Location-Path and/or Location-Query Options in CoAP responses. Hence, the proxy will have to treat the payload of Message 0 as if it were a Location-Path Option of a CoAP response.
Coap-Eap Exchangeでプロキシを使用する場合、交換には交換の開始時に役割反転プロセスが含まれていると考える必要があります。最初のメッセージでは、EAPピアはCOAPクライアントとして機能し、EAP認証者はCOAPサーバーとして機能します。残りの交換では、役割は逆転します（つまり、EAPピアはCOAPサーバーとして機能し、EAP認証器はCOAPクライアントとして機能します）。交換でプロキシを使用する場合、メッセージ0については、フォワードプロキシとして機能し、残りの逆プロキシとして機能します。さらに、最初の交換では、COAPクライアントとしてのEAPピアは、リクエストのペイロードの次のCOAPメッセージのURIを送信します。これは典型的な動作ではありません。これは、新しいサービス/リソースを参照するURIがCOAP応答のロケーションパスおよび/またはロケーションクエリオプションに表示されるためです。したがって、プロキシは、メッセージ0のペイロードをCOAP応答のロケーションパスオプションであるかのように扱う必要があります。
In the CoAP-EAP exchange, the format specified by the "application/ coap-eap" media type will be used. See Section 9.5.
Coap-Eap Exchangeでは、「アプリケーション/ CoAP-EAP」メディアタイプで指定された形式が使用されます。セクション9.5を参照してください。
In CoAP-EAP, there are two different elements that can be sent over the payload. The first one is a relative URI. This payload will be present for the first message (0) in Figure 3.
Coap-eapでは、ペイロードを介して送信できる2つの異なる要素があります。最初のものは相対的なURIです。このペイロードは、図3の最初のメッセージ（0）に存在します。
In all the other cases, an EAP message will be followed by the CBOR Object specified in Section 5. A visual example of the second case can be found in Figure 7 (Section 6.1).
他のすべてのケースでは、EAPメッセージの後にセクション5で指定されたCBORオブジェクトが続きます。2番目のケースの視覚的な例を図7（セクション6.1）に示します。
In the CoAP-EAP exchange, information needs to be exchanged between the two entities -- for example, the cipher suites that need to be negotiated, or authorization information (Session-Lifetime). There may also be a need to extend the information that has to be exchanged in the future. This section specifies the CBOR data structure [RFC8949] to exchange information between the EAP peer and the EAP authenticator in the CoAP payload.
COAP-EAP交換では、2つのエンティティなどの情報を交換する必要があります。たとえば、交渉する必要がある暗号スイート、または許可情報（セッションライフタイム）です。また、将来交換する必要がある情報を拡張する必要があるかもしれません。このセクションでは、CBORデータ構造[RFC8949]を指定して、EAPピアとCOAPペイロードのEAP認証器との間の情報を交換します。
Figure 6 shows the specification of the CBOR Object to exchange information in CoAP-EAP.
図6は、COAP-EAPで情報を交換するCBORオブジェクトの仕様を示しています。
CoAP-EAP_Info = {
? 1 : [+ int], ; Cipher Suite (CS-C or CS-I)
? 2 : bstr, ; RID-C
? 3 : bstr, ; RID-I
? 4 : uint ; Session-Lifetime
}
Figure 6: CBOR Data Structure for CoAP-EAP
図6：Coap-EapのCBORデータ構造
The parameters contain the following information:
パラメーターには次の情報が含まれています。
1. Cipher Suite: An array with the list of proposed, or selected, CBOR Object Signing and Encryption (COSE) algorithms for OSCORE. If the field is carried over a request, a proposed cipher suite is indicated; if it is carried over a response, it corresponds to the agreed-upon cipher suite.
1. 暗号スイート：OSCOREの提案または選択されたCBORオブジェクトの署名および暗号化（COSE）アルゴリズムのリストを備えた配列。フィールドがリクエストに掲載されている場合、提案された暗号スイートが示されています。それが応答を引き継がれている場合、それは合意されたCipherスイートに対応します。
2. RID-C: The Recipient ID of the EAP authenticator. The EAP peer uses this value as the Sender ID for its OSCORE Sender Context. The EAP authenticator uses this value as the Recipient ID for its Recipient Context.
2. RID-C：EAP Authenticatorの受信者ID。EAPピアは、オスコア送信者のコンテキストにこの値を送信者IDとして使用します。EAP Authenticatorは、受信者のコンテキストにこの値を受信者IDとして使用します。
3. RID-I: The Recipient ID of the EAP peer. The EAP authenticator uses this value as the Sender ID for its OSCORE Sender Context. The EAP peer uses this value as the Recipient ID for its Recipient Context.
3. RID-I：EAPピアの受信者ID。EAP Authenticatorは、OSCORE Senderコンテキストにこの値を送信者IDとして使用します。EAPピアは、受信者のコンテキストにこの値を受信者IDとして使用します。
4. Session-Lifetime: The time that the session is valid, in seconds.
4. セッション - ライフタイム：セッションが有効な時間、数秒で。
Other indexes can be used to carry additional values as needed, like specific authorization parameters.
他のインデックスを使用して、特定の承認パラメーターのように、必要に応じて追加の値を伝えることができます。
The indexes from 65001 to 65535 are reserved for experimentation.
65001から65535までのインデックスは、実験のために予約されています。
OSCORE runs after the EAP authentication, using the cipher suite selected in the cipher suite negotiation (Steps 1 and 2 in Figure 3). To negotiate the cipher suite, CoAP-EAP follows a simple approach: The EAP authenticator sends a list, in decreasing order of preference, with the identifiers of the supported cipher suites (Step 1 in Figure 8). In the response to that message (Step 2 in Figure 8), the EAP peer sends its choice.
オスコアは、EAP認証の後に実行され、暗号スイートネゴシエーションで選択された暗号スイートを使用します（図3のステップ1および2）。暗号スイートを交渉するために、Coap-Eapは単純なアプローチに従います。EAP認証器は、サポートされている暗号スイートの識別子とともに、優先順位を減らす順序でリストを送信します（図8のステップ1）。そのメッセージに対する応答（図8のステップ2）で、EAPピアはその選択を送信します。
This list is included in the payload after the EAP message through a CBOR array. An example of how the fields are arranged in the CoAP payload can be seen in Figure 7. An example exchange for the cipher suite negotiation is shown in Figure 8. The EAP Request (EAP-Req/Id) and EAP Response (EAP-Resp/Id) are sent; both messages include the CBOR Object (Section 5) containing the cipher suite field for the cipher suite negotiation.
このリストは、CBORアレイを介したEAPメッセージの後、ペイロードに含まれています。COAPペイロードにフィールドがどのように配置されているかの例を図7に示します。暗号スイートの交渉の例を図8に示します。EAP要求（EAP-REQ/ID）およびEAP応答（EAP-RESP/ID）を送信します。両方のメッセージには、暗号スイートネゴシエーションの暗号スイートフィールドを含むCBORオブジェクト（セクション5）が含まれます。
+------+------------+--------+------+-----------------+
| Code | Identifier | Length | Data | cipher suites |
+------+------------+--------+------+-----------------+
<---------- EAP Packet ----------> <-- CBOR array -->
Figure 7: Cipher Suites in the CoAP Payload
図7：COAPペイロードの暗号スイート
EAP peer EAP Auth.
(CoAP server) (CoAP client)
------------- -------------
| |
| ... |
|---------------------------------------->|
| POST /a/eap/1 |
| Payload(EAP-Req/Id, CBORArray[0,1,2]) |
1)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/2] |
| Payload(EAP-Resp/Id, CBORArray[0]) |
2)|---------------------------------------->|
...
Figure 8: Cipher Suite Negotiation
図8：暗号スイートの交渉
If there is no CBOR array specifying the cipher suites, the default cipher suites are applied. If the EAP authenticator sends a restricted list of cipher suites that can be accepted, it MUST include the default value 0, since it is mandatory to implement. The EAP peer will have at least that option available.
暗号スイートを指定するCBORアレイがない場合、デフォルトの暗号スイートが適用されます。EAP Authenticatorが受け入れることができる暗号スイートの制限付きリストを送信する場合、実装することが必須であるため、デフォルト値0を含める必要があります。EAPピアには、少なくともそのオプションが利用可能になります。
The cipher suite requirements are inherited from those established by OSCORE [RFC8613], which are COSE algorithms [RFC9053]. By default, the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm is SHA-256 and the Authenticated Encryption with Associated Data (AEAD) algorithm is AES-CCM-16-64-128 [RFC9053]. ("HMAC" stands for "Hashed Message Authentication Code".) Both are mandatory to implement. The other supported and negotiated cipher suites are listed below; these hash algorithms are considered in cases where the specification includes DTLS support in the future (TLS_SHA256, TLS_SHA384, TLS_SHA512; see Appendix A):
暗号スイートの要件は、COSEアルゴリズム[RFC9053]であるOSCORE [RFC8613]によって確立された要件から継承されています。デフォルトでは、HMACベースの抽出および拡張キー導入関数（HKDF）アルゴリズムはSHA-256であり、関連データ（AEAD）アルゴリズムを使用した認証された暗号化はAES-CCM-16-64-128 [RFC9053]です。（「HMAC」は、「Hashed Message Authentication Code」の略です。）どちらも実装する必要があります。他のサポートされ、交渉された暗号スイートを以下にリストします。これらのハッシュアルゴリズムは、仕様に将来のDTLSサポートが含まれる場合に考慮されます（TLS_SHA256、TLS_SHA384、TLS_SHA512;付録Aを参照）：
* 0) AES-CCM-16-64-128, SHA-256 (default)
* 0）AES-CCM-16-64-128、SHA-256（デフォルト）
* 1) A128GCM, SHA-256
* 1）A128GCM、SHA-256
* 2) A256GCM, SHA-384
* 2）A256GCM、SHA-384
* 3) ChaCha20/Poly1305, SHA-256
* 3）Chacha20/Poly1305、SHA-256
* 4) ChaCha20/Poly1305, SHAKE256
* 4）Chacha20/Poly1305、Shake256
This specification uses the HKDF as defined in [RFC5869] to derive the necessary key material. Since the key derivation process uses the MSK, which is considered fresh key material, the HKDF-Expand function (shortened here as "KDF") will be used. See Section 8.1 regarding why the use of this function is enough and it is not necessary to use KDF-Extract.
この仕様では、[RFC5869]で定義されているHKDFを使用して、必要な重要な材料を導き出します。キー導出プロセスでは、新鮮なキーマテリアルと見なされるMSKを使用するため、HKDF-Expand関数（ここでは「KDF」として短縮）が使用されます。この関数の使用が十分であり、KDF-Extractを使用する必要はない理由については、セクション8.1を参照してください。
The derivation of the OSCORE Security Context allows securing the communication between the EAP peer and the EAP authenticator once the MSK has been exported, providing confidentiality, integrity, key confirmation (Steps 7 and 8 in Figure 3), and detection of downgrading attacks.
OSCOREセキュリティコンテキストの導出により、MSKがエクスポートされると、EAPピアとEAP認証器の間の通信を確保し、機密性、完全性、重要な確認（図3のステップ7および8）、および格下げ攻撃の検出を提供します。
Once the Master Secret and Master Salt are derived, they can be used to derive the rest of the OSCORE Security Context (see Section 3.2.1 of [RFC8613]). It should be noted that the ID Context is not provided for the OSCORE Security Context derivation.
マスターシークレットとマスターソルトが導出されると、オスコアセキュリティコンテキストの残りの部分を導出するために使用できます（[RFC8613]のセクション3.2.1を参照）。OSCOREセキュリティコンテキストの派生には、IDコンテキストが提供されていないことに注意してください。
The Master Secret can be derived by using the chosen cipher suite and the KDF as follows:
マスターシークレットは、選択した暗号スイートとKDFを次のように使用することで導き出すことができます。
Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length)
where:
ただし：
* The MSK is exported by the EAP method. The use of the MSK for key derivation is discussed in Section 8.
* MSKはEAPメソッドによってエクスポートされます。キー派生のためのMSKの使用については、セクション8で説明します。
* CS is the concatenation of the content of the cipher suite negotiation -- that is, the concatenation of two CBOR arrays CS-C and CS-I (with CBOR ints as elements), as defined in Section 5. If neither CS-C nor CS-I was sent (i.e., default algorithms are used), the value used to generate CS will be the same as if the default algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR array with the cipher suite value of 0).
* CSは、暗号スイート交渉の内容の連結です。つまり、セクション5で定義されているように、CSが送信された場合（つまり、デフォルトのアルゴリスムが使用されている場合、CS-Iが送信された場合、CS-Iが送信された場合、2つのCBORアレイCS-CおよびCS-I（CBOR INTを要素として要素として）の2つのCBORアレイCS-CとCSOR-I（CBOR INTを要素として）のコンテンツの連結です。CS-CまたはCS-I（つまり、0のCipherスイート値を持つCBORアレイ）。
* "COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation of the non-NULL-terminated string (excluding the double quotes around it).
* 「Coap-Eap Oscore Master Secret」は、非端線端端の文字列のASCIIコード表現です（その周りの二重引用符は除く）。
* CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated.
* CSと「Coap-Eap Oscore Master Secret」が連結されています。
* length is the size of the output key material.
* 長さは、出力キーマテリアルのサイズです。
Similarly to the Master Secret, the Master Salt can be derived as follows:
マスターシークレットと同様に、マスターソルトは次のように導出できます。
Master Salt = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SALT", length)
where:
ただし：
* The MSK is exported by the EAP method. The use of the MSK for key derivation is discussed in Section 8.
* MSKはEAPメソッドによってエクスポートされます。キー派生のためのMSKの使用については、セクション8で説明します。
* CS is the concatenation of the content of the cipher suite negotiation -- that is, the concatenation of two CBOR arrays CS-C and CS-I (with CBOR ints as elements), as defined in Section 5. If neither CS-C nor CS-I was sent (i.e., default algorithms are used), the value used to generate CS will be the same as if the default algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR array with the cipher suite value of 0).
* CSは、暗号スイート交渉の内容の連結です。つまり、セクション5で定義されているように、CSが送信された場合（つまり、デフォルトのアルゴリスムが使用されている場合、CS-Iが送信された場合、CS-Iが送信された場合、2つのCBORアレイCS-CおよびCS-I（CBOR INTを要素として要素として）の2つのCBORアレイCS-CとCSOR-I（CBOR INTを要素として）のコンテンツの連結です。CS-CまたはCS-I（つまり、0のCipherスイート値を持つCBORアレイ）。
* "COAP-EAP OSCORE MASTER SALT" is the ASCII code representation of the non-NULL-terminated string (excluding the double quotes around it).
* 「Coap-eap oscore Master Salt」は、非微細端線文字列のASCIIコード表現です（その周りの二重引用符は除く）。
* CS and "COAP-EAP OSCORE MASTER SALT" are concatenated.
* CSと「Coap-Eap Oscore Master Salt」が連結されています。
* length is the size of the output key material.
* 長さは、出力キーマテリアルのサイズです。
Since the MSK is used to derive the Master Key, the correct verification of the OSCORE-protected request (Step 7) and response (Step 8) confirms that the EAP authenticator and the EAP peer have the same Master Secret, achieving key confirmation.
MSKはマスターキーを導出するために使用されるため、OSCOREで保護された要求（ステップ7）と応答（ステップ8）の正しい検証は、EAP認証器とEAPピアが同じマスターシークレットを持ち、キー確認を達成したことを確認します。
To prevent a downgrading attack, the content of the cipher suite (referred to here as "CS") negotiation is embedded in the Master Secret derivation. If an attacker changes the value of the cipher suite negotiation, the result will be different OSCORE Security Contexts, which in turn will result in failure in Steps 7 and 8.
格下げ攻撃を防ぐために、暗号スイート（ここでは「CS」と呼ばれる）の内容は、Master Secret Derivationに組み込まれています。攻撃者がCipher Suiteの交渉の価値を変更すると、結果は異なるOSCOREセキュリティコンテキストになり、その結果、ステップ7と8で失敗します。
The EAP authenticator will use the Recipient ID of the EAP peer (RID-I) as the Sender ID for its OSCORE Sender Context. The EAP peer will use this value as the Recipient ID for its Recipient Context.
EAP Authenticatorは、EAPピア（RID-I）の受信者IDを、OSCORE Senderコンテキストの送信者IDとして使用します。EAPピアは、受信者のコンテキストの受信者IDとしてこの値を使用します。
The EAP peer will use the Recipient ID of the EAP authenticator (RID-C) as the Sender ID for its OSCORE Sender Context. The EAP authenticator will use this value as the Recipient ID for its Recipient Context.
EAPピアは、OSCORE送信者コンテキストの送信者IDとしてEAP Authenticator（RID-C）の受信者IDを使用します。EAP Authenticatorは、受信者のコンテキストの受信者IDとしてこの値を使用します。
This section discusses the suitability of CoAP as the EAP lower layer and reviews the requisites imposed by EAP on any protocol transporting EAP. What EAP expects from its lower layers can be found in Section 3.1 of [RFC3748], which is elaborated next:
このセクションでは、EAP下層層としてのCOAPの適合性について説明し、EAP輸送にEAPによって課される必要条件をレビューします。EAPが下層層から期待することは、[RFC3748]のセクション3.1にあります。次に詳しく説明されています。
Unreliable transport:
信頼できない輸送：
EAP does not assume that lower layers are reliable, but it can benefit from a reliable lower layer. In this sense, CoAP provides a reliability mechanism (e.g., using Confirmable messages).
EAPは、下層が信頼できるとは想定していませんが、信頼できる下層層の恩恵を受けることができます。この意味で、COAPは信頼性メカニズムを提供します（たとえば、確認可能なメッセージの使用）。
Lower-layer error detection:
低層エラー検出：
EAP relies on lower-layer error detection (e.g., CRC, checksum, Message Integrity Check (MIC), etc.). For simplicity, CoAP-EAP delegates error detection to the lower layers, such as the link layer or transport layer (e.g., UDP over IPv6 or TCP).
EAPは、低層エラー検出（例：CRC、チェックサム、メッセージの整合性チェック（MIC）など）に依存しています。簡単にするために、Coap-Eapは、リンク層や輸送層（IPv6またはTCPのUDPなど）などの下層層へのエラー検出を代表します。
Lower-layer security:
低層セキュリティ：
EAP does not require security services from the lower layers.
EAPは、下層からのセキュリティサービスを必要としません。
Minimum MTU:
最小MTU：
Lower layers need to provide an EAP MTU size of 1020 octets or greater. CoAP assumes an upper bound of 1024 octets for its payload, which covers the EAP requirements when only the EAP message is sent in the CoAP payload. In the case of Messages 1 and 2 in Figure 3, those messages have extra information apart from EAP. Nevertheless, the EAP-Req/Id has a fixed length of 5 bytes. Message 2, with the EAP-Resp/Id, would limit the length of the identity being used to the CoAP payload maximum size (1024) - len( CS-I || RID-I ) - EAP Response header (5 bytes), which leaves enough space for sending even lengthy identities. Nevertheless, this limitation can be overcome by using CoAP block-wise transfers [RFC7959]. Note: When EAP is proxied over a AAA framework, the Access-Request packets in RADIUS MUST contain a Framed-MTU attribute with a value of 1024 and, in Diameter, the Framed-MTU Attribute-Value Pair (AVP) with a value of 1024. This information signals the AAA server that it should limit its responses to 1024 octets.
下層層は、1020オクテット以上のEAP MTUサイズを提供する必要があります。COAPは、Payloadの1024オクテットの上限を想定しています。これは、COAPペイロードにEAPメッセージのみが送信される場合のEAP要件をカバーします。図3のメッセージ1と2の場合、これらのメッセージにはEAP以外の追加情報があります。それにもかかわらず、EAP-REQ/IDの固定長は5バイトです。EAP-RESP/IDを使用したメッセージ2は、COAPペイロードの最大サイズ（1024）-Len（CS-I || RID-I）-EAP応答ヘッダー（5バイト）に使用されるIDの長さを制限し、長いアイデンティティを送信するのに十分なスペースを残します。それにもかかわらず、この制限は、COAPブロックごとの転送を使用することで克服できます[RFC7959]。注：AAAフレームワークにEAPがプロキシ化されている場合、RADIUSのアクセスレクエストパケットには、1024の値を持つフレームMTU属性が含まれている必要があります。
Ordering guarantees:
注文保証：
EAP relies on lower-layer ordering guarantees for correct operation. Regarding message ordering, every time a new message arrives at the authentication service hosted by the EAP peer, a new resource is created, and this is indicated in a '2.01 Created' response code along with the name of the new resource via Location-Path or Location-Query Options. This way, the application shows that its state has advanced.
EAPは、正しい操作のために低層の注文保証に依存しています。メッセージの注文に関しては、EAPピアがホストする認証サービスに新しいメッセージが届くたびに、新しいリソースが作成されます。これは、「2.01が作成した」応答コードと、ロケーションパスまたはロケーションクエリオプションを介して新しいリソースの名前とともに示されています。これにより、アプリケーションはその状態が進んでいることを示しています。
Although [RFC3748] states that "EAP provides its own support for duplicate elimination and retransmission," EAP is also reliant on lower-layer ordering guarantees. In this regard, [RFC3748] talks about possible duplication and says, "Where the lower layer is reliable, it will provide the EAP layer with a non-duplicated stream of packets. However, while it is desirable that lower layers provide for non-duplication, this is not a requirement." CoAP provides a non-duplicated stream of packets and accomplishes the desirable non-duplication. In addition, [RFC3748] says that when EAP runs over a reliable lower layer "the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer."
[RFC3748]は、「EAPは重複の除去と再送信に対する独自のサポートを提供する」と述べていますが、EAPは低層の注文保証にも依存しています。この点で、[RFC3748]は、可能性のある複製について語り、「下層が信頼できる場合、EAP層に非重複パケットのストリームを提供します。ただし、下層層は非重複を提供することが望ましいが、これは要件ではない」COAPは、非重複したパケットのストリームを提供し、望ましい非重複を達成します。さらに、[RFC3748]は、EAPが信頼できる下層層を越えた場合、「Authenticatorの再送信タイマーは無限の値に設定する必要があるため、EAP層で再送信が発生しないように」と述べています。
Regarding the impact that an EAP lower layer will have on the number of bytes of the whole authentication exchange, [CoAP-EAP] provides a comparison with another network-layer-based EAP lower layer, the Protocol for Carrying Authentication for Network Access (PANA) as defined in [RFC5191].
EAP下層が認証交換全体のバイト数に与える影響に関して、[coap-eap]は、[RFC5191]で定義されているネットワークアクセス（PANA）を運ぶための別のネットワーク層ベースのEAP下層層との比較を提供します。
The EAP method being transported will take most of the exchange. However, the impact of the EAP lower layer cannot be ignored, especially in very constrained communication technologies such as those with limited capabilities (e.g., as can be found in IoT networks).
輸送されるEAPメソッドは、ほとんどの交換が必要です。ただし、特に能力が限られているような非常に制約されている通信技術（たとえば、IoTネットワークで見られるように）では、EAP下層の影響を無視することはできません。
Note: To improve efficiency in environments with constrained devices and networks, the latest versions of EAP methods (e.g., EAP-AKA' [RFC5448], EAP-TLS 1.3 [RFC9190]) are recommended over older versions. EAP methods more adapted for IoT networks (e.g., EAP-NOOB [RFC9140], EAP-EDHOC [EAP-EDHOC], etc.) are also recommended.
注：制約されたデバイスとネットワークを備えた環境の効率を改善するには、EAPメソッドの最新バージョン（EAP-AKA '[RFC5448]、EAP-TLS 1.3 [RFC9190]）が古いバージョンよりも推奨されます。IOTメソッドは、IoTネットワーク（例：EAP-NOOB [RFC9140]、EAP-EDHOC [EAP-EDHOC]など）に適しています。
Security aspects to be considered include how authorization is managed, the use of the MSK as key material, and how trust in the EAP authenticator is established. Additional considerations such as EAP channel binding as per [RFC6677] are also discussed here.
考慮すべきセキュリティの側面には、認可の管理方法、MSKの主要資料としての使用、およびEAP認証器への信頼がどのように確立されるかが含まれます。[RFC6677]によるEAPチャネル結合などの追加の考慮事項についてもここで説明します。
This document limits the use of EAP methods to those compliant with [RFC4017], yielding strong and fresh session keys such as the MSK. By this assumption, the HKDF-Expand function is used directly, as clarified in [RFC5869].
このドキュメントは、EAPメソッドの使用を[RFC4017]に準拠した人々に制限し、MSKなどの強力で新鮮なセッションキーを生成します。この仮定により、[RFC5869]で明確にされているように、HKDF拡張機能は直接使用されます。
Authorization is part of bootstrapping. It serves to establish whether the EAP peer can join and the set of conditions it must adhere to. The authorization data will be gathered from the organization that is responsible for the EAP peer and sent to the EAP authenticator if a AAA infrastructure is deployed.
承認はブートストラップの一部です。EAPピアが参加できるかどうか、およびそれが従わなければならない一連の条件を確立するのに役立ちます。AAAインフラストラクチャが展開されている場合、承認データはEAPピアを担当する組織から収集され、EAP認証者に送信されます。
In standalone mode, the authorization information will be in the EAP authenticator. If pass-through mode is used, authorization data received from the AAA server can be delivered by the AAA protocol (e.g., RADIUS or Diameter). Providing more fine-grained authorization data can be done by transporting the data using the Security Assertion Markup Language (SAML) in RADIUS [RFC7833]. After bootstrapping, additional authorization information may be needed to operate in the security domain. This can be taken care of by the solutions proposed in the Authentication and Authorization for Constrained Environments (ACE) WG, such as the use of OAuth [RFC9200], among other solutions, to provide ACE.
スタンドアロンモードでは、承認情報はEAP認証器になります。パススルーモードを使用すると、AAAサーバーから受信した認証データをAAAプロトコル（半径または直径など）で配信できます。より微細な認証データを提供することは、半径[RFC7833]のセキュリティアサーションマークアップ言語（SAML）を使用してデータを輸送することで実行できます。ブートストラップ後、セキュリティドメインで動作するには追加の承認情報が必要になる場合があります。これは、ACEを提供するために、他のソリューションの中でも特に、OAuth [RFC9200]の使用など、制約された環境（ACE）WGの認証と承認で提案されたソリューションによって処理できます。
Since CoAP is an application protocol, CoAP-EAP assumes certain IP connectivity in the link between the EAP peer and the EAP authenticator to run. This link MUST only authorize unprotected IP traffic to be sent between the EAP peer and the EAP authenticator during the authentication with CoAP-EAP. Once the authentication is successful, the key material generated by the EAP authentication (MSK) and any other traffic can be authorized if it is protected. It is worth noting that if the EAP authenticator is not in the same link as the EAP peer and an intermediate entity (e.g., a CoAP proxy) helps with this process, this concept also applies to the communication between the EAP peer and the intermediary.
COAPはアプリケーションプロトコルであるため、COAP-Eapは、実行するEAPピアとEAP認証器の間のリンク内の特定のIP接続を想定しています。このリンクは、COAP-EAPを使用した認証中に、保護されていないIPトラフィックをEAPピアとEAP認証器の間に送信することを許可する必要があります。認証が成功すると、EAP認証（MSK）およびその他のトラフィックによって生成される重要な資料は、保護されている場合は承認できます。EAP認証器がEAPピアと同じリンクにない場合、中間エンティティ（COAPプロキシなど）がこのプロセスに役立つ場合、この概念はEAPピアと仲介者の間の通信にも適用されます。
Alternatively, the link layer MAY provide support to transport CoAP-EAP without an IP address by using link-layer frames (e.g., by defining a new Key Management Protocol ID per IEEE 802.15.9 [IEEE802159]).
あるいは、リンクレイヤーは、リンク層フレームを使用して（IEEE 802.15.9ごとに新しいキー管理プロトコルIDを定義することにより、IPアドレスなしでCOAP-EAPを輸送するサポートを提供する場合があります。
In CoAP-EAP, there is no nonce exchange to provide freshness to the keys derived from the MSK. The MSKs and EMSKs are fresh key material per [RFC5247]. Since only one authentication is established per EAP authenticator, there is no need to generate additional key material. If a new MSK is required, a re-authentication can be done by running the process again or using a more lightweight EAP method to derive additional key material as elaborated in Section 3.3.
Coap-eapでは、MSKから派生したキーに新鮮さを提供する非CEエクスチェンジはありません。MSKとEMSKは、[RFC5247]ごとに新鮮なキーマテリアルです。EAP Authenticatorごとに1つの認証が確立されるため、追加のキーマテリアルを生成する必要はありません。新しいMSKが必要な場合、プロセスを再度実行するか、より軽量のEAPメソッドを使用してセクション3.3で詳しく説明した追加のキーマテリアルを導き出すことで、再認証を行うことができます。
According to [RFC6677], channel binding, as related to EAP, is sent through the EAP method supporting it.
[RFC6677]によると、EAPに関連するチャネル結合は、それをサポートするEAPメソッドを介して送信されます。
To satisfy the requirements of this document, the EAP lower-layer identifier for CoAP-EAP (10, as assigned by IANA; see Section 9.4) needs to be sent, in the EAP Lower-Layer Attribute if RADIUS is used.
このドキュメントの要件を満たすために、radiusが使用されている場合は、EAP低層属性で、CoAP-EAPのEAP低層識別子（IANAによって割り当てられた10、セクション9.4を参照）を送信する必要があります。
In the authentication process, it is possible for an entity to forge messages to generate denial-of-service (DoS) attacks on any of the entities involved. For instance, an attacker can forge multiple initial messages to start an authentication (Step 0 in Figure 3) with the EAP authenticator as if they were sent by different EAP peers. Consequently, the EAP authenticator will start an authentication process for each message received in Step 0, sending the EAP-Req/Id (Step 1).
認証プロセスでは、エンティティがメッセージを作成して、関係するエンティティのいずれかに対するサービス拒否（DOS）攻撃を生成することができます。たとえば、攻撃者は、複数の初期メッセージを偽造して、EAP認証器を使用して認証を開始し（図3のステップ0）、まるで異なるEAPピアによって送信されたかのようになります。その結果、EAP認証器は、ステップ0で受信した各メッセージの認証プロセスを開始し、EAP-REQ/ID（ステップ1）を送信します。
To minimize the effects of this DoS attack, it is RECOMMENDED that the EAP authenticator limit the rate at which it processes incoming messages in Step 0 to provide robustness against DoS attacks. The details of rate limiting are outside the scope of this specification. Nevertheless, the rate of these messages is also limited by the bandwidth available between the EAP peer and the EAP authenticator. This bandwidth will be especially limited in constrained links (e.g., Low-Power WANs (LPWANs)). Lastly, it is also RECOMMENDED to reduce at a minimum the state in the EAP authenticator at least until the EAP-Resp/Id is received by the EAP authenticator.
このDOS攻撃の影響を最小限に抑えるために、EAP認証器は、DOS攻撃に対して堅牢性を提供するために、ステップ0で着信メッセージを処理する速度を制限することをお勧めします。レート制限の詳細は、この仕様の範囲外です。それにもかかわらず、これらのメッセージのレートは、EAPピアとEAP認証器の間で利用可能な帯域幅によっても制限されています。この帯域幅は、制約されたリンクで特に制限されます（たとえば、低電力洗浄剤（LPWANS））。最後に、EAP-RESP/IDがEAP認証者によって受信されるまで、少なくともEAP認証器の状態を少なくとも削減することをお勧めします。
Another security-related concern is how to ensure that the EAP peer joining the security domain can trust the EAP authenticator. This issue is elaborated in [RFC5247]. In particular, the EAP peer knows it can trust the EAP authenticator because the key that is used to establish the security association is derived from the MSK. If the EAP authenticator has the MSK, it is because the AAA server of the EAP peer trusted the EAP authenticator.
別のセキュリティ関連の懸念は、セキュリティドメインに参加するEAPピアがEAP認証器を信頼できるようにする方法です。この問題は[RFC5247]で詳しく説明されています。特に、EAPピアは、セキュリティ協会の確立に使用されるキーはMSKから派生しているため、EAP認証器を信頼できることを知っています。EAP認証器にMSKがある場合、EAPピアのAAAサーバーがEAP認証器を信頼したためです。
IANA has created a new registry titled "CoAP-EAP Cipher Suites" under a new registry group named "CoAP-EAP". The registration procedures are "Specification Required", "Private Use", and "Standards Action with Expert Review" (see [RFC8126]), as shown in Table 1.
IANAは、「Coap-Eap」という名前の新しいレジストリグループの下で「Coap-eap cipher Suites」というタイトルの新しいレジストリを作成しました。登録手順は、表1に示すように、「仕様が必要」、「私的使用」、「専門家のレビューを伴う標準訴訟」（[RFC8126]を参照）です。
+===============+=====================================+
| 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 1: Registration Procedures for CoAP-EAP Cipher Suites
表1：Coap-eap暗号スイートの登録手順
The columns of the registry are Value, Algorithms, Description, and Reference, where Value is an integer and the other columns are text strings. The initial registrations are shown in Table 2.
レジストリの列は値、アルゴリズム、説明、および参照であり、値は整数であり、他の列はテキスト文字列です。最初の登録を表2に示します。
+=======+============+=============================+===========+
| Value | Algorithms | Description | Reference |
+=======+============+=============================+===========+
| 0 | 10, -16 | AES-CCM-16-64-128, SHA-256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
| 1 | 1, -16 | A128GCM, SHA-256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
| 2 | 3, -43 | A256GCM, SHA-384 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
| 3 | 24, -16 | ChaCha20/Poly1305, SHA-256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
| 4 | 24, -45 | ChaCha20/Poly1305, SHAKE256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
Table 2: CoAP-EAP Cipher Suites: Initial Registrations
表2：Coap-eap暗号スイート：初期登録
IANA has created a new registry titled "CoAP-EAP Information Elements" under a new registry group named "CoAP-EAP". The registration procedures are "Standards Action with Expert Review", "Private Use", "Specification Required", and "Experimental Use" (see [RFC8126]), as shown in Table 3.
IANAは、「coap-eap」という名前の新しいレジストリグループの下に「coap-eap情報要素」というタイトルの新しいレジストリを作成しました。登録手順は、表3に示すように、「専門家のレビューによる標準アクション」、「私的使用」、「必要な仕様」、および「実験的使用」（[RFC8126]を参照）です。
+================+=====================================+
| Range | Registration Procedures |
+================+=====================================+
| 0 to 23 | Standards Action with Expert Review |
+----------------+-------------------------------------+
| 24 to 49 | Private Use |
+----------------+-------------------------------------+
| 50 to 65000 | Specification Required |
+----------------+-------------------------------------+
| 65001 to 65535 | Experimental Use |
+----------------+-------------------------------------+
Table 3: Registration Procedures for CoAP-EAP Information Elements
表3：COAP-EAP情報要素の登録手順
The columns of the registry are Name, Label, CBOR Type, Description, and Reference, where Label is an integer and the other columns are text strings. The initial registrations are shown in Table 4.
レジストリの列は、名前、ラベル、CBORタイプ、説明、および参照であり、ラベルは整数であり、他の列はテキスト文字列です。最初の登録を表4に示します。
+==================+=======+========+===============+===========+
| Name | Label | CBOR | Description | Reference |
| | | Type | | |
+==================+=======+========+===============+===========+
| Cipher Suite | 1 | CBOR | List of the | RFC 9820 |
| | | Array | proposed or | |
| | | | selected COSE | |
| | | | algorithms | |
| | | | for OSCORE | |
+------------------+-------+--------+---------------+-----------+
| RID-C | 2 | Byte | Contains the | RFC 9820 |
| | | String | Recipient ID | |
| | | | of the EAP | |
| | | | authenticator | |
+------------------+-------+--------+---------------+-----------+
| RID-I | 3 | Byte | Contains the | RFC 9820 |
| | | String | Recipient ID | |
| | | | of the EAP | |
| | | | peer | |
+------------------+-------+--------+---------------+-----------+
| Session-Lifetime | 4 | uint | Contains the | RFC 9820 |
| | | | time that the | |
| | | | session is | |
| | | | valid, in | |
| | | | seconds | |
+------------------+-------+--------+---------------+-----------+
Table 4: CoAP-EAP Information Elements: Initial Registrations
表4：COAP-EAP情報要素：初期登録
IANA has added the well-known URI "coap-eap" to the "Well-Known URIs" registry under the "Well-Known URIs" registry group defined by [RFC8615].
IANAは、[RFC8615]で定義された「よく知られているURIS」レジストリグループの下にある「よく知られているURIS」レジストリに、よく知られているURI「Coap-eap」を追加しました。
URI Suffix:
URIサフィックス：
coap-eap
coap-eap
Reference:
参照：
RFC 9820
RFC 9820
Status:
状態：
permanent
永続
Change Controller:
Change Controller：
IETF
IETF
IANA has added the identifier "CoAP-EAP" to the "EAP Lower Layers" registry (defined by [RFC6677]) under the "Extensible Authentication Protocol (EAP) Registry".
IANAは、「拡張可能な認証プロトコル（EAP）レジストリ」の下で、「EAP下層層」レジストリ（[RFC6677]で定義）に識別子「Coap-Eap」を追加しました。
Value:
値：
10
10
Lower Layer:
下層：
CoAP-EAP
coap-eap
Reference:
参照：
RFC 9820
RFC 9820
IANA has added the media type "application/coap-eap" to the "Media Types" registry. Section 4 defines the format.
IANAは、メディアタイプの「アプリケーション/Coap-Eap」を「メディアタイプ」レジストリに追加しました。セクション4では、形式を定義します。
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
coap-eap
coap-eap
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
binary
バイナリ
Security considerations:
セキュリティ上の考慮事項：
See Section 8 of RFC 9820.
RFC 9820のセクション8を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9820
RFC 9820
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 and email address to contact for further information:
詳細については、人とメールアドレスをお問い合わせください。
ace@ietf.org
ace@ietf.org
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Author:
著者：
See the "Authors' Addresses" section of RFC 9820.
RFC 9820の「著者のアドレス」セクションを参照してください。
Change Controller:
Change Controller：
IETF
IETF
IANA has added the media type "application/coap-eap" to the "CoAP Content-Formats" registry under the "Constrained RESTful Environments (CoRE) Parameters" registry group, following the specification in Section 12.3 of [RFC7252].
IANAは、[RFC7252]のセクション12.3の仕様に従って、「制約付きRESTFUL環境（CORE）パラメーター（CORE）パラメーター」レジストリグループの下で、メディアタイプの「アプリケーション/COAP-EAP」を「COAPコンテンツフォーマット」レジストリに追加しました。
+======================+==================+=====+===========+
| Media Type | Content Encoding | ID | Reference |
+======================+==================+=====+===========+
| application/coap-eap | - | 269 | RFC 9820 |
+----------------------+------------------+-----+-----------+
Table 5: CoAP Content-Formats Registry
表5：Coap Content-Formatsレジストリ
IANA has added the resource type "core.coap-eap" to the "Resource Type (rt=) Link Target Attribute Values" registry under the "Constrained RESTful Environments (CoRE) Parameters" registry group.
IANAは、「constreaded Restful環境（core）パラメーター」レジストリグループの下で、「リソースタイプ（rt =）リンクターゲット属性値」レジストリにリソースタイプ「core.coap-eap」を追加しました。
+===============+===================+===========+
| Value | Description | Reference |
+===============+===================+===========+
| core.coap-eap | CoAP-EAP resource | RFC 9820 |
+---------------+-------------------+-----------+
Table 6: Resource Type (rt=) Link Target Attribute Values Registry
表6：リソースタイプ（rt =）リンクターゲット属性値レジストリ
The IANA registries established in this document apply the "Specification Required", "Private Use", "Standards Action with Expert Review", and "Experimental Use" policies. (See also [RFC8126].) This section provides general guidelines for what experts should focus on, but as they are designated experts for a reason, they should be granted flexibility.
このドキュメントで確立されたIANAレジストリは、「必要な仕様」、「私的使用」、「専門家のレビューを伴う標準訴訟」、および「実験的使用」ポリシーを適用します。（[RFC8126]も参照してください。）このセクションでは、専門家が焦点を当てるべき一般的なガイドラインを提供しますが、理由で専門家に指定されているため、柔軟性を認められるべきです。
* When defining the use of CoAP-EAP Information Elements (IEs), experts are expected to evaluate how the values are defined, their scope, and whether they align with CoAP-EAP's functionality and constraints. They are expected to assess whether the values are clear, well structured, and follow CoAP and CoAP-EAP conventions, such as concise encoding for constrained environments. They should ensure that these IEs can seamlessly integrate with existing CoAP implementations and extensions. Experts are also expected to verify that IE values are protected from unauthorized modification or misuse during transmission.
* Coap-Eap情報要素（IE）の使用を定義する場合、専門家は、値の定義方法、範囲、およびCoap-Eapの機能と制約と一致するかどうかを評価することが期待されます。彼らは、値が明確で十分に構造化されているかどうかを評価し、制約された環境のための簡潔なエンコードなど、COAPおよびCOAP-EAPの規則に従うことが期待されています。これらは、これらのIEが既存のCOAP実装および拡張機能とシームレスに統合できるようにする必要があります。また、専門家は、IE値が送信中の不正な変更または誤用から保護されていることを確認することも期待されています。
* When adding new cipher suites, experts must ensure that algorithm values are sourced from the appropriate registry when required. They should also consider seeking input from relevant IETF working groups regarding the accuracy of registered parameters.
* 新しい暗号スイートを追加する場合、専門家は、必要に応じて適切なレジストリからアルゴリズム値が供給されるようにする必要があります。また、登録されたパラメーターの精度に関して、関連するIETFワーキンググループから入力を求めることを検討する必要があります。
[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>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>.
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-
Binding Support for Extensible Authentication Protocol
(EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012,
<https://www.rfc-editor.org/info/rfc6677>.
[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>.
[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>.
[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>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
[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>.
[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>.
[CoAP-EAP] Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP-
Based Bootstrapping Service for the Internet of Things",
Sensors, vol. 16, no. 3, DOI 10.3390/s16030358, 2016,
<https://www.mdpi.com/1424-8220/16/3/358>.
[EAP-EDHOC]
Garcia-Carrillo, D., Marin-Lopez, R., Selander, G., Preuß
Mattsson, J., and F. Lopez-Gomez, "Using the Extensible
Authentication Protocol (EAP) with Ephemeral Diffie-
Hellman over COSE (EDHOC)", Work in Progress, Internet-
Draft, draft-ietf-emu-eap-edhoc-05, 30 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-
edhoc-05>.
[EAP-Framework-IoT]
Sethi, M. and T. Aura, "Secure Network Access
Authentication for IoT Devices: EAP Framework vs.
Individual Protocols", IEEE Communications Standards
Magazine, vol. 5, no. 3, pp. 34-39,
DOI 10.1109/MCOMSTD.201.2000088, 2021,
<https://ieeexplore.ieee.org/document/9579387>.
[IEEE802159]
IEEE, "IEEE Standard for Transport of Key Management
Protocol (KMP) Datagrams", IEEE Std 802.15.9-2021,
DOI 10.1109/IEEESTD.2022.9690134, January 2022,
<https://doi.org/10.1109/IEEESTD.2022.9690134>.
[LO-CoAP-EAP]
Garcia-Carrillo, D., Marin-Lopez, R., Kandasamy, A., and
A. Pelov, "A CoAP-Based Network Access Authentication
Service for Low-Power Wide Area Networks: LO-CoAP-EAP",
Sensors, vol. 17, no. 11, DOI 10.3390/s17112646, 2017,
<https://www.mdpi.com/1424-8220/17/11/2646>.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March
2005, <https://www.rfc-editor.org/info/rfc4017>.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137,
DOI 10.17487/RFC4137, August 2005,
<https://www.rfc-editor.org/info/rfc4137>.
[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity Modules
(EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
<https://www.rfc-editor.org/info/rfc4186>.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,
<https://www.rfc-editor.org/info/rfc4764>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication
Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
RFC 5433, DOI 10.17487/RFC5433, February 2009,
<https://www.rfc-editor.org/info/rfc5433>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009,
<https://www.rfc-editor.org/info/rfc5448>.
[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>.
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed.,
"EAP Extensions for the EAP Re-authentication Protocol
(ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012,
<https://www.rfc-editor.org/info/rfc6696>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
RADIUS Attribute, Binding, Profiles, Name Identifier
Format, and Confirmation Methods for the Security
Assertion Markup Language (SAML)", RFC 7833,
DOI 10.17487/RFC7833, May 2016,
<https://www.rfc-editor.org/info/rfc7833>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[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>.
[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>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/info/rfc8824>.
[RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M.
Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
RFC 9031, DOI 10.17487/RFC9031, May 2021,
<https://www.rfc-editor.org/info/rfc9031>.
[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>.
[RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
Authentication for EAP (EAP-NOOB)", RFC 9140,
DOI 10.17487/RFC9140, December 2021,
<https://www.rfc-editor.org/info/rfc9140>.
[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>.
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[THREAD] Kumar, S. and E. Dijk, "Thread 1.4 Features White Paper",
September 2024,
<https://www.threadgroup.org/Portals/0/Documents/
Thread_1.4_Features_White_Paper_September_2024.pdf>.
[TS133.501]
ETSI, "5G; Security architecture and procedures for 5G
System", V18.9.0, ETSI TS 133 501, April 2025,
<https://www.etsi.org/deliver/
etsi_ts/133500_133599/133501/18.09.00_60/
ts_133501v180900p.pdf>.
CoAP-EAP makes it possible to derive a Pre-Shared Key (PSK) from the MSK to allow (D)TLS PSK-based authentication between the EAP peer and the EAP authenticator instead of using OSCORE. In the case of using (D)TLS to establish a security association, there is a limitation on the use of intermediaries between the EAP peer and the EAP authenticator, as (D)TLS breaks the end-to-end communications when using intermediaries such as proxies.
COAP-EAPは、MSKから事前共有キー（PSK）を導き出し、OSCOREを使用する代わりにEAPピアとEAP認証器の間のTLS PSKベースの認証を許可することを可能にします。（d）TLSを使用してセキュリティ協会を確立する場合、（d）TLSは、プロキシなどの仲介者を使用するときにエンドツーエンドの通信を破るため、EAPピアとEAP認証器の間で仲介者の使用に制限があります。
Figure 9 shows the last steps of the flow of operation for CoAP-EAP when (D)TLS is used to protect the communication between the EAP peer and the EAP authenticator using the keying material exported by the EAP authentication. The general flow is essentially the same as in the case of OSCORE, except that DTLS negotiation is established in Step 7. Once DTLS negotiation has finished successfully, the EAP peer is granted access to the domain. Step 7 MUST be interpreted by the EAP peer as an alternate success indication, which will end up with the MSK and the DTLS_PSK derivation for the (D)TLS authentication based on the PSK.
図9は、EAPピアとEAP認証によってエクスポートされたキーイング材料を使用してEAPピアとEAP認証器の間の通信を保護するために（d）TLSが使用された場合、Coap-Eapの動作流の最後のステップを示しています。一般的なフローは、DTLS交渉がステップ7で確立されることを除いて、OSCOREの場合と本質的に同じです。DTLS交渉が成功すると、EAPピアはドメインへのアクセスを許可されます。ステップ7は、PSKに基づいた（d）TLS認証のMSKとDTLS_PSK派生に最終的に行われる代替成功指示としてEAPピアによって解釈される必要があります。
EAP peer EAP authenticator
------------- -------------
...
| 2.01 Created Location-Path [/a/eap/(n)] |
| Payload(EAP-X-Resp) |
6)|---------------------------------------->|
| | MSK
| (D)TLS 1.3 Client Hello | |
MSK 7)|<----------------------------------------| v
| | | DTLS_PSK
v |============= DTLS handshake ============|
DTLS_PSK | |
<-- Protected with (D)TLS -->
Figure 9: CoAP-EAP Flow of Operation with DTLS
図9：DTLSを使用した動作のcoap-eap流量
According to [RFC8446], the provision of the PSK out of band also requires the provision of the KDF hash algorithm and the PSK identity. To simplify the design in CoAP-EAP, the KDF hash algorithm can be included in the list of cipher suites exchanged in Steps 1 and 2 (Figure 8) if one wants to use DTLS instead of OSCORE. For the same reason, the PSK identity is derived from RID-C || RID-I as defined in Appendix A.1.
[RFC8446]によれば、BANDのPSKの提供には、KDFハッシュアルゴリズムとPSKアイデンティティの提供も必要です。COAP-EAPの設計を簡素化するために、OSCOREの代わりにDTLSを使用したい場合は、手順1および2（図8）で交換された暗号スイートのリストにKDFハッシュアルゴリズムを含めることができます。同じ理由で、PSKアイデンティティはRID-Cから派生しています||付録A.1で定義されているRID-I。
Analogous to how the cipher suite is negotiated for OSCORE (Section 6.1), the EAP authenticator sends a list, in decreasing order of preference, with the identifiers of the hash algorithms supported (Step 1). In the response, the EAP peer sends its choice.
Cipher SuiteがOSCORE（セクション6.1）のためにネゴシエートされる方法に類似しているため、EAP Authenticatorは、ハッシュアルゴリズムの識別子がサポートされている（ステップ1）を使用して、好みの順序を減らしてリストを送信します。応答では、EAPピアはその選択を送信します。
This list is included in the payload after the EAP message with a CBOR array that contains the cipher suites. This CBOR array is enclosed as one of the elements of the CBOR Object used for transporting information in CoAP-EAP (see Section 5). An example of how the fields are arranged in the CoAP payload can be seen in Figure 7.
このリストは、暗号スイートを含むCBORアレイを備えたEAPメッセージの後、ペイロードに含まれています。このCBORアレイは、COAP-EAPで情報の輸送に使用されるCBORオブジェクトの要素の1つとして囲まれています（セクション5を参照）。COAPペイロードにフィールドがどのように配置されているかの例を図7に示すことができます。
If there is no CBOR array specifying the cipher suites, the default cipher suites are applied. If the EAP authenticator sends a restricted list of cipher suites that can be accepted, it MUST include the default value 0, since it is mandatory to implement. The EAP peer will have at least that option available.
暗号スイートを指定するCBORアレイがない場合、デフォルトの暗号スイートが適用されます。EAP Authenticatorが受け入れることができる暗号スイートの制限付きリストを送信する場合、実装することが必須であるため、デフォルト値0を含める必要があります。EAPピアには、少なくともそのオプションが利用可能になります。
For DTLS, the negotiated cipher suite is used to determine the hash function to be used to derive the "DTLS_PSK" from the MSK. The following hash algorithms are considered in cases where the specification includes DTLS support in the future:
DTLSの場合、ネゴシエートされた暗号スイートを使用して、MSKから「DTLS_PSK」を導出するために使用されるハッシュ関数を決定します。次のハッシュアルゴリズムは、仕様に将来のDTLSサポートが含まれている場合に考慮されます。
* 5) TLS_SHA256
* 5）TLS_SHA256
* 6) TLS_SHA384
* 6）TLS_SHA384
* 7) TLS_SHA512
* 7）TLS_SHA512
The inclusion of these values, apart from indicating the hash algorithm, indicates that the EAP authenticator intends to establish an OSCORE security association or a DTLS security association after the authentication is completed. If both options appear in the cipher suite negotiation, the OSCORE security association will be preferred over DTLS.
これらの値を含めることは、ハッシュアルゴリズムを示すこととは別に、EAP認証器が認証が完了した後にOSCOREセキュリティ協会またはDTLSセキュリティ協会を確立するつもりであることを示しています。両方のオプションが暗号スイートの交渉に表示される場合、OSCOREセキュリティ協会はDTLよりも優先されます。
To enable DTLS after an EAP authentication, Identity and the PSK for DTLS are defined. Identity in this case is generated by concatenating the exchanged Sender ID and the Recipient ID.
EAP認証後にDTLを有効にするには、DTLのIDとPSKが定義されています。この場合のIDは、交換された送信者IDと受信者IDを連結することにより生成されます。
CoAP-EAP PSK Identity = RID-C || RID-I
It is also possible to derive a PSK for DTLS [RFC9147], referred to here as "DTLS_PSK", from the MSK between both the EAP peer and EAP authenticator if required. The length of the DTLS_PSK will depend on the cipher suite. To have keying material with sufficient length, a key of 32 bytes is derived that can be truncated later if needed:
また、必要に応じて、EAPピアとEAP認証器の両方のMSKから、ここで「DTLS_PSK」と呼ばれるDTLS [RFC9147]のPSKを導出することも可能です。DTLS_PSKの長さは、Cipherスイートに依存します。十分な長さのキーイング材料を使用するには、必要に応じて後で切り捨てられる32バイトのキーが導出されます。
DTLS_PSK = KDF(MSK, "CoAP-EAP DTLS_PSK", length)
where:
ただし：
* The MSK is exported by the EAP method.
* MSKはEAPメソッドによってエクスポートされます。
* "CoAP-EAP DTLS_PSK" is the ASCII code representation of the non-NULL-terminated string (excluding the double quotes around it).
* 「coap-eap dtls_psk」は、非末端端端の文字列のASCIIコード表現です（その周りの二重引用符は除く）。
* length is the size of the output key material.
* 長さは、出力キーマテリアルのサイズです。
Similarly to the example in Appendix A.1, where a PSK for DTLS is derived, it is possible to provide key material to different link layers after the CoAP-EAP authentication is complete.
付録A.1の例と同様に、DTLSのPSKが派生している場合、COAP-EAP認証が完了した後、異なるリンクレイヤーに重要な資料を提供することができます。
For example, CoAP-EAP could be used to derive the PSK required to run the Constrained Join Protocol (CoJP) for IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) [RFC9031]. ("TSCH" stands for "Time-Slotted Channel Hopping".)
たとえば、COAP-EAPを使用して、IEEE 802.15.4E（6TISCH）[RFC9031]のTSCHモードで、IPv6の制約付き結合プロトコル（COJP）を実行するために必要なPSKを導出することができます。（「TSCH」は「タイムスロットチャンネルホッピング」を表しています。）
Another example would be when a shared Network Key is required by the devices that join a network. An example of this Network Key can be found in the THREAD protocol [THREAD]. After CoAP-EAP execution, a security association based on OSCORE protects any exchange between the EAP peer and the EAP authenticator. This security association can be used for distributing the Network Key securely and other required parameters. How the Network Key is distributed after a successful CoAP-EAP authentication is outside the scope of this document.
別の例は、ネットワークに参加するデバイスによって共有ネットワークキーが必要な場合です。このネットワークキーの例は、スレッドプロトコル[スレッド]に記載されています。Coap-Eapの実行後、OSCOREに基づくセキュリティ協会は、EAPピアとEAP認証器の間の交換を保護します。このセキュリティ協会は、ネットワークキーを安全に配布し、その他の必要なパラメーターを配布するために使用できます。COAP-EAP認証が成功した後のネットワークキーの配布方法は、このドキュメントの範囲外です。
How a particular link-layer technology uses the MSK to derive further key material for protecting the link layer or uses OSCORE protection to distribute key material is outside the scope of this document.
特定のリンク層テクノロジーがMSKを使用して、リンクレイヤーを保護するためのさらなる重要な材料を導き出す方法、またはOSCORE Protectionを使用してキーマテリアルを配布する方法は、このドキュメントの範囲外です。
In IoT networks, for an EAP peer to act as a trustworthy entity within a security domain, certain key material needs to be shared between the EAP peer and the EAP authenticator.
IoTネットワークでは、EAPピアがセキュリティドメイン内の信頼できるエンティティとして機能するためには、EAPピアとEAP認証器の間で特定の重要な資料を共有する必要があります。
Next, examples of different use case scenarios will be elaborated on as related to the usage of CoAP-EAP.
次に、さまざまなユースケースシナリオの例が、CoAP-EAPの使用に関連するASについて詳しく説明されます。
Generally, four entities are involved:
一般的に、4つのエンティティが関与しています。
* Two EAP peers (A and B).
* 2つのEAPピア（AとB）。
* One EAP authenticator (C). The EAP authenticator manages a domain where EAP peers can be deployed. In IoT networks, it can be considered a more powerful machine than the EAP peers.
* 1つのEAP Authenticator（C）。EAP認証器は、EAPピアを展開できるドメインを管理します。IoTネットワークでは、EAPピアよりも強力なマシンと見なすことができます。
* One AAA server. Optional. The AAA server is not constrained. Here, the EAP authenticator is operating in pass-through mode.
* 1つのAAAサーバー。オプション。AAAサーバーは制約されていません。ここで、EAP認証器はパススルーモードで動作しています。
Generally, any EAP peer wanting to join the domain managed by the EAP authenticator MUST perform a CoAP-EAP authentication with the EAP authenticator (C). This authentication MAY involve an external AAA server. This means that the EAP peers (A and B), once deployed, will run CoAP-EAP once, as a bootstrapping phase, to establish a security association with C. Moreover, any other entity that wants to join and establish communications with EAP peers under C's domain must also do the same.
一般に、EAP認証器が管理するドメインに参加したいEAPピアは、EAP認証器（c）を使用してCoap-eap認証を実行する必要があります。この認証には、外部AAAサーバーが含まれる場合があります。これは、EAPピア（AとB）が展開されると、COAP-EAPをブートストラップフェーズとして一度実行し、Cとのセキュリティ関連を確立することを意味します。さらに、Cのドメインの下でEAPピアとのコミュニケーションを参加および確立したい他のエンティティも同じことをしなければなりません。
By using EAP, the flexibility of having different types of credentials can be achieved. For instance, if a device that is not battery dependent and not very constrained is available, a heavier authentication method could be used. With varied EAP peers and networks, authentication methods that are more lightweight (e.g., EAP-NOOB [RFC9140], EAP-AKA' [RFC5448], EAP-PSK [RFC4764], EAP-EDHOC [EAP-EDHOC], etc.) and are able to adapt to different types of devices according to organization policies or device capabilities might need to be used.
EAPを使用することにより、さまざまなタイプの資格情報を持つことの柔軟性を実現できます。たとえば、バッテリーに依存せず、非常に制約されていないデバイスが利用可能な場合、より重い認証方法を使用できます。さまざまなEAPピアとネットワークを使用して、より軽量の認証方法（例：EAP-NOOB [RFC9140]、EAP-AKA '[RFC5448]、EAP-PSK [RFC4764]、EAP-EDHOC [EAP-EDHOC]など）、および組織の場合は、さまざまな種類のデバイスを使用することができます。
When using ACE, the process of client registration and provisioning of credentials to the client is not specified. The process of client registration and provisioning can be achieved using CoAP-EAP. Once the process of authentication with EAP is completed, the fresh key material is shared between the EAP peer and the EAP authenticator. With ACE, the EAP authenticator and the Authorization Server (AS) can be co-located.
ACEを使用する場合、クライアント登録のプロセスとクライアントへの資格情報のプロビジョニングは指定されていません。クライアントの登録とプロビジョニングのプロセスは、COAP-EAPを使用して達成できます。EAPを使用した認証プロセスが完了すると、EAPピアとEAP認証器の間で新鮮なキー資料が共有されます。ACEを使用すると、EAP AuthenticatorとAuthorization Server（AS）を共同で配置できます。
Next, a general way to exemplify how client registration can be performed using CoAP-EAP is presented, to allow two EAP peers (A and B) to communicate and interact after a successful client registration.
次に、CoAP-EAPを使用してクライアントの登録をどのように実行できるかを実証する一般的な方法を提示し、2人のEAPピア（AとB）がクライアント登録を成功させた後に通信および対話できるようにします。
EAP peer A wants to communicate with EAP peer B (e.g., to activate a light switch). The overall process is divided into three phases.
EAPピアAは、EAPピアBと通信したい（例：ライトスイッチをアクティブにするため）。全体のプロセスは3つのフェーズに分かれています。
* In the first phase, EAP peer A does not yet belong to EAP authenticator C's domain. Then, it communicates with C and authenticates with CoAP-EAP, which, optionally, communicates with the AAA server to complete the authentication process. If the authentication is successful, a fresh MSK is shared between C and EAP peer A. This key material allows EAP peer A to establish a security association with C. Some authorization information may also be provided in this step. If EAP is used in standalone mode, the AS itself, having information about the devices, can be the entity providing said authorization information.
* 第1フェーズでは、EAP Peer AはまだEAP Authenticator Cのドメインに属していません。次に、Cと通信し、CoAp-Eapで認証されます。これは、オプションでAAAサーバーと通信して認証プロセスを完了します。認証が成功した場合、CとEAPピアAの間で新鮮なMSKが共有されます。この重要な資料により、EAPピアAはCとセキュリティ関連を確立できます。EAPがスタンドアロンモードで使用されている場合、デバイスに関する情報を持つように、そのように、その認可情報を提供するエンティティになります。
If authentication and authorization are correct, EAP peer A is enrolled in EAP authenticator C's domain for some period of time. In particular, [RFC5247] recommends 8 hours, though the entity providing the authorization information can establish this lifetime. In the same manner, B needs to perform the same process with CoAP-EAP to be part of EAP authenticator C's domain.
認証と承認が正しい場合、EAPピアAは、EAP Authenticator Cのドメインにしばらく登録されています。特に、[RFC5247]は8時間を推奨しますが、認可情報を提供するエンティティはこの寿命を確立できます。同様に、BはEAP Authenticator Cのドメインの一部となるために、CoAP-Eapで同じプロセスを実行する必要があります。
* In the second phase, when EAP peer A wants to talk to EAP peer B, it contacts EAP authenticator C for authorization to access EAP peer B and obtain all the required information to do that securely (e.g., keys, tokens, authorization information, etc.). This phase does NOT require the usage of CoAP-EAP. The details of this phase are outside the scope of this document; the ACE framework is used for this purpose. See [RFC9200].
* 第2フェーズでは、EAP Peer AがEAPピアBと話をしたい場合、EAP Authenticator Cに連絡してEAPピアBにアクセスし、それを安全に行うために必要なすべての情報を取得します（たとえば、キー、トークン、承認情報など）。このフェーズでは、CoAP-EAPの使用を必要としません。このフェーズの詳細は、このドキュメントの範囲外です。ACEフレームワークは、この目的に使用されます。[RFC9200]を参照してください。
* In the third phase, EAP peer A can access EAP peer B with the credentials and information obtained from EAP authenticator C during the second phase. This access can be repeated without contacting the EAP authenticator, as long as the credentials given to A are still valid. The details of this phase are outside the scope of this document.
* 第3フェーズでは、EAP Peer Aは、第2フェーズでEAP Authenticator Cから取得した資格情報と情報を使用してEAPピアBにアクセスできます。このアクセスは、Aに与えられた資格情報がまだ有効である限り、EAP認証器に連絡することなく繰り返すことができます。このフェーズの詳細は、このドキュメントの範囲外です。
It is worth noting that to join EAP authenticator C's domain, the first phase (authentication via CoAP-EAP) is required. Once it is performed successfully, the communications are local to EAP authenticator C's domain and there is no need to perform a new EAP authentication as long as the key material is still valid. When the keys are about to expire, the EAP peer can engage in a re-authentication to renew the key material, as explained in Section 3.3.
EAP Authenticator Cのドメインに参加するには、最初のフェーズ（CoAP-EAP経由の認証）が必要であることに注意してください。正常に実行されると、通信はEAP Authenticator Cのドメインにローカルであり、重要な資料がまだ有効である限り、新しいEAP認証を実行する必要はありません。セクション3.3で説明されているように、キーが期限切れになっている場合、EAPピアは、キーマテリアルを更新するための再認証に従事することができます。
A device (A) of the domain acme.org uses a specific kind of credential and intends to join the um.es domain. This user does not belong to this domain, for which it first performs a client registration using CoAP-EAP. To do this, it interacts with the EAP authenticator's domain, which in turn communicates with a AAA infrastructure (acting as a AAA client). Then, the local AAA server communicates with the home AAA server to complete the authentication. This way, the device can be considered as a trustworthy entity within EAP authenticator C's domain. In this scenario, the AS, in the role of the EAP authenticator, receives the key material from the AAA infrastructure.
ドメインacme.orgのデバイス（a）は、特定の種類の資格情報を使用し、um.esドメインに参加するつもりです。このユーザーはこのドメインに属していません。このドメインは、最初にCOAP-EAPを使用してクライアント登録を実行します。これを行うために、EAP Authenticatorのドメインと対話し、AAAインフラストラクチャ（AAAクライアントとして機能する）と通信します。次に、ローカルAAAサーバーはホームAAAサーバーと通信して認証を完了します。これにより、このデバイスは、EAP Authenticator Cのドメイン内の信頼できるエンティティと見なすことができます。このシナリオでは、ASがEAP認証器の役割において、AAAインフラストラクチャから重要な資料を受け取ります。
In this scenario, a university campus has several faculty buildings, where each building has its criteria or policies in place to manage EAP peers under an AS. All buildings belong to the same domain (e.g., um.es). All these buildings are managed with a AAA infrastructure. A new device (A) with credentials from the domain (e.g., um.es) will be able to perform the device registration with an EAP authenticator (C) of any building if they are managed by the same general domain.
このシナリオでは、大学のキャンパスにはいくつかの教員の建物があり、各建物にはASの下でEAPピアを管理するための基準またはポリシーがあります。すべての建物は同じドメイン（UM.ESなど）に属します。これらの建物はすべて、AAAインフラストラクチャで管理されています。ドメインからの資格情報（UM.ESなど）を備えた新しいデバイス（a）は、同じ一般ドメインによって管理されている場合、任意の建物のEAP認証器（c）を使用してデバイス登録を実行できます。
In another case, without a AAA infrastructure, with an EAP authenticator that has co-located the EAP server, and using EAP standalone mode, all the devices can be managed within the same domain locally. Client registration of an EAP peer (A) with a Controller (C) can also be performed in the same manner.
別のケースでは、AAAインフラストラクチャがなければ、EAPサーバーを共同で開催したEAP認証器を備えており、EAPスタンドアロンモードを使用して、すべてのデバイスを同じドメイン内でローカルで管理できます。EAPピア（a）のクライアント登録コントローラー（c）も同じ方法で実行できます。
One of the first steps for an EAP peer is to perform the authentication to gain access to the network. To do so, the device must first be authenticated and granted authorization to gain access to the network. Additionally, security parameters such as credentials can be derived from the authentication process, allowing the trustworthy operation of the EAP peer in a particular network by joining the security domain. By using EAP, this can be achieved with flexibility and scalability, because of the different EAP methods available and the ability to rely on AAA infrastructures if needed to support multi-domain scenarios, which is a key feature when the EAP peers deployed under the same security domain belong, for example, to different organizations.
EAPピアの最初のステップの1つは、認証を実行してネットワークにアクセスすることです。そのためには、ネットワークへのアクセスを得るために、最初にデバイスを認証し、許可を付与する必要があります。さらに、資格情報などのセキュリティパラメーターは、認証プロセスから導き出され、セキュリティドメインに参加して特定のネットワークでEAPピアの信頼できる操作を可能にします。EAPを使用することにより、これは、利用可能なさまざまなEAPメソッドと、必要に応じてマルチドメインシナリオをサポートするために必要な場合にAAAインフラストラクチャに依存する能力があるため、柔軟性とスケーラビリティで実現できます。
The following two cases apply to the process of joining a network: 1) the node has an IPv6 address (e.g., link-local IPv6 or IPv6 global address) and 2) the node does not have an IPv6 address.
次の2つのケースは、ネットワークの参加プロセスに適用されます。1）ノードにはIPv6アドレス（リンクローカルIPv6またはIPv6グローバルアドレスなど）と2）ノードにはIPv6アドレスがありません。
In networks where the device is in place but no IP support is available until the EAP peer is authenticated, specific support for this EAP lower layer has to be defined to allow CoAP-EAP messages to be exchanged between the EAP peer and the EAP authenticator. For example, in IEEE 802.15.4 networks, a new Key Management Protocol (KMP) ID can be defined to add such support in the case of IEEE 802.15.9 [IEEE802159], where it can be assumed that the device has at least a link-layer IPv6 address.
EAPピアが認証されるまで、デバイスが設置されているがIPサポートが利用できないネットワークでは、EAPピアとEAP認証器の間でCOAP-EAPメッセージを交換できるようにするために、このEAP下層層の特定のサポートを定義する必要があります。たとえば、IEEE 802.15.4ネットワークでは、IEEE 802.15.9 [IEEE802159]の場合、新しいキー管理プロトコル（KMP）IDを定義するために定義することができます。この場合、デバイスには少なくともリンクレイヤーIPv6アドレスがあると仮定できます。
When the EAP peer intends to be admitted into the network, it would search for an entity that offers the CoAP-EAP service, be it directly via the EAP authenticator or through an intermediary (e.g., proxy). See Section 3.1.
EAPピアがネットワークに入院するつもりである場合、EAP認証器を介して、または仲介者（例：プロキシ）を介して、Coap-Eapサービスを提供するエンティティを検索します。セクション3.1を参照してください。
CoAP-EAP will run between the EAP peer and the EAP authenticator or through an intermediary entity such as a proxy, as happens in a mesh network, where the EAP authenticator could be placed one or more hops away from the EAP peer. In the case that a proxy participates in CoAP-EAP, it will be because it is already a trustworthy entity within the domain and communicates through a secure channel with the EAP authenticator, as illustrated by Figure 10.
COAP-EAPは、EAPピアとEAP認証器の間で、またはEAP認証器をEAPピアから1つ以上のホップ離して配置できるメッシュネットワークで発生するように、プロキシなどの仲介エンティティを介して実行されます。プロキシがCoap-Eapに参加している場合、図10に示すように、Domain内の信頼できるエンティティであり、EAP Authenticatorとの安全なチャネルを介して通信しているためです。
If the EAP peer cannot connect to the EAP authenticator directly, the EAP peer can follow the same process as that described in Section 3.6 to perform the authentication (i.e., can connect via an intermediary entity (e.g., proxy) that is already part of the network (already shares key material and communicates through a secure channel with the authenticator) and can aid in running CoAP-EAP).
EAPピアがEAP認証器に直接接続できない場合、EAPピアはセクション3.6で説明したプロセスと同じプロセスに従って認証を実行できます（つまり、ネットワークの一部である中間エンティティ（例えば、プロキシ）を介して接続できます（すでに主要な資料と信頼性チャネルを介して主要な材料と通信型を共有し、COAP-EAPを実行できます）。
When CoAP-EAP is completed and the OSCORE security association is established with the EAP authenticator, the EAP peer receives the local configuration parameters for the network (e.g., a Network Key) and can configure a global IPv6 address. Moreover, there is no need for an intermediary entity after a successful authentication.
COAP-EAPが完了し、OSCOREセキュリティ協会がEAP認証器と共に確立されると、EAPピアはネットワークのローカル構成パラメーター（ネットワークキーなど）を受信し、グローバルIPv6アドレスを構成できます。さらに、認証が成功した後、仲介エンティティは必要ありません。
For removal, if the EAP authenticator decides to remove a particular EAP peer from the network or the peer itself intends to leave, either the EAP peer or the EAP authenticator can directly send a DELETE command to explicitly express that the network access state is removed, and the device will no longer belong to the network. Thus, any state related to the EAP peer is removed in the EAP authenticator. Forced removal can be done by sending new specific key material to the devices that still belong to the network, excluding the removed device, following a model similar to CoJP for 6TiSCH [RFC9031]. The specifics on how this process is to be done are outside the scope of this document.
削除のために、EAP認証器がネットワークから特定のEAPピアを削除するか、ピア自体が離れることを意図している場合、EAPピアまたはEAP認証装置のいずれかが削除コマンドを直接送信して、ネットワークアクセス状態が削除され、デバイスがネットワークに属していないことを明示的に表現できます。したがって、EAPピアに関連する状態は、EAP認証器で削除されます。強制削除は、6tisch [RFC9031]のCOJPに類似したモデルに従って、削除されたデバイスを除く、まだネットワークに属するデバイスに新しい特定のキー資料を送信することで実行できます。このプロセスがどのように行われるかの詳細は、このドキュメントの範囲外です。
+-------+ +--------+ +--------------+
| EAP | | CoAP | | EAP |
| peer |<------>| proxy |<------------------------->| authenticator|
+-------+ CoAP +--------+ CoAP +--------------+
OSCORE/DTLS
<-- security association -->
Figure 10: CoAP-EAP Through CoAP Proxy
図10：COAP-EAPを介したCoap-Eap
Given that EAP is also used for network access authentication, this service can be adapted to other technologies -- for instance, to provide network access control to very constrained technologies (e.g., Long Range (LoRa) networks). The authors of [LO-CoAP-EAP] provide a study of a minimal version of CoAP-EAP for LPWANs, with interesting results. In this specific case, compression as provided by Static Context Header Compression (SCHC) for CoAP [RFC8824] can be leveraged.
EAPはネットワークアクセス認証にも使用されていることを考えると、このサービスは他のテクノロジーに適合させることができます。たとえば、非常に制約されたテクノロジー（長距離（LORA）ネットワークなどのネットワークアクセス制御を提供します。[lo-coap-eap]の著者は、LPWANのCoap-eapの最小限のバージョンの研究を提供し、興味深い結果をもたらします。この特定のケースでは、COAP [RFC8824]の静的コンテキストヘッダー圧縮（SCHC）によって提供される圧縮をレバレッジできます。
It is not uncommon that the infrastructure where the device is deployed and the services of the EAP peer are managed by different organizations. Therefore, in addition to the authentication for network access control, the possibility of a secondary authentication to access different services has to be considered. This process of authentication, for example, will provide the necessary key material to establish a secure channel and interact with the entity in charge of granting access to different services.
デバイスが展開され、EAPピアのサービスがさまざまな組織によって管理されているインフラストラクチャが珍しくありません。したがって、ネットワークアクセス制御の認証に加えて、異なるサービスにアクセスするための二次認証の可能性を考慮する必要があります。たとえば、この認証プロセスは、安全なチャネルを確立し、異なるサービスへのアクセスを許可するエンティティと対話するために必要な重要な資料を提供します。
In 5G, for example, consider primary and secondary authentication using EAP [TS133.501].
たとえば、5Gでは、EAP [TS133.501]を使用した一次および二次認証を検討してください。
We would like to thank the reviewers of this work: Paul Wouters, Heikki Vatiainen, Josh Howlett, Deb Cooley, Eliot Lear, Alan DeKok, Carsten Bormann, Mohit Sethi, Benjamin Kaduk, Christian Amsüss, John Preuß Mattsson, Göran Selander, Alexandre Petrescu, Pedro Moreno-Sanchez, and Eduardo Ingles-Sanchez.
この作品のレビュアーに感謝します：ポール・ウーターズ、ヘイキ・ヴァティアイネン、ジョシュ・ハウレット、デブ・クーリー、エリオット・リア、アラン・デコク、カルステン・ボルマン、モヒト・セティ、ベンジャミン・カドゥク、クリスチャン・アムズ、ジョン・プリューフ・マットソン、ジョン・セランダー、アレクサンドレ・セランドル、ペダルェ・エデンセル、Ingles-Sanchez。
We would also like to thank Gabriel Lopez-Millan for the first review of this document, Ivan Jimenez-Sanchez for the first proof-of-concept implementation of this idea, Julian Niklas Schimmelpfennig for the implementation of the Erbium-based IoT device implementation, and Daniel Menendez Gonzalez for the Python implementation.
また、このドキュメントの最初のレビュー、このアイデアの最初の概念実装についてのIvan Jimenez-Sanchez、エルビウムベースのIoTデバイス実装の実装のためのJulian Niklas Schimmelpfennig、およびDaniel Menendez GonzalezのPythonの実装のためのJulian Niklas Schimmelpfennigについて、Gabriel Lopez-Millanに感謝します。
Thanks also to Alexander Pelov and Laurent Toutain for their valuable comments, especially regarding the potential optimizations of CoAP-EAP.
また、特にCoap-Eapの潜在的な最適化に関する貴重なコメントをしてくれたAlexander PelovとLaurent Toutainにも感謝します。
This work was supported in part by Grant PID2020-112675RB-C44 funded by MCIN/AEI/10.13039/5011000011033 (ONOFRE-3-UMU) and in part by the H2020 EU project IoTCrawler under contract 779852.
この作業は、MCIN/AEI/10.13039/5011000011033（ONOFRE-3-UMU）によって資金提供されたGrant PID20202020-112675RB-C44によって、およびH2020 EUプロジェクトIoTcrawlerが契約779852に基づいて部分的にサポートされていました。
Rafa Marin-Lopez
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
30100 Murcia
Spain
Email: rafa@um.es
Dan Garcia-Carrillo
University of Oviedo
Calle Luis Ortiz Berrocal S/N, Edificio Polivalente
33203 Gijon Asturias
Spain
Email: garciadan@uniovi.es