idnits 2.17.1 draft-harrington-isms-secshell-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1945. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 16, 2005) is 6795 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) == Missing Reference: 'RFC2119' is mentioned on line 287, but not defined == Missing Reference: 'RFC 3588' is mentioned on line 490, but not defined ** Obsolete undefined reference: RFC 3588 (Obsoleted by RFC 6733) == Missing Reference: 'RFC1994' is mentioned on line 493, but not defined == Missing Reference: 'RFC3416' is mentioned on line 1042, but not defined == Missing Reference: 'RFC3418' is mentioned on line 1555, but not defined == Unused Reference: 'RFC3417' is defined on line 1790, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 3430 -- Unexpected draft version: The latest known version of draft-schoenw-snmp-tlsm is -02, but you're referring to -04. -- Possible downref: Normative reference to a draft: ref. 'TMSM' == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-04 == Outdated reference: A later version (-06) exists of draft-ietf-netconf-ssh-04 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harrington 3 Internet-Draft Effective Software 4 Expires: March 20, 2006 J. Schoenwaelder 5 International University Bremen 6 J. Salowey 7 Cisco Systems 8 September 16, 2005 10 Secure Shell Security Model for SNMP 11 draft-harrington-isms-secshell-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 20, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This memo describes a Security Model for the Simple Network 45 Management Protocol, using the Secure Shell protocol within a 46 Transport Mapping. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.2 The Internet-Standard Management Framework . . . . . . . . 6 53 1.3 The Secure Shell Protocol . . . . . . . . . . . . . . . . 6 54 1.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 55 1.5 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 56 2. How SSHSM Fits into the TMSM Architecture . . . . . . . . . . 7 57 2.1 Security Capabilities of this Model . . . . . . . . . . . 8 58 2.1.1 Threats . . . . . . . . . . . . . . . . . . . . . . . 8 59 2.1.2 Sessions . . . . . . . . . . . . . . . . . . . . . . . 11 60 2.1.3 Authentication Protocol . . . . . . . . . . . . . . . 11 61 2.1.4 Privacy Protocol . . . . . . . . . . . . . . . . . . . 12 62 2.1.5 Protection against Message Replay, Delay and 63 Redirection . . . . . . . . . . . . . . . . . . . . . 12 64 2.1.6 Security Protocol Requirements . . . . . . . . . . . . 12 65 2.2 Security Parameter Passing Requirement . . . . . . . . . . 14 66 2.3 Requirements for Notifications . . . . . . . . . . . . . . 15 67 2.4 Scenario Diagrams . . . . . . . . . . . . . . . . . . . . 15 68 2.4.1 Command Generator or Notification Originator . . . . . 15 69 2.4.2 Command Responder . . . . . . . . . . . . . . . . . . 16 70 2.5 Abstract Service Interfaces . . . . . . . . . . . . . . . 17 71 3. RFC 3411 Abstract Service Interfaces . . . . . . . . . . . . . 18 72 3.1 Public Abstract Service Interfaces . . . . . . . . . . . . 18 73 3.1.1 Public ASIs for Outgoing Messages . . . . . . . . . . 18 74 3.1.2 Public ASIs for Incoming Messages . . . . . . . . . . 20 75 3.2 Private Abstract Service Interfaces . . . . . . . . . . . 21 76 4. SNMP Messages Using this Security Model . . . . . . . . . . . 22 77 4.1 SNMPv1 and SNMPv2c Messages Using this Security Model . . 22 78 4.2 SNMPv3 Messages Using this Security Model . . . . . . . . 23 79 4.2.1 msgGlobalData . . . . . . . . . . . . . . . . . . . . 25 80 4.3 Passing Security Parameters . . . . . . . . . . . . . . . 26 81 4.3.1 Transport Session Parameters . . . . . . . . . . . . . 27 82 4.3.2 [todo] Using Local Accounts to Authenticate Users . . 28 83 4.3.3 [todo] Using RADIUS Accounts to Authenticate Users . . 28 84 4.3.4 securityStateReference for SSHSM . . . . . . . . . . . 28 85 4.4 MIB Module for SSH Security Model . . . . . . . . . . . . 28 86 4.5 [todo] Notifications . . . . . . . . . . . . . . . . . . . 28 87 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 29 88 5.1 Establishing a Session . . . . . . . . . . . . . . . . . . 29 89 5.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 31 90 5.3 Generating an Outgoing SNMP Message . . . . . . . . . . . 32 91 5.4 Sending an Outgoing SNMP Message to the Network . . . . . 34 92 5.5 [todo] Prepare Data Elements from an Incoming SNMP 93 Message . . . . . . . . . . . . . . . . . . . . . . . . . 35 94 5.6 Processing an Incoming SNMP Message . . . . . . . . . . . 35 95 6. MIB module definition . . . . . . . . . . . . . . . . . . . . 37 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 100 10.1 Normative References . . . . . . . . . . . . . . . . . . . 40 101 10.2 Informative References . . . . . . . . . . . . . . . . . . 42 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42 103 A. Change Log from the first revision of -00- . . . . . . . . . . 43 104 Intellectual Property and Copyright Statements . . . . . . . . 44 106 1. Introduction 108 This memo describes a Security Model for the Simple Network 109 Management Protocol, using the Secure Shell protocol within a 110 Transport Mapping. 112 It is important to understand the SNMP architecture and the 113 terminology of the architecture to understand where the Security 114 Model described in this memo fits into the architecture and interacts 115 with other subsystems within the architecture. The reader is 116 expected to have read and understood the description of the SNMP 117 architecture, as defined in [RFC3411],and the "Transport Mapping 118 Security Model (TMSM) for the Simple Network Management Protocol" 119 architecture extension defined in [TMSM], which enables the use of 120 external "lower layer" protocols to provide message security, tied 121 into the SNMP architecture through the transport mapping subsystem. 122 One such external protocol is the Secure Shell protocol [SSHArch]. 124 This memo describes the Secure Shell Security Model for SNMP, a 125 specific SNMP security model to be used within the SNMP Architecture, 126 to provide authentication, encryption, and integrity checking of SNMP 127 messages. 129 This memo defines a portion of the Management Information Base (MIB) 130 for use with network management protocols in TCP/IP based internets. 131 In particular it defines objects for monitoring and managing the 132 Secure Shell Security Model for SNMP. 134 In keeping with the RFC 3411 design decisions to use self-contained 135 documents, this memo includes the elements of procedure plus 136 associated MIB objects which are needed for processing the Secure 137 Shell Security Model for SNMP. These MIB objects should not be 138 referenced in other documents. This allows the Secure Shell Security 139 Model for SNMP to be designed and documented as independent and self- 140 contained, having no direct impact on other modules, and allowing 141 this module to be upgraded and supplemented as the need arises, and 142 to move along the standards track on different time-lines from other 143 modules. 145 This modularity of specification is not meant to be interpreted as 146 imposing any specific requirements on implementation. 148 1.1 Motivation 150 Version 3 of the Simple Network Management Protocol (SNMPv3) added 151 security to the previous versions of the protocol. The User Security 152 Model (USM) [RFC3414] was designed to be independent of other 153 existing security infrastructures, to ensure it could function when 154 third party authentication services were not available, such as in a 155 broken network. As a result, USM typically utilizes a separate user 156 and key management infrastructure. Operators have reported that 157 deploying another user and key management infrastructure in order to 158 use SNMPv3 is a reason for not deploying SNMPv3 at this point in 159 time. 161 This memo describes a security model that will make use of the 162 existing and commonly deployed Secure Shell security infrastructure. 163 It is designed to meet the security and operational needs of network 164 administrators, maximize useability in operational environments to 165 achieve high deployment success and at the same time minimize 166 implementation and deployment costs to minimize the time until 167 deployment is possible. 169 The work will address the requirement for the SSH client to 170 authenticate the SSH server, for the SSH server to authenticate the 171 SSH client (the user), and how SNMP can make use of the authenticated 172 identities in authentication and auditing. . 174 The work will include the ability to use any of the user 175 authentication methods described in "SSH Authentication Protocol" 176 [SSHAuth] - public key, password, and host-based. Local accounts may 177 be supported through the use of the public key, host-based or 178 password based mechanisms. The password based mechanism allows for 179 integration with deployed password infrastructure such as AAA servers 180 using the RADIUS protocol [RFC2865]. In the future it should also be 181 able to take advantage of other defined authentication mechanism such 182 as those defined in [gsskeyex] which will allow for user 183 authentication mechanisms which support different security 184 infrastructures and provide security properties. 186 It is desirable to use mechanisms that could unify the approach for 187 administrative security for SNMPv3 and CLI and other management 188 interfaces. The use of security services provided by Secure Shell is 189 the approach commonly used for the CLI, and is the approach being 190 adopted for use with NETCONF [Netconf]. Similar to NETCONF over SSH 191 [NetconfSSH], this memo describes a method for invoking and running 192 the SNMP protocol within a Secure Shell (SSH) session as an SSH 193 subsystem. 195 This memo defines how SNMP can be used within a Secure Shell (SSH) 196 session, using the SSH connection protocol [SSHConnect] over the SSH 197 transport protocol [SSHTrans], using SSH user-auth [SSHAuth]for 198 authentication. 200 There are a number of challenges to be addressed to map Secure Shell 201 authentication method parameters into the SNMP architecture so that 202 SNMP continues to work without any surprises. These are discussed in 203 detail below. Some points requiring further WG research and 204 discussion are identified by [todo] markers in the text. 206 1.2 The Internet-Standard Management Framework 208 For a detailed overview of the documents that describe the current 209 Internet-Standard Management Framework, please refer to section 7 of 210 RFC 3410 [RFC3410]. 212 Managed objects are accessed via a virtual information store, termed 213 the Management Information Base or MIB. MIB objects are generally 214 accessed through the Simple Network Management Protocol (SNMP). 215 Objects in the MIB are defined using the mechanisms defined in the 216 Structure of Management Information (SMI). This memo specifies a MIB 217 module that is compliant to the SMIv2, which is described in STD 58, 218 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 219 [RFC2580]. 221 1.3 The Secure Shell Protocol 223 SSH is a protocol for secure remote login and other secure network 224 services over an insecure network. It consists of three major 225 components: 226 o The Transport Layer Protocol [[SSHTrans] provides server 227 authentication, confidentiality, and integrity. It may optionally 228 also provide compression. The transport layer will typically be 229 run over a TCP/IP connection, but might also be used on top of any 230 other reliable data stream. 231 o The User Authentication Protocol [SSHAuth] authenticates the 232 client-side user to the server. It runs over the transport layer 233 protocol. 234 o The Connection Protocol [SSHConnect] multiplexes the encrypted 235 tunnel into several logical channels. It runs over the user 236 authentication protocol. 238 The client sends a service request once a secure transport layer 239 connection has been established. A second service request is sent 240 after user authentication is complete. This allows new protocols to 241 be defined and coexist with the protocols listed above. 243 The connection protocol provides channels that can be used for a wide 244 range of purposes. Standard methods are provided for setting up 245 secure interactive shell sessions and for forwarding ("tunneling") 246 arbitrary TCP/IP ports and X11 connections. 248 1.4 Constraints 250 The design of this SNMP Security Model is also influenced by the 251 following constraints: 252 1. When the requirements of effective management in times of network 253 stress are inconsistent with those of security, the design of 254 this model gives preference to the former. 255 2. In times of network stress, neither the security protocol nor its 256 underlying security mechanisms should depend upon the ready 257 availability of other network services (e.g., Network Time 258 Protocol (NTP) or AAA protocols). 259 3. When the network is not under stress, the security model and its 260 underlying security mechanisms MAY depend upon the ready 261 availability of other network services. 262 4. It may not be possible for the security model to determine when 263 the network is under stress. 264 5. A security mechanism should entail no changes to the basic SNMP 265 network management philosophy. 267 1.5 Conventions 269 The terms "manager" and "agent" are not used in this document, 270 because in the RFC 3411 architecture, all entities have the 271 capability of acting as either manager or agent or both depending on 272 the SNMP applications included in the engine. Where distinction is 273 required, the application names of Command Generator, Command 274 Responder, Notification Generator, Notification Rewsponder, and Proxy 275 Forwarder are used. See "SNMP Applications" [RFC3413] for further 276 information. 278 Throughout this document, the terms "client" and "server" are used to 279 refer to the two ends of the SSH transport connection. The client 280 actively opens the SSH connection, and the server passively listens 281 for the incoming SSH connection. Either entity may act as client or 282 as server, as discussed further below. 284 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 285 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 286 document are to be interpreted as described in [RFC2119]. 288 2. How SSHSM Fits into the TMSM Architecture 290 SSH is a security layer which is plugged into the TMSM architecture 291 between the underlying transport layer and the message dispatcher. 293 The SSHSM model will establish an encrypted tunnel between the 294 transport mappings of two SNMP engines. The sending transport 295 mapping security model instance encrypts outgoing messages, and the 296 receiving transport mapping security model instance decrypts the 297 messages. 299 After the transport layer tunnel is established, then SNMP messages 300 can conceptually be sent through the tunnel from one SNMP message 301 dispatcher to another SNMP message dispatcher. Once the tunnel is 302 established, multiple SNMP messages may be able to be passed through 303 the same tunnel. 305 Within an engine, outgoing SNMP messages are passed unencrypted from 306 the message dispatcher to the transport mapping, and incoming 307 messages are passed unencrypted from the transport mapping to the 308 message dispatcher. SSHSM security processing will be called from 309 within the Transport Mapping functionality of an SNMP engine 310 dispatcher to perform the translation of transport security 311 parameters to/from security-model-independent parameters. Some SSHSM 312 security processing will also be performed within a message 313 processing portion of the model, for compatibility with the ASIs 314 between the RFC 3411 Security Subsystem and the Message Processing 315 Subsystem. 317 2.1 Security Capabilities of this Model 319 2.1.1 Threats 321 The security protocols used in this memo are considered acceptably 322 secure at the time of writing. However, the procedures allow for new 323 authentication and privacy methods to be specified at a future time 324 if the need arises. 326 The Secure Shell Security Model provides protection against the 327 threats identified by the RFC 3411 architecture [RFC3411]: 329 1. Message stream modification - Provide for verification that each 330 received SNMP message has not been modified during its 331 transmission through the network. . 332 2. Information modification - Provide for verification that the 333 contents of each received SNMP message has not been modified 334 during its transmission through the network. Data has not been 335 altered or destroyed in an unauthorized manner, nor have data 336 sequences been altered to an extent greater than can occur non- 337 maliciously 338 3. Masquerade - Provide for both verification of the identity of the 339 user on whose behalf a received SNMP message claims to have been 340 generated, and the verification of the identity of the MIB owner. 341 For the protocols specified in this memo, it is not possible to 342 assure the specific user that originated a received SNMP message; 343 rather, it is the user on whose behalf the message was originated 344 that is authenticated. SSH provides verification of the identity 345 of the MIB owner through the SSH Transport Protocol server 346 authentication [SSHTrans]. 347 4. Verification of user identity is important for use with the SNMP 348 access control subsystem, to ensure that only authorized users 349 have access to potentially sensitive data. The SSH user identity 350 will be used to map to an SNMP model-independent securityname for 351 use with SNMP access control. 352 5. Authenticating the server ensures the authenticity of the SSH 353 server that is associated with the SNMP engine that provides MIB 354 data. Operators or management applications could act upon the 355 data they receive (e.g. raise an alarm for an operator, modify 356 the configuration of the device that sent the notification, 357 modify the configuration of other devices in the network as the 358 result of the notification, and so on) , so it is important to 359 know that the data is authentic. SSH allows for authenticaiton 360 of the SSH server using the SSH public key credentials described 361 in [SSHTrans] and mechanisms such as those described in 362 [gsskeyex]. 363 6. Disclosure - Provide, when necessary, that the contents of each 364 received SNMP message are protected from disclosure to 365 unauthorized persons.. 366 7. Replay - Provide for detection of received SNMP messages, which 367 request or contain management information, whose time of 368 generation was not recent. A message whose generation time is 369 outside of a time window is not accepted. Note that message 370 reordering is not dealt with and can occur in normal conditions 372 2.1.1.1 Data Origin Authentication Issues 374 The RFC 3411 architecture recognizes three levels of security: 375 - without authentication and without privacy (noAuthNoPriv) 376 - with authentication but without privacy (authNoPriv) 377 - with authentication and with privacy (authPriv) 379 SSH provides support for encryption and data integrity. While it is 380 technically possible to support noAuthNoPriv and authNoPriv in SSH it 381 is NOT RECOMMENDED by [SSHTrans]. This means that an SSH connection 382 should support authPriv, which is the highest level of security 383 defined in RFC 3411. It is possible for SSH to skip entity 384 authenticaiton of the client through the "none" authentication method 385 to support anonymous clients, however in the this case an 386 implementation MUST still support data integrity within the SSH 387 transport protocol. The security protocols used in [SSHTrans] are 388 considered acceptably secure at the time of writing. However, the 389 procedures allow for new authentication and privacy methods to be 390 specified at a future time if the need arises. 392 authNoPriv may be important to accommodate governmental regulation 393 (e.g. export laws) regarding encryption technologies. 395 [todo] is it important to support anonymous user access to SNMP? 397 Should the transport layer provide what data integrity and encryption 398 algorithms were negotiated to the SSHSM layer? In SNMP, we 399 deliberately avoided this, and settled for an assertion that auth and 400 priv were applied accoridng to the rules of the security model. 402 SSH should also provide the identity of the authenticated parties. 403 From this information it should be possible for the SNMP subsystem to 404 determine if the session is allowed access to the subsystem. 406 2.1.1.1.1 noAuthPriv 408 SSH provides the "none" userauth method, which is normally rejected 409 by servers and used only to find out what userauth methods are 410 supported. However, it is legal for a server to accept this method, 411 which has the effect of not authenticating the ssh client to the ssh 412 server. Doing this does not compromise authentication of the ssh 413 server to the ssh client, nor does it compromise data confidentiality 414 or data integrity. 416 The RFC 3411 architecture does not permit noAuthPriv. SSHSM should 417 refuse a noAuthPriv session [todo] If we do not allow some of these 418 options, how do we determine the option was used, so we can reject 419 it? How does an SNMP engine reject a session? 421 2.1.1.1.2 skipping public key verification 423 [todo] Most key exchange algorithms are able to authenticate the SSH 424 server's identity to the client. However, for the common case of DH 425 signed by public keys, this requires the client to know the host's 426 public key a priori and to verify that the correct key is being used. 427 If this step is skipped, you no longer have authentication of the ssh 428 server to the ssh client. You do still get data confidentiality and 429 data integrity protection to whatever server you're talking to, but 430 these are of dubious value when an attacker can insert himself 431 between the client and the real ssh server. Note that some userauth 432 methods may defend against this situation, but many of the common 433 ones (including password and keyboard-interactive) do not, and in 434 fact depend on the fact that the server's identity has been verified 435 (otherwise you may be giving your password to an attacker). 437 2.1.1.1.3 the 'none' MAC algorithm 439 SSH provides the "none" MAC algorithm, which would allow you to turn 440 off data integrity while maintaining confidentiality. However, if 441 you do this, then an attacker may be able to modify the data in 442 flight, which means you effectively have no authentication. 444 SSH must not be configured using the "none" MAC algorithm for use 445 with the SSHSM security model. 447 2.1.2 Sessions 449 Sessions are not part of RFC 3411 architecture, but are considered 450 desirable because the cost of authentication can be amortized over 451 potentially many transactions. The Secure Shell security model will 452 utilize sessions, with a single user and security level associated 453 with each session. If an exchange with another engine would require 454 a different security level or would be on behalf of a different user, 455 then another session would be needed. An immediate consequence of 456 this is that implementations should be able to maintain some 457 reasonable number of concurrent sessions. This document will discuss 458 the impact of sessions on SNMP usage. [todo] 460 2.1.2.1 Message security versus session security 462 As part of session creation the client and server entities are 463 typically authenticated and authorized access to the session. In 464 addition as part of session establishment cryptographic key material 465 is exchanged and is then used to control access to the session on a 466 message by message basis. Messages that fail the basic data origin 467 authenticaiton/ data integrity checks will be rejected. Entities 468 receiving the messages that do not have the correct encryption keys 469 established during session creation will not be able to read the 470 messgaes. In order for an entity to process messages it must 471 maintain certain state associated with the session. This includes, 472 but is not limited to cryptographic encryption and data integrity 473 keys, entity identities and authorization information associated with 474 the authenticated identites. After a message is received and passes 475 integrity and authentication checks then the state stored in the 476 session is used to provide further authorization for the message. 478 2.1.3 Authentication Protocol 480 SSHSM should support any user authentication mechanism supported by 481 SSH. 483 The SSH Authentication Protocol document describes three 484 authentication methods - publickey, password, and host-based. All 485 three authentication methods are supported by the Secure Shell 486 Security Model for SNMP. 488 The password authentication mechanism allows for integration with 489 deployed password based infrastructure. It is possible to hand a 490 password to a service such as RADIUS [RFC2865] or Diameter [RFC 3588] 491 for validation. The validation could be done using the user-name and 492 user-password attributes. It is also possible to use a different 493 password validation protcol such as CHAP [RFC1994] or digest 494 authentication [RFC 2617, draft-ietf-radext-digest-auth-04] to 495 integrate with RADIUS. Any of these mechanism leave the password in 496 the clear on the device that is authenticating the password which 497 introduces threats on the authentication infrastructure which is less 498 than ideal. It is possible that new mechanism will be developed 499 using authentication mechanisms defined in [gsskeyex] which will 500 allow for user authentication mechanisms which support different 501 security infrastructures and provide security properties." 503 2.1.4 Privacy Protocol 505 The Secure Shell Security Model uses the SSH transport layer 506 protocol, which provides strong encryption, server authentication, 507 and integrity protection. 509 2.1.5 Protection against Message Replay, Delay and Redirection 511 The Secure Shell Security Model uses the SSH transport layer 512 protocol. SSH uses sequence numbers and integrity checks to protect 513 against replay and reordering of messages within a connection. 515 SSH also provides protection against replay of entire sessions. In a 516 properly-implemented DH exchange, both sides will generate new random 517 numbers for each exchange, which means the exchange hash and thus the 518 encryption and integrity keys will be distinct for every session. 519 This would prevent capturing an SNMP message and redirecting it to 520 another SNMP engine. 522 Message delay is not as important an issue with SSH as it is with 523 USM. USM checks the timeliness of messages because it does not 524 provide session protection or message sequence ordering. The only 525 delay that would seem to be possible would be to capture the next 526 sequence numbered packet and hold it to play within the same session 527 later. 529 2.1.6 Security Protocol Requirements 531 Modifying the Secure Shell protocol, or configuring it in a 532 particular manner, may change its security characteristics in ways 533 that would impact other existing usages. If a change is necessary, 534 the change should be an extension that has no impact on the existing 535 usages. This document will describe the use of an SSH subsytem for 536 SNMP. 538 It has been a long-standing requirement that SNMP be able to work 539 when the network is unstable, to enable network troubleshooting and 540 repair. The UDP approach has been considered to meet that need well, 541 with an assumption that getting small messages through, even if out 542 of order, is better than gettting no messages through. There has 543 been a long debate about whether UDP actually offers better support 544 than TCP when the underlying IP or lower layers are unstable. There 545 has been recent discussion of whether operators actually use SNMP to 546 troubleshoot and repair unstable networks. This document will 547 include a discussion of the operational expectations of this model 548 for use in troubleshooting a broken network.[todo] This may belong 549 in the TMSM document. 551 There has been discussion of ways SNMP could be extended to better 552 support management/monitoring needs when a network is running just 553 fine. Use of a TCP transport, for example, could enable larger 554 message sizes and more efficient table retrievals. Secure Shell runs 555 over TCP. This document will discuss the expected ramifications of 556 using a TCP transport for SNMP, and the coexistence of UDP and TCP 557 transport for SNMP. [todo] Should this be discussed in the TMSM 558 document? 560 The Secure Shell security model can coexist with the USM security 561 model, the only other currently defined security model. [todo] 562 compare to RFC3584 to see if there are any wrinkles to coexistence 563 with SNMPv1/v2c. 565 2.1.6.1 Mapping SSH to EngineID 567 In the RFC3411 architecture, there are three use cases for an 568 engineID: 569 snmpEngineID - RFC3411 includes the SNMP-FRAMEWORK-MIB, which 570 defines a snmpEngineID object. An snmpEngineID is the unique and 571 unambiguous identifier of an SNMP engine. Since there is a one- 572 to-one association between SNMP engines and SNMP entities, it also 573 uniquely and unambiguously identifies the SNMP entity within an 574 administrative domain. 575 contextEngineID - Management information resides at an SNMP entity 576 where a Command Responder Application has local access to 577 potentially multiple contexts. This application uses a 578 contextEngineID equal to the snmpEngineID of its associated SNMP 579 engine. 580 securityEngineID - The RFC3411 architecture defines ASIs that 581 include a securityEngineID - the authoritative SNMP entity - which 582 is either the local snmpEngineID or the target snmpEngineID, 583 depending on the type of operation. Since a security model might 584 utilize shared credentials and integrity-checking parameters, and 585 the datastores of the two endpoints could get out of sync, the 586 "authoritative" engineID indicates which end has the values to be 587 used. 589 The securityEngineID is used by USM when performing integrity 590 checking and authentication, to look up values in the USM tables, and 591 to synchronize "clocks". The securityEngineID is not needed by 592 SSHSM, since integrity checking and authentication are handled 593 outside the SNMP engine. 595 [todo] is there still a need for an "authoritative SNMP engine"? 596 Does authoritative have any meaning in a TMSM/SSHSM environment? In 597 SNMPv3, the authoritative engine is usually the engine with the 598 command responder, i.e. the agent; in non-proxy situations, 599 securityEngineID equals contextEngineID. in client-server terms, the 600 authoritative engine is usually the server. So, should the SNMP 601 engine associated with the SSH server be authoritative? Would Infoms 602 change that? Would bidirectional messaging change that? Would call- 603 home change that? Do we need to set the securityEngineID to indicate 604 which side is the SSH server? 606 2.2 Security Parameter Passing Requirement 608 [SSHSM follows the TMSM approach, in which the security -model 609 specific parameters can be determined from the transport layer by the 610 transport mapping, before the message processing begins. 612 [todo] For outgoing messages, it is necessary to have an MPSP portion 613 of the security model because it is the MPSP that actually creates 614 the WholeMsg from its component parts. In the SSHSM model, the MPSP 615 does not apply encryption, integrity-checking, or authentication. 616 For example, an SNMPv3 message is built without any content in the 617 SecurityParameters field, and the WholeMsg is passed unencrypted back 618 to the Message Processing Model for forwarding to the Transport 619 Mapping. 621 A cache mechanism will be used, into which the TMSP puts information 622 about the security applied to an incoming message, and an MPSP 623 extracts that information from the cache. Given that there may be 624 multiple TM-security caches, a cache ID will need to be passed 625 through an ASI so the MPSP knows which cache of information to 626 consult. [todo] 628 The cache reference could be thought of as an additional parameter in 629 the ASIs between the transport mapping and the messaging security 630 model. The RFC 3411 ASIs would not need to be changed since the 631 SNMPv3 WG expected that additional parameters could be passed for 632 value-add features of specific implementations. 634 This approach does create dependencies between a model-specific TPSP 635 and a corresponding specific MPSP. If a TMSM-model-independent ASI 636 parameter is passed, this approach would be consistent with the 637 securityStateReference cache already being passed around in the ASI. 639 2.3 Requirements for Notifications 641 [todo] cleanup this section 643 RFC 3430 (SNMP over TCP) suggests that TCP connections are initiated 644 by notification originators in case there is no currently established 645 connection that can be used to send the notification. Following this 646 approach with ssh would require to provision authentication 647 credentials on the agent so that agents can successfully authenticate 648 to a notification receiver. There might be other approaches, like 649 the reuse of manager initiated secure transport connections for 650 notifications. There is some text in Appendix A in RFC 3430 which 651 captures some of these discussions when RFC 3430 was written. 653 2.4 Scenario Diagrams 655 RFC 3411 section 4.6 provides scenario diagrams to illustrate how an 656 outgoing message is created, and how an incoming message is 657 processed. Both diagrams are incomplete, however.In section 4.61, 658 the diagram doesn't show the ASI for sending an SNMP request to the 659 network or receiving an SNMP response message from the network. In 660 section 4.6.2, the diagram doesn't illustrate the interfaces required 661 to receive an SNMP message from the network, or to send an SNMP 662 message to the network. 664 2.4.1 Command Generator or Notification Originator 666 This diagram from RFC 3411 4.6.1 shows how a Command Generator or 667 Notification Originator application requests that a PDU be sent, and 668 how the response is returned (asynchronously) to that application. 670 Command Dispatcher Message Security 671 Generator | Processing Model 672 | | Model | 673 | sendPdu | | | 674 |------------------->| | | 675 | | prepareOutgoingMessage | | 676 : |----------------------->| | 677 : | | generateRequestMsg | 678 : | |-------------------->| 679 : | | | 680 : | |<--------------------| 681 : | | | 682 : |<-----------------------| | 683 : | | | 684 : |------------------+ | | 685 : | Send SNMP | | | 686 : | Request Message | | | 687 : | to Network | | | 688 : | v | | 689 : : : : : 690 : : : : : 691 : : : : : 692 : | | | | 693 : | Receive SNMP | | | 694 : | Response Message | | | 695 : | from Network | | | 696 : |<-----------------+ | | 697 : | | | 698 : | prepareDataElements | | 699 : |----------------------->| | 700 : | | processIncomingMsg | 701 : | |-------------------->| 702 : | | | 703 : | |<--------------------| 704 : | | | 705 : |<-----------------------| | 706 | processResponsePdu | | | 707 |<-------------------| | | 708 | | | | 710 2.4.2 Command Responder 712 This diagram shows how a Command Responder or Notification Receiver 713 application registers for handling a pduType, how a PDU is dispatched 714 to the application after an SNMP message is received, and how the 715 Response is (asynchronously) send back to the network. 717 Command Dispatcher Message Security 718 Responder | Processing Model 719 | | Model | 720 | | | | 721 | registerContextEngineID | | | 722 |------------------------>| | | 723 |<------------------------| | | | 724 | | Receive SNMP | | | 725 : | Message | | | 726 : | from Network | | | 727 : |<-------------+ | | 728 : | | | 729 : |prepareDataElements | | 730 : |------------------->| | 731 : | | processIncomingMsg | 732 : | |------------------->| 733 : | | | 734 : | |<-------------------| 735 : | | | 736 : |<-------------------| | 737 | processPdu | | | 738 |<------------------------| | | 739 | | | | 740 : : : : 741 : : : : 742 | returnResponsePdu | | | 743 |------------------------>| | | 744 : | prepareResponseMsg | | 745 : |------------------->| | 746 : | |generateResponseMsg | 747 : | |------------------->| 748 : | | | 749 : | |<-------------------| 750 : | | | 751 : |<-------------------| | 752 : | | | 753 : |--------------+ | | 754 : | Send SNMP | | | 755 : | Message | | | 756 : | to Network | | | 757 : | v | | 759 2.5 Abstract Service Interfaces 760 3. RFC 3411 Abstract Service Interfaces 762 Abstract service interfaces have been defined by RFC 3411 to describe 763 the conceptual data flows between the various subsystems within an 764 SNMP entity. The Secure Shell Security Model uses some of these 765 conceptual data flows when communicating with other subsystems, such 766 as the Message Processing Subsystem. These RFC 3411-defined data 767 flows are referred to here as public interfaces. 769 3.1 Public Abstract Service Interfaces 771 3.1.1 Public ASIs for Outgoing Messages 773 The IN parameters of the prepareOutgoingMessage() ASI are used to 774 pass information from the dispatcher (application subsystem) to the 775 message processing subsystem. The OUT parameters are used to pass 776 information from the message processing subsystem to the dispatcher 777 and on to the transport mapping: 779 statusInformation = -- success or errorIndication 780 prepareOutgoingMessage( 781 IN transportDomain -- transport domain to be used 782 IN transportAddress -- transport address to be used 783 IN messageProcessingModel -- typically, SNMP version 784 IN securityModel -- Security Model to use 785 IN securityName -- on behalf of this principal 786 IN securityLevel -- Level of Security requested 787 IN contextEngineID -- data from/at this entity 788 IN contextName -- data from/in this context 789 IN pduVersion -- the version of the PDU 790 IN PDU -- SNMP Protocol Data Unit 791 IN expectResponse -- TRUE or FALSE 792 IN sendPduHandle -- the handle for matching 793 -- incoming responses 794 OUT destTransportDomain -- destination transport domain 795 OUT destTransportAddress -- destination transport address 796 OUT outgoingMessage -- the message to send 797 OUT outgoingMessageLength -- its length 798 ) 800 The abstract service primitive from a Message Processing Model to a 801 Security Model to generate the components of a Request message is: 803 statusInformation = -- success or errorIndication 804 generateRequestMsg( 805 IN messageProcessingModel -- typically, SNMP version 806 IN globalData -- message header, admin data 807 IN maxMessageSize -- of the sending SNMP entity 808 IN securityModel -- for the outgoing message 809 IN securityEngineID -- authoritative SNMP entity 810 IN securityName -- on behalf of this principal 811 IN securityLevel -- Level of Security requested 812 IN scopedPDU -- message (plaintext) payload 813 OUT securityParameters -- filled in by Security Module 814 OUT wholeMsg -- complete generated message 815 OUT wholeMsgLength -- length of generated message 816 ) 818 The abstract service primitive from a Message Processing Model to a 819 Security Model to generate the components of a Response message is: 821 statusInformation = -- success or errorIndication 822 generateResponseMsg( 823 IN messageProcessingModel -- typically, SNMP version 824 IN globalData -- message header, admin data 825 IN maxMessageSize -- of the sending SNMP entity 826 IN securityModel -- for the outgoing message 827 IN securityEngineID -- authoritative SNMP entity 828 IN securityName -- on behalf of this principal 829 IN securityLevel -- Level of Security requested 830 IN scopedPDU -- message (plaintext) payload 831 IN securityStateReference -- reference to security state 832 -- information from original 833 -- request 834 OUT securityParameters -- filled in by Security Module 835 OUT wholeMsg -- complete generated message 836 OUT wholeMsgLength -- length of generated message 837 ) 839 The abstract data elements passed as parameters in the abstract 840 service primitives are as follows: [todo] check each parameter and 841 determine if it is necessary for SSHSM and whether the description is 842 accurate 843 statusInformation - An indication of whether the encoding and 844 securing of the message was successful. If not it is an 845 indication of the problem. 846 messageProcessingModel - The SNMP version number for the message 847 to be generated. This data is not used by the User-based Security 848 module. 850 globalData - The message header (i.e., its administrative 851 information). This data is not used by the User-based Security 852 module. 853 maxMessageSize - The maximum message size as included in the 854 message. This data is not used by the User-based Security module. 855 securityParameters - These are the security parameters. They will 856 be filled in by the SSH Security module. 857 securityModel - The securityModel in use. Should be SSH Security 858 Model. 859 securityName - identifies a principal to be used for securing an 860 outgoing message. The securityName has a format that is 861 independent of the Security Model. In case of a response this 862 parameter is ignored and the value from the cache is used. 863 securityLevel - The Level of Security from which the SSH Security 864 module determines if the message needs to be protected from 865 disclosure and if the message needs to be authenticated. 866 securityEngineID - The snmpEngineID of the authoritatvie SNMP 867 engine to which a dateRequest message is to be sent. In case of a 868 response it is implied to be the processing SNMP engine's 869 snmpEngineID and so if it is specified, then it is ignored. 870 scopedPDU - The message payload. The data is opaque as far as the 871 SSH Security Model is concerned. 872 securityStateReference - A handle/reference to cachedSecurityData 873 to be used when securing an outgoing Response message. This is 874 the exact same handle/reference as it was generated by the SSH 875 Security module when processing the incoming Request message to 876 which this is the Response message. 877 wholeMsg - The fully encoded SNMP message ready for sending on the 878 wire. 879 wholeMsgLength - The length of the encoded SNMP message 880 (wholeMsg). 881 Upon completion of the process, the SSH Security module returns 882 statusInformation. If the process was successful, the completed 883 message is returned, without the privacy and authentication 884 applied yet. If the process was not successful, then an 885 errorIndication is returned. 887 3.1.2 Public ASIs for Incoming Messages 889 The abstract service primitive from a Transport Mapping (in the 890 dispatcher) to a Message Processing Model for a received message is:: 892 result = -- SUCCESS or errorIndication 893 prepareDataElements( 894 IN transportDomain -- origin transport domain 895 IN transportAddress -- origin transport address 896 IN wholeMsg -- as received from the network 897 IN wholeMsgLength -- as received from the network 898 OUT messageProcessingModel -- typically, SNMP version 899 OUT securityModel -- Security Model to use 900 OUT securityName -- on behalf of this principal 901 OUT securityLevel -- Level of Security requested 902 OUT contextEngineID -- data from/at this entity 903 OUT contextName -- data from/in this context 904 OUT pduVersion -- the version of the PDU 905 OUT PDU -- SNMP Protocol Data Unit 906 OUT pduType -- SNMP PDU type 907 OUT sendPduHandle -- handle for matched request 908 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 909 OUT statusInformation -- success or errorIndication 910 -- error counter OID/value if error 911 OUT stateReference -- reference to state information 912 -- to be used for possible Response 913 ) 915 The abstract service primitive from a Message Processing Model to the 916 Security Subsystem for a received message is:: 918 statusInformation = -- errorIndication or success 919 -- error counter OID/value if error 920 processIncomingMsg( 921 IN messageProcessingModel -- typically, SNMP version 922 IN maxMessageSize -- of the sending SNMP entity 923 IN securityParameters -- for the received message 924 IN securityModel -- for the received message 925 IN securityLevel -- Level of Security 926 IN wholeMsg -- as received on the wire 927 IN wholeMsgLength -- length as received on the wire 928 OUT securityEngineID -- authoritative SNMP entity 929 OUT securityName -- identification of the principal 930 OUT scopedPDU, -- message (plaintext) payload 931 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 932 OUT securityStateReference -- reference to security state 933 ) -- information, needed for response 935 3.2 Private Abstract Service Interfaces 937 A set of abstract service interfaces have been defined within this 938 document to describe the conceptual data flows between the Secure 939 Shell Security Model (SSHSM) and the self-contained transport mapping 940 services.These apply only to the Secure Shell Security Model (SSHSM), 941 and are referred to here as private interfaces. 943 The Secure Shell Security Model provides the following internal 944 primitives to pass data back and forth between the Security Model 945 itself and the SSH authentication service: 947 statusInformation = 948 establishSession( 949 IN transportDomain -- transport domain to be used 950 IN transportAddress -- transport address to be used 951 IN securityModel -- Security Model to use 952 IN securityEngineID -- SNMP entity 953 IN securityName -- on behalf of this principal 954 IN securityLevel -- Level of Security requested 955 OUT sessionID 956 ) 958 4. SNMP Messages Using this Security Model 960 The syntax of an SNMP message using this Security Model adheres to 961 the message format defined in the version-specific Message Processing 962 Model document (for example [RFC3412]). At the time of this writing, 963 there are three defined message formats - SNMPv1, SNMPv2c, and 964 SNMPv3. 966 4.1 SNMPv1 and SNMPv2c Messages Using this Security Model 968 Since message security is provided by a "lower layer", the message 969 does not need to carry message security parameters within the PDU. 971 The securityModel and securityName parameters are determined by the 972 Secure Shell Security Model from the SSH service. SSHSM requires 973 that transport always be authenticated and integrity-checked, and 974 encrypted, so all SSHSM messages are authpriv. Since an incoming 975 SNMPv1 or SNMPv2c message lacks a msgFlags field, the msgFlags is 976 always treated as authPriv. [todo] 978 The communitystring is not used as an authentication mechansism, 979 since user authentication is provided by SSH userauth. The community 980 string is still used to provide context information. 982 The SNMPv1 and SNMPv2c message formats do not contain a 983 contextEngineID, but do contain an IP Address field that can be used 984 to perform proxy. [todo] determine the proxy forwarding mechanism, if 985 any. 987 4.2 SNMPv3 Messages Using this Security Model 989 RFC 3412 defines two primitives, generateRequestMsg() and 990 processIncomingMsg() which require the specification of an 991 authoritative SNMP entity. [todo] We need to discuss what the meaning 992 of authoritative would be in a TMSM environment, whether the specific 993 services provided in USM security from msgSecurityParameters are 994 needed in TMSM/SSHSM, and how the Message Processing model provides 995 this information to the security model via generateRequestMsg() and 996 processIncomingMsg() primitives. 998 The SNMPv3Message SEQUENCE is defined in [RFC3412]. The following 999 fields are specific to the Secure Shell Security Model: 1001 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN 1003 SNMPv3Message ::= SEQUENCE { 1004 -- identify the layout of the SNMPv3Message 1005 -- this element is in same position as in SNMPv1 1006 -- and SNMPv2c, allowing recognition 1007 -- the value 3 is used for snmpv3 1008 msgVersion INTEGER ( 0 .. 2147483647 ), 1009 -- administrative parameters 1010 msgGlobalData HeaderData, 1011 -- security model-specific parameters 1012 -- format defined by Security Model 1013 msgSecurityParameters OCTET STRING, 1014 msgData ScopedPduData 1015 } 1017 HeaderData ::= SEQUENCE { 1018 msgID INTEGER (0..2147483647), 1019 msgMaxSize INTEGER (484..2147483647), 1021 msgFlags OCTET STRING (SIZE(1)), 1022 -- .... ...1 authFlag 1023 -- .... ..1. privFlag 1024 -- .... .1.. reportableFlag 1025 -- Please observe: 1026 -- .... ..00 is OK, means noAuthNoPriv 1027 -- .... ..01 is OK, means authNoPriv 1028 -- .... ..10 reserved, MUST NOT be used. 1029 -- .... ..11 is OK, means authPriv 1031 msgSecurityModel INTEGER (1..2147483647) 1032 } 1034 ScopedPduData ::= CHOICE { 1035 plaintext ScopedPDU, 1036 encryptedPDU OCTET STRING -- encrypted scopedPDU value 1037 } 1039 ScopedPDU ::= SEQUENCE { 1040 contextEngineID OCTET STRING, 1041 contextName OCTET STRING, 1042 data ANY -- e.g., PDUs as defined in [RFC3416] 1043 } 1044 END 1046 4.2.1 msgGlobalData 1048 SSHSM requires that transport always be authenticated, integrity- 1049 checked, and encrypted, so all SSHSM messages are authpriv. The 1050 msgFlags MUST always be set to authPriv. 1052 msgSecurityModel is set to the IANA-assigned value for the Secure 1053 Shell Security Model. See 1054 http://www.iana.org/assignments/snmp-number-spaces. 1056 4.2.1.1 msgSecurityParameters 1058 Since message security is provided by a "lower layer", and the 1059 securityName parameter is always determined from the SSH 1060 authentication method, the SNMP message does not need to carry 1061 message security parameters within the msgSecurityParameters field. 1062 To prevent its being used in a manner that could be damaging, such as 1063 for carrying a virus or worm, when used with SSHSM, it is an empty 1064 field. [todo] should this be an ASN.1 NULL within the OCTET STRING, 1065 or just a zero-length OCTET STRING? 1067 The field msgSecurityParameters in SNMPv3 messages has a data type of 1068 OCTET STRING. Its value MUST be the BER serialization of the 1069 following ASN.1 sequence: 1071 SSHSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN 1073 SSHsmSecurityParameters ::= 1074 SEQUENCE { 1075 NULL 1076 } 1077 END 1079 4.2.1.2 msgFlags 1081 [todo] For an outgoing message, msgFlags is the requested security 1082 for the message; if a SSHSM cannot provide the requested 1083 securityLevel, the request MUST be discarded and SHOULD notify the 1084 message processing model that the request failed. [todo: how does 1085 this apply in the SSHSM model, especially if the msgFlags MUST always 1086 be set to authpriv?] 1088 [todo] do we need do discuss the rest of this, or is this applicable 1089 to all TMSM models? 1091 For an outgoing message, it is acceptable for the SSHSM to provide 1092 stronger than requested security. To avoid the need to mess with the 1093 ASN.1 encoding, the SNMPv3 message carries the requested msgFlags, 1094 not the actual securityLevel applied to the message. If a message 1095 format other than SNMPv3 is used, then the new message may carry the 1096 more accurate securityLevel in the SNMP message. 1098 For an incoming message, the receiving SSHSM knows what must be done 1099 to process the message based on the transport layer mechanisms. If 1100 the underlying transport security mechanisms for the receiver cannot 1101 provide the matching securityLevel, then the message should follow 1102 the standard behaviors for the transport security mechanism, or be 1103 discarded silently. 1105 Part of the responsibility of the SSHSM is to ensure that the actual 1106 security provided by the underlying transport layer security 1107 mechanisms is configured to meet or exceed the securityLevel required 1108 by the msgFlags in the SNMP message. When the MPSP processes the 1109 incoming message, it should compare the msgFlags field to the 1110 securityLevel actually provided for the message by the transport 1111 layer security. If they differ, the MPSP should determine whether 1112 the changed securityLevel is acceptable. If not, it should discard 1113 the message. 1115 4.3 Passing Security Parameters 1117 For each message received, the Security Model caches the state 1118 information such that a Response message can be generated using the 1119 same security information, even if the Configuration Datastore is 1120 altered between the time of the incoming request and the outgoing 1121 response. For SSHSM, there are three levels of state that need to be 1122 maintained: the session, the message, and the model-independent 1123 translations. 1125 [todo]ensuring consistent security for responses even if the 1126 datastore changes is important for USM because USM handles 1127 keychanges; will SSHSM allow keychanges to the SSH local datastore? 1128 if not, this cache of message-pair-state may be an unnecessary 1129 constraint. is it important to ensure responses use the same security 1130 as the request for secureity reasons? 1132 tmSessionReference is used to pass model- and mechanism-specific 1133 parameters to coordinate the session-related activities of the TMSP 1134 and MPSP. The SSHSM has the responsibility for explicitly releasing 1135 the tmSessionReference when the session is destroyed. 1137 tmStateReference is used to pass model- and mechanism-specific 1138 parameters to coordinate the activities of the TMSP and MPSP related 1139 to a specific pair of messages. The SSHSM has the responsibility for 1140 explicitly releasing the tmStateReference once a response message has 1141 been sent, or the data is no longer needed. 1143 The MPSP translates select parameters from the tmSessionReference 1144 cache into model-independent parameters subsequently passed in the 1145 securityStateReference cache to a Message Processing Model. The 1146 Message Processing Model has the responsibility for explicitly 1147 releasing the securityStateReference if such data is no longer 1148 needed. The securityStateReference cached data may be implicitly 1149 released via the generation of a response, or explicitly released by 1150 using the stateRelease primitive, as described in RFC 3411 section 1151 4.5.1." 1153 4.3.1 Transport Session Parameters 1155 [todo] SSHSM will create a session between the TMSM of one SNMP 1156 entity and the TMSM of another SNMP entity. The created "tunnel" 1157 will provide encryption and data integrity. The SSHSM model MUST 1158 provide mutual authentication of the client and server, and MUST 1159 authenticate, integrity-check, and encrypt the messages. 1161 Upon establishment of a SSH session, the TMSP will cache the state 1162 information about the transport parameters. The tmSessionReference 1163 will be passed to the corresponding MPSP. 1165 [todo] The tmSessionReference cache for use with the SSH 1166 Authentication Protocol [SSHAuth]: 1167 tmStateReference 1168 tmSecurityStateReference 1169 tmTransportDomain = TCP/IPv4 1170 tmTransportAddress = x.x.x.x:y 1171 tmSecurityModel - SSHSM 1172 tmSecurityLevel = "authPriv" 1173 tmSessionID = Handshake session identifier 1174 tmSessionKey = Handshake peer certificate 1175 tmSessionMasterSecret = master secret 1176 tmSessionParameters = compression method, cipher spec, is- 1177 resumable 1179 tmSecurityName = "dbharrington" 1180 tmAuthMechanism = "[todo]" 1181 tmAuthProtocol = "" 1182 tmRadiusServer = "" 1183 tmPrivProtocol = "" 1185 Additional information will be added to the tmStateReference by the 1186 authentication portion of the SSHSM. 1188 4.3.1.1 Authenticating Servers and Clients 1190 [todo] can we mandate mutual authentication? 1192 4.3.2 [todo] Using Local Accounts to Authenticate Users 1194 Upon creation of a SSH session leveraging SSH Local Accounts, the 1195 TMSP will cache the session authentication information in the 1196 tmSessionReference: 1197 tmSecurityName = "dbharrington" 1198 tmAuthMechanism = "public key" 1199 tmAuthProtocol = LocalAccounts 1201 4.3.3 [todo] Using RADIUS Accounts to Authenticate Users 1203 Upon creation of a SSH session leveraging RADIUS Accounts, the TMSP 1204 will cache the session authentication information in the 1205 tmSessionReference: 1206 tmSecurityName is the name used in username field of the RADIUS 1207 ACCESS-REQUEST message. 1208 tmAuthMechanism = "[todo]" 1209 tmAuthProtocol = RADIUS 1210 tmRadiusServer = x.x.x.x:y 1212 4.3.4 securityStateReference for SSHSM 1214 [todo] 1215 messageProcessingModel = SNMPv3 1216 securityModel = SSHSM 1217 securityName = tmSecurityName 1218 securityLevel = msgSecurityLevel 1220 4.4 MIB Module for SSH Security Model 1222 Each security model should use its own MIB module, rather than 1223 utilizing the USM MIB, to eliminate dependencies on a model that 1224 could be replaced some day. See RFC 3411 section 4.1.1. 1226 The SSHSM-MIB module needs to provide the mapping from model-specific 1227 identity to a model independent securityName, and possibly a mapping 1228 to a groupname. 1230 [todo] Module needs to be worked out once things become stable... 1232 4.5 [todo] Notifications 1234 For notifications, if the cache has been released and then session 1235 closed, then the MPSP will request the TMSP to establish a session, 1236 populate the cache, and pass the securityStateReference to the MPSP. 1238 [todo] We need to determine what state needs to be saved here. 1240 5. Elements of Procedure 1242 5.1 Establishing a Session 1244 The Secure Shell Security Model provides the following internal 1245 primitive to pass data back and forth between the Security Model 1246 itself and the SSH authentication service: 1248 statusInformation = 1249 establishSession( 1250 IN transportDomain -- transport domain to be used 1251 IN transportAddress -- transport address to be used 1252 IN securityModel -- Security Model to use 1253 IN securityEngineID -- SNMP entity 1254 IN securityName -- on behalf of this principal 1255 IN securityLevel -- Level of Security requested 1256 OUT sessionID 1257 ) 1259 The following describes the procedure to follow to establish a 1260 session between a client and sever to run SNMP over SSH. This 1261 process is followed by any SNMP engine establishing a session for 1262 subsequent use. In practice, this is done by an application that 1263 initiates a transaction, such as a Command Generator or a 1264 Notification Originator or a Proxy Forwarder. It is never triggered 1265 by an application preparing a response message, such as a Command 1266 Responder or Notification Receiver, because securityStatereference 1267 will always have session information for a response message 1269 The parameters necessary to establish a session are provided by the 1270 Secure Shell Security Model to the SSH client code, using the 1271 establishSession() ASI. 1273 1) If the securityLevel specifies that the message is to be 1274 authenticated, but the SSH implementation does not support an 1275 authentication protocol, then the message cannot be sent. An error 1276 indication (unsupportedSecurityLevel) is returned to the calling 1277 module. 1279 2) If the securityLevel specifies that the message is to be protected 1280 from disclosure, but the SSH implementation does not support 1281 encryption, then the message cannot be sent. An error indication 1282 (unsupportedSecurityLevel) is returned to the calling module. 1284 3) Using destTransportDomain and destTransportAddress, the client 1285 will establish an SSH transport connection using the SSH transport 1286 protocol, and the client and server will mutually authenticate, and 1287 exchange keys for message integrity and encryption. if the attempt to 1288 establish a connection is successful, then tmStateReference is 1289 created, and the values of destTransportDomain and 1290 destTransportAddress are saved. If the attempt to establish a 1291 connection is unsuccessful, then an error indication [todo] will be 1292 returned, and [todo] processing stops. 1294 4) The provided securityEngineID is used to lookup the associated 1295 entry in the Local Configuration Datastore (LCD), and the 1296 securityName, securityModel, and securityLevel, information 1297 concerning the user at the destination is extracted. This step 1298 allows preconfiguration of model-specific user identities mapped to a 1299 securityName. Set the username in the SSH_MSG_USERAUTH_REQUEST to 1300 the username extracted from the LCD. 1302 If information about the user is absent from the LCD, then set the 1303 username in the SSH_MSG_USERAUTH_REQUEST to the value of 1304 securityName. This allows a deployment without preconfigured 1305 mappings between model-specific and model-independent names, but the 1306 securityName will need to contain a username recognized by the 1307 authentication mechanism. 1309 5)The client will then invoke the "ssh-userauth" service to 1310 authenticate the user, as described in the SSH authentication 1311 protocol [SSHAuth]. 1313 6) If the authentication is unsuccessful, then the transport 1314 connection should be closed, tmStateReference is discarded, the 1315 message is discarded, an error indication (unknownSecurityName) is 1316 returned to the calling module, and processing stops for this 1317 message. 1319 7) Once the user has been successfully authenticated, the client will 1320 invoke the "ssh- connection" service, also known as the SSH 1321 connection protocol [SSHConnect]. 1323 8) After the ssh-connection service is established, the client will 1324 use an SSH_MSG_CHANNEL_OPEN message to open a channel of type 1325 "session", providing a selected sender channel number, and a maximum 1326 packet size based on maxMessageSize. 1328 9) If successful, this will result in an SSH session. The 1329 destTransportDomain nd the destTransportAddress, plus the "recipient 1330 channel" and "sender channel" and other relevant data from the 1331 SSH_MSG_CHANNEL_OPEN_CONFIRMATION are added to the tmStateReference 1332 for subsequent use. 1334 10) Once the SSH session has been established, the SNMP engine will 1335 invoke SNMP as an SSH subsystem called "SNMP". Running SNMP as an 1336 SSH subsystem avoids the need for the script to recognize shell 1337 prompts or skip over extraneous information, such as a system message 1338 that is printed at shell start-up. 1340 In order to allow SNMP traffic to be easily identified and filtered 1341 by firewalls and other network devices, servers associated with SNMP 1342 entities using the Secure Shell Security Model MUST default to 1343 providing access to the "SNMP" SSH subsystem only when the SSH 1344 session is established using the IANA-assigned TCP port (TBD). 1345 Servers SHOULD be configurable to allow access to the SNMP SSH 1346 subsystem over other ports. 1348 [todo] check whether there is a better way to establish a tunnel for 1349 SNMP messages. 1351 [todo] Should we perform some type of engineID discovery to provide 1352 the mapping between transport address, session, and engineID at this 1353 point in the session establishment procedure? We have an established 1354 channel; can we simply send a GET of snmpEngineID and record the 1355 value i the tmStateReference? 1357 11) [todo] the engine will perform an SNMP GET command requesting the 1358 value of the remote engine's snmpEngineID object, and create a 1359 tmSessionReference cache recording the following information: 1360 the remote engine's snmpEngineID 1361 the transport address 1362 the recipient and sender channels 1364 5.2 Discovery 1366 Since snmpEngineID isn't really needed for authentication and 1367 integrity checking, it becomes useful primarily for contextEngineID. 1368 contextEngineID is useful for proxy, and for a management application 1369 to uniquely identify an SNMP entity. Since snmpEngineID is an object 1370 in the SNMP-FRAMEWORK-MIB, the mapping between engineID and transport 1371 address could be established after a tunnel is established, or could 1372 be determined using noAuthNoPriv (with suitable caveats). 1374 [todo] Auto-discovery of SNMP devices is an important feature of many 1375 NMS platforms. Should we simply use a noAuthNoPriv request, and 1376 recommend an associated access control configuration that only makes 1377 accessible relatively benign data such as sysOID, sysDescription, and 1378 snmpEngineID? Should we standardize this approach for all TMSM 1379 models, including a "named policy" for what can be discovered (a 1380 policy to be configured within whatever access control system is 1381 used)? 1383 Alternatively, can we let USM perform discovery so we don't have to 1384 attenpt to establish an SSH connection first? USM is the mandatory- 1385 to-implement security model, so this could make sense. 1387 5.3 Generating an Outgoing SNMP Message 1389 This section describes the procedure followed by the Secure Shell 1390 Security Model whenever it generates a message containing a 1391 management operation (like a request, a response, a notification, or 1392 a report) on behalf of a user. 1394 The parameters needed are supplied by the Message Processing Model 1395 via the generateRequestMsg() or the generateResponseMsg() ASI 1397 statusInformation = -- success or errorIndication 1398 generateRequestMsg( 1399 IN messageProcessingModel -- typically, SNMP version 1400 IN globalData -- message header, admin data 1401 IN maxMessageSize -- of the sending SNMP entity 1402 IN securityModel -- for the outgoing message 1403 IN securityEngineID -- authoritative SNMP entity 1404 IN securityName -- on behalf of this principal 1405 IN securityLevel -- Level of Security requested 1406 IN scopedPDU -- message (plaintext) payload 1407 OUT securityParameters -- filled in by Security Module 1408 OUT wholeMsg -- complete generated message 1409 OUT wholeMsgLength -- length of generated message 1410 OUT tmStateReference -- reference to session info 1411 ) 1413 statusInformation = -- success or errorIndication 1414 generateResponseMsg( 1415 IN messageProcessingModel -- typically, SNMP version 1416 IN globalData -- message header, admin data 1417 IN maxMessageSize -- of the sending SNMP entity 1418 IN securityModel -- for the outgoing message 1419 IN securityEngineID -- authoritative SNMP entity 1420 IN securityName -- on behalf of this principal 1421 IN securityLevel -- Level of Security requested 1422 IN scopedPDU -- message (plaintext) payload 1423 IN securityStateReference -- reference to security state 1424 -- information from original 1425 -- request 1426 OUT securityParameters -- filled in by Security Module 1427 OUT wholeMsg -- complete generated message 1428 OUT wholeMsgLength -- length of generated message 1429 OUT tmStateReference -- reference to session info 1430 ) 1432 verify securityModel = sshsmSecurityModel 1433 If there is a securityStateReference, extract the tmStateReference 1434 information from the cachedSecurityData from the Request message. 1435 [todo] With USM, at the point the cachedSecurityData can now be 1436 discarded. Since we now have persistent sessions, this is no 1437 longer true, but can some of the cached data be discarded, such as 1438 message pair information? 1439 If there is no securityStateReference, then lookup the session 1440 info indexed by {securityEngineID, securityName, securityLevel}, 1441 and set tmStateReference. 1442 If there is no session info for this index, then create an 1443 incomplete tmStateReference indexed by the provided 1444 {securityEngineID, securityName, securityLevel}. Store the 1445 securityModel and maxMessageSize information. When the TMSP gets 1446 the incomplete tmStateReference, it will recognize that it needs 1447 to establish a new session, and fill in the rest of the 1448 information for subsequent use. 1449 fill in securityParameters [todo] a NULL octet string since 1450 [todo] we don't need to send securityEngineID, unless it is 1451 needed for a discovery mechanism.. 1452 [todo] we don't need to send Boots and Time values 1453 [todo] we don't need to send a username, since we use the one 1454 from SSH authentication 1455 [todo] we don't need to call authenticateOutgoingMsg() 1456 The wholeMsg is now serialized and then represents the 1457 unauthenticated message being prepared. 1458 The completed message (wholeMsg) with its length (wholeMsgLength) 1459 and securityParameters (a NULL octet string) and tmStateReference 1460 is returned to the calling module with the statusInformation set 1461 to success. 1463 The Message Processing Model then passes information to the 1464 disptacher for forwarding to the Transport Mapping. 1466 5.4 Sending an Outgoing SNMP Message to the Network 1468 The TMSP portion of the Secure Shell Security Model performs the 1469 following tasks: 1470 Uses tmStateReference to lookup session information. 1471 [todo] verifies that auth and priv can be provided, as requested, 1472 and error-out if not. 1473 If the session information is incomplete (i.e, has no 1474 tmTransportAddress), then call establishSession() using the 1475 destTransportDomain and destTransportAddress (the output of the 1476 PrepareOutgoingMessage() ASI) and the securityModel, 1477 securityEngineID, securityName, securityLevel from the 1478 tmStateReference. Store all information in the tmStateReference 1479 for subsequent use. 1480 An SSH_MSG_CHANNEL_DATA message is sent, indicating the recipient 1481 channel and encapsulating the wholeMessage. 1483 [todo] According to RFC 3411, section 4.1.1, the application provides 1484 the transportDomain and transportAddress to the PDU dispatcher via 1485 the sendPDU() primitive. If we permit multiple sessions per 1486 transportAddress, then we would need to define how session 1487 identifiers get passed from the application to the PDU dispatcher 1488 (and then to the MP model). 1490 [todo] The SNMP over TCP Transport Mapping document [RFC3430] says 1491 that TCP connections can be recreated dynamically or kept for future 1492 use and actually leaves all that to the transport mapping. 1494 [todo] We might have a MIB module that records the session 1495 information for subsequent use by the applications and other 1496 subsytems, or it might be passed in the tmStateReference cache. For 1497 notifications, I assume the SNMPv3 notification tables would be a 1498 place to find the address, but I'm not sure how to identify the 1499 presumably-dynamic session identifiers. The MIB module could 1500 identify whether the session was initiated by the remote engine or 1501 initiated by the current engine, and possibly assigned a purpose 1502 (incoming request/response or outgoing notifications). First we need 1503 to decide whether to handle notifications and requests in one or two 1504 (or more) sessions. Do we use an established session bi- 1505 directionally, or do we establish two separate sessions, one for each 1506 direction as needed? 1508 5.5 [todo] Prepare Data Elements from an Incoming SNMP Message 1510 For an incoming message, the TMSP will need to put information from 1511 the transport mechanisms used into the tmStateReference so the MPSP 1512 can extract the information and add it conceptually to the 1513 securityStateReference. 1515 5.6 Processing an Incoming SNMP Message 1517 This section describes the procedure followed by an SNMP engine 1518 whenever it receives a message containing a management operation on 1519 behalf of a user. 1521 To simplify the elements of procedure, the release of state 1522 information is not always explicitly specified. As a general rule, 1523 if state information is available when a message gets discarded, the 1524 message-state information should also be released. Also, an error 1525 indication can return an OID and value for an incremented counter and 1526 optionally a value for securityLevel, and values for contextEngineID 1527 or contextName for the counter. In addition, the 1528 securityStateReference data is returned if any such information is 1529 available at the point where the error is detected. [todo] this 1530 paragraph may no longer be accurate because of persistent session 1531 state information. 1533 The abstract service primitive from a Message Processing Model to the 1534 Security Subsystem for a received message is:: 1536 statusInformation = -- errorIndication or success 1537 -- error counter OID/value if error 1538 processIncomingMsg( 1539 IN messageProcessingModel -- typically, SNMP version 1540 IN maxMessageSize -- of the sending SNMP entity 1541 IN securityParameters -- for the received message 1542 IN securityModel -- for the received message 1543 IN securityLevel -- Level of Security 1544 IN wholeMsg -- as received on the wire 1545 IN wholeMsgLength -- length as received on the wire 1546 OUT securityEngineID -- authoritative SNMP entity 1547 OUT securityName -- identification of the principal 1548 OUT scopedPDU, -- message (plaintext) payload 1549 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 1550 OUT securityStateReference -- reference to security state 1551 ) -- information, needed for response 1553 1) If the received securityParameters is not the serialization of an 1554 OCTET STRING formatted according to the SSHsmSecurityParameters , 1555 then the snmpInASNParseErrs counter [RFC3418] is incremented, and an 1556 error indication (parseError) is returned to the calling module. 1557 [todo] Note that we return without the OID and value of the 1558 incremented counter, which may be important if this security model 1559 supports generating a Report PDU (which SSHSM doesn't so far), 1560 because in this case there is not enough information to generate a 1561 Report PDU. 1563 [todo] If we actually do not extract anything from 1564 securityParameters, do we need to check whether this parses 1565 correctly? It apparently parsed well enough to pass the parse test 1566 in the messaging model. Could we simply ignore the 1567 securityParameters being passed in? The only argument I see for 1568 checking to ensure this is empty/null is to ensure somebody isn't 1569 using the filed for non-standard purposes, such as passing a virus in 1570 the field. 1572 2) The SSHSM queries the associated SSH engine, in an 1573 implementation-dependent manner, to determine the transport and 1574 security parameters for the received message: 1575 a) the transportDomain and transportAddress 1576 b) the authentication parameters, including the authenticated 1577 username 1578 c) the encryption options, 1579 d) the integrity-checking options 1581 3) The securityEngineID to be returned to the caller is determined in 1582 an implementation-dependent manner, such as by using the transport 1583 address to perform a lookup in its Local Configuration Datastore 1584 (LCD). If the securityEngineID is unknown, then an SNMP engine may 1585 perform discovery to create a new entry in its LCD and continue 1586 processing. Note that securityEngineID is required by the SNMPv3 1587 message processing model in RFC 3412 section 7.2 13a) 1589 4) If the information about the message security indicates that the 1590 security options do not match the securityLevel requested by the 1591 caller, then the SSHsmStatsUnsupportedSecLevels counter is 1592 incremented and an error indication (unsupportedSecurityLevel) 1593 together with the OID and value of the incremented counter is 1594 returned to the calling module. 1596 5) The scopedPDU component is assumed to be in plain text and is the 1597 message payload to be returned to the calling module. 1599 7) The maxSizeResponseScopedPDU is calculated. This is the maximum 1600 size allowed for a scopedPDU for a possible Response message. 1601 Provision is made for a message header that allows the same 1602 securityLevel as the received Request. 1604 [todo] Is this relevant? Can it be calculated once for the session? 1605 Do we need to take into consideration the SSH window size? 1607 10) Information about the value of the SSH username is extracted from 1608 the Local Configuration Datastore (LCD) to provide conversion from 1609 the SSHSM model-specific username to a model-independent 1610 securityName. If no information is available for the username, then 1611 the securityName is set to the username used in the SSH-USER-AUTH- 1612 REQUEST. [todo] Note that USM at this point would flag an 1613 unknownSecurityName error. 1615 11) The security data is cached as cachedSecurityData, so that a 1616 possible response to this message can and will use the same 1617 authentication and privacy parameters. Information to be saved/ 1618 cached is as follows: 1619 transportDomain, transportAddress 1620 securityEngineID 1621 SSH username, 1622 auth options [todo] 1623 encryption options [todo] 1624 Integrity checking options [todo] 1626 12) The statusInformation is set to success and a return is made to 1627 the calling module passing back the OUT parameters as specified in 1628 the processIncomingMsg primitive. 1630 6. MIB module definition 1632 SSHSM-MIB DEFINITIONS ::= BEGIN 1634 IMPORTS 1635 MODULE-IDENTITY, OBJECT-TYPE, 1636 OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI 1637 TEXTUAL-CONVENTION FROM SNMPv2-TC 1638 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 1639 SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 1641 sshsmMIB MODULE-IDENTITY 1642 LAST-UPDATED "200509020000Z" 1643 ORGANIZATION "ISMS Working Group" 1644 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 1645 Subscribe: isms-request@lists.ietf.org 1647 Chair: 1648 Juergen Quittek 1649 NEC Europe Ltd. 1650 Network Laboratories 1651 Kurfuersten-Anlage 36 1652 69115 Heidelberg 1653 Germany 1654 +49 6221 90511-15 1655 quittek@netlab.nec.de 1657 Co-editors: 1658 David Harrington 1659 Effective Software 1660 50 Harding Rd 1661 Portsmouth, New Hampshire 03801 1662 USA 1663 +1 603-436-8634 1664 ietfdbh@comcast.net 1666 Juergen Schoenwaelder 1667 International University Bremen 1668 Campus Ring 1 1669 28725 Bremen 1670 Germany 1671 +49 421 200-3587 1672 j.schoenwaelder@iu-bremen.de 1674 Joseph Salowey 1675 Cisco Systems 1676 2901 3rd Ave 1677 Seattle, WA 98121 1678 USA 1679 jsalowey@cisco.com 1680 " 1681 DESCRIPTION "The Secure Shell Security Model MIB 1683 Copyright (C) The Internet Society (2005). This 1684 version of this MIB module is part of RFC XXXX; 1685 see the RFC itself for full legal notices. 1686 -- NOTE to RFC editor: replace XXXX with actual RFC number 1687 -- for this document and remove this note 1688 " 1690 REVISION "200509020000Z" -- 02 September 2005 1691 DESCRIPTION "The initial version, published in RFC XXXX. 1692 -- NOTE to RFC editor: replace XXXX with actual RFC number 1693 -- for this document and remove this note 1694 " 1696 ::= { mib-2 xxxx } 1697 -- RFC Ed.: replace xxxx with IANA-assigned number and 1698 -- remove this note 1699 -- ---------------------------------------------------------- -- 1700 -- subtrees in the SSHSM-MIB 1701 -- ---------------------------------------------------------- -- 1703 sshsmNotifications OBJECT IDENTIFIER ::= { sshsmMIB 0 } 1704 sshsmObjects OBJECT IDENTIFIER ::= { sshsmMIB 1 } 1705 sshsmConformance OBJECT IDENTIFIER ::= { sshsmMIB 2 } 1707 -- ------------------------------------------------------------- 1708 -- Objects 1709 -- ------------------------------------------------------------- 1711 -- ------------------------------------------------------------- 1712 -- sshsmMIB - Conformance Information 1713 -- ------------------------------------------------------------- 1715 sshsmGroups OBJECT IDENTIFIER ::= { sshsmConformance 1 } 1717 sshsmCompliances OBJECT IDENTIFIER ::= { sshsmConformance 2 } 1719 -- ------------------------------------------------------------- 1720 -- Units of conformance 1721 -- ------------------------------------------------------------- 1722 sshsmGroup OBJECT-GROUP 1723 OBJECTS { 1725 } 1726 STATUS current 1727 DESCRIPTION 1728 "Secure Shell Security Model objects" 1729 ::= { sshsmGroups 2 } 1731 -- ------------------------------------------------------------- 1732 -- Compliance statements 1733 -- ------------------------------------------------------------- 1735 sshsmCompliance MODULE-COMPLIANCE 1736 STATUS current 1737 DESCRIPTION 1738 "The compliance statement for support of the 1739 Secure Shell Security Model" 1740 MODULE 1741 MANDATORY-GROUPS { 1743 } 1744 ::= { sshsmCompliances 1 } 1746 END 1748 7. Security Considerations 1750 This document describes a security model that would permit SNMP to 1751 utilize SSH security services. [todo] expand as needed. 1753 SSHv2 provides PFS for encryption keys. PFS is a major design goal 1754 of SSH, and any well-designed keyex algorithm will provide it. 1756 [todo] We will probably need to discuss the security implications of 1757 password based authentication methods. 1759 8. IANA Considerations 1761 IANA is requested to assign: 1762 a TCP port number which will be the default port for SNMP over SSH 1763 sessions as defined in this document, 1764 an SMI number under mib-2, for the MIB module in this document, 1765 an SNMP SecurityModel for the Secure Shell Security Model, as 1766 documented in the MIB module in this document, 1768 9. Acknowledgments 1770 The editors would like to thank Jeffrey Hutzelman and Nicholas 1771 Williams for sharing their SSH insights. 1773 10. References 1775 10.1 Normative References 1777 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1778 Architecture for Describing Simple Network Management 1779 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1780 December 2002. 1782 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1783 "Message processing and Dispatching for SNMP", STD 62, 1784 RFC 3412, December 2002. 1786 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1787 (USM) for version 3 of the Simple Network Management 1788 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1790 [RFC3417] Presuhn (Editor), R., "Transport Mappings for the Simple 1791 Network Management Protocol (SNMP)", STD 62, RFC 3417, 1792 December 2002. 1794 [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol 1795 (SNMP) over Transmission Control Protocol (TCP) Transport 1796 Mapping", RFC 3430, December 2002. 1798 [TMSM] Harrington, D. and J. Schoenwaelder, "Transport Mapping 1799 Security Model (TMSM) for the Simple Network Management 1800 Protocol version 3 (SNMPv3)", 1801 draft-schoenw-snmp-tlsm-04.txt (work in progress), 1802 August 2005. 1804 [SSHArch] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 1805 draft-ietf-secsh-architecture-22 (work in progress), 1806 March 2005. 1808 [SSHTrans] 1809 Lonvick, C., "SSH Transport Layer Protocol", 1810 draft-ietf-secsh-transport-24 (work in progress), 1811 March 2005. 1813 [SSHAuth] Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", 1814 draft-ietf-secsh-userauth-27 (work in progress), 1815 March 2005. 1817 [SSHConnect] 1818 Lonvick, C. and T. Ylonen, "SSH Connection Protocol", 1819 draft-ietf-secsh-connect-25 (work in progress), 1820 March 2005. 1822 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1823 "Remote Authentication Dial In User Service (RADIUS)", 1824 RFC 2865, June 2000. 1826 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1827 Schoenwaelder, Ed., "Structure of Management Information 1828 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1830 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1831 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1832 STD 58, RFC 2579, April 1999. 1834 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1835 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1836 April 1999. 1838 10.2 Informative References 1840 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1841 "Introduction and Applicability Statements for Internet- 1842 Standard Management Framework", RFC 3410, December 2002. 1844 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 1845 Management Protocol (SNMP) Applications", STD 62, 1846 RFC 3413, December 2002. 1848 [Netconf] Enns, R., "NETCONF Configuration Protocol", 1849 ID draft-ietf-netconf-prot-04.txt, October 2004. 1851 [NetconfSSH] 1852 Wasserman, M. and T. Goddard, "Using the NETCONF 1853 Configuration Protocol over Secure Shell (SSH)", 1854 draft-ietf-netconf-ssh-04 (work in progress), April 2005. 1856 [gsskeyex] 1857 Hutzelman, J., "GSSAPI Authentication and Key Exchange for 1858 the Secure Shell Protocol", draft-ietf-secsh-gsskeyex-09 1859 (work in progress), May 2005. 1861 Authors' Addresses 1863 David Harrington 1864 Effective Software 1865 Harding Rd 1866 Portsmouth NH 1867 USA 1869 Phone: +1 603 436 8634 1870 Email: dbharrington@comcast.net 1872 Juergen Schoenwaelder 1873 International University Bremen 1874 Campus Ring 1 1875 28725 Bremen 1876 Germany 1878 Phone: +49 421 200-3587 1879 Email: j.schoenwaelder@iu-bremen.de 1880 Joseph Salowey 1881 Cisco Systems 1882 2901 3rd Ave 1883 Seattle, WA 98121 1884 USA 1886 Email: jsalowey@cisco.com 1888 Appendix A. Change Log from the first revision of -00- 1890 -00-b draft: 1891 re-ordered the sections from abstract to concrete. 1892 worked on how the SSHSM fitsinto the RFC3411 and TMSM 1893 architectures. 1894 added goals tot he Motivation section. 1895 worked on Security Capabilities based on input from Joe, Nick, and 1896 JHutz. Added Joe to the authors list based on contributed text. 1897 created Data origin Authentication section, to separate this 1898 discussion. 1899 expanded "Authentication Protocol" section 1900 Updated Message replay section. 1901 --00-c draft 1902 worked on security information cacheing, including breaking caches 1903 into session, message, and model-independent (which we probably 1904 want to remerge later) 1905 eliminated a lot of TMSM-carryover stuff and modified to be SSHSM- 1906 specific. 1907 updated references. 1908 filled in Elements of Procedure for Outgoing Messages 1909 created shell for SSHSM-MIB 1910 -01- draft 1911 added Processing an Incoming Message 1912 updated change log 1913 modified masquerade discussion to differentiate server vs user 1914 authentication 1915 added [todos] for Data origin Authentication Issues section, 1916 trying to nail down whether we even need this section. 1917 disallow the 'none' MAC algorithm 1918 added text to Message secuirty versus session security 1919 wordsmithed "authentication protocol" section 1920 rewrote "Mapping SSH to EngineID", eliminating most [todos] 1921 modified "Establishing a Session" 1923 Intellectual Property Statement 1925 The IETF takes no position regarding the validity or scope of any 1926 Intellectual Property Rights or other rights that might be claimed to 1927 pertain to the implementation or use of the technology described in 1928 this document or the extent to which any license under such rights 1929 might or might not be available; nor does it represent that it has 1930 made any independent effort to identify any such rights. Information 1931 on the procedures with respect to rights in RFC documents can be 1932 found in BCP 78 and BCP 79. 1934 Copies of IPR disclosures made to the IETF Secretariat and any 1935 assurances of licenses to be made available, or the result of an 1936 attempt made to obtain a general license or permission for the use of 1937 such proprietary rights by implementers or users of this 1938 specification can be obtained from the IETF on-line IPR repository at 1939 http://www.ietf.org/ipr. 1941 The IETF invites any interested party to bring to its attention any 1942 copyrights, patents or patent applications, or other proprietary 1943 rights that may cover technology that may be required to implement 1944 this standard. Please address the information to the IETF at 1945 ietf-ipr@ietf.org. 1947 Disclaimer of Validity 1949 This document and the information contained herein are provided on an 1950 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1951 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1952 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1953 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1954 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1955 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1957 Copyright Statement 1959 Copyright (C) The Internet Society (2005). This document is subject 1960 to the rights, licenses and restrictions contained in BCP 78, and 1961 except as set forth therein, the authors retain all their rights. 1963 Acknowledgment 1965 Funding for the RFC Editor function is currently provided by the 1966 Internet Society.