Draft: draft-ietf-lake-edhoc

Commentary: At first glance , I like this better than , as here I do n't have to keep the number of elements in EAD_3 around . ( I 'll have to have processed them at some point , but that does n't mean I 'm keeping the count around ) . 
 Based on Christians comment . I would suggest that we merge this . I think allowing a CBOR sequence in the exporter migth also be a good idea . That allows external applications to input a CBOR sequence . The implementation allows a implementation to input tsrt , bsrt . That is just a special case when the CBOR sequence consist of a single bstr . 
 COSE has discussed and are are planning to standardize new encryption algorithms for the AEAD interface after a request from FIDO . The new algorithms would not provide any integrity protection . The current version of the Group OSCORE draft would not be secure at all with these new algorithms due to the unusual design choice to let the sender countersign it 's own AEAD . This could easily be addressed by using a traditional MAC - then - Sign approach . EDHOC currently uses the inner COSE_Encrypt as a MAC function , this would of course be unsecure if the encryption function is AES - CTR . 
 Might actually be a very good idea to change the inner COSEEncrypt0 to just a simple single invocation of the EDHOC - KDF ( ) . As pointed out in [ 1 ] the short MAC length is probably the weakest point in the EDHOC design . [ 1 ] Chaning inner COSEEncrypt0 to EDHOC - KDF ( ) would significantly simplify the specification NEW OLD 
 " K2 m " , " K3 m " , " IV2 m " , " IV3 m " could then be removed from the specification . 
 I think this is a significant simplification that also saves memory . The CPU saving are likely minimal compared to the asymmetric operations . Additional benefits are that the MAC length becomes flexible . We could then define a full MAC length for the Signature modes . I do n't see any disadvantages . I will make a PR during next week . 
 This is the PR : 
 If we merge this PR we should remove the following sentence from 3.5.1 . " The MAC is implemented with an AEAD algorithm . " 
 Made two new PRs and deleted the old ones . Began implementing with a CBOR sequence . I then modified to where an array is used instead of a sequence . is likely the better choice . I think somebody expressed that it was good if context is explicit . also seems simpler . 
 Thinking more maybe CBOR bstr for context is the best If so , should the context for MAC2 be ? I do n't think the following definition in the current draft is correct : Key K = EDHOC - Exporter ( " EDHOCmessage4Key " , h '' , length ) The exporter takes an byte string and calls the the EDHOC - KDF . The caller of the exporter does not need to do any CBOR encoding . 
 The last point , empty byte string representation , relates to . 
 The input to the exporter should likely be a byte string ( not a CBOR encoded bstr ) The input to the KDF could be something different e.g. a sequence . 
 Maybe mac_length and AEAD should be decoupled . They are independent things with different purposes . Maybe the Static DH mac length should be to the cipher suite instead . 
 Comments from Christian during IETF 111 is that sequence is better than array for EDHOC - KDF 
 Based on Christian comments I would say that the current plan is to merge with the byte string change above for the exporter : Exporter context is a byte string ( not CBOR ) EDHOC - KDF context is a CBOR sequence 
 I suggest merging as is . That seems like the best and most flexible solution 
 We could make context a separate parameter without changing anything else in EDHOC - Exporter(label , context , length ) = EDHOC - KDF(PRK4x3 m , TH4 , label , context , length )  MAC2 = EDHOC - KDF ( PRK3x2 m , TH2 , " MAC2 " , ( IDCREDR , CREDR , ? AD2 ) , maclength ) Master Secret = EDHOC - Exporter ( " OSCORE Master Secret " , , keylength ) 
 The agreed solution with a sequnece that Christian preferred has been merged . Closing this
Paragraph (version A):
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,
perfect 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.
Paragraph (version B):
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.
Paragraph (version A):
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
lightweight authenticated key exchange protocol providing good
security properties including perfect forward secrecy, identity
protection, and cipher suite negotiation.  Authentication can be
based on raw public keys (RPK) or public key certificates, and
requires the application to provide input on how to verify that
endpoints are trusted.  This specification focuses on referencing
instead of transporting credentials to reduce message overhead.
Paragraph (version B):
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
lightweight authenticated key exchange protocol providing good
security properties including forward secrecy, identity protection,
and cipher suite negotiation.  Authentication can be based on raw
public keys (RPK) or public key certificates and requires the
application to provide input on how to verify that endpoints are
trusted.  This specification focuses on referencing instead of
transporting credentials to reduce message overhead.  EDHOC does
currently not support pre-shared key (PSK) authentication as
authentication with static Diffie-Hellman public keys by reference
produces equally small message sizes but with much simpler key
distribution.
Paragraph (version A):
EDHOC is designed for highly constrained settings making it
especially suitable for low-power wide area networks RFC8376 such as
Cellular IoT, 6TiSCH, and LoRaWAN.  A main objective for EDHOC is to
be a lightweight authenticated key exchange for OSCORE, i.e. to
provide authentication and session key establishment for IoT use
cases such as those built on CoAP RFC7252.  CoAP is a specialized web
transfer protocol for use with constrained nodes and networks,
providing a request/response interaction model between application
endpoints.  As such, EDHOC is targeting a large variety of use cases
involving 'things' with embedded microcontrollers, sensors, and
actuators.
Paragraph (version B):
EDHOC is designed for highly constrained settings making it
especially suitable for low-power wide area networks RFC8376 such as
Cellular IoT, 6TiSCH, and LoRaWAN.  A main objective for EDHOC is to
be a lightweight authenticated key exchange for OSCORE, i.e., to
provide authentication and session key establishment for IoT use
cases such as those built on CoAP RFC7252.  CoAP is a specialized web
transfer protocol for use with constrained nodes and networks,
providing a request/response interaction model between application
endpoints.  As such, EDHOC is targeting a large variety of use cases
involving 'things' with embedded microcontrollers, sensors, and
actuators.
Paragraph (version A):
A typical setting is when one of the endpoints is constrained or in a
constrained network, and the other endpoint is a node on the Internet
(such as a mobile phone) or at the edge of the constrained network
(such as a gateway).  Thing-to-thing interactions over constrained
networks are also relevant since both endpoints would then benefit
from the lightweight properties of the protocol.  EDHOC could e.g. be
run when a device connects for the first time, or to establish fresh
keys which are not revealed by a later compromise of the long-term
keys.  Further security properties are described in sec-prop.
Paragraph (version A):
EDHOC enables the reuse of the same lightweight primitives as OSCORE:
CBOR for encoding, COSE for cryptography, and CoAP for transport.  By
reusing existing libraries the additional code size can be kept very
low.  Note that, while CBOR and COSE primitives are built into the
protocol messages, EDHOC is not bound to a particular transport.
Transfer of EDHOC messages in CoAP payloads is detailed in coap.
Paragraph (version B):
A typical setting is when one of the endpoints is constrained or in a
constrained network, and the other endpoint is a node on the Internet
(such as a mobile phone) or at the edge of the constrained network
(such as a gateway).  Thing-to-thing interactions over constrained
networks are also relevant since both endpoints would then benefit
from the lightweight properties of the protocol.  EDHOC could e.g.,
be run when a device connects for the first time, or to establish
fresh keys which are not revealed by a later compromise of the long-
term keys.  Further security properties are described in sec-prop.
Paragraph (version B):
EDHOC enables the reuse of the same lightweight primitives as OSCORE:
CBOR for encoding, COSE for cryptography, and CoAP for transport.  By
reusing existing libraries, the additional code size can be kept very
low.  Note that, while CBOR and COSE primitives are built into the
protocol messages, EDHOC is not bound to a particular transport.
Transfer of EDHOC messages in CoAP payloads is detailed in coap.
Paragraph (version A):
We use the term Unprotected CWT Claims Set (UCCS) just as in I-
D.ietf-rats-uccs to denote a CBOR Web Token RFC8392 without wrapping
it into a COSE object, i.e. a CBOR map consisting of claims.
Paragraph (version B):
We use the term Unprotected CWT Claims Set (UCCS) just as in I-
D.ietf-rats-uccs to denote a CBOR Web Token RFC8392 without wrapping
it into a COSE object, i.e., a CBOR map consisting of claims.
Paragraph (version A):
EDHOC specifies different authentication methods of the Diffie-
Hellman key exchange: digital signatures and static Diffie-Hellman
keys.  This section outlines the digital signature based method.
Further details of protocol elements and other authentication methods
are provided in the remainder of this document.
Paragraph (version B):
EDHOC specifies different authentication methods of the Diffie-
Hellman key exchange: digital signatures and static Diffie-Hellman
keys.  This section outlines the digital signature-based method.
Further details of protocol elements and other authentication methods
are provided in the remainder of this document.
Paragraph (version A):
A key material exporter and a key update function enabling
frequent forward secrecy.
Paragraph (version B):
A key material exporter and a key update function enabling forward
secrecy.
Paragraph (version A):
Connection identifiers in EDHOC are byte strings or integers, encoded
in CBOR.  One byte connection identifiers (the integers -24 to 23 and
the empty bytestring h'') are realistic in many scenarios as most
constrained devices only have a few connections.
Paragraph (version B):
Connection identifiers in EDHOC are byte strings or integers, encoded
in CBOR.  One byte connection identifiers (the integers -24 to 23 and
the empty byte string h'') are realistic in many scenarios as most
constrained devices only have a few connections.
Paragraph (version A):
For OSCORE, the choice of a connection identifier results in the
endpoint selecting its Recipient ID, see Section 3.1 of RFC8613), for
which certain uniqueness requirements apply, see Section 3.3 of
RFC8613).  Therefore the Initiator and the Responder MUST NOT select
connection identifiers such that it results in same OSCORE Recipient
ID.  Since the Recipient ID is a byte string and a EDHOC connection
identifier is either a CBOR byte string or a CBOR integer, care must
be taken when selecting the connection identifiers and converting
them to Recipient IDs.  A mapping from EDHOC connection identifier to
OSCORE Recipient ID is specified in edhoc-to-oscore.
Paragraph (version B):
For OSCORE, the choice of a connection identifier results in the
endpoint selecting its Recipient ID, see Section 3.1 of RFC8613, for
which certain uniqueness requirements apply, see Section 3.3 of
RFC8613.  Therefore, the Initiator and the Responder MUST NOT select
connection identifiers such that it results in same OSCORE Recipient
ID.  Since the Recipient ID is a byte string and a EDHOC connection
identifier is either a CBOR byte string or a CBOR integer, care must
be taken when selecting the connection identifiers and converting
them to Recipient IDs.  A mapping from EDHOC connection identifier to
OSCORE Recipient ID is specified in edhoc-to-oscore.
Paragraph (version A):
denial of service protection.
Paragraph (version A):
Besides these common transport oriented properties, EDHOC transport
additionally needs to support the correlation between EDHOC messages,
including an indication of a message being message_1.  The
correlation may reuse existing mechanisms in the transport protocol.
For example, the CoAP Token may be used to correlate EDHOC messages
in a CoAP response and an associated CoAP request.  In the absense of
correlation between a message received and a message previously sent
inherent to the transport, the EDHOC connection identifiers may be
added, e.g. by prepending the appropriate connection identifier (when
available from the EDHOC protocol) to the EDHOC message.  Transport
of EDHOC in CoAP payloads is described in coap, which also shows how
to use connection identifiers and message_1 indication with CoAP.
Paragraph (version B):
denial-of-service protection.
Paragraph (version B):
Besides these common transport-oriented properties, EDHOC transport
additionally needs to support the correlation between EDHOC messages,
including an indication of a message being message_1.  The
correlation may reuse existing mechanisms in the transport protocol.
For example, the CoAP Token may be used to correlate EDHOC messages
in a CoAP response and an associated CoAP request.  In the absence of
correlation between a message received and a message previously sent
inherent to the transport, the EDHOC connection identifiers may be
added, e.g., by prepending the appropriate connection identifier
(when available from the EDHOC protocol) to the EDHOC message.
Transport of EDHOC in CoAP payloads is described in coap, which also
shows how to use connection identifiers and message_1 indication with
CoAP.
Paragraph (version A):
EDHOC enables public-key based authentication and supports various
settings for how the other endpoint's public key is transported,
identified and trusted.
Paragraph (version B):
EDHOC enables public-key based authentication and supports various
settings for how the other endpoint's public key is transported,
identified, and trusted.
Paragraph (version A):
The choice of authentication credential also depends on the trust
model.  For example, a certificate or CWT may rely on a trusted third
party, whereas a UCCS may be used when trust in the public key can be
achieved by other means, or in the case of trust-on-first-use.  A
UCCS as authentication credential provides essentially the same
trustworthiness as a self-signed certificate or CWT, but has smaller
size.
Paragraph (version B):
The choice of authentication credential also depends on the trust
model.  For example, a certificate or CWT may rely on a trusted third
party, whereas a UCCS may be used when trust in the public key can be
achieved by other means, or in the case of trust-on-first-use.  A
UCCS as authentication credential provides essentially the same
trustworthiness as a self-signed certificate or CWT but has smaller
size.
Paragraph (version A):
The authentication key MUST be a signature key or static Diffie-
Hellman key.  The Initiator and the Responder MAY use different types
of authentication keys, e.g. one uses a signature key and the other
uses a static Diffie-Hellman key.  When using a signature key, the
authentication is provided by a signature.  When using a static
Diffie-Hellman key the authentication is provided by a Message
Authentication Code (MAC) computed from an ephemeral-static ECDH
shared secret which enables significant reductions in message sizes.
The MAC is implemented with an AEAD algorithm.  When using static
Diffie-Hellman keys the Initiator's and Responder's private
authentication keys are called I and R, respectively, and the public
authentication keys are called G_I and G_R, respectively.  The
authentication key algorithm needs to specified with enough
parameters to make it completely determined.  Note that for most
signature algorithms, the signature is determined by the signature
algorithm and the authentication key algorithm together.  For
example, the curve used in the signature is typically determined by
the authentication key parameters.
Paragraph (version B):
The authentication key MUST be a signature key or static Diffie-
Hellman key.  The Initiator and the Responder MAY use different types
of authentication keys, e.g., one uses a signature key and the other
uses a static Diffie-Hellman key.  When using a signature key, the
authentication is provided by a signature.  When using a static
Diffie-Hellman key the authentication is provided by a Message
Authentication Code (MAC) computed from an ephemeral-static ECDH
shared secret which enables significant reductions in message sizes.
When using static Diffie-Hellman keys the Initiator's and Responder's
private authentication keys are called I and R, respectively, and the
public authentication keys are called G_I and G_R, respectively.  The
authentication key algorithm needs to specified with enough
parameters to make it completely determined.  Note that for most
signature algorithms, the signature is determined by the signature
algorithm and the authentication key algorithm together.  For
example, the curve used in the signature is typically determined by
the authentication key parameters.
Paragraph (version A):
The authentication credentials, CRED_I and CRED_R, contain the public
authentication key of the Initiator and the Responder, respectively.
The Initiator and the Responder MAY use different types of
credentials, e.g. one uses an UCCS and the other uses an X.509
certificate.
Paragraph (version A):
The credentials CRED_I and CRED_R are signed or MAC:ed (in the
Signature_OR_MAC field, depending on method) by the Initiator and the
Responder, respectively, see m3 and m2.
Paragraph (version A):
When the credential is a certificate, CRED_x is an end-entity
certificate (i.e. not the certificate chain), encoded as a CBOR bstr.
In X.509 and C509 certificates, signature keys typically have key
usage "digitalSignature" and Diffie-Hellman public keys typically
have key usage "keyAgreement".
Paragraph (version B):
The authentication credentials, CRED_I and CRED_R, contain the public
authentication key of the Initiator and the Responder, respectively.
The Initiator and the Responder MAY use different types of
credentials, e.g., one uses an UCCS and the other uses an X.509
certificate.
Paragraph (version B):
The credentials CRED_I and CRED_R are signed or MACed (in the
Signature_OR_MAC field, depending on method) by the Initiator and the
Responder, respectively, see m3 and m2.
Paragraph (version A):
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
parameter "kid" or "kid2".  The latter is introduced to allow more
one-byte identifiers (see kid2-header-param and kid2-key-common-
param) which may be useful in many scenarios since constrained
devices only have a few keys.  Note that in CBOR, the integers -24 to
23 and the empty bytestring h'' are encoded as one byte.
Paragraph (version B):
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
parameter "kid" or "kid2".  The latter is introduced to allow more
one-byte identifiers (see kid2-header-param and kid2-key-common-
param) which may be useful in many scenarios since constrained
devices only have a few keys.  Note that in CBOR, the integers -24 to
23 and the empty byte string h'' are encoded as one byte.
Paragraph (version A):
An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries.
Algorithms need to be specified with enough parameters to make them
completely determined.  Currently, none of the algorithms require
parameters.  EDHOC is only specified for use with key exchange
algorithms of type ECDH curves.  Use with other types of key exchange
algorithms would likely require a specification updating EDHOC.  Note
that for most signature algorithms, the signature is determined by
the signature algorithm and the authentication key algorithm
together, see auth-keys.
Paragraph (version B):
An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length.  Algorithms need to be specified with enough
parameters to make them completely determined.  Currently, none of
the algorithms require parameters.  EDHOC is only specified for use
with key exchange algorithms of type ECDH curves.  Use with other
types of key exchange algorithms would likely require a specification
updating EDHOC.  Note that for most signature algorithms, the
signature is determined by the signature algorithm and the
authentication key algorithm together, see auth-keys.
Paragraph (version A):
For other parameters, like CRED_x in the case that it is not
transported, it may not be possible to verify that incompliance with
applicability statement was the reason for failure: Integrity
verification in message_2 or message_3 may fail not only because of
wrong authentication credential.  For example, in case the Initiator
uses public key certificate by reference (i.e. not transported within
the protocol) then both endpoints need to use an identical data
structure as CRED_I or else the integrity verification will fail.
Paragraph (version B):
For other parameters, like CRED_x in the case that it is not
transported, it may not be possible to verify that incompliance with
applicability statement was the reason for failure: Integrity
verification in message_2 or message_3 may fail not only because of
wrong authentication credential.  For example, in case the Initiator
uses public key certificate by reference (i.e., not transported
within the protocol) then both endpoints need to use an identical
data structure as CRED_I or else the integrity verification will
fail.
Paragraph (version A):
PRK_2e is used to derive a keystream to encrypt message_2.  PRK_3e2m
is used to derive keys and IVs to produce a MAC in message_2 and to
encrypt message_3.  PRK_4x3m is used to derive keys and IVs to
produce a MAC in message_3 and to derive application specific data.
Paragraph (version B):
PRK_2e is used to derive a keystream to encrypt message_2.  PRK_3e2m
is used to produce a MAC in message_2 and to encrypt message_3.
PRK_4x3m is used to produce a MAC in message_3, to encrypt message_4,
and to derive application specific data.
Paragraph (version A):
label is a tstr set to the name of the derived key or IV, i.e.
"K_2m", "IV_2m", "KEYSTREAM_2", "K_3m", "IV_3m", "K_3ae", or
"IV_3ae".
Paragraph (version A):
If the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, length
) = HKDF-Expand( PRK, info, length ) RFC5869.  If the EDHOC hash
algorithm is SHAKE128, then Expand( PRK, info, length ) = KMAC128(
PRK, info, L, "" ).  If the EDHOC hash algorithm is SHAKE256, then
Expand( PRK, info, length ) = KMAC256( PRK, info, L, "" ).
Paragraph (version A):
KEYSTREAM_2 are derived using the transcript hash TH_2 and the
pseudorandom key PRK_2e.  K_2m and IV_2m are derived using the
transcript hash TH_2 and the pseudorandom key PRK_3e2m.  K_3ae and
IV_3ae are derived using the transcript hash TH_3 and the
pseudorandom key PRK_3e2m.  K_3m and IV_3m are derived using the
transcript hash TH_3 and the pseudorandom key PRK_4x3m.  IVs are only
used if the EDHOC AEAD algorithm uses IVs.
Paragraph (version A):
where label is a registered tstr from the EDHOC Exporter Label
registry (exporter-label), context is a bstr defined by the
application, and length is a uint defined by the application.  The
(label, context) pair must be unique, i.e. a (label, context) MUST
NOT be used for two different purposes.  However an application can
re-derive the same key several times as long as it is done in a
secure way.  For example, in most encryption algorithms the same
(key, nonce) pair must not be reused.
Paragraph (version B):
label is a tstr set to the name of the derived key or IV, i.e.
"KEYSTREAM_2", "MAC_2", "K_3ae", "IV_3ae", or "MAC_3".
Paragraph (version B):
If the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, length
) = HKDF-Expand( PRK, info, length ) RFC5869.  If the EDHOC hash
algorithm is SHAKE128, then Expand( PRK, info, length ) = KMAC128(
PRK, info, , "" ).  If the EDHOC hash algorithm is SHAKE256, then
Expand( PRK, info, length ) = KMAC256( PRK, info, L, "" ).  L =
8*length is the output length in bits.
Paragraph (version B):
KEYSTREAM_2 is derived using the transcript hash TH_2 and the
pseudorandom key PRK_2e.  MAC_2 is derived using the transcript hash
TH_2 and the pseudorandom key PRK_3e2m.  K_3ae and IV_3ae are derived
using the transcript hash TH_3 and the pseudorandom key PRK_3e2m.
MAC_3 is derived using the transcript hash TH_3 and the pseudorandom
key PRK_4x3m.  IVs are only used if the EDHOC AEAD algorithm uses
IVs.  KEYSTREAM_2, K_3ae, and IV_3ae do not use a context.  MAC_2 and
MAC_3 use context as defined in asym-msg2-proc and asym-msg3-proc,
respectively.
Paragraph (version B):
where label is a registered tstr from the EDHOC Exporter Label
registry (exporter-label), context is a CBOR sequence defined by the
application, and length is a uint defined by the application.  The
(label, context) pair must be unique, i.e., a (label, context) MUST
NOT be used for two different purposes.  However an application can
re-derive the same key several times as long as it is done in a
secure way.  For example, in most encryption algorithms the same
(key, nonce) pair must not be reused.  The context can for example be
the empty (zero-length) sequence or a single CBOR byte string.
Paragraph (version B):
The EDHOC-KeyUpdate takes a nonce as input to guarantee that there
are no short cycles.  The Initiator and the Responder need to agree
on the nonce, which can e.g., be a counter or a random number.  While
the KeyUpdate method provides forward secrecy it does not give as
strong security properties as re-running EDHOC, see security.
Paragraph (version A):
While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
structures, only a subset of the parameters is included in the EDHOC
messages, see COSE.  The unprotected COSE header in COSE_Sign1, and
COSE_Encrypt0 (not included in the EDHOC message) MAY contain
parameters (e.g. 'alg').
Paragraph (version B):
While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
structures, only a subset of the parameters is included in the EDHOC
messages, see COSE.  The unprotected COSE header in COSE_Sign1, and
COSE_Encrypt0 (not included in the EDHOC message) MAY contain
parameters (e.g., 'alg').
Paragraph (version A):
For each session, the endpoints are assumed to keep an associated
protocol state containing identifiers, keys, etc. used for subsequent
processing of protocol related data.  The protocol state is assumed
to be associated to an applicability statement (applicability) which
provides the context for how messages are transported, identified and
processed.
Paragraph (version B):
For each session, the endpoints are assumed to keep an associated
protocol state containing identifiers, keys, etc. used for subsequent
processing of protocol related data.  The protocol state is assumed
to be associated to an applicability statement (applicability) which
provides the context for how messages are transported, identified,
and processed.
Paragraph (version A):
If the message received is an error message then process according
to error, else process as the expected next message according to
the protocol state.
Paragraph (version B):
If the message received is an error message, then process
according to error, else process as the expected next message
according to the protocol state.
Paragraph (version A):
SUITES_I - cipher suites which the Initiator supports in order of
(decreasing) preference.  The list of supported cipher suites can
be truncated at the end, as is detailed in the processing steps
below and wrong-selected.  One of the supported cipher suites is
selected.  The selected suite is the first suite in the SUITES_I
CBOR array.  If a single supported cipher suite is conveyed then
that cipher suite is selected and SUITES_I is encoded as an int
instead of an array.
Paragraph (version B):
SUITES_I - cipher suites which the Initiator supports in order of
(decreasing) preference.  The list of supported cipher suites can
be truncated at the end, as is detailed in the processing steps
below and wrong-selected.  One of the supported cipher suites is
selected.  The selected suite is the first suite in the SUITES_I
CBOR array.  If a single supported cipher suite is conveyed, then
that cipher suite is selected and SUITES_I is encoded as an int
instead of an array.
Paragraph (version A):
The supported cipher suites and the order of preference MUST NOT
be changed based on previous error messages.  However, the list
SUITES_I sent to the Responder MAY be truncated such that cipher
suites which are the least preferred are omitted.  The amount of
truncation MAY be changed between sessions, e.g. based on previous
error messages (see next bullet), but all cipher suites which are
more preferred than the least preferred cipher suite in the list
MUST be included in the list.
Paragraph (version B):
The supported cipher suites and the order of preference MUST NOT
be changed based on previous error messages.  However, the list
SUITES_I sent to the Responder MAY be truncated such that cipher
suites which are the least preferred are omitted.  The amount of
truncation MAY be changed between sessions, e.g., based on
previous error messages (see next bullet), but all cipher suites
which are more preferred than the least preferred cipher suite in
the list MUST be included in the list.
Paragraph (version A):
If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in error, and the session
MUST be discontinued.  Sending error messages is essential for
debugging but MAY e.g. be skipped due to denial of service reasons,
see security.
Paragraph (version B):
If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in error, and the session
MUST be discontinued.  Sending error messages is essential for
debugging but MAY e.g., be skipped due to denial-of-service reasons,
see security.
Paragraph (version A):
MAC_2 is the 'ciphertext' of the inner COSE_Encrypt0.
Paragraph (version B):
Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", ( ID_CRED_R,
CRED_R, ? EAD_2 ), mac_length ).  If the Responder authenticates
with a static Diffie-Hellman key (method equals 1 or 3), then
mac_length is the EDHOC MAC length given by the cipher suite.  If
the Responder authenticates with a signature key (method equals 0
or 2), then mac_length is equal to the output size of the EDHOC
hash algorithm given by the cipher suite.
Paragraph (version A):
If any processing step fails, the Initiator SHOULD send an EDHOC
error message back, formatted as defined in error.  Sending error
messages is essential for debugging but MAY e.g.be skipped if a
session cannot be found or due to denial of service reasons, see
security.  If an error message is sent, the session MUST be
discontinued.
Paragraph (version B):
If any processing step fails, the Initiator SHOULD send an EDHOC
error message back, formatted as defined in error.  Sending error
messages is essential for debugging but MAY e.g., be skipped if a
session cannot be found or due to denial-of-service reasons, see
security.  If an error message is sent, the session MUST be
discontinued.
Paragraph (version A):
CRED_I - bstr containing the credential of the Initiator,
see id_cred.
Paragraph (version A):
MAC_3 is the 'ciphertext' of the inner COSE_Encrypt0.
Paragraph (version B):
Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", ( ID_CRED_I,
CRED_I, ? EAD_3 ), mac_length ).  If the Initiator authenticates
with a static Diffie-Hellman key (method equals 2 or 3), then
mac_length is the EDHOC MAC length given by the cipher suite.  If
the Initiator authenticates with a signature key (method equals 0
or 1), then mac_length is equal to the output size of the EDHOC
hash algorithm given by the cipher suite.
Paragraph (version A):
confirmation is e.g. assured when the Initiator has verified an
OSCORE message or message_4 from the Responder.
Paragraph (version B):
confirmation is e.g., assured when the Initiator has verified an
OSCORE message or message_4 from the Responder.
Paragraph (version A):
If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in error.  Sending error
messages is essential for debugging but MAY e.g.be skipped if a
session cannot be found or due to denial of service reasons, see
security.  If an error message is sent, the session MUST be
discontinued.
Paragraph (version B):
If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in error.  Sending error
messages is essential for debugging but MAY e.g., be skipped if a
session cannot be found or due to denial-of-service reasons, see
security.  If an error message is sent, the session MUST be
discontinued.
Paragraph (version A):
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
item.  Error code 0 MUST NOT be used as part of the EDHOC message
exchange flow.
Paragraph (version B):
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
item.  Error code 0 MUST NOT be used as part of the EDHOC message
exchange flow.
Paragraph (version A):
If the selected cipher suite is not the first cipher suite which the
Responder supports in SUITES_I received in message_1, then Responder
MUST discontinue the protocol, see resp-proc-msg1.  If SUITES_I in
message_1 is manipulated then the integrity verification of message_2
containing the transcript hash TH_2 will fail and the Initiator will
discontinue the protocol.
Paragraph (version B):
If the selected cipher suite is not the first cipher suite which the
Responder supports in SUITES_I received in message_1, then Responder
MUST discontinue the protocol, see resp-proc-msg1.  If SUITES_I in
message_1 is manipulated, then the integrity verification of
message_2 containing the transcript hash TH_2 will fail and the
Initiator will discontinue the protocol.
Paragraph (version A):
EDHOC inherits its security properties from the theoretical SIGMA-I
protocol SIGMA.  Using the terminology from SIGMA, EDHOC provides
perfect forward secrecy, mutual authentication with aliveness,
consistency, and peer awareness.  As described in SIGMA, peer
awareness is provided to the Responder, but not to the Initiator.
Paragraph (version B):
EDHOC inherits its security properties from the theoretical SIGMA-I
protocol SIGMA.  Using the terminology from SIGMA, EDHOC provides
forward secrecy, mutual authentication with aliveness, consistency,
and peer awareness.  As described in SIGMA, peer awareness is
provided to the Responder, but not to the Initiator.
Paragraph (version A):
EDHOC also adds selection of connection identifiers and downgrade
protected negotiation of cryptographic parameters, i.e. an attacker
cannot affect the negotiated parameters.  A single session of EDHOC
does not include negotiation of cipher suites, but it enables the
Responder to verify that the selected cipher suite is the most
preferred cipher suite by the Initiator which is supported by both
the Initiator and the Responder.
Paragraph (version B):
EDHOC also adds selection of connection identifiers and downgrade
protected negotiation of cryptographic parameters, i.e., an attacker
cannot affect the negotiated parameters.  A single session of EDHOC
does not include negotiation of cipher suites, but it enables the
Responder to verify that the selected cipher suite is the most
preferred cipher suite by the Initiator which is supported by both
the Initiator and the Responder.
Paragraph (version A):
As required by RFC7258, IETF protocols need to mitigate pervasive
monitoring when possible.  One way to mitigate pervasive monitoring
is to use a key exchange that provides perfect forward secrecy.
EDHOC therefore only supports methods with perfect forward secrecy.
To limit the effect of breaches, it is important to limit the use of
symmetrical group keys for bootstrapping.  EDHOC therefore strives to
make the additional cost of using raw public keys and self-signed
certificates as small as possible.  Raw public keys and self-signed
certificates are not a replacement for a public key infrastructure,
but SHOULD be used instead of symmetrical group keys for
bootstrapping.
Paragraph (version B):
As required by RFC7258, IETF protocols need to mitigate pervasive
monitoring when possible.  EDHOC therefore only supports methods with
ephemeral Diffie-Hellman and provides a KeyUpdate function for
lightweight application protocol rekeying with forward secrecy.  As
discussed in RFC4949 the term "forward secrecy" is a muddled area.
EDHOC provides forward secrecy in the sense that compromise of the
private authentication keys does not compromise past session keys,
and compromise of a session key does not compromise past session
keys.
Paragraph (version A):
Compromise of the long-term keys (private signature or static DH
keys) does not compromise the security of completed EDHOC exchanges.
Compromising the private authentication keys of one party lets an
active attacker impersonate that compromised party in EDHOC exchanges
with other parties, but does not let the attacker impersonate other
parties in EDHOC exchanges with the compromised party.  Compromise of
the long-term keys does not enable a passive attacker to compromise
future session keys.  Compromise of the HDKF input parameters (ECDH
shared secret) leads to compromise of all session keys derived from
that compromised shared secret.  Compromise of one session key does
not compromise other session keys.  Compromise of PRK_4x3m leads to
compromise of all exported keying material derived after the last
invocation of the EDHOC-KeyUpdate function.
Paragraph (version B):
Compromise of the long-term keys (private signature or static DH
keys) does not compromise the security of completed EDHOC exchanges.
Compromising the private authentication keys of one party lets an
active attacker impersonate that compromised party in EDHOC exchanges
with other parties but does not let the attacker impersonate other
parties in EDHOC exchanges with the compromised party.  Compromise of
the long-term keys does not enable a passive attacker to compromise
future session keys.  Compromise of the HDKF input parameters (ECDH
shared secret) leads to compromise of all session keys derived from
that compromised shared secret.  Compromise of one session key does
not compromise other session keys.  Compromise of PRK_4x3m leads to
compromise of all exported keying material derived after the last
invocation of the EDHOC-KeyUpdate function.
Paragraph (version A):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_4x3m (implicit key
authentication).  The Initiator does however not know that the
Responder has actually computed the key PRK_4x3m.  While the
Initiator can securely send protected application data, the Initiator
SHOULD NOT permanently store the keying material PRK_4x3m and TH_4
until the Initiator is assured that the Responder has actually
computed the key PRK_4x3m (explicit key confirmation).  Explicit key
confirmation is e.g. assured when the Initiator has verified an
OSCORE message or message_4 from the Responder.  After verifying
message_3, the Responder is assured that the Initiator has calculated
the key PRK_4x3m (explicit key confirmation) and that no other party
than the Responder can compute the key.  The Responder can securely
send protected application data and store the keying material
PRK_4x3m and TH_4.
Paragraph (version B):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_4x3m (implicit key
authentication).  The Initiator does however not know that the
Responder has actually computed the key PRK_4x3m.  While the
Initiator can securely send protected application data, the Initiator
SHOULD NOT permanently store the keying material PRK_4x3m and TH_4
until the Initiator is assured that the Responder has actually
computed the key PRK_4x3m (explicit key confirmation).  Explicit key
confirmation is e.g., assured when the Initiator has verified an
OSCORE message or message_4 from the Responder.  After verifying
message_3, the Responder is assured that the Initiator has calculated
the key PRK_4x3m (explicit key confirmation) and that no other party
than the Responder can compute the key.  The Responder can securely
send protected application data and store the keying material
PRK_4x3m and TH_4.
Paragraph (version A):
Key compromise impersonation (KCI): In EDHOC authenticated with
signature keys, EDHOC provides KCI protection against an attacker
having access to the long term key or the ephemeral secret key.  With
static Diffie-Hellman key authentication, KCI protection would be
provided against an attacker having access to the long-term Diffie-
Hellman key, but not to an attacker having access to the ephemeral
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
ephemeral secret key can only attack that specific protocol run.
Paragraph (version B):
Key compromise impersonation (KCI): In EDHOC authenticated with
signature keys, EDHOC provides KCI protection against an attacker
having access to the long-term key or the ephemeral secret key.  With
static Diffie-Hellman key authentication, KCI protection would be
provided against an attacker having access to the long-term Diffie-
Hellman key, but not to an attacker having access to the ephemeral
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
ephemeral secret key can only attack that specific protocol run.
Paragraph (version A):
The security of the SIGMA protocol requires the MAC to be bound to
the identity of the signer.  Hence the message authenticating
functionality of the authenticated encryption in EDHOC is critical:
authenticated encryption MUST NOT be replaced by plain encryption
only, even if authentication is provided at another level or through
a different mechanism.  EDHOC implements SIGMA-I using a MAC-then-
Sign approach.
Paragraph (version B):
The SIGMA protocol requires that the encryption of message_3 provides
confidentiality against active attackers and EDHOC message_4 relies
on the use of authenticated encryption.  Hence the message
authenticating functionality of the authenticated encryption in EDHOC
is critical: authenticated encryption MUST NOT be replaced by plain
encryption only, even if authentication is provided at another level
or through a different mechanism.
Paragraph (version A):
As discussed the SIGMA, the encryption of message_2 does only need to
protect against passive attacker as active attackers can always get
the Responders identity by sending their own message_1.  EDHOC uses
the Expand function (typically HKDF-Expand) as a binary additive
stream cipher.  HKDF-Expand provides better confidentiality than AES-
CTR but is not often used as it is slow on long messages, and most
applications require both IND-CCA confidentiality as well as
integrity protection.  For the encryption of message_2, any speed
difference is negligible, IND-CCA does not increase security, and
integrity is provided by the inner MAC (and signature depending on
method).
Paragraph (version B):
As discussed, the SIGMA, the encryption of message_2 does only need
to protect against passive attacker as active attackers can always
get the Responders identity by sending their own message_1.  EDHOC
uses the Expand function (typically HKDF-Expand) as a binary additive
stream cipher.  HKDF-Expand provides better confidentiality than AES-
CTR but is not often used as it is slow on long messages, and most
applications require both IND-CCA confidentiality as well as
integrity protection.  For the encryption of message_2, any speed
difference is negligible, IND-CCA does not increase security, and
integrity is provided by the inner MAC (and signature depending on
method).
Paragraph (version A):
The data rates in many IoT deployments are very limited.  Given that
the application keys are protected as well as the long-term
authentication keys they can often be used for years or even decades
before the cryptographic limits are reached.  If the application keys
established through EDHOC need to be renewed, the communicating
parties can derive application keys with other labels or run EDHOC
again.
Paragraph (version A):
Requirement for how to securely generate, validate, and process the
ephermeral public keys depend on the elliptic curve.  For X25519 and
X448, the requirements are defined in RFC7748.  For secp256r1,
secp384r1, and secp521r1, the requirements are defined in Section 5
of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least
partial public-key validation MUST be done.
Paragraph (version B):
Requirement for how to securely generate, validate, and process the
ephemeral public keys depend on the elliptic curve.  For X25519 and
X448, the requirements are defined in RFC7748.  For secp256r1,
secp384r1, and secp521r1, the requirements are defined in Section 5
of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least
partial public-key validation MUST be done.
Paragraph (version A):
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 be forged by and
attacker and ignore it without sending an error message or
discontinuing the session.
Paragraph (version B):
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 and
attacker and ignore it without sending an error message or
discontinuing the session.
Paragraph (version A):
The availability of a secure random number generator is essential for
the security of EDHOC.  If no true random number generator is
available, a truly random seed MUST be provided from an external
source and used with a cryptographically secure pseudorandom number
generator.  As each pseudorandom number must only be used once, an
implementation need to get a new truly random seed after reboot, or
continuously store state in nonvolatile memory, see (RFC8613,
Appendix B.1.1) for issues and solution approaches for writing to
nonvolatile memory.  Intentionally or unintentionally weak or
predictable pseudorandom number generators can be abused or exploited
for malicious purposes.  RFC8937 describes a way for security
protocol implementations to augment their (pseudo)random number
generators using a long-term private keys and a deterministic
signature function.  This improves randomness from broken or
otherwise subverted random number generators.  The same idea can be
used with other secrets and functions such as a Diffie-Hellman
function or a symmetric secret and a PRF like HMAC or KMAC.  It is
RECOMMENDED to not trust a single source of randomness and to not put
unaugmented random numbers on the wire.
Paragraph (version B):
The availability of a secure random number generator is essential for
the security of EDHOC.  If no true random number generator is
available, a truly random seed MUST be provided from an external
source and used with a cryptographically secure pseudorandom number
generator.  As each pseudorandom number must only be used once, an
implementation needs to get a new truly random seed after reboot, or
continuously store state in nonvolatile memory, see (RFC8613,
Appendix B.1.1) for issues and solution approaches for writing to
nonvolatile memory.  Intentionally or unintentionally weak or
predictable pseudorandom number generators can be abused or exploited
for malicious purposes.  RFC8937 describes a way for security
protocol implementations to augment their (pseudo)random number
generators using a long-term private key and a deterministic
signature function.  This improves randomness from broken or
otherwise subverted random number generators.  The same idea can be
used with other secrets and functions such as a Diffie-Hellman
function or a symmetric secret and a PRF like HMAC or KMAC.  It is
RECOMMENDED to not trust a single source of randomness and to not put
unaugmented random numbers on the wire.
Paragraph (version A):
If ECDSA is supported, "deterministic ECDSA" as specified in RFC6979
MAY be used.  Pure deterministic elliptic-curve signatures such as
deterministic ECDSA and EdDSA have gained popularity over randomized
ECDSA as their security do not depend on a source of high-quality
randomness.  Recent research has however found that implementations
of these signature algorithms may be vulnerable to certain side-
channel and fault injection attacks due to their determinism.  See
e.g.  Section 1 of I-D.mattsson-cfrg-det-sigs-with-noise for a list
of attack papers.  As suggested in Section 6.1.2 of I-D.ietf-cose-
rfc8152bis-algs this can be addressed by combining randomness and
determinism.
Paragraph (version A):
The Initiator and the Responder are allowed to select the connection
identifiers C_I and C_R, respectively, for the other party to use in
the ongoing EDHOC protocol as well as in a subsequent application
protocol (e.g.  OSCORE RFC8613).  The choice of connection identifier
is not security critical in EDHOC but intended to simplify the
retrieval of the right security context in combination with using
short identifiers.  If the wrong connection identifier of the other
party is used in a protocol message it will result in the receiving
party not being able to retrieve a security context (which will
terminate the protocol) or retrieve the wrong security context (which
also terminates the protocol as the message cannot be verified).
Paragraph (version B):
The Initiator and the Responder are allowed to select the connection
identifiers C_I and C_R, respectively, for the other party to use in
the ongoing EDHOC protocol as well as in a subsequent application
protocol (e.g., OSCORE RFC8613).  The choice of connection identifier
is not security critical in EDHOC but intended to simplify the
retrieval of the right security context in combination with using
short identifiers.  If the wrong connection identifier of the other
party is used in a protocol message it will result in the receiving
party not being able to retrieve a security context (which will
terminate the protocol) or retrieve the wrong security context (which
also terminates the protocol as the message cannot be verified).
Paragraph (version A):
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 of
code and data in the Rich Execution Environment (REE) by validating
the REE image.
Paragraph (version B):
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
of code and data in the Rich Execution Environment (REE) by
validating the REE image.
Paragraph (version A):
IANA has created a new registry entitled "EDHOC Method Type" 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.  The initial contents of the registry is shown in fig-
method-types.
Paragraph (version B):
IANA has created a new registry entitled "EDHOC Method Type" 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.  The initial contents of the registry are shown in fig-
method-types.
Paragraph (version A):
IANA has created a new registry entitled "EDHOC Error Codes" under
the new heading "EDHOC".  The registration procedure is
"Specification Required".  The columns of the registry are ERR_CODE,
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
initial contents of the registry is shown in fig-error-codes.
Paragraph (version B):
IANA has created a new registry entitled "EDHOC Error Codes" under
the new heading "EDHOC".  The registration procedure is
"Specification Required".  The columns of the registry are ERR_CODE,
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
initial contents of the registry are shown in fig-error-codes.