Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
Extracted elements (28)
SSH does not support session resumption (unlike TLS), making short-lived sessions computationally expensive due to CPU-intensive session-key establishment. SNMP applications SHOULD therefore keep SSH sessions for longer time periods to amortize setup costs.
The SSH Transport Model always sends SNMP messages with authPriv-level protection regardless of the requested securityLevel, because it has no mechanism to test whether an underlying SSH connection provides auth or priv; the design deliberately avoids exposing SSH transport-layer algorithm details to the Transport Model layer.
USM requires a separate user and key-management infrastructure independent of existing security deployments, and operators reported this as a reason for not deploying SNMPv3. SSHTM was designed to leverage the existing and commonly deployed SSH security infrastructure to maximize deployment success while minimizing implementation and deployment costs.
Because naming policies may differ between administrative domains, the SnmpSSHAddress 'user@hostname:port' syntax allows operators to align non-equivalent account names. If no 'user@' prefix is specified, the tmSecurityName is used as the SSH user name. For GSSAPI authentication, a mapping algorithm may be required to transform between SSH identity and tmSecurityName.
To use the SSH Transport Model, SNMP MUST be paired with a Security Model that knows how to process a tmStateReference, such as the Transport Security Model (TSM) for SNMP defined in RFC 5591. The SSH Transport Model alone does not provide sufficient integration with SNMP without a compatible Security Model.
An SSH Transport-Model-compliant implementation MUST use an SSH connection that provides authentication, data integrity, and encryption meeting the highest level of SNMP security (authPriv). Outgoing messages specified with noAuthNoPriv or authNoPriv are actually sent with authPriv-level protection.
Credentials presented by a notification receiver MUST match the expected value(s) for a given transport address, and ownership of the credentials MUST be properly cryptographically verified, because notification authorization is performed before credentials are verified.
Servers associated with SNMP entities using the Secure Shell Transport Model MUST default to providing access to the 'snmp' SSH Subsystem if the SSH session is established using the IANA-assigned TCP ports (5161 and 5162).
SSH MUST NOT be configured to skip public-key verification for use with the SSH Transport Model, as doing so leaves data confidentiality and integrity protection of dubious value when an attacker can insert himself between client and server.
SSH MUST NOT be configured using the 'none' MAC algorithm for use with the SSH Transport Model; disabling data integrity while maintaining confidentiality allows an attacker to modify data in flight, effectively eliminating authentication.
The SnmpSSHAddress and tmSecurityName associated with an SSH session MUST remain constant during the life of the session. Messages MUST NOT be sent through an existing SSH session established using a different tmSecurityName.
The SSH Transport Model MUST NOT be used with an SSH connection using the 'none' userauth method. Confidentiality and integrity MUST NOT be turned off when used with the SSH Transport Model.
The tmSecurityName MUST be a human-readable name in snmpAdminString format and MUST be constant for all traffic passing through an SSHTM session.
The tmSessionID MUST be recorded per message at the time of receipt and MUST uniquely identify the session over which the message was received; this session identifier MUST NOT be reused until there are no references to it remaining.
The transportAddress associated with a session MUST remain constant during the lifetime of the SSH session; on the server side, the tmTransportAddress set from the first incoming message MUST remain constant for all subsequent messages.
An SSH Subsystem of type 'snmp' is opened by the SSH Transport Model. The client invokes the SSH connection protocol to open a 'session' channel type and then requests 'snmp' as the SSH Subsystem; failures at either step cause the transport connection to be closed and appropriate counters to be incremented.
SSH sessions in the SSH Transport Model are uniquely identified by the combination of tmTransportAddress and tmSecurityName. The SnmpSSHAddress Textual Convention supports a 'user@hostname:port' syntax; if a 'user@' prefix is present, that user name is used for SSH authentication; otherwise tmSecurityName is used.
The SSH Transport Model (SSHTM) sits between the SSH transport layer and the SNMP Message Dispatcher, translating SSH-specific security parameters into SNMP model-independent parameters. It establishes an SSH channel carrying SNMP messages between two SNMP engines, with multiple SNMP messages MAY be passed through the same channel.
The tmStateReference cache carries: tmTransportDomain (snmpSSHDomain), tmTransportAddress, tmSecurityName, tmTransportSecurityLevel (always 'authPriv'), and tmSessionID. It is created upon receipt of an incoming message and referenced during outgoing message processing.
IANA assigned TCP port 5161 ('snmpssh') for SNMP-over-SSH and port 5162 ('snmpssh-trap') for SNMP-over-SSH notifications. SMI number 189 under mib-2 and SMI number 7 under snmpDomains (snmpSSHDomain) were also assigned. 'ssh' was registered as the snmpSSHDomain prefix in the SNMP Transport Domains registry, and 'snmp' was registered as a Connection Protocol Subsystem Name in the SSH Protocol Parameters registry.
The SNMP-SSH-TM-MIB (OID mib-2 189) defines the snmpSSHDomain object identity (snmpDomains 7), the SnmpSSHAddress Textual Convention, and the snmpSshtmSession group containing eight Counter32 objects: SessionOpens, SessionCloses, SessionOpenErrors, SessionUserAuthFailures, SessionNoChannels, SessionNoSubsystems, SessionNoSessions, and SessionInvalidCaches.
Notification authorization is performed before the SSH connection to the receiver is established and before the receiver's credentials are verified, so the locally configured securityName is entirely trusted within the notification originator. The receiver's credentials MUST be cryptographically verified when the connection is made.
Session statistics in the snmpSshtmSession MIB group can reveal the configured capabilities of a remote SSH server, which could help an attacker focus an attack. Even read-only access to these objects should be controlled, and their values should be encrypted when transmitted via SNMP.
The SSH Transport Model has no mechanism to verify that server authentication was performed or that the correct host public key is being used; it trusts that these are properly configured by the implementer and deployer. Skipping public-key verification leaves data protection of dubious value against a man-in-the-middle attacker.
When SNMPv1 or SNMPv2c message processing is used (RFC 3584), the security model derives securityName and securityLevel from the SNMP message contents rather than from the authenticated SSH identity, effectively bypassing the security benefits of the SSH Transport Model.
For outgoing messages, the SSH Transport Model selects a session by: (A) if tmSameSecurity is true, require matching tmSessionID/tmSecurityName/tmTransportAddress or discard; (B) match on tmSessionID+tmTransportAddress+tmSecurityName; (C) match on tmTransportAddress+tmSecurityName; (D) call openSession(). Invalid tmStateReference increments snmpSshtmSessionInvalidCaches.
Session establishment transitions: (1) openSession increments snmpSshtmSessionOpens; (2) SSH transport connection and server authentication — failure increments snmpSshtmSessionOpenErrors; (3) SSH user authentication — failure increments snmpSshtmSessionUserAuthFailures and closes transport; (4) open 'session' channel — failure increments snmpSshtmSessionNoChannels; (5) invoke 'snmp' subsystem — failure increments snmpSshtmSessionNoSubsystems; (6) session ready, record tmSessionID.
The SnmpSSHAddress Textual Convention is an OCTET STRING of SIZE 1..255, encoding an optional 'user@' UTF-8 prefix, followed by a hostname (US-ASCII/IDNA) or IPv4 dotted-decimal or bracket-enclosed IPv6 address, followed by ':' and a decimal port number in US-ASCII.