Draft: draft-ietf-lake-edhoc

Commentary: This pull request corresponds to . Changes : is now only , i.e. only used for computing the MAC . An additional key is defined , which can be seen as the final session key , computed based on and . The export now only depends on . Comments : The name is completely arbitrary . The input that was inside the exporter has been replaced by the empty string . It is a shortcut that allows to use the existing syntax , but it is also arbitrary . This update also corresponds to the option 2 ) of . Indeed , computing both the MAC and could be performed inside a TEE , and a leak of once it is outside of the TEE would not allow an attacker to forge any MAC it wants , as and are now disjoint values . 
 This looks like a good thing to do for several reasons . It also lowers memory requirements as the implementation only has to store PRKout instead of ( PRK4x3 m , TH_4 ) . 
 I assume that is enough . The document should probably say something about PRKout as well . I assume the property we get it the the Responder knows that I can compute PRKout . 
 you can check out the last update ! 
 I spotted a typo , otherwise the update looks ready to merge . But following there are quite a few other changes we want to make to the key schedule . To avoid merge conflicts should probably do the changes in sequence . We could start by merging this , although there will be further changes to some of the changes made here . 
 There has been a lot of suggestions and discussion regarding the key derivation latelely . Below is an attempt to summarize all the current suggstions that currently seems relatively likely to be done . This is not an issue in itself but I think it is good to have somewhere to discucess the complete changes to the key derivation . Suggested to permute the order of element in the TH2 sequence to be more resistant to any future collision attacks in hash functions . Exact order unclear but suggested to put the random and unpredictable GY first . Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes to simplify formal verification . Endpoints agree on that they received the same plaintext rather then the same cipertext . Suggested to use a salt derived from PRK in Extract to avoid usign the PRK keys directly in both Extract and ExpandSuggested to use unsigned integer instead of text string for label to save memory . Suggestion to add a final key derivation PRKout and use that in the exporter . Note that the exporter would also have uint labelsSuggestion to base Key - Update on Expand instead of extract . The label would need IANA registration .  is a new variable that the implementation needs to keep track of . Should considered whether using Exporter for KeyUpdate has any disadvantages . Suggested that more info on how an application protocol is supposed to use KeyUpdate and  together is needed . The EDHOC internal key derivations ( i.e. , not using the  ) would then be something like below . The exact labels should be discussed . Note that that only some of the derivations actually need a label to avoid collisionIncluding KeyUpdate , the IANA registered exporter labels could be : 
 Looks good . I had different naming in mind of the salts : PRK3e2 m = Extract ( SALT3e2 m , GRX ) PRK3 m = Extract ( SALT3 m , GIY ) where SALT3e2 m = EDHOC - KDF ( PRK2e , TH2 , 0 , h '' , hashlength ) SALT3 m = EDHOC - KDF ( PRK3e2 m ,  , 0 , h '' , hashlength ) With this the salts are named by its use rather than from what key they are derived . 
 The labels was just to illustrate the fact that they do n't need to be separate . I think it is still better to just use 0 - 7 . That makes it very easy for the reader to see that there are no collisions . 
 Was this a comment on my proposed names of salts , or a separate comment ? ( I agree labels 0 - 7 is good . ) 
 It was a separate comments . Your suggestion for salt naming is fine with me . Some other non - technical naming things that a hidden in my summary above I think keylength should use different terms in the derivation of K4 and OSCORE Master Secret . The current naming gives the idea that they are the same . I think the contexts in the MAC2 and MAC3 derivations should be given names . Should consider collection all the EDHOC - KDF derivations in a single place . 
 Might want to derive : K4 = EDHOC - KDF ( PRK3 m , TH4 , 0 , h '' , keylength ) IV4 = EDHOC - KDF ( PRK3 m , TH4 , 0 , h '' , ivlength ) to avoid that the applicaiton gets K4 and IV4 . Another alternative is to use K4 = EDHOC - Exporter ( 7 , h '' , keylength ) IV4 = EDHOC - Exporter ( 8 , h '' , ivlength ) and forbid the application to use the labels for K4 and IV4 
 Editorial ; should be : K4 = EDHOC - KDF ( PRK3 m , TH4 , 1 , h '' , keylength ) IV4 = EDHOC - KDF ( PRK3 m , TH4 , 2 , h '' , ivlength ) or , if we want all KDF labels distinct : K4 = EDHOC - KDF ( PRK3 m , TH4 , 8 , h '' , keylength ) IV4 = EDHOC - KDF ( PRK3 m , TH4 , 9 , h '' , ivlength ) Alternatively , application access to Exporter only allows uint with : K4 = EDHOC - Exporter ( -1 , h '' , keylength ) IV4 = EDHOC - Exporter ( -2 , h '' , ivlength ) 
 Trying to compile the suggestions . These have a PR : Suggested to permute the order of element in the TH2 sequence … Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes … Suggestion to add a final key derivation PRKout and use that in the exporter The following needs to be addressed : Suggested to use a salt derived from PRK in Extract define salt derive salt Suggested to use unsigned integer instead of text string for label to save memory suggestion to base Key - Update on Expand consider whether using Exporter for KeyUpdate has any disadvantages . more info on how an application protocol is supposed to use KeyUpdate and Exporter together distinguish keylength in K3 / K_4 and OSCORE Master Secret define contexts explicitly table of KDF derivations 
 Trying to put things together . Let 's call this variant A , part 1 . where and ( edit : depending on method ) New salts to avoid double use of PRK , named by its use . Same construction for K4 / IV4 as K3 / IV3 , motivating the renaming of 3 m in as 4e3 m. The label in the KDF , third argument , is an uint , all distinct for simplicity . 
   , part 2 : Distinct " transcript hash " in KeyUpdate and Exporter . Exporter does not give access to EDHOC internal keys . OSCORE key length separate from key_length . Edit : Not clear that ' context ' is needed in the EDHOC - Exporter . Also , to be strict in labelling we could continue enumeration . Here is variant B , part 2 ( B.1 = A.1 ): 
 Variant C.2 ( C.1 = A.1 ): ( edited :) Same as B.2 but with different labels . With variant C we have essentially : the internal KDF labels with current list : 0 , ... , 9 ; and the IANA EDHOC Exporter Registry with current list : 0 , 1 . 
 and all : Any implementation considerations or other comments on variant C above ? We 'll start with the PR(s ) soon . 
 The last posts here are confusing .... I do n't agree . These are separate . We should definitly not try to keep them separate . I.e. it should be Master Secret = EDHOC - Exporter ( 0 , h '' , oscorekeylength ) Master  = EDHOC - Exporter ( 1 , h '' , oscoresaltlength ) 
 The above looks good to me with the following not so interesting options . order of the 0 - 9 labels use 10 or 0 label for Key - Update order of the h'00 ' and h'01 ' " transcripts " 
 I think we should maybe merge the " context " and " transcript hash " inputs . This simplifies things and avoids using h'00 ' and h''01 ' as " transcript hashes . 
 Alternatively 
 The latest version of the summary looks good . 
 Overview of main changes needed :   PRK3 m as PRK4e3 m Section 4.1 update PRK definitions move section PRKout to 4.2 Section 4.2 Update EDHOC - KDF and info definition Update derivations Include derivations of salts and K4 / IV4 List EDHOC - KDF derivations with labels 0 - 9 Section 4.3 Update EDHOC - Exporter ( use label 10 instead of 11 ) Remove derivation of K4 / IV4 Section 4.4 Update EDHOC - KeyUpdate ( use label 11 instead of 10 ) Section 5.3.2 Define context2 Section 5.4.2 Define context3 Section 9.1 Update EDHOC Exporter labels     Secret / Salt derivation 
 Additional updates : As noted in previous comment , a proposal to interchange labels 10 and 11 to enumerate labels in the order they appear in the specification . ( Other proposal for assignment of   is welcome . ) Should we align / adapt definition of contextx and externalaad ? Currently ( for message2 and similar for message3 ): externalaad = < < TH2 , CREDR , ? EAD2 context2 = < < TH2 , IDCREDR , CREDR , ? EAD2 Edit : Seems to be favourable to at least align this blobs , so changed context2 to < < IDCREDR , TH2 , CREDR , ? EAD2 and similar for context_3 , in 
 PRKexporter is a key which we only introduce for simple distinction between different KDF applications . Perhaps an overkill ? May open up for unnecessary discussion about properties of that key . Here is another variant : Edit : As commented before ,  thinks a separate PRKExporter is preferred ; less error prone etc . 
 Most old comments are now addressed , and there are quite a few changes , so it is a good time to merge PR . Remaining points : derivation of K4/ IV4 and text about key confirmation . Not clear if there is any difference in practice between K4 /IV4 being derived from PRK4e3 m or PRKout , but the current text about explicit key confirmation is not valid in the former case . May alternatively tune down the key confirmation terminology . Suggested 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 . More guidance on the latter is also proposed . 
 Tried to address the remaining points in the previous comment with the latest two commits : and . More guidance on KeyUpdate may still be needed . Other points ? 
 What more guidance is needed on KeyUpdate ? 
 Was a request from someone . Might be hard to understand how to use it . E.g. that you should alternate key update and exporter Exporter Key Update Exporter Key Update Exporter ... 
 Another guidance needed is how to manage overwrite of PRKout pending confirmation of the derived key from the other endpoint . When the Initiator is updating PRKout it needs both old and new derived keys to be able to communicate securely in lock - step the change to the new key . 
 Perhaps good to remark that the entire application contexts ( including e.g. sequence numbers ) need to be maintained before a transition is made . 
 see instead . The current discussion has very little to do with 
 In method 0 , the attacker must be able to compromise the long term authentication key to break the authentication of the protocol . In other terms , leaking the ephemeral share and the session key is not enough to break authentication , and does only break secrecy . This leads to a situation where it makes sense to protect the long term authentication key inside a TEE , as it strengthens authentication . The issue is that in other methods , where an agent authenticates with a long term DH key , the attacker only needs access to ephemeral and session keys to impersonate an agent . In turn , this implies that using a TEE for the long term DH share does not currently have any meaningful impact on the security of the protocol . In more detail , for instance in Method 2 , the MAC key used to authenticate the initiator is actually the final session key . An attacker can thus by learning the ephemeral key and the session key of an initiator complete a Machine - In - The - Middle attack where the initiator believes to be talking to A while the attacker impersonated I to some Responder R. We provide a the bottom of this issue a picture describing the attack on a simplified , abstracted LAKE - EDHOC execution for clarity . Possible actions : mention that method 0 is better suited for TEE implementations , and that other methods offer weaker authentication guarantees update the protocol to allow DH authentication with a TEE , where the session key would not allow to recompute a MAC . The TEE interface would then contain both an export function to compute PRK_4x3 m as well as a function that would return the full MAC . Two similar options could be considered : Option 1 ) Add to the MAC payload the value G^IY . This option does not update the key derivation . Option 2 ) Distinguish the session key and the MAC key , with an additional inclusion of the G^IY value for the MAC key . On an abstracted edhoc protocol : ! 
 Thanks for presenting both problem and solution ! Just for clarity ( just reiterating text in ): With PR and by computing both the MAC and PRKout inside a TEE , an attacker with a leaked PRKout would not be able to forge the MAC - thus strengthening the role of a TEE also for other methods than 0 , right ? 
 Just a note about this : We found this statement quite strong :-) If the session key leaks , then authentication in the application is broken . This is the same regardless of signature vs. static DH key protected in TEE . The long - term key in TEE continues to provide security in other instances of the protocol in which the session key does not leak . This is also the same regardless of signature vs static DH key protected in TEE . So there seems to be some cases where the use of a TEE has some impact on the security even for static DH methods , no ? :-) 
 Another comment which may be beyond the protocol analysis is that the application of the Initiator in general may know what Responder public key it intends to authenticate . This may be a specific public key or public keys certified with a particular trust anchor . If pkA is not in the in the trusted set the Initiator is supposed to discontinue the protocol . 
 Yes ! Sorry about that , it is indeed , we are always looking through the lens of our theoretical models , so it does distort a bit things^^ And as outlined by your point on the security of other instances of the protocol , it is actually a false statement . Coming up with a better sentence here would have been : " In turn , this implies that using a TEE for the long term DH share does not currently have as strong as an impact as it could on the security of the protocol . " Just a side remark on your final point : It kind of depends on what we call authentication in the application . For an application for which authentication is equal to " I have completed successfully an EDHOC exchange " , and if such authentication should trigger a concrete action , then we have a difference . Indeed , the core difference is that in method 0 , both agents will be aware that they established an EDHOC session together , even though the authentication at the application level is broken . In other methods , this may not be the case , and there may be successful EDHOC sessions between agents that are not however of having communicated together . , 
 As is , the session key PRK4x3 m offers much weaker properties than the final exported keys . Reason 1 : session keys do n't have " contributiveness " or " key control " : even if  produces good randomness each time , keys may not be unique ( if  sends low order points or the identity point - see footnote 1 ) . Exported keys fix this by inclusion of transcript , which also gives a better binding to the protocol execution .   : does not authenticate as it is independent of it . If there are ways " to play with " in order to obtain distinct values of on both sides ( we discuss this further below ) , any application key derivation not using and only will break the authentication claim over . As an additional remark , the current construction makes it difficult to identify in cryptographic terms what is the session key of the protocol , as the stored key material at the end is both and . Our suggestion is to follow a design similar to e.g. TLS , and to have a final key derivation , that combines both and into a final key . This has multiple advantages : solve the issues raise before , ensuring contributivity and no key control over the session key , as well as ensuring that the session key is tied to the execution through ; simplify the final state of the protocol , where instead of managing both and , only the final key is stored ; simplify the exporter , as it would only now depend on the session key . To make this proposal a bit more concrete , we provide a first draft of a commit that could implement this solution here : We discuss here some subtle ways that may lead to a breach of authentication for , which could make the authentication very implementation dependent . Those mostly rely on the fact that using inside the transcript instead of the underlying payload may allow the attacker some leeway in changing the concrete value of , thus leading to an initiator and a responder disagreeing on the vlaue of after verification of message 3 . 1 ) According to Appendix B , there appear to exist multiple valid encodings of the same bitstring value . Typically , can be encoded as , or . If that is the case , by converting between those multiple encodings , an attacker can change the value of the that is included inside ( unless the implementation does a COSE decoding to obtain the actual value of the ciphertext , then does a new COSE encoding to put back the value inside the COSE sequence used for ) . 2 ) The standard specifies a way to interface with the COSE encryption , where after computing a object the protected and unprotected fields are dropped to only keep the ciphertext field . This may be error prone on the implementation side : if the full is used inside the implementation instead of the ciphertext field , the message becomes malleable through the unprotected header . 3 ) An encryption scheme based on the  paradigm may only provide integrity of the plaintext , and not integrity of the ciphertext itself . This would lead to two different values of each being a valid ciphertext for the same plaintext . This implies in term of a computational analysis that stronger security assumptions are required to prove the security of the key exchange . ( Disclaimer : I incorrectly claimed that AES - CCM does not provide ciphertext integrity during the ietf 113 presentation , based on the fact that it is a MacThenEncrypt paradigm , but there is actually a proof of ciphertext integrity for CCM ) . 4 ) Related to Issue , where a randomized signature may force a responder to send two distinct ( different randomization ) , we could forward the first copy to I ( while R keeps the second one ) . Both agents would derive the same but not the same . -As a side remark , using the plaintext inside of the ciphertext inside would resolve points 1,2 and 3 ) . 1 ) A low order point over the elliptic curve is a point thus such that with high probability . A particular case is the identity of the group , which is such that always . 
 PR looks very good , also as a starting point for other updates . One comment by the ETH team [ 0 ] was To address this we could replace this : with something like this : Another comment in [ 0 ] : So , for example , this part : could be changed into something like this : We 'll make one of more PRs for this . [ 0 ] 
 For clarity : The four cases of " Breaking TH_4 Authentication " you mention above , they are all mitigated by PR , right ? Just a remark about item 1 : Note that the different representations you list are in the diagnostic notation ( which indeed has multiple ways to notate certain byte strings ) but not the encoding used on the wire , so would e.g. not impact the ciphertext . 
 Yes . By strongly tying together the session key and the transcript in the session key , we then avoid any of those issues about the transcript authentication . diagnostic notation ( which indeed has multiple ways to notate certain byte strings ) but not the encoding used on the wire , so would e.g. not impact the ciphertext . Thanks for the explanation ! 
 More text is needed on PRKOut . What does R know about I and PRKOut after receiveing flight 3 vs. after recieving flight 5 . What does I know about R and PRK_Out after recieving flight 4 .
Mailing list commentary: Dear LAKE WG , We are a team from ETH Zurich working on a computational analysis of EDHOC as a key exchange protocol . We are currently at an early stage of our work , but hope to have some preliminary analysis results in the next two months or so . At this point , we 're reaching out mainly to communicate a few early comments / questions based on our investigations so far . We hope this can clarify potential misunderstandings on our side before we dive deeper into our analysis . Main points : 1 . : In Section 5.4.2 , the draft states that  takes the ciphertext ( of message 2 ) as input instead of the underlying plaintext ; TH4 works similarly . Is there a particular reason for including the ciphertext and not the plaintext ( as done , e.g. , in TLS 1.3 ) ? ( From an analysis perspective , hashing the ciphertext might introduce dependencies on the encryption method . ) 2 . Session Key : It is unclear to us what is considered the " final " session key in EDHOC . PRK4x3 m seems to be the " final " key derived in the main document . As PRK4x3 m is however also used for deriving the encryption keys , MAC keys , OSCORE security context , exported material , etc . , it is not an " independent and random - looking " key anymore by the time EDHOC completes , which would be the computational security guarantee one would ask for in a key exchange . 3 . in KDF : The key schedule uses PRK2e , PRK3e2 m , and PRK-4x3 m as inputs in both Extract and Expand ( depending on the authentication mode ) . Such reuse of key material across is generally not secure . Concretely , in HMAC / KMAC - based derivation , one would need to carefully ensure domain separation between such calls . We point out that TLS 1.3 , for specifically that reason , uses derived secrets ( RFC 8446 , Section 7.1 : keys with label " derived " ) to separate Extract and Expand calls ( cf . [ 1 ] ) . Secondary points : 4 . KDF Usage in KeyUpdate : 1 ) The method takes a nonce to prevent " short cycles " . What exactly is meant by that or the formal reasoning behind this ? 2 ) Since Extract is used here as a PRF , the key ( PRK_4x3 m ) should be the first input , and nonce the second . ( In that context , even a constant nonce would be fine ; hence the question in 1 ) . ) 3 ) To prevent key reuse across primitives , KeyUpdate should use Expand , not Extract . ( see 3 . ) 5 . Key Updates for OSCORE : As currently specified , it seems key updates will not influence the OSCORE security context ( or other applications ) , as it seems such keys are not updated / re - derived . Is that intended ? 6 . Connection Identifiers : The draft states that CIDs have no cryptographic purpose ( Section 3.3 ) , but at the same time that they may be used to identify keys ( Section 2 ) , which sounds like a cryptographic purpose . What are we misunderstanding ? 7 . MAC Length : On page 30 , MAC lengths seem to be depending on the authentication mode ( besides the ciphersuite ) . What is the reason behind changing MAC length based on the mode ? 8 . XOR Encryption for Message 2 : Why is message 2 encrypted via a one - time pad instead of using the AEAD scheme ? While an attacker can of course impersonate the server at this point , an AEAD scheme still protects against manipulations by a so - far passive person - in - the - middle . 9 . Usage of EADs : The security guarantees for EADs are not explicit . They are considered unprotected ; however , they are also passed to security applications . Moreover , the draft states , " the content in an EAD field may impact the security properties provided by EDHOC . " What security guarantees can be affected by the EADs ? We hope these initial comments are helpful and look forward to some clarifications of the questions we have . Kind regards , and [ 1 ]
Paragraph (version A):
Connection identifiers in EDHOC are byte strings or integers, encoded
in CBOR.  One byte connection identifiers (the integers -24 to 23 and
the empty CBOR byte string h'') are realistic in many scenarios as
most constrained devices only have a few connections.  An endpoint
may choose to select only integer or only byte string connection
identifiers.
Paragraph (version A):
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.  Therefore, the Initiator and the Responder MUST NOT select
connection identifiers such that it results in same OSCORE Recipient
ID.  Since the Recipient ID is a byte string and an EDHOC connection
identifier is either a CBOR byte string or a CBOR integer, care must
be taken when selecting the connection identifiers and converting
them to Recipient IDs.  A mapping from EDHOC connection identifier to
OSCORE Recipient ID is specified in edhoc-to-oscore.
Paragraph (version B):
To allow identifiers with minimal overhead on the wire, certain byte
strings are defined to have integer representations.
Paragraph (version B):
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 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 always use the same 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 B):
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):
If the Initiator authenticates with a static Diffie-Hellman key, then
PRK_4x3m = 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_4x3m = PRK_3e2m.
Paragraph (version B):
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 B):
where H() is the EDHOC hash algorithm in the selected cipher suite.
Paragraph (version A):
MAC_3 is derived using the transcript hash TH_3 and the
pseudorandom key PRK_4x3m.
Paragraph (version B):
MAC_3 is derived using the transcript hash TH_3 and the
pseudorandom key PRK_3m.
Paragraph (version A):
where H() is the EDHOC hash algorithm in the selected cipher suite.
Examples of use of the EDHOC-Exporter are given in asym-msg4-proc and
transfer.
Paragraph (version B):
Examples of use of the EDHOC-Exporter are given in asym-msg4-proc and
transfer.
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 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):
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):
C_I - variable length connection identifier.  Note that connection
identifiers are byte strings but certain values are represented as
integers in the message, see bstr-repr.
Paragraph (version B):
G_Y_CIPHERTEXT_2 - the concatenation of G_Y (i.e., the ephemeral
public key of the Responder) and CIPHERTEXT_2.
Paragraph (version B):
C_R - variable length connection identifier.  Note that connection
identifiers are byte strings but certain values are represented as
integers in the message, see bstr-repr.
Paragraph (version A):
Compute MAC_3 = EDHOC-KDF( PRK_4x3m, 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):
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 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 sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_4x3m (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_4x3m and
therefore the Initiator SHOULD NOT permanently store the keying
material PRK_4x3m and TH_4, or derive application keys, until the
Initiator is assured that the Responder has actually computed the key
PRK_4x3m (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):
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 B):
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 A):
After verifying message_3, the Responder is assured that the
Initiator has calculated the key PRK_4x3m (explicit key confirmation)
and that no other party than the Initiator can compute the key.  The
Responder can securely send protected application data and store the
keying material PRK_4x3m and TH_4.
Paragraph (version B):
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_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):
Implementations MUST support 'kid' parameters.  None of the other
COSE header parameters are mandatory-to-implement.
Paragraph (version A):
not compromise other session keys.  Compromise of PRK_4x3m leads to
compromise of all keying material derived with the EDHOC-Exporter
since the last invocation (if any) of the EDHOC-KeyUpdate function.
Paragraph (version B):
not compromise other session keys.  Compromise of PRK_out leads to
compromise of all keying material derived with the EDHOC-Exporter
since the last invocation (if any) of the EDHOC-KeyUpdate function.
Paragraph (version A):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_4x3m (implicit key
authentication).  The Initiator does however not know that the
Responder has actually computed the key PRK_4x3m.  While the
Initiator can securely send protected application data, the Initiator
SHOULD NOT permanently store the keying material PRK_4x3m and TH_4
until the Initiator is assured that the Responder has actually
computed the key PRK_4x3m (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_4x3m (explicit key confirmation) and that no other party
than the Initiator can compute the key.  The Responder can securely
send protected application data and store the keying material
PRK_4x3m and TH_4.
Paragraph (version B):
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):
Information regarding the lengths of ID_CRED_I, ID_CRED_R, EAD_2,
EAD_3, and EAD_4 are leaked to a passive attacker.  Many COSE header
parameters have variable length.  To mitigate an attacker from
differentiating endpoints with identifiers of different length, an
implementation may, e.g., only use fix length identifiers like 'kid'
with one-byte CBOR int representations for the Responders.
Alternatively padding may be used to hide the length of, e.g.,
certificates by value in 'x5chain' or 'c5c'.
Paragraph (version A):
EDHOC itself does not provide countermeasures against Denial-of-
Service attacks.  In particular, by sending a number of new or
replayed message_1 an attacker may cause the Responder to allocate
state, perform cryptographic operations, and amplify messages.  To
mitigate such attacks, an implementation SHOULD rely on lower layer
mechanisms.  For instance, when EDHOC is transferred as an exchange
of CoAP messages, the CoAP server can use the Echo option defined in
I-D.ietf-core-echo-request-tag which forces the CoAP client to
demonstrate reachability at its apparent network address.