idnits 2.17.1 draft-bormann-t2trg-sworn-02.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 (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-ace-cwt-proof-of-possession-03 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-05 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 Summary: 2 errors (**), 0 flaws (~~), 4 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 October 22, 2018 5 Expires: April 25, 2019 7 SWORN: Secure Wake on Radio Nudging 8 draft-bormann-t2trg-sworn-02 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 https://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 April 25, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 7 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.ietf-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 [RFC8152], packaging a grant key, provided from 134 D or D's authorization manager to C. (Possibly the grant key can be 135 conveyed within a larger confidentiality protected data structure or 136 channel, such as a CWT [RFC8392] employing a "cnf" claim for the key 137 [I-D.ietf-ace-cwt-proof-of-possession].) 139 A wake grant may then be used by C for initiating (a possibly limited 140 number or total duration of) wake periods, employing Wake-Tokens. 142 Information about the wake grant is also made available to R, so it 143 knows the grant key and the parameters of the wake grant. (Upon a 144 change of parent router, D will need to make that information 145 available to its new parent router as well.) 147 3.2. Wake-Token 149 A wake token is a CWS, MACed with the Wake-Grant's key, containing a 150 CBOR data item of the form: 152 [serial: uint, wake-period: duration] 154 The CWS is additionally marked by tagging it with a CBOR tag 155 1398230866 (a value that becomes visible in a packet dump as ASCII 156 "SWOR"). 158 (Discussion: Should this be a CWE for confidentiality?) 160 The serial is used for replay detection, based on the usual window 161 mechanism. Wake-Tokens for a fresh wake grant start out with serial 162 numbers at zero. 164 A Wake-Token instructs R to use MAC mechanisms to provide an extended 165 wake period to D the next time it wakes up. 167 The wake token is sent from C to D. 169 3.3. Finding the wake token 171 As C is addressing D with the wake token, R needs to find it in 172 traffic purportedly for D. 174 As described in [I-D.bormann-intarea-alfi], this cannot be reasonably 175 done with IP options (which originally would have carried this kind 176 of information in the IP architecture). 178 Instead, R finds the wake token by deep packet inspection. The wake 179 token is found by a heuristic that may have false positives; this is 180 not a problem as the wake token is then verified by its MAC. 182 SWORN requests are carried in UDP packets that also may have a 183 payload function. To this end, they are conveyed as CoAP messages 184 [RFC7252]. The wake token is carried in a CoAP option, Wake-Token. 185 R can find the option by decoding the CoAP packet in the UDP payload 186 or simply by scanning for the 5-byte signature 0xda53574f52 created 187 by the CBOR wake token tag. Any potential wake token so found is 188 then validated as a CWS. 190 This works well with [I-D.ietf-core-object-security] as the CoAP 191 security mechanism for any payload function that this packet may 192 have. To be able to use DTLS as well, we define a media type 193 "application/dtls-payload" that can be used in a CoAP POST request to 194 send a DTLS payload as payload of a CoAP message (in other words, the 195 CoAP POST request carries a Wake-Token and a Content-Format option). 196 (Any return packet can be similarly sent back in the POST response.) 197 (TODO: This media type has to define the port number juggling 198 needed.) 200 4. IANA Considerations 202 Define CBOR Wake-Token Tag 1398230866 in [IANA.cbor-tags]. 204 Define CoAP option Wake-Token in the CoAP Option Numbers subregistry 205 of [IANA.core-parameters]. (The option is safe, no-cache-key, 206 elective, repeatable, of type opaque 0-255 bytes.) 208 Define media-type "application/dtls-payload", with an associated CoAP 209 Content-Format. 211 5. Security Considerations 213 The purpose of the security mechanisms described is primarily to 214 protect availability (obviously, any symmetric keys employed also 215 need to be confidentiality protected for the sake of the integrity of 216 the mechanism). 218 TBD 220 6. References 222 6.1. Normative References 224 [I-D.ietf-ace-cwt-proof-of-possession] 225 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 226 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 227 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 228 possession-03 (work in progress), June 2018. 230 [I-D.ietf-cbor-cddl] 231 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 232 definition language (CDDL): a notational convention to 233 express CBOR and JSON data structures", draft-ietf-cbor- 234 cddl-05 (work in progress), August 2018. 236 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 237 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 238 October 2013, . 240 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 241 Application Protocol (CoAP)", RFC 7252, 242 DOI 10.17487/RFC7252, June 2014, 243 . 245 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 246 RFC 8152, DOI 10.17487/RFC8152, July 2017, 247 . 249 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 250 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 251 May 2018, . 253 6.2. Informative References 255 [I-D.bormann-intarea-alfi] 256 Bormann, C., "Adaptation Layer Fragmentation Indication", 257 draft-bormann-intarea-alfi-04 (work in progress), 258 September 2013. 260 [I-D.ietf-core-object-security] 261 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 262 "Object Security for Constrained RESTful Environments 263 (OSCORE)", draft-ietf-core-object-security-15 (work in 264 progress), August 2018. 266 [IANA.cbor-tags] 267 IANA, "Concise Binary Object Representation (CBOR) Tags", 268 . 270 [IANA.core-parameters] 271 IANA, "Constrained RESTful Environments (CoRE) 272 Parameters", 273 . 275 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 276 Constrained-Node Networks", RFC 7228, 277 DOI 10.17487/RFC7228, May 2014, 278 . 280 Acknowledgements 282 TBD 284 Author's Address 286 Carsten Bormann 287 Universitaet Bremen TZI 288 Postfach 330440 289 Bremen D-28359 290 Germany 292 Phone: +49-421-218-63921 293 Email: cabo@tzi.org