idnits 2.17.1 draft-ietf-isms-secshell-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2009) is 5471 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-16 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4742 (Obsoleted by RFC 6242) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harrington 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Standards Track J. Salowey 5 Expires: October 29, 2009 Cisco Systems 6 W. Hardaker 7 Sparta, Inc. 8 April 27, 2009 10 Secure Shell Transport Model for SNMP 11 draft-ietf-isms-secshell-16 13 Status of This Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on October 29, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This memo describes a Transport Model for the Simple Network 60 Management Protocol, using the Secure Shell protocol (SSH). 62 This memo also defines a portion of the Management Information Base 63 (MIB) for use with network management protocols in TCP/IP based 64 internets. In particular it defines objects for monitoring and 65 managing the Secure Shell Transport Model for SNMP. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. The Internet-Standard Management Framework . . . . . . . . 4 71 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 75 2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 7 76 3. How SSHTM Fits into the Transport Subsystem . . . . . . . . . 8 77 3.1. Security Capabilities of this Model . . . . . . . . . . . 9 78 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 9 79 3.1.2. Message Authentication . . . . . . . . . . . . . . . . 10 80 3.1.3. Authentication Protocol Support . . . . . . . . . . . 11 81 3.1.4. SSH Subsystem . . . . . . . . . . . . . . . . . . . . 11 82 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 12 83 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 12 84 4. Cached Information and References . . . . . . . . . . . . . . 13 85 4.1. Secure Shell Transport Model Cached Information . . . . . 13 86 4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . . . 14 87 4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . . . 14 88 4.1.3. Session State . . . . . . . . . . . . . . . . . . . . 15 89 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 15 90 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 15 91 5.2. Procedures for sending an Outgoing Message . . . . . . . . 17 92 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 18 93 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 20 94 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 21 95 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 21 96 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 21 97 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 21 98 6.3.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 21 99 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 22 100 8. Operational Considerations . . . . . . . . . . . . . . . . . . 29 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 102 9.1. Skipping Public Key Verification . . . . . . . . . . . . . 30 103 9.2. Notification Authorizaton Considerations . . . . . . . . . 31 104 9.3. SSH User and Key Selection . . . . . . . . . . . . . . . . 31 105 9.4. Conceptual Differences Between USM and SSHTM . . . . . . . 31 106 9.5. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 32 107 9.6. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 32 108 9.7. MIB Module Security . . . . . . . . . . . . . . . . . . . 32 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 110 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 112 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 113 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 114 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 37 116 1. Introduction 118 This memo describes a Transport Model for the Simple Network 119 Management Protocol, using the Secure Shell protocol (SSH) [RFC4251] 120 within a transport subsystem [I-D.ietf-isms-tmsm]. The transport 121 model specified in this memo is referred to as the Secure Shell 122 Transport Model (SSHTM). 124 This memo also defines a portion of the Management Information Base 125 (MIB) for use with network management protocols in TCP/IP based 126 internets. In particular it defines objects for monitoring and 127 managing the Secure Shell Transport Model for SNMP. 129 It is important to understand the SNMP architecture [RFC3411] and the 130 terminology of the architecture to understand where the Transport 131 Model described in this memo fits into the architecture and interacts 132 with other subsystems within the architecture. 134 1.1. The Internet-Standard Management Framework 136 For a detailed overview of the documents that describe the current 137 Internet-Standard Management Framework, please refer to section 7 of 138 RFC 3410 [RFC3410]. 140 Managed objects are accessed via a virtual information store, termed 141 the Management Information Base or MIB. MIB objects are generally 142 accessed through the Simple Network Management Protocol (SNMP). 143 Objects in the MIB are defined using the mechanisms defined in the 144 Structure of Management Information (SMI). This memo specifies a MIB 145 module that is compliant to the SMIv2, which is described in STD 58, 146 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 147 [RFC2580]. 149 1.2. Conventions 151 For consistency with SNMP-related specifications, this document 152 favors terminology as defined in STD62 rather than favoring 153 terminology that is consistent with non-SNMP specifications. This is 154 consistent with the IESG decision to not require the SNMPv3 155 terminology be modified to match the usage of other non-SNMP 156 specifications when SNMPv3 was advanced to Full Standard. 158 Authentication in this document typically refers to the English 159 meaning of "serving to prove the authenticity of" the message, not 160 data source authentication or peer identity authentication. 162 The terms "manager" and "agent" are not used in this document, 163 because in the RFC 3411 architecture [RFC3411], all SNMP entities 164 have the capability of acting in either manager or agent or in both 165 roles depending on the SNMP application types supported in the 166 implementation. Where distinction is required, the application names 167 of Command Generator, Command Responder, Notification Originator, 168 Notification Receiver, and Proxy Forwarder are used. See "SNMP 169 Applications" [RFC3413] for further information. 171 Throughout this document, the terms "client" and "server" are used to 172 refer to the two ends of the SSH transport connection. The client 173 actively opens the SSH connection, and the server passively listens 174 for the incoming SSH connection. Either SNMP entity may act as 175 client or as server, as discussed further below. 177 The User-Based Security Model (USM) [RFC3414] is a mandatory-to- 178 implement Security Model in STD 62. While SSH and USM frequently 179 refer to a user, the terminology preferred in RFC3411 [RFC3411] and 180 in this memo is "principal". A principal is the "who" on whose 181 behalf services are provided or processing takes place. A principal 182 can be, among other things, an individual acting in a particular 183 role; a set of individuals, with each acting in a particular role; an 184 application or a set of applications, or a combination of these 185 within an administrative domain. 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 Sections requiring further editing are identified by [todo] markers 192 in the text. Points requiring further WG research and discussion are 193 identified by [discuss] markers in the text. 195 Note to RFC Editor - if the previous paragraph and this note have not 196 been removed, please send the document back to the editor to remove 197 this. 199 1.3. Modularity 201 The reader is expected to have read and understood the description of 202 the SNMP architecture, as defined in [RFC3411], and the Transport 203 Subsystem architecture extension specified in "Transport Subsystem 204 for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm]. 206 This memo describes the Secure Shell Transport Model for SNMP, a 207 specific SNMP transport model to be used within the SNMP transport 208 subsystem to provide authentication, encryption, and integrity 209 checking of SNMP messages. 211 In keeping with the RFC 3411 design decision to use self-contained 212 documents, this document defines the elements of procedure and 213 associated MIB module objects which are needed for processing the 214 Secure Shell Transport Model for SNMP. 216 This modularity of specification is not meant to be interpreted as 217 imposing any specific requirements on implementation. 219 1.4. Motivation 221 Version 3 of the Simple Network Management Protocol (SNMPv3) added 222 security to the protocol. The User-based Security Model (USM) 223 [RFC3414] was designed to be independent of other existing security 224 infrastructures, to ensure it could function when third party 225 authentication services were not available, such as in a broken 226 network. As a result, USM utilizes a separate user and key 227 management infrastructure. Operators have reported that deploying 228 another user and key management infrastructure in order to use SNMPv3 229 is a reason for not deploying SNMPv3. 231 This memo describes a transport model that will make use of the 232 existing and commonly deployed Secure Shell security infrastructure. 233 This transport model is designed to meet the security and operational 234 needs of network administrators, maximize usability in operational 235 environments to achieve high deployment success and at the same time 236 minimize implementation and deployment costs to minimize deployment 237 time. 239 This document addresses the requirement for the SSH client to 240 authenticate the SSH server, for the SSH server to authenticate the 241 SSH client, and describes how SNMP can make use of the authenticated 242 identities in authorization policies for data access, in a manner 243 that is independent of any specific access control model. 245 This document addresses the requirement to utilize client 246 authentication and key exchange methods which support different 247 security infrastructures and provide different security properties. 248 This document describes how to use client authentication as described 249 in "SSH Authentication Protocol" [RFC4252]. The SSH Transport Model 250 should work with any of the ssh-userauth methods including the 251 "publickey", "password", "hostbased", "none", "keyboard-interactive", 252 "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx" 253 (see http://www.iana.org/assignments/ssh-parameters). The use of the 254 "none" authentication method is NOT RECOMMENDED, as described in 255 Security Considerations. Local accounts may be supported through the 256 use of the publickey, hostbased or password methods. The password 257 method allows for integration with deployed password infrastructure 258 such as AAA servers using the RADIUS protocol [RFC2865]. The SSH 259 Transport Model SHOULD be able to take advantage of future defined 260 ssh-userauth methods, such as those that might make use of X.509 261 certificate credentials. 263 It is desirable to use mechanisms that could unify the approach for 264 administrative security for SNMPv3 and Command Line interfaces (CLI) 265 and other management interfaces. The use of security services 266 provided by Secure Shell is the approach commonly used for the CLI, 267 and is the approach being adopted for use with NETCONF [RFC4742]. 268 This memo describes a method for invoking and running the SNMP 269 protocol within a Secure Shell (SSH) session as an SSH subsystem. 271 This memo describes how SNMP can be used within a Secure Shell (SSH) 272 session, using the SSH connection protocol [RFC4254] over the SSH 273 transport protocol, using SSH user-auth [RFC4252] for authentication. 275 There are a number of challenges to be addressed to map Secure Shell 276 authentication method parameters into the SNMP architecture so that 277 SNMP continues to work without any surprises. These are discussed in 278 detail below. 280 1.5. Constraints 282 The design of this SNMP Transport Model is influenced by the 283 following constraints: 285 1. In times of network stress, the transport protocol and its 286 underlying security mechanisms SHOULD NOT depend upon the ready 287 availability of other network services (e.g., Network Time 288 Protocol (NTP) or AAA protocols). 290 2. When the network is not under stress, the transport model and its 291 underlying security mechanisms MAY depend upon the ready 292 availability of other network services. 294 3. It may not be possible for the transport model to determine when 295 the network is under stress. 297 4. A transport model should require no changes to the SNMP 298 architecture. 300 5. A transport model should require no changes to the underlying 301 protocol. 303 2. The Secure Shell Protocol 305 SSH is a protocol for secure remote login and other secure network 306 services over an insecure network. It consists of three major 307 protocol components, and add-on methods for user authentication: 309 o The Transport Layer Protocol [RFC4253] provides server 310 authentication, and message confidentiality and integrity. It may 311 optionally also provide compression. The transport layer will 312 typically be run over a TCP/IP connection, but might also be used 313 on top of any other reliable data stream. 315 o The User Authentication Protocol [RFC4252] authenticates the 316 client-side principal to the server. It runs over the transport 317 layer protocol. 319 o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel 320 into several logical channels. It runs over the transport after 321 successfully authenticating the principal. 323 o Generic Message Exchange Authentication [RFC4256] is a general 324 purpose authentication method for the SSH protocol, suitable for 325 interactive authentications where the authentication data should 326 be entered via a keyboard 328 o Generic Security Service Application Program Interface (GSS-API) 329 Authentication and Key Exchange for the Secure Shell (SSH) 330 Protocol [RFC4462] describes methods for using the GSS-API for 331 authentication and key exchange in SSH. It defines an SSH user 332 authentication method that uses a specified GSS-API mechanism to 333 authenticate a user, and a family of SSH key exchange methods that 334 use GSS-API to authenticate a Diffie-Hellman key exchange. 336 The client sends a service request once a secure transport layer 337 connection has been established. A second service request is sent 338 after client authentication is complete. This allows new protocols 339 to be defined and coexist with the protocols listed above. 341 The connection protocol provides channels that can be used for a wide 342 range of purposes. Standard methods are provided for setting up 343 secure interactive shell sessions and for forwarding ("tunneling") 344 arbitrary TCP/IP ports and X11 connections. 346 3. How SSHTM Fits into the Transport Subsystem 348 A transport model is a component of the Transport Subsystem 349 [I-D.ietf-isms-tmsm] within the SNMP architecture. The SSH Transport 350 Model thus fits between the underlying SSH transport layer and the 351 message dispatcher [RFC3411]. 353 The SSH Transport Model will establish a channel between itself and 354 the SSH Transport Model of another SNMP engine. The sending 355 transport model passes unencrypted messages from the dispatcher to 356 SSH to be encrypted, and the receiving transport model accepts 357 decrypted incoming messages from SSH and passes them to the 358 dispatcher. 360 After an SSH Transport model channel is established, then SNMP 361 messages can conceptually be sent through the channel from one SNMP 362 message dispatcher to another SNMP message dispatcher. Multiple SNMP 363 messages MAY be passed through the same channel. 365 The SSH Transport Model of an SNMP engine will perform the 366 translation between SSH-specific security parameters and SNMP- 367 specific, model-independent parameters. 369 3.1. Security Capabilities of this Model 371 3.1.1. Threats 373 The Secure Shell Transport Model provides protection against the 374 threats identified by the RFC 3411 architecture [RFC3411]: 376 1. Modification of Information - SSH provides for verification that 377 the contents of each message has not been modified during its 378 transmission through the network, by digitally signing each SSH 379 packet. 381 2. Masquerade - SSH provides for verification of the identity of the 382 SSH server and the identity of the SSH client. 384 SSH provides for verification of the identity of the SSH server 385 through the SSH Transport Protocol server authentication 386 [RFC4253]. This allows an operator or management station to 387 ensure the authenticity of the SNMP engine that provides MIB 388 data. 390 SSH provides a number of mechanisms for verification of the 391 identity of the SSH client-side principal, using the Secure Shell 392 Authentication Protocol [RFC4252]. These include public key, 393 password and host-based mechanisms. This allows the SNMP access 394 control subsystem to ensure that only authorized principals have 395 access to potentially sensitive data. 397 Verification of client's principal identity is important for use 398 with the SNMP access control subsystem, to ensure that only 399 authorized principals have access to potentially sensitive data. 400 The SSH user identity is provided to the transport model, so it 401 can be used to map to an SNMP model-independent securityName for 402 use with SNMP access control and notification configuration. 403 (The identity may undergo various transforms before it maps to 404 the securityName.) 406 3. Message Stream Modification - SSH protects against malicious re- 407 ordering or replaying of messages within a single SSH session by 408 using sequence numbers and integrity checks. SSH protects 409 against replay of messages across SSH sessions by ensuring that 410 the cryptographic keys used for encryption and integrity checks 411 are generated afresh for each session. 413 4. Disclosure - SSH provides protection against the disclosure of 414 information to unauthorized recipients or eavesdroppers by 415 allowing for encryption of all traffic between SNMP engines. 417 3.1.2. Message Authentication 419 The RFC 3411 architecture recognizes three levels of security: 421 - without authentication and without privacy (noAuthNoPriv) 423 - with authentication but without privacy (authNoPriv) 425 - with authentication and with privacy (authPriv) 427 The Secure Shell protocol provides support for encryption and data 428 integrity. While it is technically possible to support no 429 authentication and no encryption in SSH it is NOT RECOMMENDED by 430 [RFC4253]. 432 The SSH Transport Model determines from SSH the identity of the 433 authenticated principal, and the type and address associated with an 434 incoming message, and provides this information to SSH for an 435 outgoing message. The transport layer algorithms used to provide 436 authentication, data integrity and encryption SHOULD NOT be exposed 437 to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided 438 this and settled for an assertion by the security model that the 439 requirements of securityLevel were met The SSH Transport Model has no 440 mechanisms by which it can test whether an underlying SSH connection 441 provides auth or priv, so the SSH Transport Model trusts that the 442 underlying SSH connection has been properly configured to support 443 authPriv security characteristics. 445 An SSH Transport Model-compliant implementation MUST use an SSH 446 connection that provides authentication, data integrity and 447 encryption that meets the highest level of SNMP security (authPriv). 448 Outgoing messages specified with a securityLevel of noAuthNoPriv or 449 authNoPriv, are actually sent by the SSH Transport Model with 450 authPriv-level protection. 452 The security protocols used in the Secure Shell Authentication 453 Protocol [RFC4252] and the Secure Shell Transport Layer Protocol 455 [RFC4253] are considered acceptably secure at the time of writing. 456 However, the procedures allow for new authentication and privacy 457 methods to be specified at a future time if the need arises. 459 3.1.3. Authentication Protocol Support 461 The SSH Transport Model should support any server or client 462 authentication mechanism supported by SSH. This includes the three 463 authentication methods described in the SSH Authentication Protocol 464 document [RFC4252] - publickey, password, and host-based - and 465 keyboard interactive and others. 467 The password authentication mechanism allows for integration with 468 deployed password based infrastructure. It is possible to hand a 469 password to a service such as RADIUS [RFC2865] or Diameter [RFC3588] 470 for validation. The validation could be done using the user-name and 471 user-password attributes. It is also possible to use a different 472 password validation protocol such as CHAP [RFC1994] or digest 473 authentication [RFC5090] to integrate with RADIUS or Diameter. At 474 some point in the processing, these mechanisms require the password 475 be made available as clear text on the device that is authenticating 476 the password which might introduce threats to the authentication 477 infrastructure. 479 GSSKeyex [RFC4462] provides a framework for the addition of client 480 authentication mechanisms which support different security 481 infrastructures and provide different security properties. 482 Additional authentication mechanisms, such as one that supports X.509 483 certificates, may be added to SSH in the future. 485 3.1.4. SSH Subsystem 487 This document describes the use of an SSH subsystem for SNMP to make 488 SNMP usage distinct from other usages. 490 An SSH subsystem of type "snmp" is opened by the SSH Transport Model 491 during the elements of procedure for an outgoing SNMP message. Since 492 the sender of a message initiates the creation of an SSH session if 493 needed, the SSH session will already exist for an incoming message or 494 the incoming message would never reach the SSH Transport Model. 496 Implementations MAY choose to instantiate SSH sessions in 497 anticipation of outgoing messages. This approach might be useful to 498 ensure that an SSH session to a given target can be established 499 before it becomes important to send a message over the SSH session. 500 Of course, there is no guarantee that a pre-established session will 501 still be valid when needed. 503 SSH sessions are uniquely identified within the SSH Transport Model 504 by the combination of tmTransportAddress and tmSecurityName 505 associated with each session. 507 Because naming policies might differ between administrative domains, 508 many SSH client software packages support a user@hostname:port 509 addressing syntax that operators can use to align non-equivalent 510 account names. The SnmpSSHAddress Textual Convention echos this 511 common SSH notation. 513 When this notation is used in an SnmpSSHAddress, the SSH connection 514 should be established with a SSH user name matching the "user" 515 portion of the notation when establishing a session with the remote 516 SSH server. The "user" portion may or may not match the 517 tmSecurityName parameter passed from the security model. If no 518 "user@" portion is specified in the SnmpSSHAddress, then the SSH 519 connection should be established using the tmSecurityName as the SSH 520 user name when establishing a session with the remote SSH server. 522 The SnmpSSHAddress and tmSecurityName associated with an SSH session 523 MUST remain constant during the life of the session. Different 524 SnmpSSHAddress values (with different hostnames, "user@" prefix names 525 and/or port numbers) will each result in individual SSH sessions. 527 3.2. Security Parameter Passing 529 For incoming messages, SSH-specific security parameters are 530 translated by the transport model into security parameters 531 independent of the transport and security models. The transport 532 model accepts messages from the SSH subsystem, and records the 533 transport-related and SSH-security-related information, including the 534 authenticated identity, in a cache referenced by tmStateReference, 535 and passes the WholeMsg and the tmStateReference to the dispatcher 536 using the receiveMessage() ASI (Application Service Interface). 538 For outgoing messages, the transport model takes input provided by 539 the dispatcher in the sendMessage() ASI. The SSH Transport Model 540 converts that information into suitable security parameters for SSH, 541 establishes sessions as needed, and passes messages to the SSH 542 subsystem for sending. 544 3.3. Notifications and Proxy 546 SSH connections may be initiated by command generators or by 547 notification originators. Command generators are frequently operated 548 by a human, but notification originators are usually unmanned 549 automated processes. As a result, it may be necessary to provision 550 authentication credentials on the SNMP engine containing the 551 notification originator, or use a third party key provider such as 552 Kerberos, so the engine can successfully authenticate to an engine 553 containing a notification receiver. 555 The targets to whom notifications or proxy requests should be sent is 556 typically determined and configured by a network administrator. The 557 SNMP-NOTIFICATION-MIB contains a list of targets to which 558 notifications should be sent. The SNMP-TARGET-MIB module [RFC3413] 559 contains objects for defining these management targets, including 560 transport domains and addresses and security parameters, for 561 applications such as notification generators and proxy forwarders. 563 For the SSH Transport Model, transport type and address are 564 configured in the snmpTargetAddrTable, and the securityName, and 565 securityLevel parameters are configured in the snmpTargetParamsTable. 566 The default approach is for an administrator to statically 567 preconfigure this information to identify the targets authorized to 568 receive notifications or received proxied messages. Local access 569 control processing needs to be performed by a Notification Originator 570 before notifications are actually sent and this processing is done 571 using the configured securityName. An important characteristic of 572 this is that authorization is done prior to determining if the 573 connection can succeed. Thus the locally configured securityName is 574 entirely trusted within the Notification Originator. 576 The SNMP-TARGET-MIB and NOTIFICATION-MIB MIB modules may be 577 configured using SNMP or other implementation-dependent mechanisms, 578 such as CLI scripting or loading a configuration file. It may be 579 necessary to provide additional implementation-specific configuration 580 of SSH parameters. 582 4. Cached Information and References 584 When performing SNMP processing, there are two levels of state 585 information that may need to be retained: the immediate state linking 586 a request-response pair, and potentially longer-term state relating 587 to transport and security. "Transport Subsystem for the Simple 588 Network Management Protocol" [I-D.ietf-isms-tmsm] defines general 589 requirements for caches and references. 591 This document defines additional cache requirements related to the 592 Secure Shell Transport Model. 594 4.1. Secure Shell Transport Model Cached Information 596 The Secure Shell Transport Model has specific responsibilities 597 regarding the cached information. See the Elements of Procedure in 598 Section 5 for detailed processing instructions on the use of the 599 tmStateReference fields by the SSH Transport Model. 601 4.1.1. tmSecurityName 603 The tmSecurityName MUST be a human-readable name (in snmpAdminString 604 format) representing the identity that has been set according to the 605 procedures in Section 5. The tmSecurityName MUST be constant for all 606 traffic passing through an SSHTM session. Messages MUST NOT be sent 607 through an existing SSH session that was established using a 608 different tmSecurityName. 610 On the SSH server side of a connection: 612 The tmSecurityName SHOULD be the SSH user name. How the SSH user 613 name is extracted from the SSH layer is implementation-dependent. 615 The SSH protocol is not always clear on whether the user name 616 field must be filled in, so for some implementations, such as 617 those using GSSAPI authentication, it may be necessary to use a 618 mapping algorithm to transform an SSH identity to a 619 tmSecurityName, or to transform a tmSecurityName to an SSH 620 identity. 622 In other cases the user name may not be verified by the server, so 623 for these implementations, it may be necessary to obtain the user 624 name from other credentials exchanged during the SSH exchange. 626 On the SSH client side of a connection: 628 The tmSecurityName is presented to the SSH Transport Model by the 629 application (possibly because of configuration specified in the 630 SNMP-TARGET-MIB). 632 The securityName MAY be derived from the tmSecurityName by a security 633 model, and MAY be used to configure notifications and access 634 controls. Transport models SHOULD generate a predictable 635 tmSecurityName. 637 4.1.2. tmSessionID 639 The tmSessionID MUST be recorded per message at the time of receipt. 640 When tmSameSecurity is set, the recorded tmSessionID can be used to 641 determine whether the SSH session available for sending a 642 corresponding outgoing message is the same SSH session as was used 643 when receiving the incoming message (e.g., a response to a request). 645 4.1.3. Session State 647 The per-session state that is referenced by tmStateReference may be 648 saved across multiple messages in a Local Configuration Datastore. 649 Additional session/connection state information might also be stored 650 in a Local Configuration Datastore. 652 5. Elements of Procedure 654 Abstract service interfaces have been defined by [RFC3411] and 655 further augmented by [I-D.ietf-isms-tmsm] to describe the conceptual 656 data flows between the various subsystems within an SNMP entity. The 657 Secure Shell Transport Model uses some of these conceptual data flows 658 when communicating between subsystems. 660 To simplify the elements of procedure, the release of state 661 information is not always explicitly specified. As a general rule, 662 if state information is available when a message gets discarded, the 663 message-state information should also be released, and if state 664 information is available when a session is closed, the session state 665 information should also be released. 667 An error indication in statusInformation will typically include the 668 OID and value for an incremented error counter. This may be 669 accompanied by the requested securityLevel, and the tmStateReference. 670 Per-message context information is not accessible to Transport 671 Models, so for the returned counter OID and value, contextEngine 672 would be set to the local value of snmpEngineID, and contextName to 673 the default context for error counters. 675 5.1. Procedures for an Incoming Message 677 1. The SSH Transport Model queries the SSH engine, in an 678 implementation-dependent manner, to determine the address the 679 message originated from, the user name authenticated by SSH, and 680 a session identifier. 682 2. Determine the tmTransportAddress to be associated with the 683 incoming message: 685 A. If this is a client-side SSH session, then the 686 tmTransportAddress is set to the tmTransportAddress used to 687 establish the session. It MUST exactly include any "user@" 688 prefix associated with the address provided to the 689 openSession() ASI. 691 B. If this is a server-side SSH session and this is the first 692 message received over the session, then the 693 tmTransportAddress is set to the address the message 694 originated from, determined in an implementation-dependent 695 way. This value MUST be constant for the entire SSH session 696 and future messages received MUST result in the 697 tmTransportAddress being set to the same value. 699 C. If this is a server-side SSH session and this is not the 700 first message received over the session, then the 701 tmTransportAddress is set to the previously established 702 tmTransportAddress for the session (e.g. the value from step 703 B. determined from a previous incoming message). 705 3. Determine the tmSecurityName to be associated with the incoming 706 message: 708 A. If this is a client-side SSH session, then the tmSecurityName 709 MUST be set to the tmSecurityName used to establish the 710 session. 712 B. If this is a server-side SSH session and this is the first 713 message received over the session, then the tmSecurityName is 714 set to the SSH user name. How the SSH user name is extracted 715 from the SSH layer is implementation-dependent. This value 716 MUST be constant for the entire SSH session and future 717 messages received MUST result in the tmSecurityName being set 718 to the same value. 720 C. If this is a server-side SSH session and this is not the 721 first message received over the session, then the 722 tmSecurityName is set to the previously established 723 tmSecurityName for the session (e.g. the value from step B. 724 determined from a previous incoming message). 726 4. Create a tmStateReference cache for subsequent reference to the 727 information. 729 tmTransportDomain = snmpSSHDomain 731 tmTransportAddress = the derived tmTransportAddress from step 732 3. 734 tmSecurityName = The derived tmSecurityName from step 2. 736 tmTransportSecurityLevel = "authPriv" (authentication and 737 confidentiality MUST be used to comply with this transport 738 model.) 739 tmSessionID = an implementation-dependent value that can be 740 used to detect when a session has closed and been replaced by 741 another session. The value in tmStateReference MUST uniquely 742 identify the session over which the message was received. 743 This session identifier MUST NOT be reused until there are no 744 references to it remaining. 746 Then the Transport model passes the message to the Dispatcher using 747 the following ASI: 749 statusInformation = 750 receiveMessage( 751 IN transportDomain -- snmpSSHDomain 752 IN transportAddress -- The tmTransportAddress for the message 753 IN wholeMessage -- the whole SNMP message from SSH 754 IN wholeMessageLength -- the length of the SNMP message 755 IN tmStateReference -- (NEW) transport info 756 ) 758 5.2. Procedures for sending an Outgoing Message 760 The Dispatcher passes the information to the Transport Model using 761 the ASI defined in the transport subsystem: 763 statusInformation = 764 sendMessage( 765 IN destTransportDomain -- transport domain to be used 766 IN destTransportAddress -- transport address to be used 767 IN outgoingMessage -- the message to send 768 IN outgoingMessageLength -- its length 769 IN tmStateReference -- (NEW) transport info 770 ) 772 The SSH Transport Model performs the following tasks. 774 1. If tmStateReference does not refer to a cache containing values 775 for tmTransportDomain, tmTransportAddress, tmSecurityName, 776 tmRequestedSecurityLevel, and tmSameSecurity, then increment the 777 snmpSshtmSessionInvalidCaches counter, discard the message and 778 return the error indication in the statusInformation. Processing 779 of this message stops. 781 2. Extract the tmTransportDomain, tmTransportAddress, 782 tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and 783 tmSessionID from the tmStateReference. 785 3. Identify an SSH session to send the messages over: 787 A. If tmSameSecurity is true and there is no existing session 788 with a matching tmSessionID, tmSecurityName and 789 tmTransportAddress, then increment the 790 snmpSshtmSessionNoSessions counter, discard the message and 791 return the error indication in the statusInformation. 792 Processing of this message stops. 794 B. If there is a session with a matching tmSessionID, 795 tmTransportAddress and tmSecurityName, then select that 796 session. 798 C. If there is a session that matches the tmTransportAddress and 799 tmSecurityName, then select that session. 801 D. If the above steps failed to select a session to use, then 802 call openSession() with the tmStateReference as a parameter. 804 + If openSession fails, then discard the message, release 805 tmStateReference and pass the error indication returned by 806 openSession back to the calling module. Processing stops 807 for this message. 809 + If openSession succeeds, then record the 810 destTransportDomain, destTransportAddress, tmSecurityname 811 and tmSessionID in an implementation-dependent manner. 812 This will be needed when processing an incoming message. 814 4. Pass the wholeMessage to SSH for encapsulation as data in an SSH 815 message over the identified SSH session. Any necessary 816 additional SSH-specific parameters should be provided in an 817 implementation-dependent manner. 819 5.3. Establishing a Session 821 The Secure Shell Transport Model provides the following abstract 822 service interface (ASI) to describe the data passed between the SSH 823 Transport Model and the SSH service. It is an implementation 824 decision how such data is passed. 826 statusInformation = 827 openSession( 828 IN tmStateReference -- transport information to be used 829 OUT tmStateReference -- transport information to be used 830 IN maxMessageSize -- of the sending SNMP entity 831 ) 833 The following describes the procedure to follow to establish a 834 session between a client and server to run SNMP over SSH. This 835 process is used by any SNMP engine establishing a session for 836 subsequent use. 838 This will be done automatically for an SNMP application that 839 initiates a transaction, such as a Command Generator or a 840 Notification Originator or a Proxy Forwarder. 842 1. Increment the snmpSshtmSessionOpens counter. 844 2. Using tmTransportAddress, the client will establish an SSH 845 transport connection using the SSH transport protocol, 846 authenticate the server, and exchange keys for message integrity 847 and encryption. The transportAddress associated with a session 848 MUST remain constant during the lifetime of the SSH session. 849 Implementations may need to cache the transportAddress passed to 850 the openSession API for later use when performing incoming 851 message processing (see section Section 5.1). 853 1. To authenticate the server, the client usually stores 854 (tmTransportAddress, server host public key) pairs in an 855 implementation-dependent manner. 857 2. The other parameters of the transport connection are provided 858 in an implementation-dependent manner. 860 3. If the attempt to establish a connection is unsuccessful, or 861 server authentication fails, then snmpSshtmSessionOpenErrors 862 is incremented, an openSession error indication is returned, 863 and openSession processing stops. 865 3. The client will then invoke an SSH authentication service to 866 authenticate the principal, such as that described in the SSH 867 authentication protocol [RFC4252]. 869 1. If the tmTransportAddress field contains a user-name followed 870 by an '@' character (ASCII 0x40), that user-name string that 871 should be presented to the ssh server as the "user name" for 872 user authentication purposes. If there is no user-name in 873 the tmTransportAddress then the tmSecurityName should be used 874 as the user-name. 876 2. The credentials used to authenticate the SSH principal are 877 determined in an implementation-dependent manner. 879 3. In an implementation-specific manner, invoke the SSH user 880 authentication service using the calculated user-name. 882 4. If the user authentication is unsuccessful, then the 883 transport connection is closed, the 884 snmpSshtmSessionUserAuthFailures counter is incremented, an 885 error indication is returned to the calling module, and 886 processing stops for this message. 888 4. The client should invoke the "ssh-connection" service (also known 889 as the SSH connection protocol [RFC4254]), and request a channel 890 of type "session". If unsuccessful, the transport connection is 891 closed, the snmpSshtmSessionNoChannels counter is incremented, an 892 error indication is returned to the calling module, and 893 processing stops for this message. 895 5. The client invokes "snmp" as an SSH subsystem, as indicated in 896 the "subsystem" parameter. If unsuccessful, the transport 897 connection is closed, the snmpSshtmSessionNoSubsystems counter is 898 incremented, an error indication is returned to the calling 899 module, and processing stops for this message. 901 In order to allow SNMP traffic to be easily identified and 902 filtered by firewalls and other network devices, servers 903 associated with SNMP entities using the Secure Shell Transport 904 Model MUST default to providing access to the "snmp" SSH 905 subsystem if the SSH session is established using the IANA- 906 assigned TCP ports (YYY and ZZZ). Servers SHOULD be configurable 907 to allow access to the SNMP SSH subsystem over other ports. 909 6. Set tmSessionID in the tmStateReference cache to an 910 implementation-dependent value to identify the session. 912 7. The tmSecurityName used to establish the SSH session must be the 913 only tmSecurityName used with the session. Incoming messages for 914 the session MUST be associated with this tmSecurityName value. 915 How this is accomplished is implementation-dependent. 917 5.4. Closing a Session 919 The Secure Shell Transport Model provides the following ASI to close 920 a session: 922 statusInformation = 923 closeSession( 924 IN tmSessionID -- transport address to be used 925 ) 927 The following describes the procedure to follow to close a session 928 between a client and server . This process is followed by any SNMP 929 engine to close an SSH session. It is implementation-dependent when 930 a session should be closed. The calling code should release the 931 associated tmStateReference. 933 1. Increment the snmpSshtmSessionCloses counter. 935 2. If there is no session corresponding to tmSessionID, then 936 closeSession processing is completed. 938 3. Have SSH close the session associated with tmSessionID. 940 6. MIB Module Overview 942 This MIB module provides management of the Secure Shell Transport 943 Model. It defines an OID to identify the SNMP-over-SSH transport 944 domain, a textual convention for SSH Addresses and several statistics 945 counters. 947 6.1. Structure of the MIB Module 949 Objects in this MIB module are arranged into subtrees. Each subtree 950 is organized as a set of related objects. The overall structure and 951 assignment of objects to their subtrees, and the intended purpose of 952 each subtree, is shown below. 954 6.2. Textual Conventions 956 Generic and Common Textual Conventions used in this document can be 957 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 959 6.3. Relationship to Other MIB Modules 961 Some management objects defined in other MIB modules are applicable 962 to an entity implementing the SSH Transport Model. In particular, it 963 is assumed that an entity implementing the SNMP-SSH-TM-MIB will 964 implement the SNMPv2-MIB [RFC3418], and the SNMP-FRAMEWORK-MIB 965 [RFC3411]. It is expected that an entity implementing this MIB will 966 also support the Transport Security Model 967 [I-D.ietf-isms-transport-security-model], and therefore implement the 968 SNMP-TSM-MIB. 970 This MIB module is for monitoring SSH Transport Model information. 972 6.3.1. MIB Modules Required for IMPORTS 974 The following MIB module imports items from [RFC2578], [RFC2579], 975 [RFC2580]. 977 This MIB module also references [RFC3490] and [RFC3986] 979 This document uses TDomain textual conventions for the SNMP-internal 980 MIB modules defined here for compatibility with the RFC3413 MIB 981 modules and the RFC3411 Abstract Service Interfaces. 983 7. MIB Module Definition 985 SNMP-SSH-TM-MIB DEFINITIONS ::= BEGIN 987 IMPORTS 988 MODULE-IDENTITY, OBJECT-TYPE, 989 OBJECT-IDENTITY, mib-2, snmpDomains, 990 Counter32 991 FROM SNMPv2-SMI 992 TEXTUAL-CONVENTION 993 FROM SNMPv2-TC 994 MODULE-COMPLIANCE, OBJECT-GROUP 995 FROM SNMPv2-CONF 996 ; 998 snmpSshtmMIB MODULE-IDENTITY 999 LAST-UPDATED "200903090000Z" 1000 ORGANIZATION "ISMS Working Group" 1001 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 1002 Subscribe: isms-request@lists.ietf.org 1004 Chairs: 1005 Juergen Quittek 1006 NEC Europe Ltd. 1007 Network Laboratories 1008 Kurfuersten-Anlage 36 1009 69115 Heidelberg 1010 Germany 1011 +49 6221 90511-15 1012 quittek@netlab.nec.de 1014 Juergen Schoenwaelder 1015 Jacobs University Bremen 1016 Campus Ring 1 1017 28725 Bremen 1018 Germany 1019 +49 421 200-3587 1020 j.schoenwaelder@iu-bremen.de 1022 Co-editors: 1023 David Harrington 1024 Huawei Technologies USA 1025 1700 Alma Drive 1026 Plano Texas 75075 1027 USA 1028 +1 603-436-8634 1029 ietfdbh@comcast.net 1031 Joseph Salowey 1032 Cisco Systems 1033 2901 3rd Ave 1034 Seattle, WA 98121 1035 USA 1036 jsalowey@cisco.com 1038 Wes Hardaker 1039 Sparta, Inc. 1040 P.O. Box 382 1041 Davis, CA 95617 1042 USA 1043 +1 530 792 1913 1044 ietf@hardakers.net 1045 " 1046 DESCRIPTION "The Secure Shell Transport Model MIB 1048 Copyright (c) 2009 IETF Trust and the persons identified as 1049 authors of the MIB module. All rights reserved. 1051 Redistribution and use in source and binary forms, with or without 1052 modification, are permitted provided that the following conditions 1053 are met: 1054 - Redistributions of source code must retain the above copyright 1055 notice, this list of conditions and the following disclaimer. 1056 - Redistributions in binary form must reproduce the above 1057 copyright notice, this list of conditions and the following 1058 disclaimer in the documentation and/or other materials provided 1059 with the distribution. 1060 - Neither the name of Internet Society, IETF or IETF Trust, nor the 1061 names of specific contributors, may be used to endorse or promote 1062 products derived from this software without specific prior written 1063 permission. 1065 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 1066 CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, 1067 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 1068 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 1069 DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR 1070 CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1071 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1072 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF 1073 USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 1074 AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 1075 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 1076 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1077 POSSIBILITY OF SUCH DAMAGE. 1079 This version of this MIB module is part of RFC XXXX; 1080 see the RFC itself for full legal notices. 1081 -- NOTE to RFC editor: replace XXXX with actual RFC number 1082 -- for this document and remove this note 1083 " 1085 REVISION "200903090000Z" 1086 DESCRIPTION "The initial version, published in RFC XXXX. 1087 -- NOTE to RFC editor: replace XXXX with actual RFC number 1088 -- for this document and remove this note 1089 " 1091 ::= { mib-2 xxxx } 1092 -- RFC Ed.: replace xxxx with IANA-assigned number and 1093 -- remove this note 1095 -- ---------------------------------------------------------- -- 1096 -- subtrees in the SNMP-SSH-TM-MIB 1097 -- ---------------------------------------------------------- -- 1099 snmpSshtmNotifications OBJECT IDENTIFIER ::= { snmpSshtmMIB 0 } 1100 snmpSshtmObjects OBJECT IDENTIFIER ::= { snmpSshtmMIB 1 } 1101 snmpSshtmConformance OBJECT IDENTIFIER ::= { snmpSshtmMIB 2 } 1103 -- ------------------------------------------------------------- 1104 -- Objects 1105 -- ------------------------------------------------------------- 1107 snmpSSHDomain OBJECT-IDENTITY 1108 STATUS current 1109 DESCRIPTION 1110 "The SNMP over SSH transport domain. The corresponding 1111 transport address is of type SnmpSSHAddress. 1113 When an SNMP entity uses the snmpSSHDomain transport 1114 model, it must be capable of accepting messages up to 1115 and including 8192 octets in size. Implementation of 1116 larger values is encouraged whenever possible. 1118 The securityName prefix to be associated with the 1119 snmpSSHDomain is 'ssh'. This prefix may be used by security 1120 models or other components to identify what secure transport 1121 infrastructure authenticated a securityName." 1122 ::= { snmpDomains yy } 1124 -- RFC Ed.: Please replace the I-D reference with a proper one once it 1125 -- has been published. 1127 -- RFC Ed.: replace yy with IANA-assigned number and 1128 -- remove this note 1130 -- RFC Ed.: replace 'ssh' with the actual IANA assigned prefix string 1131 -- if 'ssh' is not assigned to this document. 1133 SnmpSSHAddress ::= TEXTUAL-CONVENTION 1134 DISPLAY-HINT "1a" 1135 STATUS current 1136 DESCRIPTION 1137 "Represents either a hostname or IP address, along with a port 1138 number and an optional username. 1140 The beginning of the address specification may contain a 1141 username followed by an '@' (ASCII character 0x40). This 1142 portion of the address will indicate the user name that should 1143 be used when authenticating to an SSH server. If missing, the 1144 SNMP securityName should be used. After the optional user name 1145 field and '@' character comes the hostname or IP address. 1147 The hostname must be encoded in ASCII, as specified in 1148 RFC3490 (Internationalizing Domain Names in Applications) 1149 followed by a colon ':' (ASCII character 0x3A) and a 1150 decimal port number in ASCII. The name SHOULD be fully 1151 qualified whenever possible. 1153 An IPv4 address must be in dotted decimal format followed 1154 by a colon ':' (ASCII character 0x3A) and a decimal port 1155 number in ASCII. 1157 An IPv6 address must be in colon separated format, surrounded 1158 by square brackets ('[' ASCII character 0x5B and ']' ASCII 1159 character 0x5D), followed by a colon ':' (ASCII character 1160 0x3A) and a decimal port number in ASCII. 1162 Values of this textual convention might not be directly useable 1163 as transport-layer addressing information, and may require 1164 runtime resolution. As such, applications that write them 1165 must be prepared for handling errors if such values are 1166 not supported, or cannot be resolved (if resolution occurs 1167 at the time of the management operation). 1169 The DESCRIPTION clause of TransportAddress objects that may 1170 have snmpSSHAddress values must fully describe how (and 1171 when) such names are to be resolved to IP addresses and vice 1172 versa. 1174 This textual convention SHOULD NOT be used directly in 1175 object definitions since it restricts addresses to a 1176 specific format. However, if it is used, it MAY be used 1177 either on its own or in conjunction with 1178 TransportAddressType or TransportDomain as a pair. 1180 When this textual convention is used as a syntax of an 1181 index object, there may be issues with the limit of 128 1182 sub-identifiers specified in SMIv2, STD 58. It is 1183 RECOMMENDED that all MIB documents using this textual 1184 convention make explicit any limitations on index 1185 component lengths that management software must observe. 1186 This may be done either by including SIZE constraints on 1187 the index components or by specifying applicable 1188 constraints in the conceptual row DESCRIPTION clause or 1189 in the surrounding documentation. 1190 " 1191 REFERENCE 1192 "RFC3986, Uniform Resource Identifier (URI): Generic Syntax" 1193 SYNTAX OCTET STRING (SIZE (1..255)) 1195 -- The snmpSshtmSession Group 1197 snmpSshtmSession OBJECT IDENTIFIER ::= { snmpSshtmObjects 1 } 1199 snmpSshtmSessionOpens OBJECT-TYPE 1200 SYNTAX Counter32 1201 MAX-ACCESS read-only 1202 STATUS current 1203 DESCRIPTION "The number of times an openSession() request has been 1204 executed as an SSH client, whether it succeeded or 1205 failed. 1206 " 1207 ::= { snmpSshtmSession 1 } 1209 snmpSshtmSessionCloses OBJECT-TYPE 1210 SYNTAX Counter32 1211 MAX-ACCESS read-only 1212 STATUS current 1213 DESCRIPTION "The number of times a closeSession() request has been 1214 executed as an SSH client, whether it succeeded or 1215 failed. 1217 " 1218 ::= { snmpSshtmSession 2 } 1220 snmpSshtmSessionOpenErrors OBJECT-TYPE 1221 SYNTAX Counter32 1222 MAX-ACCESS read-only 1223 STATUS current 1224 DESCRIPTION "The number of times an openSession() request 1225 failed to open a transport connection, or failed to 1226 authenticate the server. 1227 " 1228 ::= { snmpSshtmSession 3 } 1230 snmpSshtmSessionUserAuthFailures OBJECT-TYPE 1231 SYNTAX Counter32 1232 MAX-ACCESS read-only 1233 STATUS current 1234 DESCRIPTION "The number of times an openSession() request 1235 failed to open a session as a SSH client due to user 1236 authentication failures. 1237 " 1238 ::= { snmpSshtmSession 4 } 1240 snmpSshtmSessionNoChannels OBJECT-TYPE 1241 SYNTAX Counter32 1242 MAX-ACCESS read-only 1243 STATUS current 1244 DESCRIPTION "The number of times an openSession() request 1245 failed to open a session as a SSH client due to 1246 channel open failures. 1247 " 1248 ::= { snmpSshtmSession 5 } 1250 snmpSshtmSessionNoSubsystems OBJECT-TYPE 1251 SYNTAX Counter32 1252 MAX-ACCESS read-only 1253 STATUS current 1254 DESCRIPTION "The number of times an openSession() request 1255 failed to open a session as a SSH client due to 1256 inability to connect to the requested subsystem. 1257 " 1258 ::= { snmpSshtmSession 6 } 1260 snmpSshtmSessionNoSessions OBJECT-TYPE 1261 SYNTAX Counter32 1262 MAX-ACCESS read-only 1263 STATUS current 1264 DESCRIPTION "The number of times an outgoing message 1265 was dropped because the same 1266 session was no longer available. 1267 " 1268 ::= { snmpSshtmSession 7 } 1270 snmpSshtmSessionInvalidCaches OBJECT-TYPE 1271 SYNTAX Counter32 1272 MAX-ACCESS read-only 1273 STATUS current 1274 DESCRIPTION "The number of outgoing messages dropped because the 1275 tmStateReference referred to an invalid cache. 1276 " 1277 ::= { snmpSshtmSession 8 } 1279 -- ************************************************ 1280 -- snmpSshtmMIB - Conformance Information 1281 -- ************************************************ 1283 snmpSshtmCompliances OBJECT IDENTIFIER ::= { snmpSshtmConformance 1 } 1285 snmpSshtmGroups OBJECT IDENTIFIER ::= { snmpSshtmConformance 2 } 1287 -- ************************************************ 1288 -- Compliance statements 1289 -- ************************************************ 1291 snmpSshtmCompliance MODULE-COMPLIANCE 1292 STATUS current 1294 DESCRIPTION "The compliance statement for SNMP engines that 1295 support the SNMP-SSH-TM-MIB" 1296 MODULE 1297 MANDATORY-GROUPS { snmpSshtmGroup } 1298 ::= { snmpSshtmCompliances 1 } 1300 -- ************************************************ 1301 -- Units of conformance 1302 -- ************************************************ 1303 snmpSshtmGroup OBJECT-GROUP 1304 OBJECTS { 1305 snmpSshtmSessionOpens, 1306 snmpSshtmSessionCloses, 1307 snmpSshtmSessionOpenErrors, 1308 snmpSshtmSessionUserAuthFailures, 1309 snmpSshtmSessionNoChannels, 1310 snmpSshtmSessionNoSubsystems, 1311 snmpSshtmSessionNoSessions, 1312 snmpSshtmSessionInvalidCaches 1314 } 1315 STATUS current 1316 DESCRIPTION "A collection of objects for maintaining 1317 information of an SNMP engine which implements the 1318 SNMP Secure Shell Transport Model. 1319 " 1321 ::= { snmpSshtmGroups 2 } 1323 END 1325 8. Operational Considerations 1327 The SSH Transport Model will likely not work in conditions where 1328 access to the CLI has stopped working. In situations where SNMP 1329 access has to work when the CLI has stopped working, a UDP transport 1330 model should be considered instead of the SSH Transport Model. 1332 If the SSH Transport Model is configured to utilize AAA services, 1333 operators should consider configuring support for local 1334 authentication mechanisms, such as local passwords, so SNMP can 1335 continue operating during times of network stress. 1337 The SSH protocol has its own window mechanism, defined in RFC 4254. 1338 The SSH specifications leave it open when window adjustments messages 1339 should be created, and some implementations send these whenever 1340 received data has been passed to the application. There are 1341 noticeable bandwidth and processing overheads to handling such window 1342 adjustment messages, which can be avoided by sending them less 1343 frequently. 1345 The SSH protocol requires the execution of CPU intensive calculations 1346 to establish a session key during session establishment. This means 1347 that short lived sessions become computationally expensive compared 1348 to USM, which does not have a notion of a session key. Other 1349 transport security protocols such as TLS support a session resumption 1350 feature that allows reusing a cached session key. Such a mechanism 1351 does not exist for SSH and thus SNMP applications should keep SSH 1352 sessions for longer time periods. 1354 To initiate SSH connections, an entity must be configured with SSH 1355 client credentials plus information to authenticate the server. 1356 While hosts are often configured to be SSH clients, most 1357 internetworking devices are not. To send notifications over SSHTM, 1358 the internetworking device will need to be configured as an SSH 1359 client. How this credential configuration is done is implementation 1360 and deployment specific. 1362 9. Security Considerations 1364 This document describes a transport model that permits SNMP to 1365 utilize SSH security services. The security threats and how the SSH 1366 Transport Model mitigates those threats is covered in detail 1367 throughout this memo. 1369 The SSH Transport Model relies on SSH mutual authentication, binding 1370 of keys, confidentiality and integrity. Any authentication method 1371 that meets the requirements of the SSH architecture will provide the 1372 properties of mutual authentication and binding of keys. 1374 SSHv2 provides Perfect Forward Security (PFS) for encryption keys. 1375 PFS is a major design goal of SSH, and any well-designed keyex 1376 algorithm will provide it. 1378 The security implications of using SSH are covered in [RFC4251]. 1380 The SSH Transport Model has no way to verify that server 1381 authentication was performed, to learn the host's public key in 1382 advance, or verify that the correct key is being used. The SSH 1383 Transport Model simply trusts that these are properly configured by 1384 the implementer and deployer. 1386 SSH provides the "none" userauth method. The SSH Transport Model 1387 MUST NOT be used with an SSH connection with the "none" userauth 1388 method. While SSH does support turning off confidentiality and 1389 integrity, they MUST NOT be turned off when used with the SSH 1390 Transport Model. 1392 The SSH protocol is not always clear on whether the user name field 1393 must be filled in, so for some implementations, such as those using 1394 GSSAPI authentication, it may be necessary to use a mapping algorithm 1395 to transform an SSH identity to a tmSecurityName, or to transform a 1396 tmSecurityName to an SSH identity. 1398 In other cases the user name may not be verified by the server, so 1399 for these implementations, it may be necessary to obtain the user 1400 name from other credentials exchanged during the SSH exchange. 1402 9.1. Skipping Public Key Verification 1404 Most key exchange algorithms are able to authenticate the SSH 1405 server's identity to the client. However, for the common case of DH 1406 signed by public keys, this requires the client to know the host's 1407 public key a priori and to verify that the correct key is being used. 1408 If this step is skipped, then authentication of the SSH server to the 1409 SSH client is not done. Data confidentiality and data integrity 1410 protection to the server still exist, but these are of dubious value 1411 when an attacker can insert himself between the client and the real 1412 SSH server. Note that some userauth methods may defend against this 1413 situation, but many of the common ones (including password and 1414 keyboard-interactive) do not, and in fact depend on the fact that the 1415 server's identity has been verified (so passwords are not disclosed 1416 to an attacker). 1418 SSH MUST NOT be configured to skip public key verification for use 1419 with the SSH Transport Model. 1421 9.2. Notification Authorizaton Considerations 1423 SNMP Notifications are authorized to be sent to a receiver based on 1424 the securityName used by the notification originator's SNMP engine. 1425 This authorization is performed before the message is actually sent 1426 and before the credentials of the remote receiver have been verified. 1427 It is thus critical that the credentials presented by a notification 1428 receiver MUST match the expected value(s) for a given transport 1429 address and that ownership of the credentials MUST be properly 1430 cryptographically verified. 1432 9.3. SSH User and Key Selection 1434 If a "user@" prefix is used within a SnmpSSHAddress value to specify 1435 a SSH user name to use for authentication then the key presented to 1436 the remote entity MUST be the key expected by the server for the 1437 "user". This may be different than a locally cached key identified 1438 by the securityName value. 1440 9.4. Conceptual Differences Between USM and SSHTM 1442 The User Based Security Model [RFC3414] employed symmetric 1443 cryptography and user naming conventions. SSH employs an asymmetric 1444 cryptographic and naming model. Unlike USM, cryptographic keys will 1445 be different on both sides of the SSH connection. Both sides are 1446 responsible for verifying that the remote entity presents the right 1447 key. The optional "user@" prefix component of the SnmpSSHAddress 1448 Textual Convention allows the client SNMP stack to associate the 1449 connection with a securityName that may be different than the SSH 1450 user name presented to the SSH server. 1452 9.5. The 'none' MAC Algorithm 1454 SSH provides the "none" MAC algorithm, which would allow you to turn 1455 off data integrity while maintaining confidentiality. However, if 1456 you do this, then an attacker may be able to modify the data in 1457 flight, which means you effectively have no authentication. 1459 SSH MUST NOT be configured using the "none" MAC algorithm for use 1460 with the SSH Transport Model. 1462 9.6. Use with SNMPv1/v2c Messages 1464 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 1465 74) [RFC3584] always select the SNMPv1 or SNMPv2c Security Models 1466 respectively. Both of these, and the User-based Security Model 1467 typically used with SNMPv3, derive the securityName and securityLevel 1468 from the SNMP message received, even when the message was received 1469 over a secure transport. Access control decisions are therefore made 1470 based on the contents of the SNMP message, rather than using the 1471 authenticated identity and securityLevel provided by the SSH 1472 Transport Model. 1474 9.7. MIB Module Security 1476 There are no management objects defined in this MIB module that have 1477 a MAX-ACCESS clause of read-write and/or read-create. So, if this 1478 MIB module is implemented correctly, then there is no risk that an 1479 intruder can alter or create any management objects of this MIB 1480 module via direct SNMP SET operations. 1482 Some of the readable objects in this MIB module (i.e., objects with a 1483 MAX-ACCESS other than not-accessible) may be considered sensitive or 1484 vulnerable in some network environments. It is thus important to 1485 control even GET and/or NOTIFY access to these objects and possibly 1486 to even encrypt the values of these objects when sending them over 1487 the network via SNMP. These are the tables and objects and their 1488 sensitivity/vulnerability: 1490 o The readable objects in this MIB module are not sensitive. 1492 SNMP versions prior to SNMPv3 did not include adequate security. 1493 Even if the network itself is secure (for example by using IPSec or 1494 SSH), even then, there is no control as to who on the secure network 1495 is allowed to access and GET/SET (read/change/create/delete) the 1496 objects in this MIB module. 1498 It is RECOMMENDED that implementers consider the security features as 1499 provided by the SNMPv3 framework (see [RFC3410] section 8), including 1500 full support for the USM and the SSH Transport Model cryptographic 1501 mechanisms (for authentication and privacy). 1503 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1504 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1505 enable cryptographic security. It is then a customer/operator 1506 responsibility to ensure that the SNMP entity giving access to an 1507 instance of this MIB module is properly configured to give access to 1508 the objects only to those principals (users) that have legitimate 1509 rights to indeed GET or SET (change/create/delete) them. 1511 10. IANA Considerations 1513 IANA is requested to assign: 1515 1. two TCP registered port numbers in the 1516 http://www.iana.org/assignments/port-numbers registry which will 1517 be the default ports for SNMP over an SSH Transport Model as 1518 defined in this document, and SNMP over an SSH Transport Model 1519 for notifications as defined in this document. It would be good 1520 if the assigned keywords were "snmpssh" and "snmpssh-trap" and 1521 the port numbers were x161 and x162. 1523 2. an SMI number under mib-2, for the MIB module in this document, 1525 3. an SMI number under snmpDomains, for the snmpSSHDomain, 1527 4. "ssh" as the corresponding prefix for the snmpSSHDomain in the 1528 SNMP Transport Model registry; defined in [I-D.ietf-isms-tmsm] 1530 5. "snmp" as an SSH Subsystem Name in the 1531 http://www.iana.org/assignments/ssh-parameters registry. 1533 -- note to RFC editor -- Please replace YYY and ZZZ in this document 1534 with the assigned port numbers and remove this note. 1536 11. Acknowledgements 1538 The editors would like to thank Jeffrey Hutzelman for sharing his SSH 1539 insights, and Dave Shield for an outstanding job wordsmithing the 1540 existing document to improve organization and clarity. 1542 Additionally, helpful document reviews were received from: Juergen 1543 Schoenwaelder. 1545 12. References 1546 12.1. Normative References 1548 [RFC2119] Bradner, S., "Key words for 1549 use in RFCs to Indicate 1550 Requirement Levels", 1551 BCP 14, RFC 2119, 1552 March 1997. 1554 [RFC2578] McCloghrie, K., Ed., 1555 Perkins, D., Ed., and J. 1556 Schoenwaelder, Ed., 1557 "Structure of Management 1558 Information Version 2 1559 (SMIv2)", STD 58, RFC 2578, 1560 April 1999. 1562 [RFC2579] McCloghrie, K., Ed., 1563 Perkins, D., Ed., and J. 1564 Schoenwaelder, Ed., 1565 "Textual Conventions for 1566 SMIv2", STD 58, RFC 2579, 1567 April 1999. 1569 [RFC2580] McCloghrie, K., Perkins, 1570 D., and J. Schoenwaelder, 1571 "Conformance Statements for 1572 SMIv2", STD 58, RFC 2580, 1573 April 1999. 1575 [RFC2865] Rigney, C., Willens, S., 1576 Rubens, A., and W. Simpson, 1577 "Remote Authentication Dial 1578 In User Service (RADIUS)", 1579 RFC 2865, June 2000. 1581 [RFC3411] Harrington, D., Presuhn, 1582 R., and B. Wijnen, "An 1583 Architecture for Describing 1584 Simple Network Management 1585 Protocol (SNMP) Management 1586 Frameworks", STD 62, 1587 RFC 3411, December 2002. 1589 [RFC3413] Levi, D., Meyer, P., and B. 1590 Stewart, "Simple Network 1591 Management Protocol (SNMP) 1592 Applications", STD 62, 1593 RFC 3413, December 2002. 1595 [RFC3414] Blumenthal, U. and B. 1596 Wijnen, "User-based 1597 Security Model (USM) for 1598 version 3 of the Simple 1599 Network Management Protocol 1600 (SNMPv3)", STD 62, 1601 RFC 3414, December 2002. 1603 [RFC3418] Presuhn, R., "Management 1604 Information Base (MIB) for 1605 the Simple Network 1606 Management Protocol 1607 (SNMP)", STD 62, RFC 3418, 1608 December 2002. 1610 [RFC3490] Faltstrom, P., Hoffman, P., 1611 and A. Costello, 1612 "Internationalizing Domain 1613 Names in Applications 1614 (IDNA)", RFC 3490, 1615 March 2003. 1617 [RFC3584] Frye, R., Levi, D., 1618 Routhier, S., and B. 1619 Wijnen, "Coexistence 1620 between Version 1, Version 1621 2, and Version 3 of the 1622 Internet-standard Network 1623 Management Framework", 1624 BCP 74, RFC 3584, 1625 August 2003. 1627 [RFC4251] Ylonen, T. and C. Lonvick, 1628 "The Secure Shell (SSH) 1629 Protocol Architecture", 1630 RFC 4251, January 2006. 1632 [RFC4252] Ylonen, T. and C. Lonvick, 1633 "The Secure Shell (SSH) 1634 Authentication Protocol", 1635 RFC 4252, January 2006. 1637 [RFC4253] Ylonen, T. and C. Lonvick, 1638 "The Secure Shell (SSH) 1639 Transport Layer Protocol", 1640 RFC 4253, January 2006. 1642 [RFC4254] Ylonen, T. and C. Lonvick, 1643 "The Secure Shell (SSH) 1644 Connection Protocol", 1645 RFC 4254, January 2006. 1647 [I-D.ietf-isms-tmsm] Harrington, D. and J. 1648 Schoenwaelder, "Transport 1649 Subsystem for the Simple 1650 Network Management Protocol 1651 (SNMP)", 1652 draft-ietf-isms-tmsm-16 1653 (work in progress), 1654 February 2009. 1656 12.2. Informative References 1658 [RFC1994] Simpson, W., "PPP Challenge 1659 Handshake Authentication 1660 Protocol (CHAP)", RFC 1994, 1661 August 1996. 1663 [RFC3410] Case, J., Mundy, R., 1664 Partain, D., and B. 1665 Stewart, "Introduction and 1666 Applicability Statements 1667 for Internet-Standard 1668 Management Framework", 1669 RFC 3410, December 2002. 1671 [RFC3588] Calhoun, P., Loughney, J., 1672 Guttman, E., Zorn, G., and 1673 J. Arkko, "Diameter Base 1674 Protocol", RFC 3588, 1675 September 2003. 1677 [RFC3986] Berners-Lee, T., Fielding, 1678 R., and L. Masinter, 1679 "Uniform Resource 1680 Identifier (URI): Generic 1681 Syntax", STD 66, RFC 3986, 1682 January 2005. 1684 [RFC4256] Cusack, F. and M. Forssen, 1685 "Generic Message Exchange 1686 Authentication for the 1687 Secure Shell Protocol 1688 (SSH)", RFC 4256, 1689 January 2006. 1691 [RFC4462] Hutzelman, J., Salowey, J., 1692 Galbraith, J., and V. 1693 Welch, "Generic Security 1694 Service Application Program 1695 Interface (GSS-API) 1696 Authentication and Key 1697 Exchange for the Secure 1698 Shell (SSH) Protocol", 1699 RFC 4462, May 2006. 1701 [RFC5090] Sterman, B., Sadolevsky, 1702 D., Schwartz, D., Williams, 1703 D., and W. Beck, "RADIUS 1704 Extension for Digest 1705 Authentication", RFC 5090, 1706 February 2008. 1708 [RFC4742] Wasserman, M. and T. 1709 Goddard, "Using the NETCONF 1710 Configuration Protocol over 1711 Secure SHell (SSH)", 1712 RFC 4742, December 2006. 1714 [I-D.ietf-isms-transport-security-model] Harrington, D. and W. 1715 Hardaker, "Transport 1716 Security Model for SNMP", d 1717 raft-ietf-isms-transport- 1718 security-model-12 (work in 1719 progress), March 2009. 1721 Appendix A. Change Log 1723 Changes from -15- to -16- 1725 o updated MIB copyright 1727 o renamed SSHTM-MIB to SNMP-SSH-TM-MIB, which required: 1729 * renaming the module identity from sshtmMIB to snmpSshtmMIB 1731 * renaming the prefixes for all objects from sshtmXXXX to 1732 snmpSshtmXXXX 1734 From -14 to -15 1736 Updated the elements of procedure to better reflect the working 1737 group consensus that a given session must always have identical 1738 sessionIDs, addresses and names to match the ASI parameters. 1740 Discuss that the tmSessionID, tmSecurityName and 1741 tmTransportAddress need to be constant for the life of the 1742 session. 1744 Minor wording edits 1746 Added earlier text to introduce the concept of the user@ portion 1747 of the SSH transport address convention. 1749 Discussed notification authorization more extensively in the 1750 security considerations. 1752 Changed "ssh principal" to "ssh user name" where appropriate. 1754 Removed the sshtmSessionInvalidCaches object from the MIB 1755 conformance section. 1757 From -13 to -14 1759 Removed duplicated text on Caches and References, and reference 1760 tmsm document 1762 Simplified securityStateReference 1764 Simplified EOP to use tmStateReference rather than ASI parameters 1766 Simplified openSession and closeSession 1768 Seperated steps in openSession 1770 Clarified conditions in the openSession error counter descriptions 1772 Reworded text to clarify short versus long term information 1774 Added more warnings about the unreliability of SSH user name 1776 removed any references to LCD 1778 From -12 to -13 1780 Removed redundant sections 3.1.4 and 3.1.5 on privacy and replay/ 1781 delay/etc protection. 1783 From -11- to -12 1785 Updated "Cached Information and References" to match other ISMS 1786 documents. 1788 Added separate subsection on Secure Shell Transport Model Cached 1789 Information. 1791 Added IANA considerations to add snmpSSHDomain and "ssh" to a 1792 registry for domains and corresponding prefixes, defined in TMSM. 1794 Added support for user@ prefixing in the SSH Transport Address 1795 definition and EOP. 1797 Added support for the "ssh" prefix to the transport address 1798 definition and IANA considerations section. 1800 Removed the LCD tables and related configuration since the user@ 1801 transport address prefixing and the TSM user prefix changes change 1802 makes it no longer needed. 1804 From -10- to -11 1806 Changed LCD to sshtmLCDTable so it would not be confused with the 1807 snmpTsmLCD. 1809 Removed the text that said the format and content of the LCD is 1810 implementation-specific, since we now have a MIB module to 1811 standardize the format and content. 1813 Designed sshtmLCDTable to reflect there is only one 1814 transportDomain and one securityLevel supported by this transport 1815 model. 1817 Used sshtmLCDTmSecurityName to reflect that the values in this 1818 table and the values in the tmStateReference are usually the same 1819 for some fields. 1821 Added operational considerations about SSH client credential 1822 distribution. 1824 Modified EOP to use sshtmLCDTable 1826 Resolved Issue #8: Should we allow transport models to select the 1827 corresponding security model by providing an additional parameter 1828 - the securityModel parameter - to tmStateReference, which would 1829 override the securityModel parameter extracted from a message 1830 header? Doing this would resolve Issue #5, and would allow the 1831 transport security model to be used with all SNMP message 1832 versions. - The consensus is that we will not allow the transport 1833 model to specify the security model. 1835 From -09- to -10 1836 Issue #1: Made release of cached session info an implementation 1837 requirement on session close. 1839 Issue #4: UTF-8 syntax of userauth user name matches syntax of 1840 SnmpAdminString. 1842 Issue #7: Resolved to not describe how an SSH session is closed. 1844 From -08- to -09 1846 Updated MIB assignment to by rfc4181 compatible 1848 update MIB security considerations with coexistence issues 1850 update sameSession and tmSessionID support 1852 Fixed note about terminology, for consistency with SNMPv3. 1854 From -07- to -08 1856 Updated MIB 1858 update MIB security considerations 1860 develop sameSession and tmSessionID support 1862 Added a note about terminology, for consistency with SNMPv3 rather 1863 than with RFC2828. 1865 Removed reference to mappings other than the identity function. 1867 From -06- to -07 1869 removed section on SSH to EngineID mappings, since engineIDs are 1870 not exposed to the transport model 1872 removed references to engineIDs and discovery 1874 removed references to securityModel. 1876 added security considerations warning about using with SNMPv1/v2c 1877 messages. 1879 added keyboard interactive discussion 1881 noted some implementation-dependent points 1882 removed references to transportModel; we use the transport domain 1883 as a model identifier. 1885 cleaned up ASIs 1887 modified MIB to be under snmpModules 1889 changed transportAddressSSH to snmpSSHDomain style addressing 1891 From -05- to -06 1893 replaced transportDomainSSH with RFC3417-style snmpSSHDomain 1895 replaced transportAddressSSH with RFC3417-style snmpSSHAddress 1897 Changed recvMessage to receiveMessage, and modified OUT to IN to 1898 match TMSM. 1900 From -04- to -05 1902 added sshtmUserTable 1904 moved session table into the transport model MIB from the 1905 transport subsystem MIB 1907 added and then removed Appendix A - Notification Tables 1908 Configuration (see Transport Security Model) 1910 made this document a specification of a transport model, rather 1911 than a security model in two parts. Eliminated TMSP and MPSP and 1912 replaced them with "transport model" and "security model". 1914 Removed security-model-specific processing from this document. 1916 Removed discussion of snmpv3/v1/v2c message format co-existence 1918 changed tmSessionReference back to tmStateReference 1920 "From -03- to -04-" 1922 changed tmStateReference to tmSessionReference 1924 "From -02- to -03-" 1925 rewrote almost all sections 1927 merged ASI section and Elements of Procedure sections 1929 removed references to the SSH user, in preference to SSH client 1931 updated references 1933 created a conventions section to identify common terminology. 1935 rewrote sections on how SSH addresses threats 1937 rewrote mapping SSH to engineID 1939 eliminated discovery section 1941 detailed the Elements of Procedure 1943 eliminated sections on msgFlags, transport parameters 1945 resolved issues of opening notifications 1947 eliminated sessionID (TMSM needs to be updated to match) 1949 eliminated use of tmsSessiontable except as an example 1951 updated Security Considerations 1953 "From -01- to -02-" 1955 Added TransportDomainSSH and Address 1957 Removed implementation considerations 1959 Changed all "user auth" to "client auth" 1961 Removed unnecessary MIB module objects 1963 updated references 1965 improved consistency of references to TMSM as architectural 1966 extension 1968 updated conventions 1970 updated threats to be more consistent with RFC3552 1971 discussion of specific SSH mechanism configurations moved to 1972 security considerations 1974 modified session discussions to reference TMSM sessions 1976 expanded discussion of engineIDs 1978 wrote text to clarify the roles of MPSP and TMSP 1980 clarified how snmpv3 message parts are ised by SSHSM 1982 modified nesting of subsections as needed 1984 securityLevel used by the SSH Transport Model always equals 1985 authPriv 1987 removed discussion of using SSHSM with SNMPv1/v2c 1989 started updating Elements of Procedure, but realized missing info 1990 needs discussion. 1992 updated MIB module relationship to other MIB modules 1994 "From -00- to -01-" 1996 -00- initial draft as ISMS work product: 1998 updated references to secshell RFCs 2000 Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19, 2001 20, 29, 30, and 32. 2003 updated security considerations 2005 removed Juergen Schoenwaelder from authors, at his request 2007 ran the mib module through smilint 2009 Authors' Addresses 2011 David Harrington 2012 Huawei Technologies (USA) 2013 1700 Alma Dr. Suite 100 2014 Plano, TX 75075 2015 USA 2017 Phone: +1 603 436 8634 2018 EMail: dharrington@huawei.com 2020 Joseph Salowey 2021 Cisco Systems 2022 2901 3rd Ave 2023 Seattle, WA 98121 2024 USA 2026 EMail: jsalowey@cisco.com 2028 Wes Hardaker 2029 Sparta, Inc. 2030 P.O. Box 382 2031 Davis, CA 95617 2032 US 2034 Phone: +1 530 792 1913 2035 EMail: ietf@hardakers.net