Draft: draft-ietf-lake-edhoc

Commentary: Here is a rough first suggestion for changes . 
 In you " Explanation : " to COSE processing description of Section 5 . I removed that as out context for that PR and instead opened this issue as placeholder . 
 Essential that something like that need to be to -11 . It is very important to point out that this is not specification at all . The COSE RFC specifies these things . If the EDHOC spec makes anything incorrect or COSE makes updates in the future , that apply and NOT the EHDOC spec . 
 Unless you have a better suggestion than " Explanation : " I think " Explanation : " should stay , but I can live with basically any formulation here . Whether it is out of the context of the PR is not very important . The important thing is that it is merged to master . The important thing is to make it very clear that these parts is not normative specification . 
 There was already an issue regarding this 
 OK . Just adding " Explanation : " was not sufficient explanation , at least not for me . So now we have two issues and surely wo n't forget adding it to the master . 
 I see now that you already submitted -11 . " Essential " was maybe a bit strong , but I it would have been good to clearly distinguish between COSE and EDHOC before more formal verfication . Let 's try to do that for -12 . Might be good to add that the separaration between signature algorithm and key authentication algorithm ( where the key authentication algorithm might not be a COSE algorithm ) comes from COSE . TLS chose a different approach than COSE where the curve ( but not RSA key lenght ) is integrated into the " signature algorithm " . So also in TLS the security level and exact parameters are determined by the signature algorithm and the key algorithm together . COSE is flexible and allows ECDSA with Brainpool as long as Brainpool is stored in a X509 even if Brainpool is not registered in the COSE IANA registry . The security consideration section in EDHOC should maybe consider refering to the section in COSE section discussion  . 
 Maybe something like COSE recap : COSE summary : COSE explanation : Informal COSE recap : Informal COSE summary : Informal COSE explanation : 
 Current text says : " COSE constructs the input to the Signature Algorithm as : The key is the private authentication key of the Responder . The message M to be signed = [ " Signature1 " , < < IDCREDR , < < TH2 , CREDR , ? EAD2 , MAC2 ] " If this is not clear , then I think a prefix is not enough . A potential confusion is where the COSE processing stops and EDHOC processing restarts . More clear is to separate the explanation from the processing and put this text in some other section . The purpose of appendix C.3 is to explain COSE , so that section could be used . At least a reference to the explanation should be put in that section . 
 Let 's make subsections for the " COSE constructs " . Lets discuss how COSE works with signature algorithms and public keys . 
 I went through the processing steps and removed the COSE constructs part , see . We may want to add to C.3 if something was lost in the process . 
 In C.3 . we may e.g. describe how Sigstructure and Encstructure are used 
 C.3 used to contain the " COSE constructs " parts . I.e. explanation of how COSE takes the input to its API and transform them to input to the AEAD / Signature interfaces . Some implementor a long time ago suggested to integrate this into the body , but maybe it is better to have it in the appendix to make it clearer what is EDHOC and what is COSE 
 in PR the " COSE constructs " explanations for COSESign1 and COSEEncrypt0 are now back in C.3 , with reference to it from the message processing sections 5.3 - 5.5 . 
 Fixed in 
 Looks good . Two other things we discussed : 1 . using credential " as received " instead of canonicalization . 2 . Examples of multiple CBOR header maps .
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-key-id).  COSE provides crypto agility and enables the
use of future algorithms and credentials targeting IoT.
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, CWT, CCS, X.509,
C509, see auth-cred).  COSE provides crypto agility and enables the
use of future algorithms and credentials targeting IoT.
Paragraph (version A):
The single output from authenticated encryption (including the
authentication tag) is called "ciphertext", following RFC5116.
Paragraph (version A):
We use the term CWT Claims Set (CCS) as in RFC8392 to denote a CBOR
Web Token (CWT) without wrapping it into a COSE object, i.e., a CBOR
map that contains the claims conveyed by a CWT.
Paragraph (version B):
Readers are expected to be familiar with the terms and concepts
described in CBOR RFC8949, CBOR Sequences RFC8742, COSE structures
and processing I-D.ietf-cose-rfc8152bis-struct, COSE algorithms I-
D.ietf-cose-rfc8152bis-algs, CWT and CWT Claims Set RFC8392, and CDDL
RFC8610.  The Concise Data Definition Language (CDDL) is used to
express CBOR data structures RFC8949.  Examples of CBOR and CDDL are
provided in CBOR.  When referring to CBOR, this specification always
refers to Deterministically Encoded CBOR as specified in Sections
encryption (including the authentication tag) is called "ciphertext",
following RFC5116.
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), and like IKEv2 RFC7296, EDHOC implements the
SIGMA-I variant as MAC-then-Sign.  The MAC-then-Sign variant of the
SIGMA-I protocol is 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
RFC8446, EDHOC authenticated with digital signatures is built on a
variant of the SIGMA protocol which provides identity protection of
the initiator (SIGMA-I), and like IKEv2 RFC7296, EDHOC implements the
MAC-then-Sign variant of the SIGMA-I protocol shown in fig-sigma.
Paragraph (version B):
The data item METHOD in message_1 (see asym-msg1-form), is an integer
specifying the authentication method.  EDHOC supports authentication
with signature or static Diffie-Hellman keys, as defined in the four
authentication methods: 0, 1, 2, and 3, see fig-method-types.  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.
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 supports various settings for how the other endpoint's
authentication (public) key is transported, identified, and trusted
as described in this section.
Paragraph (version A):
For CWT and CCS, the authentication key is represented with a 'cnf'
claim RFC8747 containing a COSE_Key I-D.ietf-cose-rfc8152bis-struct.
CCS can be seen as a generic representation of a raw public key, see
auth-cred for an example.  COSE_Key is omitted from the list above
because of limitations to represent the identity (see identities) and
because it can easily be embedded in a CCS.
Paragraph (version A):
Identical authentication credentials need to be established in both
endpoints to accomplish item 1 above (see auth-cred) but for many
settings it is not necessary to transport the authentication
credential over constrained links.  It may, for example, be pre-
provisioned or acquired out-of-band over less constrained links.
ID_CRED_x contains the authentication credential CRED_x in case it is
transported, or else contains a reference to the authentication
credential to facilitate its retrieval (see id_cred).
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 CCS 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 CCS
as authentication credential provides essentially the same
trustworthiness as a self-signed certificate or CWT but has smaller
size.
Paragraph (version A):
More details are provided in the following subsections.
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.
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.
Paragraph (version A):
The authentication key algorithm needs to be specified with enough
parameters to make it completely determined.  Note that for most
signature algorithms, the signature is determined jointly by the
signature algorithm and the authentication key algorithm.  For
example, the curve used in the signature is typically determined by
the authentication key parameters.
Paragraph (version A):
Only the Responder SHALL have access to the Responder's private
authentication key.
Paragraph (version A):
Only the Initiator SHALL have access to the Initiator's private
authentication key.
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 CCS and the other uses an X.509
certificate.
Paragraph (version A):
The credentials CRED_I and CRED_R are MACed by the Initiator and the
Responder, respectively, see asym-msg3-proc and asym-msg2-proc, and
thus included in the message integrity calculation.
Paragraph (version A):
To prevent misbinding attacks in systems where an attacker can
register public keys without proving knowledge of the private key,
SIGMA SIGMA enforces a MAC to be calculated over the "identity".
EDHOC follows SIGMA by calculating a MAC over the whole credential,
which in case of a X.509 or C509 certificate includes the "subject"
and "subjectAltName" fields, and in the case of CWT or CCS includes
the "sub" claim, see identities.  While the SIGMA paper only focuses
on the identity, the same principle is true for any information such
as policies connected to the public key.
Paragraph (version A):
When the credential is a certificate, CRED_x is an end-entity
certificate (i.e., not the certificate chain).  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 A):
the 'sub' (subject) claim containing the "identity", if the
parties have agreed on an identity besides the public key.
Paragraph (version A):
CRED_x needs to be defined such that it is identical when generated
by Initiator or Responder, see applicability.  The parameters SHALL
be encoded in bytewise lexicographic order of their deterministic
encodings as specified in Section 4.2.1 of RFC8949.
Paragraph (version A):
EDHOC assumes the existence of mechanisms (certification authority,
trusted third party, pre-provisioning, etc.) for specifying and
distributing authentication keys and identities.  Policies are
typically set based on the identity of the other party, and parties
typically only allow connections from a specific identity or a small
restricted set of identities.  For example, in the case of a device
connecting to a network, the network may only allow connections from
devices which authenticate with certificates having a particular
range of serial numbers in the subject field and signed by a
particular CA.  On the other side, the device may only be allowed to
connect to a network which authenticates with a particular public key
(information of which may be provisioned, e.g., out of band or in the
external authorization data, see AD).
Paragraph (version A):
The EDHOC implementation or the application must enforce information
about the intended endpoint, and in particular whether it is a
specific identity or a set of identities.  Either EDHOC passes
information about identity to the application for a decision, or
EDHOC needs to have access to relevant information and makes the
decision on its own.
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.  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):
EDHOC relies on COSE for identification of authentication credentials
(using ID_CRED_x, see id_cred) and supports all credential types for
which COSE header parameters are defined (see auth-cred).
Paragraph (version B):
The choice of authentication credential depends also on the trust
model (see identities).  For example, a certificate or CWT may rely
on a trusted third party, whereas a CCS or a self-signed certificate/
CWT may be used when trust in the public key can be achieved by other
means, or in the case of trust-on-first-use.
Paragraph (version B):
The type of authentication key, authentication credential, and the
way to identify the credential have a large impact on the message
size.  For example, the signature_or_MAC field is much smaller with a
static DH key than with a signature key.  A CCS is much smaller than
a self-signed certificate/CWT, but if it is possible to reference the
credential with a COSE header like 'kid', then that is typically much
smaller than to transport a CCS.
Paragraph (version B):
Policies for what connections to allow are typically set based on the
identity of the other party, and parties typically only allow
connections from a specific identity or a small restricted set of
identities.  For example, in the case of a device connecting to a
network, the network may only allow connections from devices which
authenticate with certificates having a particular range of serial
numbers and signed by a particular CA.  On the other hand, the device
may only be allowed to connect to a network which authenticates with
a particular public key (information of which may be provisioned,
e.g., out of band or in the external authorization data, see AD).
The EDHOC implementation or the application must enforce information
about the intended endpoint, and in particular whether it is a
specific identity or a set of identities.  Either EDHOC passes
information about identity to the application for a decision, or
EDHOC needs to have access to relevant information and makes the
decision on its own.
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.
Before running 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 B):
EDHOC assumes the existence of mechanisms (certification authority,
trusted third party, pre-provisioning, etc.) for specifying and
distributing authentication credentials.
Paragraph (version B):
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):
Similarly, when a PKI is used with CWTs, each party needs to have
a trusted third party public key as trust anchor to verify the
end-entity CWTs, and a specific identity or set of identities in
the 'sub'(subject) claim of the CWT to determine if it is allowed
to communicate with.  The trusted third party public key can e.g.,
be stored in a self-signed CWT or in a CCS.
Paragraph (version B):
Similarly, when a PKI is used with CWTs, each party needs to have
a trusted third party public key as trust anchor to verify the
end-entity CWTs, and a specific identity or set of identities in
the 'sub' (subject) claim of the CWT to determine if it is allowed
to communicate with.  The trusted third party public key can,
e.g., be stored in a self-signed CWT or in a CCS.
Paragraph (version A):
cred.  Before running EDHOC, each endpoint needs a specific
authentication key/unique associated subject name, or a set of
public authentication keys/unique associated subject names, which
it is allowed to communicate with.  EDHOC provides proof that the
other party possesses the private authentication key corresponding
to the public authentication key.
Paragraph (version A):
ID_CRED_I and ID_CRED_R are used to identify and optionally transport
the public authentication keys of the Initiator and the Responder,
respectively.  ID_CRED_I and ID_CRED_R do not have any cryptographic
purpose in EDHOC.
Paragraph (version A):
ID_CRED_R is intended to facilitate for the Initiator to retrieve
the Responder's public authentication key.
Paragraph (version A):
ID_CRED_I is intended to facilitate for the Responder to retrieve
the Initiator's public authentication key.
Paragraph (version A):
The identifiers ID_CRED_I and ID_CRED_R are registered in the "COSE
Header Parameters" IANA registry.  As such, ID_CRED_I and ID_CRED_R
typically also provide information about the format of authentication
credential, CRED_I and CRED_R, respectively.  ID_CRED_I and ID_CRED_R
MAY be of different types.
Paragraph (version A):
ID_CRED_x = { 35 : uri }, for x = I or R,
Paragraph (version A):
ID_CRED_x = { TBD4 : uri }, for x = I or R.
Paragraph (version A):
ID_CRED_x MAY contain the actual credential used for authentication,
CRED_x.  For example, a certificate chain can be transported in
ID_CRED_x with COSE header parameter c5c or x5chain, defined in I-
D.ietf-cose-cbor-encoded-cert and I-D.ietf-cose-x509.
Paragraph (version A):
ID_CRED_x = { TBD1 : CWT }, for x = I or R,
Paragraph (version A):
ID_CRED_x = { TBD2 : CCS }, for x = I or R.
Paragraph (version A):
As stated in Section 3.1 of I-D.ietf-cose-rfc8152bis-struct,
applications MUST NOT assume that 'kid' values are unique and several
keys associated with a 'kid' may need to be checked before the
correct one is found.  Applications might use additional information
such as 'kid context' or lower layers to determine which key to try
first.  Applications should strive to make ID_CRED_x as unique as
possible, since the recipient may otherwise have to try several keys.
ID_CRED_I and ID_CRED_R are transported in the 'ciphertext', see
asym-msg3-proc and asym-msg2-proc.
Paragraph (version B):
cred.  In order to run EDHOC, each endpoint needs a specific
authentication key/unique associated subject name, or a set of
public authentication keys/unique associated subject names, which
it is allowed to communicate with.  EDHOC provides the proof that
the other party possesses the private authentication key
corresponding to the public authentication key.
Paragraph (version B):
To prevent misbinding attacks in systems where an attacker can
register public keys without proving knowledge of the private key,
SIGMA SIGMA enforces a MAC to be calculated over the "identity".
EDHOC follows SIGMA by calculating a MAC over the whole credential,
which in case of a X.509 or C509 certificate includes the "subject"
and "subjectAltName" fields, and in the case of CWT or CCS includes
the "sub" claim.  While the SIGMA paper only focuses on the identity,
the same principle is true for other information such as policies
associated to the public key.
Paragraph (version B):
The authentication key (i.e. the public key used for authentication)
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.  The authentication key algorithm needs to be compatible
with the method and the cipher suite.  The authentication key
algorithm needs to be compatible with the EDHOC key exchange
algorithm when static Diffie-Hellman authentication is used and
compatible with the EDHOC signature algorithm when signature
authentication is used.
Paragraph (version B):
Note that for most signature algorithms, the signature is determined
by the signature algorithm and the authentication key algorithm
together.  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.
Paragraph (version B):
For X.509 the authentication key is represented with a
SubjectPublicKeyInfo field.  For CWT and CCS, the authentication key
is represented with a 'cnf' claim RFC8747 containing a COSE_Key I-
D.ietf-cose-rfc8152bis-struct.
Paragraph (version B):
The authentication credentials, CRED_I and CRED_R, contain the public
authentication key of the Initiator and the Responder, respectively.
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".
Paragraph (version B):
CRED_x needs to be defined such that it is identical when used by
Initiator or Responder.  The Initiator and Responder are expected to
agree on a specific encoding of the credential, see applicability.
It is RECOMMENDED that the COSE 'kid' parameter, when used, refers to
a specific encoding.  The Initiator and Responder SHOULD use an
available authentication credential (transported in EDHOC or
otherwise provisioned) without re-encoding.  If for some reason re-
encoding of the authentication credential may occur, then a potential
common encoding for CBOR based credentials is bytewise lexicographic
order of their deterministic encodings as specified in Section 4.2.1
of RFC8949.
Paragraph (version B):
When the authentication credential is a X.509 certificate, CRED_x
SHALL be the end-entity DER encoded certificate wrapped in a bstr
I-D.ietf-cose-x509.
Paragraph (version B):
When the authentication credential is a COSE_Key in a CWT, CRED_x
SHALL be the untagged CWT.
Paragraph (version B):
When the authentication credential is a COSE_Key but not in a CWT,
CRED_x SHALL be an untagged CCS.  * Naked COSE_Keys are thus
dressed as CCS when used in EDHOC, which is done by prefixing the
COSE_Key with 0xA108A101.
Paragraph (version B):
ID_CRED_R and ID_CRED_I are transported in message_2 and message_3,
respectively (see asym-msg2-proc and asym-msg3-proc).  They are used
to identify and optionally transport the authentication keys of the
Initiator and the Responder, respectively.  ID_CRED_I and ID_CRED_R
do not have any cryptographic purpose in EDHOC since EDHOC integrity
protects the authentication credential.  EDHOC relies on COSE for
identification of authentication credentials and supports all COSE
header parameters used to identify authentication credentials
including X.509, C509, CWT and CCS.
Paragraph (version B):
ID_CRED_R is intended to facilitate for the Initiator to retrieve
the Responder's authentication key.
Paragraph (version B):
ID_CRED_I is intended to facilitate for the Responder to retrieve
the Initiator's authentication key.
Paragraph (version B):
ID_CRED_I and ID_CRED_R are COSE header maps and contains one or more
COSE header parameter.  ID_CRED_I and ID_CRED_R MAY contain different
header parameters.  The header parameters typically provide some
information about the format of authentication credential.
Paragraph (version A):
Note that 'kid' is extended to support int values to allow more one-
byte identifiers (see kid-header-param and kid-key-common-param)
which may be useful in many scenarios since constrained devices only
have a few keys.
Paragraph (version B):
Note that 'kid' is extended to support int values to allow more one-
byte identifiers (see kid-header-param and kid-key-common-param)
which may be useful in many scenarios since constrained devices only
have a few keys.  As stated in Section 3.1 of I-D.ietf-cose-
rfc8152bis-struct, applications MUST NOT assume that 'kid' values are
unique and several keys associated with a 'kid' may need to be
checked before the correct one is found.  Applications might use
additional information such as 'kid context' or lower layers to
determine which key to try first.  Applications should strive to make
ID_CRED_x as unique as possible, since the recipient may otherwise
have to try several keys.
Paragraph (version B):
See COSE for more examples.
Paragraph (version A):
The Initiator and the Responder are responsible for verifying the
integrity of certificates.  The selection of trusted CAs should be
done very carefully and certificate revocation should be supported.
The private authentication keys MUST be kept secret.
Paragraph (version B):
The Initiator and the Responder are responsible for verifying the
integrity of certificates.  The selection of trusted CAs should be
done very carefully and certificate revocation should be supported.
The private authentication keys MUST be kept secret, only the
Responder SHALL have access to the Responder's private authentication
key and only the Initiator SHALL have access to the Initiator's
private authentication key.