Draft: draft-ietf-lake-edhoc

Commentary: I have been reading v17 and sent some comments to the authors , that I summarize here : 1 ) - Regarding RPK , previous versions of the document had a more detailed explanation about RPK . For example , in version v06 you had " The Initiator and the Responder  use different types of credentials , e.g. one uses an RPK and the other uses a public key certificate . ” So RPK is included as part of the definition of authentication credential . However , v17 may have a different meaning since it seems “ credentials " is defined as follows : " EDHOC relies on COSE for identification of credentials ( see Section 3.5.3 ) , for example X.509 certificates [ RFC5280 ] , C509 certificates [ I - D.ietf - cose - cbor - encoded - cert ] , CWTs [ RFC8392 ] and CWT Claims Sets ( CCS ) [ RFC8392 ] . When the identified credential is a chain or a bag , the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT . I assume RPK is also an authentication credential and this should be included in this text . A clarification would be worthy . 2 ) I assume it is possible that any two IoT devices can act as initiator but also as a responder , even between same two peers . It is the application which decides when to start EDHOC ( initiator ) in a particular case , correct ? 3 ) It seems the EDHOC does not define any exchange for the key update ( some sort of rekey ) . It seems an application at some point exchange some messages as " some event that triggered the key update . ” Then the application call to EDHOC - KeyUpdate function to get a new PRK . Am I right ? I am asking because looking at IKEv2 , for example , and for the rekey , an exchange is required . Although it would add a little bit more complexity , would n’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying . Moreover , this function is defined in an Appendix . Is it mandatory to implement ? 
 . The document should talk about RPK a bit more as that is term that people might search for . Should be explained that CWT is the format EDHOC uses for raw public keys ( RPK ) .
Mailing list commentary: Hi all : I have been reading v17 and sent some comments to the authors , that I summarize here : 1 ) - Regarding RPK , previous versions of the document had a more detailed explanation about RPK . For example , in version v06 you had " The Initiator and the Responder use different types of credentials , e.g. one uses an RPK and the other uses a public key certificate . ” So RPK is included as part of the definition of authentication credential . However , v17 may have a different meaning since it seems “ credentials " is defined as follows : " EDHOC relies on COSE for identification of credentials ( see Section 3.5.3 ) , for example X.509 certificates [ RFC5280 ] , C509 certificates [ I - D.ietf - cose - cbor - encoded - cert ] , CWTs [ RFC8392 ] and CWT Claims Sets ( CCS ) [ RFC8392 ] . When the identified credential is a chain or a bag , the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT . I assume RPK is also an authentication credential and this should be included in this text . A clarification would be worthy . 2 ) I assume it is possible that any two IoT devices can act as initiator but also as a responder , even between same two peers . It is the application which decides when to start EDHOC ( initiator ) in a particular case , correct ? 3 ) It seems the EDHOC does not define any exchange for the key update ( some sort of rekey ) . It seems an application at some point exchange some messages as " some event that triggered the key update . ” Then the application call to EDHOC - KeyUpdate function to get a new PRK . Am I right ? I am asking because looking at IKEv2 , for example , and for the rekey , an exchange is required . Although it would add a little bit more complexity , would n’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying . Moreover , this function is defined in an Appendix . Is it mandatory to implement ? Beyond these clarifications , I think the document is ready . Best Regards .
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, and are deterministically encoded. 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):
The EDHOC protocol consists of three mandatory messages (message_1,
message_2, message_3) between an Initiator and a Responder, an
optional fourth message (message_4), and an error message.  The roles
have slightly different security properties which should be
considered when the roles are assigned, see sec-prop.  All EDHOC
messages are CBOR Sequences RFC8742, and are deterministically
encoded. 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 A):
For X.509 certificates the authentication key is represented with a
SubjectPublicKeyInfo field.  For CWT and CCS (see auth-cred)) the
authentication key is represented with a 'cnf' claim RFC8747
containing a COSE_Key RFC9052.
Paragraph (version A):
The authentication credentials, CRED_I and CRED_R, contain the public
authentication key of the Initiator and the Responder, respectively.
Paragraph (version A):
EDHOC relies on COSE for identification of credentials (see id_cred),
for example X.509 certificates RFC5280, C509 certificates I-D.ietf-
cose-cbor-encoded-cert, CWTs RFC8392 and CWT Claims Sets (CCS)
RFC8392.  When the identified credential is a chain or a bag, the
authentication credential CRED_x is just the end entity X.509 or C509
certificate / CWT.
Paragraph (version B):
For X.509 certificates the authentication key is represented by a
SubjectPublicKeyInfo field.  For CWT and CCS (see auth-cred)) the
authentication key is represented by a 'cnf' claim RFC8747 containing
a COSE_Key RFC9052.  In EDHOC, a raw public key (RPK) is an
authentication key encoded as a COSE_Key wrapped in a CCS.
Paragraph (version B):
The authentication credentials, CRED_I and CRED_R, contain the public
authentication key of the Initiator and the Responder, respectively.
The authentication credential typically also contains other
parameters that needs to be verified by the application, see auth-
validation, and in particular information about the identity
("subject") of the endpoint to prevent misbinding attacks, see
identities.
Paragraph (version B):
EDHOC relies on COSE for identification of credentials (see id_cred),
for example X.509 certificates RFC5280, C509 certificates I-D.ietf-
cose-cbor-encoded-cert, CWTs RFC8392 and CWT Claims Sets (CCS)
RFC8392.  When the identified credential is a chain or a bag, the
authentication credential CRED_x is just the end entity X.509 or C509
certificate / CWT.  The Initiator and the Responder MAY use different
types of authentication credentials, e.g., one uses an RPK and the
other uses a public key certificate.
Paragraph (version A):
When the authentication credential is a CWT including a COSE_Key,
then CRED_x SHALL be the untagged CWT.
Paragraph (version A):
When the authentication credential includes a COSE_Key but is not
in a CWT, CRED_x SHALL be an untagged CCS.
Paragraph (version A):
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):
When the authentication credential is a CWT including a COSE_Key,
CRED_x SHALL be the untagged CWT.
Paragraph (version B):
When the authentication credential includes a COSE_Key but is not
in a CWT, CRED_x SHALL be an untagged CCS.  This is how RPKs are
encoded, see fig-ccs for an example.
Paragraph (version B):
Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in
its simplest form by prefixing the COSE_Key with 0xA108A101 (a
map with a 'cnf' claim).  In that case the resulting
authentication credential contains no other identity than the
public key itself, see identities.
Paragraph (version A):
EDHOC requires certain parameters to be agreed upon between Initiator
and Responder.  Some parameters can be negotiated through the
protocol execution (specifically, cipher suite, see cs) but other
parameters are only communicated and may not be negotiated (e.g.,
which authentication method is used, see method).  Yet other
parameters need to be known out-of-band.
Paragraph (version B):
EDHOC requires certain parameters to be agreed upon between Initiator
and Responder.  Some parameters can be negotiated through the
protocol execution (specifically, cipher suite, see cs) but other
parameters are only communicated and may not be negotiated (e.g.,
which authentication method is used, see method).  Yet other
parameters need to be known out-of-band.  The application decides
which endpoint is Initiator and which is Responder.