idnits 2.17.1 draft-ietf-isms-secshell-18.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 (May 11, 2009) is 5464 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) ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- 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) -- No information found for draft-ietf-isms-transport-security-model - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 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: November 12, 2009 Cisco Systems 6 W. Hardaker 7 Sparta, Inc. 8 May 11, 2009 10 Secure Shell Transport Model for SNMP 11 draft-ietf-isms-secshell-18 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 November 12, 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 . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 13 84 4. Cached Information and References . . . . . . . . . . . . . . 13 85 4.1. Secure Shell Transport Model Cached Information . . . . . 14 86 4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . . . 14 87 4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . 22 99 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 22 100 8. Operational Considerations . . . . . . . . . . . . . . . . . . 29 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 102 9.1. Skipping Public Key Verification . . . . . . . . . . . . . 31 103 9.2. Notification Authorization Considerations . . . . . . . . 31 104 9.3. SSH User and Key Selection . . . . . . . . . . . . . . . . 32 105 9.4. Conceptual Differences Between USM and SSHTM . . . . . . . 32 106 9.5. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 32 107 9.6. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 32 108 9.7. MIB Module Security . . . . . . . . . . . . . . . . . . . 33 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 110 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 112 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 113 12.2. Informative References . . . . . . . . . . . . . . . . . . 37 115 1. Introduction 117 This memo describes a Transport Model for the Simple Network 118 Management Protocol, using the Secure Shell protocol (SSH) [RFC4251] 119 within a transport subsystem [I-D.ietf-isms-tmsm]. The transport 120 model specified in this memo is referred to as the Secure Shell 121 Transport Model (SSHTM). 123 This memo also defines a portion of the Management Information Base 124 (MIB) for use with network management protocols in TCP/IP based 125 internets. In particular it defines objects for monitoring and 126 managing the Secure Shell Transport Model for SNMP. 128 It is important to understand the SNMP architecture [RFC3411] and the 129 terminology of the architecture to understand where the Transport 130 Model described in this memo fits into the architecture and interacts 131 with other subsystems within the architecture. 133 1.1. The Internet-Standard Management Framework 135 For a detailed overview of the documents that describe the current 136 Internet-Standard Management Framework, please refer to section 7 of 137 RFC 3410 [RFC3410]. 139 Managed objects are accessed via a virtual information store, termed 140 the Management Information Base or MIB. MIB objects are generally 141 accessed through the Simple Network Management Protocol (SNMP). 142 Objects in the MIB are defined using the mechanisms defined in the 143 Structure of Management Information (SMI). This memo specifies a MIB 144 module that is compliant to the SMIv2, which is described in STD 58, 145 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 146 [RFC2580]. 148 1.2. Conventions 150 For consistency with SNMP-related specifications, this document 151 favors terminology as defined in STD62 rather than favoring 152 terminology that is consistent with non-SNMP specifications. This is 153 consistent with the IESG decision to not require the SNMPv3 154 terminology be modified to match the usage of other non-SNMP 155 specifications when SNMPv3 was advanced to Full Standard. 157 Authentication in this document typically refers to the English 158 meaning of "serving to prove the authenticity of" the message, not 159 data source authentication or peer identity authentication. 161 The terms "manager" and "agent" are not used in this document, 162 because in the RFC 3411 architecture [RFC3411], all SNMP entities 163 have the capability of acting in either manager or agent or in both 164 roles depending on the SNMP application types supported in the 165 implementation. Where distinction is required, the application names 166 of Command Generator, Command Responder, Notification Originator, 167 Notification Receiver, and Proxy Forwarder are used. See "SNMP 168 Applications" [RFC3413] for further information. 170 Throughout this document, the terms "client" and "server" are used to 171 refer to the two ends of the SSH transport connection. The client 172 actively opens the SSH connection, and the server passively listens 173 for the incoming SSH connection. Either SNMP entity may act as 174 client or as server, as discussed further below. 176 The User-Based Security Model (USM) [RFC3414] is a mandatory-to- 177 implement Security Model in STD 62. While SSH and USM frequently 178 refer to a user, the terminology preferred in RFC3411 [RFC3411] and 179 in this memo is "principal". A principal is the "who" on whose 180 behalf services are provided or processing takes place. A principal 181 can be, among other things, an individual acting in a particular 182 role; a set of individuals, with each acting in a particular role; an 183 application or a set of applications, or a combination of these 184 within an administrative domain. 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 Non uppercased versions of the keywords should be read as in normal 191 English. They will usually, but not always, be used in a context 192 relating to compatibility with the RFC3411 architecture or the 193 subsystem defined here, but which might have no impact on on-the-wire 194 compatibility. These terms are used as guidance for designers of 195 proposed IETF models to make the designs compatible with RFC3411 196 subsystems and Abstract Service Interfaces (ASIs) (see section 3.2). 197 Implementers are free to implement differently. Some usages of these 198 lowercase terms are simply normal English usage. 200 1.3. Modularity 202 The reader is expected to have read and understood the description of 203 the SNMP architecture, as defined in [RFC3411], and the Transport 204 Subsystem architecture extension specified in "Transport Subsystem 205 for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm]. 207 This memo describes the Secure Shell Transport Model for SNMP, a 208 specific SNMP transport model to be used within the SNMP transport 209 subsystem to provide authentication, encryption, and integrity 210 checking of SNMP messages. 212 In keeping with the RFC 3411 design decision to use self-contained 213 documents, this document defines the elements of procedure and 214 associated MIB module objects which are needed for processing the 215 Secure Shell Transport Model for SNMP. 217 This modularity of specification is not meant to be interpreted as 218 imposing any specific requirements on implementation. 220 1.4. Motivation 222 Version 3 of the Simple Network Management Protocol (SNMPv3) added 223 security to the protocol. The User-based Security Model (USM) 224 [RFC3414] was designed to be independent of other existing security 225 infrastructures, to ensure it could function when third party 226 authentication services were not available, such as in a broken 227 network. As a result, USM utilizes a separate user and key 228 management infrastructure. Operators have reported that having to 229 deploy another user and key management infrastructure in order to use 230 SNMPv3 is a reason for not deploying SNMPv3. 232 This memo describes a transport model that will make use of the 233 existing and commonly deployed Secure Shell security infrastructure. 234 This transport model is designed to meet the security and operational 235 needs of network administrators, maximize usability in operational 236 environments to achieve high deployment success and at the same time 237 minimize implementation and deployment costs to minimize deployment 238 time. 240 This document addresses the requirement for the SSH client to 241 authenticate the SSH server, for the SSH server to authenticate the 242 SSH client, and describes how SNMP can make use of the authenticated 243 identities in authorization policies for data access, in a manner 244 that is independent of any specific access control model. 246 This document addresses the requirement to utilize client 247 authentication and key exchange methods which support different 248 security infrastructures and provide different security properties. 249 This document describes how to use client authentication as described 250 in "SSH Authentication Protocol" [RFC4252]. The SSH Transport Model 251 should work with any of the ssh-userauth methods including the 252 "publickey", "password", "hostbased", "none", "keyboard-interactive", 253 "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx" 254 (see http://www.iana.org/assignments/ssh-parameters). The use of the 255 "none" authentication method is NOT RECOMMENDED, as described in 256 Security Considerations. Local accounts may be supported through the 257 use of the publickey, hostbased or password methods. The password 258 method allows for integration with deployed password infrastructure 259 such as AAA servers using the RADIUS protocol [RFC2865]. The SSH 260 Transport Model SHOULD be able to take advantage of future defined 261 ssh-userauth methods, such as those that might make use of X.509 262 certificate credentials. 264 It is desirable to use mechanisms that could unify the approach for 265 administrative security for SNMPv3 and Command Line interfaces (CLI) 266 and other management interfaces. The use of security services 267 provided by Secure Shell is the approach commonly used for the CLI, 268 and is the approach being adopted for use with NETCONF [RFC4742]. 269 This memo describes a method for invoking and running the SNMP 270 protocol within a Secure Shell (SSH) session as an SSH subsystem. 272 This memo describes how SNMP can be used within a Secure Shell (SSH) 273 session, using the SSH connection protocol [RFC4254] over the SSH 274 transport protocol, using SSH user-auth [RFC4252] for authentication. 276 There are a number of challenges to be addressed to map Secure Shell 277 authentication method parameters into the SNMP architecture so that 278 SNMP continues to work without any surprises. These are discussed in 279 detail below. 281 1.5. Constraints 283 The design of this SNMP Transport Model is influenced by the 284 following constraints: 286 1. In times of network stress, the transport protocol and its 287 underlying security mechanisms SHOULD NOT depend upon the ready 288 availability of other network services (e.g., Network Time 289 Protocol (NTP) or AAA protocols). 291 2. When the network is not under stress, the transport model and its 292 underlying security mechanisms MAY depend upon the ready 293 availability of other network services. 295 3. It may not be possible for the transport model to determine when 296 the network is under stress. 298 4. A transport model SHOULD NOT require changes to the SNMP 299 architecture. 301 5. A transport model SHOULD NOT require changes to the underlying 302 security protocol. 304 2. The Secure Shell Protocol 306 SSH is a protocol for secure remote login and other secure network 307 services over an insecure network. It consists of three major 308 protocol components, and add-on methods for user authentication: 310 o The Transport Layer Protocol [RFC4253] provides server 311 authentication, and message confidentiality and integrity. It may 312 optionally also provide compression. The transport layer will 313 typically be run over a TCP/IP connection, but might also be used 314 on top of any other reliable data stream. 316 o The User Authentication Protocol [RFC4252] authenticates the 317 client-side principal to the server. It runs over the transport 318 layer protocol. 320 o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel 321 into several logical channels. It runs over the transport after 322 successfully authenticating the principal. 324 o Generic Message Exchange Authentication [RFC4256] is a general 325 purpose authentication method for the SSH protocol, suitable for 326 interactive authentications where the authentication data should 327 be entered via a keyboard 329 o Generic Security Service Application Program Interface (GSS-API) 330 Authentication and Key Exchange for the Secure Shell (SSH) 331 Protocol [RFC4462] describes methods for using the GSS-API for 332 authentication and key exchange in SSH. It defines an SSH user 333 authentication method that uses a specified GSS-API mechanism to 334 authenticate a user, and a family of SSH key exchange methods that 335 use GSS-API to authenticate a Diffie-Hellman key exchange. 337 The client sends a service request once a secure transport layer 338 connection has been established. A second service request is sent 339 after client authentication is complete. This allows new protocols 340 to be defined and coexist with the protocols listed above. 342 The connection protocol provides channels that can be used for a wide 343 range of purposes. Standard methods are provided for setting up 344 secure interactive shell sessions and for forwarding ("tunneling") 345 arbitrary TCP/IP ports and X11 connections. 347 3. How SSHTM Fits into the Transport Subsystem 349 A transport model is a component of the Transport Subsystem 350 [I-D.ietf-isms-tmsm] within the SNMP architecture. The SSH Transport 351 Model thus fits between the underlying SSH transport layer and the 352 message dispatcher [RFC3411]. 354 The SSH Transport Model will establish a channel between itself and 355 the SSH Transport Model of another SNMP engine. The sending 356 transport model passes unencrypted messages from the dispatcher to 357 SSH to be encrypted, and the receiving transport model accepts 358 decrypted incoming messages from SSH and passes them to the 359 dispatcher. 361 After an SSH Transport model channel is established, then SNMP 362 messages can conceptually be sent through the channel from one SNMP 363 message dispatcher to another SNMP message dispatcher. Multiple SNMP 364 messages MAY be passed through the same channel. 366 The SSH Transport Model of an SNMP engine will perform the 367 translation between SSH-specific security parameters and SNMP- 368 specific, model-independent parameters. 370 3.1. Security Capabilities of this Model 372 3.1.1. Threats 374 The Secure Shell Transport Model provides protection against the 375 threats identified by the RFC 3411 architecture [RFC3411]: 377 1. Modification of Information - SSH provides for verification that 378 the contents of each message has not been modified during its 379 transmission through the network, by digitally signing each SSH 380 packet. 382 2. Masquerade - SSH provides for verification of the identity of the 383 SSH server and the identity of the SSH client. 385 SSH provides for verification of the identity of the SSH server 386 through the SSH Transport Protocol server authentication 387 [RFC4253]. This allows an operator or management station to 388 ensure the authenticity of the SNMP engine that provides MIB 389 data. 391 SSH provides a number of mechanisms for verification of the 392 identity of the SSH client-side principal, using the Secure Shell 393 Authentication Protocol [RFC4252]. These include public key, 394 password and host-based mechanisms. This allows the SNMP access 395 control subsystem to ensure that only authorized principals have 396 access to potentially sensitive data. 398 Verification of client's principal identity is important for use 399 with the SNMP access control subsystem, to ensure that only 400 authorized principals have access to potentially sensitive data. 401 The SSH user identity is provided to the transport model, so it 402 can be used to map to an SNMP model-independent securityName for 403 use with SNMP access control and notification configuration. 404 (The identity may undergo various transforms before it maps to 405 the securityName.) 407 3. Message Stream Modification - SSH protects against malicious re- 408 ordering or replaying of messages within a single SSH session by 409 using sequence numbers and integrity checks. SSH protects 410 against replay of messages across SSH sessions by ensuring that 411 the cryptographic keys used for encryption and integrity checks 412 are generated afresh for each session. 414 4. Disclosure - SSH provides protection against the disclosure of 415 information to unauthorized recipients or eavesdroppers by 416 allowing for encryption of all traffic between SNMP engines. 418 3.1.2. Message Authentication 420 The RFC 3411 architecture recognizes three levels of security: 422 - without authentication and without privacy (noAuthNoPriv) 424 - with authentication but without privacy (authNoPriv) 426 - with authentication and with privacy (authPriv) 428 The Secure Shell protocol provides support for encryption and data 429 integrity. While it is technically possible to support no 430 authentication and no encryption in SSH it is NOT RECOMMENDED by 431 [RFC4253]. 433 The SSH Transport Model determines from SSH the identity of the 434 authenticated principal, and the type and address associated with an 435 incoming message, and provides this information to SSH for an 436 outgoing message. The SSH transport layer algorithms used to provide 437 authentication, data integrity and encryption SHOULD NOT be exposed 438 to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided 439 this and settled for an assertion by the security model that the 440 requirements of securityLevel were met. The SSH Transport Model has 441 no mechanisms by which it can test whether an underlying SSH 442 connection provides auth or priv, so the SSH Transport Model trusts 443 that the underlying SSH connection has been properly configured to 444 support authPriv security characteristics. 446 An SSH Transport Model-compliant implementation MUST use an SSH 447 connection that provides authentication, data integrity and 448 encryption that meets the highest level of SNMP security (authPriv). 449 Outgoing messages specified with a securityLevel of noAuthNoPriv or 450 authNoPriv, are actually sent by the SSH Transport Model with 451 authPriv-level protection. 453 The security protocols used in the Secure Shell Authentication 454 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 name must be encoded in UTF-8 (per RFC4252 517 [RFC4252]). The "user" portion may or may not match the 518 tmSecurityName parameter passed from the security model. If no 519 "user@" portion is specified in the SnmpSSHAddress, then the SSH 520 connection should be established using the tmSecurityName as the SSH 521 user name when establishing a session with the remote SSH server. 523 The SnmpSSHAddress and tmSecurityName associated with an SSH session 524 MUST remain constant during the life of the session. Different 525 SnmpSSHAddress values (with different hostnames, "user@" prefix names 526 and/or port numbers) will each result in individual SSH sessions. 528 3.2. Security Parameter Passing 530 For incoming messages, SSH-specific security parameters are 531 translated by the transport model into security parameters 532 independent of the transport and security models. The transport 533 model accepts messages from the SSH subsystem, and records the 534 transport-related and SSH-security-related information, including the 535 authenticated identity, in a cache referenced by tmStateReference, 536 and passes the WholeMsg and the tmStateReference to the dispatcher 537 using the receiveMessage() ASI (Application Service Interface). 539 For outgoing messages, the transport model takes input provided by 540 the dispatcher in the sendMessage() ASI. The SSH Transport Model 541 converts that information into suitable security parameters for SSH, 542 establishes sessions as needed, and passes messages to the SSH 543 subsystem for sending. 545 3.3. Notifications and Proxy 547 SSH connections may be initiated by command generators or by 548 notification originators. Command generators are frequently operated 549 by a human, but notification originators are usually unmanned 550 automated processes. As a result, it may be necessary to provision 551 authentication credentials on the SNMP engine containing the 552 notification originator, or use a third party key provider such as 553 Kerberos, so the engine can successfully authenticate to an engine 554 containing a notification receiver. 556 The targets to whom notifications or proxy requests should be sent is 557 typically determined and configured by a network administrator. The 558 SNMP-NOTIFICATION-MIB contains a list of targets to which 559 notifications should be sent. The SNMP-TARGET-MIB module [RFC3413] 560 contains objects for defining these management targets, including 561 transport domains and addresses and security parameters, for 562 applications such as notification generators and proxy forwarders. 564 For the SSH Transport Model, transport type and address are 565 configured in the snmpTargetAddrTable, and the securityName, and 566 securityLevel parameters are configured in the snmpTargetParamsTable. 567 The default approach is for an administrator to statically 568 preconfigure this information to identify the targets authorized to 569 receive notifications or received proxied messages. Local access 570 control processing needs to be performed by a Notification Originator 571 before notifications are actually sent and this processing is done 572 using the configured securityName. An important characteristic of 573 this is that authorization is done prior to determining if the 574 connection can succeed. Thus the locally configured securityName is 575 entirely trusted within the Notification Originator. 577 The SNMP-TARGET-MIB and NOTIFICATION-MIB MIB modules may be 578 configured using SNMP or other implementation-dependent mechanisms, 579 such as CLI scripting or loading a configuration file. It may be 580 necessary to provide additional implementation-specific configuration 581 of SSH parameters. 583 4. Cached Information and References 585 When performing SNMP processing, there are two levels of state 586 information that may need to be retained: the immediate state linking 587 a request-response pair, and potentially longer-term state relating 588 to transport and security. "Transport Subsystem for the Simple 589 Network Management Protocol" [I-D.ietf-isms-tmsm] defines general 590 requirements for caches and references. 592 This document defines additional cache requirements related to the 593 Secure Shell Transport Model. 595 4.1. Secure Shell Transport Model Cached Information 597 The Secure Shell Transport Model has specific responsibilities 598 regarding the cached information. See the Elements of Procedure in 599 Section 5 for detailed processing instructions on the use of the 600 tmStateReference fields by the SSH Transport Model. 602 4.1.1. tmSecurityName 604 The tmSecurityName MUST be a human-readable name (in snmpAdminString 605 format) representing the identity that has been set according to the 606 procedures in Section 5. The tmSecurityName MUST be constant for all 607 traffic passing through an SSHTM session. Messages MUST NOT be sent 608 through an existing SSH session that was established using a 609 different tmSecurityName. 611 On the SSH server side of a connection: 613 The tmSecurityName should be the SSH user name. How the SSH user 614 name is extracted from the SSH layer is implementation-dependent. 616 The SSH protocol is not always clear on whether the user name 617 field must be filled in, so for some implementations, such as 618 those using GSSAPI authentication, it may be necessary to use a 619 mapping algorithm to transform an SSH identity to a 620 tmSecurityName, or to transform a tmSecurityName to an SSH 621 identity. 623 In other cases the user name may not be verified by the server, so 624 for these implementations, it may be necessary to obtain the user 625 name from other credentials exchanged during the SSH exchange. 627 On the SSH client side of a connection: 629 The tmSecurityName is presented to the SSH Transport Model by the 630 application (possibly because of configuration specified in the 631 SNMP-TARGET-MIB). 633 The securityName MAY be derived from the tmSecurityName by a security 634 model, and MAY be used to configure notifications and access controls 635 in MIB modules. Transport models SHOULD generate a predictable 636 tmSecurityName so operators will know what to use when configuring 637 MIB modules that use securityNames derived from tmSecurityNames. 639 4.1.2. tmSessionID 641 The tmSessionID MUST be recorded per message at the time of receipt. 642 When tmSameSecurity is set, the recorded tmSessionID can be used to 643 determine whether the SSH session available for sending a 644 corresponding outgoing message is the same SSH session as was used 645 when receiving the incoming message (e.g., a response to a request). 647 4.1.3. Session State 649 The per-session state that is referenced by tmStateReference may be 650 saved across multiple messages in a Local Configuration Datastore. 651 Additional session/connection state information might also be stored 652 in a Local Configuration Datastore. 654 5. Elements of Procedure 656 Abstract service interfaces have been defined by [RFC3411] and 657 further augmented by [I-D.ietf-isms-tmsm] to describe the conceptual 658 data flows between the various subsystems within an SNMP entity. The 659 Secure Shell Transport Model uses some of these conceptual data flows 660 when communicating between subsystems. 662 To simplify the elements of procedure, the release of state 663 information is not always explicitly specified. As a general rule, 664 if state information is available when a message gets discarded, the 665 message-state information should also be released, and if state 666 information is available when a session is closed, the session state 667 information should also be released. 669 An error indication in statusInformation will typically include the 670 OID and value for an incremented error counter. This may be 671 accompanied by the requested securityLevel, and the tmStateReference. 672 Per-message context information is not accessible to Transport 673 Models, so for the returned counter OID and value, contextEngine 674 would be set to the local value of snmpEngineID, and contextName to 675 the default context for error counters. 677 5.1. Procedures for an Incoming Message 679 1. The SSH Transport Model queries the SSH engine, in an 680 implementation-dependent manner, to determine the address the 681 message originated from, the user name authenticated by SSH, and 682 a session identifier. 684 2. Determine the tmTransportAddress to be associated with the 685 incoming message: 687 A. If this is a client-side SSH session, then the 688 tmTransportAddress is set to the tmTransportAddress used to 689 establish the session. It MUST exactly include any "user@" 690 prefix associated with the address provided to the 691 openSession() ASI. 693 B. If this is a server-side SSH session and this is the first 694 message received over the session, then the 695 tmTransportAddress is set to the address the message 696 originated from, determined in an implementation-dependent 697 way. This value MUST be constant for the entire SSH session 698 and future messages received MUST result in the 699 tmTransportAddress being set to the same value. 701 C. If this is a server-side SSH session and this is not the 702 first message received over the session, then the 703 tmTransportAddress is set to the previously established 704 tmTransportAddress for the session (the value from step B. 705 determined from a previous incoming message). 707 3. Determine the tmSecurityName to be associated with the incoming 708 message: 710 A. If this is a client-side SSH session, then the tmSecurityName 711 MUST be set to the tmSecurityName used to establish the 712 session. 714 B. If this is a server-side SSH session and this is the first 715 message received over the session, then the tmSecurityName is 716 set to the SSH user name. How the SSH user name is extracted 717 from the SSH layer is implementation-dependent. This value 718 MUST be constant for the entire SSH session and future 719 messages received MUST result in the tmSecurityName being set 720 to the same value. 722 C. If this is a server-side SSH session and this is not the 723 first message received over the session, then the 724 tmSecurityName is set to the previously established 725 tmSecurityName for the session (the value from step B. 726 determined from a previous incoming message). 728 4. Create a tmStateReference cache for subsequent reference to the 729 information. 731 tmTransportDomain = snmpSSHDomain 733 tmTransportAddress = the derived tmTransportAddress from step 734 2. 736 tmSecurityName = The derived tmSecurityName from step 3. 738 tmTransportSecurityLevel = "authPriv" (authentication and 739 confidentiality MUST be used to comply with this transport 740 model.) 742 tmSessionID = an implementation-dependent value that can be 743 used to detect when a session has closed and been replaced by 744 another session. The value in tmStateReference MUST uniquely 745 identify the session over which the message was received. 746 This session identifier MUST NOT be reused until there are no 747 references to it remaining. 749 Then the Transport model passes the message to the Dispatcher using 750 the following ASI: 752 statusInformation = 753 receiveMessage( 754 IN transportDomain -- snmpSSHDomain 755 IN transportAddress -- The tmTransportAddress for the message 756 IN wholeMessage -- the whole SNMP message from SSH 757 IN wholeMessageLength -- the length of the SNMP message 758 IN tmStateReference -- (NEW) transport info 759 ) 761 5.2. Procedures for sending an Outgoing Message 763 The Dispatcher passes the information to the Transport Model using 764 the ASI defined in the transport subsystem: 766 statusInformation = 767 sendMessage( 768 IN destTransportDomain -- transport domain to be used 769 IN destTransportAddress -- transport address to be used 770 IN outgoingMessage -- the message to send 771 IN outgoingMessageLength -- its length 772 IN tmStateReference -- (NEW) transport info 773 ) 775 The SSH Transport Model performs the following tasks. 777 1. If tmStateReference does not refer to a cache containing values 778 for tmTransportDomain, tmTransportAddress, tmSecurityName, 779 tmRequestedSecurityLevel, and tmSameSecurity, then increment the 780 snmpSshtmSessionInvalidCaches counter, discard the message and 781 return the error indication in the statusInformation. Processing 782 of this message stops. 784 2. Extract the tmTransportDomain, tmTransportAddress, 785 tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and 786 tmSessionID from the tmStateReference. 788 3. Identify an SSH session to send the messages over: 790 A. If tmSameSecurity is true and there is no existing session 791 with a matching tmSessionID, tmSecurityName and 792 tmTransportAddress, then increment the 793 snmpSshtmSessionNoSessions counter, discard the message and 794 return the error indication in the statusInformation. 795 Processing of this message stops. 797 B. If there is a session with a matching tmSessionID, 798 tmTransportAddress and tmSecurityName, then select that 799 session. 801 C. If there is a session that matches the tmTransportAddress and 802 tmSecurityName, then select that session. 804 D. If the above steps failed to select a session to use, then 805 call openSession() with the tmStateReference as a parameter. 807 + If openSession fails, then discard the message, release 808 tmStateReference and pass the error indication returned by 809 openSession back to the calling module. Processing stops 810 for this message. 812 + If openSession succeeds, then record the 813 destTransportDomain, destTransportAddress, tmSecurityname 814 and tmSessionID in an implementation-dependent manner. 815 This will be needed when processing an incoming message. 817 4. Pass the wholeMessage to SSH for encapsulation as data in an SSH 818 message over the identified SSH session. Any necessary 819 additional SSH-specific parameters should be provided in an 820 implementation-dependent manner. 822 5.3. Establishing a Session 824 The Secure Shell Transport Model provides the following abstract 825 service interface (ASI) to describe the data passed between the SSH 826 Transport Model and the SSH service. It is an implementation 827 decision how such data is passed. 829 statusInformation = 830 openSession( 831 IN tmStateReference -- transport information to be used 832 OUT tmStateReference -- transport information to be used 833 IN maxMessageSize -- of the sending SNMP entity 834 ) 836 The following describes the procedure to follow to establish a 837 session between a client and server to run SNMP over SSH. This 838 process is used by any SNMP engine establishing a session for 839 subsequent use. 841 This will be done automatically for an SNMP application that 842 initiates a transaction, such as a Command Generator or a 843 Notification Originator or a Proxy Forwarder. 845 1. Increment the snmpSshtmSessionOpens counter. 847 2. Using tmTransportAddress, the client will establish an SSH 848 transport connection using the SSH transport protocol, 849 authenticate the server, and exchange keys for message integrity 850 and encryption. The transportAddress associated with a session 851 MUST remain constant during the lifetime of the SSH session. 852 Implementations may need to cache the transportAddress passed to 853 the openSession API for later use when performing incoming 854 message processing (see section Section 5.1). 856 1. To authenticate the server, the client usually stores 857 (tmTransportAddress, server host public key) pairs in an 858 implementation-dependent manner. 860 2. The other parameters of the transport connection are provided 861 in an implementation-dependent manner. 863 3. If the attempt to establish a connection is unsuccessful, or 864 server authentication fails, then snmpSshtmSessionOpenErrors 865 is incremented, an openSession error indication is returned, 866 and openSession processing stops. 868 3. The client will then invoke an SSH authentication service to 869 authenticate the principal, such as that described in the SSH 870 authentication protocol [RFC4252]. 872 1. If the tmTransportAddress field contains a user-name followed 873 by an '@' character (US-ASCII 0x40), that user-name string 874 should be presented to the ssh server as the "user name" for 875 user authentication purposes. If there is no user-name in 876 the tmTransportAddress then the tmSecurityName should be used 877 as the user-name. 879 2. The credentials used to authenticate the SSH principal are 880 determined in an implementation-dependent manner. 882 3. In an implementation-specific manner, invoke the SSH user 883 authentication service using the calculated user-name. 885 4. If the user authentication is unsuccessful, then the 886 transport connection is closed, the 887 snmpSshtmSessionUserAuthFailures counter is incremented, an 888 error indication is returned to the calling module, and 889 processing stops for this message. 891 4. The client should invoke the "ssh-connection" service (also known 892 as the SSH connection protocol [RFC4254]), and request a channel 893 of type "session". If unsuccessful, the transport connection is 894 closed, the snmpSshtmSessionNoChannels counter is incremented, an 895 error indication is returned to the calling module, and 896 processing stops for this message. 898 5. The client invokes "snmp" as an SSH subsystem, as indicated in 899 the "subsystem" parameter. If unsuccessful, the transport 900 connection is closed, the snmpSshtmSessionNoSubsystems counter is 901 incremented, an error indication is returned to the calling 902 module, and processing stops for this message. 904 In order to allow SNMP traffic to be easily identified and 905 filtered by firewalls and other network devices, servers 906 associated with SNMP entities using the Secure Shell Transport 907 Model MUST default to providing access to the "snmp" SSH 908 subsystem if the SSH session is established using the IANA- 909 assigned TCP ports (YYY and ZZZ). Servers SHOULD be configurable 910 to allow access to the SNMP SSH subsystem over other ports. 912 6. Set tmSessionID in the tmStateReference cache to an 913 implementation-dependent value to identify the session. 915 7. The tmSecurityName used to establish the SSH session must be the 916 only tmSecurityName used with the session. Incoming messages for 917 the session MUST be associated with this tmSecurityName value. 918 How this is accomplished is implementation-dependent. 920 5.4. Closing a Session 922 The Secure Shell Transport Model provides the following ASI to close 923 a session: 925 statusInformation = 926 closeSession( 927 IN tmSessionID -- session ID of session to be closed 928 ) 930 The following describes the procedure to follow to close a session 931 between a client and server. This process is followed by any SNMP 932 engine to close an SSH session. It is implementation-dependent when 933 a session should be closed. The calling code should release the 934 associated tmStateReference. 936 1. Increment the snmpSshtmSessionCloses counter. 938 2. If there is no session corresponding to tmSessionID, then 939 closeSession processing is completed. 941 3. Have SSH close the session associated with tmSessionID. 943 6. MIB Module Overview 945 This MIB module provides management of the Secure Shell Transport 946 Model. It defines an OID to identify the SNMP-over-SSH transport 947 domain, a textual convention for SSH Addresses and several statistics 948 counters. 950 6.1. Structure of the MIB Module 952 Objects in this MIB module are arranged into subtrees. Each subtree 953 is organized as a set of related objects. The overall structure and 954 assignment of objects to their subtrees, and the intended purpose of 955 each subtree, is shown below. 957 6.2. Textual Conventions 959 Generic and Common Textual Conventions used in this document can be 960 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 962 6.3. Relationship to Other MIB Modules 964 Some management objects defined in other MIB modules are applicable 965 to an entity implementing the SSH Transport Model. In particular, it 966 is assumed that an entity implementing the SNMP-SSH-TM-MIB will 967 implement the SNMPv2-MIB [RFC3418], and the SNMP-FRAMEWORK-MIB 968 [RFC3411]. It is expected that an entity implementing this MIB will 969 also support the Transport Security Model 970 [I-D.ietf-isms-transport-security-model], and therefore implement the 971 SNMP-TSM-MIB. 973 This MIB module is for monitoring SSH Transport Model information. 975 6.3.1. MIB Modules Required for IMPORTS 977 The following MIB module imports items from [RFC2578], [RFC2579], 978 [RFC2580]. 980 This MIB module also references [RFC1033], , [RFC4252][RFC3490] and 981 [RFC3986] 983 This document uses TDomain textual conventions for the SNMP-internal 984 MIB modules defined here for compatibility with the RFC3413 MIB 985 modules and the RFC3411 Abstract Service Interfaces. 987 7. MIB Module Definition 989 SNMP-SSH-TM-MIB DEFINITIONS ::= BEGIN 991 IMPORTS 992 MODULE-IDENTITY, OBJECT-TYPE, 993 OBJECT-IDENTITY, mib-2, snmpDomains, 994 Counter32 995 FROM SNMPv2-SMI -- RFC 2578 996 TEXTUAL-CONVENTION 997 FROM SNMPv2-TC -- RFC 2579 998 MODULE-COMPLIANCE, OBJECT-GROUP 999 FROM SNMPv2-CONF -- RFC 2580 1000 ; 1002 snmpSshtmMIB MODULE-IDENTITY 1003 LAST-UPDATED "200903090000Z" 1004 ORGANIZATION "ISMS Working Group" 1005 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 1006 Subscribe: isms-request@lists.ietf.org 1008 Chairs: 1009 Juergen Quittek 1010 NEC Europe Ltd. 1011 Network Laboratories 1012 Kurfuersten-Anlage 36 1013 69115 Heidelberg 1014 Germany 1015 +49 6221 90511-15 1016 quittek@netlab.nec.de 1018 Juergen Schoenwaelder 1019 Jacobs University Bremen 1020 Campus Ring 1 1021 28725 Bremen 1022 Germany 1023 +49 421 200-3587 1024 j.schoenwaelder@jacobs-university.de 1026 Co-editors: 1027 David Harrington 1028 Huawei Technologies USA 1029 1700 Alma Drive 1030 Plano Texas 75075 1031 USA 1032 +1 603-436-8634 1033 ietfdbh@comcast.net 1035 Joseph Salowey 1036 Cisco Systems 1037 2901 3rd Ave 1038 Seattle, WA 98121 1039 USA 1040 jsalowey@cisco.com 1042 Wes Hardaker 1043 Sparta, Inc. 1044 P.O. Box 382 1045 Davis, CA 95617 1046 USA 1047 +1 530 792 1913 1048 ietf@hardakers.net 1049 " 1050 DESCRIPTION "The Secure Shell Transport Model MIB 1052 Copyright (c) 2009 IETF Trust and the persons identified as 1053 authors of the MIB module. All rights reserved. 1055 Redistribution and use in source and binary forms, with or without 1056 modification, are permitted provided that the following conditions 1057 are met: 1058 - Redistributions of source code must retain the above copyright 1059 notice, this list of conditions and the following disclaimer. 1060 - Redistributions in binary form must reproduce the above 1061 copyright notice, this list of conditions and the following 1062 disclaimer in the documentation and/or other materials provided 1063 with the distribution. 1064 - Neither the name of Internet Society, IETF or IETF Trust, nor the 1065 names of specific contributors, may be used to endorse or promote 1066 products derived from this software without specific prior written 1067 permission. 1069 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 1070 CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, 1071 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 1072 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 1073 DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR 1074 CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1075 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1076 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF 1077 USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 1078 AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 1079 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 1080 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1081 POSSIBILITY OF SUCH DAMAGE. 1083 This version of this MIB module is part of RFC XXXX; 1084 see the RFC itself for full legal notices. 1085 -- NOTE to RFC editor: replace XXXX with actual RFC number 1086 -- for this document and remove this note 1087 " 1089 REVISION "200903090000Z" 1090 DESCRIPTION "The initial version, published in RFC XXXX. 1091 -- NOTE to RFC editor: replace XXXX with actual RFC number 1092 -- for this document and remove this note 1093 " 1095 ::= { mib-2 xxxx } 1096 -- RFC Ed.: replace xxxx with IANA-assigned number and 1097 -- remove this note 1099 -- ---------------------------------------------------------- -- 1100 -- subtrees in the SNMP-SSH-TM-MIB 1101 -- ---------------------------------------------------------- -- 1103 snmpSshtmNotifications OBJECT IDENTIFIER ::= { snmpSshtmMIB 0 } 1104 snmpSshtmObjects OBJECT IDENTIFIER ::= { snmpSshtmMIB 1 } 1105 snmpSshtmConformance OBJECT IDENTIFIER ::= { snmpSshtmMIB 2 } 1107 -- ------------------------------------------------------------- 1108 -- Objects 1109 -- ------------------------------------------------------------- 1111 snmpSSHDomain OBJECT-IDENTITY 1112 STATUS current 1113 DESCRIPTION 1114 "The SNMP over SSH transport domain. The corresponding 1115 transport address is of type SnmpSSHAddress. 1117 When an SNMP entity uses the snmpSSHDomain transport 1118 model, it must be capable of accepting messages up to 1119 and including 8192 octets in size. Implementation of 1120 larger values is encouraged whenever possible. 1122 The securityName prefix to be associated with the 1123 snmpSSHDomain is 'ssh'. This prefix may be used by security 1124 models or other components to identify which secure transport 1125 infrastructure authenticated a securityName." 1126 ::= { snmpDomains yy } 1128 -- RFC Ed.: replace yy with IANA-assigned number and 1129 -- remove this note 1131 -- RFC Ed.: replace 'ssh' with the actual IANA assigned prefix string 1132 -- if 'ssh' is not assigned to this document. 1134 SnmpSSHAddress ::= TEXTUAL-CONVENTION 1135 DISPLAY-HINT "1a" 1136 STATUS current 1137 DESCRIPTION 1138 "Represents either a hostname or IP address, along with a port 1139 number and an optional user name. 1141 The beginning of the address specification may contain a 1142 user name followed by an '@' (US-ASCII character 0x40). This 1143 portion of the address will indicate the user name that should 1144 be used when authenticating to an SSH server. The user name 1145 must be encoded in UTF-8 (per RFC4252). If missing, the 1146 SNMP securityName should be used. After the optional user name 1147 field and '@' character comes the hostname or IP address. 1149 The hostname is always in US-ASCII (as per 1033), 1150 Internationalized hostnames are encoded in US-ASCII as 1151 specified in RFC 3490. The hostname is followed by a colon 1152 ':' (US-ASCII character 0x3A) and a decimal port number in 1153 US-ASCII. The name SHOULD be fully qualified whenever 1154 possible. 1156 An IPv4 address must be in dotted decimal format followed 1157 by a colon ':' (US-ASCII character 0x3A) and a decimal port 1158 number in US-ASCII. 1160 An IPv6 address must be in colon separated format, surrounded 1161 by square brackets ('[' US-ASCII character 0x5B and ']' 1162 US-ASCII character 0x5D), followed by a colon ':' (US-ASCII 1163 character 0x3A) and a decimal port number in US-ASCII. 1165 Values of this textual convention might not be directly useable 1166 as transport-layer addressing information, and may require 1167 runtime resolution. As such, applications that write them 1168 must be prepared for handling errors if such values are 1169 not supported, or cannot be resolved (if resolution occurs 1170 at the time of the management operation). 1172 The DESCRIPTION clause of TransportAddress objects that may 1173 have snmpSSHAddress values must fully describe how (and 1174 when) such names are to be resolved to IP addresses and vice 1175 versa. 1177 This textual convention SHOULD NOT be used directly in 1178 object definitions since it restricts addresses to a 1179 specific format. However, if it is used, it MAY be used 1180 either on its own or in conjunction with 1181 TransportAddressType or TransportDomain as a pair. 1183 When this textual convention is used as a syntax of an 1184 index object, there may be issues with the limit of 128 1185 sub-identifiers specified in SMIv2, STD 58. It is 1186 RECOMMENDED that all MIB documents using this textual 1187 convention make explicit any limitations on index 1188 component lengths that management software must observe. 1189 This may be done either by including SIZE constraints on 1190 the index components or by specifying applicable 1191 constraints in the conceptual row DESCRIPTION clause or 1192 in the surrounding documentation. 1193 " 1194 REFERENCE 1195 "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE 1196 RFC 3490: Internationalizing Domain Names in Applications 1197 RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 1198 RFC 4252: The Secure Shell (SSH) Authentication Protocol" 1199 SYNTAX OCTET STRING (SIZE (1..255)) 1201 -- The snmpSshtmSession Group 1203 snmpSshtmSession OBJECT IDENTIFIER ::= { snmpSshtmObjects 1 } 1204 snmpSshtmSessionOpens OBJECT-TYPE 1205 SYNTAX Counter32 1206 MAX-ACCESS read-only 1207 STATUS current 1208 DESCRIPTION "The number of times an openSession() request has been 1209 executed as an SSH client, whether it succeeded or 1210 failed. 1211 " 1212 ::= { snmpSshtmSession 1 } 1214 snmpSshtmSessionCloses OBJECT-TYPE 1215 SYNTAX Counter32 1216 MAX-ACCESS read-only 1217 STATUS current 1218 DESCRIPTION "The number of times a closeSession() request has been 1219 executed as an SSH client, whether it succeeded or 1220 failed. 1221 " 1222 ::= { snmpSshtmSession 2 } 1224 snmpSshtmSessionOpenErrors OBJECT-TYPE 1225 SYNTAX Counter32 1226 MAX-ACCESS read-only 1227 STATUS current 1228 DESCRIPTION "The number of times an openSession() request 1229 failed to open a transport connection, or failed to 1230 authenticate the server. 1231 " 1232 ::= { snmpSshtmSession 3 } 1234 snmpSshtmSessionUserAuthFailures OBJECT-TYPE 1235 SYNTAX Counter32 1236 MAX-ACCESS read-only 1237 STATUS current 1238 DESCRIPTION "The number of times an openSession() request 1239 failed to open a session as a SSH client due to user 1240 authentication failures. 1241 " 1242 ::= { snmpSshtmSession 4 } 1244 snmpSshtmSessionNoChannels OBJECT-TYPE 1245 SYNTAX Counter32 1246 MAX-ACCESS read-only 1247 STATUS current 1248 DESCRIPTION "The number of times an openSession() request 1249 failed to open a session as a SSH client due to 1250 channel open failures. 1251 " 1253 ::= { snmpSshtmSession 5 } 1255 snmpSshtmSessionNoSubsystems OBJECT-TYPE 1256 SYNTAX Counter32 1257 MAX-ACCESS read-only 1258 STATUS current 1259 DESCRIPTION "The number of times an openSession() request 1260 failed to open a session as a SSH client due to 1261 inability to connect to the requested subsystem. 1262 " 1263 ::= { snmpSshtmSession 6 } 1265 snmpSshtmSessionNoSessions OBJECT-TYPE 1266 SYNTAX Counter32 1267 MAX-ACCESS read-only 1268 STATUS current 1269 DESCRIPTION "The number of times an outgoing message 1270 was dropped because the same 1271 session was no longer available. 1272 " 1273 ::= { snmpSshtmSession 7 } 1275 snmpSshtmSessionInvalidCaches OBJECT-TYPE 1276 SYNTAX Counter32 1277 MAX-ACCESS read-only 1278 STATUS current 1279 DESCRIPTION "The number of outgoing messages dropped because the 1280 tmStateReference referred to an invalid cache. 1281 " 1282 ::= { snmpSshtmSession 8 } 1284 -- ************************************************ 1285 -- snmpSshtmMIB - Conformance Information 1286 -- ************************************************ 1288 snmpSshtmCompliances OBJECT IDENTIFIER ::= { snmpSshtmConformance 1 } 1290 snmpSshtmGroups OBJECT IDENTIFIER ::= { snmpSshtmConformance 2 } 1292 -- ************************************************ 1293 -- Compliance statements 1294 -- ************************************************ 1296 snmpSshtmCompliance MODULE-COMPLIANCE 1297 STATUS current 1299 DESCRIPTION "The compliance statement for SNMP engines that 1300 support the SNMP-SSH-TM-MIB" 1302 MODULE 1303 MANDATORY-GROUPS { snmpSshtmGroup } 1304 ::= { snmpSshtmCompliances 1 } 1306 -- ************************************************ 1307 -- Units of conformance 1308 -- ************************************************ 1309 snmpSshtmGroup OBJECT-GROUP 1310 OBJECTS { 1311 snmpSshtmSessionOpens, 1312 snmpSshtmSessionCloses, 1313 snmpSshtmSessionOpenErrors, 1314 snmpSshtmSessionUserAuthFailures, 1315 snmpSshtmSessionNoChannels, 1316 snmpSshtmSessionNoSubsystems, 1317 snmpSshtmSessionNoSessions, 1318 snmpSshtmSessionInvalidCaches 1319 } 1320 STATUS current 1321 DESCRIPTION "A collection of objects for maintaining 1322 information of an SNMP engine which implements the 1323 SNMP Secure Shell Transport Model. 1324 " 1326 ::= { snmpSshtmGroups 2 } 1328 END 1330 8. Operational Considerations 1332 The SSH Transport Model will likely not work in conditions where 1333 remote access to the CLI has stopped working. The SSH Transport 1334 Model assumes that TCP and IP continue to operate correctly between 1335 the communicating nodes. Failures in either node, death of the 1336 deamon serving the communication, routing problems in the network 1337 between, firewalls that block the traffic, and other problems can 1338 prevent the SSH Transport Model from working. In situations where 1339 management access has to be very reliable, operators should consider 1340 mitigating measures. These measures may include dedicated 1341 management-only networks, point-to-point links, and the ability to 1342 use alternate protocols and transports. 1344 To have SNMP properly utilize the security services provided by SSH, 1345 the SSH Transport Model MUST be used with a Security Model that knows 1346 how to process a tmStateReference, such as the Transport Security 1347 Model for SNMP [I-D.ietf-isms-transport-security-model]. 1349 If the SSH Transport Model is configured to utilize AAA services, 1350 operators should consider configuring support for local 1351 authentication mechanisms, such as local passwords, so SNMP can 1352 continue operating during times of network stress. 1354 The SSH protocol has its own window mechanism, defined in RFC 4254. 1355 The SSH specifications leave it open when window adjustments messages 1356 should be created, and some implementations send these whenever 1357 received data has been passed to the application. There are 1358 noticeable bandwidth and processing overheads to handling such window 1359 adjustment messages, which can be avoided by sending them less 1360 frequently. 1362 The SSH protocol requires the execution of CPU intensive calculations 1363 to establish a session key during session establishment. This means 1364 that short lived sessions become computationally expensive compared 1365 to USM, which does not have a notion of a session key. Other 1366 transport security protocols such as TLS support a session resumption 1367 feature that allows reusing a cached session key. Such a mechanism 1368 does not exist for SSH and thus SNMP applications should keep SSH 1369 sessions for longer time periods. 1371 To initiate SSH connections, an entity must be configured with SSH 1372 client credentials plus information to authenticate the server. 1373 While hosts are often configured to be SSH clients, most 1374 internetworking devices are not. To send notifications over SSHTM, 1375 the internetworking device will need to be configured as an SSH 1376 client. How this credential configuration is done is implementation 1377 and deployment specific. 1379 9. Security Considerations 1381 This document describes a transport model that permits SNMP to 1382 utilize SSH security services. The security threats and how the SSH 1383 Transport Model mitigates those threats is covered in detail 1384 throughout this memo. 1386 The SSH Transport Model relies on SSH mutual authentication, binding 1387 of keys, confidentiality and integrity. Any authentication method 1388 that meets the requirements of the SSH architecture will provide the 1389 properties of mutual authentication and binding of keys. 1391 SSHv2 provides Perfect Forward Security (PFS) for encryption keys. 1392 PFS is a major design goal of SSH, and any well-designed keyex 1393 algorithm will provide it. 1395 The security implications of using SSH are covered in [RFC4251]. 1397 The SSH Transport Model has no way to verify that server 1398 authentication was performed, to learn the host's public key in 1399 advance, or verify that the correct key is being used. The SSH 1400 Transport Model simply trusts that these are properly configured by 1401 the implementer and deployer. 1403 SSH provides the "none" userauth method. The SSH Transport Model 1404 MUST NOT be used with an SSH connection with the "none" userauth 1405 method. While SSH does support turning off confidentiality and 1406 integrity, they MUST NOT be turned off when used with the SSH 1407 Transport Model. 1409 The SSH protocol is not always clear on whether the user name field 1410 must be filled in, so for some implementations, such as those using 1411 GSSAPI authentication, it may be necessary to use a mapping algorithm 1412 to transform an SSH identity to a tmSecurityName, or to transform a 1413 tmSecurityName to an SSH identity. 1415 In other cases the user name may not be verified by the server, so 1416 for these implementations, it may be necessary to obtain the user 1417 name from other credentials exchanged during the SSH exchange. 1419 9.1. Skipping Public Key Verification 1421 Most key exchange algorithms are able to authenticate the SSH 1422 server's identity to the client. However, for the common case of DH 1423 signed by public keys, this requires the client to know the host's 1424 public key a priori and to verify that the correct key is being used. 1425 If this step is skipped, then authentication of the SSH server to the 1426 SSH client is not done. Data confidentiality and data integrity 1427 protection to the server still exist, but these are of dubious value 1428 when an attacker can insert himself between the client and the real 1429 SSH server. Note that some userauth methods may defend against this 1430 situation, but many of the common ones (including password and 1431 keyboard-interactive) do not, and in fact depend on the fact that the 1432 server's identity has been verified (so passwords are not disclosed 1433 to an attacker). 1435 SSH MUST NOT be configured to skip public key verification for use 1436 with the SSH Transport Model. 1438 9.2. Notification Authorization Considerations 1440 SNMP Notifications are authorized to be sent to a receiver based on 1441 the securityName used by the notification originator's SNMP engine. 1442 This authorization is performed before the message is actually sent 1443 and before the credentials of the remote receiver have been verified. 1444 It is thus critical that the credentials presented by a notification 1445 receiver MUST match the expected value(s) for a given transport 1446 address and that ownership of the credentials MUST be properly 1447 cryptographically verified. 1449 9.3. SSH User and Key Selection 1451 If a "user@" prefix is used within a SnmpSSHAddress value to specify 1452 a SSH user name to use for authentication then the key presented to 1453 the remote entity MUST be the key expected by the server for the 1454 "user". This may be different than a locally cached key identified 1455 by the securityName value. 1457 9.4. Conceptual Differences Between USM and SSHTM 1459 The User Based Security Model [RFC3414] employed symmetric 1460 cryptography and user naming conventions. SSH employs an asymmetric 1461 cryptographic and naming model. Unlike USM, cryptographic keys will 1462 be different on both sides of the SSH connection. Both sides are 1463 responsible for verifying that the remote entity presents the right 1464 key. The optional "user@" prefix component of the SnmpSSHAddress 1465 Textual Convention allows the client SNMP stack to associate the 1466 connection with a securityName that may be different than the SSH 1467 user name presented to the SSH server. 1469 9.5. The 'none' MAC Algorithm 1471 SSH provides the "none" MAC algorithm, which would allow you to turn 1472 off data integrity while maintaining confidentiality. However, if 1473 you do this, then an attacker may be able to modify the data in 1474 flight, which means you effectively have no authentication. 1476 SSH MUST NOT be configured using the "none" MAC algorithm for use 1477 with the SSH Transport Model. 1479 9.6. Use with SNMPv1/v2c Messages 1481 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 1482 74) [RFC3584] always select the SNMPv1 or SNMPv2c Security Models 1483 respectively. Both of these, and the User-based Security Model 1484 typically used with SNMPv3, derive the securityName and securityLevel 1485 from the SNMP message received, even when the message was received 1486 over a secure transport. Access control decisions are therefore made 1487 based on the contents of the SNMP message, rather than using the 1488 authenticated identity and securityLevel provided by the SSH 1489 Transport Model. 1491 9.7. MIB Module Security 1493 There are no management objects defined in this MIB module that have 1494 a MAX-ACCESS clause of read-write and/or read-create. So, if this 1495 MIB module is implemented correctly, then there is no risk that an 1496 intruder can alter or create any management objects of this MIB 1497 module via direct SNMP SET operations. 1499 Some of the readable objects in this MIB module (i.e., objects with a 1500 MAX-ACCESS other than not-accessible) may be considered sensitive or 1501 vulnerable in some network environments. It is thus important to 1502 control even GET and/or NOTIFY access to these objects and possibly 1503 to even encrypt the values of these objects when sending them over 1504 the network via SNMP. These are the tables and objects and their 1505 sensitivity/vulnerability: 1507 o The information in the snmpSshtmSession group is generated locally 1508 when a client session is being opened or closed. This information 1509 can reflect the configured capabilities of a remote SSH server, 1510 which could be helpful to an attacker for focusing an attack. 1512 SNMP versions prior to SNMPv3 did not include adequate security. 1513 Even if the network itself is secure (for example by using IPSec or 1514 SSH), even then, there is no control as to who on the secure network 1515 is allowed to access and GET/SET (read/change/create/delete) the 1516 objects in this MIB module. 1518 It is RECOMMENDED that implementers consider the security features as 1519 provided by the SNMPv3 framework (see [RFC3410] section 8), including 1520 full support for cryptographic mechanisms for authentication and 1521 privacy, such as those found in the User-based Security Model 1522 [RFC3414], the Transport Security Model 1523 [I-D.ietf-isms-transport-security-model] and the SSH Transport Model 1524 described in this document. 1526 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1527 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1528 enable cryptographic security. It is then a customer/operator 1529 responsibility to ensure that the SNMP entity giving access to an 1530 instance of this MIB module is properly configured to give access to 1531 the objects only to those principals (users) that have legitimate 1532 rights to indeed GET or SET (change/create/delete) them. 1534 10. IANA Considerations 1536 IANA is requested to assign: 1538 1. two TCP registered port numbers in the 1539 http://www.iana.org/assignments/port-numbers registry which will 1540 be the default ports for SNMP over an SSH Transport Model as 1541 defined in this document, and SNMP over an SSH Transport Model 1542 for notifications as defined in this document. It would be good 1543 if the assigned keywords were "snmpssh" and "snmpssh-trap" and 1544 the port numbers were x161 and x162 (where x represents a number, 1545 such as '5' or '6', so that we end up with ports 5161 and 5162, 1546 or 6161 and 6162). 1548 2. an SMI number under mib-2, for the MIB module in this document, 1550 3. an SMI number under snmpDomains, for the snmpSSHDomain, 1552 4. "ssh" as the corresponding prefix for the snmpSSHDomain in the 1553 SNMP Transport Model registry; defined in [I-D.ietf-isms-tmsm] 1555 5. "snmp" as an SSH Subsystem Name in the 1556 http://www.iana.org/assignments/ssh-parameters registry. 1558 -- note to RFC editor -- Please replace YYY and ZZZ in this document 1559 with the assigned port numbers and remove this note. 1561 11. Acknowledgements 1563 The editors would like to thank Jeffrey Hutzelman for sharing his SSH 1564 insights, and Dave Shield for an outstanding job wordsmithing the 1565 existing document to improve organization and clarity. 1567 Additionally, helpful document reviews were received from: Juergen 1568 Schoenwaelder. 1570 12. References 1572 12.1. Normative References 1574 [RFC1033] Lottor, M., "Domain 1575 administrators operations 1576 guide", RFC 1033, 1577 November 1987. 1579 [RFC2119] Bradner, S., "Key words for 1580 use in RFCs to Indicate 1581 Requirement Levels", 1582 BCP 14, RFC 2119, 1583 March 1997. 1585 [RFC2578] McCloghrie, K., Ed., 1586 Perkins, D., Ed., and J. 1587 Schoenwaelder, Ed., 1588 "Structure of Management 1589 Information Version 2 1590 (SMIv2)", STD 58, RFC 2578, 1591 April 1999. 1593 [RFC2579] McCloghrie, K., Ed., 1594 Perkins, D., Ed., and J. 1595 Schoenwaelder, Ed., 1596 "Textual Conventions for 1597 SMIv2", STD 58, RFC 2579, 1598 April 1999. 1600 [RFC2580] McCloghrie, K., Perkins, 1601 D., and J. Schoenwaelder, 1602 "Conformance Statements for 1603 SMIv2", STD 58, RFC 2580, 1604 April 1999. 1606 [RFC3411] Harrington, D., Presuhn, 1607 R., and B. Wijnen, "An 1608 Architecture for Describing 1609 Simple Network Management 1610 Protocol (SNMP) Management 1611 Frameworks", STD 62, 1612 RFC 3411, December 2002. 1614 [RFC3413] Levi, D., Meyer, P., and B. 1615 Stewart, "Simple Network 1616 Management Protocol (SNMP) 1617 Applications", STD 62, 1618 RFC 3413, December 2002. 1620 [RFC3414] Blumenthal, U. and B. 1621 Wijnen, "User-based 1622 Security Model (USM) for 1623 version 3 of the Simple 1624 Network Management Protocol 1625 (SNMPv3)", STD 62, 1626 RFC 3414, December 2002. 1628 [RFC3418] Presuhn, R., "Management 1629 Information Base (MIB) for 1630 the Simple Network 1631 Management Protocol 1632 (SNMP)", STD 62, RFC 3418, 1633 December 2002. 1635 [RFC3490] Faltstrom, P., Hoffman, P., 1636 and A. Costello, 1637 "Internationalizing Domain 1638 Names in Applications 1639 (IDNA)", RFC 3490, 1640 March 2003. 1642 [RFC3584] Frye, R., Levi, D., 1643 Routhier, S., and B. 1644 Wijnen, "Coexistence 1645 between Version 1, Version 1646 2, and Version 3 of the 1647 Internet-standard Network 1648 Management Framework", 1649 BCP 74, RFC 3584, 1650 August 2003. 1652 [RFC4251] Ylonen, T. and C. Lonvick, 1653 "The Secure Shell (SSH) 1654 Protocol Architecture", 1655 RFC 4251, January 2006. 1657 [RFC4252] Ylonen, T. and C. Lonvick, 1658 "The Secure Shell (SSH) 1659 Authentication Protocol", 1660 RFC 4252, January 2006. 1662 [RFC4253] Ylonen, T. and C. Lonvick, 1663 "The Secure Shell (SSH) 1664 Transport Layer Protocol", 1665 RFC 4253, January 2006. 1667 [RFC4254] Ylonen, T. and C. Lonvick, 1668 "The Secure Shell (SSH) 1669 Connection Protocol", 1670 RFC 4254, January 2006. 1672 [I-D.ietf-isms-tmsm] Harrington, D. and J. 1673 Schoenwaelder, "Transport 1674 Subsystem for the Simple 1675 Network Management Protocol 1676 (SNMP)", 1677 draft-ietf-isms-tmsm-18 1678 (work in progress), 1679 May 2009. 1681 12.2. Informative References 1683 [RFC1994] Simpson, W., "PPP Challenge 1684 Handshake Authentication 1685 Protocol (CHAP)", RFC 1994, 1686 August 1996. 1688 [RFC2865] Rigney, C., Willens, S., 1689 Rubens, A., and W. Simpson, 1690 "Remote Authentication Dial 1691 In User Service (RADIUS)", 1692 RFC 2865, June 2000. 1694 [RFC3410] Case, J., Mundy, R., 1695 Partain, D., and B. 1696 Stewart, "Introduction and 1697 Applicability Statements 1698 for Internet-Standard 1699 Management Framework", 1700 RFC 3410, December 2002. 1702 [RFC3588] Calhoun, P., Loughney, J., 1703 Guttman, E., Zorn, G., and 1704 J. Arkko, "Diameter Base 1705 Protocol", RFC 3588, 1706 September 2003. 1708 [RFC3986] Berners-Lee, T., Fielding, 1709 R., and L. Masinter, 1710 "Uniform Resource 1711 Identifier (URI): Generic 1712 Syntax", STD 66, RFC 3986, 1713 January 2005. 1715 [RFC4256] Cusack, F. and M. Forssen, 1716 "Generic Message Exchange 1717 Authentication for the 1718 Secure Shell Protocol 1719 (SSH)", RFC 4256, 1720 January 2006. 1722 [RFC4462] Hutzelman, J., Salowey, J., 1723 Galbraith, J., and V. 1724 Welch, "Generic Security 1725 Service Application Program 1726 Interface (GSS-API) 1727 Authentication and Key 1728 Exchange for the Secure 1729 Shell (SSH) Protocol", 1730 RFC 4462, May 2006. 1732 [RFC5090] Sterman, B., Sadolevsky, 1733 D., Schwartz, D., Williams, 1734 D., and W. Beck, "RADIUS 1735 Extension for Digest 1736 Authentication", RFC 5090, 1737 February 2008. 1739 [RFC4742] Wasserman, M. and T. 1740 Goddard, "Using the NETCONF 1741 Configuration Protocol over 1742 Secure SHell (SSH)", 1743 RFC 4742, December 2006. 1745 [I-D.ietf-isms-transport-security-model] Harrington, D. and W. 1746 Hardaker, "Transport 1747 Security Model for SNMP", d 1748 raft-ietf-isms-transport- 1749 security-model-14 (work in 1750 progress), May 2009. 1752 Authors' Addresses 1754 David Harrington 1755 Huawei Technologies (USA) 1756 1700 Alma Dr. Suite 100 1757 Plano, TX 75075 1758 USA 1760 Phone: +1 603 436 8634 1761 EMail: dharrington@huawei.com 1763 Joseph Salowey 1764 Cisco Systems 1765 2901 3rd Ave 1766 Seattle, WA 98121 1767 USA 1769 EMail: jsalowey@cisco.com 1770 Wes Hardaker 1771 Sparta, Inc. 1772 P.O. Box 382 1773 Davis, CA 95617 1774 US 1776 Phone: +1 530 792 1913 1777 EMail: ietf@hardakers.net