diff --git a/.gitignore b/.gitignore new file mode 100644 index 000000000..743328ec1 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +*.dia~ diff --git a/doc/Analytics.xml b/doc/Analytics.xml index 8f5c0132f..5397a0d3f 100644 --- a/doc/Analytics.xml +++ b/doc/Analytics.xml @@ -4,12 +4,12 @@ Analytics Service Specification Analytics - 23.06 + 23.12 ONVIF™ www.onvif.org - June, 2023 + December, 2023 @@ -259,6 +259,14 @@ Addition of spherical coordinate descriptor, direction descriptor and barcode information. Rule additions for abondoned and removed objects. + + 23.12 + Dec-2023 + + Sriram Bhetanabottla, Hans Busch, Sujith Raman + + JSON Payload section moved to Core spec, fix EyeShape definition, clarify metadata image format and add optional event object description. + @@ -281,8 +289,6 @@ <> RFC 7159 The JavaScript Object Notation (JSON) Data Interchange Format <> - JSON-LD 1.1 A JSON-based Serialization for Linked Data - <> Terms and Definitions @@ -1375,7 +1381,7 @@
Image Data - Frames where objects have been detected can also carry image data within the Scene Description. Image Data relating to a detected object are added in the Appearance Node. Below, the definitions of Image and ImageRef are given for convenience: + Frames where objects have been detected can also carry image data within the Scene Description. Image Data relating to a detected object are added in the Appearance Node. When embedding Image Data as base64Binary, image format shall be either JPG or PNG (On receiving end, start bytes may be used to identify the image type). Below, the definitions of Image and ImageRef are given for convenience: @@ -2443,9 +2449,9 @@ - The following sections describe how topics and payload shall be - structured by an ONVIF metadata producer when published to an MQTT - broker. + The following section describe how topics shall be structured by an ONVIF metadata + producer when published to an MQTT broker. The payload shall be encoded as defined in + Annex E of the ONVIF Core Specification.
MQTT topic structure @@ -2569,120 +2575,6 @@
-
- JSON payload format - - Instead of creating a full fledged schema for XML to JSON conversion, provides a set of generic rules that devices shall need to - implement to express ONVIF metadata in JSON format as defined by RFC 7159. - - - ONVIF Metadata XML to JSON conversion - - - - - ONVIF XML Element - - ONVIF JSON - Representation - - Description - - - - - - <xmltag/> - - “xmltag”: null - - Null tag - - - - <xmltag>text</xmltag> - - “xmltag”: "text" - - Simple tag with value - - - - < xmltag name="value" /> - - “xmltag”:{"@name": "value"} - - Tag with attribute - - - - <xmltag name="value">text</ - xmltag> - - “xmltag”: { "@name": "value", "#text": "text" - } - - Tag with attribute and value - - - - <xmltag> <tag1>text</tag1> - <tag2>text</tag2> </xmltag - - “xmltag”: { "tag1": "text", "tag2": "text" - } - - Tag with multiple child tags - - - - <xmltag> <tag1>text</tag1> - <tag1>text</tag1> </ xmltag> - - “xmltag”: { "tag1": ["text", "text"] - } - - Tag with multiple child tags of same type - (similar to minOccurs > 1) - - - -
- - All extension elements and attributes shall be included within - the same parent JSON object. - Note, that quotes may be omitted for integer and floating point values as well as logical states true and false. - Namespace prefixes for ONVIF defined namespaces shall be - dropped, i.e. elements and attributes that belong to the following - namespaces: - - - - http://www.onvif.org/ver10/schema - - - - http://www.onvif.org/ver20/analytics/humanface - - - - http://www.onvif.org/ver20/analytics/humanbody - - - - http://www.onvif.org/ver20/analytics/radiometry - - - - XML elements and attributes that belong to a different namespace - shall have their names prepended with their corresponding namespace - prefix joined by a ':' as shown in the example while defining - the namespace in the "context" object as per JSON-LD specification.. See specifically the acme:ColorName - exampe. -
-
Example @@ -2805,6 +2697,7 @@ xmlns:acme="http://www.acme.com/schema"> }, { "@x": 20.0, "@y": 80.0 }] + } }, "Color": { "ColorCluster": [{ @@ -3887,6 +3780,8 @@ xmlns:acme="http://www.acme.com/schema"> Optional list of objects triggering this rule. ClassTypes - optional [tt:StringList] Optional list of class types of the detected objects, one for each object, in the same order as object ids are listed. + Object - optional, unbounded [tt:Object] + Optional description of objects triggering this rule. @@ -3901,9 +3796,12 @@ xmlns:acme="http://www.acme.com/schema"> ... + tns1:RuleEngine/Xxxx ]]> + Note that if the message includes Object information there is no need to include + ObjectIds, because each Object includes its ID.
Parameters @@ -6428,7 +6326,7 @@ xmlns:acme="http://www.acme.com/schema"> - + EyeShape @@ -6438,26 +6336,12 @@ xmlns:acme="http://www.acme.com/schema"> - + - - - Slitty - - - - - - - - - - - Round @@ -7496,6 +7380,7 @@ xmlns:acme="http://www.acme.com/schema"> + tns1:RuleEngine/AudioDetector/Class @@ -7538,6 +7423,8 @@ xmlns:acme="http://www.acme.com/schema"> List of detected audio classifications of type tt:AudioClassification. Score - optional [tt:FloatList] Optional list of scores of detected audio classifications. + Loudness - optional [xs:float] + Optional loudness of the detected sound in dB. diff --git a/doc/Core.xml b/doc/Core.xml index aea60c81f..1906dcf04 100644 --- a/doc/Core.xml +++ b/doc/Core.xml @@ -4,12 +4,12 @@ ONVIF Core Specification ONVIF Core Spec - 23.06 + 23.12 ONVIF™ www.onvif.org - June, 2023 + December, 2023 @@ -277,7 +277,7 @@ Venkateswara Rao, Hans Busch - HTTP Digest Authentication - SHA 256 support as per RFC 7616. Clarify behavior in case no hostname has been assigned. Unify analytics and core attribute and value handling. + HTTP Digest Authentication - SHA 256 support as per [RFC 7616]. Clarify behavior in case no hostname has been assigned. Unify analytics and core attribute and value handling. 23.06 @@ -287,6 +287,14 @@ Extend storage configuration for object store. + + 23.12 + Dec-2023 + + Ottavio Campana, Fredrik Svensson + + Add support for JSON Web Tokens + @@ -294,10 +302,10 @@ Version 1 - - - - + + + + Christian Gehrmann (Ed.)> @@ -359,10 +367,10 @@ Version 2 - - - - + + + + Stefan Andersson @@ -500,32 +508,36 @@ Normative references IEEE 1003.1, The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition <> - IETF RFC 2131, Dynamic Host Configuration Protocol + RFC 2131, Dynamic Host Configuration Protocol <> - IETF RFC 2136, Dynamic Updates in the Domain Name System (DNS UPDATE) + RFC 2136, Dynamic Updates in the Domain Name System (DNS UPDATE) <> - IETF RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 + RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 <> - IETF RFC 2617, HTTP Authentication: Basic and Digest Access Authentication + RFC 2617, HTTP Authentication: Basic and Digest Access Authentication <> - IETF RFC 7616, HTTP Digest Access Authentication + RFC 7616, HTTP Digest Access Authentication <> - IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) <> - IETF RFC 3548, The Base16, Base32, and Base64 Data Encodings + RFC 3548, The Base16, Base32, and Base64 Data Encodings <> - IETF RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses + RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses <> - IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax + RFC 3986, Uniform Resource Identifier (URI): Generic Syntax <> - IETF RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace + RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace <> - IETF 4702, The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option + RFC 4702, The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option <> - IETF 4861, Neighbor Discovery for IP version 6 (IPv6) + RFC 4861, Neighbor Discovery for IP version 6 (IPv6) <> - IETF 4862, IPv6 Stateless Address Auto configuration + RFC 4862, IPv6 Stateless Address Auto configuration <> + RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage + <> + RFC 7519, JSON Web Token (JWT) + <> W3C SOAP Message Transmission Optimization Mechanism, <> W3C SOAP 1.2, Part 1, Messaging Framework @@ -561,6 +573,8 @@ <> WGS1984, National Geospatial Intelligence Agency: DoD World Geodetic System 1984 < > + JSON-LD 1.1 A JSON-based Serialization for Linked Data + <> Terms and Definitions @@ -814,6 +828,10 @@ Internet Protocol Version 6 + + JWT + JSON Web Token + LAN @@ -1499,10 +1517,10 @@ - wsdl + wsdl - http://schemas.xmlsoap.org/wsdl/ + http://schemas.xmlsoap.org/wsdl/ WSDL namespace for WSDL framework. @@ -1513,7 +1531,7 @@ wsoap12 - http://schemas.xmlsoap.org/wsdl/soap12/ + http://schemas.xmlsoap.org/wsdl/soap12/ WSDL namespace for WSDL SOAP 1.2 binding. @@ -1524,7 +1542,7 @@ http - http://schemas.xmlsoap.org/wsdl/http/ + http://schemas.xmlsoap.org/wsdl/http/ WSDL namespace for WSDL HTTP GET & POST binding. @@ -1535,7 +1553,7 @@ soapenc - http://www.w3.org/2003/05/soap-encoding + http://www.w3.org/2003/05/soap-encoding Encoding namespace as defined by SOAP 1.2 [SOAP 1.2, Part 2] @@ -1546,7 +1564,7 @@ soapenv - http://www.w3.org/2003/05/soap-envelope + http://www.w3.org/2003/05/soap-envelope Envelope namespace as defined by SOAP 1.2 [SOAP 1.2, Part 1] @@ -1557,7 +1575,7 @@ xs - http://www.w3.org/2001/XMLSchema + http://www.w3.org/2001/XMLSchema Instance namespace as defined by XS [XML-Schema, Part1] and [XML-Schema, Part 2] @@ -1719,7 +1737,7 @@ named set of abstract operations referencing the abstract messages involved. The message definitions map messages to parameter types. - A message defintion shall have exactly one parameter type reference as defined by WS-I basic profile [WS-I BP 2.0] named “parameters”. + A message definition shall have exactly one parameter type reference as defined by WS-I basic profile [WS-I BP 2.0] named “parameters”.
@@ -2180,43 +2198,67 @@ DATE: when response was generated A server should avoid reporting internal errors as this can expose security weaknesses that can be misused.
+
+ SCTP errors + If the server waits for the start of the inbound message and no SOAP message is received, the server shall not generate a SOAP fault and not send any error response. +
Security
- Authentication - The services defined in this standard shall be protected using digest authentication according to [RFC 2617] with the following exceptions. + Authentication over HTTP and HTTPS + The services defined in this standard, whenever consumed overt HTTP and HTTPS, shall be protected using digest authentication according to [RFC 2617] with the following exceptions. - legacy devices supporting [WS-UsernameToken] and + Legacy devices supporting [WS-UsernameToken] and + + + TLS client authorization and - TLS client authorization. + Devices supporting JWT client authorization based on [RFC 6750], only over + HTTPS. If server supports both digest authentication as specified in [RFC 2617] and the user name token profile as specified in WS-Security the following behavior shall be adapted: a web service request can be authenticated on the HTTP level via digest authentication [RFC 2617] or on the web service level via the WS-Security (WSS) framework. If a client does not supply authentication credentials along with a web service request, the server shall assume that the client intends to use digest authentication [RFC 2617], if required. Hence, if a client does not provide authentication credentials when requesting a service that requires authentication, it will receive an HTTP 401 error according to [RFC 2617]. Note that this behaviour on the server’s side differs from the case of supporting only username token profile, which requires for this case an HTTP 400 error on the HTTP level and a SOAP:Fault env:Sender ter:NotAuthorized error on the WS level. A client should not simultaneously supply authentication credentials on both the HTTP level and the WS level. If a server receives a web service request that contains authentication credentials on both the HTTP level and the WS level, it shall first validate the credentials provided on the HTTP layer. If this validation was successful, the server shall finally validate the authentication credentials provided on the WS layer. - - summarizes the authentication of a web service request by a server. + summarizes the authentication of a web service request by a server over HTTP and HTTPS.
- Authentication of a WS request by a server + Authentication of a WS request by a server over HTTP and HTTPS - +
- Both digest authentication and the user name token profile give only a rudimentary level of security. In a system where security is important, it is recommended to always configure the device for TLS-based access (see Advanced Security Service). Digest authentication or the user name token message level security combined with TLS, with client and server authentication, protected transport level security give an acceptable level of security in many systems. + Both digest authentication and WS-Security provide only a rudimentary level of security. In a system where security is important, it is recommended to always configure the device for TLS-based access (see Security Service). Digest authentication or WS-Security messages can be combined with TLS security for a client and server authentication. A protected transport level of security will provide an acceptable level of security in many systems. + JWT client authorization should only be used over TLS secured connections, in order to + protect bearer tokens against replay attacks. An ONVIF compliant device should authenticate an RTSP request at the RTSP level. If HTTP is used to tunnel the RTSP request the device shall not authenticate on the HTTP level. - When authenticating RTSP or HTTP methods, an ONVIF compliant device shall use digest authentication [RFC 2617]. The credentials shall be managed with the GetUsers, CreateUsers, DeleteUsers and SetUser methods. If the device also supports WS-Security, the same set of credentials shall be used. + When authenticating RTSP or HTTP methods, an ONVIF compliant device shall use digest authentication [RFC 2617] or JWT-based authorization. The credentials shall be managed with the GetUsers, CreateUsers, DeleteUsers and SetUser methods. If the device also supports WS-Security, the same set of credentials shall be used. +
+
+ Authentication over SCTP + The services defined in this standard, whenever consumed overt SCTP, shall be protected using digest authentication according to [WS-BinarySecurityToken]. + Since HTTP headers are not present when consuming the services over SCTP, upon authentication failure the device shall return only the a SOAP:Fault env:Sender ter:NotAuthorized error on the WS level. + summarizes the authentication of a web service request by a server over SCTP. +
+ Authentication of a WS request by a server over SCTP + + + + + +
+ WS-Security BinarySecurityToken does not provide security. It is recommended to always configure the device for TLS-based access (see Advanced Security Service). A protected transport level of security will provide an acceptable level of security in many systems. WS-Security BinarySecurityToken should never be used without TLS.
SHA-256 Support in HTTP and RTSP digest authentication - To support SHA-256 hashing algorithm in HTTP and RTSP digest authentication, an ONVIF compliant device and client should follow [RFC 7616]. - Below table explains the default and optional parameters for ONVIF compliant devices: - - Device authentication Behavior + To support the SHA-256 hashing algorithm in HTTP and RTSP digest authentication, an ONVIF compliant device and client should follow [RFC 7616]. + The below table explains the default and optional parameters for ONVIF compliant devices: +
+ Device authentication Behavior @@ -2526,8 +2568,8 @@ X-Frame-Options: SAMEORIGIN]]>
Username token profile - A client shall use both nonce and timestamps as defined in [WS-UsernameToken]. The server shall reject any Username Token not using both nonce and creation timestamps. - This specification defines a set of command for managing the user credentials, see . These commands allow associating users with the different user levels defined in . + A client shall use both nonce and timestamps as defined in [WS-UsernameToken]. The server shall reject any Username Token not using both nonce and creation timestamps. + This specification defines a set of commands for managing the user credentials, see . These commands allow associating users with the different user levels defined in .
@@ -2549,12 +2591,12 @@ X-Frame-Options: SAMEORIGIN]]> An ONVIF compliant device shall have at least one network interface that gives it IP network connectivity. Similarly, the client shall have at least one network interface that gives IP connectivity and allows data communication between the device and the client. Both device and client shall support IPv4 based network communication. The device and client should support IPv6 based network communication. It shall be possible to make static IP configuration on the device using a network or local configuration interface. - An ONVIF compliant device should support dynamic IP configuration of link-local addresses according to [RFC3927]. A device that supports IPv6 shall support stateless IP configuration according to [RFC4862] and neighbour discovery according to RFC4861. + An ONVIF compliant device should support dynamic IP configuration of link-local addresses according to [RFC 3927]. A device that supports IPv6 shall support stateless IP configuration according to [RFC 4862] and neighbour discovery according to [RFC 4861]. The device shall support dynamic IP configuration according to [RFC 2131]. A device that supports IPv6 shall support stateful IP configuration via DHCPv6 according to [RFC3315] if signaled via the corresponding capability. The device may support any additional IP configuration mechanism. Network configuration of a device shall be provided via the ONVIF device management service as specified in section and may additionally be provided through local interfaces. The latter is outside the scope of this specification. The default device configuration shall have both DHCP and dynamic link-local (stateless) address configuration enabled. Even if the device is configured through a static address configuration it should have the link-local address default enabled. - When a device is connected to an IPv4 network, address assignment priorities (link local versus routable address) should be done as recommended in [RFC3927]. + When a device is connected to an IPv4 network, address assignment priorities (link local versus routable address) should be done as recommended in [RFC 3927]. Note that the network interface should set up an explicit IPv4 route for multicast traffic to ensure that WS-Discovery is successful, whether a default route is present or not. In a linux environment, this can be done with a command line like: /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 Further details regarding how the IP connectivity is achieved are outside the scope of this standard. @@ -2567,7 +2609,7 @@ X-Frame-Options: SAMEORIGIN]]> protocol [WS-Discovery]. A device compliant with this specification shall implement the Target Service role as specified in [WS-Discovery] unless it signals DiscoveryNotSupported via its capabilities. - [WS-Discovery] describes the Universally Unique Identifier (UUID): URI format recommendation for endpoint references in Section 2.6, but this specification overrides this recommendation. Instead, the Uniform Resource Name: Universally Unique Identifier (URN:UUID) format is used [RFC4122] (see Section ). + [WS-Discovery] describes the Universally Unique Identifier (UUID): URI format recommendation for endpoint references in Section 2.6, but this specification overrides this recommendation. Instead, the Uniform Resource Name: Universally Unique Identifier (URN:UUID) format is used [RFC 4122] (see Section ).
Modes of operation @@ -2587,7 +2629,7 @@ X-Frame-Options: SAMEORIGIN]]> Discovery definitions
Endpoint reference - A device or an endpoint that takes the client role should use a URN:UUID [RFC4122] as the address property of its endpoint reference. + A device or an endpoint that takes the client role should use a URN:UUID [RFC 4122] as the address property of its endpoint reference. The device or an endpoint that takes the client role shall use a stable, globally unique identifier that is constant across network interfaces as part of its endpoint reference property. The combination of an wsadis:Address and wsadis:ReferenceProperties provide a stable and globally-unique identifier.
@@ -2678,6 +2720,28 @@ X-Frame-Options: SAMEORIGIN]]> The searchable name of the device. A device shall include at least one name entry into its scope list. + + + MacAddress + + + Any character string. + + + MacAddress of the network interface. + + + + + SerialNumber + + + Any character string (alphanumeric). + + + Unique serial number of the device. + +
@@ -3335,7 +3399,7 @@ onvif://www.onvif.org/name/ARV-453
SetHostname This operation sets the hostname on a device. It shall be possible to set the device hostname configurations through the SetHostname command. Attention: a call to SetDNS may result in overriding a previously set hostname. - A device shall accept strings formated according to RFC 1123 section 2.1 or alternatively to RFC 952, other string shall be considered as invalid strings. + A device shall accept strings formated according to [RFC 1123] section 2.1 or alternatively to [RFC 952], other string shall be considered as invalid strings. A device shall try to retrieve the name via DHCP when the HostnameFromDHCP capability is set and an empty name string is provided. @@ -3517,7 +3581,7 @@ onvif://www.onvif.org/name/ARV-453
SetNTP This operation sets the NTP settings on a device. If support for NTP is signalled via the NTP capability, it shall be possible to set the NTP server settings through the SetNTP command. - A device shall accept string formated according to RFC 1123 section 2.1, other string shall be considered as invalid strings. It is valid to set the FromDHCP flag while the device is not using DHCP to retrieve its IPv4 address. + A device shall accept string formated according to [RFC 1123] section 2.1, other string shall be considered as invalid strings. It is valid to set the FromDHCP flag while the device is not using DHCP to retrieve its IPv4 address. Changes to the NTP server list shall not affect the clock mode DateTimeType. Use SetSystemDateAndTime to activate NTP operation. @@ -3865,7 +3929,7 @@ onvif://www.onvif.org/name/ARV-453
GetZeroConfiguration - This operation gets the zero-configuration from a device. If the device supports dynamic IP configuration according to [RFC3927], it shall support the return of IPv4 zero configuration address and status through the GetZeroConfiguration command + This operation gets the zero-configuration from a device. If the device supports dynamic IP configuration according to [RFC 3927], it shall support the return of IPv4 zero configuration address and status through the GetZeroConfiguration command request @@ -4805,7 +4869,7 @@ onvif://www.onvif.org/name/ARV-453 - In case it is not possible to provide exact figures for either UploadDelay or ExpectedDownTime, the device shall provide best-effort estimates. + In case it is not possible to provide exact figures for either UploadDelay or ExpectedDownTime, the device shall provide best-effort estimates.
GetSystemLog @@ -5933,7 +5997,7 @@ onvif://www.onvif.org/name/ARV-453
Input/Output (I/O) - The commands in ths section are kept for backward compatibility purposes. For a more extensive IO interface please refer to the ONVIF Device IO Specification. + The commands in this section are kept for backward compatibility purposes. For a more extensive IO interface please refer to the ONVIF Device IO Specification. The Input/Output (I/O) commands are used to control the state or observe the status of the I/O ports. If the device has I/O ports, then it shall support the I/O commands.
GetRelayOutputs @@ -6052,7 +6116,7 @@ onvif://www.onvif.org/name/ARV-453
SendAuxiliaryCommand This section describes operations to manage auxiliary commands supported by a device, such as controlling an Infrared (IR) lamp, a heater or a wiper or a thermometer that is connected to the device. - The commands supported by the device is reported in the AuxiliaryCommands attribute returned by the capabilites commands, see section . The command transmitted by using this command should match one of the commands supported by the device. If for example the capability command response lists only irlampon command, then the SendAuxiliaryCommand argument will be irlampon, which may indicate turning the connected IR lamp on. + The commands supported by the device is reported in the AuxiliaryCommands attribute returned by the capabilities commands, see section . The command transmitted by using this command should match one of the commands supported by the device. If for example the capability command response lists only irlampon command, then the SendAuxiliaryCommand argument will be irlampon, which may indicate turning the connected IR lamp on. Although the name of the auxiliary commands can be freely defined, commands starting with the prefix tt: are reserved to define frequently used commands and these reserved commands shall all share the "tt:command|parameter" syntax. @@ -6623,7 +6687,7 @@ Event description: The device evaluates the subscription request and returns either a CreatePullPointSubscriptionResponse or one of the Fault codes. - If the subscription is accepted, the response contains a WS-EndpointReference to the instanciated pull point. This WS-Endpoint provides a PullMessages operation, which is used by the client to retrieve Notifications. Additionally it provides the Renew and Unsubscribe operations of the Base Subscription Manager Interface. The sequence diagram of the interaction is shown in . + If the subscription is accepted, the response contains a WS-EndpointReference to the instantiated pull point. This WS-Endpoint provides a PullMessages operation, which is used by the client to retrieve Notifications. Additionally it provides the Renew and Unsubscribe operations of the Base Subscription Manager Interface. The sequence diagram of the interaction is shown in .
@@ -6640,7 +6704,7 @@ Event description: For a device implementation it is important to support multiple pull points (including multiple pullpoints per client) in order to allow precise event generation. If a device would only support one subscription at a time a client would need to subscribe without any scope restriction, because changing of event subscription is not possible. Hence this would require the device to serve all available events for which the device would have to activate all subsystems that generate events. This may cause unnecessary load by e.g. activating multiple motion detectors and similar without need. Additionally the traffic produced by all these events may cause a substantial network load. - If the device supports persistent notification storage, see , the WS-Endpoint also provides a Seek operation. This operation allows to reposition the pull pointer into the past. With the Seek operation it is also possible to revserse the pull direction. There is also a BeginOfBuffer event, as defined in , that signals the start of the buffer. + If the device supports persistent notification storage, see , the WS-Endpoint also provides a Seek operation. This operation allows to reposition the pull pointer into the past. With the Seek operation it is also possible to reverse the pull direction. There is also a BeginOfBuffer event, as defined in , that signals the start of the buffer. An ONVIF compliant device shall implement the Real Time Pull-Point Notification Interface.
Create pull point subscription @@ -6897,12 +6961,12 @@ Event description: depicts the basic operation of a pull point. This chapter states the requirements on the pull point lifecycle. A device shall create a new pull point on each CreatePullPointSubscription command as long as the number of instantiated pull points does not exceed the capability MaxPullPoints. Each pull point shall have a unique endpoint reference to which the client can direct its consecutive operations on the pull point. - A pull point shall exist until either its termination time has elapsed or the client has requested its disposal via an Unsubscribe request. There are no requirements regarding persitancy of a pull point across a power cycle of a device. + A pull point shall exist until either its termination time has elapsed or the client has requested its disposal via an Unsubscribe request. There are no requirements regarding persistency of a pull point across a power cycle of a device.
Persistent notification storage To ensure that no notifications are lost by a client a device may store its notifications. The stored notifications can at any time be retrieved by a client. The device shall indicate if its support persistent notification storage with the PersistentNotificationStorage capability. See section . - This specification defines that the interface to the persistant storage allows linear access via the originating message event time. This holds also for events that are delivered out of order in the live streaming case due to e.g. computational dealy. + This specification defines that the interface to the persistent storage allows linear access via the originating message event time. This holds also for events that are delivered out of order in the live streaming case due to e.g. computational delay. The details of what notification and how and where those notifications actually are stored are outside the scope of this specification. Removal policy of stored notifications to get room for new ones is also out of scope.
@@ -7032,7 +7096,7 @@ Event description:
Property Events - This specification introduces the notion of a propery event which allows observation of state changes of properties. As with other events a property is uniquely identified by its Topic and Source. The state of a property is reflected by the values of its Data items. + This specification introduces the notion of a property event which allows observation of state changes of properties. As with other events a property is uniquely identified by its Topic and Source. The state of a property is reflected by the values of its Data items. Each property has an individual lifecycle in a subscription as shown in Figure 7.
@@ -7253,7 +7317,7 @@ Event description: ONVIF Topic Namespace The [WS-Topics] specification distinguishes between the definition of a Topic Tree belonging to a certain Topic Namespace and the Topic Set supported by a certain Web Service. This distinction allows vendors to refer to a common Topic Namespace while only using a portion of the defined Topics. If the Topic Tree of an existing Topic Namespace covers only a subset of the topics available by a device, the Topic Tree can be grown by defining a new Topic Namespace. A new Topic Namespace is defined by appending a new topic to an existing Topic Namespace as described in the [WS-Topics] specification. - All notifications referring to topics in the ONVIF topic namespace shall use the Message Format as described in Section . + All notifications referring to topics in the ONVIF topic namespace shall use the Message Format as described in Section .
Topic Type Information @@ -7396,7 +7460,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet
Capabilities - The capabilities reflect optional functions and functionality of a service. The information is static and does not change during device operation. The following capabilites are available: + The capabilities reflect optional functions and functionality of a service. The information is static and does not change during device operation. The following capabilities are available: WSSubscriptionPolicySupport @@ -7945,7 +8009,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet
Topic Structure Topics are published according to the following structure, expressed as ABNF rules - according to RFC 5234. Note that special characters like, '#' and '+' shall be omitted + according to [RFC 5234]. Note that special characters like, '#' and '+' shall be omitted from the topic. For an example, see section . Topic = TopicPrefix "/" PayloadPrefix "/" LocalTopic [ "/&" Source ] Source = SVALUE *("/" SVALUE) @@ -8011,7 +8075,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet
JSON Event Payload - This section describes how an ONVIF event is mapped to the JSON data format when published using the "onvif-ej" payload definition. Mapping definition from XML to JSON according to RFC 5234: + This section describes how an ONVIF event is mapped to the JSON data format when published using the "onvif-ej" payload definition. Mapping definition from XML to JSON according to [RFC 5234]: MESSAGE = "{" TIMEINFO "," SOURCE ["," DATA ] "}" TIMEINFO = DQUOTE "UtcTime" DQUOTE ":" TIMESTAMP SOURCE = DQUOTE "Source" DQUOTE ":" "{" *(ITEM) "}" @@ -8294,7 +8358,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet SystemLogging - Indication if the device supports system log retrieval as specified in Section . + Indication if the device supports system log retrieval as specified in Section . @@ -8357,7 +8421,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet - + Device – Security @@ -8431,9 +8495,13 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet Indication if the device supports the WS-Security REL token [WS-RELToken]. + + JsonWebToken + Indication if the devices supports JWT-based authentication. + - Dot1X + Dot1X Indication if the device supports IEEE 802.1X port-based network authentication (deprecated). @@ -8774,28 +8842,25 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet Bibliography [EAP-Registry] Extensible Authentication Protocol (EAP) Registry - [http://www.iana.org/assignments/eap-numbers/eap-numbers.xml] - ONVIF Security Recommendations White Paper - [http://www.onvif.org/portals/3/documents/whitepapers/ONVIF_Security_Recommendations_ver10.pdf] - ONVIF PTZ Coordinate Spaces White Paper - [http://www.onvif.org/Portals/0/documents/whitepapers/ONVIF_PTZ_coordinate_spaces.pdf] + [http://www.iana.org/assignments/eap-numbers/eap-numbers.xml] + ONVIF Recommendations for Cybersecurity Best Practices for IP-based Physical Security Products + [] RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee et al., August 1998 [http://www.ietf.org/rfc/rfc2396.txt] - [UDDI API ver2, “UDDI Version 2.04 API Specification UDDI Committee Specification, 19 July 2002”, OASIS standard, 19 July 2002 [http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf] + [UDDI API ver2, “UDDI Version 2.04 API Specification UDDI Committee Specification, 19 July 2002”, OASIS standard, 19 July 2002> + [] [UDDI Data Structure ver2] “UDDI Version 2.03 Data Structure Reference UDDI Committee Specification”, OASIS standard, 19 July 2002. - + []> [WS-KerberosToken] “Web Services Security Kerberos Token Profile 1.1”, OASIS Standard, ,1 February 2006. - + [] [WS-SAMLToken] “Web Services Security: SAML Token Profile 1.1”, OASIS Standard, 1 February 2006. - + [] [WS-X.509Token] “Web Services Security X.509 Certificate Token Profile 1.1”, OASIS Standard,1 February 2006. - + [] [WS-RELToken] “Web Services Security Rights Expression Language (REL) Token Profile 1.1”, OASIS Standard, 1 February 2006 - + [] + [WS-BinarySecurityToken] “Basic Security Profile Version 1.1 Committee Specification 01”, + OASIS Standard, 22 October 2004 + [] [X.680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation. @@ -8812,23 +8877,19 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). [ONVIF DM WSDL] ONVIF Device Management Service WSDL, ver 2.1, 2011. - + [] [ONVIF Event WSDL] ONVIF Event Service WSDL, ver 2.1, 2011. - + [] [ONVIF DP WSDL] ONVIF Remote Discovery Proxy Services WSDL, ver 2.0, 2010. - + [] [ONVIF Schema] ONVIF Schema, ver 2.0, 2010. - + [] [ONVIF Topic Namespace] ONVIF Topic Namespace XML, ver 2.0, 2010. - + [] [ONVIF Security] ONVIF Advanced Security Specification + [ONVIF Analytics] ONVIF Analytics Service Specification WS-I, Basic Profile Version 2.0 – Working Group Draft, C. Ferris (Ed), A. Karmarkar (Ed) and P. Yendluri (Ed), October 2007. - <http://www.ws-i.org/Profiles/BasicProfile-2_0(WGD).html> + [ Example for GetServices Response with capabilities @@ -8942,7 +9003,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet Deprecated Interfaces
- D.1 Remote Discovery Proxy + Remote Discovery Proxy The definition and interfaces for the Remote Discovery Proxy have been deprecated with release 2.6.1. The following interfaces have been removed from the specification: @@ -8961,7 +9022,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet The definitions are available via the link http://www.onvif.org/specs/core/ONVIF-Core-Specification-v260.pdf.
- D.2 Security + Security The definition and interfaces for the Security have been deprecated with release 16.12. The following interfaces have been removed from the specification: The Security part was handed over to Advanced Security Service. @@ -9037,6 +9098,120 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet The definitions are available via the link http://www.onvif.org/specs/core/ONVIF-Core-Specification-v1606.pdf.
+ + JSON payload format +
+ XML to JSON conversion guidance + Instead of creating a full fledged schema for XML to JSON conversion, provides a set of generic rules to express ONVIF XML in JSON format + as defined by RFC 7159. + + + ONVIF XML to JSON conversion + + + + + ONVIF XML Element + + ONVIF JSON + Representation + + Description + + + + + + <xmltag/> + + “xmltag”: null + + Null tag + + + + <xmltag>text</xmltag> + + “xmltag”: "text" + + Simple tag with value + + + + < xmltag name="value" /> + + “xmltag”:{"@name": "value"} + + Tag with attribute + + + + <xmltag name="value">text</ + xmltag> + + “xmltag”: { "@name": "value", "#text": "text" + } + + Tag with attribute and value + + + + <xmltag> <tag1>text</tag1> + <tag2>text</tag2> </xmltag + + “xmltag”: { "tag1": "text", "tag2": "text" + } + + Tag with multiple child tags + + + + <xmltag> <tag1>text</tag1> + <tag1>text</tag1> </ xmltag> + + “xmltag”: { "tag1": ["text", "text"] + } + + Tag with multiple child tags of same type + (similar to maxOccurs > 1) + + + +
+ + All extension elements and attributes shall be included within + the same parent JSON object. + Note, that quotes may be omitted for integer and floating point values as well as logical states true and false. + Namespace prefixes for ONVIF defined namespaces shall be + dropped, i.e. elements and attributes that belong to the following + namespaces: + + + + http://www.onvif.org/ver10/schema + + + + http://www.onvif.org/ver20/analytics/humanface + + + + http://www.onvif.org/ver20/analytics/humanbody + + + + http://www.onvif.org/ver20/analytics/radiometry + + + + XML elements and attributes that belong to a different namespace shall have their + names prepended with their corresponding namespace prefix joined by a ':' while defining the + namespace in the "context" object as per JSON-LD specification. See specifically the + acme:ColorName as part of JSON metadata example in ONVIF Analytics Service specification for + better understanding. +
+ Revision History diff --git a/doc/Security.xml b/doc/Security.xml index 3f7cb1fb8..9a40bed4e 100644 --- a/doc/Security.xml +++ b/doc/Security.xml @@ -4,12 +4,12 @@ Advanced Security Service Specification Security Configuration - 23.06 + 23.12 ONVIF™ www.onvif.org - June 2023 + December 2023 @@ -42,8 +42,7 @@ Dirk Stegemann - Change Request 1219, 1220 -1222, 1267, 1271, 1272, 1277 + Change Request 1219, 1220, 1222, 1267, 1271, 1272, 1277 1.0.2 @@ -67,8 +66,7 @@ Dirk Stegemann - Change Request 1552, 1555, 1565, 1580, 1583, 1590, 1615, 1616, 1617, 1618, 1619 -Added certificate-based client authentication + Change Request 1552, 1555, 1565, 1580, 1583, 1590, 1615, 1616, 1617, 1618, 1619. Added certificate-based client authentication 1.3 @@ -79,8 +77,7 @@ Added certificate-based client authentication Added IEEE 802.1X configuration - - + Mar-2017 Hans Busch @@ -143,6 +140,14 @@ Added certificate-based client authentication Remove requirement on passphrase support. + + 23.12 + Dec-2023 + + Ottavio Campana, Fredrik Svensson + + Added support for ECC cryptography, JSON Web Tokens, Authorization Servers using OAuth2 and OpenID Connect. + @@ -152,37 +157,60 @@ Added certificate-based client authentication Normative References + Basic Security Profile Version 1.1 Committee Specification 01, OASIS Standard, 22 October 2004 + <https://docs.oasis-open.org/ws-brsp/BasicSecurityProfile/v1.1/cs01/BasicSecurityProfile-v1.1-cs01.pdf> + IANA TLS Supported Groups, Elliptic curve groups + <> IEEE 802.1X, Port-Based Network Access Control - -]]> + <http://standards.ieee.org/getieee802/download/802.1X-2004.pdf> ONVIF Core Specification <http://www.onvif.org/specs/core/ONVIF-Core-Specification.pdf> - RFC 2246 The TLS Protocol Version 1.0 + IETF RFC 2246 The TLS Protocol Version 1.0 <http://www.ietf.org/rfc/rfc2246.txt> - RFC 2898 PKCS#5 Password-based Cryptography Specification v2.0 + IETF RFC 2898 PKCS#5 Password-based Cryptography Specification v2.0 <http://www.ietf.org/rfc/rfc2898.txt> - RFC 2986 PKCS #10: Certification RequestSyntaxSpecification Version 1.7 + IETF RFC 2986 PKCS #10: Certification RequestSyntaxSpecification Version 1.7 <http://www.ietf.org/rfc/rfc2986.txt> - RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile + IETF RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <http://www.ietf.org/rfc/rfc3279.txt> - RFC 3447 Public Key Cryptography Standards #1: RSA Cryptogaphy Specifications Version 2.1 + IETF RFC 3447 Public Key Cryptography Standards #1: RSA Cryptography Specifications Version 2.1 <http://www.ietf.org/rfc/rfc3447.txt> - RFC 4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile + IETF RFC 4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <http://www.ietf.org/rfc/rfc4055.txt> - RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 + IETF RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 <http://www.ietf.org/rfc/rfc4346.txt> - RFC 5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification v1.2 + IETF RFC 5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification v1.2 <http://www.ietf.org/rfc/rfc5208.txt> - RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 + IETF RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 <http://www.ietf.org/rfc/rfc5246.txt> - RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile + IETF RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <http://www.ietf.org/rfc/rfc5280.txt> - RFC 5958 Asymmetric Key Packages + IETF RFC 5958 Asymmetric Key Packages <http://www.ietf.org/rfc/rfc5958.txt> - RFC 5959 Algorithms for Asymmetric Key Package Content Type + IETF RFC 5959 Algorithms for Asymmetric Key Package Content Type <http://www.ietf.org/rfc/rfc5959.txt> + IETF RFC 6749 The OAuth 2.0 Authorization Framework + <http://www.ietf.org/rfc/rfc6749.txt> + IETF RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage + <http://www.ietf.org/rfc/rfc6750.txt> + IETF RFC 7517 JSON Web Key (JWK) + <http://www.ietf.org/rfc/rfc7517.txt> + IETF RFC 7518 JSON Web Algorithms (JWA) + <http://www.ietf.org/rfc/rfc7518.txt> + IETF RFC 7519 JSON Web Token (JWT) + <http://www.ietf.org/rfc/rfc7519.txt> + IETF RFC 7643 System for Cross-domain Identity Management: Core Schema + <http://www.ietf.org/rfc/rfc7643.txt> + IETF RFC 8414 OAuth 2.0 Authorization Server Metadata + <http://www.ietf.org/rfc/rfc8414.txt> + IETF RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens + <http://www.ietf.org/rfc/rfc8705.txt> Unified Modeling Language (UML) <http://www.omg.org/spec/UML> + OpenID Connect Core + <https://openid.net/specs/openid-connect-core-1_0.html> + OpenID Connect Discovery + <https://openid.net/specs/openid-connect-discovery-1_0.html> PKCS#5 Password-based Encryption Standard v1.5, RSA Laboratories, 1993 PKCS#12: Personal Information Exchange Syntax v1.0, RSA Laboratories, 1999 @@ -254,6 +282,10 @@ Added certificate-based client authentication verification of the signature. + + ECC key pair + A key pair that is accepted as input by the ECC algorithm. + Inner @@ -343,6 +375,12 @@ Added certificate-based client authentication EAP Extensible Authentication Protocol + + ECC + + Elliptic Curve Cryptography + + HTTP Hypertext Transfer Protocol @@ -351,6 +389,14 @@ Added certificate-based client authentication IEEE Institute of Electrical and Electronics Engineers + + JWS + JSON Web Signature + + + JWT + JSON Web Token + MAC Message Authentication Code @@ -367,6 +413,10 @@ Added certificate-based client authentication PEAP Protected EAP + + SCTP + Stream Control Transmission Protocol + SHA Secure Hashing Algorithm @@ -395,8 +445,8 @@ Added certificate-based client authentication Referenced namespaces (with prefix) - - + + @@ -421,7 +471,7 @@ Added certificate-based client authentication tas - http://www.onvif.org/advancedsecurity/wsdl + http://www.onvif.org/ver10/advancedsecurity/wsdl @@ -469,7 +519,7 @@ Added certificate-based client authentication IEEE 802.1X - Basic security features such as user authentication based on WS UsernameToken and HTTP Authentication as well as a default access policy are specified in the [ONVIF Core Specification] as part of the device management service. + Basic security features such as user authentication based on WS UsernameToken and HTTP Authentication as well as a default access policy are specified in the ONVIF Core Specification as part of the device management service. WSDL for the Security Configuration Service is specified in <http://www.onvif.org/ver10/advancedsecurity/wsdl/security.wsdl>. All sections in this specification are normative unless explicitly marked as informative. @@ -506,13 +556,13 @@ Added certificate-based client authentication Algorithm steps: - Construct all prospective certification paths c1,…,cn from the input certification path c1,…,cm as specified in Sect. . If no prospective certification path can be constructed from the input certification path, return invalid. + Construct all prospective certification paths c1,…,cn from the input certification path c1,…,cm as specified in Sect. . If no prospective certification path can be constructed from the input certification path, return invalid. For all prospective certification paths c1,…,cn - Determine whether c1,…,cn is valid by applying the algorithm defined in Sect. with inputs + Determine whether c1,…,cn is valid by applying the algorithm defined in Sect. with inputs Prospective certification path c1,…,cn @@ -606,7 +656,7 @@ Added certificate-based client authentication Algorithm steps: - Execute the algorithm specified in [RFC 5280], Sect. 6.1, with inputs + Execute the algorithm specified in RFC 5280, Sect. 6.1, with inputs Prospective certification path cn,…,c1 @@ -644,7 +694,7 @@ Added certificate-based client authentication If the output of step (1) contains a success indication, return true. Otherwise, return false. - For determining the revocation status of a given certificate cert (Step (3) in [RFC 5280, Sect. 6.1.3]) in Step (1), the device shall use the algorithm defined in Sect. with inputs + For determining the revocation status of a given certificate cert (Step (3) in RFC 5280, Sect. 6.1.3) in Step (1), the device shall use the algorithm defined in Sect. with inputs Certificate := cert @@ -653,7 +703,7 @@ Added certificate-based client authentication Certification path validation policy - In order to determine whether an X.509 version 1 or version 2 certificate is a CA certificate as required in [RFC 5280], Sect. 6.1.4, step (k), the device shall use the source specified in the cA-information-source-for-v1-and-v2 information of the certification path validation policy. + In order to determine whether an X.509 version 1 or version 2 certificate is a CA certificate as required in RFC 5280, Sect. 6.1.4, step (k), the device shall use the source specified in the cA-information-source-for-v1-and-v2 information of the certification path validation policy.
Determine Certificate Revocation Status @@ -681,7 +731,7 @@ Added certificate-based client authentication Algorithm steps: - For all CRLs l that shall be considered according to the certification path validation policy, execute the CRL validation algorithm defined in [RFC 5280], Sect. 6.3 with inputs + For all CRLs l that shall be considered according to the certification path validation policy, execute the CRL validation algorithm defined in RFC 5280, Sect. 6.3 with inputs Certificate := the certificate cert @@ -704,20 +754,20 @@ Added certificate-based client authentication Certification Path Validation Policy
Certification Path Validation Algorithm Parameters - By default, a device shall use the values defined in for the algorithm parameters defined in [RFC 5280, Sect. 6.1.1] for the certification path validation algorithm defined in Sect. . + By default, a device shall use the values defined in for the algorithm parameters defined in RFC 5280, Sect. 6.1.1 for the certification path validation algorithm defined in Sect. .
Default parameter values for the certification path validation algorithm - - - + + + Parameter - Default Value + Default Default Value Semantics @@ -808,20 +858,20 @@ Added certificate-based client authentication
Revocation Status Checking - By default, a device shall use the parameter values defined in for the parameters defined in [RFC 5280, Sect. 6.1.1] for the CRL-based certificate revocation status checking algorithm defined in Sect. . + By default, a device shall use the parameter values defined in for the parameters defined in RFC 5280, Sect. 6.1.1 for the CRL-based certificate revocation status checking algorithm defined in Sect. .
Default parameter values for the revocation status checking algorithm - - - + + + Parameter - Default Value + Default Default Value Semantics @@ -848,7 +898,7 @@ Added certificate-based client authentication All-reasons - The device considers a certificate revoked if it has been revoked for any reason defined in [RFC 5280]. + The device considers a certificate revoked if it has been revoked for any reason defined in RFC 5280. @@ -860,29 +910,29 @@ Added certificate-based client authentication
Trust Anchors - The trust anchors assigned to the certification path validation policy shall be used as trust anchor input to the certification path validation algorithm specified in Sect. . + The trust anchors assigned to the certification path validation policy shall be used as trust anchor input to the certification path validation algorithm specified in Sect. .
Certificate Repository for constructing Certification Paths - By default, the certification path validation algorithm specified in Sect. shall consider all certificates in the keystore on the device when constructing prospective certification paths. + By default, the certification path validation algorithm specified in Sect. shall consider all certificates in the keystore on the device when constructing prospective certification paths.
Specific certification path validation parameters - defines additional certification path validation parameters. + defines additional certification path validation parameters.
Specific certification path validation parameters - - - + + + Parameter - Default Value + Default Default Value Semantics @@ -908,11 +958,11 @@ Added certificate-based client authentication
Validate CRLs - By default, the device shall use the following algorithm to obtain and validate the certification path for a CRL issuer in Step (f) of the CRL processing algorithm defined in [RFC 5280, Sect. 6.3.3]. + By default, the device shall use the following algorithm to obtain and validate the certification path for a CRL issuer in Step (f) of the CRL processing algorithm defined in RFC 5280, Sect. 6.3.3. Algorithm input: - CRL l + CRL Certification path validation policy @@ -928,7 +978,7 @@ Added certificate-based client authentication For each certificate ci - Execute the certification path validation algorithm defined in Sect. with input + Execute the certification path validation algorithm defined in Sect. with input The certification path with ci as the only certificate in the path @@ -955,6 +1005,82 @@ Added certificate-based client authentication
+
+ JWT-based client authorization + Unlike with HTTP Digest and WS-UsernameToken authentication, this specification defines how to associate clients with the different User Levels as defined in the ONVIF Core Specification. Devices are not expected to have the user credentials stored in their memory, instead they will verify that the user has been correctly authenticated by a trusted service based on OpenID Connect and authorize accessing different functions, based on the claims presented in the supplied JWT. JWTs can be presented has headers in case of HTTPS or RTSP, or they can be embedded in SOAP messages, in the form of binary security tokens. In case JWTs are embedded in binary security tokens, their content is base64-encoded according to RFC 7519. + JWTs consists of three elements: + + + + JOSE header + + + Payload + + + Signature + + + + The JOSE header shall declare that the encoded object is a JSON Web Token by setting the typ parameter to JWT, and the JWT is a JWS that is signed using the algorithm identified by the alg claim with a value defined in RFC7518. Since the keystore does not support symmetric encryption, this specification only mandates asymmetric encryption. + The JWT payload shall include the following standard claims: + + + + iss: Issuer, the URI of the server that generated the JWT. + + + aud: Audience, a list of strings representing the recipients that the JWT is intended for. Each principal intended to process the JWT shall identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the audience claim when this claim is present, then the JWT shall be rejected. + + + exp: Expiration Time. + + + nbf: Not before. + + + + For the exp, nbf claims, a device shall reject a token when the current time is not within the range of claims nbf and exp . It shall reject a token when at least one of the claims is missing. + The JWT payload shall include the roles claim, as defined within RFC 7643: + + + + roles: Access class. One of the authenticated classes of the default access policy prefixed with the string onvif:, i.e. "onvif:Administrator", "onvif:Operator" or "onvif:User" as defined also within the ONVIF Core Specification. This access level will be used to authorize access to the required function. + + + + The signature is evaluated by applying ECDSA using secp256r1 and SHA-256 hashing to the base64-encoded header and payload, concatenated by a '.' + ECDSA-SHA256 (base64UrlEncode(header) + "." + + base64UrlEncode(payload), + secp256r1)) + The evaluated signature is further appended to the encoded header and payload with a '.' separator, to get the final JWT. Appendix demonstrates the construction or a JWT. + The signature is used to protect the JWT data integrity and JWT source authenticity. +
+ Usage of JWT-based client authentication over HTTP + Since authentication tokens contain sensitive information that could be easily used to perform replay attacks, JWT-based client authentication shall not be used over unencrypted HTTP connections. +
+
+ Usage of JWT-based client authentication over HTTPS + Usage JWT-based client authentication over HTTPS shall adhere to the Authorization Request header Field, as specified by RFC 6750. In case of authentication failure, ONVIF-compliant devices shall respond with the error codes specified by RFC 6750. +
+
+ Usage of JWT-based client authentication over SCTP + In scenarios where a SCTP channel is used to exchange commands and responses between the device and the client, it is not possible to embed a JWT within a header. In this case, the JWT can be embedded in the Security Token of the SOAP message, as defined in the WS-Security Basic Security Profile. + A client shall use both ValueType and EncodingType. The device shall reject any Binary Security Token not using both ValueType and EncodingType. + The EncodingType attribute shall have the value of + http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#BinarySecurityToken + The ValueType attribute shall have the value of + urn:ietf:params:oauth:token-type:jwt +
+
+ Usage of JWT-based client authentication over RTSP + Since authentication tokens contain sensitive information that could be easily used to perform replay attacks, JWT-based client authentication shall be used with RTSP connections only when HTTPS transport is selected. +
+
+ Usage of JWT-based client authentication over RTSPS + Since the RTSPS protocol is similar to HTTPS, JWT-based client authentication over RTSPS behaves in the same way as JWT-based client authentication over HTTPS. +
+
IEEE 802.1X IEEE 802.1X is an IEEE standard for port based network access control for the purpose of providing authentication and authorization of the devices attached to LAN ports. It allows access to the LAN port to devices that are configured for access, and prevents access to the LAN port to devices that are not correctly configured. @@ -962,6 +1088,235 @@ Added certificate-based client authentication This specification defines a set of commands to configure and manage a device’s IEEE 802.1X configurations, both for wireless and hardwired network interfaces. It assumes that IEEE 802.1X configuration and reconfiguration is performed outside of the IEEE 802.1X-secured network. Many schema elements in this specification include Dot1X as shorthand for IEEE 802.1X. This convention increases the readability of source code generated from the WSDL.
+
+ Authorization Servers + This section describes use of external authorization servers that can be used for + providing authentication of users and authorizing access to both device services and + external services, like cloud storage. + OAuth 2.0 is a specification that describes how to issue access tokens. It is defined in RFC6749. OpenID Connect has been developed as an extension of OAuth 2.0. + OAuth 2.0 includes the definition of a web API called "authorization endpoint". Requests to this API must include a parameter called response_type which can be either code or token. OpenID Connect extends the OAuth 2.0 specification, by adding the values id_token and none for response_type and allowing any combination of code, token and id_token. + Any request for ID tokens must include openid in the scope request parameter. +
+ User authentication and authorization + Users can retrieve JWTs from an OpenID Connect server by authenticating and authorizing access to resources by following the OAuth2 Authorization Code Flow. + The Authorization Code Flow is summarized in . +
+ OpenID Connect authorization code flow for users + + + + + +
+ A device can be setup to use JWTs obtained with this flow to allow access to its internal web interface for externally authenticated users. In that case an authorization server configuration with type OAuthAuthorizationCode should be created. + Access to the camera can be granted to users bearing either an ID Token or an Access Token, as long as the claims specified in are present. +
+
+ Device authentication and authorization + Devices will typically use the Oauth2 Client Credentials Grant Flow to gain access to resources. There are a number of different ways for a device (called a client in the OAuth2 Spec) to authenticate with the server using this flow, listed in + The Client Credentials Flow is summarized in . +
+ OpenID Connect client credentials flow for devices + + + + + +
+ Since in the case of a camera accessing a remote resource there is no user involved and no identity to be checked, cameras are expected to use Access Tokens to perform this operation. +
+
+ Authorization server configuration + The following parameters are used when creating a configuration for an external + authorization server. +
+ Authorization server settings + + + + + + + Setting + + Description + + + + + + ServerUri + + + Authorization server address + + + + + ClientId + + + Client identifier issued by the authorization server + + + + + ClientSecret + + + Client secret used to authenticate with the authorization server + + + + + Scope + + + The requested access scope(s) + + + + KeyID + Key identifier for the private_key_jwt authentication method + + + CertificateID + Certificate identifier for the self_signed_tls_client_auth authentication method + + + + Type + + + The type of configuration, see for + possible values. + + + + + ClientAuth + + + The type of client authentication method to use, see for + possible values. + + + + +
+ The following types of authorization server configurations are defined. + + Authorization server configuration types + + + + + + + Method + + Description + + + + + + OAuthAuthorizationCode + + + OAuth2 authorization code flow per RFC 6749. + + + + + OAuthClientCredentials + + + OAuth2 client credentials grant flow per RFC 6749. + + + + + OIDC2AuthorizationCode + + + OpenID Connect authorization code flow per Open ID Connect Core. + The ServerUri is used as metadata URI, where you can retrieve the endpoint + URIs for authorization, token and JWKS. + + + + +
+ The following client authentication methods are defined. + + Client authentication methods + + + + + + + Method + + Description + + + + + + client_secret_basic + + + Use HTTP Authorization header to specify client_secret, see RFC 6749 + + + + + client_secret_post + + + Use HTTP POST body to specify client_secret, see RFC 6749 + + + + + client_secret_jwt + + + Use a HMAC signed JWT using client_secret as shared secret, see OpenID + Connect Core + + + + + private_key_jwt + + + Use PKI signed JWT using private key, see OpenID Connect Core + + + + + tls_client_auth + + + Use PKI certificate to authenticate, see RFC 8705 + + + + + self_signed_tls_client_auth + + + Use self-signed certificate to authenticate, see RFC 8705 + + + + +
+
+
Security Configuration Service @@ -979,12 +1334,12 @@ Added certificate-based client authentication IEEE 802.1X - The design and data model of the ONVIF Security Configuration Service is reflected in . + The design and data model of the ONVIF Security Configuration Service is reflected in .
- ONVIF Security Configuration Service [UML] Class Diagram + ONVIF Security Configuration Service UML Class Diagram - +
@@ -994,7 +1349,7 @@ Added certificate-based client authentication
Elements of the Keystore The keystore security feature handles the storage and management of passphrases, keys, and certificates on an ONVIF device. - The keystore specified in this document supports passphrases, keys, key pairs, which are a particular type of key, RSA key pairs, which are a particular type of key pairs, certificates, certification paths, certificate revocation lists, and certification path validation policies. + The keystore specified in this document supports passphrases, keys, key pairs, RSA and ECC key pairs, which are particular types of key pairs, certificates, certification paths, certificate revocation lists, and certification path validation policies. The boolean attribute externallyGenerated of a key shall be true if and only if the key was generated outside the device. The boolean attribute securelyStored of a key shall be true if and only if the key is stored in a specially protected hardware component (e.g., a trusted platform module) inside the device.
@@ -1237,8 +1592,8 @@ Added certificate-based client authentication Key Management
CreateRSAKeyPair - This operation triggers the asynchronous generation of an RSA key pair of a particular keylength (specified as the number of bits) as specified in [RFC 3447], with a suitable key generation mechanism on the device. Keys, especially RSA key pairs, are uniquely identified using key IDs. - If the device does not have enough storage capacity for storing the key pair to be created, the maximum number of keys reached fault shall be produced and no key pair shall be generated. Otherwise, the operation generates a keyID for the new key and associates the generating status to it. Immediately after key generation has started, the device shall return the keyID to the client and continue to generate the key pair. The client may query the device with the GetKeyStatus operation (see Sect. ) whether the generation has finished. The client may also subscribe to Key Status events (see Sect. ) to be notified about key status changes. + This operation triggers the asynchronous generation of an RSA key pair of a particular keylength (specified as the number of bits) as specified in RFC 3447, with a suitable key generation mechanism on the device. Keys, especially RSA key pairs, are uniquely identified using key IDs. + If the device does not have enough storage capacity for storing the key pair to be created, the maximum number of keys reached fault shall be produced and no key pair shall be generated. Otherwise, the operation generates a keyID for the new key and associates the generating status to it. Immediately after key generation has started, the device shall return the keyID to the client and continue to generate the key pair. The client may query the device with the GetKeyStatus operation (see Sect. ) whether the generation has finished. The client may also subscribe to Key Status events (see Sect. ) to be notified about key status changes. The device also returns a best-effort estimate of how much time it requires to create the key pair.Implementors may estimate the key generation time for a fixed key length as the average elapsed time of a number of key generation operations for this key length. A client may use this information as an indication how long to wait before querying the device whether key generation is completed. After the key has been successfully created, the device shall assign it the ok status. If the key generation fails, the device shall assign the key the corrupt status. @@ -1277,10 +1632,57 @@ Added certificate-based client authentication
+
+ CreateECCKeyPair + This operation triggers the asynchronous generation of an ECC key pair using a particular elliptic curve as specified in RFC 4492, with a suitable key generation mechanism on the device. Keys, especially ECC key pairs, are uniquely identified using key IDs. + If the device does not have enough storage capacity for storing the key pair to be created, the maximum number of keys reached fault shall be produced and no key pair shall be generated. Otherwise, the operation generates a keyID for the new key and associates the generating status to it. Immediately after key generation has started, the device shall return the keyID to the client and continue to generate the key pair. The client may query the device with the GetKeyStatus operation (see Sect. ) whether the generation has finished. The client may also subscribe to Key Status events (see Sect. ) to be notified about key status changes. + The device also returns a best-effort estimate of how much time it requires to create the key pair.Implementors may estimate the key generation time for a fixed key length as the average elapsed time of a number of key generation operations for this key length. A client may use this information as an indication how long to wait before querying the device whether key generation is completed. + After the key has been successfully created, the device shall assign it the ok status. If the key generation fails, the device shall assign the key the corrupt status. + + + request + + EllipticCurve - [xs:string] + The name of the elliptic curve to be used for genereting the ECC keypair. For definitions see IANA TLS Supported Groups. + Alias - optional [xs:string] + The client-defined alias of the key. + + + + response + + KeyID - [tas:KeyID] + The key ID of the key pair being generated. + EstimatedCreationTime - [xs:duration] + Best-effort estimation of how long the key generation will take. + + + + faults + + env:Receiver - ter:Action - ter:MaximumNumberOfKeysReached + The keystore does not have enough storage space to store the key pair that has to be generated. + env:Sender - ter:InvalidArgVal - ter:UnsupportedEllipticCurve + The specified elliptic curve is not supported by the device. + + + + access class + + WRITE_SYSTEM + + + +
UploadKeyPairInPKCS8 This operation uploads a key pair in a PKCS#8 data structure as specified in [RFC 5958, RFC 5959]. - If an encryption passphrase ID is supplied in the request, the device shall assume that the KeyPair parameter contains an EncryptedPrivateKeyInfo ASN.1 structure that is encrypted under the passphrase in the keystore that corresponds to the supplied ID, where the EncryptedPrivateKeyInfo structure contains both the private key and the corresponding public key. If no encryption passphrase ID is supplied, the device shall assume that the KeyPair parameter contains a OneAsymmetricKey ASN.1 structure which contains both the private key and the corresponding public key. If a passphrase is supplied, the device shall ignore an eventually supplied passphrase ID and assume that the KeyPair parameter contains an EncryptedPrivateKeyInfo ASN.1 structure that is encrypted under the supplied passphrase, where the EncryptedPrivateKeyInfo structure contains both the private key and the corresponding public key. + If a passphrase is either directly provided or as ID reference to a previously + uploaded passphrase, the device shall assume that the KeyPair parameter contains an + EncryptedPrivateKeyInfo ASN.1 structure that is encrypted with the given passphrase. + In case neither a passphrase nor a passphrase ID is provided the device shall assume + that the KeyPair parameter contains a OneAsymmetricKey ASN.1 structure which contains + both the private key and the corresponding public key. If the supplied key pair cannot be processed by the device, the device shall produce an UnsupportedPublicKeyAlgorithm fault and shall not store the uploaded key pair in the keystore. Key pairs are uniquely identified using key IDs. If a key pair exists in the keystore with the public key equal to the public key in the request and this key pair does not contain a private key, the device shall add the supplied private key to the existing key pair and return the ID of this key pair. If a key pair exists in the keystore with the public key equal to the public key in the request and this key pair contains a private key, the device shall leave the key pair unchanged and return the ID of this key pair. @@ -1343,7 +1745,7 @@ Added certificate-based client authentication
GetKeyStatus - This operation returns the status of a key as defined in Sect. . + This operation returns the status of a key as defined in Sect. . Keys are uniquely identified using key IDs. If no key is stored under the requested key ID in the keystore, an InvalidKeyID fault is produced. Otherwise, the status of the key is returned. @@ -1380,7 +1782,7 @@ Added certificate-based client authentication This operation returns whether a key pair contains a private key. Keys are uniquely identified using key IDs. If no key is stored under the requested key ID in the keystore, an invalid key ID fault shall be produced. If a key is stored under the requested key ID in the keystore, but this key is not a key pair, an invalid key type fault shall be produced. Otherwise, this operation returns true if the key pair identified by the key ID contains a private key, and false otherwise. - This command is deprecated. Use GetAllKeys (see Sect. ) instead. + This command is deprecated. Use GetAllKeys (see Sect. ) instead. request @@ -1489,7 +1891,7 @@ Added certificate-based client authentication Certificate Management
CreatePKCS10CSR - This operation generates a DER-encoded PKCS#10 v1.7 certification request (sometimes also called certificate signing request or CSR) as specified in [RFC 2986] for a public key on the device. + This operation generates a DER-encoded PKCS#10 v1.7 certification request (sometimes also called certificate signing request or CSR) as specified in RFC 2986 for a public key on the device. The key pair that contains the public key for which a certification request shall be produced is specified by its key ID. If no key is stored under the requested KeyID or the key specified by the requested KeyID is not an asymmetric key pair, an invalid key ID fault shall be produced and no CSR shall be generated. The subject parameter describes the entity that the public key belongs to. Additional attributes can be included in the attribute parameter. Distinguished name attribute values shall be supplied either in UTF-8 or in hexadecimal form as specified in RFC 4514. @@ -1547,19 +1949,19 @@ Added certificate-based client authentication
CreateSelfSignedCertificate - This operation generates for a public key on the device a self-signed X.509 certificate that complies to [RFC 5280]. - The X509Version parameter specifies the version of X.509 that the generated certificate shall comply to. A device that supports this command shall support the generation of X.509v3 certificates as specified in [RFC 5280] and may additionally be able to handle other X.509 certificate formats as indicated by the X.509Versions capability. If no X509Version is specified in the request, the device shall produce an X.509v3 certificate. + This operation generates for a public key on the device a self-signed X.509 certificate that complies to RFC 5280. + The X509Version parameter specifies the version of X.509 that the generated certificate shall comply to. A device that supports this command shall support the generation of X.509v3 certificates as specified in RFC 5280 and may additionally be able to handle other X.509 certificate formats as indicated by the X.509Versions capability. If no X509Version is specified in the request, the device shall produce an X.509v3 certificate. The key pair that contains the public key for which a self-signed certificate shall be produced is specified by its key pair ID. The subject parameter describes the entity that the public key belongs to. If the key pair does not have status ok, a device shall produce an InvalidKeyStatus fault and no certificate shall be generated. If the specified subject is invalid or incomplete, an InvalidSubject fault shall be produced and no certificate shall be created. - The notValidBefore parameter specifies at which point in time the validity period of the generated certificate shall begin. If this parameter is not specified in the request, the device shall use its current time or a time before its current time as starting point of the validity period. The notValidAfter parameter specifies at which point in time the validity period of the generated certificate shall end. If this parameter is not specified in the request, the device shall assign the GeneralizedTime value of 99991231235959Z as specified in [RFC 5280] to the notValidAfter parameter. If the notValidBefore parameter is invalid, an invalid DateTime fault shall be produced and no certificate shall be generated. If the notValidAfter parameter is invalid, an invalid DateTime fault shall be produced and no certificate shall be generated. + The notValidBefore parameter specifies at which point in time the validity period of the generated certificate shall begin. If this parameter is not specified in the request, the device shall use its current time or a time before its current time as starting point of the validity period. The notValidAfter parameter specifies at which point in time the validity period of the generated certificate shall end. If this parameter is not specified in the request, the device shall assign the GeneralizedTime value of 99991231235959Z as specified in RFC 5280 to the notValidAfter parameter. If the notValidBefore parameter is invalid, an invalid DateTime fault shall be produced and no certificate shall be generated. If the notValidAfter parameter is invalid, an invalid DateTime fault shall be produced and no certificate shall be generated. The signature algorithm parameter determines which signature algorithm shall be used for signing the certification request with the public key specified by the key ID parameter. - The Extensions parameter specifies potential X509v3 extensions that shall be contained in the certificate. A device that supports this command shall support the extensions that are defined in [RFC5280, Sect. 4.2] as mandatory for CAs that issue self-signed certificates. + The Extensions parameter specifies potential X509v3 extensions that shall be contained in the certificate. A device that supports this command shall support the extensions that are defined in RFC5280, Sect. 4.2 as mandatory for CAs that issue self-signed certificates. Distinguished name attribute values shall be supplied either in UTF-8 or in hexadecimal form as specified in RFC 4514. If the distinguished name attribute value is supplied in hexadecimal form, the device shall encode the attribute in the format given in the hexadecimal format. If the distinguished name attribute value is supplied in UTF-8 and the attribute value has a uniquely defined encoding (e.g., CountryName is defined as PrintableString), the device shall encode the attribute as the defined encoding. Otherwise, the device shall encode the attribute value as UTF-8. - [RFC 5280, Sect. 4.1.2.2] mandates that the certificate serial numbers be unique for each certificate issued by a given issuer (a CA). Since the subject is equal to the issuer in a self-signed certificate, the serial number shall be unique for each self-signed certificate that the device issues for a given subject. - The generated certificate shall not contain a unique identifier as specified in [RFC 5280], Sect. 4.1.2.8. The device shall not mark the generated certificate as trusted. + RFC 5280, Sect. 4.1.2.2 mandates that the certificate serial numbers be unique for each certificate issued by a given issuer (a CA). Since the subject is equal to the issuer in a self-signed certificate, the serial number shall be unique for each self-signed certificate that the device issues for a given subject. + The generated certificate shall not contain a unique identifier as specified in RFC 5280, Sect. 4.1.2.8. The device shall not mark the generated certificate as trusted. Certificates are uniquely identified using certificate IDs. If the command was successful, the device generates a new ID for the generated certificate and returns this ID. If the device does not have enough storage capacity for storing the certificate to be created, the maximum number of certificates reached fault shall be produced and no certificate shall be generated. @@ -1602,7 +2004,7 @@ Added certificate-based client authentication The specified X.509 version is not supported by the device. ter:Sender - ter:InvalidArgVal - ter:KeyID No key is stored under the requested KeyID. - ter:Sender - ter:InvalidArgVal - ter:UnsupportedSignatureAlgorithm + ter:Sender - ter:InvalidArgVal - ter:UnsupportedSignatureAlgorithm The specified signature algorithm is not supported by the device. ter:Sender - ter:InvalidArgVal - ter:KeySignatureAlgorithmMismatch The specified public key is an invalid input to the specified signature algorithm. @@ -1626,27 +2028,27 @@ Added certificate-based client authentication
UploadCertificate - This operation uploads an X.509 certificate as specified by [RFC 5280]in DER encoding and the public key in the certificate to a device’s keystore. A device that supports this command shall be able to handle X.509v3 certificates as specified in [RFC 5280] and may additionally be able to handle other X.509 certificate formats as indicated by the X.509Versions capability. + This operation uploads an X.509 certificate as specified by RFC 5280 in DER encoding and the public key in the certificate to a device’s keystore. A device that supports this command shall be able to handle X.509v3 certificates as specified in RFC 5280 and may additionally be able to handle other X.509 certificate formats as indicated by the X.509Versions capability. Certificates are uniquely identified using certificate IDs, and key pairs are uniquely identified using key IDs. The device shall generate a new certificate ID for the uploaded certificate. Certain certificate usages, e.g. TLS server authentication, require the private key that corresponds to the public key in the certificate to be present in the keystore. In such cases, the client may indicate that it expects the device to produce a fault if the matching private key for the uploaded certificate is not present in the keystore by setting the PrivateKeyRequired argument in the upload request to true. The uploaded certificate has to be linked to a key pair in the keystore. If no private key is required for the public key in the certificate and a key pair exists in the keystore with a public key equal to the public key in the certificate, the uploaded certificate is linked to the key pair identified by the supplied key ID by adding a reference from the certificate to the key pair. If no private key is required for the public key in the certificate and no key pair exists with the public key equal to the public key in the certificate, a new key pair with status ok is created with the public key from the certificate, and this key pair is linked to the uploaded certificate by adding a reference from the certificate to the key pair. - If a private key is required for the public key in the certificate, and a key pair exists in the keystore with a private key that matches the public key in the certificate, the uploaded certificate is linked to this key pair by adding a reference from the certificate to the key pair. If a private key is required for the public key and no such keypair exists in the keystore, the NoMatchingPrivateKey fault shall be produced and the certificate shall not be stored in the keystore. + If a private key is required for the public key in the certificate, and a key pair exists in the keystore with a private key that matches the public key in the certificate, the uploaded certificate is linked to this key pair by adding a reference from the certificate to the key pair. If a private key is required for the public key and no such keypair exists in the keystore, then NoMatchingPrivateKey fault shall be produced and the certificate shall not be stored in the keystore. The device shall assign the supplied Alias to the uploaded certificate. If a new key pair is generated, the device shall assign the supplied KeyAlias to it. Otherwise, the device shall ignore an eventually supplied KeyAlias. - How the link between the uploaded certificate and a key pair is established is illustrated in . + How the link between the uploaded certificate and a key pair is established is illustrated in .
Link establishment between certificate and key pair for Upload Certificate - +
- If the key pair that the certificate shall be linked to does not have status ok, an InvalidKeyID fault is produced, and the uploaded certificate is not stored in the keystore. + If the key pair that the certificate shall be linked to does not have status ok, an InvalidKeyStatus fault is produced, and the uploaded certificate is not stored in the keystore. If the signature algorithm that the signature of the supplied certificate is based on is not supported by the device, the device shall generate an UnsupportedSignatureAlgorithm fault and shall not store the uploaded certificate nor the contained public key in the keystore. - If the device cannot process the uploaded certificate, a BadCertificate fault is produced and neither the uploaded certificate nor the public key are stored in the device’s keystore. The BadCertificate fault shall not be produced based on the mere fact that the device’s current time lies outside the interval defined by the notBefore and notAfter fields as specified by [RFC 5280], Sect. 4.1. + If the device cannot process the uploaded certificate, a BadCertificate fault is produced and neither the uploaded certificate nor the public key are stored in the device’s keystore. The BadCertificate fault shall not be produced based on the mere fact that the device’s current time lies outside the interval defined by the notBefore and notAfter fields as specified by RFC 5280, Sect. 4.1. The device shall not mark the uploaded certificate as trusted. If the device does not have enough storage capacity for storing the certificate to be uploaded, the maximum number of certificates reached fault shall be produced and no certificate shall be uploaded. If the device does not have enough storage capacity for storing the key pair that eventually has to be created, the device shall generate a maximum number of keys reached fault. Furthermore the device shall not generate a key pair and no certificate shall be stored. @@ -1690,7 +2092,7 @@ Added certificate-based client authentication ter:Sender - ter:InvalidArgVal - ter:UnsupportedSignatureAlgorithm The specified signature algorithm is not supported by the device. ter:Sender - ter:InvalidArgVal - ter:InvalidKeyStatus - The key with the requested KeyID has an inappropriate status. + The key pair has an inappropriate status. @@ -1703,18 +2105,18 @@ Added certificate-based client authentication
UploadCertificateWithPrivateKeyInPKCS12 - This operation uploads a certification path consisting of X.509 certificates as specified by [RFC 5280] in DER encoding along with a private key to a device’s keystore. Certificates and private key are supplied in the form of a PKCS#12 file as specified in [PKCS#12]. + This operation uploads a certification path consisting of X.509 certificates as specified by RFC 5280 in DER encoding along with a private key to a device’s keystore. Certificates and private key are supplied in the form of a PKCS#12 file as specified in PKCS#12. The device shall support PKCS#12 files that contain the following safe bags: - one or more instances of CertBag [PKCS#12, Sect. 4.2.3] + one or more instances of CertBag PKCS#12, Sect. 4.2.3 - either exactly one instance of KeyBag [PKCS#12, Sect. 4.3.1] or exactly one instance of PKCS8ShroudedKeyBag [PKCS#12, Sect. 4.2.2]. + either exactly one instance of KeyBag PKCS#12, Sect. 4.3.1 or exactly one instance of PKCS8ShroudedKeyBag PKCS#12, Sect. 4.2.2. If the IgnoreAdditionalCertificates parameter has the value true, the device shall behave as if the client had supplied only the first CertBag in the sequence of CertBag instances. - The device shall support PKCS#12 passphrase integrity mode for integrity protection of the PKCS#12 PFX as specified in [PKCS#12, Sect. 4]. The device shall support PKCS8ShroudedKeyBags that are encrypted with the same passphrase as the CertBag instances. + The device shall support PKCS#12 passphrase integrity mode for integrity protection of the PKCS#12 PFX as specified in PKCS#12, Sect. 4. The device shall support PKCS8ShroudedKeyBags that are encrypted with the same passphrase as the CertBag instances. If an integrity passphrase ID is supplied, the device shall use the corresponding passphrase in the keystore to check the integrity of the supplied PKCS#12 PFX. If an integrity passphrase ID is supplied, but the supplied PKCS#12 PFX has no integrity protection, the device shall produce a BadPKCS12File fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. If an encryption passphrase ID is supplied, the device shall use the corresponding passphrase in the keystore to decrypt the PKCS8ShroudedKeyBag and the CertBag instances. If an EncryptionPassphraseID is supplied, but a CertBag is not encrypted, the device shall ignore the supplied EncryptionPassphraseID when processing this CertBag. If an EncryptionPassphraseID is supplied, but a KeyBag is provided instead of a PKCS8ShroudedKeyBag, the device shall ignore the supplied EncryptionPassphraseID when processing the KeyBag. @@ -1725,18 +2127,18 @@ Added certificate-based client authentication Certificates are uniquely identified using certificate IDs. The device shall store the uploaded certificates in the keystore and generate a new certificate ID for each of the uploaded certificates. Certification paths are uniquely identified using certification path IDs. The device shall create a certification path from the uploaded certificates. In this certification path, the certificates shall appear in the same order as in the PKCS#12 file. The device shall generate a new certification path ID for the created certification path and assign the eventually supplied CertificationPathAlias to the created certification path. The signature of each certificate in the sequence of uploaded certificates except for the last one shall be verifiable with the public key contained in the next certificate in the sequence. If there is a certificate in the request other than the last certificate for which the signature cannot be verified with the public key in the next certificate, the device shall produce an invalid certification path fault and shall not store the uploaded certificates nor uploaded private key in the keystore. - If the device cannot process one of the uploaded certificates, it shall produce a BadCertificate fault and neither store the uploaded certificates nor private key in the keystore. The BadCertificate fault shall not be produced based on the mere fact that the device’s current time lies outside the interval defined by the notBefore and notAfter fields as specified by [RFC 5280], Sect. 4.1. + If the device cannot process one of the uploaded certificates, it shall produce a BadCertificate fault and neither store the uploaded certificates nor private key in the keystore. The BadCertificate fault shall not be produced based on the mere fact that the device’s current time lies outside the interval defined by the notBefore and notAfter fields as specified by RFC 5280, Sect. 4.1. The device shall not mark the uploaded certificates as trusted. The uploaded certificates have to be linked to key pairs in the keystore. Key pairs are uniquely identified using key IDs. If a key pair exists in the keystore with the public key equal to the public key in a certificate in the request, the device shall link the uploaded certificate to the key pair in the keystore by adding a reference from the certificate to the key pair. If the key pair in the keystore does not contain a private key and the private key contained in the KeyBag or PKCS8ShroudedKeyBag that matches the public key in the key pair, the device shall add the private key contained in the KeyBag or PKCS8ShroudedKeyBag to the key pair. If no key pair exists in the keystore with the public key equal to the public key in a certificate in the request, the device shall create a new key pair with status ok, externally generated attribute set to true, and the public and private keys from the request, and shall link this key pair to the uploaded certificate by adding a reference from the certificate to the key pair. If a new key pair is created for the uploaded private key, the device shall assign the supplied KeyAlias to it. Otherwise, the device shall ignore an eventually supplied KeyAlias. - How the link between an uploaded certificate and a key pair is established is illustrated in . + How the link between an uploaded certificate and a key pair is established is illustrated in .
Link establishment between certificates and key pair for Upload Certificate with Private Key in PKCS#12 - +
@@ -2084,7 +2486,7 @@ Added certificate-based client authentication CRL Management
UploadCRL - This operation uploads a certificate revocation list (CRL) as specified in [RFC 5280] to the keystore on the device. + This operation uploads a certificate revocation list (CRL) as specified in RFC 5280 to the keystore on the device. If the device does not have enough storage space to store the CRL to be uploaded, the device shall produce a MaximumNumberOfCRLsReached fault and shall not store the supplied CRL. If the device is not able to process the supplied CRL, the device shall produce a BadCRL fault and shall not store the supplied CRL. If the device does not support the signature algorithm that was used to sign the supplied CRL, the device shall produce an UnsupportedSignatureAlgorithm fault and shall not store the supplied CRL. @@ -2241,7 +2643,7 @@ Added certificate-based client authentication CreateCertPathValidationPolicy This operation creates a certification path validation policy. Certification path validation policies are uniquely identified using certification path validation policy IDs. The device shall generate a new certification path validation policy ID for the created certification path validation policy. - For the certification path validation parameters that are not represented in the certPathValidationParameters data type, the device shall use the default values specified in Sect. . + For the certification path validation parameters that are not represented in the certPathValidationParameters data type, the device shall use the default values specified in Sect. . If the device does not have enough storage capacity for storing the certification path validation policy to be created, the device shall produce a maximum number of certification path validation policies reached fault and shall not create a certification path validation policy. If there is at least one trust anchor certificate ID in the request for which there exists no certificate in the device’s keystore, the device shall produce a CertificateID fault and shall not create a certification path validation policy. If the device cannot process the supplied certification path validation parameters, the device shall produce a CertPathValidationParameters fault and shall not create a certification path validation policy. @@ -2396,21 +2798,21 @@ Added certificate-based client authentication TLS Server
Elements of the TLS Server - The TLS server security feature implements a TLS server as specified in [RFC 2246] and subsequent specifications. - This specification defines how to manage the associations between certification paths and the TLS server. All other TLS server configuration actions are outside the scope of this specification. In particular, enabling and disabling the TLS server on the device shall be performed using the device management service specified in the [ONVIF Core Specification]. + The TLS server security feature implements a TLS server as specified in RFC 2246 and subsequent specifications. + This specification defines how to manage the associations between certification paths and the TLS server. All other TLS server configuration actions are outside the scope of this specification. In particular, enabling and disabling the TLS server on the device shall be performed using the device management service specified in the ONVIF Core Specification.
Authorization of TLS authenticated connections - If TLS client authentication is enabled, connections shall be authenticated as specified in [RFC 2246], and the device shall before all validate the client TLS certificate. In case of invalid certificate the TLS connection shall be terminated and the device shall ignore any other credentials received on HTTP or WS layer. + If TLS client authentication is enabled, connections shall be authenticated as specified in RFC 2246, and the device shall before all validate the client TLS certificate. In case of invalid certificate the TLS connection shall be terminated and the device shall ignore any other credentials received on HTTP or WS layer. Once a service request is authenticated on the TLS layer, the device shall decide based on its access policy whether the requestor is authorized to receive the service. In order to authorize the requestor, additional information for the device is required. If CnMapsToUser is true, the name of the user requiring access to the device shall be presented in the Common Name (CN) attribute of the certificate presented by the client to the device. The device shall validate the provided username against its set of credentials, and grant access to the requested function in case of success. If the user is not allowed to access the function, the device shall return a 403 Forbidden. - If CnMapsToUser is false, from this point forward the authorization procedure follows what is specified in the [ONVIF Core Specification] as part of the security service. - The authentication and authorization process and falling back to the [ONVIF Core Specification] is illustrated in . + If CnMapsToUser is false, from this point forward the authorization procedure follows what is specified in the ONVIF Core Specification as part of the security service. + The authentication and authorization process and falling back to the ONVIF Core Specification is illustrated in .
- Authentication and authorization flow chart and fallback mechanism to the [ONVIF Core Specification]. + Authentication and authorization flow chart and fallback mechanism to the ONVIF Core Specification. - +
@@ -2419,10 +2821,10 @@ Added certificate-based client authentication TLS Server Operations
AddServerCertificateAssignment - This operation assigns a key pair and certificate along with a certification path (certificate chain) to the TLS server on the device. The TLS server shall use this information for key exchange during the TLS handshake, particularly for constructing server certificate messages as specified in [RFC 4346, RFC 2246]. + This operation assigns a key pair and certificate along with a certification path (certificate chain) to the TLS server on the device. The TLS server shall use this information for key exchange during the TLS handshake, particularly for constructing server certificate messages as specified in RFC 4346, RFC 2246. Certification paths are identified by their certification path IDs in the keystore. The first certificate in the certification path shall be the TLS server certificate. Since each certificate has exactly one associated key pair, a reference to the key pair that is associated with the server certificate is not supplied explicitly. Devices shall obtain the private key or results of operations under the private key by suitable internal interaction with the keystore. - If a device chooses to perform a TLS key exchange based on the supplied certification path, it shall use the key pair that is associated with the server certificate for key exchange and transmit the certification path to TLS clients as-is, i.e., the device shall not check conformance of the certification path to [RFC 4346, RFC 2246]. + If a device chooses to perform a TLS key exchange based on the supplied certification path, it shall use the key pair that is associated with the server certificate for key exchange and transmit the certification path to TLS clients as-is, i.e., the device shall not check conformance of the certification path to RFC 4346, RFC 2246. In order to use the server certificate during the TLS handshake, the corresponding private key is required. Therefore, if the key pair that is associated with the server certificate, i.e., the first certificate in the certification path, does not have an associated private key, the NoPrivateKey fault is produced and the certification path is not associated with the TLS server. A TLS server may present different certification paths to different clients during the TLS handshake instead of presenting the same certification path to all clients. Therefore more than one certification path may be assigned to the TLS server. If the maximum number of certification paths that may be assigned to the TLS server simultaneously is reached, the device shall generate a MaximumNumberOfTLSCertificationPathsReached fault and the requested certification path shall not be assigned to the TLS server. If the certification path identified by the supplied certification path ID is already assigned to the TLS server, this command shall have no effect. @@ -2502,7 +2904,7 @@ Added certificate-based client authentication Certification paths are identified using certification path IDs. If the supplied old certification path ID is not associated with the TLS server, or no certification path exists under the new certification path ID, the corresponding InvalidArgVal faults are produced and the associations are unchanged. The first certificate in the new certification path shall be the TLS server certificate. Since each certificate has exactly one associated key pair, a reference to the key pair that is associated with the new server certificate is not supplied explicitly. Devices shall obtain the private key or results of operations under the private key by suitable internal interaction with the keystore. - If a device chooses to perform a TLS key exchange based on the new certification path, it shall use the key pair that is associated with the server certificate for key exchange and transmit the certification path to TLS clients as-is, i.e., the device shall not check conformance of the certification path to [RFC 4346, RFC 2246]. + If a device chooses to perform a TLS key exchange based on the new certification path, it shall use the key pair that is associated with the server certificate for key exchange and transmit the certification path to TLS clients as-is, i.e., the device shall not check conformance of the certification path to RFC 4346, RFC 2246. In order to use the server certificate during the TLS handshake, the corresponding private key is required. Therefore, if the key pair that is associated with the server certificate, i.e., the first certificate in the certification path, does not have an associated private key, the NoPrivateKey fault is produced and the certification path is not associated with the TLS server. @@ -2577,7 +2979,7 @@ Added certificate-based client authentication This operation activates or deactivates TLS client authentication for the TLS server on the device. The TLS server on the device shall require client authentication if and only if clientAuthenticationRequired is set to true. If TLS client authentication is requested to be enabled and no certification path validation policy is assigned to the TLS server, the device shall return an EnablingClientAuthenticationFailed fault and shall not enable TLS client authentication. - The device shall execute this command regardless of the TLS enabled/disabled state configured in the [ONVIF Device Management Service]. + The device shall execute this command regardless of the TLS enabled/disabled state configured in the ONVIF Device Management Service. request @@ -2704,7 +3106,7 @@ Added certificate-based client authentication
AddCertPathValidationPolicyAssignment - This operation assigns a certification path validation policy to the TLS server on the device. The TLS server shall enforce the policy when authenticating TLS clients and consider a client authentic if and only if the algorithm defined in Sect. returns valid. + This operation assigns a certification path validation policy to the TLS server on the device. The TLS server shall enforce the policy when authenticating TLS clients and consider a client authentic if and only if the algorithm defined in Sect. returns valid. If no certification path validation policy is stored under the requested CertPathValidationPolicyID, the device shall produce a CertPathValidationPolicyID fault. A TLS server may use different certification path validation policies to authenticate clients. Therefore more than one certification path validation policy may be assigned to the TLS server. If the maximum number of certification path validation policies that may be assigned to the TLS server simultaneously is reached, the device shall produce a MaximumNumberOfTLSCertPathValidationPoliciesReached fault and shall not assign the requested certification path validation policy to the TLS server. @@ -2943,15 +3345,15 @@ Added certificate-based client authentication faults - foo env:Receiver - ter:Action - ter:MaximumNumberOfDot1XConfigurationsReached + env:Receiver - ter:Action - ter:MaximumNumberOfDot1XConfigurationsReached The device already has the number of configurations specified by MaximumNumberOfDot1XConfigurations. env:Sender - ter:InvalidArgVal - ter:PassphraseID A supplied passphrase ID cannot be processed by the device. env:Sender - ter:InvalidArgVal - ter:CertificationPathID A supplied certification path ID cannot be processed by the device. - env:Sender - ter:InvalidArgVal - ter: Dot1XMethod + env:Sender - ter:InvalidArgVal - ter:Dot1XMethod A supplied IEEE 802.1X authentication method cannot be processed by the device. - env:Sender - ter:InvalidArgVal - ter: Dot1XMethodCombination + env:Sender - ter:InvalidArgVal - ter:Dot1XMethodCombination The combination of IEEE 802.1X authentication methods cannot be processed by the device. @@ -3122,7 +3524,7 @@ Added certificate-based client authentication request token - [xs:string] - The unique identifier of the Network Interface for which the 802.1X configuration is to be retrieved. (NOTE: the network interface token is defined in devicemgmt.wsdl as tt:ReferenceToken, which is a derived type of xs:string. To avoid importing all of common.xsd for this single type, the base type is used here.) + The unique identifier of the Network Interface for which the 802.1X configuration is to be retrieved. (NOTE: the network interface token is defined in devicemgmt.wsdl as tt:ReferenceToken, which is a derived type of xs:string. To avoid importing all of common.xsd for this single type, the base type is used here.) @@ -3185,60 +3587,278 @@ Added certificate-based client authentication
-
- Capabilities -
- GetServiceCapabilities - The capabilities reflect optional functions and functionality of the different features in the security configuration service. The service capabilities consist of keystore capabilities and TLS server capabilities. The information is static and does not change during device operation. - A device shall support this command. +
+ Autorization Server Configuration + This chapter describes configuration of external authorization servers. For an overview of this see . +
+ GetAuthorizationServerConfigurations + This operation retrieves an existing authorization server configuration, or all existing authorization server configurations if Token is not specified. request - This is an empty message. + Token - optional [tt:ReferenceToken] + Optional configuration token to get. response - Capabilities - [tas:Capabilities] - The capabilities for the security configuration service. + Configuration - optional, unbounded [tas:AuthorizationServerConfiguration] + List of authorization server configurations. faults - None + env:Sender - ter:InvalidArgVal - ter:NoConfig + The requested configuration does not exist. access class - PRE_AUTH + READ_SYSTEM_SECRET
-
- Keystore Capabilities - The keystore capabilities reflect optional functions and functionality of the keystore on a device. The following capabilites are available: - - Keystore Capabilities - - - - - - - - Capability Name - - - - - Capability Semantics - - +
+ CreateAuthorizationServerConfiguration + This operation creates a new authorization server configuration. The configuration data shall be created in the device and shall be persistent (remain after reboot). + + + request + + Configuration - [tas:AuthorizationServerConfigurationData] + Details of the configuration that shall be created. + + + + response + + Token - [tt:ReferenceToken] + Token assigned to the newly configuration. + + + + faults + + env:Receiver - ter:Action - ter:MaxAuthorizationServers + The maximum number of configurations supported by the device has been reached. + env:Sender - ter:InvalidArgVal - ter:InvalidConfig + The configuration parameters are not possible to set. + + + + access class + + WRITE_SYSTEM + + + +
+
+ SetAuthorizationServerConfiguration + This operation modifies an existing authorization server configuration. + + + request + + Configuration - [tas:AuthorizationServerConfiguration] + The modified authorization server configuration. + + + + response + + This is an empty message + + + + faults + + env:Sender - ter:InvalidArgVal - ter:NoConfig + The requested configuration does not exist. + env:Sender - ter:InvalidArgVal - ter:InvalidConfig + The configuration parameters are not possible to set. + + + + access class + + WRITE_SYSTEM + + + +
+
+ DeleteAuthorizationServerConfiguration + This operation deletes the given authorization server configuration and configuration + change shall always be persistent. + + + request + + Token - [tt:ReferenceToken] + Token of the configuration to delete. + + + + response + + This is an empty message + + + + faults + + env:Sender - ter:InvalidArgVal - ter:NoConfig + The requested configuration does not exist. + + + + access class + + WRITE_SYSTEM + + + +
+ +
+ JWT-based authentication + The following functions are defined to control the set of accepted aud claims. See also . +
+ GetJWTConfiguration + This operation returns the parameters of the JWT authorization used by the device. A + device shall support this command if the capability JsonWebToken in the device service capabilities is set. + + + request + + This is an empty message. + + + + response + + Configuration - [tas:JWTConfiguration] + The configuration parameters for JWT authorization used by the + device. + + + + faults + + None + + + + access class + + READ_SYSTEM_SECRET + + + +
+
+ SetJWTConfiguration + This operation sets the parameters of the JWT authorization used by the device. A + device shall support this command if the capability JsonWebToken in the device service capabilities is set. + JWT client authorization of the device is enabled when at least one key or trusted issuer URI is provided. + + + request + + Configuration - [tas:JWTConfiguration] + The configuration parameters for JWT authorization used by the + device. + + + + response + + This is an empty message. + + + + faults + + env:Sender - ter:InvalidArgVal - ter:TooManyAudiences + The list of audiences is too big to be saved. + ter:Sender - ter:InvalidArgVal - ter:KeyID + No key is stored under the requested KeyID. + ter:Sender - ter:InvalidArgVal - ter:MaxIssuersExceeded + Too many trusted issuers provided. + env:Sender - ter:InvalidArgVal - ter:CertPathValidationPolicyID + No certification path validation policy is stored under the requested certification path validation policy ID. + + + + access class + + WRITE_SYSTEM_SECRET + + + + A device shall support assignment of as many keys as its key store can hold. A device shall support at least two trusted issuers. +
+
+
+ Capabilities +
+ GetServiceCapabilities + The capabilities reflect optional functions and functionality of the different features in the security configuration service. The service capabilities consist of keystore capabilities and TLS server capabilities. The information is static and does not change during device operation. + A device shall support this command. + + + request + + This is an empty message. + + + + response + + Capabilities - [tas:Capabilities] + The capabilities for the security configuration service. + + + + faults + + None + + + + access class + + PRE_AUTH + + + +
+
+ Keystore Capabilities + The keystore capabilities reflect optional functions and functionality of the keystore on a device. The following capabilities are available: +
+ Keystore Capabilities + + + + + + + + Capability Name + + + + + Capability Semantics + + @@ -3282,6 +3902,14 @@ Added certificate-based client authenticationIndicates support for on-board RSA key pair generation. + + + ECCKeyPairGeneration + + + Indicates support for on-board ECC key pair generation. + + RSAKeyLengths @@ -3290,6 +3918,14 @@ Added certificate-based client authentication Indicates which RSA key lengths are supported by the device. + + + EllipticCurves + + + Indicates which elliptic curves are supported by the device. + + PKCS8RSAKeyPairUpload @@ -3298,6 +3934,14 @@ Added certificate-based client authentication Indicates support for uploading an RSA key pair in a PKCS#8 data structure. + + + PKCS8 + + + Indicates support for uploading supported key pair in a PKCS#8 data structure. + + PKCS12CertificateWithRSAPrivateKeyUpload @@ -3306,6 +3950,14 @@ Added certificate-based client authentication Indicates support for uploading a certificate along with an RSA private key in a PKCS#12 data structure. + + + PKCS12 + + + Indicates support for uploading a certificate along with a private key in a PKCS#12 data structure. + + PKCS10ExternalCertificationWithRSA @@ -3314,6 +3966,14 @@ Added certificate-based client authentication Indicates support for creating PKCS#10 requests for RSA keys and uploading the certificate obtained from a CA. + + + PKCS10 + + + Indicates support for creating PKCS#10 requests for asymetric key pair and uploading the certificate obtained from a CA. + + SelfSignedCertificateCreationWithRSA @@ -3322,6 +3982,14 @@ Added certificate-based client authentication Indicates support for creating self-signed certificates for RSA keys. + + + SelfSignedCertificateCreation + + + Indicates support for creating self-signed certificates. + + SignatureAlgorithms @@ -3392,12 +4060,12 @@ Added certificate-based client authentication
TLS Server Capabilities - The TLS server capabilities reflect optional functions and functionality of the TLS server. The information is static and does not change during device operation. The following capabilites are available: + The TLS server capabilities reflect optional functions and functionality of the TLS server. The information is static and does not change during device operation. The following capabilities are available:
TLS Server Capabilities - - + + @@ -3457,8 +4125,8 @@ Added certificate-based client authentication
Additional IEEE 802.1X Configuration Capabilities - - + + @@ -3490,15 +4158,63 @@ Added certificate-based client authentication
+
+ Authorization Server Capabilities + The authorization server capabilities reflect optional functionality regarding + configuration of external authorization servers. The following capabilities are + defined: + + Authorization Server Configuration Capabilities + + + + + + + Capability Name + + + Capability Semantics + + + + + + + MaxAuthorizationServerConfigurations + + + Indicates the maximum number of authorization server configurations that + the device is able to configure simultaneously. + + + + + AuthorizationServerConfigurationTypesSupported + + + A list of authorization server configuration types that is supported by the + device, see for possible values. + + + + ClientAuthenticationMethodsSupported + A list of authentication methods that is supported by the device, see for possible values. + + + + +
+
Capability-implied Requirements - summarizes for each capability the minimum requirements that a device signaling this capability shall satisfy; it should not be seen as a recommendation. + summarizes for each capability the minimum requirements that a device signaling this capability shall satisfy; it should not be seen as a recommendation. Requirements implied by Capabilities - - + + @@ -3582,7 +4298,22 @@ Added certificate-based client authentication - PKCS8RSAKeyPairUpload + ECCKeyPairGeneration + + + If true, the following commands shall be supported: + + + CreateECCKeyPair + + + If true, the list of supported elliptic curves indicated by the EllipticCurves capability shall not be empty. + If true, MaximumNumberOfKeys>0 shall hold. + + + + + PKCS8 If true, the following commands shall be supported: @@ -3592,13 +4323,24 @@ Added certificate-based client authentication If true, MaximumNumberOfKeys > 0 shall hold. + If true, the list of supported password-based encryption algorithms as + indicated by the PasswordBasedEncryptionAlgorithms capability shall contain at + least the algorithm pbeWithSHAAnd3-KeyTripleDES-CBC. + If true, at least one capability between EllipticCurves and RSAKeyLenghts shall be specified. + + + + + PKCS8RSAKeyPairUpload + + + If true, the conditions of PKCS8 shall be supported: If true, the list of supported RSA key lengths as indicated by the RSAKeyLenghts capability shall not be empty. - If true, the list of supported password-based encryption algorithms as indicated by the PasswordBasedEncryptionAlgorithms capability shall contain at least the algorithm pbeWithSHAAnd3-KeyTripleDES-CBC. - PKCS12CertificateWithRSAPrivateKeyUpload + PKCS12 If true, the following commands shall be supported: @@ -3628,23 +4370,27 @@ Added certificate-based client authentication If true, MaximumNumberOfKeys >=2 shall hold. If true, MaximumNumberOfCertificates >=2 shall hold. If true, MaximumNumberOfCertificattionPaths >0 shall hold. - If true, the list of supported RSA key lengths as indicated by the RSAKeyLenghts capability shall not be empty. If true, the list of supported password-based encryption algorithms as indicated by the PasswordBasedEncryptionAlgorithms capability shall contain at least the algorithm pbeWithSHAAnd3-KeyTripleDES-CBC. If true, the list of supported password-based MAC algorithms as indicated by the PasswordBasedMACAlgorithms capability shall contain at least the algorithm hmacWithSHA256. If true, the list of supported X.509 versions as indicated by the X.509Versions capability shall contain at least the value 3. - If true, the list of supported signature algorithms as indicated by the SignatureAlgorithms capability shall contain at least the algorithms sha1-WithRSAEncryption and sha256WithRSAEncryption. - PKCS10ExternalCertificationWithRSA + PKCS12CertificateWithRSAPrivateKeyUpload + + + If true, the conditions of capability PKCS12 shall be fulfilled. + If true, the list of supported RSA key lengths as indicated by the RSAKeyLenghts capability shall not be empty. + + + + + PKCS10 If true, the following operations shall be supported: - - RSA key pair generation as signaled by the RSAKeyPairGeneration capability or RSA key pair upload as signaled by the PKCS8RSAKeyPairUpload capability or RSA key pair upload as signaled by the PKCS12CertificateWithRSAPrivateKeyUpload capability - Creating a CSR with the CreatePKCS10CSR command. @@ -3663,12 +4409,34 @@ Added certificate-based client authentication If true, MaximumNumberOfCertificates>=2 and MaximumNumberOfCertificationPaths>0 shall hold. If true, MaximumNumberOfKeys>=2 shall hold. - If true, the list of supported signature algorithms as indicated by the SignatureAlgorithms capability shall contain at least the algorithms sha1-WithRSAEncryption and sha256WithRSAEncryption. + If true and the capability RSAKeyLenghts is not empty the following condition shall be fulfilled: + + + The capability RSAKeyPairGeneration shall be specified . + + + If true and the capability EllipticCurves is provided, the following conditions shall be fulfilled: + + + The capability ECCKeyPairGeneration shall be specified. + + + The list of supported signature algorithms as indicated by the SignatureAlgorithms capability shall contain at least the algorithms ECDSA-With-SHA1 and ECDSA-With-SHA256. + + + + PKCS10ExternalCertificationWithRSA - SelfSignedCertificateCreationWithRSA + If true, the conditions of capability PKCS10 shall be fulfilled. + If true, the list of supported RSA key lengths as indicated by the RSAKeyLenghts capability shall not be empty. + + + + + SelfSignedCertificateCreation If true, the following commands shall be supported: @@ -3686,14 +4454,37 @@ Added certificate-based client authentication DeleteCertificate + If true, MaximumNumberOfCertificates> 0 shall hold. If true, the following operations shall be supported: - RSA key pair generation as signaled by the RSAKeyPairGeneration capability or RSA key pair upload as signaled by the PKCS8RSAKeyPairUpload capability or RSA key pair upload as signaled by the PKCS12CertificateWithRSAPrivateKeyUpload capability + Key pair generation as signaled by the RSAKeyPairGeneration or ECCKeyPairGeneration capability or key pair upload as signaled by the PKCS8 capability or key pair upload as signaled by the PKCS12CertificateWithRSAPrivateKeyUpload capability + + + If true and the capability RSAKeyLenghts is not empty the following conditions shall be fulfilled: + + + The capability RSAKeyPairGeneration shall be specified . + + + The list of supported signature algorithms as indicated by the SignatureAlgorithms capability shall contain at least the algorithms sha1-WithRSAEncryption and sha256WithRSAEncryption. + + + If true and the capability EllipticCurves is provided, the following condition shall be fulfilled: + + + The capability ECCKeyPairGeneration shall be specified. - If true, MaximumNumberOfCertificates> 0 shall hold. - If true, the list of supported signature algorithms as indicated by the SignatureAlgorithms capability shall contain at least the algorithms sha1-WithRSAEncryption and sha256WithRSAEncryption. + + + + + SelfSignedCertificateCreationWithRSA + + + If true, the conditions of the SelfSignedCertificateCreation capability shall be supported. + If true, the list of supported RSA key lengths as indicated by the RSAKeyLenghts capability shall not be empty. @@ -3701,7 +4492,7 @@ Added certificate-based client authentication TLSServerSupported - If not empty, PKCS10ExternalCertificationWithRSA shall be true or SelfSignedCertificateCreationWithRSA shall be true. + If not empty, PKCS10ExternalCertificationWithRSA or SelfSignedCertificateCreationWithRSA or PKCS10 or SelfSignedCertificateCreation shall be true. If not empty, the following commands shall be supported: @@ -3740,6 +4531,14 @@ Added certificate-based client authentication If TLSServerSupported is non-empty and PKCS10ExternalCertificationWithRSA is true, MaximumNumberOfCertificates>=3 shall hold. + + + TLSServerSupported and PKCS10 + + + If TLSServerSupported is non-empty and PKCS10 is true, MaximumNumberOfCertificates>=3 shall hold. + + MaximumNumberOfTLSCertificationPaths @@ -3816,7 +4615,7 @@ Added certificate-based client authentication DeleteCertPathValidationPolicy - If greater than zero, PKCS12CertificateWithRSAPrivateKeyUpload, PKCS10ExternalCertificationWithRSA or SelfSignedCertificateCreationWithRSA shall be true. + If greater than zero, PKCS12CertificateWithRSAPrivateKeyUpload, PKCS10ExternalCertificationWithRSA or SelfSignedCertificateCreationWithRSA or PKCS12 or PKCS10 or SelfSignedCertificateCreation shall be true. @@ -3850,16 +4649,16 @@ Added certificate-based client authentication If true, the device shall support - validating certification paths containing X.509v3 certificates that are signed with signatures of type sha1-WithRSAEncryption or with sha256WithRSAEncrpytion + validating certification paths containing X.509v3 certificates that are signed with signatures of type sha1-WithRSAEncryption or sha256WithRSAEncrpytion - processing X.509 CRLs that are compliant to the CRL profile defined in [RFC 5280], Sect. 5 and that + processing X.509 CRLs that are compliant to the CRL profile defined in RFC 5280, Sect. 5 and that - are signed with signatures of type sha1-WithRSAEncryption or sha256WithRSAEncryption and + are signed with signatures of type sha1-WithRSAEncryption or, sha256WithRSAEncryption and - are complete direct CRLs as defined in [RFC 5280] that that are signed with the same signature key as the signature key that the CA uses to sign issued certificates + are complete direct CRLs as defined in RFC 5280 that are signed with the same signature key as the signature key that the CA uses to sign issued certificates @@ -3914,6 +4713,10 @@ Added certificate-based client authentication If not empty, shall contain at least the “EAP-PEAP/MSCHAPv2” method, and MaximumNumberOfDot1XConfigurations shall be greater than zero. + + EllipticCurves + The list of supported elliptic curves. +
@@ -3924,14 +4727,14 @@ Added certificate-based client authentication
Key Status A device that indicates support for key handling via the MaximumNumberOfKeys capability shall provide information about key status changes through key status events. - A device shall include an OldStatus value unless NewStatus is generating. + A device shall include optional item OldStatus unless NewStatus is generating. - + @@ -3951,7 +4754,7 @@ Added certificate-based client authentication Faults and their types shall not disclose sensitive information to an attacker that he could not obtain otherwise. - For interoperability reasons, sha1WithRSAEncryption as specified in [RFC3279] is mandated as default signature algorithm. However, since the security of the SHA-1 algorithm is under question, this specification mandates that a signature algorithm based on SHA-256, particularly sha256WithRSAEncryption as specified in [RFC 4055], be supported in addition. + For interoperability reasons, sha1WithRSAEncryption as specified in RFC 3279 is mandated as default signature algorithm. However, since the security of the SHA-1 algorithm is under question, this specification mandates that a signature algorithm based on SHA-256, particularly sha256WithRSAEncryption as specified in RFC 4055, be supported in addition. Operations with arguments that need protection against eavesdropping or manipulation shall only be executed over sufficiently protected communication channels. @@ -3966,22 +4769,22 @@ Added certificate-based client authentication In general, externally generated keys must be regarded less trustworthy than keys that are generated by the device because the probability of being disclosed to an attacker is higher for an externally generated key than for an internally generated key. A client may determine whether a key was generated by the device from the externallyGenerated attribute of the key. - While new specifications should be based on [PKCS#5 v2.0] or higher, adoption of this standard is still limited. Therefore, this specification intends to balance security and interoperability by mandating cryptographic algorithms based on [PKCS#5 v1.5] as interoperability baseline while strongly encouraging the use of [PKCS#5 v2.0] or higher. Future versions of this specification or specifications referring to this specification may mandate additional cryptographic algorithms. + While new specifications should be based on PKCS#5 v2.0 or higher, adoption of this standard is still limited. Therefore, this specification intends to balance security and interoperability by mandating cryptographic algorithms based on PKCS#5 v1.5 as interoperability baseline while strongly encouraging the use of PKCS#5 v2.0 or higher. Future versions of this specification or specifications referring to this specification may mandate additional cryptographic algorithms. - Although PKCS#8 [RFC 5208] is widely used for exchanging cryptographic keys, this specification is based on the successor standard [RFC 5958], particularly in order to incorporate both private key and public key in the same data structure. + Although PKCS#8 RFC 5208 is widely used for exchanging cryptographic keys, this specification is based on the successor standard RFC 5958, particularly in order to incorporate both private key and public key in the same data structure. - The default certification path validation policy is designed as a permissive interoperability baseline based on the certification path validation algorithm defined in [RFC 5280]. + The default certification path validation policy is designed as a permissive interoperability baseline based on the certification path validation algorithm defined in RFC 5280. - CRLs can be expected to be available from virtually any CA as a source of revocation information. The benefit of OCSP [RFC 6960] as a means to obtain revocation information is increasingly under question, since a man-in-the-middle attacker blocking OCSP traffic combined with a permissive validator that silently accepts certificates for which no revocation is available limits the effective security gain of using OCSP. Therefore, this specification mandates support for CRLs as interoperability baseline and leaves other revocation information sources to future versions. + CRLs can be expected to be available from virtually any CA as a source of revocation information. The benefit of OCSP RFC 6960 as a means to obtain revocation information is increasingly under question, since a man-in-the-middle attacker blocking OCSP traffic combined with a permissive validator that silently accepts certificates for which no revocation is available limits the effective security gain of using OCSP. Therefore, this specification mandates support for CRLs as interoperability baseline and leaves other revocation information sources to future versions. Devices may be required to use different trust anchors for different security features. Therefore, trust in a certificate is indicated as part of a certification path validation policy rather than globally, e.g., with an attribute of the X509Certificate data type. - [RFC 5280], Sect. 6.1.4 (k) mandates that every certificate in a certification path except for the end entity certificate must be verified to be a CA certificate. For X.509 version 3 certificates, this is verified through the CA attribute in the basic constraints extension. For X.509 version 1 and 2 certificates, this information must be supplied by out-of-band mechanisms. Within the scope of this specification, the only means to obtain this information is the trust anchor information contained in the certification path validation algorithm. Therefore, the default certification path validation policy mandates that the certification path validation algorithm defined in Sect. consider all certificates that are not marked as trust anchor as non-CA certificates. + RFC 5280, Sect. 6.1.4 (k) mandates that every certificate in a certification path except for the end entity certificate must be verified to be a CA certificate. For X.509 version 3 certificates, this is verified through the CA attribute in the basic constraints extension. For X.509 version 1 and 2 certificates, this information must be supplied by out-of-band mechanisms. Within the scope of this specification, the only means to obtain this information is the trust anchor information contained in the certification path validation algorithm. Therefore, the default certification path validation policy mandates that the certification path validation algorithm defined in Sect. consider all certificates that are not marked as trust anchor as non-CA certificates. When configuring IEEE 802.1X, it is usually necessary to upload a password to the device’s keystore. This should be done either on a private network (e.g., using a direct network connection between a laptop and a device) or using TLS (SSL) on the device to encrypt client / device traffic. @@ -4001,10 +4804,10 @@ Added certificate-based client authentication Keystore The keystore design assumes that passphrases are chosen by clients. Therefore, an operation for retrieving passphrases from a device is deliberately omitted. If client loses a previously uploaded passphrase, the client should create a new passphrase, upload the new passphrase to the device, and delete the old passphrase from the device. This specification deliberately deviates from the terminology in PKCS#8 and PKCS#12 by using the term ‘passphrase’ instead of ‘password’ in order to avoid confusion with the password that is assigned to ONVIF device users and the corresponding API in the ONVIF Device Management Service. - The keystore design is based on the rationale that an RSA key pair is a special type of key pair and a key pair is a special type of key. Therefore, key-related operations in the keystore deliberately refer to the most generic possible type in this hierarchy. For example, the DeleteKey operation (see Sect. ) refers to a key instead of a key pair or even an RSAKeyPair because it is applicable to all keys. On the other hand, the GetPrivateKeyStatus command refers to a key pair instead of a key, since this command is not meaningful for a key that is not a key pair, e.g., a symmetric key. + The keystore design is based on the rationale that an RSA key pair is a special type of key pair and a key pair is a special type of key. Therefore, key-related operations in the keystore deliberately refer to the most generic possible type in this hierarchy. For example, the DeleteKey operation (see Sect. ) refers to a key instead of a key pair or even an RSAKeyPair because it is applicable to all keys. On the other hand, the GetPrivateKeyStatus command refers to a key pair instead of a key, since this command is not meaningful for a key that is not a key pair, e.g., a symmetric key. While this revision of the keystore specification only supports RSA key pairs as key pairs, later revisions of this specification may add other types of key pairs or symmetric keys as special types of keys. Some interactions with the keystore, e.g., retrieving the private key for a public key that is contained in a certificate, are required device-internally, but need not be accessible to clients and may even, as in the above example, imply a security risk when made available outside the device. Such operations are therefore deliberately omitted from this specification. - The certificate-based client authentication specification intends to balance security concerns, interoperability, and implementation effort in order to facilitate adoption. Therefore, the certification path validation algorithm defined in [RFC 5280] serves as interoperability baseline. The parameter values in the default certification path validation policy have been selected such that widely used implementations of the certification path validation algorithm can be used in their default configurations as much as permitted by the objective to provide an acceptable security baseline. + The certificate-based client authentication specification intends to balance security concerns, interoperability, and implementation effort in order to facilitate adoption. Therefore, the certification path validation algorithm defined in RFC 5280 serves as interoperability baseline. The parameter values in the default certification path validation policy have been selected such that widely used implementations of the certification path validation algorithm can be used in their default configurations as much as permitted by the objective to provide an acceptable security baseline. At the same time, more fine grained customization of the default certification path validation behavior in future versions of this specification is enabled by an extensible CertValidationPolicyParameters data type and capabilities that indicate which configuration options a device supports. As an example, checking for the TLS WWW client authentication key usage extension in client certificates is included in this specification, which can be implemented with moderate effort on the device side (e.g., with the OpenSSL option –purpose sslclient). Customization options for other parameters of the certification path validation algorithm are deliberately left to future versions of this specification in order to limit the required initial implementation effort. In order to facilitate future extensions of this specification, the number of certification path validation policies that may be assigned to the TLS server simultaneously is not limited, but the certification path validation behavior is unspecified if more than one policy is assigned to the TLS server at the same time. Therefore, devices implementing this specification should limit the number of simultaneously assigned policies to one.
@@ -4014,8 +4817,132 @@ Added certificate-based client authentication All other configuration of the TLS server on a device is outside the scope of this specification revision and may be addressed by later revisions of this document.
+ + JWT over SCTP example + The JWT will have the following content + + which is base64-encoded as + eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJzZXJ2ZXIucGF0aC5jb20iLCJuYmYiOjE2NzA0ODI4MDAsImV +4cCI6MTY3MDU3MjgwMCwiYXVkIjoidGFyZ2V0LmF1ZGllbmNlIiwicm9sZXMiOlsib252aWY6T3BlcmF0b3IiXX0=.SflKxw +RJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c + While the individual components of the JWT are already base64-encoded, the whole structure is not technically base64-encoded. Therefore it is necessary to base64-encode it again, leading to + ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKRlV6STFOaUo5LmV5SnBjM01pT2lKelpYSjJaWEl1Y0dGMGFDNW +piMjBpTENKdVltWWlPakUyTnpBME9ESTRNREFzSW1WNGNDSTZNVFkzTURVM01qZ3dNQ3dpWVhWa0lqb2lkR0Z5 +WjJWMExtRjFaR2xsYm1ObElpd2ljbTlzWlhNaU9pSnZiblpwWmpwUGNHVnlZWFJ2Y2lKOS5TZmxLeHdSSlNNZU +tLRjJRVDRmd3BNZUpmMzZQT2s2eUpWX2FkUXNzdzVj + At this point, the JWT can be used in the WS-Security header of the SOAP request: + + + + + +ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKRlV6STFOaUo5LmV5SnBjM01pT2lKelpYSjJaWEl1Y0dGMGFDNW +piMjBpTENKdVltWWlPakUyTnpBME9ESTRNREFzSW1WNGNDSTZNVFkzTURVM01qZ3dNQ3dpWVhWa0lqb2lkR0Z5 +WjJWMExtRjFaR2xsYm1ObElpd2ljbTlzWlhNaU9sc2liMjUyYVdZNlQzQmxjbUYwYjNJaVhYMD0uU2ZsS3h3Uk +pTTWVLS0YyUVQ0ZndwTWVKZjM2UE9rNnlKVl9hZFFzc3c1Yw== + + + + + + +]]> + + + JWT over HTTPS example + The following exchange between client and device over HTTPS demonstrates a device supporting MD5 and SHA-256 for digest authentication as well as JWT-based client authentication. + Unauthenticated request from the client: + + + + +]]> + Response from the device challenging for authentication + + Authenticated request from the client, by using JWT-based client authentication + + + + +]]> + Response from the device, rejecting the expired token + + + + JWT over RTSPS + The following exchange between client and device over RTSPS demonstrates a device supporting MD5 and SHA-256 for digest authentication as well as JWT-based client authentication. + Unauthenticated request from the client: + + Response from the device challenging for authentication + + Authenticated request from the client, by using JWT-based client authentication + + Revision History - + diff --git a/doc/Uplink.xml b/doc/Uplink.xml index 0ef0ca98c..2467b245d 100644 --- a/doc/Uplink.xml +++ b/doc/Uplink.xml @@ -4,12 +4,12 @@ Uplink Specification Uplink - 23.06 + 23.12 ONVIF™ www.onvif.org - June, 2023 + December, 2023 @@ -49,6 +49,14 @@ Clarify authentication within the established tunnel. + + 23.12 + Dec 2023 + + Hans Busch + + Add error codes. + @@ -308,6 +316,17 @@ This message is empty + + faults + + ter:Sender - ter:InvalidArgVal - ter:CertificateID + No certificate is stored under the requested CertificateID. + ter:Sender - ter:InvalidArgVal - + ter:CertPathValidationPolicyID + No certification path validation policy is stored under the requested + ID. + + access class @@ -333,6 +352,13 @@ This message is empty + + faults + + ter:Sender - ter:InvalidArgVal - ter:Address + No uplink exists for the given address. + + access class diff --git a/doc/docbook.xsl b/doc/docbook.xsl index 12bc82887..a0db81d64 100644 --- a/doc/docbook.xsl +++ b/doc/docbook.xsl @@ -86,6 +86,9 @@ padding: 1mm 3mm 1mm 3mm; .table>table>thead>tr>th { background-color: #d0d0d0; font-weight: bold; +} +literal { +font-family: monospace; } diff --git a/doc/media/Core/image7.drawio b/doc/media/Core/image7.drawio new file mode 100644 index 000000000..026c96afd --- /dev/null +++ b/doc/media/Core/image7.drawio @@ -0,0 +1,61 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/media/Core/image7.png b/doc/media/Core/image7.png new file mode 100644 index 000000000..98d4a200c Binary files /dev/null and b/doc/media/Core/image7.png differ diff --git a/doc/media/Security/image2.dia b/doc/media/Security/image2.dia new file mode 100644 index 000000000..ccdfde0be Binary files /dev/null and b/doc/media/Security/image2.dia differ diff --git a/doc/media/Security/image2.png b/doc/media/Security/image2.png index 4e1a4595b..b1dffeec2 100644 Binary files a/doc/media/Security/image2.png and b/doc/media/Security/image2.png differ diff --git a/doc/media/Security/image2.svg b/doc/media/Security/image2.svg new file mode 100644 index 000000000..41df9a383 --- /dev/null +++ b/doc/media/Security/image2.svg @@ -0,0 +1,233 @@ + + + + + + + Certificate + + + +CertificateID + + + + + CertificationPath + + + +CertificationPathID + + + + + TLSServer + + + +ClientAuthenticationRequired + + + + + CertPathValidationPolicy + + + +CertPathValidationPolicyID + + + + + + + + 1..n + 0..1 + + + + + + 1..n + 0..n + + + + + + 0..n + 0..1 + + + + + + 1..n + 0..n + + + + + + + + PublicKey + + + + + KeyPair + + + + + PrivateKey + + + + + Key + + + +KeyID + +externallyGenerated + +securelyStored + + + + + + + + + + Passphrase + + + +PassphraseID + + + + + + 0..n + implies + 0..1 + + + + + RSAPublicKey + + + + + RSAKeyPair + + + + + RSAPrivateKey + + + + + ECCPublicKey + + + + + ECCKeyPair + + + + + ECCPrivateKey + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 1 + 1 + + + + + 0..1 + 1 + + + + + 1 + 1 + + + + + 1 + 1 + + + + + 1 + 1 + + + + + 1 + 1 + + + + + + subject public key + + 0..n + + + + + CRL + + + +crlID + + + + + 0..n + 0..n + + diff --git a/doc/media/Security/image6.dia b/doc/media/Security/image6.dia new file mode 100644 index 000000000..2219f4581 Binary files /dev/null and b/doc/media/Security/image6.dia differ diff --git a/doc/media/Security/image6.svg b/doc/media/Security/image6.svg new file mode 100644 index 000000000..628cccca6 --- /dev/null +++ b/doc/media/Security/image6.svg @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + + + + Client + + + + + + + + + Authentication & + Authorization Request + + + + + + 1 + + + + + + + + + + + + 2 + + + + + + + + + U + s + e + r + + + + Authentication + Authorization + + + + + + + + + + + 3 + + + + + + + + + + + + 4 + + + + Token Request + + + + + + + + + + + 5 + + + + Token + Endpoint + + + Authorization + endpoint + + + + + + Authorization + Code + + + + + + + ID Token + + + + + + + Access Token + + + + + + + Server + + + + response_type=code (scope includes openid) + + diff --git a/doc/media/Security/image7.dia b/doc/media/Security/image7.dia new file mode 100644 index 000000000..6afedb65b Binary files /dev/null and b/doc/media/Security/image7.dia differ diff --git a/doc/media/Security/image7.svg b/doc/media/Security/image7.svg new file mode 100644 index 000000000..97274d94e --- /dev/null +++ b/doc/media/Security/image7.svg @@ -0,0 +1,71 @@ + + + + + + + + + + + + + + + + + + + Client + + + + + + + + + Authentication & + Authorization Request + + + + + + 1 + + + + + + + + + + + + 2 + + + + Authorization + endpoint + + + + + + Access Token + + + + + + + Server + + + + response_type=token + + diff --git a/wsdl/ver10/advancedsecurity/wsdl/advancedsecurity.wsdl b/wsdl/ver10/advancedsecurity/wsdl/advancedsecurity.wsdl index 171869f7f..511832b0c 100644 --- a/wsdl/ver10/advancedsecurity/wsdl/advancedsecurity.wsdl +++ b/wsdl/ver10/advancedsecurity/wsdl/advancedsecurity.wsdl @@ -1,7 +1,7 @@ - + + @@ -656,6 +657,12 @@ + + + A list of elliptic curves. + + + A list of X.509 versions. @@ -719,21 +726,41 @@ Indication that the device supports on-board RSA key pair generation. + + + Indication that the device supports on-board ECC key pair generation. + + Indicates which RSA key lengths are supported by the device. + + + Indicates which elliptic curves are supported by the device. + + Indicates support for creating PKCS#10 requests for RSA keys and uploading the certificate obtained from a CA.. + + + Indicates support for creating PKCS#10 requests for keypairs and uploading the certificate obtained from a CA. + + Indicates support for creating self-signed certificates for RSA keys. + + + Indicates support for creating self-signed certificates. + + Indicates which X.509 versions are supported by the device. @@ -749,11 +776,21 @@ Indicates support for uploading an RSA key pair in a PKCS#8 data structure. + + + Indicates support for uploading a key pair in a PKCS#8 data structure. + + Indicates support for uploading a certificate along with an RSA private key in a PKCS#12 data structure. + + + Indicates support for uploading a certificate along with a private key in a PKCS#12 data structure. + + Indicates which password-based encryption algorithms are supported by the device. @@ -836,6 +873,133 @@ + + + + + + + OAuth2 authorization code flow per RFC 6749 + + + + + OAuth2 client credentials grant flow per RFC 6749 + + + + + + + + + + Use HTTP Authorization header to specify client_secret per RFC 6749 + + + + + Use HTTP POST body to specify client_secret per RFC 6749 + + + + + Use a HMAC signed JWT using client_secret as shared secret per OpenID Connect Core + + + + + Use PKI signed JWT using private key per OpenID Connect Core + + + + + Use PKI certificate to authenticate per RFC 8705 + + + + + Use self-signed certificate to authenticate per RFC 8705 + + + + + + + + + + Authorization server address + + + + + Client identifier issued by the authorization server + + + + + Client secret used to authenticate with the authorization server + + + + + The requested access scope(s) + + + + + Key identifier for the private_key_jwt authentication method + + + + + Certificate identifier for the self_signed_tls_client_auth authentication method + + + + + + + The type of configuration, tas:AuthorizationServerConfigurationType lists the acceptable values + + + + + How to authenticate with the server, tas:ClientAuthenticationMethod lists the acceptable values + + + + + + + + + + + + + + + + + + + + + Indicates maximum number of authorization server configurations supported. + + + + + Enumerates the supported authorization server configuration types, see tas:AuthorizationServerConfigurationType. + + + + + Enumerates the supported client authentication methods, see tas:ClientAuthenticationMethod. + + @@ -859,6 +1023,11 @@ The capabilities of the 802.1X implementation. + + + The capabilities for external authorization server capabilities. + + @@ -883,6 +1052,60 @@ + + + + + + The list of all the aud claims, which the recipient identifies with. + + + + + If present, this is the list to URIs pointing to the metadata file conforming to RFC8414, such as "https://your.domain/.well-known/openid-configuration" , of the trusted Open ID Connect servers issuing JWT tokens. Using metadata, the device can reach the information about the JWKS and implement the rotation of the keys accordingly. + + + + + If present, this is the list of keys provided out of band to verify the origin and integrity of the JWT. + + + + + If present, the device will validate the certification path of the Open ID Connect servers. The OIDC server iso considered to be valid if its certificate is validated by one of the provided certification path validation policies. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -917,6 +1140,39 @@ + + + + + + The name of the elliptic curve to be used for generating the ECC keypair. + + + + + The client-defined alias of the key. + + + + + + + + + + + The key ID of the key pair being generated. + + + + + Best-effort estimate of how long the key generation will take. + + + + + + @@ -1893,7 +2149,7 @@ - + @@ -2049,6 +2305,64 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -2057,12 +2371,30 @@ + + + + + + + + + + + + + + + + + + @@ -2351,6 +2683,30 @@ + + + + + + + + + + + + + + + + + + + + + + + + Common functionality for all security configuraiton service parts. @@ -2359,6 +2715,23 @@ + + Json Web Token functionality. + + + This operation returns the parameters of the JWT authorization used by the device. + + + + + + + This operation sets the parameters of the JWT authorization used by the device. + + + + + Basic keystore functionality. @@ -2377,6 +2750,22 @@ + + + This operation triggers the asynchronous generation of an ECC key pair using a particular elliptic curve as specified in [RFC 4492], with a suitable key generation mechanism on the device. + Keys, especially ECC key pairs, are uniquely identified using key IDs.
+ If the device does not have not enough storage capacity for storing the key pair to be created, the maximum number of keys reached fault shall be produced and no key pair shall be generated. + Otherwise, the operation generates a keyID for the new key and associates the generating status to it.
+ Immediately after key generation has started, the device shall return the keyID to the client and continue to generate the key pair. + The client may query the device with the GetKeyStatus operation whether the generation has finished. + The client may also subscribe to Key Status events to be notified about key status changes.
+ The device also returns a best-effort estimate of how much time it requires to create the key pair. + A client may use this information as an indication how long to wait before querying the device whether key generation is completed.
+ After the key has been successfully created, the device shall assign it the ok status. If the key generation fails, the device shall assign the key the corrupt status. + + + + This operation uploads a key pair in a PKCS#8 data structure as specified in [RFC 5958, RFC 5959].
@@ -2907,6 +3296,38 @@ + + Configuration of external authorization servers. + + + This operation lists all existing authorization server configurations for the device. + + + + + + + This operation creates a new authorization server configuration. + The configuration data shall be created in the device and shall be persistent (remain after reboot). + + + + + + + This operation modifies an existing authorization server configuration. + + + + + + + This operation deletes the given authorization server configuration and configuration change shall always be persistent. + + + + + @@ -2919,6 +3340,27 @@ + + + + + + + + + + + + + + + + + + + + + @@ -2930,6 +3372,15 @@ + + + + + + + + + @@ -3381,6 +3832,45 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/wsdl/ver10/advancedsecurity/wsdl/security.wsdl b/wsdl/ver10/advancedsecurity/wsdl/security.wsdl deleted file mode 100644 index 55421d38b..000000000 --- a/wsdl/ver10/advancedsecurity/wsdl/security.wsdl +++ /dev/null @@ -1,3312 +0,0 @@ - - - - - - - - - - - - Unique identifier for keys in the keystore. - - - - - - - - - Unique identifier for certificates in the keystore. - - - - - - - - - Unique identifier for certification paths in the keystore. - - - - - - - - - Unique identifier for passphrases in the keystore. - - - - - - - - - Unique identifier for 802.1X configurations in the keystore. - - - - - - - - - The status of a key in the keystore. - - - - - Key is ready for use - - - - - Key is being generated - - - - - Key has not been successfully generated and cannot be used. - - - - - - - - An object identifier (OID) in dot-decimal form as specified in RFC4512. - - - - - - - - - The distinguished name attribute type encoded as specified in RFC 4514. - - - - - - - - The distinguished name attribute values are encoded in UTF-8 or in hexadecimal form as specified in RFC 4514. - - - - - - - The attributes of a key in the keystore. - - - - - The ID of the key. - - - - - The client-defined alias of the key. - - - - - Absent if the key is not a key pair. True if and only if the key is a key pair and contains a private key. False if and only if the key is a key pair and does not contain a private key. - - - - - The status of the key. The value should be one of the values in the tas:KeyStatus enumeration. - - - - - - True if and only if the key was generated outside the device. - - - - - True if and only if the key is stored in a specially protected hardware component inside the device. - - - - - - - - - - - - - - - - A distinguished name attribute type and value pair. - - - - - The attribute type. - - - - - The value of the attribute. - - - - - - - - - - A multi-valued RDN - - - - - A list of types and values defining a multi-valued RDN - - - - - - - - - - A country name as specified in - X.500. - - - - - An organization name as specified in - X.500. - - - - - An organizational unit name as specified in - X.500. - - - - - A distinguished name qualifier as specified in - X.500. - - - - - A state or province name as specified in - X.500. - - - - - A common name as specified in - X.500. - - - - - A serial number as specified in - X.500. - - - - - A locality as specified in X.500. - - - - - A title as specified in X.500. - - - - - A surname as specified in X.500. - - - - - A given name as specified in X.500. - - - - - Initials as specified in X.500. - - - - - A pseudonym as specified in X.500. - - - - - A generation qualifier as specified in - X.500. - - - - - A generic type-value pair - attribute. - - - - - A multi-valued RDN - - - - - - Required extension point. It is recommended to not use this element, and instead use GenericAttribute and the numeric Distinguished Name Attribute Type. - - - - - - - Domain Component as specified in RFC3739 - - - - - - - - - - - - - An identifier of an algorithm. - - - - - The OID of the algorithm in dot-decimal form. - - - - - Optional parameters of the algorithm (depending on the algorithm). - - - - - - - - - - - - - - - - A CSR attribute as specified in RFC 2986. - - - - - The OID of the attribute. - - - - - The value of the attribute as a base64-encoded DER representation of an ASN.1 value. - - - - - - - - - - A CSR attribute as specified in PKCS#10. - - - - - An X.509v3 extension field. - - - - - A basic CSR attribute. - - - - - - - - - - - - - - - - A base64-encoded ASN.1 value. - - - - - - - An X.509v3 extension field as specified in RFC 5280 - - - - - The OID of the extension field. - - - - - True if and only if the extension is critical. - - - - - The value of the extension field as a base64-encoded DER representation of an ASN.1 value. - - - - - - - - - - An X.509 cerficiate as specified in RFC 5280. - - - - - The ID of the certificate. - - - - - The ID of the key that this certificate associates to the certificate subject. - - - - - The client-defined alias of the certificate. - - - - - The base64-encoded DER representation of the X.509 certificate. - - - - - - - - - - A sequence of certificate IDs. - - - - - A certificate ID. - - - - - - - - - An X.509 certification path as defined in RFC 5280. - - - - - A certificate in the certification path. - - - - - The client-defined alias of the certification path. - - - - - - - - - - - - - - - - - - The ID of the passphrase. - - - - - The alias of the passphrase. - - - - - - - - - - A list of supported 802.1X authentication methods, such as "EAP-PEAP/MSCHAPv2" and "EAP-MD5". The '/' character is used as a separator between the outer and inner methods. - - - - - - - The capabilities of the 802.1X implementation on a device. - - - - - - - The maximum number of 802.1X configurations that may be defined simultaneously. - - - - - The authentication methods supported by the 802.1X implementation. - - - - - - - - The configuration parameters required for a particular authentication method. - - - - - The identity used in this authentication method, if required. - - - - - The unique identifier of the certification path used in this authentication method, if required. - - - - - The identifier for the password used in this authentication method, if required. If Identity is used as an anonymous identity for this authentication method, PassphraseID is ignored. - - - - - The configuration of the next stage of authentication, if required. - - - - - - - The authentication method for this stage (e.g., "EAP-PEAP"). - - - - - - - - - - - - - - - The unique identifier of the IEEE 802.1X configuration. - - - - - The client-defined alias of the 802.1X configuration. - - - - - The outer level authentication method used in this 802.1X configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - True if and only if the TLS server shall not authenticate client certificates that do not contain the TLS WWW client authentication key usage extension as specified in RFC 5280, Sect. 4.2.1.12. - - - - - True if and only if delta CRLs, if available, shall be applied to CRLs. - - - - - - - - - - - - - - - - - The certificate ID of the certificate to be used as trust anchor. - - - - - - - - - - - - - - - - - - - - - - - - - - - A list of RSA key lenghts in bits. - - - - - - A list of X.509 versions. - - - - - - A list of TLS versions. - - - - - - A list of password based encryption algorithms. - - - - - - A list of password based MAC algorithms. - - - - - - - The capabilities of a keystore implementation on a device. - - - - - The signature algorithms supported by the keystore implementation. - - - - - - - - - - - - - Indicates the maximum number of keys that the device can store simultaneously. - - - - - Indicates the maximum number of certificates that the device can store simultaneously. - - - - - Indicates the maximum number of certification paths that the device can store simultaneously. - - - - - Indication that the device supports on-board RSA key pair generation. - - - - - Indicates which RSA key lengths are supported by the device. - - - - - Indicates support for creating PKCS#10 requests for RSA keys and uploading the certificate obtained from a CA.. - - - - - Indicates support for creating self-signed certificates for RSA keys. - - - - - Indicates which X.509 versions are supported by the device. - - - - - Indicates the maximum number of passphrases that the device is able to store simultaneously. - - - - - Indicates support for uploading an RSA key pair in a PKCS#8 data structure. - - - - - Indicates support for uploading a certificate along with an RSA private key in a PKCS#12 data structure. - - - - - Indicates which password-based encryption algorithms are supported by the device. - - - - - Indicates which password-based MAC algorithms are supported by the device. - - - - - - - - Indicates the maximum number of CRLs that the device is able to store simultaneously. - - - - - Indicates the maximum number of certification path validation policies that the device is able to store simultaneously. - - - - - Indicates whether a device supports checking for the TLS WWW client auth extended key usage extension while validating certification paths. - - - - - - - - Indicates the device requires that each certificate with private key has its own unique key. - - - - - - - - The capabilities of a TLS server implementation on a device. - - - - - - - Indicates which TLS versions are supported by the device. - - - - - Indicates whether the device supports enabling and disabling specific TLS versions. - - - - - Indicates the maximum number of certification paths that may be assigned to the TLS server simultaneously. - - - - - - - - Indicates whether the device supports TLS client authentication. - - - - - Indicates the maximum number of certification path validation policies that may be assigned to the TLS server simultaneously. - - - - - - - - - - - The capabilities of a Security Configuration Service implementation on a device. - - - - - The capabilities of the keystore implementation. - - - - - The capabilities of the TLS server implementation. - - - - - The capabilities of the 802.1X implementation. - - - - - - - - - - - - - - - - - - - - - The capabilities for the security configuration service is returned in the Capabilities element. - - - - - - - - - - - - The length of the key to be created. - - - - - The client-defined alias of the key. - - - - - - - - - - - The key ID of the key pair being generated. - - - - - Best-effort estimate of how long the key generation will take. - - - - - - - - - - - - The key pair to be uploaded in a PKCS#8 data structure. - - - - - The client-defined alias of the key pair. - - - - - The ID of the passphrase to use for decrypting the uploaded key pair. - - - - - The passphrase to use for decrypting the uploaded key pair. - - - - - - - - - - - The key ID of the uploaded key pair. - - - - - - - - - - - - The certificates and key pair to be uploaded in a PKCS#12 data structure. - - - - - The client-defined alias of the certification path. - - - - - The client-defined alias of the key pair. - - - - - True if and only if the device shall behave as if the client had only supplied the first certificate in the sequence of certificates. - - - - - The ID of the passphrase to use for integrity checking of the uploaded PKCS#12 data structure. - - - - - The ID of the passphrase to use for decrypting the uploaded PKCS#12 data structure. - - - - - The passphrase to use for integrity checking and decrypting the uploaded PKCS#12 data structure. - - - - - - - - - - - The certification path ID of the uploaded certification path. - - - - - The key ID of the uploaded key pair. - - - - - - - - - - - - The ID of the key for which to return the status. - - - - - - - - - - - Status of the requested key. The value should be one of the values in the tas:KeyStatus enumeration. - - - - - - - - - - - - The ID of the key pair for which to return whether it contains a private key. - - - - - - - - - - - True if and only if the key pair contains a private key. - - - - - - - - - - - - - - - - - Information about a key in the keystore. - - - - - - - - - - - - The ID of the key that is to be deleted from the keystore. - - - - - - - - - - - - - - - - - The subject to be included in the CSR. - - - - - The ID of the key for which the CSR shall be created. - - - - - An attribute to be included in the CSR. - - - - - The signature algorithm to be used to sign the CSR. - - - - - - - - - - - The DER encoded PKCS#10 certification request. - - - - - - - - - - - - The X.509 version that the generated certificate shall comply to. - - - - - Distinguished name of the entity that the certificate shall belong to. - - - - - The ID of the key for which the certificate shall be created. - - - - - The client-defined alias of the certificate to be created. - - - - - The X.509 not valid before information to be included in the certificate. Defaults to the device's current time or a time before the device's current time. - - - - - The X.509 not valid after information to be included in the certificate. Defaults to the time 99991231235959Z as specified in RFC 5280. - - - - - The signature algorithm to be used for signing the certificate. - - - - - An X.509v3 extension to be included in the certificate. - - - - - - - - - - - The ID of the generated certificate. - - - - - - - - - - - - The base64-encoded DER representation of the X.509 certificate to be uploaded. - - - - - The client-defined alias of the certificate. - - - - - The client-defined alias of the key pair. - - - - - Indicates if the device shall verify that a matching key pair with a private key exists in the keystore. - - - - - - - - - - - The ID of the uploaded certificate. - - - - - The ID of the key that the uploaded certificate certifies. - - - - - - - - - - - - The ID of the certificate to retrieve. - - - - - - - - - - - The DER representation of the certificate. - - - - - - - - - - - - - - - A list with all certificates stored in the keystore. - - - - - A certificate stored in the keystore. - - - - - - - - - - - - The ID of the certificate to delete. - - - - - - - - - - - - - - - - - The IDs of the certificates to include in the certification path, where each certificate signature except for the last one in the path must be verifiable with the public key certified by the next certificate in the path. - - - - - The client-defined alias of the certification path. - - - - - - - - - - - The ID of the generated certification path. - - - - - - - - - - - - The ID of the certification path to retrieve. - - - - - - - - - - - The certification path that is stored under the given ID in the keystore. - - - - - - - - - - - - - - - - - An ID of a certification path in the keystore. - - - - - - - - - - - - The ID of the certification path to delete. - - - - - - - - - - - - - - - - - The passphrase to upload. - - - - - The alias for the passphrase to upload. - - - - - - - - - - - The PassphraseID of the uploaded passphrase. - - - - - - - - - - - - - - - - A list with information about all passphrases in the keystore. - - - - Information about a passphrase in the keystore. - - - - - - - - - - - - The ID of the passphrase that is to be deleted from the keystore. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The IDs of all certification paths that are assigned to the TLS server on the device. - - - - - - - - - - - - List of TLS versions to allow. - - - - - - - - - - - - - - - - - - - - - - List of allowed TLS versions. - - - - - - - - - - - - - - - The CRL to be uploaded to the device. - - - - - - - The alias to assign to the uploaded CRL. - - - - - - - - - - - - - - - - - - - - The ID of the uploaded CRL. - - - - - - - - - - - - - - The ID of the CRL to be returned. - - - - - - - - - - - - - The CRL with the requested ID. - - - - - - - - - - - - - - - - - - - A list of all CRLs that are stored in the keystore on the device. - - - - - - - - - - - - - - The ID of the CRL to be deleted. - - - - - - - - - - - - - - - - - - - The alias to assign to the created certification path validation policy. - - - - - - - The parameters of the certification path validation policy to be created. - - - - - - - The trust anchors of the certification path validation policy to be created. - - - - - - - - - - - - - - - - - - - - The ID of the created certification path validation policy. - - - - - - - - - - - - - - The ID of the certification path validation policy to be created. - - - - - - - - - - - - - The certification path validation policy that is stored under the requested ID. - - - - - - - - - - - - - - - - - - - A list of all certification path validation policies that are stored in the keystore on the device. - - - - - - - - - - - - - - The ID of the certification path validation policy to be deleted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The ID of the certification path validation policy to assign to the TLS server. - - - - - - - - - - - - - - - - - - - The ID of the certification path validation policy to de-assign from the TLS server. - - - - - - - - - - - - - - - - - - - The ID of the certification path validation policy to be de-assigned from the TLS server. - - - - - - - The ID of the certification path validation policy to assign to the TLS server. - - - - - - - - - - - - - - - - - - - - - - - - A list of IDs of the certification path validation policies that are assigned to the TLS server. - - - - - - - - - - - - - - - - The desired 802.1X configuration. - - - - - - - - - - - The unique identifier of the created 802.1X configuration. - - - - - - - - - - - - - - - - - The list of unique identifiers of 802.1X configurations on the device. - - - - - - - - - - - - The unique identifier of the desired 802.1X configuration. - - - - - - - - - - - The 802.1X configuration, without password information. - - - - - - - - - - - - The unique identifier of the 802.1X configuration to be deleted. - - - - - - - - - - - - - - - - - The unique identifier of the Network Interface on which the 802.1X configuration is to be set. (NOTE: the network interface token is defined in devicemgmt.wsdl as tt:ReferenceToken, which is a derived type of xs:string. To avoid importing all of common.xsd for this single type, the base type is used here.) - - - - - The unique identifier of the 802.1X configuration to be set. - - - - - - - - - - - Indicates whether or not a reboot is required after configuration updates. - - - - - - - - - - - - The unique identifier of the Network Interface for which the 802.1X configuration is to be retrieved. (NOTE: the network interface token is defined in devicemgmt.wsdl as tt:ReferenceToken, which is a derived type of xs:string. To avoid importing all of common.xsd for this single type, the base type is used here.) - - - - - - - - - - - The unique identifier of 802.1X configuration assigned to the Network Interface. - - - - - - - - - - - - The unique identifier of the Network Interface for which the 802.1X configuration is to be deleted. (NOTE: the network interface token is defined in devicemgmt.wsdl as tt:ReferenceToken, which is a derived type of xs:string. To avoid importing all of common.xsd for this single type, the base type is used here.) - - - - - - - - - - - Indicates whether or not a reboot is required after configuration updates. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Common functionality for all security configuraiton service parts. - - Returns the capabilities of the security configuraiton service. The result is returned in a typed answer. - - - - - - Basic keystore functionality. - - - This operation triggers the asynchronous generation of an RSA key pair of a particular key length (specified as the number of bits) as specified in [RFC 3447], with a suitable key generation mechanism on the device. - Keys, especially RSA key pairs, are uniquely identified using key IDs.
- If the device does not have not enough storage capacity for storing the key pair to be created, the maximum number of keys reached fault shall be produced and no key pair shall be generated. - Otherwise, the operation generates a keyID for the new key and associates the generating status to it.
- Immediately after key generation has started, the device shall return the keyID to the client and continue to generate the key pair. - The client may query the device with the GetKeyStatus operation whether the generation has finished. - The client may also subscribe to Key Status events to be notified about key status changes.
- The device also returns a best-effort estimate of how much time it requires to create the key pair. - A client may use this information as an indication how long to wait before querying the device whether key generation is completed.
- After the key has been successfully created, the device shall assign it the ok status. If the key generation fails, the device shall assign the key the corrupt status. - - - - - - - This operation uploads a key pair in a PKCS#8 data structure as specified in [RFC 5958, RFC 5959].
- If an encryption passphrase ID is supplied in the request, the device shall assume that the KeyPair parameter contains an EncryptedPrivateKeyInfo ASN.1 - structure that is encrypted under the passphrase in the keystore that corresponds to the supplied ID, where the EncryptedPrivateKeyInfo structure contains - both the private key and the corresponding public key. If no encryption passphrase ID is supplied, the device shall assume that the KeyPair parameter contains a - OneAsymmetricKey ASN.1 structure which contains both the private key and the corresponding public key. - - - - - - - This operation uploads a certification path consisting of X.509 certificates as specified by [RFC 5280] in DER encoding along with a private key to a device’s keystore. - Certificates and private key are supplied in the form of a PKCS#12 file as specified in [PKCS#12].
- The device shall support PKCS#12 files that contain the following safe bags:
- * one or more instances of CertBag [PKCS#12, Sect. 4.2.3] - * either exactly one instance of KeyBag [PKCS#12, Sect. 4.3.1] or exactly one instance of PKCS8ShroudedKeyBag [PKCS#12, Sect. 4.2.2].
- If the IgnoreAdditionalCertificates parameter has the value true, the device shall behave as if the client had supplied only the first CertBag in the sequence of CertBag instances. - The device shall support PKCS#12 passphrase integrity mode for integrity protection of the PKCS#12 PFX as specified in [PKCS#12, Sect. 4]. - The device shall support PKCS8ShroudedKeyBags that are encrypted with the same passphrase as the CertBag instances. - If an integrity passphrase ID is supplied, the device shall use the corresponding passphrase in the keystore to check the integrity of the supplied PKCS#12 PFX. - If an integrity passphrase ID is supplied, but the supplied PKCS#12 PFX has no integrity protection, the device shall produce a BadPKCS12File fault and shall - not store the uploaded certificates nor the uploaded key pair in the keystore. - If an encryption passphrase ID is supplied, the device shall use the corresponding passphrase in the keystore to decrypt the PKCS8ShroudedKeyBag and the CertBag instances. - If an EncryptionPassphraseID is supplied, but a CertBag is not encrypted, the device shall ignore the supplied EncryptionPassphraseID when processing this CertBag. - If an EncryptionPassphraseID is supplied, but a KeyBag is provided instead of a PKCS8ShroudedKeyBag, the device shall ignore the supplied EncryptionPassphraseID when processing the KeyBag. - - - - - - - This operation returns the status of a key.
- Keys are uniquely identified using key IDs. If no key is stored under the requested key ID in the keystore, an InvalidKeyID fault is produced. - Otherwise, the status of the key is returned. - - - - - - - This operation returns whether a key pair contains a private key.
- Keys are uniquely identified using key IDs. If no key is stored under the requested key ID in the keystore or the key identified by the requested key ID does not identify a key pair, - the device shall produce an InvalidKeyID fault. - Otherwise, this operation returns true if the key pair identified by the key ID contains a private key, and false otherwise. - - - - - - - This operation returns information about all keys that are stored in the device’s keystore.
- This operation may be used, e.g., if a client lost track of which keys are present on the device. - If no key is stored on the device, an empty list is returned. - - - - - - - This operation deletes a key from the device’s keystore.
- Keys are uniquely identified using key IDs. If no key is stored under the requested key ID in the keystore, a device shall produce an InvalidArgVal fault. - If a reference exists for the specified key, a device shall produce the corresponding fault and shall not delete the key. - If there is a key under the requested key ID stored in the keystore and the key could not be deleted, a device shall produce a KeyDeletion fault. - If the key has the status generating, a device shall abort the generation of the key and delete from the keystore all data generated for this key. - After a key is successfully deleted, the device may assign its former ID to other keys. - - - - - - - This operation generates a DER-encoded PKCS#10 v1.7 certification request (sometimes also called certificate signing request or CSR) as specified in RFC 2986 - for a public key on the device.
- The key pair that contains the public key for which a certification request shall be produced is specified by its key ID. - If no key is stored under the requested KeyID or the key specified by the requested KeyID is not an asymmetric key pair, an invalid key ID fault shall be produced and - no CSR shall be generated.
- - A device that supports this command shall as minimum support the sha-1WithRSAEncryption signature algorithm as specified in RFC 3279. - If the specified signature algorithm is not supported by the device, an UnsupportedSignatureAlgorithm fault shall be produced and no CSR shall be generated.
- - If the public key identified by the requested Key ID is an invalid input to the specified signature algorithm, a KeySignatureAlgorithmMismatch fault shall be produced - and no CSR shall be generated. - If the key pair does not have status ok, a device shall produce an InvalidKeyStatus fault and no CSR shall be generated. - - - - - - - This operation generates for a public key on the device a self-signed X.509 certificate that complies to RFC 5280.
- The X509Version parameter specifies the version of X.509 that the generated certificate shall comply to. - A device that supports this command shall support the generation of X.509v3 certificates as specified in RFC 5280 and may additionally be able to handle other X.509 certificate formats - as indicated by the X.509Versions capability.
- The key pair that contains the public key for which a self-signed certificate shall be produced is specified by its key pair ID. - The subject parameter describes the entity that the public key belongs to. - If the key pair does not have status ok, a device shall produce an InvalidKeyStatus fault and no certificate shall be generated. - - The signature algorithm parameter determines which signature algorithm shall be used for signing the certification request with the public key specified by the key ID parameter. - A device that supports this command shall as minimum support the sha-1WithRSAEncryption signature algorithm as specified in RFC 3279. - The Extensions parameter specifies potential X509v3 extensions that shall be contained in the certificate. - A device that supports this command shall support the extensions that are defined in [RFC 5280], Sect. 4.2] as mandatory for CAs that issue self-signed certificates.
- - Certificates are uniquely identified using certificate IDs. If the command was successful, the device generates a new ID for the generated certificate and returns this ID.
- If the device does not have not enough storage capacity for storing the certificate to be created, the maximum number of certificates reached fault shall be produced and no certificate shall be generated. - - - - - - - This operation uploads an X.509 certificate as specified by [RFC 5280] in DER encoding and the public key in the certificate to a device’s keystore.
- A device that supports this command shall be able to handle X.509v3 certificates as specified in RFC 5280 and may additionally be able to handle other X.509 certificate formats as indicated by the X.509Versions capability. - A device that supports this command shall support sha1-WithRSAEncryption as certificate signature algorithm.
- - Certificates are uniquely identified using certificate IDs, and key pairs are uniquely identified using key IDs. - The device shall generate a new certificate ID for the uploaded certificate.
- Certain certificate usages, e.g. TLS server authentication, require the private key that corresponds to the public key in the certificate to be present in the keystore. - In such cases, the client may indicate that it expects the device to produce a fault if the matching private key for - the uploaded certificate is not present in the keystore by setting the PrivateKeyRequired argument in the upload request to true.
- - The uploaded certificate has to be linked to a key pair in the keystore. - If no private key is required for the public key in the certificate and a key pair exists in the keystore with a public key equal to the public key in the certificate, - the uploaded certificate is linked to the key pair identified by the supplied key ID by adding a reference from the certificate to the key pair. - If no private key is required for the public key in the certificate and no key pair exists with the public key equal to the public key in the certificate, - a new key pair with status ok is created with the public key from the certificate, and this key pair is linked to the uploaded certificate by adding a reference from - the certificate to the key pair. - If a private key is required for the public key in the certificate, and a key pair exists in the keystore with a private key that matches the public key in the certificate, - the uploaded certificate is linked to this keypair by adding a reference from the certificate to the key pair. - If a private key is required for the public key and no such keypair exists in the keystore, the NoMatchingPrivateKey fault shall be produced and the certificate - shall not be stored in the keystore. - If the key pair that the certificate shall be linked to does not have status ok, an InvalidKeyID fault is produced, and the uploaded certificate is not stored in the keystore. - If the device cannot process the uploaded certificate, a BadCertificate fault is produced and neither the uploaded certificate nor the public key are stored in the device’s keystore. - The BadCertificate fault shall not be produced based on the mere fact that the device’s current time lies outside the interval defined by the notBefore and notAfter fields as specified by [RFC 5280], Sect. 4.1 . - This operation shall not mark the uploaded certificate as trusted.
- - If the device does not have not enough storage capacity for storing the certificate to be uploaded, the maximum number of certificates reached fault shall be produced - and no certificate shall be uploaded. - If the device does not have not enough storage capacity for storing the key pair that eventually has to be created, the device shall generate a maximum number of keys reached fault. - Furthermore the device shall not generate a key pair and no certificate shall be stored. - - - - - - - This operation returns a specific certificate from the device’s keystore.
- Certificates are uniquely identified using certificate IDs. If no certificate is stored under the requested certificate ID in the keystore, an InvalidArgVal fault is produced. - It shall be noted that this command does not return the private key that is associated to the public key in the certificate. - - - - - - - This operation returns the IDs of all certificates that are stored in the device’s keystore.
- This operation may be used, e.g., if a client lost track of which certificates are present on the device. - If no certificate is stored in the device’s keystore, an empty list is returned. - - - - - - - This operation deletes a certificate from the device’s keystore.
- The operation shall not delete the public key that is contained in the certificate from the keystore. - Certificates are uniquely identified using certificate IDs. If no certificate is stored under the requested certificate ID in the keystore, an InvalidArgVal fault is produced. - If there is a certificate under the requested certificate ID stored in the keystore and the certificate could not be deleted, a CertificateDeletion fault is produced. - If a reference exists for the specified certificate, the certificate shall not be deleted and the corresponding fault shall be produced. - After a certificate has been successfully deleted, the device may assign its former ID to other certificates. - - - - - - - This operation creates a sequence of certificates that may be used, e.g., for certification path validation or for TLS server authentication.
- Certification paths are uniquely identified using certification path IDs. Certificates are uniquely identified using certificate IDs. - A certification path contains a sequence of certificate IDs. - If there is a certificate ID in the sequence of supplied certificate IDs for which no certificate exists in the device’s keystore, the corresponding fault shall be produced - and no certification path shall be created.
- - The signature of each certificate in the certification path except for the last one must be verifiable with the public key contained in the next certificate in the path. - If there is a certificate ID in the request other than the last ID for which the corresponding certificate cannot be verified with the public key in the certificate identified - by the next certificate ID, an InvalidCertificateChain fault shall be produced and no certification path shall be created. - - - - - - - This operation returns a specific certification path from the device’s keystore.
- Certification paths are uniquely identified using certification path IDs. - If no certification path is stored under the requested ID in the keystore, an InvalidArgVal fault is produced. - - - - - - - This operation returns the IDs of all certification paths that are stored in the device’s keystore.
- This operation may be used, e.g., if a client lost track of which certificates are present on the device. - If no certification path is stored on the device, an empty list is returned. - - - - - - - This operation deletes a certification path from the device’s keystore.
- This operation shall not delete the certificates that are referenced by the certification path. - Certification paths are uniquely identified using certification path IDs. - If no certification path is stored under the requested certification path ID in the keystore, an InvalidArgVal fault is produced. - If there is a certification path under the requested certification path ID stored in the keystore and the certification path could not be deleted, - a CertificationPathDeletion fault is produced. - If a reference exists for the specified certification path, the certification path shall not be deleted and the corresponding fault shall be produced. - After a certification path is successfully deleted, the device may assign its former ID to other certification paths. - - - - - - - This operation uploads a passphrase to the keystore of the device. - - - - - - - This operation returns information about all passphrases that are stored in the keystore of the device. - This operation may be used, e.g., if a client lost track of which passphrases are present on the device. - If no passphrase is stored on the device, the device shall return an empty list. - - - - - - - This operation deletes a passphrase from the keystore of the device. - - - - - - - - - - This operation uploads a certificate revocation list (CRL) as specified in [RFC 5280] to the keystore on the device. - If the device does not have enough storage space to store the CRL to be uploaded, the device shall produce a MaximumNumberOfCRLsReached fault and shall not store the supplied CRL. - If the device is not able to process the supplied CRL, the device shall produce a BadCRL fault and shall not store the supplied CRL. - If the device does not support the signature algorithm that was used to sign the supplied CRL, the device shall produce an UnsupportedSignatureAlgorithm fault and shall not store the supplied CRL. - - - - - - - This operation returns a specific certificate revocation list (CRL) from the keystore on the device. - Certification revocation lists are uniquely identified using CRLIDs. If no CRL is stored under the requested CRLID, the device shall produce a CRLID fault. - - - - - - - This operation returns all certificate revocation lists (CRLs) that are stored in the keystore on the device. - If no certificate revocation list is stored in the device’s keystore, an empty list is returned. - - - - - - - This operation deletes a certificate revocation list (CRL) from the keystore on the device. - Certification revocation lists are uniquely identified using CRLIDs. If no CRL is stored under the requested CRLID, the device shall produce a CRLID fault. - If a reference exists for the specified CRL, the device shall produce a ReferenceExists fault and shall not delete the CRL. - After a CRL has been successfully deleted, a device may assign its former ID to other CRLs. - - - - - - - This operation creates a certification path validation policy. - Certification path validation policies are uniquely identified using certification path validation policy IDs. The device shall generate a new certification path validation policy ID for the created certification path validation policy. - For the certification path validation parameters that are not represented in the certPathValidationParameters data type, the device shall use the default values specified in Sect. 3. - If the device does not have enough storage capacity for storing the certification path validation policy to be created, the device shall produce a maximum number of certification path validation policies reached fault and shall not create a certification path validation policy. - If there is at least one trust anchor certificate ID in the request for which there exists no certificate in the device’s keystore, the device shall produce a CertificateID fault and shall not create a certification path validation policy. - If the device cannot process the supplied certification path validation parameters, the device shall produce a CertPathValidationParameters fault and shall not create a certification path validation policy. - - - - - - - This operation returns a certification path validation policy from the keystore on the device. - Certification path validation policies are uniquely identified using certification path validation policy IDs. If no certification path validation policy is stored under the requested certification path validation policy ID, the device shall produce a CertPathValidationPolicyID fault. - - - - - - - This operation returns all certification path validation policies that are stored in the keystore on the device. - If no certification path validation policy is stored in the device’s keystore, an empty list is returned. - - - - - - - This operation deletes a certification path validation policy from the keystore on the device. - Certification path validation policies are uniquely identified using certification path validation policy IDs. If no certification path validation policy is stored under the requested certification path validation policy ID, the device shall produce an InvalidCertPathValidationPolicyID fault. - If a reference exists for the requested certification path validation policy, the device shall produce a ReferenceExists fault and shall not delete the certification path validation policy. - After the certification path validation policy has been deleted, the device may assign its former ID to other certification path validation policies. - - - - - - - - - - TLS server functionality. - - - This operation assigns a key pair and certificate along with a certification path (certificate chain) to the TLS server on the device. - The TLS server shall use this information for key exchange during the TLS handshake, particularly for constructing server certificate messages as specified in RFC 4346 and RFC 2246.
- - Certification paths are identified by their certification path IDs in the keystore. The first certificate in the certification path must be the TLS server certificate. - Since each certificate has exactly one associated key pair, a reference to the key pair that is associated with the server certificate is not supplied explicitly. - Devices shall obtain the private key or results of operations under the private key by suitable internal interaction with the keystore.
- If a device chooses to perform a TLS key exchange based on the supplied certification path, it shall use the key pair that is associated with the server certificate for - key exchange and transmit the certification path to TLS clients as-is, i.e., the device shall not check conformance of the certification path to RFC 4346 norRFC 2246. - In order to use the server certificate during the TLS handshake, the corresponding private key is required. - Therefore, if the key pair that is associated with the server certificate, i.e., the first certificate in the certification path, does not have an associated private key, - the NoPrivateKey fault is produced and the certification path is not associated to the TLS server.
- A TLS server may present different certification paths to different clients during the TLS handshake instead of presenting the same certification path to all clients. - Therefore more than one certification path may be assigned to the TLS server.
- If the maximum number of certification paths that may be assigned to the TLS server simultaneously is reached, the device shall generate a MaximumNumberOfCertificationPathsReached - fault and the requested certification path shall not be assigned to the TLS server. - - - - - - - This operation removes a key pair and certificate assignment (including certification path) to the TLS server on the device.
- Certification paths are identified using certification path IDs. If the supplied certification path ID is not associated to the TLS server, an InvalidArgVal fault is produced. - - - - - - - This operation replaces an existing key pair and certificate assignment to the TLS server on the device by a new key pair and certificate assignment (including certification paths).
- - After the replacement, the TLS server shall use the new certificate and certification path exactly in those cases in which it would have used the old certificate and certification path. - Therefore, especially in the case that several server certificates are assigned to the TLS server, clients that wish to replace an old certificate assignment by a new assignment - should use this operation instead of a combination of the Add TLS Server Certificate Assignment and the Remove TLS Server Certificate Assignment operations.
- - Certification paths are identified using certification path IDs. If the supplied old certification path ID is not associated to the TLS server, or no certification path exists - under the new certification path ID, the corresponding InvalidArgVal faults are produced and the associations are unchanged. - The first certificate in the new certification path must be the TLS server certificate.
- Since each certificate has exactly one associated key pair, a reference to the key pair that is associated with the new server certificate is not supplied explicitly. - Devices shall obtain the private key or results of operations under the private key by suitable internal interaction with the keystore.
- If a device chooses to perform a TLS key exchange based on the new certification path, it shall use the key pair that is associated with the server certificate - for key exchange and transmit the certification path to TLS clients as-is, i.e., the device shall not check conformance of the certification path to RFC 4346 norRFC 2246. - In order to use the server certificate during the TLS handshake, the corresponding private key is required. - Therefore, if the key pair that is associated with the server certificate, i.e., the first certificate in the certification path, does not have an associated private key, - the NoPrivateKey fault is produced and the certification path is not associated to the TLS server. - - - - - - - This operation sets the version(s) of TLS which the device shall use. Valid values are taken from the TLSServerSupported capability.
- A client initiates a TLS session by sending a ClientHello with the hightest TLS version it supports. This suggests to the server that the client can accept any TLS version up to and including that version.
- The server then chooses the TLS version to use. This is generally the highest TLS version the server supports that is within the range of the client. For example, if a ClientHello indicates TLS version 1.1, the server can proceed with TLS 1.0 or TLS 1.1.
- In the event that an ONVIF installation wishes to disable certain version(s) of TLS, it may do so with this operation. For example, to disable TLS 1.0 on a device signaling support for TLS versions 1.0, 1.1, and 1.2, the enabled version list may be set to "1.1 1.2", omitting 1.0. If a client then attempts to connect with a ClientHello containing TLS 1.0, the server shall send a "protocol_version" alert message and close the connection. This handshake indicates to the client that TLS 1.0 is not supported by the server. The client must try again with a higher TLS version suggestion.
- An empty list is not permitted. Disabling all versions of TLS is not the intent of this operation. See AddServerCertificateAssignment and RemoveServerCertificateAssignment. - - - - - - - This operation retrieves the version(s) of TLS which are currently enabled on the device. - - - - - - - This operation returns the IDs of all key pairs and certificates (including certification paths) that are assigned to the TLS server on the device.
- This operation may be used, e.g., if a client lost track of the certification path assignments on the device. - If no certification path is assigned to the TLS server, an empty list is returned. - - - - - - - - - - This operation activates or deactivates TLS client authentication for the TLS server on the device. - The TLS server on the device shall require client authentication if and only if clientAuthenticationRequired is set to true. - If TLS client authentication is requested to be enabled and no certification path validation policy is assigned to the TLS server, the device shall return an EnablingTLSClientAuthenticationFailed fault and shall not enable TLS client authentication. - The device shall execute this command regardless of the TLS enabled/disabled state configured in the ONVIF Device Management Service. - - - - - - - This operation returns whether TLS client authentication is active. - - - - - - - This operation assigns a certification path validation policy to the TLS server on the device. The TLS server shall enforce the policy when authenticating TLS clients and consider a client authentic if and only if the algorithm returns valid. - If no certification path validation policy is stored under the requested CertPathValidationPolicyID, the device shall produce a CertPathValidationPolicyID fault. - A TLS server may use different certification path validation policies to authenticate clients. Therefore more than one certification path validation policy may be assigned to the TLS server. If the maximum number of certification path validation policies that may be assigned to the TLS server simultaneously is reached, the device shall produce a MaximumNumberOfTLSCertPathValidationPoliciesReached fault and shall not assign the requested certification path validation policy to the TLS server. - - - - - - - This operation removes a certification path validation policy assignment from the TLS server on the device. - If the certification path validation policy identified by the requested CertPathValidationPolicyID is not associated to the TLS server, the device shall produce a CertPathValidationPolicy fault. - - - - - - - This operation replaces a certification path validation policy assignment to the TLS server on the device with another certification path validation policy assignment. - If the certification path validation policy identified by the requested OldCertPathValidationPolicyID is not associated to the TLS server, the device shall produce an OldCertPathValidationPolicyID fault and shall not associate the certification path validation policy identified by the NewCertPathValidationPolicyID to the TLS server. - If no certification path validation policy exists under the requested NewCertPathValidationPolicyID in the device’s keystore, the device shall produce a NewCertPathValidationPolicyID fault and shall not remove the association of the old certification path validation policy to the TLS server. - - - - - - - This operation returns the IDs of all certification path validation policies that are assigned to the TLS server on the device. - - - - - - - - - - 802.1X configuration. - - - (to be written) - - - - - - - (to be written) - - - - - - - (to be written) - - - - - - - (to be written) - - - - - - - (to be written) - - - - - - - (to be written) - - - - - - - (to be written) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/wsdl/ver10/device/wsdl/devicemgmt.wsdl b/wsdl/ver10/device/wsdl/devicemgmt.wsdl index 9ead66688..ef86eff77 100644 --- a/wsdl/ver10/device/wsdl/devicemgmt.wsdl +++ b/wsdl/ver10/device/wsdl/devicemgmt.wsdl @@ -10,7 +10,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO --> - + @@ -232,6 +232,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicates support for WS-Security REL token. + + + Indicates support for JWT-based authentication with WS-Security Binary Security token. + + EAP Methods supported by the device. The int values refer to the IANA EAP Registry. @@ -2266,6 +2271,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + @@ -2880,8 +2886,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - + diff --git a/wsdl/ver10/schema/metadatastream.xsd b/wsdl/ver10/schema/metadatastream.xsd index 9d7930ad9..4790e3a9e 100644 --- a/wsdl/ver10/schema/metadatastream.xsd +++ b/wsdl/ver10/schema/metadatastream.xsd @@ -11,7 +11,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:fc="http://www.onvif.org/ver20/analytics/humanface" xmlns:bd="http://www.onvif.org/ver20/analytics/humanbody" - xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" targetNamespace="http://www.onvif.org/ver10/schema" elementFormDefault="qualified" version="23.06"> + xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" targetNamespace="http://www.onvif.org/ver10/schema" elementFormDefault="qualified" version="23.12"> @@ -111,7 +111,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Refers to the pixels per module - + diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index b3df64207..7770ce185 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -8,7 +8,7 @@ Recipients of this document may copy, distribute, publish, or display this docum THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT. THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE CORPORATION. --> - + @@ -1066,6 +1066,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Group of Video frames length. Determines typically the interval in which the I-Frames will be coded. An entry of 1 indicates I-Frames are continuously generated. An entry of 2 indicates that every 2nd image is an I-Frame, and 3 only every 3rd frame, etc. The frames in between are coded as P or B Frames. + + + Distance between anchor frames of type I-Frame and P-Frame. '1' indicates no B-Frames, '2' indicates that every 2nd frame is encoded as B-Frame, '3' indicates a structure like IBBPBBP..., etc. + + The encoder profile as defined in tt:VideoEncodingProfiles. @@ -1153,6 +1158,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Exactly two values, which define the Lower and Upper bounds for the supported group of Video frames length. These values typically correspond to the I-Frame distance. + + + Signals support for B-Frames. Upper bound for the supported anchor frame distance (must be larger than one). + + List of supported target frame rates in fps (frames per second). The list shall be sorted with highest values first. @@ -8100,7 +8110,7 @@ and sample rate. Optional filter defining on which event condition a recording job gets active. - + diff --git a/wsdl/ver20/analytics/humanface.xsd b/wsdl/ver20/analytics/humanface.xsd index a3c96b252..f51289fa3 100644 --- a/wsdl/ver20/analytics/humanface.xsd +++ b/wsdl/ver20/analytics/humanface.xsd @@ -1,6 +1,6 @@ @@ -121,7 +121,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - @@ -148,7 +147,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Describe the shape of the eye, acceptable values are defined in fc:EyeBrowShape. + Describe the shape of the eye, acceptable values are defined in fc:EyeShape.