|
| Lightweight Machine to Machine Device Vanilla Bootstrap in Cellular Networks |
| Draft Version: 1.0 - 2022-01-18 |
| Open Mobile Alliance |
| OMA-WID-LightweightM2M_Device_Vanilla_Bootstrap_in_Cellular_Networks-20220118-D |
| tech_spec: 22 Feb 2022 15:27:00 rev: 428a1bb |
Use of this document is subject to all of the terms and conditions of the Use Agreement located at https://www.omaspecworks.org/about/policies-and-terms-of-use/.
Unless this document is clearly designated as an approved specification, this document is a work in process, is not an approved Open Mobile Alliance™ specification, and is subject to revision or removal without notice.
You may use this document or any part of the document for internal or educational purposes only, provided you do not modify, edit or take out of context the information in this document in any manner. Information contained in this document may be used, at your sole risk, for any purposes. You may not use this document in any other manner without the prior written permission of the Open Mobile Alliance. The Open Mobile Alliance authorizes you to copy this document, provided that you retain all copyright and other proprietary notices contained in the original materials on any copies of the materials and that you comply strictly with these terms. This copyright permission does not constitute an endorsement of the products or services. The Open Mobile Alliance assumes no responsibility for errors or omissions in this document.
Each Open Mobile Alliance member has agreed to use reasonable endeavors to inform the Open Mobile Alliance in a timely manner of Essential IPR as it becomes aware that the Essential IPR is related to the prepared or published specification.
However, the members do not have an obligation to conduct IPR searches. The declared Essential IPR is publicly available to members and non-members of the Open Mobile Alliance and may be found on the “OMA IPR Declarations” list at https://www.omaspecworks.org/about/intellectual-property-rights/. The Open Mobile Alliance has not conducted an independent IPR review of this document and the information contained herein, and makes no representations or warranties regarding third party IPR, including without limitation patents, copyrights or trade secret rights. This document may contain inventions for which you must obtain licenses from third parties before making, using or selling the inventions. Defined terms above are set forth in the schedule to the Open Mobile Alliance Application Form.
NO REPRESENTATIONS OR WARRANTIES (WHETHER EXPRESS OR IMPLIED) ARE MADE BY THE OPEN MOBILE ALLIANCE OR ANY OPEN MOBILE ALLIANCE MEMBER OR ITS AFFILIATES REGARDING ANY OF THE IPR’S REPRESENTED ON THE “OMA IPR DECLARATIONS” LIST, INCLUDING, BUT NOT LIMITED TO THE ACCURACY, COMPLETENESS, VALIDITY OR RELEVANCE OF THE INFORMATION OR WHETHER OR NOT SUCH RIGHTS ARE ESSENTIAL OR NON-ESSENTIAL.
THE OPEN MOBILE ALLIANCE IS NOT LIABLE FOR AND HEREBY DISCLAIMS ANY DIRECT, INDIRECT, PUNITIVE, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES ARISING OUT OF OR IN CONNECTION WITH THE USE OF DOCUMENTS AND THE INFORMATION CONTAINED IN THE DOCUMENTS.
THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS.
Copyright 2024 Open Mobile Alliance.
Used with the permission of the Open Mobile Alliance under the terms set forth above.
| Concept | Value |
|---|---|
| Work Item Title: | Lightweight Machine to Machine Device Vanilla Bootstrapping in Cellular Network |
| Short Name: | LwM2M Vanilla Bootstrappring |
| Version: | 1.0 |
| Concept | Value |
|---|---|
| Existing Specifications Affected: | OMA-RD-LightweightM2M |
| OMA-TS-LightweightM2M_Core | |
| OMA-TS-LightweightM2M_Transport | |
| External Organizations Affected: | IETF |
| Any Other Impact | None |
| Document | Q1 | Q2 | Q3 | Q4 |
|---|---|---|---|---|
| Requirements Document | 03/2022 | 05/2022 | 07/2022 | 09/2022 |
| Architecture Document | 05/2022 | 07/2022 | 09/2022 | 10/2022 |
| Technical Specification(s) | 07/2022 | 09/2022 | 11/2022 | 12/2022 |
Note: enter only the target date by when the document will be completed by the Working Group
| Company Name | Membership Type |
|---|---|
| Nokia | Associate |
| Deliverable/Role | Volunteer |
|---|---|
| Enabler Editor | Colin Grealish (Nokia) |
The opportunity for use of LWM2M devices within Cellular networks is huge. This covers a range of applications, but is particularly appropriate in applications where a wide area network is required or roaming is needed. Cellular networks have a distinct advantage because they use Licensed spectrum which ensures a level of business case security over the lifetime of the device and associated service.
The advent of Low Power Networks for Cellular has also provided a new range of applications on a par with the unlicensed technologies such as WIZE, LoRaWAN and Sigfox.
LWM2M is a good fit for application on Cellular for a number of different reasons, these include:
One of the key reasons why LWM2M works well is that it is fully standardised right up to the data and application, this makes for a single design which creates efficiency for Mobile Device Manufacturers.
From a technical perspective, Devices on Cellular Networks are already secured using a SIM. This can be a hardware SIM card, similar to what is used in a mobile phone, but more commonly an electronic SIM that is integrated, or soldered into the Device, or complete software based SIM. But in all cases the Device has a secure identity already. This paper discusses the opportunity of re-using that SIM, but at the LWM2M level.
Setting up an individual device requires the insertion of data items such as security credentials and server URLs. When rolling this out across millions of devices across multiple manufacturers in a secure way this is not a trivial cost.
Different manufacturers may have to set up to different servers, this all requires coordination and has to be done in a way that does not risk compromise of the security. Often this is done with distributing spreadsheets. While more advanced solutions can use API based solutions, which can integrate in a secure end to end way, the integration of these systems is a cost.
Alternatively Public Key Encryption can be used. This is a well proven technology used throughout the internet for applications such a banking. In theory this can address many of the security issues, but in practice this only applies to devices that have enough bandwidth and resources to use Public Key Encryption. Many devices such as NB-IOT are too constrained to use it.
Setting up vanilla devices using the SIM card as a root of trust has been standardised and is widely used.
Client Provisioning is a standardised way of updating a Device with settings. Often this is simply the APN that the device is to use, but can also be email settings or OMA Device Management Bootstrap. OMA Client Provisioning supports the use of the IMSI of the SIM used by the Device to secure the provisioning.
When used with OMA Device Management this technique fully meets all the requirements herein. Unfortunately the OMA Device Management has not been fully optimised for IoT and does not have the rich set of capabilities that is inherent in OMA Lightweight M2M. Also SMS is not always deployed within Cellular IoT networks.
GSMA Rich Communications Suite provisioning use a Domain name that is automatically determined using the IMSI from the SIM card. The Domain name is made up of the MNC and MCC values combined with some other predefined strings. The DNS server within the network can then be setup to direct the request to a secure provisioning server at which point the credentials can then be retrieved.
To identify the cellular identity the device is using, HTTP header enrichment is used.
It is an entirely feasible that this type of solution can be for used with OMA LWM2M, although a method identifying a the cellular identity using COAP would have to be determined. HTTP header enrichment is not normally used for COAP.
3GPP Private Access Point Name Using a Private APN it is possible to control all access to a Device using VPN technology. Although this doesn't provide a full solution for setting up a vanilla device, it does provide a way of securing the access to a device to a trusted environment which can be part of the solution.
The LWM2M Enabler shall enable a Device to be LWM2M Bootstrapped without any settings inserted into the Device in a Cellular Network.
The LWM2M Enabler shall enable a Device to use a LWM2M session without any settings inserted into the Device in a Cellular Network.
The LWM2M Enabler shall enable a Device to be LWM2M Bootstrapped with only security settings inserted into the Device in a Cellular Network. This simplifies logistics as the Device can use a Public Key or other credentials that are not network specific.
The LWM2M Enabler shall enable a Device to be LWM2M session with only security settings inserted into the Device in a Cellular Network. This simplifies logistics as the Device can use a Public Key or other credentials that are not network specific.
The solution relies on the assumption that the Cellular network can be made implicitly secure. The use of Private APNs is one way of creating a secure environment for a device.
It is also desirable, but not essential that the cellular identity of any device connecting on the Cellular network can identified. The cellular identity can be the IMSI, MSISDN, External Identity, SUPI or GPSI.
To ensure security if the Device is relying on this security it should not allow this when roaming as this may not always be as secure. The Device should also not allow concurrent Cellular and Non-Cellular connections concurrently as this could also create insecurity.
The actual techniques of securing the network for the devices is assumed, but not defined herein.
Since the assumption is that the identification, authentication and encryption are secure, the crux of the requirement comes down to the technique of retrieving the remaining parameters used when accessing the LWM2M bootstrap server, the key data item being the URL of the server.
Two approaches are proposed.
The Dynamic Host Configuration Protocol (DHCP) is widely used for the retrieval of IP addresses and other settings,see DHCP Options and BOOTP Vendor Extensions.
Device DHCP Server
|------------------------>| At connection, the device looks up the DHCP settings
|<------------------------| The DHCP returns the URL of the LWM2M Bootstrap Server
| LWM2M Bootstrap Server
|------------------------>| The Device initiates a LWM2M Bootstrap with the URL provided by the DHCP server
| | The LWM2M Bootstrap server will authenticate the device with the SIM as the root of trust
|<------------------------| The LWM2M Bootstrap Server returns the Bootstrap information
This solution would require that a new vendor extension option code be provided that requests the LWM2M Server URI.
This could be used and is already part proposed by the IETF as Options for LWM2M bootstrap information. This would need to be completed.
The disadvantage of this solution is that the DHCP server would have to be able to support the vendor extensions and the mobile operator would have to setup the DHCP values. The actual range of values that can be reteived is also limited and any new parameters would involve liasing with the IETF, which for standards administration is cumbersome.
The Domain Name System (DNS) Protocol is widely used for the resolution of names to IP addresses in the IP.
The solution proposed would be very similar to what is used with GSMA Rich Communications Suite whereby the a very specific domain format is used.
This could be http://bsf.mnc
Device DNS Server
|------------------------>| At connection, the device looks up the IP of the Device using DNS. In this example the SIM used by the device uses IMSI
| | 313 460 000 000 001, which would mean URL http://bsf.mnc460.mcc313.LWM2M.org
|<------------------------| The DNS returns the domain of the LWM2M Bootstrap Server
| LWM2M Bootstrap Server
|------------------------>| The Device initiates a LWM2M Bootstrap with the URL provided by the DNS server
| | The LWM2M Bootstrap server will authenticate the device with the SIM as the root of trust
|<------------------------| The LWM2M Bootstrap Server returns the Bootstrap information
Thus when a device bootstrap it will use this URL and the local DNS will direct the request to a server in the local cellular network.
This is very easy to implement. The disadvantage being that the mobile operator would have to set up a local DNS entry. Also the solution is not very flexible in terms of ports to use and other URL items as its only the domain that can be provided by the DNS.