draft-ietf-lake-reqs-01.txt   draft-ietf-lake-reqs-02.txt 
Network Working Group M. Vucinic Network Working Group M. Vucinic
Internet-Draft Inria Internet-Draft Inria
Intended status: Informational G. Selander Intended status: Informational G. Selander
Expires: 22 August 2020 J. Mattsson Expires: 10 September 2020 J. Mattsson
Ericsson AB Ericsson AB
D. Garcia D. Garcia
Odin Solutions S.L. Odin Solutions S.L.
19 February 2020 9 March 2020
Requirements for a Lightweight AKE for OSCORE Requirements for a Lightweight AKE for OSCORE
draft-ietf-lake-reqs-01 draft-ietf-lake-reqs-02
Abstract Abstract
This document compiles the requirements for a lightweight This document compiles the requirements for a lightweight
authenticated key exchange protocol for OSCORE. authenticated key exchange protocol for OSCORE. This draft is in a
working group last call (WGLC) in the LAKE working group. Post-WGLC,
the requirements will be considered sufficiently stable for the
working group to proceed with its work. It is not currently planned
to publish this draft as an RFC.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 August 2020. This Internet-Draft will expire on 10 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 16 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem description . . . . . . . . . . . . . . . . . . . . . 3 2. Problem description . . . . . . . . . . . . . . . . . . . . . 3
2.1. AKE for OSCORE . . . . . . . . . . . . . . . . . . . . . 3 2.1. AKE for OSCORE . . . . . . . . . . . . . . . . . . . . . 3
2.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 6 2.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 6
2.4. Confidentiality . . . . . . . . . . . . . . . . . . . . . 7 2.4. Confidentiality . . . . . . . . . . . . . . . . . . . . . 7
2.5. Cryptographic Agility and Negotiation Integrity . . . . . 7 2.5. Cryptographic Agility and Negotiation Integrity . . . . . 7
2.6. Identity Protection . . . . . . . . . . . . . . . . . . . 8 2.6. Identity Protection . . . . . . . . . . . . . . . . . . . 8
2.7. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 9 2.7. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 9
2.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 2.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
2.9. Denial of Service . . . . . . . . . . . . . . . . . . . . 10 2.9. Denial of Service . . . . . . . . . . . . . . . . . . . . 10
2.10. Lightweight . . . . . . . . . . . . . . . . . . . . . . . 10 2.10. Lightweight . . . . . . . . . . . . . . . . . . . . . . . 10
2.10.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 12 2.10.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 12
2.10.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . 13 2.10.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . 13
2.10.3. NB-IoT . . . . . . . . . . . . . . . . . . . . . . . 14 2.10.3. NB-IoT . . . . . . . . . . . . . . . . . . . . . . . 15
2.10.4. Discussion . . . . . . . . . . . . . . . . . . . . . 16 2.10.4. Discussion . . . . . . . . . . . . . . . . . . . . . 16
2.10.5. AKE frequency . . . . . . . . . . . . . . . . . . . 17 2.10.5. AKE frequency . . . . . . . . . . . . . . . . . . . 17
3. Requirements Summary . . . . . . . . . . . . . . . . . . . . 17 3. Security Considerations . . . . . . . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . . 18 Informative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
OSCORE [RFC8613] is a lightweight communication security protocol OSCORE [RFC8613] is a lightweight communication security protocol
providing end-to-end security on application layer for constrained providing end-to-end security on application layer for constrained
IoT settings (cf. [RFC7228]). OSCORE lacks a matching authenticated IoT settings (cf. [RFC7228]). OSCORE lacks a matching authenticated
key exchange protocol (AKE). The intention with LAKE is to create a key exchange protocol (AKE). The intention with the LAKE WG
simple yet secure AKE for implementation in embedded devices [LAKE-WG] is to create a simple yet secure AKE for implementation in
supporting OSCORE. embedded devices supporting OSCORE.
To ensure that the AKE is efficient for the expected applications of To ensure that the AKE is efficient for the expected applications of
OSCORE, we list the relevant public specifications of technologies OSCORE, we list the relevant public specifications of technologies
where OSCORE is included: where OSCORE is included:
* The IETF 6TiSCH WG charter (-02) identifies the need to "secur[e] * The IETF 6TiSCH WG charter identifies the need to "secur[e] the
the join process and mak[e] that fit within the constraints of join process and mak[e] that fit within the constraints of high
high latency, low throughput and small frame sizes that latency, low throughput and small frame sizes that characterize
characterize IEEE802.15.4 TSCH". OSCORE protects the join IEEE802.15.4 TSCH". OSCORE protects the join protocol as
protocol as described in 6TiSCH Minimal Security described in 6TiSCH Minimal Security
[I-D.ietf-6tisch-minimal-security]. [I-D.ietf-6tisch-minimal-security].
* The IETF LPWAN WG charter (-01) identifies the need to improve the * The IETF LPWAN WG charter identifies the need to improve the
transport capabilities of LPWA networks such as NB-IoT and LoRa transport capabilities of LPWA networks such as NB-IoT and LoRa
whose "common traits include ... frame sizes ... [on] the order of whose "common traits include ... frame sizes ... [on] the order of
tens of bytes transmitted a few times per day at ultra-low tens of bytes transmitted a few times per day at ultra-low
speeds". The application of OSCORE is described in speeds". The application of OSCORE is described in
[I-D.ietf-lpwan-coap-static-context-hc]. [I-D.ietf-lpwan-coap-static-context-hc].
* OMA Specworks LwM2M version 1.1 [LwM2M] defines bindings to two * OMA Specworks LwM2M version 1.1 [LwM2M] defines bindings to two
challenging radio technologies where OSCORE will be deployed: challenging radio technologies where OSCORE will be deployed:
LoRaWAN and NB-IoT. LoRaWAN and NB-IoT.
Other industry fora which plan to use OSCORE:
* Open Connectivity Foundation (OCF) has been actively involved in
the OSCORE development for the purpose of deploying OSCORE.
* Fairhair Alliance has defined an architecture [Fairhair] which * Fairhair Alliance has defined an architecture [Fairhair] which
adopts OSCORE for multicast, but it is not clear whether the adopts OSCORE for multicast, but it is not clear whether the
architecture will support unicast OSCORE. Fairhair Alliance architecture will support unicast OSCORE. Fairhair Alliance
merged with OCF in November 2019. merged with Open Connectivity Foundation (OCF) in November 2019.
This document compiles the requirements for the AKE for OSCORE. It This document compiles the requirements for the AKE for OSCORE. It
summarizes the security requirements that are expected from such an summarizes the security requirements that are expected from such an
AKE, as well as the main characteristics of the environments where AKE, as well as the main characteristics of the environments where
the solution is envisioned to be deployed. The solution will the solution is envisioned to be deployed. The solution will
presumably be useful in other scenarios as well since a low security presumably be useful in other scenarios as well since a low security
overhead improves the overall performance. overhead improves the overall performance.
2. Problem description 2. Problem description
2.1. AKE for OSCORE 2.1. AKE for OSCORE
The rationale for designing this protocol is that OSCORE is lacking a The rationale for designing this protocol is that OSCORE is lacking a
matching AKE. OSCORE was designed for lightweight RESTful operations matching AKE. OSCORE was designed for lightweight RESTful operations
for example by minimizing the overhead, and applying the protection for example by minimizing the overhead, and applying the protection
to the application layer, thereby limiting the data being encrypted to the application layer, thereby limiting the data being encrypted
and integrity protected for the other endpoint. Moreover, OSCORE was and integrity protected for the other endpoint. Moreover, OSCORE was
tailored for use with lightweight primitives that are likely to be tailored for use with lightweight primitives that are likely to be
implemented in the device, specifically CoAP, CBOR and COSE. The implemented in the device, specifically CoAP [RFC7252], CBOR
same properties must apply to the AKE. [RFC7049] and COSE [RFC8152]. The same properties must apply to the
AKE.
In order to be suitable for OSCORE, at the end of the AKE protocol In order to be suitable for OSCORE, at the end of the AKE protocol
run the two parties must agree on (see Section 3.2 of [RFC8613]): run the two parties must agree on (see Section 3.2 of [RFC8613]):
* A shared secret (OSCORE Master Secret) with Perfect Forward * A shared secret (OSCORE Master Secret) with Perfect Forward
Secrecy (PFS, see Section 2.4) and a good amount of randomness. Secrecy (PFS, see Section 2.4) and a good amount of randomness.
(The term "good amount of randomness" is borrowed from [HKDF] to (The term "good amount of randomness" is borrowed from [HKDF] to
signify not necessarily uniformly distributed randomness.) signify not necessarily uniformly distributed randomness.)
* OSCORE Sender IDs of peer endpoints, arbitrarily short * OSCORE Sender IDs of peer endpoints, arbitrarily short.
- Sender IDs are expected to be unique for a given Master Secret,
more precisely the quartet (Master Secret, Master Salt, ID
Context, Sender ID) must be unique, see Section 3.3. of
[RFC8613].
* COSE algorithms to use with OSCORE * COSE algorithms to use with OSCORE
COSE provides the crypto primitives for OSCORE, and shall therefore COSE provides the crypto primitives for OSCORE. The AKE shall
be used also by the AKE, for several reasons including maintenance of specify how COSE can be reused for identification of credentials and
crypto library. COSE provides identification of credentials and algorithms of OSCORE and the AKE, as extension point for new schemes,
algorithms for OSCORE and the AKE, and an extension point for new and to avoid duplicated maintenance of crypto library.
schemes.
The AKE cannot rely on messages being exchanged in both directions The AKE cannot rely on messages being exchanged in both directions
after the AKE has completed, because CoAP/OSCORE requests may not after the AKE has completed, because CoAP/OSCORE requests may not
have a response [RFC7967]. Furthermore, there is no assumption of have a response [RFC7967]. Furthermore, there is no assumption of
dependence between CoAP client/server and AKE initiator/responder dependence between CoAP client/server and AKE initiator/responder
roles, and an OSCORE context may be used with CoAP client and server roles, and an OSCORE context may be used with CoAP client and server
roles interchanged as is done, for example, in [LwM2M]. roles interchanged as is done, for example, in [LwM2M].
Moreover, the AKE must support transport over CoAP. Since the AKE Moreover, the AKE must support transport over CoAP. Since the AKE
messages most commonly will be encapsulated in CoAP, the AKE must not messages most commonly will be encapsulated in CoAP, the AKE must not
skipping to change at page 4, line 37 skipping to change at page 4, line 44
attacks, such as provided by the CoAP Echo option attacks, such as provided by the CoAP Echo option
[I-D.ietf-core-echo-request-tag]. [I-D.ietf-core-echo-request-tag].
The AKE may use other transport than CoAP. In this case the The AKE may use other transport than CoAP. In this case the
underlying layers must correspondingly handle message loss, underlying layers must correspondingly handle message loss,
reordering, message duplication, fragmentation, and denial of service reordering, message duplication, fragmentation, and denial of service
protection. protection.
2.2. Credentials 2.2. Credentials
IoT deployments differ in terms of what credentials can be supported. IoT deployments differ from one another in terms of what credentials
Currently many systems use pre-shared keys (PSKs) provisioned out of can be supported. Currently many systems use pre-shared keys (PSKs)
band, for various reasons. PSKs are often used in a first deployment provisioned out of band, for various reasons. PSKs are often used in
because of their perceived simplicity. The use of PSKs allows for a first deployment because of their perceived simplicity. The use of
protection of communication without major additional security PSKs allows for protection of communication without major additional
processing, and also enables the use of symmetric crypto algorithms security processing, and also enables the use of symmetric crypto
only, reducing the implementation and computational effort in the algorithms only, reducing the implementation and computational effort
endpoints. in the endpoints.
However, PSK-based provisioning has inherent weaknesses. There has However, PSK-based provisioning has inherent weaknesses. There has
been reports of massive breaches of PSK provisioning systems, and as been reports of massive breaches of PSK provisioning systems, and as
many systems use PSKs without perfect forward secrecy (PFS) they are many systems use PSKs without perfect forward secrecy (PFS) they are
vulnerable to passive pervasive monitoring. The security of these vulnerable to passive pervasive monitoring. The security of these
systems can be improved by adding PFS through an AKE authenticated by systems can be improved by adding PFS through an AKE authenticated by
the provisioned PSK. the provisioned PSK.
Shared keys can alternatively be established in the endpoints using Shared keys can alternatively be established in the endpoints using
an AKE protocol authenticated with asymmetric public keys instead of an AKE protocol authenticated with asymmetric public keys instead of
skipping to change at page 5, line 36 skipping to change at page 5, line 43
PSK- (shared between two nodes), RPK- and certificate-based PSK- (shared between two nodes), RPK- and certificate-based
authentication. authentication.
Multiple public key authentication credential types may need to be Multiple public key authentication credential types may need to be
supported for RPK and certificate-based authentication. In case of a supported for RPK and certificate-based authentication. In case of a
Diffie-Hellman key exchange both the use of signature based public Diffie-Hellman key exchange both the use of signature based public
keys (for compatibility with existing ecosystem) and static DH public keys (for compatibility with existing ecosystem) and static DH public
keys (for reduced message size) is expected. keys (for reduced message size) is expected.
To further minimize the bandwidth consumption it is required to To further minimize the bandwidth consumption it is required to
support transporting the certificates by reference rather than by support transporting certificates and raw public keys by reference
value. Considering the wide variety of deployments the AKE must rather than by value. Considering the wide variety of deployments,
support different schemes for transporting and identifying the AKE must support different schemes for transporting and
credentials, including those identified in Section 2 of identifying credentials, including those identified in Section 2 of
[I-D.ietf-cose-x509]. [I-D.ietf-cose-x509].
The common lack of a user interface in constrained devices leads to The common lack of a user interface in constrained devices leads to
various credential provisioning schemes. The use of RPKs may be various credential provisioning schemes. The use of RPKs may be
appropriate for the authentication of the AKE initiator but not for appropriate for the authentication of the AKE initiator but not for
the AKE responder. The AKE must support different credentials for the AKE responder. The AKE must support different credentials for
authentication in different directions of the AKE run, e.g. authentication in different directions of the AKE run, e.g.
certificate-based authentication for the initiating endpoint and RPK- certificate-based authentication for the initiating endpoint and RPK-
based authentication for the responding endpoint. based authentication for the responding endpoint.
skipping to change at page 6, line 25 skipping to change at page 6, line 32
credentials of both endpoints. credentials of both endpoints.
Since the protocol may be initiated by different endpoints, it shall Since the protocol may be initiated by different endpoints, it shall
not be necessary to determine beforehand which endpoint takes the not be necessary to determine beforehand which endpoint takes the
role of initiator of the AKE. role of initiator of the AKE.
The mutual authentication guarantees of the AKE shall at least The mutual authentication guarantees of the AKE shall at least
guarantee the following properties: guarantee the following properties:
* The AKE shall provide Key Compromise Impersonation (KCI) * The AKE shall provide Key Compromise Impersonation (KCI)
resistance. resistance [KCI].
* The AKE shall protect against identity misbinding attacks, when * The AKE shall protect against identity misbinding attacks
applicable. Note that the identity may be directly related to a [Misbinding]. Note that the identity may be directly related to a
public key such as for example the public key itself, a hash of public key such as for example the public key itself, a hash of
the public key, or data unrelated to a key. the public key, or data unrelated to a key.
* The AKE shall protect against reflection attacks, but need not * The AKE shall protect against reflection attacks, but need not
protect against attacks when more than two parties legitimately protect against attacks when more than two parties legitimately
share keys (cf. the Selfie attack on TLS 1.3) as that setting is share keys (cf. the Selfie attack on TLS 1.3 [Selfie]) as that
out of scope. setting is out of scope.
Moreover, it shall be possible for the receiving endpoint to detect a Moreover, it shall be possible for the receiving endpoint to detect a
replayed AKE message. replayed AKE message.
Furthermore, the endpoints shall be able to verify that the identity Furthermore, the endpoints shall be able to verify that the identity
of the other endpoint is an acceptable identity that it is intended of the other endpoint is an acceptable identity that it is intended
to authenticate to. (This requirement extends beyond the AKE in that to authenticate to. (This requirement extends beyond the AKE in that
the application must enable access to information about acceptable the application must enable access to information about acceptable
identities without compromising the overall lightweightness of the identities without compromising the overall lightweightness of the
AKE.) AKE.)
skipping to change at page 7, line 47 skipping to change at page 8, line 8
crypto algorithms and negotiation of preferred crypto algorithms for crypto algorithms and negotiation of preferred crypto algorithms for
OSCORE and the AKE. OSCORE and the AKE.
* The protocol shall support both pre-shared key and asymmetric key * The protocol shall support both pre-shared key and asymmetric key
authentication. PAKE and post-quantum key exchange is out of authentication. PAKE and post-quantum key exchange is out of
scope, but may be supported in a later version. scope, but may be supported in a later version.
* The protocol shall allow multiple elliptic curves for Diffie- * The protocol shall allow multiple elliptic curves for Diffie-
Hellman operations and signature-based authentication. Hellman operations and signature-based authentication.
* The AKE shall support negotiation of all the COSE algorithms to be * The AKE shall support negotiation of COSE algorithms
used in the AKE and in OSCORE. A successful negotiation shall [IANA-COSE-Algorithms] to be used in the AKE and in OSCORE. A
result in the most preferred algorithms of one of the parties successful negotiation shall result in the most preferred
which are supported by the other. algorithms of one of the parties which are supported by the other.
* The AKE may choose different sets of symmetric crypto algorithms * The AKE may choose different sets of symmetric crypto algorithms
(AEAD, MAC, etc.) for AKE and for OSCORE. In particular, the (AEAD, MAC, etc.) for AKE and for OSCORE. In particular, the
length of the MAC for the AKE may be required to be larger than length of the MAC for the AKE may be required to be larger than
for OSCORE. for OSCORE.
The AKE negotiation must provide strong integrity guarantees against The AKE negotiation must provide strong integrity guarantees against
active attackers. At the end of the AKE protocol, both endpoints active attackers. At the end of the AKE protocol, both endpoints
must agree on both the crypto algorithms that were proposed and those must agree on both the crypto algorithms that were proposed and those
that were chosen. In particular, the protocol must protect against that were chosen. In particular, the protocol must protect against
skipping to change at page 8, line 25 skipping to change at page 8, line 33
2.6. Identity Protection 2.6. Identity Protection
In general, it is necessary to transport identities as part of the In general, it is necessary to transport identities as part of the
AKE run in order to provide authentication of an entity not AKE run in order to provide authentication of an entity not
identified beforehand. In the case of constrained devices, the identified beforehand. In the case of constrained devices, the
identity may contain sensitive information on the manufacturer of the identity may contain sensitive information on the manufacturer of the
device, the batch, default firmware version, etc. Protecting device, the batch, default firmware version, etc. Protecting
identifying information from passive and active attacks is important identifying information from passive and active attacks is important
from a privacy point of view, but needs to be balanced with the other from a privacy point of view, but needs to be balanced with the other
requirements, including security and lightweightness. For certain requirements, including security and lightweightness.
data we therefore need to make an exemption in order to obtain an
efficient protocol.
In the case of public key identities, the AKE is required to protect In the case of public key identities, the AKE is required to protect
the identity of one of the peers against active attackers and the the identity of one of the peers against active attackers and the
identity of the other peer against passive attackers. identity of the other peer against passive attackers.
In case of a PSK identifier, this may be protected against passive In case of a PSK identifier, this may be protected against passive
attackers, for example with a key derived from a Diffie-Hellman attackers, for example with a key derived from a Diffie-Hellman
shared secret at the earliest in flight 3. As a consequence, in shared secret at the earliest in flight 3. As a consequence, in
order to authenticate the responder within the AKE, at least four order to authenticate the responder within the AKE, at least four
protocol flights are needed in case of symmetric key authentication protocol flights are needed in case of symmetric key authentication
skipping to change at page 10, line 20 skipping to change at page 10, line 28
While remaining extensible, the AKE should avoid optional mechanisms While remaining extensible, the AKE should avoid optional mechanisms
which introduce code paths that are less well tested. which introduce code paths that are less well tested.
The AKE should avoid mechanisms where an initiator takes a guess at The AKE should avoid mechanisms where an initiator takes a guess at
the policy, and when it receives a negative response, must guess, the policy, and when it receives a negative response, must guess,
based upon what it has tried, what to do next. based upon what it has tried, what to do next.
2.9. Denial of Service 2.9. Denial of Service
The AKE shall protect against denial of service attacks on responder The AKE shall protect against denial of service attacks on responder,
and initiator to the extent that the protocol supports lightweight initiator and third parties to the extent that the protocol supports
deployments (see Section 2.10) and without duplicating the DoS lightweight deployments (see Section 2.10) and without duplicating
mitigation of the underlying transport (see Section 2.1). the DoS mitigation of the underlying transport (see Section 2.1).
Jamming attacks, cutting cables etc. leading to long term loss of Jamming attacks, cutting cables etc. leading to long term loss of
availability may not be possible to mitigate, but an attacker availability may not be possible to mitigate, but an attacker
temporarily injecting messages or disturbing the communication shall temporarily injecting messages or disturbing the communication shall
not have a similar impact. not have a similar impact.
2.10. Lightweight 2.10. Lightweight
We target an AKE which is efficiently deployable in 6TiSCH multi-hop We target an AKE which is efficiently deployable in 6TiSCH multi-hop
networks, LoRaWAN networks and NB-IoT networks. The desire is to networks, LoRaWAN networks and NB-IoT networks. (For an overview of
low-power wide area networks, see e.g. [RFC8376].) The desire is to
optimize the AKE to be 'as lightweight as reasonably achievable' in optimize the AKE to be 'as lightweight as reasonably achievable' in
these environments, where 'lightweight' refers to: these environments, where 'lightweight' refers to:
* resource consumption, measured by bytes on the wire, wall-clock * resource consumption, measured by bytes on the wire, wall-clock
time and number of round trips to complete, or power consumption time and number of round trips to complete, or power consumption
* the amount of new code required on end systems which already have * the amount of new code required on end systems which already have
an OSCORE stack an OSCORE stack
These properties need to be considered in the context of the use of These properties need to be considered in the context of the use of
skipping to change at page 11, line 41 skipping to change at page 11, line 50
crypto to draw as little power as possible. The best mechanism for crypto to draw as little power as possible. The best mechanism for
doing so differs across radio technologies. For example, NB-IoT uses doing so differs across radio technologies. For example, NB-IoT uses
licensed spectrum and thus can transmit at higher power to improve licensed spectrum and thus can transmit at higher power to improve
coverage, making the transmitted byte count relatively more important coverage, making the transmitted byte count relatively more important
than for other radio technologies. In other cases, the radio than for other radio technologies. In other cases, the radio
transmitter will be active for a full MTU frame regardless of how transmitter will be active for a full MTU frame regardless of how
much of the frame is occupied by message content, which makes the much of the frame is occupied by message content, which makes the
byte count less sensitive for the power consumption as long as it byte count less sensitive for the power consumption as long as it
fits into the MTU frame. The power consumption thus increases with fits into the MTU frame. The power consumption thus increases with
AKE message size and the largest impact is on average under poor AKE message size and the largest impact is on average under poor
network conditions. network conditions. Note that listening for messages to receive can
in many cases be a large contribution to the power consumption, for
which there are separate techniques to handle, e.g., time slots,
discontinuous reception, etc. but this is not considered in scope of
the AKE design.
Per 'new code', it is desirable to introduce as little new code as Per 'new code', it is desirable to introduce as little new code as
possible onto OSCORE-enabled devices to support this new AKE. These possible onto OSCORE-enabled devices to support this new AKE. These
devices have on the order of 10s of kB of memory and 100 kB of devices have on the order of 10s of kB of memory and 100 kB of
storage on which an embedded OS; a COAP stack; CORE and AKE storage on which an embedded OS; a COAP stack; CORE and AKE
libraries; and target applications would run. It is expected that libraries; and target applications would run. It is expected that
the majority of this space is available for actual application logic, the majority of this space is available for actual application logic,
as opposed to the support libraries. In a typical OSCORE as opposed to the support libraries. In a typical OSCORE
implementation COSE encrypt and signature structures will be implementation COSE encrypt and signature structures will be
available, as will support for COSE algorithms relevant for IoT available, as will support for COSE algorithms relevant for IoT
skipping to change at page 12, line 36 skipping to change at page 12, line 49
providing end-to-end security on application layer needs to comply providing end-to-end security on application layer needs to comply
with the duty cycle. with the duty cycle.
2.10.1.1. Bytes on the wire 2.10.1.1. Bytes on the wire
LoRaWAN has a variable MTU depending on the Spreading Factor (SF). LoRaWAN has a variable MTU depending on the Spreading Factor (SF).
The higher the spreading factor, the higher distances can be achieved The higher the spreading factor, the higher distances can be achieved
and/or better reception. If the coverage and distance allows it, and/or better reception. If the coverage and distance allows it,
with SF7 - corresponding to higher data rates - the maximum payload with SF7 - corresponding to higher data rates - the maximum payload
is 222 bytes. For a SF12 - and low data rates - the maximum payload is 222 bytes. For a SF12 - and low data rates - the maximum payload
is 51 bytes. is 51 bytes on data link layer.
The benchmark used here is Data Rates 0-2 corresponding to a packet The benchmark used here is Data Rates 0-2 corresponding to a packet
size of 51 bytes [LoRaWAN]. The use of larger frame size depend on size of 51 bytes [LoRaWAN]. The use of larger frame size depend on
good radio conditions which are not always present. Some libraries/ good radio conditions which are not always present. Some libraries/
providers only support 51-bytes packet size. providers only support 51-bytes packet size.
2.10.1.2. Time 2.10.1.2. Time
The time it takes to send a message over the air in LoRaWAN can be The time it takes to send a message over the air in LoRaWAN can be
calculated as a function of the different parameters of the calculated as a function of the different parameters of the
skipping to change at page 17, line 44 skipping to change at page 18, line 13
AKE frequency, a lightweight AKE: AKE frequency, a lightweight AKE:
* reduces the time for network formation and AKE runs in challenging * reduces the time for network formation and AKE runs in challenging
radio technologies, radio technologies,
* allows devices to quickly re-establish security in case of * allows devices to quickly re-establish security in case of
reboots, and reboots, and
* enables support for recommendations of frequent key renewal. * enables support for recommendations of frequent key renewal.
3. Requirements Summary 3. Security Considerations
* The AKE must support PSK, RPK and certificate based authentication
with PFS and crypto agility for AKE as well as OSCORE, have 3
flights and support transport over CoAP. It is required to
support different schemes for transporting and identifying
credentials.
* After the AKE run, the peers must be mutually authenticated, agree
on a shared secret with PFS and good amount of randomness, peer
identifiers (potentially short), and COSE algorithms to use.
* The AKE must reuse CBOR, CoAP and COSE primitives and algorithms
for low code complexity and to avoid duplicate maintenance of a
combined OSCORE and AKE implementation.
* The messages should be as small as reasonably achievable. The
messages shall fit into as few LoRaWAN packets and 6TiSCH frames
as possible.
4. Security Considerations
This document compiles the requirements for an AKE and provides some This document compiles the requirements for an AKE and provides some
related security considerations. related security considerations.
The AKE must provide the security properties expected of IETF The AKE must provide the security properties expected of IETF
protocols, e.g., providing mutual authentication, confidentiality, protocols, e.g., providing mutual authentication, confidentiality,
and negotiation integrity as is further detailed in the requirements. and negotiation integrity as is further detailed in the requirements.
5. IANA Considerations 4. IANA Considerations
None. None.
Acknowledgments Acknowledgments
The authors want to thank Richard Barnes, Karthik Bhargavan, Ivaylo The authors want to thank Richard Barnes, Karthik Bhargavan, Stephen
Petrov, Eric Rescorla, Michael Richardson, and Claes Tidestav for Farrell, Ivaylo Petrov, Eric Rescorla, Michael Richardson, Jesus
providing valuable input. Sanchez-Gomez, and Claes Tidestav for providing valuable input.
Informative References Informative References
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[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>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967, No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>. August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Constrained Join Protocol (CoJP) for 6TiSCH", Work in "Constrained Join Protocol (CoJP) for 6TiSCH", Work in
Progress, Internet-Draft, draft-ietf-6tisch-minimal- Progress, Internet-Draft, draft-ietf-6tisch-minimal-
security-15, 10 December 2019, <http://www.ietf.org/ security-15, 10 December 2019, <http://www.ietf.org/
internet-drafts/draft-ietf-6tisch-minimal-security- internet-drafts/draft-ietf-6tisch-minimal-security-
15.txt>. 15.txt>.
[I-D.ietf-lpwan-coap-static-context-hc] [I-D.ietf-lpwan-coap-static-context-hc]
Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static
skipping to change at page 19, line 39 skipping to change at page 19, line 52
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", Work in Progress, Request-Tag, and Token Processing", Work in Progress,
Internet-Draft, draft-ietf-core-echo-request-tag-08, 4 Internet-Draft, draft-ietf-core-echo-request-tag-08, 4
November 2019, <http://www.ietf.org/internet-drafts/draft- November 2019, <http://www.ietf.org/internet-drafts/draft-
ietf-core-echo-request-tag-08.txt>. ietf-core-echo-request-tag-08.txt>.
[I-D.irtf-cfrg-randomness-improvements] [I-D.irtf-cfrg-randomness-improvements]
Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security and C. Wood, "Randomness Improvements for Security
Protocols", Work in Progress, Internet-Draft, draft-irtf- Protocols", Work in Progress, Internet-Draft, draft-irtf-
cfrg-randomness-improvements-09, 27 January 2020, cfrg-randomness-improvements-10, 17 February 2020,
<http://www.ietf.org/internet-drafts/draft-irtf-cfrg- <http://www.ietf.org/internet-drafts/draft-irtf-cfrg-
randomness-improvements-09.txt>. randomness-improvements-10.txt>.
[I-D.selander-ace-ake-authz] [I-D.selander-ace-ake-authz]
Selander, G., Mattsson, J., Vucinic, M., and M. Selander, G., Mattsson, J., Vucinic, M., and M.
Richardson, "Lightweight Authorization for Authenticated Richardson, "Lightweight Authorization for Authenticated
Key Exchange.", Work in Progress, Internet-Draft, draft- Key Exchange.", Work in Progress, Internet-Draft, draft-
selander-ace-ake-authz-00, 6 February 2020, selander-ace-ake-authz-00, 6 February 2020,
<http://www.ietf.org/internet-drafts/draft-selander-ace- <http://www.ietf.org/internet-drafts/draft-selander-ace-
ake-authz-00.txt>. ake-authz-00.txt>.
[AKE-for-6TiSCH] [AKE-for-6TiSCH]
skipping to change at page 20, line 22 skipping to change at page 20, line 35
[NB-IoT-battery-life-evaluation] [NB-IoT-battery-life-evaluation]
"On mMTC, NB-IoT and eMTC battery life evaluation", "On mMTC, NB-IoT and eMTC battery life evaluation",
January 2017, January 2017,
<http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_AH/ <http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_AH/
NR_AH_1701/Docs//R1-1701044.zip>. NR_AH_1701/Docs//R1-1701044.zip>.
[HKDF] Krawczyk, H., "Cryptographic Extraction and Key [HKDF] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", May 2010, Derivation: The HKDF Scheme", May 2010,
<https://eprint.iacr.org/2010/264.pdf>. <https://eprint.iacr.org/2010/264.pdf>.
[IANA-COSE-Algorithms]
"COSE Algorithms", March 2020,
<https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>.
[LwM2M] "OMA SpecWorks LwM2M", August 2018, [LwM2M] "OMA SpecWorks LwM2M", August 2018,
<http://www.openmobilealliance.org/release/LightweightM2M/ <https://www.openmobilealliance.org/release/
V1_1-20180710-A/OMA-TS-LightweightM2M_Transport- LightweightM2M/V1_1-20180710-A/OMA-TS-
V1_1-20180710-A.pdf>. LightweightM2M_Transport-V1_1-20180710-A.pdf>.
[Fairhair] "Security Architecture for the Internet of Things (IoT) in [Fairhair] "Security Architecture for the Internet of Things (IoT) in
Commercial Buildings, Fairhair Alliance white paper", Commercial Buildings, Fairhair Alliance white paper",
March 2018, <https://www.fairhair- March 2018, <https://openconnectivity.org/wp-
alliance.org/data/downloadables/1/9/ content/uploads/2019/11/fairhair_security_wp_march-
fairhair_security_wp_march-2018.pdf>. 2018.pdf>.
[LoRaWAN] "LoRaWAN Regional Parameters v1.0.2rB", February 2017, [LoRaWAN] "LoRaWAN Regional Parameters v1.0.2rB", February 2017,
<https://lora-alliance.org/resource-hub/lorawantm- <https://lora-alliance.org/resource-hub/lorawantm-
regional-parameters-v102rb>. regional-parameters-v102rb>.
[LAKE-WG] "LAKE WG", March 2020,
<https://datatracker.ietf.org/wg/lake/about/>.
[KCI] Hlauschek et al, ., "Selfie:KCI attacks against TLS",
August 2015,
<https://www.usenix.org/system/files/conference/woot15/
woot15-paper-hlauschek.pdf>.
[Misbinding]
Sethi et al, ., "Misbinding Attacks on Secure Device
Pairing and Bootstrapping", May 2019,
<https://arxiv.org/pdf/1902.07550.pdf>.
[Selfie] Drucker, N. and S. Gueron, "Selfie:Reflections on TLS 1.3
with PSK", March 2019, <https://eprint.iacr.org/2019/347>.
Authors' Addresses Authors' Addresses
Malisa Vucinic Malisa Vucinic
Inria Inria
Email: malisa.vucinic@inria.fr Email: malisa.vucinic@inria.fr
Goeran Selander Goeran Selander
Ericsson AB Ericsson AB
 End of changes. 40 change blocks. 
98 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/