[要約] RFC 8613は、制約のあるRESTful環境におけるオブジェクトセキュリティ（OSCORE）に関する仕様です。目的は、制約のあるデバイス間でのセキュアな通信を実現するためのプロトコルを提供することです。
Internet Engineering Task Force (IETF) G. Selander
Request for Comments: 8613 J. Mattsson
Updates: 7252 F. Palombini
Category: Standards Track Ericsson AB
ISSN: 2070-1721 L. Seitz
RISE
July 2019
Object Security for Constrained RESTful Environments (OSCORE)
制約付きRESTful環境のオブジェクトセキュリティ（OSCORE）
Abstract
概要
This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.
このドキュメントでは、CBOR Object Signing and Encryption（COSE）を使用して、Constrained Application Protocol（CoAP）のアプリケーション層を保護する方法であるConstrained RESTful Environments（OSCORE）のオブジェクトセキュリティを定義します。 OSCOREは、CoAPまたはCoAPマッピング可能なHTTPを使用して通信するエンドポイント間のエンドツーエンドの保護を提供します。 OSCOREは、さまざまなトランスポートプロトコル間の変換など、さまざまなプロキシ操作をサポートする制約のあるノードとネットワーク用に設計されています。
Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.
OSAPはCoAPのオプション機能ですが、CoAPオプション処理とIANA登録を変更します。したがって、このドキュメントはRFC 7252を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8613.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8613で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The OSCORE Option . . . . . . . . . . . . . . . . . . . . . . 8
3. The Security Context . . . . . . . . . . . . . . . . . . . . 8
3.1. Security Context Definition . . . . . . . . . . . . . . . 9
3.2. Establishment of Security Context Parameters . . . . . . 11
3.3. Requirements on the Security Context Parameters . . . . . 14
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 15
4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 16
4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 24
4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 25
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. ID Context and 'kid context' . . . . . . . . . . . . . . 27
5.2. AEAD Nonce . . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Additional Authenticated Data . . . . . . . . . . . . . . 30
6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 31
6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 32
6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 33
6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 33
7. Message Binding, Sequence Numbers, Freshness, and Replay
Protection . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 36
7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 36
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 37
7.5. Losing Part of the Context State . . . . . . . . . . . . 38
8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Protecting the Request . . . . . . . . . . . . . . . . . 39
8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 40
8.3. Protecting the Response . . . . . . . . . . . . . . . . . 41
8.4. Verifying the Response . . . . . . . . . . . . . . . . . 43
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 44
10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 45
11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 46
11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 46
11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 47
11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 48
11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 48
11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 48
11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 50
12. Security Considerations . . . . . . . . . . . . . . . . . . . 51
12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 51
12.2. Security Context Establishment . . . . . . . . . . . . . 52
12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 52
12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 53
12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 53
12.6. Cryptographic Considerations . . . . . . . . . . . . . . 53
12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 54
12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 54
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
13.1. COSE Header Parameters Registry . . . . . . . . . . . . 55
13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 55
13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 56
13.4. Header Field Registrations . . . . . . . . . . . . . . . 57
13.5. Media Type Registration . . . . . . . . . . . . . . . . 57
13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 58
13.7. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 58
13.8. Expert Review Instructions . . . . . . . . . . . . . . . 59
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
14.1. Normative References . . . . . . . . . . . . . . . . . . 60
14.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 65
A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 65
A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 66
Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 68
B.1. Security Context Derived Once . . . . . . . . . . . . . . 68
B.2. Security Context Derived Multiple Times . . . . . . . . . 70
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 75
C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 75
C.2. Test Vector 2: Key Derivation without Master Salt . . . . 77
C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 78
C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 80
C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 81
C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 82
C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 84
C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 85
Appendix D. Overview of Security Properties . . . . . . . . . . 86
D.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 86
D.2. Supporting Proxy Operations . . . . . . . . . . . . . . . 87
D.3. Protected Message Fields . . . . . . . . . . . . . . . . 87
D.4. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 88
D.5. Unprotected Message Fields . . . . . . . . . . . . . . . 89
Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 93
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
The Constrained Application Protocol (CoAP) [RFC7252] is a web transfer protocol designed for constrained nodes and networks [RFC7228]; CoAP may be mapped from HTTP [RFC8075]. CoAP specifies the use of proxies for scalability and efficiency and references DTLS [RFC6347] for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP proxies require DTLS or TLS [RFC8446] to be terminated at the proxy. Therefore, the proxy not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of, the message payload and metadata in transit between the endpoints. The proxy can also inject, delete, or reorder packets since they are no longer protected by (D)TLS.
制約付きアプリケーションプロトコル（CoAP）[RFC7252]は、制約付きノードとネットワーク[RFC7228]用に設計されたWeb転送プロトコルです。 CoAPはHTTP [RFC8075]からマッピングされる場合があります。 CoAPは、スケーラビリティと効率性のためにプロキシの使用を指定し、セキュリティのためにDTLS [RFC6347]を参照します。 CoAP-to-CoAP、HTTP-to-CoAP、およびCoAP-to-HTTPプロキシでは、プロキシでDTLSまたはTLS [RFC8446]を終端する必要があります。したがって、プロキシは、目的のプロキシ機能を実行するために必要なデータにアクセスできるだけでなく、エンドポイント間で転送中のメッセージペイロードとメタデータを傍受したり、操作したりすることもできます。プロキシは、パケットが（D）TLSによって保護されなくなったため、パケットを挿入、削除、または並べ替えることもできます。
This document defines the Object Security for Constrained RESTful Environments (OSCORE) security protocol, protecting CoAP and CoAP-mappable HTTP requests and responses end-to-end across intermediary nodes such as CoAP forward proxies and cross-protocol translators including HTTP-to-CoAP proxies [RFC8075]. In addition to the core CoAP features defined in [RFC7252], OSCORE supports the Observe [RFC7641], Block-wise [RFC7959], and No-Response [RFC7967] options, as well as the PATCH and FETCH methods [RFC8132]. An analysis of end-to-end security for CoAP messages through some types of intermediary nodes is performed in [CoAP-E2E-Sec]. OSCORE essentially protects the RESTful interactions: the request method, the requested resource, the message payload, etc. (see Section 4), where "RESTful" refers to the Representational State Transfer (REST) Architecture [REST]. OSCORE protects neither the CoAP messaging layer nor the CoAP Token, which may change between the endpoints; therefore, those are processed as defined in [RFC7252]. Additionally, since the message formats for CoAP over unreliable transport [RFC7252] and for CoAP over reliable transport [RFC8323] differ only in terms of CoAP messaging layer, OSCORE can be applied to both unreliable and reliable transports (see Figure 1).
このドキュメントは、制約付きRESTful環境（OSCORE）セキュリティプロトコルのオブジェクトセキュリティを定義し、CoAPフォワードプロキシやHTTP-to-CoAPを含むクロスプロトコルトランスレータなどの中間ノード全体でCoAPおよびCoAPマッピング可能なHTTP要求および応答をエンドツーエンドで保護しますプロキシ[RFC8075]。 [RFC7252]で定義されたコアCoAP機能に加えて、OSCOREはObserve [RFC7641]、Block-wise [RFC7959]、およびNo-Response [RFC7967]オプション、ならびにPATCHおよびFETCHメソッド[RFC8132]をサポートしています。いくつかのタイプの中間ノードを介したCoAPメッセージのエンドツーエンドセキュリティの分析は、[CoAP-E2E-Sec]で実行されます。 OSCOREは本質的にRESTfulな相互作用を保護します：リクエストメソッド、リクエストされたリソース、メッセージペイロードなど（セクション4を参照）。 OSCOREは、CoAPメッセージングレイヤーもCoAPトークンも保護しません。これらはエンドポイント間で変更される可能性があります。したがって、これらは[RFC7252]で定義されているように処理されます。さらに、CoAP over unreliable transport [RFC7252]とCoAP over reliable transport [RFC8323]のメッセージフォーマットはCoAPメッセージングレイヤーのみが異なるため、OSCOREは信頼性のないトランスポートと信頼性の高いトランスポートの両方に適用できます（図1を参照）。
OSCORE works in very constrained nodes and networks, thanks to its small message size and the restricted code and memory requirements in addition to what is required by CoAP. Examples of the use of OSCORE are given in Appendix A. OSCORE may be used over any underlying layer, such as UDP or TCP, and with non-IP transports (e.g., [CoAP-802.15.4]). OSCORE may also be used in different ways with HTTP. OSCORE messages may be transported in HTTP, and OSCORE may also be used to protect CoAP-mappable HTTP messages, as described below.
OSCOREは、CoAPに必要なものに加えて、メッセージサイズが小さく、コードとメモリの要件が制限されているため、非常に制約されたノードとネットワークで機能します。 OSCOREの使用例は付録Aに記載されています。OSCOREは、UDPやTCPなどの基礎となるレイヤー上で、非IPトランスポート（[CoAP-802.15.4]など）とともに使用できます。 OSCOREは、HTTPでもさまざまな方法で使用できます。 OSCOREメッセージはHTTPで転送される場合があり、OSCOREは、以下で説明するように、CoAPマッピング可能なHTTPメッセージを保護するためにも使用できます。
+-----------------------------------+
| Application |
+-----------------------------------+
+-----------------------------------+ \
| Requests / Responses / Signaling | |
|-----------------------------------| |
| OSCORE | | CoAP
|-----------------------------------| |
| Messaging Layer / Message Framing | |
+-----------------------------------+ /
+-----------------------------------+
| UDP / TCP / ... |
+-----------------------------------+
Figure 1: Abstract Layering of CoAP with OSCORE
図1：OSCOREを使用したCoAPの抽象的なレイヤリング
OSCORE is designed to protect as much information as possible while still allowing CoAP proxy operations (Section 10). It works with existing CoAP-to-CoAP forward proxies [RFC7252], but an OSCORE-aware proxy will be more efficient. HTTP-to-CoAP proxies [RFC8075] and CoAP-to-HTTP proxies can also be used with OSCORE, as specified in Section 11. OSCORE may be used together with TLS or DTLS over one or more hops in the end-to-end path, e.g., transported with HTTPS in one hop and with plain CoAP in another hop. The use of OSCORE does not affect the URI scheme; therefore, OSCORE can be used with any URI scheme defined for CoAP or HTTP. The application decides the conditions for which OSCORE is required.
OSCOREは、CoAPプロキシ操作を許可しながら、可能な限り多くの情報を保護するように設計されています（セクション10）。既存のCoAP-to-CoAPフォワードプロキシ[RFC7252]で動作しますが、OSCORE対応プロキシの方が効率的です。 HTTP-to-CoAPプロキシ[RFC8075]およびCoAP-to-HTTPプロキシは、セクション11で指定されているように、OSCOREでも使用できます。OSCOREは、エンドツーエンドの1つ以上のホップでTLSまたはDTLSと一緒に使用できますパス。たとえば、1つのホップでHTTPSを使用して転送され、別のホップでプレーンCoAPを使用して転送されます。 OSCOREを使用しても、URIスキームには影響しません。したがって、OSCOREはCoAPまたはHTTP用に定義された任意のURIスキームで使用できます。アプリケーションは、OSCOREが必要な条件を決定します。
OSCORE uses pre-shared keys that may have been established out-of-band or with a key establishment protocol (see Section 3.2). The technical solution builds on CBOR Object Signing and Encryption (COSE) [RFC8152], providing end-to-end encryption, integrity, replay protection, and binding of response to request. A compressed version of COSE is used, as specified in Section 6. The use of OSCORE is signaled in CoAP with a new option (Section 2), and in HTTP with a new header field (Section 11.1) and content type (Section 13.5). The solution transforms a CoAP/HTTP message into an "OSCORE message" before sending, and vice versa after receiving. The OSCORE message is a CoAP/HTTP message related to the original message in the following way: the original CoAP/HTTP message is translated to CoAP (if not already in CoAP) and protected in a COSE object. The encrypted message fields of this COSE object are transported in the CoAP payload/HTTP body of the OSCORE message, and the OSCORE option/ header field is included in the message. A sketch of an exchange of OSCORE messages, in the case of the original message being CoAP, is provided in Figure 2. The use of OSCORE with HTTP is detailed in Section 11.
OSCOREは、帯域外で確立された、またはキー確立プロトコル（セクション3.2を参照）で確立された可能性がある事前共有キーを使用します。この技術ソリューションは、CBORオブジェクト署名および暗号化（COSE）[RFC8152]に基づいて構築されており、エンドツーエンドの暗号化、整合性、再生保護、および要求に対する応答のバインドを提供します。セクション6で指定されているように、COSEの圧縮バージョンが使用されます。OSCOREの使用は、CoAPで新しいオプション（セクション2）と、HTTPで新しいヘッダーフィールド（セクション11.1）とコンテンツタイプ（セクション13.5）で通知されます。 。このソリューションは、送信前にCoAP / HTTPメッセージを「OSCOREメッセージ」に変換し、受信後はその逆を行います。 OSCOREメッセージは、次の方法で元のメッセージに関連するCoAP / HTTPメッセージです。元のCoAP / HTTPメッセージはCoAP（まだCoAPにない場合）に変換され、COSEオブジェクトで保護されます。このCOSEオブジェクトの暗号化されたメッセージフィールドは、OSCOREメッセージのCoAPペイロード/ HTTP本文で転送され、OSCOREオプション/ヘッダーフィールドがメッセージに含まれます。元のメッセージがCoAPである場合のOSCOREメッセージの交換のスケッチを図2に示します。HTTPでのOSCOREの使用については、セクション11で詳しく説明しています。
Client Server
| OSCORE request - POST example.com: |
| Header, Token, |
| Options: OSCORE, ..., |
| Payload: COSE ciphertext |
+--------------------------------------------->|
| |
|<---------------------------------------------+
| OSCORE response - 2.04 (Changed): |
| Header, Token, |
| Options: OSCORE, ..., |
| Payload: COSE ciphertext |
| |
Figure 2: Sketch of CoAP with OSCORE
図2：OSCOREを使用したCoAPのスケッチ
An implementation supporting this specification MAY implement only the client part, MAY implement only the server part, or MAY implement only one of the proxy parts.
この仕様をサポートする実装は、クライアント部分のみを実装してもよいし（MAY）、サーバー部分のみを実装してもよい（MAY）、またはプロキシ部分の1つだけを実装してもよい（MAY）。
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], COSE [RFC8152], Concise Binary Object Representation (CBOR) [RFC7049], Concise Data Definition Language (CDDL) [RFC8610] as summarized in Appendix E, and constrained environments [RFC7228]. Additional optional features include Observe [RFC7641], Block-wise [RFC7959], No-Response [RFC7967] and CoAP over reliable transport [RFC8323].
読者は、付録Eに要約されているように、CoAP [RFC7252]、COSE [RFC8152]、簡潔なバイナリオブジェクト表現（CBOR）[RFC7049]、簡潔なデータ定義言語（CDDL）[RFC8610]で説明されている用語と概念に精通している必要があります。制約された環境[RFC7228]。その他のオプション機能には、Observe [RFC7641]、Block-wise [RFC7959]、No-Response [RFC7967]、および信頼できるトランスポート[RFC8323]上のCoAPがあります。
The term "hop" is used to denote a particular leg in the end-to-end path. The concept "hop-by-hop" (as in "hop-by-hop encryption" or "hop-by-hop fragmentation") opposed to "end-to-end", is used in this document to indicate that the messages are processed accordingly in the intermediaries, rather than just forwarded to the next node.
「ホップ」という用語は、エンドツーエンドパスの特定のレッグを示すために使用されます。このドキュメントでは、「エンドツーエンド」ではなく、「ホップバイホップ」という概念（「ホップバイホップ暗号化」または「ホップバイホップフラグメンテーション」など）を使用して、メッセージが単に次のノードに転送されるのではなく、中間で適切に処理されます。
The term "stop processing" is used throughout the document to denote that the message is not passed up to the CoAP request/response layer (see Figure 1).
「処理の停止」という用語は、メッセージがCoAP要求/応答層に渡されないことを示すためにドキュメント全体で使用されています（図1を参照）。
The terms Common Context, Sender Context, Recipient Context, Master Secret, Master Salt, Sender ID, Sender Key, Recipient ID, Recipient Key, ID Context, and Common IV are defined in Section 3.1.
Common Context、Sender Context、Recipient Context、Master Secret、Master Salt、Sender ID、Sender Key、Recipient ID、Recipient Key、ID Context、Common IVという用語は、セクション3.1で定義されています。
The OSCORE option defined in this section (see Figure 3, which extends "Table 4: Options" of [RFC7252]) indicates that the CoAP message is an OSCORE message and that it contains a compressed COSE object (see Sections 5 and 6). The OSCORE option is critical, safe to forward, part of the cache key, and not repeatable.
このセクションで定義されているOSCOREオプション（[RFC7252]の「表4：オプション」を拡張した図3を参照）は、CoAPメッセージがOSCOREメッセージであり、圧縮されたCOSEオブジェクトが含まれていることを示します（セクション5および6を参照）。 OSCOREオプションは重要であり、転送しても安全で、キャッシュキーの一部であり、再現性はありません。
+------+---+---+---+---+----------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+----------------+--------+--------+---------+
| 9 | x | | | | OSCORE | (*) | 0-255 | (none) |
+------+---+---+---+---+----------------+--------+--------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable (*) See below.
C =緊急、U =安全でない、N = NoCacheKey、R =反復可能（*）以下を参照してください。
Figure 3: The OSCORE Option
図3：OSCOREオプション
The OSCORE option includes the OSCORE flag bits (Section 6), the Sender Sequence Number, the Sender ID, and the ID Context when these fields are present (Section 3). The detailed format and length is specified in Section 6. If the OSCORE flag bits are all zero (0x00), the option value SHALL be empty (Option Length = 0). An endpoint receiving a CoAP message without payload that also contains an OSCORE option SHALL treat it as malformed and reject it.
OSCOREオプションには、OSCOREフラグビット（セクション6）、送信者シーケンス番号、送信者ID、およびこれらのフィールドが存在する場合（セクション3）のIDコンテキストが含まれます。詳細なフォーマットと長さはセクション6で指定されています。OSCOREフラグビットがすべてゼロ（0x00）の場合、オプション値は空（SHALL）（オプション長さ= 0）です。 OSCOREオプションも含むペイロードのないCoAPメッセージを受信するエンドポイントは、それを不正な形式として扱い、拒否する必要があります（SHALL）。
A successful response to a request with the OSCORE option SHALL contain the OSCORE option. Whether error responses contain the OSCORE option depends on the error type (see Section 8).
OSCOREオプションを使用した要求に対する正常な応答には、OSCOREオプションが含まれている必要があります。エラー応答にOSCOREオプションが含まれるかどうかは、エラーのタイプによって異なります（セクション8を参照）。
For CoAP proxy operations, see Section 10.
CoAPプロキシ操作については、セクション10を参照してください。
OSCORE requires that client and server establish a shared security context used to process the COSE objects. OSCORE uses COSE with an Authenticated Encryption with Associated Data (AEAD, [RFC5116]) algorithm for protecting message data between a client and a server. In this section, we define the security context and how it is derived in client and server based on a shared secret and a key derivation function.
OSCOREでは、クライアントとサーバーがCOSEオブジェクトの処理に使用される共有セキュリティコンテキストを確立する必要があります。 OSCOREは、クライアントとサーバー間のメッセージデータを保護するために、関連データを伴う認証済み暗号化（AEAD、[RFC5116]）アルゴリズムを備えたCOSEを使用します。このセクションでは、セキュリティコンテキストと、共有シークレットとキー派生関数に基づいてクライアントとサーバーでセキュリティコンテキストがどのように派生するかを定義します。
The security context is the set of information elements necessary to carry out the cryptographic operations in OSCORE. For each endpoint, the security context is composed of a "Common Context", a "Sender Context", and a "Recipient Context".
セキュリティコンテキストは、OSCOREで暗号化操作を実行するために必要な情報要素のセットです。各エンドポイントのセキュリティコンテキストは、「共通コンテキスト」、「送信者コンテキスト」、および「受信者コンテキスト」で構成されています。
The endpoints protect messages to send using the Sender Context and verify messages received using the Recipient Context; both contexts being derived from the Common Context and other data. Clients and servers need to be able to retrieve the correct security context to use.
エンドポイントは、送信者コンテキストを使用して送信するメッセージを保護し、受信者コンテキストを使用して受信したメッセージを確認します。両方のコンテキストは、共通コンテキストと他のデータから派生しています。クライアントとサーバーは、使用する正しいセキュリティコンテキストを取得できる必要があります。
An endpoint uses its Sender ID (SID) to derive its Sender Context; the other endpoint uses the same ID, now called Recipient ID (RID), to derive its Recipient Context. In communication between two endpoints, the Sender Context of one endpoint matches the Recipient Context of the other endpoint, and vice versa. Thus, the two security contexts identified by the same IDs in the two endpoints are not the same, but they are partly mirrored. Retrieval and use of the security context are shown in Figure 4.
エンドポイントは、送信者ID（SID）を使用して送信者コンテキストを導出します。もう一方のエンドポイントは、現在は受信者ID（RID）と呼ばれる同じIDを使用して、その受信者コンテキストを導出します。 2つのエンドポイント間の通信では、1つのエンドポイントの送信者コンテキストが他のエンドポイントの受信者コンテキストと一致し、その逆も同様です。したがって、2つのエンドポイントで同じIDによって識別される2つのセキュリティコンテキストは同じではありませんが、部分的にミラーリングされています。セキュリティコンテキストの取得と使用を図4に示します。
.---------------------. .---------------------.
| Common Context | = | Common Context |
+---------------------+ +---------------------+
| Sender Context | = | Recipient Context |
+---------------------+ +---------------------+
| Recipient Context | = | Sender Context |
'---------------------' '---------------------'
Client Server
| |
Retrieve context for | OSCORE request: |
target resource | Token = Token1, |
Protect request with | kid = SID, ... |
Sender Context +---------------------->| Retrieve context with
| | RID = kid
| | Verify request with
| | Recipient Context
| OSCORE response: | Protect response with
| Token = Token1, ... | Sender Context
Retrieve context with |<----------------------+
Token = Token1 | |
Verify request with | |
Recipient Context | |
Figure 4: Retrieval and Use of the Security Context
図4：セキュリティコンテキストの取得と使用
The Common Context contains the following parameters:
共通コンテキストには、以下のパラメーターが含まれています。
o AEAD Algorithm. The COSE AEAD algorithm to use for encryption.
o AEADアルゴリズム。暗号化に使用するCOSE AEADアルゴリズム。
o HKDF Algorithm. An HMAC-based key derivation function (HKDF, [RFC5869]) used to derive the Sender Key, Recipient Key, and Common IV.
o HKDFアルゴリズム。送信者キー、受信者キー、および共通IVを導出するために使用されるHMACベースのキー導出関数（HKDF、[RFC5869]）。
o Master Secret. Variable length, random byte string (see Section 12.3) used to derive AEAD keys and Common IV.
o マスターシークレット。可変長のランダムバイト文字列（セクション12.3を参照）は、AEADキーとCommon IVを導出するために使用されます。
o Master Salt. Optional variable-length byte string containing the salt used to derive AEAD keys and Common IV.
o マスターソルト。 AEADキーとCommon IVの導出に使用されるソルトを含むオプションの可変長バイト文字列。
o ID Context. Optional variable-length byte string providing additional information to identify the Common Context and to derive AEAD keys and Common IV. The use of ID Context is described in Section 5.1.
o IDコンテキスト。共通コンテキストを識別し、AEADキーと共通IVを導出するための追加情報を提供するオプションの可変長バイト文字列。 IDコンテキストの使用については、セクション5.1で説明します。
o Common IV. Byte string derived from the Master Secret, Master Salt, and ID Context. Used to generate the AEAD nonce (see Section 5.2). Same length as the nonce of the AEAD Algorithm.
o 一般的なIV。マスターシークレット、マスターソルト、IDコンテキストから派生したバイト文字列。 AEADナンスを生成するために使用されます（セクション5.2を参照）。 AEADアルゴリズムのノンスと同じ長さ。
The Sender Context contains the following parameters:
Sender Contextには、次のパラメーターが含まれています。
o Sender ID. Byte string used to identify the Sender Context, to derive AEAD keys and Common IV, and to contribute to the uniqueness of AEAD nonces. Maximum length is determined by the AEAD Algorithm.
o 送信者ID。送信者コンテキストを識別し、AEADキーとCommon IVを導出し、AEADナンスの一意性に貢献するために使用されるバイト文字列。最大長はAEADアルゴリズムによって決定されます。
o Sender Key. Byte string containing the symmetric AEAD key to protect messages to send. Derived from Common Context and Sender ID. Length is determined by the AEAD Algorithm.
o 送信者キー。送信するメッセージを保護するための対称AEADキーを含むバイト文字列。共通コンテキストと送信者IDから派生。長さはAEADアルゴリズムによって決定されます。
o Sender Sequence Number. Non-negative integer used by the sender to enumerate requests and certain responses, e.g., Observe notifications. Used as "Partial IV" [RFC8152] to generate unique AEAD nonces. Maximum value is determined by the AEAD Algorithm. Initialization is described in Section 3.2.2.
o 送信者シーケンス番号。送信者がリクエストと特定の応答を列挙するために使用する負でない整数。一意のAEADナンスを生成するために「部分IV」[RFC8152]として使用されます。最大値はAEADアルゴリズムによって決定されます。初期化については、セクション3.2.2で説明します。
The Recipient Context contains the following parameters:
受信者コンテキストには、次のパラメーターが含まれています。
o Recipient ID. Byte string used to identify the Recipient Context, to derive AEAD keys and Common IV, and to contribute to the uniqueness of AEAD nonces. Maximum length is determined by the AEAD Algorithm.
o 受信者ID。受信者コンテキストを識別し、AEADキーとCommon IVを導出し、AEADナンスの一意性に貢献するために使用されるバイト文字列。最大長はAEADアルゴリズムによって決定されます。
o Recipient Key. Byte string containing the symmetric AEAD key to verify messages received. Derived from Common Context and Recipient ID. Length is determined by the AEAD Algorithm.
o 受信者キー。受信したメッセージを検証するための対称AEADキーを含むバイト文字列。共通のコンテキストと受信者IDから派生。長さはAEADアルゴリズムによって決定されます。
o Replay Window (Server only). The replay window used to verify requests received. Replay protection is described in Section 7.4 and Section 3.2.2.
o 再生ウィンドウ（サーバーのみ）。受信したリクエストの確認に使用されるリプレイウィンドウ。リプレイ保護については、セクション7.4およびセクション3.2.2で説明しています。
All parameters except Sender Sequence Number and Replay Window are immutable once the security context is established. An endpoint may free up memory by not storing the Common IV, Sender Key, and Recipient Key, deriving them when needed. Alternatively, an endpoint may free up memory by not storing the Master Secret and Master Salt after the other parameters have been derived.
セキュリティコンテキストが確立されると、送信者シーケンス番号とリプレイウィンドウを除くすべてのパラメーターは不変です。エンドポイントは、Common IV、Sender Key、およびRecipient Keyを格納せず、必要に応じてそれらを取得することにより、メモリを解放する場合があります。または、他のパラメータが導出された後、エンドポイントはマスターシークレットとマスターソルトを保存しないことでメモリを解放する場合があります。
Endpoints MAY operate as both client and server and use the same security context for those roles. Independent of being client or server, the endpoint protects messages to send using its Sender Context, and verifies messages received using its Recipient Context. The endpoints MUST NOT change the Sender/Recipient ID when changing roles. In other words, changing the roles does not change the set of AEAD keys to be used.
エンドポイントはクライアントとサーバーの両方として機能し、それらのロールに同じセキュリティコンテキストを使用する場合があります。エンドポイントは、クライアントまたはサーバーであるかどうかに関係なく、送信者コンテキストを使用して送信するメッセージを保護し、受信者コンテキストを使用して受信したメッセージを検証します。エンドポイントは、役割を変更するときに送信者/受信者IDを変更してはなりません（MUST NOT）。つまり、役割を変更しても、使用するAEADキーのセットは変更されません。
Each endpoint derives the parameters in the security context from a small set of input parameters. The following input parameters SHALL be preestablished:
各エンドポイントは、セキュリティコンテキストのパラメーターを、少数の入力パラメーターのセットから派生させます。次の入力パラメータを事前に確立する必要があります。
o Master Secret
o マスターシークレット
o Sender ID
o 送信者ID
o Recipient ID
o 受信者ID
The following input parameters MAY be preestablished. In case any of these parameters is not preestablished, the default value indicated below is used:
次の入力パラメータは事前に確立されている場合があります。これらのパラメーターのいずれかが事前に確立されていない場合、以下に示すデフォルト値が使用されます。
o AEAD Algorithm
o AEADアルゴリズム
* Default is AES-CCM-16-64-128 (COSE algorithm encoding: 10)
* デフォルトはAES-CCM-16-64-128です（COSEアルゴリズムエンコーディング：10）
o Master Salt
o マスターソルト
* Default is the empty byte string
* デフォルトは空のバイト文字列です
o HKDF Algorithm
o HKDFアルゴリズム
* Default is HKDF SHA-256
* デフォルトはHKDF SHA-256です
o Replay Window
o 再生ウィンドウ
* The default mechanism is an anti-replay sliding window (see Section 4.1.2.6 of [RFC6347] with a window size of 32
* デフォルトのメカニズムは、アンチリプレイスライディングウィンドウです（ウィンドウサイズ32の[RFC6347]のセクション4.1.2.6を参照）
All input parameters need to be known and agreed on by both endpoints, but the Replay Window may be different in the two endpoints. The way the input parameters are preestablished is application specific. Considerations of security context establishment are given in Section 12.2 and examples of deploying OSCORE in Appendix B.
すべての入力パラメーターは、両方のエンドポイントで認識され、合意される必要がありますが、再生ウィンドウは2つのエンドポイントで異なる場合があります。入力パラメーターが事前に確立される方法は、アプリケーション固有です。セキュリティコンテキストの確立に関する考慮事項については、セクション12.2と、付録BにOSCOREの導入例を示します。
The HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms defined for COSE [RFC8152]. HKDF SHA-256 is mandatory to implement. The security context parameters Sender Key, Recipient Key, and Common IV SHALL be derived from the input parameters using the HKDF, which consists of the composition of the HKDF-Extract and HKDF-Expand steps [RFC5869]:
HKDFは、COSE [RFC8152]に対して定義されたHMACベースのHKDF [RFC5869]アルゴリズムの1つでなければなりません（MUST）。 HKDF SHA-256の実装は必須です。セキュリティコンテキストパラメーターの送信者キー、受信者キー、および共通IVは、HKDFを使用して入力パラメーターから派生する必要があります。HKDFは、HKDF-ExtractステップとHKDF-Expandステップの構成で構成されます[RFC5869]。
output parameter = HKDF(salt, IKM, info, L)
出力パラメーター= HKDF（塩、IKM、情報、L）
where:
ただし：
o salt is the Master Salt as defined above
o saltは上記で定義されたマスターソルトです
o IKM is the Master Secret as defined above
o IKMは、上で定義したマスターシークレットです。
o info is the serialization of a CBOR array consisting of (the notation follows [RFC8610] as summarized in Appendix E):
o infoは、以下で構成されるCBOR配列のシリアライゼーションです（表記法は[RFC8610]に従い、付録Eに要約されています）。
info = [
id : bstr,
id_context : bstr / nil,
alg_aead : int / tstr,
type : tstr,
L : uint,
]
where:
ただし：
o id is the Sender ID or Recipient ID when deriving Sender Key and Recipient Key, respectively, and the empty byte string when deriving the Common IV.
o idは、それぞれ送信者キーと受信者キーを取得するときの送信者IDまたは受信者IDであり、共通IVを取得するときは空のバイト文字列です。
o id_context is the ID Context, or nil if ID Context is not provided.
o id_contextはIDコンテキストです。IDコンテキストが指定されていない場合はnilです。
o alg_aead is the AEAD Algorithm, encoded as defined in [RFC8152].
o alg_aeadは、[RFC8152]で定義されているようにエンコードされたAEADアルゴリズムです。
o type is "Key" or "IV". The label is an ASCII string and does not include a trailing NUL byte.
o タイプは「キー」または「IV」です。ラベルはASCII文字列で、末尾のNULバイトは含まれません。
o L is the size of the key/nonce for the AEAD Algorithm used, in bytes.
o Lは、使用するAEADアルゴリズムのキー/ノンスのサイズ（バイト単位）です。
For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in [RFC8152]) is used, the integer value for alg_aead is 10, the value for L is 16 for keys and 13 for the Common IV. Assuming use of the default algorithms HKDF SHA-256 and AES-CCM-16-64-128, the extract phase of HKDF produces a pseudorandom key (PRK) as follows:
たとえば、アルゴリズムAES-CCM-16-64-128（[RFC8152]のセクション10.2を参照）が使用されている場合、alg_aeadの整数値は10、Lの値はキーの場合は16、Common IVの場合は13です。デフォルトのアルゴリズムHKDF SHA-256およびAES-CCM-16-64-128の使用を想定すると、HKDFの抽出フェーズでは、次のように擬似ランダムキー（PRK）が生成されます。
PRK = HMAC-SHA-256(Master Salt, Master Secret)
PRK = HMAC-SHA-256（マスターソルト、マスターシークレット）
and as L is smaller than the hash function output size, the expand phase of HKDF consists of a single HMAC invocation; therefore, the Sender Key, Recipient Key, and Common IV are the first 16 or 13 bytes of
Lはハッシュ関数の出力サイズよりも小さいため、HKDFの展開フェーズは単一のHMAC呼び出しで構成されます。したがって、送信者キー、受信者キー、および共通IVは、最初の16バイトまたは13バイトです。
output parameter = HMAC-SHA-256(PRK, info || 0x01)
出力パラメーター= HMAC-SHA-256（PRK、info || 0x01）
where different values of info are used for each derived parameter and where || denotes byte string concatenation.
ここで、派生した各パラメーターに異なる値の情報が使用され、||バイト文字列の連結を示します。
Note that [RFC5869] specifies that if the salt is not provided, it is set to a string of zeros. For implementation purposes, not providing the salt is the same as setting the salt to the empty byte string. OSCORE sets the salt default value to empty byte string, which is converted to a string of zeroes (see Section 2.2 of [RFC5869]).
[RFC5869]は、ソルトが提供されない場合、ゼロの文字列に設定されることを指定していることに注意してください。実装の目的で、ソルトを提供しないことは、ソルトを空のバイト文字列に設定することと同じです。 OSCOREはソルトのデフォルト値を空のバイト文字列に設定します。これはゼロの文字列に変換されます（[RFC5869]のセクション2.2を参照）。
The Sender Sequence Number is initialized to 0.
送信者シーケンス番号は0に初期化されます。
The supported types of replay protection and replay window size is application specific and depends on how OSCORE is transported (see Section 7.4). The default mechanism is the anti-replay window of received messages used by IPsec AH/ESP and DTLS (see Section 4.1.2.6 of [RFC6347]) with a window size of 32.
サポートされる再生保護と再生ウィンドウサイズのタイプはアプリケーション固有であり、OSCOREの転送方法によって異なります（第7.4項を参照）。デフォルトのメカニズムは、ウィンドウサイズが32で、IPsec AH / ESPおよびDTLS（[RFC6347]のセクション4.1.2.6を参照）で使用される受信メッセージのアンチリプレイウィンドウです。
To ensure unique Sender Keys, the quartet (Master Secret, Master Salt, ID Context, Sender ID) MUST be unique, i.e., the pair (ID Context, Sender ID) SHALL be unique in the set of all security contexts using the same Master Secret and Master Salt. This means that Sender ID SHALL be unique in the set of all security contexts using the same Master Secret, Master Salt, and ID Context; such a requirement guarantees unique (key, nonce) pairs for the AEAD.
一意の送信者キーを確保するには、カルテット（マスターシークレット、マスターソルト、IDコンテキスト、送信者ID）が一意である必要があります。つまり、ペア（IDコンテキスト、送信者ID）は、同じマスターを使用するすべてのセキュリティコンテキストのセットで一意である必要があります。秘密とマスターソルト。つまり、Sender IDは、同じマスターシークレット、マスターソルト、IDコンテキストを使用するすべてのセキュリティコンテキストのセットで一意である必要があります。このような要件により、AEADの一意の（キー、ノンス）ペアが保証されます。
Different methods can be used to assign Sender IDs: a protocol that allows the parties to negotiate locally unique identifiers, a trusted third party (e.g., [ACE-OAuth]), or the identifiers can be assigned out-of-band. The Sender IDs can be very short (note that the empty string is a legitimate value). The maximum length of Sender ID in bytes equals the length of the AEAD nonce minus 6, see Section 5.2. For AES-CCM-16-64-128 the maximum length of Sender ID is 7 bytes.
送信者IDの割り当てには、さまざまな方法を使用できます。当事者がローカルで一意の識別子をネゴシエートできるようにするプロトコル、信頼できるサードパーティ（[ACE-OAuth]など）、または識別子を帯域外に割り当てることができます。 Sender IDは非常に短くなる可能性があります（空の文字列は正当な値であることに注意してください）。送信者IDの最大長（バイト単位）は、AEADナンスの長さから6を引いたものに等しくなります。セクション5.2を参照してください。 AES-CCM-16-64-128の場合、Sender IDの最大長は7バイトです。
To simplify retrieval of the right Recipient Context, the Recipient ID SHOULD be unique in the sets of all Recipient Contexts used by an endpoint. If an endpoint has the same Recipient ID with different Recipient Contexts, i.e., the Recipient Contexts are derived from different Common Contexts, then the endpoint may need to try multiple times before verifying the right security context associated to the Recipient ID.
正しい受信者コンテキストの取得を簡単にするために、受信者IDは、エンドポイントで使用されるすべての受信者コンテキストのセットで一意である必要があります（SHOULD）。エンドポイントの受信者IDが同じで、受信者コンテキストが異なる場合、つまり、受信者コンテキストが異なる共通コンテキストから派生している場合、エンドポイントは、受信者IDに関連付けられた正しいセキュリティコンテキストを確認する前に、複数回試行する必要がある場合があります。
The ID Context is used to distinguish between security contexts. The methods used for assigning Sender ID can also be used for assigning the ID Context. Additionally, the ID Context can be used to introduce randomness into new Sender and Recipient Contexts (see Appendix B.2). ID Context can be arbitrarily long.
IDコンテキストは、セキュリティコンテキストを区別するために使用されます。 Sender IDの割り当てに使用されるメソッドは、IDコンテキストの割り当てにも使用できます。さらに、IDコンテキストを使用して、新しい送信者および受信者コンテキストにランダム性を導入できます（付録B.2を参照）。 IDコンテキストは任意に長くできます。
OSCORE transforms a CoAP message (which may have been generated from an HTTP message) into an OSCORE message, and vice versa. OSCORE protects as much of the original message as possible while still allowing certain proxy operations (see Sections 10 and 11). This section defines how OSCORE protects the message fields and transfers them end-to-end between client and server (in any direction).
OSCOREは、CoAPメッセージ（HTTPメッセージから生成された可能性がある）をOSCOREメッセージに変換します。 OSCOREは、特定のプロキシ操作を許可しながら、元のメッセージを可能な限り保護します（セクション10および11を参照）。このセクションでは、OSCOREがメッセージフィールドを保護し、それらをクライアントとサーバー間でエンドツーエンドで（任意の方向に）転送する方法を定義します。
The remainder of this section and later sections focus on the behavior in terms of CoAP messages. If HTTP is used for a particular hop in the end-to-end path, then this section applies to the conceptual CoAP message that is mappable to/from the original HTTP message as discussed in Section 11. That is, an HTTP message is conceptually transformed to a CoAP message and then to an OSCORE message, and similarly in the reverse direction. An actual implementation might translate directly from HTTP to OSCORE without the intervening CoAP representation.
このセクションの以降のセクションでは、CoAPメッセージに関する動作に焦点を当てます。エンドツーエンドパスの特定のホップにHTTPが使用されている場合、このセクションは、セクション11で説明したように、元のHTTPメッセージとの間でマッピング可能な概念的なCoAPメッセージに適用されます。つまり、HTTPメッセージは概念的にCoAPメッセージに変換されてからOSCOREメッセージに変換され、同様に逆方向に変換されます。実際の実装では、CoAP表現を介さずにHTTPからOSCOREに直接変換される場合があります。
Protection of signaling messages (Section 5 of [RFC8323]) is specified in Section 4.3. The other parts of this section target request/response messages.
シグナリングメッセージの保護（[RFC8323]のセクション5）は、セクション4.3で指定されています。このセクションの他の部分は、要求/応答メッセージを対象としています。
Message fields of the CoAP message may be protected end-to-end between CoAP client and CoAP server in different ways:
CoAPメッセージのメッセージフィールドは、CoAPクライアントとCoAPサーバー間のエンドツーエンドでさまざまな方法で保護できます。
o Class E: encrypted and integrity protected,
o クラスE：暗号化および整合性保護、
o Class I: integrity protected only, or
o クラスI：完全性のみ保護、または
o Class U: unprotected.
o クラスU：保護されていません。
The sending endpoint SHALL transfer Class E message fields in the ciphertext of the COSE object in the OSCORE message. The sending endpoint SHALL include Class I message fields in the AAD of the AEAD algorithm, allowing the receiving endpoint to detect if the value has changed in transfer. Class U message fields SHALL NOT be protected in transfer. Class I and Class U message field values are transferred in the header or options part of the OSCORE message, which is visible to proxies.
送信エンドポイントは、OSCOREメッセージ内のCOSEオブジェクトの暗号文のクラスEメッセージフィールドを転送するものとします（SHALL）。送信エンドポイントは、AEADアルゴリズムのAADにクラスIメッセージフィールドを含める必要があります（SHALL）。これにより、受信エンドポイントは、転送中に値が変更されたかどうかを検出できます。クラスUメッセージフィールドは転送時に保護されるべきではありません。クラスIおよびクラスUのメッセージフィールド値は、OSCOREメッセージのヘッダーまたはオプションの部分で転送されます。これは、プロキシに表示されます。
Message fields not visible to proxies, i.e., transported in the ciphertext of the COSE object, are called "Inner" (Class E). Message fields transferred in the header or options part of the OSCORE message, which is visible to proxies, are called "Outer" (Class I or Class U). There are currently no Class I options defined.
プロキシから見えない、つまり、COSEオブジェクトの暗号文で転送されるメッセージフィールドは、「内部」（クラスE）と呼ばれます。 OSCOREメッセージのヘッダーまたはオプション部分で転送されるメッセージフィールドは、プロキシに表示され、「外部」（クラスIまたはクラスU）と呼ばれます。現在、クラスIオプションは定義されていません。
An OSCORE message may contain both an Inner and an Outer instance of a certain CoAP message field. Inner message fields are intended for the receiving endpoint, whereas Outer message fields are used to enable proxy operations.
OSCOREメッセージには、特定のCoAPメッセージフィールドの内部インスタンスと外部インスタンスの両方が含まれる場合があります。内部メッセージフィールドは受信エンドポイントを対象としていますが、外部メッセージフィールドはプロキシ操作を有効にするために使用されます。
A summary of how options are protected is shown in Figure 5. Note that some options may have both Inner and Outer message fields, which are protected accordingly. Certain options require special processing as is described in Section 4.1.3.
オプションの保護方法の概要を図5に示します。一部のオプションには、内部メッセージフィールドと外部メッセージフィールドの両方があり、それに従って保護されることに注意してください。セクション4.1.3で説明されているように、特定のオプションには特別な処理が必要です。
Options that are unknown or for which OSCORE processing is not defined SHALL be processed as Class E (and no special processing). Specifications of new CoAP options SHOULD define how they are processed with OSCORE. A new COAP option SHOULD be of Class E unless it requires proxy processing. If a new CoAP option is of class U, the potential issues with the option being unprotected SHOULD be documented (see Appendix D.5).
不明なオプションまたはOSCORE処理が定義されていないオプションは、クラスEとして処理される必要があります（特別な処理は行われません）。新しいCoAPオプションの仕様は、OSCOREでの処理方法を定義する必要があります（SHOULD）。新しいCOAPオプションは、プロキシ処理を必要としない限り、クラスEにする必要があります（SHOULD）。新しいCoAPオプションがクラスUの場合、保護されていないオプションの潜在的な問題を文書化する必要があります（付録D.5を参照）。
Inner option message fields (Class E) are used to communicate directly with the other endpoint.
内部オプションメッセージフィールド（クラスE）は、他のエンドポイントと直接通信するために使用されます。
The sending endpoint SHALL write the Inner option message fields present in the original CoAP message into the plaintext of the COSE object (Section 5.3) and then remove the Inner option message fields from the OSCORE message.
送信エンドポイントは、元のCoAPメッセージに存在する内部オプションメッセージフィールドをCOSEオブジェクトのプレーンテキストに書き込み（セクション5.3）、OSCOREメッセージから内部オプションメッセージフィールドを削除する必要があります（SHALL）。
The processing of Inner option message fields by the receiving endpoint is specified in Sections 8.2 and 8.4.
受信エンドポイントによる内部オプションメッセージフィールドの処理は、セクション8.2および8.4で指定されています。
+------+-----------------+---+---+
| No. | Name | E | U |
+------+-----------------+---+---+
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
| 5 | If-None-Match | x | |
| 6 | Observe | x | x |
| 7 | Uri-Port | | x |
| 8 | Location-Path | x | |
| 9 | OSCORE | | x |
| 11 | Uri-Path | x | |
| 12 | Content-Format | x | |
| 14 | Max-Age | x | x |
| 15 | Uri-Query | x | |
| 17 | Accept | x | |
| 20 | Location-Query | x | |
| 23 | Block2 | x | x |
| 27 | Block1 | x | x |
| 28 | Size2 | x | x |
| 35 | Proxy-Uri | | x |
| 39 | Proxy-Scheme | | x |
| 60 | Size1 | x | x |
| 258 | No-Response | x | x |
+------+-----------------+---+---+
E = Encrypt and Integrity Protect (Inner) U = Unprotected (Outer)
E =暗号化および整合性保護（内部）U =保護されていない（外部）
Figure 5: Protection of CoAP Options
図5：CoAPオプションの保護
Outer option message fields (Class U or I) are used to support proxy operations, see Appendix D.2.
外部オプションメッセージフィールド（クラスUまたはI）は、プロキシ操作をサポートするために使用されます。付録D.2を参照してください。
The sending endpoint SHALL include the Outer option message field present in the original message in the options part of the OSCORE message. All Outer option message fields, including the OSCORE option, SHALL be encoded as described in Section 3.1 of [RFC7252], where the delta is the difference from the previously included instance of Outer option message field.
送信エンドポイントは、OSCOREメッセージのオプション部分の元のメッセージに存在する外部オプションメッセージフィールドを含む必要があります（SHALL）。 OSCOREオプションを含むすべての外部オプションメッセージフィールドは、[RFC7252]のセクション3.1の説明に従ってエンコードする必要があります（SHOULD）。デルタは、以前に含まれていた外部オプションメッセージフィールドのインスタンスとの差です。
The processing of Outer options by the receiving endpoint is specified in Sections 8.2 and 8.4.
受信エンドポイントによる外部オプションの処理は、セクション8.2および8.4で指定されています。
A procedure for integrity-protection-only of Class I option message fields is specified in Section 5.4. Specifications that introduce repeatable Class I options MUST specify that proxies MUST NOT change the order of the instances of such an option in the CoAP message.
クラスIオプションメッセージフィールドの整合性保護のみの手順は、5.4節で指定されています。反復可能なクラスIオプションを導入する仕様では、プロキシがCoAPメッセージ内のそのようなオプションのインスタンスの順序を変更してはならないことを指定する必要があります。
Note: There are currently no Class I option message fields defined.
注：現在、クラスIオプションメッセージフィールドは定義されていません。
Some options require special processing as specified in this section.
一部のオプションには、このセクションで指定されている特別な処理が必要です。
An Inner Max-Age message field is used to indicate the maximum time a response may be cached by the client (as defined in [RFC7252]), end-to-end from the server to the client, taking into account that the option is not accessible to proxies. The Inner Max-Age SHALL be processed by OSCORE as a normal Inner option, specified in Section 4.1.1.
Inner Max-Ageメッセージフィールドは、サーバーがクライアントにエンドツーエンドで（[RFC7252]で定義されているように）応答をクライアントがキャッシュできる最大時間を示し、オプションがプロキシにはアクセスできません。内部最大年齢は、セクション4.1.1で指定されている通常の内部オプションとしてOSCOREによって処理されるものとします（SHALL）。
An Outer Max-Age message field is used to avoid unnecessary caching of error responses caused by OSCORE processing at OSCORE-unaware intermediary nodes. A server MAY set a Class U Max-Age message field with value zero to such error responses, described in Sections 7.4, 8.2, and 8.4, since these error responses are cacheable, but subsequent OSCORE requests would never create a hit in the intermediary node caching it. Setting the Outer Max-Age to zero relieves the intermediary from uselessly caching responses. Successful OSCORE responses do not need to include an Outer Max-Age option. Except when the Observe option (see Section 4.1.3.5) is used, responses appear to the OSCORE-unaware intermediary as 2.04 (Changed) responses, which are non-cacheable (see Section 4.2). For Observe responses, which are cacheable, an Outer Max-Age option with value 0 may be used to avoid unnecessary proxy caching.
Outer Max-Ageメッセージフィールドは、OSCORE非対応中間ノードでのOSCORE処理によって引き起こされるエラー応答の不要なキャッシュを回避するために使用されます。これらのエラー応答はキャッシュ可能ですが、後続のOSCORE要求が中間ノードでヒットを作成することはないため、サーバーは、セクションUの最大期間メッセージフィールドに値0のエラー応答を設定できます（セクション7.4、8.2、および8.4で説明）。それをキャッシュします。 Outer Max-Ageを0に設定すると、中間者が応答を無駄にキャッシュすることから解放されます。成功したOSCORE応答には、Outer Max-Ageオプションを含める必要はありません。監視オプション（セクション4.1.3.5を参照）を使用する場合を除いて、応答はOSCORE非対応の仲介者に対して2.04（変更済み）応答として表示され、キャッシュ不可（セクション4.2を参照）です。キャッシュ可能なObserve応答の場合、値0のOuter Max-Ageオプションを使用して、不要なプロキシキャッシングを回避できます。
The Outer Max-Age message field is processed according to Section 4.1.2.
Outer Max-Ageメッセージフィールドは、セクション4.1.2に従って処理されます。
When the Uri-Host and Uri-Port are set to their default values (see Section 5.10.1 [RFC7252]), they are omitted from the message (Section 5.4.4 of [RFC7252]), which is favorable both for overhead and privacy.
Uri-HostとUri-Portがデフォルト値に設定されている場合（セクション5.10.1 [RFC7252]を参照）、メッセージから省略されます（[RFC7252]のセクション5.4.4））。これはオーバーヘッドとプライバシー。
In order to support forward proxy operations, Proxy-Scheme, Uri-Host, and Uri-Port need to be Class U. For the use of Proxy-Uri, see Section 4.1.3.3.
フォワードプロキシ操作をサポートするには、Proxy-Scheme、Uri-Host、およびUri-PortがクラスUである必要があります。Proxy-Uriの使用については、4.1.3.3項を参照してください。
Manipulation of unprotected message fields (including Uri-Host, Uri-Port, destination IP/port or request scheme) MUST NOT lead to an OSCORE message becoming verified by an unintended server. Different servers SHALL have different security contexts.
保護されていないメッセージフィールド（Uri-Host、Uri-Port、宛先IP /ポート、または要求スキームを含む）を操作しても、OSCOREメッセージが意図しないサーバーによって検証されることにはなりません。異なるサーバーは異なるセキュリティコンテキストを持つ必要があります。
When Proxy-Uri is present, the client SHALL first decompose the Proxy-Uri value of the original CoAP message into the Proxy-Scheme, Uri-Host, Uri-Port, Uri-Path, and Uri-Query options according to Section 6.4 of [RFC7252].
Proxy-Uriが存在する場合、クライアントは、最初に、元のCoAPメッセージのProxy-Uri値を、セクション6.4に従ってProxy-Scheme、Uri-Host、Uri-Port、Uri-Path、およびUri-Queryオプションに分解する必要があります（SHALL）。 [RFC7252]。
Uri-Path and Uri-Query are Class E options and SHALL be protected and processed as Inner options (Section 4.1.1).
Uri-PathおよびUri-QueryはクラスEオプションであり、内部オプションとして保護および処理する必要があります（セクション4.1.1）。
The Proxy-Uri option of the OSCORE message SHALL be set to the composition of Proxy-Scheme, Uri-Host, and Uri-Port options as specified in Section 6.5 of [RFC7252] and processed as an Outer option of Class U (Section 4.1.2).
OSCOREメッセージのProxy-Uriオプションは、[RFC7252]のセクション6.5で指定されているように、Proxy-Scheme、Uri-Host、およびUri-Portオプションの構成に設定し、クラスUの外部オプションとして処理する必要があります（セクション4.1）。 .2）。
Note that replacing the Proxy-Uri value with the Proxy-Scheme and Uri-* options works by design for all CoAP URIs (see Section 6 of [RFC7252]). OSCORE-aware HTTP servers should not use the userinfo component of the HTTP URI (as defined in Section 3.2.1 of [RFC3986]), so that this type of replacement is possible in the presence of CoAP-to-HTTP proxies (see Section 11.2). In future specifications of cross-protocol proxying behavior using different URI structures, it is expected that the authors will create Uri-* options that allow decomposing the Proxy-Uri, and specifying the OSCORE processing.
Proxy-Uri値をProxy-SchemeおよびUri- *オプションで置き換えることは、すべてのCoAP URIに対して仕様上機能することに注意してください（[RFC7252]のセクション6を参照）。 OSCORE対応のHTTPサーバーは、HTTP URIのuserinfoコンポーネント（[RFC3986]のセクション3.2.1で定義）を使用しないでください。これにより、CoAP-to-HTTPプロキシが存在する場合に、このタイプの置換が可能になります（セクションを参照）。 11.2）。異なるURI構造を使用したクロスプロトコルプロキシ動作の将来の仕様では、作成者がProxy-Uriの分解とOSCORE処理の指定を可能にするUri- *オプションを作成することが期待されています。
An example of how Proxy-Uri is processed is given here. Assume that the original CoAP message contains:
ここでは、Proxy-Uriの処理方法の例を示します。元のCoAPメッセージに次のものが含まれていると仮定します。
o Proxy-Uri = "coap://example.com/resource?q=1"
o Proxy-Uri = "coap：//example.com/resource？q = 1"
During OSCORE processing, Proxy-Uri is split into:
OSCOREの処理中に、Proxy-Uriは次のように分割されます。
o Proxy-Scheme = "coap"
o Proxy-Scheme = "coap"
o Uri-Host = "example.com"
o Uri-Host = "example.com"
o Uri-Port = "5683" (default)
o Uri-Port = "5683"（デフォルト）
o Uri-Path = "resource"
o Uri-Path = "リソース"
o Uri-Query = "q=1" Uri-Path and Uri-Query follow the processing defined in Section 4.1.1; thus, they are encrypted and transported in the COSE object:
o Uri-Query = "q = 1" Uri-PathおよびUri-Queryは、セクション4.1.1で定義された処理に従います。したがって、これらは暗号化され、COSEオブジェクトで転送されます。
o Uri-Path = "resource"
o Uri-Path = "リソース"
o Uri-Query = "q=1"
o Uri-Query = "q = 1"
The remaining options are composed into the Proxy-Uri included in the options part of the OSCORE message, which has value:
残りのオプションは、OSCOREメッセージのオプション部分に含まれるProxy-Uriに組み込まれます。
o Proxy-Uri = "coap://example.com"
o Proxy-Uri = "coap：//example.com"
See Sections 6.1 and 12.6 of [RFC7252] for more details.
詳細については、[RFC7252]のセクション6.1および12.6を参照してください。
Block-wise [RFC7959] is an optional feature. An implementation MAY support CoAP [RFC7252] and the OSCORE option without supporting block-wise transfers. The Block options (Block1, Block2, Size1, Size2), when Inner message fields, provide secure message segmentation such that each segment can be verified. The Block options, when Outer message fields, enable hop-by-hop fragmentation of the OSCORE message. Inner and Outer block processing may have different performance properties depending on the underlying transport. The end-to-end integrity of the message can be verified both in case of Inner and Outer Block-wise transfers, provided all blocks are received.
ブロックワイズ[RFC7959]はオプション機能です。実装は、ブロック単位の転送をサポートせずにCoAP [RFC7252]とOSCOREオプションをサポートしてもよい（MAY）。ブロックオプション（Block1、Block2、Size1、Size2）は、内部メッセージフィールドの場合、各セグメントを検証できるように安全なメッセージセグメンテーションを提供します。 [ブロック]オプションは、外部メッセージフィールドの場合、OSCOREメッセージのホップバイホップフラグメンテーションを有効にします。内部および外部ブロック処理は、基になるトランスポートに応じて異なるパフォーマンスプロパティを持つ場合があります。メッセージのエンドツーエンドの整合性は、すべてのブロックが受信された場合に、ブロック単位の内部転送と外部転送の両方で検証できます。
The sending CoAP endpoint MAY fragment a CoAP message as defined in [RFC7959] before the message is processed by OSCORE. In this case, the Block options SHALL be processed by OSCORE as normal Inner options (Section 4.1.1). The receiving CoAP endpoint SHALL process the OSCORE message before processing Block-wise as defined in [RFC7959].
送信CoAPエンドポイントは、メッセージがOSCOREによって処理される前に、[RFC7959]で定義されているCoAPメッセージをフラグメント化してもよい（MAY）。この場合、ブロックオプションはOSCOREによって通常の内部オプションとして処理される必要があります（セクション4.1.1）。 [RFC7959]で定義されているように、受信CoAPエンドポイントは、ブロック単位で処理する前にOSCOREメッセージを処理する必要があります（SHALL）。
Proxies MAY fragment an OSCORE message using [RFC7959] by introducing Block option message fields that are Outer (Section 4.1.2). Note that the Outer Block options are neither encrypted nor integrity protected. As a consequence, a proxy can maliciously inject block fragments indefinitely, since the receiving endpoint needs to receive the last block (see [RFC7959]) to be able to compose the OSCORE message and verify its integrity. Therefore, applications supporting OSCORE and [RFC7959] MUST specify a security policy defining a maximum unfragmented message size (MAX_UNFRAGMENTED_SIZE) considering the maximum size of message that can be handled by the endpoints. Messages exceeding this size SHOULD be fragmented by the sending endpoint using Inner Block options (Section 4.1.3.4.1).
プロキシは、[RFC7959]を使用して、外部のブロックオプションメッセージフィールドを導入することにより、OSCOREメッセージをフラグメント化できます（セクション4.1.2）。外部ブロックオプションは、暗号化も完全性も保護されないことに注意してください。その結果、受信側エンドポイントがOSCOREメッセージを作成してその整合性を検証できるようにするには、受信側エンドポイントが最後のブロック（[RFC7959]を参照）を受信する必要があるため、プロキシが無期限にブロックフラグメントを悪意を持って挿入する可能性があります。したがって、OSCOREと[RFC7959]をサポートするアプリケーションは、エンドポイントで処理できるメッセージの最大サイズを考慮して、フラグメント化されていない最大メッセージサイズ（MAX_UNFRAGMENTED_SIZE）を定義するセキュリティポリシーを指定する必要があります。このサイズを超えるメッセージは、内部ブロックオプションを使用して送信エンドポイントでフラグメント化する必要があります（セクション4.1.3.4.1）。
An endpoint receiving an OSCORE message with an Outer Block option SHALL first process this option according to [RFC7959], until all blocks of the OSCORE message have been received or the cumulated message size of the blocks exceeds MAX_UNFRAGMENTED_SIZE. In the former case, the processing of the OSCORE message continues as defined in this document. In the latter case, the message SHALL be discarded.
外部ブロックオプションでOSCOREメッセージを受信するエンドポイントは、OSCOREメッセージのすべてのブロックが受信されるか、ブロックの累積メッセージサイズがMAX_UNFRAGMENTED_SIZEを超えるまで、最初に[RFC7959]に従ってこのオプションを処理する必要があります。前者の場合、OSCOREメッセージの処理は、このドキュメントでの定義に従って続行されます。後者の場合、メッセージは破棄される必要があります。
Because of encryption of Uri-Path and Uri-Query, messages to the same server may, from the point of view of a proxy, look like they also target the same resource. A proxy SHOULD mitigate a potential mix-up of blocks from concurrent requests to the same server, for example, using the Request-Tag processing specified in Section 3.3.2 of [CoAP-ECHO-REQ-TAG].
Uri-PathとUri-Queryの暗号化のため、同じサーバーへのメッセージは、プロキシの観点からは、同じリソースをターゲットにしているように見える場合があります。プロキシは、たとえば、[CoAP-ECHO-REQ-TAG]のセクション3.3.2で指定されているRequest-Tag処理を使用して、同時リクエストから同じサーバーへのブロックの潜在的な混在を軽減する必要があります（SHOULD）。
Observe [RFC7641] is an optional feature. An implementation MAY support CoAP [RFC7252] and the OSCORE option without supporting [RFC7641], in which case the Observe-related processing can be omitted.
観察[RFC7641]はオプション機能です。実装はCoAP [RFC7252]および[RFC7641]をサポートせずにOSCOREオプションをサポートしてもよい（MAY）。この場合、Observe関連の処理は省略できます。
The support for Observe [RFC7641] with OSCORE targets the requirements on forwarding of Section 2.2.1 of [CoAP-E2E-Sec], i.e., that observations go through intermediary nodes, as illustrated in Figure 8 of [RFC7641].
OSCOREによるObserve [RFC7641]のサポートは、[CoAP-E2E-Sec]のセクション2.2.1の転送に関する要件を対象としています。つまり、[RFC7641]の図8に示すように、観測は中間ノードを通過します。
Inner Observe SHALL be used to protect the value of the Observe option between the endpoints. Outer Observe SHALL be used to support forwarding by intermediary nodes.
内部監視は、エンドポイント間の監視オプションの値を保護するために使用する必要があります。 Outer Observeは、中間ノードによる転送をサポートするために使用する必要があります。
The server SHALL include a new Partial IV (see Section 5) in responses (with or without the Observe option) to Observe registrations, except for the first response where Partial IV MAY be omitted.
サーバーは、登録を監視するための応答に（監視オプションありまたはなしで）新しい部分IV（セクション5を参照）を含める必要があります（ただし、部分IVを省略できる最初の応答を除く）。
For cancellations, Section 3.6 of [RFC7641] specifies that all options MUST be identical to those in the registration request except for the Observe option and the set of ETag options. For OSCORE messages, this matching is to be done to the options in the decrypted message.
キャンセルについては、[RFC7641]のセクション3.6に、監視オプションと一連のETagオプションを除いて、すべてのオプションが登録リクエストのオプションと同一でなければならないことを指定しています。 OSCOREメッセージの場合、この照合は、復号化されたメッセージのオプションに対して行われます。
[RFC7252] does not specify how the server should act upon receiving the same Token in different requests. When using OSCORE, the server SHOULD NOT remove an active observation just because it receives a request with the same Token.
[RFC7252]は、異なるリクエストで同じトークンを受信したときのサーバーの動作を指定していません。 OSCOREを使用する場合、サーバーは同じトークンでリクエストを受け取ったからといって、アクティブな監視を削除してはなりません（SHOULD NOT）。
Since POST with the Observe option is not defined, for messages with the Observe option, the Outer Code MUST be set to 0.05 (FETCH) for requests and to 2.05 (Content) for responses (see Section 4.2).
監視オプション付きのPOSTは定義されていないため、監視オプション付きのメッセージの場合、外部コードは要求の場合は0.05（FETCH）、応答の場合は2.05（コンテンツ）に設定する必要があります（セクション4.2を参照）。
The Inner and Outer Observe options in the request MUST contain the Observe value of the original CoAP request; 0 (registration) or 1 (cancellation).
要求の内部および外部監視オプションには、元のCoAP要求の監視値が含まれている必要があります。 0（登録）または1（キャンセル）。
Every time a client issues a new request with the Observe option, a new Partial IV MUST be used (see Section 5), and so the payload and OSCORE option are changed. The server uses the Partial IV of the new request as the 'request_piv' of all associated notifications (see Section 5.4).
クライアントがObserveオプションを使用して新しいリクエストを発行するたびに、新しいPartial IVを使用する必要があり（セクション5を参照）、ペイロードとOSCOREオプションが変更されます。サーバーは、関連するすべての通知の「request_piv」として、新しいリクエストのPartial IVを使用します（セクション5.4を参照）。
Intermediaries are not assumed to have access to the OSCORE security context used by the endpoints; thus, they cannot make requests or transform responses with the OSCORE option that pass verification (at the receiving endpoint) as having come from the other endpoint. This has the following consequences and limitations for Observe operations.
仲介者は、エンドポイントが使用するOSCOREセキュリティコンテキストにアクセスできるとは想定されていません。したがって、他のエンドポイントから来たものとして（受信エンドポイントで）検証に合格したOSCOREオプションを使用して、リクエストや変換応答を行うことはできません。これには、Observeオペレーションに対して次のような結果と制限があります。
o An intermediary node removing the Outer Observe 0 option does not change the registration request to a request without the Observe option (see Section 2 of [RFC7641]). Instead other means for cancellation may be used as described in Section 3.6 of [RFC7641].
o 外部監視0オプションを削除する中間ノードは、登録要求を監視オプションなしの要求に変更しません（[RFC7641]のセクション2を参照）。代わりに、[RFC7641]のセクション3.6で説明されているように、他のキャンセル手段を使用できます。
o An intermediary node is not able to transform a normal response into an OSCORE-protected Observe notification (see Figure 7 of [RFC7641]) that verifies as coming from the server.
o 中間ノードは、通常の応答をOSCOREで保護された監視通知（[RFC7641]の図7を参照）に変換できず、サーバーから送信されたことを確認できます。
o An intermediary node is not able to initiate an OSCORE protected Observe registration (Observe option with value 0) that verifies as coming from the client. An OSCORE-aware intermediary SHALL NOT initiate registrations of observations (see Section 10). If an OSCORE-unaware proxy resends an old registration message from a client, the replay protection mechanism in the server will be triggered. To prevent this from resulting in the OSCORE-unaware proxy canceling the registration, a server MAY respond to a replayed registration request with a replay of a cached notification. Alternatively, the server MAY send a new notification.
o 中間ノードは、OSCOREで保護された監視登録（値0の監視オプション）を開始できず、クライアントから送信されたものとして検証されます。 OSCORE対応の仲介者は、観測の登録を開始しないものとします（セクション10を参照）。 OSCORE非対応プロキシがクライアントから古い登録メッセージを再送信すると、サーバーのリプレイ保護メカニズムがトリガーされます。これによりOSCORE非対応プロキシが登録をキャンセルすることを防ぐために、サーバーは、キャッシュされた通知の再生を使用して、再生された登録要求に応答する場合があります。あるいは、サーバーは新しい通知を送信してもよい（MAY）。
o An intermediary node is not able to initiate an OSCORE-protected Observe cancellation (Observe option with value 1) that verifies as coming from the client. An application MAY decide to allow intermediaries to cancel Observe registrations, e.g., to send the Observe option with value 1 (see Section 3.6 of [RFC7641]); however, that can also be done with other methods, e.g., by sending a RST message. This is out of scope for this specification.
o 中間ノードは、OSCOREで保護された監視のキャンセル（値が1の監視オプション）を開始できず、クライアントから送信されたものとして検証されます。アプリケーションは、仲介者が監視登録を取り消すことを許可することを決定する場合があります。たとえば、値1の監視オプションを送信します（[RFC7641]のセクション3.6を参照）。ただし、これは、RSTメッセージを送信するなど、他の方法でも実行できます。これはこの仕様の範囲外です。
If the server accepts an Observe registration, a Partial IV MUST be included in all notifications (both successful and error), except for the first one where the Partial IV MAY be omitted. To protect against replay, the client SHALL maintain a Notification Number for each Observation it registers. The Notification Number is a non-negative integer containing the largest Partial IV of the received notifications for the associated Observe registration. Further details of replay protection of notifications are specified in Section 7.4.1.
サーバーが監視登録を受け入れる場合、部分IVを省略できる最初の通知を除いて、すべての通知（成功とエラーの両方）に部分IVを含める必要があります。リプレイから保護するために、クライアントは登録する各観測の通知番号を維持する必要があります（SHALL）。通知番号は、関連するObserve登録の受信通知の最大の部分IVを含む負でない整数です。通知のリプレイ保護の詳細は、セクション7.4.1で指定されています。
For notifications, the Inner Observe option value MUST be empty (see Section 3.2 of [RFC7252]). The Outer Observe option in a notification is needed for intermediary nodes to allow multiple responses to one request, and it MAY be set to the value of the Observe option in the original CoAP message. The client performs ordering of notifications and replay protection by comparing their Partial IVs and SHALL ignore the Outer Observe option value.
通知の場合、内部監視オプションの値は空にする必要があります（[RFC7252]のセクション3.2を参照）。通知の外部監視オプションは、中間ノードが1つの要求に対する複数の応答を許可するために必要であり、元のCoAPメッセージの監視オプションの値に設定される場合があります。クライアントは、パーシャルIVを比較して通知の順序付けとリプレイ保護を実行し、外部監視オプションの値を無視する必要があります（SHALL）。
If the client receives a response to an Observe request without an Inner Observe option, then it verifies the response as a non-Observe response, as specified in Section 8.4. If the client receives a response to a non-Observe request with an Inner Observe option, then it stops processing the message, as specified in Section 8.4.
クライアントが内部監視オプションなしで監視要求への応答を受信した場合、クライアントはセクション8.4で指定されているように、応答を非監視応答として検証します。クライアントが「内部監視」オプションを使用した非監視要求への応答を受信すると、セクション8.4で指定されているように、クライアントはメッセージの処理を停止します。
A client MUST consider the notification with the highest Partial IV as the freshest, regardless of the order of arrival. In order to support existing Observe implementations, the OSCORE client implementation MAY set the Observe option value to the three least significant bytes of the Partial IV. Implementations need to make sure that the notification without Partial IV is considered the oldest.
クライアントは、到着の順序に関係なく、最高のパーシャルIVの通知を最新のものと見なす必要があります。既存のObserve実装をサポートするために、OSCOREクライアント実装はObserveオプション値をPartial IVの最下位3バイトに設定してもよい（MAY）。実装では、Partial IVのない通知が最も古いと見なされることを確認する必要があります。
No-Response [RFC7967] is an optional feature used by the client to communicate its disinterest in certain classes of responses to a particular request. An implementation MAY support [RFC7252] and the OSCORE option without supporting [RFC7967].
応答なし[RFC7967]は、特定の要求に対する特定のクラスの応答に関心がないことを伝えるためにクライアントが使用するオプション機能です。実装は、[RFC7967]をサポートせずに[RFC7252]およびOSCOREオプションをサポートする場合があります。
If used, No-Response MUST be Inner. The Inner No-Response SHALL be processed by OSCORE as specified in Section 4.1.1. The Outer option SHOULD NOT be present. The server SHALL ignore the Outer No-Response option. The client MAY set the Outer No-Response value to 26 (suppress all known codes) if the Inner value is set to 26. The client MUST be prepared to receive and discard 5.04 (Gateway Timeout) error messages from intermediaries potentially resulting from destination time out due to no response.
使用する場合、No-Responseは内部である必要があります。内部無応答は、セクション4.1.1で指定されているようにOSCOREによって処理されるものとします（SHALL）。外部オプションは存在すべきではありません。サーバーは外部の無応答オプションを無視する必要があります（SHALL）。クライアントは、Inner値が26に設定されている場合、Outer No-Response値を26（すべての既知のコードを抑制する）に設定してもよい（MAY）。クライアントは、宛先時間に起因する可能性のある仲介者からの5.04（ゲートウェイタイムアウト）エラーメッセージを受信して破棄する準備をしなければならない（MUST）。応答がないためアウト。
The OSCORE option is only defined to be present in OSCORE messages as an indication that OSCORE processing has been performed. The content in the OSCORE option is neither encrypted nor integrity protected as a whole, but some part of the content of this option is protected (see Section 5.4). Nested use of OSCORE is not supported: If OSCORE processing detects an OSCORE option in the original CoAP message, then processing SHALL be stopped.
OSCOREオプションは、OSCORE処理が実行されたことを示すものとして、OSCOREメッセージに存在するようにのみ定義されています。 OSCOREオプションのコンテンツは、全体として暗号化も完全性も保護されていませんが、このオプションのコンテンツの一部は保護されています（セクション5.4を参照）。 OSCOREのネストされた使用はサポートされていません。OSCORE処理が元のCoAPメッセージでOSCOREオプションを検出した場合、処理は停止する必要があります（SHALL）。
A summary of how the CoAP header fields and payload are protected is shown in Figure 6, including fields specific to CoAP over UDP and CoAP over TCP (marked accordingly in the table).
CoAPヘッダーフィールドとペイロードがどのように保護されるかについての概要を図6に示します。これには、CoAP over UDPおよびCoAP over TCPに固有のフィールドが含まれます（表で適宜マークされています）。
+------------------+---+---+
| Field | E | U |
+------------------+---+---+
| Version (UDP) | | x |
| Type (UDP) | | x |
| Length (TCP) | | x |
| Token Length | | x |
| Code | x | |
| Message ID (UDP) | | x |
| Token | | x |
| Payload | x | |
+------------------+---+---+
E = Encrypt and Integrity Protect (Inner)
U = Unprotected (Outer)
Figure 6: Protection of CoAP Header Fields and Payload
図6：CoAPヘッダーフィールドとペイロードの保護
Most CoAP header fields (i.e., the message fields in the fixed 4-byte header) are required to be read and/or changed by CoAP proxies; thus, they cannot, in general, be protected end-to-end from one endpoint to the other. As mentioned in Section 1, OSCORE protects the CoAP request/response layer only and not the CoAP messaging layer (Section 2 of [RFC7252]), so fields such as Type and Message ID are not protected with OSCORE.
ほとんどのCoAPヘッダーフィールド（つまり、4バイトの固定ヘッダー内のメッセージフィールド）は、CoAPプロキシによる読み取りや変更が必要です。したがって、一般に、エンドポイント間でエンドポイント間を保護することはできません。セクション1で述べたように、OSCOREはCoAPリクエスト/レスポンスレイヤーのみを保護し、CoAPメッセージングレイヤーは保護しないため（[RFC7252]のセクション2）、タイプやメッセージIDなどのフィールドはOSCOREで保護されません。
The CoAP header field Code is protected by OSCORE. Code SHALL be encrypted and integrity protected (Class E) to prevent an intermediary from eavesdropping on or manipulating it (e.g., changing from GET to DELETE).
CoAPヘッダーフィールドコードはOSCOREによって保護されています。コードは暗号化され、整合性が保護されている必要があります（クラスE）。
The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see Section 5.3). After that, the sending endpoint writes an Outer Code to the OSCORE message. With one exception (see Section 4.1.3.5), the Outer Code SHALL be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses. The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (Section 5.3) into the decrypted CoAP message.
送信エンドポイントは、元のCoAPメッセージのコードをCOSEオブジェクトのプレーンテキストに書き込む必要があります（セクション5.3を参照）。その後、送信エンドポイントはOSCOREメッセージに外部コードを書き込みます。 1つの例外を除き（セクション4.1.3.5を参照）、外部コードは、要求の場合は0.02（POST）に、応答の場合は2.04（変更）に設定する必要があります（SHALL）。受信エンドポイントは、OSCOREメッセージ内の外部コードを破棄し、復号化されたCoAPメッセージにCOSEオブジェクトプレーンテキスト（セクション5.3）のコードを書き込む必要があります（SHALL）。
The other currently defined CoAP header fields are Unprotected (Class U). The sending endpoint SHALL write all other header fields of the original message into the header of the OSCORE message. The receiving endpoint SHALL write the header fields from the received OSCORE message into the header of the decrypted CoAP message.
現在定義されている他のCoAPヘッダーフィールドは、保護されていない（クラスU）です。送信エンドポイントは、元のメッセージの他のすべてのヘッダーフィールドをOSCOREメッセージのヘッダーに書き込む必要があります。受信エンドポイントは、受信したOSCOREメッセージのヘッダーフィールドを、復号化されたCoAPメッセージのヘッダーに書き込む必要があります（SHALL）。
The CoAP Payload, if present in the original CoAP message, SHALL be encrypted and integrity protected; thus, it is an Inner message field. The sending endpoint writes the payload of the original CoAP message into the plaintext (Section 5.3) input to the COSE object. The receiving endpoint verifies and decrypts the COSE object, and it recreates the payload of the original CoAP message.
CoAPペイロードは、元のCoAPメッセージに存在する場合、暗号化され、整合性が保護されている必要があります。したがって、これは内部メッセージフィールドです。送信エンドポイントは、元のCoAPメッセージのペイロードをCOSEオブジェクトへのプレーンテキスト（5.3節）入力に書き込みます。受信エンドポイントはCOSEオブジェクトを検証および復号化し、元のCoAPメッセージのペイロードを再作成します。
Signaling messages (CoAP Code 7.00-7.31) were introduced to exchange information related to an underlying transport connection in the specific case of CoAP over reliable transports [RFC8323].
シグナリングメッセージ（CoAPコード7.00〜7.31）は、信頼できるトランスポートを介したCoAPの特定のケースで、基になるトランスポート接続に関連する情報を交換するために導入されました[RFC8323]。
OSCORE MAY be used to protect signaling if the endpoints for OSCORE coincide with the endpoints for the signaling message. If OSCORE is used to protect signaling then:
OSCOREは、OSCOREのエンドポイントがシグナリングメッセージのエンドポイントと一致する場合に、シグナリングを保護するために使用できます。 OSCOREを使用してシグナリングを保護する場合：
o To comply with [RFC8323], an initial empty Capabilities and Settings Message (CSM) SHALL be sent. The subsequent signaling message SHALL be protected.
o [RFC8323]に準拠するには、最初の空の機能と設定メッセージ（CSM）を送信する必要があります（SHALL）。後続のシグナリングメッセージは保護する必要があります。
o Signaling messages SHALL be protected as CoAP request messages, except in the case in which the signaling message is a response to a previous signaling message; then it SHALL be protected as a CoAP response message. For example, 7.02 (Ping) is protected as a CoAP request and 7.03 (Pong) as a CoAP response.
o シグナリングメッセージが前のシグナリングメッセージへの応答である場合を除いて、シグナリングメッセージはCoAP要求メッセージとして保護される必要があります。次に、それはCoAP応答メッセージとして保護される必要があります。たとえば、7.02（Ping）はCoAP要求として保護され、7.03（Pong）はCoAP応答として保護されます。
o The Outer Code for signaling messages SHALL be set to 0.02 (POST), unless it is a response to a previous signaling message, in which case it SHALL be set to 2.04 (Changed).
o シグナリングメッセージの外部コードは、以前のシグナリングメッセージへの応答でない限り、0.02（POST）に設定する必要があります。その場合、2.04（変更）に設定する必要があります。
o All signaling options, except the OSCORE option, SHALL be Inner (Class E).
o OSCOREオプションを除くすべてのシグナリングオプションは、内部（クラスE）である必要があります。
NOTE: Option numbers for signaling messages are specific to the CoAP Code (see Section 5.2 of [RFC8323]).
注：シグナリングメッセージのオプション番号はCoAPコードに固有です（[RFC8323]のセクション5.2を参照）。
If OSCORE is not used to protect signaling, Signaling messages SHALL be unaltered by OSCORE.
OSCOREがシグナリングの保護に使用されていない場合、シグナリングメッセージはOSCOREによって変更されないものとします（SHALL）。
This section defines how to use COSE [RFC8152] to wrap and protect data in the original message. OSCORE uses the untagged COSE_Encrypt0 structure (see Section 5.2 of [RFC8152]) with an AEAD algorithm. The AEAD key lengths, AEAD nonce length, and maximum Sender Sequence Number are algorithm dependent.
このセクションでは、COSE [RFC8152]を使用して、元のメッセージのデータをラップおよび保護する方法を定義します。 OSCOREは、タグなしのCOSE_Encrypt0構造（[RFC8152]のセクション5.2を参照）をAEADアルゴリズムで使用します。 AEADキーの長さ、AEADナンスの長さ、最大送信者シーケンス番号は、アルゴリズムによって異なります。
The AEAD algorithm AES-CCM-16-64-128 defined in Section 10.2 of [RFC8152] is mandatory to implement. For AES-CCM-16-64-128, the length of Sender Key and Recipient Key is 128 bits; the length of AEAD nonce and Common IV is 13 bytes. The maximum Sender Sequence Number is specified in Section 12.
[RFC8152]のセクション10.2で定義されているAEADアルゴリズムAES-CCM-16-64-128の実装は必須です。 AES-CCM-16-64-128の場合、送信者キーと受信者キーの長さは128ビットです。 AEAD nonceおよびCommon IVの長さは13バイトです。最大送信者シーケンス番号は、セクション12で指定されています。
As specified in [RFC5116], plaintext denotes the data that is to be encrypted and integrity protected, and Additional Authenticated Data (AAD) denotes the data that is to be integrity protected only.
[RFC5116]で指定されているように、プレーンテキストは暗号化されて整合性が保護されるデータを示し、追加認証データ（AAD）は整合性のみが保護されるデータを示します。
The COSE object SHALL be a COSE_Encrypt0 object with fields defined as follows:
COSEオブジェクトは、次のようにフィールドが定義されたCOSE_Encrypt0オブジェクトである必要があります（SHALL）。
o The 'protected' field is empty.
o 「保護」フィールドは空です。
o The 'unprotected' field includes:
o 「保護されていない」フィールドには以下が含まれます。
* The 'Partial IV' parameter. The value is set to the Sender Sequence Number. All leading bytes of value zero SHALL be removed when encoding the Partial IV, except in the case of Partial IV value 0, which is encoded to the byte string 0x00.
* 「部分IV」パラメーター。値は送信者シーケンス番号に設定されます。バイト文字列0x00にエンコードされる部分IV値0の場合を除いて、値0のすべての先行バイトは、部分IVをエンコードするときに削除される必要があります。
This parameter SHALL be present in requests and will not typically be present in responses (for two exceptions, see Observe notifications (Section 4.1.3.5.2) and Replay Window synchronization (Appendix B.1.2)).
このパラメータはリクエストに存在する必要があり、通常は応答には存在しません（2つの例外については、通知の監視（セクション4.1.3.5.2）および再生ウィンドウの同期（付録B.1.2）を参照してください）。
* The 'kid' parameter. The value is set to the Sender ID. This parameter SHALL be present in requests and will not typically be present in responses. An example where the Sender ID is included in a response is the extension of OSCORE to group communication [Group-OSCORE].
* 「子供」パラメータ。値は送信者IDに設定されます。このパラメーターは要求に存在する必要があり（SHALL）、通常応答には存在しません。 Sender IDが応答に含まれる例は、グループ通信へのOSCOREの拡張です[Group-OSCORE]。
* Optionally, a 'kid context' parameter (see Section 5.1). This parameter MAY be present in requests and, if so, MUST contain an ID Context (see Section 3.1). This parameter SHOULD NOT be present in responses: an example of how 'kid context' can be used in responses is given in Appendix B.2. If 'kid context' is present in the request, then the server SHALL use a security context with that ID Context when verifying the request.
* オプションで、「キッドコンテキスト」パラメータ（セクション5.1を参照）。このパラメータはリクエストに存在する場合があり、存在する場合は、IDコンテキストを含める必要があります（セクション3.1を参照）。このパラメーターは応答に存在してはなりません（SHOULD NOT）。応答での「子供コンテキスト」の使用例は、付録B.2にあります。リクエストに「子供コンテキスト」が存在する場合、サーバーはリクエストを検証するときにそのIDコンテキストを持つセキュリティコンテキストを使用する必要があります（SHALL）。
o The 'ciphertext' field is computed from the secret key (Sender Key or Recipient Key), AEAD nonce (see Section 5.2), plaintext (see Section 5.3), and the AAD (see Section 5.4) following Section 5.2 of [RFC8152].
o 「暗号文」フィールドは、秘密鍵（送信者鍵または受信者鍵）、AEADナンス（セクション5.2を参照）、平文（セクション5.3を参照）、および[RFC8152]のセクション5.2に続くAAD（セクション5.4を参照）から計算されます。
The encryption process is described in Section 5.3 of [RFC8152].
暗号化プロセスについては、[RFC8152]のセクション5.3で説明されています。
For certain use cases, e.g., deployments where the same Sender ID is used with multiple contexts, it is possible (and sometimes necessary, see Section 3.3) for the client to use an ID Context to distinguish the security contexts (see Section 3.1). For example:
特定のユースケース、たとえば、同じSender IDが複数のコンテキストで使用される展開では、クライアントがIDコンテキストを使用してセキュリティコンテキストを区別することが可能です（場合によっては、セクション3.3を参照）。例えば：
o If the client has a unique identifier in some namespace, then that identifier can be used as ID Context.
o クライアントのネームスペースに一意の識別子がある場合、その識別子はIDコンテキストとして使用できます。
o The ID Context may be used to add randomness into new Sender and Recipient Contexts, see Appendix B.2.
o IDコンテキストは、新しい送信者および受信者コンテキストにランダム性を追加するために使用できます。付録B.2を参照してください。
o In the case of group communication [Group-OSCORE], a group identifier is used as ID Context to enable different security contexts for a server belonging to multiple groups.
o グループ通信[Group-OSCORE]の場合、グループ識別子はIDコンテキストとして使用され、複数のグループに属するサーバーに対して異なるセキュリティコンテキストを有効にします。
The Sender ID and ID Context are used to establish the necessary input parameters and in the derivation of the security context (see Section 3.2).
送信者IDとIDコンテキストは、必要な入力パラメータを確立するため、およびセキュリティコンテキストの導出に使用されます（セクション3.2を参照）。
While the 'kid' parameter is used to transport the Sender ID, the new COSE header parameter 'kid context' is used to transport the ID Context in requests, see Figure 7.
'kid'パラメーターはSender ISを転送するために使用されますが、新しいCODEヘッダーパラメーター 'kid context'はリクエスト内のIDコンテキストを転送するために使用されます。図7を参照してください。
+----------+--------+------------+----------------+-----------------+
| Name | Label | Value Type | Value Registry | Description |
+----------+--------+------------+----------------+-----------------+
| kid | 10 | bstr | | Identifies the |
| context | | | | context for the |
| | | | | key identifier |
+----------+--------+------------+----------------+-----------------+
Figure 7: Common Header Parameter 'kid context' for the COSE Object
図7：COSEオブジェクトの共通ヘッダーパラメーター「子供コンテキスト」
If ID Context is non-empty and the client sends a request without 'kid context' resulting in an error indicating that the server could not find the security context, then the client could include the ID Context in the 'kid context' when making another request. Note that since the error is unprotected, it may have been spoofed and the real response blocked by an on-path attacker.
IDコンテキストが空でなく、クライアントが「キッドコンテキスト」なしでリクエストを送信した結果、サーバーがセキュリティコンテキストを見つけられなかったことを示すエラーが発生した場合、クライアントは別のIDコンテキストを「キッドコンテキスト」に含めることができます。リクエスト。エラーは保護されていないため、なりすましされ、実際の応答がパス上の攻撃者によってブロックされた可能性があることに注意してください。
The high-level design of the AEAD nonce follows Section 4.4 of [IV-GEN]. The detailed construction of the AEAD nonce is presented here (see Figure 8):
AEAD nonceの高レベルの設計は、[IV-GEN]のセクション4.4に従います。 AEAD nonceの詳細な構造を以下に示します（図8を参照）。
1. left-pad the Partial IV (PIV) with zeroes to exactly 5 bytes,
1. パーシャルIV（PIV）にゼロを正確に5バイトまで左詰めします。
2. left-pad the Sender ID of the endpoint that generated the Partial IV (ID_PIV) with zeroes to exactly nonce length minus 6 bytes,
2. ゼロの部分的なIV（ID_PIV）を生成したエンドポイントの送信者IDの左に、正確にノンス長から6バイトを引いたものを左に埋め込み、
3. concatenate the size of the ID_PIV (a single byte S) with the padded ID_PIV and the padded PIV,
3. ID_PIV（1バイトS）のサイズを、埋め込みID_PIVおよび埋め込みPIVと連結します。
4. and then XOR with the Common IV.
4. その後、コモンIVとXORします。
Note that in this specification, only AEAD algorithms that use nonces equal or greater than 7 bytes are supported. The nonce construction with S, ID_PIV, and PIV together with endpoint-unique IDs and encryption keys makes it easy to verify that the nonces used with a specific key will be unique, see Appendix D.4.
この仕様では、7バイト以上のノンスを使用するAEADアルゴリズムのみがサポートされていることに注意してください。 S、ID_PIV、およびPIVとエンドポイント固有のIDおよび暗号化キーを使用したナンス構成により、特定のキーで使用されるナンスが一意であることを簡単に確認できます。付録D.4を参照してください。
If the Partial IV is not present in a response, the nonce from the request is used. For responses that are not notifications (i.e., when there is a single response to a request), the request and the response should typically use the same nonce to reduce message overhead. Both alternatives provide all the required security properties, see Section 7.4 and Appendix D.4. Another non-Observe scenario where a Partial IV is included in a response is when the server is unable to perform replay protection, see Appendix B.1.2. For processing instructions see Section 8.
Partial IVが応答に存在しない場合、要求からのナンスが使用されます。通知ではない応答の場合（つまり、要求に対する単一の応答がある場合）、要求と応答は通常、メッセージのオーバーヘッドを減らすために同じノンスを使用する必要があります。どちらの方法でも、必要なセキュリティプロパティがすべて提供されます。セクション7.4および付録D.4を参照してください。応答にPartial IVが含まれる別の非監視シナリオは、サーバーが再生保護を実行できない場合です。付録B.1.2を参照してください。処理手順については、セクション8を参照してください。
<- nonce length minus 6 B -> <-- 5 bytes -->
+---+-------------------+--------+---------+-----+
| S | padding | ID_PIV | padding | PIV |----+
+---+-------------------+--------+---------+-----+ |
|
<---------------- nonce length ----------------> |
+------------------------------------------------+ |
| Common IV |->(XOR)
+------------------------------------------------+ |
|
<---------------- nonce length ----------------> |
+------------------------------------------------+ |
| Nonce |<---+
+------------------------------------------------+
Figure 8: AEAD Nonce Formation
図8：AEADノンス形成
The plaintext is formatted as a CoAP message with a subset of the header (see Figure 9) consisting of:
プレーンテキストは、以下で構成されるヘッダーのサブセット（図9を参照）を含むCoAPメッセージとしてフォーマットされます。
o the Code of the original CoAP message as defined in Section 3 of [RFC7252]; and
o [RFC7252]のセクション3で定義されている元のCoAPメッセージのコード。そして
o all Inner option message fields (see Section 4.1.1) present in the original CoAP message (see Section 4.1). The options are encoded as described in Section 3.1 of [RFC7252], where the delta is the difference from the previously included instance of Class E option; and
o 元のCoAPメッセージ（セクション4.1を参照）に存在するすべての内部オプションメッセージフィールド（セクション4.1.1を参照）オプションは、[RFC7252]のセクション3.1で説明されているようにエンコードされます。デルタは、以前に含まれていたクラスEオプションのインスタンスとの差です。そして
o the Payload of original CoAP message, if present, and in that case prefixed by the one-byte Payload Marker (0xff).
o 元のCoAPメッセージのペイロード（存在する場合）。その場合、1バイトのペイロードマーカー（0xff）が前に付きます。
NOTE: The plaintext contains all CoAP data that needs to be encrypted end-to-end between the endpoints.
注：プレーンテキストには、エンドポイント間でエンドツーエンドで暗号化する必要があるすべてのCoAPデータが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Class E options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(only if there is payload)
Figure 9: Plaintext
図9：平文
The external_aad SHALL be a CBOR array wrapped in a bstr object as defined below, following the notation of [RFC8610] as summarized in Appendix E:
付録Eに要約されている[RFC8610]の表記に従って、external_aadは、以下に定義されているbstrオブジェクトにラップされたCBOR配列である必要があります（SHALL）。
external_aad = bstr .cbor aad_array
external_aad = bstr .cbor aad_array
aad_array = [
oscore_version : uint,
algorithms : [ alg_aead : int / tstr ],
request_kid : bstr,
request_piv : bstr,
options : bstr,
]
where:
ただし：
o oscore_version: contains the OSCORE version number. Implementations of this specification MUST set this field to 1. Other values are reserved for future versions.
o oscore_version：OSCOREのバージョン番号が含まれています。この仕様の実装では、このフィールドを1に設定する必要があります。その他の値は、将来のバージョン用に予約されています。
o algorithms: contains (for extensibility) an array of algorithms, according to this specification only containing alg_aead.
o アルゴリズム：（拡張性のために）アルゴリズムの配列を含みます。この仕様によれば、alg_aeadのみを含みます。
o alg_aead: contains the AEAD Algorithm from the security context used for the exchange (see Section 3.1).
o alg_aead：交換に使用されるセキュリティコンテキストからのAEADアルゴリズムが含まれます（セクション3.1を参照）。
o request_kid: contains the value of the 'kid' in the COSE object of the request (see Section 5).
o request_kid：リクエストのCOSEオブジェクトの「kid」の値が含まれます（セクション5を参照）。
o request_piv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5).
o request_piv：リクエストのCOSEオブジェクトの「Partial IV」の値が含まれます（セクション5を参照）。
o options: contains the Class I options (see Section 4.1.2) present in the original CoAP message encoded as described in Section 3.1 of [RFC7252], where the delta is the difference from the previously included instance of class I option.
o オプション：[RFC7252]のセクション3.1の説明に従ってエンコードされた元のCoAPメッセージに存在するクラスIオプション（セクション4.1.2を参照）が含まれます。デルタは、以前に含まれていたクラスIオプションのインスタンスとの違いです。
The oscore_version and algorithms parameters are established out-of-band; thus, they are not transported in OSCORE, but the external_aad allows to verify that they are the same in both endpoints.
oscore_versionとアルゴリズムのパラメーターは帯域外で確立されます。したがって、OSCOREでは転送されませんが、external_aadを使用すると、両方のエンドポイントで同じであることを確認できます。
NOTE: The format of the external_aad is, for simplicity, the same for requests and responses, although some parameters, e.g., request_kid, need not be integrity protected in all requests.
注：単純にするために、external_aadの形式は要求と応答で同じですが、一部のパラメーター（request_kidなど）は、すべての要求で整合性を保護する必要はありません。
The AAD is composed from the external_aad as described in Section 5.3 of [RFC8152] (the notation follows [RFC8610] as summarized in Appendix E):
AADは、[RFC8152]のセクション5.3で説明されているように、external_aadから構成されます（表記は[RFC8610]に従い、付録Eに要約されています）。
AAD = Enc_structure = [ "Encrypt0", h'', external_aad ]
The following is an example of AAD constructed using AEAD Algorithm = AES-CCM-16-64-128 (10), request_kid = 0x00, request_piv = 0x25 and no Class I options:
以下は、AEADアルゴリズム= AES-CCM-16-64-128（10）、request_kid = 0x00、request_piv = 0x25、クラスIオプションなしを使用して構築されたAADの例です。
o oscore_version: 0x01 (1 byte)
o oscore_version：0x01（1バイト）
o algorithms: 0x810a (2 bytes)
o アルゴリズム：0x810a（2バイト）
o request_kid: 0x00 (1 byte)
o request_kid：0x00（1バイト）
o request_piv: 0x25 (1 byte)
o request_piv：0x25（1バイト）
o options: 0x (0 bytes)
o オプション：0x（0バイト）
o aad_array: 0x8501810a4100412540 (9 bytes)
o aad_array：0x8501810a4100412540（9バイト）
o external_aad: 0x498501810a4100412540 (10 bytes)
o external_aad：0x498501810a4100412540（10バイト）
o AAD: 0x8368456e63727970743040498501810a4100412540 (21 bytes)
o AAD：0x8368456e63727970743040498501810a4100412540（21バイト）
Note that the AAD consists of a fixed string of 11 bytes concatenated with the external_aad.
AADは、external_aadと連結された11バイトの固定文字列で構成されることに注意してください。
The Concise Binary Object Representation (CBOR) [RFC7049] combines very small message sizes with extensibility. The CBOR Object Signing and Encryption (COSE) [RFC8152] uses CBOR to create compact encoding of signed and encrypted data. However, COSE is constructed to support a large number of different stateless use cases and is not fully optimized for use as a stateful security protocol, leading to a larger than necessary message expansion. In this section, we define a stateless header compression mechanism, simply removing redundant information from the COSE objects, which significantly reduces the per-packet overhead. The result of applying this mechanism to a COSE object is called the "compressed COSE object".
簡潔なバイナリオブジェクト表現（CBOR）[RFC7049]は、非常に小さなメッセージサイズと拡張性を兼ね備えています。 CBORオブジェクトの署名と暗号化（COSE）[RFC8152]は、CBORを使用して、署名および暗号化されたデータのコンパクトなエンコーディングを作成します。ただし、COSEは多数の異なるステートレスユースケースをサポートするように構築されており、ステートフルセキュリティプロトコルとしての使用に完全に最適化されていないため、必要以上にメッセージが拡張されます。このセクションでは、ステートレスヘッダー圧縮メカニズムを定義し、COSEオブジェクトから冗長な情報を削除するだけで、パケットごとのオーバーヘッドを大幅に削減します。このメカニズムをCOSEオブジェクトに適用した結果は、「圧縮されたCOSEオブジェクト」と呼ばれます。
The COSE_Encrypt0 object used in OSCORE is transported in the OSCORE option and in the Payload. The Payload contains the ciphertext of the COSE object. The headers of the COSE object are compactly encoded as described in the next section.
OSCOREで使用されるCOSE_Encrypt0オブジェクトは、OSCOREオプションとペイロードで転送されます。ペイロードには、COSEオブジェクトの暗号文が含まれています。 COSEオブジェクトのヘッダーは、次のセクションで説明するようにコンパクトにエンコードされます。
The value of the OSCORE option SHALL contain the OSCORE flag bits, the 'Partial IV' parameter, the 'kid context' parameter (length and value), and the 'kid' parameter as follows:
OSCOREオプションの値には、OSCOREフラグビット、「Partial IV」パラメーター、「kid context」パラメーター（長さと値）、および「kid」パラメーターが次のように含まれている必要があります。
0 1 2 3 4 5 6 7 <------------- n bytes -------------->
+-+-+-+-+-+-+-+-+--------------------------------------
|0 0 0|h|k| n | Partial IV (if any) ...
+-+-+-+-+-+-+-+-+--------------------------------------
<- 1 byte -> <----- s bytes ------>
+------------+----------------------+------------------+
| s (if any) | kid context (if any) | kid (if any) ... |
+------------+----------------------+------------------+
Figure 10: The OSCORE Option Value
図10：OSCOREオプションの値
o The first byte, containing the OSCORE flag bits, encodes the following set of bits and the length of the 'Partial IV' parameter:
o OSCOREフラグビットを含む最初のバイトは、次のビットセットと「部分IV」パラメータの長さをエンコードします。
* The three least significant bits encode the Partial IV length n. If n = 0, then the Partial IV is not present in the compressed COSE object. The values n = 6 and n = 7 are reserved.
* 最下位3ビットは、部分IVの長さnをエンコードします。 n = 0の場合、Partial IVは圧縮されたCOSEオブジェクトに存在しません。値n = 6およびn = 7は予約されています。
* The fourth least significant bit is the 'kid' flag, k. It is set to 1 if 'kid' is present in the compressed COSE object.
* 4番目の最下位ビットは「子供」フラグkです。 'kid'が圧縮されたCOSEオブジェクトに存在する場合、1に設定されます。
* The fifth least significant bit is the 'kid context' flag, h. It is set to 1 if the compressed COSE object contains a 'kid context' (see Section 5.1).
* 5番目の最下位ビットは、「子供コンテキスト」フラグhです。圧縮されたCOSEオブジェクトに「キッドコンテキスト」が含まれている場合は、1に設定されます（セクション5.1を参照）。
* The sixth-to-eighth least significant bits are reserved for future use. These bits SHALL be set to zero when not in use. According to this specification, if any of these bits are set to 1, the message is considered to be malformed and decompression fails as specified in item 2 of Section 8.2.
* 6番目から8番目の最下位ビットは、将来の使用のために予約されています。これらのビットは、使用されていないときはゼロに設定する必要があります。この仕様によれば、これらのビットのいずれかが1に設定されている場合、メッセージは不正な形式であると見なされ、8.2項の2項で指定されているように解凍に失敗します。
The flag bits are registered in the "OSCORE Flag Bits" registry specified in Section 13.7.
フラグビットは、セクション13.7で指定された「OSCOREフラグビット」レジストリに登録されます。
o The following n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0).
o 次のnバイトは、部分IVが存在する場合（n> 0）、部分IVの値をエンコードします。
o The following 1 byte encodes the length s of the 'kid context' (Section 5.1), if the 'kid context' flag is set (h = 1).
o 次の1バイトは、「キッドコンテキスト」フラグが設定されている場合（h = 1）、「キッドコンテキスト」（セクション5.1）の長さsをエンコードします。
o The following s bytes encode the 'kid context', if the 'kid context' flag is set (h = 1).
o 次のsバイトは、「子供コンテキスト」フラグが設定されている場合（h = 1）、「子供コンテキスト」をエンコードします。
o The remaining bytes encode the value of the 'kid', if the 'kid' is present (k = 1).
o 残りのバイトは、「子供」が存在する場合（k = 1）、「子供」の値をエンコードします。
Note that the 'kid' MUST be the last field of the OSCORE option value, even in the case in which reserved bits are used and additional fields are added to it.
予約ビットが使用され、追加のフィールドが追加されている場合でも、「子供」はOSCOREオプション値の最後のフィールドでなければならないことに注意してください。
The length of the OSCORE option thus depends on the presence and length of Partial IV, 'kid context', 'kid', as specified in this section, and on the presence and length of additional parameters, as defined in the future documents registering those parameters.
したがって、OSCOREオプションの長さは、このセクションで指定されているPartial IV、「kid context」、「kid」の存在と長さ、およびそれらを登録する将来のドキュメントで定義されている追加パラメーターの存在と長さに依存します。パラメーター。
The payload of the OSCORE message SHALL encode the ciphertext of the COSE object.
OSCOREメッセージのペイロードは、COSEオブジェクトの暗号文をエンコードする必要があります（SHALL）。
This section covers a list of OSCORE Header Compression examples for requests and responses. The examples assume the COSE_Encrypt0 object is set (which means the CoAP message and cryptographic material is known). Note that the full CoAP unprotected message, as well as the full security context, is not reported in the examples, but only the input necessary to the compression mechanism, i.e., the COSE_Encrypt0 object. The output is the compressed COSE object as defined in Section 6, divided into two parts, since the object is transported in two CoAP fields: the OSCORE option and payload.
このセクションでは、リクエストとレスポンスのOSCOREヘッダー圧縮の例のリストを扱います。例では、COSE_Encrypt0オブジェクトが設定されていることを前提としています（これは、CoAPメッセージと暗号化マテリアルが既知であることを意味します）。例では、完全なCoAP保護されていないメッセージと完全なセキュリティコンテキストは報告されず、圧縮メカニズムに必要な入力、つまりCOSE_Encrypt0オブジェクトのみが報告されることに注意してください。オブジェクトは2つのCoAPフィールド（OSCOREオプションとペイロード）で転送されるため、出力はセクション6で定義された圧縮COSEオブジェクトであり、2つの部分に分割されます。
1. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = 0x25, and Partial IV = 0x05
1. 暗号文= 0xaea0155667924dff8a24e4cb35b9、kid = 0x25、Partial IV = 0x05のリクエスト
Before compression (24 bytes):
圧縮前（24バイト）：
[ h'', { 4:h'25', 6:h'05' }, h'aea0155667924dff8a24e4cb35b9', ]
[h ''、{4：h'25 '、6：h'05'}、h'aea0155667924dff8a24e4cb35b9 '、]
After compression (17 bytes):
圧縮後（17バイト）：
Flag byte: 0b00001001 = 0x09 (1 byte)
フラグバイト：0b00001001 = 0x09（1バイト）
Option Value: 0x090525 (3 bytes)
オプション値：0x090525（3バイト）
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
ペイロード：0xaea0155667924dff8a24e4cb35b9（14バイト）
2. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = empty string, and Partial IV = 0x00
2. 暗号文= 0xaea0155667924dff8a24e4cb35b9、kid =空の文字列、Partial IV = 0x00のリクエスト
Before compression (23 bytes):
圧縮前（23バイト）：
[ h'', { 4:h'', 6:h'00' }, h'aea0155667924dff8a24e4cb35b9', ]
[h ''、{4：h ''、6：h'00 '}、h'aea0155667924dff8a24e4cb35b9'、]
After compression (16 bytes):
圧縮後（16バイト）：
Flag byte: 0b00001001 = 0x09 (1 byte)
フラグバイト：0b00001001 = 0x09（1バイト）
Option Value: 0x0900 (2 bytes)
オプション値：0x0900（2バイト）
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
ペイロード：0xaea0155667924dff8a24e4cb35b9（14バイト）
3. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = empty string, Partial IV = 0x05, and kid context = 0x44616c656b
3. 暗号文= 0xaea0155667924dff8a24e4cb35b9、キッド=空の文字列、部分IV = 0x05、キッドコンテキスト= 0x44616c656bのリクエスト
Before compression (30 bytes):
圧縮前（30バイト）：
[ h'', { 4:h'', 6:h'05', 10:h'44616c656b' }, h'aea0155667924dff8a24e4cb35b9', ]
[h ''、{4：h ''、6：h'05 '、10：h'44616c656b'}、h'aea0155667924dff8a24e4cb35b9 '、]
After compression (22 bytes):
圧縮後（22バイト）：
Flag byte: 0b00011001 = 0x19 (1 byte)
フラグバイト：0b00011001 = 0x19（1バイト）
Option Value: 0x19050544616c656b (8 bytes)
オプション値：0x19050544616c656b（8バイト）
Payload: 0xae a0155667924dff8a24e4cb35b9 (14 bytes)
ペイロード：0xae a0155667924dff8a24e4cb35b9（14バイト）
4. Response with ciphertext = 0xaea0155667924dff8a24e4cb35b9 and no Partial IV
4. 暗号文= 0xaea0155667924dff8a24e4cb35b9の応答、部分IVなし
Before compression (18 bytes):
圧縮前（18バイト）：
[ h'', {}, h'aea0155667924dff8a24e4cb35b9', ]
[h ''、{}、h'aea0155667924dff8a24e4cb35b9 '、]
After compression (14 bytes):
圧縮後（14バイト）：
Flag byte: 0b00000000 = 0x00 (1 byte)
フラグバイト：0b00000000 = 0x00（1バイト）
Option Value: 0x (0 bytes)
オプション値：0x（0バイト）
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
ペイロード：0xaea0155667924dff8a24e4cb35b9（14バイト）
5. Response with ciphertext = 0xaea0155667924dff8a24e4cb35b9 and Partial IV = 0x07
5. 暗号文= 0xaea0155667924dff8a24e4cb35b9および部分IV = 0x07の応答
Before compression (21 bytes):
圧縮前（21バイト）：
[ h'', { 6:h'07' }, h'aea0155667924dff8a24e4cb35b9', ]
[h ''、{6：h'07 '}、h'aea0155667924dff8a24e4cb35b9'、]
After compression (16 bytes):
圧縮後（16バイト）：
Flag byte: 0b00000001 = 0x01 (1 byte)
フラグバイト：0b00000001 = 0x01（1バイト）
Option Value: 0x0107 (2 bytes)
オプション値：0x0107（2バイト）
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
ペイロード：0xaea0155667924dff8a24e4cb35b9（14バイト）
In order to prevent response delay and mismatch attacks [CoAP-Actuators] from on-path attackers and compromised intermediaries, OSCORE binds responses to the requests by including the 'kid' and Partial IV of the request in the AAD of the response. Therefore, the server needs to store the 'kid' and Partial IV of the request until all responses have been sent.
経路上の攻撃者および侵害された中間者からの応答遅延および不一致攻撃[CoAP-Actuators]を防ぐために、OSCOREは、応答のAADに「キッド」と要求の部分IVを含めることにより、応答を要求にバインドします。したがって、すべての応答が送信されるまで、サーバーは要求の「子供」と部分IVを保存する必要があります。
An AEAD nonce MUST NOT be used more than once per AEAD key. The uniqueness of (key, nonce) pairs is shown in Appendix D.4, and in particular depends on a correct usage of Partial IVs (which encode the Sender Sequence Numbers, see Section 5). If messages are processed concurrently, the operation of reading and increasing the Sender Sequence Number MUST be atomic.
AEAD nonceは、AEADキーごとに複数回使用してはなりません。 （key、nonce）ペアの一意性は付録D.4に示されています。特に、Partial IV（送信者シーケンス番号をエンコードする、セクション5を参照）の正しい使用法に依存しています。メッセージが同時に処理される場合、送信者シーケンス番号の読み取りと増加の操作はアトミックである必要があります。
The maximum Sender Sequence Number is algorithm dependent (see Section 12) and SHALL be less than 2^40. If the Sender Sequence Number exceeds the maximum, the endpoint MUST NOT process any more messages with the given Sender Context. If necessary, the endpoint SHOULD acquire a new security context before this happens. The latter is out of scope of this document.
最大送信者シーケンス番号はアルゴリズムに依存し（セクション12を参照）、2 ^ 40未満である必要があります。送信者シーケンス番号が最大値を超える場合、エンドポイントは、指定された送信者コンテキストでこれ以上メッセージを処理してはなりません（MUST NOT）。必要に応じて、エンドポイントは、これが発生する前に新しいセキュリティコンテキストを取得する必要があります（SHOULD）。後者はこのドキュメントの範囲外です。
For requests, OSCORE provides only the guarantee that the request is not older than the security context. For applications having stronger demands on request freshness (e.g., control of actuators), OSCORE needs to be augmented with mechanisms providing freshness (for example, as specified in [CoAP-ECHO-REQ-TAG]).
リクエストの場合、OSCOREは、リクエストがセキュリティコンテキストより古くないことの保証のみを提供します。要求の鮮度（アクチュエータの制御など）に対する要求が強いアプリケーションでは、OSCOREに鮮度を提供するメカニズム（たとえば、[CoAP-ECHO-REQ-TAG]で指定されている）を追加する必要があります。
Assuming an honest server (see Appendix D), the message binding guarantees that a response is not older than its request. For responses that are not notifications (i.e., when there is a single response to a request), this gives absolute freshness. For notifications, the absolute freshness gets weaker with time, and it is RECOMMENDED that the client regularly re-register the observation. Note that the message binding does not guarantee that a misbehaving server created the response before receiving the request, i.e., it does not verify server aliveness.
正直なサーバー（付録Dを参照）を想定すると、メッセージバインディングによって、応答が要求よりも古くないことが保証されます。通知ではない応答の場合（つまり、要求に対する応答が1つしかない場合）、これにより完全な鮮度が得られます。通知の場合、時間の経過とともに絶対的な鮮度が低下します。クライアントが定期的に観測を再登録することをお勧めします。メッセージバインディングは、誤動作しているサーバーがリクエストを受信する前に応答を作成したことを保証しないことに注意してください。つまり、サーバーの生存を確認しません。
For requests and notifications, OSCORE also provides relative freshness in the sense that the received Partial IV allows a recipient to determine the relative order of requests or responses.
リクエストと通知の場合、OSCOREは、受信したPartial IVが受信者がリクエストまたはレスポンスの相対的な順序を決定できるという意味で、相対的な鮮度も提供します。
In order to protect from replay of requests, the server's Recipient Context includes a Replay Window. A server SHALL verify that the Sender Sequence Number received in the 'Partial IV' parameter of the COSE object (see Section 6.1) has not been received before. If this verification fails, the server SHALL stop processing the message, and it MAY optionally respond with a 4.01 (Unauthorized) error message. Also, the server MAY set an Outer Max-Age option with value zero to inform any intermediary that the response is not to be cached. The diagnostic payload MAY contain the string "Replay detected". The size and type of the Replay Window depends on the use case and the protocol with which the OSCORE message is transported. In case of reliable and ordered transport from endpoint to endpoint, e.g., TCP, the server MAY just store the last received Partial IV and require that newly received Partial IVs equal the last received Partial IV + 1. However, in the case of mixed reliable and unreliable transports and where messages may be lost, such a replay mechanism may be too restrictive and the default replay window may be more suitable (see Section 3.2.2).
リクエストのリプレイから保護するために、サーバーの受信者コンテキストにはリプレイウィンドウが含まれています。サーバーは、COSEオブジェクト（セクション6.1を参照）の「部分IV」パラメーターで受信した送信者シーケンス番号が以前に受信されていないことを確認する必要があります（SHALL）。この検証が失敗した場合、サーバーはメッセージの処理を停止するものとし（SHALL）、オプションで4.01（無許可）エラーメッセージで応答する場合があります。また、サーバーは、応答がキャッシュされないことを仲介者に通知するために、ゼロの値でOuter Max-Ageオプションを設定してもよい（MAY）。診断ペイロードには、文字列「Replay detected」が含まれる場合があります。再生ウィンドウのサイズとタイプは、OSCOREメッセージの転送に使用されるユースケースとプロトコルによって異なります。エンドポイントからエンドポイントへの信頼性の高い順序付けられたトランスポート（TCPなど）の場合、サーバーは最後に受信したパーシャルIVを格納し、新しく受信したパーシャルIVが最後に受信したパーシャルIV + 1と等しいことを要求できます（ただし、混合信頼性の場合）。信頼性の低いトランスポート、およびメッセージが失われる可能性がある場合、そのような再生メカニズムは制限が厳しすぎる可能性があり、デフォルトの再生ウィンドウの方が適している場合があります（セクション3.2.2を参照）。
Responses (with or without Partial IV) are protected against replay as they are bound to the request and the fact that only a single response is accepted. In this case the Partial IV is not used for replay protection of responses.
応答（パーシャルIVの有無にかかわらず）は、要求にバインドされているため、リプレイから保護され、単一の応答のみが受け入れられます。この場合、Partial IVは応答のリプレイ保護には使用されません。
The operation of validating the Partial IV and updating the replay protection MUST be atomic.
パーシャルIVを検証し、リプレイ保護を更新する操作は、アトミックである必要があります。
The following applies additionally when the Observe option is supported.
監視オプションがサポートされている場合、以下が追加で適用されます。
The Notification Number (see Section 4.1.3.5.2) is initialized to the Partial IV of the first successfully verified notification in response to the registration request. A client MUST only accept at most one Observe notification without Partial IV, and treat it as the oldest notification received. A client receiving a notification containing a Partial IV SHALL compare the Partial IV with the Notification Number associated to that Observe registration. The client MUST stop processing notifications with a Partial IV that has been previously received. Applications MAY decide that a client only processes notifications that have a greater Partial IV than the Notification Number.
通知番号（セクション4.1.3.5.2を参照）は、登録要求への応答として、最初に正常に検証された通知の部分IVに初期化されます。クライアントは、部分IVなしで最大1つの監視通知のみを受け入れ、受信した最も古い通知として扱う必要があります。部分IVを含む通知を受信するクライアントは、部分IVをそのObserve登録に関連付けられた通知番号と比較する必要があります（SHALL）。クライアントは、以前に受信されたPartial IVによる通知の処理を停止する必要があります。アプリケーションは、クライアントが通知番号よりも部分IVが大きい通知のみを処理することを決定する場合があります。
If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number, then the client SHALL overwrite the corresponding Notification Number with the received Partial IV.
応答の検証が成功し、受信した部分IVが通知番号より大きい場合、クライアントは、対応する通知番号を受信した部分IVで上書きする必要があります（SHALL）。
To prevent reuse of an AEAD nonce with the same AEAD key or the acceptance of replayed messages, an endpoint needs to handle the situation of losing rapidly changing parts of the context, such as the Sender Sequence Number and Replay Window. These are typically stored in RAM and therefore lost in the case of, e.g., an unplanned reboot. There are different alternatives to recover, for example:
同じAEADキーでAEADナンスを再利用したり、再生されたメッセージを受け入れたりしないようにするには、エンドポイントは、送信者シーケンス番号や再生ウィンドウなど、コンテキストの急速に変化する部分を失う状況に対処する必要があります。これらは通常RAMに保存されるため、たとえば、予期しない再起動の場合には失われます。回復するためのさまざまな代替手段があります。次に例を示します。
1. The endpoints can reuse an existing Security Context after updating the mutable parts of the security context (Sender Sequence Number and Replay Window). This requires that the mutable parts of the security context are available throughout the lifetime of the device or that the device can establish a fresh security context after loss of mutable security context data. Examples are given based on careful use of nonvolatile memory, see Appendix B.1.1 and the use of the Echo option, see Appendix B.1.2. If an endpoint makes use of a partial security context stored in nonvolatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages.
1. エンドポイントは、セキュリティコンテキストの可変部分（送信者シーケンス番号とリプレイウィンドウ）を更新した後、既存のセキュリティコンテキストを再利用できます。これには、セキュリティコンテキストの変更可能な部分がデバイスの存続期間を通じて利用可能であるか、またはデバイスが変更可能なセキュリティコンテキストデータの損失後に新しいセキュリティコンテキストを確立できることが必要です。例は、不揮発性メモリの注意深い使用に基づいて提供されています。付録B.1.1を参照してください。また、エコーオプションの使用は、付録B.1.2を参照してください。エンドポイントが不揮発性メモリに格納されている部分的なセキュリティコンテキストを利用する場合、以前の送信者シーケンス番号を再利用してはならず、以前に受信したメッセージを受け入れてはなりません。
2. The endpoints can reuse an existing shared Master Secret and derive new Sender and Recipient Contexts, see Appendix B.2 for an example. This typically requires a good source of randomness.
2. エンドポイントは、既存の共有マスターシークレットを再利用し、新しい送信者と受信者のコンテキストを導出できます。例については、付録B.2を参照してください。これには通常、ランダム性の優れたソースが必要です。
3. The endpoints can use a trusted third-party-assisted key establishment protocol such as [OSCORE-PROFILE]. This requires the execution of a three-party protocol and may require a good source of randomness.
3. エンドポイントは、[OSCORE-PROFILE]などの信頼できるサードパーティ支援のキー確立プロトコルを使用できます。これには、サードパーティのプロトコルを実行する必要があり、ランダム性の優れたソースが必要になる場合があります。
4. The endpoints can run a key exchange protocol providing forward secrecy resulting in a fresh Master Secret, from which an entirely new Security Context is derived. This requires a good source of randomness, and additionally, the transmission and processing of the protocol may have a non-negligible cost, e.g., in terms of power consumption.
4. エンドポイントは、完全に新しいセキュリティコンテキストがそこから導出される新鮮なマスターシークレットをもたらす転送秘密を提供する鍵交換プロトコルを実行できます。これは、ランダム性の優れたソースを必要とし、さらに、プロトコルの送信および処理は、例えば、電力消費に関して無視できないほどのコストを伴う場合がある。
The endpoints need to be configured with information about which method is used. The choice of method may depend on capabilities of the devices deployed and the solution architecture. Using a key exchange protocol is necessary for deployments that require forward secrecy.
エンドポイントには、使用する方法に関する情報を設定する必要があります。方法の選択は、展開されたデバイスの機能とソリューションアーキテクチャによって異なります。前方秘密性を必要とするデプロイメントでは、鍵交換プロトコルを使用する必要があります。
This section describes the OSCORE message processing. Additional processing for Observe or Block-wise are described in subsections.
このセクションでは、OSCOREメッセージ処理について説明します。 ObserveまたはBlock-wiseの追加処理については、サブセクションで説明します。
Note that, analogously to [RFC7252] where the Token and source/ destination pair are used to match a response with a request, both endpoints MUST keep the association (Token, {Security Context, Partial IV of the request}), in order to be able to find the Security Context and compute the AAD to protect or verify the response. The association MAY be forgotten after it has been used to successfully protect or verify the response, with the exception of Observe processing, where the association MUST be kept as long as the Observation is active.
[RFC7252]と同様に、トークンとソース/宛先のペアを使用して応答を要求と照合し、両方のエンドポイントが関連付け（トークン、{セキュリティコンテキスト、要求の部分IV}）を維持する必要があることに注意してください。セキュリティコンテキストを見つけてAADを計算し、応答を保護または検証できます。 Observationが例外であり、Observationがアクティブである限り関連付けを保持する必要があるObserve処理を除いて、関連付けは応答の保護または検証に使用された後は忘れられる場合があります。
The processing of the Sender Sequence Number follows the procedure described in Section 3 of [IV-GEN].
送信者シーケンス番号の処理は、[IV-GEN]のセクション3で説明されている手順に従います。
Given a CoAP request, the client SHALL perform the following steps to create an OSCORE request:
CoAP要求が与えられると、クライアントはOSCORE要求を作成するために次の手順を実行する必要があります（SHALL）。
1. Retrieve the Sender Context associated with the target resource.
1. ターゲットリソースに関連付けられた送信者コンテキストを取得します。
2. Compose the AAD and the plaintext, as described in Sections 5.3 and 5.4.
2. セクション5.3および5.4で説明されているように、AADとプレーンテキストを作成します。
3. Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV as described in Section 5.2.
3. パーシャルIV（ネットワークバイト順の送信者シーケンス番号）をエンコードし、送信者シーケンス番号を1つ増やします。セクション5.2の説明に従って、Sender ID、Common IV、Partial IVからAEAD nonceを計算します。
4. Encrypt the COSE object using the Sender Key. Compress the COSE object as specified in Section 6.
4. 送信者キーを使用してCOSEオブジェクトを暗号化します。セクション6の指定に従って、COSEオブジェクトを圧縮します。
5. Format the OSCORE message according to Section 4. The OSCORE option is added (see Section 4.1.2).
5. セクション4に従ってOSCOREメッセージをフォーマットします。OSCOREオプションが追加されます（セクション4.1.2を参照）。
A server receiving a request containing the OSCORE option SHALL perform the following steps:
OSCOREオプションを含む要求を受信するサーバーは、次の手順を実行する必要があります。
1. Discard Code and all Class E options (marked in Figure 5 with 'x' in column E) present in the received message. For example, an If-Match Outer option is discarded, but an Uri-Host Outer option is not discarded.
1. 受信メッセージに存在するコードを破棄し、すべてのクラスEオプション（図5で列Eに「x」が付いている）を表示します。たとえば、If-Match Outerオプションは破棄されますが、Uri-Host Outerオプションは破棄されません。
2. Decompress the COSE object (Section 6) and retrieve the Recipient Context associated with the Recipient ID in the 'kid' parameter, additionally using the 'kid context', if present. Note that the Recipient Context MAY be retrieved by deriving a new security context, e.g. as described in Appendix B.2. If either the decompression or the COSE message fails to decode, or the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, then the server SHALL stop processing the request.
2. COSEオブジェクトを解凍し（セクション6）、「kid」パラメーター内の受信者IDに関連付けられた受信者コンテキストを取得し、さらに「kidコンテキスト」が存在する場合はそれを使用します。受信者コンテキストは、新しいセキュリティコンテキストを取得することで取得できます。付録B.2で説明されています。解凍またはCOSEメッセージのいずれかがデコードに失敗した場合、またはサーバーが受信した 'kid'パラメーターに対応する受信者IDの受信者コンテキストを取得できない場合、サーバーは要求の処理を停止する必要があります（SHALL）。
* If either the decompression or the COSE message fails to decode, the server MAY respond with a 4.02 (Bad Option) error message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload MAY contain the string "Failed to decode COSE".
* 解凍またはCOSEメッセージのいずれかがデコードに失敗した場合、サーバーは4.02（不良オプション）エラーメッセージで応答する場合があります。サーバーは、ゼロの値でOuter Max-Ageオプションを設定してもよい（MAY）。診断ペイロードは、文字列「COSEをデコードできませんでした」を含む場合があります。
* If the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, the server MAY respond with a 4.01 (Unauthorized) error message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload MAY contain the string "Security context not found".
* サーバーが受信した 'kid'パラメーターに対応する受信者IDの受信者コンテキストの取得に失敗した場合、サーバーは4.01（無許可）エラーメッセージで応答できます（MAY）。サーバーは、ゼロの値でOuter Max-Ageオプションを設定してもよい（MAY）。診断ペイロードには、文字列「セキュリティコンテキストが見つかりません」が含まれる場合があります。
3. Verify that the Partial IV has not been received before using the Replay Window, as described in Section 7.4.
3. セクション7.4で説明されているように、リプレイウィンドウを使用する前に、パーシャルIVが受信されていないことを確認してください。
4. Compose the AAD, as described in Section 5.4.
4. セクション5.4の説明に従って、AADを作成します。
5. Compute the AEAD nonce from the Recipient ID, Common IV, and the Partial IV, received in the COSE object.
5. COSEオブジェクトで受信した受信者ID、Common IV、およびPartial IVからAEAD nonceを計算します。
6. Decrypt the COSE object using the Recipient Key, as per Section 5.3 of [RFC8152]. (The decrypt operation includes the verification of the integrity.)
6. [RFC8152]のセクション5.3に従って、受信者キーを使用してCOSEオブジェクトを復号化します。 （復号化操作には整合性の検証が含まれます。）
* If decryption fails, the server MUST stop processing the request and MAY respond with a 4.00 (Bad Request) error message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload MAY contain the string "Decryption failed".
* 復号化が失敗した場合、サーバーはリクエストの処理を停止する必要があり、4.00（Bad Request）エラーメッセージで応答する場合があります。サーバーは、ゼロの値でOuter Max-Ageオプションを設定してもよい（MAY）。診断ペイロードには、文字列「復号化に失敗しました」が含まれる場合があります。
* If decryption succeeds, update the Replay Window, as described in Section 7.
* 復号化が成功した場合は、セクション7の説明に従って、再生ウィンドウを更新します。
7. Add decrypted Code, options, and payload to the decrypted request. The OSCORE option is removed.
7. 復号化されたコード、オプション、ペイロードを復号化されたリクエストに追加します。 OSCOREオプションは削除されました。
8. The decrypted CoAP request is processed according to [RFC7252].
8. 復号化されたCoAP要求は、[RFC7252]に従って処理されます。
If Block-wise is supported, insert the following step before any other:
ブロックワイズがサポートされている場合は、次のステップを他のステップの前に挿入します。
A. If Block-wise is present in the request, then process the Outer Block options according to [RFC7959], until all blocks of the request have been received (see Section 4.1.3.4).
A.リクエストにブロックワイズが存在する場合、リクエストのすべてのブロックが受信されるまで（セクション4.1.3.4を参照）、[RFC7959]に従ってアウターブロックオプションを処理します。
If a CoAP response is generated in response to an OSCORE request, the server SHALL perform the following steps to create an OSCORE response. Note that CoAP error responses derived from CoAP processing (step 8 in Section 8.2) are protected, as well as successful CoAP responses, while the OSCORE errors (steps 2, 3, and 6 in Section 8.2) do not follow the processing below but are sent as simple CoAP responses, without OSCORE processing.
OSCORE要求への応答としてCoAP応答が生成される場合、サーバーはOSCORE応答を作成するために次の手順を実行する必要があります（SHALL）。 CoAP処理から派生したCoAPエラーレスポンス（セクション8.2のステップ8）と成功したCoAPレスポンスが保護されている一方、OSCOREエラー（セクション8.2のステップ2、3、および6）は以下の処理に従っていないが、 OSCORE処理なしで、単純なCoAP応答として送信されます。
1. Retrieve the Sender Context in the Security Context associated with the Token.
1. トークンに関連付けられたセキュリティコンテキストで送信者コンテキストを取得します。
2. Compose the AAD and the plaintext, as described in Sections 5.3 and 5.4.
2. セクション5.3および5.4で説明されているように、AADとプレーンテキストを作成します。
3. Compute the AEAD nonce as described in Section 5.2:
3. セクション5.2の説明に従って、AEADナンスを計算します。
* Either use the AEAD nonce from the request, or
* リクエストからAEAD nonceを使用するか、
* Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV.
* パーシャルIV（ネットワークバイト順の送信者シーケンス番号）をエンコードし、送信者シーケンス番号を1つ増やします。 Sender ID、Common IV、Partial IVからAEAD nonceを計算します。
4. Encrypt the COSE object using the Sender Key. Compress the COSE object as specified in Section 6. If the AEAD nonce was constructed from a new Partial IV, this Partial IV MUST be included in the message. If the AEAD nonce from the request was used, the Partial IV MUST NOT be included in the message.
4. 送信者キーを使用してCOSEオブジェクトを暗号化します。セクション6で指定されているようにCOSEオブジェクトを圧縮します。AEADnonceが新しいPartial IVから作成された場合、このPartial IVをメッセージに含める必要があります。リクエストからのAEAD nonceが使用された場合、Partial IVをメッセージに含めてはなりません（MUST NOT）。
5. Format the OSCORE message according to Section 4. The OSCORE option is added (see Section 4.1.2).
5. セクション4に従ってOSCOREメッセージをフォーマットします。OSCOREオプションが追加されます（セクション4.1.2を参照）。
If Observe is supported, insert the following step between steps 2 and 3 of Section 8.3:
監視がサポートされている場合は、セクション8.3のステップ2と3の間に次のステップを挿入します。
A. If the response is an Observe notification:
A.応答が監視通知の場合：
o If the response is the first notification:
o 応答が最初の通知の場合：
* compute the AEAD nonce as described in Section 5.2:
* セクション5.2の説明に従って、AEADナンスを計算します。
+ Either use the AEAD nonce from the request, or
+ リクエストからAEAD nonceを使用するか、
+ Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV.
+ パーシャルIV（ネットワークバイト順の送信者シーケンス番号）をエンコードし、送信者シーケンス番号を1つ増やします。 Sender ID、Common IV、Partial IVからAEAD nonceを計算します。
Then, go to 4.
次に、4に進みます。
o If the response is not the first notification:
o 応答が最初の通知ではない場合：
* encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV, then go to 4.
* パーシャルIV（ネットワークバイト順の送信者シーケンス番号）をエンコードし、送信者シーケンス番号を1つ増やします。 Sender ID、Common IV、Partial IVからAEAD nonceを計算してから、4に進みます。
A client receiving a response containing the OSCORE option SHALL perform the following steps:
OSCOREオプションを含む応答を受信するクライアントは、次の手順を実行する必要があります。
1. Discard Code and all Class E options (marked in Figure 5 with 'x' in column E) present in the received message. For example, ETag Outer option is discarded, as well as Max-Age Outer option.
1. 受信メッセージに存在するコードを破棄し、すべてのクラスEオプション（図5で列Eに「x」が付いている）を表示します。たとえば、ETag OuterオプションとMax-Age Outerオプションは破棄されます。
2. Retrieve the Recipient Context in the Security Context associated with the Token. Decompress the COSE object (Section 6). If either the decompression or the COSE message fails to decode, then go to 8.
2. トークンに関連付けられたセキュリティコンテキストで受信者コンテキストを取得します。 COSEオブジェクトを解凍します（セクション6）。解凍またはCOSEメッセージのいずれかがデコードに失敗した場合は、8に進みます。
3. Compose the AAD, as described in Section 5.4.
3. セクション5.4の説明に従って、AADを作成します。
4. Compute the AEAD nonce
4. AEADナンスを計算する
* If the Partial IV is not present in the response, the AEAD nonce from the request is used.
* Partial IVが応答に存在しない場合、要求からのAEAD nonceが使用されます。
* If the Partial IV is present in the response, compute the AEAD nonce from the Recipient ID, Common IV, and the Partial IV, received in the COSE object.
* 応答に部分IVが存在する場合、COSEオブジェクトで受信した受信者ID、共通IV、および部分IVからAEADナンスを計算します。
5. Decrypt the COSE object using the Recipient Key, as per Section 5.3 of [RFC8152]. (The decrypt operation includes the verification of the integrity.) If decryption fails, then go to 8.
5. [RFC8152]のセクション5.3に従って、受信者キーを使用してCOSEオブジェクトを復号化します。 （復号化操作には整合性の検証が含まれます。）復号化が失敗した場合は、8に進みます。
6. Add decrypted Code, options and payload to the decrypted request. The OSCORE option is removed.
6. 解読されたコード、オプション、ペイロードを解読されたリクエストに追加します。 OSCOREオプションは削除されました。
7. The decrypted CoAP response is processed according to [RFC7252].
7. 復号化されたCoAP応答は、[RFC7252]に従って処理されます。
8. In case any of the previous erroneous conditions apply: the client SHALL stop processing the response.
8. 以前の誤った条件のいずれかが当てはまる場合：クライアントは応答の処理を停止するものとします（SHALL）。
If Block-wise is supported, insert the following step before any other:
ブロックワイズがサポートされている場合は、次のステップを他のステップの前に挿入します。
A. If Block-wise is present in the response, then process the Outer Block options according to [RFC7959], until all blocks of the response have been received (see Section 4.1.3.4).
A.ブロックワイズが応答に存在する場合、応答のすべてのブロックが受信されるまで（セクション4.1.3.4を参照）、[RFC7959]に従って外部ブロックオプションを処理します。
If Observe is supported:
Observeがサポートされている場合：
Insert the following step between step 5 and step 6:
手順5と手順6の間に次の手順を挿入します。
A. If the request was an Observe registration, then:
A.要求がObserve登録の場合、次のようになります。
o If the Partial IV is not present in the response, and the Inner Observe option is present, and the AEAD nonce from the request was already used once, then go to 8.
o Partial IVが応答に存在せず、Inner Observeオプションが存在し、要求からのAEAD nonceがすでに1回使用されている場合は、8に進みます。
o If the Partial IV is present in the response and the Inner Observe option is present, then follow the processing described in Section 4.1.3.5.2 and Section 7.4.1, then:
o Partial IVが応答に存在し、Inner Observeオプションが存在する場合は、セクション4.1.3.5.2およびセクション7.4.1で説明されている処理に従います。
* initialize the Notification Number (if first successfully verified notification), or
* 通知番号を初期化する（最初に正常に検証された通知の場合）、または
* overwrite the Notification Number (if the received Partial IV was greater than the Notification Number).
* 通知番号を上書きします（受け取ったPartial IVが通知番号より大きい場合）。
Replace step 8 of Section 8.4 with:
セクション8.4のステップ8を以下で置き換えます。
B. In case any of the previous erroneous conditions apply: the client SHALL stop processing the response. An error condition occurring while processing a response to an observation request does not cancel the observation. A client MUST NOT react to failure by re-registering the observation immediately.
B.上記のエラー条件のいずれかが当てはまる場合：クライアントは応答の処理を停止する必要があります（SHALL）。監視リクエストへの応答の処理中に発生したエラー条件は、監視をキャンセルしません。クライアントは、オブザベーションをすぐに再登録して、失敗に反応してはなりません（MUST NOT）。
The use of OSCORE MAY be indicated by a target "osc" attribute in a web link [RFC8288] to a resource, e.g., using a link-format document [RFC6690] if the resource is accessible over CoAP.
OSCOREの使用は、リソースへのWebリンク[RFC8288]のターゲット「osc」属性によって示される場合があります。たとえば、CoAPを介してリソースにアクセスできる場合は、リンク形式のドキュメント[RFC6690]を使用します。
The "osc" attribute is a hint indicating that the destination of that link is only accessible using OSCORE, and unprotected access to it is not supported. Note that this is simply a hint, it does not include any security context material or any other information required to run OSCORE.
「osc」属性は、そのリンクの宛先がOSCOREを使用してのみアクセス可能であり、保護されていないアクセスはサポートされていないことを示すヒントです。これは単なるヒントであり、OSCOREの実行に必要なセキュリティコンテキスト資料やその他の情報は含まれていません。
A value MUST NOT be given for the "osc" attribute; any present value MUST be ignored by parsers. The "osc" attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.
「osc」属性に値を指定してはなりません。現在の値はパーサーによって無視される必要があります。 「osc」属性は、特定のリンク値に複数回出現してはなりません。最初の後ろの出現はパーサーによって無視されなければなりません。
The example in Figure 11 shows a use of the "osc" attribute: the client does resource discovery on a server and gets back a list of resources, one of which includes the "osc" attribute indicating that the resource is protected with OSCORE. The link-format notation (see Section 5 of [RFC6690]) is used.
図11の例は、「osc」属性の使用方法を示しています。クライアントはサーバー上でリソースディスカバリを実行し、リソースのリストを取得します。そのうちの1つには、リソースがOSCOREで保護されていることを示す「osc」属性が含まれています。リンク形式の表記法（[RFC6690]のセクション5を参照）が使用されます。
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors/temp>;osc,
</sensors/light>;if="sensor"
Figure 11: The Web Link
図11：Webリンク
CoAP is designed for proxy operations (see Section 5.7 of [RFC7252]).
CoAPはプロキシ操作用に設計されています（[RFC7252]のセクション5.7を参照）。
OSCORE is designed to work with OSCORE-unaware CoAP proxies. Security requirements for forwarding are listed in Section 2.2.1 of [CoAP-E2E-Sec]. Proxy processing of the (Outer) Proxy-Uri option works as defined in [RFC7252]. Proxy processing of the (Outer) Block options works as defined in [RFC7959].
OSCOREは、OSCORE非対応のCoAPプロキシと連携するように設計されています。転送のセキュリティ要件は、[CoAP-E2E-Sec]のセクション2.2.1にリストされています。 （外部）Proxy-Uriオプションのプロキシ処理は、[RFC7252]で定義されているとおりに機能します。 （外部）ブロックオプションのプロキシ処理は、[RFC7959]で定義されているとおりに機能します。
However, not all CoAP proxy operations are useful:
ただし、すべてのCoAPプロキシ操作が役立つわけではありません。
o Since a CoAP response is only applicable to the original CoAP request, caching is in general not useful. In support of existing proxies, OSCORE uses the Outer Max-Age option, see Section 4.1.3.1.
o CoAP応答は元のCoAP要求にのみ適用できるため、一般的にキャッシングは役に立ちません。既存のプロキシをサポートするために、OSCOREはOuter Max-Ageオプションを使用します。セクション4.1.3.1を参照してください。
o Proxy processing of the (Outer) Observe option as defined in [RFC7641] is specified in Section 4.1.3.5.
o [RFC7641]で定義されている（外部）監視オプションのプロキシ処理は、セクション4.1.3.5で指定されています。
Optionally, a CoAP proxy MAY detect OSCORE and act accordingly. An OSCORE-aware CoAP proxy:
オプションで、CoAPプロキシはOSCOREを検出し、それに応じて動作する場合があります。 OSCORE対応のCoAPプロキシ：
o SHALL bypass caching for the request if the OSCORE option is present.
o OSCOREオプションが存在する場合、リクエストのキャッシュをバイパスする必要があります。
o SHOULD avoid caching responses to requests with an OSCORE option.
o OSCOREオプションを使用して、リクエストへの応答をキャッシュしないでください。
In the case of Observe (see Section 4.1.3.5), the OSCORE-aware CoAP proxy:
Observeの場合（セクション4.1.3.5を参照）、OSCORE対応のCoAPプロキシ：
o SHALL NOT initiate an Observe registration.
o オブザーブ登録を開始しないでください。
o MAY verify the order of notifications using Partial IV rather than the Observe option.
o 監視オプションではなく部分IVを使用して、通知の順序を確認できます。
The CoAP request/response model may be mapped to HTTP and vice versa as described in Section 10 of [RFC7252]. The HTTP-CoAP mapping is further detailed in [RFC8075]. This section defines the components needed to map and transport OSCORE messages over HTTP hops. By mapping between HTTP and CoAP and by using cross-protocol proxies, OSCORE may be used end-to-end between, e.g., an HTTP client and a CoAP server. Examples are provided in Sections 11.5 and 11.6.
[RFC7252]のセクション10で説明されているように、CoAPリクエスト/レスポンスモデルはHTTPにマッピングでき、その逆も可能です。 HTTP-CoAPマッピングは、[RFC8075]でさらに詳しく説明されています。このセクションでは、HTTPホップを介してOSCOREメッセージをマップおよび転送するために必要なコンポーネントを定義します。 HTTPとCoAP間のマッピングおよびクロスプロトコルプロキシの使用により、OSCOREは、たとえばHTTPクライアントとCoAPサーバーの間でエンドツーエンドで使用できます。例は、セクション11.5および11.6に記載されています。
The HTTP OSCORE header field (see Section 13.4) is used for carrying the content of the CoAP OSCORE option when transporting OSCORE messages over HTTP hops.
HTTP OSCOREヘッダーフィールド（セクション13.4を参照）は、HTTPホップを介してOSCOREメッセージを転送するときに、CoAP OSCOREオプションのコンテンツを運ぶために使用されます。
The HTTP OSCORE header field is only used in POST requests and responses with HTTP Status Code 200 (OK). When used, the HTTP header field Content-Type is set to 'application/oscore' (see Section 13.5) indicating that the HTTP body of this message contains the OSCORE payload (see Section 6.2). No additional semantics are provided by other message fields.
HTTP OSCOREヘッダーフィールドは、HTTPステータスコード200（OK）のPOST要求および応答でのみ使用されます。使用すると、HTTPヘッダーフィールドのContent-Typeは 'application / oscore'（セクション13.5を参照）に設定され、このメッセージのHTTP本文にOSCOREペイロード（セクション6.2を参照）が含まれることを示します。他のメッセージフィールドによって追加のセマンティクスが提供されることはありません。
Using the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], including the following core ABNF syntax rules defined by that specification: ALPHA (letters) and DIGIT (decimal digits), the HTTP OSCORE header field value is as follows.
[RFC5234]の拡張バッカスナウアフォーム（ABNF）表記を使用し、その仕様で定義されている次のコアABNF構文規則：ALPHA（文字）とDIGIT（10進数字）を使用すると、HTTP OSCOREヘッダーフィールド値は次のようになります。
base64url-char = ALPHA / DIGIT / "-" / "_"
OSCORE = 2*base64url-char
OSCORE = 2 * base64url-char
The HTTP OSCORE header field is not appropriate to list in the Connection header field (see Section 6.1 of [RFC7230]) since it is not hop-by-hop. OSCORE messages are generally not useful when served from cache (i.e., they will generally be marked Cache-Control: no-cache) and so interaction with Vary is not relevant (Section 7.1.4 of [RFC7231]). Since the HTTP OSCORE header field is critical for message processing, moving it from headers to trailers renders the message unusable in case trailers are ignored (see Section 4.1 of [RFC7230]).
HTTP OSCOREヘッダーフィールドはホップバイホップではないため、Connectionヘッダーフィールドにリストするのは適切ではありません（[RFC7230]のセクション6.1を参照）。 OSCOREメッセージは、キャッシュから提供される場合（つまり、通常はCache-Control：no-cacheとマークされます）には役に立たないため、Varyとの相互作用は関係ありません（[RFC7231]のセクション7.1.4）。 HTTP OSCOREヘッダーフィールドはメッセージ処理にとって重要であるため、ヘッダーからトレーラーに移動すると、トレーラーが無視された場合にメッセージが使用できなくなります（[RFC7230]のセクション4.1を参照）。
In general, intermediaries are not allowed to insert, delete, or modify the OSCORE header. In general, changes to the HTTP OSCORE header field will violate the integrity of the OSCORE message resulting in an error. For the same reason the HTTP OSCORE header field is generally not preserved across redirects.
一般に、仲介者はOSCOREヘッダーを挿入、削除、または変更することはできません。一般に、HTTP OSCOREヘッダーフィールドを変更すると、OSCOREメッセージの整合性に違反してエラーが発生します。同じ理由で、HTTP OSCOREヘッダーフィールドは通常、リダイレクト間で保持されません。
Since redirects are not defined in the mappings between HTTP and CoAP ([RFC8075] [RFC7252]), a number of conditions need to be fulfilled for redirects to work. For CoAP-client-to-HTTP-server redirects, such conditions include:
リダイレクトはHTTPとCoAPの間のマッピング（[RFC8075] [RFC7252]）で定義されていないため、リダイレクトが機能するには、いくつかの条件を満たす必要があります。 CoAPクライアントからHTTPサーバーへのリダイレクトの場合、そのような条件は次のとおりです。
o the CoAP-to-HTTP proxy follows the redirect, instead of the CoAP client as in the HTTP case.
o CoAP-to-HTTPプロキシは、HTTPの場合のようにCoAPクライアントではなく、リダイレクトに従います。
o the CoAP-to-HTTP proxy copies the HTTP OSCORE header field and body to the new request.
o CoAP-to-HTTPプロキシは、HTTP OSCOREヘッダーフィールドと本文を新しいリクエストにコピーします。
o the target of the redirect has the necessary OSCORE security context required to decrypt and verify the message.
o リダイレクトのターゲットには、メッセージの復号化と検証に必要なOSCOREセキュリティコンテキストがあります。
Since OSCORE requires the HTTP body to be preserved across redirects, the HTTP server is RECOMMENDED to reply with 307 (Temporary Redirect) or 308 (Permanent Redirect) instead of 301 (Moved Permanently) or 302 (Found).
OSCOREではリダイレクト全体でHTTP本文を保持する必要があるため、HTTPサーバーは、301（永続的に移動）または302（検出）ではなく、307（一時的なリダイレクト）または308（永続的なリダイレクト）で応答することをお勧めします。
For the case of HTTP-client-to-CoAP-server redirects, although redirect is not defined for CoAP servers [RFC7252], an HTTP client receiving a redirect should generate a new OSCORE request for the server it was redirected to.
HTTPクライアントからCoAPサーバーへのリダイレクトの場合、リダイレクトはCoAPサーバー[RFC7252]に対して定義されていませんが、リダイレクトを受信するHTTPクライアントは、リダイレクト先のサーバーに対して新しいOSCORE要求を生成する必要があります。
Section 10.1 of [RFC7252] describes the fundamentals of the CoAP-to-HTTP cross-protocol mapping process. The additional rules for OSCORE messages are as follows:
[RFC7252]のセクション10.1では、CoAPからHTTPへのクロスプロトコルマッピングプロセスの基本について説明しています。 OSCOREメッセージの追加ルールは次のとおりです。
o The HTTP OSCORE header field value is set to:
o HTTP OSCOREヘッダーフィールドの値は次のように設定されます。
* AA if the CoAP OSCORE option is empty; otherwise,
* CoAP OSCOREオプションが空の場合はAA。さもないと、
* the value of the CoAP OSCORE option (Section 6.1) in base64url (Section 5 of [RFC4648]) encoding without padding. Implementation notes for this encoding are given in Appendix C of [RFC7515].
* パディングなしのbase64url（[RFC4648]のセクション5）エンコーディングのCoAP OSCOREオプション（セクション6.1）の値このエンコードの実装メモは、[RFC7515]の付録Cに記載されています。
o The HTTP Content-Type is set to 'application/oscore' (see Section 13.5), independent of CoAP Content-Format.
o HTTP Content-Typeは、CoAP Content-Formatとは関係なく、「application / oscore」（セクション13.5を参照）に設定されます。
Section 10.2 of [RFC7252] and [RFC8075] specify the behavior of an HTTP-to-CoAP proxy. The additional rules for HTTP messages with the OSCORE header field are as follows.
[RFC7252]のセクション10.2および[RFC8075]は、HTTP-to-CoAPプロキシの動作を指定しています。 OSCOREヘッダーフィールドを持つHTTPメッセージの追加ルールは次のとおりです。
o The CoAP OSCORE option is set as follows:
o CoAP OSCOREオプションは次のように設定されています。
* empty if the value of the HTTP OSCORE header field is a single zero byte (0x00) represented by AA; otherwise,
* HTTP OSCOREヘッダーフィールドの値がAAで表される単一のゼロバイト（0x00）の場合は空。さもないと、
* the value of the HTTP OSCORE header field decoded from base64url (Section 5 of [RFC4648]) without padding. Implementation notes for this encoding are given in Appendix C of [RFC7515].
* パディングなしでbase64url（[RFC4648]のセクション5）からデコードされたHTTP OSCOREヘッダーフィールドの値このエンコードの実装メモは、[RFC7515]の付録Cに記載されています。
o The CoAP Content-Format option is omitted, the content format for OSCORE (Section 13.6) MUST NOT be used.
o CoAP Content-Formatオプションは省略され、OSCORE（セクション13.6）のコンテンツ形式は使用してはなりません（MUST NOT）。
Restricted to subsets of HTTP and CoAP supporting a bijective mapping, OSCORE can be originated or terminated in HTTP endpoints.
全単射マッピングをサポートするHTTPおよびCoAPのサブセットに制限されているOSCOREは、HTTPエンドポイントで開始または終了できます。
The sending HTTP endpoint uses [RFC8075] to translate the HTTP message into a CoAP message. The CoAP message is then processed with OSCORE as defined in this document. The OSCORE message is then mapped to HTTP as described in Section 11.2 and sent in compliance with the rules in Section 11.1.
送信HTTPエンドポイントは[RFC8075]を使用して、HTTPメッセージをCoAPメッセージに変換します。次に、CoAPメッセージは、このドキュメントで定義されているOSCOREで処理されます。 OSCOREメッセージは、セクション11.2で説明されているようにHTTPにマップされ、セクション11.1のルールに従って送信されます。
The receiving HTTP endpoint maps the HTTP message to a CoAP message using [RFC8075] and Section 11.3. The resulting OSCORE message is processed as defined in this document. If successful, the plaintext CoAP message is translated to HTTP for normal processing in the endpoint.
受信HTTPエンドポイントは、[RFC8075]とセクション11.3を使用して、HTTPメッセージをCoAPメッセージにマップします。結果のOSCOREメッセージは、このドキュメントの定義に従って処理されます。成功した場合、プレーンテキストのCoAPメッセージは、エンドポイントでの通常の処理のためにHTTPに変換されます。
This section gives an example of what a request and a response between an HTTP client and a CoAP server could look like. The example is not a test vector but intended as an illustration of how the message fields are translated in the different steps.
このセクションでは、HTTPクライアントとCoAPサーバー間の要求と応答の例を示します。この例はテストベクタではありませんが、メッセージフィールドがさまざまなステップでどのように変換されるかを示すためのものです。
Mapping and notation here is based on "Simple Form" (Section 5.4.1 of [RFC8075]).
ここでのマッピングと表記は、「シンプルなフォーム」に基づいています（[RFC8075]のセクション5.4.1）。
[HTTP request -- Before client object security processing]
[HTTPリクエスト-クライアントオブジェクトセキュリティ処理の前]
GET http://proxy.url/hc/?target_uri=coap://server.url/orders
HTTP/1.1
[HTTP request -- HTTP Client to Proxy]
[HTTPリクエスト-HTTPクライアントからプロキシへ]
POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1
Content-Type: application/oscore
OSCORE: CSU
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[CoAP request -- Proxy to CoAP Server]
[CoAPリクエスト-CoAPサーバーへのプロキシ]
POST coap://server.url/
OSCORE: 09 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[CoAP request -- After server object security processing]
[CoAPリクエスト-サーバーオブジェクトセキュリティ処理後]
GET coap://server.url/orders
[CoAP response -- Before server object security processing]
[CoAP応答-サーバーオブジェクトセキュリティ処理の前]
2.05 Content Content-Format: 0 Payload: Exterminate! Exterminate!
2.05 コンテンツコンテンツ形式：0ペイロード：根絶！絶滅させる！
[CoAP response -- CoAP Server to Proxy]
[CoAP応答-CoAPサーバーからプロキシへ]
2.04 Changed OSCORE: [empty] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
2.04 変更されたOSCORE：[空]ペイロード：00 31 d1 fc f6 70 fb 0c 1d d5 ... [バイナリ]
[HTTP response -- Proxy to HTTP Client]
[HTTP応答-HTTPクライアントへのプロキシ]
HTTP/1.1 200 OK
Content-Type: application/oscore
OSCORE: AA
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[HTTP response -- After client object security processing]
[HTTPレスポンス-クライアントオブジェクトのセキュリティ処理後]
HTTP/1.1 200 OK
Content-Type: text/plain
Body: Exterminate! Exterminate!
Note that the HTTP Status Code 200 (OK) in the next-to-last message is the mapping of CoAP Code 2.04 (Changed), whereas the HTTP Status Code 200 (OK) in the last message is the mapping of the CoAP Code 2.05 (Content), which was encrypted within the compressed COSE object carried in the Body of the HTTP response.
最後から2番目のメッセージのHTTPステータスコード200（OK）はCoAPコード2.04（変更）のマッピングですが、最後のメッセージのHTTPステータスコード200（OK）はCoAPコード2.05のマッピングです。 （コンテンツ）、HTTP応答の本文に含まれる圧縮されたCOSEオブジェクト内で暗号化されています。
This section gives an example of what a request and a response between a CoAP client and an HTTP server could look like. The example is not a test vector but intended as an illustration of how the message fields are translated in the different steps.
このセクションでは、CoAPクライアントとHTTPサーバー間の要求と応答の例を示します。この例はテストベクタではありませんが、メッセージフィールドがさまざまなステップでどのように変換されるかを示すためのものです。
[CoAP request -- Before client object security processing]
[CoAPリクエスト-クライアントオブジェクトセキュリティ処理の前]
GET coap://proxy.url/
Proxy-Uri=http://server.url/orders
[CoAP request -- CoAP Client to Proxy]
[CoAPリクエスト-CoAPクライアントからプロキシへ]
POST coap://proxy.url/
Proxy-Uri=http://server.url/
OSCORE: 09 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[HTTP request -- Proxy to HTTP Server]
[HTTPリクエスト-HTTPサーバーへのプロキシ]
POST http://server.url/ HTTP/1.1
Content-Type: application/oscore
OSCORE: CSU
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[HTTP request -- After server object security processing]
[HTTPリクエスト-サーバーオブジェクトセキュリティ処理後]
GET http://server.url/orders HTTP/1.1
[HTTP response -- Before server object security processing]
[HTTPレスポンス-サーバーオブジェクトセキュリティ処理の前]
HTTP/1.1 200 OK
Content-Type: text/plain
Body: Exterminate! Exterminate!
[HTTP response -- HTTP Server to Proxy]
[HTTP応答-HTTPサーバーからプロキシへ]
HTTP/1.1 200 OK
Content-Type: application/oscore
OSCORE: AA
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[CoAP response -- Proxy to CoAP Client]
[CoAP応答-CoAPクライアントへのプロキシ]
2.04 Changed OSCORE: [empty] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
2.04 変更されたOSCORE：[空]ペイロード：00 31 d1 fc f6 70 fb 0c 1d d5 ... [バイナリ]
[CoAP response -- After client object security processing]
[CoAP応答-クライアントオブジェクトセキュリティ処理後]
2.05 Content Content-Format: 0 Payload: Exterminate! Exterminate!
2.05 コンテンツコンテンツ形式：0ペイロード：根絶！絶滅させる！
Note that the HTTP Code 2.04 (Changed) in the next-to-last message is the mapping of HTTP Status Code 200 (OK), whereas the CoAP Code 2.05 (Content) in the last message is the value that was encrypted within the compressed COSE object carried in the Body of the HTTP response.
最後から2番目のメッセージのHTTPコード2.04（変更済み）はHTTPステータスコード200（OK）のマッピングですが、最後のメッセージのCoAPコード2.05（コンテンツ）は圧縮内で暗号化された値です。 HTTP応答の本文に含まれるCOSEオブジェクト。
An overview of the security properties is given in Appendix D.
セキュリティプロパティの概要を付録Dに示します。
In scenarios with intermediary nodes such as proxies or gateways, transport layer security such as (D)TLS only protects data hop-by-hop. As a consequence, the intermediary nodes can read and modify any information. The trust model where all intermediary nodes are considered trustworthy is problematic, not only from a privacy perspective, but also from a security perspective, as the intermediaries are free to delete resources on sensors and falsify commands to actuators (such as "unlock door", "start fire alarm", "raise bridge"). Even in the rare cases where all the owners of the intermediary nodes are fully trusted, attacks and data breaches make such an architecture brittle.
プロキシやゲートウェイなどの中間ノードを使用するシナリオでは、（D）TLSなどのトランスポート層セキュリティはデータをホップバイホップでのみ保護します。その結果、中間ノードは任意の情報を読み取って変更できます。すべての中間ノードが信頼できると見なされる信頼モデルは、プライバシーの観点からだけでなく、セキュリティの観点からも問題があります。これは、仲介者がセンサー上のリソースを自由に削除し、アクチュエーターへのコマンドを偽造できるためです（「ドアのロック解除」など）。 「火災警報を開始する」、「橋を上げる」）。中間ノードのすべての所有者が完全に信頼されているまれなケースでさえ、攻撃とデータ侵害がそのようなアーキテクチャを脆弱にします。
(D)TLS protects hop-by-hop the entire message. OSCORE protects end-to-end all information that is not required for proxy operations (see Section 4). (D)TLS and OSCORE can be combined, thereby enabling end-to-end security of the message payload, in combination with hop-by-hop protection of the entire message, during transport between endpoint and intermediary node. In particular, when OSCORE is used with HTTP, the additional TLS protection of HTTP hops is RECOMMENDED, e.g., between an HTTP endpoint and a proxy translating between HTTP and CoAP.
（D）TLSはメッセージ全体をホップバイホップで保護します。 OSCOREは、プロキシ操作に必要のないすべての情報をエンドツーエンドで保護します（セクション4を参照）。 （D）TLSとOSCOREを組み合わせることができるため、エンドポイントと中間ノード間の転送中に、メッセージ全体のホップバイホップ保護と組み合わせて、メッセージペイロードのエンドツーエンドのセキュリティを実現できます。特に、OSCOREがHTTPとともに使用される場合、HTTPホップの追加のTLS保護が推奨されます（たとえば、HTTPエンドポイントとHTTPとCoAPの間で変換するプロキシの間）。
Applications need to consider that certain message fields and messages types are not protected end-to-end and may be spoofed or manipulated. The consequences of unprotected message fields are analyzed in Appendix D.5.
アプリケーションは、特定のメッセージフィールドとメッセージタイプがエンドツーエンドで保護されておらず、なりすましまたは操作される可能性があることを考慮する必要があります。保護されていないメッセージフィールドの結果は、付録D.5で分析されています。
The use of COSE_Encrypt0 and AEAD to protect messages as specified in this document requires an established security context. The method to establish the security context described in Section 3.2 is based on a common Master Secret and unique Sender IDs. The necessary input parameters may be preestablished or obtained using a key establishment protocol augmented with establishment of Sender/ Recipient ID, such as a key exchange protocol or the OSCORE profile of the Authentication and Authorization for Constrained Environments (ACE) framework [OSCORE-PROFILE]. Such a procedure must ensure that the requirements of the security context parameters for the intended use are complied with (see Section 3.3) even in error situations. While recipient IDs are allowed to coincide between different security contexts (see Section 3.3), this may cause a server to process multiple verifications before finding the right security context or rejecting a message. Considerations for deploying OSCORE with a fixed Master Secret are given in Appendix B.
このドキュメントで指定されているようにCOSE_Encrypt0とAEADを使用してメッセージを保護するには、確立されたセキュリティコンテキストが必要です。セクション3.2で説明されているセキュリティコンテキストを確立する方法は、共通のマスターシークレットと一意の送信者IDに基づいています。必要な入力パラメーターは、送信者/受信者IDの確立で補強されたキー確立プロトコルを使用して、事前に確立または取得できます。たとえば、鍵交換プロトコルや、制約付き環境の認証と承認（ACE）フレームワークのOSCOREプロファイル[OSCORE-PROFILE] 。このような手順では、エラーが発生した場合でも、使用目的のセキュリティコンテキストパラメータの要件に準拠していることを確認する必要があります（セクション3.3を参照）。受信者IDは異なるセキュリティコンテキスト間で一致することが許可されていますが（セクション3.3を参照）、これにより、サーバーは正しいセキュリティコンテキストを見つけるかメッセージを拒否する前に複数の検証を処理する可能性があります。マスターシークレットを固定してOSCOREを展開するための考慮事項は、付録Bに記載されています。
OSCORE uses HKDF [RFC5869] and the established input parameters to derive the security context. The required properties of the security context parameters are discussed in Section 3.3; in this section, we focus on the Master Secret. In this specification, HKDF denotes the composition of the expand and extract functions as defined in [RFC5869] and the Master Secret is used as Input Keying Material (IKM).
OSCOREはHKDF [RFC5869]と確立された入力パラメーターを使用してセキュリティコンテキストを導出します。セキュリティコンテキストパラメータの必須プロパティについては、セクション3.3で説明します。このセクションでは、マスターシークレットに焦点を当てます。この仕様では、HKDFは[RFC5869]で定義されている拡張機能と抽出機能の構成を示し、マスターシークレットは入力キーイングマテリアル（IKM）として使用されます。
Informally, HKDF takes as source an IKM containing some good amount of randomness but not necessarily distributed uniformly (or for which an attacker has some partial knowledge) and derive from it one or more cryptographically strong secret keys [RFC5869].
非公式には、HKDFはソースとしてある程度のランダム性を含むが必ずしも均一に分散されていない（または攻撃者がある程度の部分的な知識を持っている）IKMをソースとし、そこから1つ以上の暗号学的に強力な秘密鍵[RFC5869]を導出します。
Therefore, the main requirement for the OSCORE Master Secret, in addition to being secret, is that it have a good amount of randomness. The selected key establishment schemes must ensure that the necessary properties for the Master Secret are fulfilled. For pre-shared key deployments and key transport solutions such as [OSCORE-PROFILE], the Master Secret can be generated offline using a good random number generator. Randomness requirements for security are described in [RFC4086].
したがって、OSCOREマスターシークレットの主な要件は、シークレットであることに加えて、かなりのランダム性を備えていることです。選択されたキー確立スキームは、マスターシークレットに必要なプロパティが確実に満たされるようにする必要があります。事前共有鍵の導入や[OSCORE-PROFILE]などの鍵転送ソリューションでは、優れた乱数ジェネレータを使用してマスターシークレットをオフラインで生成できます。セキュリティのランダム性要件は[RFC4086]で説明されています。
Replay attacks need to be considered in different parts of the implementation. Most AEAD algorithms require a unique nonce for each message, for which the Sender Sequence Numbers in the COSE message field 'Partial IV' is used. If the recipient accepts any sequence number larger than the one previously received, then the problem of sequence number synchronization is avoided. With reliable transport, it may be defined that only messages with sequence numbers that are equal to the previous sequence number + 1 are accepted. An adversary may try to induce a device reboot for the purpose of replaying a message (see Section 7.5).
リプレイ攻撃は、実装のさまざまな部分で考慮する必要があります。ほとんどのAEADアルゴリズムでは、メッセージごとに一意のナンスが必要です。この場合、COSEメッセージフィールドの「部分IV」の送信者シーケンス番号が使用されます。受信者が以前に受信したものよりも大きいシーケンス番号を受け入れる場合、シーケンス番号の同期の問題は回避されます。信頼性の高いトランスポートでは、前のシーケンス番号+ 1に等しいシーケンス番号を持つメッセージのみが受け入れられると定義できます。攻撃者は、メッセージを再生する目的でデバイスの再起動を試みる可能性があります（セクション7.5を参照）。
Note that sharing a security context between servers may open up for replay attacks, for example, if the Replay Windows are not synchronized.
サーバー間でセキュリティコンテキストを共有すると、リプレイウィンドウが同期されていない場合などに、リプレイ攻撃が発生する可能性があることに注意してください。
A verified OSCORE request enables the server to verify the identity of the entity who generated the message. However, it does not verify that the client is currently involved in the communication, since the message may be a delayed delivery of a previously generated request, which now reaches the server. To verify the aliveness of the client the server may use the Echo option in the response to a request from the client (see [CoAP-ECHO-REQ-TAG]).
検証済みのOSCORE要求により、サーバーはメッセージを生成したエンティティのIDを検証できます。ただし、メッセージが以前に生成されたリクエストの配信遅延であり、サーバーに到達したため、クライアントが現在通信に関与していることは確認されません。クライアントの活性を確認するために、サーバーはクライアントからの要求への応答でEchoオプションを使用できます（[CoAP-ECHO-REQ-TAG]を参照）。
The maximum Sender Sequence Number is dependent on the AEAD algorithm. The maximum Sender Sequence Number is 2^40 - 1, or any algorithm-specific lower limit, after which a new security context must be generated. The mechanism to build the AEAD nonce (Section 5.2) assumes that the nonce is at least 56 bits, and the Partial IV is at most 40 bits. The mandatory-to-implement AEAD algorithm AES-CCM-16-64-128 is selected for compatibility with CCM*. AEAD algorithms that require unpredictable nonces are not supported.
最大送信者シーケンス番号は、AEADアルゴリズムによって異なります。最大送信者シーケンス番号は2 ^ 40-1、またはアルゴリズム固有の下限です。その後、新しいセキュリティコンテキストを生成する必要があります。 AEADナンスを構築するメカニズム（セクション5.2）では、ナンスは少なくとも56ビットであり、パーシャルIVは最大で40ビットであると想定しています。実装に必須のAEADアルゴリズムAES-CCM-16-64-128は、CCM *との互換性のために選択されています。予測できないナンスを必要とするAEADアルゴリズムはサポートされていません。
In order to prevent cryptanalysis when the same plaintext is repeatedly encrypted by many different users with distinct AEAD keys, the AEAD nonce is formed by mixing the sequence number with a secret per-context initialization vector (Common IV) derived along with the keys (see Section 3.1 of [RFC8152]), and by using a Master Salt in the key derivation (see [MF00] for an overview). The Master Secret, Sender Key, Recipient Key, and Common IV must be secret, the rest of the parameters may be public. The Master Secret must have a good amount of randomness (see Section 12.3).
同じプレーンテキストが異なるAEADキーを持つ多くの異なるユーザーによって繰り返し暗号化されるときの暗号解読を防ぐために、AEADナンスは、シーケンス番号をキーと共に導出される秘密のコンテキストごとの初期化ベクトル（共通IV）と混合することによって形成されます（参照[RFC8152]のセクション3.1）、および鍵導出でマスターソルトを使用する（概要については[MF00]を参照）。マスターシークレット、送信者キー、受信者キー、および共通IVは秘密にする必要があり、残りのパラメーターは公開することができます。マスターシークレットには十分なランダム性が必要です（セクション12.3を参照）。
The ID Context, Sender ID, and Partial IV are always at least implicitly integrity protected, as manipulation leads to the wrong nonce or key being used and therefore results in decryption failure.
IDコンテキスト、送信者ID、および部分IVは常に操作によって少なくとも暗黙的に整合性が保護されます。これは、操作によって誤ったナンスまたはキーが使用され、その結果、復号化が失敗するためです。
The Inner Block options enable the sender to split large messages into OSCORE-protected blocks such that the receiving endpoint can verify blocks before having received the complete message. The Outer Block options allow for arbitrary proxy fragmentation operations that cannot be verified by the endpoints but that can, by policy, be restricted in size since the Inner Block options allow for secure fragmentation of very large messages. A maximum message size (above which the sending endpoint fragments the message and the receiving endpoint discards the message, if complying to the policy) may be obtained as part of normal resource discovery.
内部ブロックオプションを使用すると、送信側は大きなメッセージをOSCOREで保護されたブロックに分割できるため、受信側のエンドポイントは完全なメッセージを受信する前にブロックを検証できます。外部ブロックオプションを使用すると、エンドポイントでは検証できない任意のプロキシフラグメンテーション操作を実行できますが、内部ブロックオプションを使用すると、非常に大きなメッセージを安全にフラグメント化できるため、ポリシーによってサイズを制限できます。通常のリソース検出の一部として、最大メッセージサイズ（送信エンドポイントがメッセージをフラグメント化し、受信エンドポイントがポリシーを遵守している場合は、メッセージを破棄するサイズ）を取得できます。
Privacy threats executed through intermediary nodes are considerably reduced by means of OSCORE. End-to-end integrity protection and encryption of the message payload and all options that are not used for proxy operations provide mitigation against attacks on sensor and actuator communication, which may have a direct impact on the personal sphere.
中間ノードを介して実行されるプライバシーの脅威は、OSCOREによって大幅に軽減されます。エンドツーエンドの整合性保護とメッセージペイロードの暗号化、およびプロキシ操作に使用されないすべてのオプションにより、個人の領域に直接影響する可能性のあるセンサーおよびアクチュエーター通信への攻撃を軽減できます。
The unprotected options (Figure 5) may reveal privacy-sensitive information, see Appendix D.5. CoAP headers sent in plaintext allow, for example, matching of CON and ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis. OSCORE does not provide protection for HTTP header fields that are not both CoAP-mappable and Class E. The HTTP message fields that are visible to on-path entities are only used for the purpose of transporting the OSCORE message, whereas the application-layer message is encoded in CoAP and encrypted.
保護されていないオプション（図5）はプライバシーに敏感な情報を明らかにする可能性があります。付録D.5を参照してください。プレーンテキストで送信されるCoAPヘッダーにより、たとえば、CONとACK（CoAPメッセージID）のマッチング、要求と応答（トークン）のマッチング、およびトラフィック分析が可能になります。 OSCOREは、CoAPマップ可能でもクラスEでもないHTTPヘッダーフィールドの保護を提供しません。オンパスエンティティに表示されるHTTPメッセージフィールドは、OSCOREメッセージを転送する目的でのみ使用されますが、アプリケーション層メッセージはCoAPでエンコードされ、暗号化されます。
COSE message fields, i.e., the OSCORE option, may reveal information about the communicating endpoints. For example, 'kid' and 'kid context', which are intended to help the server find the right context, may reveal information about the client. Tracking 'kid' and 'kid context' to one server may be used for correlating requests from one client.
COSEメッセージフィールド、つまりOSCOREオプションは、通信するエンドポイントに関する情報を明らかにする場合があります。たとえば、サーバーが適切なコンテキストを見つけることを目的とした「kid」と「kid context」は、クライアントに関する情報を明らかにする場合があります。 1つのサーバーへの「子供」と「子供コンテキスト」の追跡は、1つのクライアントからの要求を関連付けるために使用できます。
Unprotected error messages reveal information about the security state in the communication between the endpoints. Unprotected signaling messages reveal information about the reliable transport used on a leg of the path. Using the mechanisms described in Section 7.5 may reveal when a device goes through a reboot. This can be mitigated by the device storing the precise state of Sender Sequence Number and Replay Window on a clean shutdown.
保護されていないエラーメッセージは、エンドポイント間の通信のセキュリティ状態に関する情報を明らかにします。保護されていないシグナリングメッセージは、パスのレッグで使用されている信頼性の高いトランスポートに関する情報を明らかにします。セクション7.5で説明されているメカニズムを使用すると、デバイスが再起動するタイミングが明らかになる場合があります。これは、デバイスがクリーンシャットダウン時に送信者シーケンス番号とリプレイウィンドウの正確な状態を保存することで軽減できます。
The length of message fields can reveal information about the message. Applications may use a padding scheme to protect against traffic analysis.
メッセージフィールドの長さにより、メッセージに関する情報が明らかになります。アプリケーションは、トラフィック分析から保護するためにパディングスキームを使用できます。
The 'kid context' parameter has been added to the "COSE Header Parameters" registry:
「キッドコンテキスト」パラメータが「COSEヘッダパラメータ」レジストリに追加されました。
o Name: kid context
o 名前：子供のコンテキスト
o Label: 10
o ラベル10
o Value Type: bstr
o 値のタイプ：bstr
o Value Registry:
o バリューレジストリ：
o Description: Identifies the context for the key identifier
o 説明：キー識別子のコンテキストを識別します
o Reference: Section 5.1 of this document
o 参照：このドキュメントのセクション5.1
The OSCORE option has been added to the "CoAP Option Numbers" registry:
OSCOREオプションが「CoAP Option Numbers」レジストリに追加されました。
+--------+-----------------+-------------------+
| Number | Name | Reference |
+--------+-----------------+-------------------+
| 9 | OSCORE | [RFC8613] |
+--------+-----------------+-------------------+
Furthermore, the following existing entries in the "CoAP Option Numbers" registry have been updated with a reference to the document specifying OSCORE processing of that option:
さらに、「CoAP Option Numbers」レジストリの次の既存のエントリは、そのオプションのOSCORE処理を指定するドキュメントへの参照で更新されました。
+--------+-----------------+-------------------------------+
| Number | Name | Reference |
+--------+-----------------+-------------------------------+
| 1 | If-Match | [RFC7252] [RFC8613] |
| 3 | Uri-Host | [RFC7252] [RFC8613] |
| 4 | ETag | [RFC7252] [RFC8613] |
| 5 | If-None-Match | [RFC7252] [RFC8613] |
| 6 | Observe | [RFC7641] [RFC8613] |
| 7 | Uri-Port | [RFC7252] [RFC8613] |
| 8 | Location-Path | [RFC7252] [RFC8613] |
| 11 | Uri-Path | [RFC7252] [RFC8613] |
| 12 | Content-Format | [RFC7252] [RFC8613] |
| 14 | Max-Age | [RFC7252] [RFC8613] |
| 15 | Uri-Query | [RFC7252] [RFC8613] |
| 17 | Accept | [RFC7252] [RFC8613] |
| 20 | Location-Query | [RFC7252] [RFC8613] |
| 23 | Block2 | [RFC7959] [RFC8323] [RFC8613] |
| 27 | Block1 | [RFC7959] [RFC8323] [RFC8613] |
| 28 | Size2 | [RFC7959] [RFC8613] |
| 35 | Proxy-Uri | [RFC7252] [RFC8613] |
| 39 | Proxy-Scheme | [RFC7252] [RFC8613] |
| 60 | Size1 | [RFC7252] [RFC8613] |
| 258 | No-Response | [RFC7967] [RFC8613] |
+--------+-----------------+-------------------------------+
Future additions to the "CoAP Option Numbers" registry need to provide a reference to the document where the OSCORE processing of that CoAP Option is defined.
「CoAPオプション番号」レジストリへの将来の追加では、そのCoAPオプションのOSCORE処理が定義されているドキュメントへの参照を提供する必要があります。
The OSCORE option has been added to the "CoAP Signaling Option Numbers" registry:
OSCOREオプションが「CoAP Signaling Option Numbers」レジストリに追加されました。
+------------+--------+---------------------+-------------------+
| Applies to | Number | Name | Reference |
+------------+--------+---------------------+-------------------+
| 7.xx (all) | 9 | OSCORE | [RFC8613] |
+------------+--------+---------------------+-------------------+
The HTTP OSCORE header field has been added to the "Message Headers" registry:
HTTP OSCOREヘッダーフィールドが「メッセージヘッダー」レジストリに追加されました。
+-------------------+----------+----------+---------------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------------+
| OSCORE | http | standard | [RFC8613], |
| | | | Section 11.1 |
+-------------------+----------+----------+---------------------+
This section registers the 'application/oscore' media type in the "Media Types" registry. This media type is used to indicate that the content is an OSCORE message. The OSCORE body cannot be understood without the OSCORE header field value and the security context.
このセクションでは、「アプリケーション/ oscore」メディアタイプを「メディアタイプ」レジストリに登録します。このメディアタイプは、コンテンツがOSCOREメッセージであることを示すために使用されます。 OSCOREボディは、OSCOREヘッダーフィールド値とセキュリティコンテキストなしでは理解できません。
Type name: application
タイプ名：アプリケーション
Subtype name: oscore
サブタイプ名：oscore
Required parameters: N/A
必須パラメーター：なし
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: binary
エンコーディングに関する考慮事項：バイナリ
Security considerations: See the Security Considerations section of [RFC8613].
セキュリティに関する考慮事項：[RFC8613]のセキュリティに関する考慮事項のセクションを参照してください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: [RFC8613]
公開された仕様：[RFC8613]
Applications that use this media type: IoT applications sending security content over HTTP(S) transports.
このメディアタイプを使用するアプリケーション：HTTP（S）トランスポートを介してセキュリティコンテンツを送信するIoTアプリケーション。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：なし
Additional information:
追加情報：
* Deprecated alias names for this type: N/A
* Magic number(s): N/A
* File extension(s): N/A
* Macintosh file type code(s): N/A
Person & email address to contact for further information:
IESG <iesg@ietf.org>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：N / A
Author: Goeran Selander <goran.selander@ericsson.com>
Change Controller: IESG
コントローラーの変更：IESG
Provisional registration? No
仮登録？番号
This section registers the media type 'application/oscore' media type in the "CoAP Content-Formats" registry. This Content-Format for the OSCORE payload is defined for potential future use cases and SHALL NOT be used in the OSCORE message. The OSCORE payload cannot be understood without the OSCORE option value and the security context.
このセクションでは、メディアタイプ「application / oscore」メディアタイプを「CoAP Content-Formats」レジストリに登録します。 OSCOREペイロードのこのContent-Formatは、将来の潜在的な使用例のために定義されており、OSCOREメッセージで使用されるべきではありません（SHALL NOT）。 OSCOREペイロードは、OSCOREオプション値とセキュリティコンテキストなしでは理解できません。
+----------------------+----------+----------+-------------------+
| Media Type | Encoding | ID | Reference |
+----------------------+----------+----------+-------------------+
| application/oscore | | 10001 | [RFC8613] |
+----------------------+----------+----------+-------------------+
This document defines a subregistry for the OSCORE flag bits within the "CoRE Parameters" registry. The name of the subregistry is "OSCORE Flag Bits". The registry has been created with the Expert Review policy [RFC8126]. Guidelines for the experts are provided in Section 13.8.
このドキュメントでは、「CoREパラメータ」レジストリ内のOSCOREフラグビットのサブレジストリを定義します。サブレジストリの名前は「OSCORE Flag Bits」です。レジストリは、エキスパートレビューポリシー[RFC8126]を使用して作成されています。エキスパートのためのガイドラインはセクション13.8にあります。
The columns of the registry are as follows:
レジストリの列は次のとおりです。
o Bit Position: This indicates the position of the bit in the set of OSCORE flag bits, starting at 0 for the most significant bit. The bit position must be an integer or a range of integers, in the range 0 to 63.
o ビット位置：これは、OSCOREフラグビットのセット内のビットの位置を示し、最上位ビットの0から始まります。ビット位置は、整数または整数の範囲（0〜63の範囲）でなければなりません。
o Name: The name is present to make it easier to refer to and discuss the registration entry. The value is not used in the protocol. Names are to be unique in the table.
o 名前：名前は、登録エントリの参照と議論を容易にするために存在します。この値はプロトコルでは使用されません。名前はテーブル内で一意である必要があります。
o Description: This contains a brief description of the use of the bit.
o 説明：これには、ビットの使用に関する簡単な説明が含まれています。
o Reference: This contains a pointer to the specification defining the entry.
o 参照：これには、エントリを定義する仕様へのポインタが含まれています。
The initial contents of the registry are in the table below. The reference column for all rows is this document. The entries with Bit Position of 0 and 1 are marked as 'Reserved'. The entry with Bit Position of 1 will be specified in a future document and will be used to expand the space for the OSCORE flag bits in Section 6.1, so that entries 8-63 of the registry are defined.
レジストリの初期の内容は、以下の表にあります。すべての行の参照列はこのドキュメントです。ビット位置が0および1のエントリは、「予約済み」としてマークされます。ビット位置が1のエントリは、今後のドキュメントで指定され、セクション6.1でOSCOREフラグビットのスペースを拡張するために使用されるため、レジストリのエントリ8〜63が定義されます。
+--------------+-------------+-----------------------------+-----------+
| Bit Position | Name | Description | Reference |
+--------------+-------------+-----------------------------+-----------+
| 0 | Reserved | | |
+--------------+-------------+-----------------------------+-----------+
| 1 | Reserved | | |
+--------------+-------------+-----------------------------+-----------+
| 2 | Unassigned | | |
+--------------+-------------+-----------------------------+-----------+
| 3 | Kid Context | Set to 1 if kid context | [RFC8613] |
| | Flag | is present in the | |
| | | compressed COSE object | |
+--------------+-------------+-----------------------------+-----------+
| 4 | Kid Flag | Set to 1 if kid is present | [RFC8613] |
| | | in the compressed COSE | |
| | | object | |
+--------------+-------------+-----------------------------+-----------+
| 5-7 | Partial IV | Encodes the Partial IV | [RFC8613] |
| | Length | length; can have value | |
| | | 0 to 5 | |
+--------------+-------------+-----------------------------+-----------+
| 8-63 | Unassigned | | |
+--------------+-------------+-----------------------------+-----------+
The expert reviewers for the registry defined in this document are expected to ensure that the usage solves a valid use case that could not be solved better in a different way, that it is not going to duplicate one that is already registered, and that the registered point is likely to be used in deployments. They are furthermore expected to check the clarity of purpose and use of the requested code points. Experts should take into account the expected usage of entries when approving point assignment, and the length of the encoded value should be weighed against the number of code points left that encode to that size and the size of device it will be used on. Experts should block registration for entries 8-63 until these points are defined (i.e., until the mechanism for the OSCORE flag bits expansion via bit 1 is specified).
このドキュメントで定義されているレジストリのエキスパートレビューアは、別の方法では解決できなかった有効なユースケースを解決し、すでに登録されているものと重複しないこと、および登録されていることを確認する必要があります。ポイントは展開で使用される可能性があります。さらに、目的の明確さと要求されたコードポイントの使用を確認することが求められます。専門家は、ポイントの割り当てを承認するときにエントリの予想される使用法を考慮に入れる必要があり、エンコードされた値の長さは、そのサイズにエンコードされた残りのコードポイントの数とそれが使用されるデバイスのサイズと比較検討する必要があります。専門家は、これらのポイントが定義されるまで（つまり、ビット1を介したOSCOREフラグビット拡張のメカニズムが指定されるまで）、エントリ8〜63の登録をブロックする必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<https：//www.rfc-editor .org / info / rfc4086>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7049] Bormann、C。およびP. Hoffman、「簡潔なバイナリオブジェクト表現（CBOR）」、RFC 7049、DOI 10.17487 / RFC7049、2013年10月、<https://www.rfc-editor.org/info/rfc7049> 。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[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>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-editor。 org / info / rfc7252>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「Observing Resources in the Constrained Application Protocol（CoAP）」、RFC 7641、DOI 10.17487 / RFC7641、2015年9月、<https://www.rfc-editor.org/info/rfc7641>。
[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>.
[RFC7959] Bormann、C.およびZ. Shelby、Ed。、「Block-Wise Transfers in the Constrained Application Protocol（CoAP）」、RFC 7959、DOI 10.17487 / RFC7959、2016年8月、<https：//www.rfc- editor.org/info/rfc7959>。
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, <https://www.rfc-editor.org/info/rfc8075>.
[RFC8075] Castellani、A.、Loreto、S.、Rahman、A.、Fossati、T。、およびE. Dijk、「実装のマッピングのガイドライン：HTTPから制約付きアプリケーションプロトコル（CoAP）」、RFC 8075、DOI 10.17487 / RFC8075、2017年2月、<https://www.rfc-editor.org/info/rfc8075>。
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, <https://www.rfc-editor.org/info/rfc8132>.
[RFC8132] van der Stok、P.、Bormann、C。、およびA. Sehgal、「制約付きアプリケーションプロトコル（CoAP）のPATCHおよびFETCHメソッド」、RFC 8132、DOI 10.17487 / RFC8132、2017年4月、<https：/ /www.rfc-editor.org/info/rfc8132>。
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.
[RFC8152] Schaad、J。、「CBOR Object Signing and Encryption（COSE）」、RFC 8152、DOI 10.17487 / RFC8152、2017年7月、<https://www.rfc-editor.org/info/rfc8152>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]ノッティンガム、M。、「Webリンク」、RFC 8288、DOI 10.17487 / RFC8288、2017年10月、<https://www.rfc-editor.org/info/rfc8288>。
[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>.
[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、2018年2月、<https://www.rfc-editor.org/info/rfc8323>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C。、およびC. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）およびJSONデータ構造を表現するための表記法」、RFC 8610、DOI 10.17487 / RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[ACE-OAuth] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", Work in Progress, draft-ietf-ace-oauth-authz-24, March 2019.
[ACE-OAuth] Seitz、L.、Selander、G.、Wahlstroem、E.、Erdtman、S。、およびH. Tschofenig、「OAuth 2.0フレームワークを使用した制約付き環境（ACE）の認証と承認（ACE-OAuth） "、作業中、draft-ietf-ace-oauth-authz-24、2019年3月。
[CoAP-802.15.4] Bormann, C., "Constrained Application Protocol (CoAP) over IEEE 802.15.4 Information Element for IETF", Work in Progress, draft-bormann-6lo-coap-802-15-ie-00, April 2016.
[CoAP-802.15.4] Bormann、C。、「IETFのIEEE 802.15.4情報要素上の制約付きアプリケーションプロトコル（CoAP）」、作業中、draft-bormann-6lo-coap-802-15-ie-00、 2016年4月。
[CoAP-Actuators] Mattsson, J., Fornehed, J., Selander, G., Palombini, F., and C. Amsuess, "Controlling Actuators with CoAP", Work in Progress, draft-mattsson-core-coap-actuators-06, September 2018.
[CoAP-Actuators] Mattsson、J.、Fornehed、J.、Selander、G.、Palombini、F.、and C. Amsuess、 "Controlling Actuators with CoAP"、Work in Progress、draft-mattsson-core-coap-actuators -06、2018年9月。
[CoAP-E2E-Sec] Selander, G., Palombini, F., and K. Hartke, "Requirements for CoAP End-To-End Security", Work in Progress, draft-hartke-core-e2e-security-reqs-03, July 2017.
[CoAP-E2E-Sec] Selander、G.、Palombini、F。、およびK. Hartke、「CoAPエンドツーエンドセキュリティの要件」、進行中の作業、draft-hartke-core-e2e-security-reqs- 2017年7月3日。
[CoAP-ECHO-REQ-TAG] Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Request-Tag, and Token Processing", Work in Progress, draft-ietf-core-echo-request-tag-04, March 2019.
[CoAP-ECHO-REQ-TAG] Amsuess、C.、Mattsson、J。、およびG. Selander、「CoAP：Echo、Request-Tag、およびToken Processing」、Work in Progress、draft-ietf-core-echo- request-tag-04、2019年3月。
[Group-OSCORE] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, draft-ietf-core-oscore-groupcomm-04, March 2019.
[Group-OSCORE] Tiloca、M.、Selander、G.、Palombini、F.、J。Park、「Group OSCORE-CoAPの安全なグループ通信」、作業中、draft-ietf-core-oscore-groupcomm- 2019年3月4日。
[IV-GEN] McGrew, D., "Generation of Deterministic Initialization Vectors (IVs) and Nonces", Work in Progress, draft-mcgrew-iv-gen-03, October 2013.
[IV-GEN] McGrew、D。、「Generative of Deterministic Initialization Vector（IVs）and Nonces」、Work in Progress、draft-mcgrew-iv-gen-03、2013年10月。
[MF00] McGrew, D. and S. Fluhrer, "Attacks on Additive Encryption of Redundant Plaintext and Implications on Internet Security", Proceedings of the Seventh Annual Workshop on Selected Areas in Cryptography (SAC 2000) Springer-Verlag., pp. 14-28, 2000.
[MF00] McGrew、D。およびS. Fluhrer、「冗長な平文の付加的暗号化とインターネットセキュリティへの影響に関する攻撃」、暗号化の選択された領域に関する第7回年次ワークショップの議事録（SAC 2000）Springer-Verlag。、pp。14 -28、2000。
[OSCORE-PROFILE] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", Work in Progress, draft-ietf-ace-oscore-profile-07, February 2019.
[OSCORE-PROFILE] Palombini、F.、Seitz、L.、Selander、G。、およびM. Gunnarsson、「制約付き環境フレームワークの認証および承認のOSCOREプロファイル」、作業中、draft-ietf-ace-oscore -profile-07、2019年2月。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2010.
[REST] Fielding、R。、「Architectural Styles and the Design of Network-based Software Architectures」、Ph.D。カリフォルニア大学アーバイン校、2010年。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストの記述に関するガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<https://www.rfc-editor.org/ info / rfc3552>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<https://www.rfc-editor.org/info/rfc5116>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー導出関数（HKDF）」、RFC 5869、DOI 10.17487 / RFC5869、2010年5月、<https：//www.rfc-editor .org / info / rfc5869>。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>.
[RFC6690] Shelby、Z。、「Constrained RESTful Environments（CoRE）Link Format」、RFC 6690、DOI 10.17487 / RFC6690、2012年8月、<https://www.rfc-editor.org/info/rfc6690>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<https://www.rfc-editor.org / info / rfc7228>。
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<https://www.rfc-editor.org / info / rfc7515>。
[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>.
[RFC7967] Bhattacharyya、A.、Bandyopadhyay、S.、Pal、A。、およびT. Bose、「サーバー応答がない場合の制限付きアプリケーションプロトコル（CoAP）オプション」、RFC 7967、DOI 10.17487 / RFC7967、2016年8月、<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>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
This section gives examples of OSCORE, targeting scenarios in Section 2.2.1.1 of [CoAP-E2E-Sec]. The message exchanges are made, based on the assumption that there is a security context established between client and server. For simplicity, these examples only indicate the content of the messages without going into detail of the (compressed) COSE message format.
このセクションでは、[CoAP-E2E-Sec]のセクション2.2.1.1のシナリオを対象としたOSCOREの例を示します。メッセージ交換は、クライアントとサーバーの間にセキュリティコンテキストが確立されているという想定に基づいて行われます。簡単にするために、これらの例は、（圧縮された）COSEメッセージ形式の詳細には触れずに、メッセージの内容のみを示しています。
This example illustrates a client requesting the alarm status from a server.
この例は、サーバーからのアラーム状態を要求するクライアントを示しています。
Client Proxy Server
| | |
+------>| | Code: 0.02 (POST)
| POST | | Token: 0x8c
| | | OSCORE: [kid:5f, Partial IV:42]
| | | Payload: {Code:0.01,
| | | Uri-Path:"alarm_status"}
| | |
| +------>| Code: 0.02 (POST)
| | POST | Token: 0x7b
| | | OSCORE: [kid:5f, Partial IV:42]
| | | Payload: {Code:0.01,
| | | Uri-Path:"alarm_status"}
| | |
| |<------+ Code: 2.04 (Changed)
| | 2.04 | Token: 0x7b
| | | OSCORE: -
| | | Payload: {Code:2.05, "0"}
| | |
|<------+ | Code: 2.04 (Changed)
| 2.04 | | Token: 0x8c
| | | OSCORE: -
| | | Payload: {Code:2.05, "0"}
| | |
Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data.
大括弧[...]は、圧縮されたCOSEオブジェクトの内容を示します。中括弧{...}は暗号化されたデータを示します。
Figure 12: Secure Access to Sensor
図12：センサーへの安全なアクセス
The CoAP request/response Codes are encrypted by OSCORE and only dummy Codes (POST/Changed) are visible in the header of the OSCORE message. The option Uri-Path ("alarm_status") and payload ("0") are encrypted.
CoAP要求/応答コードはOSCOREによって暗号化され、ダミーコード（POST /変更済み）のみがOSCOREメッセージのヘッダーに表示されます。オプションのUri-Path（ "alarm_status"）とペイロード（ "0"）は暗号化されています。
The COSE header of the request contains an identifier (5f), indicating which security context was used to protect the message and a Partial IV (42).
要求のCOSEヘッダーには、メッセージを保護するために使用されたセキュリティコンテキストと部分IV（42）を示す識別子（5f）が含まれています。
The server verifies the request as specified in Section 8.2. The client verifies the response as specified in Section 8.4.
サーバーは、セクション8.2で指定されているように要求を検証します。クライアントは、セクション8.4で指定されたとおりに応答を検証します。
This example illustrates a client requesting subscription to a blood sugar measurement resource (GET /glucose), first receiving the value 220 mg/dl and then a second value 180 mg/dl.
この例は、血糖値測定リソース（GET / glucose）へのサブスクリプションを要求し、最初に220 mg / dlの値を受け取り、次に2番目の値180 mg / dlを受け取るクライアントを示しています。
Client Proxy Server
| | |
+------>| | Code: 0.05 (FETCH)
| FETCH | | Token: 0x83
| | | Observe: 0
| | | OSCORE: [kid:ca, Partial IV:15]
| | | Payload: {Code:0.01,
| | | Observe:0,
| | | Uri-Path:"glucose"}
| | |
| +------>| Code: 0.05 (FETCH)
| | FETCH | Token: 0xbe
| | | Observe: 0
| | | OSCORE: [kid:ca, Partial IV:15]
| | | Payload: {Code:0.01,
| | | Observe:0,
| | | Uri-Path:"glucose"}
| | |
| |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe
| | | Observe: 7
| | | OSCORE: -
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "220"}
| | |
|<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Observe: 7
| | | OSCORE: -
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "220"}
... ... ...
| | |
| |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe
| | | Observe: 8
| | | OSCORE: [Partial IV:36]
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "180"}
| | |
|<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Observe: 8
| | | OSCORE: [Partial IV:36]
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "180"}
| | |
Square brackets [ ... ] indicate content of compressed COSE object header. Curly brackets { ... } indicate encrypted data.
大括弧[...]は、圧縮されたCOSEオブジェクトヘッダーの内容を示します。中括弧{...}は暗号化されたデータを示します。
Figure 13: Secure Subscribe to Sensor
図13：センサーへの安全なサブスクライブ
The dummy Codes (FETCH/Content) are used to allow forwarding of Observe messages. The options Content-Format (0) and the payload ("220" and "180") are encrypted.
ダミーコード（FETCH /コンテンツ）は、Observeメッセージの転送を可能にするために使用されます。オプションContent-Format（0）とペイロード（ "220"と "180"）は暗号化されています。
The COSE header of the request contains an identifier (ca), indicating the security context used to protect the message and a Partial IV (15). The COSE header of the second response contains the Partial IV (36). The first response uses the Partial IV of the request.
リクエストのCOSEヘッダーには、メッセージの保護に使用されるセキュリティコンテキストと部分IV（15）を示す識別子（ca）が含まれています。 2番目の応答のCOSEヘッダーには、パーシャルIV（36）が含まれています。最初の応答は、要求の部分IVを使用します。
The server verifies that the Partial IV has not been received before. The client verifies that the responses are bound to the request and that the Partial IVs are greater than any Partial IV previously received in a response bound to the request, except for the notification without Partial IV, which is considered the oldest.
サーバーは、部分IVが以前に受信されていないことを確認します。クライアントは、応答が要求にバインドされていること、および部分IVが、要求にバインドされた応答で以前に受信した部分IVよりも大きいことを確認します。ただし、最も古いと見なされる部分IVなしの通知は除きます。
For many Internet of Things (IoT) deployments, a 128-bit uniformly random Master Key is sufficient for encrypting all data exchanged with the IoT device throughout its lifetime. Two examples are given in this section. In the first example, the security context is only derived once from the Master Secret. In the second example, security contexts are derived multiple times using random inputs.
多くのモノのインターネット（IoT）の展開では、IoTデバイスと交換されるすべてのデータをそのライフタイム全体で暗号化するには、128ビットの一様にランダムなマスターキーで十分です。このセクションでは、2つの例を示します。最初の例では、セキュリティコンテキストはマスターシークレットから1回だけ取得されます。 2番目の例では、ランダムな入力を使用してセキュリティコンテキストが複数回導出されます。
An application that only derives the security context once needs to handle the loss of mutable security context parameters, e.g., due to reboot.
セキュリティコンテキストのみを取得するアプリケーションは、再起動などによる変更可能なセキュリティコンテキストパラメータの損失を処理する必要があります。
In order to handle loss of Sender Sequence Numbers, the device may implement procedures for writing to nonvolatile memory during normal operations and updating the security context after reboot, provided that the procedures comply with the requirements on the security context parameters (Section 3.3). This section gives an example of such a procedure.
送信者シーケンス番号の損失を処理するために、デバイスは、通常の操作中に不揮発性メモリに書き込み、再起動後にセキュリティコンテキストを更新する手順を実装できます。ただし、手順がセキュリティコンテキストパラメーターの要件に準拠している場合（セクション3.3）。このセクションでは、そのような手順の例を示します。
There are known issues related to writing to nonvolatile memory. For example, flash drives may have a limited number of erase operations during its lifetime. Also, the time for a write operation to nonvolatile memory to be completed may be unpredictable, e.g., due to caching, which could result in important security context data not being stored at the time when the device reboots.
不揮発性メモリへの書き込みに関連する既知の問題があります。たとえば、フラッシュドライブの寿命中は、消去操作の回数に制限があります。また、不揮発性メモリへの書き込み操作が完了するまでの時間は、たとえばキャッシュが原因で予測できない場合があり、デバイスの再起動時に重要なセキュリティコンテキストデータが保存されない可能性があります。
However, many devices have predictable limits for writing to nonvolatile memory, are physically limited to only send a small amount of messages per minute, and may have no good source of randomness.
ただし、多くのデバイスには、不揮発性メモリへの書き込みに予測可能な制限があり、1分あたりのメッセージ送信量が物理的に制限されており、ランダム性の優れたソースがない場合があります。
To prevent reuse of Sender Sequence Number, an endpoint may perform the following procedure during normal operations:
送信者シーケンス番号の再利用を防ぐために、エンドポイントは通常の操作中に次の手順を実行する場合があります。
o Before using a Sender Sequence Number that is evenly divisible by K, where K is a positive integer, store the Sender Sequence Number (SSN1) in nonvolatile memory. After booting, the endpoint initiates the new Sender Sequence Number (SSN2) to the value stored in persistent memory plus K plus F: SSN2 = SSN1 + K + F, where F is a positive integer.
o Kで割り切れる送信者シーケンス番号（Kは正の整数）を使用する前に、送信者シーケンス番号（SSN1）を不揮発性メモリに保存します。起動後、エンドポイントは永続的なメモリに格納されている値にK + Fを加えた新しい送信者シーケンス番号（SSN2）を開始します。SSN2= SSN1 + K + F、ここでFは正の整数です。
* Writing to nonvolatile memory can be costly; the value K gives a trade-off between frequency of storage operations and efficient use of Sender Sequence Numbers.
* 不揮発性メモリへの書き込みはコストがかかる可能性があります。値Kは、ストレージ操作の頻度と送信者シーケンス番号の効率的な使用との間のトレードオフを提供します。
* Writing to nonvolatile memory may be subject to delays, or failure; F MUST be set so that the last Sender Sequence Number used before reboot is never larger than SSN2.
* 不揮発性メモリへの書き込みは、遅延または障害の影響を受ける可能性があります。再起動前に使用された最後の送信者シーケンス番号がSSN2より大きくならないようにFを設定する必要があります。
If F cannot be set so SSN2 is always larger than the last Sender Sequence Number used before reboot, the method described in this section MUST NOT be used.
Fを設定できないため、SSN2が常に再起動前に使用された最後の送信者シーケンス番号よりも大きい場合、このセクションで説明されている方法を使用してはなりません。
In case of loss of security context on the server, to prevent accepting replay of previously received requests, the server may perform the following procedure after booting:
サーバーでセキュリティコンテキストが失われた場合、以前に受信した要求の再生を受け入れないようにするために、サーバーは起動後に次の手順を実行することがあります。
o The server updates its Sender Sequence Number as specified in Appendix B.1.1 to be used as Partial IV in the response containing the Echo option (next bullet).
o サーバーは、付録B.1.1に指定されている送信者シーケンス番号を更新して、エコーオプション（次の箇条書き）を含む応答で部分IVとして使用します。
o For each stored security context, the first time after booting, the server receives an OSCORE request, the server responds with an OSCORE protected 4.01 (Unauthorized), containing only the Echo option [CoAP-ECHO-REQ-TAG] and no diagnostic payload. The server MUST use its Partial IV when generating the AEAD nonce and MUST include the Partial IV in the response (see Section 5). If the server with use of the Echo option can verify a second OSCORE request as fresh, then the Partial IV of the second request is set as the lower limit of the Replay Window of that security context.
o 格納されたセキュリティコンテキストごとに、サーバーは起動後初めてOSCORE要求を受信し、サーバーはOSCOREで保護された4.01（無許可）で応答し、エコーオプション[CoAP-ECHO-REQ-TAG]のみを含み、診断ペイロードは含まれません。サーバーは、AEADナンスを生成するときにその部分IVを使用する必要があり、応答に部分IVを含める必要があります（セクション5を参照）。 Echoオプションを使用するサーバーが2番目のOSCORE要求を新しいものとして検証できる場合、2番目の要求の部分IVは、そのセキュリティコンテキストの再生ウィンドウの下限として設定されます。
To prevent the acceptance of replay of previously received notifications, the client may perform the following procedure after booting:
以前に受信した通知のリプレイの受け入れを防ぐために、クライアントは起動後に次の手順を実行できます。
o The client forgets about earlier registrations and removes all Notification Numbers. The client then registers again using the Observe option.
o クライアントは以前の登録を忘れ、すべての通知番号を削除します。その後、クライアントは監視オプションを使用して再度登録します。
An application that does not require forward secrecy may allow multiple security contexts to be derived from one Master Secret. The requirements on the security context parameters MUST be fulfilled (Section 3.3) even if the client or server is rebooted, recommissioned, or in error cases.
転送秘密を必要としないアプリケーションでは、1つのマスターシークレットから複数のセキュリティコンテキストを派生させることができます。クライアントまたはサーバーが再起動、再稼働、またはエラーが発生した場合でも、セキュリティコンテキストパラメータの要件を満たさなければなりません（セクション3.3）。
This section gives an example of a protocol that adds randomness to the ID Context parameter and uses that together with input parameters preestablished between client and server, in particular Master Secret, Master Salt, and Sender/Recipient ID (see Section 3.2), to derive new security contexts. The random input is transported between client and server in the 'kid context' parameter. This protocol MUST NOT be used unless both endpoints have good sources of randomness.
このセクションでは、IDコンテキストパラメーターにランダム性を追加し、クライアントとサーバー間で事前に確立された入力パラメーター（特に、マスターシークレット、マスターソルト、および送信者/受信者ID（セクション3.2を参照））を使用して導出するプロトコルの例を示します。新しいセキュリティコンテキスト。ランダムな入力は、「子供コンテキスト」パラメーターでクライアントとサーバー間で転送されます。両方のエンドポイントにランダム性の適切なソースがない限り、このプロトコルを使用してはなりません（MUST NOT）。
During normal requests, the ID Context of an established security context may be sent in the 'kid context', which, together with 'kid', facilitates for the server to locate a security context. Alternatively, the 'kid context' may be omitted since the ID Context is expected to be known to both client and server; see Section 5.1.
通常のリクエストでは、確立されたセキュリティコンテキストのIDコンテキストを「キッドコンテキスト」で送信できます。これは、「キッド」とともに、サーバーがセキュリティコンテキストを特定するのに役立ちます。または、IDコンテキストはクライアントとサーバーの両方に認識されることが期待されるため、「子供コンテキスト」を省略できます。セクション5.1を参照してください。
The protocol described in this section may only be needed when the mutable part of security context is lost in the client or server, e.g., when the endpoint has rebooted. The protocol may additionally be used whenever the client and server need to derive a new security context. For example, if a device is provisioned with one fixed set of input parameters (including Master Secret, Sender and Recipient Identifiers), then a randomized ID Context ensures that the security context is different for each deployment.
このセクションで説明するプロトコルは、セキュリティコンテキストの可変部分がクライアントまたはサーバーで失われた場合（エンドポイントが再起動した場合など）にのみ必要になる場合があります。このプロトコルは、クライアントとサーバーが新しいセキュリティコンテキストを導出する必要がある場合はいつでも使用できます。たとえば、デバイスに1つの固定された入力パラメーターセット（マスターシークレット、送信者、受信者の識別子を含む）がプロビジョニングされている場合、ランダムなIDコンテキストにより、展開ごとにセキュリティコンテキストが確実に異なります。
Note that the server needs to be configured to run this protocol when it is not able to retrieve an existing security context, instead of stopping processing the message as described in step 2 of Section 8.2.
サーバーは、セクション8.2のステップ2で説明されているようにメッセージの処理を停止するのではなく、既存のセキュリティコンテキストを取得できないときにこのプロトコルを実行するように構成する必要があることに注意してください。
The protocol is described below with reference to Figure 14. The client or the server may initiate the protocol, in the latter case step 1 is omitted.
プロトコルについては、図14を参照して以下で説明します。クライアントまたはサーバーがプロトコルを開始できます。後者の場合、ステップ1は省略されます。
Client Server
| |
1. Protect with | request #1 |
ID Context = ID1 |--------------------->| 2. Verify with
| kid_context = ID1 | ID Context = ID1
| |
| response #1 | Protect with
3. Verify with |<---------------------| ID Context = R2||ID1
ID Context = R2||ID1 | kid_context = R2 |
| |
Protect with | request #2 |
ID Context = R2||R3 |--------------------->| 4. Verify with
| kid_context = R2||R3 | ID Context = R2||R3
| |
| response #2 | Protect with
5. Verify with |<---------------------| ID Context = R2||R3
ID Context = R2||R3 | |
Figure 14: Protocol for Establishing a New Security Context
図14：新しいセキュリティコンテキストを確立するためのプロトコル
1. (Optional) If the client does not have a valid security context with the server, e.g., because of reboot or because this is the first time it contacts the server, then it generates a random string R1 and uses this as ID Context together with the input parameters shared with the server to derive a first security context. The client sends an OSCORE request to the server protected with the first security context, containing R1 wrapped in a CBOR bstr as 'kid context'. The request may target a special resource used for updating security contexts.
1. （オプション）クライアントがサーバーとの有効なセキュリティコンテキストを持っていない場合（再起動のため、またはサーバーに初めて接続したときなど）、ランダムな文字列R1を生成し、これをIDコンテキストとして使用します。最初のセキュリティコンテキストを取得するためにサーバーと共有される入力パラメーター。クライアントは、最初のセキュリティコンテキストで保護されたサーバーにOSCORE要求を送信します。これには、「子コンテキスト」としてCBOR bstrでラップされたR1が含まれます。リクエストは、セキュリティコンテキストの更新に使用される特別なリソースを対象とする場合があります。
2. The server receives an OSCORE request for which it does not have a valid security context, either because the client has generated a new security context ID1 = R1 or because the server has lost part of its security context, e.g., ID Context, Sender Sequence Number or Replay Window. If the server is able to verify the request (see Section 8.2) with the new derived first security context using the received ID1 (transported in 'kid context') as ID Context and the input parameters associated to the received 'kid', then the server generates a random string R2 and derives a second security context with ID Context = ID2 = R2 || ID1. The server sends a 4.01 (Unauthorized) response protected with the second security context, containing R2 wrapped in a CBOR bstr as 'kid context', and caches R2. R2 MUST NOT be reused as that may lead to reuse of key and nonce in response #1. Note that the server may receive several requests #1 associated with one security context, leading to multiple parallel protocol runs. Multiple instances of R2 may need to be cached until one of the protocol runs is completed, see Appendix B.2.1.
2. クライアントが新しいセキュリティコンテキストID1 = R1を生成したか、サーバーがセキュリティコンテキストの一部（IDコンテキスト、送信者シーケンス番号など）を失ったため、サーバーは有効なセキュリティコンテキストがないOSCORE要求を受信しましたまたはリプレイウィンドウ。サーバーが、受信したID1（「子供コンテキスト」で転送された）をIDコンテキストとして使用し、受信した「子供」に関連付けられた入力パラメーターを使用して、新しい派生最初のセキュリティコンテキストで要求（セクション8.2を参照）を検証できる場合、サーバーはランダムな文字列R2を生成し、ID Context = ID2 = R2 ||の2番目のセキュリティコンテキストを導出します。 ID1。サーバーは、2番目のセキュリティコンテキストで保護された4.01（無許可）応答を送信し、CBOR bstrに「子供コンテキスト」としてラップされたR2を含み、R2をキャッシュします。 R2を再利用してはなりません。応答＃1でキーとノンスが再利用される可能性があるためです。サーバーは、1つのセキュリティコンテキストに関連付けられた複数の要求＃1を受信し、複数の並列プロトコルの実行につながる可能性があることに注意してください。プロトコルの実行の1つが完了するまで、R2の複数のインスタンスをキャッシュする必要がある場合があります。付録B.2.1を参照してください。
3. The client receives a response with 'kid context' containing a CBOR bstr wrapping R2 to an OSCORE request it made with ID Context = ID1. The client derives a second security context using ID Context = ID2 = R2 || ID1. If the client can verify the response (see Section 8.4) using the second security context, then the client makes a request protected with a third security context derived from ID Context = ID3 = R2 || R3, where R3 is a random byte string generated by the client. The request includes R2 || R3 wrapped in a CBOR bstr as 'kid context'.
3. クライアントは、ID Context = ID1で作成されたOSCORE要求に対するR2をラップするCBOR bstrを含む「子供コンテキスト」の応答を受け取ります。クライアントは、IDコンテキスト= ID2 = R2 ||を使用して2番目のセキュリティコンテキストを導出します。 ID1。クライアントが2番目のセキュリティコンテキストを使用して応答（8.4を参照）を検証できる場合、クライアントはIDコンテキスト= ID3 = R2 ||から派生した3番目のセキュリティコンテキストで保護された要求を作成します。 R3。R3はクライアントによって生成されたランダムなバイト文字列です。リクエストにはR2が含まれます|| R3は「子供コンテキスト」としてCBOR bstrにラップされています。
4. If the server receives a request with 'kid context' containing a CBOR bstr wrapping ID3, where the first part of ID3 is identical to an R2 sent in a previous response #1, which it has not received before, then the server derives a third security context with ID Context = ID3. The server MUST NOT accept replayed request #2 messages. If the server can verify the request (see Section 8.2) with the third security context, then the server marks the third security context to be used with this client and removes all instances of R2 associated to this security context from the cache. This security context replaces the previous security context with the client, and the first and the second security contexts are deleted. The server responds using the same security context as in the request.
4. サーバーが、ID 3の最初の部分が以前に受信していない以前の応答＃1で送信されたR2と同じである、CBOR bstrラッピングID3を含む「キッドコンテキスト」を含むリクエストを受信した場合、サーバーは3番目を取得します。 IDコンテキスト= ID3のセキュリティコンテキスト。サーバーは、再生された要求＃2メッセージを受け入れてはなりません（MUST NOT）。サーバーが3番目のセキュリティコンテキストで要求を検証できる場合（セクション8.2を参照）、サーバーはこのクライアントで使用する3番目のセキュリティコンテキストをマークし、このセキュリティコンテキストに関連付けられているR2のすべてのインスタンスをキャッシュから削除します。このセキュリティコンテキストは、以前のセキュリティコンテキストをクライアントに置き換え、最初と2番目のセキュリティコンテキストは削除されます。サーバーは、リクエストと同じセキュリティコンテキストを使用して応答します。
5. If the client receives a response to the request with the third security context and the response verifies (see Section 8.4), then the client marks the third security context to be used with this server. This security context replaces the previous security context with the server, and the first and second security contexts are deleted.
5. クライアントが3番目のセキュリティコンテキストで要求への応答を受信し、その応答が検証された場合（セクション8.4を参照）、クライアントはこのサーバーで使用する3番目のセキュリティコンテキストをマークします。このセキュリティコンテキストは、以前のセキュリティコンテキストをサーバーに置き換え、最初と2番目のセキュリティコンテキストは削除されます。
If verification fails in any step, the endpoint stops processing that message.
いずれかのステップで検証が失敗した場合、エンドポイントはそのメッセージの処理を停止します。
The length of the nonces R1, R2, and R3 is application specific. The application needs to set the length of each nonce such that the probability of its value being repeated is negligible; typically, at least 8 bytes long. Since R2 may be generated as the result of a replayed request #1, the probability for collision of R2s is impacted by the birthday paradox. For example, setting the length of R2 to 8 bytes results in an average collision after 2^32 response #1 messages, which should not be an issue for a constrained server handling on the order of one request per second.
ナンスR1、R2、およびR3の長さはアプリケーション固有です。アプリケーションは、その値が繰り返される確率が無視できるように各ナンスの長さを設定する必要があります。通常、少なくとも8バイトの長さ。 R2はリプレイされた要求＃1の結果として生成される可能性があるため、R2の衝突の確率は誕生日のパラドックスの影響を受けます。たとえば、R2の長さを8バイトに設定すると、2 ^ 32応答＃1メッセージの後の平均衝突が発生します。これは、1秒あたり1要求のオーダーの制約付きサーバー処理では問題になりません。
Request #2 can be an ordinary request. The server performs the action of the request and sends response #2 after having successfully completed the operations related to the security context in step 4. The client acts on response #2 after having successfully completed step 5.
リクエスト＃2は通常のリクエストです。サーバーは、ステップ4でセキュリティコンテキストに関連する操作を正常に完了した後、要求のアクションを実行し、応答＃2を送信します。クライアントは、ステップ5を正常に完了した後、応答＃2を処理します。
When sending request #2, the client is assured that the Sender Key (derived with the random value R3) has never been used before. When receiving response #2, the client is assured that the response (protected with a key derived from the random value R3 and the Master Secret) was created by the server in response to request #2.
要求＃2を送信するとき、クライアントは（ランダムな値R3で導出された）送信者キーが以前に使用されたことがないことが保証されます。応答＃2を受信すると、クライアントは、応答（ランダムな値R3とマスターシークレットから導出されたキーで保護されている）が要求＃2への応答としてサーバーによって作成されたことを確認します。
Similarly, when receiving request #2, the server is assured that the request (protected with a key derived from the random value R2 and the Master Secret) was created by the client in response to response #1. When sending response #2, the server is assured that the Sender Key (derived with the random value R2) has never been used before.
同様に、要求＃2を受信すると、サーバーは、要求（ランダムな値R2とマスターシークレットから導出されたキーで保護されている）が応答＃1に応答してクライアントによって作成されたことを保証します。応答＃2を送信するとき、サーバーは（ランダムな値R2で導出された）送信者キーが以前に使用されたことがないことが保証されます。
Implementation and denial-of-service considerations are made in Appendix B.2.1 and Appendix B.2.2.
実装およびサービス拒否の考慮事項については、付録B.2.1および付録B.2.2を参照してください。
This section add some implementation considerations to the protocol described in the previous section.
このセクションでは、前のセクションで説明したプロトコルに実装に関する考慮事項をいくつか追加します。
The server may only have space for a few security contexts or only be able to handle a few protocol runs in parallel. The server may legitimately receive multiple request #1 messages using the same immutable security context, e.g., because of packet loss. Replays of old request #1 messages could be difficult for the server to distinguish from legitimate. The server needs to handle the case when the maximum number of cached R2s is reached. If the server receives a request #1 and is not capable of executing it then it may respond with an unprotected 5.03 (Service Unavailable) error message. The server may clear up state from protocol runs that never complete, e.g., set a timer when caching R2, and remove R2 and the associated security contexts from the cache at timeout. Additionally, state information can be flushed at reboot.
サーバーには、いくつかのセキュリティコンテキスト用のスペースしかない場合や、並行して実行されるいくつかのプロトコルのみを処理できる場合があります。サーバーは、たとえばパケット損失が原因で、同じ不変のセキュリティコンテキストを使用して複数のリクエスト＃1メッセージを合法的に受信する場合があります。古い要求＃1メッセージの再生は、サーバーが正当なものと区別するのが難しい場合があります。キャッシュされたR2の最大数に達した場合、サーバーはケースを処理する必要があります。サーバーがリクエスト＃1を受信し、それを実行できない場合は、保護されていない5.03（Service Unavailable）エラーメッセージで応答することがあります。サーバーは、R2をキャッシュするときにタイマーを設定するなど、完了しないプロトコル実行から状態をクリアし、タイムアウト時にR2と関連するセキュリティコンテキストをキャッシュから削除する場合があります。さらに、状態情報は再起動時にフラッシュすることができます。
As an alternative to caching R2, the server could generate R2 in such a way that it can be sent (in response #1) and verified (at reception of request #2) as the value of R2 it had generated. Such a procedure MUST NOT lead to the server accepting replayed request #2 messages. One construction described in the following is based on using a secret random HMAC key K_HMAC per set of immutable security context parameters associated with a client. This construction allows the server to handle verification of R2 in response #2 at the cost of storing the K_HMAC keys and a slightly larger message overhead in response #1. Steps below refer to modifications to Appendix B.2:
R2をキャッシュする代わりに、サーバーはR2を生成して（応答＃1で）送信し、生成したR2の値として（要求＃2の受信時に）検証できます。そのような手順は、サーバーが再生された要求＃2メッセージを受け入れるようにしてはなりません。以下で説明する1つの構成は、クライアントに関連付けられた不変のセキュリティコンテキストパラメータのセットごとに秘密のランダムHMACキーK_HMACを使用することに基づいています。この構成により、サーバーは、K_HMACキーを格納する代わりに、応答＃2でR2の検証を処理し、応答＃1でメッセージオーバーヘッドがわずかに大きくなります。以下の手順は、付録B.2への変更を示しています。
o In step 2, R2 is generated in the following way. First, the server generates a random K_HMAC (unless it already has one associated with the security context), then it sets R2 = S2 || HMAC(K_HMAC, S2) where S2 is a random byte string, and the HMAC is truncated to 8 bytes. K_HMAC may have an expiration time, after which it is erased. Note that neither R2, S2, nor the derived first and second security contexts need to be cached.
o ステップ2では、R2は次の方法で生成されます。最初に、サーバーはランダムなK_HMACを生成し（セキュリティコンテキストに関連付けられたものがない場合）、次にR2 = S2 ||を設定します。 HMAC（K_HMAC、S2）ここで、S2はランダムなバイト文字列であり、HMACは8バイトに切り捨てられます。 K_HMACには有効期限があり、その後消去されます。 R2、S2、および派生した1番目と2番目のセキュリティコンテキストはキャッシュする必要がないことに注意してください。
o In step 4, instead of verifying that R2 coincides with a cached value, the server looks up the associated K_HMAC and verifies the truncated HMAC, and the processing continues accordingly depending on verification success or failure. K_HMAC is used until a run of the protocol is completed (after verification of request #2), or until it expires (whatever comes first), after which K_HMAC is erased. (The latter corresponds to removing the cached values of R2 in step 4 of Appendix B.2 and makes the server reject replays of request #2.)
o ステップ4で、R2がキャッシュされた値と一致することを確認する代わりに、サーバーは関連するK_HMACを検索して切り捨てられたHMACを確認し、確認の成功または失敗に応じて処理が続行されます。 K_HMACは、プロトコルの実行が完了するまで（リクエスト＃2の検証後）、または期限が切れるまで（最初に来るものは何でも）使用され、その後K_HMACは消去されます。 （後者は、付録B.2のステップ4でR2のキャッシュされた値を削除することに対応し、サーバーに要求＃2のリプレイを拒否させます。）
The length of S2 is application specific and the probability for collision of S2s is impacted by the birthday paradox. For example, setting the length of S2 to 8 bytes results in an average collision after 2^32 response #1 messages, which should not be an issue for a constrained server handling on the order of one request per second.
S2の長さはアプリケーション固有であり、S2の衝突の確率は誕生日のパラドックスの影響を受けます。たとえば、S2の長さを8バイトに設定すると、2 ^ 32応答＃1メッセージの後で平均衝突が発生します。これは、1秒あたり1要求のオーダーで処理される制約付きサーバーでは問題になりません。
Two endpoints sharing a security context may accidentally initiate two instances of the protocol at the same time, each in the role of client, e.g., after a power outage affecting both endpoints. Such a race condition could potentially lead to both protocols failing, and both endpoints repeatedly reinitiating the protocol without converging. Both endpoints can detect this situation, and it can be handled in different ways. The requests could potentially be more spread out in time, for example, by only initiating this protocol when the endpoint actually needs to make a request, potentially adding a random delay before requests immediately after reboot or if such parallel protocol runs are detected.
セキュリティコンテキストを共有する2つのエンドポイントが誤って同時に2つのプロトコルのインスタンスを開始する可能性があります。たとえば、両方のエンドポイントに影響する停電の後などに、それぞれがクライアントの役割を果たします。このような競合状態により、両方のプロトコルが失敗し、両方のエンドポイントが収束せずにプロトコルを繰り返し再起動する可能性があります。両方のエンドポイントでこの状況を検出でき、さまざまな方法で処理できます。たとえば、エンドポイントが実際に要求を行う必要がある場合にのみこのプロトコルを開始し、再起動直後またはそのような並列プロトコルの実行が検出された場合に要求の前にランダムな遅延を追加することにより、要求が時間内に広がる可能性があります。
An on-path attacker may inject a message causing the endpoint to process verification of the message. A message crafted without access to the Master Secret will fail to verify.
パス上の攻撃者がメッセージを挿入し、エンドポイントにメッセージの検証を処理させる可能性があります。マスターシークレットにアクセスせずに作成されたメッセージは、検証に失敗します。
Replaying an old request with a value of 'kid_context' that the server does not recognize could trigger the protocol. This causes the server to generate the first and second security context and send a response. But if the client did not expect a response, it will be discarded. This may still result in a denial-of-service attack against the server, e.g., because of not being able to manage the state associated with many parallel protocol runs, and it may prevent legitimate client requests. Implementation alternatives with less data caching per request #1 message are favorable in this respect; see Appendix B.2.1.
サーバーが認識しない「kid_context」の値を持つ古いリクエストを再生すると、プロトコルがトリガーされる可能性があります。これにより、サーバーは最初と2番目のセキュリティコンテキストを生成し、応答を送信します。ただし、クライアントが応答を期待していなかった場合、その応答は破棄されます。これは、たとえば、多くの並列プロトコルの実行に関連する状態を管理できないために、サーバーに対するサービス拒否攻撃を引き起こす可能性があり、正当なクライアント要求を妨げる可能性があります。この点で、リクエスト＃1メッセージあたりのデータキャッシングが少ない実装の選択肢が適しています。付録B.2.1を参照してください。
Replaying response #1 in response to some request other than request #1 will fail to verify, since response #1 is associated to request #1, through the dependencies of ID Contexts and the Partial IV of request #1 included in the external_aad of response #1.
リクエスト＃1以外のリクエストに応答してレスポンス＃1を再生すると、IDコンテキストの依存関係とレスポンスのexternal_aadに含まれるリクエスト＃1のパーシャルIVを介してリクエスト＃1に関連付けられているため、検証に失敗します。 ＃1。
If request #2 has already been well received, then the server has a valid security context, so a replay of request #2 is handled by the normal replay protection mechanism. Similarly, if response #2 has already been received, a replay of response #2 to some other request from the client will fail by the normal verification of binding of response to request.
要求＃2がすでに十分に受信されている場合、サーバーには有効なセキュリティコンテキストがあるため、要求＃2の再生は通常の再生保護メカニズムによって処理されます。同様に、応答＃2がすでに受信されている場合、クライアントからの他の要求に対する応答＃2の再生は、要求に対する応答のバインディングの通常の検証によって失敗します。
This appendix includes the test vectors for different examples of CoAP messages using OSCORE. Given a set of inputs, OSCORE defines how to set up the Security Context in both the client and the server.
この付録には、OSCOREを使用したCoAPメッセージのさまざまな例のテストベクタが含まれています。入力のセットが与えられると、OSCOREはクライアントとサーバーの両方でセキュリティコンテキストを設定する方法を定義します。
Note that in Appendix C.4 and all following test vectors the Token and the Message ID of the OSCORE-protected CoAP messages are set to the same value of the unprotected CoAP message to help the reader with comparisons.
付録C.4および以下のすべてのテストベクタでは、OSCOREで保護されたCoAPメッセージのトークンとメッセージIDが、保護されていないCoAPメッセージと同じ値に設定されているため、読みやすくなっています。
In this test vector, a Master Salt of 8 bytes is used. The default values are used for AEAD Algorithm and HKDF.
このテストベクタでは、8バイトのマスターソルトが使用されています。デフォルト値は、AEADアルゴリズムとHKDFに使用されます。
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o マスターシークレット：0x0102030405060708090a0b0c0d0e0f10（16バイト）
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o マスターソルト：0x9e7ca92223786340（8バイト）
o Sender ID: 0x (0 byte) o Recipient ID: 0x01 (1 byte)
o送信者ID：0x（0バイト）o受信者ID：0x01（1バイト）
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x8540f60a634b657910 (9 bytes)
o 情報（送信者キー用）：0x8540f60a634b657910（9バイト）
o info (for Recipient Key): 0x854101f60a634b657910 (10 bytes)
o 情報（受信者キー用）：0x854101f60a634b657910（10バイト）
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o info（Common IVの場合）：0x8540f60a6249560d（8バイト）
Outputs:
出力：
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o 送信者キー：0xf0910ed7295e6ad4b54fc793154302ff（16バイト）
o Recipient Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 受信者キー：0xffb14e093c94c9cac9471648b4f98710（16バイト）
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 共通IV：0x4622d4dd6d944168eefb54987c（13バイト）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しい部分IV（送信者と受信者の両方）から：
o sender nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 送信者ノンス：0x4622d4dd6d944168eefb54987c（13バイト）
o recipient nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
o 受信者ノンス：0x4722d4dd6d944169eefb54987c（13バイト）
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o マスターシークレット：0x0102030405060708090a0b0c0d0e0f10（16バイト）
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o マスターソルト：0x9e7ca92223786340（8バイト）
o Sender ID: 0x01 (1 byte)
o 送信者ID：0x01（1バイト）
o Recipient ID: 0x (0 byte)
o 受信者ID：0x（0バイト）
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
o 情報（送信者キー用）：0x854101f60a634b657910（10バイト）
o info (for Recipient Key): 0x8540f60a634b657910 (9 bytes)
o 情報（受信者キー用）：0x8540f60a634b657910（9バイト）
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o info（Common IVの場合）：0x8540f60a6249560d（8バイト）
Outputs:
出力：
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o Recipient Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o送信者キー：0xffb14e093c94c9cac9471648b4f98710（16バイト）o受信者キー：0xf0910ed7295e6ad4b54fc793154302ff（16バイト）
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 共通IV：0x4622d4dd6d944168eefb54987c（13バイト）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しい部分IV（送信者と受信者の両方）から：
o sender nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
o 送信者ノンス：0x4722d4dd6d944169eefb54987c（13バイト）
o recipient nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 受信者ノンス：0x4622d4dd6d944168eefb54987c（13バイト）
In this test vector, the default values are used for AEAD Algorithm, HKDF, and Master Salt.
このテストベクトルでは、AEADアルゴリズム、HKDF、およびマスターソルトにデフォルト値が使用されます。
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o マスターシークレット：0x0102030405060708090a0b0c0d0e0f10（16バイト）
o Sender ID: 0x00 (1 byte)
o 送信者ID：0x00（1バイト）
o Recipient ID: 0x01 (1 byte)
o 受信者ID：0x01（1バイト）
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x854100f60a634b657910 (10 bytes)
o 情報（送信者キー用）：0x854100f60a634b657910（10バイト）
o info (for Recipient Key): 0x854101f60a634b657910 (10 bytes)
o 情報（受信者キー用）：0x854101f60a634b657910（10バイト）
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o info（Common IVの場合）：0x8540f60a6249560d（8バイト）
Outputs:
出力：
o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o 送信者キー：0x321b26943253c7ffb6003b0b64d74041（16バイト）
o Recipient Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes)
o 受信者キー：0xe57b5635815177cd679ab4bcec9d7dda（16バイト）
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
o 共通IV：0xbe35ae297d2dace910c52e99f9（13バイト）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しい部分IV（送信者と受信者の両方）から：
o sender nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
o 送信者ノンス：0xbf35ae297d2dace910c52e99f9（13バイト）
o recipient nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
o 受信者ノンス：0xbf35ae297d2dace810c52e99f9（13バイト）
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o マスターシークレット：0x0102030405060708090a0b0c0d0e0f10（16バイト）
o Sender ID: 0x01 (1 byte)
o 送信者ID：0x01（1バイト）
o Recipient ID: 0x00 (1 byte)
o 受信者ID：0x00（1バイト）
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
o 情報（送信者キー用）：0x854101f60a634b657910（10バイト）
o info (for Recipient Key): 0x854100f60a634b657910 (10 bytes)
o 情報（受信者キー用）：0x854100f60a634b657910（10バイト）
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o info（Common IVの場合）：0x8540f60a6249560d（8バイト）
Outputs:
出力：
o Sender Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes)
o 送信者キー：0xe57b5635815177cd679ab4bcec9d7dda（16バイト）
o Recipient Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o 受信者キー：0x321b26943253c7ffb6003b0b64d74041（16バイト）
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
o 共通IV：0xbe35ae297d2dace910c52e99f9（13バイト）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しい部分IV（送信者と受信者の両方）から：
o sender nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
o 送信者ノンス：0xbf35ae297d2dace810c52e99f9（13バイト）
o recipient nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
o 受信者ノンス：0xbf35ae297d2dace910c52e99f9（13バイト）
In this test vector, a Master Salt of 8 bytes and an ID Context of 8 bytes are used. The default values are used for AEAD Algorithm and HKDF.
このテストベクトルでは、8バイトのマスターソルトと8バイトのIDコンテキストが使用されます。デフォルト値は、AEADアルゴリズムとHKDFに使用されます。
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o マスターシークレット：0x0102030405060708090a0b0c0d0e0f10（16バイト）
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o マスターソルト：0x9e7ca92223786340（8バイト）
o Sender ID: 0x (0 byte) o Recipient ID: 0x01 (1 byte)
o送信者ID：0x（0バイト）o受信者ID：0x01（1バイト）
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
o IDコンテキスト：0x37cbf3210017a2d3（8バイト）
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x85404837cbf3210017a2d30a634b657910 (17 bytes)
o 情報（送信者キー用）：0x85404837cbf3210017a2d30a634b657910（17バイト）
o info (for Recipient Key): 0x8541014837cbf3210017a2d30a634b657910 (18 bytes)
o 情報（受信者キー用）：0x8541014837cbf3210017a2d30a634b657910（18バイト）
o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16 bytes)
o 情報（共通IVの場合）：0x85404837cbf3210017a2d30a6249560d（16バイト）
Outputs:
出力：
o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o 送信者キー：0xaf2a1300a5e95788b356336eeecd2b92（16バイト）
o Recipient Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o 受信者キー：0xe39a0c7c77b43f03b4b39ab9a268699f（16バイト）
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o 共通IV：0x2ca58fb85ff1b81c0b7181b85e（13バイト）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しい部分IV（送信者と受信者の両方）から：
o sender nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o 送信者ノンス：0x2ca58fb85ff1b81c0b7181b85e（13バイト）
o recipient nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o 受信者ノンス：0x2da58fb85ff1b81d0b7181b85e（13バイト）
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o マスターシークレット：0x0102030405060708090a0b0c0d0e0f10（16バイト）
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o マスターソルト：0x9e7ca92223786340（8バイト）
o Sender ID: 0x01 (1 byte)
o 送信者ID：0x01（1バイト）
o Recipient ID: 0x (0 byte)
o 受信者ID：0x（0バイト）
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
o IDコンテキスト：0x37cbf3210017a2d3（8バイト）
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x8541014837cbf3210017a2d30a634b657910 (18 bytes)
o 情報（送信者キー用）：0x8541014837cbf3210017a2d30a634b657910（18バイト）
o info (for Recipient Key): 0x85404837cbf3210017a2d30a634b657910 (17 bytes)
o 情報（受信者キー用）：0x85404837cbf3210017a2d30a634b657910（17バイト）
o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16 bytes)
o 情報（共通IVの場合）：0x85404837cbf3210017a2d30a6249560d（16バイト）
Outputs:
出力：
o Sender Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o 送信者キー：0xe39a0c7c77b43f03b4b39ab9a268699f（16バイト）
o Recipient Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o 受信者キー：0xaf2a1300a5e95788b356336eeecd2b92（16バイト）
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o 共通IV：0x2ca58fb85ff1b81c0b7181b85e（13バイト）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しい部分IV（送信者と受信者の両方）から：
o sender nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o 送信者ノンス：0x2da58fb85ff1b81d0b7181b85e（13バイト）
o recipient nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o 受信者ノンス：0x2ca58fb85ff1b81c0b7181b85e（13バイト）
This section contains a test vector for an OSCORE-protected CoAP GET request using the security context derived in Appendix C.1. The unprotected request only contains the Uri-Path and Uri-Host options.
このセクションには、付録C.1で派生したセキュリティコンテキストを使用した、OSCOREで保護されたCoAP GETリクエストのテストベクタが含まれています。保護されていない要求には、Uri-PathおよびUri-Hostオプションのみが含まれます。
Unprotected CoAP request: 0x44015d1f00003974396c6f63616c686f737483747631 (22 bytes)
保護されていないCoAP要求：0x44015d1f00003974396c6f63616c686f737483747631（22バイト）
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEADアルゴリズム：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256
o 鍵導出関数：HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 共通IV：0x4622d4dd6d944168eefb54987c（13バイト）
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x (0 byte)
o 送信者ID：0x（0バイト）
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o 送信者キー：0xf0910ed7295e6ad4b54fc793154302ff（16バイト）
o Sender Sequence Number: 20 The following COSE and cryptographic parameters are derived:
o送信者シーケンス番号：20次のCOSEおよび暗号化パラメーターが導出されます。
o Partial IV: 0x14 (1 byte)
o 部分IV：0x14（1バイト）
o kid: 0x (0 byte)
o 子供：0x（0バイト）
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_array：0x8501810a40411440（8バイト）
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD：0x8368456e63727970743040488501810a40411440（20バイト）
o plaintext: 0x01b3747631 (5 bytes)
o 平文：0x01b3747631（5バイト）
o encryption key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o 暗号化キー：0xf0910ed7295e6ad4b54fc793154302ff（16バイト）
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
o nonce：0x4622d4dd6d944168eefb549868（13バイト）
From the previous parameter, the following is derived:
前のパラメーターから、以下が導出されます。
o OSCORE option value: 0x0914 (2 bytes)
o OSCOREオプション値：0x0914（2バイト）
o ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)
o 暗号文：0x612f1092f1776f1c1668b3825e（13バイト）
From there:
そこから：
o Protected CoAP request (OSCORE message): 0x44025d1f00003974396c6f6 3616c686f7374620914ff612f1092f1776f1c1668b3825e (35 bytes)
o 保護されたCoAP要求（OSCOREメッセージ）：0x44025d1f00003974396c6f6 3616c686f7374620914ff612f1092f1776f1c1668b3825e（35バイト）
This section contains a test vector for an OSCORE-protected CoAP GET request using the security context derived in Appendix C.2. The unprotected request only contains the Uri-Path and Uri-Host options.
このセクションには、付録C.2で派生したセキュリティコンテキストを使用した、OSCOREで保護されたCoAP GETリクエストのテストベクタが含まれています。保護されていない要求には、Uri-PathおよびUri-Hostオプションのみが含まれます。
Unprotected CoAP request: 0x440171c30000b932396c6f63616c686f737483747631 (22 bytes)
保護されていないCoAP要求：0x440171c30000b932396c6f63616c686f737483747631（22バイト）
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEADアルゴリズム：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256
o 鍵導出関数：HKDF SHA-256
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
o 共通IV：0xbe35ae297d2dace910c52e99f9（13バイト）
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x00 (1 bytes) o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o送信者ID：0x00（1バイト）o送信者キー：0x321b26943253c7ffb6003b0b64d74041（16バイト）
o Sender Sequence Number: 20
o 送信者シーケンス番号：20
The following COSE and cryptographic parameters are derived:
次のCOSEおよび暗号化パラメーターが導出されます。
o Partial IV: 0x14 (1 byte)
o 部分IV：0x14（1バイト）
o kid: 0x00 (1 byte)
o kid：0x00（1バイト）
o aad_array: 0x8501810a4100411440 (9 bytes)
o aad_array：0x8501810a4100411440（9バイト）
o AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes)
o AAD：0x8368456e63727970743040498501810a4100411440（21バイト）
o plaintext: 0x01b3747631 (5 bytes)
o 平文：0x01b3747631（5バイト）
o encryption key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o 暗号化キー：0x321b26943253c7ffb6003b0b64d74041（16バイト）
o nonce: 0xbf35ae297d2dace910c52e99ed (13 bytes)
o nonce：0xbf35ae297d2dace910c52e99ed（13バイト）
From the previous parameter, the following is derived:
前のパラメーターから、以下が導出されます。
o OSCORE option value: 0x091400 (3 bytes)
o OSCOREオプション値：0x091400（3バイト）
o ciphertext: 0x4ed339a5a379b0b8bc731fffb0 (13 bytes)
o 暗号文：0x4ed339a5a379b0b8bc731fffb0（13バイト）
From there:
そこから：
o Protected CoAP request (OSCORE message): 0x440271c30000b932396c6f6 3616c686f737463091400ff4ed339a5a379b0b8bc731fffb0 (36 bytes)
o 保護されたCoAP要求（OSCOREメッセージ）：0x440271c30000b932396c6f6 3616c686f737463091400ff4ed339a5a379b0b8bc731fffb0（36バイト）
This section contains a test vector for an OSCORE-protected CoAP GET request for an application that sets the ID Context and requires it to be sent in the request, so 'kid context' is present in the protected message. This test vector uses the security context derived in Appendix C.3. The unprotected request only contains the Uri-Path and Uri-Host options.
このセクションには、IDコンテキストを設定し、それをリクエストで送信する必要があるアプリケーションのOSCOREで保護されたCoAP GETリクエストのテストベクタが含まれているため、保護されたメッセージに「子供コンテキスト」が存在します。このテストベクトルは、付録C.3で派生したセキュリティコンテキストを使用します。保護されていない要求には、Uri-PathおよびUri-Hostオプションのみが含まれます。
Unprotected CoAP request: 0x44012f8eef9bbf7a396c6f63616c686f737483747631 (22 bytes)
保護されていないCoAP要求：0x44012f8eef9bbf7a396c6f63616c686f737483747631（22バイト）
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEADアルゴリズム：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256 o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o鍵導出関数：HKDF SHA-256 o共通IV：0x2ca58fb85ff1b81c0b7181b85e（13バイト）
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
o IDコンテキスト：0x37cbf3210017a2d3（8バイト）
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x (0 bytes)
o 送信者ID：0x（0バイト）
o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o 送信者キー：0xaf2a1300a5e95788b356336eeecd2b92（16バイト）
o Sender Sequence Number: 20
o 送信者シーケンス番号：20
The following COSE and cryptographic parameters are derived:
次のCOSEおよび暗号化パラメーターが導出されます。
o Partial IV: 0x14 (1 byte)
o 部分IV：0x14（1バイト）
o kid: 0x (0 byte)
o 子供：0x（0バイト）
o kid context: 0x37cbf3210017a2d3 (8 bytes)
o キッドコンテキスト：0x37cbf3210017a2d3（8バイト）
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_array：0x8501810a40411440（8バイト）
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD：0x8368456e63727970743040488501810a40411440（20バイト）
o plaintext: 0x01b3747631 (5 bytes)
o 平文：0x01b3747631（5バイト）
o encryption key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o 暗号化キー：0xaf2a1300a5e95788b356336eeecd2b92（16バイト）
o nonce: 0x2ca58fb85ff1b81c0b7181b84a (13 bytes)
o nonce：0x2ca58fb85ff1b81c0b7181b84a（13バイト）
From the previous parameter, the following is derived:
前のパラメーターから、以下が導出されます。
o OSCORE option value: 0x19140837cbf3210017a2d3 (11 bytes)
o OSCOREオプション値：0x19140837cbf3210017a2d3（11バイト）
o ciphertext: 0x72cd7273fd331ac45cffbe55c3 (13 bytes)
o 暗号文：0x72cd7273fd331ac45cffbe55c3（13バイト）
From there:
そこから：
o Protected CoAP request (OSCORE message): 0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff 72cd7273fd331ac45cffbe55c3 (44 bytes)
o 保護されたCoAP要求（OSCOREメッセージ）：0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff 72cd7273fd331ac45cffbe55c3（44バイト）
This section contains a test vector for an OSCORE-protected 2.05 (Content) response to the request in Appendix C.4. The unprotected response has payload "Hello World!" and no options. The protected response does not contain a 'kid' nor a Partial IV. Note that some parameters are derived from the request.
このセクションには、付録C.4の要求に対するOSCOREで保護された2.05（コンテンツ）応答のテストベクタが含まれています。保護されていない応答のペイロードは「Hello World！」です。オプションはありません。保護された応答には、「子供」もパーシャルIVも含まれていません。一部のパラメータはリクエストから取得されることに注意してください。
Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes)
保護されていないCoAP応答：0x64455d1f00003974ff48656c6c6f20576f726c6421（21バイト）
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEADアルゴリズム：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256
o 鍵導出関数：HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 共通IV：0x4622d4dd6d944168eefb54987c（13バイト）
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x01 (1 byte)
o 送信者ID：0x01（1バイト）
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 送信者キー：0xffb14e093c94c9cac9471648b4f98710（16バイト）
o Sender Sequence Number: 0
o 送信者シーケンス番号：0
The following COSE and cryptographic parameters are derived:
次のCOSEおよび暗号化パラメーターが導出されます。
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_array：0x8501810a40411440（8バイト）
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD：0x8368456e63727970743040488501810a40411440（20バイト）
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o 平文：0x45ff48656c6c6f20576f726c6421（14バイト）
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 暗号化キー：0xffb14e093c94c9cac9471648b4f98710（16バイト）
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
o nonce：0x4622d4dd6d944168eefb549868（13バイト）
From the previous parameter, the following is derived:
前のパラメーターから、以下が導出されます。
o OSCORE option value: 0x (0 bytes)
o OSCOREオプション値：0x（0バイト）
o ciphertext: 0xdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (22 bytes)
o 暗号文：0xdbaad1e9a7e7b2a813d3c31524378303cdafae119106（22バイト）
From there:
そこから：
o Protected CoAP response (OSCORE message): 0x64445d1f0000397490ffdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (32 bytes)
o 保護されたCoAP応答（OSCOREメッセージ）：0x64445d1f0000397490ffdbaad1e9a7e7b2a813d3c31524378303cdafae119106（32バイト）
This section contains a test vector for an OSCORE protected 2.05 (Content) response to the request in Appendix C.4. The unprotected response has payload "Hello World!" and no options. The protected response does not contain a 'kid', but contains a Partial IV. Note that some parameters are derived from the request.
このセクションには、付録C.4の要求に対するOSCORE保護2.05（コンテンツ）応答のテストベクタが含まれています。保護されていない応答のペイロードは「Hello World！」です。オプションはありません。保護された応答には「子供」は含まれませんが、部分IVが含まれます。一部のパラメータはリクエストから取得されることに注意してください。
Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes)
保護されていないCoAP応答：0x64455d1f00003974ff48656c6c6f20576f726c6421（21バイト）
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEADアルゴリズム：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256
o 鍵導出関数：HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 共通IV：0x4622d4dd6d944168eefb54987c（13バイト）
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x01 (1 byte)
o 送信者ID：0x01（1バイト）
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 送信者キー：0xffb14e093c94c9cac9471648b4f98710（16バイト）
o Sender Sequence Number: 0
o 送信者シーケンス番号：0
The following COSE and cryptographic parameters are derived:
次のCOSEおよび暗号化パラメーターが導出されます。
o Partial IV: 0x00 (1 byte)
o 部分IV：0x00（1バイト）
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_array：0x8501810a40411440（8バイト）
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD：0x8368456e63727970743040488501810a40411440（20バイト）
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o 平文：0x45ff48656c6c6f20576f726c6421（14バイト）
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 暗号化キー：0xffb14e093c94c9cac9471648b4f98710（16バイト）
o nonce: 0x4722d4dd6d944169eefb54987c (13 bytes) From the previous parameter, the following is derived:
o nonce：0x4722d4dd6d944169eefb54987c（13バイト）前のパラメーターから、以下が導出されます。
o OSCORE option value: 0x0100 (2 bytes)
o OSCOREオプション値：0x0100（2バイト）
o ciphertext: 0x4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (22 bytes)
o 暗号文：0x4d4c13669384b67354b2b6175ff4b8658c666a6cf88e（22バイト）
From there:
そこから：
o Protected CoAP response (OSCORE message): 0x64445d1f00003974920100 ff4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (34 bytes)
o 保護されたCoAP応答（OSCOREメッセージ）：0x64445d1f00003974920100 ff4d4c13669384b67354b2b6175ff4b8658c666a6cf88e（34バイト）
This section describes the threat model using the terms of [RFC3552].
このセクションでは、[RFC3552]の用語を使用して脅威モデルについて説明します。
It is assumed that the endpoints running OSCORE have not themselves been compromised. The attacker is assumed to have control of the CoAP channel over which the endpoints communicate, including intermediary nodes. The attacker is capable of launching any passive or active on-path or off-path attacks; including eavesdropping, traffic analysis, spoofing, insertion, modification, deletion, delay, replay, man-in-the-middle, and denial-of-service attacks. This means that the attacker can read any CoAP message on the network and undetectably remove, change, or inject forged messages onto the wire.
OSCOREを実行しているエンドポイント自体は侵害されていないと想定されています。攻撃者は、中間ノードを含め、エンドポイントが通信するCoAPチャネルを制御していると想定されます。攻撃者は、パッシブまたはアクティブなパス上またはパス外の攻撃を開始することができます。盗聴、トラフィック分析、スプーフィング、挿入、変更、削除、遅延、再生、中間者攻撃、サービス拒否攻撃など。これは、攻撃者がネットワーク上の任意のCoAPメッセージを読み取り、偽造されたメッセージを検出できないほど削除、変更、または回線に注入できることを意味します。
OSCORE targets the protection of the CoAP request/response layer (Section 2 of [RFC7252]) between the endpoints, including the CoAP Payload, Code, Uri-Path/Uri-Query, and the other Class E option instances (Section 4.1).
OSCOREは、CoAPペイロード、コード、Uri-Path / Uri-Query、およびその他のクラスEオプションインスタンス（セクション4.1）を含む、エンドポイント間のCoAPリクエスト/レスポンスレイヤー（[RFC7252]のセクション2）の保護を対象としています。
OSCORE does not protect the CoAP messaging layer (Section 2 of [RFC7252]) or other lower layers involved in routing and transporting the CoAP requests and responses.
OSCOREは、CoAPメッセージングレイヤー（[RFC7252]のセクション2）またはCoAP要求と応答のルーティングとトランスポートに関与するその他の下位レイヤーを保護しません。
Additionally, OSCORE does not protect Class U option instances (Section 4.1), as these are used to support CoAP forward proxy operations (see Section 5.7.2 of [RFC7252]). The supported proxies (forwarding, cross-protocol, e.g., CoAP to CoAP-mappable protocols such as HTTP) must be able to change certain Class U options (by instruction from the Client), resulting in the CoAP request being redirected to the server. Changes caused by the proxy may result in the request not reaching the server or reaching the wrong server. For cross-protocol proxies, mappings are done on the Outer part of the message so these protocols are essentially used as transport. Manipulation of these options may thus impact whether the protected message reaches or does not reach the destination endpoint.
さらに、OSCOREはクラスUオプションインスタンス（セクション4.1）を保護しません。これらはCoAPフォワードプロキシ操作をサポートするために使用されるためです（[RFC7252]のセクション5.7.2を参照）。サポートされているプロキシ（転送、クロスプロトコル、たとえばCoAPからHTTPなどのCoAPマッピング可能なプロトコル）は、特定のクラスUオプションを（クライアントからの指示によって）変更できる必要があり、その結果、CoAP要求がサーバーにリダイレクトされます。プロキシによって引き起こされた変更により、リクエストがサーバーに到達しないか、間違ったサーバーに到達する可能性があります。クロスプロトコルプロキシの場合、マッピングはメッセージの外部部分で行われるため、これらのプロトコルは本質的にトランスポートとして使用されます。したがって、これらのオプションの操作は、保護されたメッセージが宛先エンドポイントに到達するか到達しないかに影響を与える可能性があります。
Attacks on unprotected CoAP message fields generally causes denial-of-service attacks which are out of scope of this document, more details are given in Appendix D.5.
保護されていないCoAPメッセージフィールドに対する攻撃は、通常、サービス拒否攻撃を引き起こしますが、このドキュメントの範囲外です。詳細については、付録D.5を参照してください。
Attacks against the CoAP request-response layer are in scope. OSCORE is intended to protect against eavesdropping, spoofing, insertion, modification, deletion, replay, and man-in-the middle attacks.
CoAP要求/応答層に対する攻撃が対象です。 OSCOREは、盗聴、なりすまし、挿入、変更、削除、再生、および中間者攻撃から保護することを目的としています。
OSCORE is susceptible to traffic analysis as discussed later in Appendix D.
付録Dで後述するように、OSCOREはトラフィック分析の影響を受けます。
CoAP is designed to work with intermediaries reading and/or changing CoAP message fields to perform supporting operations in constrained environments, e.g., forwarding and cross-protocol translations.
CoAPは、仲介者がCoAPメッセージフィールドを読み取ったり変更したりして、制約された環境で転送やクロスプロトコル変換などのサポート操作を実行するように設計されています。
Securing CoAP on the transport layer protects the entire message between the endpoints, in which case CoAP proxy operations are not possible. In order to enable proxy operations, security on the transport layer needs to be terminated at the proxy; in which case, the CoAP message in its entirety is unprotected in the proxy.
トランスポート層でCoAPを保護すると、エンドポイント間のメッセージ全体が保護されます。この場合、CoAPプロキシ操作はできません。プロキシ操作を有効にするには、トランスポート層のセキュリティをプロキシで終了する必要があります。この場合、CoAPメッセージ全体がプロキシで保護されません。
Requirements for CoAP end-to-end security are specified in [CoAP-E2E-Sec], in particular, forwarding is detailed in Section 2.2.1. The client and server are assumed to be honest, while proxies and gateways are only trusted to perform their intended operations.
CoAPエンドツーエンドセキュリティの要件は[CoAP-E2E-Sec]で指定されています。特に、転送についてはセクション2.2.1で詳しく説明されています。クライアントとサーバーは正直であると想定されていますが、プロキシとゲートウェイは、意図された操作を実行するためにのみ信頼されています。
By working at the CoAP layer, OSCORE enables different CoAP message fields to be protected differently, which allows message fields required for proxy operations to be available to the proxy while message fields intended for the other endpoint remain protected. In the remainder of this section, we analyze how OSCORE protects the protected message fields and the consequences of message fields intended for proxy operation being unprotected.
OSAPはCoAPレイヤーで作業することにより、異なるCoAPメッセージフィールドを異なる方法で保護できるようにします。これにより、他のエンドポイント向けのメッセージフィールドは保護されたまま、プロキシ操作に必要なメッセージフィールドをプロキシで使用できるようになります。このセクションの残りの部分では、OSCOREが保護されたメッセージフィールドをどのように保護するか、およびプロキシ操作を目的としたメッセージフィールドが保護されない結果を分析します。
Protected message fields are included in the plaintext (Section 5.3) and the AAD (Section 5.4) of the COSE_Encrypt0 object and encrypted using an AEAD algorithm.
保護されたメッセージフィールドは、COSE_Encrypt0オブジェクトのプレーンテキスト（セクション5.3）およびAAD（セクション5.4）に含まれ、AEADアルゴリズムを使用して暗号化されます。
OSCORE depends on a preestablished random Master Secret (Section 12.3) used to derive encryption keys, and a construction for making (key, nonce) pairs unique (Appendix D.4). Assuming this is true, and the keys are used for no more data than indicated in Section 7.2.1, OSCORE should provide the following guarantees:
OSCOREは、暗号化キーの導出に使用される事前に確立されたランダムなマスターシークレット（セクション12.3）と、（キー、ノンス）ペアを一意にするための構造（付録D.4）に依存しています。これが当てはまり、キーがセクション7.2.1に示されているよりも多くのデータに使用されない場合、OSCOREは次の保証を提供する必要があります。
o Confidentiality: An attacker should not be able to determine the plaintext contents of a given OSCORE message or determine that different plaintexts are related (Section 5.3).
o 機密性：攻撃者は、特定のOSCOREメッセージの平文の内容を判別したり、異なる平文が関連していると判別したりすることはできません（セクション5.3）。
o Integrity: An attacker should not be able to craft a new OSCORE message with protected message fields different from an existing OSCORE message that will be accepted by the receiver.
o 完全性：攻撃者は、受信者が受け入れる既存のOSCOREメッセージとは異なる保護されたメッセージフィールドを持つ新しいOSCOREメッセージを作成することはできません。
o Request-response binding: An attacker should not be able to make a client match a response to the wrong request.
o 要求と応答のバインディング：攻撃者は、クライアントに間違った要求への応答を一致させることはできません。
o Non-replayability: An attacker should not be able to cause the receiver to accept a message that it has previously received and accepted.
o 非再生可能性：攻撃者は、以前に受信して受け入れたメッセージを受信者に受け入れさせるべきではありません。
In the above, the attacker is anyone except the endpoints, e.g., a compromised intermediary. Informally, OSCORE provides these properties by AEAD-protecting the plaintext with a strong key and uniqueness of (key, nonce) pairs. AEAD encryption [RFC5116] provides confidentiality and integrity for the data. Response-request binding is provided by including the 'kid' and Partial IV of the request in the AAD of the response. Non-replayability of requests and notifications is provided by using unique (key, nonce) pairs and a replay protection mechanism (application dependent, see Section 7.4).
上記では、攻撃者はエンドポイントを除くすべてのユーザーです（例：侵害された仲介者）。非公式に、OSCOREは、強力なキーと（キー、ノンス）ペアの一意性でプレーンテキストをAEAD保護することにより、これらのプロパティを提供します。 AEAD暗号化[RFC5116]は、データの機密性と整合性を提供します。応答-要求バインディングは、応答のAADに要求の「子供」と部分IVを含めることによって提供されます。リクエストと通知の非再生性は、一意の（キー、ノンス）ペアと再生保護メカニズム（アプリケーションに依存、セクション7.4を参照）を使用して提供されます。
OSCORE is susceptible to a variety of traffic analysis attacks based on observing the length and timing of encrypted packets. OSCORE does not provide any specific defenses against this form of attack, but the application may use a padding mechanism to prevent an attacker from directly determining the length of the padding. However, information about padding may still be revealed by side-channel attacks observing differences in timing.
OSCOREは、暗号化されたパケットの長さとタイミングの観察に基づいて、さまざまなトラフィック分析攻撃を受けやすくなっています。 OSCOREはこの形式の攻撃に対して特定の防御を提供しませんが、アプリケーションはパディングメカニズムを使用して、攻撃者がパディングの長さを直接決定できないようにすることができます。ただし、パディングに関する情報は、タイミングの違いを観察するサイドチャネル攻撃によって明らかになる可能性があります。
In this section, we show that (key, nonce) pairs are unique as long as the requirements in Sections 3.3 and 7.2.1 are followed.
このセクションでは、セクション3.3および7.2.1の要件が満たされている限り、（キー、ノンス）ペアが一意であることを示します。
Fix a Common Context (Section 3.1) and an endpoint, called the encrypting endpoint. An endpoint may alternate between client and server roles, but each endpoint always encrypts with the Sender Key of its Sender Context. Sender Keys are (stochastically) unique since they are derived with HKDF using unique Sender IDs, so messages encrypted by different endpoints use different keys. It remains to be proven that the nonces used by the fixed endpoint are unique.
Fix a Common Context (Section 3.1) and an endpoint, called the encrypting endpoint. An endpoint may alternate between client and server roles, but each endpoint always encrypts with the Sender Key of its Sender Context. Sender Keys are (stochastically) unique since they are derived with HKDF using unique Sender IDs, so messages encrypted by different endpoints use different keys. It remains to be proven that the nonces used by the fixed endpoint are unique.
Since the Common IV is fixed, the nonces are determined by PIV, where PIV takes the value of the Partial IV of the request or of the response, and by the Sender ID of the endpoint generating that Partial IV (ID_PIV). The nonce construction (Section 5.2) with the size of the ID_PIV (S) creates unique nonces for different (ID_PIV, PIV) pairs. There are two cases:
Common IVは固定されているため、ナンスはPIVによって決定されます。PIVは、要求または応答のPartial IVの値と、そのPartial IVを生成するエンドポイントの送信者ID（ID_PIV）を使用します。 ID_PIV（S）のサイズのノンス構造（セクション5.2）は、異なる（ID_PIV、PIV）ペアに対して一意のノンスを作成します。 2つのケースがあります。
A. For requests, and responses with Partial IV (e.g., Observe notifications):
A. For requests, and responses with Partial IV (e.g., Observe notifications):
o ID_PIV = Sender ID of the encrypting endpoint
o ID_PIV =暗号化エンドポイントの送信者ID
o PIV = current Partial IV of the encrypting endpoint
o PIV =暗号化エンドポイントの現在の部分IV
Since the encrypting endpoint steps the Partial IV for each use, the nonces used in case A are all unique as long as the number of encrypted messages is kept within the required range (Section 7.2.1).
暗号化エンドポイントは使用ごとに部分IVを実行するため、暗号化されたメッセージの数が必要な範囲内にある限り（ケース7.2.1）、ケースAで使用されるナンスはすべて一意です。
B. For responses without Partial IV (e.g., single response to a request):
B. For responses without Partial IV (e.g., single response to a request):
o ID_PIV = Sender ID of the endpoint generating the request
o ID_PIV = Sender ID of the endpoint generating the request
o PIV = Partial IV of the request
o PIV =リクエストの部分IV
Since the Sender IDs are unique, ID_PIV is different from the Sender ID of the encrypting endpoint. Therefore, the nonces in case B are different compared to nonces in case A, where the encrypting endpoint generated the Partial IV. Since the Partial IV of the request is verified for replay (Section 7.4) associated to this Recipient Context, PIV is unique for this ID_PIV, which makes all nonces in case B distinct.
Since the Sender IDs are unique, ID_PIV is different from the Sender ID of the encrypting endpoint. Therefore, the nonces in case B are different compared to nonces in case A, where the encrypting endpoint generated the Partial IV. Since the Partial IV of the request is verified for replay (Section 7.4) associated to this Recipient Context, PIV is unique for this ID_PIV, which makes all nonces in case B distinct.
This section analyzes attacks on message fields that are not protected by OSCORE according to the threat model Appendix D.1.
このセクションでは、脅威モデルの付録D.1に従って、OSCOREで保護されていないメッセージフィールドに対する攻撃を分析します。
o Version. The CoAP version [RFC7252] is not expected to be sensitive to disclosure. Currently, there is only one CoAP version defined. A change of this parameter is potentially a denial-of-service attack. Future versions of CoAP need to analyze attacks to OSCORE-protected messages due to an adversary changing the CoAP version.
oバージョン。 CoAPバージョン[RFC7252]は開示に敏感であるとは想定されていません。現在、定義されているCoAPバージョンは1つだけです。このパラメータの変更は、潜在的にサービス拒否攻撃です。 CoAPの将来のバージョンでは、攻撃者がCoAPバージョンを変更するため、OSCOREで保護されたメッセージへの攻撃を分析する必要があります。
o Token/Token Length. The Token field is a client-local identifier for differentiating between concurrent requests [RFC7252]. CoAP proxies are allowed to read and change Token and Token Length between hops. An eavesdropper reading the Token can match requests to responses that can be used in traffic analysis. In particular, this is true for notifications, where multiple responses are matched to one request. Modifications of Token and Token Length by an on-path attacker may become a denial-of-service attack, since it may prevent the client to identify to which request the response belongs or to find the correct information to verify integrity of the response.
o トークン/トークンの長さ。 Tokenフィールドは、同時リクエストを区別するためのクライアントローカル識別子です[RFC7252]。 CoAPプロキシは、ホップ間でトークンとトークン長を読み取って変更することができます。トークンを読み取る盗聴者は、トラフィック分析で使用できる応答と要求を照合できます。特に、これは、複数の応答が1つの要求に一致する通知に当てはまります。経路上の攻撃者によるトークンとトークン長の変更は、クライアントが応答の属する要求を識別したり、応答の整合性を検証するための正しい情報を見つけたりできないため、サービス拒否攻撃になる可能性があります。
o Code. The Outer CoAP Code of an OSCORE message is POST or FETCH for requests with corresponding response codes. An endpoint receiving the message discards the Outer CoAP Code and uses the Inner CoAP Code instead (see Section 4.2). Hence, modifications from attackers to the Outer Code do not impact the receiving endpoint. However, changing the Outer Code from FETCH to a Code value for a method that does not work with Observe (such as POST) may, depending on proxy implementation since Observe is undefined for several Codes, cause the proxy to not forward notifications, which is a denial-of-service attack. The use of FETCH rather than POST reveals no more than what is revealed by the presence of the Outer Observe option.
o コード。 OSCOREメッセージの外部CoAPコードは、対応する応答コードを持つ要求のPOSTまたはFETCHです。メッセージを受信するエンドポイントは、外部CoAPコードを破棄し、代わりに内部CoAPコードを使用します（セクション4.2を参照）。したがって、攻撃者から外部コードへの変更は、受信エンドポイントに影響を与えません。ただし、外部コードをFETCHから、Observeで機能しないメソッド（POSTなど）のコード値に変更すると、プロキシの実装によっては、いくつかのコードでObserveが定義されていないため、プロキシが通知を転送しない場合があります。サービス拒否攻撃。 POSTではなくFETCHを使用すると、[外部監視]オプションの存在によって明らかになることだけが明らかになります。
o Type/Message ID. The Type/Message ID fields [RFC7252] reveal information about the UDP transport binding, e.g., an eavesdropper reading the Type or Message ID gain information about how UDP messages are related to each other. CoAP proxies are allowed to change Type and Message ID. These message fields are not present in CoAP over TCP [RFC8323] and do not impact the request/response message. A change of these fields in a UDP hop is a denial-of-service attack. By sending an ACK, an attacker can make the endpoint believe that it does not need to retransmit the previous message. By sending a RST, an attacker may be able to cancel an observation. By changing a NON to a CON, the attacker can cause the receiving endpoint to ACK messages for which no ACK was requested.
o タイプ/メッセージID。タイプ/メッセージIDフィールド[RFC7252]は、UDPトランスポートバインディングに関する情報を明らかにします。たとえば、タイプIDまたはメッセージIDを盗聴する盗聴者は、UDPメッセージの相互関係に関する情報を入手します。 CoAPプロキシは、タイプとメッセージIDを変更できます。これらのメッセージフィールドは、CoAP over TCP [RFC8323]には存在せず、要求/応答メッセージに影響を与えません。 UDPホップのこれらのフィールドの変更は、サービス拒否攻撃です。攻撃者はACKを送信することにより、エンドポイントに前のメッセージを再送信する必要がないと信じ込ませることができます。 RSTを送信することにより、攻撃者は観測をキャンセルできる可能性があります。 NONをCONに変更することにより、攻撃者は受信エンドポイントに、ACKが要求されていないメッセージをACKさせることができます。
o Length. This field contains the length of the message [RFC8323], which may be used for traffic analysis. This message field is not present in CoAP over UDP and does not impact the request/response message. A change of Length is a denial-of-service attack similar to changing TCP header fields.
o 長さ。このフィールドには、メッセージ[RFC8323]の長さが含まれ、トラフィック分析に使用できます。このメッセージフィールドは、CoAP over UDPには存在せず、要求/応答メッセージには影響しません。長さの変更は、TCPヘッダーフィールドの変更と同様のサービス拒否攻撃です。
o Max-Age. The Outer Max-Age is set to zero to avoid unnecessary caching of OSCORE error responses. Changing this value thus may cause unnecessary caching. No additional information is carried with this option.
o マックスエイジ。 OSCOREエラー応答の不要なキャッシュを回避するために、Outer Max-Ageはゼロに設定されています。したがって、この値を変更すると、不要なキャッシュが発生する可能性があります。このオプションでは、追加情報は提供されません。
o Proxy-Uri/Proxy-Scheme. These options are used in CoAP forward proxy deployments. With OSCORE, the Proxy-Uri option does not contain the Uri-Path/Uri-Query parts of the URI. The other parts of Proxy-Uri cannot be protected because forward proxies need to change them in order to perform their functions. The server can verify what scheme is used in the last hop, but not what was requested by the client or what was used in previous hops.
o Proxy-Uri/Proxy-Scheme. These options are used in CoAP forward proxy deployments. With OSCORE, the Proxy-Uri option does not contain the Uri-Path/Uri-Query parts of the URI. The other parts of Proxy-Uri cannot be protected because forward proxies need to change them in order to perform their functions. The server can verify what scheme is used in the last hop, but not what was requested by the client or what was used in previous hops.
o Uri-Host/Uri-Port. In forward proxy deployments, the Uri-Host/ Uri-Port may be changed by an adversary, and the application needs to handle the consequences of that (see Section 4.1.3.2). The Uri-Host may either be omitted, reveal information equivalent to that of the IP address, or reveal more privacy-sensitive information, which is discouraged.
o Uri-Host / Uri-Port。フォワードプロキシ展開では、Uri-Host / Uri-Portが攻撃者によって変更される可能性があり、アプリケーションはその結果を処理する必要があります（セクション4.1.3.2を参照）。 Uri-Hostは、省略されるか、IPアドレスと同等の情報を公開するか、プライバシーを保護するための情報を公開することをお勧めしますが、推奨されません。
o Observe. The Outer Observe option is intended for a proxy to support forwarding of Observe messages, but it is ignored by the endpoints since the Inner Observe option determines the processing in the endpoints. Since the Partial IV provides absolute ordering of notifications, it is not possible for an intermediary to spoof reordering (see Section 4.1.3.5). The absence of Partial IV, since only allowed for the first notification, does not prevent correct ordering of notifications. The size and distributions of notifications over time may reveal information about the content or nature of the notifications. Cancellations (Section 4.1.3.5.1) are not bound to the corresponding registrations in the same way responses are bound to requests in OSCORE (see Appendix D.3). However, that does not make attacks based on mismatched cancellations possible, since for cancellations to be accepted, all options in the decrypted message except for ETag options MUST be the same (see Section 4.1.3.5).
o Observe. The Outer Observe option is intended for a proxy to support forwarding of Observe messages, but it is ignored by the endpoints since the Inner Observe option determines the processing in the endpoints. Since the Partial IV provides absolute ordering of notifications, it is not possible for an intermediary to spoof reordering (see Section 4.1.3.5). The absence of Partial IV, since only allowed for the first notification, does not prevent correct ordering of notifications. The size and distributions of notifications over time may reveal information about the content or nature of the notifications. Cancellations (Section 4.1.3.5.1) are not bound to the corresponding registrations in the same way responses are bound to requests in OSCORE (see Appendix D.3). However, that does not make attacks based on mismatched cancellations possible, since for cancellations to be accepted, all options in the decrypted message except for ETag options MUST be the same (see Section 4.1.3.5).
o Block1/Block2/Size1/Size2. The Outer Block options enable fragmentation of OSCORE messages in addition to segmentation performed by the Inner Block options. The presence of these options indicates a large message being sent, and the message size can be estimated and used for traffic analysis. Manipulating these options is a potential denial-of-service attack, e.g., injection of alleged Block fragments. The specification of a maximum size of message, MAX_UNFRAGMENTED_SIZE (Section 4.1.3.4.2), above which messages will be dropped, is intended as one measure to mitigate this kind of attack.
o Block1 / Block2 / Size1 / Size2。外部ブロックオプションは、内部ブロックオプションによって実行されるセグメンテーションに加えて、OSCOREメッセージの断片化を有効にします。これらのオプションの存在は、送信されている大きなメッセージを示し、メッセージサイズを推定してトラフィック分析に使用できます。これらのオプションの操作は、サービス拒否攻撃の可能性があります。たとえば、申し立てられたブロックフラグメントの挿入です。メッセージの最大サイズであるMAX_UNFRAGMENTED_SIZE（セクション4.1.3.4.2）の指定は、それを超えるとメッセージがドロップされ、この種の攻撃を緩和するための1つの手段として意図されています。
o No-Response. The Outer No-Response option is used to support proxy functionality, specifically to avoid error transmissions from proxies to clients, and to avoid bandwidth reduction to servers by proxies applying congestion control when not receiving responses. Modifying or introducing this option is a potential denial-of-service attack against the proxy operations, but since the option has an Inner value, its use can be securely agreed upon between the endpoints. The presence of this option is not expected to reveal any sensitive information about the message exchange.
o No-Response. The Outer No-Response option is used to support proxy functionality, specifically to avoid error transmissions from proxies to clients, and to avoid bandwidth reduction to servers by proxies applying congestion control when not receiving responses. Modifying or introducing this option is a potential denial-of-service attack against the proxy operations, but since the option has an Inner value, its use can be securely agreed upon between the endpoints. The presence of this option is not expected to reveal any sensitive information about the message exchange.
o OSCORE. The OSCORE option contains information about the compressed COSE header. Changing this field may cause OSCORE verification to fail.
o OSCORE。 OSCOREオプションには、圧縮されたCOSEヘッダーに関する情報が含まれています。このフィールドを変更すると、OSCORE検証が失敗する可能性があります。
Error messages occurring during CoAP processing are protected end-to-end. Error messages occurring during OSCORE processing are not always possible to protect, e.g., if the receiving endpoint cannot locate the right security context. For this setting, unprotected error messages are allowed as specified to prevent extensive retransmissions. Those error messages can be spoofed or manipulated, which is a potential denial-of-service attack.
Error messages occurring during CoAP processing are protected end-to-end. Error messages occurring during OSCORE processing are not always possible to protect, e.g., if the receiving endpoint cannot locate the right security context. For this setting, unprotected error messages are allowed as specified to prevent extensive retransmissions. Those error messages can be spoofed or manipulated, which is a potential denial-of-service attack.
This document specifies OPTIONAL error codes and specific diagnostic payloads for OSCORE processing error messages. Such messages might reveal information about how many and which security contexts exist on the server. Servers MAY want to omit the diagnostic payload of error messages, use the same error code for all errors, or avoid responding altogether in case of OSCORE processing errors, if that is a security concern for the application. Moreover, clients MUST NOT rely on the error code or the diagnostic payload to trigger specific actions, as these errors are unprotected and can be spoofed or manipulated.
This document specifies OPTIONAL error codes and specific diagnostic payloads for OSCORE processing error messages. Such messages might reveal information about how many and which security contexts exist on the server. Servers MAY want to omit the diagnostic payload of error messages, use the same error code for all errors, or avoid responding altogether in case of OSCORE processing errors, if that is a security concern for the application. Moreover, clients MUST NOT rely on the error code or the diagnostic payload to trigger specific actions, as these errors are unprotected and can be spoofed or manipulated.
Signaling messages used in CoAP over TCP [RFC8323] are intended to be hop-by-hop; spoofing signaling messages can be used as a denial-of-service attack of a TCP connection.
CoAP over TCP [RFC8323]で使用されるシグナリングメッセージは、ホップバイホップであることを意図しています。スプーフィングシグナリングメッセージは、TCP接続のサービス拒否攻撃として使用できます。
In contrast to CoAP, where OSCORE does not protect header fields to enable CoAP-CoAP proxy operations, the use of OSCORE with HTTP is restricted to transporting a protected CoAP message over an HTTP hop. Any unprotected HTTP message fields may reveal information about the transport of the OSCORE message and enable various denial-of-service attacks. It is RECOMMENDED to additionally use TLS [RFC8446] for HTTP hops, which enables encryption and integrity protection of headers, but still leaves some information for traffic analysis.
OSAPがヘッダーフィールドを保護してCoAP-CoAPプロキシ操作を有効にしないCoAPとは対照的に、HTTPでのOSCOREの使用は、保護されたCoAPメッセージをHTTPホップで転送することに限定されます。保護されていないHTTPメッセージフィールドは、OSCOREメッセージの転送に関する情報を明らかにし、さまざまなサービス拒否攻撃を可能にする可能性があります。 HTTPホップにTLS [RFC8446]を追加で使用することをお勧めします。これにより、ヘッダーの暗号化と整合性保護が可能になりますが、トラフィック分析のために一部の情報が残ります。
Data structure definitions in the present specification employ the CDDL language for conciseness and precision [RFC8610]. This appendix summarizes the small subset of CDDL that is used in the present specification.
本仕様におけるデータ構造定義は、簡潔さと正確さのためにCDDL言語を採用しています[RFC8610]。この付録では、本仕様で使用されるCDDLの小さなサブセットを要約しています。
Within the subset being used here, a CDDL rule is of the form "name = type", where "name" is the name given to the "type". A "type" can be one of:
ここで使用されているサブセット内では、CDDLルールは「name = type」の形式です。「name」は「type」に付けられた名前です。 「タイプ」は次のいずれかです。
o a reference to another named type, by giving its name. The predefined named types used in the present specification are as follows: "uint", an unsigned integer (as represented in CBOR by major type 0); "int", an unsigned or negative integer (as represented in CBOR by major type 0 or 1); "bstr", a byte string (as represented in CBOR by major type 2); "tstr", a text string (as represented in CBOR by major type 3);
o 名前を与えることによる、別の名前付きタイプへの参照。本明細書で使用される事前定義の名前付きタイプは次のとおりです。「uint」、符号なし整数（メジャータイプ0によってCBORで表される）。 「int」、符号なしまたは負の整数（CBORでメジャータイプ0または1として表される）。 "bstr"、バイト文字列（メジャータイプ2によってCBORで表される）。 「tstr」、テキスト文字列（メジャータイプ3によってCBORで表される）。
o a choice between two types, by giving both types separated by a "/";
o 「/」で区切られた2つのタイプを指定することによる、2つのタイプ間の選択。
o an array type (as represented in CBOR by major type 4), where the sequence of elements of the array is described by giving a sequence of entries separated by commas ",", and this sequence is enclosed by square brackets "[" and "]". Arrays described by an array description contain elements that correspond one-to-one to the sequence of entries given. Each entry of an array description is of the form "name : type", where "name" is the name given to the entry and "type" is the type of the array element corresponding to this entry.
o 配列タイプ（メジャータイプ4によるCBORで表される）。配列の要素のシーケンスは、カンマ「、」で区切られたエントリのシーケンスを与えることによって記述され、このシーケンスは角括弧「[」と「 ] "。配列記述で記述された配列には、指定されたエントリのシーケンスと1対1で対応する要素が含まれています。配列記述の各エントリは、「name：type」の形式です。「name」はエントリに付けられた名前、「type」はこのエントリに対応する配列要素のタイプです。
Acknowledgments
謝辞
The following individuals provided input to this document: Christian Amsuess, Tobias Andersson, Carsten Bormann, Joakim Brorsson, Ben Campbell, Esko Dijk, Jaro Fietz, Thomas Fossati, Martin Gunnarsson, Klaus Hartke, Rikard Hoeglund, Mirja Kuehlewind, Kathleen Moriarty, Eric Rescorla, Michael Richardson, Adam Roach, Jim Schaad, Peter van der Stok, Dave Thaler, Martin Thomson, Marco Tiloca, William Vignat, and Malisa Vucinic.
次の個人がこのドキュメントに入力を提供しました：クリスチャンアムス、トビアスアンダーソン、カルステンボルマン、ヨアキムブロンソン、ベンキャンベル、エスコダイク、ジャロフィエツ、トーマスフォッサティ、マーティンガンナーソン、クラウスハートケ、リカルドホーグルンド、ミルハキュールウィンド、キャスリーンモリアーティ、エリックレスコーラ、マイケル・リチャードソン、アダム・ローチ、ジム・シャード、ピーター・ファン・デル・ストック、デイブ・ターラー、マーティン・トムソン、マルコ・ティロカ、ウィリアム・ヴィニャット、マリサ・ヴチニック。
Ludwig Seitz and Goeran Selander worked on this document as part of the CelticPlus project CyberWI, with funding from Vinnova. Ludwig Seitz had additional funding from the SSF project SEC4Factory under the grant RIT17-0032.
Ludwig SeitzとGoeran Selanderは、Vinnovaからの資金提供を受けて、CelticPlusプロジェクトCyberWIの一部としてこのドキュメントに取り組みました。ルートヴィヒ・ザイツは、助成金RIT17-0032の下でSSFプロジェクトSEC4Factoryから追加の資金を調達しました。
Authors' Addresses
著者のアドレス
Goeran Selander Ericsson AB
Goeran Selander Ericsson AB
Email: goran.selander@ericsson.com
John Mattsson Ericsson AB
John Mattsson Ericsson AB
Email: john.mattsson@ericsson.com
Francesca Palombini Ericsson AB
フランチェスカパロンビーニエリクソンAB
Email: francesca.palombini@ericsson.com
Ludwig Seitz RISE
ルートヴィヒ・ザイツ・ライズ
Email: ludwig.seitz@ri.se