draft-ietf-lake-edhoc-12.txt   draft-ietf-lake-edhoc-13.txt 
Network Working Group G. Selander Network Working Group G. Selander
Internet-Draft J. Preuß Mattsson Internet-Draft J. Preuß Mattsson
Intended status: Standards Track F. Palombini Intended status: Standards Track F. Palombini
Expires: 23 April 2022 Ericsson Expires: 20 October 2022 Ericsson
20 October 2021 18 April 2022
Ephemeral Diffie-Hellman Over COSE (EDHOC) Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-ietf-lake-edhoc-12 draft-ietf-lake-edhoc-13
Abstract Abstract
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
very compact and lightweight authenticated Diffie-Hellman key very compact and lightweight authenticated Diffie-Hellman key
exchange with ephemeral keys. EDHOC provides mutual authentication, exchange with ephemeral keys. EDHOC provides mutual authentication,
forward secrecy, and identity protection. EDHOC is intended for forward secrecy, and identity protection. EDHOC is intended for
usage in constrained scenarios and a main use case is to establish an usage in constrained scenarios and a main use case is to establish an
OSCORE security context. By reusing COSE for cryptography, CBOR for OSCORE security context. By reusing COSE for cryptography, CBOR for
encoding, and CoAP for transport, the additional code size can be encoding, and CoAP for transport, the additional code size can be
kept very low. kept very low.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Lightweight
Authenticated Key Exchange Working Group mailing list
(lake@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/lake/.
Source for this draft and an issue tracker can be found at
https://github.com/lake-wg/edhoc.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 April 2022.
This Internet-Draft will expire on 20 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 6 1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 5
1.4. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.4. Document Structure . . . . . . . . . . . . . . . . . . . 6
1.5. Terminology and Requirements Language . . . . . . . . . . 6 1.5. Terminology and Requirements Language . . . . . . . . . . 6
2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 7 2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Connection Identifiers . . . . . . . . . . . . . . . . . 10 3.3. Connection Identifiers . . . . . . . . . . . . . . . . . 10
3.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Authentication Parameters . . . . . . . . . . . . . . . . 12 3.5. Authentication Parameters . . . . . . . . . . . . . . . . 12
3.6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 18 3.6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 18
3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 19 3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 19
3.8. External Authorization Data (EAD) . . . . . . . . . . . . 20 3.8. External Authorization Data (EAD) . . . . . . . . . . . . 20
3.9. Applicability Statement . . . . . . . . . . . . . . . . . 21 3.9. Applicability Statement . . . . . . . . . . . . . . . . . 21
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 22 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 3, line 34 skipping to change at page 3, line 22
9.9. CWT Confirmation Methods Registry . . . . . . . . . . . . 53 9.9. CWT Confirmation Methods Registry . . . . . . . . . . . . 53
9.10. The Well-Known URI Registry . . . . . . . . . . . . . . . 53 9.10. The Well-Known URI Registry . . . . . . . . . . . . . . . 53
9.11. Media Types Registry . . . . . . . . . . . . . . . . . . 54 9.11. Media Types Registry . . . . . . . . . . . . . . . . . . 54
9.12. CoAP Content-Formats Registry . . . . . . . . . . . . . . 55 9.12. CoAP Content-Formats Registry . . . . . . . . . . . . . . 55
9.13. Resource Type (rt=) Link Target Attribute Values 9.13. Resource Type (rt=) Link Target Attribute Values
Registry . . . . . . . . . . . . . . . . . . . . . . . . 55 Registry . . . . . . . . . . . . . . . . . . . . . . . . 55
9.14. Expert Review Instructions . . . . . . . . . . . . . . . 55 9.14. Expert Review Instructions . . . . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
10.1. Normative References . . . . . . . . . . . . . . . . . . 56 10.1. Normative References . . . . . . . . . . . . . . . . . . 56
10.2. Informative References . . . . . . . . . . . . . . . . . 59 10.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix A. Use with OSCORE and Transfer over CoAP . . . . . . . 62 Appendix A. Use with OSCORE and Transfer over CoAP . . . . . . . 61
A.1. Selecting EDHOC Connection Identifier . . . . . . . . . . 62 A.1. Selecting EDHOC Connection Identifier . . . . . . . . . . 62
A.2. Deriving the OSCORE Security Context . . . . . . . . . . 63 A.2. Deriving the OSCORE Security Context . . . . . . . . . . 62
A.3. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 64 A.3. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 64
Appendix B. Compact Representation . . . . . . . . . . . . . . . 67 Appendix B. Compact Representation . . . . . . . . . . . . . . . 67
Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 67 Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 67
C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 68 C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 68
C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 69 C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 69
C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 70 C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Appendix D. Applicability Template . . . . . . . . . . . . . . . 72 Appendix D. Applicability Template . . . . . . . . . . . . . . . 72
Appendix E. EDHOC Message Deduplication . . . . . . . . . . . . 73 Appendix E. EDHOC Message Deduplication . . . . . . . . . . . . 73
Appendix F. Transports Not Natively Providing Correlation . . . 74 Appendix F. Transports Not Natively Providing Correlation . . . 74
Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 74 Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 74
skipping to change at page 47, line 8 skipping to change at page 47, line 8
consideration is that the list of supported cipher suites may consideration is that the list of supported cipher suites may
potentially be used to identify the application. potentially be used to identify the application.
The Initiator and the Responder must also make sure that The Initiator and the Responder must also make sure that
unauthenticated data does not trigger any harmful actions. In unauthenticated data does not trigger any harmful actions. In
particular, this applies to EAD_1 and error messages. particular, this applies to EAD_1 and error messages.
8.6. Denial-of-Service 8.6. Denial-of-Service
As CoAP provides Denial-of-Service protection in the form of the Echo As CoAP provides Denial-of-Service protection in the form of the Echo
option [I-D.ietf-core-echo-request-tag], EDHOC itself does not option [RFC9175], EDHOC itself does not provide countermeasures
provide countermeasures against Denial-of-Service attacks. By against Denial-of-Service attacks. By sending a number of new or
sending a number of new or replayed message_1 an attacker may cause replayed message_1 an attacker may cause the Responder to allocate
the Responder to allocate state, perform cryptographic operations, state, perform cryptographic operations, and amplify messages. To
and amplify messages. To mitigate such attacks, an implementation mitigate such attacks, an implementation SHOULD rely on lower layer
SHOULD rely on lower layer mechanisms such as the Echo option in CoAP mechanisms such as the Echo option in CoAP that forces the initiator
that forces the initiator to demonstrate reachability at its apparent to demonstrate reachability at its apparent network address.
network address.
An attacker can also send faked message_2, message_3, message_4, or An attacker can also send faked message_2, message_3, message_4, or
error in an attempt to trick the receiving party to send an error error in an attempt to trick the receiving party to send an error
message and discontinue the session. EDHOC implementations MAY message and discontinue the session. EDHOC implementations MAY
evaluate if a received message is likely to have been forged by an evaluate if a received message is likely to have been forged by an
attacker and ignore it without sending an error message or attacker and ignore it without sending an error message or
discontinuing the session. discontinuing the session.
8.7. Implementation Considerations 8.7. Implementation Considerations
skipping to change at page 52, line 47 skipping to change at page 52, line 47
IANA has extended the Value Type of 'kid' in the "COSE Header IANA has extended the Value Type of 'kid' in the "COSE Header
Parameters" registry under the group name "CBOR Object Signing and Parameters" registry under the group name "CBOR Object Signing and
Encryption (COSE)" to also allow the Value Type int. The resulting Encryption (COSE)" to also allow the Value Type int. The resulting
Value Type is bstr / int. The Value Registry for this item is empty Value Type is bstr / int. The Value Registry for this item is empty
and omitted from the table below. and omitted from the table below.
+------+-------+------------+----------------+-------------------+ +------+-------+------------+----------------+-------------------+
| Name | Label | Value Type | Description | Reference | | Name | Label | Value Type | Description | Reference |
+------+-------+------------+----------------+-------------------+ +------+-------+------------+----------------+-------------------+
| kid | 4 | bstr / int | Key identifier | [RFC9052] | | kid | 4 | bstr / int | Key identifier | [[This document]] |
| | | | | [[This document]] |
+------+-------+------------+----------------+-------------------+ +------+-------+------------+----------------+-------------------+
9.8. COSE Key Common Parameters Registry 9.8. COSE Key Common Parameters Registry
IANA has extended the Value Type of 'kid' in the "COSE Key Common IANA has extended the Value Type of 'kid' in the "COSE Key Common
Parameters" registry under the group name "CBOR Object Signing and Parameters" registry under the group name "CBOR Object Signing and
Encryption (COSE)" to also allow the Value Type int. The resulting Encryption (COSE)" to also allow the Value Type int. The resulting
Value Type is bstr / int. The Value Registry for this item is empty Value Type is bstr / int. The Value Registry for this item is empty
and omitted from the table below. and omitted from the table below.
+------+-------+------------+----------------+-------------------+ +------+-------+------------+----------------+-------------------+
| Name | Label | Value Type | Description | Reference | | Name | Label | Value Type | Description | Reference |
+------+-------+------------+----------------+-------------------+ +------+-------+------------+----------------+-------------------+
| kid | 2 | bstr / int | Key identifi- | [RFC9052] | | kid | 2 | bstr / int | Key identifi- | [[This document]] |
| | | | cation value - | [[This document]] | | | | | cation value - | |
| | | | match to kid | | | | | | match to kid | |
| | | | in message | | | | | | in message | |
+------+-------+------------+----------------+-------------------+ +------+-------+------------+----------------+-------------------+
9.9. CWT Confirmation Methods Registry 9.9. CWT Confirmation Methods Registry
IANA has extended the Value Type of 'kid' in the "CWT Confirmation IANA has extended the Value Type of 'kid' in the "CWT Confirmation
Methods" registry under the group name "CBOR Web Token (CWT) Claims" Methods" registry under the group name "CBOR Web Token (CWT) Claims"
to also allow the Value Type int. The incorrect term binary string to also allow the Value Type int. The incorrect term binary string
has been corrected to bstr. The resulting Value Type is bstr / int. has been corrected to bstr. The resulting Value Type is bstr / int.
skipping to change at page 56, line 28 skipping to change at page 56, line 28
code points left that encode to that size. code points left that encode to that size.
* Specifications are recommended. When specifications are not * Specifications are recommended. When specifications are not
provided, the description provided needs to have sufficient provided, the description provided needs to have sufficient
information to verify the points above. information to verify the points above.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-core-echo-request-tag]
Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", Work in Progress,
Internet-Draft, draft-ietf-core-echo-request-tag-14, 4
October 2021, <https://www.ietf.org/archive/id/draft-ietf-
core-echo-request-tag-14.txt>.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", Work in Progress, Internet-Draft, Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-cose- <https://www.ietf.org/archive/id/draft-ietf-cose-
rfc8152bis-algs-12.txt>. rfc8152bis-algs-12.txt>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", Work in Progress, Internet-Draft, Structures and Process", Work in Progress, Internet-Draft,
skipping to change at page 58, line 38 skipping to change at page 58, line 34
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zúñiga, "SCHC: Generic Framework for Static Context Header Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724, Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020, DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>. <https://www.rfc-editor.org/info/rfc8724>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>. 2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander,
"Constrained Application Protocol (CoAP): Echo, Request-
Tag, and Token Processing", RFC 9175,
DOI 10.17487/RFC9175, February 2022,
<https://www.rfc-editor.org/info/rfc9175>.
10.2. Informative References 10.2. Informative References
[Bruni18] Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and [Bruni18] Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and
C. Schürmann, "Formal Verification of Ephemeral Diffie- C. Schürmann, "Formal Verification of Ephemeral Diffie-
Hellman Over COSE (EDHOC)", November 2018, Hellman Over COSE (EDHOC)", November 2018,
<https://www.springerprofessional.de/en/formal- <https://www.springerprofessional.de/en/formal-
verification-of-ephemeral-diffie-hellman-over-cose- verification-of-ephemeral-diffie-hellman-over-cose-
edhoc/16284348>. edhoc/16284348>.
[CborMe] Bormann, C., "CBOR Playground", May 2018, [CborMe] Bormann, C., "CBOR Playground", May 2018,
<http://cbor.me/>. <http://cbor.me/>.
[CNSA] (Placeholder), ., "Commercial National Security Algorithm [CNSA] (Placeholder), ., "Commercial National Security Algorithm
Suite", August 2015, Suite", August 2015,
<https://apps.nsa.gov/iaarchive/programs/iad-initiatives/ <https://apps.nsa.gov/iaarchive/programs/iad-initiatives/
cnsa-suite.cfm>. cnsa-suite.cfm>.
[I-D.ietf-core-oscore-edhoc] [I-D.ietf-core-oscore-edhoc]
Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S.,
and G. Selander, "Combining EDHOC and OSCORE", Work in and G. Selander, "Profiling EDHOC for CoAP and OSCORE",
Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-01, Work in Progress, Internet-Draft, draft-ietf-core-oscore-
12 July 2021, <https://www.ietf.org/archive/id/draft-ietf- edhoc-03, 7 March 2022, <https://www.ietf.org/archive/id/
core-oscore-edhoc-01.txt>. draft-ietf-core-oscore-edhoc-03.txt>.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V.
D. Stok, "CoRE Resource Directory", Work in Progress, D. Stok, "CoRE Resource Directory", Work in Progress,
Internet-Draft, draft-ietf-core-resource-directory-28, 7 Internet-Draft, draft-ietf-core-resource-directory-28, 7
March 2021, <https://www.ietf.org/archive/id/draft-ietf- March 2021, <https://www.ietf.org/archive/id/draft-ietf-
core-resource-directory-28.txt>. core-resource-directory-28.txt>.
[I-D.ietf-cose-cbor-encoded-cert] [I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509 M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft- Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-02, 12 July 2021, ietf-cose-cbor-encoded-cert-03, 10 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-cose-cbor- <https://www.ietf.org/archive/id/draft-ietf-cose-cbor-
encoded-cert-02.txt>. encoded-cert-03.txt>.
[I-D.ietf-lake-reqs] [I-D.ietf-lake-reqs]
Vucinic, M., Selander, G., Mattsson, J. P., and D. Garcia- Vucinic, M., Selander, G., Mattsson, J. P., and D. Garcia-
Carrillo, "Requirements for a Lightweight AKE for OSCORE", Carrillo, "Requirements for a Lightweight AKE for OSCORE",
Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04, Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04,
8 June 2020, <https://www.ietf.org/archive/id/draft-ietf- 8 June 2020, <https://www.ietf.org/archive/id/draft-ietf-
lake-reqs-04.txt>. lake-reqs-04.txt>.
[I-D.ietf-lwig-security-protocol-comparison] [I-D.ietf-lwig-security-protocol-comparison]
Mattsson, J. P., Palombini, F., and M. Vucinic, Mattsson, J. P., Palombini, F., and M. Vucinic,
skipping to change at page 60, line 31 skipping to change at page 60, line 27
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, <https://www.ietf.org/internet- dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-43.txt>. drafts/draft-ietf-tls-dtls13-43.txt>.
[I-D.mattsson-cfrg-det-sigs-with-noise] [I-D.mattsson-cfrg-det-sigs-with-noise]
Mattsson, J. P., Thormarker, E., and S. Ruohomaa, Mattsson, J. P., Thormarker, E., and S. Ruohomaa,
"Deterministic ECDSA and EdDSA Signatures with Additional "Deterministic ECDSA and EdDSA Signatures with Additional
Randomness", Work in Progress, Internet-Draft, draft- Randomness", Work in Progress, Internet-Draft, draft-
mattsson-cfrg-det-sigs-with-noise-02, 11 March 2020, mattsson-cfrg-det-sigs-with-noise-04, 15 February 2022,
<https://www.ietf.org/archive/id/draft-mattsson-cfrg-det- <https://www.ietf.org/archive/id/draft-mattsson-cfrg-det-
sigs-with-noise-02.txt>. sigs-with-noise-04.txt>.
[I-D.selander-ace-ake-authz] [I-D.selander-ace-ake-authz]
Selander, G., Mattsson, J. P., Vucinic, M., Richardson, Selander, G., Mattsson, J. P., Vučinić, M., Richardson,
M., and A. Schellenbaum, "Lightweight Authorization for M., and A. Schellenbaum, "Lightweight Authorization for
Authenticated Key Exchange.", Work in Progress, Internet- Authenticated Key Exchange.", Work in Progress, Internet-
Draft, draft-selander-ace-ake-authz-03, 4 May 2021, Draft, draft-selander-ace-ake-authz-04, 22 October 2021,
<https://www.ietf.org/archive/id/draft-selander-ace-ake- <https://www.ietf.org/archive/id/draft-selander-ace-ake-
authz-03.txt>. authz-04.txt>.
[I-D.selander-lake-traces] [I-D.selander-lake-traces]
Selander, G. and J. P. Mattsson, "Traces of EDHOC", Work Selander, G. and J. P. Mattsson, "Traces of EDHOC", Work
in Progress, Internet-Draft, draft-selander-lake-traces- in Progress, Internet-Draft, draft-selander-lake-traces-
01, 24 September 2021, <https://www.ietf.org/archive/id/ 02, 20 October 2021, <https://www.ietf.org/archive/id/
draft-selander-lake-traces-01.txt>. draft-selander-lake-traces-02.txt>.
[Norrman20] [Norrman20]
Norrman, K., Sundararajan, V., and A. Bruni, "Formal Norrman, K., Sundararajan, V., and A. Bruni, "Formal
Analysis of EDHOC Key Establishment for Constrained IoT Analysis of EDHOC Key Establishment for Constrained IoT
Devices", September 2020, Devices", September 2020,
<https://arxiv.org/abs/2007.11427>. <https://arxiv.org/abs/2007.11427>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
skipping to change at page 66, line 28 skipping to change at page 66, line 28
|<---------+ Header: 2.04 Changed |<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/edhoc | 2.04 | Content-Format: application/edhoc
| | Payload: EDHOC message_3 | | Payload: EDHOC message_3
| | | |
Figure 11: Transferring EDHOC in CoAP when the Initiator is CoAP Figure 11: Transferring EDHOC in CoAP when the Initiator is CoAP
Server Server
To protect against denial-of-service attacks, the CoAP server MAY To protect against denial-of-service attacks, the CoAP server MAY
respond to the first POST request with a 4.01 (Unauthorized) respond to the first POST request with a 4.01 (Unauthorized)
containing an Echo option [I-D.ietf-core-echo-request-tag]. This containing an Echo option [RFC9175]. This forces the initiator to
forces the initiator to demonstrate its reachability at its apparent demonstrate its reachability at its apparent network address. If
network address. If message fragmentation is needed, the EDHOC message fragmentation is needed, the EDHOC messages may be fragmented
messages may be fragmented using the CoAP Block-Wise Transfer using the CoAP Block-Wise Transfer mechanism [RFC7959].
mechanism [RFC7959].
EDHOC does not restrict how error messages are transported with CoAP, EDHOC does not restrict how error messages are transported with CoAP,
as long as the appropriate error message can to be transported in as long as the appropriate error message can to be transported in
response to a message that failed (see Section 6). EDHOC error response to a message that failed (see Section 6). EDHOC error
messages transported with CoAP are carried in the payload. messages transported with CoAP are carried in the payload.
A.3.1. Transferring EDHOC and OSCORE over CoAP A.3.1. Transferring EDHOC and OSCORE over CoAP
When using EDHOC over CoAP for establishing an OSCORE Security When using EDHOC over CoAP for establishing an OSCORE Security
Context, EDHOC error messages sent as CoAP responses MUST be sent in Context, EDHOC error messages sent as CoAP responses MUST be sent in
 End of changes. 27 change blocks. 
63 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/