Draft: draft-ietf-lake-edhoc

Commentary: Merging this now to avoid conflicts when rewriting 3.5 . Further comments are still welcome . 
 The algorithms of cipher suite 24 are included in the CNSA suite { { CNSA } } . Sounds backwards . Maybe "  suite 24 includes algorithms from the CNSA suite { { CNSA } } . " transport of error messages , Seems strange to single out error messages . The transport is responsible for transport of all types of EDHOC messages including error .....
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 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 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 I-
D.ietf-tls-dtls13, 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,
EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol
shown in fig-sigma.
Paragraph (version A):
The authentication credential (CRED_x) contains, in addition to the
authentication key, also the authentication key algorithm and
optionally other parameters such as identity, key usage, expiry,
issuer, etc. (see auth-cred).  Identical authentication credentials
need to be established in both endpoints to be able to verify
integrity.  For many settings it is not necessary to transport the
authentication credential within EDHOC over constrained links, for
example, it may be pre-provisioned or acquired out-of-band over less
constrained links.
Paragraph (version B):
The authentication credential (CRED_x) contains, in addition to the
authentication key, also the authentication key algorithm and
optionally other parameters such as identity, key usage, expiry,
issuer, etc. (see auth-cred).  Identical authentication credentials
need to be established in both endpoints to be able to verify
integrity, see fig-sigma.  For many settings it is not necessary to
transport the authentication credential within EDHOC over constrained
links, for example, it may be pre-provisioned or acquired out-of-band
over less constrained links.
Paragraph (version A):
When a Public Key Infrastructure (PKI) is used with certificates,
the trust anchor is a Certification Authority (CA) certificate,
and the identity is the subject whose unique name (e.g., a domain
name, NAI, or EUI) is included in the endpoint's certificate.  In
order to run EDHOC each party needs at least one CA public key
certificate, or just the public key, and a specific identity or
set of identities it is allowed to communicate with.  Only
validated public-key certificates with an allowed subject name, as
specified by the application, are to be accepted.  EDHOC provides
proof that the other party possesses the private authentication
key corresponding to the public authentication key in its
certificate.  The certification path provides proof that the
subject of the certificate owns the public key in the certificate.
Paragraph (version A):
certificate.  The certification path provides proof that the
subject of the certificate owns the public key in the certificate.
Paragraph (version B):
certificate, also known as proof-of-possession.  The certification
path contains proof that the subject of the certificate owns the
public key in the certificate.
Paragraph (version A):
EDHOC relies on COSE for identification of authentication credentials
(see id_cred) and supports all credential types for which COSE header
parameters are defined including X.509 RFC5280, C509 I-D.ietf-cose-
cbor-encoded-cert, CWT RFC8392 and CWT Claims Set (CCS) RFC8392.
When the identified credential is a chain or bag, CRED_x is just the
end-entity X.509 or C509 certificate / CWT.  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):
EDHOC relies on COSE for identification of authentication credentials
(see id_cred) and supports all credential types for which COSE header
parameters are defined including X.509 RFC5280, C509 I-D.ietf-cose-
cbor-encoded-cert, CWT RFC8392 and CWT Claims Set (CCS) RFC8392.
When the identified credential is a chain or bag, CRED_x is just the
end-entity X.509 or C509 certificate / CWT.  In X.509 and C509
certificates, signature keys typically have key usage
"digitalSignature" and Diffie-Hellman public keys typically have key
usage "keyAgreement" RFC8410.
Paragraph (version A):
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 B):
EDHOC supports all signature algorithms defined by COSE.  Just like
in (D)TLS 1.3 I-D.ietf-tls-dtls13 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 use different
names and ways to represent the authentication key and the
authentication key algorithm.
Paragraph (version A):
Cipher suites 24 and 25 are intended for high security
applications such as government use and financial applications.
These cipher suites do not share any algorithms.  Cipher suite 24
is compatible with the CNSA suite CNSA.
Paragraph (version B):
Cipher suites 24 and 25 are intended for high security
applications such as government use and financial applications.
These cipher suites do not share any algorithms.  Cipher suite 24
consists of algorithms from the CNSA suite CNSA.
Paragraph (version A):
The applicability statement may also contain information about
supported cipher suites.  The procedure for selecting and verifying a
cipher suite is still performed as described in asym-msg1-form and
wrong-selected, but it may become simplified by this knowledge.
Paragraph (version A):
An example of an applicability statement is shown in appl-temp.
Paragraph (version A):
For some parameters, like METHOD, ID_CRED_x, type of EAD, the
receiver is able to verify compliance with applicability statement,
and if it needs to fail because of incompliance, to infer the reason
why the protocol failed.
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):
The applicability template may also contain information about
supported cipher suites.  The procedure for selecting and verifying a
cipher suite is still performed as described in asym-msg1-form and
wrong-selected, but it may become simplified by this knowledge.
Paragraph (version B):
An example of an applicability template is shown in appl-temp.
Paragraph (version B):
For some parameters, like METHOD, ID_CRED_x, type of EAD, the
receiver is able to verify compliance with applicability template,
and if it needs to fail because of incompliance, to infer the reason
why the protocol failed.
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 template 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):
Other conditions may be part of the applicability statement, such as
target application or use (if there is more than one application/use)
to the extent that EDHOC can distinguish between them.  In case
multiple applicability statements are used, the receiver needs to be
able to determine which is applicable for a given session, for
example based on URI or external authorization data type.
Paragraph (version B):
Other conditions may be part of the applicability template, such as
target application or use (if there is more than one application/use)
to the extent that EDHOC can distinguish between them.  In case
multiple applicability templates are used, the receiver needs to be
able to determine which is applicable for a given session, for
example based on URI or external authorization data type.
Paragraph (version A):
The EDHOC-KeyUpdate takes a nonce as input to guarantee that there
are no short cycles and to enable binding of the updated PRK_4x3m to
some event that triggered the keyUpdate.  The Initiator and the
Responder need to agree on the nonce, which can e.g., be a counter or
a random number such as a hash.  While the KeyUpdate method provides
forward secrecy it does not give as strong security properties as re-
running EDHOC, see security.
Paragraph (version B):
The EDHOC-KeyUpdate takes a nonce as input to guarantee that there
are no short cycles and to enable binding of the updated PRK_4x3m to
some event that triggered the keyUpdate.  The Initiator and the
Responder need to agree on the nonce, which can, e.g., be a counter
or a pseudo-random number such as a hash.  The Initiator and the
Responder also need to cache the old PRK_4x3m until it has verfied
that other endpoint has the correct new PRK_4x3m.  I-D.ietf-core-
oscore-key-update describes key update for OSCORE using EDHOC-
KeyUpdate.
Paragraph (version B):
While the KeyUpdate method provides forward secrecy it does not give
as strong security properties as re-running EDHOC, see security.
Paragraph (version A):
For each new/ongoing session, the endpoints are assumed to keep an
associated protocol state containing identifiers, keying material,
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 new/ongoing session, the endpoints are assumed to keep an
associated protocol state containing identifiers, keying material,
etc. used for subsequent processing of protocol related data.  The
protocol state is assumed to be associated to an applicability
template (applicability) which provides the context for how messages
are transported, identified, and processed.
Paragraph (version A):
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 A):
The supported cipher suites and the order of preference in
SUITES_I MUST NOT be changed based on previous error messages.
Paragraph (version B):
If the Initiator previously received from the Responder an
error message with error code 2 containing SUITES_R (see wrong-
selected) which indicates 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 Initiator MUST NOT change the supported cipher suites and
the order of preference in SUITES_I based on previous error
messages.
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 dos.  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, and the session
MUST be discontinued.  Sending error messages is essential for
debugging but MAY be skipped due to, for example, denial-of-service
reasons, see dos.  If an error message is sent, the session MUST be
discontinued.
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 dos.
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 be skipped if, for
example, a session cannot be found or due to denial-of-service
reasons, see dos.  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, i.e., as a standard value in case of no error, e.g., in
status reporting or log files.  ERR_INFO can contain any type of CBOR
item, the content is out of scope for this specification.  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, i.e., as a standard value in case of no error, e.g., in
status reporting or log files.  ERR_INFO can contain any type of CBOR
item, the content is out of scope for this specification.  Error code
0 MUST NOT be used as part of the EDHOC message exchange flow.  If an
endpoint receives an error message with error code 0, then it MUST
discontinue the protocol and MUST NOT send an error message.
Paragraph (version A):
suites in SUITES_R in any order.
Paragraph (version B):
suites in SUITES_R.
Paragraph (version B):
In contrast to SUITES_I, the order of the cipher suites in SUITES_R
has no significance.
Paragraph (version A):
For many constrained IoT devices it is problematic to support several
crypto primitives.  Existing devices can be expected to support
either ECDSA or EdDSA.  Cipher suites 0 (AES-CCM-16-64-128, SHA-256,
8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) and 1 (AES-CCM-
16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256)
only differ in size of the MAC length, so supporting one or both of
these is no essential difference.  Similarly for cipher suites 2
(AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-
256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-
16-64-128, SHA-256).  To enable as much interoperability as we can
reasonably achieve, less constrained devices SHOULD implement all
four cipher suites 0-3.  Constrained endpoints SHOULD implement
cipher suites 0 and 1, or cipher suites 2 and 3.  Implementations
only need to implement the algorithms needed for their supported
methods.
Paragraph (version B):
For many constrained IoT devices it is problematic to support several
crypto primitives.  Existing devices can be expected to support
either ECDSA or EdDSA.  Cipher suites 0 (AES-CCM-16-64-128, SHA-256,
8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) and 1 (AES-CCM-
16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256)
only differ in size of the MAC length, so supporting one or both of
these is no essential difference.  Similarly for cipher suites 2
(AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-
256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-
16-64-128, SHA-256).  To enable as much interoperability as possible,
less constrained devices SHOULD implement all four cipher suites 0-3.
Constrained endpoints SHOULD implement cipher suites 0 and 1, or
cipher suites 2 and 3.  Implementations only need to implement the
algorithms needed for their supported methods.
Paragraph (version A):
The hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to
64-bits) SHALL NOT be supported for use in EDHOC except for
certificate identification with x5t and c5t.  Note that secp256k1 is
only defined for use with ECDSA and not for ECDH.  Note that some
COSE algorithms are marked as not recommended in the COSE IANA
registry.
Paragraph (version B):
The hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to
64-bits) SHALL NOT be supported for use in EDHOC except for
certificate identification with x5t and c5t.  For security
considerations of SHA-1, see RFC6194.  Note that secp256k1 is only
defined for use with ECDSA and not for ECDH.  Note that some COSE
algorithms are marked as not recommended in the COSE IANA registry.