1. Introduction
Cette section conserve le texte RFC des SCIM device schema extensions, y compris Device and EndpointApp resource types, BLE, DPP, Ethernet MAB, FDO, Zigbee, endpointAppsExt, JSON Schema, OpenAPI, IANA registrations et security considerations.
1. Introduction
The Internet of Things presents a management challenge in many
dimensions. One of them is the ability to onboard and manage a large
number of devices. There are many models for bootstrapping trust
between devices and network deployments. Indeed, it is expected that
different manufacturers will make use of different methods.
The System for Cross-domain Identity Management (SCIM) [RFC7643]
[RFC7644] defines a protocol and a schema for the provisioning of
users. However, it can easily be extended to provision device
credentials and other attributes into a network. The protocol and
core schema were designed to permit just such extensions. Bulk
operations are supported. This is good because often devices are
procured in bulk.
A primary purpose of this specification is to provision the network
for onboarding and communications access to and from devices within a
local deployment based on the underlying capabilities of those
devices.
The underlying security mechanisms of some devices range from non-
existent such as the Bluetooth Low Energy (BLE) "Just Works" pairing
method to a robust FIDO Device Onboard (FDO) mechanism. Information
from the SCIM server is dispatched to control functions based on
selected schema extensions to enable these communications within a
network. The SCIM database is therefore essentially equivalent to a
network's Authentication, Authorization, and Accounting (AAA)
database and should be carefully managed as such.
1.1. Why SCIM for Devices?
There are a number of existing models that might provide the basis
for a scheme for provisioning devices onto a network, including two
standardized by the IETF: NETCONF [RFC6241] or RESTCONF [RFC8040]
with YANG [RFC7950]. SCIM was chosen for the following reasons:
* NETCONF and RESTCONF focus on *configuration* rather than
provisioning.
* SCIM is designed with inter-domain provisioning in mind. The use
of HTTP as a substrate permits both user-based authentication for
local provisioning applications, as well as OAUTH or certificate-
based authentication. The inter-domain nature of these operations
does not expose local policy, which itself must be (and often is)
configured with other APIs, many of which are not standardized.
* SCIM is also a familiar tool within the enterprise environment,
used extensively to configure federated user accounts.
* Finally, once one chooses a vehicle such as SCIM, one is beholden
to its data model. The SCIM data model is more targeted to
provisioning as articulated in [RFC7643].
This taken together with the fact that end devices are not intended
to be *directly* configured leaves us with SCIM as the best standard
option.
1.2. Protocol Participants
In the normal SCIM model, it was presumed that large federated
deployments would be SCIM clients who provision and remove employees
and contractors as they enter and depart those deployments, and
federated services such as sales, payment, or conferencing services
would be the servers.
In the device model, the roles are reversed and may be somewhat more
varied. The SCIM server resides within a deployment and is used for
receiving information about devices that are expected to be connected
to its network. That server will apply appropriate local policies
regarding whether/how the device should be connected.
The client may be one of a number of entities:
* A vendor who is authorized to add devices to a network as part of
a sales transaction. This is similar to the sales integration
sometimes envisioned by Bootstrapping Remote Secure Key
Infrastructure (BRSKI) [RFC8995].
* A client application that administrators or employees use to add,
remove, or get information about devices. An example might be a
tablet or phone app that scans Wi-Fi Easy Connect QR codes.
+-----------------------------------+
| |
+-----------+ Request | +---------+ |
| Onboarding|------------->| SCIM | |
| App |<-------------| Server | |
+-----------+ Ctrl Endpt +---------+ |
| | |
| |(Device Info) |
| v |
+-----------+ | +------------+ +-------+ |
| Control |...........|..| ALG |.........|Device | |
| App | | +------------+ +-------+ |
+-----------+ | |
| Local Network |
+-----------------------------------+
Figure 1: Basic Architecture - Non-IP Example
In Figure 1, the onboarding application (app) provides the device
particulars, which will vary based on the type of device, as
indicated by the selection of schema extensions. As part of the
response, the SCIM server might provide additional information,
especially in the case of non-IP devices, where an application-layer
gateway may need to be used to communicate with the device (c.f.,
[NIPC]). The control endpoint is one among a number of objects that
may be returned. That control endpoint will then communicate with
the Application Layer Gateway (ALG) to reach the device.
+------------------------------------+
| |
+-----------+ Request | +---------+ +----+ +------+ |
| Onboarding|------------->| SCIM |-->| AAA|<-->|Switch| |
| App |<-------------| Server | +----+ +------+ |
+-----------+ Ctrl Endpt +---------+ | |
| | |
+-----------+ | +------------+ +-------+ |
| Control |...........|..| Router/fw |.........|Device | |
| App | | +------------+ +-------+ |
+-----------+ | |
| Local Network |
+------------------------------------+
Figure 2: Interaction with AAA
Figure 2 shows how IP-based endpoints can be provisioned. In this
case, the onboarding application provisions a device via SCIM. The
necessary information is passed to the Authentication, Authorization,
and Accounting (AAA) subsystem, such that the device is permitted to
connect. Once it is online, since the device is based on IP, it will
not need an ALG, but it will use the normal IP infrastructure to
communicate with its control application.
1.3. Schema Description
[RFC7643] does not prescribe a language to describe a schema but
instead uses a narrative description with examples. We follow that
approach. In addition, we provide non-normative JSON Schemas
[JSONSchema] and OpenAPI [OpenAPI] versions in the appendices for
ease of implementation, neither of which existed when SCIM was
originally developed. The only difference the authors note between
the normative schema representations is that the JSON Schemas and
OpenAPI versions do not have a means to express case sensitivity, and
thus attributes that are not case sensitive must be manually
validated.
Several additional schemas specify specific onboarding mechanisms,
such as Bluetooth Low Energy (BLE) [BLE54], Wi-Fi Easy Connect
[DPP2], and FIDO Device Onboard [FDO11].
When JSON is presented in this memo, it is folded in accordance with
[RFC8792].
1.4. Schema Representation
Attributes defined in the device core schema (see Section 2.2 of
[RFC7643]) and extensions comprise characteristics and the SCIM
datatypes (defined in Section 2.3 of [RFC7643]). This specification
does not define new characteristics and datatypes for the SCIM
attributes.
1.5. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The reader is also expected to be familiar with the narrative schema
language used in [RFC7643].