Network Working Group A. Yegin Internet-Draft Samsung Intended status: Standards Track Z. Shelby Expires: April 16, 2012 Sensinode October 14, 2011 CoAP Security Options draft-yegin-coap-security-options-00 Abstract This document specifies a set of Constrained Application Protocol (CoAP) options that are used for providing data origin authentication, integrity and replay protection, and encryption for the CoAP messages. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 16, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Yegin & Shelby Expires April 16, 2012 [Page 1] Internet-Draft CoAP Security Options October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. CryptoInitiate Option . . . . . . . . . . . . . . . . . . . 3 2.2. CryptoTerminate Option . . . . . . . . . . . . . . . . . . 5 2.3. CryptoEncap Option . . . . . . . . . . . . . . . . . . . . 6 2.3.1. AES-CCM (Counter with Cipher Block Chaining Message Authentication Code) . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Yegin & Shelby Expires April 16, 2012 [Page 2] Internet-Draft CoAP Security Options October 2011 1. Introduction The CoAP base specifications identifies DTLS [RFC4347] and IPsec [RFC4303] as two of the methods that can be used for providing data origin authentication, integrity and replay protection, and encryption for the CoAP messages. This document defines an alternative method that operates at the CoAP layer. It is expected that a solution defined within the same layer as the base specification would provide an efficient alternative to DTLS and IPsec in terms of crypto context setup, packet size, and implementation overhead. How the CoAP client and server decide which one(s) of the DTLS, IPsec, and this method to use is outside the scope of this document. Three new CoAP options are defined in this document. The CryptoInitiate Option is used for initializing a crypto context between the two end-points. It is used for setting up the crypto parameters that can be used with the subsequent CoAP messages. The CryptoEncap Option is used for securely delivering the CoAP messages using the crypto context between the end-points. This option can provide either data origin authentication, replay and integrity protection for the whole CoAP message, or encryption for the options and the payload of the message, or both depending on the crypto algorithm used by the crypto context. The CryptoTerminate Option is used for deleting the crypto context that is no longer needed by the end-points. The crypto context is based on a symmetric secret key shared between the end-points. It is assumed that such a key is established a priori. Methods used for establishing such keys are outside the scope of this document. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Details 2.1. CryptoInitiate Option The CryptoInitiate Option (option no. TBD) is a Critical option that is used for setting up a crypto context between the CoAP client and server. Use of this option is not mandatory, as an out-of scope Yegin & Shelby Expires April 16, 2012 [Page 3] Internet-Draft CoAP Security Options October 2011 method may substitute for its functionality. When a CoAP client wants to setup a security context to be used with the CryptoEncap Option, it SHALL send a confirmable request message that includes a CryptoInitiate Option. This message MAY include other options and payload (i.e., piggybacked). The Code field of the message SHALL be set to 0 if no other options or payload are included. The Option Value field of the CryptoInitiate Option contains a Context ID. This is an identifier value assigned to the context by the client. The Context ID space is shared between the client and the server. If an identifier is used for the initialization of a context by one of the end-points, the other end-point SHALL not use the same identifier for initializing another context. If the client re-uses an identifier that is already used with a context that was initialized by the same client, then the new request is used for re- initialization of that context. Otherwise, a new context with the provided identifier is be created. Note that these actions are executed only when the option is considered valid by the server as outlined below. The Key Name parameter in the Option Value field contains an identifier for the shared secret key that will be used in the context. For example, "Device1-Device2-key#5". The CryptoAlgos parameter in the Options Value field contains a list of one or more proposed crypto algorithms supported by the client. For example, AES-CCM, AES-CTR, etc. When the server receives the request, it SHALL check the Option Value fields. If the Context ID is not already used for a context that was initialized by the server, and at least one of the proposed crypto algorithms is supported by the server, and the Key Name is recognized, then the server SHALL send back an acknowledgement message that contains CryptoInitiate Option whose Context ID is copied from the request, CryptoAlgos includes the selected crypto algorithm from the proposed list, and Key Name copied from the request. If at least one of these checks fails, the server SHALL still send back a response with a CryptoInitiate Option. But this time the problematic parameters will include special reserved values to indicate the issue. If the Context ID is already used by the server, then the server's response SHALL carry the value of 0 in the Context ID field. If none of the proposed crypto algorithms are supported by the server, the CryptoAlgos field SHALL contain no algorithms. If the Key Name is not recognized by the server, the Key Name field Yegin & Shelby Expires April 16, 2012 [Page 4] Internet-Draft CoAP Security Options October 2011 SHALL be set to "Unknown!". A client MAY have more than one crypto context with the same server. It MAY negotiate them around the same time, or at different times. Each negotiation SHALL be carried over a dedicated request-response. In other words, there SHALL be at most one CryptoInitiate Option in a CoAP message. The same context MAY be used by the both end-points whenever they are sending request and response messages. On the other hand, each end- point MAY also choose to initialize dedicated contexts to be used for the request-responses initiated by themselves. Option Value field of the CryptoIntiate Option SHALL include the following parameters in the given order: - Context ID: One-octet unsigned integer value. Value 0 is reserved to indicate invalid context ID, values 1-255 are valid. - Key Name Length: One-octet unsigned integer value. Indicates the length of the Key Name field. - Key Name: A non-NULL-terminated string. Value OUnknown!O is reserved for the server to indicate an unknown key name. - CryptoAlgos: Zero or more one-octet unsigned integer values. Value 0, and 2-255 are reserved for future use. Value 1 indicates AES-CCM [NIST_SP800_38C]. Number of crypto algorithms carried in the option is determined by the difference between the option length and the space already consumed by the Context ID, Key Name Length, and Key Name parameters. 2.2. CryptoTerminate Option CryptoTerminate Option (option no. TBD) is a Critical option that is used for deleting a crypto context shared between the CoAP client and server. Use of this option is not mandatory, as an out-of scope method may substitute for its functionality. When a CoAP client wants to delete a security context with a server, it SHALL send a confirmable request message that includes a CryptoTerminate Option. This message MAY include other options and payload (i.e., piggybacked). The Code field of the message SHALL be set to 0 if no other options or payload are included. Option Value field of the CryptoInitiate Option contains a Context ID identifying the context to be deleted. A client SHALL NOT attempt to delete a context that was not initialized by itself. Yegin & Shelby Expires April 16, 2012 [Page 5] Internet-Draft CoAP Security Options October 2011 When the server receives a request carrying a CryptoTerminate Option, it SHALL check the Context ID. If the Context ID carries an identifier value for a context that was initialized by the client, then the server SHALL send an acknowledgment message carrying the exact same Option. Subsequently, the server SHALL delete the crypto context. The server MAY delay the deletion for handling the possibility of re-transmitted requests. If the Context ID does not match any context that was initialized by the client, then the server SHALL send the option with Context ID set to 0. Option Value field of the CryptoTerminate Option SHALL include the following parameter: - Context ID: One-octet unsigned integer value. Value 0 is reserved to indicate invalid context ID, values 1-255 are valid. 2.3. CryptoEncap Option The CryptoEncap Option (option no. TBD) is a Critical option that is used for providing security for the messages carrying this option. It is used with a crypto context that is already initialized by the client. It is up-to the client to decide which CoAP messages would carry this option, and which crypto context is used with it. When this option is used with a request, the server SHALL also use this option and with the same crypto context in its response. An appropriate crypto algorithm SHALL be negotiated for the crypto context whether this option is used for data origin authentication, integrity and replay protection, or for encryption, or both (e.g., AES-CCM). Option Value of a CryptoEncap Option in a request message SHALL start with a Context ID parameter. Client SHALL include the desired crypto contextOs identifier value in this parameter. If the CryptoEncap Option is used for data origin authentication, integrity and replay protection as indicated by the crypto algorithm, then it SHALL also include a Nonce value for freshness and a MAC (Message Authentication Code) value. Client SHALL ensure the same Nonce value is never re-used with the same crypto context. The exact format/content of the Nonce and MAC depends on the crypto algorithm being used. MAC value is computed using the complete CoAP message (including the CryptoEncap Option with its MAC value set to all zeroes), shared secret key associated with the crypto context, and the keyed hashed function indicated by the crypto algorithm. If the CryptoEncap Option is used for encryption as indicated by the crypto algorithm, then it SHALL include OptionCount and EncryptedData Yegin & Shelby Expires April 16, 2012 [Page 6] Internet-Draft CoAP Security Options October 2011 parameters. All other Options and the Payload SHALL be carried in EncryptedData parameter in encrypted form. The algorithm used for encryption is determined by the crypto algorithm. OptionCount indicates the number of Options carried in the EncryptedData. When a server receives a CoAP message that includes a CryptoEncap Option, it SHALL first process this option. Server SHALL silently drop the message if the Context ID is unknown. If a MAC parameter is used as indicated by the crypto algorithm, then the server SHALL compute its own MAC value using the complete CoAP message (including the CryptoEncap Option with its MAC value set to all zeroes), shared secret key associated with the crypto context, and the keyed hashed function indicated by the crypto algorithm. If the computed and received MAC values do not match, then the server SHALL silently drop the message. If an EncryptedData parameter is used as indicated by the crypto algorithm, then the server SHALL decrypt the Options and the Payload using that parameter, the shared secret key associated with the crypto context, and the crypto algorithm. Following these procedures the server SHALL continue processing the CoAP message as usual [I-D.ietf-core-coap]. 2.3.1. AES-CCM (Counter with Cipher Block Chaining Message Authentication Code) When the negotiated crypto algorithm is AES-CCM (code 1), then the CryptoEncap Option is used for data origin authentication, integrity and replay protection, and encryption. The formatting and counter generation function of AES-CCM as specified in Appendix A of [NIST_SP800_38C] is used with the following parameters: n, octet length of Nonce, is 12. t, octet length of MAC, is 16. q, octet length of message length field is 3. When the crypto algorithm is AES-CCM, then the Option Value field in CryptoEncap Option SHALL include the following parameters in the given order: - Context ID: One-octet unsigned integer value. Yegin & Shelby Expires April 16, 2012 [Page 7] Internet-Draft CoAP Security Options October 2011 - Nonce: 12-octet value. - MAC: 16-octet value. - OptionCount: One-octet unsigned integer value. - EncryptedData: Variable-length value. 3. Security Considerations It is possible to use this security methon in conjunction with the others, such as DTLS and IPsec. Future specification can define support for additional crypto algorithms. 4. IANA Considerations The following IANA actions are required by this specification: - Assignment of a standard CoAP Option code TBD for CryptoInitiate Option - Assignment of a standard CoAP Option code TBD for CryptoTerminate Option - Assignment of a standard CoAP Option code TBD for CryptoEncap Option - Creation of crypto algorithm identifier space for CryptoAlgos parameter. - Assignment of an crypto algorithm identifier 1 for AES_CCM. 5. Acknowledgments TBD 6. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-07 (work in progress), July 2011. Yegin & Shelby Expires April 16, 2012 [Page 8] Internet-Draft CoAP Security Options October 2011 [NIST_SP800_38C] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", May 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. Authors' Addresses Alper Yegin Samsung Istanbul Turkey Email: alper.yegin@yegin.org Zach Shelby Sensinode Kidekuja 2 Vuokatti 88600 Finland Email: zach@sensinode.com Yegin & Shelby Expires April 16, 2012 [Page 9]