994(
     [
       / protected / h'a10104' / {
           / alg / 1:4 / HMAC 256//64 /
         } / ,
       / unprotected / {},
       / payload / h'a120a5010202442edb61f92001215820acbee6672a28340a
       ffce41c721901ebd7868231bd1d86e41888a07822214050022f5'
       / COSE_Key g^y / {
          / ephemeral / -1:{
            / kty / 1:2,
            / kid / 2:h'2edb61f9', / kid_y
            / crv / -1:1,
            / x / -2:h'acbee6672a28340affce41c721901ebd7868231bd1d
            86e41888a078222140500',
            / y / -3:true
          } 
        } / ,
       / tag / h'2cc75952a7c6dc7f',
       / recipients / [
         [
           / protected / h'a101381a' / {
               \ alg \ 1:-27 \ ECDH-SS + HKDF-256 \
             } / ,
           / unprotected / {
             / static kid / -3:h'78f67901', / kid_x /
             / kid / 4:h'c150d41c', / kid_s /
             / U nonce / -22:h'66aabbadf938799613ccbf8a7da0a15f13be5b
             43d300aa51fceabc07a731232a'
           },
           / ciphertext / h''
         ]
       ]
     ]
   )

Figure 7: Example of message_2 authenticated with static ECDH keys

The equivalent CBOR encoding is: h’d903e28543a10104a05832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5482cc75952a7c6dc7f818344a101381aa3224478f679010444c150d41c35582066aabbadf938799613ccbf8a7da0a15f13be5b43d300aa51fceabc07a731232a40’, which has a size of 126 bytes.

4.5. Key Derivation

The client and server SHALL derive “traffic_secret_0” from the information available through the key exchange, as described in this section. The key derivation is identical to Section 7 of [I-D.ietf-tls-tls13], using the ECDHE operational mode and HKDF [RFC5869] with SHA-256:

• The Static Secret (SS) and the Ephemeral Secret (ES) SHALL be the ECDH shared secret, generated from the ephemeral keys, as specified in section 7.3.3. of [I-D.ietf-tls-tls13]
• The generic string “TLS 1.3, “ in HkdfLabel (Section 7.1) SHALL be replaced by “EDHOC, “
• The handshake_hash is replaced by the exchange_hash = SHA-256(message_1 + message_2), where ‘+’ denotes concatenation of octet strings

The procedure for deriving “traffic_secret_0” in Section 7 in [I-D.ietf-tls-tls13] SHALL be followed. The “traffic_secret_0” SHALL be identified with the value of the ‘kid’ field of the server’s ephemeral public key (kid_y).

Appendix C provides an example of how to derive a security context from “traffic_secret_0”.

TODO: Align key derivation with that used with ECDH-SS.

5. Security Considerations

After the key derivation is completed, the intermediate computed values should be securely deleted, along with any ephemeral ECDH secrets.

The choice of key length used in the different algorithms needs to be harmonized, e.g. the size of PSK and the length of the Client/Server Write Key.

message_1 may be replayed and cause unnecessary resource consumption for the server. A limited mitigation can be provided by caching (the hash of) the received ephemeral keys, and compare the ephemeral keys of a new request with this cache.

With the current protocol, key confirmation of the Diffie-Hellman shared secret/traffic keys is performed when the keys are successfully used. One extension of the protocol is to add key confirmation by the server, so that a client detecting a failed key confirmation can initiate a new key exchange. This may be accomplished by including a counter-MAC in the second message of the key exchange, where the key used in the MAC is derived from the traffic keys. Since the calculation of the traffic keys include the hash of the key exchange messages, the counter-MAC must be excluded from the exchange_hash.

6. Privacy Considerations

TBD

7. IANA Considerations

8. Acknowledgments

The authors wish to thank Ludwig Seitz for timely review and helpful comments.

9. References

9.1. Normative References

[I-D.ietf-cose-msg]	Schaad, J., "CBOR Encoded Message Syntax", Internet-Draft draft-ietf-cose-msg-10, February 2016.
[I-D.ietf-tls-tls13]	Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-11, December 2015.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

9.2. Informative References

[I-D.hartke-core-e2e-security-reqs]	Selander, G., Palombini, F., Hartke, K. and L. Seitz, "Requirements for CoAP End-To-End Security", Internet-Draft draft-hartke-core-e2e-security-reqs-00, March 2016.
[I-D.ietf-ace-oauth-authz]	Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S. and H. Tschofenig, "Authorization for the Internet of Things using OAuth 2.0", Internet-Draft draft-ietf-ace-oauth-authz-01, February 2016.
[I-D.ietf-oauth-pop-key-distribution]	Bradley, J., Hunt, P., Jones, M. and H. Tschofenig, "OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution", Internet-Draft draft-ietf-oauth-pop-key-distribution-02, October 2015.
[I-D.selander-ace-object-security]	Selander, G., Mattsson, J., Palombini, F. and L. Seitz, "Object Security of CoAP (OSCOAP)", Internet-Draft draft-selander-ace-object-security-03, October 2015.
[I-D.wahlstroem-ace-cbor-web-token]	Wahlstroem, E., Jones, M. and H. Tschofenig, "CBOR Web Token (CWT)", Internet-Draft draft-wahlstroem-ace-cbor-web-token-00, December 2015.
[RFC4492]	Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C. and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006.
[RFC5869]	Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010.
[RFC7228]	Bormann, C., Ersue, M. and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014.
[RFC7252]	Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014.
[RFC7519]	Jones, M., Bradley, J. and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015.

Appendix A. Implementing EDHOC with CoAP

The DH key exchange specified in this document can be implemented as a CoAP [RFC7252] message exchange. A strawman is sketched here.

The client makes the following request:

• The request method is POST
• Content-Format is “application/cose+cbor”
• The Uri-Path is “edhoc”
• The Payload is message_1

The server performs the verifications of the COSE object as specified in [I-D.ietf-cose-msg]. If successful, then the server provides the following response:

• The response Code is 2.04 (Changed)
• The Payload is message_2

Appendix B. Integrating EDHOC with ACE

A pre-requisite for using the DH key exchange protocols in Section 3 and Section 4 of this document is that some static keys are pre-established in client and server. The ACE framework [I-D.ietf-ace-oauth-authz] specifies how an authorization server (AS) supports the establishment of keys in client and (resource) server, either a shared secret key or each others’ public keys, which is exactly what is required in Section 3 and Section 4, respectively.

The ACE protocol specifies a client making a ‘token request’ to the AS to retrieve an access token (JWT [RFC7519], or CWT [I-D.wahlstroem-ace-cbor-web-token]) containing authorization information about the client regarding a certain resource on a certain server. The client can then transfer the access token to the server in the CoAP payload of the following request:

POST /authz-info

The access token may also contain a shared secret key or the public key of the client, for use by the server.

In case of symmetric keys, the AS generates this key and protects it for the client and server, after which the protocol in Section 3 can start.

In case of asymmetric keys, the ACE framework allows the client to include its public key in the ‘token request’, which results in the key being included in the access token reaching the server. The server’s public key can be assumed to be known to the AS, which can therefore provide also this information to the client in the response to the token request.

Since the protocol in Section 4 requires static ECDH keys from the same curve, information about the curve to use must be available to the client before making the request to the AS. There are different candidate sources for this information, for example: the server, a resource directory or the AS itself. As an example of the latter, the AS could, for example, reject a token request for a server with a public key in the wrong curve and provide information about the right curve in the response. The client could then generate a new static ECDH key pair in the right curve, include the public key in a new request to the AS, for inclusion in the access token delivered to the server.

The transfer of the access token as defined in [I-D.ietf-ace-oauth-authz] can be combined with the execution of EDHOC, for example, by including the access token in the Unprotected of Header of message_1. A dedicated resource could be defined for this combined message exchange, for example:

POST /authz-info-edhoc

The strawman in Appendix A applies also to this case.

Appendix C. Deriving Security Context for OSCOAP

In this section we show how to establish security context for OSCOAP [I-D.selander-ace-object-security], using the method specified in this document.

We assume that “traffic_secret_0” has been established, e.g. as described in Appendix B using a DH key exchange specified in this document. OSCOAP requires traffic keying material Client/Server Write Key/IV to be established at client and server, see section 3 of [I-D.selander-ace-object-security]. The computation of keying material mimics the traffic key calculation of Section 7.3 in TLS 1.3 [I-D.ietf-tls-tls13] using HKDF with SHA-256 and the following parameters:

• Secret = traffic_secret_0
• phase = “application data key expansion”
• purpose = “client write key” / “server write key” / “client write IV” / “server write IV”
• handshake_context = message_1 + message_2, the concatenation of the exchanged messages
• key_length for key and IV is algorithm specific.

The first three bullets are identical to TLS 1.3.

With the mandatory OSCOAP algorithm AES-CCM-64-64-128 (see Section 10.2 in [I-D.ietf-cose-msg]), key_length for the keys is 128 bits and key_length for the static IVs is 56 bits.

The Context Identifier (Cid) is set to the key identifier of traffic_secret_0 (i.e. kid_y, using the terminology of Section 3 and Section 4).

Authors' Addresses