idnits 2.17.1 draft-garcia-core-app-layer-sec-with-dtls-record-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 6, 2016) is 2688 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC7252' is defined on line 303, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-bhattacharyya-dice-less-on-coap-00 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-00 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group D. Garcia 3 Internet-Draft S. Matheu 4 Intended status: Experimental R. Marin 5 Expires: June 9, 2017 University of Murcia 6 December 6, 2016 8 Application Layer Security for CoAP using the (D)TLS Record Layer 9 draft-garcia-core-app-layer-sec-with-dtls-record-00 11 Abstract 13 This document briefly describes an idea to provide Application-Layer 14 Security for CoAP using (D)TLS Record Layer, assuming it is operative 15 in two CoAP endpoints. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 9, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Application Layer Security for CoAP with (D)TLS Record 54 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.1. CoAP Fields to protect . . . . . . . . . . . . . . . . . 3 56 3. Processing a CoAP message with the (D)TLS Record . . . . . . 3 57 4. Bootstrapping the (D)TLS Record Layer for Application 58 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 Secure communications in constrained scenarios is subject of current 66 interest since the restrictions in those kinds of networks motivates 67 rethinking the solutions that up to now have been used in networks 68 that do not suffer from very stringent requirements. (D)TLS 69 [RFC6347][RFC5246] is a standard proposed to secure the 70 communications of CoAP and suitable for end-to-end communications 71 unless a CoAP proxy participates in the communication. To overcome 72 this problem [I-D.ietf-core-object-security] propose Object Security 73 for CoAP (OSCOAP) to allow end-to-end security between two CoAP 74 endpoints in case of a CoAP proxy intermediating between them. 76 In this document we explore that possibility of providing CoAP 77 security at application layer, assuming a (D)TLS Record Layer is 78 operative (i.e. have the required keys) in both CoAP endpoints. One 79 possibility to "activate" the (D)TLS Record Layer is running (D)TLS 80 handshake over CoAP, as mentioned in CoDTLS 81 [I-D.schmertmann-dice-codtls]. Other (more challenging) options are 82 discussed in [I-D.bhattacharyya-dice-less-on-coap] 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. Application Layer Security for CoAP with (D)TLS Record Protocol 92 To achieve application layer security using the (D)TLS Record, we 93 assume the (D)TLS [RFC6347] [RFC5246] Record layer is already 94 activated, using a protocol such as CoDTLS 95 [I-D.schmertmann-dice-codtls]. Once we have the (D)TLS Record Layer 96 active, the next step is to define how the CoAP message will be 97 secured end-to-end using the (D)TLS Record Layer. 99 The entire CoAP message generated by a CoAP sender will need to 100 arrive to the CoAP recipient, achieving integrity and confidentiality 101 for certain parts of the CoAP message (specific CoAP options and 102 payload) excluding the options CoAP intermediaries (proxies) will 103 need to understand to process the CoAP message correctly. The CoAP 104 header would need to arrive maintaining the semantics and version of 105 the protocol. 107 2.1. CoAP Fields to protect 109 Here we discuss how the CoAP message is going to be processed to 110 achieve application layer security. How each part of the CoAP 111 message (Header, Options and Payload) is treated and which options 112 are protected an which ones are left unprotected using the (D)TLS 113 Record Layer. Following the procedure specified in OSCOAP 114 [I-D.ietf-core-object-security], we protect all options that are 115 intended to be read by the CoAP recipient. 117 o CoAP Header: version and code are protected. 119 o CoAP Options: All the options that can be modified by the proxy 120 are left unprotected. All options that are intended for the the 121 CoAP recipient are protected. There might be the case there an 122 option is both left unprotected for the proxy to process and is 123 also intended for the CoAP recipient to see. 125 o CoAP Payload: The payload is always protected. 127 Similarly to OSCON [I-D.ietf-core-object-security], it would be 128 possible to only encrypt the payload of the original CoAP message. 130 3. Processing a CoAP message with the (D)TLS Record 132 In this section we analyze how the CoAP message is processed and 133 protected using the (D)TLS Record. In Figure 1 we can see how from 134 the Original CoAP Header we obtain the fields that have to be 135 protected (Version and Code) in 2 bytes. We get the Version and the 136 Code. We will have a padding of 6 bits, then the version and code 137 all in 2 bytes. 139 3 140 0 ..................................1 141 Original +-----+---+-----+------+------------+ 142 CoAP | Ver | T | TKL | Code | Message ID | 143 Header +-----+---+-----+------+------------+ 145 1 1 1 1 1 1 146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 147 Protected +-----------+---+-------------+ 148 CoAP Header |0 0 0 0 0 0|Ver| Code | 149 (P. Header) +-----------+---+-------------+ 151 Figure 1: Protected Header Fields 153 This "denatured" CoAP header is concatenated with the CoAP options to 154 be protected and the Payload (if any) of the Original CoAP message 155 (see Figure 2). This array of bytes is sent to the (D)TLS Record 156 Layer to be processed. The resulting information is a protected 157 array of bytes with a (D)TLS Record Header which will process it 158 generating the (D)TLS Record (adding the (D)TLS Record Header). 159 After that, we add the (D)TLS record to the payload of the message to 160 be sent, that will contain the original CoAP Header and only the 161 options available for the proxies. The Protected CoAP message is 162 formed by the Original CoAP Message Header, the Options that are not 163 considered to be protected with this mechanism, then the marker 0xFF 164 and finally the Payload that contains the (D)TLS Record. 166 Original CoAP Message 168 +-----------------------------------------+ 169 |Header| Options |FF| Payload | 170 +-----------------------------------------+ 171 | 172 CoAP Content | 173 to protect v 175 +--------------------+-----------------+ 176 | P. |Options to be| | | 177 |Header| Protected |FF| Payload | 178 +--------------------------------------+ 179 | 180 v 181 ------------------------ 182 ( (D)TLS Record Layer ) 183 ------------------------ 184 | 185 v 186 DTLS Record 187 +-------------+--------------------------+ 188 |(D)TLS Record| CoAP Content* | 189 | Header | to protect | 190 +-------------+--------------------------+ 191 | 192 | 193 Protected v 194 CoAP Message 196 +--------+-----------+----+-----------------+ 197 | |Unprotected| | | 198 | Header | Options | FF | (D)TLS Record | 199 +--------+-----------+----+-----------------+ 201 * (Ciphered and Integrity protected) 203 Figure 2: Processing CoAP message 205 Upon reception, the CoAP recipient will get the CoAP Payload of the 206 Protected Message and send it to the (D)TLS Record Layer to obtain 207 the Protected Header and the list of options within the (D)TLS 208 Record. With this information, once it is verified correctly, the 209 CoAP recipient constructs the Original CoAP Message. 211 4. Bootstrapping the (D)TLS Record Layer for Application Security 213 To enable this solution, the (D)TLS Record Layer in both CoAP 214 endpoints must have a connection to process this information. One 215 alternative is running (D)TLS over CoAP as specified in 216 [I-D.schmertmann-dice-codtls]. However, we consider that it would be 217 possible to define we define a separation between the (D)TLS 218 Handshake and the (D)TLS Record Layer with an interface to be 219 standarized. The (D)TLS Handshake is used to negotiate the 220 parameters to establish a Security Association (SA) in (D)TLS Record 221 Layer. With this interface, we argue that this SA can be set by the 222 (D)TLS Handshake or any other Key Management Protocol (KMP), as we 223 show in Figure 3. This would be similar to the separation in the 224 IPsec architecture [RFC4301], where IKEv2 [RFC7296] is just one of 225 the possible Key Management Protocol to establish IPsec SAs. In 226 fact, IPsec defines a standard API (PFKEY_v2 [RFC2367])) for this 227 purpose. 229 An example of this separation has been proposed in 230 [I-D.bhattacharyya-dice-less-on-coap]. Another way to benefit from 231 this separation could be that one of the CoAP endpoint has a token 232 (e.g. Kerberos ticket, and ACE token, etc...), with the key material 233 and information (cryptographic keys, algorithms) to start the (D)TLS 234 Record Layer, just presenting the ticket, without the need of running 235 the (D)TLS handshake. 237 +------------------+-------+-------+--------+ 238 | | | | | 239 | (D)TLS Handshake | KMP 1 | KMP 2 | KMP i | 240 | | | | | 241 +------------------+-------+-------+--------+ 242 | | 243 | (D)TLS Record Layer Interface | 244 | | 245 +-------------------------------------------+ 246 | | 247 | | 248 | (D)TLS Record Layer | 249 | | 250 | | 251 +-------------------------------------------+ 253 Figure 3: (D)TLS Record Layer Interface 255 5. Acknowledgments 257 This work has been possible partially by the ARMOUR project 258 (FP7-ARMOUR-644852 EU Project) and the Spanish National Project CICYT 259 EDISON (TIN2014-52099-R) granted by the Ministry of Economy and 260 Competitiveness of Spain (including ERDF support). 262 6. Normative References 264 [I-D.bhattacharyya-dice-less-on-coap] 265 Bhattacharyya, A., Bandyopadhyay, S., Ukil, A., Bose, T., 266 and A. Pal, "Lightweight Establishment of Secure Session 267 (LESS) on CoAP", draft-bhattacharyya-dice-less-on-coap-00 268 (work in progress), April 2015. 270 [I-D.ietf-core-object-security] 271 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 272 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 273 object-security-00 (work in progress), October 2016. 275 [I-D.schmertmann-dice-codtls] 276 Schmertmann, L., Hartke, K., and C. Bormann, "CoDTLS: DTLS 277 handshakes over CoAP", draft-schmertmann-dice-codtls-01 278 (work in progress), August 2014. 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, 282 DOI 10.17487/RFC2119, March 1997, 283 . 285 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 286 Management API, Version 2", RFC 2367, 287 DOI 10.17487/RFC2367, July 1998, 288 . 290 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 291 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 292 December 2005, . 294 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 295 (TLS) Protocol Version 1.2", RFC 5246, 296 DOI 10.17487/RFC5246, August 2008, 297 . 299 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 300 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 301 January 2012, . 303 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 304 Application Protocol (CoAP)", RFC 7252, 305 DOI 10.17487/RFC7252, June 2014, 306 . 308 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 309 Kivinen, "Internet Key Exchange Protocol Version 2 310 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 311 2014, . 313 Authors' Addresses 315 Dan Garcia Carrillo 316 University of Murcia 317 Campus de Espinardo S/N, Faculty of Computer Science 318 Murcia 30100 319 Spain 321 Phone: +34 868 88 78 82 322 Email: dan.garcia@um.es 324 Sara Nieves Matheu Garcia 325 University of Murcia 326 Campus de Espinardo S/N, Faculty of Computer Science 327 Murcia 30100 328 Spain 330 Phone: +34 868 88 78 82 331 Email: saranieves.matheu@um.es 333 Rafa Marin-Lopez 334 University of Murcia 335 Campus de Espinardo S/N, Faculty of Computer Science 336 Murcia 30100 337 Spain 339 Phone: +34 868 88 85 01 340 Email: rafa@um.es