[要約] この文書は、制約のあるデバイス（IoT）向けのセキュアなアプリケーション層プロトコル「OSCORE (Object Security for Constrained RESTful Environments)」の仕様を定義しています。CoAPメッセージのペイロードと一部のヘッダーをEnd-to-Endで暗号化・保護するためにCOSE（RFC 8152）を利用し、中継するプロキシに対しても秘匿性を保ちつつ、メモリや帯域の消費を最小限に抑えた強固なセキュリティを提供します。
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)をアプリケーション層で保護する方式、Object Security for Constrained RESTful Environments (OSCORE)を定義します。OSCOREはエンドポイント間のエンドツーエンド保護を提供し、CoAPやCoAPと相互変換可能なHTTPを使用する複数のトランスポートプロトコル上で、各種プロキシ操作を可能にします。制約のあるノードやネットワーク環境向けに設計されています。
Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.
OSCOREは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.
本書はInternet Engineering Task Force (IETF)の成果であり、IETFコミュニティの合意を示しています。公開レビューを受け、Internet Engineering Steering Group (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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1. はじめに .......................................................5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. 用語 .......................................................7
2. The OSCORE Option . . . . . . . . . . . . . . . . . . . . . . 8
2. OSCOREオプション ...............................................8
3. The Security Context . . . . . . . . . . . . . . . . . . . . 8
3. Security Context ...............................................8
3.1. Security Context Definition . . . . . . . . . . . . . . . 9
3.1. Security Contextの定義 .....................................9
3.2. Establishment of Security Context Parameters . . . . . . 11
3.2. Security Contextパラメータの確立 ..........................11
3.3. Requirements on the Security Context Parameters . . . . . 14
3.3. Security Contextパラメータの要件 ..........................14
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 15
4. 保護されたメッセージフィールド ................................15
4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 16
4.1. CoAPオプション ............................................16
4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 24
4.2. CoAPヘッダーフィールドとペイロード ........................24
4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 25
4.3. シグナリングメッセージ ....................................25
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 26
5. COSEオブジェクト ..............................................26
5.1. ID Context and 'kid context' . . . . . . . . . . . . . . 27
5.1. ID Contextと「kid context」 ...............................27
5.2. AEAD Nonce . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. AEADnonce .................................................28
5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3. 平文 ......................................................29
5.4. Additional Authenticated Data . . . . . . . . . . . . . . 30
5.4. 追加の認証済みデータ ......................................30
6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 31
6. OSCOREヘッダー圧縮 ............................................31
6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 32
6.1. OSCOREオプション値のエンコード ............................32
6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 33
6.2. OSCOREペイロードのエンコーディング ........................33
6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 33
6.3. 圧縮されたCOSEオブジェクトの例 ............................33
7. Message Binding, Sequence Numbers, Freshness, and Replay
Protection . . . . . . . . . . . . . . . . . . . . . . . . . 36
7. メッセージのバインド、シーケンス番号、鮮度、およびリプレイ保護 ..36
7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 36
7.1. メッセージのバインド ......................................36
7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 36
7.2. シーケンス番号 ............................................36
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3. 鮮度 ......................................................36
7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 37
7.4. リプレイ保護 ..............................................37
7.5. Losing Part of the Context State . . . . . . . . . . . . 38
7.5. コンテキスト状態の一部を失う ..............................38
8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. 処理 ..........................................................39
8.1. Protecting the Request . . . . . . . . . . . . . . . . . 39
8.1. リクエストの保護 ..........................................39
8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 40
8.2. リクエストの確認 ..........................................40
8.3. Protecting the Response . . . . . . . . . . . . . . . . . 41
8.3. 応答の保護 ................................................41
8.4. Verifying the Response . . . . . . . . . . . . . . . . . 43
8.4. 応答の確認 ................................................43
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 44
9. ウェブリンク ..................................................44
10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 45
10. CoAP-to-CoAP転送プロキシ ......................................45
11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 46
11. HTTPオペレーション ............................................46
11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 46
11.1. HTTP OSCOREヘッダーフィールド ............................46
11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 47
11.2. CoAPからHTTPへのマッピング ...............................47
11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 48
11.3. HTTPからCoAPへのマッピング ...............................48
11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 48
11.4. HTTPエンドポイント .......................................48
11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 48
11.5. 例：HTTPクライアントとCoAPサーバー .......................48
11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 50
11.6. 例：CoAPクライアントとHTTPサーバー .......................50
12. Security Considerations . . . . . . . . . . . . . . . . . . . 51
12. セキュリティに関する考慮事項 ..................................51
12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 51
12.1. エンドツーエンドの保護 ...................................51
12.2. Security Context Establishment . . . . . . . . . . . . . 52
12.2. Security Contextの確立 ...................................52
12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 52
12.3. Master Secret ............................................52
12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 53
12.4. リプレイ保護 .............................................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
12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 53
12.5. クライアントの活力 .......................................53
12.6. Cryptographic Considerations . . . . . . . . . . . . . . 53
12.6. 暗号に関する考慮事項 .....................................53
12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 54
12.7. メッセージのセグメンテーション ...........................54
12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 54
12.8. プライバシーに関する考慮事項 .............................54
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
13. IANAに関する考慮事項 ..........................................55
13.1. COSE Header Parameters Registry . . . . . . . . . . . . 55
13.1. COSEヘッダーパラメータレジストリ .........................55
13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 55
13.2. CoAPオプション番号レジストリ .............................55
13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 56
13.3. CoAPシグナリングオプション番号レジストリ .................56
13.4. Header Field Registrations . . . . . . . . . . . . . . . 57
13.4. ヘッダーフィールドの登録 .................................57
13.5. Media Type Registration . . . . . . . . . . . . . . . . 57
13.5. メディアタイプ登録 .......................................57
13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 58
13.6. CoAPコンテンツ形式レジストリ .............................58
13.7. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 58
13.7. OSCOREフラグビットレジストリ .............................58
13.8. Expert Review Instructions . . . . . . . . . . . . . . . 59
13.8. エキスパートレビューの手順 ...............................59
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
14. 参考文献 ......................................................60
14.1. Normative References . . . . . . . . . . . . . . . . . . 60
14.1. 引用文献 .................................................60
14.2. Informative References . . . . . . . . . . . . . . . . . 62
14.2. 参考引用 .................................................62
Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 65
Appendix A. シナリオの例 .........................................65
A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 65
A.1. センサーへの安全なアクセス ................................65
A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 66
A.2. センサーへの安全な購読 ....................................66
Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 68
Appendix B. デプロイメントの例 ...................................68
B.1. Security Context Derived Once . . . . . . . . . . . . . . 68
B.1. 一度派生したSecurity Context ..............................68
B.2. Security Context Derived Multiple Times . . . . . . . . . 70
B.2. 複数回導出されたSecurity Context ..........................70
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 75
Appendix C. テストベクトル .......................................75
C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 75
C.1. テストベクトル1：Master Saltを使用したキーの派生 ..........75
C.2. Test Vector 2: Key Derivation without Master Salt . . . . 77
C.2. テストベクトル2：Master Saltを使用しないキーの導出 ........77
C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 78
C.3. テストベクトル3：ID Contextによるキーの派生 ...............78
C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 80
C.4. テストベクタ4：OSCOREリクエスト、クライアント .............80
C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 81
C.5. テストベクター5：OSCOREリクエスト、クライアント ...........81
C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 82
C.6. テストベクター6：OSCOREリクエスト、クライアント ...........82
C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 84
C.7. テストベクトル7：OSCORE応答、サーバー .....................84
C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 85
C.8. テストベクトル8：Partial IV、サーバーでのOSCORE応答
Appendix D. Overview of Security Properties . . . . . . . . . . 86
Appendix D. セキュリティプロパティの概要 .........................86
D.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 86
D.1. 脅威モデル ................................................86
D.2. Supporting Proxy Operations . . . . . . . . . . . . . . . 87
D.2. プロキシ操作のサポート ....................................87
D.3. Protected Message Fields . . . . . . . . . . . . . . . . 87
D.3. 保護されたメッセージフィールド ............................87
D.4. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 88
D.4. （key、nonce）の一意性 ....................................88
D.5. Unprotected Message Fields . . . . . . . . . . . . . . . 89
D.5. 保護されていないメッセージフィールド ......................89
Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 93
Appendix E. CDDLの概要 ...........................................93
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 94
謝辞 ..............................................................94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
著者のアドレス ....................................................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 節) を許容しながら、できるだけ多くの情報を保護するように設計されています。OSCORE は、既存の CoAP から CoAP への前方プロキシ [RFC7252] で動作しますが、OSCORE に対応したプロキシのほうが効率的です。HTTP から CoAP へのプロキシ [RFC8075] や、CoAP から HTTP へのプロキシも、11 節で規定されているとおり、OSCORE と併用できます。OSCORE は、エンドツーエンド経路上の 1 つ以上のホップで TLS や DTLS と併用してもよく、たとえば、あるホップでは 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 Object Signing and Encryption (COSE) [RFC8152]に基づき、エンドツーエンドの暗号化、完全性保護、リプレイ保護、および要求と応答の結び付けを提供します。セクション6で規定するCOSEオブジェクトの圧縮形式を使用します。OSCOREの使用は、CoAPでは新しいオプション（セクション2）、HTTPでは新しいヘッダーフィールド（セクション11.1）とメディアタイプ（セクション13.5）によって示されます。この方式は、CoAP/HTTPメッセージを送信前にOSCOREメッセージへ変換し、受信後に元のメッセージへ戻すことで、異なるトランスポート間のプロキシ処理にも対応します。
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）。
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].
読者は、CoAP [RFC7252]、COSE [RFC8152]、Concise Binary Object Representation (CBOR) [RFC7049]、Concise Data Definition Language (CDDL) [RFC8610]（付録Eに要約）、および制約のある環境 [RFC7228] の用語と概念に精通していることが想定されています。追加の任意機能として、Observe [RFC7641]、Block-wise [RFC7959]、No-Response [RFC7967]、および信頼性の高いトランスポート上のCoAP [RFC8323]があります。
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.
本書では「hop」をエンドツーエンド経路上の特定の区間を表す用語として使います。「hop-by-hop」（「hop-by-hop encryption」や「hop-by-hop fragmentation」など）は「end-to-end」と対比する概念であり、メッセージが単に次のノードへ転送されるのではなく、中間ノードで処理されることを示します。
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]の「Table 4: Options」を拡張する図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 = Critical、U = Unsafe、N = NoCacheKey、R = Repeatable（*）。以下を参照してください。
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 flag bits（セクション6）、Sender Sequence Number、Sender ID、および存在する場合のID Context（セクション3）が含まれます。形式と長さの詳細はセクション6で規定します。OSCORE flag bitsがすべてゼロ（0x00）の場合、オプション値は空でなければなりません (MUST)（オプション長は0です）。OSCOREオプションを含み、ペイロードのないCoAPメッセージを受信したエンドポイントは、そのメッセージを不正形式として扱い、拒否しなければなりません (MUST)。
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オプションが含まれていなければなりません (MUST)。エラー応答に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オブジェクトの処理に使用される共有Security Contextを確立する必要があります。 OSCOREは、クライアントとサーバー間のメッセージデータを保護するために、関連データを伴う認証済み暗号化（AEAD、[RFC5116]）アルゴリズムを備えたCOSEを使用します。このセクションでは、Security Contextと、共有シークレットとキー派生関数に基づいてクライアントとサーバーでSecurity Contextがどのように派生するかを定義します。
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".
Security Contextは、OSCOREで暗号化操作を実行するために必要な情報要素のセットです。各エンドポイントのSecurity Contextは、「Common Context」、「Sender Context」、および「Recipient Context」で構成されています。
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.
エンドポイントは、Sender Contextを使用して送信するメッセージを保護し、Recipient Contextを使用して受信したメッセージを確認します。両方のコンテキストは、Common Contextと他のデータから派生しています。クライアントとサーバーは、使用する正しいSecurity Contextを取得できる必要があります。
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.
エンドポイントは、Sender ID（SID）を使用してSender Contextを導出します。もう一方のエンドポイントは、現在はRecipient ID（RID）と呼ばれる同じIDを使用して、そのRecipient Contextを導出します。 2つのエンドポイント間の通信では、1つのエンドポイントのSender Contextが他のエンドポイントのRecipient Contextと一致し、その逆も同様です。したがって、2つのエンドポイントで同じIDによって識別される2つのSecurity Contextは同じではありませんが、部分的にミラーリングされています。Security Contextの取得と使用を図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：Security Contextの取得と使用
The Common Context contains the following parameters:
Common Contextには、以下のパラメーターが含まれています。
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アルゴリズム。Sender Key、Recipient Key、およびCommon 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 Master Secret。可変長のランダムバイト文字列（セクション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 Master Salt。 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 Context。Common Contextを識別し、AEADキーとCommon IVを導出するための追加情報を提供するオプションの可変長バイト文字列。 ID Contextの使用については、セクション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 Common IV。Master Secret、Master Salt、およびID Contextから導出されるバイト列です。AEAD nonceの生成に使用します（セクション5.2を参照）。長さはAEAD Algorithmのnonceと同じです。
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 Sender ID。Sender Contextを識別し、AEAD鍵とCommon IVを導出し、AEAD nonceの一意性を確保するために使うバイト列です。最大長はAEAD Algorithmによって決まります。
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 Sender Key。送信メッセージを保護する対称AEAD鍵を含むバイト列です。Common ContextとSender IDから導出されます。長さはAEAD Algorithmによって決まります。
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 Sender Sequence Number。送信者が要求と一部の応答（Observe notificationなど）を番号付けするために使う0以上の整数です。一意なAEAD nonceを生成するため、Partial IV [RFC8152]として使用します。最大値はAEAD Algorithmによって決まります。初期化についてはセクション3.2.2で説明します。
The Recipient Context contains the following parameters:
Recipient Contextには、次のパラメーターが含まれています。
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 Recipient ID。Recipient Contextを識別し、AEAD鍵とCommon IVを導出し、AEAD nonceの一意性を確保するために使うバイト列です。最大長はAEAD Algorithmによって決まります。
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 Recipient Key。受信メッセージを検証する対称AEAD鍵を含むバイト列です。Common ContextとRecipient IDから導出されます。長さはAEAD Algorithmによって決まります。
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 Replay Window（サーバーのみ）。受信した要求を検証するためのウィンドウです。リプレイ保護についてはセクション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.
Security Contextが確立されると、Sender Sequence NumberとReplay Windowを除くすべてのパラメーターは不変です。エンドポイントは、Common IV、Sender Key、およびRecipient Keyを格納せず、必要に応じてそれらを取得することにより、メモリを解放する場合があります。または、他のパラメータが導出された後、エンドポイントはMaster SecretとMaster Saltを保存しないことでメモリを解放する場合があります。
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.
エンドポイントはクライアントとサーバーの両方として機能し、それらのロールに同じSecurity Contextを使用する場合があります (MAY)。エンドポイントは、クライアントまたはサーバーであるかどうかに関係なく、Sender Contextを使用して送信するメッセージを保護し、Recipient Contextを使用して受信したメッセージを検証します。エンドポイントは、役割を変更するときに送信者/Recipient 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:
各エンドポイントは、Security Contextのパラメーターを、少数の入力パラメーターのセットから派生させます。次の入力パラメータを事前に確立しなければなりません (MUST)。
o Master Secret
o Master Secret
o Sender ID
o Sender ID
o Recipient ID
o Recipient ID
The following input parameters MAY be preestablished. In case any of these parameters is not preestablished, the default value indicated below is used:
次の入力パラメータは事前に確立されている場合があります (MAY)。これらのパラメーターのいずれかが事前に確立されていない場合、以下に示すデフォルト値が使用されます。
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 Master Salt
* Default is the empty byte string
* デフォルトは空のバイト文字列です
o HKDF Algorithm
o HKDFアルゴリズム
* Default is HKDF SHA-256
* デフォルトはHKDF SHA-256です
o Replay Window
o Replay Window
* 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.
すべての入力パラメーターは、両方のエンドポイントで認識され、合意される必要がありますが、Replay Windowは2つのエンドポイントで異なる場合があります。入力パラメーターが事前に確立される方法は、アプリケーション固有です。Security Contextの確立に関する考慮事項については、セクション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]:
output parameter = HKDF(salt, IKM, info, L)
出力パラメーター= HKDF（ソルト、IKM、情報、L）
where:
ここで:
o salt is the Master Salt as defined above
o saltは上記で定義されたMaster Saltです
o IKM is the Master Secret as defined above
o IKMは、上で定義したMaster Secretです。
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は、それぞれSender KeyとRecipient Keyを取得するときのSender IDまたはRecipient IDであり、Common IVを取得するときは空のバイト文字列です。
o id_context is the ID Context, or nil if ID Context is not provided.
o id_contextはID Contextです。ID Contextが指定されていない場合は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アルゴリズムのキー/nonceのサイズ（バイト単位）です。
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（Master Salt、Master Secret）
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呼び出しで構成されます。したがって、Sender Key、Recipient Key、およびCommon 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.
o info is the HKDF info structure (see Section 5.1 of [RFC5869]).
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]).
The Sender Sequence Number is initialized to 0.
Sender Sequence Numberは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.
サポートされるリプレイ保護とReplay Windowサイズのタイプはアプリケーション固有であり、OSCOREの転送方法によって異なります（第7.4項を参照）。デフォルトのメカニズムは、ウィンドウサイズが32で、IPsec AH/ESPおよびDTLS（[RFC6347]のセクション4.1.2.6を参照）で使用される受信メッセージのアンチReplay Windowです。
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.
一意なSender Keyを確保するため、4要素の組 (Master Secret, Master Salt, ID Context, Sender ID) は一意でなければなりません (MUST)。つまり、Master SecretとMaster Saltが同じすべてのSecurity Contextの間で、組 (ID Context, Sender ID) は一意でなければなりません (MUST)。さらに、Master Secret、Master Salt、ID Contextが同じSecurity Contextの間では、Sender IDが一意でなければなりません (MUST)。
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.
Sender IDの割り当てには、さまざまな方法を使用できます。当事者がローカルで一意の識別子をネゴシエートできるようにするプロトコル、信頼できるサードパーティ（[ACE-OAuth]など）、または識別子を帯域外に割り当てることができます。 Sender IDは非常に短くなる可能性があります（空の文字列は正当な値であることに注意してください）。Sender IDの最大長（バイト単位）は、AEAD nonceの長さから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.
正しいRecipient Contextの取得を簡単にするために、Recipient IDは、エンドポイントで使用されるすべてのRecipient Contextのセットで一意であるべきです (SHOULD)。エンドポイントのRecipient IDが同じで、Recipient Contextが異なる場合、つまり、Recipient Contextが異なるCommon Contextから派生している場合、エンドポイントは、Recipient IDに関連付けられた正しいSecurity Contextを確認する前に、複数回試行する必要がある場合があります。
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 Contextは、Security Contextを区別するために使用されます。 Sender IDの割り当てに使用されるメソッドは、ID Contextの割り当てにも使用できます。さらに、ID Contextを使用して、新しい送信者およびRecipient Contextにランダム性を導入できます（付録B.2を参照）。 ID Contextは任意に長くできます。
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メッセージに変換し、逆方向の変換も行います。特定のプロキシ操作を可能にしながら、元のメッセージを可能な限り保護します（セクション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.
送信エンドポイントは、Class EのメッセージフィールドをOSCOREメッセージ内のCOSEオブジェクトの暗号文に含めなければなりません (MUST)。Class IのメッセージフィールドはAEAD AlgorithmのAADに含めなければなりません (MUST)。これにより受信エンドポイントは、転送中に値が変更されたか検出できます。Class Uのメッセージフィールドは転送中に保護してはなりません (MUST NOT)。Class IおよびClass 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として (特別な処理なしで) 処理されるものとします (MUST)。新しいCoAPオプションの仕様では、それがOSCOREでどのように処理されるかを定義すべきです (SHOULD)。新しいCoAPオプションは、プロキシによる処理を必要としない限り、クラスEであるべきです (SHOULD)。新しいCoAPオプションがクラスUである場合、そのオプションが保護されないことによる潜在的な問題を文書化すべきです (SHOULD) (付録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メッセージから内部オプションメッセージフィールドを削除しなければなりません (MUST)。
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の説明に従ってエンコードしなければなりません (MUST)。デルタは、以前に含まれていた外部オプションメッセージフィールドのインスタンスとの差です。
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.
Class Iオプションのメッセージフィールドだけを完全性保護する手順は、セクション5.4で規定されています。繰り返し可能なClass Iオプションを導入する仕様では、プロキシがCoAPメッセージ内のそのオプションの各インスタンスの順序を変更してはならない (MUST NOT) と規定しなければなりません (MUST)。
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 message fieldは、プロキシがアクセスできないオプションを使って、サーバーからクライアントまでのエンドツーエンドで応答をキャッシュできる最大時間（[RFC7252]で定義）を示します。Inner Max-Ageは、セクション4.1.1で規定する通常のInner optionとしてOSCOREで処理しなければなりません (MUST)。
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 message fieldは、OSCOREを認識しない中間ノードでのOSCORE処理が引き起こすエラー応答の不要なキャッシュを避けるために使います。エラー応答はキャッシュ可能ですが、それをキャッシュした中間ノードで後続のOSCORE要求がキャッシュヒットすることはありません。そのため、サーバーはセクション7.4、8.2、8.4で説明するエラー応答に、値0のClass U Max-Age message fieldを設定してもよいです (MAY)。Outer Max-Ageを0にすると、中間ノードが応答を無駄にキャッシュせずに済みます。成功したOSCORE応答にOuter Max-Age optionを含める必要はありません。Observe option（セクション4.1.3.5を参照）を使わない場合、OSCOREを認識しない中間ノードには応答が2.04 (Changed)として見えます。これはキャッシュ不可です（セクション4.2を参照）。キャッシュ可能なObserve応答では、不要なプロキシキャッシュを避けるため、値0のOuter Max-Age optionを使うことがあります。
The Outer Max-Age message field is processed according to Section 4.1.2.
Outer Max-Age message fieldは、セクション4.1.2に従って処理されます。
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アドレス/ポート、request schemeなど）の操作によって、意図しないサーバーがOSCOREメッセージを検証できる状態になってはなりません (MUST NOT)。サーバーごとに異なるSecurity Contextを使わなければなりません (MUST)。
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が存在する場合、クライアントはまず、[RFC7252]のセクション6.4に従って、元のCoAPメッセージのProxy-Uri値をProxy-Scheme、Uri-Host、Uri-Port、Uri-Path、およびUri-Queryオプションに分解しなければなりません (MUST)。
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オプションであり、内部オプションとして保護および処理しなければなりません (MUST)（セクション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の外部オプションとして処理しなければなりません (MUST)（セクション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.
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 = "resource"
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 = "resource"
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].
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メッセージをフラグメント化できます (MAY)（セクション4.1.2）。Outer Block optionsは、暗号化も整合性も保護されないことに注意してください。その結果、受信側エンドポイントがOSCOREメッセージを作成してその整合性を検証できるようにするには、受信側エンドポイントが最後のブロック（[RFC7959]を参照）を受信する必要があるため、プロキシが無期限にブロックフラグメントを悪意を持って挿入する可能性があります。したがって、OSCOREと[RFC7959]をサポートするアプリケーションは、エンドポイントで処理できるメッセージの最大サイズを考慮して、フラグメント化されていない最大メッセージサイズ（MAX_UNFRAGMENTED_SIZE）を定義するセキュリティポリシーを指定しなければなりません (MUST)。このサイズを超えるメッセージは、Inner Block optionsを使用して送信エンドポイントでフラグメント化すべきです (SHOULD)（セクション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.
Outer Block optionを含むOSCOREメッセージを受信したエンドポイントは、すべてのブロックを受信するか、ブロックの累積メッセージサイズがMAX_UNFRAGMENTED_SIZEを超えるまで、まず[RFC7959]に従ってこのオプションを処理しなければなりません (MUST)。すべてのブロックを受信した場合は、本書の規定に従ってOSCOREメッセージの処理を続けます。累積サイズが上限を超えた場合、メッセージを破棄しなければなりません (MUST)。
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)。
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.
エンドポイント間のObserve optionの値を保護するため、Inner Observeを使用しなければなりません (MUST)。中間ノードによる転送を可能にするため、Outer Observeを使用しなければなりません (MUST)。
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.
サーバーは、Observe登録への応答（Observe optionの有無を問いません）に新しいPartial IV（セクション5を参照）を含めなければなりません (MUST)。ただし、最初の応答ではPartial IVを省略してもよいです (MAY)。
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に、Observe optionと一連のETagオプションを除いて、すべてのオプションが登録リクエストのオプションと同一でなければならない (MUST)ことを指定しています。 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).
Observe option付きのPOSTは定義されていないため、Observe option付きのメッセージの場合、Outer Codeは要求の場合は0.05（FETCH）、応答の場合は2.05（コンテンツ）に設定しなければなりません (MUST)（セクション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).
要求の内部および外部Observe optionには、元のCoAP要求の監視値が含まれていなければなりません (MUST)。 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を使用しなければならず (MUST)（セクション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 Security Contextにアクセスできるとは想定されていません。そのため、中間ノードは、受信エンドポイントで他方のエンドポイントが送信元であると検証されるOSCORE option付き要求を作成したり、応答を変換したりできません。これにより、Observe処理には次の結果と制約があります。
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で保護されたObserve notification（[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保護付きObserve登録（値0のObserve option）を開始できません。OSCORE対応中間ノードはObserve登録を開始してはなりません (MUST NOT)（セクション10を参照）。OSCORE非対応プロキシがクライアントの古い登録メッセージを再送すると、サーバーのリプレイ保護が作動します。プロキシが登録を取り消してしまうのを防ぐため、サーバーは再送された登録要求に対し、キャッシュ済み通知を再送してもよいです (MAY)。または、新しい通知を送信してもよいです (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保護付きObserve cancellation（値1のObserve option）を開始できません。アプリケーションは、中間ノードによるObserve登録のキャンセルを許可してもよいです (MAY)。たとえば、[RFC7641]のセクション3.6に従い、値1のObserve optionを送信できます。ただし、RST messageを送信するなど別の方法もあります。本書の範囲外です。
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.
サーバーがObserve登録を受け入れた場合、最初の通知を除くすべての通知（成功応答、エラー応答の両方）にPartial IVを含めなければなりません (MUST)。最初の通知ではPartial IVを省略してもよいです (MAY)。リプレイを防ぐため、クライアントは登録した各ObservationについてNotification Numberを保持しなければなりません (MUST)。Notification Numberは、対応するObserve登録について受信した通知のPartial IVの最大値を保持する0以上の整数です。通知のリプレイ保護の詳細はセクション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.
通知ではInner Observe optionの値を空にしなければなりません (MUST)（[RFC7252]のセクション3.2を参照）。中間ノードが1つの要求に複数の応答を転送できるよう、通知にはOuter Observe optionが必要です。この値は元のCoAPメッセージのObserve optionの値に設定してもよいです (MAY)。クライアントはPartial IVを比較して通知の順序とリプレイを検証し、Outer Observe optionの値を無視しなければなりません (MUST)。
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.
クライアントが内部Observe optionなしで監視要求への応答を受信した場合、クライアントはセクション8.4で指定されているように、応答を非監視応答として検証します。クライアントが「Inner Observe」オプションを使用した非監視要求への応答を受信すると、セクション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.
クライアントは、到着順にかかわらず、最大のPartial IVを持つ通知を最新と見なさなければなりません (MUST)。既存のObserve実装との互換性のため、OSCOREクライアント実装はObserve optionの値をPartial IVの下位3バイトに設定してもよいです (MAY)。実装では、Partial IVのない通知を最も古いものとして扱う必要があります。
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を使う場合、Innerに配置しなければなりません (MUST)。Inner No-Responseはセクション4.1.1に従ってOSCOREで処理しなければなりません (MUST)。Outer optionは存在すべきではありません (SHOULD NOT)。サーバーはOuter No-Response optionを無視しなければなりません (MUST)。Inner値が26の場合、クライアントはOuter No-Responseの値を26（既知のすべてのコードを抑制）に設定してもよいです (MAY)。応答がないために宛先側でタイムアウトが発生し、中間ノードから5.04 (Gateway Timeout)エラーが届く場合に備え、クライアントはそのメッセージを受信して破棄できなければなりません (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 optionは、OSCORE処理が実行されたことを示すためOSCOREメッセージに含めるものとしてのみ定義されています。OSCORE optionの内容全体は暗号化も完全性保護もされませんが、その一部は保護されます（セクション5.4を参照）。OSCOREの入れ子使用はサポートされません。OSCORE処理中に元のCoAPメッセージ内のOSCORE optionを検出した場合、処理を停止しなければなりません (MUST)。
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ヘッダーフィールドCodeはOSCOREで保護されます。中間ノードによる盗聴や改変（GETからDELETEへの変更など）を防ぐため、Codeを暗号化し、完全性を保護しなければなりません (MUST)（Class 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メッセージのCodeをCOSEオブジェクトの平文に書き込まなければなりません (MUST)（セクション5.3を参照）。その後、送信エンドポイントはOSCOREメッセージにOuter Codeを書き込みます。セクション4.1.3.5の例外を除き、要求ではOuter Codeを0.02 (POST)、応答では2.04 (Changed)に設定しなければなりません (MUST)。受信エンドポイントはOSCOREメッセージのOuter Codeを破棄し、COSEオブジェクトの平文（セクション5.3）にあるCodeを復号後のCoAPメッセージに書き込まなければなりません (MUST)。
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ヘッダーフィールドは保護されません（Class U）。送信エンドポイントは、元のメッセージのその他すべてのヘッダーフィールドをOSCOREメッセージのヘッダーに書き込まなければなりません (MUST)。受信エンドポイントは、受信したOSCOREメッセージのヘッダーフィールドを復号後のCoAPメッセージのヘッダーに書き込まなければなりません (MUST)。
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メッセージにPayloadがある場合、暗号化して完全性を保護しなければなりません (MUST)。したがって、PayloadはInner message fieldです。送信エンドポイントは元のCoAPメッセージのPayloadをCOSEオブジェクトの入力平文に書き込みます（セクション5.3を参照）。受信エンドポイントはCOSEオブジェクトを検証して復号し、元のCoAPメッセージのPayloadを復元します。
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のエンドポイントがシグナリングメッセージのエンドポイントと一致する場合に、シグナリングを保護するために使用できます (MAY)。 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]に準拠するため、最初に空のCapabilities and Settings Message (CSM)を送信しなければなりません (MUST)。その後のシグナリングメッセージは保護しなければなりません (MUST)。
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要求メッセージとして保護されなければなりません (MUST)。次に、それはCoAP応答メッセージとして保護されなければなりません (MUST)。たとえば、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 シグナリングメッセージのOuter Codeは、以前のシグナリングメッセージへの応答でない限り、0.02（POST）に設定しなければなりません (MUST)。その場合、2.04（変更）に設定しなければなりません (MUST)。
o All signaling options, except the OSCORE option, SHALL be Inner (Class E).
o OSCOREオプションを除くすべてのシグナリングオプションは、内部（クラスE）でなければなりません (MUST)。
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.
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の場合、Sender KeyとRecipient Keyの長さは128ビットです。 AEAD nonceおよびCommon IVの長さは13バイトです。最大Sender Sequence Numberは、セクション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オブジェクトでなければなりません (MUST)。
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.
* 「Partial IV」パラメーター。値はSender Sequence Numberに設定されます。バイト文字列0x00にエンコードされるPartial IV値0の場合を除いて、値0のすべての先行バイトは、Partial IVをエンコードするときに削除されなければなりません (MUST)。
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)).
このパラメータはリクエストに存在しなければならず (MUST)、通常は応答には存在しません（2つの例外については、通知の監視（セクション4.1.3.5.2）およびReplay Windowの同期（付録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].
* 「kid」パラメータ。値はSender IDに設定されます。このパラメーターは要求に存在しなければならず (MUST)、通常、応答には存在しません。 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.
* 任意で、'kid context' パラメータ (セクション5.1を参照)。このパラメータは要求に存在してもよく (MAY)、存在する場合はID Contextを含まなければなりません (MUST) (セクション3.1を参照)。このパラメータは応答には存在すべきではありません (SHOULD NOT)。応答で 'kid context' をどのように使用できるかの例は付録B.2に示されています。要求に 'kid context' が存在する場合、サーバーは要求を検証する際にそのID Contextを持つSecurity Contextを使用するものとします (MUST)。
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 nonce（セクション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 Contextを使用してSecurity Contextを区別することが可能です（場合によっては、セクション3.3を参照）。例えば：
o If the client has a unique identifier in some namespace, then that identifier can be used as ID Context.
o クライアントのネームスペースに一意の識別子がある場合、その識別子はID Contextとして使用できます。
o The ID Context may be used to add randomness into new Sender and Recipient Contexts, see Appendix B.2.
o ID Contextは、新しい送信者およびRecipient Contextにランダム性を追加するために使用できます。付録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 Contextとして使用され、複数のグループに属するサーバーに対して異なるSecurity Contextを有効にします。
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).
Sender IDとID Contextは、必要な入力パラメータを確立するため、およびSecurity Contextの導出に使用されます（セクション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 Contextを転送するために使用されます。図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オブジェクトの共通ヘッダーパラメーター「kid context」
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 Contextが空でなく、クライアントが「kid context」なしでリクエストを送信した結果、サーバーがSecurity Contextを見つけられなかったことを示すエラーが発生した場合、クライアントは別のID Contextを「kid context」に含めることができます。リクエスト。エラーは保護されていないため、なりすましされ、実際の応答がパス上の攻撃者によってブロックされた可能性があることに注意してください。
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. Partial 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）を生成したエンドポイントのSender IDの左に、正確にnonce長から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バイト以上のnonceを使用するAEADアルゴリズムのみがサポートされていることに注意してください。 S、ID_PIV、およびPIVとエンドポイント固有のIDおよび暗号化キーを使用したnonce構成により、特定のキーで使用されるnonceが一意であることを簡単に確認できます。付録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が応答に存在しない場合、要求からのnonceが使用されます。通知ではない応答の場合（つまり、要求に対する単一の応答がある場合）、要求と応答は通常、メッセージのオーバーヘッドを減らすために同じnonceを使用する必要があります。どちらの方法でも、必要なセキュリティプロパティがすべて提供されます。セクション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：AEADnonce形成
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配列でなければなりません (MUST)。
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に設定しなければなりません (MUST)。その他の値は、将来のバージョン用に予約されています。
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：交換に使用されるSecurity Contextからの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など）は、すべての要求で整合性を保護する必要はありません。
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".
Concise Binary Object Representation (CBOR) [RFC7049]は、小さなメッセージサイズと拡張性を両立させます。CBOR Object Signing and Encryption (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 optionの値には、OSCORE flag bits、Partial IV parameter、kid context parameter（長さと値）、およびkid parameterを次の形式で含めなければなりません (MUST):
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フラグビットを含む最初のバイトは、次のビットセットと「Partial 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ビットは、Partial 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番目のビットはkid flag kです。圧縮COSEオブジェクトにkidが含まれる場合、このビットを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番目のビットはkid context flag hです。圧縮COSEオブジェクトにkid context（セクション5.1を参照）が含まれる場合、このビットを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番目のビットは将来の使用のために予約されています。使用しない場合、これらのビットを0に設定しなければなりません (MUST)。この仕様では、これらのビットのいずれかが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バイトは、Partial IVが存在する場合（n> 0）、Partial 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 kid context flagが設定されている場合（h = 1）、次の1バイトでkid context（セクション5.1）の長さsを符号化します。
o The following s bytes encode the 'kid context', if the 'kid context' flag is set (h = 1).
o kid context flagが設定されている場合（h = 1）、続くsバイトでkid contextを符号化します。
o The remaining bytes encode the value of the 'kid', if the 'kid' is present (k = 1).
o kidが存在する場合（k = 1）、残りのバイトでkidの値を符号化します。
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.
kidは、予約ビットを使用して追加フィールドを設ける場合でも、OSCORE optionの値の最後のフィールドでなければなりません (MUST)。
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メッセージのPayloadには、COSEオブジェクトの暗号文を符号化しなければなりません (MUST)。
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 header compressionの例を示します。例ではCOSE_Encrypt0オブジェクトが確定している（CoAPメッセージと暗号材料が既知である）ものとします。完全な保護前CoAPメッセージやSecurity Contextは示さず、圧縮処理に必要な入力、すなわちCOSE_Encrypt0オブジェクトだけを示します。出力はセクション6で定義する圧縮COSEオブジェクトであり、OSCORE optionとPayloadという2つのCoAPフィールドに分けて運ばれます。
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)
Flag byte: 0b00001001 = 0x09 (1 byte)
Option Value: 0x090525 (3 bytes)
Option Value: 0x090525 (3 bytes)
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
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)
Flag byte: 0b00001001 = 0x09 (1 byte)
Option Value: 0x0900 (2 bytes)
Option Value: 0x0900 (2 bytes)
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
3. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = empty string, Partial IV = 0x05, and kid context = 0x44616c656b
3. 暗号文= 0xaea0155667924dff8a24e4cb35b9、キッド=空の文字列、Partial IV = 0x05、kid context= 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)
Flag byte: 0b00011001 = 0x19 (1 byte)
Option Value: 0x19050544616c656b (8 bytes)
Option Value: 0x19050544616c656b (8 bytes)
Payload: 0xae a0155667924dff8a24e4cb35b9 (14 bytes)
Payload: 0xae a0155667924dff8a24e4cb35b9 (14 bytes)
4. Response with ciphertext = 0xaea0155667924dff8a24e4cb35b9 and no Partial IV
4. 暗号文= 0xaea0155667924dff8a24e4cb35b9の応答、Partial IVなし
Before compression (18 bytes):
圧縮前（18バイト）：
[ h'', {}, h'aea0155667924dff8a24e4cb35b9', ]
[ h'', {}, h'aea0155667924dff8a24e4cb35b9', ]
After compression (14 bytes):
圧縮後（14バイト）：
Flag byte: 0b00000000 = 0x00 (1 byte)
Flag byte: 0b00000000 = 0x00 (1 byte)
Option Value: 0x (0 bytes)
Option Value: 0x (0 bytes)
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
5. Response with ciphertext = 0xaea0155667924dff8a24e4cb35b9 and Partial IV = 0x07
5. 暗号文= 0xaea0155667924dff8a24e4cb35b9およびPartial 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)
Flag byte: 0b00000001 = 0x01 (1 byte)
Option Value: 0x0107 (2 bytes)
Option Value: 0x0107 (2 bytes)
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
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に要求のkidとPartial IVを含め、応答を要求に結び付けます。そのためサーバーは、すべての応答を送信し終えるまで、要求のkidとPartial 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に対して2回以上使用してはなりません (MUST NOT)。 (key, nonce)の組が一意になることは付録D.4で示します。特に、これはPartial IV（Sender Sequence Numberを符号化します。セクション5を参照）の正しい使用に依存します。メッセージを並行処理する場合、Sender Sequence Numberの読み取りと増分は不可分に実行しなければなりません (MUST)。
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.
最大Sender Sequence Numberはアルゴリズムに依存し（セクション12を参照）、2^40未満でなければなりません (MUST)。Sender Sequence Numberが上限を超えた場合、エンドポイントは該当するSender Contextを使ったメッセージ処理を続けてはなりません (MUST NOT)。必要であれば、その前に新しいSecurity Contextを取得すべきです (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は、リクエストがSecurity Contextより古くないことの保証のみを提供します。要求の鮮度（アクチュエータの制御など）に対する要求が強いアプリケーションでは、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つだけの場合）では、これにより絶対的な鮮度が得られます。通知では時間とともに絶対的な鮮度が弱まるため、クライアントが定期的にObserve登録を更新することが推奨されます (SHOULD)。メッセージの結び付けでは、不正動作をするサーバーが要求を受信する前に応答を作成していないことまでは保証されません。つまり、サーバーが稼働中かどうかは検証しません。
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).
要求のリプレイを防ぐため、サーバーのRecipient ContextにはReplay Windowが含まれます。サーバーは、COSEオブジェクトのPartial IV parameter（セクション6.1を参照）で受信したSender Sequence Numberが未受信であることを検証しなければなりません (MUST)。検証に失敗した場合、サーバーは要求の処理を停止しなければなりません (MUST)。また、任意で4.01 (Unauthorized)エラーを返してもよいです (MAY)。さらに、応答をキャッシュしないよう中間ノードに知らせるため、Outer Max-Age optionを0に設定してもよいです (MAY)。診断Payloadに文字列 "Replay detected" を含めてもよいです (MAY)。Replay Windowのサイズと種類はユースケースとOSCOREメッセージを運ぶプロトコルによって異なります。TCPのようにエンドポイント間で信頼性と順序が保証されるトランスポートの場合、サーバーは最後に受信したPartial IVだけを保存し、新たに受信するPartial IVがその値に1を加えた値と一致することを要求してもよいです (MAY)。信頼性のあるトランスポートとないトランスポートが混在し、メッセージが失われる可能性がある場合、この方式は制約が厳しすぎることがあり、既定のReplay Windowの方が適切です（セクション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.
応答（Partial IVの有無にかかわらず）は、要求にバインドされているため、リプレイから保護され、単一の応答のみが受け入れられます。この場合、Partial IVは応答のリプレイ保護には使用されません。
The operation of validating the Partial IV and updating the replay protection MUST be atomic.
Partial IVを検証し、リプレイ保護を更新する操作は、アトミックでなければなりません (MUST)。
The following applies additionally when the Observe option is supported.
Observe optionがサポートされている場合、以下が追加で適用されます。
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.
Notification Number（セクション4.1.3.5.2を参照）は、登録要求への応答として最初に正常に検証された通知のPartial IVで初期化されます。クライアントはPartial IVのないObserve notificationを最大1つだけ受け入れ、それを受信済み通知のうち最も古いものとして扱わなければなりません (MUST)。Partial IVを含む通知を受信したクライアントは、そのPartial IVを該当するObserve登録のNotification Numberと比較しなければなりません (MUST)。以前に受信したPartial IVを持つ通知は処理を停止しなければなりません (MUST)。アプリケーションは、Notification Numberより大きいPartial IVを持つ通知だけをクライアントが処理するよう決めてもよいです (MAY)。
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.
応答の検証に成功し、受信したPartial IVがNotification Numberより大きい場合、クライアントは対応するNotification Numberを受信したPartial IVで上書きしなければなりません (MUST)。
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 keyでAEAD nonceを再利用したり、リプレイされたメッセージを受け入れたりしないよう、エンドポイントはSender Sequence NumberやReplay Windowなど、頻繁に変化するSecurity Contextの一部を失った場合に対処する必要があります。これらは通常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. エンドポイントは、Security Contextの可変部分（Sender Sequence NumberとReplay Window）を更新したうえで、既存のSecurity Contextを再利用できます。そのためには、デバイスの寿命を通じて可変部分を利用可能にするか、可変データを失った後に新しいSecurity Contextを確立できる必要があります。不揮発性メモリを慎重に使う例は付録B.1.1に、Echo optionを使う例は付録B.1.2に示します。不揮発性メモリに保存したSecurity Contextの一部を使うエンドポイントは、以前のSender Sequence Numberを再利用してはならず (MUST NOT)、以前に受信したメッセージを受け入れてはなりません (MUST NOT)。
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. エンドポイントは、既存の共有Master Secretを再利用し、新しい送信者と受信者のコンテキストを導出できます。例については、付録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. エンドポイントは、完全に新しいSecurity Contextがそこから導出される新鮮なMaster Secretをもたらす転送秘密を提供する鍵交換プロトコルを実行できます。これは、ランダム性の優れたソースを必要とし、さらに、プロトコルの送信および処理は、例えば、電力消費に関して無視できないほどのコストを伴う場合がある。
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]と同様に、Tokenと送信元/宛先の組を使って応答を要求に対応付けるため、両エンドポイントは (Token, {Security Context, request Partial IV}) の対応関係を保持しなければなりません (MUST)。これによりSecurity Contextを特定し、応答を保護または検証するAADを計算できます。応答の保護または検証に成功した後は、この対応関係を破棄してもよいです (MAY)。ただしObserve処理では、Observationが有効な間、この対応関係を保持しなければなりません (MUST)。
The processing of the Sender Sequence Number follows the procedure described in Section 3 of [IV-GEN].
Sender Sequence Numberの処理は、[IV-GEN]のセクション3で説明されている手順に従います。
Given a CoAP request, the client SHALL perform the following steps to create an OSCORE request:
CoAP要求を受け取ったクライアントは、OSCORE要求を作成するため、次の手順を実行しなければなりません (MUST):
1. Retrieve the Sender Context associated with the target resource.
1. ターゲットリソースに関連付けられたSender Contextを取得します。
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. Partial IV（ネットワークバイト順のSender Sequence Number）をエンコードし、Sender Sequence Numberを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. Sender Keyを使用して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 optionを含む要求を受信したサーバーは、次の手順を実行しなければなりません (MUST):
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. 受信メッセージ内のCodeと、Class Eに属するすべてのオプション（図5の列Eにxが付されたもの）を破棄します。たとえば、If-Match Outer optionは破棄しますが、Uri-Host Outer optionは破棄しません。
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 parameterに含まれるRecipient IDに対応するRecipient Contextを取得します。kid contextがあれば、それも使います。たとえば付録B.2の方法で新しいSecurity Contextを導出し、Recipient Contextを取得してもよいです (MAY)。展開またはCOSEメッセージの復号に失敗した場合、あるいは受信したkid parameterに対応するRecipient Contextを取得できない場合、サーバーは要求処理を停止しなければなりません (MUST)。
* 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 (Bad Option)エラーを返してもよいです (MAY)。Outer Max-Age optionを0に設定してもよいです (MAY)。診断Payloadには文字列 "Failed to decode COSE" を含めてもよいです (MAY)。
* 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 parameterに対応するRecipient IDのRecipient Contextを取得できない場合、サーバーは4.01 (Unauthorized)エラーを返してもよいです (MAY)。Outer Max-Age optionを0に設定してもよいです (MAY)。診断Payloadには文字列 "Security context not found" を含めてもよいです (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で説明されているように、Replay Windowを使用する前に、Partial 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オブジェクトで受信したRecipient 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に従って、Recipient Keyを使用して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".
* 復号に失敗した場合、サーバーは要求処理を停止しなければならず (MUST)、4.00 (Bad Request)エラーを返してもよいです (MAY)。Outer Max-Age optionを0に設定してもよいです (MAY)。診断Payloadには文字列 "Decryption failed" を含めてもよいです (MAY)。
* If decryption succeeds, update the Replay Window, as described in Section 7.
* 復号化が成功した場合は、セクション7の説明に従って、Replay Windowを更新します。
7. Add decrypted Code, options, and payload to the decrypted request. The OSCORE option is removed.
7. 復号したCode、オプション、Payloadを復号後の要求に加え、OSCORE optionを取り除きます。
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応答を作成するため次の手順を実行しなければなりません (MUST)。CoAP処理（セクション8.2の手順8）から生成されたエラー応答も成功応答と同様に保護します。一方、OSCORE処理エラー（セクション8.2の手順2、3、6）は以下の手順を使わず、OSCORE処理なしの通常のCoAP応答として送信します。
1. Retrieve the Sender Context in the Security Context associated with the Token.
1. トークンに関連付けられたSecurity ContextでSender Contextを取得します。
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 nonceを計算します。
* 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.
* Partial IV（ネットワークバイト順のSender Sequence Number）をエンコードし、Sender Sequence Numberを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. Sender Keyを使ってCOSEオブジェクトを暗号化し、セクション6に従って圧縮します。新しいPartial IVからAEAD nonceを構成した場合、そのPartial IVをメッセージに含めなければなりません (MUST)。要求から取得した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.応答がObserve notificationの場合：
o If the response is the first notification:
o 応答が最初の通知の場合：
* compute the AEAD nonce as described in Section 5.2:
* セクション5.2の説明に従って、AEAD nonceを計算します。
+ 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.
+ Partial IV（ネットワークバイト順のSender Sequence Number）をエンコードし、Sender Sequence Numberを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.
* Partial IV（ネットワークバイト順のSender Sequence Number）をエンコードし、Sender Sequence Numberを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 optionを含む応答を受信したクライアントは、次の手順を実行しなければなりません (MUST):
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. 受信メッセージ内のCodeと、Class Eに属するすべてのオプション（図5の列Eにxが付されたもの）を破棄します。たとえば、ETag Outer optionとMax-Age Outer optionを破棄します。
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. トークンに関連付けられたSecurity ContextでRecipient Contextを取得します。 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 nonceを計算する
* 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.
* 応答にPartial IVがある場合、COSEオブジェクトで受信したRecipient ID、Common IV、およびPartial IVからAEAD nonceを計算します。
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に従って、Recipient Keyを使用して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. 先行するエラー条件のいずれかが該当する場合、クライアントは応答の処理を停止しなければなりません (MUST)。
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]に従ってOuter Block optionsを処理します。
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. 先行するエラー条件のいずれかが該当する場合、クライアントは応答の処理を停止しなければなりません (MUST)。Observation要求への応答処理中にエラーが起きても、そのObservationはキャンセルされません。失敗したとき、クライアントは直ちにObservationを再登録してはなりません (MUST NOT)。
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の実行に必要なSecurity Context資料やその他の情報は含まれていません。
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 attributeには値を指定してはなりません (MUST NOT)。値が指定されている場合、パーサーはその値を無視しなければなりません (MUST)。osc attributeを1つのlink-valueに複数回含めてはなりません (MUST NOT)。2つ目以降の出現は、パーサーが無視しなければなりません (MUST)。
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].
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]で定義されている（外部）Observe optionのプロキシ処理は、セクション4.1.3.5で指定されています。
Optionally, a CoAP proxy MAY detect OSCORE and act accordingly. An OSCORE-aware CoAP proxy:
オプションで、CoAPプロキシはOSCOREを検出し、それに応じて動作する場合があります (MAY)。 OSCORE対応のCoAPプロキシ：
o SHALL bypass caching for the request if the OSCORE option is present.
o 要求にOSCORE optionがある場合、OSCORE対応CoAPプロキシはその要求のキャッシュを迂回しなければなりません (MUST)。
o SHOULD avoid caching responses to requests with an OSCORE option.
o OSCORE optionを含む要求への応答をキャッシュすべきではありません (SHOULD)。
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 Observeの場合、OSCORE対応CoAPプロキシはObserve登録を開始してはなりません (MUST NOT)。
o MAY verify the order of notifications using Partial IV rather than the Observe option.
o Observe optionではなくPartial IVを使用して、通知の順序を確認できます (MAY)。
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.
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
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 header fieldはホップ間だけのフィールドではないため、Connection header field（[RFC7230]のセクション6.1を参照）に列挙するのは適切ではありません。OSCOREメッセージは通常キャッシュから提供しても有用ではなく（通常は Cache-Control: no-cache と指定されます）、Varyとの連携も関係ありません（[RFC7231]のセクション7.1.4を参照）。HTTP OSCORE header fieldはメッセージ処理に不可欠です。Trailerが無視されるとメッセージが使えなくなるため、これをheaderからtrailerへ移してはなりません（[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ヘッダーフィールドは通常、リダイレクト間で保持されません。
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 リダイレクトのターゲットには、メッセージの復号化と検証に必要なOSCORESecurity Contextがあります。
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 bodyを保持する必要があるため、HTTPサーバーは301 (Moved Permanently)や302 (Found)ではなく、307 (Temporary Redirect)または308 (Permanent Redirect)を返すことが推奨されます (SHOULD)。
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 optionが空ならAA。それ以外の場合:
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を参照）に設定されます。
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 header fieldの値がAAで表される単一のゼロバイト（0x00）の場合は空。それ以外の場合:
o The CoAP Content-Format option is omitted, the content format for OSCORE (Section 13.6) MUST NOT be used.
o CoAP Content-Format optionは省略しなければなりません。OSCORE用Content-Format（セクション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 Content Content-Format: 0 Payload: Exterminate! Exterminate!
[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 Changed OSCORE: [empty] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[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 Status Code 200 (OK)はCoAP Code 2.04 (Changed)に対応します。一方、最後のメッセージのHTTP Status Code 200 (OK)はCoAP Code 2.05 (Content)に対応し、このコードはHTTP responseのbodyに含まれる圧縮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 Changed OSCORE: [empty] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[CoAP response -- After client object security processing]
[CoAP応答-クライアントオブジェクトセキュリティ処理後]
2.05 Content Content-Format: 0 Payload: Exterminate! Exterminate!
2.05 Content Content-Format: 0 Payload: Exterminate! Exterminate!
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を組み合わせれば、エンドポイントと中間ノードの間で転送されるメッセージ全体をホップ単位で保護しつつ、Payloadをエンドツーエンドで保護できます。特にHTTPでOSCOREを使う場合、HTTP endpointとCoAPへの変換プロキシの間など、HTTP hopにTLS保護を追加することが推奨されます (SHOULD)。
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を使用してメッセージを保護するには、確立されたSecurity Contextが必要です。セクション3.2で説明されているSecurity Contextを確立する方法は、共通のMaster Secretと一意のSender IDに基づいています。必要な入力パラメーターは、送信者/Recipient IDの確立で補強されたキー確立プロトコルを使用して、事前に確立または取得できます。たとえば、鍵交換プロトコルや、制約付き環境の認証と承認（ACE）フレームワークのOSCOREプロファイル[OSCORE-PROFILE] 。このような手順では、エラーが発生した場合でも、使用目的のSecurity Contextパラメータの要件に準拠していることを確認する必要があります（セクション3.3を参照）。Recipient IDは異なるSecurity Context間で一致することが許可されていますが（セクション3.3を参照）、これにより、サーバーは正しいSecurity Contextを見つけるかメッセージを拒否する前に複数の検証を処理する可能性があります。Master Secretを固定して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).
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].
したがって、OSCOREMaster Secretの主な要件は、シークレットであることに加えて、かなりのランダム性を備えていることです。選択されたキー確立スキームは、Master Secretに必要なプロパティが確実に満たされるようにする必要があります。事前共有鍵の導入や[OSCORE-PROFILE]などの鍵転送ソリューションでは、優れた乱数ジェネレータを使用してMaster Secretをオフラインで生成できます。セキュリティのランダム性要件は[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アルゴリズムでは、メッセージごとに一意のnonceが必要です。この場合、COSEメッセージフィールドの「Partial IV」のSender Sequence Numberが使用されます。受信者が以前に受信したものよりも大きいシーケンス番号を受け入れる場合、シーケンス番号の同期の問題は回避されます。信頼性の高いトランスポートでは、前のシーケンス番号+ 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.
サーバー間でSecurity Contextを共有すると、Replay Windowが同期されていない場合などに、リプレイ攻撃が発生する可能性があることに注意してください。
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.
最大Sender Sequence Numberは、AEADアルゴリズムによって異なります。最大Sender Sequence Numberは2 ^ 40-1、またはアルゴリズム固有の下限です。その後、新しいSecurity Contextを生成する必要があります。 AEAD nonceを構築するメカニズム（セクション5.2）では、nonceは少なくとも56ビットであり、Partial IVは最大で40ビットであると想定しています。実装に必須のAEADアルゴリズムAES-CCM-16-64-128は、CCM *との互換性のために選択されています。予測できないnonceを必要とする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 nonceは、シーケンス番号をキーと共に導出される秘密のコンテキストごとの初期化ベクトル（Common IV）と混合することによって形成されます（参照[RFC8152]のセクション3.1）、および鍵導出でMaster Saltを使用する（概要については[MF00]を参照）。Master Secret、Sender Key、Recipient Key、およびCommon IVは秘密にする必要があり、残りのパラメーターは公開することができます。Master Secretには十分なランダム性が必要です（セクション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 Context、Sender ID、およびPartial IVは常に操作によって少なくとも暗黙的に整合性が保護されます。これは、操作によって誤ったnonceまたはキーが使用され、その結果、復号化が失敗するためです。
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.
Inner Block optionsを使用すると、送信側は大きなメッセージをOSCOREで保護されたブロックに分割できるため、受信側のエンドポイントは完全なメッセージを受信する前にブロックを検証できます。Outer Block optionsを使用すると、エンドポイントでは検証できない任意のプロキシフラグメンテーション操作を実行できますが、Inner Block optionsを使用すると、非常に大きなメッセージを安全にフラグメント化できるため、ポリシーによってサイズを制限できます。通常のリソース検出の一部として、最大メッセージサイズ（送信エンドポイントがメッセージをフラグメント化し、受信エンドポイントがポリシーを遵守している場合は、メッセージを破棄するサイズ）を取得できます。
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 headerにより、たとえばCONとACK（CoAP Message Identifier）の対応付け、要求と応答（Token）の対応付け、トラフィック分析が可能になります。OSCOREは、CoAPにマッピング可能であり、かつClass EであるHTTP header field以外を保護しません。経路上の主体に見えるHTTP message fieldは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 message field、すなわちOSCORE optionは、通信するエンドポイントに関する情報を明らかにする場合があります。たとえば、サーバーが適切なSecurity Contextを見つけるためのkidとkid contextは、クライアントに関する情報を明らかにすることがあります。1つのサーバーに対してkidとkid contextを追跡すると、同じクライアントからの要求を関連付けられる場合があります。
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の方式から、デバイスが再起動したことが分かる場合があります。正常なシャットダウン時にSender Sequence NumberとReplay Windowの正確な状態を保存すれば、この情報漏えいを軽減できます。
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:
kid context parameterを「COSE Header Parameters」レジストリに追加しました。
o Name: kid context
o Name: kid context
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.
このセクションでは、application/oscore media typeを「Media Types」レジストリに登録します。このmedia typeは、内容がOSCOREメッセージであることを示します。OSCORE bodyは、HTTP OSCORE header fieldの値とSecurity Contextがなければ解釈できません。
Type name: application
Type name: application
Subtype name: oscore
Subtype name: oscore
Required parameters: N/A
Required parameters: N/A
Optional parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Encoding considerations: binary
Security considerations: See the Security Considerations section of [RFC8613].
セキュリティに関する考慮事項：[RFC8613]のセキュリティに関する考慮事項のセクションを参照してください。
Interoperability considerations: N/A
Interoperability considerations: N/A
Applications that use this media type: IoT applications sending security content over HTTP(S) transports.
このメディアタイプを使用するアプリケーション：HTTP（S）トランスポートを介してセキュリティコンテンツを送信するIoTアプリケーション。
Fragment identifier considerations: N/A
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
Intended usage: COMMON
Restrictions on usage: N/A
Restrictions on usage: N/A
Author: Goeran Selander <goran.selander@ericsson.com>
Change Controller: IESG
Change Controller: IESG
Provisional registration? No
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 media typeを「CoAP Content-Formats」レジストリに登録します。OSCORE payload用のこのContent-Formatは将来の用途に備えて定義されていますが、OSCOREメッセージ内で使用してはなりません (MUST NOT)。OSCORE payloadはOSCORE optionの値とSecurity Contextがなければ解釈できません。
+----------------------+----------+----------+-------------------+
| 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).
本書で定義するレジストリの専門家レビュアーには、その登録が他の方法ではより良く解決できない妥当なユースケースを満たし、既存の登録と重複せず、実運用で使われる見込みがあることを確認することが期待されます。また、申請されたコードポイントの目的と用途が明確か確認することも期待されます。割り当てを承認する際、専門家は各登録の想定用途を考慮すべきです。符号化値の長さは、その長さで表現できる残りのコードポイント数と、利用対象デバイスの規模を踏まえて評価すべきです。これらの事項が定義されるまで、専門家は8～63の登録を拒否すべきです（つまり、bit 1によるOSCORE flag bits拡張の方式が規定されるまで）。
[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., "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>.
[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, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <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] 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>.
[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. 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>.
[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. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <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] 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>.
[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] 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>.
[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., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <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, September 2015, <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. 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>.
[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., 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>.
[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., 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>.
[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, July 2017, <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., "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>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <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, February 2018, <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, August 2018, <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., 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>.
[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., 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.
[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., "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-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, September 2018.
[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., and K. Hartke, "Requirements for CoAP End-To-End Security", Work in Progress, draft-hartke-core-e2e-security-reqs-03, July 2017.
[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., and G. Selander, "CoAP: Echo, Request-Tag, and Token Processing", Work in Progress, draft-ietf-core-echo-request-tag-04, March 2019.
[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., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, draft-ietf-core-oscore-groupcomm-04, March 2019.
[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., "Generation of Deterministic Initialization Vectors (IVs) and Nonces", Work in Progress, draft-mcgrew-iv-gen-03, October 2013.
[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. 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.
[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., 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.
[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. Dissertation, University of California, Irvine, 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. 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>.
[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., 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>.
[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., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[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>.
[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, August 2012, <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] 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>.
[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., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[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>.
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の例を示します。メッセージ交換は、クライアントとサーバーの間にSecurity Contextが確立されているという想定に基づいて行われます。簡単にするために、これらの例は、（圧縮された）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 request/response CodeはOSCOREで暗号化されるため、OSCOREメッセージのheaderで見えるのはダミーCode (POST/Changed)だけです。Uri-Path option ("alarm_status")とPayload ("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ヘッダーには、メッセージを保護するために使用されたSecurity ContextとPartial 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、続いて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.
Observeメッセージを転送できるよう、ダミーCode (FETCH/Content)を使います。Content-Format option (0)とPayload ("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ヘッダーには、メッセージの保護に使用されるSecurity ContextとPartial IV（15）を示す識別子（ca）が含まれています。 2番目の応答のCOSEヘッダーには、Partial IV（36）が含まれています。最初の応答は、要求のPartial 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.
サーバーは、Partial IVが以前に受信されていないことを確認します。クライアントは、応答が要求にバインドされていること、およびPartial IVが、要求にバインドされた応答で以前に受信したPartial IVよりも大きいことを確認します。ただし、最も古いと見なされるPartial 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ビットの一様にランダムなMaster Keyで十分です。このセクションでは、2つの例を示します。最初の例では、Security ContextはMaster Secretから1回だけ取得されます。 2番目の例では、ランダムな入力を使用してSecurity Contextが複数回導出されます。
An application that only derives the security context once needs to handle the loss of mutable security context parameters, e.g., due to reboot.
Security Contextのみを取得するアプリケーションは、再起動などによる変更可能なSecurity Contextパラメータの損失を処理する必要があります。
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.
Sender Sequence Numberの損失を処理するために、デバイスは、通常の操作中に不揮発性メモリに書き込み、再起動後にSecurity Contextを更新する手順を実装できます。ただし、手順がSecurity Contextパラメーターの要件に準拠している場合（セクション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.
不揮発性メモリへの書き込みに関連する既知の問題があります。たとえば、フラッシュドライブの寿命中は、消去操作の回数に制限があります。また、不揮発性メモリへの書き込み操作が完了するまでの時間は、たとえばキャッシュが原因で予測できない場合があり、デバイスの再起動時に重要なSecurity Contextデータが保存されない可能性があります。
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:
Sender Sequence Numberの再利用を防ぐために、エンドポイントは通常の操作中に次の手順を実行する場合があります。
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で割り切れるSender Sequence Number（Kは正の整数）を使用する前に、Sender Sequence Number（SSN1）を不揮発性メモリに保存します。起動後、エンドポイントは永続的なメモリに格納されている値にK + Fを加えた新しいSender Sequence Number（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は、ストレージ操作の頻度とSender Sequence Numberの効率的な使用との間のトレードオフを提供します。
* 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.
* 不揮発性メモリへの書き込みは、遅延または障害の影響を受ける可能性があります。再起動前に使用された最後のSender Sequence NumberがSSN2を決して超えないように、Fを設定しなければなりません (MUST)。
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が常に再起動前に使用された最後のSender Sequence Numberよりも大きい場合、このセクションで説明されている方法を使用してはなりません (MUST NOT)。
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:
サーバーでSecurity Contextが失われた場合、以前に受信した要求の再生を受け入れないようにするために、サーバーは起動後に次の手順を実行することがあります。
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に指定されているSender Sequence Numberを更新して、エコーオプション（次の箇条書き）を含む応答でPartial 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 格納されたSecurity Contextごとに、サーバーは起動後初めてOSCORE要求を受信し、サーバーはOSCOREで保護された4.01（無許可）で応答し、エコーオプション[CoAP-ECHO-REQ-TAG]のみを含み、診断ペイロードは含まれません。サーバーは、AEAD nonceを生成するときにそのPartial IVを使用しなければならず (MUST)、応答にPartial IVを含めなければなりません (MUST)（セクション5を参照）。 Echoオプションを使用するサーバーが2番目のOSCORE要求を新しいものとして検証できる場合、2番目の要求のPartial IVは、そのSecurity ContextのReplay Windowの下限として設定されます。
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 クライアントは以前の登録を忘れ、すべての通知番号を削除します。その後、クライアントはObserve optionを使用して再度登録します。
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つのMaster Secretから複数のSecurity Contextを派生させることができます。クライアントまたはサーバーが再起動、再稼働、またはエラーが発生した場合でも、Security Contextパラメータの要件を満たさなければなりません (MUST)（セクション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 Context parameterにランダム性を加え、クライアントとサーバー間で事前に共有された入力（特にMaster Secret、Master Salt、Sender/Recipient ID。セクション3.2を参照）と組み合わせて新しいSecurity Contextを導出するプロトコルの例を示します。ランダムな入力はkid context parameterでクライアントとサーバー間を転送します。両エンドポイントに十分な乱数源がない場合、このプロトコルを使ってはなりません (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.
通常の要求では、確立済みSecurity ContextのID Contextをkid contextで送信できます。kid contextとkidを使うと、サーバーが該当するSecurity Contextを特定しやすくなります。クライアントとサーバーの双方がID Contextを知っている前提であれば、セクション5.1のとおりkid contextを省略することもできます。
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.
このセクションで説明するプロトコルは、Security Contextの可変部分がクライアントまたはサーバーで失われた場合（エンドポイントが再起動した場合など）にのみ必要になる場合があります。このプロトコルは、クライアントとサーバーが新しいSecurity Contextを導出する必要がある場合はいつでも使用できます。たとえば、デバイスに1つの固定された入力パラメーターセット（Master Secret、送信者、受信者の識別子を含む）がプロビジョニングされている場合、ランダムなID Contextにより、展開ごとにSecurity Contextが確実に異なります。
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で説明されているようにメッセージの処理を停止するのではなく、既存のSecurity Contextを取得できないときにこのプロトコルを実行するように構成する必要があることに注意してください。
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：新しいSecurity Contextを確立するためのプロトコル
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. （任意）再起動後やサーバーへの初回接続時など、クライアントが有効なSecurity Contextを持たない場合、ランダム文字列R1を生成します。これをID Contextとして、サーバーと共有する入力パラメーターとともに使い、最初のSecurity Contextを導出します。クライアントは、そのSecurity Contextで保護したOSCORE要求をサーバーへ送ります。要求にはR1をCBOR bstrで包み、kid contextとして含めます。この要求の宛先は、Security Context更新用の特別なリソースでもかまいません。
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. クライアントが新しいSecurity Context ID1 = R1を生成した場合や、サーバーがID Context、Sender Sequence Number、Replay WindowなどSecurity Contextの一部を失った場合、サーバーは有効なSecurity ContextのないOSCORE要求を受信します。受信したID1（kid contextで転送）をID Contextとし、受信したkidに対応する入力パラメーターを使って最初のSecurity Contextを導出したうえで要求を検証できた場合（セクション8.2を参照）、サーバーはランダム文字列R2を生成し、ID Context = ID2 = R2 || ID1とする2番目のSecurity Contextを導出します。サーバーはこのSecurity Contextで保護した4.01 (Unauthorized)応答を送り、R2をCBOR bstrで包んでkid contextに含め、R2をキャッシュします。R2を再利用してはなりません (MUST NOT)。再利用するとresponse #1でkeyとnonceが再利用されるおそれがあります。サーバーは1つのSecurity Contextに対応するrequest #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要求への応答を受信します。応答のkid contextには、R2を包んだCBOR bstrが含まれます。クライアントはID Context = ID2 = R2 || ID1として2番目のSecurity Contextを導出します。そのSecurity Contextで応答を検証できた場合（セクション8.4を参照）、クライアントはID Context = ID3 = R2 || R3から導出した3番目のSecurity Contextで要求を保護します。R3はクライアントが生成するランダムなバイト列です。この要求にはR2 || R3をCBOR bstrで包み、kid contextとして含めます。
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. サーバーが、kid contextにID3を包んだCBOR bstrを含み、ID3の先頭部分が以前のresponse #1で送信したR2と一致する要求を受信した場合（その要求は未受信であるものとします）、サーバーはID Context = ID3の3番目のSecurity Contextを導出します。サーバーは再送されたrequest #2を受け入れてはなりません (MUST NOT)。そのSecurity Contextで要求を検証できた場合（セクション8.2を参照）、サーバーはこのクライアント用のSecurity Contextとして登録し、関連するR2をすべてキャッシュから削除します。このSecurity Contextはクライアントとの以前のSecurity Contextに置き換わり、最初と2番目のSecurity Contextは削除されます。サーバーは要求と同じSecurity Contextを使って応答します。
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番目のSecurity Contextで要求への応答を受信し、その応答が検証された場合（セクション8.4を参照）、クライアントはこのサーバーで使用する3番目のSecurity Contextをマークします。このSecurity Contextは、以前のSecurity Contextをサーバーに置き換え、最初と2番目のSecurity Contextは削除されます。
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.
nonceR1、R2、およびR3の長さはアプリケーション固有です。アプリケーションは、その値が繰り返される確率が無視できるように各nonceの長さを設定する必要があります。通常、少なくとも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でSecurity Contextに関連する操作を正常に完了した後、要求のアクションを実行し、応答＃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で導出された）Sender Keyが以前に使用されたことがないことが保証されます。応答＃2を受信すると、クライアントは、応答（ランダムな値R3とMaster Secretから導出されたキーで保護されている）が要求＃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とMaster Secretから導出されたキーで保護されている）が応答＃1に応答してクライアントによって作成されたことを保証します。応答＃2を送信するとき、サーバーは（ランダムな値R2で導出された）Sender Keyが以前に使用されたことがないことが保証されます。
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.
サーバーには、いくつかのSecurity Context用のスペースしかない場合や、並行して実行されるいくつかのプロトコルのみを処理できる場合があります。サーバーは、たとえばパケット損失が原因で、同じ不変のSecurity Contextを使用して複数のリクエスト＃1メッセージを合法的に受信する場合があります。古い要求＃1メッセージの再生は、サーバーが正当なものと区別するのが難しい場合があります。キャッシュされたR2の最大数に達した場合、サーバーはケースを処理する必要があります。サーバーがリクエスト＃1を受信し、それを実行できない場合は、保護されていない5.03（Service Unavailable）エラーメッセージで応答することがあります。サーバーは、R2をキャッシュするときにタイマーを設定するなど、完了しないプロトコル実行から状態をクリアし、タイムアウト時にR2と関連するSecurity Contextをキャッシュから削除する場合があります。さらに、状態情報は再起動時にフラッシュすることができます。
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を生成し、response #1で送り、request #2の受信時にその値を検証できる方式を使うこともできます。この方式は、サーバーが再送されたrequest #2を受け入れる結果になってはなりません (MUST NOT)。以下の構成では、クライアントに対応する不変のSecurity Context parameter一式ごとに秘密の乱数HMAC key K_HMACを使います。この方法では、K_HMAC keysを保存する代わりに、response #2でR2を検証できますが、response #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を次のように生成します。まずサーバーは、Security Contextに対応するK_HMACがまだなければ、ランダムなK_HMACを生成します。次に R2 = S2 || HMAC(K_HMAC, S2) とします。S2はランダムなバイト列で、HMACは8バイトに切り詰めます。K_HMACには有効期限を設定でき、期限後に消去します。R2、S2、および導出した1番目と2番目のSecurity Contextをキャッシュする必要はありません。
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はプロトコル実行が完了するまで（request #2の検証後）、または有効期限が来るまで（早い方）使い、その後消去します。後者は付録B.2の手順4でキャッシュしたR2を削除することに相当し、request #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.
Security Contextを共有する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.
パス上の攻撃者がメッセージを挿入し、エンドポイントにメッセージの検証を処理させる可能性があります。Master Secretにアクセスせずに作成されたメッセージは、検証に失敗します。
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番目のSecurity Contextを生成して応答しますが、クライアントが応答を予期していなければ破棄します。これは、並行実行の状態を管理できなくなるなど、サーバーへのサービス拒否攻撃につながり、正当なクライアント要求を妨げる可能性があります。この点では、request #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.
request #1以外の要求への応答としてresponse #1を再送しても、検証に失敗します。response #1は、ID Contextの依存関係とresponse #1のexternal_aadに含まれるrequest #1のPartial IVによって、そのrequest #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がすでに十分に受信されている場合、サーバーには有効なSecurity Contextがあるため、要求＃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はクライアントとサーバーの両方でSecurity Contextを設定する方法を定義します。
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バイトのMaster Saltが使用されています。デフォルト値は、AEADアルゴリズムとHKDFに使用されます。
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o Sender ID: 0x (0 byte) o Recipient ID: 0x01 (1 byte)
o Sender ID: 0x (0 byte) o Recipient ID: 0x01 (1 byte)
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x8540f60a634b657910 (9 bytes)
o info (for Sender Key): 0x8540f60a634b657910 (9 bytes)
o info (for Recipient Key): 0x854101f60a634b657910 (10 bytes)
o info (for Recipient Key): 0x854101f60a634b657910 (10 bytes)
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
Outputs:
出力：
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o Recipient Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Recipient Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しいPartial IV（送信者と受信者の両方）から：
o sender nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
o sender nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
o recipient nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
o recipient nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o Sender ID: 0x01 (1 byte)
o Sender ID: 0x01 (1 byte)
o Recipient ID: 0x (0 byte)
o Recipient ID: 0x (0 byte)
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
o info (for Recipient Key): 0x8540f60a634b657910 (9 bytes)
o info (for Recipient Key): 0x8540f60a634b657910 (9 bytes)
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
Outputs:
出力：
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o Recipient Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o Recipient Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しいPartial IV（送信者と受信者の両方）から：
o sender nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
o sender nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
o recipient nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
o recipient nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
In this test vector, the default values are used for AEAD Algorithm, HKDF, and Master Salt.
このテストベクトルでは、AEADアルゴリズム、HKDF、およびMaster Saltにデフォルト値が使用されます。
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Sender ID: 0x00 (1 byte)
o Sender ID: 0x00 (1 byte)
o Recipient ID: 0x01 (1 byte)
o Recipient ID: 0x01 (1 byte)
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x854100f60a634b657910 (10 bytes)
o info (for Sender Key): 0x854100f60a634b657910 (10 bytes)
o info (for Recipient Key): 0x854101f60a634b657910 (10 bytes)
o info (for Recipient Key): 0x854101f60a634b657910 (10 bytes)
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
Outputs:
出力：
o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o Recipient Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes)
o Recipient Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes)
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しいPartial IV（送信者と受信者の両方）から：
o sender nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
o sender nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
o recipient nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
o recipient nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Sender ID: 0x01 (1 byte)
o Sender ID: 0x01 (1 byte)
o Recipient ID: 0x00 (1 byte)
o Recipient ID: 0x00 (1 byte)
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
o info (for Recipient Key): 0x854100f60a634b657910 (10 bytes)
o info (for Recipient Key): 0x854100f60a634b657910 (10 bytes)
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
Outputs:
出力：
o Sender Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes)
o Sender Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes)
o Recipient Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o Recipient Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しいPartial IV（送信者と受信者の両方）から：
o sender nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
o sender nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
o recipient nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
o recipient nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
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バイトのMaster Saltと8バイトのID Contextが使用されます。デフォルト値は、AEADアルゴリズムとHKDFに使用されます。
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o Sender ID: 0x (0 byte) o Recipient ID: 0x01 (1 byte)
o Sender ID: 0x (0 byte) o Recipient ID: 0x01 (1 byte)
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x85404837cbf3210017a2d30a634b657910 (17 bytes)
o info (for Sender Key): 0x85404837cbf3210017a2d30a634b657910 (17 bytes)
o info (for Recipient Key): 0x8541014837cbf3210017a2d30a634b657910 (18 bytes)
o info (for Recipient Key): 0x8541014837cbf3210017a2d30a634b657910 (18 bytes)
o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16 bytes)
o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16 bytes)
Outputs:
出力：
o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o Recipient Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o Recipient Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しいPartial IV（送信者と受信者の両方）から：
o sender nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o sender nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o recipient nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o recipient nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
Inputs:
入力：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o Sender ID: 0x01 (1 byte)
o Sender ID: 0x01 (1 byte)
o Recipient ID: 0x (0 byte)
o Recipient ID: 0x (0 byte)
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
From the previous parameters,
以前のパラメータから、
o info (for Sender Key): 0x8541014837cbf3210017a2d30a634b657910 (18 bytes)
o info (for Sender Key): 0x8541014837cbf3210017a2d30a634b657910 (18 bytes)
o info (for Recipient Key): 0x85404837cbf3210017a2d30a634b657910 (17 bytes)
o info (for Recipient Key): 0x85404837cbf3210017a2d30a634b657910 (17 bytes)
o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16 bytes)
o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16 bytes)
Outputs:
出力：
o Sender Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o Sender Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o Recipient Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o Recipient Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
前のパラメーターと0に等しいPartial IV（送信者と受信者の両方）から：
o sender nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o sender nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o recipient nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o recipient nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
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で派生したSecurity Contextを使用した、OSCOREで保護されたCoAP GETリクエストのテストベクタが含まれています。保護されていない要求には、Uri-PathおよびUri-Hostオプションのみが含まれます。
Unprotected CoAP request: 0x44015d1f00003974396c6f63616c686f737483747631 (22 bytes)
Unprotected CoAP request: 0x44015d1f00003974396c6f63616c686f737483747631 (22 bytes)
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o Key Derivation Function: HKDF SHA-256
o Key Derivation Function: HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x (0 byte)
o Sender ID: 0x (0 byte)
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o Sender Sequence Number: 20 The following COSE and cryptographic parameters are derived:
o Sender Sequence Number: 20 The following COSE and cryptographic parameters are derived:
o Partial IV: 0x14 (1 byte)
o Partial IV: 0x14 (1 byte)
o kid: 0x (0 byte)
o kid: 0x (0 byte)
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_array: 0x8501810a40411440 (8 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o plaintext: 0x01b3747631 (5 bytes)
o plaintext: 0x01b3747631 (5 bytes)
o encryption key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o encryption key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
From the previous parameter, the following is derived:
前のパラメーターから、以下が導出されます。
o OSCORE option value: 0x0914 (2 bytes)
o OSCORE option value: 0x0914 (2 bytes)
o ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)
o ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)
From there:
そこから：
o Protected CoAP request (OSCORE message): 0x44025d1f00003974396c6f6 3616c686f7374620914ff612f1092f1776f1c1668b3825e (35 bytes)
o Protected CoAP request (OSCORE message): 0x44025d1f00003974396c6f6 3616c686f7374620914ff612f1092f1776f1c1668b3825e (35 bytes)
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で派生したSecurity Contextを使用した、OSCOREで保護されたCoAP GETリクエストのテストベクタが含まれています。保護されていない要求には、Uri-PathおよびUri-Hostオプションのみが含まれます。
Unprotected CoAP request: 0x440171c30000b932396c6f63616c686f737483747631 (22 bytes)
Unprotected CoAP request: 0x440171c30000b932396c6f63616c686f737483747631 (22 bytes)
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o Key Derivation Function: HKDF SHA-256
o Key Derivation Function: HKDF SHA-256
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x00 (1 bytes) o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o Sender ID: 0x00 (1 bytes) o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o Sender Sequence Number: 20
o Sender Sequence Number: 20
The following COSE and cryptographic parameters are derived:
次のCOSEおよび暗号化パラメーターが導出されます。
o Partial IV: 0x14 (1 byte)
o Partial IV: 0x14 (1 byte)
o kid: 0x00 (1 byte)
o kid: 0x00 (1 byte)
o aad_array: 0x8501810a4100411440 (9 bytes)
o aad_array: 0x8501810a4100411440 (9 bytes)
o AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes)
o AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes)
o plaintext: 0x01b3747631 (5 bytes)
o plaintext: 0x01b3747631 (5 bytes)
o encryption key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o encryption key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o nonce: 0xbf35ae297d2dace910c52e99ed (13 bytes)
o nonce: 0xbf35ae297d2dace910c52e99ed (13 bytes)
From the previous parameter, the following is derived:
前のパラメーターから、以下が導出されます。
o OSCORE option value: 0x091400 (3 bytes)
o OSCORE option value: 0x091400 (3 bytes)
o ciphertext: 0x4ed339a5a379b0b8bc731fffb0 (13 bytes)
o ciphertext: 0x4ed339a5a379b0b8bc731fffb0 (13 bytes)
From there:
そこから：
o Protected CoAP request (OSCORE message): 0x440271c30000b932396c6f6 3616c686f737463091400ff4ed339a5a379b0b8bc731fffb0 (36 bytes)
o Protected CoAP request (OSCORE message): 0x440271c30000b932396c6f6 3616c686f737463091400ff4ed339a5a379b0b8bc731fffb0 (36 bytes)
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 Contextを設定し、それをリクエストで送信する必要があるアプリケーションのOSCOREで保護されたCoAP GETリクエストのテストベクタが含まれているため、保護されたメッセージに「kid context」が存在します。このテストベクトルは、付録C.3で派生したSecurity Contextを使用します。保護されていない要求には、Uri-PathおよびUri-Hostオプションのみが含まれます。
Unprotected CoAP request: 0x44012f8eef9bbf7a396c6f63616c686f737483747631 (22 bytes)
Unprotected CoAP request: 0x44012f8eef9bbf7a396c6f63616c686f737483747631 (22 bytes)
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o Key Derivation Function: HKDF SHA-256 o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o Key Derivation Function: HKDF SHA-256 o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x (0 bytes)
o Sender ID: 0x (0 bytes)
o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o Sender Sequence Number: 20
o Sender Sequence Number: 20
The following COSE and cryptographic parameters are derived:
次のCOSEおよび暗号化パラメーターが導出されます。
o Partial IV: 0x14 (1 byte)
o Partial IV: 0x14 (1 byte)
o kid: 0x (0 byte)
o kid: 0x (0 byte)
o kid context: 0x37cbf3210017a2d3 (8 bytes)
o kid context: 0x37cbf3210017a2d3 (8 bytes)
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_array: 0x8501810a40411440 (8 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o plaintext: 0x01b3747631 (5 bytes)
o plaintext: 0x01b3747631 (5 bytes)
o encryption key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o encryption key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o nonce: 0x2ca58fb85ff1b81c0b7181b84a (13 bytes)
o nonce: 0x2ca58fb85ff1b81c0b7181b84a (13 bytes)
From the previous parameter, the following is derived:
前のパラメーターから、以下が導出されます。
o OSCORE option value: 0x19140837cbf3210017a2d3 (11 bytes)
o OSCORE option value: 0x19140837cbf3210017a2d3 (11 bytes)
o ciphertext: 0x72cd7273fd331ac45cffbe55c3 (13 bytes)
o ciphertext: 0x72cd7273fd331ac45cffbe55c3 (13 bytes)
From there:
そこから：
o Protected CoAP request (OSCORE message): 0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff 72cd7273fd331ac45cffbe55c3 (44 bytes)
o Protected CoAP request (OSCORE message): 0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff 72cd7273fd331ac45cffbe55c3 (44 bytes)
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！」です。オプションはありません。保護された応答には、kidもPartial IVも含まれていません。一部のパラメータはリクエストから取得されることに注意してください。
Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes)
Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes)
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o Key Derivation Function: HKDF SHA-256
o Key Derivation Function: HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x01 (1 byte)
o Sender ID: 0x01 (1 byte)
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Sender Sequence Number: 0
o Sender Sequence Number: 0
The following COSE and cryptographic parameters are derived:
次のCOSEおよび暗号化パラメーターが導出されます。
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_array: 0x8501810a40411440 (8 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
From the previous parameter, the following is derived:
前のパラメーターから、以下が導出されます。
o OSCORE option value: 0x (0 bytes)
o OSCORE option value: 0x (0 bytes)
o ciphertext: 0xdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (22 bytes)
o ciphertext: 0xdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (22 bytes)
From there:
そこから：
o Protected CoAP response (OSCORE message): 0x64445d1f0000397490ffdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (32 bytes)
o Protected CoAP response (OSCORE message): 0x64445d1f0000397490ffdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (32 bytes)
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！」です。オプションはありません。保護された応答にはkidは含まれませんが、Partial IVが含まれます。一部のパラメータはリクエストから取得されることに注意してください。
Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes)
Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes)
Common Context:
共通のコンテキスト：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o Key Derivation Function: HKDF SHA-256
o Key Derivation Function: HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
Sender Context:
送信者のコンテキスト：
o Sender ID: 0x01 (1 byte)
o Sender ID: 0x01 (1 byte)
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Sender Sequence Number: 0
o Sender Sequence Number: 0
The following COSE and cryptographic parameters are derived:
次のCOSEおよび暗号化パラメーターが導出されます。
o Partial IV: 0x00 (1 byte)
o Partial IV: 0x00 (1 byte)
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_array: 0x8501810a40411440 (8 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o nonce: 0x4722d4dd6d944169eefb54987c (13 bytes) From the previous parameter, the following is derived:
o nonce: 0x4722d4dd6d944169eefb54987c (13 bytes) From the previous parameter, the following is derived:
o OSCORE option value: 0x0100 (2 bytes)
o OSCORE option value: 0x0100 (2 bytes)
o ciphertext: 0x4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (22 bytes)
o ciphertext: 0x4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (22 bytes)
From there:
そこから：
o Protected CoAP response (OSCORE message): 0x64445d1f00003974920100 ff4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (34 bytes)
o Protected CoAP response (OSCORE message): 0x64445d1f00003974920100 ff4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (34 bytes)
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.
OSCOREをCoAP層で動作させることで、CoAP message fieldごとに異なる保護を行えます。これにより、プロキシ操作に必要なフィールドはプロキシから利用可能にし、他方のエンドポイント向けのフィールドは保護したままにできます。この節の残りでは、OSCOREが保護対象のmessage fieldをどのように守るかと、プロキシ操作用フィールドを保護しない場合の影響を分析します。
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は、暗号鍵の導出に使う事前共有の乱数Master Secret（セクション12.3）と、(key, nonce)の組を一意にする構成（付録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メッセージを、攻撃者が作成できないようにします。
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は強力な鍵と一意な(key, nonce)の組で平文をAEAD保護することにより、これらの性質を提供します。AEAD暗号化[RFC5116]はデータの機密性と完全性を提供します。応答と要求の結び付けは、要求のkidとPartial IVを応答のAADに含めることで実現します。要求と通知のリプレイ防止は、一意な(key, nonce)の組と、アプリケーションに応じたリプレイ保護機構（セクション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の要件が満たされている限り、（キー、nonce）ペアが一意であることを示します。
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.
Common Context（セクション3.1）と、暗号化エンドポイントと呼ぶ一方のエンドポイントを固定します。エンドポイントはクライアントとサーバーの役割を交互に担う場合がありますが、常に自身のSender ContextのSender Keyで暗号化します。Sender Keyは一意なSender IDを使ってHKDFで導出されるため（確率的に）一意であり、異なるエンドポイントが暗号化するメッセージには異なる鍵が使われます。残る課題は、固定したエンドポイントが使うnonceの一意性を示すことです。
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が固定されているため、nonceはPIVによって決まります。PIVは要求または応答のPartial IVの値であり、ID_PIVはそのPartial IVを生成したエンドポイントのSender IDです。ID_PIVのサイズをSとしたセクション5.2のnonce構成により、異なる(ID_PIV, PIV)の組から異なるnonceが生成されます。場合分けは次のとおりです。
A. For requests, and responses with Partial IV (e.g., Observe notifications):
A. 要求、およびPartial IVを含む応答（Observe notificationなど）:
o ID_PIV = Sender ID of the encrypting endpoint
o ID_PIV = 暗号化エンドポイントのSender ID
o PIV = current Partial IV of the encrypting endpoint
o PIV = 暗号化エンドポイントの現在のPartial 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).
暗号化エンドポイントは使用のたびにPartial IVを増やすため、暗号化メッセージ数が上限内（セクション7.2.1を参照）である限り、ケースAのnonceはすべて一意です。
B. For responses without Partial IV (e.g., single response to a request):
B. Partial IVを含まない応答（要求に対する単一応答など）:
o ID_PIV = Sender ID of the endpoint generating the request
o ID_PIV = 要求を生成したエンドポイントのSender ID
o PIV = Partial IV of the request
o PIV = 要求のPartial 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.
Sender IDは一意なので、ID_PIVは暗号化エンドポイント自身のSender IDとは異なります。そのため、ケースBのnonceは、暗号化エンドポイント自身がPartial IVを生成するケースAのnonceとは異なります。このRecipient Contextにおける要求のPartial IVはリプレイ検証されるため（セクション7.4を参照）、このID_PIVに対するPIVは一意です。したがって、ケースBのnonceもすべて一意です。
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 Version。CoAP version [RFC7252]は開示に敏感な情報ではないと想定されます。現在定義されているCoAP versionは1つだけです。この値の変更はサービス拒否攻撃につながる可能性があります。将来のCoAP versionを規定する際は、攻撃者によるversion変更が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/Token Length。Token fieldは、並行する要求を区別するためのクライアント内識別子です [RFC7252]。CoAPプロキシはhop間でTokenとToken Lengthを読み取り、変更できます。盗聴者がTokenを読むと、要求と応答を対応付けられ、トラフィック分析に利用できます。複数の応答が1つの要求に対応する通知では、特にこの点が当てはまります。経路上の攻撃者がTokenやToken Lengthを変更すると、クライアントが応答の属する要求を特定できなくなったり、応答の完全性検証に必要な情報を見つけられなくなったりするため、サービス拒否攻撃になる可能性があります。
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 Code。OSCOREメッセージのOuter CoAP Codeは、要求ではPOSTまたはFETCH、対応する応答では所定のCodeになります。受信エンドポイントはOuter CoAP Codeを破棄し、代わりにInner CoAP Codeを使います（セクション4.2を参照）。そのため、攻撃者がOuter Codeを変更しても受信エンドポイントには影響しません。ただし、Outer CodeをFETCHからObserveに対応しないmethodのCode（POSTなど）へ変更すると、複数のCodeでObserveが未定義であるため、プロキシの実装によって通知が転送されない場合があり、サービス拒否攻撃となります。POSTではなくFETCHを使っても、Outer Observe optionの存在から分かる以上の情報は明らかになりません。
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 Type/Message ID。Type/Message ID field [RFC7252]はUDP transport bindingに関する情報を明らかにします。たとえば、TypeまたはMessage IDを読む盗聴者は、UDPメッセージ間の関連を知ることができます。CoAPプロキシはTypeとMessage IDを変更できます。これらのmessage fieldはCoAP over TCP [RFC8323]にはなく、要求/応答メッセージには影響しません。UDP hopでこれらの値を変更することはサービス拒否攻撃です。攻撃者はACKを送って、前のメッセージを再送する必要がないとエンドポイントに誤認させることができます。RSTを送信してObservationを取り消すこともできます。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 Length。このfieldにはメッセージ長が含まれます [RFC8323]。トラフィック分析に使われる場合があります。このmessage fieldはCoAP over UDPにはなく、要求/応答メッセージには影響しません。Lengthの変更はTCP header fieldの変更と同様のサービス拒否攻撃です。
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 Max-Age。OSCORE処理エラー応答が不必要にキャッシュされないよう、Outer Max-Ageは0に設定されます。この値を変更すると不要なキャッシュが起きる場合があります。このoptionが追加情報を運ぶことはありません。
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。これらのoptionはCoAPフォワードプロキシの展開で使います。OSCOREでは、Proxy-Uri optionにURIのUri-Path/Uri-Query部分を含めません。フォワードプロキシは機能を果たすためにProxy-Uriのその他の部分を変更する必要があるので、それらは保護できません。サーバーは最後のhopで使われたschemeを検証できますが、クライアントが要求したschemeや前のhopで使われたschemeは検証できません。
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。Outer Observe optionはプロキシがObserve messageを転送するために使われますが、エンドポイントではInner Observe optionに従って処理するため無視されます。Partial IVが通知の絶対的な順序を示すため、中間ノードが順序を偽装することはできません（セクション4.1.3.5を参照）。最初の通知だけPartial IVを省略できますが、それによって通知の順序付けが妨げられることはありません。通知のサイズと時間的な分布から、その内容や性質が分かる場合があります。キャンセル（セクション4.1.3.5.1）は、OSCOREで応答が要求に結び付く方法と同じ形では対応する登録に結び付きません（付録D.3を参照）。ただし、不一致キャンセルを悪用する攻撃が可能になるわけではありません。キャンセルを受け入れるには、復号後メッセージのETag optionsを除くすべてのoptionが同一でなければなりません (MUST)（セクション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。Outer Block optionsは、Inner Block optionsによる分割に加えてOSCOREメッセージを分割できます。これらのoptionがあることから大きなメッセージの送信が分かり、メッセージサイズを推定してトラフィック分析に利用できます。これらのoptionの改変は、偽のBlock fragmentを挿入するなどのサービス拒否攻撃につながる場合があります。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。Outer No-Response optionはプロキシ機能を支援します。具体的には、プロキシからクライアントへのエラー送信を避け、応答を受信しないときにプロキシが輻輳制御を適用してサーバーへの帯域を減らすことを避けます。このoptionの変更や挿入はプロキシ操作へのサービス拒否攻撃となる可能性があります。ただしInner値もあるため、エンドポイント間でその使用を安全に合意できます。このoptionの存在からメッセージ交換に関する機微な情報が明らかになるとは想定されません。
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.
CoAP処理中に発生するエラーメッセージはエンドツーエンドで保護されます。OSCORE処理中のエラーメッセージは、受信エンドポイントが適切なSecurity Contextを特定できない場合など、常に保護できるとは限りません。このような場合、過剰な再送を防ぐため、本書で規定する未保護エラーメッセージを許可します。これらのエラーメッセージは偽装または改変される可能性があり、サービス拒否攻撃につながります。
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.
本書は、OSCORE処理エラー用の任意のエラーコード (MAY) と特定の診断Payloadを規定します。このようなメッセージは、サーバー上に存在するSecurity Contextの数や種類を明らかにする場合があります。アプリケーションのセキュリティ上の懸念がある場合、サーバーは診断Payloadを省略する、すべてのエラーに同じエラーコードを使う、または応答自体を避けてもよいです (MAY)。さらに、クライアントは未保護で偽装・改変され得るこれらのエラーを受けて特定の動作を起こす際、エラーコードや診断Payloadに依存してはなりません (MUST NOT)。
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.
CoAPでは、CoAP間のプロキシ操作を可能にするため、OSCOREはheader fieldを保護しません。一方、HTTPでOSCOREを使う場合は、保護されたCoAPメッセージをHTTP hopで運ぶ用途に限定されます。未保護のHTTP message fieldは、OSCOREメッセージの転送に関する情報を明らかにし、各種サービス拒否攻撃を可能にする場合があります。HTTP hopではTLS [RFC8446]も併用することが推奨されます (SHOULD)。TLSはheaderの暗号化と完全性保護を可能にしますが、トラフィック分析に使える情報は残ります。
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 ruleは "name = type" の形式です。"name"は"type"に付ける名前です。"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 別の名前付きtypeへの参照。名前を指定します。本仕様で使う定義済みの名前付きtypeは次のとおりです。"uint"は符号なし整数（CBORのmajor type 0）、"int"は符号なしまたは負の整数（CBORのmajor type 0または1）、"bstr"はbyte string（CBORのmajor type 2）、"tstr"はtext string（CBORのmajor type 3）です。
o a choice between two types, by giving both types separated by a "/";
o 2つのtypeを "/" で区切って指定する選択肢です。
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 配列type（CBORのmajor type 4）。配列要素の並びは、comma "," で区切ったentryの列で表し、その列をsquare bracket "[" と "]" で囲みます。この記述による配列は、指定したentryの列と1対1に対応する要素を含みます。配列記述の各entryは "name : type" の形式で、"name"はentryの名前、"type"はそのentryに対応する配列要素の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.
次の方々が本書に意見を寄せました: 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の一環として本書に取り組みました。Ludwig Seitzは助成金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
Francesca Palombini Ericsson AB
Email: francesca.palombini@ericsson.com
Ludwig Seitz RISE
Ludwig Seitz RISE
Email: ludwig.seitz@ri.se