CoRE L. Wang Internet-Draft W. Wang Intended status: Informational BUPT Expires: April 15, 2013 L. Zhu F. Yu Huawei Technologies October 12, 2012 CoAP Option Extensions: Profile and Sec-flag draft-wang-core-profile-secflag-options-02 Abstract This memo adds two Options for the Constrained Application Protocol (CoAP): Profile and Sec-flag. The Profile Option is indicating the identification of an application using CoAP. The Sec-flag Option complements the security considerations of CoAP. 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 15, 2013. Copyright Notice Copyright (c) 2012 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 Wang, et al. Expires April 15, 2013 [Page 1] Internet-Draft CoAP Profile and Sec-flag Options October 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Profile Option Extension . . . . . . . . . . . . . . . . . 3 2.2. Sec-flag Option Extension . . . . . . . . . . . . . . . . 4 3. Profile Option . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Profile Option Definition . . . . . . . . . . . . . . . . 5 3.1.1. Option Value Length . . . . . . . . . . . . . . . . . 5 3.2. Using the Profile Option . . . . . . . . . . . . . . . . . 6 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Sec-flag Option . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Security Negotiation . . . . . . . . . . . . . . . . . . . 7 4.2. Using the Sec-flag Option in data transport . . . . . . . 9 4.3. Sec-flag Option Definition . . . . . . . . . . . . . . . . 10 4.4. System Overview . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Wang, et al. Expires April 15, 2013 [Page 2] Internet-Draft CoAP Profile and Sec-flag Options October 2012 1. Introduction CoAP is a specialized web transfer protocol for machine-to-machine applications such as smart energy and building automation using with constrained nodes and networks. This memo adds two new options for CoAP: Profile and Sec-flag. The main purpose of the Profile Option is indicating the identification of an application using CoAP, by reading this option some intermediaries (e.g. proxy) and transport networks could distinguish different applications and do some differentiated processing. The Sec-flag Option complements the security considerations, enabling NoSec pattern in a segment of the communication path between the client and server, by taking care of establishing and maintaining lower layer security instead of DTLS in these intermediate networks. 1.1. Terminology 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. Motivations CoAP is a light-weight web protocol and can be used in constrained devices, fulfilling machine-to-machine requirements. Because of its features, more and more M2M applications MAY adopt CoAP. 2.1. Profile Option Extension CoAP applications SHOULD use an operator's network as the transport bearer. Different machine-to-machine applications MAY have different Quality of Service (QoS) requirements in terms of required bit rates as well as acceptable packet delays and packet loss rates. When application data is transmitted through the transport network, the network MAY need to identify different machine-to-machine services to do some differentiated processing, applying different control policies with subscriptions. Before applying control policies to applications, transport networks SHOULD identify them and distinguish each one from another referring to application identification, and then networks MAY apply different policies to different applications. Some intermediaries (e.g.CoAP proxy) MAY also would like to distinguish different applications and do some differentiated processing such as caching and forwarding application data in different priorities. Wang, et al. Expires April 15, 2013 [Page 3] Internet-Draft CoAP Profile and Sec-flag Options October 2012 This memo describes the extensions to CoAP and is to provide expanding proposal(s) to fulfill the motivations and requirements, defining an additional Option for the Constrained Application Protocol (CoAP): Profile. The Profile Option is defined as the identification of CoAP applications. When CoAP messages are transmitted through the transport network, network entities MAY use some technologies to read the Option Value to identify the application, and then apply control policies with the subscription of application owner. 2.2. Sec-flag Option Extension The transmission path between the client and server MAY consist of some segments: Network domain based on existing standards 3GPP, TISPAN, IETF, etc., and M2M Device and Gateway Domain based on existing standards and technologies like DLMS, CEN, CENELEC,PLT, Zigbee, M-BUS, KNX, etc. The application data MAY be transmitted through different networks between the client and server. The basic CoAP protocol defines the DTLS binding. DTLS would add a per-datagram overhead and some initialization vectors. For some constrained networks and nodes, this is really expensive. And intermediate network domain MAY have some independent and reliable security standards (e.g. ZigBee standard). In some cases, CoAP could use these security standards instead of DTLS to avoid DTLS overhead in some intermediate networks.In these network domains DTLS may be disabled but be retained in other domains. As an example, the ZigBee standard for sensor networks defines a security architecture based on an online trust center and uses CCM* model to secure applications. This standard can fulfill the security requirements of CoAP. That is to say, CoAP applications could be secured by lower layer security, so in this network DTLS could be disabled to avoid DTLS datagram overhead. We just mark a security flag to indicate that CoAP data is secured by lower layer instead in this network domain and the overhead would be much less. And in the Transport Network domain we still establish DTLS security. Thus we MAY enable two different security patterns described in [I-D.ietf-core-coap] in different segments between the client and server. The Sec-flag Option can be used to indicate the security information and ensure the integrality of the security mechanism. 3. Profile Option Wang, et al. Expires April 15, 2013 [Page 4] Internet-Draft CoAP Profile and Sec-flag Options October 2012 3.1. Profile Option Definition +-----+----------+--------+-------------+---------+---------+ | No. | C/E | Name | Format | Length | Default | +-----+----------+--------+-------------+---------+---------+ | 2n | Elective |Profile |(see below) | 4B | (none) | +-----+----------+--------+-------------+---------+---------+ The Profile Option indicates the identification of CoAP applications. Transport network entities MAY use some technologies to read the Option Value and then apply corresponding treatment. This option is "elective" and the Option Number is even. It MUST NOT occur more than once. The detailed definitions and encoding SHOULD refer to the description of Option Format in [I-D.ietf-core-coap]. It is RECOMMENDED that the Option Value consists of Enterprise Number, Application ID and Priority. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | Application ID |Pri| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Option Value Format As shown in Figure 1, Enterprise Number is the register number of application owners (e.g. traffic management agencies) in network operators. Application ID is the identification of the owner's application which subscribes transport and communication services from operators. Priority (Pri) indicates the priority of application data, data of the same application MAY has different priority (For some cost reasons, application owners MAY subscribe low priority for some application data). The SDNV[RFC5050] encoding can be used. We can distinguish different applications with a combination of Enterprise Number, Application ID and Priority. 3.1.1. Option Value Length In actual usages, the number of CoAP application owners MAY be out of length range indicated by 2 bytes, the default length cannot fulfill requirements. Hence, we can define another Option Value Length: 5bytes. Wang, et al. Expires April 15, 2013 [Page 5] Internet-Draft CoAP Profile and Sec-flag Options October 2012 In the initialization phase of CoAP message, the Option Value Length SHOULD be determined. 3.2. Using the Profile Option The semantics of Option Value are defined by prior agreement between the application owners and network operators. Some encryption algorithms MAY be used. Network entities MAY also apply some validation policies when reading the Option Value. CoAP application owners MAY realize functions through a M2M communication for some purposes (e.g. Meter readings) at their customer's premises. The Profile Option can be contained in the application message to indicate the identity. When CoAP messages across transport network, network entities MAY use some technologies such as Deep Packet Inspection (DPI) to read the Profile Option Value and report it to policy control decision function entities. And then policy control decision function entities determine the policies applied to CoAP data as well as establishing dedicated bearers. 3.3. Example In some M2M environments, the nodes access to Internet through 3GPP network. This example (Figure 2) shows that mobile network is the bearer between two M2M end-points. These end-points MAY belong to an electric power company and this M2M application is a meter reading service. The profile option value of this application is 0x12111111. +------+ CoAP-REQ +----------+ CoAP-REQ +------+ | | --------> | MOBILE | -------> | | | A | | | | B | | | <-------- | NETWORK | <------- | | +------+ CoAP-RES +----------+ CoAP-RES +------+ Figure 2 An example The message flow is shown in Figure 3. At first the requester (server) sends a request which MAY be a device trigger that makes end devices return electricity records. The number of end devices is numerous and this triggering MAY happen in a preset period of time. All devices return their records at the approximately same time, and the data transmission volume is huge. Hence it is expected that the network SHOULD offer QoS guarantee (such as high bandwidth and Wang, et al. Expires April 15, 2013 [Page 6] Internet-Draft CoAP Profile and Sec-flag Options October 2012 throughput) for the M2M application. The requester SHOULD initial the Profile Option when sending a request. Network entities can read the Option Value and know that the application is a meter reading service belonging to a certain electricity company. And then specialized policies MUST be applied. The Profile option value MUST be echoed in the messages from recipients. When the M2M application data comes into the network, network entities MUST provide corresponding policy control with subscriptions and MAY also establish dedicated bearers assign dedicated network resources to ensure the quality of transport and communication if necessary. Requester Recipient | | | | +-------->| Header: GET (T=CON, Code=1, MID=0x7d38) | GET | Token: 0x53 | | Profile:0x12111111 | | Uri-Path: "electricity" | | | | |<--------+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) | 2.05 | Token: 0x53 | | Profile:0x12111111 | | Payload: "25" | | | | Figure 3 Profile Option in CoAP messages 4. Sec-flag Option The Sec-flag Option complements the security considerations, enabling NoSec pattern in one or more segments of the communication path between the client and server. 4.1. Security Negotiation Before establishing a security session between endpoints, the negotiation SHOULD be made. As shown in Figure 4, the basic model includes three actors: a client, a proxy and a server. Wang, et al. Expires April 15, 2013 [Page 7] Internet-Draft CoAP Profile and Sec-flag Options October 2012 Client Proxy Server | | | | Hello | | +---------------------->| | | | | | Set the Sec-flag Option | | | | | | Hello | | +---------------------->| | | | | | verify | | | | | Hello-verify | | |<----------------------+ | | | | Hello-verify | | |<----------------------+ | | | | | | | Figure 4 Basic model (1) Lower security can secure CoAP application data At first, the client sends to the server a hello message in which the Sec-flag Option with an empty value is included. The proxy is requested to forward the request or serve it, and return the response. If the network domain between the client and proxy could guarantee the lower layer security, the proxy SHOULD set the Sec-flag Option with a valid value and transfer the hello message to the server. When the server receives the message, it MUST respond with a server hello-verify message. A response with the same valid option value as the value set in the proxy SHOULD be returned only if the server trusts the lower layer security between the client and proxy. If the server accepts the lower layer security, DTLS would be disabled between the client and proxy and then the proxy SHOULD make a DTLS handshake with the server to make up a DTLS security session. Otherwise, the DTLS handshake SHOULD be made between the client and server, that would be introduced in the following. (2) Lower security cannot secure CoAP application data When the server receives the Hello message, if the server does not trust the lower layer security between the client and proxy, the server would respond a hello-verify message containing an empty Wang, et al. Expires April 15, 2013 [Page 8] Internet-Draft CoAP Profile and Sec-flag Options October 2012 Security option and an error code. Then the client would send DTLS handshake messages to the server and establish DTLS between the client and the server. (3) There is no lower security between the client and M2M Gateway Client Proxy | | | Hello | +----------------------->| | | | | | | | | | | | | | | | Error Message | |<-----------------------+ | | | | Figure 5 There is no lower security in the Device and Gateway Domain If the network domain between the client and proxy could not guarantee lower layer security, the proxy SHOULD return an appropriate error response code with an empty Security Option as shown in Figure 5. Then the client would send DTLS handshake messages to the server and establish DTLS between the client and the server. In all the situations, the client and the proxy also need initialize lower security mechanism, which MAY happen either before the Security Option negotiation or after it. 4.2. Using the Sec-flag Option in data transport When the security negotiation is completed, a security session is established between the client and server. The Sec-flag Option MUST be included in messages sent by the client and the value SHOULD be empty. When the proxy receives the message, it MUST set the Sec-flag Option with a valid value and transfer the message to the server. The Sec-flag Option indicates that the message comes from a reliable network domain and the server could trust it. And then the server would respond the request. The same Sec-flag Option SHOULD be echoed in the response. When the response Wang, et al. Expires April 15, 2013 [Page 9] Internet-Draft CoAP Profile and Sec-flag Options October 2012 comes to the proxy, the proxy reads the option and knows that the message SHOULD be secured by lower layer security. 4.3. Sec-flag Option Definition +-----+----------+--------+-------------+---------+---------+ | No. | C/E | Name | Format | Length | Default | +-----+----------+--------+-------------+---------+---------+ | 2n+1| Critical |Sec-flag|(see below) | 1B | (empty) | +-----+----------+--------+-------------+---------+---------+ The Sec-flag Option is used for indicating the lower layer security. This option is "critical" and the Option Number is odd. The detailed definitions and encoding SHOULD refer to the description of Option Format in [I-D.ietf-core-coap]. The value is made up of security indication. The SDNV[RFC5050] encoding can be used. 4.4. System Overview +--------+ +---------+ +--------+ | | | | | | | | | | | | | | +---------+ | M2M | +---------+ | | | CLIENT |--->| ZIGBEE |--->| GATEWAY |--->| 3GPP |--->| SERVER | | |<---| NETWORK |<---| |<---| NETWORK |<---| | | | +---------+ | | +---------+ | | | | | | | | | | | | | | +--------+ +---------+ +--------+ Figure 6 System overview of a usage scenario As shown in Figure 6, the nodes access to Internet through 3GPP network. DTLS is enabled between M2M Gateway and application server, and in Zigbee network DTLS is disabled and lower layer security secures CoAP applications. M2M Gateway, working as a "marker", sets the Sec-flag option to show that the data from Zigbee network domain is secured and reliable in the uplink and indicate that the data need low layer security and DTLS SHOULD be disabled in the Zigbee network domain in the downlink. As the intermediate gateway, M2M Gateway needs to transfer the data to each network and adapt the security standard to the other one. M2M Gateway also needs to check the Wang, et al. Expires April 15, 2013 [Page 10] Internet-Draft CoAP Profile and Sec-flag Options October 2012 message. When a message from the end devices is received, the gateway checks whether the Sec-flag option is set by the end devices illegally (the default value SHOULD be empty). If the Sec-flag option is not empty, the gateway SHOULD drop it, else the gateway SHOULD set the valid value and transfer the message. 5. Security Considerations To be defined. 6. IANA Considerations The following entries are added to the CoAP Option Numbers registry: +---------+----------+-------------+ | Number | Name | Reference | +---------+----------+-------------+ | 2n | Profile | RFC XXXX | +---------+----------+-------------+ | 2n+1 | Sec-flag | RFC XXXX | +---------+----------+-------------+ 7. References 7.1. Normative Reference [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-12 (work in progress), October 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. 7.2. Informative References [I-D.fossati-core-publish-monitor-options] Fossati, T., Giacomin, P., and S. Loreto, "Publish and Monitor Options for CoAP", draft-fossati-core-publish-monitor-options-01 (work in progress), March 2012. Wang, et al. Expires April 15, 2013 [Page 11] Internet-Draft CoAP Profile and Sec-flag Options October 2012 Authors' Addresses Lei Wang Beijing University of Posts and Telecommunications Xitucheng road 10 Haidian District, Beijing 100876 P. R. China Email: wleiblue@163.com Wendong Wang Beijing University of Posts and Telecommunications Xitucheng road 10 Haidian District, Beijing 100876 P. R. China Email: wdwang@bupt.edu.cn Lei Zhu Huawei Technologies Huawei Building, Q20 No.156 Beiqing Rd.Z-park Haidian District, Beijing 100095 P. R. China Email: lei.zhu@huawei.com Fang Yu Huawei Technologies Huawei Building, Q20 No.156 Beiqing Rd.Z-park Haidian District, Beijing 100095 P. R. China Email: grace.yufang@huawei.com Wang, et al. Expires April 15, 2013 [Page 12]