XEP-0324: Internet of Things - Provisioning
|
|
- Eugene Richard
- 8 years ago
- Views:
Transcription
1 XEP-0324: Internet of Things - Provisioning Peter Waher mailto:peterwaher@hotmail.com xmpp:peter.waher@jabber.org Version 0.4 Status Type Short Name Experimental Standards Track sensor-network-provisioning This specification describes an architecture for efficient provisioning of services, access rights and user privileges in for the Internet of Things, where communication between Things is done using the XMPP protocol.
2 Legal Copyright This XMPP Extension Protocol is copyright by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the Specification ), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an AS IS BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## Liability In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. Conformance This XMPP Extension Protocol has been contributed in full conformance with the XSF s Intellectual Property Rights Policy (a copy of which can be found at < pr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO USA).
3 Contents 1 Introduction 1 2 Glossary 2 3 Use Cases Delegating trust Delegating original trust to a Provisioning Server Provisioning Server as a server component Tokens and X.509 Certificates Delegating Secondary Trust Multiple tokens Friendships Friendship request accepted Friendship request rejected Unfriending existing friends Recommending friendships Device Read-out Rejecting read-outs Restricting nodes during read-out Restricting fields during read-out Device Control Rejecting control actions Restricting nodes during control Restricting parameters during control Cache Clear cache Services Getting a service token User access to service User privileges User privileges in service Download all user privileges Determining Support 40 5 Implementation Notes JID vs Component Provisioning Servers Caching and cache time Working with multiple provisioning servers Automatic aggregation of services, users and privileges Reading devices from large subsystems Different types of tokens
4 6 Security Considerations Trust Delegation Token Challenges IANA Considerations 43 8 XMPP Registrar Considerations 43 9 XML Schema For more information Acknowledgements 51
5 1 INTRODUCTION 1 Introduction This specification describes an architecture for efficient provisioning of services, access rights and user privileges in for the Internet of Things, where communication between Things is done using the XMPP protocol. Note has to be taken, that this XEP, and other Internet of Things-related XEP s, are designed for implementation in small devices, many of which have very limited amount of memory (both RAM and ROM) or resources (processing power). Therefore, simplicity is of utmost importance. Furthermore, Internet of Things networks can become huge, easily containing millions or billions of devices in peer-to-peer networks. An added complexity in the provisioning case is that Things (small sensors for example) often have very limited user interface options. Therefore, this document explains how provisioning can be done efficiently using a trusted third party with more power and options when it comes to user interface design and storage. This document defines the following important operations to allow for efficient provisioning of services in the Internet of Things, based on XMPP: What Things knows what Things What Things can read data from what Things, and what data. What Things can control what Things, and what parts. Control of Users in the network. Control of Services in the network. Control generic boolean User Privileges in the network. This XEP relies on Internet of Things - Sensor Data (XEP-0323) 1 and Internet of Things - Control (XEP-0325) 2 for sensor data readout and control interfaces. It relies on Internet of Things - Concentrators (XEP-0326) 3 for bridging protocols and interfaing entities with multiple devices behind them. It also ties into Internet of Things - Discovery (XEP-0347) 4 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: 1 XEP-0323: Internet of Things - Sensor Data < 2 XEP-0325: Internet of Things - Control < 3 XEP-0326: Internet of Things - Concentrators < 4 XEP-0347: Internet of Things - Discovery < 1
6 1 INTRODUCTION XEP xep-0000-iot-batterypoweredsensors xep-0000-iot-events xep-0000-iot-interoperability xep-0000-iot-multicast xep-0000-iot-pubsub xep-0000-iot-chat XEP-0322 XEP-0323 XEP-0324 XEP-0325 XEP-0326 Description Defines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network. Defines how Things send events, how event subscription, hysteresis levels, etc., are configured. Defines guidelines for how to achieve interoperability in Internet of Things, publishing interoperability interfaces for different types of devices. Defines how sensor data can be multicast in efficient ways. Defines how efficient publication of sensor data can be made in Internet of Things. Defines how human-to-machine interfaces should be constructed using chat messages to be user friendly, automatable and consistent with other IoT extensions and possible underlying architecture. 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. Provides the underlying architecture, basic operations and data structures for sensor data communication over XMPP networks. It includes a hardware abstraction model, removing any technical detail implemented in underlying technologies. This XEP is used by all other Internet of Things XEPs. This specification. Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented. Defines how to control actuators and other devices in Internet of Things. Defines how to handle architectures containing concentrators or servers handling multiple Things. XEP-0331 Defines extensions for how color parameters can be handled, based on Data Forms (XEP-0004) XEP-0004: Data Forms < 2
7 2 GLOSSARY XEP Description XEP-0336 Defines extensions for how dynamic forms can be created, based on Data Forms (XEP-0004) XEP-0004: Data Forms < html>., Data Forms Validation (XEP- 0122) XEP-0122: Data Forms Validation < Publishing Stream Initiation Requests (XEP-0137) XEP-0137: Publishing Stream Initiation Requests < and Data Forms Layout (XEP-0141) XEP-0141: Data Forms Layout < html>.. 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. 2 Glossary The following table lists common terms and corresponding descriptions. Actuator Device containing at least one configurable property or output that can and should be controlled by some other entity or device. Authority Used synonymously with Provisioning Server. Computed Value A value that is computed instead of measured. Concentrator Device managing a set of devices which it publishes on the XMPP network. Field One item of sensor data. Contains information about: Node, Field Name, Value, Precision, Unit, Value Type, Status, Timestamp, Localization information, etc. Fields should be unique within the triple (Node ID, Field Name, Timestamp). Field Name Name of a field of sensor data. Examples: Energy, Volume, Flow, Power, etc. Field Type What type of value the field represents. Examples: Momentary Value, Status Value, Identification Value, Calculated Value, Peak Value, Historical Value, etc. Historical Value A value stored in memory from a previous timestamp. 3
8 2 GLOSSARY Identification Value A value that can be used for identification. (Serial numbers, meter IDs, locations, names, etc.) Localization information Optional information for a field, allowing the sensor to control how the information should be presented to human viewers. Meter A device possible containing multiple sensors, used in metering applications. Examples: Electricity meter, Water Meter, Heat Meter, Cooling Meter, etc. Momentary Value A momentary value represents a value measured at the time of the readout. Node Graphs contain nodes and edges between nodes. In Internet of Things, sensors, actuators, meters, devices, gateways, etc., are often depicted as nodes whereas links between sensors (friendships) are depicted as edges. In abstract terms, it s easier to talk about a Node, rather than list different possible node types (sensors, actuators, meters, devices, gateways, etc.). Each Node has a Node ID. Node ID An ID uniquely identifying a node within its corresponding context. If a globally unique ID is desired, an architecture should be used using a universally accepted ID scheme. Parameter Readable and/or writable property on a node/device. The XEP-0326 Internet of Things - Concentrators (XEP-0326) XEP-0326: Internet of Things - Concentrators < deals with reading and writing parameters on nodes/devices. Fields are not parameters, and parameters are not fields. Peak Value A maximum or minimum value during a given period. Provisioning Server An application that can configure a network and provide services to users or Things. In Internet of Things, a Provisioning Server knows who knows whom, what privileges users have, who can read what data and who can control what devices and what parts of these devices. Precision In physics, precision determines the number of digits of precision. In sensor networks however, this definition is not easily applicable. Instead, precision determines, for example, the number of decimals of precision, or power of precision. Example: MWh contains 3 decimals of precision. All entities parsing and delivering field information in sensor networks should always retain the number of decimals in a message. Sensor Device measuring at least one digital value (0 or 1) or analog value (value with precision and physical unit). Examples: Temperature sensor, pressure sensor, etc. Sensor values are reported as fields during read-out. Each sensor has a unique Node ID. SN Sensor Network. A network consisting, but not limited to sensors, where transport and use of sensor data is of primary concern. A sensor network may contain actuators, network applications, monitors, services, etc. 4
9 Status Value A value displaying status information about something. Timestamp Timestamp of value, when the value was sampled or recorded. Thing Internet of Things basically consists of Things connected to the Internet. Things can be any device, sensor, actuator etc., that can have an Internet connection. Thing Registry A registry where Things can register for simple and secure discovery by the owner of the Thing. The registry can also be used as a database for meta information about Things in the network. Token A client, device or user can get a token from a provisioning server. These tokens can be included in requests to other entities in the network, so these entities can validate access rights with the provisioning server. Unit Physical unit of value. Example: MWh, l/s, etc. Value A field value. Value Status Status of field value. Contains important status information for Quality of Service purposes. Examples: Ok, Error, Warning, Time Shifted, Missing, Signed, etc. Value Type Can be numeric, string, boolean, Date & Time, Time Span or Enumeration. WSN Wireless Sensor Network, a sensor network including wireless devices. XMPP Client Application connected to an XMPP network, having a JID. Note that sensors, as well as applications requesting sensor data can be XMPP clients. 3 Use Cases The most basic use case in sensor networks is to read out sensor data from a sensor. However, since protecting end-user integrity and system security is vital, access rights and user privileges have to be imposed on the network. To store access rights in all sensors might be very impractical. Not only does it consume memory, it s difficult to maintain track of the current system status, make sure all devices have the latest configuration, distribute changes to the configuration, etc. Furthermore, most sensors and small devices have very limited possibility to provide a rich user interface. Perhaps all it can do is to provide a small LED and a button, useful perhaps for installing the sensor in the network, but not much more. As an added complexity, the sensor network operator might not even have access to the XMPP Servers used, and provisioning needs to lie outside of the XMPP Server domains. To solve this problem in an efficient manner, an architecture using distributed trusted third parties is proposed. Such third parties would: Provide a rich user interface and configurable options to end user or back end systems. 5
10 Control friendships (who can communicate with whom). Control content available for different friends (what can be read by whom). Control operations accessible by different friends (what can be controlled/configured by whom). Provide additional interoperability services to nodes in the network (for instance, unit conversion). 3.1 Delegating trust Delegating original trust to a Provisioning Server 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. The sensor flashes its LED for a given time (for example: 30 seconds). Viewing the LED, the person installing the sensor presses the button. Receiving the button press within the given time period, accepts the friendship request. Optionally, the device can give user feedback using the LED. The device performs a service discovery of the new friend, having been a manually added friend. If the new friend supports this provisioning extension, further responsibilities are delegated to this device. As the last step the device asks the provisioning server for a token. This device token is later used in calls to other devices and can be used to check access rights. The following diagram shows the general case: 6
11 The successful case can also be illustrated in a sequence diagram, as follows: 7
12 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. 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 Provisioning Server as a server component 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: Listing 1: Checking if server supports components <iq from = device@example. org / device to= example. org type = get id= 1 > <query xmlns = http: // jabber.org/ protocol / disco # info /> 8
13 <iq type = result id= 1 from = example. org to= device@example.org/ device > <query xmlns = http: // jabber.org/ protocol / disco # info >... <feature var= http: // jabber.org/ protocol / disco # items />... </ query > If components (items) are supported, a request for available components is made: Listing 2: Requesting list of server components <iq from = device@example. org / device to= example. org type = get id= 2 > <query xmlns = http: // jabber.org/ protocol / disco # items /> <iq type = result id= 2 from = example. org to= 995 fab3dd759452ca9c af0c@ example. org / ebe2348e > <query xmlns = http: // jabber.org/ protocol / disco # items >... <item jid= provisioning. example. org name = Provisioning />... </ query > The client then loops through all components (items) and checks what features they support, until a Provisioning Server is found: Listing 3: Service discovery information request made to each component <iq type = get from = device@example. org / device to= provisioning. example.org id= 3 > <query xmlns = http: // jabber.org/ protocol / disco # info /> from = provisioning. example.org to= device@example. org / device id= 3 > <query xmlns = http: // jabber.org/ protocol / disco # info >... <feature var= urn:xmpp:iot:provisioning />... 9
14 </ query > Tokens and X.509 Certificates 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. 10
15 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. Listing 4: Requesting a token <iq type = get from = device@example. org / device to= provisioning. example.org id= 4 > < gettoken xmlns = urn: xmpp: iot: provisioning >BASE -64 ENCODED PUBLIC X.509 CERTIFICATE </ gettoken > 11
16 from = provisioning. example.org to= device@example. org / device id= 4 > < gettokenchallenge xmlns = urn: xmpp: iot: provisioning seqnr = 1 > BASE -64 ENCODED CHALLENGE </ gettokenchallenge > <iq type = get from = device@example. org / device to= provisioning. example.org id= 5 > < gettokenchallengeresponse xmlns = urn: xmpp: iot: provisioning seqnr = 1 >BASE -64 ENCODED RESPONSE </ gettokenchallengeresponse > from = provisioning. example.org to= device@example. org / device id= 5 > < gettokenresponse xmlns = urn: xmpp: iot: provisioning token = TOKEN /> 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 gettoken- Challenge 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. Listing 5: Challenge reponse incorrect from = provisioning. example.org to= device@example. org / device id= 5 > <error type = modify > <bad - request xmlns = urn:ietf:params:xml:ns:xmpp - stanzas /> </ error > 12
17 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. Listing 6: Challenge sequence number not found from = provisioning. example.org to= device@example. org / device id= 5 > <error type = cancel > <item -not - found xmlns = urn:ietf:params:xml:ns:xmpp - stanzas /> </ error > 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: Listing 7: Requesting a token <iq type = get from = provisioning. example.org to= device@example. org / device id= 6 > < tokenchallenge xmlns = urn:xmpp:iot:provisioning token = TOKEN > BASE -64 encoded challenge </ tokenchallenge > from = device@example. org / device to= provisioning. example.org id= 6 > 13
18 < tokenchallengeresponse xmlns = urn: xmpp: iot: provisioning >BASE -64 encoded response </ tokenchallengeresponse > 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: Listing 8: Invalid token challenge <iq type = error from = device@example. org / device to= provisioning. example.org id= 6 > <error type = cancel > <forbidden xmlns = urn:ietf:params:xml:ns:xmpp - stanzas /> </ error > Delegating Secondary Trust 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. The following diagram continues with the example given above, of how a sensor with a limited user interface, can allow to manually add new friends, including new trust relationships using a single LED and a button. 14
19 15
20 3.1.5 Multiple tokens 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. When a provisioning server receives a request containing multiple tokens, the most forgiving response must be returned. Listing 9: Readout request using multiple tokens <iq type = get from = master@example. org /amr to= device@example. org id= 7 > <req xmlns = urn:xmpp:iot:sensordata momentary = true servicetoken = SERVICETOKEN1 SERVICETOKEN2 usertoken = USERTOKEN1 seqnr = 4 /> <iq type = get from = device@example. org / device to= provisioning. example.org id= 8 > <canread xmlns = urn:xmpp:iot:provisioning jid= master@example. org servicetoken = SERVICETOKEN1 SERVICETOKEN2 usertoken = USERTOKEN1 momentary = true /> from = provisioning. example.org to= device@example. org / device id= 8 > < canreadresponse xmlns = urn: xmpp: iot: provisioning jid = master@example.org momentary = true result = true /> from = device@example. org to= master@example. org /amr id= 7 > <accepted xmlns = urn:xmpp:iot:sensordata seqnr = 4 /> Note: When a provisioning server wants to challenge multiple tokens, separate token challenges are sent, one for each token being challenged. 16
21 3.2 Friendships Friendship request accepted The following diagram displays how a friendship request from an external party can be handled, delegating the responsibility to a trusted third party: The communication between the XMPP Device and the Provisioning Server could be as follows: Listing 10: Friendship request accepted <iq type = get from = device@example. org / device to= provisioning. example.org id= 9 > < isfriend xmlns = urn: xmpp: iot: provisioning jid = client1@ example. org /> from = provisioning. example.org to= device@example. org / device id= 9 > < isfriendresponse xmlns = urn: xmpp: iot: provisioning jid = client1@example.org result = true /> Note: The provisioning server implicitly understands which two JIDs that are to be checked: The first one is the sender of the message, the second one is the JID available in the jid attribute in the request. 17
22 Note 2: Any resource information in the JID must be ignored by the provisioning server Friendship request rejected The following diagram displays a friendship request from an external party being rejected as a result of the trusted third party negating the friendship: The communication between the XMPP Device and the Provisioning Server could be as follows: Listing 11: Friendship request rejected <iq type = get from = device@example. org / device to= provisioning. example.org id= 10 > < isfriend xmlns = urn: xmpp: iot: provisioning jid = client2@ example. org /> from = provisioning. example.org to= device@example. org / device id= 10 > < isfriendresponse xmlns = urn: xmpp: iot: provisioning jid = client2@example.org result = false /> 18
23 3.2.3 Unfriending existing friends 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 should only send such messages to clients that have previously asked the provisioning server if friendship requests should be accepted or not. Note: The device should only honor such messages, if the sender is the trusted third party. Such messages received from other entities not trusted should be silently ignored. Listing 12: Unfriending existing friend <message from = provisioning. example.org to= device@example.org > < unfriend xmlns = urn: xmpp: iot: provisioning jid = client2@ example. org /> </ message > Recommending friendships 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: 19
24 Listing 13: Recommending friendships <message from = provisioning. example.org to= device@example.org > <friend xmlns = urn:xmpp:iot:provisioning jid= client2@example. org /> </ message > Note that the receptor can still ask the provisioning server if it can form a friendship with the suggested friend, using the isfriend command. 3.3 Device Read-out Rejecting read-outs 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. 20
25 Note: This use case is an extension of the use case Read-out rejected in the XEP-0323 Internet of Things - Sensor Data. The following example shows the communication first between the client and the device, then between the device and the provisioning server, and last between the device and the client: Listing 14: Rejecting read-outs <iq type = get from = master@example. org /amr to= device@example. org id= 11 > <req xmlns = urn:xmpp:iot:sensordata momentary = true servicetoken = SERVICETOKEN1 usertoken = USERTOKEN1 seqnr = 1 /> <iq type = get from = device@example. org / device to= provisioning. example.org id= 12 > <canread xmlns = urn:xmpp:iot:provisioning jid= master@example. org servicetoken = SERVICETOKEN1 usertoken = USERTOKEN1 momentary = true /> from = provisioning. example.org to= device@example. org / device id= 12 > < canreadresponse xmlns = urn: xmpp: iot: provisioning jid = master@example.org momentary = true result = false /> 21
26 <iq type = error from = device@example. org to= master@example. org /amr id= 11 > <rejected xmlns = urn:xmpp:iot:sensordata seqnr = 1 > <error >Access denied.</ error > </ rejected > Restricting nodes during read-out 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. Note: This use case is an extension of the use case Read-out of multiple devices in the XEP-0323 Internet of Things - Sensor Data. Note 2: If the server responds, but without specifying a list of nodes, the device can assume that all nodes available in the original request are allowed to be read. If no nodes in the request are allowed to be read, the provisioning server must respond with a result= false, so the device can reject the read-out request. The following example shows the communication first between the client and the device, then between the device and the provisioning server, and last between the device and the client: Listing 15: Restricting nodes during read-out <iq type = get from = master@example. org /amr 22
27 to= org id= 13 > <req xmlns = urn:xmpp:iot:sensordata momentary = true servicetoken = SERVICETOKEN1 usertoken = USERTOKEN1 seqnr = 2 > <node nodeid = Device02 /> <node nodeid = Device03 /> </ req > <iq type = get from = device@example. org / device to= provisioning. example.org id= 14 > <canread xmlns = urn:xmpp:iot:provisioning jid= master@example. org momentary = true servicetoken = SERVICETOKEN1 usertoken = USERTOKEN1 > <node nodeid = Device02 /> <node nodeid = Device03 /> </ canread > from = provisioning. example.org to= device@example. org / device id= 14 > < canreadresponse xmlns = urn: xmpp: iot: provisioning jid = master@example.org momentary = true result = true > <node nodeid = Device02 /> </ canreadresponse > from = device@example. org to= master@example. org /amr id= 13 > <accepted xmlns = urn:xmpp:iot:sensordata seqnr = 2 /> Note that the provisioning server responds with a canreadresponse element, similar to the canread element in the request, except only the nodes allowed to be read are read. The device must only permit read-out of nodes listed in the response from the provisioning server. Other nodes available in the request should be ignored Restricting fields during read-out 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 23
28 allowed to send to the corresponding client. Note: If the server responds, but without specifying a list of field names, the device can assume that all fields available in the original request are allowed to be sent. If no fields in the request are allowed to be sent, the provisioning server must respond with a result= false, so the device can reject the read-out request. The following example shows the communication first between the client and the device, then between the device and the provisioning server, and last between the device and the client: Listing 16: Restricting fields during read-out <iq type = get from = master@example. org /amr to= device@example. org id= 15 > <req xmlns = urn:xmpp:iot:sensordata momentary = true servicetoken = SERVICETOKEN1 usertoken = USERTOKEN1 seqnr = 3 /> <iq type = get from = device@example. org / device to= provisioning. example.org id= 16 > <canread xmlns = urn:xmpp:iot:provisioning jid= master@example. org momentary = true servicetoken = SERVICETOKEN1 usertoken = USERTOKEN1 /> 24
29 from = provisioning. example.org to= device@example. org / device id= 16 > < canreadresponse xmlns = urn: xmpp: iot: provisioning jid = master@example.org momentary = true result = true > <field name = Energy /> <field name = Power /> </ canreadresponse > from = device@example. org to= master@example. org /amr id= 15 > <accepted xmlns = urn:xmpp:iot:sensordata seqnr = 3 /> Note that the provisioning server responds with a canreadresponse element, similar to the canread element in the request, except only the fields allowed to be sent are listed. The client must only send fields having field names in this list. Also note, that the provisioning server can return a list of both allowed nodes and allowed field names in the response. In this case, the device must only send allowed fields from allowed nodes, and ignore all other fields and/or nodes. 3.4 Device Control Rejecting control actions 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. 25
30 The following example shows the communication first between the client and the device, then between the device and the provisioning server, and last between the device and the client: Listing 17: Rejecting control action <iq type = set from = master@example. org /amr to= device@example. org id= 17 > <set xmlns = urn:xmpp:iot:control xml:lang = en > <boolean name = Output value = true /> </ set > <iq type = get from = device@example. org / device to= provisioning. example.org id= 18 > <cancontrol xmlns = urn:xmpp:iot:provisioning jid= master@ example. org servicetoken = SERVICETOKEN1 usertoken = USERTOKEN1 > <parameter name = Output /> </ cancontrol > from = provisioning. example.org to= device@example. org / device id= 18 > < cancontrolresponse xmlns = urn: xmpp: iot: provisioning jid = master@example.org result = false /> <iq type = error from = device@example. org to= master@example. org /amr id= 17 > < setresponse xmlns = urn: xmpp: iot: control responsecode = InsufficientPrivileges / > Restricting nodes during control 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. 26
31 Note: If the server responds, but without specifying a list of nodes, the device can assume that all nodes available in the original request are allowed to be controlled. If no nodes in the request are allowed to be controlled, the provisioning server must respond with a result= false, so the device can reject the read-out request. The same is true for parameters: If the provisioning server does not specify parameters in the response, the caller can assume all parameters are allowed. The following example shows the communication first between the client and the device, then between the device and the provisioning server, and last between the device and the client: Listing 18: Restricting nodes during control <iq type = set from = master@example. org /amr to= concentrator@example.org id= 19 > <set xmlns = urn:xmpp:iot:control xml:lang = en > <node nodeid = DigitalOutput1 /> <node nodeid = DigitalOutput2 /> <node nodeid = DigitalOutput3 /> <node nodeid = DigitalOutput4 /> <boolean name = Output value = true /> </ set > <iq type = get from = concentrator@example.org/plc to= provisioning. example.org id= 20 > <cancontrol xmlns = urn:xmpp:iot:provisioning jid= master@ example. org servicetoken = SERVICETOKEN1 usertoken = USERTOKEN1 > 27
32 <node nodeid = DigitalOutput1 /> <node nodeid = DigitalOutput2 /> <node nodeid = DigitalOutput3 /> <node nodeid = DigitalOutput4 /> <parameter name = Output /> </ cancontrol > from = provisioning. example.org to= concentrator@example.org /plc id= 20 > < cancontrolresponse xmlns = urn: xmpp: iot: provisioning jid = master@example.org result = true > <node nodeid = DigitalOutput2 /> <node nodeid = DigitalOutput3 /> </ cancontrolresponse > from = concentrator@example.org to= master@example. org /amr id= 19 > < setresponse xmlns = urn:xmpp:iot:control responsecode = OK > <node nodeid = DigitalOutput2 /> <node nodeid = DigitalOutput3 /> </ setresponse > Note that the provisioning server responds with a cancontrolresponse element, similar to the cancontrol element in the request, except only the nodes allowed to be controlled are included. The device must only permit control of nodes listed in the response from the provisioning server. Other nodes available in the request should be ignored. Also note, that the restricted set of nodes and/or parameters returned from the provisioning server must be returned to the original caller, so it can act on the information that only a partial control action was allowed and taken Restricting parameters during control 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. 28
33 Note: If the server responds, but without specifying a list of nodes, the device can assume that all nodes available in the original request are allowed to be controlled. If no nodes in the request are allowed to be controlled, the provisioning server must respond with a result= false, so the device can reject the read-out request. The same is true for parameters: If the provisioning server does not specify parameters in the response, the caller can assume all parameters are allowed. The following example shows the communication first between the client and the device, then between the device and the provisioning server, and last between the device and the client: Listing 19: Restricting parameters during control <iq type = set from = master@example. org /amr to= plc@example. org id= 21 > <set xmlns = urn:xmpp:iot:control xml:lang = en > <boolean name = DigitalOutput1 value = true /> <boolean name = DigitalOutput2 value = true /> <boolean name = DigitalOutput3 value = true /> <boolean name = DigitalOutput4 value = true /> <int name = AnalogOutput1 value = /> <int name = AnalogOutput2 value = /> <int name = AnalogOutput3 value = /> <int name = AnalogOutput4 value = /> </ set > <iq type = get from = plc@example. org /plc to= provisioning. example.org id= 22 > 29
34 <cancontrol xmlns = urn:xmpp:iot:provisioning jid= master@ example. org servicetoken = SERVICETOKEN1 usertoken = user0001 > < parameter name = DigitalOutput1 / > < parameter name = DigitalOutput2 / > < parameter name = DigitalOutput3 / > < parameter name = DigitalOutput4 / > < parameter name = AnalogOutput1 / > < parameter name = AnalogOutput2 / > < parameter name = AnalogOutput3 / > < parameter name = AnalogOutput4 / > </ cancontrol > from = provisioning. example.org to= plc@example. org / plc id= 22 > < cancontrolresponse xmlns = urn: xmpp: iot: provisioning jid = master@example.org result = true > < parameter name = DigitalOutput1 / > < parameter name = DigitalOutput2 / > < parameter name = DigitalOutput3 / > < parameter name = DigitalOutput4 / > </ cancontrolresponse > from = plc@example. org to= master@example. org /amr id= 21 > < setresponse xmlns = urn:xmpp:iot:control responsecode = OK > < parameter name = DigitalOutput1 / > < parameter name = DigitalOutput2 / > < parameter name = DigitalOutput3 / > < parameter name = DigitalOutput4 / > </ setresponse > Note that the provisioning server responds with a cancontrolresponse element, similar to the cancontrol element in the request, except only the parameters allowed to be sent are listed. The device must only control parameters included in this list. Also note, that the provisioning server can return a list of both allowed nodes and allowed parameter names in the response back to the client, so it can act on the information that only a partial control action was allowed and taken. 30
35 3.5 Cache Clear cache 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 done by the client. It simply acknowledges the receipt of the command, to make sure the provisioning server does not resend the clear cache command again. Note: The clearcache command does not include information on what has been changed, so the device needs to clear the entire cache. This to avoid complexities in making sure updates made to the provisioning rules works in all cases, and to minimize complexity in the implementation of the protocol on the sensor side. It is also not deemed to decrease network performance, since changing provisioning rules for a device is an exceptional event and therefore does not affect performance during normal operation. Listing 20: Clear cache <iq type = set from = provisioning. example.org to= device@example. org id= 23 > < clearcache xmlns = urn: xmpp: iot: provisioning / > from = device@example. org to= provisioning. example.org id= 23 > < clearcacheresponse xmlns = urn: xmpp: iot: provisioning / > 3.6 Services Getting a service token A service requesting provisioning assistance, needs to retrieve a service token from the provisioning server, by providing a base-64 encoded X.509 certificate. The following example shows how this can be done. Listing 21: Requesting a service token <iq type = get from = device@example. org / device to= provisioning. example.org 31
36 id= 24 > < gettoken xmlns = urn: xmpp: iot: provisioning >BASE -64 ENCODED PUBLIC X.509 CERTIFICATE </ gettoken > from = provisioning. example.org to= device@example. org / device id= 24 > < gettokenchallenge xmlns = urn: xmpp: iot: provisioning seqnr = 1 > BASE -64 ENCODED CHALLENGE </ gettokenchallenge > <iq type = get from = device@example. org / device to= provisioning. example.org id= 25 > < gettokenchallengeresponse xmlns = urn: xmpp: iot: provisioning seqnr = 1 >BASE -64 ENCODED RESPONSE </ gettokenchallengeresponse > from = provisioning. example.org to= device@example. org / device id= 25 > < gettokenresponse xmlns = urn: xmpp: iot: provisioning token = TOKEN /> User access to service Provisioning in sensor networks also requires control of user access to different services in the network. This use case shows how service access rights are controlled using a trusted provisioning server. 32
37 First, the user connects to the service in some way. This can be done using XMPP, HTTP, HTTPS or some other means. The service need to extract some form of identifying credentials from the user, and provide that to the provisioning server. The provisioning server determines if the client has access rights to the service based on these credentials, and also provides the service with a usertoken that the service can use in further communication with the provisioning server regarding the user and its privileges. The following table lists some different types of credentials that the service can extract from the client: Type Protocols Description JID XMPP Allows provisioning to be done on the JID the user has. IP Address HTTP, HTTPS Allows provisioning to be done on IP address or IPranges for instance. Host Name HTTP, HTTPS with DNS If the service has access to the client host name, for instance in an intra network, this can be used for provisioning. X.509 Certificate HTTPS If the client provides a client certificate, such a certificate can be used to provide provisioning. 33
XEP-0135: File Sharing
XEP-0135: File Sharing Peter Saint-Andre mailto:peter@andyet.net xmpp:stpeter@stpeter.im https://stpeter.im/ 2004-06-04 Version 0.1 Status Type Short Name Deferred Standards Track files This document specifies
More informationXEP-0347: Internet of Things - Discovery
XEP-0347: Internet of Things - Discovery Peter Waher mailto:peterwaher@hotmail.com xmpp:peter.waher@jabber.org http://www.linkedin.com/in/peterwaher Ronny Klauck mailto:rklauck@informatik.tu-cottbus.de
More informationXEP-0337: Event Logging over XMPP
XEP-0337: Event Logging over XMPP Peter Waher mailto:peterwaher@hotmail.com xmpp:peter.waher@jabber.org http://www.linkedin.com/in/peterwaher 2015-11-09 Version 0.2 Status Type Short Name Experimental
More informationXEP-0043: Jabber Database Access
XEP-0043: Jabber Database Access Justin Kirby mailto:justin@openaether.org xmpp:zion@openaether.org 2003-10-20 Version 0.2 Status Type Short Name Retracted Standards Track Expose RDBM systems directly
More informationSecurity in Internet of Things using Delegation of Trust to a Provisioning Server
Security in Internet of Things using Delegation of Trust to a Provisioning Server Architecture overview Peter Waher Clayster Laboratorios Chile S.A, Blanco 1623, of. 1402, Valparaíso, Chile peter.waher@clayster.com
More informationXEP-0210: Requirements for Encrypted Sessions
XEP-0210: Requirements for Encrypted Sessions Ian Paterson mailto:ian.paterson@clientside.co.uk xmpp:ian@zoofy.com 2007-05-30 Version 0.2 Status Type Short Name Deferred Standards Track N/A This document
More informationXEP-0060: Publish-Subscribe
XEP-0060: Publish-Subscribe Peter Millard Peter Saint-Andre mailto:peter@andyet.net xmpp:stpeter@stpeter.im https://stpeter.im/ 2010-07-12 Version 1.13 Ralph Meijer mailto:ralphm@ik.nu xmpp:ralphm@ik.nu
More informationW3C Meeting ISO/IEC/IEEE P21451-1-4
W3C Meeting ISO/IEC/IEEE P21451-1-4 1 st International Semantic Web 3.0 Standard for the Internet of Things (IoT) William J. Miller Chairman 07/22/2015 1 Internet of Things (IoT) http://www.sensei-iot.org
More informationRSA Two Factor Authentication
RSA Two Factor Authentication VERSION: 1.0 UPDATED: MARCH 2014 Copyright 2002-2014 KEMP Technologies, Inc. All Rights Reserved. Page 1 / 16 Copyright Notices Copyright 2002-2014 KEMP Technologies, Inc..
More informationHyper V Windows 2012 and 8. Virtual LoadMaster for Microsoft Hyper V on Windows Server 2012, 2012 R2 and Windows 8. Installation Guide
Virtual LoadMaster for Microsoft Hyper V on Windows Server 2012, 2012 R2 and Windows 8 Installation Guide VERSION: 3.0 UPDATED: SEPTEMBER 2015 Copyright Notices Copyright 2002 2015 KEMP Technologies, Inc..
More informationRSA Two Factor Authentication. Feature Description
RSA Two Factor Authentication Feature Description VERSION: 3.0 UPDATED: SEPTEMBER 2015 Copyright Notices Copyright 2002 2015 KEMP Technologies, Inc.. All rights reserved.. KEMP Technologies and the KEMP
More informationVirtual LoadMaster for Microsoft Hyper-V
Virtual LoadMaster for Microsoft Hyper-V on Windows Server 2012, 2012 R2 and Windows 8 VERSION: 1.3 UPDATED: MARCH 2014 Copyright 2002-2014 KEMP Technologies, Inc. All Rights Reserved. Page 1 / 20 Copyright
More informationLog Insight Manager. Deployment Guide
Log Insight Manager Deployment Guide VERSION: 3.0 UPDATED: OCTOBER 2015 Copyright Notices Copyright 2002-2015 KEMP Technologies, Inc.. All rights reserved.. KEMP Technologies and the KEMP Technologies
More informationCisco TelePresence VCR Converter 1.0(1.8)
Cisco TelePresence VCR Converter 1.0(1.8) Software release notes D14725.02 February 2011 Contents Contents Document revision history... 3 Introduction... 4 New features in version 1.0(1.8)... 5 Convert
More informationAzure Multi-Factor Authentication. KEMP LoadMaster and Azure Multi- Factor Authentication. Technical Note
KEMP LoadMaster and Azure Multi- Factor Authentication Technical Note VERSION: 1.0 UPDATED: APRIL 2016 Copyright Notices Copyright 2002-2016 KEMP Technologies, Inc.. All rights reserved.. KEMP Technologies
More informationGravityLab Multimedia Inc. Windows Media Authentication Administration Guide
GravityLab Multimedia Inc. Windows Media Authentication Administration Guide Token Auth Menu GravityLab Multimedia supports two types of authentication to accommodate customers with content that requires
More informationHealthstone Monitoring System
Healthstone Monitoring System Patrick Lambert v1.1.0 Healthstone Monitoring System 1 Contents 1 Introduction 2 2 Windows client 2 2.1 Installation.............................................. 2 2.2 Troubleshooting...........................................
More informationCA Nimsoft Monitor. Probe Guide for DNS Response Monitoring. dns_response v1.6 series
CA Nimsoft Monitor Probe Guide for DNS Response Monitoring dns_response v1.6 series Legal Notices This online help system (the "System") is for your informational purposes only and is subject to change
More informationSvn.spamsvn110. QuickStart Guide to Authentication. WebTitan Version 5
Svn.spamsvn110 QuickStart Guide to Authentication WebTitan Version 5 Copyright 2014 Copperfasten Technologies. All rights reserved. The product described in this document is furnished under a license agreement
More informationMicrosoft SharePoint
Microsoft SharePoint VERSION: 1.1 UPDATED: JULY 2014 Copyright 2002-2014 KEMP Technologies, Inc. All Rights Reserved. Page 1 / 13 Copyright Notices Copyright 2002-2014 KEMP Technologies, Inc.. All rights
More informationSupply Chain Management Use Case Model
Supply Chain Management Use Case Model Date: 2002/11/10 This version: http://www.ws-i.org/sampleapplications/supplychainmanagement/2002-11/scmusecases-0.18- WGD.htm Latest version: http://www.ws-i.org/sampleapplications/supplychainmanagement/2002-11/scmusecases-0.18-
More informationPort Following. Port Following. Feature Description
Feature Description VERSION: 6.0 UPDATED: MARCH 2016 Copyright Notices Copyright 2002-2016 KEMP Technologies, Inc.. All rights reserved.. KEMP Technologies and the KEMP Technologies logo are registered
More informationSimba ODBC Driver with SQL Connector for Apache Cassandra
Simba ODBC Driver with SQL Connector for Apache Cassandra Installation and Configuration Guide May 7, 2013 Simba Technologies Inc. Copyright 2012-2013 Simba Technologies Inc. All Rights Reserved. Information
More informationSolarWinds. Packet Analysis Sensor Deployment Guide
SolarWinds Packet Analysis Sensor Deployment Guide Copyright 1995-2015 SolarWinds Worldwide, LLC. All rights reserved worldwide. No part of this document may be reproduced by any means nor modified, decompiled,
More informationInstallation and configuration guide
Installation and Configuration Guide Installation and configuration guide Adding X-Username support to Forward and Reverse Proxy TMG Servers Published: December 2010 Applies to: Winfrasoft X-Username for
More informationSymantec Endpoint Protection Shared Insight Cache User Guide
Symantec Endpoint Protection Shared Insight Cache User Guide Symantec Endpoint Protection Shared Insight Cache User Guide The software described in this book is furnished under a license agreement and
More informationSOFTWARE LICENSE LIMITED WARRANTY
CYBEROAM INSTALLATION GUIDE VERSION: 6..0..0..0 IMPORTANT NOTICE Elitecore has supplied this Information believing it to be accurate and reliable at the time of printing, but is presented without warranty
More informationHP A-IMC Firewall Manager
HP A-IMC Firewall Manager Configuration Guide Part number: 5998-2267 Document version: 6PW101-20110805 Legal and notice information Copyright 2011 Hewlett-Packard Development Company, L.P. No part of this
More informationPHP Integration Kit. Version 2.5.1. User Guide
PHP Integration Kit Version 2.5.1 User Guide 2012 Ping Identity Corporation. All rights reserved. PingFederate PHP Integration Kit User Guide Version 2.5.1 December, 2012 Ping Identity Corporation 1001
More informationVirtual LoadMaster for VMware ESX, ESXi using vsphere
Virtual LoadMaster for VMware ESX, ESXi using vsphere VERSION: 1.15 UPDATED: MARCH 2014 Copyright 2002-2014 KEMP Technologies, Inc. All Rights Reserved. Page 1 / 22 Copyright Notices Copyright 2002-2014
More informationADS Integration Guide
ADS Integration Guide Document version 9402-1.0-18/10/2006 Cyberoam ADS Integration Guide IMPORTANT NOTICE Elitecore has supplied this Information believing it to be accurate and reliable at the time of
More informationCA Nimsoft Monitor. Probe Guide for CA ServiceDesk Gateway. casdgtw v2.4 series
CA Nimsoft Monitor Probe Guide for CA ServiceDesk Gateway casdgtw v2.4 series Copyright Notice This online help system (the "System") is for your informational purposes only and is subject to change or
More informationCA Spectrum and CA Performance Center
CA Spectrum and CA Performance Center Integration Guide CA Spectrum Release 9.3 - CA Performance Center r2.3.00 This Documentation, which includes embedded help systems and electronically distributed materials,
More informationNimsoft Monitor. dns_response Guide. v1.6 series
Nimsoft Monitor dns_response Guide v1.6 series CA Nimsoft Monitor Copyright Notice This online help system (the "System") is for your informational purposes only and is subject to change or withdrawal
More informationVeritas Cluster Server Database Agent for Microsoft SQL Configuration Guide
Veritas Cluster Server Database Agent for Microsoft SQL Configuration Guide Windows Server 2003, Windows Server 2008 5.1 Veritas Cluster Server Database Agent for Microsoft SQL Configuration Guide Copyright
More informationOpen Source Software used in the product
Open Source Software used in the product The software in this product contains parts licensed under various Open Source licenses. Please refer to the below list for further information on the software
More informationCisco TelePresence Management Suite Extension for Microsoft Exchange Version 4.0
Cisco TelePresence Management Suite Extension for Microsoft Exchange Version 4.0 Software Release Notes May 2014 Contents Introduction 1 Changes to interoperability 1 Product documentation 1 New features
More informationNokia for Business. Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation
Nokia for Business Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation Nokia E50 Configuring connection settings Nokia E50 Configuring connection settings Legal Notice Copyright
More informationCisco TelePresence Management Suite Extension for Microsoft Exchange Version 4.0.1
Cisco TelePresence Management Suite Extension for Microsoft Exchange Version 4.0.1 Software Release Notes May 2014 Contents Introduction 1 Changes to interoperability 1 Product documentation 2 New features
More informationNetwork Monitoring with SNMP
Network Monitoring with SNMP This paper describes how SNMP is used in WhatsUp- Professional and provides specific examples on how to configure performance, active, and passive monitors. Introduction SNMP
More information9236245 Issue 2EN. Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation
9236245 Issue 2EN Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation Nokia 9300 Configuring connection settings Legal Notice Copyright Nokia 2005. All rights reserved. Reproduction,
More informationRealex Payments Gateway Extension with 3D Secure for Magento. User Guide to Installation and Configuration. StudioForty9 www.studioforty9.
Realex Payments Gateway Extension with 3D Secure for Magento User Guide to Installation and Configuration StudioForty9 www.studioforty9.com User Guide: Table of Contents 3 How to Install the Realex Module
More informationDIGIPASS Authentication for Windows Logon Product Guide 1.1
DIGIPASS Authentication for Windows Logon Product Guide 1.1 Disclaimer of Warranties and Limitations of Liabilities The Product is provided on an 'as is' basis, without any other warranties, or conditions,
More informationTesting and Restoring the Nasuni Filer in a Disaster Recovery Scenario
Testing and Restoring the Nasuni Filer in a Disaster Recovery Scenario Version 7.0 July 2015 2015 Nasuni Corporation All Rights Reserved Document Information Testing Disaster Recovery Version 7.0 July
More informationApplication Note. Citrix Presentation Server through a Citrix Web Interface with OTP only
Application Note Citrix Presentation Server through a Citrix Web Interface with OTP only ii Preface All information herein is either public information or is the property of and owned solely by Gemalto
More informationRemote Desktop Services
Remote Desktop Services VERSION: 1.0 UPDATED: JUNE 2014 Copyright 2002-2014 KEMP Technologies, Inc. All Rights Reserved. Page 1 / 43 Copyright Notices Copyright 2002-2014 KEMP Technologies, Inc.. All rights
More informationInstallation and configuration guide
Installation and Configuration Guide Installation and configuration guide Adding X-Forwarded-For support to Forward and Reverse Proxy TMG Servers Published: May 2010 Applies to: Winfrasoft X-Forwarded-For
More informationCORPORATE HEADQUARTERS Elitecore Technologies Ltd. 904 Silicon Tower, Off. C.G. Road, Ahmedabad 380015, INDIA www.cyberoam.com 7300-1.
CYBEROAM - ADS INTEGRATION GUIDE VERSION: 7 7300-1.0-9/20/2005 2 IMPORTANT NOTICE Elitecore has supplied this Information believing it to be accurate and reliable at the time of printing, but is presented
More informationOpen Source Used In Cisco IronPort Email Encryption SDK 6.9.2 014
Open Source Used In Cisco IronPort Email Encryption SDK 6.9.2 014 This document contains the licenses and notices for open source software used in this product. With respect to the free/open source software
More informationCA Unified Infrastructure Management
CA Unified Infrastructure Management Probe Guide for IIS Server Monitoring iis v1.7 series Copyright Notice This online help system (the "System") is for your informational purposes only and is subject
More informationTesting and Restoring the Nasuni Filer in a Disaster Recovery Scenario
Testing and Restoring the Nasuni Filer in a Disaster Recovery Scenario Version 7.2 November 2015 Last modified: November 3, 2015 2015 Nasuni Corporation All Rights Reserved Document Information Testing
More information7.5 7.5. Spotlight on Messaging. Evaluator s Guide
7.5 Spotlight on Messaging 7.5 Evaluator s Guide 2010 Quest Software, Inc. ALL RIGHTS RESERVED. This guide contains proprietary information protected by copyright. The software described in this guide
More informationBackup Exec Cloud Storage for Nirvanix Installation Guide. Release 2.0
Backup Exec Cloud Storage for Nirvanix Installation Guide Release 2.0 The software described in this book is furnished under a license agreement and may be used only in accordance with the terms of the
More informationIntegrated Citrix Servers
Installation Guide Supplement for use with Integrated Citrix Servers Websense Web Security Websense Web Filter v7.5 1996-2010, Websense, Inc. 10240 Sorrento Valley Rd., San Diego, CA 92121, USA All rights
More informationSoftware Package Document exchange (SPDX ) Tools. Version 1.2. Copyright 2011-2014 The Linux Foundation. All other rights are expressly reserved.
Software Package Document exchange (SPDX ) Tools Version 1.2 This document last updated March 18, 2014. Please send your comments and suggestions for this document to: spdx-tech@fossbazzar.org Copyright
More informationInstallation Guide Supplement
Installation Guide Supplement for use with Microsoft ISA Server and Forefront TMG Websense Web Security Websense Web Filter v7.5 1996 2010, Websense Inc. All rights reserved. 10240 Sorrento Valley Rd.,
More informationSymantec Integrated Enforcer for Microsoft DHCP Servers Getting Started Guide
Symantec Integrated Enforcer for Microsoft DHCP Servers Getting Started Guide Legal Notice Copyright 2006 Symantec Corporation. All rights reserved. Federal acquisitions: Commercial Software - Government
More informationCisco Expressway IP Port Usage for Firewall Traversal. Cisco Expressway X8.1 D15066.01 December 2013
Cisco Expressway IP Port Usage for Firewall Traversal Cisco Expressway X8.1 D15066.01 December 2013 Contents: Cisco Expressway IP port usage Which IP ports are used with Cisco Expressway? Which IP ports
More informationOmnicast Migration Guide 5.2. Click here for the most recent version of this document.
Omnicast Migration Guide 5.2 Click here for the most recent version of this document. Copyright notice 2015 Genetec Inc. All rights reserved. Genetec Inc. distributes this document with software that includes
More informationDigipass Plug-In for IAS. IAS Plug-In IAS. Microsoft's Internet Authentication Service. Installation Guide
Digipass Plug-In for IAS IAS Plug-In IAS Microsoft's Internet Authentication Service Installation Guide Disclaimer of Warranties and Limitations of Liabilities Disclaimer of Warranties and Limitations
More informationRTI Monitor. Release Notes
RTI Monitor Release Notes Version 5.1.0 2013 Real-Time Innovations, Inc. All rights reserved. Printed in U.S.A. First printing. December 2013. Trademarks Real-Time Innovations, RTI, and Connext are trademarks
More informationfor this software, unless other terms accompany those items. If so, those terms apply.
MICROSOFT SOFTWARE LICENSE TERMS WINDOWS VISTA ENTERPRISE SERVICE PACK 1 Your use of this software is subject to the terms and conditions of your volume license agreement. You may not use this software
More informationHP IMC Firewall Manager
HP IMC Firewall Manager Configuration Guide Part number: 5998-2267 Document version: 6PW102-20120420 Legal and notice information Copyright 2012 Hewlett-Packard Development Company, L.P. No part of this
More informationShrew Soft VPN Client Configuration for GTA Firewalls
Shrew Soft VPN Client Configuration for GTA Firewalls ShrewVPN201003-01 Global Technology Associates 3505 Lake Lynda Drive Suite 109 Orlando, FL 32817 Tel: +1.407.380.0220 Fax. +1.407.380.6080 Email: info@gta.com
More informationHow To Install Caarcserve Backup Patch Manager 27.3.2.2 (Carcserver) On A Pc Or Mac Or Mac (Or Mac)
CA ARCserve Backup Patch Manager for Windows User Guide r16 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation
More informationGoogle Cloud Print User's Manual
Google Cloud Print User's Manual Symbols used in this manual This manual uses the following symbols. Note! These are cautions and limitations for correct operation. It is strongly recommended that you
More informationUser s Guide. Getting Started
User s Guide Snap-Link is HAI's newest PC application that allows you to monitor and control an Omni IIe or OmniPro II system across a network or over the Internet. It can be installed on the PC as a conventional
More informationUnicenter Patch Management
Unicenter Patch Management Best Practices for Managing Security Updates R11 This documentation (the Documentation ) and related computer software program (the Software ) (hereinafter collectively referred
More informationRemote Desktop Services
Remote Desktop Services Deployment Guide VERSION: 6.0 UPDATED: MARCH 2016 Copyright Notices Copyright 2002-2016 KEMP Technologies, Inc.. All rights reserved.. KEMP Technologies and the KEMP Technologies
More informationCisco TelePresence Authenticating Cisco VCS Accounts Using LDAP
Cisco TelePresence Authenticating Cisco VCS Accounts Using LDAP Deployment Guide Cisco VCS X8.1 D14465.06 December 2013 Contents Introduction 3 Process summary 3 LDAP accessible authentication server configuration
More informationCOMMANDbatch. VLink COMMANDbatch Interface Setup & Operation. Last Updated 3/16/16 COMMANDbatch V1.8.7.0 & Later
COMMANDbatch VLink COMMANDbatch Interface Setup & Operation Last Updated 3/16/16 COMMANDbatch V1.8.7.0 & Later 2003-2016 Command Alkon Incorporated. All rights reserved. The contents of this document are
More informationCA Nimsoft Monitor. Probe Guide for NT Event Log Monitor. ntevl v3.8 series
CA Nimsoft Monitor Probe Guide for NT Event Log Monitor ntevl v3.8 series Legal Notices Copyright 2013, CA. All rights reserved. Warranty The material contained in this document is provided "as is," and
More informationtechnical brief Optimizing Performance in HP Web Jetadmin Web Jetadmin Overview Performance HP Web Jetadmin CPU Utilization utilization.
technical brief in HP Overview HP is a Web-based software application designed to install, configure, manage and troubleshoot network-connected devices. It includes a Web service, which allows multiple
More informationGetting Started Guide
Snap-Link Mobile allows you to monitor and control lights, security, audio, temperatures and webcams on handheld mobile devices, such as Smartphones, PDAs or other devices running Windows Mobile operating
More informationUnicenter NSM Integration for BMC Remedy. User Guide
Unicenter NSM Integration for BMC Remedy User Guide This documentation and any related computer software help programs (hereinafter referred to as the Documentation ) is for the end user s informational
More informationAltiris Task Server 6.0 Help
Altiris Task Server 6.0 Help Notice Altiris Task Server 6.0 Help 2000-2006 Altiris, Inc. All rights reserved. Document Date: December 27, 2006 Information in this document: (i) is provided for informational
More informationProcon Frostbite 1.1 and subsequent releases End User License Agreement Revised: April 7, 2015
Procon Frostbite 1.1 and subsequent releases End User License Agreement Revised: April 7, 2015 THIS IS A LEGAL AGREEMENT between "you", the individual, company, or organisation utilising Procon Frostbite
More informationVeritas Cluster Server Database Agent for Microsoft SQL Configuration Guide
Veritas Cluster Server Database Agent for Microsoft SQL Configuration Guide Windows 2000, Windows Server 2003 5.0 11293743 Veritas Cluster Server Database Agent for Microsoft SQL Configuration Guide Copyright
More informationGEO Sticky DNS. GEO Sticky DNS. Feature Description
GEO Sticky DNS Feature Description VERSION: 5.0 UPDATED: JANUARY 2016 Copyright Notices Copyright 2002-2016 KEMP Technologies, Inc.. All rights reserved.. KEMP Technologies and the KEMP Technologies logo
More informationQuick Install Guide. Lumension Endpoint Management and Security Suite 7.1
Quick Install Guide Lumension Endpoint Management and Security Suite 7.1 Lumension Endpoint Management and Security Suite - 2 - Notices Version Information Lumension Endpoint Management and Security Suite
More informationSymantec Event Collector 4.3 for Microsoft Windows Quick Reference
Symantec Event Collector 4.3 for Microsoft Windows Quick Reference Symantec Event Collector for Microsoft Windows Quick Reference The software described in this book is furnished under a license agreement
More informationTerms of Service MANAGED FIREWALL Service
This Service is subject to and governed by Customer s separate signed master services agreement with CTS. This Agreement is entered into between you and CTS for the provision of CTS Managed Firewall Services.
More informationCisco TelePresence Management Suite Extension for Microsoft Exchange Version 4.0.3
Cisco TelePresence Management Suite Extension for Microsoft Exchange Version 4.0.3 Software Release Notes Revised September 2014 Contents Introduction 1 Changes to interoperability 1 Product documentation
More informationCA Performance Center
CA Performance Center Single Sign-On User Guide 2.4 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation ) is
More informationEmail Encryption. Administrator Guide
Email Encryption Administrator Guide Email Encryption Administrator Guide Documentation version: 1.0 Legal Notice Copyright 2015 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo,
More informationAcroTime Workforce Management Time & Labor Human Resources Payroll Service Terms and Conditions
Terms of Agreement Acroprint Time Recorder Company (referred as Acroprint ) grants you access to use its web hosted time and attendance solution AcroTime (referred as Service ), subject to your agreement
More informationMigrating to vcloud Automation Center 6.1
Migrating to vcloud Automation Center 6.1 vcloud Automation Center 6.1 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a
More informationDell Unified Communications Command Suite - Diagnostics 8.0. Data Recorder User Guide
Dell Unified Communications Command Suite - Diagnostics 8.0 2014 Dell Inc. ALL RIGHTS RESERVED. This guide contains proprietary information protected by copyright. The software described in this guide
More informationNokia and Nokia Connecting People are registered trademarks of Nokia Corporation
Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation Nokia E70 Configuring connection settings Nokia E70 Configuring connection settings Legal Notice Copyright Nokia 2006. All
More informationIntel Internet of Things (IoT) Developer Kit
Intel Internet of Things (IoT) Developer Kit IoT Cloud-Based Analytics User Guide September 2014 IoT Cloud-Based Analytics User Guide Introduction Table of Contents 1.0 Introduction... 4 1.1. Revision
More informationRadius Integration Guide Version 9
Radius Integration Guide Version 9 Document version 9402-1.0-18/10/2006 2 IMPORTANT NOTICE Elitecore has supplied this Information believing it to be accurate and reliable at the time of printing, but
More informationSafeguard Ecommerce Integration / API
Safeguard Ecommerce Integration / API Product Manual Version 3 Revision 1.11 Table of Contents 1. INTRODUCTION... 4 1.1 Available commands... 4 2. HOW THE ADMINISTRATION SYSTEM IS EXPECTED TO BE USED OPERATIONALLY...
More informationSafeGuard Enterprise Web Helpdesk. Product version: 6 Document date: February 2012
SafeGuard Enterprise Web Helpdesk Product version: 6 Document date: February 2012 Contents 1 SafeGuard web-based Challenge/Response...3 2 Installation...5 3 Authentication...8 4 Select the Web Helpdesk
More informationvcloud Air Platform Programmer's Guide
vcloud Air Platform Programmer's Guide vcloud Air OnDemand 5.7 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition.
More informationUsing SNMP with OnGuard
Advanced Installation Topics Chapter 8: Using SNMP with OnGuard SNMP (Simple Network Management Protocol) is used primarily for managing and monitoring devices on a network. This is achieved through the
More informationPortal Administration. Administrator Guide
Portal Administration Administrator Guide Portal Administration Guide Documentation version: 1.0 Legal Notice Legal Notice Copyright 2013 Symantec Corporation. All rights reserved. Symantec, the Symantec
More informationXerox Mobile Print Cloud
September 2012 702P00860 Xerox Mobile Print Cloud Information Assurance Disclosure 2012 Xerox Corporation. All rights reserved. Xerox and Xerox and Design are trademarks of Xerox Corporation in the United
More informationCompleteView Admin Console User s Manual. Version 3.8
CompleteView Admin Console User s Manual Version 3.8 Table Of Contents Introduction... 1 End User License Agreement... 1 Overview... 2 Configuration... 3 Starting the Admin Console... 3 Adding a Server...
More informationIdentikey Server Getting Started Guide 3.1
Identikey Server Getting Started Guide 3.1 Disclaimer of Warranties and Limitations of Liabilities Disclaimer of Warranties and Limitations of Liabilities The Product is provided on an 'as is' basis, without
More information