draft-ietf-lake-edhoc-09.txt   draft-ietf-lake-edhoc-10.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: 24 February 2022 Ericsson Expires: 8 March 2022 Ericsson
23 August 2021 4 September 2021
Ephemeral Diffie-Hellman Over COSE (EDHOC) Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-ietf-lake-edhoc-09 draft-ietf-lake-edhoc-10
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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 24 February 2022. This Internet-Draft will expire on 8 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 20 3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . . . . 23 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Extract . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Extract . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Expand . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2. Expand . . . . . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 2, line 50 skipping to change at page 2, line 50
6.2. Unspecified . . . . . . . . . . . . . . . . . . . . . . . 39 6.2. Unspecified . . . . . . . . . . . . . . . . . . . . . . . 39
6.3. Wrong Selected Cipher Suite . . . . . . . . . . . . . . . 39 6.3. Wrong Selected Cipher Suite . . . . . . . . . . . . . . . 39
7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41
7.1. Security Properties . . . . . . . . . . . . . . . . . . . 41 7.1. Security Properties . . . . . . . . . . . . . . . . . . . 41
7.2. Cryptographic Considerations . . . . . . . . . . . . . . 44 7.2. Cryptographic Considerations . . . . . . . . . . . . . . 44
7.3. Cipher Suites and Cryptographic Algorithms . . . . . . . 45 7.3. Cipher Suites and Cryptographic Algorithms . . . . . . . 45
7.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 45 7.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 45
7.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 46 7.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 46
7.6. Implementation Considerations . . . . . . . . . . . . . . 46 7.6. Implementation Considerations . . . . . . . . . . . . . . 46
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
8.1. EDHOC Exporter Label . . . . . . . . . . . . . . . . . . 48 8.1. EDHOC Exporter Label Registry . . . . . . . . . . . . . . 48
8.2. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 48 8.2. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 48
8.3. EDHOC Method Type Registry . . . . . . . . . . . . . . . 50 8.3. EDHOC Method Type Registry . . . . . . . . . . . . . . . 50
8.4. EDHOC Error Codes Registry . . . . . . . . . . . . . . . 50 8.4. EDHOC Error Codes Registry . . . . . . . . . . . . . . . 50
8.5. COSE Header Parameters Registry . . . . . . . . . . . . . 50 8.5. EDHOC External Authorization Data Registry . . . . . . . 50
8.6. COSE Header Parameters Registry . . . . . . . . . . . . . 51 8.6. COSE Header Parameters Registry . . . . . . . . . . . . . 51
8.7. COSE Key Common Parameters Registry . . . . . . . . . . . 51 8.7. COSE Header Parameters Registry . . . . . . . . . . . . . 51
8.8. The Well-Known URI Registry . . . . . . . . . . . . . . . 51 8.8. COSE Key Common Parameters Registry . . . . . . . . . . . 51
8.9. Media Types Registry . . . . . . . . . . . . . . . . . . 52 8.9. CWT Confirmation Methods Registry . . . . . . . . . . . . 52
8.10. CoAP Content-Formats Registry . . . . . . . . . . . . . . 53 8.10. The Well-Known URI Registry . . . . . . . . . . . . . . . 52
8.11. EDHOC External Authorization Data . . . . . . . . . . . . 53 8.11. Media Types Registry . . . . . . . . . . . . . . . . . . 52
8.12. Expert Review Instructions . . . . . . . . . . . . . . . 53 8.12. CoAP Content-Formats Registry . . . . . . . . . . . . . . 53
8.13. Expert Review Instructions . . . . . . . . . . . . . . . 54
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1. Normative References . . . . . . . . . . . . . . . . . . 54 9.1. Normative References . . . . . . . . . . . . . . . . . . 54
9.2. Informative References . . . . . . . . . . . . . . . . . 56 9.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. Use with OSCORE and Transfer over CoAP . . . . . . . 59 Appendix A. Use with OSCORE and Transfer over CoAP . . . . . . . 60
A.1. Selecting EDHOC Connection Identifier . . . . . . . . . . 59 A.1. Selecting EDHOC Connection Identifier . . . . . . . . . . 60
A.2. Deriving the OSCORE Security Context . . . . . . . . . . 60 A.2. Deriving the OSCORE Security Context . . . . . . . . . . 61
A.3. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 61 A.3. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 62
Appendix B. Compact Representation . . . . . . . . . . . . . . . 64 Appendix B. Compact Representation . . . . . . . . . . . . . . . 65
Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 65 Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 65
C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 65 C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 66
C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 66 C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 66
C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 68 C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 68 Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 68
Appendix E. Applicability Template . . . . . . . . . . . . . . . 68 Appendix E. Applicability Template . . . . . . . . . . . . . . . 68
Appendix F. EDHOC Message Deduplication . . . . . . . . . . . . 69 Appendix F. EDHOC Message Deduplication . . . . . . . . . . . . 69
Appendix G. Transports Not Natively Providing Correlation . . . 70 Appendix G. Transports Not Natively Providing Correlation . . . 70
Appendix H. Change Log . . . . . . . . . . . . . . . . . . . . . 70 Appendix H. Change Log . . . . . . . . . . . . . . . . . . . . . 70
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 75 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75
skipping to change at page 8, line 28 skipping to change at page 8, line 28
secret and used for authenticated encryption of different secret and used for authenticated encryption of different
messages. messages.
* An optional fourth message giving explicit key confirmation to I * An optional fourth message giving explicit key confirmation to I
in deployments where no protected application data is sent from R in deployments where no protected application data is sent from R
to I. to I.
* A key material exporter and a key update function enabling forward * A key material exporter and a key update function enabling forward
secrecy. secrecy.
* Verification of a common preferred cipher suite: * Verification of a common preferred cipher suite.
- The Initiator lists supported cipher suites in order of
preference
- The Responder verifies that the selected cipher suite is the
first supported cipher suite (or else rejects and states
supported cipher suites).
* Method types and error handling. * Method types and error handling.
* Selection of connection identifiers C_I and C_R which may be used * Selection of connection identifiers C_I and C_R which may be used
to identify established keys or protocol state. to identify established keys or protocol state.
* Transport of external authorization data. * Transport of external authorization data.
EDHOC is designed to encrypt and integrity protect as much EDHOC is designed to encrypt and integrity protect as much
information as possible, and all symmetric keys are derived using as information as possible, and all symmetric keys are derived using as
skipping to change at page 15, line 19 skipping to change at page 15, line 10
An example of CRED_x being a UCCS in bytewise lexicographic order An example of CRED_x being a UCCS in bytewise lexicographic order
containing an X25519 static Diffie-Hellman key and where the parties containing an X25519 static Diffie-Hellman key and where the parties
have agreed on an EUI-64 identity is shown below: have agreed on an EUI-64 identity is shown below:
{ /UCCS/ { /UCCS/
2 : "42-50-31-FF-EF-37-32-39", /sub/ 2 : "42-50-31-FF-EF-37-32-39", /sub/
8 : { /cnf/ 8 : { /cnf/
1 : { /COSE_Key/ 1 : { /COSE_Key/
1 : 1, /kty/ 1 : 1, /kty/
2 : 0, /kid/
-1 : 4, /crv/ -1 : 4, /crv/
-2 : h'b1a3e89460e88d3a8d54211dc95f0b90 /x/ -2 : h'b1a3e89460e88d3a8d54211dc95f0b90 /x/
3ff205eb71912d6db8f4af980d2db83a' 3ff205eb71912d6db8f4af980d2db83a'
} }
} }
} }
3.5.3. Identities 3.5.3. Identities
EDHOC assumes the existence of mechanisms (certification authority, EDHOC assumes the existence of mechanisms (certification authority,
skipping to change at page 17, line 34 skipping to change at page 17, line 37
- ID_CRED_x = { 35 : uri }, for x = I or R, - ID_CRED_x = { 35 : uri }, for x = I or R,
- ID_CRED_x = { TBD4 : uri }, for x = I or R. - ID_CRED_x = { TBD4 : uri }, for x = I or R.
ID_CRED_x MAY contain the actual credential used for authentication, ID_CRED_x MAY contain the actual credential used for authentication,
CRED_x. For example, a certificate chain can be transported in CRED_x. For example, a certificate chain can be transported in
ID_CRED_x with COSE header parameter c5c or x5chain, defined in ID_CRED_x with COSE header parameter c5c or x5chain, defined in
[I-D.ietf-cose-cbor-encoded-cert] and [I-D.ietf-cose-x509]. [I-D.ietf-cose-cbor-encoded-cert] and [I-D.ietf-cose-x509].
Credentials of type CWT and UCCS are transported with the COSE header Credentials of type CWT and UCCS are transported with the COSE header
parameter registered in Section 8.5: parameters registered in Section 8.6:
* ID_CRED_x = { TBD1 : CWT }, for x = I or R, * ID_CRED_x = { TBD1 : CWT }, for x = I or R,
* ID_CRED_x = { TBD1 : UCCS }, for x = I or R. * ID_CRED_x = { TBD2 : UCCS }, for x = I or R.
It is RECOMMENDED that ID_CRED_x uniquely identify the public It is RECOMMENDED that ID_CRED_x uniquely identify the public
authentication key as the recipient may otherwise have to try several authentication key as the recipient may otherwise have to try several
keys. ID_CRED_I and ID_CRED_R are transported in the 'ciphertext', keys. ID_CRED_I and ID_CRED_R are transported in the 'ciphertext',
see Section 5.4.2 and Section 5.3.2. see Section 5.4.2 and Section 5.3.2.
When ID_CRED_x does not contain the actual credential, it may be very When ID_CRED_x does not contain the actual credential, it may be very
short, e.g., if the endpoints have agreed to use a key identifier short, e.g., if the endpoints have agreed to use a key identifier
parameter 'kid': parameter 'kid':
* ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or * ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or
R. R.
Note that 'kid' is extended to support int values to allow more one- Note that 'kid' is extended to support int values to allow more one-
byte identifiers (see Section 8.6 and Section 8.7) which may be byte identifiers (see Section 8.7 and Section 8.8) which may be
useful in many scenarios since constrained devices only have a few useful in many scenarios since constrained devices only have a few
keys. keys.
3.6. Cipher Suites 3.6. Cipher Suites
An EDHOC cipher suite consists of an ordered set of algorithms from An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length. Algorithms need to be specified with enough as the EDHOC MAC length. Algorithms need to be specified with enough
parameters to make them completely determined. Currently, none of parameters to make them completely determined. Currently, none of
the algorithms require parameters. EDHOC is only specified for use the algorithms require parameters. EDHOC is only specified for use
skipping to change at page 20, line 11 skipping to change at page 20, line 11
25. ( 24, -45, 16, 5, -8, 24, -45 ) 25. ( 24, -45, 16, 5, -8, 24, -45 )
(ChaCha20/Poly1305, SHAKE256, 16, X448, EdDSA, (ChaCha20/Poly1305, SHAKE256, 16, X448, EdDSA,
ChaCha20/Poly1305, SHAKE256) ChaCha20/Poly1305, SHAKE256)
The different methods use the same cipher suites, but some algorithms The different methods use the same cipher suites, but some algorithms
are not used in some methods. The EDHOC signature algorithm is not are not used in some methods. The EDHOC signature algorithm is not
used in methods without signature authentication. used in methods without signature authentication.
The Initiator needs to have a list of cipher suites it supports in The Initiator needs to have a list of cipher suites it supports in
order of preference. The Responder needs to have a list of cipher order of preference. The Responder needs to have a list of cipher
suites it supports. SUITES_I is a CBOR array containing cipher suites it supports. SUITES_I contains cipher suites supported by the
suites that the Initiator supports. SUITES_I is formatted and Initiator, formatted and processed as detailed in Section 5.2.1 to
processed as detailed in Section 5.2.1 to secure the cipher suite secure the cipher suite negotiation. Examples of cipher suite
negotiation. Examples of cipher suite negotiation are given in negotiation are given in Section 6.3.2.
Section 6.3.2.
3.7. Ephemeral Public Keys 3.7. Ephemeral Public Keys
EDHOC always uses compact representation of elliptic curve points, EDHOC always uses compact representation of elliptic curve points,
see Appendix B. In COSE compact representation is achieved by see Appendix B. In COSE compact representation is achieved by
formatting the ECDH ephemeral public keys as COSE_Keys of type EC2 or formatting the ECDH ephemeral public keys as COSE_Keys of type EC2 or
OKP according to Sections 7.1 and 7.2 of OKP according to Sections 7.1 and 7.2 of
[I-D.ietf-cose-rfc8152bis-algs], but only including the 'x' parameter [I-D.ietf-cose-rfc8152bis-algs], but only including the 'x' parameter
in G_X and G_Y. For Elliptic Curve Keys of type EC2, compact in G_X and G_Y. For Elliptic Curve Keys of type EC2, compact
representation MAY be used also in the COSE_Key. If the COSE representation MAY be used also in the COSE_Key. If the COSE
skipping to change at page 21, line 12 skipping to change at page 21, line 12
consisting of one or more (type, ext_authz_data) pairs as defined consisting of one or more (type, ext_authz_data) pairs as defined
below: below:
ead = 1* ( ead = 1* (
type : int, type : int,
ext_authz_data : any, ext_authz_data : any,
) )
where ext_authz_data is authorization related data defined in a where ext_authz_data is authorization related data defined in a
separate specification and its type is an int. Different types of separate specification and its type is an int. Different types of
ext_authz_data are registered in Section 8.11. ext_authz_data are registered in Section 8.5.
The EAD fields of EDHOC are not intended for generic application The EAD fields of EDHOC are not intended for generic application
data. Since data carried in EAD_1 and EAD_2 fields may not be data. Since data carried in EAD_1 and EAD_2 fields may not be
protected, special considerations need to be made such that it does protected, special considerations need to be made such that it does
not violate security and privacy requirements of the service which not violate security and privacy requirements of the service which
uses this data. Moreover, the content in an EAD field may impact the uses this data. Moreover, the content in an EAD field may impact the
security properties provided by EDHOC. Security applications making security properties provided by EDHOC. Security applications making
use of the EAD fields must perform the necessary security analysis. use of the EAD fields must perform the necessary security analysis.
3.9. Applicability Statement 3.9. Applicability Statement
skipping to change at page 22, line 19 skipping to change at page 22, line 19
EAD_4; see Section 3.8). EAD_4; see Section 3.8).
6. Identifier used as identity of endpoint; see Section 3.5.3. 6. Identifier used as identity of endpoint; see Section 3.5.3.
7. If message_4 shall be sent/expected, and if not, how to ensure a 7. If message_4 shall be sent/expected, and if not, how to ensure a
protected application message is sent from the Responder to the protected application message is sent from the Responder to the
Initiator; see Section 5.5. Initiator; see Section 5.5.
The applicability statement may also contain information about The applicability statement may also contain information about
supported cipher suites. The procedure for selecting and verifying supported cipher suites. The procedure for selecting and verifying
cipher suite is still performed as specified by the protocol, but it cipher suite is still performed as described in Section 5.2.1 and
may become simplified by this knowledge. Section 6.3, but it may become simplified by this knowledge.
An example of an applicability statement is shown in Appendix E. An example of an applicability statement is shown in Appendix E.
For some parameters, like METHOD, ID_CRED_x, type of EAD, the For some parameters, like METHOD, ID_CRED_x, type of EAD, the
receiver is able to verify compliance with applicability statement, receiver is able to verify compliance with applicability statement,
and if it needs to fail because of incompliance, to infer the reason and if it needs to fail because of incompliance, to infer the reason
why the protocol failed. why the protocol failed.
For other parameters, like CRED_x in the case that it is not For other parameters, like CRED_x in the case that it is not
transported, it may not be possible to verify that incompliance with transported, it may not be possible to verify that incompliance with
skipping to change at page 25, line 8 skipping to change at page 25, line 8
4.2. Expand 4.2. Expand
The keys, IVs and MACs used in EDHOC are derived from the PRKs using The keys, IVs and MACs used in EDHOC are derived from the PRKs using
Expand, and instantiated with the EDHOC AEAD algorithm in the Expand, and instantiated with the EDHOC AEAD algorithm in the
selected cipher suite. selected cipher suite.
OKM = EDHOC-KDF( PRK, transcript_hash, label, context, length ) OKM = EDHOC-KDF( PRK, transcript_hash, label, context, length )
= Expand( PRK, info, length ) = Expand( PRK, info, length )
where info is the CBOR encoding of where info is encoded as the CBOR sequence
info = [ info = (
edhoc_aead_id : int / tstr, edhoc_aead_id : int / tstr,
transcript_hash : bstr, transcript_hash : bstr,
label : tstr, label : tstr,
* context : any, context : bstr,
length : uint, length : uint,
] )
where where
* edhoc_aead_id is an int or tstr containing the algorithm * edhoc_aead_id is an int or tstr containing the algorithm
identifier of the EDHOC AEAD algorithm in the selected cipher identifier of the EDHOC AEAD algorithm in the selected cipher
suite encoded as defined in [I-D.ietf-cose-rfc8152bis-algs]. Note suite encoded as defined in [I-D.ietf-cose-rfc8152bis-algs]. Note
that a single fixed edhoc_aead_id is used in all invocations of that a single fixed edhoc_aead_id is used in all invocations of
EDHOC-KDF, including the derivation of KEYSTREAM_2 and invocations EDHOC-KDF, including the derivation of KEYSTREAM_2 and invocations
of the EDHOC-Exporter (see Section 4.3). of the EDHOC-Exporter (see Section 4.3).
* transcript_hash is a bstr set to one of the transcript hashes * transcript_hash is a bstr set to one of the transcript hashes
TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.3. TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.3.
* label is a tstr set to the name of the derived key, IV or MAC; * label is a tstr set to the name of the derived key, IV or MAC;
i.e., "KEYSTREAM_2", "MAC_2", "K_3ae", "IV_3ae", or "MAC_3". i.e., "KEYSTREAM_2", "MAC_2", "K_3ae", "IV_3ae", or "MAC_3".
* context is a CBOR sequence, i.e., zero or more encoded CBOR data * context is a bstr
items
* length is the length of output keying material (OKM) in bytes * length is the length of output keying material (OKM) in bytes
The definition of Expand depends on the EDHOC hash algorithm of the The definition of Expand depends on the EDHOC hash algorithm of the
selected cipher suite: selected cipher suite:
* if the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, * if the EDHOC hash algorithm is SHA-2, then Expand( PRK, info,
length ) = HKDF-Expand( PRK, info, length ) [RFC5869] length ) = HKDF-Expand( PRK, info, length ) [RFC5869]
* if the EDHOC hash algorithm is SHAKE128, then Expand( PRK, info, * if the EDHOC hash algorithm is SHAKE128, then Expand( PRK, info,
skipping to change at page 26, line 31 skipping to change at page 26, line 31
4.3. EDHOC-Exporter 4.3. EDHOC-Exporter
Application keys and other application specific data can be derived Application keys and other application specific data can be derived
using the EDHOC-Exporter interface defined as: using the EDHOC-Exporter interface defined as:
EDHOC-Exporter(label, context, length) EDHOC-Exporter(label, context, length)
= EDHOC-KDF(PRK_4x3m, TH_4, label, context, length) = EDHOC-KDF(PRK_4x3m, TH_4, label, context, length)
where label is a registered tstr from the EDHOC Exporter Label where label is a registered tstr from the EDHOC Exporter Label
registry (Section 8.1), context is a CBOR sequence defined by the registry (Section 8.1), context is a bstr defined by the application,
application, and length is a uint defined by the application. The and length is a uint defined by the application. The (label,
(label, context) pair must be unique, i.e., a (label, context) MUST context) pair must be unique, i.e., a (label, context) MUST NOT be
NOT be used for two different purposes. However an application can used for two different purposes. However an application can re-
re-derive the same key several times as long as it is done in a derive the same key several times as long as it is done in a secure
secure way. For example, in most encryption algorithms the same way. For example, in most encryption algorithms the same (key,
(key, nonce) pair must not be reused. The context can for example be nonce) pair must not be reused. The context can for example be the
the empty (zero-length) sequence or a single CBOR byte string. empty (zero-length) sequence or a single CBOR byte string.
The transcript hash TH_4 is a CBOR encoded bstr and the input to the The transcript hash TH_4 is a CBOR encoded bstr and the input to the
hash function is a CBOR Sequence. hash function is a CBOR Sequence.
TH_4 = H( TH_3, CIPHERTEXT_3 ) TH_4 = H( TH_3, CIPHERTEXT_3 )
where H() is the hash function in the selected cipher suite. where H() is the hash function in the selected cipher suite.
Examples of use of the EDHOC-Exporter are given in Section 5.5.2 and Examples of use of the EDHOC-Exporter are given in Section 5.5.2 and
Appendix A. Appendix A.
skipping to change at page 28, line 40 skipping to change at page 28, line 40
5.2. EDHOC Message 1 5.2. EDHOC Message 1
5.2.1. Formatting of Message 1 5.2.1. Formatting of Message 1
message_1 SHALL be a CBOR Sequence (see Appendix C.1) as defined message_1 SHALL be a CBOR Sequence (see Appendix C.1) as defined
below below
message_1 = ( message_1 = (
METHOD : int, METHOD : int,
SUITES_I : [ selected : suite, supported : 2* suite ] / suite, SUITES_I : suites,
G_X : bstr, G_X : bstr,
C_I : bstr / int, C_I : bstr / int,
? EAD_1 : ead, ? EAD_1 : ead,
) )
suite = int suite = int
suites = [ 2* suite ] / suite
where: where:
* METHOD = 0, 1, 2, or 3 (see Figure 4). * METHOD = 0, 1, 2, or 3 (see Figure 4).
* SUITES_I - cipher suites which the Initiator supports in order of * SUITES_I - array of cipher suites which the Initiator supports in
(decreasing) preference. The list of supported cipher suites can order of preference, starting with the most preferred and ending
be truncated at the end, as is detailed in the processing steps with the cipher suite selected for this session. If the most
below and Section 6.3. One of the supported cipher suites is preferred cipher suite is selected then SUITES_I is encoded as
selected. The selected suite is the first suite in the SUITES_I that cipher suite, i.e. as an int. The processing steps are
CBOR array. If a single supported cipher suite is conveyed, then detailed below and in Section 6.3.
that cipher suite is selected and SUITES_I is encoded as an int
instead of an array.
* G_X - the ephemeral public key of the Initiator * G_X - the ephemeral public key of the Initiator
* C_I - variable length connection identifier * C_I - variable length connection identifier
* EAD_1 - unprotected external authorization data, see Section 3.8. * EAD_1 - unprotected external authorization data, see Section 3.8.
5.2.2. Initiator Processing of Message 1 5.2.2. Initiator Processing of Message 1
The Initiator SHALL compose message_1 as follows: The Initiator SHALL compose message_1 as follows:
* The supported cipher suites and the order of preference MUST NOT * The supported cipher suites and the order of preference MUST NOT
be changed based on previous error messages. However, the list be changed based on previous error messages. SUITES_I contains
SUITES_I sent to the Responder MAY be truncated such that cipher the ordered list of supported cipher suites, truncated after the
suites which are the least preferred are omitted. The amount of cipher suite selected for this session. The selected cipher suite
truncation MAY be changed between sessions, e.g., based on MAY be changed between sessions, e.g., based on previous error
previous error messages (see next bullet), but all cipher suites messages (see next bullet), but all cipher suites which are more
which are more preferred than the least preferred cipher suite in preferred than the selected cipher suite in the list MUST be
the list MUST be included in the list. included in SUITES_I.
* The Initiator MUST select its most preferred cipher suite, * The Initiator MUST select its most preferred cipher suite,
conditioned on what it can assume to be supported by the conditioned on what it can assume to be supported by the
Responder. If the Initiator previously received from the Responder. If the Initiator previously received from the
Responder an error message with error code 2 (see Section 6.3) Responder an error message with error code 2 (see Section 6.3)
indicating cipher suites supported by the Responder which also are indicating cipher suites supported by the Responder, then the
supported by the Initiator, then the Initiator SHOULD select the Initiator SHOULD select the most preferred supported cipher suite
most preferred cipher suite of those (note that error messages are among those (note that error messages are not authenticated and
not authenticated and may be forged). may be forged).
* Generate an ephemeral ECDH key pair using the curve in the * Generate an ephemeral ECDH key pair using the curve in the
selected cipher suite and format it as a COSE_Key. Let G_X be the selected cipher suite and format it as a COSE_Key. Let G_X be the
'x' parameter of the COSE_Key. 'x' parameter of the COSE_Key.
* Choose a connection identifier C_I and store it for the length of * Choose a connection identifier C_I and store it for the length of
the protocol. the protocol.
* Encode message_1 as a sequence of CBOR encoded data items as * Encode message_1 as a sequence of CBOR encoded data items as
specified in Section 5.2.1 specified in Section 5.2.1
skipping to change at page 31, line 11 skipping to change at page 31, line 11
* Choose a connection identifier C_R and store it for the length of * Choose a connection identifier C_R and store it for the length of
the protocol. the protocol.
* Compute the transcript hash TH_2 = H( H(message_1), G_Y, C_R ) * Compute the transcript hash TH_2 = H( H(message_1), G_Y, C_R )
where H() is the hash function in the selected cipher suite. The where H() is the hash function in the selected cipher suite. The
transcript hash TH_2 is a CBOR encoded bstr and the input to the transcript hash TH_2 is a CBOR encoded bstr and the input to the
hash function is a CBOR Sequence. Note that H(message_1) can be hash function is a CBOR Sequence. Note that H(message_1) can be
computed and cached already in the processing of message_1. computed and cached already in the processing of message_1.
* Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", ( ID_CRED_R, * Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", << ID_CRED_R,
CRED_R, ? EAD_2 ), mac_length ). If the Responder authenticates CRED_R, ? EAD_2 >>, mac_length_2 ). If the Responder
with a static Diffie-Hellman key (method equals 1 or 3), then authenticates with a static Diffie-Hellman key (method equals 1 or
mac_length is the EDHOC MAC length given by the cipher suite. If 3), then mac_length_2 is the EDHOC MAC length given by the
the Responder authenticates with a signature key (method equals 0 selected cipher suite. If the Responder authenticates with a
or 2), then mac_length is equal to the output size of the EDHOC signature key (method equals 0 or 2), then mac_length_2 is equal
hash algorithm given by the cipher suite. to the output size of the EDHOC hash algorithm given by the
selected cipher suite.
- ID_CRED_R - identifier to facilitate retrieval of CRED_R, see - ID_CRED_R - identifier to facilitate retrieval of CRED_R, see
Section 3.5.4 Section 3.5.4
- CRED_R - CBOR item containing the credential of the Responder, - CRED_R - CBOR item containing the credential of the Responder,
see Section 3.5.4 see Section 3.5.4
- EAD_2 = unprotected external authorization data, see - EAD_2 = unprotected external authorization data, see
Section 3.8 Section 3.8
skipping to change at page 33, line 23 skipping to change at page 33, line 23
5.4.2. Initiator Processing of Message 3 5.4.2. Initiator Processing of Message 3
The Initiator SHALL compose message_3 as follows: The Initiator SHALL compose message_3 as follows:
* Compute the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H() * Compute the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H()
is the hash function in the selected cipher suite. The transcript is the hash function in the selected cipher suite. The transcript
hash TH_3 is a CBOR encoded bstr and the input to the hash hash TH_3 is a CBOR encoded bstr and the input to the hash
function is a CBOR Sequence. Note that H(TH_2, CIPHERTEXT_2) can function is a CBOR Sequence. Note that H(TH_2, CIPHERTEXT_2) can
be computed and cached already in the processing of message_2. be computed and cached already in the processing of message_2.
* Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", ( ID_CRED_I, * Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", << ID_CRED_I,
CRED_I, ? EAD_3 ), mac_length ). If the Initiator authenticates CRED_I, ? EAD_3 >>, mac_length_3 ). If the Initiator
with a static Diffie-Hellman key (method equals 2 or 3), then authenticates with a static Diffie-Hellman key (method equals 2 or
mac_length is the EDHOC MAC length given by the cipher suite. If 3), then mac_length_3 is the EDHOC MAC length given by the
the Initiator authenticates with a signature key (method equals 0 selected cipher suite. If the Initiator authenticates with a
or 1), then mac_length is equal to the output size of the EDHOC signature key (method equals 0 or 1), then mac_length_3 is equal
hash algorithm given by the cipher suite. to the output size of the EDHOC hash algorithm given by the
selected cipher suite.
- ID_CRED_I - identifier to facilitate retrieval of CRED_I, see - ID_CRED_I - identifier to facilitate retrieval of CRED_I, see
Section 3.5.4 Section 3.5.4
- CRED_I - CBOR item containing the credential of the Initiator, - CRED_I - CBOR item containing the credential of the Initiator,
see Section 3.5.4 see Section 3.5.4
- EAD_3 = protected external authorization data, see Section 3.8 - EAD_3 = protected external authorization data, see Section 3.8
* If the Initiator authenticates with a static Diffie-Hellman key * If the Initiator authenticates with a static Diffie-Hellman key
skipping to change at page 34, line 32 skipping to change at page 34, line 32
- plaintext = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? - plaintext = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ?
EAD_3 ) EAD_3 )
o Note that if ID_CRED_I contains a single 'kid' parameter, o Note that if ID_CRED_I contains a single 'kid' parameter,
i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or
integer kid_I is conveyed in the plaintext encoded as a bstr integer kid_I is conveyed in the plaintext encoded as a bstr
or int. or int.
COSE constructs the input to the AEAD [RFC5116] as follows: COSE constructs the input to the AEAD [RFC5116] as follows:
- Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length ) - Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", h'', length )
- Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length ) - Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", h'', length )
- Plaintext P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? - Plaintext P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ?
EAD_3 ) EAD_3 )
- Associated data A = [ "Encrypt0", h'', TH_3 ] - Associated data A = [ "Encrypt0", h'', TH_3 ]
CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0. CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0.
* Encode message_3 as a sequence of CBOR encoded data items as * Encode message_3 as a sequence of CBOR encoded data items as
specified in Section 5.4.1. specified in Section 5.4.1.
skipping to change at page 37, line 8 skipping to change at page 37, line 8
- protected = h'' - protected = h''
- external_aad = TH_4 - external_aad = TH_4
- plaintext = ( ? EAD_4 ) - plaintext = ( ? EAD_4 )
where EAD_4 is protected external authorization data, see where EAD_4 is protected external authorization data, see
Section 3.8. COSE constructs the input to the AEAD [RFC5116] as Section 3.8. COSE constructs the input to the AEAD [RFC5116] as
follows: follows:
- Key K = EDHOC-Exporter( "EDHOC_message_4_Key", , length ) - Key K = EDHOC-Exporter( "EDHOC_message_4_Key", h'', length )
- Nonce N = EDHOC-Exporter( "EDHOC_message_4_Nonce", , length ) - Nonce N = EDHOC-Exporter( "EDHOC_message_4_Nonce", h'', length
)
- Plaintext P = ( ? EAD_4 ) - Plaintext P = ( ? EAD_4 )
- Associated data A = [ "Encrypt0", h'', TH_4 ] - Associated data A = [ "Encrypt0", h'', TH_4 ]
CIPHERTEXT_4 is the ciphertext of the COSE_Encrypt0. CIPHERTEXT_4 is the ciphertext of the COSE_Encrypt0.
* Encode message_4 as a sequence of CBOR encoded data items as * Encode message_4 as a sequence of CBOR encoded data items as
specified in Section 5.5.1. specified in Section 5.5.1.
skipping to change at page 38, line 48 skipping to change at page 38, line 48
Additional error codes and corresponding error information may be Additional error codes and corresponding error information may be
specified. specified.
+----------+---------------+----------------------------------------+ +----------+---------------+----------------------------------------+
| ERR_CODE | ERR_INFO Type | Description | | ERR_CODE | ERR_INFO Type | Description |
+==========+===============+========================================+ +==========+===============+========================================+
| 0 | any | Success | | 0 | any | Success |
+----------+---------------+----------------------------------------+ +----------+---------------+----------------------------------------+
| 1 | tstr | Unspecified | | 1 | tstr | Unspecified |
+----------+---------------+----------------------------------------+ +----------+---------------+----------------------------------------+
| 2 | SUITES_R | Wrong selected cipher suite | | 2 | suites | Wrong selected cipher suite |
+----------+---------------+----------------------------------------+ +----------+---------------+----------------------------------------+
Figure 6: Error Codes and Error Information Figure 6: Error Codes and Error Information
6.1. Success 6.1. Success
Error code 0 MAY be used internally in an application to indicate Error code 0 MAY be used internally in an application to indicate
success, e.g., in log files. ERR_INFO can contain any type of CBOR success, e.g., in log files. ERR_INFO can contain any type of CBOR
item. Error code 0 MUST NOT be used as part of the EDHOC message item. Error code 0 MUST NOT be used as part of the EDHOC message
exchange flow. exchange flow.
skipping to change at page 39, line 28 skipping to change at page 39, line 28
debugging need to interpret it in the context of the EDHOC debugging need to interpret it in the context of the EDHOC
specification. The diagnostic message SHOULD be provided to the specification. The diagnostic message SHOULD be provided to the
calling application where it SHOULD be logged. calling application where it SHOULD be logged.
6.3. Wrong Selected Cipher Suite 6.3. Wrong Selected Cipher Suite
Error code 2 MUST only be used in a response to message_1 in case the Error code 2 MUST only be used in a response to message_1 in case the
cipher suite selected by the Initiator is not supported by the cipher suite selected by the Initiator is not supported by the
Responder, or if the Responder supports a cipher suite more preferred Responder, or if the Responder supports a cipher suite more preferred
by the Initiator than the selected cipher suite, see Section 5.2.3. by the Initiator than the selected cipher suite, see Section 5.2.3.
ERR_INFO is of type SUITES_R: ERR_INFO is in this case denoted SUITES_R and is of type suites, see
Section 5.2.1). If the Responder does not support the selected
SUITES_R : [ supported : 2* suite ] / suite cipher suite, then SUITES_R MUST include one or more supported cipher
suites. If the Responder supports a cipher suite in SUITES_I other
If the Responder does not support the selected cipher suite, then than the selected cipher suite (independently of if the selected
SUITES_R MUST include one or more supported cipher suites. If the cipher suite is supported or not) then SUITES_R MUST include the
Responder does not support the selected cipher suite, but supports supported cipher suite in SUITES_I which is most preferred by the
another cipher suite in SUITES_I, then SUITES_R MUST include the Initiator. SUITES_R MAY include a single cipher suite, i.e. be
first supported cipher suite in SUITES_I. encoded as an int. If the Responder does not support any cipher
suite in SUITES_I, then it SHOULD include all its supported cipher
suites in SUITES_R in any order.
6.3.1. Cipher Suite Negotiation 6.3.1. Cipher Suite Negotiation
After receiving SUITES_R, the Initiator can determine which cipher After receiving SUITES_R, the Initiator can determine which cipher
suite to select for the next EDHOC run with the Responder. suite to select (if any) for the next EDHOC run with the Responder.
If the Initiator intends to contact the Responder in the future, the If the Initiator intends to contact the Responder in the future, the
Initiator SHOULD remember which selected cipher suite to use until Initiator SHOULD remember which selected cipher suite to use until
the next message_1 has been sent, otherwise the Initiator and the next message_1 has been sent, otherwise the Initiator and
Responder will likely run into an infinite loop. After a successful Responder will likely run into an infinite loop where the Initiator
run of EDHOC, the Initiator MAY remember the selected cipher suite to selects its most preferred and the Responder sends an error with
use in future EDHOC runs. Note that if the Initiator or Responder is supported cipher suites. After a successful run of EDHOC, the
updated with new cipher suite policies, any cached information may be Initiator MAY remember the selected cipher suite to use in future
EDHOC sessions. Note that if the Initiator or Responder is updated
with new cipher suite policies, any cached information may be
outdated. outdated.
6.3.2. Examples 6.3.2. Examples
Assume that the Initiator supports the five cipher suites 5, 6, 7, 8, Assume that the Initiator supports the five cipher suites 5, 6, 7, 8,
and 9 in decreasing order of preference. Figures 7 and 8 show and 9 in decreasing order of preference. Figures 7 and 8 show
examples of how the Initiator can truncate SUITES_I and how SUITES_R examples of how the Initiator can format SUITES_I and how SUITES_R is
is used by Responders to give the Initiator information about the used by Responders to give the Initiator information about the cipher
cipher suites that the Responder supports. suites that the Responder supports.
In the first example (Figure 7), the Responder supports cipher suite In the first example (Figure 7), the Responder supports cipher suite
6 but not the initially selected cipher suite 5. 6 but not the initially selected cipher suite 5.
Initiator Responder Initiator Responder
| METHOD, SUITES_I = 5, G_X, C_I, EAD_1 | | METHOD, SUITES_I = 5, G_X, C_I, EAD_1 |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_1 | | message_1 |
| | | |
| DIAG_MSG, SUITES_R = 6 | | ERR_CODE = 2, SUITES_R = 6 |
|<------------------------------------------------------------------+ |<------------------------------------------------------------------+
| error | | error |
| | | |
| METHOD, SUITES_I = [6, 5, 6], G_X, C_I, EAD_1 | | METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1 |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_1 | | message_1 |
Figure 7: Example of Responder supporting suite 6 but not suite 5. Figure 7: Example of Responder supporting suite 6 but not suite 5.
In the second example (Figure 8), the Responder supports cipher In the second example (Figure 8), the Responder supports cipher
suites 8 and 9 but not the more preferred (by the Initiator) cipher suites 8 and 9 but not the more preferred (by the Initiator) cipher
suites 5, 6 or 7. To illustrate the negotiation mechanics we let the suites 5, 6 or 7. To illustrate the negotiation mechanics we let the
Initiator first make a guess that the Responder supports suite 6 but Initiator first make a guess that the Responder supports suite 6 but
not suite 5. Since the Responder supports neither 5 nor 6, it not suite 5. Since the Responder supports neither 5 nor 6, it
responds with an error and SUITES_R, after which the Initiator responds with SUITES_R containing the supported suites, after which
selects its most preferred supported suite. The order of cipher the Initiator selects its most preferred supported suite. The order
suites in SUITES_R does not matter. (If the Responder had supported of cipher suites in SUITES_R does not matter. (If the Responder had
suite 5, it would include it in SUITES_R of the response, and it supported suite 5, it would have included it in SUITES_R of the
would in that case have become the selected suite in the second response, and it would in that case have become the selected suite in
message_1.) the second message_1.)
Initiator Responder Initiator Responder
| METHOD, SUITES_I = [6, 5, 6], G_X, C_I, EAD_1 | | METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1 |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_1 | | message_1 |
| | | |
| DIAG_MSG, SUITES_R = [9, 8] | | ERR_CODE = 2, SUITES_R = [9, 8] |
|<------------------------------------------------------------------+ |<------------------------------------------------------------------+
| error | | error |
| | | |
| METHOD, SUITES_I = [8, 5, 6, 7, 8], G_X, C_I, EAD_1 | | METHOD, SUITES_I = [5, 6, 7, 8], G_X, C_I, EAD_1 |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_1 | | message_1 |
Figure 8: Example of Responder supporting suites 8 and 9 but not Figure 8: Example of Responder supporting suites 8 and 9 but not
5, 6 or 7. 5, 6 or 7.
Note that the Initiator's list of supported cipher suites and order Note that the Initiator's list of supported cipher suites and order
of preference is fixed (see Section 5.2.1 and Section 5.2.2). of preference is fixed (see Section 5.2.1 and Section 5.2.2).
Furthermore, the Responder shall only accept message_1 if the Furthermore, the Responder shall only accept message_1 if the
selected cipher suite is the first cipher suite in SUITES_I that the selected cipher suite is the first cipher suite in SUITES_I that the
skipping to change at page 43, line 44 skipping to change at page 43, line 44
PRK_4x3m and TH_4. PRK_4x3m and TH_4.
Key compromise impersonation (KCI): In EDHOC authenticated with Key compromise impersonation (KCI): In EDHOC authenticated with
signature keys, EDHOC provides KCI protection against an attacker signature keys, EDHOC provides KCI protection against an attacker
having access to the long-term key or the ephemeral secret key. With having access to the long-term key or the ephemeral secret key. With
static Diffie-Hellman key authentication, KCI protection would be static Diffie-Hellman key authentication, KCI protection would be
provided against an attacker having access to the long-term Diffie- provided against an attacker having access to the long-term Diffie-
Hellman key, but not to an attacker having access to the ephemeral Hellman key, but not to an attacker having access to the ephemeral
secret key. Note that the term KCI has typically been used for secret key. Note that the term KCI has typically been used for
compromise of long-term keys, and that an attacker with access to the compromise of long-term keys, and that an attacker with access to the
ephemeral secret key can only attack that specific protocol run. ephemeral secret key can only attack that specific session.
Repudiation: In EDHOC authenticated with signature keys, the Repudiation: In EDHOC authenticated with signature keys, the
Initiator could theoretically prove that the Responder performed a Initiator could theoretically prove that the Responder performed a
run of the protocol by presenting the private ephemeral key, and vice run of the protocol by presenting the private ephemeral key, and vice
versa. Note that storing the private ephemeral keys violates the versa. Note that storing the private ephemeral keys violates the
protocol requirements. With static Diffie-Hellman key protocol requirements. With static Diffie-Hellman key
authentication, both parties can always deny having participated in authentication, both parties can always deny having participated in
the protocol. the protocol.
Two earlier versions of EDHOC have been formally analyzed [Norrman20] Two earlier versions of EDHOC have been formally analyzed [Norrman20]
skipping to change at page 48, line 14 skipping to change at page 48, line 14
protect against such attacks EDHOC needs to be in its own zone. To protect against such attacks EDHOC needs to be in its own zone. To
provide better protection against some forms of physical attacks, provide better protection against some forms of physical attacks,
sensitive EDHOC data should be stored inside the SoC or encrypted and sensitive EDHOC data should be stored inside the SoC or encrypted and
integrity protected when sent on a data bus (e.g., between the CPU integrity protected when sent on a data bus (e.g., between the CPU
and RAM or Flash). Secure boot can be used to increase the security and RAM or Flash). Secure boot can be used to increase the security
of code and data in the Rich Execution Environment (REE) by of code and data in the Rich Execution Environment (REE) by
validating the REE image. validating the REE image.
8. IANA Considerations 8. IANA Considerations
8.1. EDHOC Exporter Label 8.1. EDHOC Exporter Label Registry
IANA has created a new registry titled "EDHOC Exporter Label" under IANA has created a new registry titled "EDHOC Exporter Label" under
the new heading "EDHOC". The registration procedure is "Expert the new heading "EDHOC". The registration procedure is "Expert
Review". The columns of the registry are Label, Description, and Review". The columns of the registry are Label, Description, and
Reference. All columns are text strings. The initial contents of Reference. All columns are text strings. The initial contents of
the registry are: the registry are:
Label: EDHOC_message_4_Key Label: EDHOC_message_4_Key
Description: Key used to protect EDHOC message_4 Description: Key used to protect EDHOC message_4
Reference: [[this document]] Reference: [[this document]]
skipping to change at page 50, line 45 skipping to change at page 50, line 45
8.4. EDHOC Error Codes Registry 8.4. EDHOC Error Codes Registry
IANA has created a new registry entitled "EDHOC Error Codes" under IANA has created a new registry entitled "EDHOC Error Codes" under
the new heading "EDHOC". The registration procedure is the new heading "EDHOC". The registration procedure is
"Specification Required". The columns of the registry are ERR_CODE, "Specification Required". The columns of the registry are ERR_CODE,
ERR_INFO Type and Description, where ERR_CODE is an integer, ERR_INFO ERR_INFO Type and Description, where ERR_CODE is an integer, ERR_INFO
is a CDDL defined type, and Description is a text string. The is a CDDL defined type, and Description is a text string. The
initial contents of the registry are shown in Figure 6. initial contents of the registry are shown in Figure 6.
8.5. COSE Header Parameters Registry 8.5. EDHOC External Authorization Data Registry
IANA has created a new registry entitled "EDHOC External
Authorization Data" under the new heading "EDHOC". The registration
procedure is "Expert Review". The columns of the registry are Value,
Description, and Reference, where Value is an integer and the other
columns are text strings.
8.6. COSE Header Parameters Registry
This document registers the following entries in the "COSE Header This document registers the following entries in the "COSE Header
Parameters" registry under the "CBOR Object Signing and Encryption Parameters" registry under the "CBOR Object Signing and Encryption
(COSE)" heading. The value of the 'cwt' header parameter is a CWT (COSE)" heading. The value of the 'cwt' header parameter is a COSE
[RFC8392] or an Unprotected CWT Claims Set, see Section 1.5. Web Token (CWT) [RFC8392] and the value of the 'uccs' header
parameter is an Unprotected CWT Claims Set (UCCS), see Section 1.5.
+-----------+-------+----------------+------------------------------+ +-----------+-------+----------------+---------------------------+
| Name | Label | Value Type | Description | | Name | Label | Value Type | Description |
+===========+=======+================+==============================+ +===========+=======+================+===========================+
| cwt | TBD1 | COSE_Messages | A CBOR Web Token (CWT) or an | | cwt | TBD1 | COSE_Messages | A CBOR Web Token (CWT) |
| | | / map | Unprotected CWT Claims Set | +-----------+-------+----------------+---------------------------+
+-----------+-------+----------------+------------------------------+ | uccs | TBD2 | map | An Unprotected CWT Claims |
| | | | Set (UCCS) |
+-----------+-------+----------------+---------------------------+
8.6. COSE Header Parameters Registry 8.7. COSE Header Parameters Registry
IANA has extended the Value Type of the COSE Header Parameter 'kid' IANA has extended the Value Type of the COSE Header Parameter 'kid'
to also allow the Value Type int. The resulting Value Type is bstr / to also allow the Value Type int. The resulting Value Type is bstr /
int. The 'kid' parameter can be used to identify a key stored in a int. The 'kid' parameter can be used to identify a key stored in a
UCCS, in a CWT, or in a public key certificate. (The Value Registry UCCS, in a CWT, or in a public key certificate. (The Value Registry
for this item is empty and omitted from the table below.) for this item is empty 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 | [RFC9052] |
| | | | | [[This document]] | | | | | | [[This document]] |
+------+-------+------------+----------------+-------------------+ +------+-------+------------+----------------+-------------------+
8.7. COSE Key Common Parameters Registry 8.8. COSE Key Common Parameters Registry
IANA has extended the Value Type of the COSE Key Common Parameter IANA has extended the Value Type of the COSE Key Common Parameter
'kid' to the COSE Key Value Type int. The resulting Value Type is 'kid' to the COSE Key Value Type int. The resulting Value Type is
bstr / int. (The Value Registry for this item is empty and omitted bstr / int. (The Value Registry for this item is empty and omitted
from the table below.) 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- | [RFC9052] |
| | | | cation value - | [[This document]] | | | | | cation value - | [[This document]] |
| | | | match to kid | | | | | | match to kid | |
| | | | in message | | | | | | in message | |
+------+-------+------------+----------------+-------------------+ +------+-------+------------+----------------+-------------------+
8.8. The Well-Known URI Registry 8.9. CWT Confirmation Methods Registry
IANA has extended the Value Type of the WT Confirmation Methods 'kid'
to the COSE Key Value Type int. The incorrect term binary string has
been corrected to bstr. The resulting Value Type is bstr / int. The
new updated content for the 'kid' method is shown in the list below.
* Confirmation Method Name: kid
* Confirmation Method Description: Key Identifier
* JWT Confirmation Method Name: kid
* Confirmation Key: 3
* Confirmation Value Type(s): bstr / int
* Change Controller: IESG
* Specification Document(s): Section 3.4 of RFC 8747 [[This
document]]
8.10. The Well-Known URI Registry
IANA has added the well-known URI "edhoc" to the Well-Known URIs IANA has added the well-known URI "edhoc" to the Well-Known URIs
registry. registry.
* URI suffix: edhoc * URI suffix: edhoc
* Change controller: IETF * Change controller: IETF
* Specification document(s): [[this document]] * Specification document(s): [[this document]]
* Related information: None * Related information: None
8.9. Media Types Registry 8.11. Media Types Registry
IANA has added the media type "application/edhoc" to the Media Types IANA has added the media type "application/edhoc" to the Media Types
registry. registry.
* Type name: application * Type name: application
* Subtype name: edhoc * Subtype name: edhoc
* Required parameters: N/A * Required parameters: N/A
skipping to change at page 53, line 5 skipping to change at page 53, line 35
"Authors' Addresses" section. "Authors' Addresses" section.
* Intended usage: COMMON * Intended usage: COMMON
* Restrictions on usage: N/A * Restrictions on usage: N/A
* Author: See "Authors' Addresses" section. * Author: See "Authors' Addresses" section.
* Change Controller: IESG * Change Controller: IESG
8.10. CoAP Content-Formats Registry 8.12. CoAP Content-Formats Registry
IANA has added the media type "application/edhoc" to the CoAP IANA has added the media type "application/edhoc" to the CoAP
Content-Formats registry. Content-Formats registry.
* Media Type: application/edhoc * Media Type: application/edhoc
* Encoding: * Encoding:
* ID: TBD42 * ID: TBD42
* Reference: [[this document]] * Reference: [[this document]]
8.11. EDHOC External Authorization Data 8.13. Expert Review Instructions
IANA has created a new registry entitled "EDHOC External
Authorization Data" under the new heading "EDHOC". The registration
procedure is "Expert Review". The columns of the registry are Value,
Description, and Reference, where Value is an integer and the other
columns are text strings.
8.12. Expert Review Instructions
The IANA Registries established in this document is defined as The IANA Registries established in this document is defined as
"Expert Review". This section gives some general guidelines for what "Expert Review". This section gives some general guidelines for what
the experts should be looking for, but they are being designated as the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude. experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
* Clarity and correctness of registrations. Experts are expected to * Clarity and correctness of registrations. Experts are expected to
check the clarity of purpose and use of the requested entries. check the clarity of purpose and use of the requested entries.
skipping to change at page 60, line 48 skipping to change at page 61, line 33
Salt", respectively. Salt", respectively.
The context parameter is h'' (0x40), the empty CBOR byte string. The context parameter is h'' (0x40), the empty CBOR byte string.
By default, key_length is the key length (in bytes) of the By default, key_length is the key length (in bytes) of the
application AEAD Algorithm of the selected cipher suite for the EDHOC application AEAD Algorithm of the selected cipher suite for the EDHOC
session. Also by default, salt_length has value 8. The Initiator session. Also by default, salt_length has value 8. The Initiator
and Responder MAY agree out-of-band on a longer key_length than the and Responder MAY agree out-of-band on a longer key_length than the
default and on a different salt_length. default and on a different salt_length.
Master Secret = EDHOC-Exporter( "OSCORE Master Secret", , key_length ) Master Secret = EDHOC-Exporter("OSCORE Master Secret", h'', key_length)
Master Salt = EDHOC-Exporter( "OSCORE Master Salt", , salt_length ) Master Salt = EDHOC-Exporter("OSCORE Master Salt", h'', salt_length)
* The AEAD Algorithm is the application AEAD algorithm of the * The AEAD Algorithm is the application AEAD algorithm of the
selected cipher suite for the EDHOC session. selected cipher suite for the EDHOC session.
* The HKDF Algorithm is the one based on the application hash * The HKDF Algorithm is the one based on the application hash
algorithm of the selected cipher suite for the EDHOC session. For algorithm of the selected cipher suite for the EDHOC session. For
example, if SHA-256 is the application hash algorithm of the example, if SHA-256 is the application hash algorithm of the
selected ciphersuite, HKDF SHA-256 is used as HKDF Algorithm in selected cipher suite, HKDF SHA-256 is used as HKDF Algorithm in
the OSCORE Security Context. the OSCORE Security Context.
* In case the Client is Initiator and the Server is Responder, the * In case the Client is Initiator and the Server is Responder, the
Client's OSCORE Sender ID and the Server's OSCORE Sender ID are Client's OSCORE Sender ID and the Server's OSCORE Sender ID are
determined from the EDHOC connection identifiers C_R and C_I for determined from the EDHOC connection identifiers C_R and C_I for
the EDHOC session, respectively, by applying the conversion in the EDHOC session, respectively, by applying the conversion in
Appendix A.1. The reverse applies in case the Client is the Appendix A.1. The reverse applies in case the Client is the
Responder and the Server is the Initiator. Responder and the Server is the Initiator.
Client and Server use the parameters above to establish an OSCORE Client and Server use the parameters above to establish an OSCORE
skipping to change at page 67, line 7 skipping to change at page 67, line 7
( 1, 2, true ) 0x0102f5 sequence ( 1, 2, true ) 0x0102f5 sequence
1, 2, true 0x0102f5 sequence 1, 2, true 0x0102f5 sequence
------------------------------------------------------------------ ------------------------------------------------------------------
C.2. CDDL Definitions C.2. CDDL Definitions
This sections compiles the CDDL definitions for ease of reference. This sections compiles the CDDL definitions for ease of reference.
suite = int suite = int
suites = [ 2* suite ] / suite
ead = 1* ( ead = 1* (
type : int, type : int,
ext_authz_data : any, ext_authz_data : any,
) )
message_1 = ( message_1 = (
METHOD : int, METHOD : int,
SUITES_I : [ selected : suite, supported : 2* suite ] / suite, SUITES_I : suites,
G_X : bstr, G_X : bstr,
C_I : bstr / int, C_I : bstr / int,
? EAD_1 : ead, ? EAD_1 : ead,
) )
message_2 = ( message_2 = (
G_Y_CIPHERTEXT_2 : bstr, G_Y_CIPHERTEXT_2 : bstr,
C_R : bstr / int, C_R : bstr / int,
) )
message_3 = ( message_3 = (
CIPHERTEXT_3 : bstr, CIPHERTEXT_3 : bstr,
) )
message_4 = ( message_4 = (
CIPHERTEXT_4 : bstr, CIPHERTEXT_4 : bstr,
) )
SUITES_R : [ supported : 2* suite ] / suite
error = ( error = (
ERR_CODE : int, ERR_CODE : int,
ERR_INFO : any, ERR_INFO : any,
) )
info = [ info = (
edhoc_aead_id : int / tstr, edhoc_aead_id : int / tstr,
transcript_hash : bstr, transcript_hash : bstr,
label : tstr, label : tstr,
* context : any, context : bstr,
length : uint, length : uint,
] )
C.3. COSE C.3. COSE
CBOR Object Signing and Encryption (COSE) CBOR Object Signing and Encryption (COSE)
[I-D.ietf-cose-rfc8152bis-struct] describes how to create and process [I-D.ietf-cose-rfc8152bis-struct] describes how to create and process
signatures, message authentication codes, and encryption using CBOR. signatures, message authentication codes, and encryption using CBOR.
COSE builds on JOSE, but is adapted to allow more efficient COSE builds on JOSE, but is adapted to allow more efficient
processing in constrained devices. EDHOC makes use of COSE_Key, processing in constrained devices. EDHOC makes use of COSE_Key,
COSE_Encrypt0, and COSE_Sign1 objects in the message processing: COSE_Encrypt0, and COSE_Sign1 objects in the message processing:
skipping to change at page 70, line 51 skipping to change at page 70, line 51
server does not send any such indicator, as responses are matched to server does not send any such indicator, as responses are matched to
request by the client-server protocol design. request by the client-server protocol design.
Protocols that do not provide any correlation at all can prescribe Protocols that do not provide any correlation at all can prescribe
prepending of the peer's chosen C_x to all messages. prepending of the peer's chosen C_x to all messages.
Appendix H. Change Log Appendix H. Change Log
RFC Editor: Please remove this appendix. RFC Editor: Please remove this appendix.
Main changes: * From -09 to -10:
- SUITES_I simplified to only contain the selected and more
preferred suites
- Info is a CBOR sequence and context is a bstr
- Added kid to UCCS example
- Separate header parameters for CWT and UCCS
- CWT Confirmation Method kid extended to bstr / int
* From -08 to -09: * From -08 to -09:
- G_Y and CIPHERTEXT_2 are now included in one CBOR bstr - G_Y and CIPHERTEXT_2 are now included in one CBOR bstr
- MAC_2 and MAC_3 are now generated with EDHOC-KDF - MAC_2 and MAC_3 are now generated with EDHOC-KDF
- Info field "context" is now general and explicit in EDHOC-KDF - Info field "context" is now general and explicit in EDHOC-KDF
- Restructured Section 4, Key Derivation - Restructured Section 4, Key Derivation
 End of changes. 67 change blocks. 
156 lines changed or deleted 192 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/