Draft: draft-ietf-lake-edhoc

Commentary: Just first commit , more to come . . . 
 Merging this now to avoid conflicts when rewriting 3.5 . Further comments are still welcome . 
 Oxford comma OLD " X.509 and " NEW " X.509 , and " I do n't think this figure text is appropriate here . It mixes EDHOC and SIGMA , claim wrong things about SIGMA , and includes normative text in the caption . AEAD is defined earlier . OLD The SIGMA construction allows message2 to include a plain encryption Enc ( ) , whereas message3 includes an authenticated encryption with additional data AEAD ( ) that MUST NOT be replaced by a plain encryption . More details in Section 8.2 . " } { : artwork - align="center " } NEW The SIGMA construction allows message2 to include a plain encryption Enc ( ) , whereas message3 is required to be authenticated encryption . I am not a big fan of the long caption in fig - error1 and fig - error2 . For fig - error2 there is similar text " above " the figure " In the second example (      } } ) , " ans in the caption ....
Paragraph (version A):
EDHOC makes use of known protocol constructions, such as SIGMA SIGMA
and Extract-and-Expand RFC5869.  EDHOC uses COSE for cryptography and
identification of credentials (including COSE_Key, CWT, CCS, X.509,
C509, see auth-cred).  COSE provides crypto agility and enables the
use of future algorithms and credential types targeting IoT.
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 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.  In
using libraries already in the code base, 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):
Compared to the DTLS 1.3 handshake I-D.ietf-tls-dtls13 with ECDHE and
connection ID, the EDHOC message size when transferred in CoAP can be
less than 1/6 when RPK authentication is used, see I-D.ietf-lwig-
security-protocol-comparison. fig-sizes shows examples of message
sizes for EDHOC with different kinds of authentication keys and
different COSE header parameters for identification: static Diffie-
Hellman keys or signature keys, either in CBOR Web Token (CWT) / CWT
Claims Set (CCS) RFC8392 identified by a key identifier using 'kid'
I-D.ietf-cose-rfc8152bis-struct, or in X.509 certificates identified
by a hash value using 'x5t' I-D.ietf-cose-x509.
Paragraph (version A):
The remainder of the document is organized as follows: background
outlines EDHOC authenticated with digital signatures, overview
describes the protocol elements of EDHOC, including formatting of the
ephemeral public keys, key-der specifies the key derivation, asym
specifies message processing for EDHOC authenticated with signature
keys or static Diffie-Hellman keys, error describes the error
messages, and transfer shows how to transfer EDHOC with CoAP and
establish an OSCORE security context.
Paragraph (version B):
EDHOC makes use of known protocol constructions, such as SIGMA SIGMA
and Extract-and-Expand RFC5869.  EDHOC uses COSE for cryptography and
identification of credentials (including COSE_Key, CBOR Web Token
(CWT), CWT Claims Set (CCS), X.509 and CBOR encoded X.509 (C509)
certificates, see auth-cred).  COSE provides crypto agility and
enables the use of future algorithms and credential types targeting
IoT.
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 involving 'things' with
embedded microcontrollers, sensors, and actuators.  By reusing the
same lightweight primitives as OSCORE (CBOR, COSE, CoAP) 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.
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).  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.
Paragraph (version B):
Compared to the DTLS 1.3 handshake I-D.ietf-tls-dtls13 with ECDHE and
connection ID, the EDHOC message size when transferred in CoAP can be
less than 1/6 when RPK authentication is used, see I-D.ietf-lwig-
security-protocol-comparison. fig-sizes shows examples of EDHOC
message sizes based on the assumptions in Section 2 of I-D.ietf-lwig-
security-protocol-comparison, comparing different kinds of
authentication keys and COSE header parameters for identification:
static Diffie-Hellman keys or signature keys, either in CBOR Web
Token (CWT) / CWT Claims Set (CCS) RFC8392 identified by a key
identifier using 'kid' I-D.ietf-cose-rfc8152bis-struct, or in X.509
certificates identified by a hash value using 'x5t' I-D.ietf-cose-
x509.
Paragraph (version B):
The remainder of the document is organized as follows: background
outlines EDHOC authenticated with signature keys, overview describes
the protocol elements of EDHOC, including formatting of the ephemeral
public keys, key-der specifies the key derivation, asym specifies
message processing for EDHOC authenticated with signature keys or
static Diffie-Hellman keys, error describes the error messages, and
transfer shows how to transfer EDHOC with CoAP and establish an
OSCORE security context.
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 A):
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants SIGMA.  Like IKEv2 RFC7296 and (D)TLS 1.3
RFC8446, EDHOC authenticated with digital signatures is built on a
variant of the SIGMA protocol which provides identity protection of
the initiator (SIGMA-I) against active attackers, and like IKEv2
RFC7296, EDHOC implements the MAC-then-Sign variant of the SIGMA-I
protocol shown in fig-sigma.
Paragraph (version B):
EDHOC specifies different authentication methods of the ephemeral
Diffie-Hellman key exchange: signature keys and static Diffie-Hellman
keys.  This section outlines the signature key based method.  Further
details of protocol elements and other authentication methods are
provided in the remainder of this document.
Paragraph (version B):
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants SIGMA.  Like IKEv2 RFC7296 and (D)TLS 1.3
RFC8446, EDHOC authenticated with signature keys is built on a
variant of the SIGMA protocol which provides identity protection of
the initiator (SIGMA-I) against active attackers, and like IKEv2
RFC7296, EDHOC implements the MAC-then-Sign variant of the SIGMA-I
protocol shown in fig-sigma.
Paragraph (version A):
The EDHOC protocol consists of three mandatory messages (message_1,
message_2, message_3) between Initiator and Responder, an optional
fourth message (message_4), and an error message.  All EDHOC messages
are CBOR Sequences RFC8742. fig-flow illustrates an EDHOC message
flow with the optional fourth message as well as the content of each
message.  The protocol elements in the figure are introduced in
overview and asym.  Message formatting and processing is specified in
asym and error.
Paragraph (version A):
Application data may be protected using the agreed application
algorithms (AEAD, hash) in the selected cipher suite (see cs) and the
application can make use of the established connection identifiers
C_I and C_R (see ci).  EDHOC may be used with the media type
application/edhoc defined in iana.
Paragraph (version B):
The EDHOC protocol consists of three mandatory messages (message_1,
message_2, message_3) between Initiator and Responder, an optional
fourth message (message_4), and an error message.  All EDHOC messages
are CBOR Sequences RFC8742. fig-flow illustrates an EDHOC message
flow with the optional fourth message as well as the content of each
message.  The protocol elements in the figure are introduced in
overview and asym.  Message formatting and processing are specified
in asym and error.
Paragraph (version B):
Application data may be protected using the agreed application
algorithms (AEAD, hash) in the selected cipher suite (see cs) and the
application can make use of the established connection identifiers
C_I and C_R (see ci).  EDHOC may be used with the media type
application/edhoc defined in media-type.
Paragraph (version A):
EDHOC supports all signature algorithms defined by COSE, including
PQC signature algorithms such as HSS-LMS.  Just like in TLS 1.3
RFC8446 and IKEv2 RFC7296, a signature in COSE is determined by the
signature algorithm and the authentication key algorithm together,
see auth-keys.  The exact details of the authentication key algorithm
depend on the type of authentication credential.  COSE supports
different formats for storing the public authentication keys
including COSE_Key and X.509, which have different names and ways to
represent the authentication key and the authentication key
algorithm.
Paragraph (version B):
EDHOC supports all signature algorithms defined by COSE.  Just like
in TLS 1.3 RFC8446 and IKEv2 RFC7296, a signature in COSE is
determined by the signature algorithm and the authentication key
algorithm together, see auth-keys.  The exact details of the
authentication key algorithm depend on the type of authentication
credential.  COSE supports different formats for storing the public
authentication keys including COSE_Key and X.509, which have
different names and ways to represent the authentication key and the
authentication key algorithm.
Paragraph (version A):
If the Responder authenticates with a static Diffie-Hellman key, then
PRK_3e2m = Extract( PRK_2e, G_RX ), where G_RX is the ECDH shared
secret calculated from G_R and X, or G_X and R, else PRK_3e2m =
PRK_2e.
Paragraph (version A):
If the Initiator authenticates with a static Diffie-Hellman key, then
PRK_4x3m = Extract( PRK_3e2m, G_IY ), where G_IY is the ECDH shared
secret calculated from G_I and Y, or G_Y and I, else PRK_4x3m =
PRK_3e2m.
Paragraph (version B):
If the Responder authenticates with a static Diffie-Hellman key, then
PRK_3e2m = Extract( PRK_2e, G_RX ), where G_RX is the ECDH shared
secret calculated from G_R and X, or G_X and R (the Responder's
private authentication key, see auth-keys), else PRK_3e2m = PRK_2e.
Paragraph (version B):
If the Initiator authenticates with a static Diffie-Hellman key, then
PRK_4x3m = Extract( PRK_3e2m, G_IY ), where G_IY is the ECDH shared
secret calculated from G_I and Y, or G_Y and I (the Initiator's
private authentication key, see auth-keys), else PRK_4x3m = PRK_3e2m.
Paragraph (version A):
SUITES_I - array of cipher suites which the Initiator supports in
order of preference, starting with the most preferred and ending
with the cipher suite selected for this session.  If the most
preferred cipher suite is selected then SUITES_I contains only
that cipher suite and is encoded as an int.  The processing steps
are detailed below and in wrong-selected.
Paragraph (version B):
SUITES_I - array of cipher suites which the Initiator supports in
order of preference, the first cipher suite in network byte order
is the most preferred by I, the last is the one selected by I for
this session.  If the most preferred cipher suite is selected then
SUITES_I contains only that cipher suite and is encoded as an int.
The processing steps are detailed below and in wrong-selected.
Paragraph (version A):
SUITES_I contains a list of supported cipher suites, in order of
preference, truncated after the cipher suite selected for this
session.
Paragraph (version A):
The selected cipher suite 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 selected
cipher suite in the list MUST be included in SUITES_I.
Paragraph (version A):
If the Initiator previously received from the Responder an
error message with error code 2 (see wrong-selected) indicating
cipher suites supported by the Responder, then the Initiator
SHOULD select the most preferred supported cipher suite among
those (note that error messages are not authenticated and may
be forged).
Paragraph (version A):
The supported cipher suites and the order of preference MUST
NOT be changed based on previous error messages.
Paragraph (version B):
The selected cipher suite (i.e. the last cipher suite in
SUITES_I) MAY be different between sessions, e.g., based on
previous error messages (see next bullet), but all cipher
suites which are more preferred by I than the selected cipher
suite MUST be included in SUITES_I.
Paragraph (version B):
If the Initiator previously received from the Responder an
error message with error code 2 (see wrong-selected) which
indicate cipher suites supported by the Responder, then the
Initiator SHOULD select its most preferred supported cipher
suite among those (bearing in mind that error messages are not
authenticated and may be forged).
Paragraph (version B):
The supported cipher suites and the order of preference in
SUITES_I MUST NOT be changed based on previous error messages.
Paragraph (version A):
This section defines the format for error messages.
Paragraph (version B):
This section defines the format for error messages, and the
processing associated to the currently defined error codes.
Additional error codes may be registered, see error-code-reg.
Paragraph (version A):
EDHOC provides a minimum of 64-bit security against online brute
force attacks and a minimum of 128-bit security against offline brute
force attacks.  This is in line with IPsec, TLS, and COSE.  To break
64-bit security against online brute force an attacker would on
average have to send 4.3 billion messages per second for 68 years,
which is infeasible in constrained IoT radio technologies.
Paragraph (version B):
EDHOC provides a minimum of 64-bit security against online brute
force attacks and a minimum of 128-bit security against offline brute
force attacks.  To break 64-bit security against online brute force
an attacker would on average have to send 4.3 billion messages per
second for 68 years, which is infeasible in constrained IoT radio
technologies.
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 needs to generate unique input to the pseudorandom
number generator after reboot, by using a new truly random seed, or
by continuously storing unique state in nonvolatile memory, such as
strictly increasing sequence numbers.  Appendix B.1.1 in RFC8613
describes issues and solution approaches for writing sequence numbers
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 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 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 unique input to the pseudorandom number generator
after reboot, or continuously store state in nonvolatile memory.
Appendix B.1.1 in RFC8613 describes 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 supported by the device, it is RECOMMENDED that at least the long-
term private keys are stored in a Trusted Execution Environment (TEE)
and that sensitive operations using these keys are performed inside
the TEE.  To achieve even higher security it is RECOMMENDED that
additional operations such as ephemeral key generation, all
computations of shared secrets, and storage of the PRK keys can be
done inside the TEE.  The use of a TEE enforces that code within that
environment cannot be tampered with, and that any data used by such
code cannot be read or tampered with by code outside that
environment.
Paragraph (version B):
If supported by the device, it is RECOMMENDED that at least the long-
term private keys are stored in a Trusted Execution Environment (TEE)
and that sensitive operations using these keys are performed inside
the TEE.  To achieve even higher security it is RECOMMENDED that
additional operations such as ephemeral key generation, all
computations of shared secrets, and storage of the PRK keys can be
done inside the TEE.  The use of a TEE aims at preventing code within
that environment to be tampered with, and preventing data used by
such code to be read or tampered with by code outside that
environment.
Paragraph (version A):
Client applications can use this resource type to discover a server's
resource for EDHOC, where to send a request for executing the EDHOC
protocol.