Draft: draft-ietf-lake-edhoc

Commentary: Merging this as no new comments appeared . 
 From : Radia Perlman < : Tuesday , 24 January 2023 at 03:49 To : , The IESG , draft - ietf - lake- < draft - ietf - lake- Secdir review of draft - ietf - lake - edhoc-18 I have reviewed this document as part of the security directorate 's ongoing effort to review all IETF documents being processed by the IESG . These comments were written primarily for the benefit of the security area directors . Document editors and WG chairs should treat these comments just like any other last call comments . There are a family of " lightweight " protocols designed for us in " constrained " environments ( think IoT ) that replace other IETF protocols that would be otherwise be used . The constraints may include lack of CPU power , lack of bandwidth , lack of non - volatile memory , and running over a non - IP network . EDHOC ( Ephemeral    over COSE ) specifies a protocol for establishing session keys for use with OSCORE that specifies how to cryptographically protect a session . So you can think of EDHOC as corresponding to IKE while OSCORE corresponds to ESP , or you can think of the pair EDHOC / OSCORE as corresponding to TLS . As you would expect , the protocol is functionally quite similar to both TLS and IKE , and the interesting security discussions would be around the justifications for the differences . The name EDHOC is misleading , since EDHOC supports four authentication variants , only one of which is Ephemeral    . The other three are where one of both endpoints use a static Diffie - Hellman key . TLS 1.3 decided to abandon all such variants because they do not provide forward secrecy , but I suppose it reasonable to revisit that decision in the context of a constrained environment . But I can think of no justification for the misleading name . The working group name ( Lightweight Authenticated Key Exchange - LAKE ) would be a more accurately descriptive name . The authors may be confused about the definition of forward secrecy , since in Security Considerations they say this protocol provides forward secrecy and in Appendix J they refer to a key refresh technique that has some nice security properties but does not provide what is generally regarded as forward secrecy . Other differences : They simplify the protocol compared to TLS by not including the variations allowing restart of a security context based on cached information . While this makes the code to implement the protocol simpler , it hurts performance . The negotiation of cryptographic algorithms is based on suites ( as early versions of TLS did ) rather than a more ala carte approach that TLS has evolved towards . Further , while TLS has a system of initiator proposes and responder chooses cryptographic algorithms , in EDHOC 's system the responder is constrained to choose the most preferred of the initiator 's suites that it supports . Further , the initiator must guess the suite the responder will choose and the protocol may be very " chatty " the first time the protocol is run ( or every time if the initiator does not cache the preferred suite of the responder ) . There would be an extra pair of messages for each suite the initiator prefers over the first one the responder accepts . Whether authentication is going to be based on Ephemeral or Static Diffie - Hellman keys is not negotiated . The initiator is expected to know ( or the protocol gets more chatty ) . Finally , rather than negotiating a symmetric encryption algorithm for use within EDHOC itself , EDHOC generates an extended PRF output which it XORs into messages to encrypt them . In practice , this strikes me as a clever hack to greatly simpify the specification while not substantially hurting performance . But others may disagree . There was a reference to an analysis of the security of the protocol ( which is based on SIGMA ) . I did n't read it , but the design of the protocol looks sound to me . Nits : From Section 1.1 : " This specification emphasizes the possibility to reference rather than to transport credentials in order to reduce message overhead , but the latter is also supported . " -"This specification supports the referencing of credentials in order to reduce message overhead , but credentials may alternatively be embedded . " In Section 3.9 : " incompliance " -"non - compliance " Radia 
 Addressed in 
 Comment from Loïc : I am wondering if the computational independence of the intermediary secret keys has been discussed . I looked among the different issues on the Github repository but did not find any reference to that point . Indeed in his on SIGMA , Krawczyk stresses that the ( intermediary ) authentication keys , encryption keys and the session key must be computationally independent : ( § 5.1 , p. 17 ) “ It is essential for the protocol security that the keys Km [ MAC key ] and Ks [ session key ] be “ computationally independent ” ( namely no information on Ks can be learned from Km and vice - versa ) . ” ( § 5.2 , p. 19 ) “ Ke [ intermediary encryption key ] must be computationally independent from the authentication key Km and the session key Ks ” It happens that this is not always true in EDHOC depending on the authentication mode . The most demonstrative example is with the Sig - Sig mode . PRK2e is used to compute the authentication tag MAC2 . If this key is disclosed , all the intermediary secret parameters ( tags , keys , IVs ) and the session key PRKout can be computed . Using a static DH key to authenticate adds more independence . For example , with the Sig - Stat mode , the disclosure of PRK4e3 m = PRK3e2 m used to compute MAC3 does not allow computing the session key PRKout unless TH4 = H(TH3 , PLAINTEXT3 , CREDI ) is revealed ( and PLAINTEXT3 , IDCREDI are encrypted , as well as PLAINTEXT2 , IDCREDR where TH3 = H(TH2 , PLAINTEXT3 , CREDR ) ) . In addition , this shows that the computational independence does not rely only on the function used to compute the intermediary keys but also on the encryption schemes used to protect PLAINTEXT2 , IDCREDR and PLAINTEXT3 , IDCRED_I. So I wanted to know if this has already been discussed ( and possibly discarded since one way to leverage this lack of independence is to get one these intermediary keys , which may not be trivial in practice ) . 
 This issue was discussed and actually concluded in an email exchange before Christmas but we forgot to update the issue . The conditions on SIGMA listed in this issue does not apply to EDHOC . This is one example of a difference with SIGMA . The security analysis papers of EDHOC listed in Section 8.1 show that the relevant security properties still apply . The clarifications of security properties in PR cover also this issue . 
 Closing this , as is merged .
Paragraph (version A):
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
lightweight authenticated key exchange protocol providing good
security properties including forward secrecy, identity protection,
and cipher suite negotiation.  Authentication can be based on raw
public keys (RPK) or public key certificates and requires the
application to provide input on how to verify that endpoints are
trusted.  This specification emphasizes the possibility of
referencing rather than to transport credentials in order to reduce
message overhead, but the latter is also supported.  EDHOC does not
currently support pre-shared key (PSK) authentication as
authentication with static Diffie-Hellman public keys by reference
produces equally small message sizes but with much simpler key
distribution and identity protection.
Paragraph (version A):
EDHOC makes use of known protocol constructions, such as SIGMA SIGMA
and Extract-and-Expand RFC5869.  EDHOC uses COSE for cryptography and
identification of credentials (including COSE_Key, CBOR Web Token
(CWT), CWT Claims Set (CCS), X.509, and CBOR encoded X.509 (C509)
certificates, see auth-cred).  COSE provides crypto agility and
enables the use of future algorithms and credential types targeting
IoT.
Paragraph (version B):
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
lightweight authenticated key exchange protocol providing good
security properties including forward secrecy, identity protection,
and cipher suite negotiation.  Authentication can be based on raw
public keys (RPK) or public key certificates and requires the
application to provide input on how to verify that endpoints are
trusted.  This specification supports the referencing of credentials
in order to reduce message overhead, but credentials may
alternatively be embedded in the messages.  EDHOC does not currently
support pre-shared key (PSK) authentication as authentication with
static Diffie-Hellman public keys by reference produces equally small
message sizes but with much simpler key distribution and identity
protection.
Paragraph (version B):
EDHOC makes use of known protocol constructions, such as SIGMA SIGMA,
the Noise XX pattern Noise, and Extract-and-Expand RFC5869.  EDHOC
uses COSE for cryptography and identification of credentials
(including COSE_Key, CBOR Web Token (CWT), CWT Claims Set (CCS),
X.509, and CBOR encoded X.509 (C509) certificates, see auth-cred).
COSE provides crypto agility and enables the use of future algorithms
and credential types targeting IoT.
Paragraph (version A):
EDHOC specifies different authentication methods of the ephemeral
Diffie-Hellman key exchange: signature keys and static Diffie-Hellman
keys.  This section outlines the signature key based method.  Further
details of protocol elements and other authentication methods are
provided in the remainder of this document.
Paragraph (version B):
EDHOC specifies different authentication methods of the ephemeral-
ephemeral Diffie-Hellman key exchange: signature keys and static
Diffie-Hellman keys.  This section outlines the signature key based
method.  Further details of protocol elements and other
authentication methods are provided in the remainder of this
document.
Paragraph (version A):
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3
RFC9147, EDHOC authenticated with signature keys is built on a
variant of the SIGMA protocol, SIGMA-I, which provides identity
protection against active attacks on the party initiating the
protocol.  Also like IKEv2, EDHOC implements the MAC-then-Sign
variant of the SIGMA-I protocol shown in fig-sigma.
Paragraph (version B):
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3
RFC9147, EDHOC authenticated with signature keys is built on a
variant of the SIGMA protocol, SIGMA-I, which provides identity
protection against active attacks on the party initiating the
protocol.  Also like IKEv2, EDHOC implements the MAC-then-Sign
variant of the SIGMA-I protocol.  The message flow (excluding an
optional fourth message) is shown in fig-sigma.
Paragraph (version A):
The data item METHOD in message_1 (see asym-msg1-form), is an integer
specifying the authentication method.  EDHOC supports authentication
with signature or static Diffie-Hellman keys, as defined in the four
authentication methods: 0, 1, 2, and 3, see fig-method-types.  When
using a static Diffie-Hellman key the authentication is provided by a
Message Authentication Code (MAC) computed from an ephemeral-static
ECDH shared secret which enables significant reductions in message
sizes.
Paragraph (version B):
The data item METHOD in message_1 (see asym-msg1-form), is an integer
specifying the authentication method.  EDHOC supports authentication
with signature or static Diffie-Hellman keys, as defined in the four
authentication methods: 0, 1, 2, and 3, see fig-method-types.  When
using a static Diffie-Hellman key the authentication is provided by a
Message Authentication Code (MAC) computed from an ephemeral-static
ECDH shared secret which enables significant reductions in message
sizes.  Note that also in the static Diffie-Hellman based
authentication methods there is an ephemeral-ephemeral Diffie-Hellman
key exchange.
Paragraph (version A):
EDHOC inherits its security properties from the theoretical SIGMA-I
protocol SIGMA.  Using the terminology from SIGMA, EDHOC provides
forward secrecy, mutual authentication with aliveness, consistency,
and peer awareness.  As described in SIGMA, message_3 provides peer
awareness to the Responder while message_4 provides peer awareness to
the Initiator.  By including the authentication credentials in the
transcript hash, EDHOC protects against Duplicate Signature Key
Selection (DSKS)-like identity mis-binding attack that the MAC-then-
Sign variant of SIGMA-I is otherwise vulnerable to.
Paragraph (version B):
EDHOC has similar security properties as can be expected from the
theoretical SIGMA-I protocol SIGMA and the Noise XX pattern Noise,
which are similar to methods 0 and 3, respectively.  Proven security
properties are detailed in the security analysis publications
referenced at the end of this section.
Paragraph (version B):
Using the terminology from SIGMA, EDHOC provides forward secrecy,
mutual authentication with aliveness, consistency, and peer
awareness.  As described in SIGMA, message_3 provides peer awareness
to the Responder while message_4 provides peer awareness to the
Initiator.  By including the authentication credentials in the
transcript hash, EDHOC protects against Duplicate Signature Key
Selection (DSKS)-like identity mis-binding attack that the MAC-then-
Sign variant of SIGMA-I is otherwise vulnerable to.