Draft: draft-ietf-lake-edhoc

Commentary: Looks good to me . 
 As far as I understand , since we changed the derivation of K4 / IV4 , verifying  does not give explicit key confirmation of PRKout . Should we change to K4 = EDHOC - KDF ( PRKout , 8 , h '' , keylength ) IV4 = EDHOC - KDF ( PRKout , 9 , h '' , ivlength ) or K4 = EDHOC - KDF ( PRKexporter , 8 , h '' , keylength ) IV4 = EDHOC - KDF ( PRKexporter , 9 , h '' , ivlength ) ( in the latter case we may want to re - shuffle the labels ) Edit : These changes are not necessary , rephrasing of key confirmation in . 
 Chunk ready to merge ? Discussion continues in . 
 Latest commit addresses suggestion to make clearer distinction between key derivation for EDHOC processing , resulting in PRKout , and key derivation for application , i.e. making use of PRKout in EDHOC - Exporter and EDHOC - KeyUpdate .
Paragraph (version A):
The parties exchanging messages are called Initiator (I) and
Responder (R).  They exchange ephemeral public keys, compute a shared
secret, and derive symmetric application keys used to protect
application data.
Paragraph (version B):
The parties exchanging messages are called Initiator (I) and
Responder (R).  They exchange ephemeral public keys, compute a shared
secret key PRK_out, and derive symmetric application keys used to
protect application data.
Paragraph (version A):
An optional fourth message giving explicit key confirmation to I
in deployments where no protected application data is sent from R
to I.
Paragraph (version B):
An optional fourth message giving key confirmation to I in
deployments where no protected application data is sent from R to
I.
Paragraph (version A):
EDHOC uses Extract-and-Expand RFC5869 with the EDHOC hash algorithm
in the selected cipher suite to derive keys used in EDHOC and in the
application.  Extract is used to derive fixed-length uniformly
pseudorandom keys (PRK) from ECDH shared secrets.  Expand is used to
derive additional output keying material (OKM) from the PRKs.
Paragraph (version A):
This section defines Extract, Expand and other key derivation
functions based on these: Expand is used to define EDHOC-KDF and in
turn EDHOC-Exporter, whereas Extract is used to define EDHOC-
KeyUpdate.  In EDHOC a specific message is protected with a certain
pseudorandom key, but how the key is derived depends on the method.
A diagram of the EDHOC key schedule can be found in Figure 2 of
Vucinic22.
Paragraph (version A):
The pseudorandom keys (PRKs) are derived using Extract.
Paragraph (version B):
EDHOC uses Extract-and-Expand RFC5869 with the EDHOC hash algorithm
in the selected cipher suite to derive keys used in message
processing.  This section defines Extract (extract) and Expand
(expand), and how to use them to derive PRK_out (prkout) which is the
shared secret key resulting from a successful EDHOC exchange.
Paragraph (version B):
Extract is used to derive fixed-length uniformly pseudorandom keys
(PRK) from ECDH shared secrets.  Expand is used to define EDHOC-KDF
for generating MACs and for deriving output keying material (OKM)
from PRKs.
Paragraph (version B):
In EDHOC a specific message is protected with a certain pseudorandom
key, but how the key is derived depends on the method as detailed in
asym.
Paragraph (version B):
The rest of the section defines the pseudo-random keys PRK_2e,
PRK_3e2m and PRK_4e3m; their use is shown in fig-edhoc-kdf.
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 (the Responder's
private authentication key, see auth-keys), else PRK_3e2m = PRK_2e.
Paragraph (version A):
If the Initiator authenticates with a static Diffie-Hellman key, then
PRK_3m = 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_3m = PRK_3e2m.
Paragraph (version A):
The transcript hash TH_4 is a CBOR encoded bstr and the input to the
hash function is a CBOR Sequence.
Paragraph (version A):
where H() is the EDHOC hash algorithm in the selected cipher suite.
Paragraph (version A):
The keys, IVs and MACs used in EDHOC are derived from the PRKs using
Expand, and instantiated with the EDHOC AEAD algorithm in the
selected cipher suite.
Paragraph (version A):
transcript_hash is a bstr set to one of the transcript hashes
TH_2, TH_3, or TH_4 as defined in Sections asym-msg2-form, asym-
msg3-form, and exporter.
Paragraph (version A):
label is a tstr set to the name of the derived key, IV or MAC;
i.e., "KEYSTREAM_2", "MAC_2", "K_3", "IV_3", or "MAC_3".
Paragraph (version B):
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),
Paragraph (version B):
else PRK_3e2m = PRK_2e.
Paragraph (version B):
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),
Paragraph (version B):
else PRK_4e3m = PRK_3e2m.
Paragraph (version B):
When EDHOC-KDF is used to derive OKM for EDHOC message processing,
then context includes one of the transcript hashes TH_2, TH_3, or
TH_4 defined in Sections asym-msg2-proc and asym-msg3-proc.
Paragraph (version A):
KEYSTREAM_2 is derived using the transcript hash TH_2 and the
pseudorandom key PRK_2e.
Paragraph (version A):
MAC_2 is derived using the transcript hash TH_2 and the
pseudorandom key PRK_3e2m.
Paragraph (version A):
K_3 and IV_3 are derived using the transcript hash TH_3 and the
pseudorandom key PRK_3e2m.  IVs are only used if the EDHOC AEAD
algorithm uses IVs.
Paragraph (version A):
MAC_3 is derived using the transcript hash TH_3 and the
pseudorandom key PRK_3m.
Paragraph (version A):
KEYSTREAM_2, K_3, and IV_3 use an empty CBOR byte string h'' as
context.  MAC_2 and MAC_3 use context as defined in asym-msg2-proc
and asym-msg3-proc, respectively.
Paragraph (version A):
where label is a registered tstr from the EDHOC Exporter Label
registry (exporter-label), context is a bstr defined by the
application, and length is a uint defined by the application.  The
(label, context) pair must be unique, i.e., a (label, context) MUST
NOT be used for two different purposes.  However an application can
re-derive the same key several times as long as it is done in a
secure way.  For example, in most encryption algorithms the same key
can be reused with different nonces.  The context can for example be
the empty CBOR byte string.
Paragraph (version A):
Examples of use of the EDHOC-Exporter are given in asym-msg4-proc and
transfer.
Paragraph (version A):
K_4 and IV_4 are derived with the EDHOC-Exporter using the empty
CBOR byte string h'' as context, and labels "EDHOC_K_4" and
"EDHOC_IV_4", respectively.  IVs are only used if the EDHOC AEAD
algorithm uses IVs.
Paragraph (version A):
With SHA-256, no context, and OKM length smaller than 24, any label
longer than 20 characters requires an additional iteration of the
hash function to compute.  The labels in this specification have all
been chosen to fit within this limit.
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_out 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_out until it has verfied
that other endpoint has the correct new PRK_out.  I-D.ietf-core-
oscore-key-update describes key update for OSCORE using EDHOC-
KeyUpdate.
Paragraph (version B):
fig-edhoc-kdf lists derivations made with EDHOC-KDF during message
processing.  How the output keying material is used is specified in
asym.
Paragraph (version B):
The pseudo-random key PRK_out, derived as shown in fig-edhoc-kdf, is
the only secret key shared between Initiator and Responder that needs
to be stored after a successful EDHOC exchange, see m3.  Keys for
applications are derived from PRK_out, see exporter.
Paragraph (version B):
This section defines EDHOC-Exporter and EDHOC-KeyUpdate in terms of
EDHOC-KDF and PRK_out.
Paragraph (version B):
PRK_exporter MUST be derived anew if PRK_out is updated, in
particular if EDHOC-KeyUpdate is used, see keyupdate.
Paragraph (version B):
The (label, context) pair must be unique, i.e., a (label, context)
MUST NOT be used for two different purposes.  However an application
can re-derive the same key several times as long as it is done in a
secure way.  For example, in most encryption algorithms the same key
can be reused with different nonces.  The context can for example be
the empty CBOR byte string.
Paragraph (version B):
Examples of use of the EDHOC-Exporter are given in transfer.
Paragraph (version B):
The EDHOC-KeyUpdate takes a context as input to enable binding of the
updated PRK_out to some event that triggered the keyUpdate.  The
Initiator and the Responder need to agree on the context, 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_out until
it has verfied that other endpoint has the correct new PRK_out.  I-
D.ietf-core-oscore-key-update describes key update for OSCORE using
EDHOC-KeyUpdate.
Paragraph (version A):
Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", << ID_CRED_R,
CRED_R, ? EAD_2 >>, mac_length_2 ).  If the Responder
authenticates with a static Diffie-Hellman key (method equals 1 or
3), then mac_length_2 is the EDHOC MAC length given by the
selected cipher suite.  If the Responder authenticates with a
signature key (method equals 0 or 2), then mac_length_2 is equal
to the output size of the EDHOC hash algorithm given by the
selected cipher suite.
Paragraph (version B):
If the Responder authenticates with a static Diffie-Hellman key
(method equals 1 or 3), then mac_length_2 is the EDHOC MAC
length given by the selected cipher suite.  If the Responder
authenticates with a signature key (method equals 0 or 2), then
mac_length_2 is equal to the output size of the EDHOC hash
algorithm given by the selected cipher suite.
Paragraph (version B):
Compute KEYSTREAM_2 as in expand, where plaintext_length is the
length of PLAINTEXT_2.
Paragraph (version A):
Compute MAC_3 = EDHOC-KDF( PRK_3m, TH_3, "MAC_3", << ID_CRED_I,
CRED_I, ? EAD_3 >>, mac_length_3 ).  If the Initiator
authenticates with a static Diffie-Hellman key (method equals 2 or
3), then mac_length_3 is the EDHOC MAC length given by the
selected cipher suite.  If the Initiator authenticates with a
signature key (method equals 0 or 1), then mac_length_3 is equal
to the output size of the EDHOC hash algorithm given by the
selected cipher suite.
Paragraph (version B):
If the Initiator authenticates with a static Diffie-Hellman key
(method equals 2 or 3), then mac_length_3 is the EDHOC MAC
length given by the selected cipher suite.  If the Initiator
authenticates with a signature key (method equals 0 or 1), then
mac_length_3 is equal to the output size of the EDHOC hash
algorithm given by the selected cipher suite.
Paragraph (version A):
Make the connection identifiers (C_I, C_R) and the application
algorithms in the selected cipher suite available to the
application.  The application can now compute PRK_out and derive
application keys using the EDHOC-Exporter interface, see exporter.
Paragraph (version A):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_out (implicit key
authentication).  The Initiator can securely derive application keys
and send protected application data.  However, the Initiator does not
know that the Responder has actually computed the key PRK_out and
therefore the Initiator SHOULD NOT permanently store the keying
material PRK_out, or derive application keys, until the Initiator is
assured that the Responder has actually computed the key PRK_out
(explicit key confirmation).  This is similar to waiting for
acknowledgement (ACK) in a transport protocol.  Explicit key
confirmation is e.g., assured when the Initiator has verified an
OSCORE message or message_4 from the Responder.
Paragraph (version B):
Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3) where H()
is the EDHOC hash algorithm of the selected cipher suite.  The
transcript hash TH_4 is a CBOR encoded bstr and the input to the
hash function is a CBOR Sequence.
Paragraph (version B):
Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can
now derive application keys using the EDHOC-Exporter interface,
see exporter.
Paragraph (version B):
The Initiator SHOULD NOT persistently store PRK_out or application
keys until the Initiator has verified message_4 or a message
protected with a derived application key, such as an OSCORE message,
from the Responder.  This is similar to waiting for acknowledgement
(ACK) in a transport protocol.
Paragraph (version A):
Make the connection identifiers (C_I, C_R) and the application
algorithms in the selected cipher suite available to the
application.  The application can now derive application keys
using the EDHOC-Exporter interface, see exporter.
Paragraph (version A):
After verifying message_3, the Responder is assured that the
Initiator has calculated the key PRK_3m (explicit key confirmation),
that no other party than the Initiator can compute the key PRK_3m,
and that no other party than the Initiator can compute the key
PRK_out (implicit key authentication).  The Responder can securely
derive and store the keying material PRK_out and send protected
application data.
Paragraph (version B):
After verifying message_3, the Responder can compute PRK_out, see
prkout, derive application keys using the EDHOC-Exporter interface,
see exporter, persistently store the keying material, and send
protected application data.
Paragraph (version A):
After verifying message_4, the Initiator is assured that the
Responder has calculated the key PRK_out (explicit key confirmation)
and that no other party can derive the key.
Paragraph (version B):
After verifying message_4, the Initiator is assured that the
Responder has calculated the key PRK_out (key confirmation) and that
no other party can derive the key.
Paragraph (version A):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_out (implicit key
authentication).  The Initiator does however not know that the
Responder has actually computed the key PRK_out.  While the Initiator
can securely send protected application data, the Initiator SHOULD
NOT permanently store the keying material PRK_out until the Initiator
is assured that the Responder has actually computed the key PRK_out
(explicit key confirmation).  Explicit key confirmation is e.g.,
assured when the Initiator has verified an OSCORE message or
message_4 from the Responder.  After verifying message_3, the
Responder is assured that the Initiator has calculated the key PRK_3m
(explicit key confirmation) and that no other party than the
Initiator can compute the keys PRK_3m and PRK_out.  The Responder can
securely derive and store the keying material PRK_out and send
protected application data.
Paragraph (version B):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_out.  While the Initiator
can securely send protected application data, the Initiator SHOULD
NOT persistently store the keying material PRK_out until the
Initiator has verified an OSCORE message or message_4 from the
Responder.  After verifying message_3, the Responder is assured that
an honest Initiator has computed the key PRK_out.  The Responder can
securely derive and store the keying material PRK_out, and send
protected application data.