- This XEP relies on &xep0323; and &xep0325; for sensor data readout and control interfaces. - Internet of Things contain many different architectures and use cases. For this reason, the IoT standards have been divided into multiple XEPs according to the following table: -
+ This XEP relies on &xep0323; and &xep0325; for sensor data readout and control interfaces. It relies on &xep0326; for bridging protocols and interfaing entities with multiple devices + behind them. It also ties into &xep0347; for automatic discovery of provisioning servers by things. + ++ Internet of Things contain many different architectures and use cases. For this reason, the IoT standards have been divided into multiple XEPs according to the following table: +
| XEP | @@ -139,10 +161,6 @@xep-0000-IoT-BatteryPoweredSensors | Defines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network. |
|---|---|---|
| xep-0000-IoT-Discovery | -Defines the peculiars of Thing discovery in Internet of Things. Apart from discovering Things by JID, it also defines how to discover Things based on location, etc. | -|
| xep-0000-IoT-Events | Defines how Things send events, how event subscription, hysteresis levels, etc., are configured. | @@ -166,7 +184,7 @@|
| XEP-0322 | - Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not a Internet of Things specific XEP, this XEP should be considered + Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not an Internet of Things specific XEP, this XEP should be considered in all Internet of Things implementations where memory and packet size is an issue. | XEP-0336 | Defines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;. | +
| XEP-0347 | +Defines the peculiars of sensor discovery in sensor networks. Apart from discovering sensors by JID, it also defines how to discover sensors based on location, etc. | +
- Trust is delegated to a provisioning server by a device, simply by befriending the provisioning server and asking it questions and complying with - its answers. -
-- As an illustrative example, following is a short description of how such a trust relationship can be created in a scenario where the sensor only - has a single LED and a single button. -
++ A provisioning server can be accessed either through a JID published by the provisioning server, or through a subdomain address, if hosted as a server component. + This section will show how to delegate original trust to a Provisioning Server, in the case the server uses a JID to communicate with things. +
++ Trust is delegated to a provisioning server by a device, simply by befriending the provisioning server and asking it questions and complying with + its answers. As an illustrative example, following is a short description of how such a trust relationship can be created in a scenario where the sensor only + has a single LED and a single button. +
- Somebody is installing the sensor, giving it a connection to an XMPP server and a JID, reachable from the provisioning server.
- The provisioning server is told to create a friendship request to the new sensor. @@ -409,48 +432,243 @@ The following diagram shows the general case:
- 
-
+
The successful case can also be illustrated in a sequence diagram, as follows:
- The following example shows how a device can request a device token from the provisioning server: -
-+ Note 2: A certificate token has an undefined lifetime. It can be reused across sessions. +
++ The following use cases will assume such a trust relationship has been created between the corresponding device and the provisioning server. +
++ A provisioning server can also be hosted as a server component, and in these cases be addressed by using the component address, or sub-domain address of the component. + In this case, the client searches through the components hosted by the server to see if one of them is a Provisioning Server. There are no friendship requests and + presence subscriptions necessary, when communicating with a Provisioning Server hosted as a server component. +
++ To search for a Provisioning Server hosted as a component on an XMPP Server, you first request a list of available components, as follows: +
++ If components (items) are supported, a request for available components is made: +
++ The client then loops through all components (items) and checks what features they support, until a Provisioning Server is found: +
+- The provisioning server must not return tokens that contain white space characters. -
-- Note: In many cases, an address to a provisioning server might be preprogrammed during production of the - device. In these cases, parts of the above procedure may not be necessary. All the client needs to do, if the provisioning server is not available - in the roster of the device, is to send a subscription request to the provisioning server, to alert the server of the existence of the device, - and possibly request a device token. -
-- The following use cases will assume such a trust relationship has been created between the corresponding device and the provisioning server. -
-+ +
+ The provisioning server contains a set of rules defining what operation can take place and by whom, by participants in the network. Rules can be applied based on JIDs used, + content affected, and also through device, service and user identities based on X.509 Certificates. In order for a service (for instance) to identify itself in the network, it + uses an X.509 certificate. It sends the public part of this certificate to the provisioning server, and receives a token back in the form of a simple string. This token can then + be used in requests and propagated through the network. +
++ To validate that the sender is allowed to use the certificate using its token, it encrypts a challenge using the public part of the certificate and sends it to the sender of the + token, who in turn decrypts it using the private part of the certificate and returns it to the server. The provisioning server can also use the public part of the certificate to + perform validation checks on the certificate itself. If the certificate becomes invalid, the provisioning server can invalidate any corresponding rules in the network. If the sender + of a token cannot respond to a token challenge, the provisioning server can also refuse to allow the operation. +
++ In case of multiple units being part of an operation, a token can be propagated in the network. For example, a service can read data from U1, who reads data from U2. The service + provides a token to U1, who propagates this token in the request to U2. When U2 asks the provisioning server if the operation should be allowed or not, the server knows what entity + originated the request. If the provisioning server wants to challenge U2, concerning the token, U2 propagates the challenge to U1, who propagates it to the service, who can resolve + the challenge, returns the response back to U1 who returns the response to U2 who in turn returns it to the provisioning server. +
+
+ 
+
+ The following example shows how a device or service can request a token from the provisioning server, by providing the base-64 encoded public part of an X.509 certificate. + This step is optional, but can be used as a method to identify the device (or service), apart from the JID it is using. This might be useful if you want to assign a particular + device or service privileges in the provisioning server, regardless of the JID it uses to perform the action. +
++ The getToken element contains the base-64 encoded public version of the certificate that is used to identify the device or service. The server + responds with a challenge in a getTokenChallenge response. This challenge is also a base-64 encoded binary block of data, which corresponds to a random + sequence of bytes that is then encrypted using the public certificate. Now, the device, or service, decrypts this challenge using the private part of the certificate, and + returns the base-64 encoded decrypted version of the challenge back to the provisioning server using the getTokenChallengeResponse element. The provisioning + server checks the response to the original random sequence of bytes. If equal, the provisioning server responds with a getTokenResponse result, containing + the token (a string this time) that can be used when reference to the identity defined by the certificate has to be made. The provisioning server must not return tokens that + contain white space characters. +
++ If the response to the challenge is wrong, the server returns a bad-request error result, as is shown below. +
++ If the sequence number identifying the challenge is not found on the server, the server returns a item-not-found error result, as is shown below. +
++ The server must retain the challenge in memory for at least one minute before assuming the challenge will go unresponded. +
++ For reasons the provisioning server determines, it can challenge the use of a token in any of the requests made to it. This is done by sending a + iq get stanza with a tokenChallenge to the party sending the token. This element contains both the token being challenged, and a binary + challenge. This challenge is made up of a random block of data that is encrypted using the public certificate referred to by the token. +
++ The receiver of the challenge, if it has access to the private certificate referenced, decrypts the challenge, and returns the decrypted binary block of data + to the caller (i.e. the Provisioning Server in this case). If the decrypted block of data corresponds to the original random block of data encrypted, the sender + of the token is considered to be allowed to use the token. +
++ If the received of the challenge does not have access to the private certificate referenced, but used the token in a propagated request made to it, it can propagate the + request to the original sender of the token. When the response is returned, it returns the response in turn to the sender of the challenge. +
++ A challenge/response sequence can look as follows: +
++ Note: It is important that a unit only responds to a tokenChallenge request from a JID to which the corresponding token + has been sent. If a token challenge is received from a JID to which the token has not been sent the last minute, the following error message must be returned: +
+
The isFriendResponse element returned by the provisioning server contains an attribute secondaryTrustAllowed that is by default
set to false. If the provisioning server has no problem with allowing multiple trust to be delegated by devices in the network, it can choose to set this
attribute to true in the response. If true, the device knows it has the right to add its own friends, or to add secondary trust relationships.
@@ -463,8 +681,8 @@
+
When multiple trust is used, the entity (client, user, service, etc.) has one token from each provisioning server. However, when sending a token to a third party,
the sender does not know what provisioning server(s) the third party uses to check access rights and user privileges. Therefore, the client must send all tokens, separated
by a space.
@@ -477,36 +695,39 @@
+
+ Note: When a provisioning server wants to challenge multiple tokens, separate token challenges are sent, one for each token being challenged. +
+The following diagram displays how a friendship request from an external party can be handled, delegating the responsibility to a trusted third party:
@@ -519,15 +740,15 @@
+ to='provisioning.clayster.com'
+ id='9'>
+
The following diagram displays a friendship request from an external party being rejected as a result of the trusted third party negating the friendship:
@@ -553,21 +774,21 @@
+ to='provisioning.clayster.com'
+ id='10'>
+
If the provisioning server decides that two friends in the network should no longer be friends and communicate with each other, it simply sends a message to
at least one of the friends as follows:
+
The provisioning server can, apart from accepting new friendships and rejecting old friendships, also recommend new friendships. In this case, the provisioning server
simply sends a message to one or both of the soon to be friends, as follows:
+
An important use case for provisioning in sensor networks is who gets to read out sensor data from which sensors. This use case details how communication with a
provisioning server can help the device determine if a client has sufficient access rights to read the values of the device.
+
In case the device handles multiple nodes that can be read, the provisioning server has the possibility to grant read-out, but to limit the nodes that can be read out.
The provisioning server does this by returning the list of nodes that can be read.
+
In case the provisioning server wants to limit the fields a device can send to a client, the provisioning server has the possibility to grant read-out, but
list a set of fields the device is allowed to send to the corresponding client.
+
An important use case for provisioning in sensor networks is who gets to control devices, and what they can control. This use case details how communication with a
provisioning server can help the device determine if a client has sufficient access rights to perform control actions on the device.
+
In case the device handles multiple nodes that can be read, the provisioning server has the possibility to grant control access, but to limit the nodes that can be controlled.
The provisioning server does this by returning the list of nodes that can be controlled.
In case the provisioning server wants to limit the control parameters a client can control in a device, the provisioning server has the possibility to grant
control access, but list a set of parameters the client is allowed to control in the corresponding device.
@@ -927,7 +1148,7 @@
+
When the provisioning server updates access rights and user privileges in the system, it will send a clearCache command to corresponding devices.
If a device was offline during the change, the provisioning server must send the clearCache message when the device comes online again. To acknowledge
the receipt of the command, the client responds with a clearCacheResponse element. This response message does not contain any information on what was
@@ -1007,43 +1228,58 @@
- A service requesting provisioning assistance, needs to retrieve a service token from the provisioning server. The following example shows how this can be done.
-
@@ -1138,9 +1374,9 @@
+
When a user has been given access to a service, and properly been identified, the service can ask the provisioning service for detailed user privileges to control
different aspects of the service. This can be done using the hasPrivilege command. Here, the service sends its serviceToken and
the userToken earlier received when being granted access to the service. Furthermore a privilegeId has to be provided.
@@ -1236,23 +1472,23 @@
+
To improve performance, services can download the entire set of user privileges, and perform privilege checks internally. The following diagram displays
how the above two use cases could be handled in such a case:
If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:iot:provisioning" in response to &xep0030; information requests.
-+ If an entity is a Provisioning Server and supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:iot:provisioning" + in response to &xep0030; information requests. +
++ A client must treat the connection between a Provisioning Server differently if it is hosted as a client, having a JID, or if it is hosted as a Jabber Server Component. + If it is hosted as a server component, there's no need for the thing to become friends with the Provisioning Server. Messages and requests can be made directly to the + server component without having to add it to the roster or request presence subscriptions. If the Provisioning Server is hosted as a client, having a JID (@ in the address), + the Provisioning Server must be added to the roster of the client before the client can communicate with the Provisioning Server. +
+To minimize network traffic, and optimize response time, devices should cache access rights and user privileges provided by the provisioning server. If memory is limited, items in the cache should be ordered by last access, and items with the oldest last access timestamp should be removed first. A safety valve can optionally be implemented as well, @@ -1370,8 +1617,8 @@ not persisting its cache may produce too much stress on the provisioning server on start-up, practically removing it from the network.
+
When working with multiple provisioning servers, there are some things that should be considered:
+
One important design consideration when implementing a provisioning server is how to handle new services, users and privileges. One option might be to automatically
ignore anything not recognized. Another option might be to dynamically add new services, user names and privileges to internal data sources, making it easier to manage
new types of services dynamically. However, adding such items automatically might also make such data sources grow beyond control.
+
All examples in this document have been simplified examples where a few devices containing a few fields have been read. However, in many cases large subsystems with
very many sensors containing many fields have to be read, as is documented in Internet of Things - Concentrators
Internet of Things - Concentrators. In such cases, a node may have to be specified using two or perhaps
@@ -1416,8 +1663,8 @@
If there is ambiguity in the request, the receptor must treat the request as a request with a set of nodes, all with the corresponding nodeId as requested.
+
A small note regarding the use of different tokens. A service can get a Service Token, a device a Device Token and a user
a User Token. When delegating these tokens to third parties, a service sends its Service Token. But, if the service does this
within the context of a user action, the service sends both its Service Token and the users User Token. The same with a device.
@@ -1426,31 +1673,39 @@
@@ -1395,15 +1642,15 @@
- Delegating trust to a third party may create a weak link in the overall security of a sensor network. Therefore, it's vitally important that the following be adhered to: -
--
-
- - Trust should only be delegated in a secure way. Once delegated, it should be able to lock this trust so it cannot be changed without reverting the device to - factory default settings. Such a locked delegation mode can be likened with a production mode, where vital configuration parameters should not be able to be changed. - -
- - If allowing installation using a LED, as above, make sure the LED does not light up for a long time, limiting the window of access where the sensor can be linked to a - provisioning server. - -
- - Provisioning servers should be monitored during operation, since it provides a vital link in the operation of the network. - -
- - Multiple provisioning servers could be allowed, for redundancy or for scalability. This specification does not limit the number of provisioning servers used in a network, - not used by a device. Examples in this specification use only one provisioning server for simplicity. - -
- - Generally, take care what kind of provisioning servers you allow in a network. - -
+ Delegating trust to a third party may create a weak link in the overall security of a sensor network. Therefore, it's vitally important that the following be adhered to: +
+-
+
- + Trust should only be delegated in a secure way. Once delegated, it should be able to lock this trust so it cannot be changed without reverting the device to + factory default settings. Such a locked delegation mode can be likened with a production mode, where vital configuration parameters should not be able to be changed. + +
- + If allowing installation using a LED, as above, make sure the LED does not light up for a long time, limiting the window of access where the sensor can be linked to a + provisioning server. + +
- + Provisioning servers should be monitored during operation, since it provides a vital link in the operation of the network. + +
- + Multiple provisioning servers could be allowed, for redundancy or for scalability. This specification does not limit the number of provisioning servers used in a network, + not used by a device. Examples in this specification use only one provisioning server for simplicity. + +
- + Generally, take care what kind of provisioning servers you allow in a network. + +
+ When receiving token challenges from somebody, make sure you've sent the corresponding token to the corresponding party less than a minute before receiving the token + challenge. If not, the token challenge might represent a malicious attempt by somebody else to use the token to gain privileges in the network otherwise not enjoyed. +
+This document requires no interaction with &IANA;.