idnits 2.17.1 draft-bormann-t2trg-sworn-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2017) is 2578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-10 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational March 26, 2017 5 Expires: September 27, 2017 7 SWORN: Secure Wake on Radio Nudging 8 draft-bormann-t2trg-sworn-00 10 Abstract 12 Normally off devices (RFC7228) would need to expend considerable 13 energy resources to be reachable at all times. Instead, MAC layer 14 mechanisms are often employed that allow the last hop router of the 15 device to "wake" the device via radio when needed. Activating these 16 devices even for a short time still does expend energy and thus 17 should be available to authorized correspondents only. 18 Traditionally, this has been achieved by heavy firewalling, allowing 19 only authorized hosts to reach the device at all. This may be too 20 inflexible for an Internet of Things. 22 The present report describes how to use a combination of currently 23 standardized (or in progress) technologies to securely effect this 24 authorization. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 27, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Assumptions and Requirements . . . . . . . . . . . . . . . . 3 63 2.1. Security goals . . . . . . . . . . . . . . . . . . . . . 3 64 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Wake-Grant . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.2. Wake-Token . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.3. Finding the wake token . . . . . . . . . . . . . . . . . 4 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 72 6.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 1.1. Terminology 80 The term "byte" is used in its now customary sense as a synonym for 81 "octet". 83 Messages defined in this document employ CBOR [RFC7049] are described 84 in CDDL [I-D.greevenbosch-appsawg-cbor-cddl]. 86 Terms used in this draft: 88 C: Client, or Correspondent host. The node that wants to effect 89 "Wake on Radio" on D by sending a message to D. 91 D: Device. This is typically battery operated and "Normally off" 92 [RFC7228]. 94 R: Router. The router that is adjacent to D, sharing an energy- 95 saving link with D, and serving as a ("parent") router to D. 97 2. Assumptions and Requirements 99 D is a normally off [RFC7228] device, waking up very briefly to 100 communicate with its first hop router R. R and D share a MAC layer 101 that allows R to keep D in extended wake periods. 103 R and D have a security association. (This may have been created in 104 network onboarding, or be setup dynamically from the device-to- 105 network security association when D chose R as a parent router.) 107 D wants to authorize a client (or correspondent host) C to ask R to 108 initiate wake periods in D. 110 Because of changes in the radio environment, D needs to be able to 111 change its parent router from R1 to R2 occasionally. This should not 112 cause a need to notify all its clients; which parent router is used 113 by D is therefore opaque to its clients as usual in IP. 115 2.1. Security goals 117 Since packets with wake tokens are kept in R for extended periods, 118 the limited size buffer provided in R for this is a resource that 119 needs to be protected to protect availability. 121 D uses up battery for a wake period, which would make it susceptible 122 to battery depletion attacks. To protect availability, D should only 123 undergo wake periods that R has commanded based on previous 124 authorization by D. 126 There may be confidentiality requirements (e.g., for privacy); this 127 is not addressed in the present version of this report. 129 3. Mechanism 131 3.1. Wake-Grant 133 A wake grant is a CWE [I-D.ietf-cose-msg], packaging a grant key, 134 provided from D or D's authorization manager to C. (Possibly the 135 grant key can be conveyed within a larger confidentiality protected 136 data structure or channel.) 138 A wake grant may then be used by C for initiating (a possibly limited 139 number or total duration of) wake periods, employing Wake-Tokens. 141 Information about the wake grant is also made available to R, so it 142 knows the grant key and the parameters of the wake grant. (Upon a 143 change of parent router, D will need to make that information 144 available to its new parent router as well.) 146 3.2. Wake-Token 148 A wake token is a CWS, MACed with the Wake-Grant's key, containing a 149 CBOR data item of the form: 151 [serial: uint, wake-period: duration] 153 The CWS is additionally marked by tagging it with a CBOR tag 154 1398230866 (a value that becomes visible in a packet dump as ASCII 155 "SWOR"). 157 (Discussion: Should this be a CWE for confidentiality?) 159 The serial is used for replay detection, based on the usual window 160 mechanism. Wake-Tokens for a fresh wake grant start out with serial 161 numbers at zero. 163 A Wake-Token instructs R to use MAC mechanisms to provide an extended 164 wake period to D the next time it wakes up. 166 The wake token is sent from C to D. 168 3.3. Finding the wake token 170 As C is addressing D with the wake token, R needs to find it in 171 traffic purportedly for D. 173 As described in [I-D.bormann-intarea-alfi], this cannot be reasonably 174 done with IP options (which originally would have carried this kind 175 of information in the IP architecture). 177 Instead, R finds the wake token by deep packet inspection. The wake 178 token is found by a heuristic that may have false positives; this is 179 not a problem as the wake token is then verified by its MAC. 181 SWORN requests are carried in UDP packets that also may have a 182 payload function. To this end, they are conveyed as CoAP messages 183 [RFC7252]. The wake token is carried in a CoAP option, Wake-Token. 184 R can find the option by decoding the CoAP packet in the UDP payload 185 or simply by scanning for the 5-byte signature 0xda53574f52 created 186 by the CBOR wake token tag. Any potential wake token so found is 187 then validated as a CWS. 189 This works well with [I-D.ietf-core-object-security] as the CoAP 190 security mechanism for any payload function that this packet may 191 have. To be able to use DTLS as well, we define a media type 192 "application/dtls-payload" that can be used in a CoAP POST request to 193 send a DTLS payload as payload of a CoAP message (in other words, the 194 CoAP POST request carries a Wake-Token and a Content-Format option). 195 (Any return packet can be similarly sent back in the POST response.) 196 (TODO: This media type has to define the port number juggling 197 needed.) 199 4. IANA Considerations 201 Define CBOR Wake-Token Tag 1398230866 in [IANA.cbor-tags]. 203 Define CoAP option Wake-Token in the CoAP Option Numbers subregistry 204 of [IANA.core-parameters]. (The option is safe, no-cache-key, 205 elective, repeatable, of type opaque 0-255 bytes.) 207 Define media-type "application/dtls-payload", with an associated CoAP 208 Content-Format. 210 5. Security Considerations 212 The purpose of the security mechanisms described is primarily to 213 protect availability (obviously, any symmetric keys employed also 214 need to be confidentiality protected for the sake of the integrity of 215 the mechanism). 217 TBD 219 6. References 221 6.1. Normative References 223 [I-D.greevenbosch-appsawg-cbor-cddl] 224 Birkholz, H., Vigano, C., and C. Bormann, "CBOR data 225 definition language (CDDL): a notational convention to 226 express CBOR data structures", draft-greevenbosch-appsawg- 227 cbor-cddl-10 (work in progress), March 2017. 229 [I-D.ietf-cose-msg] 230 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 231 draft-ietf-cose-msg-24 (work in progress), November 2016. 233 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 234 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 235 October 2013, . 237 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 238 Application Protocol (CoAP)", RFC 7252, 239 DOI 10.17487/RFC7252, June 2014, 240 . 242 6.2. Informative References 244 [I-D.bormann-intarea-alfi] 245 Bormann, C., "Adaptation Layer Fragmentation Indication", 246 draft-bormann-intarea-alfi-04 (work in progress), 247 September 2013. 249 [I-D.ietf-core-object-security] 250 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 251 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 252 object-security-02 (work in progress), March 2017. 254 [IANA.cbor-tags] 255 IANA, "Concise Binary Object Representation (CBOR) Tags", 256 . 258 [IANA.core-parameters] 259 IANA, "Constrained RESTful Environments (CoRE) 260 Parameters", 261 . 263 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 264 Constrained-Node Networks", RFC 7228, 265 DOI 10.17487/RFC7228, May 2014, 266 . 268 Acknowledgements 270 TBD 272 Author's Address 274 Carsten Bormann 275 Universitaet Bremen TZI 276 Postfach 330440 277 Bremen D-28359 278 Germany 280 Phone: +49-421-218-63921 281 Email: cabo@tzi.org