--- 1/draft-ietf-lake-edhoc-12.txt 2022-04-18 04:13:44.815254107 -0700 +++ 2/draft-ietf-lake-edhoc-13.txt 2022-04-18 04:13:44.963257826 -0700 @@ -1,83 +1,72 @@ Network Working Group G. Selander Internet-Draft J. Preuß Mattsson Intended status: Standards Track F. Palombini -Expires: 23 April 2022 Ericsson - 20 October 2021 +Expires: 20 October 2022 Ericsson + 18 April 2022 Ephemeral Diffie-Hellman Over COSE (EDHOC) - draft-ietf-lake-edhoc-12 + draft-ietf-lake-edhoc-13 Abstract This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code size can be 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. 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. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5 - 1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 6 + 1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 5 1.4. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.5. Terminology and Requirements Language . . . . . . . . . . 6 2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 + 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Connection Identifiers . . . . . . . . . . . . . . . . . 10 3.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5. Authentication Parameters . . . . . . . . . . . . . . . . 12 3.6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 18 3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 19 3.8. External Authorization Data (EAD) . . . . . . . . . . . . 20 3.9. Applicability Statement . . . . . . . . . . . . . . . . . 21 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 22 @@ -116,23 +105,23 @@ 9.9. CWT Confirmation Methods Registry . . . . . . . . . . . . 53 9.10. The Well-Known URI Registry . . . . . . . . . . . . . . . 53 9.11. Media Types Registry . . . . . . . . . . . . . . . . . . 54 9.12. CoAP Content-Formats Registry . . . . . . . . . . . . . . 55 9.13. Resource Type (rt=) Link Target Attribute Values Registry . . . . . . . . . . . . . . . . . . . . . . . . 55 9.14. Expert Review Instructions . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 10.1. Normative References . . . . . . . . . . . . . . . . . . 56 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.2. Deriving the OSCORE Security Context . . . . . . . . . . 63 + A.2. Deriving the OSCORE Security Context . . . . . . . . . . 62 A.3. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 64 Appendix B. Compact Representation . . . . . . . . . . . . . . . 67 Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 67 C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 68 C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 69 C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Appendix D. Applicability Template . . . . . . . . . . . . . . . 72 Appendix E. EDHOC Message Deduplication . . . . . . . . . . . . 73 Appendix F. Transports Not Natively Providing Correlation . . . 74 Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 74 @@ -2118,28 +2107,27 @@ consideration is that the list of supported cipher suites may potentially be used to identify the application. The Initiator and the Responder must also make sure that unauthenticated data does not trigger any harmful actions. In particular, this applies to EAD_1 and error messages. 8.6. Denial-of-Service 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 - provide countermeasures against Denial-of-Service attacks. By - sending a number of new or replayed message_1 an attacker may cause - the Responder to allocate state, perform cryptographic operations, - and amplify messages. To mitigate such attacks, an implementation - SHOULD rely on lower layer mechanisms such as the Echo option in CoAP - that forces the initiator to demonstrate reachability at its apparent - network address. + option [RFC9175], EDHOC itself does not provide countermeasures + against Denial-of-Service attacks. By sending a number of new or + replayed message_1 an attacker may cause the Responder to allocate + state, perform cryptographic operations, and amplify messages. To + mitigate such attacks, an implementation SHOULD rely on lower layer + mechanisms such as the Echo option in CoAP that forces the initiator + to demonstrate reachability at its apparent network address. 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 message and discontinue the session. EDHOC implementations MAY evaluate if a received message is likely to have been forged by an attacker and ignore it without sending an error message or discontinuing the session. 8.7. Implementation Considerations @@ -2386,37 +2376,36 @@ IANA has extended the Value Type of 'kid' in the "COSE Header Parameters" registry under the group name "CBOR Object Signing and Encryption (COSE)" to also allow the Value Type int. The resulting Value Type is bstr / int. The Value Registry for this item is empty and omitted from the table below. +------+-------+------------+----------------+-------------------+ | Name | Label | Value Type | Description | Reference | +------+-------+------------+----------------+-------------------+ - | kid | 4 | bstr / int | Key identifier | [RFC9052] | - | | | | | [[This document]] | + | kid | 4 | bstr / int | Key identifier | [[This document]] | +------+-------+------------+----------------+-------------------+ 9.8. COSE Key Common Parameters Registry IANA has extended the Value Type of 'kid' in the "COSE Key Common Parameters" registry under the group name "CBOR Object Signing and Encryption (COSE)" to also allow the Value Type int. The resulting Value Type is bstr / int. The Value Registry for this item is empty and omitted from the table below. +------+-------+------------+----------------+-------------------+ | Name | Label | Value Type | Description | Reference | +------+-------+------------+----------------+-------------------+ - | kid | 2 | bstr / int | Key identifi- | [RFC9052] | - | | | | cation value - | [[This document]] | + | kid | 2 | bstr / int | Key identifi- | [[This document]] | + | | | | cation value - | | | | | | match to kid | | | | | | in message | | +------+-------+------------+----------------+-------------------+ 9.9. CWT Confirmation Methods Registry IANA has extended the Value Type of 'kid' in the "CWT Confirmation Methods" registry under the group name "CBOR Web Token (CWT) Claims" to also allow the Value Type int. The incorrect term binary string has been corrected to bstr. The resulting Value Type is bstr / int. @@ -2549,27 +2538,20 @@ code points left that encode to that size. * Specifications are recommended. When specifications are not provided, the description provided needs to have sufficient information to verify the points above. 10. 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, . - [I-D.ietf-cose-rfc8152bis-algs] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", Work in Progress, Internet-Draft, draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, . [I-D.ietf-cose-rfc8152bis-struct] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", Work in Progress, Internet-Draft, @@ -2653,77 +2635,83 @@ Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . [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, DOI 10.17487/RFC8724, April 2020, . [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, . [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . + [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, + . + 10.2. Informative References [Bruni18] Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and C. Schürmann, "Formal Verification of Ephemeral Diffie- Hellman Over COSE (EDHOC)", November 2018, . [CborMe] Bormann, C., "CBOR Playground", May 2018, . [CNSA] (Placeholder), ., "Commercial National Security Algorithm Suite", August 2015, . [I-D.ietf-core-oscore-edhoc] Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., - and G. Selander, "Combining EDHOC and OSCORE", Work in - Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-01, - 12 July 2021, . + and G. Selander, "Profiling EDHOC for CoAP and OSCORE", + Work in Progress, Internet-Draft, draft-ietf-core-oscore- + edhoc-03, 7 March 2022, . [I-D.ietf-core-resource-directory] Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. D. Stok, "CoRE Resource Directory", Work in Progress, Internet-Draft, draft-ietf-core-resource-directory-28, 7 March 2021, . [I-D.ietf-cose-cbor-encoded-cert] Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft- - ietf-cose-cbor-encoded-cert-02, 12 July 2021, + ietf-cose-cbor-encoded-cert-03, 10 January 2022, . + encoded-cert-03.txt>. [I-D.ietf-lake-reqs] Vucinic, M., Selander, G., Mattsson, J. P., and D. Garcia- Carrillo, "Requirements for a Lightweight AKE for OSCORE", Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04, 8 June 2020, . [I-D.ietf-lwig-security-protocol-comparison] Mattsson, J. P., Palombini, F., and M. Vucinic, @@ -2737,37 +2725,37 @@ Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- dtls13-43, 30 April 2021, . [I-D.mattsson-cfrg-det-sigs-with-noise] Mattsson, J. P., Thormarker, E., and S. Ruohomaa, "Deterministic ECDSA and EdDSA Signatures with Additional 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, . + sigs-with-noise-04.txt>. [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 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, . + authz-04.txt>. [I-D.selander-lake-traces] Selander, G. and J. P. Mattsson, "Traces of EDHOC", Work in Progress, Internet-Draft, draft-selander-lake-traces- - 01, 24 September 2021, . + 02, 20 October 2021, . [Norrman20] Norrman, K., Sundararajan, V., and A. Bruni, "Formal Analysis of EDHOC Key Establishment for Constrained IoT Devices", September 2020, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, @@ -3002,25 +2990,24 @@ |<---------+ Header: 2.04 Changed | 2.04 | Content-Format: application/edhoc | | Payload: EDHOC message_3 | | Figure 11: Transferring EDHOC in CoAP when the Initiator is CoAP Server To protect against denial-of-service attacks, the CoAP server MAY respond to the first POST request with a 4.01 (Unauthorized) - containing an Echo option [I-D.ietf-core-echo-request-tag]. This - forces the initiator to demonstrate its reachability at its apparent - network address. If message fragmentation is needed, the EDHOC - messages may be fragmented using the CoAP Block-Wise Transfer - mechanism [RFC7959]. + containing an Echo option [RFC9175]. This forces the initiator to + demonstrate its reachability at its apparent network address. If + message fragmentation is needed, the EDHOC messages may be fragmented + using the CoAP Block-Wise Transfer mechanism [RFC7959]. EDHOC does not restrict how error messages are transported with CoAP, as long as the appropriate error message can to be transported in response to a message that failed (see Section 6). EDHOC error messages transported with CoAP are carried in the payload. A.3.1. Transferring EDHOC and OSCORE over CoAP When using EDHOC over CoAP for establishing an OSCORE Security Context, EDHOC error messages sent as CoAP responses MUST be sent in