Change:
Issue
Minor comment, but reading through all the security claims, they multiple times refer to the term (for instance in ), which is not per say completely defined. I am not even sure there is any ambiguity, but is it still worth adding somewhere that this relates to ?
Yes, I assume session key most often refer to PRK_out. Could maybe refer to the exported application keys in some sentence. Let's go through all instances and make it clear what it refers to.

Discussion:
The parties exchanging messages are called Initiator (I) and Responder (R).  They exchange ephemeral public keys, compute a shared <del> secret key PRK_out, and derive symmetric application keys used to protect application data. </del> <ins> secret session key PRK_out, and derive symmetric application keys used to protect application data. </ins> G_X and G_Y are the ECDH ephemeral public keys of I and R, respectively.

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 <del> shared secret key resulting from a successful EDHOC exchange. </del> <ins> shared secret session key resulting from a successful EDHOC exchange. </ins> Extract is used to derive fixed-length uniformly pseudorandom keys (PRK) from ECDH shared secrets.  Expand is used to define EDHOC-KDF

4.1.3. The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is <del> the output of a successful EDHOC exchange.  Keys for applications are derived from PRK_out, see exporter.  For the purpose of using EDHOC- Exporter, an application only needs to store PRK_out or PRK_exporter. (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </del> <ins> the output session key of a successful EDHOC exchange.  Keys for applications are derived from PRK_out, see exporter.  For the purpose of using EDHOC-Exporter, an application only needs to store PRK_out or PRK_exporter.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </ins> 4.2.

ephemeral Diffie-Hellman and provides a key update function (see keyupdate) for lightweight application protocol rekeying.  Either of these provide forward secrecy, in the sense that compromise of the <del> private authentication keys does not compromise past session keys, and compromise of a session key does not compromise past session keys.  Frequently re-running EDHOC with ephemeral Diffie-Hellman forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, </del> <ins> private authentication keys does not compromise past session keys (PRK_out), and compromise of a session key does not compromise past session keys.  Frequently re-running EDHOC with ephemeral Diffie- Hellman forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, </ins> which is a significant complication. To limit the effect of breaches, it is important to limit the use of

with other parties but does not let the attacker impersonate other parties in EDHOC exchanges with the compromised party.  Compromise of the long-term keys does not enable a passive attacker to compromise <del> future session keys.  Compromise of the HDKF input parameters (ECDH shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to compromise of all keying material derived with the EDHOC-Exporter. </del> <ins> future session keys (PRK_out).  Compromise of the HDKF input parameters (ECDH shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to compromise of all keying material derived with the EDHOC-Exporter. </ins> Based on the cryptographic algorithms requirements sec_algs, EDHOC provides a minimum of 64-bit security against online brute force