Add basic SNMPv3 configuration and user handling by ubkr · Pull Request #611 · onvif/specs

ubkr · 2025-07-18T15:09:46Z

Adds basic SNMPv3 configuration to enable SNMPv3 on the device and configure parameters such as the listening port, EngineID, initial user and set its associated secrets.

venki5685 · 2025-07-21T03:59:57Z

+  <section xml:id="s.snmpv3_extension">
+    <title>SNMPv3 Device Management Extension (Optional)</title>
+    <para>
+      This section defines an optional extension to the Device Management Service for supporting Simple Network Management Protocol version 3 (SNMPv3) as specified in <xref linkend="RFC3410"/> and related standards. Devices supporting this extension <emphasis role="bold">shall</emphasis> indicate this capability via the <literal>SNMPv3</literal> flag in the <literal>DeviceServiceCapabilities</literal> (see Section <xref linkend="_Ref468447902"/>).


where SNMPv3 capability flag is added in DeviceServiceCapabilities in the PR?

No.. I forgot to add that, but I've added it now to the Network category

@ubkr @venki5685 there is an error in the table and the "SNMPv3" is not rendering properly in the table noted in my review comment. Looks to be missing a row section.

kieran242

@ubkr raised a few points and noted some of the Privacy protocols should be prob updated into the new Security Baseline document.

kieran242 · 2025-09-04T15:04:50Z

                </row>
+                <row>
+                  <entry>
+                    <para>SNMPv3</para>


Error here needs correction. Misalignment between the "SNMPv3" and definition "Indication if the device supports SNMPv3..." and description.

kieran242 · 2025-09-04T15:13:26Z

+  <section xml:id="s.snmpv3_extension">
+    <title>SNMPv3 Device Management Extension (Optional)</title>
+    <para>
+      This section defines an optional extension to the Device Management Service for supporting Simple Network Management Protocol version 3 (SNMPv3) as specified in <xref linkend="RFC3410"/> and related standards. Devices supporting this extension <emphasis role="bold">shall</emphasis> indicate this capability via the <literal>SNMPv3</literal> flag in the <literal>DeviceServiceCapabilities</literal> (see Section <xref linkend="_Ref468447902"/>).


@ubkr @venki5685 there is an error in the table and the "SNMPv3" is not rendering properly in the table noted in my review comment. Looks to be missing a row section.

kieran242 · 2025-09-04T15:21:31Z

+              <para role="text">The requested <literal>PrivacyProtocol</literal> is not supported by the Device.</para>
+              <para role="param">env:Sender - ter:InvalidArgVal - ter:SNMPUnsupportedSecurityLevel</para>
+              <para role="text">The combination of protocols for the specified <literal>SecurityLevel</literal> is not supported, or a required protocol was not specified.</para>
+              <para role="param">env:Receiver - ter:ActionNotSupported - ter:MaxSNMPUsersExceeded</para>


How does a device user know the "MaxSNMPUsersExceeded" where has it been defined ?

kieran242 · 2025-09-04T15:26:11Z

+        Keys for authentication and privacy <emphasis role="bold">shall</emphasis> be provided by the Client as base64-encoded binary data using the <literal>tt:BinaryData</literal> type. The Device <emphasis role="bold">shall</emphasis> delocalize these keys using its EngineID as per SNMPv3 USM specifications (<xref linkend="RFC3414"/> Appendix A) before storing them internally.
+      </para>
+      <section xml:id="s.snmpv3_auth_protocols">
+        <title>Authentication Protocols</title>


@HansBusch are these needed to be included in the new security baseline specification? #571

kieran242 · 2025-09-04T15:28:51Z

+        <itemizedlist>
+          <listitem>
+            <para>
+              <emphasis role="bold">AES-128-CFB:</emphasis> As specified in <xref linkend="RFC3826"/> (OID: <literal>usmAesCfb128Protocol</literal>). This protocol is <emphasis role="bold">REQUIRED</emphasis>. The privacy key length is 16 octets.


@HansBusch do we need to also support these protocols "AES-128-CFB" in the Security Baseline doc? #571

HansBusch · 2025-11-12T01:57:13Z

Propose to remove version from method names to ease any potential future support for v4.
Suggest to move schema types to device.wsdl.

Adds SNMPv3 configuration, user handling and control.

- Remove AddSNMPUser, DeleteSNMPUser, and GetSNMPUsers operations - Enhance SetSNMPConfiguration to support initial user creation - Remove SNMPUser and SNMPUserConfiguration complex types - Retain security level, authentication, and privacy protocol types - Update capability descriptions for service config + initial user setup - Maintain GetSNMPConfiguration and SetSNMPConfiguration operations

- Remove xml:id attributes from SNMPv3 RFC entries (RFC 3410, 3411, 3414, 3826, 7860) - Replace <xref linkend='RFCxxxx'/> with [RFC xxxx] bracket notation throughout SNMPv3 section - Maintain datatracker.ietf.org URLs for modern RFC access - Align SNMPv3 references with existing document RFC citation style

Rename privacy protocol enumerations from AES_*_CFB to CFB_AES_* to match RFC 3826 naming convention (cipher mode first). Update OID references from usmAesCfb*Protocol to usmAesCfb*PrivProtocol (correct "Priv" suffix). Remove redundant SNMPv1/v2c statement. The CFB_AES_128 pattern better represents cipher mode (CFB) followed by algorithm (AES) and key size, consistent with RFC 3826 specifications.

Standardize terminology from "SNMPv3" to "SNMP" throughout specification while clarifying that only SNMPv3 protocol version is supported. Update section IDs, operation references, and capability flags for consistency. Flatten SetSNMPConfiguration request structure to accept individual parameters rather than nested types.

ubkr · 2025-12-04T09:33:09Z

Rebased to current development branch.

Some open questions to be adressed later:

Which MIBs should be mandatory or recommended?
Are the mentioned hash and encryption algoritms still valid in todays environment and are there others used by the industry and in IT envs?

venki5685 · 2026-06-03T10:08:31Z

+                      <entry>SecurityLevel</entry>
+                      <entry>tt:SNMPSecurityLevel</entry>
+                      <entry>optional</entry>
+                      <entry>Security level for the initial user (noAuthNoPriv, authNoPriv, authPriv). Required if InitialUserName is provided.</entry>


Device SecurityLevel supported values should be provided via SNMP Options for the client to choose and configure via SetSNMPConfiguration.

I've added a SNMPSecurityLevels capability

venki5685 · 2026-06-03T10:08:51Z

+                    </row>
+                    <row>
+                      <entry>AuthenticationProtocol</entry>
+                      <entry>tt:SNMPAuthenticationProtocol</entry>


Device AuthenticationProtocol supported values should be provided via SNMP Options for the client to choose and configure via SetSNMPConfiguration.

I've added a SNMPAuthenticationProtocols capability

venki5685 · 2026-06-03T10:09:32Z

+                      <entry>Authentication protocol. Required if SecurityLevel is authNoPriv or authPriv.</entry>
+                    </row>
+                    <row>
+                      <entry>AuthenticationKey</entry>


This parameter should be AuthPassword for Initial User, not AuthKey.

I changed it to AuthPassword as suggested

venki5685 · 2026-06-03T10:12:18Z

+                      <entry>Privacy protocol. Required if SecurityLevel is authPriv.</entry>
+                    </row>
+                    <row>
+                      <entry>PrivacyKey</entry>


This parameter should be PrivacyPassword for Initial User, not PrivacyKey.

I changed it to PrivacyPassword as suggested

venki5685 · 2026-06-03T10:12:45Z

+                    </row>
+                    <row>
+                      <entry>PrivacyProtocol</entry>
+                      <entry>tt:SNMPPrivacyProtocol</entry>


Device PrivacyProtocol supported values should be provided via SNMP Options for the client to choose and configure via SetSNMPConfiguration.

I've added a SNMPPrivacyProtocols capability

venki5685 · 2026-06-03T10:15:35Z

+                          port is maintained. Valid port range is typically 1-65535. </entry>
+                    </row>
+                    <row>
+                      <entry>InitialUserName</entry>


if the current SNMP V3 ONVIF spec is limited with only Initial User creation itself rather than SNMP multi user creation and it's management, the spec should explicitly clarify it's scope for snmp Initial User handling.

I tried to change the wording so that you can only set the parameters if SNMP is disabled and you make a SetSNMPConfiguration with all the parameters needed. if you want to change your configuration you need to disable SNMP and then redo the SetSNMPConfiguration with all parameters again.

venki5685 · 2026-06-03T10:18:00Z

+			<wsdl:output message="tds:GetSNMPConfigurationResponse"/>
+		</wsdl:operation>
+		<wsdl:operation name="SetSNMPConfiguration">
+			<wsdl:documentation>Enables or disables the SNMP service and allows configuration of global SNMP parameters such as engine ID and listening port, in accordance with Core.xml. Only SNMPv3 is supported. Only secure protocols as specified in Core.xml are accepted.</wsdl:documentation>


instead of saying Core.xml in the wsdl file, we can use ONVIF-Core-Specification which is published officially.

Refered to "core specifikation" as done in some other places in the document.

…and clarify parameter descriptions

…ved understanding

venki5685 reviewed Jul 21, 2025

View reviewed changes

kieran242 reviewed Sep 4, 2025

View reviewed changes

ocampana-videotec added 26.06 IPR needed WG_enh labels Nov 12, 2025

bsriramprasad mentioned this pull request Nov 20, 2025

SNMPv3 spec edits for readability #687

Merged

ubkr and others added 10 commits December 4, 2025 10:27

Add SNMPv3 configuration and control.

3187ad2

Adds SNMPv3 configuration, user handling and control.

Add SNMPv3 capability flag to Network category.

c09c347

Corrected capabilities table rendering

27c6871

schema validation errors

d9b13d4

spec edits for readability

2d14f44

schema changes

cdae9a3

ubkr force-pushed the SNMPv3 branch from fec6766 to cdae9a3 Compare December 4, 2025 09:30

ubkr marked this pull request as ready for review December 4, 2025 09:34

ocampana-videotec added this to the 26.06 milestone Dec 4, 2025

venki5685 reviewed Jun 3, 2026

View reviewed changes

ubkr added 2 commits June 3, 2026 16:14

Enhance SNMP documentation with additional security protocol details …

36c5c9d

…and clarify parameter descriptions

Clarify SNMP security levels and protocols in documentation for impro…

23bc847

…ved understanding

ubkr added 2 commits June 3, 2026 16:59

Update SNMP documentation for clarity on core specification references

f05db8e

Update entry row span in Core.xml for accurate table representation

9ad3df0

ocampana-videotec added 26.12 and removed 26.06 labels Jun 5, 2026

ocampana-videotec modified the milestones: 26.06, 26.12 Jun 5, 2026

Align SNMP capability attributes between Core.xml and devicemgmt.wsdl

b2879dd

Uh oh!

Conversation

ubkr commented Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kieran242 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HansBusch commented Nov 12, 2025

Uh oh!

ubkr commented Dec 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ubkr Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ubkr Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

ubkr commented Jul 18, 2025 •

edited

Loading

ubkr Jun 3, 2026 •

edited

Loading

ubkr Jun 3, 2026 •

edited

Loading