Network Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Informational October 20, 2019
Expires: April 22, 2020
SWORN: Secure Wake on Radio Nudging
draft-bormann-t2trg-sworn-03
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 (or in progress) 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 April 22, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bormann Expires April 22, 2020 [Page 1]
Internet-Draft SWORN: Secure Wake on Radio Nudging October 2019
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 . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 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 [RFC7049] 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 Expires April 22, 2020 [Page 2]
Internet-Draft SWORN: Secure Wake on Radio Nudging October 2019
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
[I-D.ietf-ace-cwt-proof-of-possession].)
A wake grant may then be used by C for initiating (a possibly limited
number or total duration of) wake periods, employing Wake-Tokens.
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
Bormann Expires April 22, 2020 [Page 3]
Internet-Draft SWORN: Secure Wake on Radio Nudging October 2019
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.
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.
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
Bormann Expires April 22, 2020 [Page 4]
Internet-Draft SWORN: Secure Wake on Radio Nudging October 2019
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 subregistry
of [IANA.core-parameters]. (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.
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).
TBD
6. References
6.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-09 (work in progress), October 2019.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[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>.
Bormann Expires April 22, 2020 [Page 5]
Internet-Draft SWORN: Secure Wake on Radio Nudging October 2019
[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>.
6.2. Informative References
[I-D.bormann-intarea-alfi]
Bormann, C., "Adaptation Layer Fragmentation Indication",
draft-bormann-intarea-alfi-04 (work in progress),
September 2013.
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters",
<http://www.iana.org/assignments/core-parameters>.
[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>.
[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
Bormann Expires April 22, 2020 [Page 6]
Internet-Draft SWORN: Secure Wake on Radio Nudging October 2019
Author's Address
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Bormann Expires April 22, 2020 [Page 7]