Skip to main content

SWORN: Secure Wake on Radio Nudging
draft-bormann-t2trg-sworn-04

The information below is for an old version of the document.
Document Type Active Internet-Draft (individual)
Authors Carsten Bormann , Yizhou Li
Last updated 2021-10-22
Stream (None)
Formats plain text html xml htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-bormann-t2trg-sworn-04
Network Working Group                                         C. Bormann
Internet-Draft                                    Universität Bremen TZI
Intended status: Informational                                     Y. Li
Expires: 25 April 2022                               Huawei Technologies
                                                         22 October 2021

                  SWORN: Secure Wake on Radio Nudging
                      draft-bormann-t2trg-sworn-04

Abstract

   Normally off devices (RFC7228) would need to expend considerable
   energy resources to be reachable at all times.  Instead, MAC layer
   mechanisms are often employed that allow the last hop router of the
   device to "wake" the device via radio when needed.  Activating these
   devices even for a short time still does expend energy and thus
   should be available to authorized correspondents only.
   Traditionally, this has been achieved by heavy firewalling, allowing
   only authorized hosts to reach the device at all.  This may be too
   inflexible for an Internet of Things.

   The present report describes how to use a combination of currently
   standardized technologies to securely effect this authorization.

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 https://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 25 April 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Bormann & Li              Expires 25 April 2022                 [Page 1]
Internet-Draft     SWORN: Secure Wake on Radio Nudging      October 2021

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Assumptions and Requirements  . . . . . . . . . . . . . . . .   3
     2.1.  Security goals  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Wake-Grant  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Wake-Token  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Finding the wake token  . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

1.1.  Terminology

   The term "byte" is used in its now customary sense as a synonym for
   "octet".

   Messages defined in this document employ CBOR [RFC8949] and are
   described in CDDL [RFC8610].

   Terms used in this draft:

   C:  Client, or Correspondent host.  The node that wants to effect
      "Wake on Radio" on D by sending a message to D.

   D:  Device.  This is typically battery operated and "Normally off"
      [RFC7228].

   R:  Router.  The router that is adjacent to D, sharing an energy-
      saving link with D, and serving as a ("parent") router to D.

Bormann & Li              Expires 25 April 2022                 [Page 2]
Internet-Draft     SWORN: Secure Wake on Radio Nudging      October 2021

2.  Assumptions and Requirements

   D is a normally off [RFC7228] device, waking up very briefly to
   communicate with its first hop router R.  R and D share a MAC layer
   that allows R to keep D in extended wake periods.

   R and D have a security association.  (This may have been created in
   network onboarding, or be setup dynamically from the device-to-
   network security association when D chose R as a parent router.)

   D wants to authorize a client (or correspondent host) C to ask R to
   initiate wake periods in D.

   Because of changes in the radio environment, D needs to be able to
   change its parent router from R1 to R2 occasionally.  This should not
   cause a need to notify all its clients; which parent router is used
   by D is therefore opaque to its clients as usual in IP.

2.1.  Security goals

   Since packets with wake tokens are kept in R for extended periods,
   the limited size buffer provided in R for this is a resource that
   needs to be protected to protect availability.

   D uses up battery for a wake period, which would make it susceptible
   to battery depletion attacks.  To protect availability, D should only
   undergo wake periods that R has commanded based on previous
   authorization by D.

   There may be confidentiality requirements (e.g., for privacy); this
   is not addressed in the present version of this report.

3.  Mechanism

3.1.  Wake-Grant

   A wake grant is a CWE [RFC8152], packaging a grant key, provided from
   D or D's authorization manager to C.  (Possibly the grant key can be
   conveyed within a larger confidentiality protected data structure or
   channel, such as a CWT [RFC8392] employing a cnf claim for the key
   [RFC8747].)

   A wake grant may then be used by C for initiating (a possibly limited
   number or total duration of) wake periods, employing Wake-Tokens.

Bormann & Li              Expires 25 April 2022                 [Page 3]
Internet-Draft     SWORN: Secure Wake on Radio Nudging      October 2021

   Information about the wake grant is also made available to R, so it
   knows the grant key and the parameters of the wake grant.  (Upon a
   change of parent router, D will need to make that information
   available to its new parent router as well.)

3.2.  Wake-Token

   A wake token is a CWS, MACed with the Wake-Grant's key, containing a
   CBOR data item of the form:

   [serial: uint, wake-period: duration]

   The CWS is additionally marked by tagging it with a CBOR tag
   1398230866 (a value that becomes visible in a packet dump as ASCII
   "SWOR").

   (Discussion: Should this be a CWE for confidentiality?)

   The serial is used for replay detection, based on the usual window
   mechanism.  Wake-Tokens for a fresh wake grant start out with serial
   numbers at zero.

   A Wake-Token instructs R to use MAC mechanisms to provide an extended
   wake period to D the next time it wakes up.

   The wake token is sent from C to D; R finds it be examining packets
   that it would need to forward to D.

3.3.  Finding the wake token

   As C is addressing D with the wake token, R needs to find it in
   traffic purportedly for D.

   As described in [I-D.bormann-intarea-alfi], this cannot be reasonably
   done with IP options (which originally would have carried this kind
   of information in the IP architecture).

   Instead, R finds the wake token by deep packet inspection.  The wake
   token is found by a heuristic that may have false positives; this is
   not a problem as the wake token is then verified by its MAC.

   SWORN requests are carried in UDP packets that also may have a
   payload function.  To this end, they are conveyed as CoAP messages
   [RFC7252].  The wake token is carried in a CoAP option, Wake-Token.
   R can find the option by decoding the CoAP packet in the UDP payload
   or simply by scanning for the 5-byte signature 0xda53574f52 created
   by the CBOR wake token tag.  Any potential wake token so found is
   then validated as a CWS.

Bormann & Li              Expires 25 April 2022                 [Page 4]
Internet-Draft     SWORN: Secure Wake on Radio Nudging      October 2021

   This works well with [RFC8613] as the CoAP security mechanism for any
   payload function that this packet may have.  To be able to use DTLS
   as well, we define a media type "application/dtls-payload" that can
   be used in a CoAP POST request to send a DTLS payload as payload of a
   CoAP message (in other words, the CoAP POST request carries a Wake-
   Token and a Content-Format option).  (Any return packet can be
   similarly sent back in the POST response.)  (TODO: This media type
   has to define the port number juggling needed.)

4.  IANA Considerations

   Define CBOR Wake-Token Tag 1398230866 in [IANA.cbor-tags].

   Define CoAP option Wake-Token in the CoAP Option Numbers Registry of
   [IANA.core-parameters] (Section 12.2 of [RFC7252].  (The option is
   safe, no-cache-key, elective, repeatable, of type opaque 0-255
   bytes.)

   Define media-type "application/dtls-payload", with an associated CoAP
   Content-Format in the CoAP Content-Formats Registry of
   [IANA.core-parameters] (Section 12.3 of [RFC7252].

5.  Security Considerations

   The purpose of the security mechanisms described is primarily to
   protect availability (obviously, any symmetric keys employed also
   need to be confidentiality protected for the sake of the integrity of
   the mechanism).  For the purposes of this kind of availability
   protection, occasional false positives of the per-packet
   authorization mechanisms may be acceptable, as long as they don't
   reach a probability of success that is application dependent (say,
   success in one out of a million of brute force attempts, equivalent
   to 20-bit security).  This may offer optimization opportunities that
   need further study.

   TBD

6.  References

6.1.  Normative References

   [IANA.cbor-tags]
              IANA, "Concise Binary Object Representation (CBOR) Tags",
              <https://www.iana.org/assignments/cbor-tags>.

Bormann & Li              Expires 25 April 2022                 [Page 5]
Internet-Draft     SWORN: Secure Wake on Radio Nudging      October 2021

   [IANA.core-parameters]
              IANA, "Constrained RESTful Environments (CoRE)
              Parameters",
              <https://www.iana.org/assignments/core-parameters>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8747]  Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
              Tschofenig, "Proof-of-Possession Key Semantics for CBOR
              Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
              2020, <https://www.rfc-editor.org/info/rfc8747>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

6.2.  Informative References

   [I-D.bormann-intarea-alfi]
              Bormann, C., "Adaptation Layer Fragmentation Indication",
              Work in Progress, Internet-Draft, draft-bormann-intarea-
              alfi-04, 9 September 2013,
              <https://www.ietf.org/archive/id/draft-bormann-intarea-
              alfi-04.txt>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

Bormann & Li              Expires 25 April 2022                 [Page 6]
Internet-Draft     SWORN: Secure Wake on Radio Nudging      October 2021

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

Acknowledgements

   TBD

Authors' Addresses

   Carsten Bormann
   Universität Bremen TZI
   Postfach 330440
   D-28359 Bremen
   Germany

   Phone: +49-421-218-63921
   Email: cabo@tzi.org

   Yizhou Li
   Huawei Technologies

   Email: liyizhou@huawei.com

Bormann & Li              Expires 25 April 2022                 [Page 7]