Draft: draft-ietf-lake-edhoc

Commentary: Did n't manage to make a PR on , but this should just be rebasing on current master 
 I reviewed and updated it with my proposed changes in the commit above . Pending resolution of comments in and further quick comments I think we are ready to merge . 
 I updated the example message sizes , I think it makes most sense to describe EDHOC itselft without any transport parameters . Two editorials " may need ... no , they do n't need anything special " " For use of EDHOC in the XX protocol " Otherwise I think this is ready to merge 
 Christian had a comment that one of the hashes became useless . I am not sure it should be removed . New methods may specify things send in message_3 . 
 Let 's not do the editorials now , current text can be kept as placeholders . Let 's remove data_3 and the iterated hash until there is a concrete method that needs it , but let 's merge first to avoid further conflicts . 
 In general , I think that this approach is a cleaner way to solve the issue than what we had with CORR . Still , as discussed in , in order to implement this , interaction between three different protocol implementations is needed : EDHOC to negotiate connection identifiers , OSCORE / application for uniqueness requirements and CoAP / transport layer to transport them . The text is not very clear on how this interaction happens . While this is an implementation decision , it would still be good to organize the text in such a way that a clean separation of concerns is described . One way of doing this would be to split " Connection Identifiers and Transport " into two separate sections : " Connection Identifiers " , and " Transport " . I would further split the " Connection Identifiers " section into three subsections , e.g : 1 ) " CID Negotiation " , 2 ) " CID Selection " , and 3 ) " CID Transport " . The goal is to describe a clear flow and who does what . For instance , EDHOC calls an OSCORE API which proposes the CID , EDHOC negotiates the CID by exchanging EDHOC messages , EDHOC sets the CIDs to the underlying transport as soon as the CIDs are available . Transport module decides when to send and when to omit the CIDs depending on its correlation properties . The text should be general of course to account for other applications and transports . Would that make sense ? P.S. I am missing normative text in the CoAP transport case mandating the transport of connection identifiers for different messages ( in Section 7.2 ? ) . Am I missing the reason why there is no normative text at all in Section 7 ? 
 I forgot to respond to The PR which was merged addressed much of these comments . split " Connection Identifiers and Transport " into two separate sections split the " Connection Identifiers " section into subsections CID Selection Use of CID in EDHOC Use of CID in OSCORE and expanded text about CID transport in the new Transport section The second split was not exactly what was requested but it made more sense to me : The concept of " CID negotation " was redundant in the draft and replaced with " CID Selection " in a few occurences , wherefore a separate section of CID negotation was not needed . Having one section about CID Transport and then immediately followed by a section about Transport lead to duplicated text so I settled for a reference to the latter section . I did not include any text about OSCORE API which seemed too implementation specific . About normative text for CoAP transport of connection identifier , I do n't know why that is needed . How EDHOC messages are transported is application dependent . If desirable an applicability statement can state that they use connection identifiers as described in A.3 . I do n't think adding normative text makes a difference . If you think this is missing , or something else was missed in this comment , please make separate issues . Thanks . 
 A couple of editorial comments while going through the PR .
Paragraph (version A):
Explicit connection identifiers C_I, C_R chosen by I and R,
respectively, enabling the recipient to find the protocol state.
Paragraph (version B):
Negotiation of connection identifiers C_I and C_R which may be
used to identify established keys or protocol state.
Paragraph (version A):
Application data is 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_1, C_I, and C_R (see corr).  EDHOC may be used with the media type
application/edhoc defined in iana.
Paragraph (version B):
Application data is 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 A):
The data item METHOD_CORR in message_1 (see asym-msg1-form), is an
integer specifying the method and the correlation properties of the
transport, which are described in this section.
Paragraph (version A):
EDHOC includes optional connection identifiers (C_1, C_I, C_R).  The
connection identifiers C_1, C_I, and C_R do not have any
cryptographic purpose in EDHOC.  They contain information
facilitating retrieval of the protocol state and may therefore be
very short.  C_1 is always set to "null", while C_I and C_R are
chosen by I and R, respectively.  One byte connection identifiers are
realistic in many scenarios as most constrained devices only have a
few connections.  In cases where a node only has one connection, the
identifiers may even be the empty byte string.
Paragraph (version A):
The connection identifier MAY be used with an application protocol
(e.g.  OSCORE) for which EDHOC establishes keys, in which case the
connection identifiers SHALL adhere to the requirements for that
protocol.  Each party choses a connection identifier it desires the
other party to use in outgoing messages.  (For OSCORE this results in
the endpoint selecting its Recipient ID, see Section 3.1 of RFC8613).
Paragraph (version A):
Cryptographically, EDHOC does not put requirements on the lower
layers.  EDHOC is not bound to a particular transport layer, and can
be used in environments without IP.  The application using EDHOC is
responsible to handle message loss, reordering, message duplication,
fragmentation, demultiplex EDHOC messages from other types of
messages, and denial of service protection, where necessary.
Paragraph (version A):
The Initiator and the Responder need to have agreed on a transport to
be used for EDHOC, see applicability.  It is recommended to transport
EDHOC in CoAP payloads, see transfer.
Paragraph (version A):
corr = 0, the transport does not provide a correlation mechanism.
Paragraph (version A):
corr = 1, the transport provides a correlation mechanism that
enables the Responder to correlate message_2 and message_1 as well
as message_4 and message_3.
Paragraph (version A):
corr = 2, the transport provides a correlation mechanism that
enables the Initiator to correlate message_3 and message_2.
Paragraph (version A):
corr = 3, the transport provides a correlation mechanism that
enables both parties to correlate all three messages.
Paragraph (version A):
For example, if the key exchange is transported over CoAP, the CoAP
Token can be used to correlate messages, see coap.
Paragraph (version B):
EDHOC includes the negotiation of connection identifiers (C_I, C_R)
which may be used to identify a connection for which EDHOC has
established keys.  The connection identifiers C_I and C_R do not have
any cryptographic purpose in EDHOC.
Paragraph (version B):
C_I and C_R are chosen by I and R, respectively.  Each party chooses
a connection identifier it wants the other party to use in its
outgoing messages.  One byte connection identifiers are realistic in
many scenarios as most constrained devices only have a few
connections.  In cases where a node has only one connection, the
identifier may even be the empty byte string.
Paragraph (version B):
If a connection identifier is used with an application protocol for
which EDHOC establishes keys (such as OSCORE) then the connection
identifiers SHALL adhere to the requirements for that protocol.  For
OSCORE the choice of 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).
Paragraph (version B):
Connection identifiers may be used to facilitate the retrieval of
protocol state during EDHOC protocol execution.  EDHOC transports
that do not inherently provide correlation across all messages of an
exchange can send connection identifiers along with EDHOC messages to
gain that required capability, see transport).  For an example when
CoAP is used as transport, see coap.
Paragraph (version B):
message loss,
Paragraph (version B):
message reordering,
Paragraph (version B):
message duplication,
Paragraph (version B):
correlation of messages, including an indication of a message
being message_1,
Paragraph (version B):
fragmentation,
Paragraph (version B):
denial of service protection.
Paragraph (version B):
The Initiator and the Responder need to have agreed on a transport to
be used for EDHOC, see applicability.  It is recommended to transport
EDHOC in CoAP payloads, see coap.
Paragraph (version A):
How the endpoint detects that an EDHOC message is received.  This
includes how EDHOC messages are transported, for example in the
payload of a CoAP message with a certain Uri-Path or Content-
Format; see coap.
Paragraph (version A):
Method and correlation of underlying transport messages
(METHOD_CORR; see method and corr).  This gives information about
the optional connection identifier fields.
Paragraph (version B):
How the endpoint detects that an EDHOC message is received.  This
includes how EDHOC messages are transported, for example in the
payload of a CoAP message with a certain Uri-Path or Content-
Format; see coap.  * The method of transporting EDHOC messages may
also describe data carried along with the messages that are needed
for the transport to satisfy the requirements of transport, e.g.,
connection identifiers used with certain messages, see coap.
Paragraph (version B):
Authentication method (METHOD; see method).
Paragraph (version A):
For some parameters, like METHOD_CORR, 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 B):
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 each session, the endpoints are assumed to keep an associated
protocol state containing connection 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):
Retrieve the protocol state, e.g. using the received connection
identifier (ci) or with the help of message correlation provided
by the transport protocol (corr).  If there is no protocol state,
in the case of message_1, a new protocol state is created.  An
initial C_1 = "null" byte in message_1 (asym-msg1-form) can be
used to distinguish message_1 from other messages.  The Responder
endpoint needs to make use of available Denial-of-Service
mitigation (dos).
Paragraph (version B):
Retrieve the protocol state according to the message correlation
provided by the transport, see transport.  If there is no protocol
state, in the case of message_1, a new protocol state is created.
The Responder endpoint needs to make use of available Denial-of-
Service mitigation (dos).
Paragraph (version A):
C_1 - an initial CBOR simple value "null" (= 0xf6) MAY be used to
distinguish message_1 from other messages.
Paragraph (version A):
METHOD_CORR = 4 * method + corr, where method = 0, 1, 2, or 3 (see
fig-method-types) and the correlation parameter corr is chosen
based on the transport and determines which connection identifiers
that are omitted (see corr).
Paragraph (version B):
METHOD = 0, 1, 2, or 3 (see fig-method-types).
Paragraph (version A):
If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted,
otherwise C_R is not omitted.
Paragraph (version A):
Retrieve the protocol state using the connection identifier C_R
and/or other external information such as the CoAP Token and the
5-tuple.
Paragraph (version B):
Retrieve the protocol state using the message correlation provided
by the transport (e.g., the CoAP Token and the 5-tuple as a
client, or the prepended C_R as a server).
Paragraph (version A):
C_x - (optional) variable length connection identifier, encoded as
a bstr_identifier (see bstr_id).  If error is sent by the
Responder and corr (METHOD_CORR mod 4) equals 0 or 2 then C_x is
set to C_I, else if error is sent by the Initiator and corr
(METHOD_CORR mod 4) equals 0 or 1 then C_x is set to C_R, else C_x
is omitted.
Paragraph (version A):
The exchange in fig-coap1 protects the client identity against active
attackers and the server identity against passive attackers.  An
alternative exchange that protects the server identity against active
attackers and the client identity against passive attackers is shown
in fig-coap2.  In this case the CoAP Token enables the Responder to
correlate message_2 and message_3 so the correlation parameter corr =
payload of a POST request with a 2.04 (Changed) response.
Paragraph (version B):
In order to correlate a message received from a client to a message
previously sent by the server, messages sent by the client are
prepended with the CBOR serialization of the connection identifier
which the server has chosen.  This applies independently of if the
CoAP server is Responder or Initiator.  For the default case when the
server is Responder, the prepended connection identifier is C_R, and
C_I if the server is Initiator.  If message_1 is sent to the server,
the CBOR simple value "null" (0xf6) is sent in its place (given that
the server has not selected C_R yet).
Paragraph (version B):
These identifiers are encoded in CBOR and thus self-delimiting.  They
are sent in front of the actual EDHOC message, and only the part of
the body following the identifier is used for EDHOC processing.
Paragraph (version B):
Consequently, the application/edhoc media type does not apply to
these messages; their media type is unnamed.
Paragraph (version B):
An example of a successful EDHOC exchange using CoAP is shown in fig-
coap1.  In this case the CoAP Token enable correlation on the
Initiator side, and the prepended C_R enables correlation on the
Responder (server) side.
Paragraph (version B):
The exchange in fig-coap1 protects the client identity against active
attackers and the server identity against passive attackers.  An
alternative exchange that protects the server identity against active
attackers and the client identity against passive attackers is shown
in fig-coap2.  In this case the CoAP Token enables the Responder to
correlate message_2 and message_3, and the prepended C_I enables
correlation on the Initiator (server) side.  If EDHOC message_4 is
used, C_I is prepended, and it is transported with CoAP in the
payload of a POST request with a 2.04 (Changed) response.