RFC 5592
Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) 🦋
Okay bestie, this is RFC 5592 ✨ It's a Standards Track doc from the Network Working Group, published June 2009. Three authors wrote it: D. Harrington from Huawei Technologies (USA), J. Salowey from Cisco Systems, and W. Hardaker from Cobham Analytic Solutions 💅 The title block doesn't list anything it obsoletes or updates.
Status of This Memo 🌸
Okay so this doc is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements 💬 If you want to know where this protocol stands in standardization, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 🫶
Copyright Notice 🎀
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Read those carefully, because they spell out your rights and restrictions for this doc 📜
Heads up on this one: the doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈
Abstract 🍓
This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.
It also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. Specifically, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP 🧚
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. The Internet-Standard Management Framework .................3
1.2. Conventions ................................................3
1.3. Modularity .................................................5
1.4. Motivation .................................................5
1.5. Constraints ................................................6
2. The Secure Shell Protocol .......................................7
3. How SSHTM Fits into the Transport Subsystem .....................8
3.1. Security Capabilities of this Model ........................8
3.1.1. Threats .............................................8
3.1.2. Message Authentication ..............................9
3.1.3. Authentication Protocol Support ....................10
3.1.4. SSH Subsystem ......................................11
3.2. Security Parameter Passing ................................12
3.3. Notifications and Proxy ...................................12
4. Cached Information and References ..............................13
4.1. Secure Shell Transport Model Cached Information ...........13
4.1.1. tmSecurityName .....................................13
4.1.2. tmSessionID ........................................14
4.1.3. Session State ......................................14
5. Elements of Procedure ..........................................14
5.1. Procedures for an Incoming Message ........................15
5.2. Procedures for Sending an Outgoing Message ................17
5.3. Establishing a Session ....................................18
5.4. Closing a Session .........................................20
6. MIB Module Overview ............................................21
6.1. Structure of the MIB Module ...............................21
6.2. Textual Conventions .......................................21
6.3. Relationship to Other MIB Modules .........................21
6.3.1. MIB Modules Required for IMPORTS ...................21
7. MIB Module Definition ..........................................22
8. Operational Considerations .....................................29
9. Security Considerations ........................................30
9.1. Skipping Public Key Verification ..........................31
9.2. Notification Authorization Considerations .................31
9.3. SSH User and Key Selection ................................31
9.4. Conceptual Differences between USM and SSHTM ..............31
9.5. The 'none' MAC Algorithm ..................................32
9.6. Use with SNMPv1/v2c Messages ..............................32
9.7. MIB Module Security .......................................32
10. IANA Considerations ...........................................33
11. Acknowledgments ...............................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................351. Introduction ✨
So this memo describes a Transport Model for the Simple Network Management Protocol. It runs over the Secure Shell (SSH) protocol [RFC4251] inside a Transport Subsystem [RFC5590]. The model is called the Secure Shell Transport Model (SSHTM) 🔥
This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. The main point is that it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP 👑
It's really important to get the SNMP architecture [RFC3411] and its terminology down first. That's how you'll see where this Transport Model lives in the architecture and how it talks to the other subsystems 🧚
1.1. The Internet-Standard Management Framework 🌈
If you want the full tour of the documents that make up the current Internet-Standard Management Framework, go check section 7 of RFC 3410 [RFC3410] 🫶
Managed objects get accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). The objects in the MIB are defined using the mechanisms from the Structure of Management Information (SMI). This memo specifies a MIB module that's compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 💅
1.2. Conventions 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the capital-letter words you'll see doing the heavy lifting 🔥
Lowercase versions of those keywords should be read as normal English 🙈 They'll usually, but not always, show up in a context about compatibility with the RFC 3411 architecture or the subsystem defined here. They might have no effect on on-the-wire compatibility at all. These terms are guidance for designers of proposed IETF models, meant to keep their designs compatible with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to do things differently, and some uses of the lowercase words are just regular English 🌸
For consistency with SNMP-related specs, this document goes with the terminology defined in STD 62, instead of terms that match non-SNMP specs. That matches the IESG's decision not to make SNMPv3 terminology change to match non-SNMP specs when SNMPv3 advanced to Full Standard 🎀
"Authentication" in this document usually means the everyday meaning of "serving to prove the authenticity of" the message. It does not mean data source authentication or peer identity authentication 🧐
The terms "manager" and "agent" aren't used here 🙅♀️ Under the RFC 3411 architecture, every SNMP entity can act as a manager, an agent, or both, depending on which SNMP application types its implementation supports. When you need to make a distinction, the document uses the application names: command generator, command responder, notification originator, notification receiver, and proxy forwarder. For more, see "SNMP Applications" [RFC3413] 📜
The User-based Security Model (USM) [RFC3414] is a mandatory-to-implement Security Model in STD 62. SSH and USM specs often talk about a "user", but [RFC3411] and this memo prefer the word "principal" 💖 A principal is the "who" on whose behalf services get provided or processing happens. A principal can be, among other things, an individual in a particular role, a set of individuals each in a particular role, an application or set of applications, or some combo of these within an administrative domain 👑
Throughout this document, "client" and "server" refer to the two ends of the SSH transport connection. The client actively opens the SSH connection, and the server passively listens for the incoming one. Either SNMP entity can be the client or the server, as discussed further below 🦋
1.3. Modularity 🧚
You're expected to have read and understood the SNMP architecture description in [RFC3411], plus the Transport Subsystem architecture extension in "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590]. Those are the foundations 🌈
This memo describes the Secure Shell Transport Model for SNMP, a specific SNMP Transport Model that runs inside the SNMP Transport Subsystem. Its job is to provide authentication, encryption, and integrity checking of SNMP messages 🔥
Following the RFC 3411 design choice to use self-contained documents, this document defines the elements of procedure and the associated MIB module objects needed to process the Secure Shell Transport Model for SNMP ✨
And just so we're clear, this modular setup doesn't mean imposing any specific requirements on implementation 💅
1.4. Motivation
okay so SNMPv3 finally added security to the protocol 🔒✨ and the User-based Security Model (USM) [RFC3414] was built to be totally independent of other security systems, so it could still work when third-party authentication services were down, like in a broken network 🫠. the tradeoff is that USM runs its own separate user and key-management setup. operators have said that having to deploy another user and key-management system just to use SNMPv3 is a reason they don't deploy SNMPv3 at all 💀. big mood, honestly.
so this memo describes a Transport Model that plugs into the Secure Shell security infrastructure people already run everywhere 🧚. the goal is to meet what network admins actually need for security and operations, make it easy to deploy successfully, and keep implementation and deployment costs low so rollouts don't take forever 🎀.
this document covers the requirement that the SSH client authenticates the SSH server, and that the SSH server authenticates the SSH client 🤝. it also explains how SNMP can use those authenticated identities in authorization policies for data access, and it does this in a way that doesn't depend on any specific Access Control Model 💅.
it also covers the requirement to support client-authentication and key-exchange methods from different security infrastructures, each with different security properties 🌈. the client authentication part follows "The Secure Shell (SSH) Authentication Protocol" [RFC4252]. the SSH Transport Model should work with any of the ssh-userauth methods, including publickey, password, hostbased, none, keyboard-interactive, gssapi-with-mic, ."gssapi-keyex", gssapi, and external-keyx (check the SSH Protocol Parameters registry that IANA maintains for the full list) 📋. the none method is NOT RECOMMENDED, and the Security Considerations section of this document explains why 🙈. local accounts can be supported with the publickey, hostbased, or password methods 🔑. the password method also lets you plug into a password infrastructure that's already deployed, like Authentication, Authorization, and Accounting (AAA) servers that speak the RADIUS protocol [RFC2865] 🧁. and the SSH Transport Model SHOULD be able to take advantage of ssh-userauth methods defined in the future, like ones that might use X.509 certificate credentials 🔮.
unifying the admin security story is a big deal too. ideally SNMPv3, the command line interface (CLI), and other management interfaces all share one approach 🫶. Secure Shell's security services are already what the CLI uses, and they're the approach being adopted for NETCONF [RFC4742] 👑. so this memo describes how to invoke and run SNMP inside a Secure Shell (SSH) session as an SSH Subsystem 🦋.
more specifically, this memo describes how SNMP runs inside an SSH session, using the SSH connection protocol [RFC4254] on top of the SSH transport protocol, with ssh-userauth [RFC4252] for authentication 💜.
there are a bunch of challenges to solve when mapping Secure Shell authentication method parameters into the SNMP architecture, so SNMP keeps working without any surprises 😭. we'll go through them in detail below.
1.5. Constraints
the design of this SNMP Transport Model is shaped by these constraints 📏:
- in times of network stress, the transport protocol and its underlying security mechanisms SHOULD NOT depend on other network services being readily available (for example, Network Time Protocol (NTP) or AAA protocols) ⏰.
- when the network isn't under stress, the Transport Model and its underlying security mechanisms MAY depend on other network services being readily available 🌤️.
- it may not be possible for the Transport Model to figure out when the network is under stress 🤷♀️.
- a Transport Model SHOULD NOT require changes to the SNMP architecture 🏗️.
- a Transport Model SHOULD NOT require changes to the underlying security protocol 🔐.
2. The Secure Shell Protocol
SSH is a protocol for secure remote login and other secure network services over an insecure network 🐚✨. it's made of three major protocol components, plus add-on methods for user authentication 💅:
- The Transport Layer Protocol [RFC4253] provides server authentication and message confidentiality and integrity. it may optionally provide compression too 🗜️. the transport layer will typically run over a TCP/IP connection, but it could also sit on top of any other reliable data stream 🌊.
- The User Authentication Protocol [RFC4252] authenticates the client-side principal to the server. it runs over the Transport Layer Protocol 🪪.
- The Connection Protocol [RFC4254] multiplexes the encrypted tunnel into several logical channels. it runs over the transport after the principal has been authenticated successfully 🎀.
- Generic Message Exchange Authentication [RFC4256] is a general-purpose authentication method for SSH. it's good for interactive authentication where the auth data gets typed in on a keyboard ⌨️.
- "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol" [RFC4462] describes ways to use GSS-API for authentication and key exchange in SSH 🔑🔥. it defines an SSH user-authentication method that uses a specified GSS-API mechanism to authenticate a user, and it also defines a family of SSH key-exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange 🧠.
the client sends a service request once a secure, transport-layer connection is established 📨. then a second service request goes out after client authentication is complete 🎟️. this is what lets new protocols get defined and coexist with the ones listed above 🦄.
the connection protocol gives you channels for all kinds of purposes 🌈. it has standard methods for setting up secure interactive shell sessions and for forwarding ("tunneling") arbitrary TCP/IP ports and X11 connections 🖥️✨.
3. How SSHTM Fits into the Transport Subsystem
okay the big picture 🗺️: a Transport Model is a component of the Transport Subsystem [RFC5590] inside the SNMP architecture 🧩. so the SSH Transport Model sits between the underlying SSH transport layer and the Message Dispatcher [RFC3411] 💖.
the SSH Transport Model sets up a channel between itself and the SSH Transport Model of another SNMP engine 🛤️. the sending Transport Model takes unencrypted messages from the Dispatcher and passes them to SSH to get encrypted 🔒. the receiving Transport Model takes decrypted incoming messages from SSH and hands them to the Dispatcher 📬.
once an SSH Transport Model channel exists, SNMP messages can conceptually travel through it from one SNMP Message Dispatcher to another SNMP Message Dispatcher 🚀. multiple SNMP messages MAY go through the same channel 🫧.
the SSH Transport Model of an SNMP engine does the translating between SSH-specific security parameters and SNMP-specific, model-independent parameters 🔄💅.
3.1. Security Capabilities of this Model
3.1.1. Threats
the Secure Shell Transport Model protects against the threats listed in the RFC 3411 architecture [RFC3411] 🛡️. let's go through them bestie 🫶:
- Modification of Information: SSH checks that the contents of each message weren't changed while they were in transit across the network, because each SSH packet is digitally signed 🖊️✅.
- Masquerade: SSH verifies who's who. both the identity of the SSH server and the identity of the SSH client get checked 🕵️♀️.
SSH verifies the SSH server's identity through SSH transport protocol server authentication [RFC4253]. this lets an operator or management station make sure the SNMP engine providing the MIB data is the real deal 🏆.
SSH has several mechanisms for verifying the SSH client-side principal's identity, using the Secure Shell Authentication Protocol [RFC4252]. these include public key, password, and host-based mechanisms 🔑. this lets the SNMP Access Control Subsystem make sure only authorized principals can reach potentially sensitive data 🚫.
verifying the client's principal identity matters a lot for the SNMP Access Control Subsystem, because it's how you make sure only authorized principals get to see potentially sensitive data 👀.
the SSH user identity is handed to the Transport Model, so it can be mapped to a model-independent SNMP securityName, which is used for SNMP access control and notification configuration 🗝️. (the identity may go through various transforms before it maps to the securityName 🔁.)
- Message Stream Modification: SSH guards against malicious re-ordering or replaying of messages within a single SSH session by using sequence numbers and integrity checks 🔢. it also protects against replay of messages across SSH sessions, because the cryptographic keys used for encryption and integrity checks are generated afresh for each session 🔄✨.
- Disclosure: SSH keeps information away from unauthorized recipients and eavesdroppers by encrypting all traffic between SNMP engines 🤫🔐.
3.1.2. Message Authentication ✨
okay so the RFC 3411 architecture recognizes three levels of security 🔐:
- without authentication and without privacy (noAuthNoPriv)
- with authentication but without privacy (authNoPriv)
- with authentication and with privacy (authPriv)
bestie, the Secure Shell protocol gives us encryption and data integrity 💖. technically you could skip authentication and encryption in SSH, but [RFC4253] says that is NOT RECOMMENDED, so please don't be that person 🙅♀️.
the SSH Transport Model figures out from SSH who the authenticated principal is, plus the type and address of an incoming message, and it hands that info back to SSH when sending an outgoing one 🦋. the SSH transport-layer algorithms that handle authentication, data integrity, and encryption SHOULD NOT be exposed up to the SSH Transport Model layer 🫶. the SNMPv3 WG deliberately avoided this and just settled for the Security Model saying the securityLevel requirements were met 💅. the SSH Transport Model has no way to test whether an underlying SSH connection really gives auth or priv, so it trusts that the connection was configured properly for authPriv 🎀.
ngl this is the big one: an SSH Transport-Model-compliant implementation MUST use an SSH connection that provides authentication, data integrity, and encryption at the highest SNMP security level (authPriv) 👑. outgoing messages marked noAuthNoPriv or authNoPriv still get sent with authPriv-level protection, so no shortcuts 😭.
the security protocols in the Secure Shell Authentication Protocol [RFC4252] and the Secure Shell Transport Layer Protocol [RFC4253] are considered acceptably secure at the time of writing 🌈. the procedures do leave room for new authentication and privacy methods to be specified later if the need comes up ✨.
3.1.3. Authentication Protocol Support 🧚
the SSH Transport Model SHOULD support any server- or client-authentication mechanism that SSH supports 💜. that includes the three methods in the SSH Authentication Protocol document [RFC4252] (publickey, password, and host-based), plus keyboard interactive, and others 🍓.
the password-authentication mechanism lets you plug into password infrastructure that's already deployed 🌸. you can hand a password off to a service like RADIUS [RFC2865] or Diameter [RFC3588] for validation. that validation could use the user name and user password attributes. you could also use a different password-validation protocol, like the Challenge Handshake Authentication Protocol (CHAP) [RFC1994] or digest authentication [RFC5090], to work with RADIUS or Diameter 🦋. heads up though 🙈: at some point these mechanisms need the password available as cleartext on the device doing the authenticating, which might introduce threats to the authentication infrastructure 💀.
GSS-API key exchange [RFC4462] gives you a framework for adding client-authentication mechanisms that work with different security infrastructures and offer different security properties 🔥. additional mechanisms, like one that supports X.509 certificates, may be added to SSH in the future 👑.
3.1.4. SSH Subsystem 🎀
this document uses an SSH Subsystem for SNMP so that SNMP usage stays distinct from other usages 💖.
an SSH Subsystem of type "snmp" gets opened by the SSH Transport Model during the elements of procedure for an outgoing SNMP message ✨. the sender of a message starts the SSH session if one is needed, so for an incoming message the SSH session will already exist. otherwise the incoming message would never reach the SSH Transport Model 🫶.
implementations can choose to set up SSH sessions ahead of time, in anticipation of outgoing messages 🦋. this can help make sure an SSH session to a given target can be established before it's actually needed to send a message 💅. of course, there's no guarantee a pre-established session will still be valid when you need it 😭.
SSH sessions are uniquely identified within the SSH Transport Model by the combination of tmTransportAddress and tmSecurityName for each session 🌈.
because naming policies can differ between administrative domains, lots of SSH client packages support a user@hostname:port addressing syntax that operators can use to line up non-equivalent account names 🍓. the SnmpSSHAddress Textual Convention echoes this common SSH notation 🧚.
when this notation is used in an SnmpSSHAddress, the SSH connection should be established with an SSH user name matching the "user" portion of the notation when setting up a session with the remote SSH server 💜. the user name must be encoded in UTF-8 (per [RFC4252]) 🌸. the "user" portion may or may not match the tmSecurityName parameter passed from the Security Model 🤷♀️. if no "user@" portion is specified in the SnmpSSHAddress, then the SSH connection should use the tmSecurityName as the SSH user name when setting up a session with the remote SSH server 🎀.
the SnmpSSHAddress and tmSecurityName associated with an SSH session MUST remain constant for the life of the session 👑. different SnmpSSHAddress values (with different hostnames, "user@" prefix names, and/or port numbers) each get their own individual SSH session 🦋.
3.2. Security Parameter Passing 💅
for incoming messages, the Transport Model translates SSH-specific security parameters into security parameters that don't depend on the Transport and Security Models 🫶. the Transport Model accepts messages from the SSH Subsystem, records the transport-related and SSH-security-related info (including the authenticated identity) in a cache referenced by tmStateReference ✨, and then passes the WholeMsg and the tmStateReference to the Dispatcher using the receiveMessage() ASI (Abstract Service Interface) 🌈.
for outgoing messages, the Transport Model takes the input the Dispatcher gives it in the sendMessage() ASI 💜. the SSH Transport Model turns that into suitable security parameters for SSH, sets up sessions as needed, and passes messages to the SSH Subsystem for sending 🧚.
3.3. Notifications and Proxy 🔥
SSH connections can be started by command generators or by notification originators 🌸. command generators are often run by a human, but notification originators are usually unmanned automated processes 🤖. so it may be necessary to provision authentication credentials on the SNMP engine that holds the notification originator, or to use a third-party key provider like Kerberos, so the engine can successfully authenticate to an engine holding a notification receiver 🎀.
the targets that notifications or proxy requests get sent to are usually decided and configured by a network administrator 👑. the SNMP-NOTIFICATION-MIB has a list of targets that notifications should go to 🦋. the SNMP-TARGET-MIB module [RFC3413] has objects for defining these management targets, including transport domains, addresses, and security parameters, for things like notification generators and proxy forwarders 💖.
for the SSH Transport Model, the transport type and address are configured in the snmpTargetAddrTable, and the securityName and securityLevel parameters are configured in the snmpTargetParamsTable 💅. the default approach is for an administrator to statically preconfigure this info so it identifies the targets allowed to receive notifications or proxied messages 🫶. local access-control processing has to happen at the notification originator before notifications actually get sent, and that processing uses the configured securityName 🔐. the important thing here is that authorization happens before figuring out whether the connection can succeed 😤. so the locally configured securityName is entirely trusted within the notification originator 🌈.
the SNMP-TARGET-MIB and NOTIFICATION-MIB MIB modules may be configured using SNMP or other implementation-dependent mechanisms, like CLI scripting or loading a configuration file 🧚. it may be necessary to provide additional implementation-specific configuration of SSH parameters too ✨.
4. Cached Information and References 📦
when performing SNMP processing, there are two levels of state information that may need to be kept: the immediate state linking a request-response pair, and a potentially longer-term state relating to transport and security 🦋. "Transport Subsystem for the Simple Network Management Protocol" [RFC5590] defines general requirements for caches and references 💜.
this document defines additional cache requirements related to the Secure Shell Transport Model 🫶.
4.1. Secure Shell Transport Model Cached Information 🎀
the Secure Shell Transport Model has specific responsibilities when it comes to cached information 💅. see the Elements of Procedure in Section 5 for detailed processing instructions on how the SSH Transport Model uses the tmStateReference fields 🌸.
4.1.1. tmSecurityName 🔑
the tmSecurityName MUST be a human-readable name (in snmpAdminString format) representing the identity that has been set according to the procedures in Section 5 💖. the tmSecurityName MUST be constant for all traffic passing through an SSHTM session 👑. messages MUST NOT be sent through an existing SSH session that was established using a different tmSecurityName 😭.
on the SSH server side of a connection 🖥️:
the tmSecurityName should be the SSH user name. how the SSH user name gets extracted from the SSH layer is implementation-dependent 🧚.
the SSH protocol isn't always clear on whether the user name field must be filled in, so for some implementations, like those using GSSAPI authentication, it may be necessary to use a mapping algorithm to turn an SSH identity into a tmSecurityName, or a tmSecurityName into an SSH identity 🌈.
in other cases the user name may not be verified by the server, so for these implementations it may be necessary to get the user name from other credentials exchanged during the SSH exchange 🙈.
on the SSH client side of a connection 💻:
the tmSecurityName is presented to the SSH Transport Model by the application (possibly because of configuration specified in the SNMP-TARGET-MIB) 🦋.
the securityName MAY be derived from the tmSecurityName by a Security Model, and MAY be used to configure notifications and access controls in MIB modules 🌸. Transport Models SHOULD generate a predictable tmSecurityName so operators know what to use when configuring MIB modules that use securityNames derived from tmSecurityNames 💜.
4.1.2. tmSessionID 🪪
the tmSessionID MUST be recorded per message at the time of receipt 📝. when tmSameSecurity is set, the recorded tmSessionID can be used to determine whether the SSH session available for sending a corresponding outgoing message is the same SSH session that was used when receiving the incoming message (e.g., a response to a request) 🎀.
4.1.3. Session State 🌷
the per-session state referenced by tmStateReference may be saved across multiple messages in a Local Configuration Datastore 💖. additional session/connection state information might also be stored in a Local Configuration Datastore too ✨.
5. Elements of Procedure ✨
Okay so the Abstract Service Interfaces (ASIs) were defined by [RFC3411] and then glammed up even more by [RFC5590] 💅. They describe the conceptual data flows between the subsystems inside an SNMP entity, and the Secure Shell Transport Model uses some of those flows when it talks to the other subsystems. Iconic teamwork 🫶
To keep the steps from getting too long, the release of state information isn't always spelled out. The general rule is: if state information exists when a message gets discarded, the message-state information should also be released. And if state information exists when a session closes, the session-state information should also be released. 🧹✨
An error indication in statusInformation will typically include the Object Identifier (OID) and value for an incremented error counter 🔢. It may also come with the requested securityLevel and the tmStateReference. Per-message context info isn't accessible to Transport Models, though, so for the returned counter OID and value, contextEngine gets set to the local value of snmpEngineID and contextName gets set to the default context for error counters. Not me having to dig through context info 🙈
5.1. Procedures for an Incoming Message
- The SSH Transport Model asks the SSH engine, in an implementation-dependent manner, to figure out three things: the address the message originated from, the user name SSH authenticated, and a session identifier 🕵️♀️
- Determine the tmTransportAddress for the incoming message:
- A. If this is a client-side SSH session, then the tmTransportAddress is set to the tmTransportAddress used to establish the session. It MUST exactly include any "user@" prefix associated with the address provided to the openSession() ASI. 🎀
- B. If this is a server-side SSH session and this is the first message received over the session, then the tmTransportAddress is set to the address the message originated from, determined in an implementation-dependent way. This value MUST be constant for the entire SSH session, and future messages received MUST result in the tmTransportAddress being set to the same value. 🦋
- C. If this is a server-side SSH session and this is not the first message received over the session, then the tmTransportAddress is set to the previously established tmTransportAddress for the session (the value from step B, determined from a previous incoming message). 🌸
- Determine the tmSecurityName for the incoming message:
- A. If this is a client-side SSH session, then the tmSecurityName MUST be set to the tmSecurityName used to establish the session. 💜
- B. If this is a server-side SSH session and this is the first message received over the session, then the tmSecurityName is set to the SSH user name. How the SSH user name gets extracted from the SSH layer is implementation-dependent. This value MUST be constant for the entire SSH session, and future messages received MUST result in the tmSecurityName being set to the same value. 🔐
- C. If this is a server-side SSH session and this is not the first message received over the session, then the tmSecurityName is set to the previously established tmSecurityName for the session (the value from step B, determined from a previous incoming message). 🧚
- Create a tmStateReference cache so you can reference this info later. It looks like this:
tmTransportDomain = snmpSSHDomain
tmTransportAddress = the derived tmTransportAddress from step
2.
tmSecurityName = the derived tmSecurityName from step 3.
tmTransportSecurityLevel = "authPriv" (authentication and
confidentiality MUST be used to comply with this Transport
Model.)
tmSessionID = an implementation-dependent value that can be
used to detect when a session has closed and been replaced by
another session. The value in tmStateReference 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.Then the Transport Model passes the message to the Dispatcher using this ASI:
statusInformation =
receiveMessage(
IN transportDomain -- snmpSSHDomain
IN transportAddress -- the tmTransportAddress for the message
IN wholeMessage -- the whole SNMP message from SSH
IN wholeMessageLength -- the length of the SNMP message
IN tmStateReference -- (NEW) transport info
)5.2. Procedures for Sending an Outgoing Message
The Dispatcher hands the information over to the Transport Model using the ASI defined in the Transport Subsystem 📤
statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length
IN tmStateReference -- (NEW) transport info
)The SSH Transport Model performs the following tasks 💅
- If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity, then increment the
snmpSshtmSessionInvalidCachescounter, discard the message, and return the error indication in the statusInformation. Processing of this message stops. 🚫 - Extract the tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and tmSessionID from the tmStateReference. 🔍
- Identify an SSH session over which to send the messages:
- A. If tmSameSecurity is true and there is no existing session with a matching tmSessionID, tmSecurityName, and tmTransportAddress, then increment the
snmpSshtmSessionNoSessionscounter, discard the message, and return the error indication in the statusInformation. Processing of this message stops. 🙅♀️ - B. If there is a session with a matching tmSessionID, tmTransportAddress, and tmSecurityName, then select that session. 💖
- C. If there is a session that matches the tmTransportAddress and tmSecurityName, then select that session. 🌈
- D. If the above steps failed to select a session to use, then call openSession() with the tmStateReference as a parameter.
- If openSession fails, then discard the message, release tmStateReference, and pass the error indication returned by openSession back to the calling module. Processing of this message stops. 💀
- If openSession succeeds, then record the destTransportDomain, destTransportAddress, tmSecurityname, and tmSessionID in an implementation-dependent manner. This will be needed when processing an incoming message. 📝
- A. If tmSameSecurity is true and there is no existing session with a matching tmSessionID, tmSecurityName, and tmTransportAddress, then increment the
- Pass the wholeMessage to SSH for encapsulation as data in an SSH message over the identified SSH session. Any necessary additional SSH-specific parameters should be provided in an implementation-dependent manner. 🧁
5.3. Establishing a Session ✨
Okay bestie, this is the ASI 💅 that the Secure Shell Transport Model uses to describe the data passed between the SSH Transport Model and the SSH service. How that data actually gets passed is an implementation decision, so it's up to whoever builds it 🫶
statusInformation =
openSession(
IN tmStateReference -- transport information to be used
OUT tmStateReference -- transport information to be used
IN maxMessageSize -- of the sending SNMP entity
)Now the procedure for setting up a session between a client and a server so SNMP can run over SSH 🦋 Any SNMP engine that's opening a session for later use follows this, and it happens automatically for any SNMP app that starts a transaction, like a command generator, a notification originator, or a proxy forwarder. It's giving main character energy 👑
- Increment the
snmpSshtmSessionOpenscounter 🌸 - Using
tmTransportAddress, the client sets up an SSH transport connection through the SSH transport protocol, authenticates the server, and exchanges keys for message integrity and encryption 🔐 ThetransportAddresstied to a session MUST remain constant for the whole life of the SSH session. Implementations may need to cache thetransportAddresspassed to theopenSessionAPI so they can use it later when processing incoming messages (see Section 5.1) ✨- To authenticate the server, the client usually stores pairs of (
tmTransportAddress, server host public key) in an implementation-dependent way. - The other parameters of the transport connection are provided in an implementation-dependent way.
- If the connection attempt fails or server-authentication fails,
snmpSshtmSessionOpenErrorsgets incremented, anopenSessionerror indication is returned, andopenSessionprocessing stops 😭
- To authenticate the server, the client usually stores pairs of (
- Next, the client invokes an SSH authentication service to authenticate the principal, like the one described in the SSH authentication protocol [RFC4252] 🎀
- If
tmTransportAddresshas a user name followed by an'@'character (US-ASCII 0x40), that user name string should be presented to the SSH server as the "user name" for user-authentication purposes. If there's no user name intmTransportAddress, thentmSecurityNameshould be used as the user name. - The credentials used to authenticate the SSH principal are figured out in an implementation-dependent way.
- In an implementation-specific way, invoke the SSH user-authentication service using the calculated user name.
- If user authentication fails, the transport connection gets closed,
snmpSshtmSessionUserAuthFailuresis incremented, an error indication is returned to the calling module, and processing stops for this message 💀
- If
- The client should invoke the "ssh-connection" service (also known as the SSH connection protocol [RFC4254]) and request a channel of type "session". If that's unsuccessful, the transport connection is closed,
snmpSshtmSessionNoChannelsis incremented, an error indication goes back to the calling module, and processing stops for this message 🙈 - The client invokes "snmp" as an SSH Subsystem, as indicated in the "subsystem" parameter. If that's unsuccessful, the transport connection is closed,
snmpSshtmSessionNoSubsystemsis incremented, an error indication goes back to the calling module, and processing stops for this message 🧚
Okay, this part is important 🔥 In order to let SNMP traffic be easily identified and filtered by firewalls and other network devices, 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). Servers SHOULD be configurable to allow access to the SNMP SSH Subsystem over other ports.
- Set
tmSessionIDin thetmStateReferencecache to an implementation-dependent value that identifies the session 🍓 - The
tmSecurityNameused to establish the SSH session must be the onlytmSecurityNameused with the session. Incoming messages for the session MUST be associated with thistmSecurityNamevalue. How that's accomplished is implementation-dependent 💜
5.4. Closing a Session
Time to wrap things up 🌈 The Secure Shell Transport Model provides the following ASI to close a session:
statusInformation =
closeSession(
IN tmSessionID -- session ID of session to be closed
)This is the procedure any SNMP engine follows to close an SSH session between a client and a server. When a session should be closed is implementation-dependent, and the calling code should release the associated tmStateReference 🦋
- Increment the
snmpSshtmSessionClosescounter 🌸 - If there is no session corresponding to
tmSessionID, thencloseSessionprocessing is complete ✨ - Have SSH close the session associated with
tmSessionID👑
6. MIB Module Overview 🧚
This MIB module is all about managing the Secure Shell Transport Model 💖 It defines an OID to identify the SNMP-over-SSH transport domain, a Textual Convention for SSH Addresses, and several statistics counters.
6.1. Structure of the MIB Module
Objects in this MIB module are sorted into subtrees 🫶 Each subtree is a set of related objects. The overall structure, which objects go into which subtree, and what each subtree is for is meant to be shown below.
6.2. Textual Conventions
Generic and Common Textual Conventions used in this document can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html 🎀
6.3. Relationship to Other MIB Modules
Some management objects defined in other MIB modules apply to an entity implementing the SSH Transport Model 🌸 In particular, it's assumed that an entity implementing the SNMP-SSH-TM-MIB will implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK-MIB [RFC3411]. It's also expected that an entity implementing this MIB will support the Transport Security Model [RFC5591] and, therefore, implement the SNMP-TSM-MIB 💅
This MIB module is for monitoring SSH Transport Model information 👀
6.3.1. MIB Modules Required for IMPORTS
The following MIB module imports items from [RFC2578], [RFC2579], and [RFC2580] 🍓
This MIB module also references [RFC1033], [RFC4252], [RFC3490], and [RFC3986] 🦋
This document uses TDomain Textual Conventions for the SNMP-internal MIB modules defined here, for compatibility with the RFC 3413 MIB modules and the RFC 3411 Abstract Service Interfaces 🌈
7. MIB Module Definition
Here's the MIB module itself 🔥
SNMP-SSH-TM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY, mib-2, snmpDomains,
Counter32
FROM SNMPv2-SMI -- RFC 2578
TEXTUAL-CONVENTION
FROM SNMPv2-TC -- RFC 2579
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- RFC 2580
;
snmpSshtmMIB MODULE-IDENTITY
LAST-UPDATED "200906090000Z"
ORGANIZATION "ISMS Working Group"
CONTACT-INFO "WG-EMail: isms@lists.ietf.org
Subscribe: isms-request@lists.ietf.org
Chairs:
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
+49 6221 90511-15
quittek@netlab.nec.de
Juergen Schoenwaelder
Jacobs University Bremen
Campus Ring 1
28725 Bremen
Germany
+49 421 200-3587
j.schoenwaelder@jacobs-university.de
Co-editors:
David Harrington
Huawei Technologies USA
1700 Alma Drive
Plano Texas 75075
USA
+1 603-436-8634
ietfdbh@comcast.net
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
USA
jsalowey@cisco.com
Wes Hardaker
Cobham Analytic Solutions
P.O. Box 382
Davis, CA 95617
USA
+1 530 792 1913
ietf@hardakers.net
"
DESCRIPTION
"The Secure Shell Transport Model MIB.
Copyright (c) 2009 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
- Neither the name of Internet Society, IETF or IETF Trust,
nor the names of specific contributors, may be used to endorse
or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This version of this MIB module is part of RFC 5592;
see the RFC itself for full legal notices."
REVISION "200906090000Z"
DESCRIPTION "The initial version, published in RFC 5592."
::= { mib-2 189 }
-- ---------------------------------------------------------- --
-- subtrees in the SNMP-SSH-TM-MIB
-- ---------------------------------------------------------- --
snmpSshtmNotifications OBJECT IDENTIFIER ::= { snmpSshtmMIB 0 }
snmpSshtmObjects OBJECT IDENTIFIER ::= { snmpSshtmMIB 1 }
snmpSshtmConformance OBJECT IDENTIFIER ::= { snmpSshtmMIB 2 }
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------Okay so the actual MIB bits are next, and they're giving whole main character energy 💅🦋
snmpSSHDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP-over-SSH transport domain. The corresponding
transport address is of type SnmpSSHAddress.
When an SNMP entity uses the snmpSSHDomain Transport
Model, it must be capable of accepting messages up to
and including 8192 octets in size. Implementation of
larger values is encouraged whenever possible.
The securityName prefix to be associated with the
snmpSSHDomain is 'ssh'. This prefix may be used by Security
Models or other components to identify which secure transport
infrastructure authenticated a securityName."
::= { snmpDomains 7 }
SnmpSSHAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents either a hostname or IP address, along with a port
number and an optional user name.
The beginning of the address specification may contain a
user name followed by an '@' (US-ASCII character 0x40). This
portion of the address will indicate the user name that should
be used when authenticating to an SSH server. The user name
must be encoded in UTF-8 (per [RFC4252]). If missing, the
SNMP securityName should be used. After the optional user
name field and '@' character comes the hostname or IP
address.
The hostname is always in US-ASCII (as per RFC1033);
internationalized hostnames are encoded in US-ASCII as
specified in RFC 3490. The hostname is followed by a colon
':' (US-ASCII character 0x3A) and a decimal port number in
US-ASCII. The name SHOULD be fully qualified whenever
possible.
An IPv4 address must be in dotted decimal format followed
by a colon ':' (US-ASCII character 0x3A) and a decimal port
number in US-ASCII.
An IPv6 address must be in colon-separated format, surrounded
by square brackets ('[', US-ASCII character 0x5B, and ']',
US-ASCII character 0x5D), followed by a colon ':' (US-ASCII
character 0x3A) and a decimal port number in US-ASCII.
Values of this Textual Convention might not be directly usable
as transport-layer addressing information and may require
runtime resolution. As such, applications that write them
must be prepared for handling errors if such values are
not supported or cannot be resolved (if resolution occurs
at the time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may
have snmpSSHAddress values must fully describe how (and
when) such names are to be resolved to IP addresses and vice
versa.
This Textual Convention SHOULD NOT be used directly in
object definitions since it restricts addresses to a
specific format. However, if it is used, it MAY be used
either on its own or in conjunction with
TransportAddressType or TransportDomain as a pair.
When this Textual Convention is used as a syntax of an
index object, there may be issues with the limit of 128
sub-identifiers, which is specified in SMIv2 (STD 58). It
is RECOMMENDED that all MIB documents using this Textual
Convention make explicit any limitations on index
component lengths that management software must observe.
This may be done either by including SIZE constraints on
the index components or by specifying applicable
constraints in the conceptual row DESCRIPTION clause or
in the surrounding documentation.
"
REFERENCE
"RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE
RFC 3490: Internationalizing Domain Names in Applications
RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
RFC 4252: The Secure Shell (SSH) Authentication Protocol"
SYNTAX OCTET STRING (SIZE (1..255))Now the session counters, bestie. These are the ones that keep track of what's happening with SSH sessions 📊✨
-- The snmpSshtmSession Group
snmpSshtmSession OBJECT IDENTIFIER ::= { snmpSshtmObjects 1 }
snmpSshtmSessionOpens OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request has been
executed as an SSH client, whether it succeeded or
failed.
"
::= { snmpSshtmSession 1 }
snmpSshtmSessionCloses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times a closeSession() request has been
executed as an SSH client, whether it succeeded or
failed.
"
::= { snmpSshtmSession 2 }
snmpSshtmSessionOpenErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a transport connection or failed to
authenticate the server.
"
::= { snmpSshtmSession 3 }
snmpSshtmSessionUserAuthFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
user-authentication failures.
"
::= { snmpSshtmSession 4 }
snmpSshtmSessionNoChannels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
channel-open failures.
"
::= { snmpSshtmSession 5 }
snmpSshtmSessionNoSubsystems OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
inability to connect to the requested subsystem.
"
::= { snmpSshtmSession 6 }
snmpSshtmSessionNoSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an outgoing message was
dropped because the same session was no longer
available.
"
::= { snmpSshtmSession 7 }
snmpSshtmSessionInvalidCaches OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of outgoing messages dropped because the
tmStateReference referred to an invalid cache.
"
::= { snmpSshtmSession 8 }Last MIB bit, the conformance stuff. It's the part that says who's compliant and which groups have to be there 🎀
-- ************************************************
-- snmpSshtmMIB - Conformance Information
-- ************************************************
snmpSshtmCompliances OBJECT IDENTIFIER ::= { snmpSshtmConformance 1 }
snmpSshtmGroups OBJECT IDENTIFIER ::= { snmpSshtmConformance 2 }
-- ************************************************
-- Compliance statements
-- ************************************************
snmpSshtmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines that
support the SNMP-SSH-TM-MIB."
MODULE
MANDATORY-GROUPS { snmpSshtmGroup }
::= { snmpSshtmCompliances 1 }
-- ************************************************
-- Units of conformance
-- ************************************************
snmpSshtmGroup OBJECT-GROUP
OBJECTS {
snmpSshtmSessionOpens,
snmpSshtmSessionCloses,
snmpSshtmSessionOpenErrors,
snmpSshtmSessionUserAuthFailures,
snmpSshtmSessionNoChannels,
snmpSshtmSessionNoSubsystems,
snmpSshtmSessionNoSessions,
snmpSshtmSessionInvalidCaches
}
STATUS current
DESCRIPTION "A collection of objects for maintaining information
of an SNMP engine that implements the SNMP Secure
Shell Transport Model.
"
::= { snmpSshtmGroups 2 }
END8. Operational Considerations ✨
ngl this section is the real-life "what could go wrong" talk 🙈 The SSH Transport Model will likely not work when remote access to the CLI has stopped working. It also assumes TCP and IP keep working correctly between the two nodes. Failures in either node, a dead daemon serving the communication, routing problems in the network in between, firewalls blocking the traffic, and other problems can all stop it from working. If management access has to be super reliable, operators should consider mitigating measures, like dedicated management-only networks, point-to-point links, and the ability to use alternate protocols and transports 💜
To have SNMP properly use the security services SSH provides, the SSH Transport Model MUST be used with a Security Model that knows how to process a tmStateReference, such as the Transport Security Model for SNMP [RFC5591]. This one is a must, bestie 🫶
If the SSH Transport Model is set up to use AAA services, operators should consider configuring local authentication mechanisms, like local passwords, so SNMP can keep running during times of network stress 🌸
The SSH protocol has its own window mechanism, defined in RFC 4254. The SSH specs leave it open for when window adjustment messages should be created, and some implementations send them whenever received data has been passed to the application. Those messages have noticeable bandwidth and processing overhead, which you can avoid by sending them less often 🦋
SSH also needs CPU-intensive calculations to establish a session key during session setup. So short-lived sessions get computationally expensive compared to USM, which doesn't have a notion of a session key at all 😭 Other transport security protocols, like TLS, support session resumption, which lets them reuse a cached session key. SSH doesn't have an equivalent, so SNMP applications should keep SSH sessions open for longer periods 🧚
To start SSH connections, an entity has to be configured with SSH client credentials plus info to authenticate the server. Hosts are often set up as SSH clients, but most internetworking devices aren't. If a device needs to send notifications over SSHTM, it'll have to be configured as an SSH client. How that credential configuration gets done is implementation- and deployment-specific 🍓✨
9. Security Considerations ✨
Okay bestie, this is the MAIN CHARACTER section 💅 This memo describes a Transport Model that lets SNMP use SSH security services 🔐. The security threats, and how the SSH Transport Model mitigates them, are covered in detail all throughout this memo 🫶.
The SSH Transport Model relies on SSH mutual authentication, binding of keys, confidentiality, and integrity 💜. Any authentication method that meets the requirements of the SSH architecture will provide the properties of mutual authentication and binding of keys ✨.
SSHv2 provides perfect forward secrecy (PFS) for encryption keys 🔥. PFS is a major design goal of SSH, and any well-designed key-exchange algorithm will provide it 👑.
The security implications of using SSH are covered in [RFC4251] 🧚.
The SSH Transport Model has no way to verify that server authentication was performed, to learn the host's public key in advance, or to verify that the correct key is being used 💀. It simply trusts that these are properly configured by the implementer and deployer 🙈.
SSH provides the "none" userauth method. The SSH Transport Model MUST NOT be used with an SSH connection with the "none" userauth method 😭. While SSH does support turning off confidentiality and integrity, they MUST NOT be turned off when used with the SSH Transport Model 🥺.
The SSH protocol is not always clear on whether the user name field must be filled in, so for some implementations, such as those using GSSAPI authentication, it may be necessary to use a mapping algorithm to transform an SSH identity to a tmSecurityName or to transform a tmSecurityName to an SSH identity 🎀.
In other cases, the user name may not be verified by the server, so for these implementations, it may be necessary to obtain the user name from other credentials exchanged during the SSH exchange 🌸.
9.1. Skipping Public Key Verification
Most key-exchange algorithms are able to authenticate the SSH server's identity to the client. However, for the common case of Diffie-Hellman (DH) signed by public keys, this requires the client to know the host's public key a priori and to verify that the correct key is being used 🔑. If this step is skipped, then authentication of the SSH server to the SSH client is not done. Data confidentiality and data integrity protection to the server still exist, but these are of dubious value when an attacker can insert himself between the client and the real SSH server 😬. Note that some userauth methods may defend against this situation, but many of the common ones (including password and keyboard-interactive) do not and, in fact, depend on the fact that the server's identity has been verified (so passwords are not disclosed to an attacker) 🙅♀️.
SSH MUST NOT be configured to skip public-key verification for use with the SSH Transport Model. 🚨
9.2. Notification Authorization Considerations
SNMP Notifications are authorized to be sent to a receiver based on the securityName used by the notification originator's SNMP engine 📣. This authorization is performed before the message is actually sent and before the credentials of the remote receiver have been verified. Thus, the 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 🔐.
9.3. SSH User and Key Selection
If a "user@" prefix is used within an SnmpSSHAddress value to specify an SSH user name to use for authentication, then the key presented to the remote entity MUST be the key expected by the server for the "user" 🗝️. This may be different than a locally cached key identified by the securityName value 🧐.
9.4. Conceptual Differences between USM and SSHTM
The User-based Security Model [RFC3414] employed symmetric cryptography and user-naming conventions. SSH employs an asymmetric cryptography and naming model 🪞. Unlike USM, cryptographic keys will be different on both sides of the SSH connection. Both sides are responsible for verifying that the remote entity presents the right key. The optional "user@" prefix component of the SnmpSSHAddress Textual Convention allows the client SNMP stack to associate the connection with a securityName that may be different than the SSH user name presented to the SSH server 🦋.
9.5. The 'none' MAC Algorithm
SSH provides the "none" Message Authentication Code (MAC) algorithm, which would allow you to turn off data integrity while maintaining confidentiality 🙃. However, if you do this, then an attacker may be able to modify the data in flight, which means you effectively have no authentication 💀.
SSH MUST NOT be configured using the "none" MAC algorithm for use with the SSH Transport Model. 🛑
9.6. Use with SNMPv1/v2c Messages
The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP 74) always selects the SNMPv1 or SNMPv2c Security Models, respectively. Both of these and the User-based Security Model typically used with SNMPv3 derive the securityName and securityLevel from the SNMP message received, even when the message was received over a secure transport 📨. Access control decisions are therefore made based on the contents of the SNMP message, rather than using the authenticated identity and securityLevel provided by the SSH Transport Model 🫠.
9.7. MIB Module Security
There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create 🙌. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations 🛡️.
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects, and possibly to even encrypt the values of these objects when sending them over the network via SNMP 👀. These are the tables and objects, and their sensitivity/vulnerability:
- The information in the snmpSshtmSession group is generated locally when a client session is being opened or closed. This information can reflect the configured capabilities of a remote SSH server, which could be helpful to an attacker for focusing an attack 🎯.
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec or SSH), there is still no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module 😱.
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for cryptographic mechanisms for authentication and privacy, such as those found in the User-based Security Model [RFC3414], the Transport Security Model [RFC5591], and the SSH Transport Model described in this document 🔒.
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security 🌈. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them 👑.
10. IANA Considerations
IANA has assigned:
- Two TCP port numbers in the Port Numbers registry that will be the default ports for the SNMP-over-SSH Transport Model as defined in this document, and the SNMP-over-SSH Transport Model for notifications as defined in this document. The assigned keywords and port numbers are
"snmpssh"(5161) and"snmpssh-trap"(5162) 🧁. - An SMI number (189) under mib-2, for the MIB module in this document 🍓.
- An SMI number (7) under snmpDomains, for the snmpSSHDomain 🦋.
"ssh"as the corresponding prefix for the snmpSSHDomain in the SNMP Transport Domains registry; defined in [RFC5590] 🌸."snmp"as a Connection Protocol Subsystem Name in the SSH Protocol Parameters registry ✨.
11. Acknowledgments
The editors would like to thank Jeffrey Hutzelman for sharing his SSH insights, and Dave Shield for an outstanding job wordsmithing the existing document to improve organization and clarity 🫶.
Additionally, helpful document reviews were received from Juergen Schoenwaelder 💖.
12. References
12.1. Normative References
- [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
- [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
- [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
- [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
- [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
- [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
- [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
- [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
- [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
- [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
12.2. Informative References 📚✨
okay bestie, these are the "go read this if you want the backstory" references 🧚 they aren't required to implement the spec, but they're where all the good lore lives 💅
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. 🌸
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 🎀
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 🦋
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 💜
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 🌈
[RFC4256] Cusack, F. and M. Forssen, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", RFC 4256, January 2006. 🫶
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006. 🔥
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006. ⭐
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, February 2008. 🍓
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. 👑
Authors' Addresses 💖
these are the three legends who wrote this 🫶 if you have questions, you know where to find them 🙈
David Harrington
Huawei Technologies (USA)
1700 Alma Dr. Suite 100
Plano, TX 75075
USA
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
USA
EMail: jsalowey@cisco.com
Wes Hardaker
Cobham Analytic Solutions
P.O. Box 382
Davis, CA 95617
US
Phone: +1 530 792 1913
EMail: ietf@hardakers.netthe end, and honestly what a ride 🌈💅✨
📦 where this page comes from
- ietf: rfc5592 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms