Transport Security Model for the Simple Network Management Protocol (SNMP)
also
- std-78
Extracted elements (30)
The SNMP-TSM-MIB objects SHOULD NOT be modified via other subsystems or models defined in other documents, following the RFC 3411 design principle of self-contained, independently evolvable modules. This allows TSM to move along the standards track on a different timeline from other SNMP modules.
Transport domain prefixes on securityNames allow SNMP applications (access control, notification generation, proxy forwarding) to differentiate principals by their transport mechanism, since the RFC 3411 ASIs carry no explicit Transport Model identifier.
TSM does not implement cryptographic mechanisms itself; instead it trusts assertions from the Transport Model about the security level provided. This is by design because the Security Model has no means to verify whether a Transport Model's assertion about its security characteristics is accurate.
With secure transports, authentication, integrity, timeliness, and decryption occur in the Transport Model before ASN.1 decoding, reversing the order used by USM where the Security Model processes security after the Message Processing Model decodes the header. This difference reflects where security context is available in each architecture.
SNMPv1 and SNMPv2c message processing as described in BCP 74 (RFC 3584) always selects the SNMPv1(1) and SNMPv2c(2) Security Models with no mechanism to select an alternative, so these message formats cannot use the Transport Security Model.
The Transport Security Model uses its own independent MIB module to maintain isolation from other Security Models such as USM (RFC 3414), enabling coexistence within the same SNMP engine.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, SNMPv3 with cryptographic security is RECOMMENDED, and implementers should consider full USM and Transport Security Model support.
For an outgoing SNMPv3 message to be secured using the Transport Security Model, the application MUST specify a securityModel parameter value of transportSecurityModel(4) in the sendPdu Abstract Service Interface (ASI).
For responses and reports, the security parameters used MUST be the same as those used for the corresponding request. The TSM sets tmSameSecurity to true in the tmStateReference before passing it to the Transport Model.
If snmpTsmConfigurationUsePrefix is set to false, then all securityNames provided by or to the Transport Security Model MUST NOT include a transport domain prefix.
If snmpTsmConfigurationUsePrefix is set to true, then all securityNames provided by or to the Transport Security Model MUST include a valid transport domain prefix.
If tmStateReference does not contain values for tmTransportDomain, tmTransportAddress, tmSecurityName, and tmTransportSecurityLevel, the snmpTsmInvalidCaches counter is incremented, an error is returned, and Security Model processing stops.
If tmTransportSecurityLevel specifies weaker security than the securityLevel requested (e.g., noPriv when Priv is required), the snmpTsmInadequateSecurityLevels counter is incremented and an unsupportedSecurityLevel error indication is returned.
In times of network stress, the security protocol and its underlying security mechanisms SHOULD NOT depend solely upon the ready availability of other network services such as NTP or AAA protocols.
The snmpTsmConfigurationUsePrefix object SHOULD persist across system reboots.
The Transport Security Model MUST only be used with Transport Models that know how to process a tmStateReference, such as the Secure Shell Transport Model (RFC 5592).
The Transport Security Model SHOULD always be used with Transport Models that provide adequate security; 'adequate security' is a configuration and/or run-time decision of the operator or management application.
The generateRequestMsg and generateResponseMsg ASIs are extended by the Transport Subsystem to add transportDomain, transportAddress (IN), and tmStateReference (OUT) parameters for coordinating transport-layer security with the Security Model.
The securityStateReference is a per-message cache created by the Transport Security Model during incoming message processing. It stores the tmStateReference so that response messages can reuse the same transport security parameters.
The snmpTsmConfigurationUsePrefix MIB object (TruthValue, read-write, default false) controls whether transport-domain prefixes are prepended to securityNames. This allows applications such as access control and notification generation to factor in the transport model used.
The snmpTsmStats subtree defines four Counter32 error counters: snmpTsmInvalidCaches (missing tmStateReference), snmpTsmInadequateSecurityLevels (transport security weaker than requested), snmpTsmUnknownPrefixes (no registered prefix for transport domain), and snmpTsmInvalidPrefixes (malformed prefix in securityName).
The tmStateReference is a cache passed between the Transport Model and the Security Model carrying tmTransportDomain, tmTransportAddress, tmSecurityName, tmTransportSecurityLevel, and tmSameSecurity. It links transport-layer security parameters to SNMP processing.
The Transport Security Model is assigned security model identifier value 4 (transportSecurityModel) in the SNMP Number Spaces Security Models registry. SNMPv3 message processing routes to TSM when msgSecurityModel equals 4.
When snmpTsmConfigurationUsePrefix is true, securityNames are formatted as 'prefix:tmSecurityName', where the prefix is a 1–4 character US-ASCII alphanumeric transport domain identifier followed by a colon (0x3a). The tmSecurityName in the tmStateReference never contains a prefix.
IANA assigned SMI number 190 under the mib-2 prefix for the SNMP-TSM-MIB module defined in this document (OID: mib-2.190).
IANA assigned value 4 for the Transport Security Model (TSM) in the Security Models sub-registry of the SNMP Number Spaces registry. Values 0–3 were previously assigned to 'any', SNMPv1, SNMPv2c, and USM respectively.
Readable counter objects in the SNMP-TSM-MIB reflect configuration errors and do not expose sensitive information, but GET and NOTIFY access should still be controlled, and values should be encrypted when transmitted over the network.
The Transport Security Model does not itself provide authentication or encryption; it relies entirely on the underlying Transport Model for mutual authentication, key binding, confidentiality, and integrity. Which threats are mitigated depends on the chosen Transport Model.
Unauthorized modification of snmpTsmConfigurationUsePrefix can create a denial-of-service condition or cause SNMP messages to be authorized that would not have been authorized under the previous Access Control Model configuration (e.g., VACM).
For outgoing messages, the Transport Security Model sets securityParameters to a zero-length OCTET STRING encoded as '0400' (BER: OCTET STRING tag 0x04, length 0x00). All security context is carried via the tmStateReference, not in the SNMP message header.